Driver Buddy Reloaded is an IDA Pro Python plugin that helps automate some tedious Windows Kernel Drivers reverse engineering tasks
Copy the DriverBuddyReloaded
folder and the DriverBuddyReloaded.py
script file into the IDA plugins folder, for example:
%APPDATA%\Hex-Rays\IDA Pro\plugins\
C:\Program Files\IDA Pro 7.6\plugins\
~/.idapro/plugins/
If you use Python v. 3.x, run the idapyswitch.exe
binary (located in IDA's folder) from an admin command prompt.
NOTE: IDA SDK > v.7.5 is required in order for this script to run.
To use the auto-analysis feature:
Edit -> Plugins -> Driver Buddy Reloaded
or press CTRL+ALT+A
to start the auto-analysis.<DRIVER_NAME>.sys-YYYY-MM-DD-TIME_STAMP-DriverBuddyReloaded_autoanalysis.txt
file containing the analysis results,
will be written under IDA's DB directory.To decode an IOCTL:
Driver Buddy Reloaded -> Decode IOCTL
; alternatively, press the CTRL+ALT+D
shortcut.To decode ALL IOCTLs within a function:
DispatchDeviceControl
, DispatchInternalDeviceControl
, Possible_DispatchDeviceControl_#
)Driver Buddy Reloaded -> Decode ALL IOCTLs in Function
; alternatively, press the CTRL+ALT+F
shortcut.DriverName.sys-2021-12-10-TIME_STAMP-IOCTLs.txt
/DriverName.sys-2021-12-10-TIME_STAMP-IOCTLs.txt_dumb.txt
file,
containing all the decoded IOCTLs up to that moment, will be written under IDA's DB directory.The vulnerable_function_lists directory contains a lists of potentially
dangerous/problematic functions, Windows APIs and opcodes; a brief description on why a specific function/API has been listed is
provided. You can edit the custom
list including driver's specific functions.
Note: winapi_function_prefixes
will partial match to start of function name (e.g. Zw
will match ZwClose
, ZwCommitComplete
and so on) while winapi_functions
will perform exact matches only.
In find_opcodes.py, the find_opcode_data
option will prevent Driver Buddy
Reloaded to find opcodes in data sections. Switching it to True
will print something along
this line:
Found jnz short loc_15862 in sub_15820 at 0x00015852
Usually, going at the showed address and re-defining the selection as code will bring the searched opcode back.
Watch out: switching it to True
, will generates more false positives!
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:
DispatchDeviceControl
/ DispatchInternalDeviceControl
functionsWDF
and WDM
drivers
IRP
and IO_STACK_LOCATION
WDF
functions that would normally be unlabeledDeviceName
Pooltags
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 from DriverEntry
has been transferred to. It is
usually where the DeviceName
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 recover DispatchDeviceControl
or DispatchInternalDeviceControl
, it employs an experimental searching, following the execution flow, and checking
for cases where the function is loading known IO_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.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.
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, alternatively using the
Ctrl+Alt+F
shortcut, 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.
DriverName.sys-2021-12-10-TIME_STAMP-IOCTLs.txt
/DriverName.sys-2021-12-10-TIME_STAMP-IOCTLs.txt_dumb.txt
file,
containing all the decoded IOCTLs up to that moment, will be written under IDA's DB directory.
Driver Buddy Reloaded has lists of C/C++ functions, opcodes and Windows APIs (defined in the vulnerable_function_lists directory) 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.
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.
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.
DriverName.sys-2021-12-10-TIME_STAMP-pooltags.txt
file, containing all the dumped Pooltags, will be written under
IDA's DB directory.0x10000
will be automatically decoded, thus to prevent an high number of false positives. Issue #15
DispatchDeviceControl
searching works only for x64 driversfind_opcode_data
option will prevent Driver Buddy
Reloaded to find opcodes in data sections. Switching it to True
will print something along
this line:
Found jnz short loc_15862 in sub_15820 at 0x00015852
Usually, going at the showed address and re-defining the selection as code will bring the searched opcode back.
Watch out: It is prone to false positives!