...schade, geht mit Pipes mit großer Sicherheit nicht.
Virtuelle Datei
-
-
-
Noch mal, warum das meiner Meinung nach leider nicht geht:
Bei einer Pipe wird scheinbar bei jedem Aufruf von ReadFile / WriteFile der Buffer gelöscht. Die DLL wird wahrscheinlich die Datei gar nicht in einem Rutsch schreiben, es wird also beim Aufruf der Funktion in der DLL mehrmals WriteFile angesprochen, bevor die Funktion zurückkehrt. Da die Pipe bei jedem Aufruf von Writefile "gelöscht" wird, kommen also nicht alle Daten an.
Ein zweiter Thread könnte hier evtl. Abhilfe schaffen...
[Blockierte Grafik: http://img162.imageshack.us/img162/6104/43906095.th.jpg] -
Mit CreateFile wäre es einfach gewesen, meine nächste Idee wäre es, NtWriteFile lokal zu patchen. Dafür muss ich mir erst mal eine ganze Menge Opcode schreiben; darin bin ich eine ziemliche Niete und das dauert deshalb etwas.
-
Viiiiiiiiiiiiiiiiiilen Dank für Eure Bemühungen, aaaaaber: Wenn´s nicht mit Bordmitteln geht, hat´s für 'Anwendungsprogrammierer', die ja meist für Kunden mit Standardumgebung arbeiten, nicht sehr viel Sinn. Einspielen gepatchter Standard-DLL in Kernel-Umgebung ist sowieso nicht, bzw. wenn Anwenderfirmen auf sowas mal draufkommen, dann gibts groben Zoff.
Ausserdem, was ist, wenn da ein Microsoft AutoUpdate drüberläuft?
Aber nochmals: Danke! -
Zitat
Einspielen gepatchter Standard-DLL in Kernel-Umgebung ist sowieso nicht, bzw. wenn Anwenderfirmen auf sowas mal draufkommen, dann gibts groben Zoff.
Es ist wohl eher das Verändern einer Dll zur Laufzeit gemeint. Ein paar Bytes (meist zwei bis fünf) der Dll im Speicher werden so geändert, dass beim Aufrufen zuerst ein anderer Code angesprungen wird. Dieser wird abgearbeitet und danach springt er wieder zurück zur originalen Dll-Routine. Ist eine gängiger Praxis vieler (spezialisierter) Anwendungen, aber bei System-Dlls mitunter recht aufwändig, da oft jede Windowsversion und auch schon Servicepacks Änderungen an der Dll vorgenommen haben und das beim "patchen" berücksichtigt werden muss.
-
Hallo,
Frank hat mich per Skype auf den Thread hier aufmerksam gemacht. Leider hatte ich noch nicht genug Zeit, ihn richtig durchzulesen... Kann jemand kurz zusammenfassen, womit ich konkret helfen könnte?
Viele Grüße aus Görlitz,
Sebastian
-
Peter hat gefragt, ob dieser Code nach XProfan zu Portieren sei: Pipe (Informatik) ? Wikipedia
-
Der Code beschreibt nur die Standardausgabe, man könnte (heutzutage) die Konsolenausgaben-Apis nutzen AllocConsole Function (Windows) und fprintf wäre dann halt "WriteConsole". Man kann auch das Console-Flag der Prfrun32.exe setzen, das ist imho aber alles am Problem von Jac vorbei denn er will ja aus einer Dateischreibeaktion eine Speicherschreibeaktion machen und nicht aus einer Konsolenausgabe. Man könnte ein Hook auf CreateFile machen und im Falle, eine andere Funktionsadresse aufrufen (imho einfachste Mgl.). Lieb verkauft wäre es dann ein "Debuggen" der DLL.
-
Danke für die Beschreibung des Codes!
ZitatMan könnte ein Hook auf CreateFile machen und im Falle, eine andere Funktionsadresse aufrufen (imho einfachste Mgl.).
Ich denke, du wirfst Sachen durcheinander.
Was du meinst, ist ein Patch. Ein Hook ist das Abfangen diverser Ereignisse, wobei jedesmal ein eigener Code angesprungen wird. So ein Ereignis ist z.B. ein Tastendruck, siehe Hooks.
In der EDV werden die beiden Begriffe leider oft zusammengewürfelt, sind aber im Grunde zwei ganz unterschiedliche Dinge.
Beim Patchen von Dll-Funktionen schreibt man mit Maschinencode einen Sprungbefehl (der zu eigenen Code führt) an den Einsprung dieser Funktion. Wird jetzt die Dll-Funktion ausgeführt, wird sofort der eigene Code angesprungen. Im eigenen Code muss beim Rücksprung der ursprüngliche Code der Dll-Funktion "simuliert" werden, danach erfolgt der Rücksprung hinter den Sprung zu unserem Code.CreateFile zu patchen wird auch nicht das gewünschte Ergebnis bringen. Ich würde WriteFile und WriteFileEx patchen und den an die Funktion übergebenen Speicher einfach in einen neuen Speicherbuffer kopieren. Zusätzlich müsste auch CloseHandle gepatch werden, damit das Ende des Speichervorgangs erkennt würde und der kopierte Buffer (der ja durch mehrere WriteFile(Ex)-Vorgänge zusammengestellt worden sein kann) ausgewertet und zurückgesetzt werden kann.
Ich selber habe für mich drei solche (na ja, ähnliche) Anwendungen gebastelt. Darum kenne ich die Vorgehensweise und weiß auch um deren Tücken. Jede Windowsversion und sogar jedes Servicepack kann eine Dll-Funktion mit verändertem Code beinhalten und das Vorhaben somit erschweren.
-
Zitat von Frabbing;728893
Ich denke, du wirfst Sachen durcheinander.
Was du meinst, ist ein Patch.Nänä, "Hook auf CreateFile", dass meine ich schon so. Das man dafür einen Speicher "patcht" /den Wert ändert, sodass eine eigene/andere Funktionsadresse angesprungen wird, und wie man den Speicher patcht z.B. per von Windows gegebenen Mitteln (z.B. gwl_procAddr) oder per manuellem ändern einen Wertes im Speicher, das steht auf einem anderen Blatt.
-
Zitat von Frabbing;728785
Es ist wohl eher das Verändern einer Dll zur Laufzeit gemeint.
So ist es, zur Laufzeit - hast du ja schon mal gemacht. Mit CreateFile habe ich es schon versucht, das haut in diesem Falll nur mit Profanmitteln nicht hin. WriteFiele kann etwas dauern, hab zur Zeit viel um die Ohren und weiß noch nicht, ob ich das hinbekomme (will das nur mit ASM Opcode versuchen, ohne DLL).
Den Code, den P.Specht da wohl möchte, habe ich bereits, bloß mit NamedPipes - mich hat er aber diesbezüglich noch nicht angesprochen.
NamedPipes lassen sich in der Interprozesskommunikation besser verwenden, da hier keine Handlewerte übermittelt werden müssen (p.specht braucht das scheinbar für einen anderen Zweck). Eine Pipe ist ein Kernelhandle, und Kernelhandles sind nicht global. Der Client-Prozess muss also den Wert des Handles in der von mir bereits angesprochenen Liste wissen, damit er sich das Write-/Read-Handle der Unnamed Pipe aus dem Server-Prozess über DuplicateHandle holen kann.ZitatCreateFile zu patchen wird auch nicht das gewünschte Ergebnis bringen.
So ist es. Zu patchen wäre dann hier aber NtWriteFile. Desweiteren muss beachtet werden, das unter nicht NT-basierenden Systemen ein Patch auf die Kernel32.dll immer global ist! Unter Windows95/98/ME befindet sich die Kernel32.dll in einem virtuellen Speicherbereich, der zwischen 2GB und 3GB liegt (ich nehme hier die Ausdrucksweise aus der Win32.hlp, also bitte nicht über das GB wundern, ist nur der Kürze halber). Dieser Speicherbereich ist dort "Shared-Memory". Eine Änderung in einem Prozess (lokal) wirkt sich hier gleichermaßen auf alle anderen laufenden Prozesse aus. Sollte es als Ergebnis hier nacher zu einem lokalen Patch oder Hook der Kernel32.dll kommen, darf das daraus entstehende Programm unter keinen Umständen unter Windows95/98/ME lauffähig sein! -
@iF: Welchen Hook willst du denn verwenden? Ich lass mich gerne vom Gegenteil überzeugen, aber bitte nur stichhaltig.
Zitat...und wie man den Speicher patcht z.B. per von Windows gegebenen Mitteln (z.B. gwl_procAddr) oder per manuellem ändern einen Wertes im Speicher, das steht auf einem anderen Blatt.
iF, GWL_PROCADDR gibt es nicht, siehe: Google
Wahrscheinlich meinst du GWL_WNDPROC:ZitatGWL_WNDPROC:
Retrieves the address of the window procedure, or a handle representing the address of the window procedure. You must use the CallWindowProc function to call the window procedure.[Quelle: ]Content not found
GWL_WNDPROC ermittelt lediglich die Adresse der Windows-Prozedur eines Fensters oder einen Handle zur Adresse.
XProfans ProcAddr ermittelt die Adresse einer Dll-Funktion, patcht aber nicht. Aber das weißt du ja selber.ZitatWriteFiele kann etwas dauern, hab zur Zeit viel um die Ohren und weiß noch nicht, ob ich das hinbekomme (will das nur mit ASM Opcode versuchen, ohne DLL
Ich habs bislang immer mit Dll gemacht. Wenn ich mal etwas Zeit habe (bin grad am Umbauen), versuche ich mich mal an einer kleinen Assembler-Exe.
ZitatSollte es als Ergebnis hier nacher zu einem lokalen Patch oder Hook der Kernel32.dll kommen, darf das daraus entstehende Programm unter keinen Umständen unter Windows95/98/ME lauffähig sein!
Meine Tools sollten immer global wirken.
-
Zitat von Frabbing;729060
Meine Tools sollten immer global wirken.
Das war auch nicht auf deine Tools bezogen, sondern auf diesen speziellen Fall hier. Macht man das in diesem Fall auch global (unter nicht Nt-basierenden Systemen ist auch ein lokaler Hook oder Patch der Kernel32 immer global), passieren ganz gewaltige Fehler. -
Nicht NT-basierende Systeme sind ja mittlereweile so gut wie ausgestorben.
-
Na ja, habe neulich noch eine komplett eingeschweißte Vollversion von Windows95 geschenkt bekommen.
-
Aber sicher nicht installiert, oder?
-
Zitat von AHT;729900
Na ja, habe neulich noch eine komplett eingeschweißte Vollversion von Windows95 geschenkt bekommen.
...noch auf Disketten ?
-
Nein, leider auf CD.
Ach ja... Hab die Sache hier fertig. Habe es mir erst mal etwas einfach gemacht und eine DLL geschrieben, die einen API-Hook auf NtWriteFile ausführt. Haut super hin. Besteht noch Interesse an der Sache?
Aufruf erfolgt so:CodeDLL&=UseDLL("HNTCTF.DLL") _inithook@4(Text#) Assign #1,"C:\TEMP\TEST.TXT" Rewrite #1 Print #1,"Hallo!" Print #1,"Das ist ein Test..." Print #1,"alles geht hier in den Bereich, nicht in die Datei!" Close #1 _delhook@0()
Alles, was zwischen _inithook und _delhook an Schreiboperationen in eine datei erfolgt, landet in dem Bereich Text#. -
@AHT,
du weißt doch, dass an guten Sachen immer Interesse besteht.
Da du nur von NtWriteFile sprichst gehe ich mal davon aus, dass man die Daten nicht als Datei wieder laden kann, sondern normal aus dem Speicher auslesen muss. -
Ja, darum ging es hier ja. Die Ausgaben einer DLL von einer Datei in einen Bereich umleiten - in der Datei stehen die dann nicht - werden erst gar nicht da rein geschrieben. Die Datei wird trotzdem erstellt, aber ohne Inhalt
Wenn ich es online habe, schicke ich dir das Ding bei Bedarf gern mal zum Testen zu.
Getestet habe ich es bislang oberflächlich unter Windows2000 SP2 und SP4/XP ohne SP und mit SP3 / Vista mit Sp2. Unter Windows7 bräuchte ich noch einen Tester. Die Technik, die ich mir da ausgedacht habe, lässt sich ohne weiteres problemlos auch auf alle anderen Nt-Funktionen der NTDLL.dll anwenden - da sind also noch ganz andere Sachen möglich. Vielleicht lässt sich da eine DLL bauen, mit der sich alle möglichen Sachen lokal hooken lassen (so was wie in Delphi) - mal schauen...
"Gut" ist erst mal ein wertender Ausdruck. Wer sich nur mit äußerst gewöhnlichen Sachen beschäftigt, der hält bereits sehr gewöhnliche Dinge für gut und kann mit Sachen, die jemand anderes vielleicht für gut hält, gar nichts anfangen - die sind für den wertlos. Ich hab das Ding auch nur gebaut, weil ich zur Zeit krank mit Fieber zu Hause liege und etwas einfaches brauchte, womit ich mit zwischendurch beschäftigen konnte. Für das ganze habe ich etwa einen Tag gebraucht - dafür ist also noch nicht einmal großartiges Programmierkönnen nötig. Wie gesagt, ob das "gut" ist und ob daran überhaupt Interesse besteht, weiß ich nicht. -
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!