The work you don't do

The last post ended with a hang and a lesson. I had tried to make Ghidra faster by running it 4 ways at once, and it got slower. But there is a more basic question I had skipped past, and at scale it is the one that mattered: not how fast can you decompile a binary, but how many binaries do you actually need to decompile? The answer is almost none of them.

Two thousand binaries, and most of them noise

A real Windows product is not one file. Install something substantial and you get hundreds, sometimes a couple of thousand, executables and DLLs sitting next to each other. Run full Ghidra analysis across all of them, at roughly 12 minutes a binary, and 2,000 files is hundreds of hours of compute. Most of those hours would be spent on code that was never going to matter: Microsoft runtimes, third-party libraries shipped alongside the real target, exact copies of the same DLL in a dozen folders, and binaries with no attack surface at all. The expensive tool should never touch any of them.

The fastest analysis is the one you never run.

The funnel

Version 0.4 built the filter that decides what the decompiler is even allowed to see. Three cuts, in order.

First, filter third-party. The tool reads each binary's version metadata, its stated company and product, and matches it against a catalogue of publishers. Microsoft runtimes, UI toolkits like DevExpress, common libraries, all set aside. On one real product corpus of 499 binaries, a quarter of them were third-party.

Second, deduplicate. Every binary gets a SHA-256 as it arrives, and if that exact hash was analyzed before, the whole heavy pipeline short-circuits and reuses the earlier result. Across a corpus where the same runtime ships in a dozen places, that removes about half of what is left.

Third, triage. Everything remaining goes through a cheap, no-Ghidra pass that reads the imports and the IPC surface. A binary with no dangerous imports, no named pipes, nothing an attacker could reach, gets marked low-priority and skipped, saving 12 minutes of decompilation each.

Stack the three, and 2,000 binaries in becomes roughly 100 out. More than 90 percent of the analysis never happens.

The one rule that kept it honest

There is a way to get a filter like this badly wrong, and it is worth saying how I avoided it. Every one of these cuts is a bet that a binary is not worth analyzing, and a wrong bet is not symmetric. Skip a Microsoft DLL that turns out to be interesting and you have lost a few minutes you could have spent. Skip a first-party binary that had the bug, and it is gone; you will never know it was there. So the rule, written into the design, is: when in doubt, analyze. The filters are deliberately timid. They only skip a binary when they are confident it is noise, and they err, every time, toward doing the expensive thing. A filter that saves time by occasionally losing findings is worse than no filter at all.

Setting the third-party libraries aside had a bonus, too. On the way past, the filter reads their versions and checks them against known vulnerabilities, and a few came back already broken: an outdated zlib carrying a CVSS 9.8 flaw among them. Skipped for decompilation, flagged for a human anyway.

Parallelism, the right way

That left about 100 binaries that genuinely needed the decompiler, and at 12 minutes each, one at a time, that is still 20 hours. Now the parallelism question comes back, and this time the answer was already written by the last post's failure. The threads died because they shared one loaded program and fought over its locks. So share nothing. Version 0.5 runs the decompiler as separate operating-system processes: split the binaries into groups, launch several Ghidra processes at once, and give each one its own project, its own memory, its own everything. There is nothing to contend over because there is nothing in common, and the 50 seconds a Ghidra JVM takes to start is paid once per worker instead of once per binary. Where the 4 threads had managed a useless 179 percent of a single core, 2 isolated processes hit a genuine 242, real parallelism with nothing to fight over. Scaled to 8 workers, 100 binaries that would take 20 hours in sequence finish in under three.

There was one more cut to make, this time inside each binary rather than across them. The bugs that matter cluster in a small set of code: input handlers, callbacks, cleanup routines, anything that parses or deserializes. Version 0.6 uses the names of functions, patterns lifted from 15 real Windows CVEs, words that mark input handlers, callbacks, cleanup routines and deserializers, to decide what to decompile first, before a time budget runs out, without decompiling anything to find out. How much it helps depends entirely on the binary. A geometry kernel has almost none of those names, so the budget just expires; it finishes about twice as fast, but drops nearly half the dangerous calls along with the noise, which is a real cost, not a free win. On the service and driver code the patterns came from, the same rule catches most of the right functions and keeps 80 to 90 percent of the signal. Stacked on the worker pool, the hundred binaries drop from about two and a half hours to roughly one.

// decompile these first: name patterns lifted from 15 real Windows CVEs
PRIORITIZE  *Handler*  *Callback*  *Cleanup*  *Deserialize*  *Parse*
// a geometry kernel has almost none of these, so its budget simply expires

One day, one wrong idea, three right ones

All of it, the failed threads and the funnel and the process pool and the tiered decompiler, happened on the same day. It reads now like a plan, but it was not. It was one wrong idea followed by three right ones, and the wrong idea taught the right ones what to avoid: the threads that fought over shared state are the reason the processes share nothing. Those 20 hours became one, and almost none of that came from making the decompiler faster. It came from pointing it at less.

Which leaves the harder question for the next post. Once a binary is finally in front of the decompiler, and you are staring at a wall of reconstructed functions, how do you find the few that carry an attacker's data all the way to something dangerous?