What Is Reverse Engineering, and What Is REA? (Part 1 of 5)

By Dr. Sanju Abraham, Fractional CTO, investor, multiple exits. Published November 1, 2026. Part 1 of a 5-part series: How REA (Reverse-Engineer Anything) Will Transform Software Development.

New series. Over the next four parts this series argues that reverse engineering is no longer a specialist niche — it is a general discipline every software team should practice weekly, applied not only to binaries but to legacy systems, dependencies, competitors, incidents, and markets. We call that generalized discipline REA (Reverse-Engineer Anything). Part 1 (this piece) — definitions, the classical five roles, and why REA is the right frame for 2026. Part 2 — Reverse-engineering a legacy codebase you inherited. Part 3 — Reverse-engineering a dependency, a competitor’s product, and an API. Part 4 — Reverse-engineering an incident, a market, and a team’s workflow. Part 5 — How AI coding tools (Claude Code, Codex, Cursor, Opencode) change the economics of REA and what to automate first.

Key takeaways

• Reverse engineering (classical) is the practice of deconstructing a compiled artifact to recover its architecture, interfaces, data structures, and behavior — without access to the original source code. It is older than modern software (the term predates computing by decades) and has five canonical roles in software development, named in the next section.
• REA (Reverse-Engineer Anything) is the same discipline applied beyond binaries. Every artifact your team touches — a legacy service, a third-party dependency, a competitor’s UX, a production incident, a market segment — has a knowable internal structure that can be recovered through the same disciplined process. REA names that generalization.
• The five classical roles are not optional in 2026. Maintaining legacy systems, interoperability, security vulnerability discovery, fostering innovation, and understanding competitors’ products — each shows up weekly on a typical mid-market engineering team, and each requires a reverse-engineering move whether or not the team names it.
• The ethical and legal boundaries are real and knowable. Clean-room reconstruction, DMCA §1201 and its security-research exemptions, GPL-style copyleft contamination, and the EU InfoSoc Directive’s interoperability carve-out are the four things every REA practitioner should know by name — covered in the “ethical and legal” section below.
• The economics changed in 2024–2026. AI coding tools cut the cost of the mechanical steps of reverse engineering — decompilation reading, binary diffing, protocol inference — by more than an order of magnitude. The discipline that was previously a specialist skill is now cheap enough for weekly use by a generalist team. Part 5 of this series makes that case concretely.

The short answer: Reverse engineering is the recovery of a system’s design and behavior from its artifacts without access to the original specifications — classically, from a compiled binary. REA (Reverse-Engineer Anything) is the generalization of that discipline to every opaque artifact a software team encounters: legacy code they inherited, a dependency they rely on, a competitor’s product, an incident log, a market segment. The classical practice has five canonical roles — maintaining legacy systems, enabling interoperability, finding security vulnerabilities, fostering innovation, and understanding competitors — all five of which show up weekly on a typical mid-market team. What changed in 2024–2026 is that AI coding tools made the mechanical steps roughly an order of magnitude cheaper, moving REA from a specialist skill to a weekly generalist practice. This part defines the terms and the five roles. Parts 2–5 apply them.

What is reverse engineering, exactly?

Reverse engineering is the practice of recovering the design, structure, and behavior of a system from its artifacts, without access to the original source material. The term predates computing — it originated in mechanical and military contexts in the mid-20th century, where engineers would disassemble a captured enemy device to understand how it worked. The computing version keeps the same shape: you have the compiled artifact, and you want the design.

The classical software pipeline has four steps, shown in the hero infographic above:

• Step 1 — the input. A compiled artifact: a binary executable, a stripped library, a minified JavaScript bundle, a protocol trace on the wire, a database file. You don’t have the source code.
• Step 2 — the process. Disassembly, decompilation, dynamic analysis (running the artifact and observing behavior), static analysis (reading the recovered code), and protocol inference. In 2026, each of these steps has a mature tool chain — IDA Pro, Ghidra, Binary Ninja, radare2, Frida — most of them free.
• Step 3 — recovered knowledge. The output: a map of the artifact’s architecture, its interfaces, its data structures, its algorithms, and its behavior. Not a line-for-line reconstruction of the original source (that is rarely the goal and often illegal), but a model complete enough to act on.
• Step 4 — new insights or applications. The recovered knowledge is used — to maintain the system, to interoperate with it, to patch a security flaw, to build a compatible product, or to inform a competitive strategy.

