____ _     _____ ____  _____
 / ___| |   |  ___/ ___||  ___|   _ ___________ _ __
| |   | |   | |_  \___ \| |_ | | | |_  /_  / _ \ '__|
| |___| |___|  _|  ___) |  _|| |_| |/ / / /  __/ |
 \____|_____|_|   |____/|_|   \__,_/___/___\___|_|
        C L F S   K E R N E L   F U Z Z E R

a structure-aware, CVE-informed fuzzer for the Windows Common Log File System (clfs.sys)

platform: Windows 11 . arch: x64 / ARM64 . license: MIT . built with: C / Python / PowerShell

version 1.0.238 (build 210726p)

╔═════════════════════════════════════════════════════════════════════════╗
║  fuzzes the .blf (Base Log File) parser inside the Windows kernel.      ║
║  mutations are mapped to real CLFS CVEs. runs in a disposable VM only.  ║
╚═════════════════════════════════════════════════════════════════════════╝

░▒▓ screenshots ▓▒░

the retro DOS control panel (gui.cmd):

live fuzzing in the console (menu.cmd -> f) -- watch reached %, topErr, and the [sample] view of the exact fields being mutated:

░▒▓ the story ▓▒░

This began as a research + learning project by the students at Silly Security Academy, a for-fun expedition into territory that was uncharted for us: Windows kernel driver fuzzing. We leaned on AI to move fast, and on datasets of previous CLFS CVEs to map the attack surface - then the students layered their own mutation strategies on top.

Along the way we actually learned the stuff we came for: the CLFS on-disk format, the Windows CLFS APIs and their gateways, checksum/shadow validation gates, the new 24H2 HMAC log protection, and the whole fuzzing loop end to end - seed -> mutate -> reach the parser -> Driver Verifier -> bugcheck -> triage -> minimize.

No 0-day (yet!). But a genuinely fun tool and a pile of hard-won knowledge. Ship it.

░▒▓ quickstart ▓▒░

!! Kernel fuzzer. Disposable VM ONLY. A hit = BSOD. Snapshot the VM first.

1. copy to the VM, unblock:  Get-ChildItem -Recurse | Unblock-File
2. run:                      menu.cmd     (or gui.cmd for the DOS panel)
3. press  A                  AUTO-CAMPAIGN: arms Verifier -> reboot -> fuzz

The whole effective path is A (or manually: v -> reboot -> f). Watch reached % and topErr. A BSOD means you caught one - the VM reboots, press 6 to triage.

░▒▓ the menu ▓▒░

  A) AUTO-CAMPAIGN .. the one button. arms Verifier (if needed), makes a seed
                      with real records, then live-fuzzes. start here.
  v) ARM VERIFIER  .. turns on Driver Verifier + crash dumps on clfs.sys.
                      REQUIRED once (needs a reboot) or OOB bugs won't BSOD.
  h) HELP          .. the effective path + what the live numbers mean.

  1) VALIDATE      .. checks VM / python / cdb / Verifier are all good to go.
  2) MAKE SEED     .. builds a valid .blf seed (real log records + containers).
  s) HARVEST       .. copies REAL system .blf logs (registry TM/TxR) as seeds.
  3) GEN CORPUS    .. writes a batch of structure-aware, CRC-fixed mutants.

  f) FOREGROUND FUZZ .. the live loop: mutate -> fuzz -> repeat, with an animated
                      reach% bar and a [sample] view of the fields being mutated.
  4) AUTONOMOUS    .. fire-and-forget: sets up, reboots, fuzzes as a task, resumes
                      across BSODs on its own. good for leaving it running.
  5) API-SEQ FUZZ  .. fuzzes the runtime CLFS API surface (container/marshalling
                      calls) instead of the on-disk parse.

  6) TRIAGE        .. after a BSOD: bundles the dump + crashing .blf + a WinDbg
                      CLFS analysis (bugcheck, faulting symbol, disasm).
  b) BUCKETIZE     .. dedups many crash bundles into unique bugs.
  m) MINIMIZE      .. reduces a crashing .blf to its minimal causal bytes.

  7) STOP          .. kill switch. drops STOP.flag + kills the fuzzer now.
  8) UNINSTALL     .. removes the autonomous task + resets Verifier.
  9) OPEN FOLDERS  .. opens logs\ and crashes\.
  0) EXIT

Two numbers do all the talking during a run:

• reached % - how many mutants got past validation into the parser. Higher = better.
• topErr - why the rest were rejected. 6612 LOG_METADATA_CORRUPT is normal. 6614 LOG_METADATA_INCONSISTENT means a shadow/cache desync (see docs/tuning.md).

░▒▓ what it actually fuzzes ▓▒░

Four layers of the BLF, each strategy mapped to a real CVE class (docs/cve-map.md):

  header fields ......... SignaturesOffset / RecordOffsets  (2022-37969, 2025-60709)
  client context LSNs ... lsnOwnerPage & friends            (2024-6768, bugcheck 0xC1F5)
  container context ..... pContainer pointer deref          (2023-28252, 2024-49138)
  node records + strings  node-type confusion, name strings

It recomputes CRC32 and mirrors shadow blocks so mutants survive CLFS's integrity gates and reach the deep parser - then it opens and reads the log records, so the record parser (ClfsGetFirstRecord) actually runs on the mutated pointers.

░▒▓ layout ▓▒░

  gui.cmd / menu.cmd / run.cmd   three front-ends (GUI / TUI / autonomous)
  harness/clfs_harness.c         create / replay / fuzzdir / seqfuzz / snap
  mutator/blf_mutate.py          the structure-aware, CVE-informed mutation engine
  triage/                        setup_vm, collect, minimize, bucketize, crashtriage
  docs/                          blf-format, cve-map, tuning, bug-classes, recovery,
                                 snapshot-fuzzing

░▒▓ responsible use ▓▒░

Authorized security research only - on hardware you own, in a throwaway VM. This is a defensive/research tool: the point is to find bugs and get them fixed. Find something real? Report it to Microsoft MSRC under coordinated disclosure before publishing.

░▒▓ credits ▓▒░

  made with equal parts curiosity, AI, and stubbornness by
        _____ _ _ _         _____                  _ _
       |   __|_| | |_ _    |   __|___ ___ _ _ ___ |_| |_ _ _
       |__   | | | | | |   |__   | -_|  _| | |  _|| |  _| | |
       |_____|_|_|_|_  |   |_____|___|___|___|_|  |_|_| |_  |
                   |___|                 Inc.           |___|

░▒▓ license ▓▒░

Licensed under MIT (see LICENSE).