The people who built the system left years ago. The documentation stopped matching the code long before that. Now you need to modernise it, integrate with it or replace it, and nobody can say for sure what it does.
You can find out, and you rarely need to decompile anything to do it. Collect evidence from four sources, cheapest first, and stop when you know enough for the decision in front of you. AI has made reverse engineering legacy code, the most expensive of the four, faster. Its findings still need checking against the running system.
Start with the decision you need to make
How much you need to know depends on what you are about to do with the system.
- Replacing it: you need its business rules and edge cases, so the new system doesn’t silently drop or break them.
- Modernising it: you need its architecture, data structures and dependencies, so you know what can change safely and what will break.
- Integrating with it: you need its interfaces: APIs, file formats, network protocols.
- Keeping it: you need enough to maintain it safely: how it’s deployed, what tends to fail, who depends on it.
Write the decision down before anyone opens the code. It tells you when to stop digging.
Four ways to find out how a system works
Work through these in order. Each one is more expensive than the last, and each tells you exactly what the next one needs to answer.
| Source | What it tells you | Cost | Where it falls short |
|---|---|---|---|
| 1. Talk to whoever is left | Why things work the way they do, known workarounds, who uses what | Low | Memory is incomplete and often wrong on details |
| 2. Read what exists | Documentation, configs, database schema, old tickets, logs | Low to medium | Shows structure, not behaviour; documents may be out of date |
| 3. Watch the running system | Real inputs and outputs, network calls, database changes | Medium | Only shows the paths that run while you watch |
| 4. Reverse engineer the software | Logic and data flows recovered from source code, compiled code, binaries and protocols | Highest | Needs specialist tools, expertise and careful verification |
In my experience, teams jump to the last row too early, because decompiling feels like progress and interviews feel like delay.
Is reverse engineering legal? Check before you start
Reverse engineering is usually lawful when you hold the right to analyse the software and have a legitimate purpose. Licence terms and local law can still narrow what you may do. So get the basics answered in writing before anyone starts:
- Which system (name, version, components) is in scope?
- Who owns the rights to it: your company or a vendor?
- If it’s a vendor’s system, under which licence or agreement do you use it, and does it restrict reverse engineering or decompilation?
- What will be done with it: observe and test, analyse the code, decompile, analyse network traffic, or something else?
- What is the purpose of the analysis?
- Does the system use any protection, such as encryption, licence checks, digital rights management (DRM) or obfuscation?
- Do you need consent from anyone else, such as a vendor or a data owner, and have you obtained it?
If the software isn’t yours yet, for example during an acquisition, the analysis needs the owner’s authorisation. When in doubt, check with your own legal team.
Can AI reverse engineer legacy code?
Partly, and much faster than a person working alone.
AI coding agents can be connected to professional reverse engineering tools such as Ghidra and IDA Pro. REA (Reverse Engineer Anything), an open source MCP server, connects agents such as Claude Code, Codex and Cursor to Ghidra, IDA or Hopper. It can also inspect JavaScript and Electron apps, .NET assemblies, Android packages and saved network captures. Once connected, an agent can map a program’s functions, trace how data moves through it and recover pseudocode, assembly, strings and call references from a compiled binary, which the agent then turns into code you can test.
REA runs its analysis on your machine, but the agent’s model provider receives the results. If the binary contains credentials, customer data or regulated logic, check your provider’s data terms first.
Treat every AI explanation as a hypothesis until a test confirms it. AI misreads obfuscated code, hand-optimised assembly and output from unusual compilers, and it explains what it finds with the same confidence whether it is right or wrong.
A wrong explanation of a business rule is worse than none, because someone will build on it. That is why the next step matters most.
Check every finding against the running system
A finding is only useful if you would bet a migration on it. To get there:
1Write each finding as a testable statement. “Orders over $10,000 skip the credit check” is testable. “Handles large orders differently” is not.
2Test it against the running original: give it inputs and compare what actually happens.
3Keep the evidence next to the finding: the test, the log entry, the place in the code.
4Label each finding verified (a test confirms it), observed (seen in logs or traffic), inferred (read from code or AI output) or assumed.
5If you are rebuilding code, run the old and new versions side by side on the same inputs before you switch. Normalise fields that differ by design, such as timestamps and generated IDs, or every comparison will fail.
A finding record can be this simple:
| Finding | Evidence | Confidence | Owner |
|---|---|---|---|
| Orders over $10,000 skip the credit check | 20 test orders replayed on a staging copy; matching branch in the order validation module | Verified | Head of Finance Operations |
It takes longer than accepting what the AI says, and far less time than finding a missing business rule in production.
What you should have at the end
Whichever sources you use, the output should outlive the project:
- Documentation of how the system actually behaves, with its business rules listed one by one
- Architecture and data-flow diagrams
- Interface specifications for anything you integrate with
- A verified functional specification, if you plan to migrate or rebuild
- A short list of open questions and assumptions that are still unconfirmed
Store it in the repository next to the code, or in the wiki your engineers already search, and update it when the system changes.
Where to start this week
1Write down the decision you need to make, and the date you need to make it by.
2List everyone who still knows something about the system: former developers, long-time users, the ops team.
3Gather everything that exists in one place: repositories, configs, database access, old tickets, contracts with vendors.
4Map the integrations from logs and network traffic: what the system talks to, and what talks to it.
5Mark the gaps that the first three sources couldn’t close. Those are the only parts that need reverse engineering.
The short version
Decide what you need to know. Collect evidence cheapest first. Use AI to speed up the hard part, and check every finding before anyone builds on it.
If the gaps sit in compiled code nobody can read, here is how our AI-assisted software reverse engineering service works through them, using the verification steps above. If you still have readable source and want to know how healthy it is, start with a legacy audit.
FAQ
Can AI reverse engineer software?
Yes, with limits. AI agents connected to reverse engineering tools can map functions, trace data flows and draft readable code much faster than manual analysis. Every finding still needs to be checked against the running system by an experienced engineer.
Will AI replace reverse engineers?
No. AI takes over much of the slow, repetitive analysis. Engineers still decide what matters, verify the findings and turn them into documentation or working software.
Can lost source code be recovered?
You can recover the logic, then rebuild it as new code and prove it behaves like the original by running both on the same inputs. Compilers throw away comments, formatting, local variable names, type definitions and the boundaries of inlined functions. Stripped binaries lose function names too. Java and .NET bytecode keep far more metadata, so recovery there comes much closer to the original source.
Is it legal to reverse engineer software?
Often, yes, within limits. It depends on who holds the rights to the code, the licence terms and local law. See our full answer on this question.
