gmh5225/rust-mordor-rsBibliothèque Rusty Hell's Gate / Halo's Gate / Tartarus' Gate / FreshyCalls / Syswhispers2
J'ai nommé ce projet Mordor parce que Hell's Gate / Halo's Gate / Tartarus' Gate me rappellent la Porte Noire du Mordor dans Le Seigneur des Anneaux pour une raison étrange, haha, et le projet a besoin d'un nom cool alors pourquoi pas ?
Crédits au Wiki de Middle-earth: Shadow of War
Le hooking est une technique utilisée pour intercepter les appels vers des fonctions préexistantes ou rediriger le flux d'exécution d'une API légitime vers un autre emplacement en mémoire. Cet emplacement mémoire pourrait être contrôlé par un attaquant, un antivirus (AV), un système de détection et de réponse sur les points terminaux (EDR) ou un anti-triche (AC).
Inline Hooking : Cela nous permet de remplacer les premiers octets (instructions d'assembly) de la fonction ciblée par une instruction de saut afin de rediriger le flux d'exécution vers un autre emplacement en mémoire.
Import Address Table Hooking (IAT hooking) : La table d'adresses d'importation est une table de correspondance de pointeurs de fonctions pour les fonctions importées depuis des DLL ou des exécutables. Le hooking IAT nous permet de remplacer l'adresse de fonction dans la table d'adresses d'importation par une autre afin de rediriger le flux d'exécution du programme.
Crédits à Kyle Mistele
Hell's Gate est une technique d'injection de processus qui nous permet de rechercher une séquence d'octets appelée syscall stub, dans le module ntdll.dll, afin d'extraire les numéros d'appel système et de les enregistrer dans une table mémoire dédiée, qui est ensuite utilisée pour appeler directement les API système. Cependant, la limitation de Hell's Gate est qu'il nécessite l'accès à un module ntdll.dll propre si les fonctions sont hookées. Sinon, il ne peut pas remplir les numéros d'appel système nécessaires et finit par échouer à effectuer les appels d'API natives. Pour résoudre ce problème, une sœur jumelle est née, appelée Halo's Gate, qui n'est qu'un correctif de Hell's Gate basé sur une observation très simple.
Lorsqu'un hook est placé sur une fonction (jmp <address>), nous ne pourrons pas récupérer dynamiquement les numéros d'appel système ; pour résoudre ce problème, nous pouvons examiner les numéros d'appel système des fonctions voisines et ajuster les calculs en conséquence pour obtenir notre numéro d'appel système, car les ID d'appel système dans le syscall stub se suivent de manière incrémentale.
Hell's Gate vérifie uniquement une séquence d'octets dans l'ordre suivant 4c8bd1b8, qui ressemble à ceci en assembly :
mov r10, rcx
mov eax, <syscall>
Halo's Gate fait la même chose que Hell's Gate mais avec une vérification supplémentaire pour voir si un hook est en place en vérifiant si le premier octet de l'export est e9 (jmp) et si un hook est en place, alors Halo's Gate commence à examiner les fonctions voisines et ajuste les calculs en conséquence pour obtenir notre numéro d'appel système, puisque l'ID de syscall dans le stub de syscall se suit de manière incrémentielle.
Cependant, tous les EDR ne posent pas de hook au même endroit (au début de la fonction). Que se passe-t-il si les EDR posent un hook juste après mov r10, rcx (4c8bd1) ? Cela cassera notre code.
Tartarus' Gate résout ce problème en ajoutant une vérification supplémentaire à Halo's Gate en recherchant également ces octets de manière séquentielle 4c8bd1e9, ce qui ressemble à ceci en assembleur.
mov r10, rcx
jmp <address>
Cependant, si toutes les fonctions sont hookées, nous pouvons trouver la première et déhooker toutes une par une en commençant par l'ID d'appel 0. Cette méthode est appelée Veles' Reek chez SEKTOR7.
La technique FreshyCalls recherche dans le Export Directory les fonctions commençant par Nt (en excluant Ntdll) et les trie par adresses. Étonnamment, l'adresse la plus basse correspond au numéro de syscall 0 et la suivante aux numéros de syscall 1, 2, 3... Vous pouvez le vérifier vous-même dans x64 dbg ou Windbg.
Syswhispers2 fait la même chose mais au lieu de rechercher les fonctions Nt dans le répertoire d'export de ntdll.dll, il recherche les fonctions commençant par Zw. Étonnamment, les fonctions Zw et les fonctions Nt pointent vers les mêmes stubs de syscall et auront le même numéro d'appel système.
Ici, nous pouvons le vérifier :
La différence entre les fonctions Zw et Nt est expliquée par Microsoft ici :
"*L'API des services du système d'exploitation natif de Windows est implémentée sous la forme d'un ensemble de routines qui s'exécutent en mode noyau. Ces routines ont des noms qui commencent par le préfixe Nt ou Zw. Les pilotes en mode noyau peuvent appeler ces routines directement. Les applications en mode utilisateur peuvent accéder à ces routines en utilisant des appels système.
À quelques exceptions près, chaque routine de services système natifs possède deux versions légèrement différentes qui ont des noms similaires mais des préfixes différents. Par exemple, les appels à NtCreateFile et ZwCreateFile effectuent des opérations similaires et sont, en fait, servis par la même routine système en mode noyau.
Pour les appels système depuis le mode utilisateur, les versions Nt et Zw d'une routine se comportent de manière identique. Pour les appels depuis un pilote en mode noyau, les versions Nt et Zw d'une routine diffèrent dans la façon dont elles gèrent les valeurs de paramètres que l'appelant transmet à la routine.
Un pilote en mode noyau appelle la version Zw d'une routine de services système natifs pour informer la routine que les paramètres proviennent d'une source de confiance en mode noyau. Dans ce cas, la routine suppose qu'elle peut utiliser les paramètres en toute sécurité sans les valider au préalable. Cependant, si les paramètres peuvent provenir d'une source en mode utilisateur ou d'une source en mode noyau, le pilote appelle plutôt la version Nt de la routine, qui détermine, en fonction de l'historique du thread appelant, si les paramètres proviennent du mode utilisateur ou du mode noyau*"
Hell's Gate: Cela va analyser ntdll.dll pour trouver le début du stub de syscall (4c8bd1b8) puis récupérer l'ID de syscall. Cependant, si le stub de syscall est hooké, notre code échouera.