View Full Version : Fuzzing device drivers.

October 1st, 2010, 17:08

It's not exactly about RE, but I think here is a good place to ask since a lot of you guys like exploitation and vulnerability development.

I'm interested in learn more about fuzzing windows device drivers.

I'm using the great IOCTL Fuzzer from Esagelab and I followed this tutorial:


So, I started trying it myself and I have a few questions, and help from more experienced is very welcome.

I used the fuzzer in monitor mode and I got a few entries and created a config.xml file.

1) I noted a thing that sounds strange to me, I see a lot of
third-parties apps calling \SystemRoot\System32\drivers\afd.sys, that is a Windows core file. So I got curious, when you see a entry like that you fuzz? I believe not, since it's a driver from Microsoft it
should be very well audited and would not let me to find any flaw on the third-party software, right?

2) There is a way that a device driver is vulnerable during tests with IOCTL Fuzzer, but the trigger may not happen in normal circumstances with restricted user? I mean, IOCTL Fuzzer has a device driver, so it may send any request to the device driver we are testing. There are any kind of ACL (access control list) that are imposed by Windows or may be imposed by the own device driver to only allow certain process to communicate with it? How common it's?

3) In general do you turn <fuze_requests> to true? And <fuze_size> too? There are any special advise to turn them on, etc?

4) Probable the most hard is to find exactly what IRP message triggered the BSOD. What do you do in average to detect the exactly sent request that triggered the issue? I checked the file ioctls.txt, but I'm a bit unsure if the last entry is the one that triggered the BSOD. What is your experience with that?

Also, I noted a few enter (\r\n) on the end of ioctls.txt, but opening it in wordpad shows it as very strange characters (non printable).


5) I used !exploitable and it tells UNKNOWN. On the nice article that I referenced the example sounds a bit
more easy then mine, you have a lot of 0x42 (A) in the debugger when it crashes, on mine not, mine has nothing like that and my last request at ioctls.txt are preety small without a sequence of A, that's why I believe it was not logged or it's not the last request.

All answers and help are very welcome.

Thanks and sorry for dumb questions.

October 3rd, 2010, 01:57

Hopefully someone can answer your questions. I've wanted to play with that fuzzer myself but never found the time.

I just wanted to mention that Microsoft has it's own IOCTL fuzzer, called Device Path Exerciser. It's in the tools directory of the DDK, variously called devctl.exe, dc2.exe or devpathexer.exe in the latest version.


You might find more general info on driver fuzzing searching for examples of usage of the MS resource (searching for the keywords I highlighted in bold above, as well as the MSDN link), rather than the Esagelab version.