afd.sys, zero to twelve

Until now this tool has been proving itself against things that were built to be found: synthetic test suites, code we wrote ourselves, benchmarks with the answers printed on the back. This is the first time it was pointed at something real, a Windows kernel driver with an actual, published vulnerability in it. That sounds like the moment the diary has been building toward, and it is, but read the frame before you read the number. This was a calibration, not a hunt. The target was chosen because the answer was already known, down to the exact list of functions the vendor patched. It is the most favourable test I can construct, the opposite end of the spectrum from the blind backtest, and even so, the most interesting thing that happened was a number I had to take back.

The bug with no dangerous call

The target was afd.sys, and the flaw was CVE-2024-38141, a use-after-free. Everything this tool had learned to hunt so far was, in the end, a dangerous call: a memcpy, a strcpy, an allocation sized from attacker input. This bug has none of those. The functions the vendor patched, the ones that actually hold the vulnerability, do their damage in object lifecycle: create, close, dispatch. There is no alarming API to point at. The top patched function has 0 dangerous calls in it and is nonetheless the bug. That is exactly the shape the typestate work from post 05 was built for, a good pointer used at the wrong time rather than a bad value reaching a sink, and it is the reason a tool that spent its first 4 posts hunting sinks would have walked straight past this one.

Teaching it to see kernel allocations

A use-after-free detector is only as good as its view of allocations and frees, and in kernel code that view started out completely blank. Drivers do not call malloc; they call ExAllocatePoolWithTag and free with ExFreePoolWithTag, and those arrive in the binary through import thunks. The extractor was reading the thunk's decorated name, never the real API behind it, so the driver's entire allocation life was invisible: 0 allocations seen, 0 frees, and therefore, for a state machine that needs to watch a pointer go from allocated to freed to used, nothing to watch at all.

obj = ExAllocatePoolWithTag(NonPagedPool, size, 'Afd');   // ALLOC (hidden behind an __imp_ thunk)
...
ExFreePoolWithTag(obj, 'Afd');                       // FREED
...
obj->endpoint->State = Connected;                    // USE of a freed object: the use-after-free

Resolving the thunk to its canonical name was the whole fix, and it was the kind of small change that unlocks a disproportionate amount. On afd.sys, the count of kernel allocation and free operations the tool could see went from 0 to 425, and the raw use-after-free findings from 0 to over 1,200. Suddenly the typestate engine had a driver's worth of pointer lifetimes to reason about. To be sure it was the mechanism and not the one binary, I ran it across 4 more published kernel driver CVEs, and the same blindness lifted on all of them: across 5 drivers, the allocation operations the tool could see went from nothing to over 2,000.

Zero to twelve

Seeing the allocations was necessary but not sufficient. The findings existed deep in the database, but they were not reaching the top of the operator's list, because the pipeline that ranks and presents findings had never been taught that a kernel driver was a thing that could have this class of bug. A native-technology fallback and a fix to the way use-after-free entries were counted opened that path, and the ranked plan the operator actually reads went from 3 items to 250. When I scored that plan against the vendor's 15 patched functions, 12 of them were there, near the top. From 1 of 15 to 12 of 15. For an afternoon, that was the number, and it was the best result this tool had ever produced against anything real.

Twelve to nine

Then I tried to reproduce it, and could not. Run the same tool on the same binary again and the number moved. Sometimes 12, sometimes 10, sometimes 9. The cause was mundane and completely disqualifying: the use-after-free chain search walked a set, and set iteration order in the language depends on a hash seed that changes every run. The 12 was not an achievement, it was a coin landing well. When I sorted the search into a fixed order and ran it 100×, it returned the same answer every time, and that answer was 9.

A number you cannot reproduce is not a result. It is a rumour that happened to be flattering, and the only honest thing to do with it is write down the smaller number that survives being run twice.

Three asterisks

Getting to 9 of 15 is a real and useful result, and I am proud of the machinery under it. But there are three things about it that matter more than the number, and leaving any of them out would turn an honest calibration into a brag.

It ran with the vendor's own symbols. This calibration was fed a version-matched debug-symbol file, the kind that ships to developers and effectively never accompanies a binary in the field. With those symbols the tool found over 1,200 use-after-free candidates in afd.sys; run against the same driver stripped, the way the tool sees the world in every real engagement, that number collapsed to 34. The symbols multiply its reach on this target roughly 35×. So the honest headline is not "the tool found the afd.sys bug." It is "the tool found the afd.sys bug when it was handed the vendor's own map of the driver."

Surfaced is not the same as delivered. 9 of 15 means 9 of the patched functions reached the top of the ranked plan, where an operator would see them and know to look. It does not mean the tool drew a source-to-sink chain through any of them, and it did not. No complete chains were delivered here, the same as in the blind test; what changed is that on this target, with these advantages, the right functions at least rose to the surface. Finding the room the bug is in is worth something. It is not the same as finding the bug.

The answer was in the envelope the whole time. This was not a discovery. The scorer that produced "9 of 15" works by joining the tool's output against the vendor's published list of patched functions, a list it only exists to be checked against. The target was picked because it was already solved. That is what calibration is for, and it is a legitimate and necessary thing to do, but it is the exact inverse of the question the diary actually cares about, which is what the tool finds when nobody has told it where to look.

And even inside that favourable frame it was not clean. At 9 of 15, 6 of the patched functions still did not reach the operator's list at all: some sat far down the ranking, well below the cut where the list ends, and one could not even be matched by name, because the function the vendor named does not exist under that name in this build of the driver, where it was refactored into several differently-named pieces. That is the 9 that survived all of it.

The scoreboard the tool kept on itself

There is a smaller story folded into this one that I think is the most honest thing in the post. For a while, three different numbers for afd.sys were live at once: the tool's saved data still showed the old 1-of-15, a note in the changelog claimed 9, and a stale mid-cycle artifact said 6. Nobody had actually re-run the thing from scratch and re-derived the score; each number was a fossil from a different week. So I stopped trusting the recorded numbers and forced a clean rerun, and it is worth saying what that rerun returned, because it does not flatter the neat arc above. A few weeks later, with the detectors improved and the search made stable, a fresh deterministic scan of afd.sys came back at 12 of 15 surfaced. The 12 I had retracted as a fluke turned out to be reachable for real; it simply had to be earned by improving the detectors rather than handed over by a lucky seed. The 9 was the honest number the day I wrote it down; the 12 is the honest number now, and the only reason I trust it is the same reason I threw the first 12 away: this time it survived being run 100×.

What it actually proved

So here is afd.sys, stated without inflation. Pointed at a real, high-value kernel driver, handed the vendor's symbols and the knowledge that a bug was there, the tool ranked most of the 15 relevant functions to the top of the pile, deterministically, up from 1. That proves the kernel machinery works and that the typestate engine can find the neighbourhood of a lifecycle bug when the conditions are generous. It proves nothing about doing it blind, on a stripped binary, with no list to check against, which is the only test that finally counts.

The distance between this post's 9-of-15, with every advantage, and the blind test's 0 delivered chains, with none, is the honest width of the gap the rest of this work is trying to close. And it was about to get wider before it got narrower, because the next month the tool developed a new and far more dangerous talent than missing real bugs. It started finding bugs that were not there at all.