How REA works: reverse engineering with agents (Oct 2026)

REA, short for Reverse Engineer Anything, lets an agent investigate software when the original source is unavailable. It connects existing analysis tools to the agent through the Model Context Protocol, or MCP. REA is not itself a replacement decompiler. Native analysis can use Hopper, Ghidra, or IDA; JavaScript analysis follows a different path.

The difficult part of an investigation is often deciding what to inspect next. A string may lead to a reference, a reference to a caller, and a caller to the function that explains the behavior. A useful answer must retain those links so another person can check them. REA combines tool access with workflow instructions and findings that include evidence and limitations. REA overview.

For DeepSeek users, the relevant question is whether their chosen agent client can expose REA's MCP tools to the model. REA does not change the model's API configuration. For installation details, see our REA MCP setup guide.

A typical native investigation starts with an inventory of the target, then narrows to a function or behavior. The agent can inspect strings, references, calls, assembly, and pseudocode. The next query should follow a finding from the previous one.

Pseudocode is a starting point. If its function signature or arithmetic looks incomplete, the instruction view and callers can clarify what the decompiler missed. Use exact names or addresses returned by the tool. Do not assume a target contains a function named main or entry.

Static references describe relationships in the analyzed artifact. They do not by themselves establish which path executed during a particular user action. Runtime observation is a separate source of evidence. Native investigation documentation.

This division explains why installing an MCP server does not remove an engine's limitations. It also explains why replacing an engine can leave the agent's broader investigation method intact. The table is an editorial model for reviewing a session, rather than a literal list of REA source directories.

Static analysis and runtime observation answer different questions

For JavaScript applications, REA can retain module relationships and source locations in an application graph. Its documented follow-up workflows can inspect that evidence, trace a feature, or compare versions. These operations do not automatically execute the application or attach to a live process. An inferred relationship, a source observation, and a runtime observation retain different authority.

That distinction matters when a graph is incomplete. An empty result does not prove that a behavior is absent if the relevant part of the application was never analyzed. JavaScript workflow documentation.

No. Choose the analysis path from the artifact's contents and the question you need to answer.

The wider project also covers targets such as SQLite snapshots, network captures, and firmware. A supported target category does not mean every operation works on every platform. The official target catalog lists the relevant prerequisites.

npx rea-agents setup

Setup registers the MCP server for selected clients and installs matching workflow instructions by default. It previews the changes, asks for approval, and backs up existing configuration. Analysis engines have their own requirements; an optional Hopper installation has a separate approval step. Restart the affected agent after setup.

The documented clients include Claude Code, Codex, Cursor, Gemini CLI, and Grok Build. Exact features depend on the installed package and connected server. Repository main and the package published to npm can differ.

Use scoped diagnostics to check the provider or client you intend to use. A successful doctor report checks files and prerequisites; it does not prove that the active agent session has connected. Confirm that the session can see the tools and complete a small inspection. Installation and readiness checks.

DX-Ball: a function checked against its original

The sound-pan reconstruction for DX-Ball 1.07 is a useful example of evidence followed by validation. REA exposed the instructions, caller, and constants. The maintained C function was then compared with the original x86 function in 3,205 behavior cases. A pinned VC4.0 compiler replay matched 63 bytes after reviewed relocations and constant checks.

Those checks apply to the sound-pan function. They do not establish that the entire game has been reconstructed. DX-Ball case study.

Notion: following a feature across Electron processes

The Notion Desktop 7.6.1 example traces a clipboard method through its preload wrapper and IPC channel to the main process and Electron's clipboard writer. Source locations and matching channel names connect the steps. The study distinguishes inspection of packaged code and saved probes from a captured live desktop session. Notion case study.

TH04: recovering an angle calculation

The Touhou 4 study follows a 16-bit DOS helper into the C++ reconstruction of a bullet ring. It separates the instructions returned by REA from compiler checks supplied by the reconstruction project. That separation makes the result easier to assess: analysis evidence and reconstruction validation have different sources. TH04 case study.

Other examples mentioned in the Chinese article

The Tencent article also reports a Sony Sound Connect wind-noise-control app and community projects involving home IoT software, a television, and a Xiaomi scale. Its shooter example reports 99% function recovery and 83% byte matches, but explicitly used Hex-Rays MCP, not REA. These remain attributed reports, rather than results independently reproduced for this guide. Tencent article.

Before accepting a reconstruction, ask for a record that lets someone else repeat the reasoning. The following is our suggested review checklist.

1. Identify the target. Record the artifact version or hash, engine, and analysis scope.
2. Locate the evidence. Retain the function address or file and source range behind each material claim.
3. Separate observation from interpretation. Explain what the tool returned and what the agent inferred.
4. Test the behavior. Compare representative inputs and edge cases with the original, where you can do so.
5. Record the remaining gaps. Missing code, unresolved calls, and unobserved runtime paths belong in the result.

For large JavaScript targets, retain the complete evidence separately and request a bounded summary or module view. The CLI documentation warns that application evidence can be very large; sending the whole record into a conversation can obscure the useful findings. CLI and Evidence documentation.

Suggested prompt, not a measured test:
Inspect this authorized local target and explain one feature.
For each conclusion, give its address or source location.
Separate static observations, inferences, and runtime checks.
List unresolved questions before proposing a reconstruction.
Describe how we could compare it with the original.

REA can make an investigation easier to start and review. It cannot make inaccessible evidence appear, repair every decompiler error, or guarantee that a plausible reconstruction behaves like the original.

The Chinese article identifies heavy obfuscation, anti-debugging, virtualized protection, and kernel or driver analysis as difficult areas. Treat these as reasons to investigate the provider's actual capabilities and the required runtime tooling. A bridge alone does not resolve them.

Use targets you own or are authorized to inspect. The article places the work in research, interoperability, education, and software preservation. Its broader technical point is useful: an agent can carry out more of the investigation when tool operations and evidence are structured. A person still has to decide whether the evidence answers the original question.

For a first installation and a smaller example, continue with the REA MCP setup guide.

For DeepSeek coding, compare available Coding Plans on our Pricing page while stock lasts.