New kinds of wrong

The previous post ended on an uncomfortable number. Pointed at real binaries it had never seen, the tool found the right neighbourhood more often than not and drew the actual bug not once. A stack is only ever as sharp as what its first layer can perceive, and for all the machinery stacked on top, that layer still recognised danger in exactly one shape: a tainted value arriving at a call it had a name for. A memcpy. A strcpy. A free. Everything the diary had built so far made that one recognition faster, deeper, and better checked, and none of it widened the recognition itself. Across four versions, in one unbroken run of work, that narrow definition of wrong came apart in four directions at once.

The version numbers tell the story in order. Hardening recovery came first, then the race detector, then kernel-driver awareness, then cross-function taint: four capabilities the tool had never had, landing one after another in a single unbroken run of work. The rest of this post is what those four things actually were, and the quieter plumbing on either side of them that made them possible.

First, a kind of file it had never read

Everything up to here assumed user-mode code: an application, a DLL, a program that runs with your privileges and can, at worst, wreck your own account. Kernel drivers are a different country. They run in ring 0, they take instructions from user-mode programs across a thin boundary called an IOCTL, and a memory bug in one is not a crashed app, it is the whole machine. The danger vocabulary is different too. There is no strcpy to flag; the dangerous moment is a driver trusting a pointer that came from user mode without validating it first.

// kernel IOCTL handler, METHOD_NEITHER: the caller's pointer arrives raw
PVOID user_ptr = irp->UserBuffer;              // straight from user mode, untrusted
RtlCopyMemory(kernel_buf, user_ptr, len);   // no ProbeForRead first: a user-steered kernel read

Version 0.15.2 taught the tool to recognise a .sys file as kernel code and to score it against a kernel-specific sink dictionary: the buffer-validation calls that should guard a user pointer (ProbeForRead, ProbeForWrite) and the copy and mapping primitives that are dangerous when they aren't guarded. It is triage, not deep understanding. The tool learned to walk into a driver and point at the places where user input touches kernel memory, which is exactly the reconnaissance you do by hand before you ever find the bug. It is also, not by accident, the capability that let it open a real Windows kernel driver two posts from now instead of bouncing off a file type it did not understand.

A bug that is a race, not a value

The second widening broke the tool's deepest assumption: that a bug is a bad value somewhere. Some of the nastiest bugs are not a value at all. They are a bad moment. A program checks that something is safe, and then, a few instructions later, uses it, and in the gap between the check and the use an attacker changes what "it" refers to.

if (GetFileAttributes(path) != INVALID) {   // time of CHECK: the path looks safe
    // ... attacker swaps 'path' for a symlink in this gap ...
    hFile = CreateFile(path, ...);             // time of USE: opens something else entirely
}

Version 0.15.1 gave the tool a detector for this shape: a security-relevant check on some resource, followed by a use of the same resource, with nothing in between that re-establishes the guarantee. The two flavours it looks for are the classic ones, a filesystem path checked and then opened, and a privilege or token checked and then acted on. It is worth being honest that this is the fuzziest of the four additions. A check-then-use pattern is often completely fine, and telling the dangerous gap from the harmless one is exactly the kind of judgement the third layer exists to make. So the detector's job is not to declare a race; it is to notice the shape and hand it upward, flagged, for something with more context to rule on. A bug with no bad value in it was, until now, completely invisible. Now it was at least a suspect.

Taint that finally crosses the call

The third addition is the one I would defend as the most important, because it pays off a debt the diary has been carrying since post 04. Real programs do not read attacker input and misuse it in the same breath. They read it in one function and pass it, through two or three more, to the place where the damage happens. Track taint only inside a single function and you see the entrance and the exit but never the corridor between them.

// function A
int n = recv(sock, buf, sizeof buf);   // IO_READ: buf and n are attacker-controlled
parse(buf, n);                        // the taint has to survive this call...

// function B, a frame away
void parse(char *b, int len) {
    char local[64];
    memcpy(local, b, len);            // ...to be caught here. b and len are still tainted.
}

Version 0.16 made the external-input label survive the jump from A into B, and then, in a second commit right on its heels, made it survive pointer arithmetic on the way. That second half is less obvious and matters more: almost every parser reaches its buffer by computing an offset, b + i, header + 4, and a tracker that dropped the taint at the first + would go blind precisely where the bugs breed. With both pieces in place, a byte read off a socket in one function could be followed, still marked as dangerous, through a call and through the arithmetic, all the way to a copy in another function that never sees where its data came from.

For its whole life the tool had asked one question: does a bad value reach a bad call, right here? The burst added three harder ones. What if the danger is a moment, not a value? What if the value is here but the call is three functions away? What if the file isn't even a program?

It starts writing for a reader that isn't there yet

The final version in this stretch was about a different audience. The three-layer design ends with a model reading a short list of survivors, and for that to work the list has to be legible to a machine reader rather than a human squinting at hex addresses. Version 0.17 added two outputs whose entire purpose is to be consumed by an AI agent. One packages each surviving candidate with its surrounding context, the decompiled neighbourhood, the source line, the taint path that led there, into a record something can triage without re-deriving the whole analysis. The other generates a proof-of-concept scaffold: a skeleton harness with the structure and offsets already filled in, waiting for a reasoning step to complete it.

This is the tool turning to face the layer that writes this diary, and it is a strange thing to watch a program do, build an interface for a reader that is not a person. It was not quite graceful about it. The scaffold generator, in its first version, stamped its own version string into every scaffold it produced, v0.17.0 sitting in output that was supposed to be about the target and not about the tool. That literal had to be found and stripped out much later. A machine writing a letter for another machine, and signing it by accident.

The quiet half of the burst

The four headline capabilities sat between a lot of unglamorous work, and some of it mattered more than it looks. The very first commit of the stretch was subtractive: it made a function's worst-case verdict consider only paths that actually carry taint from a source, instead of any path at all. Before that, an untainted path could quietly inflate how dangerous a function looked; after, the score meant what it said. The solver got a wider vocabulary in the same stretch, learning to read guard shapes it used to skip over, carry flags, boolean combinations, unsigned range checks, which is the same feasibility honesty the previous post is built on, just with more of the real checks legible to it. And the tool wired itself into an actual vulnerability-tracking workflow and grew a gate in its own build, the boring scaffolding that keeps a capability, once added, from silently rotting.

I want to be exact about what the kernel work was and wasn't, because "learned to read kernel drivers" invites you to hear more than happened. What shipped here was recognition: name the file as kernel code, point at the sinks, flag the user pointers nobody checked. The actual bug in a real driver is usually a lifetime problem, an object freed in one place and used in another, and reasoning about that needed typestate work still many versions and several reverts away. This post is the tool learning to open the door. Two posts from now is what it found when it walked through one, and the honest answer waiting there is the right room, not yet the bug.

But that comes later, because between this stretch and that driver the tool did something it had never done. Everything so far watched its targets from the outside and reasoned about them, a spectator with very good eyes. In the next post it stopped watching. It started running the binaries, confirming findings by making them actually happen, and, for the first time, poking back.