Reverse Engineer Anything
REA gives AI agents a common interface for investigating software - from a website's behaviour to an Electron bundle or native binary - while keeping evidence, coverage and unknowns attached to every conclusion.
Reverse engineering usually means assembling a difficult toolchain: one program for decompilation, another for strings and references, browser tooling for runtime behaviour, and a notebook to separate facts from guesses. REA - short for Reverse Engineer Anything - turns that fragmented process into a shared interface that an AI agent or a person can query.
The project is not a universal AI decompiler. It is an orchestration and evidence layer. REA exposes specialised analysis workflows through one local MCP server and the same command-line interface, routes each target to an appropriate provider, then returns structured findings that preserve what was observed, what remains incomplete and which tool produced the result.
That distinction is the reason the repository matters. An agent can move from a product-level question - “how does this feature work?” - toward scripts, IPC boundaries, functions, calls and instructions without pretending that decompiled pseudocode is original source. REA makes the investigation agent-native; it does not make uncertainty disappear.
How REA works, from question to reconstruction
1. Setup connects the agent, the skill and the local server
The recommended command is npx rea-agents setup. It proposes changes, lets the user choose supported clients, backs up existing configuration and registers REA as an MCP server together with matching investigation instructions. After a restart, an agent such as Codex, Claude Code, Cursor or Gemini CLI can discover the workflows. The CLI remains available independently for direct inspection and scripting.
2. The target determines the workflow
REA first distinguishes what is actually being examined: a native executable, JavaScript or Electron application, .NET assembly, website, APK, firmware image, SQLite database, packet capture, recorded crash or running process. That routing matters because these are not interchangeable evidence sources. Static JavaScript inspection can read supplied files without executing them; observing a live application or browser has different permissions and side effects.
3. Specialist engines do the underlying analysis
For deep native work, REA can coordinate Hopper, Ghidra, IDA or Kuna; it also supports narrower providers and built-in parsers for other formats. Web investigations attach to a Chrome-family debugging endpoint, Android analysis can use JADX or adb, and JavaScript workflows can recover modules, imports, routes, source maps, Electron IPC and native add-on boundaries. REA provides the common contract, not one algorithm that replaces every engine.
4. Every useful result becomes Evidence
An evidence-producing operation returns a canonical record with an identity, the normalised result, provider context, analysis profile, coverage and limitations; raw provider output is retained when it exists. The important idea is semantic honesty. An empty list is not treated as proof that nothing exists when collection was incomplete, and a missing decompiler facet remains unknown instead of becoming a confident conclusion.
5. The agent traces a feature instead of dumping an entire program
A useful investigation starts with a question. For a native feature, the agent might search strings, identify a relevant procedure, inspect callers and callees, decompile the function and compare the result with assembly. For an Electron app, it can follow a renderer API through preload and IPC into the main process. For a website, it can combine DOM structure, scripts, network observations and selected screenshots. Each follow-up narrows the evidence chain.
6. Large analyses are retained, then viewed in smaller slices
Real applications can produce evidence far too large for one model response. REA keeps the complete session record and exposes summaries, pages and focused views without repeating the analysis. Its documentation gives a useful scale example: a 334 MB Obsidian application record can be projected into a summary of roughly 10 KB. Complete bundles can also be exported for transfer, audit or later comparison.
7. Static and runtime observations can be reconciled
Static inspection explains what an artifact contains; runtime observation shows what happened in one bounded execution. REA keeps those authorities separate, then provides workflows for correlating them. That avoids a common reverse-engineering error: treating code that exists as code that definitely ran, or treating one observed run as proof that no other path exists.
8. Comparisons preserve uncertainty instead of flattening it
REA can compare functions, artifacts, process captures, browser scenarios and saved application evidence. A comparison only claims equality where both sides have compatible and complete coverage. Missing graph members, unavailable facets or unresolved calls remain gaps. This makes the system useful for regression analysis and version-to-version investigations, where an apparently empty diff can otherwise be dangerously persuasive.
9. The agent can turn findings into a tested reconstruction
After understanding the behaviour, the agent may write a new implementation adapted to the user's project and test it against the observed contract. REA's showcases illustrate the pattern: reconstructing DX-Ball's sound-pan calculation, tracing Notion's Electron clipboard bridge and recovering a 16-bit bullet-ring calculation from Touhou 4. The tool supplies evidence; engineering judgment still decides what should be built.
10. The safety boundary is part of the architecture
Analysis runs locally, but results sent to an AI agent remain subject to that model provider's data policy. REA marks target-derived text as untrusted so embedded instructions are treated as data rather than commands. Runtime, browser, network and device workflows can alter state or expose sensitive material, so the project explicitly limits its intended use to lawful, authorised research, interoperability, preservation, education and analysis of software you may examine.
REA's most important contribution is not that it puts an AI label on Ghidra or Hopper. It gives agents a disciplined way to choose tools, retain provenance and keep unknowns visible across a long investigation. That turns reverse engineering from a sequence of disconnected outputs into a reproducible conversation with the artifact.
The repository will be most valuable where understanding matters more than imitation: auditing a dependency, documenting a legacy system, investigating malware in a controlled environment, testing interoperability or recovering the contract behind a feature. It lowers the coordination cost of expert tools. It does not grant permission, restore original source code or remove the need for a human to verify consequential conclusions.
Explore the source
- morluto/rea on GitHub
The official REA source code, setup instructions, technical documentation, issue tracker and releases.
Where we track this
- What an AI agent harness actually does →
Why tools, memory, permissions and verification - not only the model - determine whether an agent is useful.
- Coding agents still need a verification gate →
A complementary look at where AI can accelerate technical work and where evidence must remain in charge.
- Explore the TaskNorth AI tool library →
Compare practical AI tools by the task you need to complete rather than by model hype.
Questions people ask
- What is Reverse Engineer Anything (REA)?
- REA is an MIT-licensed local CLI and MCP server that connects AI agents to workflows for inspecting binaries, applications, websites and runtime behaviour. It coordinates specialised tools and returns structured Evidence rather than relying on the model to guess from an opaque artifact.
- Is REA an AI decompiler?
- Not by itself. For native binaries, REA can orchestrate decompilers and analysis providers such as Hopper, Ghidra, IDA or Kuna. It adds a common interface, evidence contracts, session retention, comparisons and agent instructions around those engines. Other target types use their own parsers or runtime providers.
- Does REA upload the application being analysed?
- REA says target analysis runs locally. If an AI agent is controlling the investigation, however, the findings returned to that agent are processed under the agent model provider's own data policy. Sensitive targets therefore still require an appropriate provider, configuration and authorisation.
- Do I need Ghidra, Hopper or IDA to use REA?
- Only for deep native-binary analysis. Static JavaScript and Electron artifact analysis, .NET metadata and CIL inspection, and several other workflows do not require a native decompiler. Exact prerequisites depend on the target and operating system.
- Is reverse engineering with REA legal?
- That depends on the target, your rights, the licence, the jurisdiction and the operation. REA is intended for authorised activities such as security research, interoperability, preservation, debugging and education. Its documentation rejects bypassing DRM, authentication, anti-cheat or licensing controls and copying proprietary software. This article is not legal advice.
- How do you install REA for an AI agent?
- The project's recommended setup command is npx rea-agents setup. Review the proposed configuration changes, select the intended agent clients and analysis providers, approve only the scope you want, and restart the agent afterward. Requirements vary by workflow; use the official morluto/rea repository and rea.tools documentation.
Written 15 October 2026 from the official morluto/rea repository (github.com/morluto/rea), its documentation at rea.tools and release rea-agents v6.5.0, published 14 October 2026. The repository was reviewed at main commit 2202e3f. The architecture description was checked against README.md, docs/mcp-contracts.md, docs/cli.md, docs/browser-observation.md, docs/javascript-artifact-reconstruction.md, docs/native-investigation.md, docs/installation.md and DISCLAIMER.md. Primary-source claims retained: REA exposes shared CLI and MCP workflows; analysis runs locally; native providers include Hopper, Ghidra, IDA and Kuna; static and runtime workflows have different effects; canonical Evidence records retain coverage and limitations; large retained results can be projected into smaller views; target-derived content is marked untrusted; and the official showcases cover DX-Ball, Notion and Touhou 4. Corrective framing: REA is not presented as a universal AI decompiler, a way to recover original source code, or permission to copy a product. It orchestrates different engines whose availability and coverage vary, decompilation and inference can be wrong, runtime operations can affect the target, and model-provider data policies still apply to findings an agent receives. The GitHub star count was deliberately omitted because it changes rapidly and says nothing about analytical accuracy. TaskNorth has no commercial relationship with REA, its maintainers or the named analysis-tool vendors. This article is editorial analysis, not legal or security advice.
Trying to work out which AI tools fit your task? Describe the outcome and get a Blueprint: the tools, the prompt, and the steps, with pricing we verified ourselves.