The crucial constraint is in the middle: you do not have the source code. That is what distinguishes reverse engineering from ordinary code reading or documentation. It is also what makes the discipline hard — and what makes the five roles below worth their cost.

What is REA (Reverse-Engineer Anything), and how does it extend classical reverse engineering?

REA generalizes the classical reverse-engineering discipline to every opaque artifact a software team touches, not just binaries. The move is simple: keep the method, change the object. The method — observe behavior, form hypotheses, test them, build a working model — applies to any artifact whose internal structure matters and whose source material is unavailable, incomplete, or expensive to read directly.

Four examples of the same method on non-binary artifacts:

• A legacy service you inherited has source code, but the design intent is gone — the people who wrote it have left, the documentation is stale, and the tests cover 12% of the behavior. The source is technically available but the design is opaque. REA treats the running service as the artifact and recovers the design the same way you’d recover it from a binary — observed behavior, logs, traces, and small controlled experiments. (Part 2 of this series.)
• A third-party dependency publishes an API surface and a changelog, but what the library actually does when you call it — the implicit contracts, the retry behavior, the edge cases — lives in the implementation. REA on a dependency means reading its source as if it were a binary (goal: a working mental model, not a line-for-line understanding), running it under instrumentation, and documenting what you find. (Part 3.)
• A competitor’s product publishes marketing copy and a public UX, but the product’s design decisions — the choices they made at each fork, the trade-offs they accepted — live in the shipping artifact. REA on a competitor means using the product as a user, logging what it does, inferring the model it implements, and surfacing the strategic choices behind it. (Part 3.)
• A production incident leaves behind logs, metrics, traces, and a changed system. The incident itself — what actually happened, in what order, under what triggers — has to be reverse-engineered from those artifacts after the fact. REA on an incident is a disciplined root-cause reconstruction, not a story. (Part 4.)

In every case, the method is the same: collect artifacts, form a hypothesis about the internal model, run cheap tests, refine, document, act. REA is not a new technique — it is a generalization of a mature discipline onto a wider set of problems. The series argument is that treating these problems as reverse-engineering problems, rather than ad-hoc investigations, makes a team dramatically faster and more honest.

What are the five canonical roles of reverse engineering in software development?

Five roles are canonical because they show up on nearly every mid-market engineering team, every week. They are named on the right side of the hero infographic and summarized here; each one gets a dedicated treatment later in the series.

• 1. Maintaining and upgrading legacy systems. When a system’s original authors are gone and the documentation is stale, maintenance is reverse engineering. You need to understand the system to change it safely. In 2026 this is often most of the work: industry estimates put legacy-system maintenance at 60–80% of enterprise engineering spend.
• 2. Enabling interoperability. Two systems that need to talk to each other, one of which is closed, require a reverse-engineered understanding of its protocol or data format. SMB-to-cloud bridges, device-to-service integrations, and most SaaS-to-SaaS “glue code” has a reverse-engineering move hiding in it.
• 3. Discovering vulnerabilities and strengthening security. The security research industry — bug bounties, penetration testing, vulnerability disclosure — is reverse engineering with a defensive goal. The attacker’s and the defender’s method is the same; only the goal differs. Protected under DMCA §1201’s security-research exemption in the U.S. and the EU’s analogous carve-outs.
• 4. Fostering innovation. Reading how a successful product works — the design patterns it chose, the UX decisions, the back-end architecture inferred from its behavior — informs what you build next. Every “we studied how Figma / Linear / Notion did this” moment in a product review is a reverse-engineering exercise.
• 5. Understanding competitors’ products. Related to innovation but distinct: not “what should we build,” but “what are they actually shipping, and what does that tell us about their roadmap and their strengths?” Marketing copy lies; the shipping artifact doesn’t.

