25x faster than Ghidra

A decompiler turns a compiled program back into readable source code, one function at a time. openbinary 26.10.8 decompiles all 25,406 functions in locationd, the background program macOS runs for location services, in 12 seconds, and Ghidra 12.1.4, the standard free decompiler, takes 303 seconds on the same file and laptop.¹

At five minutes a file, an analyst decompiles the one file under suspicion. At twelve seconds, every binary in a release can be decompiled before anyone suspects it.

Results

We measured two programs from macOS: locationd, 9.6 MB and 25,406 functions, and syspolicyd, which decides whether software may run, 1.3 MB and 4,174 functions. Ghidra, radare2 and rizin ran on our Mac. Binary Ninja, a paid decompiler, published its own numbers from a much larger machine, which we show but did not measure.² Analyse is the step before decompiling, finding the functions and the calls between them. radare2 and rizin do not decompile, so their Decompile cells are empty; they do find functions, so they appear in the Analyse and Functions found rows and in the function-finding test.

locationd, 25,406 functions, 9.6 MB

syspolicyd, 4,174 functions, 1.3 MB

The smaller file widens the gap to 78x, since Ghidra is written in Java and sets up a project database before it reads the file, a fixed cost that dominates on a small file. Both binaries are public: locationd, syspolicyd.

Flutter engine, 40,726 functions, 21 MB

The third file is a Linux library, libflutter_linux_gtk.so, the engine behind Flutter desktop apps, written in C++, with its debug information removed and its symbol table kept.

searchpartyd, 56,718 functions, 22 MB

The largest macOS file we timed is searchpartyd, the background program behind Find My, with twice the code of locationd.

dsymutil, 43,056 functions, 50 MB

The fifth file is dsymutil, the tool Xcode uses to build debug-symbol bundles, 50 MB of C++ from the LLVM project. It is the one file where openbinary uses more memory than Ghidra, 8.9 GB against 6.4 GB at peak, and one of its functions, with 2,401 basic blocks and 27 switch tables, takes 18 of openbinary's analysis seconds on its own.

Where the time goes

Two effects account for the gap. openbinary executes 12x fewer instructions than Ghidra on the same file, so it spends 14x less processor time, and it keeps on average 2.4 cores busy against Ghidra's 1.4. Instruction count is the most stable measure: it moved under 0.1% between runs, while Ghidra's wall time moved by 40% because the laptop was busy. Memory follows the same shape, 1.8 GB against 3.8 GB at peak.

Every function becomes an independent job that any core can take, and producing the C accounts for two thirds of the time, finding the functions for the rest.

Finding the functions

A tool can be faster because it finds fewer functions, so we compared the counts: the four tools on this Mac agree within 0.5% on each file. Ghidra hit its 60-second limit on five functions, four in locationd and one in syspolicyd, and produced no C for those, which openbinary did.

macOS programs list their function addresses inside the file. A Linux program leaves the compiler with a symbol table, a list of every function's name and address, and stripping removes that list before the program ships, so a decompiler has to find the function starts on its own. We stripped three Linux files and measured the share of the table's functions each tool found, and how many it reported where the table has none.³

openbinary found every function in all three files, with ten false positives across 62,687 functions. Ghidra matched it on the two C++ files and found 95% on the Rust one, with far more false positives. The stripped files keep the unwind tables, a crash-handling structure that marks function starts, and openbinary relies on them: with those removed as well, which no normal build does, it finds only a third in the first file.

Side by side

A small function from syspolicyd, picked by rule rather than by hand.⁴

struct self_s { uint64_t field_8; uint64_t field_10; uint64_t field_18; uint64_t field_20; uint64_t field_28; }; void -[SPSamplingTasking encodeWithCoder:](struct self_s * self, id a1){    uint64_t r12_1;    uint64_t r13_1;    uint64_t r14_1;    uint64_t rax_7;     r12_1 = self->uuid;    r14_1 = *(uint64_t *)0x1001204e8;    (*(uint64_t *)0x1000fef68)(a1);    r13_1 = *(uint64_t *)0x1000fef20;    (r13_1)(a1, r14_1, r12_1, 0x1001037c8);    (r13_1)(a1, r14_1, self->name, 0x1001037e8);    (r13_1)(a1, r14_1, self->expiration, 0x100103808);    (r13_1)(a1, r14_1, self->samplingRate, 0x100103828);    (r13_1)(a1, r14_1, self->publicKey, 0x100103848);    rax_7 = (*(uint64_t *)0x1000fef60)(a1);    return;}

/* Function Stack Size: 0x18 bytes */ void SPSamplingTasking::encodeWithCoder_(ID param_1,SEL param_2,ID param_3) {  undefined8 uVar1;  undefined *puVar2;  undefined *puVar3;    puVar3 = PTR_s_encodeObject_forKey__1001204e8;  uVar1 = *(undefined8 *)(param_1 + 8);  (*(code *)PTR__objc_retain_1000fef68)(param_3);  puVar2 = PTR__objc_msgSend_1000fef20;  (*(code *)PTR__objc_msgSend_1000fef20)(param_3,puVar3,uVar1,&cf__uuid);  (*(code *)puVar2)(param_3,puVar3,*(undefined8 *)(param_1 + 0x10),&cf__name);  (*(code *)puVar2)(param_3,puVar3,*(undefined8 *)(param_1 + 0x18),&cf__expiration);  (*(code *)puVar2)(param_3,puVar3,*(undefined8 *)(param_1 + 0x20),&cf__samplingRate);  (*(code *)puVar2)(param_3,puVar3,*(undefined8 *)(param_1 + 0x28),&cf__publicKey);  (*(code *)PTR__objc_release_1000fef60)(param_3);  return;}

• Both tools: produce the same five encode calls in the same order.
• openbinary: keeps the method's real name and reads its fields by name, self->uuid and self->name, while the struct declaration above the body still names them field_8 to field_28, which is a bug on our side.
• Ghidra: keeps the names of the called helpers, objc_msgSend among them, and the text keys such as uuid, where openbinary shows numeric addresses.

What it changes

At this speed the unit of work is a release, not a file.

• Coverage: every finding and every attack path is computed over all 25,406 functions, rather than the handful an analyst opened.
• Scale: a firmware image of hundreds of binaries takes minutes, so every release is a batch job rather than a project.
• Automation: an AI agent or a CI check can wait twelve seconds inside one step, and neither can wait five minutes.

What we don't know

Binary Ninja reports 28,372 functions on locationd, 12% more than we find, and their input is not published, so we cannot tell counting differences from functions we miss. Produced is not the same as correct: we never checked the C against debug information or recompiled it, and the field_8 names above are the defect such a check would catch. Five files is still a small sample: three macOS programs and two Linux files, all x86_64, no Windows binary, and nothing the size of a browser. Ghidra ran once on the three larger files, so those multipliers carry one run's noise and, on searchpartyd, a busy machine.

What's next

The C is produced but not verified. Next are a Windows binary, a file the size of a browser, and a correctness check of the C. You can upload your own binary.