voidsec / driverbuddyreloaded Goto Github PK

Describe the bug
Pooltags which aren't immediate values in the correct place, but possibly propagated via a register, aren't found.
Example code snippet:

...
mov     ebp, 'ABCD'
mov     rdx, rax        ; NumberOfBytes
mov     r8d, ebp        ; Tag
call    cs:ExAllocatePoolWithTag

Expected behavior
All Pooltags should be found

Desktop (please complete the following information):

• OS and version: Windows 10 21H2 (19044.1586)
• IDA version: IDA 7.7 SP1
• DriverBuddyReloaded Version: latest (1.3)
• Python Version: 3.9.5

find opcode sometimes print out opcodes not related with the searching

[>] Searching for interesting opcodes...
	- Found mov     al, [rdi+rcx] in sub_231C4 at 0x0002327d

• refactor list of vulnerable functions
• also refactor NTSTATUS array into a separate module

I use IDA Pro 7.6 and Python 3.10, after copying the folder and py script, it should be appeared in Edit->Plugins, but I cannot see the plugin listed?, exact for which IDA and Python versions, will this work?

Describe the bug
WDF detection library correctly detect a KmdfLibrary but the driver is marked as WSF anyway

To Reproduce

[WDF]: Found KmdfLibrary string at 0x14000f388
[WDF]: Creating struct for KmdfLibrary Functions version 1.11
[WDF]: doStruct (size=0xdb0) at 0x140010430
[WDF]: Success
[+] Driver type detected: WDF

Expected behavior
[+] Driver type detected: KMDF

Traceback (most recent call last):
  File "C:/Program Files/IDA 7.0/plugins/DriverBuddyReloaded.py", line 465, in run
    driver_type = utils.get_driver_id(driver_entry_addr, log_file)
  File "C:/Program Files/IDA 7.0/plugins\DriverBuddyReloaded\utils.py", line 209, in get_driver_id
    populate_wdf()
  File "C:/Program Files/IDA 7.0/plugins\DriverBuddyReloaded\wdf.py", line 102, in populate_wdf
    binpat = idaapi.compiled_binpat_vec_t()
AttributeError: module 'idaapi' has no attribute 'compiled_binpat_vec_t'

Version 7.5.201028 Windows x64 (64-bit address size)

7.6 minimum required?

Instead of going into the "Driver Buddy Reloaded" menu and selecting "Decode all IOCTLs in Function", it would be nice to have a shortcut "triggering" the functionality.

Something along the line of:

• CTRL+ALT+D: Decode IOCTL
• CTRL+ALT+A: Auto-analysis
• CRTL+ALT+F: Decode all IOCTLs in Function

Testing cdrom.sys

Failed while executing plugin_t.run():
Traceback (most recent call last):
  File "D:/IDA/plugins/DriverBuddyReloaded.py", line 466, in run
    driver_type = utils.get_driver_id(driver_entry_addr, log_file)
  File "D:\IDA/plugins\DriverBuddyReloaded\utils.py", line 208, in get_driver_id
    populate_wdf()
  File "D:\IDA/plugins\DriverBuddyReloaded\wdf.py", line 759, in populate_wdf
    id = add_struct(version)
  File "D:\IDA/plugins\DriverBuddyReloaded\wdf.py", line 45, in add_struct
    idc.del_struc(idaapi.get_struc(id))
  File "D:\IDA\python\3\idc.py", line 3855, in del_struc
    s = ida_struct.get_struc(sid)
  File "D:\IDA\python\3\ida_struct.py", line 532, in get_struc
    return _ida_struct.get_struc(*args)
TypeError: in method 'get_struc', argument 1 of type 'ea_t'

https://github.com/alexander-pick/win_driver_plugin

It seems that you can refer to the functions he added. For example, the function of executing IOCTL is added to the interface menu.

In

1. idc.find_binary is deprecated due to signature confusion with ida_search.find_binary. Please use ida_search.find_binary instead
2. ida_search.find_binary is deprecated use ida_bytes.bin_search() instead.

In IDA Pro 8.2, IDA automatically identifies the driver entry as "GsDriverEntry". However, this can cause a bug as DriverBuddyReloaded might mistakenly determine it is not a driver. To resolve this issue, we need to patch the is_driver function in utils.py.

