API Hooks - ASM (keine hochsprache erwünscht!)

03/21/2007 13:30 cc_ip#1
Die Überschrift sollte alles sagen, hier mal kurz meine vorgehensweise:

1. Aktuelle Position im Speicher finden. (delta offset)
2. kernel32.dll ImageBase Adresse finden.
3. Und dann finde ich die Funktionsadressen (scanning Export Directory Table).

Code:
;find kernel32.dll image base address. *
 * *xor * * * *eax, eax * * * * * * * * * * * * * * 
 * *ASSUME * * FS:NOTHING 
 * *mov * * eax,fs:[eax+30h] * * * * * * * *
 * *test * *eax,eax * * * * * * * * * * * * * *
 * *js * * * * __kernel_9X * * * * * * * * * * * * 
__kernel_NT: 
 * *mov * * eax,[eax+0Ch] * * * * * * * * * * 
 * *mov * * esi,[eax+1Ch] * * * * * * * * * * 
 * *lodsd * * * * * * * * * * * * * * * * * * 
 * *mov * * eax,[eax+8h] * * * * * * * * * * 
 * *jmp * * __kernel_finish * * * * * * * *
__kernel_9X: 
 * *mov * * * *byte ptr[ebx+winNT], 0 *&#59;we are at a win9X machine 
 * *mov * * eax, [eax+34h] 
 * *lea * * eax, [eax+7Ch] 
 * *mov * * eax, [eax+3Ch] * * * * * * * *
__kernel_finish: 
 *&#59; EAX == kernel32.dll image base address
und hier die Funktion die APIs findet:
Code:
GetFuncAddr PROC 
  &#59;search for function address by scannig Export Directory Table. 
  pushad 
  mov   ebp, [esp+28h] 
  mov   eax, [ebp+3Ch] 
  mov   edx, [ebp+eax+78h] 
  add   edx, ebp 
  mov   ecx, [edx+18h] 
  mov   ebx, [edx+20h] 
  add   ebx, ebp 
GFA_loop: 
  jecxz   GFA_notfound 
  dec   ecx 
  mov   esi, [ebx+ecx*4] 
  add   esi, ebp 
GFA_compute_hash: 
  xor   edi, edi 
  xor   eax, eax 
  cld 
GFA_compute_hash_again: 
  lodsb 
  test  al, al 
  jz     GFA_compute_hash_finished 
  ror   edi, 0Dh 
  add   edi, eax 
  jmp   GFA_compute_hash_again 
GFA_compute_hash_finished: 
GFA_compare: 
  cmp   edi, [esp+24h] 
  jnz   GFA_loop 
  mov   ebx, [edx+24h] 
  add   ebx, ebp 
  mov   cx, [ebx+2*ecx] 
  mov   ebx, [edx+1Ch] 
  add   ebx, ebp 
  mov   eax, [ebx+4*ecx] 
  add   eax, ebp 
  mov   [esp+1Ch], eax 
GFA_finish: 
  popad 
  ret   8 
GFA_notfound: 
  xor    eax,eax 
  mov    [esp+1Ch], eax 
  jmp    GFA_finish 
  
GetFuncAddr ENDP
Wie schaffe ich es code- UND datensegment in den Adressraum der kernel32.dll jedes Processes zu laden ?

Nen codeschnipsel würd mich freuen...
03/21/2007 14:41 silon#2
(Ich sage schon mal vor dem schreiben, dass einige kleine Fehler drin sein könnten. Aber meine eigene Implementierung spricht zumindest dafür, das ich das bis ins Detail verstehe habe. Zumindest funktioniert der Code einwandfrei)

Wieso zum Teufel nimmst du ASM dafür? ... err egal :)

Um deinen Code in den Zielprozess zu bekommen, kompilierst du ihn als Dll (wie du schon in deinem anderen Thread darauf gekommen bist, läuft es auf Dll Injection hinaus).
Es hat einige Vorteile hier eine Hochsprache zu benutzen. Da du C beherrscht, wäre das nicht verkehrt.
Wie auch immer, bleiben wir bei ASM. Das größte Problem was du hast, ist nicht der Code den du in den Prozess schreibst (VirtualAllocEx und WriteProcessMemory) sondern die Strings ... oder generell der ganze Segment.

