Does REA recover the original source code?

No. Nothing recovers original source code from a binary — the variable names, comments and structure that the author wrote are gone at compile time. What decompilers produce is pseudocode: a readable approximation of what the machine code does. REA’s contribution is to work from that evidence systematically and write a specification of the behaviour, which is the thing a faithful rebuild actually needs.

Is it legal to reverse-engineer an app?

It depends on whose app, why, and where. Reverse-engineering your own software, good-faith security research, and work done to achieve interoperability are widely accepted and in some jurisdictions legally protected; a product’s licence may restrict more, and circumventing DRM or access controls is prohibited in many places regardless of intent. REA’s own documentation limits it to authorised, lawful research — and so should you. When the answer matters commercially, it is a question for a lawyer in your jurisdiction, not for a tool.

Do I still need Ghidra installed to use REA?

For native binaries, yes — REA is an orchestration layer, not an engine. It drives an installed analysis engine (Ghidra, IDA Pro or Hopper) and checks each one with its doctor command. APKs go through JADX, and some targets — JavaScript and Electron apps, websites, network captures — need no native engine at all. The install is one afternoon once; the agent’s stamina is the part you could not hire.

Can AI agents reverse-engineer your app?

By John · Former Microsoft engineer with 20 years of experience.

REA — Reverse Engineer Anything — is an open-source MCP server and command-line tool that lets a coding agent operate professional reverse-engineering software: point the agent at a shipped app or binary and it inspects the code with real decompilers, writes down how a feature works as a specification, rebuilds the feature, and checks the rebuild against the original. It became one of GitHub’s fastest-growing projects in October 2026, and it changes the economics of an old fact: anything that runs on a user’s machine can be read by that user. This article explains what REA actually is, the stack of tools it drives, the workflow that makes its output trustworthy, and what a developer who ships software should do about it.

What REA is

REA (the repository is morluto/rea, MIT-licensed, installed from npm as rea-agents) is not a decompiler. It decompiles nothing itself. It is an orchestration layer that speaks the Model Context Protocol — the same interface this site’s agent-readiness work deals with from the website side — and exposes reverse-engineering operations as tools a coding agent such as Claude Code, Codex or Cursor can call: disassemble this binary, decompile this function, list the strings, follow the cross-references, show the evidence. The heavy lifting is done by the engines underneath it, which the agent drives the way a human analyst would, except that it can afford to be exhaustive.

That division of labour is the point. A decompiler’s output is enormous and mostly boring; the scarce skill in reverse engineering was never running the tool, it was deciding what to look at next and knowing when an answer is proven. REA pairs the engines with workflow instructions — investigate in a set order, record evidence for every claim, state what could not be resolved — so the agent’s output is not a pile of pseudocode but a set of findings with receipts. For native binaries it drives Ghidra, IDA Pro or Hopper; for Android packages it drives JADX; for live behaviour it can read HAR and mitmproxy captures. One interface, many engines, and the agent supplies the stamina.

The stack in one map

The analysis core. Ghidra is the NSA’s free, Apache-2.0 decompiler and the default engine for most people; IDA Pro is the commercial incumbent many professionals still prefer. What is new is not either tool but their bridges: GhidraMCP and ida-pro-mcp expose a running Ghidra or IDA session to an agent over MCP, so the agent can query the disassembly database directly instead of reading screenshots. REA sits one level above them, choosing engines and sequencing the work.

Mobile and apps. jadx decompiles Android APKs back to readable Java; Apktool unpacks an APK’s resources and smali and can rebuild it; Frida instruments a running app, hooking functions as they execute — the dynamic half that static decompilation cannot see; and ILSpy does for .NET assemblies what jadx does for APKs. (For a no-install first look at an APK’s declarations rather than its code, this site’s APK Analyzer reads the manifest, permissions and signing certificates in your browser.)

Binary and low-level. radare2 and its friendlier fork rizin are scriptable terminal-first reverse-engineering frameworks; x64dbg is the Windows debugger most analysts reach for; ImHex is a hex editor with a pattern language for describing file formats; and angr is a symbolic-execution engine that can reason about every path through a function rather than one run of it. These are the tools for the questions decompilers answer badly: packed binaries, odd file formats, “can this input reach that branch at all”.

