voidsec/driverbuddyreloadedDriver Buddy Reloaded è un plugin Python per IDA Pro che aiuta ad automatizzare alcuni noiosi compiti di reverse engineering dei driver del kernel di Windows.
Il metodo di installazione dipende dalla tua versione di IDA, poiché il plugin manager integrato (e quindi lo strumento hcli e il manifest ida-plugin.json) esiste solo in IDA 9.0 e versioni successive. IDA 7.6 e 8.x non hanno un plugin manager e scansionano solo il livello superiore della cartella dei plugin.
hcli)Il repository include un manifest ida-plugin.json, quindi IDA 9.0+ carica il plugin dalla propria sottodirectory. Installalo con:```
hcli plugin install DriverBuddyReloaded
This drops the plugin into a subdirectory of your user plugins folder (e.g.
`%APPDATA%\Hex-Rays\IDA Pro\plugins\DriverBuddyReloaded\` or `~/.idapro/plugins/DriverBuddyReloaded/`), keeping the
`DriverBuddyReloaded.py` entry point *inside* that subdirectory. This is the intended layout: IDA reads the manifest,
loads the declared entry point from the subdirectory, and puts the subdirectory on `sys.path` so the entry point can
import the sibling `DriverBuddyReloaded` package. You do **not** need to move `DriverBuddyReloaded.py` to the top level.
Verifica l'installazione con `hcli plugin status`, quindi avvia IDA e conferma che il plugin appaia sotto
`Edit -> Plugins` (controlla la finestra Output per eventuali errori Python all'avvio).
Per installare da un checkout locale per test (ad esempio dopo tue modifiche), esegui `hcli plugin install .` dalla
radice del repository; `hcli plugin lint .` prima convalida il manifest/layout.
### IDA 7.6 / 8.x (copia manuale)
Queste versioni non hanno un plugin manager, quindi un plugin installato via `hcli` in una sottodirectory **non** verrà riconosciuto. Copia
la cartella `DriverBuddyReloaded` e il file script `DriverBuddyReloaded.py` direttamente nel **livello superiore** della
cartella dei plugin di IDA, per esempio:
- `%APPDATA%\Hex-Rays\IDA Pro\plugins\`
- `C:\Program Files\IDA Pro 8.4\plugins\`
- `~/.idapro/plugins/`
Il layout risultante sarà `plugins\DriverBuddyReloaded.py` insieme a `plugins\DriverBuddyReloaded\` (la cartella del pacchetto).
### Note
Se il tuo IDA è configurato per Python 2, esegui il binario `idapyswitch` (situato nella cartella di IDA) per passare a Python 3.
**NOTA:** Driver Buddy Reloaded funziona su IDA 7.6+, 8.x (inclusa 8.4) e 9.0+ con Python 3. Tutte le differenze
dell'API IDA specifiche per versione (la rimozione di `get_inf_structure`, il modulo `ida_struct` e gli helper `idc.*struc*` in
IDA 9.0, ecc.) sono gestite internamente dal layer di compatibilità `DriverBuddyReloaded/ida_compat.py`.
## Utilizzo Rapido
Per utilizzare la funzionalità di analisi automatica:
1. Avvia IDA e carica un driver kernel Windows.
2. Vai a `Edit -> Plugins -> Driver Buddy Reloaded` o premi `CTRL+ALT+A` per avviare l'analisi automatica.
3. Controlla la finestra "Output" per i risultati dell'analisi, e la finestra **Driver Buddy Reloaded - Findings** che si apre
al termine dell'esecuzione (doppio click su una riga per saltare al suo indirizzo).
4. I seguenti file vengono scritti nella directory DB di IDA (tutti con prefisso `<DRIVER_NAME>-YYYY-MM-DD-TIMESTAMP-`):
- `findings.json` - risultati in formato machine-readable (IOCTL, funzioni segnalate, nomi dispositivo, pooltag, catene di chiamate, euristiche, audit ACL dispositivo, collegamenti simbolici, audit esportazioni, opcode privilegiati)
- `report.html` - un report HTML autonomo raggruppato per gravità
- `pooltags.txt` - pooltag esportati in formato `pooltags.txt` per WinDbg
- `autoanalysis.txt` - il log completo dell'analisi testuale (rispecchia la finestra Output)
Per decodificare un IOCTL:
1. Posiziona il cursore del mouse sulla riga contenente un sospetto codice IOCTL.
2. Clicca con il tasto destro e seleziona `Driver Buddy Reloaded -> Decode IOCTL`; in alternativa premi la scorciatoia `CTRL+ALT+D`.
Per riaprire la finestra degli IOCTL o la finestra dei risultati in qualsiasi momento (senza rieseguire l'analisi):
- Premi `CTRL+ALT+I` per aprire la finestra degli IOCTL.
- Premi `CTRL+ALT+F` per aprire la finestra dei risultati.
### Utilizzo Avanzato
- La directory [vulnerable_function_lists](https://github.com/voidsec/driverbuddyreloaded/blob/HEAD/DriverBuddyReloaded/vulnerable_functions_lists) contiene elenchi di funzioni
potenzialmente pericolose/problematiche, API Windows e opcode; viene fornita una breve descrizione del motivo per cui una specifica funzione/API è stata inclusa.
Puoi modificare l'elenco `custom` includendo funzioni specifiche del driver.
**Nota**: `winapi_function_prefixes` farà corrispondere parzialmente l'inizio del nome della funzione (ad es. `Zw` corrisponderà a `ZwClose`, `ZwCommitComplete` e così via) mentre `winapi_functions` eseguirà solo corrispondenze esatte.
- In [find_opcodes.py](https://github.com/voidsec/driverbuddyreloaded/blob/HEAD/DriverBuddyReloaded/find_opcodes.py), l'opzione `find_opcode_data` (default `False`)
sopprime le corrispondenze di opcode che cadono in sezioni dati
([issue #11](https://github.com/VoidSec/DriverBuddyReloaded/issues/11)). Impostandola a `True` si mostrano anche
le corrispondenze brute di byte nei dati; se un opcode reale è stato perso in questo modo, andare all'indirizzo segnalato e ridefinire
i byte come codice solitamente lo recupera. Le corrispondenze vengono segnalate come in ogni altra fase (finestra risultati,
`findings.json`, `report.html`).
**Attenzione**: impostarlo a `True` genera più falsi positivi!
## Informazioni su Driver Buddy Reloaded
**Driver Buddy Reloaded** è un plugin Python per IDA Pro che aiuta ad automatizzare alcune noiose attività di reverse engineering
dei driver del kernel Windows. Dispone di numerose funzionalità utili, tra cui:
* Identificazione del tipo di driver (WDM, KMDF, UMDF, WDF, Mini-Filter, Stream Minidriver, AVStream, PortCls)
* Individuazione delle funzioni `DispatchDeviceControl` / `DispatchInternalDeviceControl` per **ogni** tipo di driver
(una scansione dell'archivio `MajorFunction[IRP_MJ_DEVICE_CONTROL]` trova il gestore anche in un driver minifilter/WDF che espone
anche un dispositivo di controllo legacy, e anche quando l'assegnazione vive in un helper piuttosto che in `DriverEntry`)
* Popolamento delle strutture comuni per driver `WDF` e `WDM`
* Tenta di identificare ed etichettare strutture come `IRP` e `IO_STACK_LOCATION`
* Etichetta le chiamate a funzioni `WDF` che normalmente rimarrebbero senza etichetta
* Crea un enum IDA `IRP_MJ_FUNCTION` e lo applica agli slot dell'array `MajorFunction` in `DriverEntry` (WDM)
* Individuazione e decodifica dei codici IOCTL
* Scansione multi-strategia automatica delle funzioni dispatcher identificate (nessun posizionamento del cursore richiesto):
albero del decompilatore (recupera i codici nascosti da dispatch a tabella di salto o ricerca binaria che non appaiono mai come
immediati), recupero tabella di salto IDA e fallback grezzo su operandi immediati (il fallback viene eseguito solo su una
funzione che effettivamente legge l'IoControlCode dell'IRP, quindi un helper di libreria erroneamente identificato non può far trapelare le sue
costanti interne come falsi IOCTL)
* Valori NTSTATUS risolti dinamicamente dal database dei tipi IDA (con un ampio fallback hardcoded), e
gli IOCTL **in uscita** che il driver si limita a inviare a valle (`IoBuildDeviceIoControlRequest` / `ZwDeviceIoControlFile`
/ ...) vengono esclusi in modo che non vengano scambiati per la superficie d'attacco del driver stesso
* Segnalazione di funzioni soggette a uso improprio
* Individuazione potenziale di `DeviceName` (scansione mmap + fallback stringhe IDA, con indirizzo sorgente)
* Dump dei `Pooltag` (primario basato su import + fallback propagato tramite registro per tag inseriti in un registro)
* **Controlli euristici di vulnerabilità** su ciascun dispatcher e sulle funzioni che chiama transitivamente: copia
utente non convalidata, TOCTOU/double-fetch, use-after-free (intra-funzione e cross-funzione tramite globale liberato), mancanza
gate di privilegio, mismatch IRQL, mappatura MDL non sicura, buffer allocati sullo stack (`_alloca`), allocazione pool senza
convalida dimensione, istruzioni CPU privilegiate (I/O porta `in`/`out`, `mov cr*`), scrittura arbitraria
(write-what-where) e riferimenti a `\Device\PhysicalMemory` (pattern BYOVD) - vedere
[Controlli Euristici di Vulnerabilità](#controlli-euristici-di-vulnerabilità)
* **Audit ACL del dispositivo e tracciamento collegamenti simbolici**: segnala dispositivi `IoCreateDevice` creati senza
descrittore di sicurezza (accessibile a tutti) / SDDL deboli in `IoCreateDeviceSecure`, e decodifica i percorsi target di `IoCreateSymbolicLink`
* **Audit delle esportazioni**: segnala esportazioni del driver con zero riferimenti incrociati interni (potenziale superficie d'attacco)
* **Punteggio di rischio** per IOCTL decodificati (priorità a `METHOD_NEITHER` / `FILE_ANY_ACCESS`, e aumento del punteggio per un IOCTL
solo per i sink/opcode pericolosi raggiungibili dal suo **proprio** gestore del caso - `MmMapIoSpace`, `memcpy`,
`__writemsr`, I/O porta, accesso PCI-config - quindi un codice benigno in un dispatcher monolitico non viene più macchiato dal
sink pericoloso di un fratello; quando l'attribuzione è imprecisa l'aumento è limitato piuttosto che forzato a CRITICAL) e
presentazione di tutti i risultati, per gravità, in una finestra cliccabile (doppio click per saltare all'indirizzo)
* **Tracciamento delle catene di chiamate** dai gestori di dispatch / IOCTL ai sink pericolosi (euristico, basato sul nome)
* Esportazione dei risultati come file **JSON** machine-readable e report **HTML** autonomo
### Individuazione di DispatchDeviceControl
Lo strumento può individuare e identificare automaticamente la routine `DispatchDeviceControl`. Questa funzione viene utilizzata per instradare tutti
i codici `DeviceIoControl` in arrivo alla specifica funzione del driver associata a quel codice. Identificare automaticamente questa
funzione rende la ricerca dei codici `DeviceIoControl` validi per ciascun driver molto più rapida. Inoltre, quando si
investigano possibili vulnerabilità in un driver a causa di un crash, conoscere la posizione di questa funzione aiuta a restringere
il focus alla specifica chiamata di funzione associata al codice `DeviceIoControl` che ha causato il crash.
Quando l'analisi ha successo, alcune subroutine verranno rinominati come segue:
- `DriverEntry`: la prima routine fornita dal driver originale che viene chiamata dopo il caricamento di un driver. È responsabile
dell'inizializzazione del driver.
- `Real_Driver_Entry`: solitamente la funzione in cui l'esecuzione da `DriverEntry` è stata trasferita. Di solito è
dove viene inizializzato `DeviceName`.
- `DispatchDeviceControl`/`DispatchInternalDeviceControl`: se lo strumento è riuscito a recuperare le funzioni a determinati
offset, le funzioni verranno quindi rinominati con il nome appropriato.
- `Possible_DispatchDeviceControl_#`: se lo strumento non è riuscito a recuperare `DispatchDeviceControl`
o `DispatchInternalDeviceControl`, utilizza una ricerca sperimentale, seguendo il flusso di esecuzione e controllando
i casi in cui la funzione carica indirizzi noti di `IO_STACK_LOCATION` & `IRP`; indicando che la funzione
potrebbe essere DispatchDeviceControl. Poiché si basa su euristiche, potrebbe restituire più di un risultato ed è soggetta
a falsi positivi.
### Etichettatura delle Strutture WDM e WDF
Diverse strutture del driver sono condivise tra tutti i driver `WDM`/`WDF`. Lo strumento è in grado di identificare automaticamente queste
strutture, come `IO_STACK_LOCATION`, `IRP` e `DeviceObject`, e può aiutare a risparmiare tempo durante il
processo di reverse engineering e fornire contesto alle aree del driver in cui queste funzioni sono in uso.
### Individuazione e Decodifica dei Codici IOCTL
Durante il reverse engineering dei driver, è comune imbattersi in codici IOCTL come parte dell'analisi. Questi codici, una volta decodificati,
rivelano informazioni utili e possono attirare l'attenzione su parti specifiche del driver in cui è più probabile che esistano
vulnerabilità.
Facendo clic con il tasto destro su un potenziale codice IOCTL, viene presentata un'opzione del menu contestuale (in alternativa utilizzando la
scorciatoia `Ctrl+Alt+D` quando il cursore si trova sulla riga contenente un sospetto codice IOCTL) e può essere utilizzata per decodificare il
valore. Questo stamperà una tabella con tutti i codici IOCTL decodificati. Facendo clic con il tasto destro su un codice IOCTL decodificato, nella vista
disassembly, è possibile contrassegnarlo come non valido; questo lascerà intatto qualsiasi commento non IOCTL.
- Gli IOCTL decodificati vengono stampati nella finestra Output ed elencati nella finestra IOCTL colorata per gravità; dopo
l'analisi automatica vengono anche registrati in `findings.json` / `report.html`.
L'analisi automatica esegue inoltre una scansione multi-strategia sulle funzioni dispatcher identificate per scoprire IOCTL
automaticamente, senza richiedere il posizionamento manuale del cursore. Per ciascun dispatcher utilizza il decompilatore Hex-Rays
(se disponibile) per leggere le etichette dei casi switch e le costanti di confronto `==`/`!=` direttamente dal flusso
di controllo ricostruito, ricorrendo ai metadati della tabella di salto di IDA e quindi a una scansione grezza degli operandi immediati. Il
percorso del decompilatore recupera codici che non appaiono mai alla lettera nel disassembly - ad esempio driver il cui dispatcher
il compilatore ha emesso come tabella di salto (solo la base/limite della tabella sopravvivono come immediati) o come albero
di confronto di ricerca binaria (i codici intermedi sopravvivono solo come delta). Su un corpus rappresentativo, questo ha aumentato il recupero
da 7/28 a 28/28 (HEVD) e da 4/17 a 17/17 (ALSysIO64) senza falsi positivi.
### Segnalazione di Funzioni
Driver Buddy Reloaded dispone di elenchi di funzioni C/C++, opcode e API Windows (definite in
la directory [vulnerable_function_lists](https://github.com/voidsec/driverbuddyreloaded/blob/HEAD/DriverBuddyReloaded/vulnerable_functions_lists)) che sono comunemente vulnerabili
o che possono facilitare condizioni di buffer overflow. Tutte le istanze trovate vengono riportate durante l'analisi automatica e
possono aiutare durante la ricerca di percorsi di codice controllabili dall'utente che raggiungono funzioni sensibili.
### Individuazione del DeviceName
Lo strumento tenta automaticamente di trovare i percorsi di dispositivo registrati dal driver (`DeviceName`). Se non è possibile trovare percorsi
cercando stringhe Unicode all'interno del binario, l'analista può provare manualmente a utilizzare
Madiant's [FLOSS](https://github.com/mandiant/flare-floss/) nel tentativo di trovare percorsi offuscati.
### Dump dei Pooltag
Durante l'analisi automatica, lo strumento esegue anche il dump dei `Pooltag` utilizzati dal binario in un formato che funziona
con `pooltags.txt`. L'output può quindi essere copiato e incollato alla fine del file e successivamente raccolto da WinDbg.
- Un file `DriverName.sys-DATE-TIME_STAMP-pooltags.txt`, contenente tutti i Pooltag esportati, verrà scritto sotto
la directory DB di IDA.
### Controlli Euristici di Vulnerabilità
Il modulo `heuristics.py` viene eseguito dopo il tracciamento della catena di chiamate ed esamina ciascun dispatcher **e le funzioni che
chiama transitivamente** - quindi vengono analizzati i gestori per-IOCTL, non solo il prologo del dispatcher. La corrispondenza
del chiamato è consapevole degli import (un `call cs:__imp_<Nome>` importato corrisponde allo stesso nome di una chiamata locale). Emette risultati nella
categoria **heuristic** (i risultati delle istruzioni privilegiate utilizzano la categoria **opcode**):
| Controllo | Cosa viene segnalato | Gravità |
|---|---|---|
| Copia utente non convalidata | `memcpy`/`RtlCopyMemory`/ecc. senza `ProbeForRead`/`ProbeForWrite`/guardia stringa sicura nelle vicinanze | ALTA (handler), MEDIA (altro) |
| TOCTOU / double fetch | un puntatore in modalità utente riletto su un percorso di flusso di controllo senza `ProbeForRead` intermedio (solo su handler METHOD_NEITHER, quindi le riletture di buffer kernel non vengono segnalate) | MEDIA |
| Use-after-free | un puntatore liberato riutilizzato all'interno della funzione (walk del grafo dei registri), o un globale liberato senza essere azzerato e poi dereferenziato da un'altra funzione | ALTA |
| Mancanza gate di privilegio | un'operazione sensibile (`ZwOpenProcess`/`MmMapIoSpace`/PCI-config/ecc.) raggiungibile da un dispatcher senza `SeAccessCheck`/`SeSinglePrivilegeCheck`/controllo token da nessuna parte sul percorso | ALTA |
| Mismatch IRQL | chiamata Pageable / `Zw*` / `MmMap*` quando è presente anche una funzione che aumenta l'IRQL | MEDIA |
| Mappatura MDL non sicura | `MmMapLockedPages`/`MmProbeAndLockPages`/ecc. con `UserMode` nel disassembly | ALTA, altrimenti MEDIA |
| Allocazione sullo stack | chiamata `_alloca`/`_malloca`/`_chkstk` (allocazione stack grande o dinamica) | BASSA |
| Allocazione pool senza convalida dimensione | chiamata `ExAllocatePool*` senza guardia aritmetica sicura nelle vicinanze (pattern integer-overflow-before-alloc) | ALTA |
| Istruzione privilegiata | I/O porta (`in`/`out`), spostamento registro di controllo/debug (`mov cr*`/`mov dr*`), caricamento tabella descrittori, `cli`/`sti`/`hlt` raggiungibile da un handler (primitiva di accesso hardware BYOVD) | CRITICAL (`out`) / ALTA (`in`) / MEDIA |
| Scrittura arbitraria (write-what-where) | un'archiviazione attraverso un puntatore utente doppiamente dereferenziato `*(*p) = c`; una copia controllata `*p = *q` viene segnalata come lead più debole | ALTA / MEDIA |
| Riferimento a `\Device\PhysicalMemory` | Riferimento incrociato alla stringa dell'oggetto dispositivo di memoria fisica (pattern BYOVD tramite `ZwOpenSection`/`ZwMapViewOfSection`) | ALTA (handler), MEDIA (altro) |
Questi sono **generatori di lead**, non vulnerabilità confermate. Tratta i risultati ALTI/CRITICI come punti di partenza per
la revisione manuale.
## Flag delle Funzionalità
Tutte le fasi opzionali dell'analisi sono controllate da `DriverBuddyReloaded/config.py`. Modifica la classe `Feature` per
abilitarle o disabilitarle:
| Flag | Default | Descrizione |
|---|---|---|
| `IOCTL_SCAN` | `True` | Scopri e decodifica IOCTL (scansione dispatcher + fallback `IoControlCode`) |
| `IOCTL_DECOMPILER` | `True` | Usa l'albero del decompilatore Hex-Rays nella scansione dispatcher (recupera i codici di tabella di salto / ricerca binaria) |
| `HEURISTICS` | `True` | Controlli euristici di vulnerabilità (vedi tabella sopra) |
| `TOCTOU_CHECK` | `True` | Euristica double-fetch / TOCTOU |
| `UAF_DETECT` | `True` | Euristiche use-after-free (walk registro intra-funzione + globale cross-funzione) |
| `ACL_AUDIT` | `True` | Segnala `IoCreateDevice` accessibile a tutti / SDDL debole in `IoCreateDeviceSecure` |
| `SYMLINK_TRACK` | `True` | Decodifica i percorsi target di `IoCreateSymbolicLink` |
| `CALLCHAIN` | `True` | Tracciamento BFS della catena di chiamate dagli handler ai sink pericolosi |
| `EXPORTS_AUDIT` | `True` | Segnala esportazioni del driver con zero riferimenti incrociati interni |
| `POOLTAG_FALLBACK` | `True` | Scanner pool tag propagato tramite registro (usato quando la scansione basata su import non trova nulla) |
| `IRP_MJ_ENUM` | `True` | Crea enum IDA `IRP_MJ_FUNCTION` e applica agli slot `MajorFunction` (solo WDM) |
| `RISK_SCORING` | `True` | Punteggio di rischio IOCTL (pesi METHOD/ACCESS + aumento sink per handler) |
| `RESULTS_WINDOW` | `True` | Mostra la finestra dei risultati di Driver Buddy Reloaded dopo l'analisi |
| `JSON_EXPORT` | `True` | Scrivi `findings.json` |
| `HTML_REPORT` | `True` | Scrivi `report.html` |
| `SEGMENT_OPCODE_SCAN` | `False` | Scansione lineare opcode sull'intero segmento (rumorosa, disattivata per impostazione predefinita) |
## Test
Tre livelli, dal veloce al approfondito:
- **Regressione puramente Python** (non richiede IDA) - copre tutta la logica che non tocca il database live: ```
python tests/test_dbr.py
DBR_SDK=900 python tests/test_dbr.py # simulate the IDA 9.0 import paths
.sys reali e stampa una tabella pass/fail: pwsh tests/run_cross_version.ps1.pwsh tests/run_golden.ps1 riesegue l’analisi completa su una copia pulita di ogni driver di riferimento in tests/drivers/ e confronta i risultati con la baseline tests/drivers/<driver>.golden.json committata (senza distinzione di ordine per categoria, titolo, gravità e codice/metodo/accesso IOCTL). Qualsiasi risultato aggiunto (falso positivo), mancante (falso negativo) o cambio di gravità fa fallire l’esecuzione. Rigenera un golden solo quando una modifica altera intenzionalmente i risultati e rivedi il diff. I golden sono legati alla build del decompilatore IDA con cui sono stati catturati (8.4), quindi esegui la regressione con quella versione.CTL_CODE mediante _is_valid_ctl_code(): il campo DeviceType (bit 31‑16) deve essere diverso da zero e il valore non deve corrispondere a un codice NTSTATUS noto né al sentinella 0xFFFFFFFF (DWORD)-1 (una costante di confronto vista all’interno di dispatcher reali, ad es. WinRing0). Ciò esclude contatori di loop, immediati piccoli e codici di errore, preservando tutti gli IOCTL validi, inclusi i tipi di dispositivo definiti dal vendor (0x8000+). Lo stesso filtro viene applicato a tutti e quattro i percorsi di scoperta: la scansione dei cross‑riferimenti a IoControlCode e i tre collettori dei dispatcher (ctree del decompilatore, recovery della tabella switch di IDA e scansione grezza degli operandi immediati).DriverBuddyReloaded/config.py.DispatchDeviceControl funziona solo per driver x64.find_opcode_data (default ) sopprime le corrispondenze di opcode che cadono in sezioni dati. Impostandola a vengono mostrate anche le corrispondenze grezze di byte nei dati, il che è soggetto a falsi positivi; se un opcode reale è stato perso, andare all’indirizzo segnalato e ridefinire i byte come codice di solito lo recupera. Le corrispondenze vengono riportate come in ogni altra fase (finestra dei risultati, , ).FalseTruefindings.jsonreport.html