Driver Buddy Reloaded Quickstart
Table of Contents
- Installation
- Usage
- About Driver Buddy Reloaded
- Known Caveats & Limitations
- Credits & Acknowledgements
Installation
Copy DriverBuddyReloaded
folder and DriverBuddyReloaded.py
file into the IDA plugins folder ( e.g. C:\Program Files (x86)\IDA 7\plugins\
) or wherever you have installed IDA.
Usage
To use the auto-analysis feature:
- Start IDA and load a Windows kernel driver.
- Go to
Edit -> Plugins -> Driver Buddy Reloaded
or pressCTRL+ALT+A
to start the auto-analysis. - Check the "Output" window for the analysis results.
To decode an IOCTLs:
- Place the mouse cursor on the line containing a suspected IOCTL code.
- Right-click and select
Driver Buddy Reloaded -> Decode IOCTL
; alternatively pressCTRL+ALT+D
.
About Driver Buddy Reloaded
Driver Buddy Reloaded is an IDA Pro Python plugin that helps automate some tedious Windows Kernel Drivers reverse engineering tasks. It has a number of handy features, such as:
- Identifying the type of the driver
- Locating
DispatchDeviceControl
/DispatchInternalDeviceControl
functions - Populating common structures for
WDF
andWDM
drivers- Attempts to identify and label structures like the
IRP
andIO_STACK_LOCATION
- Label calls to
WDF
functions that would normally be unlabeled
- Attempts to identify and label structures like the
- Finding and decoding IOCTL codes
- Flagging functions prone to misuse
- Finding potential
DeviceName
- Dumping
Pooltags
Finding DispatchDeviceControl
The tool can automatically locate and identify the DispatchDeviceControl
routine. This function is used to route all incoming DeviceIoControl
codes to the specific driver function associated with that code. Automatically identifying this function makes finding the valid DeviceIoControl
codes for each driver much quicker. Additionally, when investigating possible vulnerabilities in a driver due to a crash, knowing the location of this function helps narrow the focus to the specific function call associated with the crashing DeviceIoControl
code.
When the analysis is successful some subs will be renamed as follow:
DriverEntry
: the original first driver-supplied routine that is called after a driver is loaded. It is responsible for initializing the driver.Real_Driver_Entry
: usually the function where the execution fromDriverEntry
has been transferred to. It is usually where theDeviceName
is initialized.DispatchDeviceControl
/DispatchInternalDeviceControl
: if the tool was able to recover the functions at some specific offsets, the functions will then be renamed with the appropriate name.Possible_DispatchDeviceControl_#
: if the tool was not able to recoverDispatchDeviceControl
orDispatchInternalDeviceControl
, it employs an experimental searching, following the execution flow, and checking for cases where the function is loading knownIO_STACK_LOCATION
&IRP
addresses; indicating that the function could be the DispatchDeviceControl. As it is based on heuristic, it could return more than one result, and it is prone to false positives.
Labelling WDM and WDF Structures
Several driver structures are shared among all WDM
/WDF
drivers. The tool is able to automatically identify these structures, such as the IO_STACK_LOCATION
, IRP
, and DeviceObject
structures and can help save time during the reverse engineering process and provide context to areas of the driver where these functions are in use.
Finding and Decoding IOCTL Codes
While reversing drivers, it is common to come across IOCTL codes as part of the analysis. These codes, when decoded, reveal useful information and may draw focus to specific parts of the driver where vulnerabilities are more likely to exist.
By right-clicking on a potential IOCTL code, a context menu option is presented (alternatively using the Ctrl+Alt+D
shortcut when the cursor is on the line containing a suspected IOCTL code) and can be used to decode the value. This will print out a table with all decoded IOCTL codes. By right-clicking on a decoded IOCTL code, in the disassembly view, it's possible to mark it as invalid; this will leave any non-IOCTL comment intact.
If you right-click on the first instruction of the function you believe to be the IOCTL dispatcher ( DispatchDeviceControl
/DispatchInternalDeviceControl
/Possible_DispatchDeviceControl_#
) under the Driver Buddy Reloaded menu, a “Decode All” option appears, this attempt to decode all the IOCTL codes it can find in the function. This is a bit hacky but most of the time it can speed things up.
Flagging Functions
Driver Buddy Reloaded has a list of C/C++ functions and opcodes as well as Windows API that are commonly vulnerable or that can facilitate buffer overflow conditions. All found instances are reported back during the auto-analysis and can help while looking for possible user-controlled code paths reaching sensitive functions.
Finding DeviceName
The tool automatically attempts to find the drivers registered device paths (DeviceName
), if no paths can be found by looking at Unicode strings inside the binary, then the analyst can manually try to use Madiant’s FLOSS in an attempt to find obfuscated paths.
Dumping Pooltags
During the auto-analysis, the tool also dumps the Pooltags
used by the binary in a format that works with pooltags.txt
. The output can then be copy-pasted at the end of the file and later picked up by WinDbg.
Known Caveats and Limitations
- Experimental
DispatchDeviceControl
searching works only for x64 drivers - Shortcuts are incompatible with F-Secure's win_driver_plugin
Credits and Acknowledgements
- Created in 2021 by Paolo Stagno aka @Void_Sec:
- Made it compatible with Python 3.x
- Made it compatible with IDA 7.x
- Updated C/C++ function and Windows APIs list
- Various bug fixing
- Various improvements
- Integrated part of the functionalities presents in F-Secure's win_driver_plugin
- DriverBuddy was originally written by Braden Hollembaek and Adam Pond of NCC Group.
- Using Satoshi Tanda's IOCTL decoder.
- The WDF functions struct is based on Red Plait's work and was ported to IDA Python by Nicolas Guigo, later updated by Braden Hollembaek and Adam Pond.
- Using Sam Brown's F-Secure win_driver_plugin to retrieve device name and pool tags, specifically Alexander Pick fork.
- The original code for adding items to the right-click menu (and possibly some other random snippets) came from 'herrcore'.