Es fallen gleich zu Anfang von HookFindNext einige sehr seltsame Dinge auf, die nahelegen, dass du das Speicherkonzept von Windows nicht ganz verstanden hast.
Zitat:
hProc := OpenProcess(PROCESS_ALL_ACCESS,false,GetCurrentProcessID);
Diese Zeile ist völliger Käse. OpenProcess kann scheitern, falls dein Security Descriptor zu strikt ist. Wenn du ein
Handle zum eigenen Prozess brauchst, verwendest du GetCurrentProcess (das liefert ein Pseudo-
Handle, weshalb die Funktion auch unschlagbar schnell ist) oder DuplicateHandle mit GetCurrentProcess, um ein eventuell vererbbares echtes
Handle zu erhalten.
Zitat:
FNCode := VirtualAllocEx(hProc,nil,6,MEM_COMMIT,PAGE_EXECUTE_READWRITE);
Um im eigenen Prozess eine Speicher-Seite zu reservieren, verwendet man VirtualAlloc (welches allerdings auch nur VirtualAllocEx mit GetCurrentProcess aufruft, insofern ist das nicht so schlimm). Da du allerdings nur 6 Bytes verwendest, verschwendest du vom allozierten Speicher gut 99,8% - keine schlechte Quote. Um ein bisschen Speicher im eigenen Prozess zu allozieren, verwendest du GetMem. Außerdem benötigst du eigentlich nur fünf Bytes für deinen Sprung.
Zitat:
ReadProcessMemory(hProc,@FindNextFile,FNCode,6,br);
Wenn hProc ein
Handle auf einen anderen Prozess wäre, wäre diese Zeile hier sinnfrei. Der zweite Parameter gibt die Adress im anderen Prozess an (an der eventuell Schrott steht) und der dritte die Adresse im eigenen Prozess (dito, da FNCode sich auf einen anderen Prozess bezöge).
Danach überschreibst du @FindNextFile. Das Problem dabei ist, dass diese Adresse nicht zur Compile-Zeit aufgelöst werden kann, weshalb der Linker eine Weiterleitungsfunktion (die nur von der Bibliothek verwendet wird und daher nicht zum Hooken verwendet werden kann) einfügt und diese FindNextFile nennt (diese sieht so aus: jmp [Adresse, an die der Windows-Loader die echte Adresse von Kernel32.dll.FindNextFile einfügt]). Du musst dir aus dieser die echte Adresse von FindNextFile holen, oder aber mit GetProcAdress, was einfacher sein dürfte.
Der Rest der Funktion ist halbwegs korrekt, auch wenn man sich das WriteProcessMemory sparen könnte.
In der Ersatzfunktion hast du es dir zu einfach gemacht. FindNextFileA hast du ja gerade gehookt, was zu einem rekursiven Aufruf führt. Du musst sicherstellen, dass du eine ganze Zahl von Befehlen ausgelesen hast (und nicht etwa der zweite Maschinensprache Befehl bei Byte 4 beginnt und zwei Bytes lang ist) und zur Not mehr als 5 Bytes auslesen. Die überschriebenen Befehl musst du dann wieder aufrufen und dann zu Byte 6 (oder weiter, auf jeden Fall an eine Stelle, wo ein neuer Befehl beginnt) springen. Wenn ich diese Hooking-Technik verwende, mache ich das immer so:
Delphi-Quellcode:
procedure FindNextFileReplace;
//falsche Signatur, damit kein Stackframe generiert wird!
asm
nop
nop
nop
nop
nop
//falls du die Parameter noch brauchst, kopieren!
mov eax, SavedFindNextFile
//aus GetProcAddress
add eax, 5
jmp/call eax
//call nur, falls noch etwas folgt
jmp AfterFindNextFile
end;
Die nops werden dann in HookFindNext überschrieben. AfterFindNextFile ist dabei die eigentlich Hook-Funktion, die ruhig in Delphi geschrieben werden darf - du musst allerdings mit Parametern und Aufrufkonvention aufpassen (und solltest außerdem eax, welches den Rückgabewert der Originalfunktion erhält, erhalten - also am besten ein kurzes Stück Assembler am Anfang der Funktion).
Abschließend weise ich darauf hin, dass diese Hooking-Technik nicht verwendet werden sollte, da es Probleme gibt, falls ein Thread FindNextFile aufruft während du gerade hookst. Stattdessen überschreibt man gewöhnlich für jedes Modul einzeln die vom Windows-Loader an eine bestimmte, in der
PE-Datei angegebene Stelle eingefügte Adresse der zu hookenden Funktion.