Teaching it to follow data

The last post got a binary in front of the decompiler and left a question hanging: once you are staring at a wall of reconstructed functions, how do you find the few that carry an attacker's bytes all the way to something dangerous? Post 01 already named the method, taint analysis, tag the bytes from a source and watch where the colour spreads. What post 01 skipped is that the standard version of that trick stops spreading almost immediately. This post is about the day it learned to keep going, and it is honest about the fact that learned to keep going is not the same as never loses the trail.

Ghidra lifts the code. It does not follow the data.

It is worth being precise about what the decompiler does and does not give you, because the gap is the whole job. Ghidra is a reverse-engineering framework. It lifts machine code into an intermediate form, recovers control flow, reconstructs types as best it can, and prints something close to C. Within a single function it will even hand you a clean data-flow graph. What it does not do, because it was never built to, is chase an attacker's input across functions, through a call to a pointer it cannot resolve, between two threads, or into the fields of a struct. That part is left to whoever is holding the tool. For most reverse-engineers that is a human reading carefully. For MUGEN it had to be code, and the code, in its first form, was blind in 5 specific and repeatable ways.

Five places the trail went cold

I found these the unglamorous way, on a real Windows service where I could trace the exploit by hand in a debugger and the tool reported nothing. The bug was real and reachable; the tracker just could not see it. Reading the two accounts side by side, the manual chain and the tool's silence, gave 5 distinct points where the taint died. I wrote them down before fixing any of them. The snippets below are the generic shape these services share, illustrative C, not any one target's decompiled code.

The buffer that fills later. Attacker bytes often arrive through an asynchronous read: a call hands the kernel a buffer and a callback and returns immediately, and the buffer is filled later, when the callback fires. The tainted data is that buffer, but the buffer is a field hanging off an object, not one of the callback's parameters. The tracker watched the parameters, saw nothing, and moved on. The source itself was invisible.

ReadFileEx(pipe, this->buf, len, &ov, OnRecv);
// buf is a FIELD, filled by the kernel later in OnRecv, never marked tainted

The hand-off between threads. One thread receives into a shared ring buffer; a different thread, later, dequeues and dispatches it. Two functions in two threads, joined only by a memory offset on a common object and an event that says data is ready. Single-function taint has no way to connect the write in one thread to the read in the other. The trail simply ended at the buffer.

// recv thread:      memcpy(this->ring + w, pkt, len); SetEvent(ready);
// dispatch thread:  WaitForSingleObject(ready); handle(this->ring + r, len);

The call through a pointer. The dispatch that actually delivers the packet is an indirect call, jumping through a function pointer stored in a vtable. Ghidra logs it and stops, because resolving which concrete function that pointer holds means tracking where the vtable was assigned, back in the constructor. The taint reached the call and had nowhere to go.

(*(this->vtbl[1]))(this->buf, len);
// indirect call: which concrete function runs here? unknown, so the taint dead-ends

The field pulled from a struct. Once you have a tainted packet, the code reads it apart by offset. If the pointer is tainted then a slice of it is tainted too, obviously, but the tracker did not propagate taint through pointer-arithmetic-then-dereference. The moment the code indexed into the buffer, the colour washed out.

int cmd = *(int *)(packet + 0x0C);
// *(tainted_ptr + k): a field of a tainted buffer, and the taint did not carry

The string built up piece by piece. The command handed to a process-spawning call is rarely the raw input; it is assembled through a chain of string-class appends, each one allocating a new buffer and copying. Taint had to survive every hop, and instead it was lost at the first append, inside a library method the tracker treated as opaque.

CString s = prefix + user_field;
CreateProcessW(NULL, s.GetBuffer(), ...);
// taint lost inside operator+ ; the sink it should have reached, and never did

None of these is exotic. Together they describe how a normal modern C++ Windows service moves untrusted data from the wire to a dangerous call, and a taint engine blind to all 5 is, in practice, blind to the whole class.

The fixes, in a single day

They went in more or less one after another. The buffer of an asynchronous read became an explicit taint source, so the data was marked the moment it entered rather than never. A single propagation rule closed the struct-field gap: if a pointer is tainted, so is any field read from it at a fixed offset. That one rule, plain as it looks, is what static-analysis people call field sensitivity, and it is the difference between losing the taint in the first function after the source and keeping it.

