REA (Reverse Engineer Anything) GitHub Repo: What It Does and How to Use It

You've got a compiled binary and no source. Maybe it's your own build from a contractor who left, a CTF challenge, or a suspicious sample you were handed to triage. The question "what does this thing do?" used to mean a week in a disassembler. REA, the "Reverse Engineer Anything" repo, wraps those disassemblers in an MCP server so a coding agent like Claude Code can do the legwork and show its evidence.

This post is based on the repo's own README, DISCLAIMER, SECURITY policy and MCP contract docs, fetched on 2026-10-23, plus the npm registry entry. I did not install or run REA for this post. Where I describe a workflow below, it is a labelled template, not a captured session.

What is REA and what does the repo say today?

REA's GitHub description reads "Reverse engineer anything with agents, from app behavior down to native binaries." The README calls it "one MCP for reverse engineering across binaries, applications, and runtime behavior." The same tools are available from a terminal through a rea command.

What the repo page showed when I fetched it on 2026-10-23 (the fetch tool summarises the page, so verify by looking yourself):

The star number deserves a warning. Press and fact-check articles in October quoted figures from the low thousands up to 234,477 on 14 October, and they disagree with each other because the repo was growing fast and each writer took a snapshot. I could not read the GitHub API (it returned 403 to my fetcher), so treat any star count, including mine, as "reported at a moment in time." The fork count of 92.8k is unusually high relative to watchers, which is also a reason to be careful about copies (more on that in the supply-chain post).

How does REA work?

The architecture as documented is simple. Your agent calls REA over MCP. REA inspects the target and traces relevant code. It returns findings with their evidence and limitations. The agent then explains the behaviour, answers follow-ups, or writes and tests code. If MCP is new to you, start with what the MCP protocol is.

A few design choices from docs/mcp-contracts.md that matter in practice:

• Evidence and unknowns are first-class. There are tools such as get_evidence_bundle, export_evidence_bundle, list_unknowns and record_unknown. The idea is that the agent logs what it saw directly, what it inferred, and what it could not determine.
• Untrusted target content is tagged. Results that carry text from the target include _meta.provenance with untrusted_content: true, and agents are told to treat that text as data, not instructions. This matters because a malicious binary can contain strings written to hijack your agent. See prompt injection for tool-using agents.
• Static versus runtime. Per the docs, static tools do not execute the target. analyze_javascript_application reads files without running the app, and read_bytes reads analysis memory, not a live process. Runtime tools such as capture_process_scenario and capture_browser_scenario do run foreign code and are marked with destructiveHint.
• Annotations are hints, not permission. The docs say plainly that REA has no per-call approval flags. Your MCP client controls confirmation prompts.

Example tool names listed in the contract page include binary_overview, analyze_function, get_call_graph, list_strings, inspect_artifact, trace_application_feature and inspect_apk_signature. The README does not list every tool; it links to a generated catalogue.

Which tools does REA wrap?

REA is a conductor, not a decompiler of its own for the heavy lifting. Per the README:

• Native code: Hopper, Ghidra and IDA for pseudocode, assembly, strings, symbols and references. Kuna, GNU objdump and Rizin are supported for offline inspection, and you supply those yourself.
• Android: JADX (needs a JDK), Apktool, JEB and adb.
• Network and signals: TShark, mitmdump, sigrok-cli.
• Firmware and formats: Binwalk, Unblob, WABT, plus built-in parsers for formats such as .NET, PE, ELF, Go, Rust, GGUF and safetensors, Godot PCK, IL2CPP metadata and BEAM.
• Web: a Chrome-family browser for live page behaviour.

Requirements are Node.js 22.x (22.23.4 or newer), 24.x (24.22.1 or newer) or 26.12.1 and above, plus npm. Many Linux workflows need extra system tools. Ghidra and IDA use your existing install, and the README says you must be licensed for IDA Pro, Hopper and JEB.

How do you install REA?

The README gives these commands. I have not run them.

npx rea-agents setup

Setup asks which agents to configure, shows the changes it proposes, and backs up existing config before applying them. Restart your agent afterwards. For the CLI:

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

Read what setup wants to change before you approve it. It registers an MCP server and adds workflow instructions to your agent config, which means every project that agent opens can call REA. If that makes you uneasy, good. Install it in a separate agent profile or a throwaway machine, as covered in the safety post.

