Lost your source code? How binary recovery works

Start with what you have

It helps to be precise about what was actually lost. When a developer writes source code and compiles it, the compiler translates that text into a binary: the executable program. Compilation is a one way trip for some things and a faithful record for others.

What is lost in compilation is the human layer. Comments are gone. The original names of functions and variables are usually gone. The tidy structure of the original files, and the reasons behind decisions, were never in the binary to begin with.

What survives is the program itself. The logic survives in full: every calculation, every branch, every rule the program applies. So do its text strings, error messages, and menu wording, the file formats it reads and writes, and, where the platform provides it, runtime type information that preserves class and property names. The compiled binary is a complete and exact record of the behavior of the program. Recovery is the work of translating that record back into source a developer can read and change.

Stage 1: Reconnaissance

Every engagement starts with reconnaissance. The binary is inventoried: what it does, its command line interface and flags, the file formats it reads and writes, the platform it was built for, and whether full recovery is realistic. You get an honest verdict first, before any larger commitment. That verdict is the Recon Report, fixed at $45 with delivery in about 3 days. Some binaries are packed, encrypted, or built in ways that make recovery a poor bet, and the recon stage exists to say so early and cheaply.

Stage 2: Decompilation with Ghidra

The binary is then decompiled with Ghidra, a reverse engineering framework that lifts machine code back into a C like representation. Decompiler output is a draft, not a deliverable. Functions arrive with placeholder names, types are guessed, control flow is flattened or tangled, and idioms that were one clear line of source can sprawl across a page. The draft is valuable because it is complete: every path through the program is in there. But no developer could maintain it as it stands, and handing a client raw decompiler output and calling it recovered source would be dishonest.

Stage 3: Reconstruction

Reconstruction turns the draft into source. Functions and variables get meaningful names based on what they actually do. Data structures are rebuilt from how the program uses them. Control flow is restored to normal structure, dead ends and compiler artifacts are removed, and the result is organized the way a developer would write it. The reconstructed source is then compiled into a working binary. Compilation matters as a checkpoint: source that does not build is not recovered, whatever it looks like on the page.

Stage 4: Differential verification

The rebuilt binary and the original then run side by side across thousands of generated test cases, called fuzz cases, and their outputs are compared exactly. Any divergence is found, fixed in the source, and retested, until the rebuild matches the original across the full run. This is the stage that separates recovery from guesswork, and it produces a report that states what was proven and what was not.

The measured record behind this pipeline is concrete. In completed test engagements, 9 of 9 C and C++ test targets were recovered to compilable source, with 0 behavioral divergences in final differential testing, across thousands of generated fuzz cases per target with outputs compared exactly. One target, bzip2 1.0.8, produced 8,127 lines of recovered source from a single target. The test set included the sbase sort, tar, and find utilities, bzip2 1.0.8, a C++ text statistics tool, and a hostile build compiled with aggressive optimization, link time optimization, and stripped symbols.

What recovery cannot do

Recovery cannot return what compilation destroyed. The original comments are gone for good, and so are the original names, except where runtime type information or symbols preserve them. The recovered source is a faithful reconstruction of behavior, not a photocopy of the text the original developer wrote. Packed, encrypted, or deliberately obfuscated binaries are harder, and some are not realistic candidates at any reasonable price. If a recovery hits something that cannot be recovered, we document exactly where and why instead of filling the gap with plausible looking code.

The proof standard

Two programs can look alike and behave differently in exactly the cases that matter: the odd input, the boundary value, the error path nobody exercises by hand. Reading recovered code and judging that it looks right is not proof, and neither is running it once on a sample file. Differential testing is the bar because it compares behavior directly, case after case, including cases no person would think to try. Zero divergence across thousands of cases is a claim a client can check. Anything less is an opinion.

Orphanware Recovery is operated by Josiah Wilson, who directs every engagement and signs off on every result. The decompilation, reconstruction, and testing pipeline described here is carried out by AI agents under his direction, which is what makes thousands of verification cases per program practical at fixed prices: Source Recovery at $120 with delivery in about 5 days, and Verified Recovery at $250 with delivery in about 7 days, both for scope already agreed in a Recon Report.