Need help with ioctlfuzzer?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

133 Stars 53 Forks 7 Commits 2 Opened issues


Automatically exported from

Services available


Need anything else?

Contributors list

# 58,339
7 commits

IOCTL Fuzzer ver. 1.3

(c) 2009-2011 eSage lab [email protected]



IOCTL Fuzzer is a tool designed to automate the task of searching vulnerabilities in Windows kernel drivers by performing fuzz tests on them.

Current OS support (x32 and x64): Windows XP, Vista, 2003 Server, 2008 Server, 7.

The fuzzer’s own driver hooks nt!NtDeviceIoControlFile() in order to take control of all IOCTL requests throughout the system.

While processing IOCTLs, the fuzzer will spoof those IOCTLs conforming to conditions specified in the configuration file. A spoofed IOCTL is identical to the original IRP in all respects except the input data, which is changed to randomly generated fuzz.

Besides the fuzzing functionality, monitoring mode is also available with the tool. The monitoring mode allows logging of IRPs, optionally including their HEX dumps, into a file and/or a console.

Also, since 1.2 version exceptions monitoring feature is available, that can be usefull while fuzzing not only a kernel drivers. Exception monitoring is working through unexported function nt!KiDispatchException() pathing, which address obtained from Windows kernel debug symbols (they are automatically downloading from Microsoft's PDB server, during fuzzer initialization).

Specific IOCTLs which are to be logged or fuzzed by the tool are defined in the XML configuration file. IOCTLs may be filtered by the following parameters:

  • Path to executable file corresponding to a process from which an IOCTL request is sent.
  • IOCTL destination device name.
  • IOCTL destination driver name.
  • IOCTL Control Code.

Since 1.3 version IOCTL Fuzzer dumps all catched IOCTLs information in text file %SystemDrive%\ioctls.log Information from this file can be used for calculating requests count for each device/driver during the attack surface analysis (see below).


Command line options

--config - Specify path to the fuzzer XML configuration file. For more information about configuration file format see example in bin/ioctlfuzzer.xml. If '--config' option is not specified - application will start in IOCTLs monitoring mode.

--boot - Boot time fuzzing/monitoring. This option will run fuzzer with the next system reboot.

--exceptions - Enable exceptions monitoring. Notice: files dbgeng.dll, dbghelp.dll and symsrv.dll are required for exceptions monitoring and must be placed into the same directory, as IOCTL Fuzzer executable.

--noioctls - Disable IOCTLs monitoring, show exceptions only (this option valid if '--exceptions' has been specified).

--uninstall - Uninstall IOCTL Fuzzer kernel driver and exit.

--analyze - Attack surface analysis feature: prints list of all drivers, devices and their properties (security settings, number of catched IOCTL requests, driver file product/vendor information, opened handles for devices, etc.), see log file example in attack-surface-analysisNT6.1x86.log.

--loadlog - Load catched IOCTLs information for attack surface analysis from external log file. This option can be used only with '--analyze', as '' parameter you can specify path to the catched IOCTLs log file (%SystemDrive%\ioctls.log), which is created automatically when IOCTL Fuzzer runs in IOCTLs fuzzing or monitoring mode.

Typical usage example (run IOCTL Fuzzer with XML config and enable exceptions monitoring):

ioctlfuzzer.exe --config ioctlfuzzer.xml --exceptions


Using the fuzzer

General algorithm for fuzz-testing an application is as follows.

  1. Install target application onto a virtual machine.

  2. Attach a remote debugger to the virtual machine. Notice: how to configure WinDbg remote connection to VMware:

  3. Run IOCTL Fuzzer in fuzzing mode on the guest OS.

  4. Play around with target application unless an unhandled exception is displayed in the remotely attached debugger. Notice: normally, i.e. with no debugger attached, an unhandled exception will provoke a BSOD.

  5. Release code execution on the virtual machine (F5 in WinDbg) to allow guest OS generate a crash dump.

  6. Analyze the crash dump. IOCTL which provoked the unhandled exception should be found at this step.

  7. If necessary, manual analysis of the application binary code may be performed.


Using the attack surface analysis feature

Typical attack surface analysis usage scenario:

  1. Enable boot time monitoring to collect information about the most frequently-used IOCTL requests:

ioctlfuzzer.exe --config ioctlfuzzer.xml --boot

  1. Reboot the box.

  2. After reboot run attack surface analysis and pass to the IOCTL Fuzzer path of the log file, with all of the collected IOCTLs information:

ioctlfuzzer.exe --analyze --loadlog %SystemDrive%\ioctls.log.

============================================== Using the fuzzer with

Kernel Debugger Communication Engine

Integration with Kernel Debugger Communicatioin Engine allows the IOCTL Fuzzer to execute any commands in remote kernel debugger for IOCTL requests parameters, which were specified in the XML configuration file.

  1. Before running fuzzer you need to load Kernel Debugger Communicatioin Engine extension in your remote kernel debugger by executing command ".load \path\to\ioctlfuzzer\binaries\dbgcb.dll".

  2. Edit "dbgcb" nodes list in XML configuration file. For example, if you want to run "kb 40" command for each IOCTL request, that executed from the net.exe process context:

<![CDATA[kb 40]]>

Also, you can use "device" or "driver" nodes, for specifying device/driver name, and "ioctl" for I/O Control Code value:

<![CDATA[kb 40]]> <![CDATA[kb 40]]> <![CDATA[kb 40]]>

If command value is not specified -- fuzzer just breaks into debugger when catching request with the appropriate parameters:

  1. Run fuzzer with XML configuration file:

ioctlfuzzer.exe --config ioctlfuzzer.xml

Note: Kernel Debugger Communication engine uses breakpoints for interaction between debugger extension and target system (, so, you can use VirtualKD ( for better performance.


Building from sources

  1. Download and install Windows Driver Kit Version 7.1.0

  2. Run Windows Server 2003 x86 (or x64, to build 64-bit version) Free Build Environment (Start -> «Windows Driver Kits» -> «WDK 7600.16385.1» -> «Build Environments» -> «Windows Server 2003» -> «x86 Free Build Environment»).

  3. Go to the directory ./src/ and execute .\build.bat (or .\build64.bat, to build 64-bit version) from the Build Environment.

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.