Um eine Dll zu injizieren, schreibst du als aller erstes den _vollen_ Pfad zu deiner Dll in den Zielprozess. Der nächste Schritt ist dein (Shell)Code. Hier reservierst du auch erstmal Speicher im Zielprozess mit VirtualAllocEx und schreibst ihn mit WriteProcessMemory rein. Danach muss der Pointer auf den String angepasst werden (Standard Encoding). Wenn du schlau bist, reservierst du gleich 1x Speicher mit MAX_PATH + Codelen. Den Pfad schreibst du an den Beginn des reservierten Speichers und für den Code addierst du MAX_PATH hinzu und schreibst ihn dort. Da du deinen Code kennst, subtrahierst du von der derzeitige Position MAX_PATH und ggf. die Länge der Instruktionen, die davor sind bevor du den Pointer auf den Dll-Pfad auf den Stack pusht um LoadLibrary aufzurufen.

Danach ein Aufruf in deinem Injector an CreateRemoteThread mit deiner Codeposition (Beginn des reservierten Speichers + MAX_PATH) und im Zielprozess wird ein Thread gestartet, der den Code ausführt und somit deine Dll läd.

Kleiner Hinweis: Kernel32.dll wird bei den derzeitigen Systemen _immer_ unter seiner ImageBase geladen und kollidiert mit keiner anderen System-Dll. Microsoft gibt aber keine Garantie dafür. Damit brauchst du eigentlich kein RemoteGetFuncProc.

In der Dll könntest du wie gewohnt auf deine Daten zugreifen. Für API Hooking bietet sich Dll-Injection an, da du auf herkömmliche Weise - da die volle Positon kriegst - mit dem Function Pointer arbeiten kannst, überschreibst du die ersten paar Byte der API mit einem Jmp auf deine Funktion (den Jump musst du natürlich auch kodieren/"generieren") und fertig bist du. Mit XP SP2 hat Microsoft z. B. bei den Winsock APIs vor dem push ebp den mov edi, edi Befehle eingeführt, der das Hooking mit Jumps vereinfachen soll. Damit kannst du getrost die ersten 5 byte mit deinem Jump überschreiben und bevor du die echte API aufrufst rekonstruierst den Prolog-Code und rufst die ursprüngliche Funktion auf (natürlich vorher 5 byte auf den Pointer addieren, sonst landest du wieder in deiner Funktion).
Wie dir vielleicht auffällt, sind bei vielen APIs nach push ebp und mov ebp, esp der folgende ASM Befehl nicht immer konstant (insbesondere die Länge). Damit müsstest du mit der Methode eigentlich einen Disassembler benutzen um die Länge der Befehle zu ermitteln bevor du sie hookst (und den "Rest" NOPst).

Eine andere Methode wäre Win32 Structured Exceptions zu nutzen. Der Software-Breakpoint (int 03) hat eine Länge von 1, womit du dir den Length Disassembler sparen könntest wenn du auf mov edi, edi und push ebp prüfst. Damit müsstest du zumindest alle Win APIs hooken können.

[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]

Ein Hook auf KiUserExceptionDispatcher garantiert dir, dass du als erstes die Exception zu Gesicht bekommst und dann EXCEPTION_CONTINUE_EXECUTION oder EXCEPTION_CONTINUE_SEARCH zurücklieferst und dann den Rest des Codes anhand dieses Resultats anspringst oder überspringst.

(Das ändern der Importtable werde ich nicht mal anschneiden, dafür hat es zu viele Nachteile).

Codebeispiele in ASM bekommst du leider nicht von mir. Dafür habe ich nicht die Zeit und nicht die Lust. Ich weiss auch ohne was Schmerzen sind ;)
03/21/2007 14:55 cc_ip#3
deine api befehle sind ja ganz nett, du zeugst auch davon ahnung zu haben, von dem was du laberst, dennoch soll es in asm laufen :). Wer benutzt denn die einfache methode wenns schwer auch geht ? ^^
03/21/2007 16:32 Dodge#4
Quote:
Originally posted by cc_ip@Mar 21 2007, 14:55
deine api befehle sind ja ganz nett, du zeugst auch davon ahnung zu haben, von dem was du laberst, dennoch soll es in asm laufen :). Wer benutzt denn die einfache methode wenns schwer auch geht ? ^^
die ganzen funktionen die er erwähnt hat sollte auch im asm funzen (VirtualAllocEx, WriteProcessMemory, CreateRemoteThread). bei WriteProcessMemory bin ich 100% sicher bei VirtualAllocEx nich ganz so sicher aber ich würde wetten das es geht und CreateRemoteThread sag mit nix aber wenns ne "standart funktion" ist wie die anderen 2 wird auch das gehen.

