Reverse engineering a legacy binary: keep, wrap, rewrite or retire

When the vendor is gone, the source is gone, and the binary still runs the warehouse, the board asks a fair question: can we get the code back? Reverse engineering can answer a different, more useful question: what does this thing actually do, and which of four futures is cheapest and safest, keep, wrap, rewrite, or retire.

What reverse engineering can realistically produce

• A behaviour map: inputs, outputs, state, error paths, and the interfaces other systems depend on.
• A protocol or file-format specification good enough to interoperate or to build a replacement against.
• A list of defects and unsafe defaults discovered along the way, ranked by whether they are reachable.
• Evidence that the binary does something the contract or documentation said it would not.

What it cannot produce

• The original source tree, comments, design notes or build scripts.
• A guaranteed, compilable reconstruction that you can treat as legally identical to the lost original.
• A licence to defeat DRM, licensing, anti-cheat or someone else’s access control.
• Proof that every path has been exercised, especially in heavily obfuscated or time-bombed firmware.

If a provider promises “we will recover your EXE as original source”, treat that as a sales claim, not an engineering plan. Decompilers emit approximations. The professional artefact is the behaviour map your team can maintain.

Four outcomes to choose among

• Document and keep: the system is ugly but understood, monitored, and cheaper than replacement.
• Wrap and isolate: put a better-controlled interface in front, restrict the old binary’s reach, and stop adding features to it.
• Reimplement: the behaviour map becomes the specification for a new component. This is a software project, not a reverse-engineering project, and should be costed as one.
• Retire: once you know what the binary was really doing, you may find the business process can move elsewhere.

What drives effort (without a fake price list)

Effort follows the artefact, not the file size. Packed or obfuscated code, missing symbols, unusual architectures, hardware-tied firmware, and a requirement to be certain about safety-critical paths all expand the work. A weekend with a decompiler is not an engagement. A scoped investigation with written authority, a question list, and a report your engineers can use is.

Authority comes first

We will not reverse engineer a target you do not own or are not authorised to have examined. An enquiry is not authority. If the binary may be malware rather than merely undocumented, start with malware analysis instead. The service page for authorised work is software and firmware reverse engineering.

Sources

• Product and service boundaries in this article follow the published legal and ethical engagement rules: no unauthorised targets, no licence bypass, no original-source guarantee.

Related: Reverse engineering service · Secure code review when source still exists.