REA: how to do reverse engineering with AI

Reverse engineering has a bad reputation for one specific reason: it gets confused with bypassing protections. Reverse engineering software you own or are authorised to analyse is something else: it is the practice of understanding how a system works in order to maintain it, interoperate with it, recover knowledge or teach. REA (Reverse Engineer Anything) brings that practice into the workflow of an AI agent.

It is not a new decompiler or a button that explains applications. It is an orchestration layer: a CLI and an MCP server that give the agent tools to inspect binaries, Electron applications, .NET assemblies and websites, and return the findings with the evidence and limits that go with them. That difference (evidence versus a plausible story) is what makes it worthwhile.

What exactly REA is

Verifiable facts as of 26 October 2026: it is distributed as the npm package rea-agents (version 6.8.0), under the MIT licence, with its repository at morluto/rea and its website at rea.tools. It requires Node.js 22.x (>= 22.23.4), 24.x (>= 24.22.1) or 26.12.1+, plus npm.

Its README describes it as an MCP for reverse engineering binaries, applications and runtime behaviour. In practice, the agent requests an inspection, REA runs local tools and returns code, references and gaps. The agent uses that to explain the behaviour or to write an implementation and test it.

What it is not:

• It is not a decompiler of its own. For deep native analysis it uses Hopper, Ghidra or IDA as providers.
• It is not a cloud service. The analysis happens on your machine.
• It is not an authorisation. Being able to analyse something does not mean you have the right to.
• It is not infallible. It also returns what it does not know, and you need to read that.

How it works: agent, MCP and evidence

MCP is the standard that lets an agent discover and call external tools. REA exposes its catalogue over MCP and the agent decides which tool to use depending on the question.

The loop is simple: the agent asks, REA inspects, the agent receives a structured result, forms a hypothesis and asks for a new check. The important part is the last one: the result includes evidence and limitations. It is not a black box that says "this app uses IPC"; it tells you in which file, which fragment and with what confidence.

It helps to distinguish two modes:

• Static inspection: reads files without running the application. This is the case for JavaScript, .NET, APK metadata, binary headers or model artefacts.
• Runtime observation: runs or interacts with the target using your permissions. It is useful for capturing traffic, process behaviour or web sessions, but it can modify state.

My reading: the evidence is the real product. Most agents fail at technical analysis not for lack of capability, but because they fill gaps with plausible explanations. A report that separates fact, inference and unknown can be audited; one that only sounds confident cannot.

What can be analysed

The project's list is broad. These are the groups that matter most for real work:

• JavaScript and Electron applications: modules, imports, source maps, routes, IPC and the relationship with native addons. No native engine needed.
• Native binaries: pseudocode, assembly, strings, symbols, calls and references. Needs Hopper, Ghidra or IDA.
• .NET assemblies: metadata, CIL instructions, declared native dependencies and build comparison. It is static.
• Websites: page structure, scripts, network observations and screenshots. Requires a Chrome-family browser.
• Android: APKs with JADX and a full JDK; APK signatures without an engine; resources with Apktool; Flutter apps with static analysis.
• Firmware, network captures, packages, SQLite, recorded crashes, GPU objects and WASM artefacts, among others.

There are also formats it handles without installing anything: Go binaries (compiler version, modules and build settings), Rust binaries with cargo-auditable, Unity IL2CPP metadata, Godot PCK files, PE certificates and imports, ELF notes and Linux kernel modules.

Not everything works the same on every system. On Linux, some features (Ghidra, JADX, firmware and static JavaScript analysis) need a procps-compatible ps on the PATH. On Windows and macOS there are limits per provider. The installation documentation is the source of truth.

Installation and first inspection

The official way to start is:

npx rea-agents setup

The installer asks which agents to configure, shows the proposed changes and asks for approval. It adds the MCP server and the working instructions, backing up the existing configuration. Then you need to restart the agent.

The setup recognises Claude Code, Codex, Cursor, Gemini CLI, Grok Build and other agents; any client with local MCP can be registered by hand. For Hopper it offers an optional installation, always with approval.

If you need reproducibility, pin the version you verified:

npx rea-agents@6.8.0 setup

For an inspection from the terminal, without an agent:

npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/the/app --json

Replace the path with the one for your copy. On Windows, for example, D:/apps/example. The result includes modules, imports, Electron boundaries and their evidence.

If you are going to use it often, install the global command and keep it up to date:

npm install --global rea-agents
rea --help
rea update

And a typical request to the agent, with a closed scope:

Analyse this desktop app, which I own and which is in ./target. I want to understand
how it implements local search. Return the evidence, what you cannot
determine and a plan to replicate the feature in ./my-project. Do not modify
anything outside ./my-project and do not run the app.

Evidence: the report you can argue with

The README insists that the results include the evidence and limitations of each conclusion. That translates into three questions you should always ask:

1. Which file, instruction, route or capture supports this claim?
2. Which part is the agent's inference and not direct observation?
3. What additional test would confirm or refute the hypothesis?