def is_driver():
    """
    Determine if the loaded file is actually a Windows driver, checking if `DriverEntry` is in the exports section.
    :return: address of `DriverEntry` if found in exports, False otherwise
    """

    for segment_address in idautils.Segments():
        for func_addr in idautils.Functions(idc.get_segm_start(segment_address), idc.get_segm_end(segment_address)):
            func_name = idc.get_func_name(func_addr)
            if func_name == "DriverEntry":
                return func_addr
            elif func_name == "DriverEntry_0":
                return func_addr
            elif func_name == "GsDriverEntry":
                return func_addr
    return False

Bug

[>] Searching for interesting opcodes...
	- Found jnz     short loc_15862 in sub_15820 at 0x00015852

Fix

filter out uninteresting results if the opcode we are looking for (from the list at

In

"IOCTL Decode All" function is missing some cases as can be shown in the following image:

The only immediate fix I can think of is reworking the heuristic functionality:

1. processing the entire block for cmp, mov, sub operations
2. checking that the immediate operand has 10 digits
3. excluding NTSTATUS values
4. decoding the suspected IOCTL code

Will probably generate some more false positives but it will cover "switch" cases falling into "default" case and such

It will be useful add the enumeration of MajorCodes

enum Major_Codes
{
  IRP_MJ_CREATE = 0x0,
  IRP_MJ_CREATE_NAMED_PIPE = 0x1,
  IRP_MJ_CLOSE = 0x2,
  IRP_MJ_READ = 0x3,
  IRP_MJ_WRITE = 0x4,
  IRP_MJ_QUERY_INFORMATION = 0x5,
  IRP_MJ_SET_INFORMATION = 0x6,
  IRP_MJ_QUERY_EA = 0x7,
  IRP_MJ_SET_EA = 0x8,
  IRP_MJ_FLUSH_BUFFERS = 0x9,
  IRP_MJ_QUERY_VOLUME_INFORMATION = 0xA,
  IRP_MJ_SET_VOLUME_INFORMATION = 0xB,
  IRP_MJ_DIRECTORY_CONTROL = 0xC,
  IRP_MJ_FILE_SYSTEM_CONTROL = 0xD,
  IRP_MJ_DEVICE_CONTROL = 0xE,
  IRP_MJ_INTERNAL_DEVICE_CONTROL = 0xF,
  IRP_MJ_SHUTDOWN = 0x10,
  IRP_MJ_LOCK_CONTROL = 0x11,
  IRP_MJ_CLEANUP = 0x12,
  IRP_MJ_CREATE_MAILSLOT = 0x13,
  IRP_MJ_QUERY_SECURITY = 0x14,
  IRP_MJ_SET_SECURITY = 0x15,
  IRP_MJ_QUERY_POWER = 0x16,
  IRP_MJ_SET_POWER = 0x17,
  IRP_MJ_DEVICE_CHANGE = 0x18,
  IRP_MJ_QUERY_QUOTA = 0x19,
  IRP_MJ_SET_QUOTA = 0x1A,
  IRP_MJ_PNP_POWER = 0x1B,
  IRP_MJ_MAXIMUM_FUNCTION = 0x1C,
};

If this enumeration exists in localtypes and is syncronized, you can press M in the code numbers and add the MJ function name.

This can be converted from

NTSTATUS __stdcall DriverEntry(_DRIVER_OBJECT *DriverObject, PUNICODE_STRING RegistryPath)
{
  int v3; // ebx
  _QWORD *v4; // rcx
  __int64 v5; // rax
  struct _UNICODE_STRING DestinationString; // [rsp+40h] [rbp-28h] BYREF
  struct _UNICODE_STRING SymbolicLinkName; // [rsp+50h] [rbp-18h] BYREF
  PDEVICE_OBJECT DeviceObject; // [rsp+70h] [rbp+8h] BYREF

  DriverObject->MajorFunction[0] = (PDRIVER_DISPATCH)&Possible_DispatchDeviceControl_0;
  DriverObject->MajorFunction[2] = (PDRIVER_DISPATCH)&Possible_DispatchDeviceControl_0;
  DriverObject->MajorFunction[14] = (PDRIVER_DISPATCH)&Possible_DispatchDeviceControl_0;
  DriverObject->DriverStartIo = 0i64;
  DriverObject->DriverUnload = (PDRIVER_UNLOAD)sub_11520;

to

NTSTATUS __stdcall DriverEntry(_DRIVER_OBJECT *DriverObject, PUNICODE_STRING RegistryPath)
{
  int v3; // ebx
  _QWORD *v4; // rcx
  __int64 v5; // rax
  struct _UNICODE_STRING DestinationString; // [rsp+40h] [rbp-28h] BYREF
  struct _UNICODE_STRING SymbolicLinkName; // [rsp+50h] [rbp-18h] BYREF
  PDEVICE_OBJECT DeviceObject; // [rsp+70h] [rbp+8h] BYREF

+  DriverObject->MajorFunction[IRP_MJ_CREATE] = (PDRIVER_DISPATCH)&Possible_DispatchDeviceControl_0;
+  DriverObject->MajorFunction[IRP_MJ_CLOSE] = (PDRIVER_DISPATCH)&Possible_DispatchDeviceControl_0;
+  DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = (PDRIVER_DISPATCH)&Possible_DispatchDeviceControl_0;
  DriverObject->DriverStartIo = 0i64;

Thanks for a good tool

In commit 43eba17 I've finished updating IDA's APIs and fixing breaking code changes.

Unfortunately, despite the script is not breaking anymore, it seems that it still fails this condition at:

for a reason that, at the moment, is unknown. The logic behind https://github.com/VoidSec/DriverBuddyReloaded/blob/main/DriverBuddyReloaded/wdf.py is pretty "hacky" and somewhat "obscure". In addition to that, I'm not sure that the logic detecting the WDF version at

We should also update the WDF structures in order to include updated ones and keep them updated as I'm pretty sure the latest WDF version is >= 1.13.

Describe the bug
Any IOCTL with a code that has less than 10 decimal digits (e.g. 0x222003) won't be found by the current code.

Expected behavior
All IOCTLs should be found

Desktop (please complete the following information):

• OS and version: Windows 10 21H2 (19044.1586)
• IDA version: IDA 7.7 SP1
• DriverBuddyReloaded Version: latest (1.3)
• Python Version: 3.9.5

At the moment the output does not contain the function/address where the DeviceName has been found. Adding it to the output will improve the navigability and augment the information value

In

• DriverBuddyReloaded/DriverBuddyReloaded.py

  Line 185 in d272537

  if digits == 10:

• DriverBuddyReloaded/DriverBuddyReloaded.py

  Line 230 in d272537

  if digits == 10:

decoding suspected IOCTL codes sometimes "pick-up" NTSTATUS values.

• the fix I can think of is comparing the suspected IOCTL code vs a known set of NTSTATUS values and discarding it if matching.

It would be nice to have a capability to save/export:

• the auto-analysis results
• decoded IOCTLs

maybe implemented as a log file

Describe the bug
When I try to decode cdrom.sys, it will occur python warning.

To Reproduce
Steps to reproduce the behavior:

1. use ida to reverse cdrom.sys
2. Ctrl+Alt+A

Traceback (most recent call last):
  File "C:/Users/raven/Desktop/ida77sp1/x64_idapronw_hexarm64w_hexarmw_hexmipsw_hexppc64w_hexppcw_hexx64w_hexx86w_220118/plugins/DriverBuddyReloaded.py", line 466, in run
    driver_type = utils.get_driver_id(driver_entry_addr, log_file)
  File "C:/Users/raven/Desktop/ida77sp1/x64_idapronw_hexarm64w_hexarmw_hexmipsw_hexppc64w_hexppcw_hexx64w_hexx86w_220118/plugins\DriverBuddyReloaded\utils.py", line 205, in get_driver_id
    populate_wdf()
  File "C:/Users/raven/Desktop/ida77sp1/x64_idapronw_hexarm64w_hexarmw_hexmipsw_hexppc64w_hexppcw_hexx64w_hexx86w_220118/plugins\DriverBuddyReloaded\wdf.py", line 753, in populate_wdf
    idx = ida_bytes.bin_search(ea, idaapi.BADADDR, ida_bytes.parse_binpat_str("KmdfLibrary"),
  File "C:\Users\raven\Desktop\ida77sp1\x64_idapronw_hexarm64w_hexarmw_hexmipsw_hexppc64w_hexppcw_hexx64w_hexx86w_220118\python\3\ida_bytes.py", line 3903, in parse_binpat_str
    return _ida_bytes.parse_binpat_str(*args)
TypeError: parse_binpat_str expected at least 4 arguments, got 1

Expected behavior

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS and version: Windows 11
• IDA version IDA 7.7
• DriverBuddyReloaded Version: HEad
• Python Version 3.9

Additional context
Add any other context about the problem here.

Add the information relative to where the DeviceName has been found within the driver

In

At the moment the table being printed does not contain the function/address where the specific "dumb" IOCTL values have been found. Adding it to the output will improve the navigability and augment the information value

In

ExAllocatePoolWithTag has been deprecated by ExAllocatePool2 and ExAllocatePool3