mandiant/straceUn DTrace su Windows Reimplementazione
Il tracer di Steve. Una reimplementazione dell'hook delle syscall di DTrace su Windows. Pensatelo come un hook SSDT compatibile con PatchGuard, ma senza hack. Non supporta SSSDT (API win32k), poiché le API di sistema di DTrace stesse non supportano questa tabella aggiuntiva. Le API kernel Zw* possono essere tracciate in aggiunta a tutte le syscall SSDT in modalità utente.
Leggi fino alla fine di questo readme se stai sviluppando nuovi plugin per STrace!
Dtrace su Windows supporta molteplici tipi di probe. Questi includono syscall, fbt, etw, profile e forse altri. Questa reimplementazione reimplementa solo i tipi di probe syscall ed etw. Tutti gli altri tipi di probe sono considerati completamente fuori ambito per questo progetto e non saranno mai supportati. Sentiti libero di fare il fork del progetto se desideri aggiungere ulteriori tipi di probe. L'ambito è stato limitato solo ai probe syscall ed etw a causa della complessità degli altri tipi di probe e dei sistemi che toccano.
Questa reimplementazione scarta completamente il linguaggio di scripting D (nota: NON DLang, il linguaggio moderno più popolare). La complessità di una VM nel kernel come nell'implementazione originale di DTrace è inadatta a questo progetto. Invece, questa implementazione espone direttamente le callback C rilevanti necessarie per integrarsi nelle interfacce del kernel Windows di DTrace. Per abilitare l'hot-loading degli script, è stato usato un sistema di plugin basato su DLL come sostituto della VM + ambiente di scripting del dtrace originale. Questo sistema di plugin accetta una DLL "normale" in modalità utente senza controlli di sicurezza abilitati, né dipendenze esterne, e la mappa manualmente nello spazio degli indirizzi del kernel. La plugin dll ha esportazioni che vengono invocate quando si verificano le callback di syscall del kernel. Le API del kernel vengono risolte tramite la normale import table (IAT) della DLL; le DLL plugin si collegano a ntoskrnl.lib e poi il driver risolve queste API al momento del caricamento, consentendo a qualsiasi API di sistema di essere chiamata all'interno delle DLL plugin come di consueto. Le prestazioni di questo sistema di plugin sono eccellenti, poiché il codice nativo, piuttosto che un interprete di script o un JIT, viene eseguito direttamente tra ENTRY e RETURN della syscall. Questo design migliora le prestazioni rispetto all'implementazione dtrace fornita da Microsoft.
Impostare hook è molto semplice: hai una routine per registrare/annullare la registrazione di un hook tramite nome API, con una callback pre e post syscall. Le callback hanno argomenti e valori di ritorno accessibili come valori di sola lettura. I valori di ritorno possono essere falsificati nei probe di ritorno e gli argomenti possono essere modificati nei probe di ingresso, ma la syscall originale non può normalmente sostituire o "cancellare" una syscall: questa API agisce come un osservatore. Esiste tuttavia una svista simile a quella documentata in (https://github.com/everdox/InfinityHook e https://github.com/everdox/InfinityHook/raw/master/resources/perf.png) che consente di sostituire il puntatore della syscall nello stack. Con questa svista è possibile sostituire completamente una syscall con un puntatore a una routine da te controllata. Quando si verificano eventi e la tua callback di hook viene attivata, si può fare qualsiasi cosa. Le callback sono sincrone, il che significa che se ritardi l'esecuzione nella callback di ingresso, ad esempio rimanendo in un ciclo while, la chiamata di syscall verrà ritardata di quella quantità di tempo. L'esecuzione della chiamata di sistema avviene subito dopo il ritorno dalla callback di ingresso e subito prima dell'ingresso nella callback di ritorno. Questo sistema è completamente compatibile con PatchGuard, tuttavia DSE deve essere disabilitato, poiché Microsoft purtroppo considera questo tipo di estensione del kernel parte del kernel NT e quindi verifica che il firmatario radice sia Windows. Questo non funziona con trucchi come abilitare firmatari kernel personalizzati: DSE deve essere davvero disattivato durante l'avvio del kernel.
ValidationFlags=IMGP_LATEST_MS_ROOT_REQUIRED | IMGP_WINDOWS_ROOT_REQUIRED | IMGP_MS_SIGNATURE_REQUIRED
Scenario=ImgSigningScenarioWindows
Il driver Rust abbandona il sistema di plugin basato su DLL usato dal driver C++ e tenta invece di usare un interprete web assembly per ospitare script wasm nel kernel Windows. Questo serve a essere più simile all'implementazione dtrace originale, che usa una VM, ma con un linguaggio migliore di DLang. Questo fornisce sandboxing e altri bei vantaggi. Il POC è completo e funziona, ma sfortunatamente non è utilizzabile a causa di problemi di prestazioni nell'interpretazione di WASM con WASMI. Un motore wasm basato su JIT e compatibile con il kernel NT sarebbe necessario per rendere attuabile questo progetto alternativo. È incluso come una piacevole novità e potrebbe essere utilizzabile per qualcos'altro con un po' di lavoro.
Questo progetto è in gran parte suddiviso tra i suoi componenti C++ e Rust. Il driver C è completo di funzionalità e dovrebbe essere preferito. A livello generale, il progetto ha i seguenti componenti:
Configura Visual Studio con il DDK
Compila il driver e la CLI, sposta i file nella stessa cartella dello script, quindi esegui lo script powershell nella cartella install come amministratore:
./install_as_admin.ps1
Riavvia, quindi seleziona la voce di avvio STrace e premi F8 (non Invio!) su questa schermata:
Questo dovrebbe far apparire questa schermata: seleziona l'avvio con DSE disabilitato:
Dopo un avvio riuscito, la CLI può essere usata per caricare e scaricare le DLL dei plugin per iniziare il tracing. Sono forniti due plugin di esempio. Leggi attentamente i dettagli qui sotto se riscontri problemi. Potrebbe essere necessario riavviare di nuovo la prima volta e potenzialmente impostare manualmente il servizio STrace per l'avvio automatico at boot usando uno strumento come process hacker.
L'installazione DTrace originale è qui: https://techcommunity.microsoft.com/t5/windows-kernel-internals/dtrace-on-windows-20h1-updates/ba-p/1127929. Il DTrace originale richiede che Secure Boot e Virtualization-Based Security siano configurati; non è questo il caso di STrace, poiché non implementa i tipi di probe (FBT) che richiedono queste funzionalità.