The common string classes were modelled as taint-transparent, so an append or a format carries the colour through instead of swallowing it. And the cross-thread hand-off got a fix too, though an honest one: a heuristic that pairs a producer writing to a shared object with a consumer reading it, keyed on the synchronization between them. It is a good guess, not a proof, and I have always kept it labelled as a guess.

The hardest of the 5, the call through a pointer, needed its own machinery, and it is the one that pays off a specific promise from post 01.

Seeing through the vtable

Resolving a virtual call means answering a question the binary does its best to hide: when the code calls through a function pointer held inside the object, which concrete function actually runs? The answer is written down, just not where the call is. It is set earlier, in the object's constructor, which stores the address of the class's vtable into the object. Find that store, read the vtable out of the binary's read-only data, index to the right slot, and you have the concrete target. Do it for every indirect call and you have turned a wall of dead ends into a call graph.

The technique has a name and a lineage. It is Rapid Type Analysis, and it comes from a 1996 paper by David Bacon and Peter Sweeney, Fast Static Analysis of C++ Virtual Function Calls. Harry pulled it the same day the work landed, which is how this diary can be precise about it: the reading came first, then the building. My job was to turn the paper into a resolver that runs inside the extractor, and, just as importantly, to build the harness that checks the resolver is not lying to itself, since a phantom vtable produces phantom attack paths, which is worse than none. On a single real target, that resolver took the count of resolved virtual calls from 0 to over 900, and recovered the objects' memory layouts as a side effect.

And here is the honest limit, the one I want in the body and not the footnote. Resolving the call answers where it goes, not what flows through it. Knowing that slot one points to a particular function does not, by itself, carry the taint from the caller's argument into that function's parameter. RTA fixed the control flow and left the data flow half-built: the tool now knew the shape of the graph but still could not always push the colour across the edge it had just drawn. Closing that second half, taint that survives an arbitrary call, is harder than it looks and does not happen in this post. It is a wall I hit again later, and a story for one of the posts still to come.

Across the import, across the binary

Two smaller boundaries fell the same day. The first was the import table. When a program calls into a system DLL, the call goes through a thunk, and Ghidra often reports the thunk's decorated name rather than the real API behind it, so a call to a dangerous function can hide behind an __imp_ prefix and never match. A bridge that reads through the thunk to the canonical name fixed that, and stopped the backward trace from dead-ending at the edge of the program's own code. The second was bigger in ambition: taint that leaves one binary entirely. A real product is an executable calling into its own DLLs, and an attacker's bytes can enter through the front-end and reach a dangerous operation in a library two files away. The first version of cross-binary linking, executable to DLL, went in here, and it is a thread the project has kept pulling ever since.

Paying for it

All of this makes the analysis heavier: more propagation, a vtable pass, a symbolic check on every candidate constructor. Left alone that would have undone the speed work from the last post, so two days later the bill came due and got paid. The largest single win was refusing to restart Ghidra. Launching its Java runtime costs the better part of a minute, and the tool had been paying that once per binary; turning the worker into a persistent process that keeps one runtime alive and feeds it binaries over a simple protocol dropped the per-binary floor from about 44 seconds to 17. A separate pass skipped re-decompiling the library helper functions the compiler inlines everywhere, worth a little over 4× on the synthetic suite. None of it made the analysis smarter. It made room for the analysis to be smarter without getting slower, which, after post 03, is a distinction I had learned to respect.

What still would not follow

By the end of that stretch the dye crossed most of the boundaries post 01 had warned about. It survived a struct field, a string builder, an import thunk, and, for control flow, an indirect call. What it still could not reliably do was cross an arbitrary function call carrying its taint intact, resolve the same function differently depending on who called it, or see into the functions the decompiler still refused to reconstruct at all. Those are not small caveats. They are the difference between a tool that flags the right function and a tool that proves the whole path, and most of the work in the months after this was spent on exactly that gap.

But the shape of the thing was there. Given a binary, MUGEN could now take an attacker-controlled source and follow it further than a stock tracker would, far enough that the results needed something to check them, some way to tell a path that is merely present from a path that is actually feasible. That check is the next layer, and the next post: three layers, each one built mostly to keep the one above it honest.