wtf is a distributed, code-coverage guided snapshot fuzzer for authorized researchers hunting memory corruption in Windows user and kernel-mode software, with experimental Linux support.
| Tool | 0vercl0k/wtf — distributed, code-coverage guided, cross-platform snapshot-based fuzzer for user and kernel-mode targets |
| Category | Snapshot fuzzing / vulnerability research framework |
| Primary Use | Authorized vulnerability research: harnessing and fuzzing Windows user- and kernel-mode code in Hyper-V VM snapshots via bochscpu, WHVP, or KVM execution backends |
| Safe Use | Use exclusively in authorized security assessments, research labs, and coordinated vulnerability disclosure against software you own or are licensed to test |
| Telemetry Note | Runs entirely inside researcher-controlled VMs and emulators; defenders would observe snapshot fuzzing only within their own authorized lab infrastructure, not against production systems |
0vercl0k/wtf, written in C++ and MIT-licensed with around 1.8k stars, is a distributed, code-coverage guided, customizable, cross-platform snapshot-based fuzzer aimed at user- and kernel-mode targets on Microsoft Windows, with experimental Linux user-mode support. Its distinguishing architectural decision is that execution of the target can happen in one of three backends: full emulation via bochscpu, which the author describes as the slowest but most precise option; hardware acceleration inside a Windows VM using the Windows Hypervisor Platform APIs; or a Linux VM using the KVM APIs, the fastest option. That choice lets an operator trade determinism against throughput depending on the target and the phase of a research engagement.
The README is candid about the tool's proven effectiveness. It has reportedly uncovered memory corruption vulnerabilities in a wide range of software, including IDA Pro, a AAA game, the Windows kernel, the Microsoft RDP client's RDPEGFX channel, and the NVIDIA GPU Display driver. The author links out to a strong body of third-party writeups — ret2's work on UDP game protocols, Thalium's RDPEGFX fuzzing, Fortinet's analysis of the Microsoft IMAP client protocol, and InfoGuard's fuzzing of Defender's mpengine.dll — which collectively serve as an unofficial manual for harnessing real targets. This is a fuzzer with a public track record in coordinated research contexts, not a point-and-shoot scanner.
Internally, wtf is a master/client system. The server node is described as the brain: it tracks aggregated code-coverage, owns the corpus, and generates and distributes test-cases to clients. Client nodes execute an assigned test-case through the chosen backend and report coverage and results back. The default target layout is a simple directory tree: inputs for seed test-cases, outputs for the current minset, coverage for .cov files, crashes for saved crash artifacts, and state holding the memory dump (mem.dmp), the CPU state (regs.json), and a symbol-store.json file that substitutes for native symbol support on Linux.
The recommended onboarding path runs through the bundled fuzzer_hevd and fuzzer_tlv_server modules, with target-hevd.7z and target-tlv_server.7z archives available in the Releases section; extracting them into targets/ gives you a fully wired directory structure. HEVD, the intentionally vulnerable training driver, is the obvious starting point for any authorized professional learning the harness workflow before touching a real third-party target in a licensed research setting.
A local server can be started along the lines of wtf.exe master --name hevd --max_len=1028 --runs=10000000, where max_len caps test-case size, runs bounds generation, and name selects the fuzzing module whose generator function the master invokes. A client node joins with wtf.exe fuzz --name hevd --limit 10000000, where backend selects the execution engine and limit caps instructions executed per test-case — a semantic that varies by backend. That is the entire operational surface needed to get a distributed job running; the heavy lifting, as the README repeatedly stresses, belongs to the user.
Indeed, the 'How does it work?' section is unusually honest about the philosophy: wtf 'doesn't do much of the heavy lifting; the user does.' Unlike classical fuzzers that auto-instrument a target, onboarding is an iterative process that demands deep knowledge of the target. The canonical workflow is to run the target in a single-vCPU, 4GB Hyper-V VM running Windows, freeze it with KD at an interesting state — for example, in user-mode right before a call to DeviceIoControl on HEVD's IOCTL handler — then use the companion snapshot debugger extension to dump kernel memory and the regs.json CPU state. The fuzzer then replays mutations from that frozen instant millions of times without rebooting, which is exactly why snapshot fuzzing reaches kernel attack surface that in-process fuzzers cannot.
Beyond the fuzzing loop, wtf ships a solid triage toolkit. The run subcommand replays a single test-case, which is how you reproduce and inspect a crash like crash-0xfffff764b91c0000-.... Corpus minimization is done by setting runs=0 with the master subcommand, redirecting --inputs=outputs --outputs=minset to shrink a corpus to its covering essence. Execution tracing via --trace-type=rip is fastest on bochscpu because exiting VMX mode is expensive on the hardware backends — a telling performance detail about where the accelerated backends pay their tax.
For deeper introspection, the bochscpu backend can emit --trace-type=tenet traces loadable in the Tenet trace explorer, letting an analyst walk backward from a fault — the README demonstrates tracking a corrupted source pointer in memmove back to its user-mode origin. Coverage traces via --trace-type=cov are not directly loadable into lighthouse until symbolized, which is where the author's symbolizer-rs companion tool comes in, converting raw traces to modoff-style symbolized files for coverage visualization in IDA. The master also maintains an aggregated coverage.cov file for a quick global read on what a job has exercised.
Distributed scaling is the other key design point: because the master holds all state and clients are stateless executors, you can point as many fuzzing nodes at the server as your hardware allows, mixing backends. That makes wtf a good fit for authorized lab environments — corporate research teams, bounty hunters with home clusters, or academic groups — where coverage-guided kernel fuzzing jobs need days of wall-clock time. Linux users should note the platform asymmetry: the symbol-store.json mechanism exists precisely because there is no dbgeng symbol support there, so targets prepared on Windows port more smoothly.
What to watch for: wtf demands a substantial upfront investment in understanding your target, building a stable snapshot, and often writing a custom fuzzer module in the style of fuzzer_hevd.cc. The tool is not abandoned — CI artifacts and releases are published for both Windows and Linux — and the surrounding ecosystem (snapshot, symbolizer-rs, Tenet, lighthouse) is integral rather than optional. For defenders, this tool matters as a source of insight into how memory corruption in parsers and IOCTL handlers gets found; the crashes it produces in authorized research feed coordinated disclosure, patches, and better fuzzing harnesses — a defensive payoff far removed from any operational misuse.
0vercl0k/wtf.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.