voidsec/driverbuddyreloadedDriver Buddy Reloaded ist ein IDA Pro Python-Plugin, das hilft, einige mühsame Reverse-Engineering-Aufgaben von Windows-Kernel-Treibern zu automatisieren.
Die Installationsmethode hängt von Ihrer IDA-Version ab, da der integrierte Plugin-Manager (und damit das hcli-Tool und das ida-plugin.json Manifest) nur in IDA 9.0 und höher existiert. IDA 7.6 und 8.x haben keinen Plugin-Manager und durchsuchen nur die oberste Ebene des Plugin-Ordners.
hcli)Das Repository enthält ein ida-plugin.json Manifest, sodass IDA 9.0+ das Plugin aus seinem eigenen Unterverzeichnis lädt. Installieren Sie es mit:```
hcli plugin install DriverBuddyReloaded
Dies legt das Plugin in ein Unterverzeichnis Ihres Benutzer-Plugins-Ordners (z.B.
`%APPDATA%\Hex-Rays\IDA Pro\plugins\DriverBuddyReloaded\` oder `~/.idapro/plugins/DriverBuddyReloaded/`), wobei der Einstiegspunkt `DriverBuddyReloaded.py` *innerhalb* dieses Unterverzeichnisses bleibt. Dies ist das beabsichtigte Layout: IDA liest das Manifest, lädt den deklarierten Einstiegspunkt aus dem Unterverzeichnis und fügt das Unterverzeichnis zu `sys.path` hinzu, sodass der Einstiegspunkt das benachbarte Paket `DriverBuddyReloaded` importieren kann. Sie müssen `DriverBuddyReloaded.py` **nicht** in die oberste Ebene verschieben.
Überprüfen Sie die Installation mit `hcli plugin status`, starten Sie dann IDA und bestätigen Sie, dass das Plugin unter `Edit -> Plugins` erscheint (überprüfen Sie das Ausgabefenster auf etwaige Python-Fehler beim Start).
Um aus einem lokalen Checkout zu Testzwecken zu installieren (z.B. nach eigenen Änderungen), führen Sie `hcli plugin install .` vom Repository-Stammverzeichnis aus; `hcli plugin lint .` validiert zuerst das Manifest/Layout.
### IDA 7.6 / 8.x (manuelles Kopieren)
Diese Versionen haben keinen Plugin-Manager, daher wird ein per `hcli` installiertes Unterverzeichnis-Plugin **nicht** erkannt. Kopieren Sie den Ordner `DriverBuddyReloaded` und die Skriptdatei `DriverBuddyReloaded.py` direkt in die **oberste Ebene** des IDA-Plugins-Ordners, zum Beispiel:
- `%APPDATA%\Hex-Rays\IDA Pro\plugins\`
- `C:\Program Files\IDA Pro 8.4\plugins\`
- `~/.idapro/plugins/`
Das resultierende Layout ist `plugins\DriverBuddyReloaded.py` zusammen mit `plugins\DriverBuddyReloaded\` (dem Paketordner).
### Hinweise
Wenn Ihre IDA für Python 2 konfiguriert ist, führen Sie die Binärdatei `idapyswitch` (im IDA-Ordner) aus, um auf Python 3 umzustellen.
**HINWEIS:** Driver Buddy Reloaded läuft auf IDA 7.6+, 8.x (einschließlich 8.4) und 9.0+ mit Python 3. Alle versionsspezifischen IDA-API-Unterschiede (die Entfernung von `get_inf_structure`, des `ida_struct`-Moduls und der `idc.*struc*`-Helfer in IDA 9.0 usw.) werden intern von der Kompatibilitätsschicht `DriverBuddyReloaded/ida_compat.py` behandelt.
## Kurzanleitung
So verwenden Sie die Autoanalyse-Funktion:
1. Starten Sie IDA und laden Sie einen Windows-Kernel-Treiber.
2. Gehen Sie zu `Edit -> Plugins -> Driver Buddy Reloaded` oder drücken Sie `CTRL+ALT+A`, um die Autoanalyse zu starten.
3. Überprüfen Sie das "Output"-Fenster auf die Analyseergebnisse und das **Driver Buddy Reloaded - Findings**-Fenster, das am Ende des Durchlaufs geöffnet wird (doppelklicken Sie auf eine Zeile, um zu ihrer Adresse zu springen).
4. Die folgenden Dateien werden im DB-Verzeichnis von IDA geschrieben (alle mit `<DRIVER_NAME>-YYYY-MM-DD-TIMESTAMP-` beginnend):
- `findings.json` - maschinenlesbare Ergebnisse (IOCTLs, markierte Funktionen, Gerätenamen, Pooltags, Call-Chains, Heuristiken, Geräte-ACL-Prüfung, symbolische Links, Exports-Prüfung, privilegierte Opcodes)
- `report.html` - ein eigenständiger, nach Schweregrad gruppierter HTML-Bericht
- `pooltags.txt` - ausgegebene Pooltags im `pooltags.txt`-Format für WinDbg
- `autoanalysis.txt` - das vollständige Textanalyseprotokoll (spiegelt das Ausgabefenster wider)
So decodieren Sie einen IOCTL:
1. Platzieren Sie den Mauszeiger auf der Zeile, die einen vermuteten IOCTL-Code enthält.
2. Klicken Sie mit der rechten Maustaste und wählen Sie `Driver Buddy Reloaded -> Decode IOCTL`; alternativ drücken Sie die Tastenkombination `CTRL+ALT+D`.
Um das IOCTLs-Fenster oder das Findings-Fenster jederzeit wieder zu öffnen (ohne die Analyse erneut auszuführen):
- Drücken Sie `CTRL+ALT+I`, um das IOCTLs-Fenster zu öffnen.
- Drücken Sie `CTRL+ALT+F`, um das Findings-Fenster zu öffnen.
### Erweiterte Nutzung
- Das Verzeichnis [vulnerable_function_lists](https://github.com/voidsec/driverbuddyreloaded/blob/HEAD/DriverBuddyReloaded/vulnerable_functions_lists) enthält Listen potenziell gefährlicher/problembehafteter Funktionen, Windows-APIs und Opcodes; eine kurze Beschreibung, warum eine bestimmte Funktion/API aufgelistet wurde, wird bereitgestellt. Sie können die `custom`-Liste bearbeiten, die treiberspezifische Funktionen enthalten kann.
**Hinweis**: `winapi_function_prefixes` führt eine partielle Übereinstimmung am Anfang des Funktionsnamens durch (z.B. passt `Zw` auf `ZwClose`, `ZwCommitComplete` usw.), während `winapi_functions` nur exakte Übereinstimmungen durchführt.
- In [find_opcodes.py](https://github.com/voidsec/driverbuddyreloaded/blob/HEAD/DriverBuddyReloaded/find_opcodes.py) unterdrückt die Option `find_opcode_data` (Standard `False`) Opcode-Übereinstimmungen, die in Datenabschnitte fallen ([Issue #11](https://github.com/VoidSec/DriverBuddyReloaded/issues/11)). Wenn Sie sie auf `True` setzen, werden auch rohe Byte-Übereinstimmungen in Daten sichtbar; falls auf diese Weise ein echter Opcode übersehen wurde, kann er in der Regel wiederhergestellt werden, indem Sie zur gemeldeten Adresse gehen und die Bytes als Code neu definieren. Übereinstimmungen werden wie jede andere Stufe gemeldet (Ergebnisfenster, `findings.json`, `report.html`).
**Achtung**: Wenn Sie es auf `True` setzen, werden mehr Fehlalarme generiert!
## Über Driver Buddy Reloaded
**Driver Buddy Reloaded** ist ein IDA Pro Python-Plugin, das hilft, einige mühsame Reverse-Engineering-Aufgaben für Windows-Kernel-Treiber zu automatisieren. Es bietet eine Reihe praktischer Funktionen, wie zum Beispiel:
* Identifizieren des Treibertyps (WDM, KMDF, UMDF, WDF, Mini-Filter, Stream Minidriver, AVStream, PortCls)
* Lokalisieren der `DispatchDeviceControl`- / `DispatchInternalDeviceControl`-Funktionen für **jeden** Treibertyp (ein `MajorFunction[IRP_MJ_DEVICE_CONTROL]`-Store-Scan findet den Handler selbst in einem Minifilter/WDF-Treiber, der auch ein Legacy-Steuergerät bereitstellt, und selbst wenn die Zuweisung in einem Helfer und nicht in `DriverEntry` lebt)
* Befüllen gemeinsamer Strukturen für `WDF`- und `WDM`-Treiber
* Versucht, Strukturen wie die `IRP` und `IO_STACK_LOCATION` zu identifizieren und zu beschriften
* Beschriftet Aufrufe von `WDF`-Funktionen, die normalerweise unbeschriftet wären
* Erstellt einen IDA-Enum `IRP_MJ_FUNCTION` und wendet ihn auf die `MajorFunction`-Array-Slots in `DriverEntry` an (WDM)
* Finden und Decodieren von IOCTL-Codes
* Automatischer Multi-Strategie-Scan identifizierter Dispatcher-Funktionen (keine Cursorplatzierung erforderlich): Decompiler ctree (stellt Codes wieder her, die durch Jump-Table- oder Binary-Search-Dispatch versteckt sind und nie als Immediates erscheinen), IDA-Switch-Table-Recovery und einen rohen Immediate-Operanden-Fallback (der Fallback läuft nur auf einer Funktion, die tatsächlich das IoControlCode des IRP liest, sodass ein falsch identifizierter Bibliothekshelfer seine internen Konstanten nicht als falsche IOCTLs durchsickern lassen kann)
* NTSTATUS-Werte werden dynamisch aus der IDA-Typdatenbank aufgelöst (mit einem breiten hartcodierten Fallback), und **ausgehende** IOCTLs, die der Treiber lediglich nachgelagert sendet (`IoBuildDeviceIoControlRequest` / `ZwDeviceIoControlFile` / ...), werden ausgeschlossen, damit sie nicht mit der eigenen Angriffsfläche des Treibers verwechselt werden
* Markieren von Funktionen, die zu Fehlgebrauch neigen
* Finden potenzieller `DeviceName` (mmap-Scan + IDA Strings DB Fallback, mit Quelladresse)
* Ausgeben von `Pooltags` (importbasierter Primär-Scan + register-propagierter Fallback für Tags, die in einem Register zwischengespeichert sind)
* **Heuristische Sicherheitsprüfungen** für jeden Dispatcher und die von ihm transitiv aufgerufenen Funktionen: nicht validierte Benutzerkopie, TOCTOU/Double-Fetch, Use-After-Free (intra-funktional und cross-funktional über einen freigegebenen Globalen), fehlendes Privilegientor, IRQL-Konflikt, unsicheres MDL-Mapping, stack-allocierte Puffer (`_alloca`), Pool-Allokation ohne Größenvalidierung, privilegierte CPU-Anweisungen (Port-I/O `in`/`out`, `mov cr*`), beliebiges Schreiben (Write-What-Where) und `\Device\PhysicalMemory`-Referenzen (BYOVD-Muster) - siehe [Heuristische Sicherheitsprüfungen](#heuristic-vulnerability-checks)
* **Geräte-ACL-Prüfung und Symbolic-Link-Tracking**: markiert `IoCreateDevice`-Geräte, die ohne Sicherheitsdeskriptor (weltweit zugänglich) / mit schwachen `IoCreateDeviceSecure`-SDDLs erstellt wurden, und decodiert Zielpfade von `IoCreateSymbolicLink`
* **Exports-Prüfung**: markiert Treiber-Exporte ohne interne Cross-Referenzen (potenzielle Angriffsfläche)
* **Risikobewertung** decodierter IOCTLs pro IOCTL (Priorisierung von `METHOD_NEITHER` / `FILE_ANY_ACCESS`, und Erhöhung eines IOCTL nur für die gefährlichen Sinks/Opcodes, die von seinem **eigenen** Case-Handler erreichbar sind – `MmMapIoSpace`, `memcpy`, `__writemsr`, Port-I/O, PCI-Config-Zugriff – sodass ein harmloser Code in einem monolithischen Dispatcher nicht mehr mit den Sinks eines gefährlichen Geschwisterteils in Verbindung gebracht wird; wenn die Zuordnung ungenau ist, wird die Erhöhung gedeckelt und nicht auf KRITISCH erzwungen) und Präsentation aller Ergebnisse, nach Schweregrad, in einem anklickbaren Ergebnisfenster (Doppelklick, um zur Adresse zu springen)
* **Verfolgen von Call-Chains** von Dispatch-/IOCTL-Handlern zu gefährlichen Sinks (heuristisch, namensbasiert)
* Exportieren der Ergebnisse als maschinenlesbare **JSON**-Datei und einen eigenständigen **HTML**-Bericht
### Finden von DispatchDeviceControl
Das Tool kann die `DispatchDeviceControl`-Routine automatisch lokalisieren und identifizieren. Diese Funktion wird verwendet, um alle eingehenden `DeviceIoControl`-Codes an die spezifische Treiberfunktion weiterzuleiten, die mit diesem Code verbunden ist. Die automatische Identifizierung dieser Funktion macht das Finden der gültigen `DeviceIoControl`-Codes für jeden Treiber viel schneller. Darüber hinaus hilft die Kenntnis der Position dieser Funktion bei der Untersuchung möglicher Schwachstellen in einem Treiber aufgrund eines Absturzes, den Fokus auf den spezifischen Funktionsaufruf zu legen, der mit dem abstürzenden `DeviceIoControl`-Code verbunden ist.
Bei erfolgreicher Analyse werden einige Subs wie folgt umbenannt:
- `DriverEntry`: die ursprüngliche erste treiberbereitgestellte Routine, die nach dem Laden eines Treibers aufgerufen wird. Sie ist für die Initialisierung des Treibers verantwortlich.
- `Real_Driver_Entry`: normalerweise die Funktion, an die die Ausführung von `DriverEntry` übergeben wurde. Hier wird normalerweise der `DeviceName` initialisiert.
- `DispatchDeviceControl`/`DispatchInternalDeviceControl`: wenn das Tool in der Lage war, die Funktionen an bestimmten Offsets wiederherzustellen, werden die Funktionen dann mit dem entsprechenden Namen umbenannt.
- `Possible_DispatchDeviceControl_#`: wenn das Tool `DispatchDeviceControl` oder `DispatchInternalDeviceControl` nicht wiederherstellen konnte, verwendet es eine experimentelle Suche, die dem Ausführungsfluss folgt und nach Fällen sucht, in denen die Funktion bekannte `IO_STACK_LOCATION`- und `IRP`-Adressen lädt; dies deutet darauf hin, dass die Funktion der DispatchDeviceControl sein könnte. Da es auf Heuristiken basiert, kann es mehr als ein Ergebnis zurückgeben und ist anfällig für Fehlalarme.
### Beschriften von WDM- und WDF-Strukturen
Mehrere Treiberstrukturen werden von allen `WDM`/`WDF`-Treibern gemeinsam genutzt. Das Tool kann diese Strukturen automatisch identifizieren, wie z.B. die `IO_STACK_LOCATION`-, `IRP`- und `DeviceObject`-Strukturen, und kann helfen, Zeit während des Reverse-Engineering-Prozesses zu sparen und Kontext für Bereiche des Treibers zu liefern, in denen diese Funktionen verwendet werden.
### Finden und Decodieren von IOCTL-Codes
Beim Reverse-Engineering von Treibern ist es üblich, im Rahmen der Analyse auf IOCTL-Codes zu stoßen. Diese Codes geben, wenn sie decodiert werden, nützliche Informationen preis und können den Fokus auf bestimmte Teile des Treibers lenken, in denen Schwachstellen wahrscheinlicher sind.
Durch Rechtsklick auf einen potenziellen IOCTL-Code wird eine Kontextmenüoption angezeigt (alternativ mit der Tastenkombination `Ctrl+Alt+D`, wenn der Cursor auf der Zeile mit einem vermuteten IOCTL-Code steht), mit der der Wert decodiert werden kann. Dadurch wird eine Tabelle mit allen decodierten IOCTL-Codes ausgegeben. Durch Rechtsklick auf einen decodierten IOCTL-Code in der Disassembly-Ansicht kann er als ungültig markiert werden; dadurch bleiben alle Nicht-IOCTL-Kommentare erhalten.
- Die decodierten IOCTLs werden im Ausgabefenster ausgegeben und im farbcodierten IOCTLs-Fenster aufgelistet; nach der Autoanalyse werden sie auch in `findings.json` / `report.html` aufgezeichnet.
Die Autoanalyse führt zusätzlich einen Multi-Strategie-Scan über identifizierte Dispatcher-Funktionen durch, um IOCTLs automatisch zu entdecken, ohne dass eine manuelle Cursorplatzierung erforderlich ist. Für jeden Dispatcher verwendet es den Hex-Rays-Decompiler (wenn verfügbar), um Switch-Case-Labels und `==`-/`!=`-Vergleichskonstanten direkt aus dem rekonstruierten Kontrollfluss zu lesen, und fällt auf IDAs Switch-Table-Metadaten und dann auf einen rohen Immediate-Operanden-Scan zurück. Der Decompiler-Pfad stellt Codes wieder her, die nie wörtlich in der Disassembly erscheinen – z.B. Treiber, deren Dispatcher der Compiler als Sprungtabelle emittiert hat (nur die Tabellenbasis/-grenze überlebt als Immediates) oder als Binary-Search-Vergleichsbaum (Zwischencodes überleben nur als Deltas). In einem repräsentativen Korpus erhöhte dies die Wiederherstellung von 7/28 auf 28/28 (HEVD) und von 4/17 auf 17/17 (ALSysIO64) ohne Fehlalarme.
### Markieren von Funktionen
Driver Buddy Reloaded enthält Listen von C/C++-Funktionen, Opcodes und Windows-APIs (definiert im Verzeichnis [vulnerable_function_lists](https://github.com/voidsec/driverbuddyreloaded/blob/HEAD/DriverBuddyReloaded/vulnerable_functions_lists)), die häufig anfällig sind oder Pufferüberlaufbedingungen begünstigen können. Alle gefundenen Instanzen werden während der Autoanalyse gemeldet und können bei der Suche nach möglichen benutzergesteuerten Codepfaden helfen, die zu sensiblen Funktionen führen.
### Finden von DeviceName
Das Tool versucht automatisch, die registrierten Gerätepfade (`DeviceName`) des Treibers zu finden. Wenn keine Pfade durch Suchen nach Unicode-Strings innerhalb der Binärdatei gefunden werden können, kann der Analyst manuell versuchen, Madiants [FLOSS](https://github.com/mandiant/flare-floss/) zu verwenden, um obfuskierte Pfade zu finden.
### Ausgeben von Pooltags
Während der Autoanalyse gibt das Tool auch die von der Binärdatei verwendeten `Pooltags` in einem Format aus, das mit `pooltags.txt` funktioniert. Die Ausgabe kann dann am Ende der Datei kopiert und später von WinDbg übernommen werden.
- Eine Datei `DriverName.sys-DATE-TIME_STAMP-pooltags.txt`, die alle ausgegebenen Pooltags enthält, wird im DB-Verzeichnis von IDA geschrieben.
### Heuristische Sicherheitsprüfungen
Das Modul `heuristics.py` wird nach der Call-Chain-Verfolgung ausgeführt und untersucht jeden Dispatcher **und die von ihm transitiv aufgerufenen Funktionen** – es werden also die pro-IOCTL-Handler und nicht nur der Dispatcher-Prolog analysiert. Die Callee-Erkennung ist importbewusst (ein importierter `call cs:__imp_<Name>` stimmt mit demselben Namen wie ein lokaler Aufruf überein). Es gibt Ergebnisse in der Kategorie **heuristic** aus (Ergebnisse zu privilegierten Anweisungen verwenden die Kategorie **opcode**):
| Check | Was wird gemeldet | Schweregrad |
|---|---|---|
| Nicht validierte Benutzerkopie | `memcpy`/`RtlCopyMemory`/usw. ohne nahegelegene `ProbeForRead`/`ProbeForWrite`/Safe-String-Überprüfung | HOCH (Handler), MITTEL (andere) |
| TOCTOU / Double Fetch | erneutes Lesen eines Benutzermodus-Zeigerfelds auf einem Kontrollflusspfad ohne dazwischenliegende `ProbeForRead` (nur bei METHOD_NEITHER-Handlern, sodass Kernel-Puffer-Nachlesen nicht markiert werden) | MITTEL |
| Use-after-free | ein freigegebener Zeiger, der intra-funktional wiederverwendet wird (Register-CFG-Walk), oder ein globaler Zeiger, der freigegeben wurde, ohne auf Null gesetzt zu werden, und dann von einer anderen Funktion dereferenziert wird | HOCH |
| Fehlendes Privilegientor | eine sensible Operation (`ZwOpenProcess`/`MmMapIoSpace`/PCI-Konfiguration/usw.), die von einem Dispatcher erreichbar ist, ohne dass irgendwo auf dem Pfad eine `SeAccessCheck`/`SeSinglePrivilegeCheck`/Token-Überprüfung vorhanden ist | HOCH |
| IRQL-Konflikt | Aufruf von paginierbaren / `Zw*` / `MmMap*`-Funktionen, wenn auch eine IRQL-erhöhende Funktion vorhanden ist | MITTEL |
| Unsicheres MDL-Mapping | `MmMapLockedPages`/`MmProbeAndLockPages`/usw. mit `UserMode` in der Disassembly | HOCH, sonst MITTEL |
| Stack-Allokation | `_alloca`/`_malloca`/`_chkstk`-Aufruf (große oder dynamische Stack-Allokation) | NIEDRIG |
| Pool-Allokation ohne Größenvalidierung | `ExAllocatePool*`-Aufruf ohne nahegelegene sichere arithmetische Überprüfung (Integer-Überlauf-vor-Allokation-Muster) | HOCH |
| Privilegierte Anweisung | Port-I/O (`in`/`out`), Steuer-/Debug-Register-Verschiebung (`mov cr*`/`mov dr*`), Descriptor-Table-Load, `cli`/`sti`/`hlt` von einem Handler erreichbar (BYOVD-Hardwarezugriffs-Primitive) | KRITISCH (`out`) / HOCH (`in`) / MITTEL |
| Beliebiges Schreiben (Write-What-Where) | ein Speicherzugriff über einen doppelt dereferenzierten Benutzerzeiger `*(*p) = c`; eine kontrollierte Kopie `*p = *q` wird als schwächerer Hinweis gemeldet | HOCH / MITTEL |
| `\Device\PhysicalMemory`-Referenz | Cross-Referenz auf den Zeichenfolgenstring des physischen Speichergeräteobjekts (BYOVD-Muster über `ZwOpenSection`/`ZwMapViewOfSection`) | HOCH (Handler), MITTEL (andere) |
Dies sind **Hinweisgeneratoren**, keine bestätigten Schwachstellen. Behandeln Sie HOHE/KRITISCHE Ergebnisse als Ausgangspunkte für die manuelle Überprüfung.
## Feature-Flags
Alle optionalen Analysestufen werden durch `DriverBuddyReloaded/config.py` gesteuert. Bearbeiten Sie die Klasse `Feature`, um sie zu aktivieren oder zu deaktivieren:
| Flag | Standard | Beschreibung |
|---|---|---|
| `IOCTL_SCAN` | `True` | IOCTLs entdecken & decodieren (Dispatcher-Scan + `IoControlCode`-Fallback) |
| `IOCTL_DECOMPILER` | `True` | Hex-Rays ctree im Dispatcher-Scan verwenden (stellt Sprungtabellen-/Binary-Search-Codes wieder her) |
| `HEURISTICS` | `True` | Heuristische Sicherheitsprüfungen (siehe Tabelle oben) |
| `TOCTOU_CHECK` | `True` | Double-Fetch / TOCTOU-Heuristik |
| `UAF_DETECT` | `True` | Use-after-free-Heuristiken (intra-funktionaler Register-Walk + cross-funktionaler Globaler) |
| `ACL_AUDIT` | `True` | Markieren von weltweit zugänglichen `IoCreateDevice`-Geräten / schwachen `IoCreateDeviceSecure`-SDDLs |
| `SYMLINK_TRACK` | `True` | Decodieren von Zielpfaden von `IoCreateSymbolicLink` |
| `CALLCHAIN` | `True` | BFS-Call-Chain-Verfolgung von Handlern zu gefährlichen Sinks |
| `EXPORTS_AUDIT` | `True` | Markieren von Treiber-Exporten ohne interne Cross-Referenzen |
| `POOLTAG_FALLBACK` | `True` | Register-propagierter Pooltag-Scanner (verwendet, wenn der importbasierte Scan nichts findet) |
| `IRP_MJ_ENUM` | `True` | IDA-Enum `IRP_MJ_FUNCTION` erstellen und auf `MajorFunction`-Slots anwenden (nur WDM) |
| `RISK_SCORING` | `True` | IOCTL-Risikobewertung (METHOD/ACCESS-Gewichtungen + per-Handler-Sink-Erhöhung) |
| `RESULTS_WINDOW` | `True` | Driver Buddy Reloaded-Ergebnisfenster nach der Analyse anzeigen |
| `JSON_EXPORT` | `True` | `findings.json` schreiben |
| `HTML_REPORT` | `True` | `report.html` schreiben |
| `SEGMENT_OPCODE_SCAN` | `False` | Linearer segmentweiter Opcode-Scan (verrauscht, standardmäßig aus) |
## Testen
Drei Ebenen, von schnell bis gründlich:
- **Reine Python-Regression** (keine IDA erforderlich) - deckt die gesamte Logik ab, die nicht die Live-Datenbank berührt: ```
python tests/test_dbr.py
DBR_SDK=900 python tests/test_dbr.py # simulate the IDA 9.0 import paths
.sys-Dateien aus und gibt eine Bestehen/Fehlschlag-Tabelle aus: pwsh tests/run_cross_version.ps1.pwsh tests/run_golden.ps1 führt die vollständige Analyse auf einer unveränderten Kopie jedes Referenztreibers in tests/drivers/ erneut aus und vergleicht die Ergebnisse mit der festgeschriebenen Basislinie tests/drivers/<driver>.golden.json (reihenfolgeunabhängig bezüglich Kategorie, Titel, Schweregrad und IOCTL-Code/-Methode/-Zugriff). Jeder hinzugekommene Befund (falsch positiv), fehlender Befund (falsch negativ) oder Änderung des Schweregrads führt zum Fehlschlagen des Durchlaufs. Ein Golden sollte nur neu generiert werden, wenn eine Änderung absichtlich die Befunde verändert, und das Diff sollte überprüft werden. Goldens sind an die IDA Decompiler-Build gebunden, mit der sie erstellt wurden (8.4), daher sollte die Regression mit dieser Version ausgeführt werden.CTL_CODE-Struktur durch _is_valid_ctl_code() validiert: Das DeviceType-Feld (Bits 31-16) muss ungleich Null sein, und der Wert darf weder einem bekannten NTSTATUS-Code noch dem Sentinel 0xFFFFFFFF (DWORD)-1 entsprechen (eine Vergleichskonstante, die in echten Dispatchern vorkommt, z. B. WinRing0). Dadurch werden Schleifenzähler, kleine Unmittelbare und Fehlercodes ausgeschlossen, während alle gültigen IOCTLs einschließlich herstellerdefinierter Gerätetypen (0x8000+) erhalten bleiben. Derselbe Filter wird auf alle vier Erkennungspfade angewendet: den IoControlCode-Querverweisscan und die drei Dispatcher-Sammler (Decompiler-CTree, IDA-Switchtable-Wiederherstellung und der rohe Immediate-Operand-Scan).DriverBuddyReloaded/config.py.DispatchDeviceControl-Suche funktioniert nur für x64-Treiberfind_opcode_data (Standardwert ) Opcode-Übereinstimmungen, die in Datensektionen fallen. Wenn sie auf gesetzt wird, werden auch rohe Byte-Übereinstimmungen in Daten angezeigt, was zu Fehlalarmen neigt; falls ein echter Opcode übersehen wurde, kann man zur gemeldeten Adresse gehen und die Bytes als Code neu definieren, um ihn normalerweise wiederherzustellen. Übereinstimmungen werden wie bei jeder anderen Stufe gemeldet (Ergebnisfenster, , ).FalseTruefindings.jsonreport.html