[BUG] IOCTLs with less than 10 decimal digits aren't found about driverbuddyreloaded

[VoidSec]

Thank you for the report. The checks implemented in:

• DriverBuddyReloaded/DriverBuddyReloaded.py

  Line 218 in 1b7b104

  if digits == 10 and value not in NTSTATUS.ntstatus_values:

• DriverBuddyReloaded/DriverBuddyReloaded.py

  Line 263 in 1b7b104

  if digits == 10 and value not in NTSTATUS.ntstatus_values:

are present in order to significantly lower the false positives; at the moment the script is trying to decode IOCTLs only if an immediate value, with at least 10 digits, is found in a possible DispatchDeviceControl routine and the value does not belong to a known NTSTATUS.

While it's true for most of the IOCTL values I've encountered to be in a format like 9C4060D4h = 2621464788dec (10 digits), there are also valid IOCTL codes as 0x222004h = 2236420dec (7 digits).

Unfortunately, that's a silly problem as I was not able to find any convention/definition on Windows that states what is their minimum/maximum possible value they can have nor their minimum digits. AFAIK even 0x1 will be a valid IOCTL and will be decoded successfully:

I can think of removing/limiting the safeguard to exclude unprobable IOCTL code (e.g. 1/2 digits only) in the next release thus resulting in much higher false-positive rates

[eranzim]

I'm not sure 0 is a legal device number... I mean generally you can probably do anything you want, but maybe you won't get as much 0s...
Looks like 0x10000 (== 65536) might be a good minimal value. Instead of number of digits, you could check 0x10000 <= value... Might be able to also limit value from above. According to this: https://github.com/h0mbre/ioctl.py/blob/master/ioctl.py , maximal device type is 0xf60 (though I don't know what is that repo based on)

[VoidSec]

Umh, as per Microsoft guidelines:

DeviceType: Values of less than 0x8000 are reserved for Microsoft. Values of 0x8000 and higher can be used by vendors.

Unfortunately 0x10000 is a valid IOCTL and cannot be used to tell them apart:

I spoke with @hacksysteam as well as other kernel driver hackers and we didn't come up with any good way of finding IOTCL ranges; I'll keep trying and let you know the result :)

[eranzim]

So maybe only check minimal value, i.e. anything greater than 0x10000 is valid? Maybe we can also check that the Access and Method values give valid enum values (I didn't check their width), but I think just starting with 0x10000 <= value is a good enough check for now (and an improvement to the current one).

[VoidSec]

At the moment it has been partially fixed in 96be3fa, It now includes all the IOCTL values with more than 2 digits. It will have a bit more false positives but hopefully nothing that will break

[eranzim]

Why do you even need to calculate digits? Why not change the check to if value >= 0x10000 and value not in NTSTATUS.ntstatus_values:?

[VoidSec]

You're right. I've just realized that you were using the value of 0x10000 as anything below will result in 0 as a device number.
Theoretically, 0 is an unknown device but I'll agree with you that using 0x10000 won't result in many false positives.
I'll make a new commit to reflect those changes.