[Suche]Idee wie man alle hooks auflisten koennte ..

[ReDoX]

Hi,
ich suche eine Idee *gg*, wie ich alle Hooks aus einem bestimmten Prozess auflisten koennte.
Wie ermittelt man das Offset eine Funktion aus einem Remoteprozess? (GetProcAddress)
Wie erkennt man einen Hook? (Inline, ITA).

danke fuer alle anregungen

--redox

[HellBird]

naja im Prinzip könntest du alles im Speicher vom Prozess finden:
Offset einer Funktion:
- Thread Environment Block finden
- Process Environment Block finden
- Verkettete Liste mit den geladenen DLLs finden
- Basisadresse finden
- Header auswerten

Tutorial:
http://arnold.mcdonald.free.fr/php/Index.php?p=1006
http://arnold.mcdonald.free.fr/php/Index.php?p=1007

Hook erkennen? vielleicht so
EXE-Header -> Import Table Finden -> Wert im FirstThunk mit dem echten Wert vergleichen....

Bei diesen Sachen geht man natürlich davon aus, dass es sich um eine anständige EXE handelt und vor allem kein Packer herumpfuscht

[CDW]

IAT:

Wert im FirstThunk mit dem echten Wert vergleichen.... und woher weiß man, welcher wert der echte ist ;) ?
Wenn die Applikation noch nicht läuft, verweist FistThunk auf ein Array, in welchem man entweder lauter Zeiger auf Namen-Strings oder Ordinalvalues findet - die Reihenfolge ist dabei willkürlich bzw. vom Linker festgelegt.
Also müsste man sich erstmal was zusammenbasteln, um die ImportTable durchzugehen und eine IAT zu rekonstruieren bzw selber eine "richtige" basteln (mittels LoadLibrary/GetProcAddress).

Soweit ich mich erinnere, kann die IAT auch "zerstückelt" sein (nur ImportTable-Einträge müssen zusammenhängen), die IAT-Angabe im Directory Eintrag ist dazu optional. So dass man auf jedenfall Einträge selber durchgehen muss (was eigentlich noch gut zu bewerkstelligen wäre).Folgende Probleme fallen mir ein:

1.non-system DLLs. Die werden nämlich dahin gemappt, wo der PE-Loader gerade lust hat (zumindest wären die Adressenabweichungen nicht zwingend ein Hookindiz). Man müsste also diese non-SystemDLLs erstmal rausfiltern.
2. Wer garantiert, dass der "Prüfer" nicht auch gehookt wird und somit dieselben Adresse für wichtige Funktionen erhält, die gehookt werden? Zum Beispiel wenn sowieso automatisch jede laufende Anwendung gehookt wird (es gibt ja verschiedene Methoden), dann war der ganze Aufwand umsonst.




Offset einer Funktion:
- Thread Environment Block finden
- Process Environment Block finden
- Verkettete Liste mit den geladenen DLLs finden

Ich ging bis jetzt immer davon aus, dass die System-Dlls Systemweit immer in denselben Speicherbereich eingeblendet werden.
D.h wenn man "GetProcAddress" in Programm X in 0123 findet, dann liegt diese Funktion in Programm Y auch in 0123. Sehr bequem, um eben SystemAPis in anderen Programmen zu bestimmen - z.B um einen Hook/Callback zu setzen ;) (siehe auch das Keygenme "Hiddencode" im RE Bereich, Callbackhooks sind bei Loadern mein liebstes Kind ;))

Jetzt kommen wir auch zum nächsten Problem: um solche Hooks (auf System-Apis) festzustellen, müsste man dann zusätzlich den Speicherbereich der eingeblendeten SystemDLLs verifizieren oder nach einem "Hook" scannen (wobei dann wiederum alle Möglichkeiten (call/JMP) berücksichtigt werden müssen). Sollte schon rel. aufwändig sein.
Und diese Hook-Methode dürfte gar nicht so selten sein, da man bei IAT immer die Probleme mit Packern hat (die IAT kann man dann nicht "von außen"(also wenn das Programm nicht läuft) bestimmen und auch wenn das Programm läuft, dürfte es nicht ganz einfach werden).

Naja, da gibt es bestimmt noch mehr lustige Sachen, die man berücksichtigen müsste ;)

@HellBird: nette Links, jetzt weiß ich auch, wie GetProcAddress "Ersatz/Emulation" funktioniert

[nait]

Scheinbar ist hier die Rede von API-Hooking, sonst hätte ich vorgeschlagen einen eigenen Hook mit SetWindowsHookEx zu installieren.Dieser wird per default an die Spitze der Hook-Chain gehängt und hat somit die Kontrolle über alle folgenden Hook-Adressen. Mit diesen Adressen kann man dan einfach herausfinden zu welchem Modul sie gehören und ob sie "erlaubt" sind. Z.B. mit CreateToolhelp32Snapshot und Module32First.

Um API-Hooking zu entdecken wäre ein Ansatz die Code-Section einer DLL/EXE-Datei mit dem Image im Speicher zu vergleichen (Hashing oder direkter vergleich). Das hat allerdings den Nachteil, dass kein Packer am Werke ist und der Code nicht selbstmodifizierend sein darf. Das braucht zwar Performance bringt aber den Vorteil,dass man keine Problem mit der Funktions-Adress bekommt.

@CDW:
Ich dachte bis jetzt, dass nur die Kernel32.dll an einer fixen Adresse liegt und das auch nur für jede einzelne Windowsversion, so dass Win2k und WinXP nicht die selben Basis-Adressen haben werden.

[CDW]

@CDW:
Ich dachte bis jetzt, dass nur die Kernel32.dll an einer fixen Adresse liegt und das auch nur für jede einzelne Windowsversion, so dass Win2k und WinXP nicht die selben Basis-Adressen haben werden.
Also afaik gilt das auch für advapi32, user32.dll etc. Ich habe leider keine Quelle mehr, aber bist jetzt klappten verschiedene Callback-Hooks (z.B in Loadern) ganz gut (getestet meistens auf Win2k/XP auf unterschiedliche Funktionen).Und mit "Systemweit" meinte ich natürlich nur den einen ausführenden Rechner und zwar zur gleichen ausführungszeit.

[morpheus]

Es wuerde wahrscheinlich auch weiterhelfen, wenn du verraten wuerdest, was du mit der Anwendung dann schlussendlich machen moechtest.

VICE bietet zum Beispiel eine API fuer externe Anwendungen an.

[ReDoX]

Erstmal danke an alle fuer antworten. Ich wollte ein tool coden was alle hooks in einem prozess auflistet, da ich noch kein tool gefunden habe was mir diese funktion bietet.