These five roles are the reason REA matters. Each one is already happening on your team — informally, inefficiently, often without being named. REA is the proposition that naming the discipline and running it on purpose produces better results than running it by accident.

Why is REA a discipline, not a one-off tactic?

Because the method is explicit, teachable, and compounds across cases. The thing that makes classical reverse engineering a discipline rather than a trick — a defined pipeline, a shared vocabulary, a reusable tool chain, and legal/ethical boundaries that everyone in the field knows — is also what makes REA a discipline rather than a collection of ad-hoc investigations.

Three concrete tests of “is this a discipline”:

• There is a defined method. Classical RE’s four steps (disassemble → analyze → infer → document) map one-to-one onto REA’s four steps on any artifact (observe behavior → form hypothesis → run cheap test → document). A method you can teach a new hire in a week is a discipline. An investigation style that lives in one senior engineer’s head is not.
• The output is a durable artifact, not a conversation. Classical RE produces an architecture document, an interface spec, or a behavior model — something that survives the person who created it. REA on a legacy service produces a design doc. REA on a competitor produces a one-page strategy memo. REA on an incident produces a post-mortem. These are reusable; conversations are not.
• The practice gets cheaper per unit of insight as the team runs it. The first legacy-service reverse-engineering takes a week. The tenth takes a day, because the team has a playbook, a tool chain, and a shared vocabulary. The compounding is the proof. (Part 5 covers the AI-coding-tool angle, which is a step-change in the cost curve.)

The alternative — running every opaque-artifact problem as a bespoke investigation — is what most teams do today. REA names the generalization so a team can run it on purpose.

What are the ethical and legal considerations every REA practitioner should know?

Four things, by name. The ethics and the law are not mysterious; they are well-settled on the questions that matter most to a software team, and knowing them by name separates a professional practice from a legally exposed one.

• Clean-room reconstruction. When reverse engineering a competitor’s product with intent to build a compatible one, the lawful path is a “clean room”: one team documents the behavior; a second team, with no exposure to the first team’s work beyond the behavioral spec, builds the implementation. This is how Compaq cloned the IBM PC BIOS in 1982 and is the reference pattern.
• DMCA §1201 and the security-research exemption. In the United States, circumventing technical protection measures is generally restricted — except for good-faith security research, as granted in the triennial exemption cycle most recently renewed by the Copyright Office. The exemption is narrower than many people think; before publishing vulnerability work, read the current rule.
• GPL and copyleft contamination. Reverse-engineering a GPL-licensed artifact is permitted, but using the recovered code or design in a non-GPL product is often not. The license travels with the design in some interpretations. For commercial REA on open-source dependencies, keep clean-room discipline.
• EU InfoSoc Directive’s interoperability carve-out. EU law (Directive 2001/29/EC, Article 6) grants an explicit interoperability exception to anti-circumvention rules. Teams operating across jurisdictions should know the US and EU rules differ in details and plan accordingly.

The one-line rule. Reverse engineering for interoperability, security research, and your own-code maintenance is almost always lawful. Reverse engineering to clone a product line-for-line, or to extract proprietary trade secrets, is not. The gray zone is narrower than most product teams assume — but it exists, and a 15-minute call with counsel before a large REA engagement is cheap insurance.

When does REA actually save a project?

Four moments, each of which this series will cover in depth. None of them is theoretical; each one has shown up on real mid-market engineering teams in the past 24 months of my own Fractional CTO practice.

