Named Pipe von injected DLL zu Programm
-
UIPI greift sowohl für Messages als auch Pipes. Nur bei den Pipes kannst Du eben die Security explizit setzen.
Das ganz ist nur relevant, wen nDu zwischen Applikationen mit unterschieldichen UIPI-Level kommunizieren willst (also z.B: Service und UI)
-
Omfg starte Editor und Programm als Admin, dann funktioniert auch das Pipen. Oder was kapier ich da nicht
Und warum sollte die Injection dann nicht mehr funktionieren... Frickelalarm
wenns so einfach wäre du eumel... der Editor ist natürlich nur zu Testzwecken mein Programm für die Injection, später kann die Task der Injection variieren, somit auch die Adminrechte. Und das von mir geschriebene Programm wird nicht als Admin gestartet. Punkt!
Das ganz ist nur relevant, wen nDu zwischen Applikationen mit unterschieldichen UIPI-Level kommunizieren willst (also z.B: Service und UI)
Also nochmal zu Wiederholung, mit der richtigen Securityeinstellung beim Erstellen meiner Pipe kann ich die UIPI-Level unbeachtet lassen?
Ist es denn auch möglich ein anderes Programm in Sachen Sicherheit herrunter zustufen? Hatte da mal irgendwas mit Tokens gelesen,...Aufjedenfall mal Danke für eure Hilfe!
Gruß serverHorst
-
Dann setze DACL und UIPI level und gut ist.
In meinen Artikel ist ein Sample und die Erklärung ist auch vollständig, dass hat nichts mit Frickeln zu tun.
-
Ich bins wieder,... ich hoffe ich geh euch nicht zu sehr auf den Keks aaaaber:
Hab mir das ganze mit den Security_Attributes mal angeschaut, zum anderen hab ich in einem Forum diesen Thread gefunden: http://social.msdn.microsoft.com/Forums/en-SG/netfxnetcom/thread/0d1f713c-9f6b-481f-b0ad-da303c1d4424
Mein Problem ist ja aber ehr dass er die Pipe erst gar nicht findet. Er sagt immer "Der angegebene Pfadname ist ungültig".
So, habe nun einfach mal diese Sicherheits Struktur ausgefüllt und zwar so dass jeder Zugriff drauf hat (glaube ich zumindest)
Server:
char buf_in[255] = ""; char buf_out[255] = "this is a server test"; DWORD readBytes; SECURITY_ATTRIBUTES sa; SECURITY_DESCRIPTOR sd; InitializeSecurityDescriptor(&sd,SECURITY_DESCRIPTOR_REVISION); SetSecurityDescriptorDacl(&sd,TRUE,NULL,FALSE); SetSecurityDescriptorGroup(&sd,NULL, FALSE ); SetSecurityDescriptorSacl(&sd, FALSE, NULL, FALSE ); sa.nLength = sizeof(SECURITY_ATTRIBUTES); sa.lpSecurityDescriptor = &sd; sa.bInheritHandle = TRUE; hPipe = CreateNamedPipe(PIPENAME, PIPE_ACCESS_DUPLEX, PIPE_TYPE_MESSAGE | PIPE_WAIT, 1, 1024, 1024, 5000, &sa);
Client:
char buf_in[255] = ""; char buf_out[255] = "this is a client test"; DWORD readBytes; LPTSTR Error = 0; Sleep(500); if(!WaitNamedPipe((LPCWSTR)PIPENAME, NMPWAIT_WAIT_FOREVER)) { // ERROR DWORD err = GetLastError(); MessageBox(NULL, _T("WaitNamePipe Error"), 0, MB_OK); FormatMessage( FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM, NULL, err, 0, (LPTSTR)&Error, 0, NULL); MessageBox(NULL, Error, 0, MB_OK); return; }
Bei beiden:
#define PIPENAME "\\\\.\\pipe\\dllConnection"
n meinen Artikel ist ein Sample und die Erklärung ist auch vollständig, dass hat nichts mit Frickeln zu tun.
Wo genau finde ich dieses Sample? Meinst du etwa in dem Artikel den jmd auf der ersten Seite gepostet hat?
@Martin: Du wolltest wohl auf das hier verweisen:
http://blog.m-ri.de/index.php/2007/02/21/uac-und-createnamedpipe-mit-lpsecurityattributesnull/AFAIK erlaubt eine NULL DACL nur Zugriff im selber UIPI-Level oder darüber...
Wäre super dankbar wenn mir jmd in diesem Wirrwarr weiter helfen könnte
Gruß serverHorst
-
Was oll bitte dieser cast?
if(!WaitNamedPipe((LPCWSTR)PIPENAME, NMPWAIT_WAIT_FOREVER)) {
Könnte es sein, dass Du hier ein Unicode Programm hast und einen char* castest?
Und keine T-Notation verwendest?Wenn das so ist, dann ist es kein Wunder, dass die Pipenich tgefunden wird.
Zudem, warum WaitNamedPip überhaupt ohne Not verwenden?Und was bitte für ein Wirrwarr?
-
Könnte es sein, dass Du hier ein Unicode Programm hast und einen char* castest?
Und keine T-Notation verwendest?Klingt logisch,.. warum ich das mach?! Beim Server will er LPCSTR als Parameter und beim Client LPCWSTR... war mir ehrlich gesagt gar nicht aufgefallen dass es zwei unterschiedliche sind. Wie lös ich denn dann das Problem?! Den ohne diese zwei Casts meckert mein Compiler.
Wirrwarr deswegen weil ICH bei diesen ganzen Security Dings nicht so wirklich dahinter schnall. Ich versteh zwar wieso und weshalb der ganze Stress von Seitens Windows aber ich will ja "nur" eine Simple Verbindung zwischen meine Programm und dem injizierten
-
Bzgl WaitNamedPipe....
klar ich könnte auch gleich CreateFile machen, aber damit ist mein Problem nicht behoben:Client:
hPipe = CreateFile(_T(PIPENAME), GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);
Server:
hPipe = CreateNamedPipe(_T(PIPENAME), PIPE_ACCESS_DUPLEX, PIPE_TYPE_MESSAGE | PIPE_WAIT, 1, 1024, 1024, 5000, &sa);
... (eben noch das _T miteingebaut, "Das System kann die angegebene Datei nicht finden")
-
Ich nochmal,... ;-))
Klappt nun soweit alles, aber eine Sache ist da noch bzgl den Pipes die mich beschäftigt...
Hab meine Pipe mit PIPE_ACCESS_DUPLEX angelegt. Hatte die Vorstellung auf beiden Seiten zwei Threads zu machen, jeweils einer der ReadFile mach (welches ja blockiert solange bis Daten reinkommen) und einer welcher Daten reinschreibt, da ich nie weiss wann welches Programm mal was schickt. Jetzt hab ich aber festgestellt dass ich nichts von Prozess A in die Pipe schreiben kann wenn Prozess A gleichzeitig in einem anderen Thread ReadFile macht (was auch irgendwie Sinn ergibt wenn man das ganze mal im Kopf durchspinnt)...
Muss meine Lösung also "mach einfach zwei Pipes" lauten oder ist da noch was dran zu rütteln mit einer Pipe?! Oder hat mir vielleicht jmd ein Beispiel mit einer Pipe mit PIPE_ACCESS_DUPLEX bei welchem trotzdem mal der eine Prozess mal der Andere asynchron irgendetwas sendet...
Gruß serverhorst
-
Erzähl uns erstmal von Deiner Lösung, warum bisher die Pipe nicht gfeunden wurde...
Das mit dem ReadFile auf beiden Seiten geht doch.
Was sol da nicht gehen? Ich verwende dazu overlapped I/O.
Was hast Du für Probleme?BTW: Ich meinte diesen Artikel, hier ist ein komplettes Sample drin.
http://blog.m-ri.de/index.php/2009/12/08/windows-integrity-control-schreibzugriff-auf-eine-named-pipe-eines-services-ueber-anonymen-zugriff-auf-vista-windows-2008-server-und-windows-7/
-
Martin Richter schrieb:
BTW: Ich meinte diesen Artikel, hier ist ein komplettes Sample drin.
http://blog.m-ri.de/index.php/2009/12/08/windows-i ....... griff-auf-vista-windows-2008-server-und-windows-7/übrigens sehr empfehlenswert. Hatte da einmal viel Zeit verbraten. Oder einfach mal "Microsoft Press Windows Internals 5th.Edition" lesen.