wenn ich zuhause bin und den code noh hab zeig ich dir wie man zumindest WriteProcessMemory in asm aufruft fals interesse besteht ^^



Gruß :)
03/21/2007 16:49 neji#5
machst du das nur zu lernzwecken oder willst du damit was wirklich sinnvolles schreiben?

Dann kämen nämlich noch ettliche andere Dinge hinzu, die du beachten musst, z.b.

1) was passiert, wenn ein anderes Programm auch einen Hook setzt und damit deinen Jump wieder überschreibt?

2) Teilweise stellt Windows aus Sicherheitsgründen den Originalcode wieder her, du müsstest den Hook nach bestimmten Aktionen also wieder erneuern

3) Alle neuen "linkings", sowohl dynamische als auch statische) werden zwar auf deine Callback funktionen umgeleitet, jedoch hat es keine Auswirkung auf bereits existierende linksings (z.b. statische von bereits geladenen DLLs)

4) Man kann EAT Hooks nur sehr schwer wieder entfernen , wenn überhaupt

Außerdem kann es zu Problemen kommen, wenn man die Export Tabelle von DLL's die in der Shared Area von Win9x geladen wurde, oder nicht da geladen wurden, aber eine Shared Export Table haben, ändert (komplizierter Satz Oo)

Export Table Patching kann immer nur ein bestandteil von einem guten Hook sein.

Mit deinem ASM Problem kann ich dir leider nicht helfen, aber wollte dich trotzdem darauf aufmerksam machen
03/21/2007 21:32 rEdoX#6
Quote:
Originally posted by DodgeX+Mar 21 2007, 16:32--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>QUOTE (DodgeX @ Mar 21 2007, 16:32)</td></tr><tr><td id='QUOTE'> <!--QuoteBegin--cc_ip@Mar 21 2007, 14:55
deine api befehle sind ja ganz nett, du zeugst auch davon ahnung zu haben, von dem was du laberst, dennoch soll es in asm laufen :). Wer benutzt denn die einfache methode wenns schwer auch geht ? ^^
die ganzen funktionen die er erwähnt hat sollte auch im asm funzen (VirtualAllocEx, WriteProcessMemory, CreateRemoteThread). bei WriteProcessMemory bin ich 100% sicher bei VirtualAllocEx nich ganz so sicher aber ich würde wetten das es geht und CreateRemoteThread sag mit nix aber wenns ne "standart funktion" ist wie die anderen 2 wird auch das gehen.

wenn ich zuhause bin und den code noh hab zeig ich dir wie man zumindest WriteProcessMemory in asm aufruft fals interesse besteht ^^



Gruß :) [/b][/quote]
Man kann jeden API befehl in asm nutzen, was anderes macht eine hochsprache doch auch nicht (:
03/22/2007 11:54 cc_ip#7
jedoch gibt es einen kleinen unterschied zwischen können und wollen, ich könnte ja z.b. auch ein c programm schreiben und darin(wenn auch nur teileweise) mit asm befehlen arbeiten...
03/22/2007 13:15 Dodge#8
wo is das problem mit den api befehlen?
03/23/2007 06:37 emjay#9
wieso möchtest du es denn unbedingt schwer machen? interessiert mich wirklich da die meisten coder die ich kenne wirklich faul sind ! ;) (abgesehen wenn es um den lerneffekt geht)

ich kann mich aber meinen vorrednern nur anschließen, c++ nehmen und alles in inline asm machen, api calls dann ohne probleme aufrufen. btw evtl solltest du bei deinem proc oben auch auf die flags achten (stichwort pushfd), ich hatte schon öfter probleme mit unsauberen hooks, die durch call xy die flags total verhunzt haben ;)

EDIT:
[Only registered and activated users can see links. Click Here To Register...]

lol 100% c & p. lern erstmal was bevor du mit kopiertem code fragen stellst, dass du so nix hinkriegst ist ja klar ROFL
03/23/2007 12:27 gotstyle#10
*LACHFLASH*

selfowned?
03/25/2007 14:49 cc_ip#11
ist copy paste denn nicht erlaubt ? ^^ der andre thread von mir ist auch nur copy paste ^^. habe in meinen ersten thread doch gesagt ich stell nen paar fragen das hab ich gemacht.