An example from the project itself: in the Notion case, REA follows the renderer's clipboard API, goes through the preload and IPC to the main process, and inspects the rich format. It is not enough to say "it uses Electron"; the value is in the specific chain.

In native binaries, the typical answer includes pseudocode and assembly. There, the evidence is the address, the instruction and the cross-reference. If the agent writes an implementation without citing any of them, you do not have an analysis: you have a hypothesis with good prose.

A workflow that stands up to review

1. Define the scope in writing: which software, which question and what is out of scope.
2. Keep a copy and record its hash or version. Without a baseline you cannot compare or reproduce.
3. Ask a falsifiable question. "How does the app work?" is no good. "Which route does the renderer use to write to the clipboard?" is.
4. Start with static analysis. Run the target only when the question requires it, and in a disposable environment.
5. Ask for evidence and limits at every step, not just the conclusion.
6. Reproduce the finding on a clean copy. If it does not reproduce, it is not verified.
7. Separate fact, inference and unknown in your notes. That is the difference between a report and an opinion.
8. Document what you could not resolve. Gaps are results too.

If you work with versions, keep snapshots and compare them. An important part of reverse engineering is not discovering a function, but understanding what changed between two builds and why.

Limits, costs and risks

• Native providers: Hopper, Ghidra and IDA are tools with their own licences. REA grants no licences, keys or activations. Large binaries may need the provider's start-up timeouts raised.
• Node and system: the supported versions are not a detail. An old Node breaks the installation; on Linux, missing procps breaks specific features.
• Privacy: the analysis is local, but the agent receives the results and its model provider applies its own data policy. "Local" does not mean "nothing leaves your machine" if the model is remote.
• State of the target: runtime capture interacts with the application. It can write files, open sessions or leave traces. Use a virtual machine or a copy and document the changes.
• Quality: packed binaries, obfuscation or anti-analysis protections can block the work. A good report says so instead of making things up.

There is an advanced feature worth mentioning without exaggerating: REA can turn recorded requests and responses from a website into an executable environment for agents, with AgentEnv and Docker. It is meant for evaluation and reinforcement learning, not for attacking the original site.

The legal and ethical line

The project itself makes this clear in its disclaimer: REA is for lawful research, education, interoperability, software preservation and analysis of software you own or are authorised to examine. It also says that cracked copies, stolen keys and circumventing licence restrictions are not authorised.

That translates into practical rules:

• Work on software you own or with written authorisation. If it belongs to a third party, set out in writing what you may and may not do.
• Do not circumvent DRM, licences or access controls. This article does not teach that and the tool does not legitimise it.
• Do not extract personal data, trade secrets or credentials. Minimise and delete captures when you finish.
• Interoperability has a different legal framework in each jurisdiction. If the case is commercial, review it with a lawyer.
• Respect the terms of service and users' privacy. A technical finding does not remove a legal obligation.

REA's MIT licence covers the project's own code. Third-party tools and bundled materials keep their own licences. And no REA licence gives you rights over the software you analyse.

When not to use REA

• When the documentation, the repository or the ticketing system already answers the question.
• When opening the browser's developer tools is enough.
• When you are not authorised to analyse the target.
• When you need a legal guarantee, not a technical finding.
• When the question is how to bypass a protection. That is out of scope.

What you really learn

Reverse engineering with agents is not just for copying a feature. It is for reading architecture, comparing versions, recovering abandoned software, preparing interoperability, researching security and teaching how systems are built.

The cases published by the project point in that direction: reconstructing a sound panning calculation in DX-Ball from x86 instructions, following Notion's clipboard bridge through Electron, or recovering an angle calculation in a PC-98 game. They are exercises in understanding, not appropriation.

If you want to go further, the site has a glossary with MCP, tool calling and agents; a path on agent systems for the wider context; and tools, prompts and the Radar to follow the ecosystem. And if you come from agent design, the article on AI agents in production explains why evidence and limits are not decoration.

Keep reading

• Reverse engineering with AI: how to understand a feature and build your own version with REA: a hands-on case with REA.
• AI agents: how to design one that does not fail in production: evidence, limits and traces in agent design.
• Prompt injection: the risk of AI obeying someone else: why analysed content should never give the agent orders.

Sources

• npm package: https://www.npmjs.com/package/rea-agents (version 6.8.0, MIT licence)
• Repository: https://github.com/morluto/rea
• Website and guides: https://rea.tools/
• Installation: https://github.com/morluto/rea/blob/main/docs/installation.md
• CLI and evidence: https://github.com/morluto/rea/blob/main/docs/cli.md
• Usage disclaimer: https://github.com/morluto/rea/blob/main/DISCLAIMER.md
• Licence: https://github.com/morluto/rea/blob/main/LICENSE
• Cases: https://rea.tools/showcase/

Verified on 26 October 2026 against version 6.8.0 published on npm, the repository README and the official documentation. Requirements and capabilities may change between versions: check the version you install.