Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
rust-mordor-rs — Rusty Hell's Gate / Halo's Gate / Tartarus' Gate / FreshyCalls / Syswhispers2 Library | Kitploit
Strumenti/GitHubGitHub/gmh5225/rust-mordor-rs
ExploitEvasione IDS/IPSReverse EngineeringShellcodePost-ExploitAnalisi MalwareRed TeamingSviluppo PayloadBinary Exploitation
GitHubgmh5225/rust-mordor-rs

rust-mordor-rs

Rusty Hell's Gate / Halo's Gate / Tartarus' Gate / FreshyCalls / Syswhispers2 Library

32354 anni faRevisionato da Kitploit
Vedi Repository

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

Hell's Gate / Halo's Gate / Tartarus' Gate e FreshyCalls / SysWhispers2 in Rust

Ho chiamato questo progetto Mordor perché Hell's Gate / Halo's Gate / Tartarus' Gate mi ricordano per qualche strana ragione la Porta Nera di Mordor ne Il Signore degli Anelli haha e il progetto ha bisogno di un nome accattivante, quindi perché no?

BlackGate Crediti a Middle-earth: Shadow of War Wiki

TODO (Sviluppo in corso)

  • Renderlo più facile da usare
  • Aggiungere la guida all'uso nel README.md
  • Aggiungere macro per chiamate di sistema / assembly
  • Decidere se mantenerlo come libreria o come qualcosa che genera file di output come SysWhispers1, SysWhispers2, SysWhispers3

Hooking

L'hooking è una tecnica utilizzata per intercettare le chiamate a funzioni preesistenti o reindirizzare il flusso di esecuzione di un'API legittima verso un'altra posizione in memoria. Questa posizione di memoria potrebbe essere controllata da un attaccante, da un anti-virus (AV), da un end-point detection and response (EDR) o da un anti-cheat (AC).

Inline Hooking: Questo ci permette di sostituire i primi byte (istruzioni assembly) della funzione presa di mira con un'istruzione di salto per reindirizzare il flusso di esecuzione verso un'altra posizione in memoria.

Import Address Table Hooking (IAT hooking): La Import Address Table è una tabella di ricerca di puntatori a funzione per funzioni importate da DLL o eseguibili. L'IAT hooking ci permette di sostituire l'indirizzo della funzione nella Import Address Table con un altro per reindirizzare il flusso di esecuzione del programma.

BlackGate Crediti a Kyle Mistele

Descrizione

Cos'è Hell's Gate / Halo's Gate / Tartarus' Gate?

Hell's Gate è una tecnica di process injection che ci permette di cercare un certo numero di byte chiamato syscall stub, all'interno del modulo ntdll.dll per estrarre i numeri di chiamata di sistema e salvarli in una tabella di memoria dedicata, che viene poi utilizzata per chiamare direttamente le API di sistema. Tuttavia, il limite di Hell's Gate è che necessita dell'accesso a un modulo ntdll.dll pulito se le funzioni sono hookate. Altrimenti, non può popolare i numeri di chiamata di sistema necessari e alla fine fallisce nel fornire le chiamate API native. Per risolvere questo problema, è nata una gemella chiamata Halo's Gate, che è solo una patch a Hell's Gate basata su un'osservazione molto semplice.

Quando viene piazzato un hook su una funzione (jmp <address>) non saremo in grado di recuperare dinamicamente i numeri di chiamata di sistema, quindi per risolvere questo problema possiamo guardare i numeri di chiamata di sistema delle funzioni vicine e aggiustare i calcoli di conseguenza per ottenere il nostro numero di chiamata di sistema, perché gli ID delle chiamate di sistema nello syscall stub si susseguono in modo incrementale.

Hell's Gate controlla solo una sequenza di byte nel seguente ordine 4c8bd1b8, che in assembly appare così:

mov r10, rcx
mov eax, <syscall>