Network and runtime. mitmproxy sits between an app and its servers and records the conversation — for many apps the API traffic explains more than the code does, and it is the capture format REA reads natively. dnSpy debugs and edits .NET applications live, and raddebugger is Epic’s modern graphical debugger for Windows. Around all of it sit the maps: two curated lists, awesome-ai-reverse-engineering (122 agent-era repositories, each one read and scored) and the REA author’s own awesome-reverse-engineering, are linked in the sources below.

The clean-room loop: spec, rebuild, verify

The workflow REA encourages is older than AI: it is clean-room engineering, the discipline once used to clone a BIOS without copying it. The agent investigates the target and writes SPEC.md — a specification of what the software does, in plain language, with the evidence for each behaviour attached. Only then does rebuilding start, from the spec rather than from the decompiled code, and the rebuild is judged against acceptance criteria: same inputs, same outputs, same edge cases. Where the judge says no, the loop goes back to the evidence — not to a guess — and investigates again.

This is why the interesting artefact is the spec, not the pseudocode. A spec with evidence is checkable by a second agent, by a test suite, or by a human; a raw decompilation is none of those things. It is also the legally significant step: a rebuild from a behavioural specification is a different act from copying an implementation, which is why the loop insists on evidence and criteria rather than vibes. Anyone evaluating agent tooling — for reverse engineering or anything else — should steal this pattern: the deliverable is a verified claim, not a confident answer.

What this means if you ship software

None of this makes client-side code secret; it never was. It makes reading it cheap. A skilled analyst with Ghidra could always extract the API endpoints, the feature flags and the licensing logic from your app — REA-class tooling means a junior with an agent subscription can do the first pass in an afternoon. The practical consequences are the old ones, now with shorter deadlines: a secret embedded in a shipped binary — an API key, a private endpoint, the one true discount rule — is effectively published; obfuscation raises the cost of reading but is a delay, not a barrier; and anything whose secrecy your business depends on must live on your server, behind authentication, not in the app.

The defences are equally unglamorous and they work: keep secrets and pricing/licensing decisions server-side, issue short-lived scoped tokens instead of permanent keys, use platform attestation (Play Integrity, App Attest) where the risk justifies it, and assume your client’s behaviour is fully observable when you design abuse controls. This is the mirror image of this site’s agent-readiness lesson: there, the point was that agents read your website’s machine-facing surface whether you designed it or not; here, agents read your app’s binary the same way. In both cases the winning move is to decide deliberately what the machine-facing surface says.

Legitimate uses — and the boundaries

Reverse engineering has honourable, established uses, and REA’s own documentation names the same list: analysing your own software (including the copy whose source you lost), security research and vulnerability analysis, malware and incident investigation, interoperability — making your product work with another — CTF competitions, and education. In many jurisdictions some of these are protected even against a licence clause that purports to forbid them, particularly interoperability and good-faith security research, though the details vary and this article is not legal advice.

The boundaries are just as clear. An MIT licence on the tooling is not a licence on the target: it does not authorise cloning a competitor’s product from its binary, defeating DRM or licence enforcement, or distributing what you extract. The clean-room loop in the previous section exists precisely to keep a rebuild on the right side of that line — behaviour and evidence, not copied implementation. This site’s own analysis tools take the same line in miniature: static, local, read-only, no execution, no circumvention — a first look, with the heavy and legally sensitive work left to tools and people who can take responsibility for it.

Try it yourself

REA needs Node.js 22 or later; one command — npx rea-agents setup — registers its MCP server with the coding agents it finds and installs the matching workflow instructions, and REA’s own doctor command checks each engine (a native engine such as Ghidra must be installed for native binaries; JADX covers APKs). Point it at software you own or a sample you are allowed to inspect — a small utility you wrote is the perfect first target — and ask it how one feature works. Read the spec it produces before you read any pseudocode: the evidence links are where the truth is.

If you want the zero-install version of the first step, that is what this site’s Binary File Inspector is for: drop a PE, ELF or Mach-O file into the page and read its headers, sections, imports and strings in your browser — no upload, no execution, no toolchain. It will not decompile anything, and it says so; it is the five-minute triage that tells you whether the full REA treatment is worth setting up, and for which engine.