DriverBuddy

Schnellstart

DriverBuddy-Installationsanweisungen

1. Kopieren Sie den DriverBuddy-Ordner und die Datei DriverBuddy.py in den IDA-Plugins-Ordner C:\Program Files (x86)\IDA 6.8\plugins oder dorthin, wo Sie IDA installiert haben

DriverBuddy-Verwendungsanweisungen

1. Starten Sie IDA und öffnen Sie einen Windows-Kernel-Treiber
2. Gehen Sie zu Edit->Plugins und wählen Sie Driver Buddy oder drücken Sie ctrl-alt-d
3. Prüfen Sie das Ausgabefenster auf DriverBuddy-Analyseergebnisse
4. Um IOCTLs zu dekodieren, markieren Sie den vermuteten IOCTL und drücken Sie ctrl-alt-i

DriverBuddy

DriverBuddy ist ein IDAPython-Plugin, das hilft, einen Teil der Mühsal rund um das Reverse Engineering von Windows-Kernel-Treibern zu automatisieren. Es verfügt über eine Reihe praktischer Funktionen, wie zum Beispiel:

• Identifizieren des Treibertyps
• Auffinden der Funktionen DispatchDeviceControl und DispatchInternalDeviceControl
• Befüllen gängiger Strukturen für WDF- und WDM-Treiber
  • Versucht, Strukturen wie IRP und IO_STACK_LOCATION zu identifizieren und zu beschriften
  • Beschriftet Aufrufe von WDF-Funktionen, die normalerweise unbeschriftet wären
• Auffinden bekannter IOCTL-Codes und deren Dekodierung
• Kennzeichnen von Funktionen, die anfällig für Missbrauch sind

Auffinden von DispatchDeviceControl

Die Möglichkeit, die DispatchDeviceControl-Funktion automatisch zu lokalisieren und zu identifizieren, spart Zeit beim Reverse Engineering von Treibern. Diese Funktion wird verwendet, um alle eingehenden DeviceIoControl-Codes an die jeweilige Treiberfunktion weiterzuleiten, die diesem Code zugeordnet ist. Die automatische Identifizierung dieser Funktion macht das Auffinden der gültigen DeviceIoControl-Codes für jeden Treiber erheblich schneller. Darüber hinaus hilft die Kenntnis des Speicherorts dieser Funktion bei der Untersuchung möglicher Schwachstellen in einem Treiber nach einem Absturz, den Fokus auf den spezifischen Funktionsaufruf zu lenken, der mit dem abstürzenden DeviceIoControl-Code verbunden ist.

Beschriften von WDM-Strukturen

Mehrere Treiberstrukturen werden von allen WDM-Treibern gemeinsam genutzt. Die Möglichkeit, diese Strukturen wie IO_STACK_LOCATION, IRP und DeviceObject automatisch zu identifizieren, kann während des Reverse-Engineering-Prozesses Zeit sparen. DriverBuddy versucht, viele dieser Strukturen zu lokalisieren und zu identifizieren.

Beschriften von WDF-Funktionen

Wie bei WDM-Treibern gibt es auch bei allen WDF-Treibern mehrere gemeinsame Funktionen und Strukturen. Die automatische Identifizierung dieser Funktionen und Strukturen spart Zeit beim Reverse-Engineering-Prozess und liefert Kontext für nicht identifizierte Bereiche des Treibers, in denen diese Funktionen verwendet werden.

Dekodieren von DeviceIoControl-Codes

Beim Reverse Engineering von Treibern ist es üblich, im Rahmen der Analyse auf IOCTL-Codes zu stoßen. Diese Codes liefern nach der Dekodierung nützliche Informationen für Reverse Engineers und können den Fokus auf bestimmte Teile des Treibers lenken, in denen Schwachstellen wahrscheinlicher bestehen.

Zukünftige Dinge:

1. Obref- und Deref-Prüfungen irgendeiner Art hinzufügen, um Refcount-Probleme zu finden
2. Ausgabe verbessern, GUI?
3. Aktuelle Funktionen stärken/verbessern
   • Zuverlässigkeit des DispatchDeviceControl-Finders verbessern
   • Kurze Beschreibungen schreiben, warum Dinge gekennzeichnet werden
   • MSDN-Dokumentations-Importeur

Zusatzziele:

1. IOCTLs automatisch finden
2. IRP-Taint-Analyse, d. h. Aliasing von sysbuf/inbuf und Größe verfolgen
3. Andere gängige Strukturen identifizieren
4. Nicht initialisierte Variablen usw.

Danksagungen

• Wir verwenden den IOCTL-Decoder von Satoshi Tanda, ursprünglich zu finden unter https://github.com/tandasat/WinIoCtlDecoder.
• Die WDF-Funktionsstruktur basiert auf der Arbeit von Red Plait (http://redplait.blogspot.ru/2012/12/wdffunctionsidc.html) und wurde von Nicolas Guigo nach IDA Python portiert und später von uns aktualisiert.

Lizenz

Diese Software wird unter der MIT-Lizenz veröffentlicht, siehe LICENSE.