REA: how AI agents connect reverse-engineering tools

REA is not a new universal decompiler. Its differentiator is bringing agents, CLI, MCP, workflows, sessions, evidence, and specialized tools into one shared flow.

When I first saw REA, one thing seemed more interesting than the promise to “reverse engineer anything”: it brings together tools that already existed.

Ghidra, Hopper, and IDA analyze native binaries. JADX and Apktool work with Android. GDB, pwndbg, and pwntools help with processes, ELF files, and crashes. TShark and mitmproxy observe traffic. WABT inspects WebAssembly. Frida instruments running applications. The challenge is that a real investigation crosses several of these surfaces.

Some time goes into understanding the target. Another part goes into moving addresses, pseudocode, captures, and hypotheses across tools and remembering why each finding mattered. REA tries to reduce exactly that friction.

What REA is — and what it is not

The architecture becomes clearer when we separate four roles. The developer defines the question and scope. The agent chooses next steps and interprets results. REA exposes CLI and MCP, discovers providers, maintains sessions, normalizes responses, and preserves evidence. Specialized tools perform decompilation, assembly, references, application inspection, capture, or runtime analysis.

1question and scope2  → agent and model3    → REA: CLI, MCP, workflows, sessions, and Evidence4      → specialized providers and analyzers5        → authorized target67evidence, hypotheses, implementation, and tests return through the flow

Saying REA replaces Ghidra, Hopper, or IDA would be inaccurate: deep native analysis still depends on those providers. Calling it only a thin wrapper would also be incomplete. The project has built-in or embedded analyzers for some domains, including JavaScript and Electron, .NET/CIL, Go binary metadata, SQLite, and artifact inventory.

How an investigation can unfold

1. Define the authorized target, question, and analysis boundary.
2. Identify which providers are available for that format or platform.
3. Locate candidate strings, symbols, functions, modules, or behaviors.
4. Follow calls, references, and boundaries across processes or layers.
5. Record addresses, hashes, excerpts, limitations, and unknowns.
6. Propose an explanation or implementation without mistaking it for the original source.
7. Compare the result with observed behavior and expand the tests.

CLI and MCP use the same workflows. This makes it possible to start an inspection in the terminal, produce structured results, and continue the investigation with an agent. Snapshots, versions, hashes, and providers make the path easier to repeat — provided the team actually records them.

Evidence is the most interesting part

Models are good at producing plausible explanations. Reverse engineering requires explanations supported by artifacts. REA’s Evidence model tries to keep this distinction visible by carrying origin, operation, address or excerpt, confidence, limitations, and relationships to other evidence.

• Observed: came directly from the artifact or a specific execution.
• Inferred: a consistent interpretation that was not directly observed.
• Derived: combines other evidence or results.
• Unknown or unavailable: the tool could not support the conclusion.

Evidence does not eliminate hallucinations. It creates a structure for confronting them. Incomplete pseudocode, static analysis, and a small test set still require review.

What the showcases actually demonstrate

In the DX-Ball 1.07 case, the investigation followed an audio call to the function converting position into panning. Because the initial pseudocode was incomplete, the caller, instructions, and constants had to be checked. The C reconstruction passed 3,205 cases against the original x86 function and reproduced all 63 compiled function bytes after relocations were accounted for.

The Notion showcase traces a clipboard feature through an Electron application: renderer, preload, IPC, and the main process. The Touhou 4 case analyzes 16-bit instructions from a PC-98 game, recovers angle calculations, and compares the C++ reconstruction with the historical compiler output.

These examples demonstrate narrow, evidence-backed, tested investigations. They do not show that any application can be turned into a complete clone with a single prompt.

Eight possible benefits of integration

• Less manual transport of addresses, references, and results across interfaces.
• Context continuity for follow-up questions.
• A flow that starts from a question instead of aimless navigation.
• Evidence, limitations, and unknowns attached to conclusions.
• Reproducibility through version, hash, snapshot, provider, and commands.
• Integration across JavaScript, IPC, native libraries, formats, and runtime.
• Workflows that support learning without replacing technical expertise.
• A shorter bridge between hypothesis, implementation, and differential testing.

Local-first helps, but it is not complete isolation

REA states that it analyzes targets locally. This prevents the application from being automatically uploaded to a service hosted by the project, but results sent to the agent remain subject to the model provider’s data policy. Strings, pseudocode, paths, metadata, and captures may contain sensitive information.

Local also does not mean sandboxed. Dynamic analysis may run or interact with processes, devices, networks, and files using the user’s permissions. Unknown artifacts require an appropriate environment, isolation, and explicit scope. Setup changes MCP registrations and installs agent instructions; its plan and backups should be reviewed before approval.

An ambitious and still young project

This article uses rea-agents 6.4.0, verified on October 13, 2026, as its snapshot. The repository includes extensive documentation, typed contracts, CI, a security policy, and many testing lanes. These are positive signs of internal engineering investment.

At the same time, the README itself warns that REA changes quickly and receives frequent fixes. A responsible demonstration should pin the REA and Node.js versions, agent and model, analysis provider, operating system, architecture, target hash, commands, snapshots, and tests used as the oracle.

REA, Adobe, and unproven associations

Recent attention around AI-assisted reverse engineering also included open-source projects for workflows associated with Adobe applications. In this research, I found no primary evidence that ArtCraft, PhotoCraft, or related projects used REA. They belong to a similar wave of agent-assisted development, but temporal coexistence does not establish causality.

The MIT license covering REA-authored code does not grant rights over the analyzed target, trademarks, assets, protected formats, or integrated commercial tools. Authorization and licenses remain separate concerns.

How I would evaluate REA without repeating the marketing

1. Choose an owned, open-source, or explicitly authorized artifact.
2. Write a narrow question whose answer can be verified.
3. Record version, environment, agent, model, provider, hash, and commands.
4. Run a manual baseline or use the specialized tool directly.
5. Repeat the investigation with REA and compare time, preserved context, and evidence quality.
6. Turn the conclusion into an implementation or test when appropriate.
7. Review false positives, unknowns, target changes, and permission effects.

That experiment remains a next step. My analysis here covers documentation, stated architecture, and public showcases — it is not a claim of independent hands-on product validation.

Conclusion

REA does not make every piece of software automatically copyable, and it does not turn a model into an infallible analyst. It does something more specific: it connects agents to mature tools, preserves context, organizes evidence, and brings investigation, implementation, and testing closer together.

This can reduce mechanical work and make conclusions easier to audit. It also requires discipline around authorization, versions, permissions, privacy, licenses, and validation. The tool does not remove the analyst; it changes where the analyst focuses attention.