Globaler API-Hook funktioniert nicht

[brechi]

FindNextHooked ist quatsch... 1 param ist eax? ganz sicher net :)
globale Variablen für parameter benutzen oO?


so sollte es gemacht werden (pseudocode):

origfunction:
00000 JMP hooked
00005 restlicher code (darf nicht zerteilt sein)


deinefunktion:
0000 irgendwas
00xx call nexthook
00xx irgendwas
00xx ret


nexthook:
00000 5bytes der orig funktion
00000 JMP origfunction@00005

die Funktion HookCodeNt von http://omorphia.cvs.sourceforge.net/...as?view=markup macht das so

[spaxxn]

brechi verteilt wieder seine Sourcen :P

Aber die Sammlung ist in Sachen Hooking echt was feines...

[Neutral General]

Zitat:

Zitat von brechi

FindNextHooked ist quatsch... 1 param ist eax? ganz sicher net :)

Ganz sicher doch ;) Habs ja vorher debuggt und ausführlich recherschiert ;)

Zitat:

Zitat von brechi

globale Variablen für parameter benutzen oO?

Ja wie gesagt.. Bei lokalen ist das Problem, das dann vor den nops code erzeugt wird, der dann anstelle von den nops überschrieben wird. Dann wollte ich die Param-Variablen in den public-Teil von TForm1 verlagern, aber egal was ich auch gemacht habe, man konnte diesen Variablen nix zuweisen:

Code:

mov eax, Form1.Variable

:arrow:

eax = 0

deswegen musste ich zwangsweise auf globale Variablen setzen.

so sollte es gemacht werden (pseudocode):

Zitat:

Zitat von brechi

origfunction:
00000 JMP hooked
00005 restlicher code (darf nicht zerteilt sein)

So siehts bei mir ja auch aus.

Das Problem ist ja, dass ich meinen Code nach dem Original Code ausführen will... also so:

Delphi-Quellcode:

// origfunction:
00000 JMP hooked
00005 restlicher code (darf nicht zerteilt sein)

// hooked
00000 5 Bytes der origfunktion
ab 00005: Parameter der Originalfunktion sichern
ab 0000X: call originalfunktion +5
ab 0000Y: Auswertung der Ergebnisse der Originalfunktion // <--- geht nicht

Zitat:

Zitat von brechi

die Funktion HookCodeNt von http://omorphia.cvs.sourceforge.net/...as?view=markup macht das so

Ja danke. Aber ich würds schon gern selbst hinkriegen ;)

Gruß
Neutral General

[OldGrumpy]

Also davon auszugehen, dass die ersten fünf Bytes einer jeden Win32-API-Funktion IMMER vollständige Befehle sind (also nicht z.B. ein Befehl von Byte vier bis sieben geht) finde ich schon sehr gewagt. Es gibt fertige Disassemblermodule die einem die Länge des Assemblerbefehls an einer beliebigen Speicheradresse zurückliefern, mit denen kann man dann so viele Bytes kopieren wie notwendig sind, um nicht einen Assemblerbefehl zu schreddern. Dabei kommen sonst nämlich oft genug die seltsamsten Pseudobefehle heraus... Dass der Prozess sich dann seltsam verhält oder falsche Ergebnisse liefert, darf nicht verwundern.

Also: Nicht immer davon ausgehen, dass "fünfe gerade ist" ;) Das kann derb ins Auge gehen. Einfach Opcodelängen zählen und die notwendige Anzahl Bytes kopieren. Und BTW: Das Gejammer über eine allozierte Speicherpage mehr ist echt kindisch. Speicher wird immer nur in kompletten Pages alloziert, selbst wenn man nur ein Byte über die Pagegrenze kommt. Das ist Windows echt total schnurz, also einfach eine page allozieren, Anfang der API-Funktion wie oben beschrieben rüberkopieren, absoluten Jump hinter den kopierten Bytes einfügen und dann mittels WriteProcessMemory den Anfang der API-Funktion überschreiben.

Achtung beim prozessübergreifenden Hooking: Viele "Kopierschutz"-Tools checken APIs oder zumindest deren Anfang auf bekannte Manipulationen (EB FE, CC, etc.) und verweigern dann die Benutzung der "geschützten" Software.

[Apollonius]

Ich habe extra geschrieben, dass FindNextHook ohne Parameter und besondere Aufrufkonvention notiert wird, damit kein Stackframe generiert wird. Das bedeutet aber auch, dass ebp nicht neu gesetzt wird, man muss also relativ zu esp zugreifen.
In meinem Beispielcode ist aber auch ein Fehler. Falls man eine Nachbearbeitung der Parameter durchführen will, ist es nicht mehr so einfach wie beim Jump (ich habe bisher nur diesen verwendet, daher bitte ich den Fehler zu entschuldigen). Denn die Rückkehradresse wird so ja erst nach den ersten Befehlen gepusht, was tödlich sein kann, falls die ersten Befehle irgend etwas am Stack verändern. Die richtige Variante sähe ungefähr so aus:

Delphi-Quellcode:

procedure FindNextFileReplace;
asm
  push [esp+8]
  push [esp+8]
  call @@GetReturnAdress
  @@GetReturnAdress:
  add [esp], 14 //4 Byte: Opcode, ModR/M, SIB, Immediate
  nop
  nop
  nop
  nop
  nop
  jmp offset FindNextFile + 5 //5 Byte
  jmp MyFindNextFile
end;

Das ist alles aus dem Kopf getippt und nicht getestet.
Die Länge der Befehle am Anfang der Routine musst du von Hand abzählen, um die Position der Nops zu erhalten.

[Neutral General]

Hi,

Also bei mir siehts im Moment so aus:

Delphi-Quellcode:

// beim Hooken:
WriteProcessMemory(hProc,Pointer(Integer(@FindNextHooked)+17),Sicherung,5,br);

procedure FindNextHooked;
asm
  push [esp+8]
  push [esp+8]
  call @@GetReturnAdress
  @@GetReturnAdress:
  add [esp], 14 //4 Byte: Opcode, ModR/M, SIB, Immediate
  nop
  nop
  nop
  nop
  nop
  add FindNextOld, 5
  jmp FindNextOld   // *
  jmp AfterFindNext
end;

*) jmp offset FindNextOld + 5 compiliert nicht:

[Error] Unit1.pas(66): Invalid combination of opcode and operands

deswegen habe ich es durch

Zitat:

add FindNextOld, 5
jmp FindNextOld

Allerdings verstehe ich diese Zeile nicht:

Delphi-Quellcode:

add [esp], 14 // wird da die Adresse von esp um 14 erhöht? wenn ja warum?

Hat bis eben so nicht funktioniert, weil ich nicht wusste (und immernoch nicht genau weiß, was diese Zeile bewirkt, aber ich habe herausgefunden das ich die 14 durch eine 17 ersetzten muss damit es funktioniert...

Gruß
Neutral General

[brechi]

FindNextHooked ist fürn popo.
Machs so wie ichs gesagt habe, so wirds in fast allen hooks gemacht und das hat auch seinen Grund.

[Neutral General]

Hi brechi,

Ok ich habe es mal so gemacht:

Delphi-Quellcode:

procedure NextHook;
asm
  nop
  nop
  nop
  nop
  nop
  add FindNextOld,5
  call FindNextOld
end;

procedure FindNextHooked;
asm
  push [esp+8]  // Sonst kommen die falschen parameter in FindNextOld an
  push [esp+8]  // ...
  call nexthook
  sub FindNextOld,5
  ret
end;

mein TestCode sieht so aus:

Delphi-Quellcode:

procedure TForm1.Button3Click(Sender: TObject);
var sr: TSearchRec;
begin
  FindFirst('C:\*.*',faAnyFile,sr);
  FindNext(sr);
end;

FindNext sieht so aus:

Delphi-Quellcode:

push ebx
mov ebx,eax
lea eax,[ebx+$18]
push eax
mov eax,[ebx+$14]
push eax
call FindNextFile // <--- springt zu FindNextFileA, ist gehooked
// hier macht er weiter wenn das ret aus FindNextHooked aufgerufen wird
test eax,eax
jz +$09
mov eax,ebx
call FindMatchingFile
pop ebx
ret  // <--- hier,
call GetLastError
pop ebx
ret // oder hier müsste er wieder in Button3Click springen, er springt aber (soweit ich das beurteilen kann) irgendwo in die pampa

... und das gibt dann eine AV.

Gruß
Neutral General

[Apollonius]

In NextHook sollte es Jmp und nicht Call heißen. Wie ich bereits bemerkt habe, verändert die Rückkehradresse sonst den Stack. Außerdem solltest du die Veränderung an FindNextOld direkt beim Einrichten des Hooks vornehmen, sonst gibt es Probleme mit mehreren Threads.
Meine Lösung ist übrigens praktisch identisch mit Brechis. :wink:
Um nochmal zu deiner Frage zu meinem Code zurückzukommen:
add [esp], 14 verändert nicht esp selbst, sondern den Integer, auf den esp zeigt. Das ist zufällig die Zahl, welche zuoberst auf dem Stack liegt. Welche ist das in diesem Fall? Genau, die Adresse, die durch den Call auf den Stack geschoben wurde. Diese zeigte vorher auf @@GetReturnAddress und wird nun auf den Befehl nach dem Jump rejustiert (durch das Add stimmen die 14 Bytes übrigens nicht mehr - bei diesen Adress-Geschichten ist der Inline-Assembler leider immer ein bisschen pingelig, ich sehe ehrlich gesagt kein Problem darin, zu der Adresse einer Funktion 5 zu addieren). Ich gestehe allerdings, bezüglich des jmp offset FindNextFile + 5 nicht mitgedacht zu haben - wir verwenden hier mal wieder die Weiterleitungsfunktion und nicht jene in Kernel32.dll, aber du hast das ja schon richtig mit einer globalen Variablen korrigiert. Wir legen also für die originale FindNext-Funktion eine künstliche Rückkehradresse an. Im Prinzip ist das das selbe, was in Brechis Code mit zwei Routinen gemacht wird.

[brechi]

richtigerweise würde nexthook so aussehen:

Delphi-Quellcode:

function FindNext(var F: TSearchRec): Integer;
asm
  nop
  nop
  nop
  nop
  nop
  add FindNextOld,5
  jmp FindNextOld
end;