• Moment 1 — You inherited a system and need to change it safely. The acquisition closed, the author left, the tests are thin, and the first production incident is coming. REA on the legacy service — observed behavior, controlled experiments, a durable design doc — is the alternative to “rewrite from scratch” (usually expensive and wrong). Covered in Part 2.
• Moment 2 — A dependency is misbehaving and the vendor is unresponsive. The library’s docs promise one thing; production shows another. REA on the dependency — reading its source as a binary, running it under instrumentation — produces a mental model you can act on in days, not months. Covered in Part 3.
• Moment 3 — A customer or an incident forces you to understand a competitor’s shipping behavior. A deal is on the line because a competitor claims a capability. Or an incident reveals that a competitor’s data model is subtly different from yours and the integration breaks. REA on the competitor’s shipping product — not their marketing — gives you a defensible answer. Covered in Part 3 and Part 4.
• Moment 4 — A production incident is still half-understood 48 hours in. The system is back up, but the root cause isn’t settled. REA on the incident — a disciplined reconstruction from logs, metrics, traces, and the diff of system state before and after — is the alternative to a plausible-sounding story that gets you a repeat. Covered in Part 4.

Each of these is a weekly reality for a 10-50 engineer SaaS team in 2026. The REA framing is not for exotic situations; it is for the ordinary ones that eat the schedule when run badly.

Frequently asked questions

Is reverse engineering legal? In most jurisdictions, for most purposes, yes. Reverse engineering your own code is unambiguously legal. Reverse engineering for interoperability (EU InfoSoc Directive Article 6) and for good-faith security research (U.S. DMCA §1201 exemption) is explicitly protected. Reverse engineering to clone a product line-for-line, or to extract proprietary trade secrets from a competitor, is generally not. When in doubt, the “clean-room” method and a 15-minute call with counsel resolve 95% of real-world questions.

How is REA different from “just reading the code” or “just reading the docs”? Both reading code and reading docs assume the source material is accurate and complete. REA assumes it is not — because, in practice, the source material for most non-trivial systems is either stale, missing, or systematically misleading (vendor docs lie by omission; competitor marketing lies on purpose; incident reports are compressed stories). REA treats the running system as the ground truth and recovers the model from behavior. That shift in trust is the whole discipline.

Do I need expensive tools to do classical reverse engineering? No. In 2026 the serious tool chain is largely free: Ghidra (NSA, open-source), radare2 (open-source), Frida (open-source dynamic instrumentation), and the standard Unix tool chain (objdump, strace, tcpdump) cover most practical cases. IDA Pro and Binary Ninja are premium options with real UX advantages, but the free stack is sufficient for most team-scale work.

Is REA the same as “software archaeology” or “code archaeology”? Related but narrower. “Software archaeology” (Michael Feathers’ term) is specifically about understanding old code by reading its history — commits, bug reports, email threads. REA includes that but adds the behavioral and systems dimensions: running the artifact, observing it, inferring the model. Code archaeology is one tool in the REA kit, not a synonym.

Can an AI coding tool reverse-engineer a binary for me? Yes, with the caveat that human judgment is still load-bearing on the interpretation. Claude Code, Codex, and Cursor can read decompiled output and produce a plausible architecture summary in minutes — a step that would have taken hours by hand in 2022. The AI output is a strong first draft; it is not a complete substitute for a human who understands the system’s purpose. Part 5 of this series goes deep on what AI changes and what it does not.

Who should actually practice REA on a mid-market team? Every engineer with 2+ years of experience, and the practice should be made visible in team rituals (post-incident reviews, dependency selection, legacy-service onboarding). It does not need a dedicated role; it needs a shared vocabulary and a published playbook. Part 5 covers the operational side.

Why “REA” as the name — isn’t “reverse engineering” fine already? Because “reverse engineering” has strong connotations of binaries and specialists. Most engineers hear it and think “that’s not my job.” REA (Reverse-Engineer Anything) is a deliberate reframing: same method, wider scope, routine practice. The name is a shorthand for “this is a thing you do weekly, not an exotic skill.”

What’s next in this series

Part 2 — Reverse-engineering a legacy codebase you inherited. The acquisition closed, the author left, the tests are thin, and the first production change is Tuesday. A disciplined REA pass gives you a defensible mental model in days, not a wasted “rewrite from scratch” quarter. If you want help running this on a real system — a legacy service, a dependency, an incident, or a market — that is a core part of what I do as a Fractional CTO. See the Fractional CTO page or get in touch directly.