Why borer
| borer | Ghidra 12.1.3 (headless) | |
|---|---|---|
| Ready to answer, sqlite3.dll, cold | 0.15 s | 138 s |
| Ready again, analysis kept | 0.13 s | 3.1 s |
| Decompile every function of sqlite3.dll | 2.7 s | 48 s |
| Peak memory, sqlite3.dll | 73 MB | 1.5 GB |
| Install | 14.6 MB, one file | 1.2 GB with its JDK |
| Recompiled output gives the source's answer | 359 / 420 | 308 / 420 |
| Recompiled output compiles but gives a wrong answer | 4 | 50 |
Speed is measured on notepad, msvcrt, sqlite3, ntdll and kernelbase, each tool as it ships, one after the other (numbers, harness). One function at a time the two decompilers take about as long, a few milliseconds each; borer's time includes checking every block.
Quality is measured on 60 known C functions built seven ways (x64 ELF and PE at O0/Od/O2/Os, arm64 at O0/O2). Each decompiled function was compiled again and run against its source. Ghidra still prints fewer gotos and fewer width casts on large optimized functions.
What makes it different:
- Checked decompilation. Every block of pseudo-C is run in an emulator
from three seeded states and compared with the machine. The header says how
many blocks agreed. Instructions it cannot model stay as
/* asm: ... */instead of a guess. - Built for a context window. Every list is filtered and paged on the
server and says
# showing N of M. A repeated request withsince=<tag>returns only what changed. - Deterministic and hostile-input safe. No clock, no random seed. Reads are bounds-checked, scans capped, walks fuel-limited: a malformed file gets an error, never a crash.
- Safe annotation. Renames and comments are dry-run by default and go to a separate project file. The binary is never modified.