A worked workflow: triaging a binary you are allowed to analyse

This is a template, untested, showing how I'd structure an engagement. The legitimate cases are: your own build, a CTF challenge, a malware sample in an isolated VM, or a file format you're entitled to inspect for interoperability or documentation. The project's own disclaimer lists the same cases and prohibits circumventing DRM, licence checks and anti-cheat, so this post doesn't go there.

Step 1: set the scope in writing. Put it in the first prompt so the agent has a boundary.

Target: /analysis/sample01 (a Linux ELF I built from my own source last year;
the source is lost). Goal: document what network connections it opens and what
files it writes. Do not run the binary. Static analysis only. For every claim,
label it SEEN (directly in disassembly or strings), INFERRED, or UNKNOWN, and
cite the address or string. Record unknowns with the unknowns tool.

Step 2: overview first. Ask for a binary_overview-style summary: format, architecture, imported functions, interesting strings. Imports like socket, connect and fopen narrow the search more than any amount of decompiled code.

Step 3: follow one thread. Pick one behaviour ("where does it build the URL?") and have the agent trace the call path to it. Ask for the call graph and the strings that feed it.

Step 4: verify the claim yourself. For every SEEN claim that matters, open the address in Ghidra or Hopper and read the assembly. If the agent says a function at an address does X and the disassembly shows something else, you've found a hallucination before it reached your report.

Step 5: only then consider runtime capture. Running the target is a separate decision. For anything untrusted, do it in a disposable VM with no credentials and restricted network egress. REA's runtime scenario tools declare the executable, arguments and cleanup they will use, but SECURITY.md says plainly that REA is not a sandbox.

Step 6: export the evidence. Save the evidence bundle and your own notes. If the work feeds a re-implementation for interoperability, keep the analysis notes and the implementation work separated by a written specification, which is the idea behind clean-room practice (covered in our legal overview).

Where does AI-assisted reverse engineering fail?

The disclaimer itself says analysis output, including AI-assisted results, may be incomplete or wrong. In practice, expect these failure modes:

• Invented names. Stripped binaries have no function names. A model will happily call sub_401a30 "decrypt_config" because the surrounding strings look plausible. Treat any name the agent coins as a guess until you've read the code.
• Decompiler errors passed on as facts. Pseudocode from any decompiler can get types, loop bounds and calling conventions wrong. A model reasoning over wrong pseudocode compounds the error confidently.
• Context limits. Large binaries have thousands of functions. The agent sees a slice, so claims like "this program never touches the network" are only as good as what it actually searched.
• Packers and obfuscation. Static tools see the packer stub, not the payload. An agent may describe the stub with total confidence.
• Hostile input. A sample can carry text aimed at your agent. REA tags untrusted content, but your client and your habits still decide what happens next.
• Rights, not just facts. The disclaimer notes that obtaining analysis output grants no rights to the original program.

A cheap discipline that helps: require the SEEN, INFERRED, UNKNOWN labels, and reject any SEEN claim without an address.

Is REA worth using? A verdict

Use it if you already do reverse engineering and want a faster first pass: triage, orienting yourself in a big binary, documenting your own legacy builds, CTF practice, or APK and Electron app review for apps you own. The evidence-and-unknowns design is the right idea for a tool whose main risk is confident nonsense.

Skip it if you hoped for push-button "recover the source" magic (it doesn't exist), if you can't install and license the underlying tools, or if you won't isolate it. The star count tells you it is popular. It doesn't tell you it is safe, correct, or suited to your threat model, and I haven't audited the code.

Two practical cautions. First, confirm you have the official repo and package before you install anything, because a fact-check article reports a trojanised copy circulated; the verification checklist walks through it. Second, running an agent against a model API costs tokens on long traces; if you pay in rupees, AICredits offers INR billing via UPI, which is one option among several.

Disclosure: the AICredits link is an affiliate link.

For the model-side risks of giving an agent tools, see the MCP security checklist.

Sources checked

• REA README, DISCLAIMER.md, SECURITY.md and docs/mcp-contracts.md on github.com/morluto/rea (main branch), fetched 2026-10-23.
• npm registry entry for rea-agents, fetched 2026-10-23 (the response was truncated, so I only read part of it).
• MindStudio's article on the repo, dated 2026-10-14, which describes a five-stage workflow and does not give install steps or star counts.