- L'SSDT funge da ponte tra le chiamate degli utenti e i servizi principali. Windows.
- La sua manipolazione è una tecnica fondamentale sia nella protezione che negli attacchi (rootkit, antivirus).
- La struttura e la protezione dell'SSDT si sono evolute per impedire modifiche dannose.
Comprendere il funzionamento interno di OS moderno è essenziale per qualsiasi professionista IT, soprattutto quando si tratta di questioni legate alla sicurezza, allo sviluppo driver o reverse engineering. Uno dei concetti chiave in questo campo è il Tabella dei descrittori del servizio di sistema (SSDT), una struttura fondamentale nel nucleo dei sistemi Windows che, sebbene spesso passi inosservata all'utente medio, svolge un ruolo vitale nell'interazione tra il software e l' hardware, nella gestione delle chiamate di sistema e, purtroppo, anche in alcune tecniche di attacco e difesa nel mondo di il malware e antivirus.
Questo articolo offre Una panoramica completa e dettagliata di cosa è SSDT, come funziona in diverse versioni e architetture di Windows, qual è il suo ruolo nell'esecuzione delle chiamate di sistema (syscall), come può essere utilizzato sia dai rootkit che da strumenti di sicurezza legittimi e quali tecniche consentono di ispezionarlo, manipolarlo o proteggerne l'integrità. Se sei coinvolto nello sviluppo di driver, nell'analisi forense, sicurezza informatica o se sei semplicemente appassionato del cuore dei sistemi Windows, questa guida ti servirà da riferimento essenziale.
Che cos'è la tabella dei descrittori dei servizi di sistema (SSDT)?
La Tabella dei descrittori del servizio di sistema, menzionato anche come Tabella di distribuzione dei servizi di sistema e noto con il suo acronimo SSDT, è una tabella speciale mantenuta dal kernel di Windows (ntoskrnl.exe) che contiene puntatori alle funzioni del kernel responsabili dell'elaborazione delle chiamate di sistema effettuate dallo spazio utente. In altre parole, è una sorta di "ponte" che collega le richieste effettuate da applicazioni o librerie utente (come ntdll.dll) con i servizi interni del kernel del sistema operativo.
En Sistemi a 32 bit, l'SSDT è semplicemente un array di indirizzi assoluti alle funzioni del kernel. In file a 64 bitPer motivi di sicurezza ed efficienza, la tabella memorizza gli offset relativi da una base nota all'interno del kernel. Questo dettaglio è importante perché influenza il modo in cui i percorsi verso le funzioni interne vengono risolti e come possono essere analizzati o manipolati da debugger o strumenti di analisi.
Come funziona in pratica l'SSDT
Il flusso di una chiamata di sistema dallo spazio utente alla sua gestione nel kernel può essere riassunto come segue:
- Un programma o un processo utente richiede, ad esempio, l'apertura di un file utilizzando una funzione API di Windows, come CreateFile.
- Questa chiamata finisce per chiamare una funzione di ntdll.dll come NtCreateFile, che è responsabile della preparazione della chiamata di sistema associata (syscall).
- La funzione di ntdll.dll esegue un'istruzione chiamata di sistema (su x64) o intero 0x2e (su x86), dove un indice viene passato come parametro che identifica in modo univoco quale servizio di sistema è richiesto.
- Già in modalità kernel, quell'indice viene utilizzato per cercare il SSDT l'offset o l'indirizzo della funzione kernel corrispondente e il controllo viene trasferito a quella funzione (ad esempio, nt!NtCreaFile).
In questo modo, il SSDT Funziona come una tabella di salto che consente di rendere disponibili centinaia di funzioni del kernel in modo ordinato ed efficiente, oltre a fornire una netta separazione tra lo spazio utente e lo spazio del kernel protetto.
Struttura interna dell'SSDT e sua rappresentazione in memoria
Nel kernel di Windows, l'SSDT è accessibile tramite una struttura chiamata TabellaDescrittoreKeService, esportato da lui stesso ntoskrnl.exeQuesta struttura contiene informazioni chiave sulla tabella, inclusa la base della tabella (Tabella di servizio Ki), il numero di servizi e altri metadati.
Il modo per accedere all'SSDT e interpretarne gli input varia a seconda dell'architettura:
- En x86 (32 bit), Tabella di servizio Ki Si tratta di un array in cui ogni elemento punta direttamente all'indirizzo assoluto di una funzione del kernel.
- En x64 (64 bit), gli elementi sono spostamenti relativi (offset) rispetto alla base, quindi per ottenere l'indirizzo reale è necessario applicare una formula prendendo detta base e aggiungendo lo spostamento corrispondente, normalmente dopo un aggiustamento di bit verso destra (spostamento >> 4).
Diamo un'occhiata a un esempio reale utilizzando il debugger WinDBG per illustrare come viene formata la tabella in memoria:
0: kd> dps nt!KeServiceDescriptorTable L4
fffff801`9210b880 fffff801`9203b470 nt!KiServiceTable
fffff801`9210b888 00000000`00000000
fffff801`9210b890 00000000`000001ce
fffff801`9210b898 fffff801`9203bbac nt!KiArgumentTableIl primo elemento punta a Tabella di servizio Ki, ovvero l'SSDT stesso. Il terzo elemento indica solitamente il numero di servizi disponibili. Durante l'ispezione Tabella di servizio Ki, vedremo una serie di valori che sono, ciascuno, gli spostamenti o gli indirizzi verso ciascuna funzione kernel esportata dall'SSDT.
Variazioni sulle tabelle: SSDT e SSDT Shadow
En versioni moderne di Windows Oltre alla tabella principale, c'è una tabella "ombra" chiamata KeServiceDescriptorTableShadowQuesta seconda tabella viene solitamente utilizzata per servizi più specifici, come quelli relativi all'interfaccia grafica del sistema (ad esempio, chiamate a win32k). Il sistema determina in tempo reale, tramite parametri provenienti dal processo chiamante, quale delle due tabelle deve essere utilizzata per risolvere una determinata syscall.
Esempio: risoluzione delle chiamate e delle funzioni del kernel utilizzando SSDT
Supponiamo che uno sviluppatore o un analista voglia sapere a quale funzione del kernel corrisponde un particolare numero di syscall, ad esempio, quello associato a NtCreateFileIl procedimento sarebbe il seguente:
- Identifichiamo l'indice della syscall esaminando il codice in ntdll.dllAd esempio, potrebbe essere 0x55.
- Ogni voce del Tabella di servizio Ki (l'SSDT) occupa 4 byte, quindi per la syscall 0x55 accediamo alla posizione TabellaServizioKi + 4*0x55.
- Estraiamo lo spostamento e, applicando la formula appropriata, risolviamo la direzione assoluta della funzione.
- Possiamo disassemblare la funzione nel debugger per verificare che questo offset punti effettivamente al codice in questione. nt!NtCreaFile.
Questo sistema garantisce che ogni chiamata di sistema effettuata dall'utente venga indirizzata in modo efficiente e sicuro alla funzione interna appropriata, mantenendo l'integrità del sistema e ottimizzando le prestazioni.
Tecniche di analisi e manipolazione SSDT
Accesso e analisi del SSDT È essenziale sia per lo sviluppo di driver legittimi che per il rilevamento di rootkit e malware. Ad esempio, in WinDbg Tutti gli indirizzi assoluti delle funzioni nella tabella possono essere estratti da script che attraversano l'SSDT e risolvono i nomi delle API associate a ciascun indirizzo. Esempio di frammento di codice copione:
.foreach /ps 1 /pS 1 ( offset {dd /c 1 nt!KiServiceTable L poi(nt!KeServiceDescriptorTable+10)}){ r $t0 = ( offset >>> 4) + nt!KiServiceTable; .printf "%p - %y\n", $t0, $t0 }Questa tecnica consente di elencare e analizzare le possibili modifiche, identificare se le funzioni sono state agganciate e rilevare possibili infezioni.
SSDT Hooking: uso legittimo e abuso di malware
Modificare l'SSDT, una tecnica nota come Aggancio SSDT, consiste nel sostituire le voci della tabella per reindirizzare determinate chiamate di sistema a funzioni proprietarie, solitamente da driver di terze parti. Ciò consente di intercettare, modificare o bloccare determinate operazioni, cosa che è stata utilizzata da antivirus y firewall per proteggere il sistema in tempo reale.
Tuttavia, questa stessa tecnica è stata ampiamente sfruttata da rootkit e malware avanzati per camuffare la propria presenza, nascondere processi, file o connessioni, o persino facilitare l'esecuzione di codice arbitrario nel kernel. L'aggancio SSDT può essere particolarmente pericoloso perché garantisce il controllo completo sugli eventi critici del sistema e, una volta alterato, è difficile rilevarlo senza gli strumenti appropriati o un riferimento di sistema pulito.
Un esempio chiaro può essere visto confrontando lo stato dell'SSDT prima e dopo l'installazione di un rootkit:
| Con rootkit | Nessun rootkit |
|---|---|
| … f7c38486 … | … 8056f074 … |
Il rootkit ha sostituito l'indirizzo legittimo con il proprio. Utilizzando il comando ln In WinDbg è possibile identificare quale funzione legittima è stata falsificata (ad esempio, NtQueryDirectoryFile) e cosa il malware sta cercando di nascondere (ad esempio file o directory dannosi).
Per entrambi i motivi, l'aggancio SSDT è un'arma a doppio taglio: consente l'implementazione di soluzioni di sicurezza avanzate, ma fornisce anche meccanismi altamente efficaci per l'elusione e il controllo clandestino dei sistemi.
Limitazioni, protezioni ed evoluzione dell'SSDT
Nel corso degli anni, Microsoft ha rafforzato la sicurezza della tabella per impedire che driver di terze parti o malware ne modifichino liberamente le voci. Ad esempio, con l'arrivo di Patch Guard (Kernel Patch Protection) sui sistemi x64, viene implementato il monitoraggio automatico dell'integrità SSDT e qualsiasi tentativo di alterarla al di fuori dei meccanismi consentiti finisce invariabilmente in un schianto del sistema (schermata blu).
Inoltre, le ultime versioni di Windows incoraggiano gli sviluppatori a utilizzare API e tecniche documentate anziché accedere o modificare direttamente l'SSDT, riducendo così la superficie di attacco ed evitando future incompatibilità. Tuttavia, esistono ancora scenari (analisi forense, indagine su malware, compatibilità dei driver) in cui è necessario comprenderne il funzionamento e come proteggerlo o ispezionarlo.
Differenze tra SSDT e altre tabelle di sistema
Sebbene SSDT venga spesso confuso con altre strutture descrittive di servizi o interruzioni, è importante differenziarlo, ad esempio, da Tabella dei descrittori di interruzione (IDT)Mentre SSDT gestisce le chiamate di sistema (servizi del kernel) dallo spazio utente, IDT È responsabile della risoluzione degli interrupt hardware e software che raggiungono la CPU, indirizzandoli alle routine di servizio degli interrupt (ISR) appropriate. Ognuna di esse ha una propria struttura, funzione e meccanismi di protezione, ma entrambe sono essenziali per la stabilità e la sicurezza del sistema operativo.
Scrittore appassionato del mondo dei byte e della tecnologia in generale. Adoro condividere le mie conoscenze attraverso la scrittura, ed è quello che farò in questo blog, mostrarti tutte le cose più interessanti su gadget, software, hardware, tendenze tecnologiche e altro ancora. Il mio obiettivo è aiutarti a navigare nel mondo digitale in modo semplice e divertente.