Hi,
Zitat von
Apollonius:
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.
Naja... "völliger Käse" find ich übertrieben. Klar, die Funktion kann scheitern, wenn ich mehr verlange als drin ist... Das Problem war, dass ich GetCurrentProcess nicht kannte, sondern nur GetCurrentProcessID und da ich ein Process-
Handle brauchte, war das (für mich) die einzige Möglichkeit an eins zu gelangen
Zitat von
Apollonius:
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.
Ok, jetzt weiß ichs ja
Zitat von
Apollonius:
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.
Das hier ist eine Kombination aus Unwissenheit und einem Denkfehler. Im Hinterkopf war gespeichert: "Das ist nicht dein eigener Process, also kannst du Speicher nur mit VirtualAllocEx anfordern"... Von daher VirtualAllocEx.
Das ich 99,8% verschwende war mir nicht so direkt bewusst, aber jetzt wo dus sagst: Jaa.. man reserviert ganze Memory-Pages... also mindestens 4096 Bytes...
PAGE_EXECUTE_READWRITE...
Das ich 6, anstelle von 5 Bytes reservieren wollte, liegt daran, das ich mal in einer früheren Version 6 Bytes benötigt habe. Auuußerdem war ein guter Grund:
Der Befehl, der ursprünglich an der zu hookenden Stelle stand, war folgender:
FF25E4124500 jmp dword ptr [Adresse von Kernel32.FindNextFile]
Dieser Befehl ist 6 Bytes groß und ich laß mal im Internet, das man Befehle möglichst nicht zerreißen sollte...
Dummerweiße habe ich vergessen noch ein nop; zu schreiben...
Wobei du Recht hast, wenn du sagst, dass es in diesem Fall nicht so schlimm ist, wenn ich den Befehl zerreiße weil der nachfolgende Befehl ja (höchstwahrscheinlich) nie ausgeführt wird.
Zitat von
Apollonius:
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).
Ja, wenn es denn ein anderer Prozess wäre
Zitat von
Apollonius:
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.
Also du meinst ich hooke nur die Weiterleitfunktion und nicht die echte FindNextFileA?
Das war mehr oder weniger beabsichtigt... Denn ich bekomme auf FindNextFileA keinen Schreibzugriff.. Per VirtualProtect(Ex) erhalte ich auch maximal nur
PAGE_EXECUTE_WRITECOPY
oder
PAGE_WRITECOPY
,was mir ja nicht weiterhilft, deswegen hooke ich halt dieser Weiterleitfunktion...
Zitat von
Apollonius:
Der Rest der Funktion ist halbwegs korrekt, auch wenn man sich das WriteProcessMemory sparen könnte.
Warum könnte ich mir das sparen?
Zitat von
Apollonius:
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.
Ja deswegen wie gesagt die theoretischen 6 Bytes^^ Wenn ich meine Methode in einem eigenen Programm (ohne hooks) benutze, funktioniert sie. Komischerweise gibt es auch keine Rekursion...
Vorher habe ich tatsächlich die ersten 6 gesicherten Bytes aufgerufen, aber das führte bei mir immer zu AVs weil die Parameter in FindNextFileA nicht richtig ankamen. Die Lösung dafür hast du aber ja unten gepostet
Zitat von
Apollonius:
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).
Ok
Du musst wissen, das ich mir noch nie wirklich groß mit
API-Hooking auseinandergesetzt habe. Ich habe im Internet geguckt wies so ungefähr geht, von der vorgehensweise her und den Rest wollte ich dann selbst probieren. Ich tüftele bei sowas gerne selbst etwas rum, auch wenn dabei (verständlicherweise) nicht zwangsweise was 100% korrektes rauskommt *g*
Zitat von
Apollonius:
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.
Verstehe ich leider nicht ganz
Aber danke für deine ausführliche Antwort
Gruß
Neutral General