ORPHANWARE What you get back
A real recovery is not a disassembly listing. What is rebuilt is source code you can read, compile, change, and maintain, with the program's behavior verified against the original. In practice that means four things:
- The behavior, every branch of it. Every calculation, decision, loop, and procedure the binary performs is reconstructed in readable form. If the program computes tax, discounts, or machine positions, the recovered source does the same.
- The data handling. File formats, table layouts, index structures, and record shapes are documented alongside the code, in the form they actually exist at runtime. For database programs this is often the most valuable part of the recovery.
- The hidden rules. Validation checks, report definitions, workflow steps, and the accumulated business logic that was never written down anywhere except in the program. This is the part a replacement project almost always loses.
- A buildable source tree. Organized, readable source that compiles into a working program, with build notes explaining how it fits together. You get a system that can be fixed and changed again.
What is lost for good
An honest answer requires saying what recovery cannot do. Compilation throws some information away, and that loss is permanent:
- Original names. Variable names, function names, and internal labels from the original source are gone unless the binary still carries a symbol table, which production builds almost never do. The recovery uses clear descriptive names. You can rename anything to match your own vocabulary.
- Comments and documentation. No comment text survives compilation. The recovered code is documented fresh, describing what each part provably does.
- Original file layout and build scripts. How the original developer organized their folders and their build is gone. The recovery is organized in a sane equivalent that compiles the same program.
This is why buyers should be skeptical of anyone who promises an exact replica of the lost source. What a recovery delivers is better than the promise in one important way: it is verified against the real thing, which the original source, even if it survived, might not be.
The plain version: you do not get your source back exactly as it was written. You get a readable, working equivalent that behaves the same on every case it was tested against. For keeping a business running, that is what matters.
Raw decompiler output is not recovered source
A decompiler on its own produces assembly-shaped pseudocode: technically derived from the binary, but unreadable, uncompilable, and unverified. It answers the question "what does this do" in the hardest possible way. Recovered source is what comes after that step: the output is restructured into clear code, data formats are documented, and then the whole rebuild is tested against the original program. Without the testing step, you have a reading exercise. With it, you have a maintainable system.
How we prove the rebuild matches the original
The verification is differential testing. Thousands of test cases are generated from the original program's behavior, each case is run against both the original binary and the rebuilt source, and the outputs are compared. When the outputs match on every case, the rebuild is confirmed to behave like the original on everything that was tested.
The measured results from our pipeline, stated plainly and kept consistent everywhere on this site:
- 9 of 9 C/C++ targets recovered to compilable source, with zero divergence across thousands of fuzz cases per target.
- 8,127 lines recovered from bzip2 1.0.8.
- Delphi and Object Pascal feasibility passed on October 19, 2026: recovered and verified across 4,654 fuzz cases on a Free Pascal target. Embarcadero Delphi and VCL forms work is less certain and starts with a recon verdict on your specific binary before any recovery is promised.
The honest caveat, which we state here the way we state it in every engagement: fuzz testing proves the rebuild matched the original on every case tested, not on every case possible. It is the strongest evidence available, and it is much stronger than a manual review, but no one who is being honest with you will call it a mathematical proof.
What makes one binary easier to recover than another
Not every binary is equally straightforward. Four factors decide how the work goes:
- The language and toolchain. Some compilers leave more structure behind. Visual Basic 6 applications, for example, recover unusually well; see the VB6 directory entry for why.
- Symbols. If a binary still carries debug symbols, naming and layout recovery goes much faster. Most production binaries strip them, which is expected and normal.
- Packing or obfuscation. Packed or deliberately obfuscated binaries need an unpacking stage first. Standard commercial licensing protection is ordinary work. Malware is not work we take at all.
- Age and platform. DOS and early Windows business binaries are ordinary, well understood work for the pipeline, whatever the era label on the box.
These factors change the effort, not the principle. The verdict on any specific binary comes from looking at the binary itself, which is what the recon step does.
How to find out for your binary
The $45 Recon Report is the honest-verdict step. We analyze your binary and tell you, in plain language, whether recovery is realistic, to what degree, and what a full recovery would take. It is delivered in about 3 days, and if the verdict is no, you still have the documentation of what your program does, which is exactly what a migration plan needs. Before you send anything, the intake checklist shows what we need to start.