gmh5225/rust-mordor-rsRusty Hell's Gate / Halo's Gate / Tartarus' Gate / FreshyCalls / Syswhispers2-Bibliothek
Ich habe dieses Projekt Mordor genannt, weil Hell's Gate / Halo's Gate / Tartarus' Gate mich aus irgendeinem seltsamen Grund an das Schwarze Tor von Mordor in Der Herr der Ringe erinnern, haha, und das Projekt braucht einen coolen Namen, also warum nicht?
Danksagung an Middle-earth: Shadow of War Wiki
Hooking ist eine Technik, die verwendet wird, um Aufrufe an bereits vorhandene Funktionen abzufangen oder den Ausführungsfluss einer legitimen API an eine andere Stelle im Speicher umzuleiten. Diese Speicherstelle könnte von einem Angreifer, einer Antivirus-Software (AV), einer Endpoint Detection and Response (EDR) oder einer Anti-Cheat-Software (AC) kontrolliert werden.
Inline Hooking: Dies ermöglicht es uns, die ersten paar Bytes (Assembly-Anweisungen) der Zielfunktion durch eine Sprunganweisung zu ersetzen, um den Ausführungsfluss an eine andere Stelle im Speicher umzuleiten.
Import Address Table Hooking (IAT-Hooking): Die Import Address Table ist eine Nachschlagetabelle mit Funktionszeigern für Funktionen, die aus DLLs oder ausführbaren Dateien importiert werden. IAT-Hooking ermöglicht es uns, die Funktionsadresse in der Import Address Table durch eine andere zu ersetzen, um den Ausführungsfluss des Programms umzuleiten.
Danksagung an Kyle Mistele
Hell's Gate ist eine Prozessinjektionstechnik, die es uns ermöglicht, nach einer bestimmten Bytefolge namens Syscall-Stub im Modul ntdll.dll zu suchen, um die Systemaufrufnummern zu extrahieren und sie in einer dedizierten Speichertabelle zu speichern, die dann verwendet wird, um System-APIs direkt aufzurufen. Die Einschränkung von Hell's Gate besteht jedoch darin, dass es Zugriff auf ein sauberes ntdll.dll-Modul benötigt, wenn die Funktionen gehookt sind. Andernfalls kann es die benötigten Syscall-Nummern nicht befüllen und scheitert letztendlich daran, native API-Aufrufe auszuführen. Um dieses Problem zu lösen, wurde eine Zwillingsschwester namens Halo's Gate geboren, die lediglich ein Patch für Hell's Gate ist, basierend auf einer sehr einfachen Beobachtung.
Wenn ein Hook auf eine Funktion gesetzt wird (jmp <address>), können wir die Syscall-Nummern nicht dynamisch abrufen. Um dieses Problem zu lösen, können wir uns die Systemaufrufnummern der benachbarten Funktionen ansehen und die Berechnungen entsprechend anpassen, um unsere Systemaufrufnummer zu erhalten, da die Syscall-IDs im Syscall-Stub aufeinanderfolgend inkrementell sind.
Hell's Gate prüft nur auf eine Bytefolge in der folgenden Reihenfolge 4c8bd1b8, die in Assembly so aussieht:
mov r10, rcx
mov eax, <syscall>
Halo's Gate macht dasselbe wie Hell's Gate, führt aber eine zusätzliche Prüfung durch, um festzustellen, ob ein Hook vorhanden ist, indem geprüft wird, ob das erste Byte des Exports e9 (jmp) ist. Wenn ein Hook vorhanden ist, beginnt Halo's Gate, die benachbarten Funktionen zu betrachten und die Berechnungen entsprechend anzupassen, um unsere Systemaufrufnummer zu erhalten, da die Syscall-ID im Syscall-Stub aufeinanderfolgend inkrementiert wird.
Allerdings hooken nicht alle EDRs an derselben Stelle (am Anfang der Funktion). Was, wenn EDRs direkt nach mov r10, rcx (4c8bd1) hooken? Das würde unseren Code brechen.
Tartarus' Gate löst dieses Problem, indem es eine zusätzliche Prüfung zu Halo's Gate hinzufügt, indem es ebenfalls sequenziell nach diesen Bytes 4c8bd1e9 sucht, was in Assembly so aussieht.
mov r10, rcx
jmp <address>
Wenn jedoch alle Funktionen gehookt sind, können wir die erste finden und alle nacheinander ab Call-ID 0 enthooken. Diese Methode wird Veles' Reek bei SEKTOR7 genannt.
Die FreshyCalls-Technik durchsucht das Export Directory nach Funktionen, die mit Nt beginnen (mit Ausnahme von Ntdll), und sortiert sie nach Adressen. Überraschenderweise ist die niedrigste Adresse die Syscall-Nummer 0 und die nächste sind die Syscall-Nummern 1 und 2 und 3... Sie können dies selbst in x64 dbg oder Windbg überprüfen.
Syswhispers2 macht dasselbe, aber anstatt nach den Nt-Funktionen im Exportverzeichnis von ntdll.dll zu suchen, sucht es nach Funktionen, die mit Zw beginnen. Überraschenderweise zeigen Zw-Funktionen und Nt-Funktionen auf dieselben Syscall-Stubs und haben dieselbe Systemaufrufnummer.
Hier können wir das überprüfen:
Der Unterschied zwischen Zw- und Nt-Funktionen wird von Microsoft hier erklärt:
"*Die Windows-API für native Betriebssystemdienste ist als eine Reihe von Routinen implementiert, die im Kernelmodus ausgeführt werden. Diese Routinen haben Namen, die mit dem Präfix Nt oder Zw beginnen. Kernelmodustreiber können diese Routinen direkt aufrufen. Benutzermodus-Anwendungen können auf diese Routinen über Systemaufrufe zugreifen.
Mit wenigen Ausnahmen hat jede Routine für native Systemdienste zwei leicht unterschiedliche Versionen mit ähnlichen Namen, aber unterschiedlichen Präfixen. Beispielsweise führen Aufrufe von NtCreateFile und ZwCreateFile ähnliche Operationen aus und werden tatsächlich von derselben Kernelmodus-Systemroutine bedient.
Bei Systemaufrufen aus dem Benutzermodus verhalten sich die Nt- und Zw-Versionen einer Routine identisch. Bei Aufrufen aus einem Kernelmodustreiber unterscheiden sich die Nt- und Zw-Versionen einer Routine darin, wie sie die Parameterwerte behandeln, die der Aufrufer an die Routine übergibt.
Ein Kernelmodustreiber ruft die Zw-Version einer Routine für native Systemdienste auf, um der Routine mitzuteilen, dass die Parameter aus einer vertrauenswürdigen Kernelmodus-Quelle stammen. In diesem Fall geht die Routine davon aus, dass sie die Parameter sicher verwenden kann, ohne sie zuvor zu validieren. Wenn die Parameter jedoch aus einer Benutzermodus- oder einer Kernelmodus-Quelle stammen könnten, ruft der Treiber stattdessen die Nt-Version der Routine auf, die anhand des Verlaufs des aufrufenden Threads bestimmt, ob die Parameter aus dem Benutzermodus oder dem Kernelmodus stammen*"
Hell's Gate: Dies parst ntdll.dll, um den Anfang des Syscall-Stubs (4c8bd1b8) zu finden, und ruft dann die Syscall-ID ab. Wenn der Syscall-Stub jedoch gehookt ist, bricht unser Code.
Halo's Gate: Dasselbe wie Hell's Gate, fügt aber eine zusätzliche Prüfung hinzu, um festzustellen, ob die ersten Hooks vorhanden sind, indem geprüft wird, ob das erste Byte e9 (jmp) ist. Wenn ein Hook vorhanden ist, beginnt Halo's Gate, die benachbarten Funktionen zu betrachten und die Berechnungen entsprechend anzupassen, um unsere Systemaufrufnummer zu erhalten, da die Syscall-ID im Syscall-Stub jeweils inkrementell aufeinander folgt.