wtf v0.5.1 releases: cross-platform snapshot-based fuzzer designed for attacking user/ kernel-mode targets

what the fuzz

what the fuzz or wtf is a distributed, code-coverage guided, customizable, cross-platform snapshot-based fuzzer designed for attacking user and or kernel-mode targets running on Microsoft Windows. Execution of the target can be done inside an emulator with bochscpu (slowest, most precise), inside a Windows VM with the Windows Hypervisor Platform APIs, or inside a Linux VM with KVM APIs (fastest).

It uncovered memory corruption vulnerabilities in a wide range of softwares: IDA Pro, a popular AAA game, the Windows kernel, HEVD secure mode, etc.

Compiled binaries are available from the CI artifacts for both Windows & Linux or from the Release section.

Special thanks to @yrp604 for providing valuable inputs throughout the project and @masthoon for suggesting to write a demo targeting HEVD secure mode.

How it works

wtf runs user & kernel-mode through an execution backend and relies on the user to insert test-cases in the target. Unlike other classical fuzzer tools, wtf doesn’t do much of the heavy lifting; the user does. The user needs to know the harnessed target very well and onboarding a target is an iterative process that will take time. It has a lot of flexibility to offer if you are ready to get hacking though 🙂

The usual workflow to harness a target is as follows:

1. Get your target running into a Hyper-V VM running Windows with one virtual CPU and 4GB of RAM,
2. Put your target into the desired state using KD. For example, to target HEVD‘s IOCTL handler, I chose to stop the target in user-mode right before the client invokes DeviceIoControl. This will vary depending on your targets but you probably want it to be close to the code you want to fuzz.

   kd> r
   rax=000000dfd98ff3d0 rbx=0000000000000088 rcx=0000000000000088
   rdx=00000000deadbeef rsi=0000000000000000 rdi=0000000000000000
   rip=00007ff6f5bb111e rsp=000000dfd98ff380 rbp=0000000000000000
   r8=000000dfd98ff3d0  r9=0000000000000400 r10=000002263e823055
   r11=00007ff6f5bcb54d r12=0000000000000000 r13=0000000000000000
   r14=0000000000000000 r15=0000000000000000
   iopl=0         nv up ei pl nz na po nc
   cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206
   hevd_client!main+0xae:
   00007ff6`f5bb111e ff15dc1e0100    call    qword ptr [hevd_client!_imp_DeviceIoControl (00007ff6`f5bc3000)] ds:002b:00007ff6`f5bc3000={KERNEL32!DeviceIoControlImplementation (00007ff8`3e2e6360)}

    

    

3. Use bdump.js to generate the kernel crash-dump as well as the regs.json file that contains the CPU state. I recommend to dump those file in a state directory under your target directory (targets/hevd/state for example):

   kd> .scriptload c:\\work\\codes\\bdump\\bdump.js
   [bdump] Usage: !bdump "C:\\path\\to\\dump"
   [bdump] Usage: !bdump_full "C:\\path\\to\\dump"
   [bdump] Usage: !bdump_active_kernel "C:\\path\\to\\dump"
   [bdump] This will create a dump directory and fill it with a memory and register files
   [bdump] NOTE: you must include the quotes and escape the backslashes!
   JavaScript script successfully loaded from 'c:\work\codes\bdump\bdump.js'
   
   kd> !bdump_active_kernel "c:\\work\\codes\\wtf\\targets\\hevd\\state"
   [bdump] creating dir...
   [bdump] saving regs...
   [bdump] register fixups...
   [bdump] don't know how to get mxcsr_mask or fpop, setting to zero...
   [bdump]
   [bdump] don't know how to get avx registers, skipping...
   [bdump]
   [bdump] tr.base is not cannonical...
   [bdump] old tr.base: 0x7375c000
   [bdump] new tr.base: 0xfffff8047375c000
   [bdump]
   [bdump] setting flag 0x2000 on cs.attr...
   [bdump] old cs.attr: 0x2fb
   [bdump] new cs.attr: 0x22fb
   [bdump]
   [bdump] rip and gs don't match kernel/user, swapping...
   [bdump] rip: 0x7ff6f5bb111e
   [bdump] new gs.base: 0xdfd9621000
   [bdump] new kernel_gs_base: 0xfffff8046b6f3000
   [bdump]
   [bdump] non-zero IRQL in usermode, resetting to zero...
   [bdump] saving mem, get a coffee or have a smoke, this will probably take around 10-15 minutes...
   [bdump] Creating c:\work\codes\wtf\targets\hevd\state\mem.dmp - Active kernel and user memory bitmap dump
   [bdump] Collecting pages to write to the dump. This may take a while.
   [bdump] 0% written.
   [...]
   [bdump] 95% written. 1 sec remaining.
   [bdump] Wrote 1.5 GB in 23 sec.
   [bdump] The average transfer rate was 64.7 MB/s.
   [bdump] Dump successfully written
   [bdump] done!
   @$bdump_active_kernel("c:\\work\\codes\\wtf\\targets\\hevd\\state")

    

    

4. Create a fuzzer module, write the code that inserts a test-case into your target and define the various conditions to detect crashes or the end of a test-case.

At this point, you should start to iterate and verify that the fuzzer module works as expected. The execution backends are a blackbox so you should generate execution traces to make sure it goes through the right paths, does the right things. During this phase I mainly use the bochscpu backend as it is fully deterministic, starts fast, generating execution traces is possible, code-coverage comes for free, etc. Overall, it’s a nicer environment to develop and prototype in.

Once you are satisfied with the module, you can start to look at making it work with the winhv / kvm backends if you need it to run under those. One major difference between the bochscpu backend & the others, is that the others use software breakpoints to provide code-coverage information. As a result, you’ll need to load the modules you want coverage for under IDA and use the gen_coveragefile_ida.py script to generate a simple JSON file that gets loaded by wtf. You are free to generate this JSON file yourself using whatever tool you would like: it basically is a list of basic-blocks virtual addresses.

Changelog v0.5.1

• Explicitly pass the size of the requested arguments by @1ndahous3 in #188
• Update kdmp-parser to v0.7.1 by @0vercl0k in #190

Use

Copyright (c) 2021 Axel Souchet