SFT Loader 2009 Hook

In diesem Artikel möchte ich die Vorgehensweise meiner Hook DLL erklären, die man im RR Board herunterladen kann: http://board.raidrush.ws/showthread.php?t=692390. Die DLL ist komplett in Assembler (MASM) geschrieben und Open-Source. Assembler versteht nicht jeder und selbst wer ein bisschen Ahnung davon hat, wird erst mal Probleme haben ein ca. 600 Zeilen langes ASM Programm zu verstehen, deshalb gibt es hier eine Erklärung in Worten.

Das Prinzip ist sehr einfach, die DLL wird in den Prozess geladen mittels einem DLL Injektion Tool und dadurch kann man in dem Prozess manipulieren was man möchte. Der SFT Loader ist zwar mit dem Protector DotFix NiceProtect geschützt, aber im laufenden Prozess hat dieser Protector keine Schutzmöglichkeit mehr, der SFT Loader ist somit „hoffnungslos“ Manipulationen ausgeliefert. Da der Protector auch keinerlei Checks beim Starten durchführt ist es so auch sehr einfach in einer freien Stelle einen kleinen Patch zu schreiben, der die DLL direkt beim Starten in den Prozess lädt.

Somit spart man sich das injekten mit einem DLL Injektion Tool.

Zum auslesen der Verbindungsdaten greift die Hook DLL drei Windows APIs an:

connect (Winsocks):
int connect( __in SOCKET s, __in const struct sockaddr *name, __in int namelen);

Diese API dient zum Aufbau der Verbindung zu einem Server. Hier liest meine DLL die IP und den Port aus. Die IP befindet sich in einer in_addr Struktur und zum umwandeln in das normale IP Format bietet sich die API inet_ntoa an.

send (Winsocks):
int send( __in SOCKET s, __in const char *buf, __in int len, __in int flags);

Zum Auslesen des Usernamen, Passworts und Pfad wird die send Funktion angegriffen in dem const char *buf befindet sich alles im Klartext, so dass man es nur speichern muss.

SSL_write (SSL):
int SSL_write(SSL *ssl, const void *buf, int num);

Für die SSL Verbindungen muss man eine 3. API angreifen. Bei SSL werden Username, Passwort und Pfad zunächst verschlüsselt und dann erst mit send abgeschickt. Die Funktion SSL_write ist zuständig für das Verschlüsseln der Daten. Im const void *buf befinden sich alle zu verschlüsselnden Daten im Klartext, man kann sie also auch bequem auslesen und speichern.

Um den Anti-Sniff Schutz zu deaktivieren muss eine weitere API angegriffen werden.

Process32Next (Kernel):
BOOL WINAPI Process32Next( __in HANDLE hSnapshot, __out LPPROCESSENTRY32 lppe);

Der SFT Loader benutzt CreateToolhelp32Snapshot um alle gestarteten Prozesse auf dem PC auszulesen und iteriert mit Process32Next durch alle Prozesse durch und vergleicht die Namen mit einer „Bad Wordlist“. Wenn z.B. der Prozess wireshark.exe gefunden wird, weiß der Loader das ein Sniffer vorhanden.

Wie werden die APIs angegriffen?

In meiner DLL gibt es zwei Funktionen die das sogenannte hooken der APIs übernehmen. Zum einen JmpDetour und zum anderen JmpDetourBackup. Beide Funktionen überschreiben die ersten 5 Bytes der API mit einem JMP zu einer Adresse meiner Wahl. Der einzige Unterschied zwischen ihnen ist, dass JmpDetourBackup ein Backup der originalen Bytes anlegt, wie hier im Beispiel an connect gezeigt wird.

Die connect API erhält einen JMP zu meiner connect_Hook Prozedur in meiner Hook DLL.

Der Pointer zu den IP/Port Daten wird gesichert und mit pushad/popad werden die Register vor Veränderungen geschützt. Die Prozedur bei 100013F1 liest IP/Port aus und speichert sie. Am Ende wird zum Backup der originalen API Bytes gesprungen:

Und schließlich wird zur API zurückgesprungen als ob nichts gewesen wäre.

Die gleiche Methode wird auch bei send verwendet.

Die JmpDetour Funktion wird nur bei Process32Next benutzt. Ein Backup der originalen Bytes ist nicht nötig, da wir die API nicht ausführen werden. EAX wird auf null gesetzt (= false) und mit einem RET wird zum SFT Loader zurückgekehrt. EAX = 0 bedeutet, dass keine weiteren Prozesse mehr da sind und somit denkt der Loader er wäre durch alle Prozesse bereits durch.

Für den SSL_write Hook wird eine andere Methode verwendet, da der SFT Loader die SSL Librarys erst in den Prozess ladet, wenn sie auch gebraucht werden. Die Funktionsadressen werden auch erst zur Laufzeit mit GetProcAdress geholt. Somit bietet sich hier eine sehr gute Angriffsmöglichkeit.
Vor dem Hook:

MOV EAX,leecher.00532790 ; ASCII "SSL_write"
CALL leecher.00531A44
MOV DWORD PTR DS:[5AFE20],EAX

Die Funktion bei 00531A44 bestimmt die Adresse für SSL_write und liefert sie in EAX zurück, EAX wird dann gespeichert. Unser Hook sieht nun so aus:

MOV EAX,1000138C
NOP
NOP
NOP
NOP
NOP
MOV DWORD PTR DS:[5AFE20],EAX

1000138C ist die Adresse zu der SSL_Hook Funktion in meiner DLL. Dadurch wird jedes mal wenn eigentlich SSL_write aufgerufen werden soll in Wirklichkeit meine Funktion aufgerufen.

So das war’s schon.

2 Gedanken zu „SFT Loader 2009 Hook“

  1. Pingback: API Hooking mit MS

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *