The Drivers Nobody Fuzzed

There is a whole category of serious vulnerability that the standard tooling cannot even look at.

A “bring your own vulnerable driver” attack works like this. A signed kernel driver, shipped by a legitimate hardware vendor and trusted by Windows, exposes an interface that lets an unprivileged program read and write arbitrary physical memory, map kernel pages, or hit I/O ports. That is a straight line to full kernel privileges. These drivers are everywhere: BIOS-flash utilities, overclocking tools, RGB controllers, monitoring dashboards.

And they are almost all closed-source. No source to fuzz, no symbols, no debug info. A stripped .sys and nothing else. The source-based fuzzers that find most memory bugs today are structurally blind to this surface, because there is no source to point them at. Finding and confirming these bugs is manual reverse-engineering work, one driver at a time.

We wanted to know if a machine could do the whole loop: locate the bug in a stripped binary and confirm it executes, with no human in the confirmation step. It can. Here is how it works, and, just as important, how we keep it from lying to us.

Locate: reading a binary with the names deleted

The first problem is finding the dangerous handler in a driver with no symbols. A Windows driver routes commands through a dispatch table. The interesting one is the device-control handler, and inside it, a switch over command codes leading to a memory-mapping or I/O primitive. Stripped, every one of those functions is an anonymous sub_xxxx.

So we stopped relying on names. The dispatch handler is installed by writing a function pointer to a fixed structure offset, an instruction pattern that survives stripping. The dangerous sinks (MmMapIoSpace and friends) are imported by name even in a stripped driver, because imports live in a table the loader needs. Anchor on those two facts, the pointer-install pattern and the surviving import. Recover the call graph between them, including the indirect, table-based dispatch that hides the path. The ranking falls out: the device-control handler, then the reachable sinks, at the top of the list. On real stripped drivers this puts the vulnerable handler at rank one, with no debug information at all.

Confirm: proving it on a live kernel

Locating a suspicious sink is a hypothesis. The bug is not real until it reproduces.

So the second half is an oracle. Boot the target driver in an instrumented Windows VM, attach a kernel debugger, and drive the located command with an attacker-shaped buffer. Then watch the sink. Did MmMapIoSpace execute with the physical address and length we control? Do the bytes handed back to user space match the actual physical memory at that address? Does a malformed control input not reach the sink? Only when every one of those conditions holds (attacker-controlled operands at the sink, content bound to physical memory, clean negative controls, the exact command we drove) do we call it confirmed. The verdict is a machine-checked reproduction, never the model’s opinion.

Run cold against stripped drivers, this loop re-discovered real, published vulnerabilities. It located the exact vulnerable command and confirmed arbitrary physical read/write on a live kernel, operands and all. From a binary with no source and no symbols, with nothing fed in but the file.

The honest part

Those were known bugs. Published CVEs, already fixed by their vendors. We know that precisely: our own novelty check told us the moment the pipeline tried to call one “new” (a story we told separately, and a cautionary one). So this is a claim about a machine, not about new vulnerabilities. It works on real bugs, cold, on a surface the usual tools cannot see.

That distinction is the entire discipline. It would be easy to run this over a corpus of obscure drivers, watch a confirmation light up, and announce a discovery. We built the opposite instinct into the system, at three layers:

• Proof, not opinion. A confirmation is a reproduction under a debugger with clean controls, five conditions, all required, or it does not count.
• Novelty is checked, never assumed. Before “new” is ever allowed, the finding is matched against the public record. The strongest thing the machine says on its own is candidate.
• The static hint can be wrong. One driver imported the dangerous function and looked exploitable, until we traced the operands and found it only ever maps a hard-coded BIOS region, never attacker input. The right move there is to refuse to build a confirmation, because a “confirmation” of a bug that is not there is the worst output a system like this can produce.

The point

The frontier in automated vulnerability research is two things the model can’t do on its own: reach the surfaces the incumbent tools ignore (stripped, closed-source, no symbols), then prove what you found instead of asserting it. Not a cleverer model. A machine that can do both, honestly, is worth more than one that finds ten times as much and is right some of the time.

We built the machine. The harder, more important half was building the parts that keep it honest.

---

Analysis and tooling by 0sec’s automated security-research system (https://0sec.ai). The vulnerabilities re-discovered in this work are published, vendor-remediated CVEs, used here only to validate the pipeline.