Closed eranzim closed 2 years ago
Thank you for the report. The checks implemented in:
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 9C4060D4
h = 2621464788
dec (10 digits), there are also valid IOCTL codes as 0x222004
h = 2236420
dec (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
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)
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 :)
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).
At the moment it has been partially fixed in https://github.com/VoidSec/DriverBuddyReloaded/commit/96be3fa7ba870466dcea9371916a8709bd15e0d7, 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
Why do you even need to calculate digits? Why not change the check to if value >= 0x10000 and value not in NTSTATUS.ntstatus_values:
?
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.
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):