Halo's Gate fa lo stesso di Hell's Gate ma con un controllo aggiuntivo per verificare se è presente un hook controllando se il primo byte dell'export è e9 (jmp) e, se è presente un hook, Halo's Gate inizia a esaminare le funzioni adiacenti e ad adattare i calcoli di conseguenza per ottenere il nostro numero di system call, poiché l'ID della syscall nello stub della syscall si sussegue in modo incrementale.

Tuttavia, non tutti gli EDR effettuano l'hook nella stessa posizione (all'inizio della funzione). E se gli EDR effettuassero l'hook subito dopo mov r10, rcx (4c8bd1)? Questo romperebbe il nostro codice.

Tartarus' Gate risolve questo problema aggiungendo un controllo ulteriore a Halo's Gate cercando sequenzialmente anche questi byte 4c8bd1e9, che in assembly appare così.

mov r10, rcx
jmp <address>

Tuttavia, se tutte le funzioni sono hookate, possiamo trovare la prima e unhookare tutte una per una partendo dall'ID di chiamata 0. Questo metodo è chiamato Veles' Reek presso SEKTOR7.

FreshyCalls / SysWhispers1 / SysWhispers2 / SysWhispers3

La tecnica FreshyCalls cerca nella Export Directory le funzioni che iniziano con Nt (escludendo Ntdll) e le ordina per indirizzo. Sorprendentemente l'indirizzo più basso corrisponde al numero di syscall 0 e il successivo ai numeri di syscall 1, 2, 3... Puoi verificarlo tu stesso in x64 dbg o Windbg.

Syswhispers2 fa la stessa cosa ma, invece di cercare le funzioni Nt all'interno della export directory di ntdll.dll, cerca le funzioni che iniziano con Zw. Sorprendentemente le funzioni Zw e le funzioni Nt puntano agli stessi stub di syscall e avranno lo stesso numero di system call.

Qui possiamo verificarlo: syswhisper2

syswhisper2

La differenza tra le funzioni Zw e Nt è spiegata da Microsoft qui:

"*L'API dei servizi del sistema operativo nativo di Windows è implementata come un insieme di routine che vengono eseguite in modalità kernel. Queste routine hanno nomi che iniziano con il prefisso Nt o Zw. I driver in modalità kernel possono chiamare queste routine direttamente. Le applicazioni in modalità utente possono accedere a queste routine tramite le system call.

Con poche eccezioni, ogni routine dei servizi di sistema nativi ha due versioni leggermente diverse che hanno nomi simili ma prefissi diversi. Ad esempio, le chiamate a NtCreateFile e ZwCreateFile eseguono operazioni simili e sono, di fatto, servite dalla stessa routine di sistema in modalità kernel.

Per le system call dalla modalità utente, le versioni Nt e Zw di una routine si comportano in modo identico. Per le chiamate da un driver in modalità kernel, le versioni Nt e Zw di una routine differiscono nel modo in cui gestiscono i valori dei parametri che il chiamante passa alla routine.

Un driver in modalità kernel chiama la versione Zw di una routine dei servizi di sistema nativi per informare la routine che i parametri provengono da una fonte attendibile in modalità kernel. In questo caso, la routine presume di poter utilizzare i parametri in modo sicuro senza prima validarli. Tuttavia, se i parametri potrebbero provenire da una fonte in modalità utente o da una fonte in modalità kernel, il driver chiama invece la versione Nt della routine, che determina, in base alla cronologia del thread chiamante, se i parametri hanno avuto origine in modalità utente o in modalità kernel*"

In sintesi:

Hell's Gate: Analizza ntdll.dll per trovare l'inizio dello stub di syscall (4c8bd1b8) e poi recupera l'ID della syscall. Tuttavia, se lo stub di syscall è hookato, il nostro codice si romperà.

Halo's Gate: Uguale a Hell's Gate, ma aggiunge un controllo aggiuntivo per verificare se i primi hook sono presenti controllando se il primo byte è e9 (jmp) e, se è presente un hook, Halo's Gate inizia a esaminare le funzioni vicine e ad adattare i calcoli di conseguenza per ottenere il nostro numero di system call, poiché l'ID della syscall nello stub di syscall procede in modo incrementale.

Scarica lo strumento