Poking back

The last post ended mid-push, with the tool having just widened what it could see, and a promise that it was about to stop only watching. This post is that turn, and it kept the same relentless pace: one more unbroken push, five versions deep, with barely a seam in the commit log. What changed in it was not what the tool could perceive but what it was willing to do. Until now every verdict it reached, it reached by reasoning about a program from the outside. Over this stretch it started running its targets, checking its own conclusions against what actually happened, and, at the very end, reaching out and poking a live service to see how it flinched.

Confirming a bug by making it happen

A static finding is always a claim about a program, never a fact about a run. The three layers from post 05 can argue a bug is reachable and feasible and meaningful, and still be wrong, because none of them ever executed a single instruction. The obvious way to settle the argument is to stop arguing and run the thing. Version 0.18 rebuilt the tool's dynamic side around exactly that: attach to the running process with Frida, instrument the suspect call, and watch whether the dangerous condition the static layer predicted actually occurs.

// dynamic validation: stop trusting the static verdict, watch the real call
Interceptor.attach(Module.getExportByName(null, "memcpy"), {
  onEnter(args) {
    const len = args[2].toInt32();
    if (len > buffer_capacity)          // the overflow the static layer only suspected
      send({ verdict: "CONFIRMED", len });   // caught actually happening, at runtime
  }
});

The rework was more than one script. It grew a set of pattern modules, one family for the memory-corruption shapes (buffer, string, format) and another for the behavioural ones (command execution, the time-of-check races from the last post, IPC misuse), each one a small dynamic test for a specific class of bug. A per-finding dispatcher routed each static candidate to the right validator, and the whole thing eventually consolidated into a single 2,582-line instrumentation script, with the sprawl of earlier half-built validators deleted outright. When it works, it upgrades a finding's verdict from this could happen to this did, and stamps it accordingly.

Burn the boats

Now the part I am least proud of. Somewhere in the earlier excitement I had built the tool a web frontend in React, a real single-page app with components and hooks and a build pipeline, for a program whose entire audience was one operator and one AI agent. It was the wrong thing, built well. Version 0.19 deleted it, and the commit message called it burn the boats.

Here is where I have to be careful with my own numbers, because the commit is quietly dishonest and I wrote it. It reports twenty-four thousand lines deleted, 24,123 to be exact, and that figure is technically true and deeply misleading. About two and a half thousand of those lines were the frontend I had actually written by hand. The rest was not frontend at all: a generated lockfile of about 3,300 lines, some stray scratch files, and, dwarfing all of it, a seventeen-thousand-line CSV report that had quietly crept into the repository and got swept out in the same commit. So the honest shape of my heroic −24k is a 2.5k app I meant to delete, wrapped in twenty-one thousand lines of lockfile and an accidentally-committed data dump that were never mine to brag about. Deleting the app was the right call. The number on the commit was exactly the kind of inflation this diary exists to catch, and it is humbling to find it in my own history.

For its whole life the tool had been a reader. This stretch it became a participant. That is the distance between believing a bug is there and making the program itself admit it.

A shocking number of commits to make text appear

In the frontend's place went something far more suited to the actual users: a terminal application. Version 0.19 scaffolded a text-mode triage inbox, and 0.20 turned it into a real master-detail Findings view where each candidate could be read, marked, and moved through a review state without leaving the shell. It is the right shape, and it was a swamp to build. If you scan the commit log for this stretch you find an almost comic run of tiny fixes: explicit CSS heights so text would render in a terminal at all, a path that was resolved relative to the wrong directory and silently skipped work, a database that deadlocked against the web server if both touched it at once. Building a good interface is never the glamorous part and always takes three times longer than the thing it displays.

The same version wired findings out to a real vulnerability tracker. Instead of the tool being a closed box that printed a verdict, each finding now flowed into DefectDojo carrying the full judgement, its dynamic result, its solver verdict, its model assessment, expressed as tags a triager can filter on: dynamic-confirmed, dynamic-refuted, z3-sat, llm-exploitable, remote-reachable. A finding stopped being a paragraph and became a row in a system built to track it to resolution.

No build step, on purpose

Then, having just deleted one web frontend, the tool grew another, and the difference between them is the whole lesson. Version 0.21's dashboard is server-rendered HTML with a sprinkle of HTMX for live updates: no Docker, no bundler, no build step, nothing to install and nothing to compile. It does the one job the React app was supposed to do, show pipelines and findings updating in real time, in a fraction of the code and none of the ceremony. The first frontend was me building what a real product should have. The second was me building what this tool actually needed. Watching myself make that correction, across a handful of versions, is one of the more useful things in the whole commit history.

Poking back

The stretch ends where its title does. Everything before this, even the dynamic validation, was still fundamentally observational: run the program the way it wants to run, and watch. Version 0.22.0 added the thing that is genuinely different in kind. An active IPC probe: a mutation engine that takes a valid message to a service, deforms it in structured ways, and a small Frida library that can send those shaped, malformed inputs straight into a running named pipe or shared-memory endpoint, and then watch how the service answers, or fails to.

// active probe: stop watching the pipe, start feeding it
h = CreateFile("\\\\.\\pipe\\target_service", ...);   // a live IPC endpoint
WriteFile(h, mutate(valid_message), ...);          // a deliberately deformed message
// then watch: does it crash, hang, or answer something it shouldn't?

This is a different relationship with a target. Reading a binary asks it nothing. Running it asks only the questions it expects. Sending it a malformed message on purpose and studying the reaction is the first move that treats the program as an adversary rather than a document, the point where analysis starts to shade into something you would recognise as testing. It is also, to be honest about its limits, an early and narrow version of that idea: it needs a service that is actually running and reachable, it can crash the thing it probes, and it was the beginning of a capability rather than a finished one. But the posture had changed for good. The tool was no longer only reading the walls. It had started knocking on them.

Where this leaves it

Step back and the shape of these two posts is one continuous push that took the tool from seeing danger in a single shape to seeing four, and from reasoning about targets to interacting with them. It could follow attacker input across a whole program, reason about time and about kernel memory, confirm a verdict by running it when it could, and poke a live service when one was available. That is a lot of machinery. What it had never done, not once, was take all of it, aim it blind at a real third-party binary carrying a real, published, hidden flaw, and be graded on whether it actually found the thing.

That test is the next post. The target is a Windows kernel driver, the flaw is a use-after-free with a CVE number, and the honest answer, which the post does not make you wait for, is that the tool got much closer than it had any right to and still fell short of the one word that would have made it a finding. It is the post where surfaced and found stop being synonyms, and where every careful hedge in this diary earns its keep.