Wie realisiert man einen hook für memcpy?
-
Hallo,
ich muss für ein Projekt ein Hook auf die memcpy-Funktion schreiben, um diverse Aktionen zu protokollieren. Nur leider komme ich nicht mehr weiter...
Im moment habe ich eine simple Win-Anwendung die auf Knopfdruck ein memcpy ausführt, sie dient qausi als Testobjekt.
Ein Injector, der mir eine DLL in eine Anwenung lädt.
Als letztes Stück noch eine DLL, die "versucht" per IAT-Hook die Adresse für die memcpy Funktion zu überschreiben.Die DLL erzeugt sich einen Snapshot aller geladenen Module, iteriet sie und durchsucht ggf. den Header nach den importierten Funktionen.
Leider wird mir für die ntdll.dll leider keine importierte memcpy-Funktion angezeigt bzw. ausgegeben, dafür jede menge anderer.Für andere/selbstgeschriebene DLLs klappt diese Methode wunderbar, nur bei der uminösen ntdll.dll nicht.
Ist es überhaupt möglich auf diesen Weg die memcpy-Funktion der ntdll.dll zu hooken oder muss man dafür einen anderen Weg gehen?
Ich hoffe, dass mir jemand helfen kann oder zumindest einen kleinen Denkanstoss geben kann.
Gruß,
-mh
-
1. Die ntdll verwendet keine CRT! Hättest Du DEPENDS mal für diese DLL aufegrufen, dann müsstest Du sehen, dass die NTDLL gar keine weiteren DLLs verwendet.
2. memcpy wird dortintern wahrscheinlich intrinsic ausgeführt werden, d.h. der Compiler had entsprechenden Assembler Code expandended.
Du kannt selbst in einem C++ Programm, dass die CRT als DLL verwendet, memcpy evtl. nicht hooken, genau aus diesem Grund.
3. Es gibt die SDK Funktion CopyMemory, die auch gerne verwendet wird.
4. Die ntdll kannst Du gar nicht hooken Code aus dieser DLL läuft immer im Kernel-Mode.Was willst Du denn bitte mit solch einem Trick: Die memcpy Funktion zu hooken?
Protokollieren? Was denn da bitte?
-
guck dir mal mit nem debugger an welche funktion wirklich aufgerufen wird bei memcpy, ich glaub das war sowas wie hmemcpy wenn ich mich recht erinnere. kann sein dass diese auch gar nciht in einer dll steckt sondern statisch gelinkt wird.
-
Die memcpy ist nicht in der ntdll!
Das ist eine CRT funktion, und wenn die statisch gelinkt wird hast du auch keine IAT und kannst folglich auch nicht die addresse der funktion auslesen. Besser wäre es, wenn du vor dem ausführen der zu protokollierenden exe nach der byte repräsentation von memcpy suchst(8-16 bytes sollten reichen: "(char(*)[8])memcpy") uund diese stellen dann in der exe mit deiner funktion ersetzst.
-
Die NTDLL.DLL exportiert eine Funktion namens memcpy (). Sie importiert aber keine. Sie hat nicht mal eine "Import-Section" im PE-Header.
Funktionen 7C910000 in NTDLL DLL adresse ordnungszahl name ----------------------------------- 7C911D1D 04BB _memccpy 7C980106 04BC _memicmp 7C9120A5 04F1 memchr 7C91214F 04F2 memcmp 7C912200 04F3 memcpy 7C91253A 04F4 memmove 7C91287A 04F5 memset
-
Um mal ein bisschen weiter auszuholen...
Der Hook soll für eine Applikation werden, die zur Steuerung eines Robotersystems dient. Diese schreibt zwar ein Logfile, allerdings erst wenn die gewünschte Aktion fertig ausgeführt wurde. Wichtig zu wissen wäre aber, wann sie damit anfängt. Ein ehemaliger Kollege aus einem anderem Geschäftsbereich benutzt für eine ähnliche Software dazu erfolgreich einen memcpy hook. Leider komme ich aber nicht an die Sourcen ran, politische Gründe
@dfssdfsdf
Sowas hatte ich mir auch schon überlegt bzw. die Calls nach memcpy zu patchen.
In der art, jedes "CALL 0xDEADBEEF // call memcpy" auf meine eigene Funktion umzulenken.@merker
Genau, aber meine Applikation importiert eine memcpy Funktion...Hat jemand ideen, wie man sonst noch einen memcpy-hook umsetzen kann?
-
Also ich verstehe nicht was Du mit diesem memcpy Hook willst. Woher weißt Du denn wer wann diese Funktion in welcher Weise ausführt?
Ganz zu schweigen davon, dass eine Applikation diese Funktion überhaupt nicht zu benutzen braucht?Was hat dieser Hook mit der Steuerung eines Robotersystems zu tun?
Warum änderst Du nicht die entsprechende Software, dass Sie den Log-File schreibt wenn Du möchtest? Was sind das für Bedingungen?
-
Die Meldungen werden wohl erstmal intern vorgehalten und später ausgegeben. Laufen derweil aber durch die memcpy Funktion...
Mit der Steuerung des Roboters hat die memcpy gar nichts zu tun, hatte ich auch nicht geschrieben. Die Software zur Steuerung des Roboters benutzt nur die memcpy Funktion.
Weil die Software leider nicht von uns stammt, sondern von einer Fremdfirma erstellt wurde. Der ganze Zusammenhang ist ein bisschen umfangreicher und würde hier weit über das eigentliche Thema hinaus gehen...
-
Martin Richter schrieb:
4. Die ntdll kannst Du gar nicht hooken Code aus dieser DLL läuft immer im Kernel-Mode.
mit tricks schon, z.b. den speicherbereich, den die ntdll belegt, schreibfähig machen und dann den hook-code dort einschleusen.
...und dass die ntdll immer im kernel-mode läuft, ist natürlich unsinn.
--> http://vx.netlux.org/lib/vzo12.html
-
mh schrieb:
Genau, aber meine Applikation importiert eine memcpy Funktion...
Dann reicht es (falls nicht via LoadLibrary () geladen) wenn die DLL den IAT-Hook in die IAT der EXE setzt. Die "anderen" DLL's müssen nicht durchsucht werden.
