IOCTL-Hammer is a lightweight fuzzing harness focused on targeted, parameter-centric testing of Windows driver IOCTL interfaces. It lowers the barrier to kernel driver testing by systematically stressing the four user-mode buffer descriptors used with DeviceIoControl, instead of relying on heavyweight coverage-guided tooling.
Core idea: manipulate the DeviceIOControl API (input buffer, output buffer, lpBytesReturned, and buffer contents/sizes) to exercise boundary conditions that commonly produce high-impact issues in kernel drivers (BSOD, DoS, privilege escalation).
IOCTL-Hammer is built to be:
- Small and pragmatic: no complex feedback loops required.
- Targeted: focuses on the most dangerous surface of DeviceIoControl parameters.
- Extensible: add new cases in Python quickly or extend the Go binary for high-performance runs.
Prerequisites:
- Windows test VM (strongly recommended). Do NOT run on production hosts.
- Administrator privileges (required to open device handles and exercise drivers).
- Optional: WinDbg or kernel crash dump capture configured for post-crash analysis.
We have rolled out this concept tool in two flavours :
- python version: does the job neat and clean, very lightweight and easy to tweak and play around.
- golang version: to make this as a tool belt with utilities that we intend to use during an engagement involving IOCTL and windows drivers. We have decided to use a compiled language that is very good for prototyping and has native support for Win32 APIs.
PS: Don't ask us why we have not used Rust ! ;)
You can directly install from the netskope repository using the following command. [TODO]
go install github.com/netskope/ioctlhammer
- Clone this repository
- Use the following command to to build the CLI tool from scratch :
go build -o ioctlhammer.exe main.go
We have added helpdocs for each of the commands in the tool
Certain proprietary or custom drivers might require custom parameters in-order to trigger expected behavior. Only once these conditions are met further exploitation is possible. This is the why we have made code modular :
- Addition of test cases begins with creation of custom functions.
- Now these functions can be simply be extended and added to the test suite(this is achieved with the help of TestCase class).
Run the following command after making the changes in the python script :
python ./python/modular_fuzzer.py
- Only fuzz drivers you own or have explicit permission to test.
- Always use an isolated test environment (VMs with snapshots).
- Configure VM to capture crash dumps and ensure you have a plan to examine them (WinDbg).
- Fuzzing kernel code can cause system instability; the harness intentionally causes crashes to find vulnerabilities.
This project has been used to discover impactful vulnerabilities in proprietary drivers; always act responsibly and follow coordinated disclosure practices.