Automatically exported from code.google.com/p/ioctlfuzzer
The developer of this repository has not created any items for sale yet. Need a bug fixed? Help with integration? A different license? Create a request here:
IOCTL Fuzzer ver. 1.3 http://code.google.com/p/ioctlfuzzer/
(c) 2009-2011 eSage lab http://www.esagelab.com/ [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:
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).
--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
General algorithm for fuzz-testing an application is as follows.
Install target application onto a virtual machine.
Attach a remote debugger to the virtual machine. Notice: how to configure WinDbg remote connection to VMware: http://silverstr.ufies.org/lotr0/windbg-vmware.html.
Run IOCTL Fuzzer in fuzzing mode on the guest OS.
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.
Release code execution on the virtual machine (F5 in WinDbg) to allow guest OS generate a crash dump.
Analyze the crash dump. IOCTL which provoked the unhandled exception should be found at this step.
If necessary, manual analysis of the application binary code may be performed.
Typical attack surface analysis usage scenario:
ioctlfuzzer.exe --config ioctlfuzzer.xml --boot
Reboot the box.
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
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.
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".
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:
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:
ioctlfuzzer.exe --config ioctlfuzzer.xml
Note: Kernel Debugger Communication engine uses breakpoints for interaction between debugger extension and target system (https://github.com/Cr4sh/DbgCb/blob/master/dbgcb_scheme.png), so, you can use VirtualKD (http://virtualkd.sysprogs.org/) for better performance.
Download and install Windows Driver Kit Version 7.1.0 http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=36a2630f-5d56-43b5-b996-7633f2ec14ff
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»).
Go to the directory ./src/ and execute .\build.bat (or .\build64.bat, to build 64-bit version) from the Build Environment.