What Is REA (Reverse Engineer Anything)? The MCP Server That Hit 115K GitHub Stars in a Week

REA: Reverse-Engineer Software with an AI Agent

REA, short for Reverse Engineer Anything, is an open-source MCP server and CLI that gives coding agents tools for analyzing software without access to its source code. Point Claude Code, Codex, Cursor, or another agent at a native binary, Electron app, .NET assembly, Android APK, website, or saved network capture. REA can return pseudocode, module graphs, request logs, and evidence for each finding. The agent can then explain the behavior or help rebuild it.

Try Apidog today

The morluto/rea repository was created in April 2026 and remained mostly unnoticed until the first week of October. By October 12, it had passed 115,000 stars and 25,000 forks, making it one of the fastest-growing repositories GitHub has seen. This guide explains what REA does, how to install it, where it works well, where the hype goes too far, and how its HAR and mitmproxy support creates a practical path from API reverse engineering to Apidog.

The numbers behind the hype

Trendshift’s daily tracking shows how quickly the project grew. REA first appeared on the trending list on October 4 with about 1,400 new stars in one day, then continued compounding for the following week.

Date	New stars that day
Oct 4	1,373
Oct 7	5,602
Oct 9	19,375
Oct 10	26,572
Oct 11	31,255

The repository held the number-one position on GitHub Trending for five of the seven days from October 6 to 12. Releases also moved quickly:

• Version 3.2: October 3
• Version 4.0: October 5
• Version 5.0: October 7
• Version 6.0: October 8
• Versions 6.1 through 6.4: October 9–11

That release cadence matters if you plan to automate against REA.

No single tweet or launch post explains the jump. The pitch did the work: “See a feature you like. Understand how it works, down to the binary level.” Demo videos of agents rebuilding desktop apps from binaries spread quickly, along with claims that software reconstruction was effectively solved.

A more useful interpretation is narrower: REA is a well-packaged connector between AI agents and reverse-engineering tools that already existed.

What REA does

REA runs as a local MCP server. Your agent calls REA’s tools, REA inspects the target with the appropriate engine, and the agent receives structured findings along with limitations and unknowns.

The same workflows are available through CLI commands, so you can also automate them without an agent.

The following table summarizes the target types listed in the README:

Target	What REA returns	Requirements
Native binaries	Pseudocode, assembly, strings, symbols, cross-references	Hopper, Ghidra, or IDA
Go binaries	Compiler version, modules, build settings	Nothing extra
JavaScript and Electron apps	Modules, imports, source maps, routes, IPC boundaries	Node.js only
Websites	Page structure, scripts, network observations, screenshots	A Chrome-family browser
Saved network captures	Requests, responses, payloads, source locations	HAR; mitmdump on Linux for mitmproxy
.NET assemblies	Metadata, CIL, native dependencies	Nothing extra
Android APKs and devices	Manifest, decompiled methods, logs, screen captures	JADX plus a JDK; adb
Firmware	Regions and extraction results	Binwalk or Unblob on Linux
WASM and EVM bytecode	Sections, imports and exports, dispatch selectors	WABT; Linux x64

Evidence and provenance

REA’s key design choice is its evidence model. Each result includes provenance such as:

• File digests
• Byte ranges
• JSON pointers into captures
• An explicit list of facts the analysis could not establish

Analysis runs on your machine. However, the agent’s model provider still receives the tool results, so that provider’s data policy applies.

How to install REA

You need Node.js 22.19 or later. Node.js 23 and 25 are unsupported. You also need npm.

Run the setup command:

npx rea-agents setup

The setup process shows a plan, backs up existing configuration, and writes changes only after you approve them.

According to the installation guide, REA supports Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf, Devin, OpenCode, Antigravity, GitHub Copilot CLI, VS Code, Grok Build, Hermes, and more. Select a client with the --client flag.

Restart your agent after setup, then try a focused prompt:

Understand how search works in the Notes app, show me the evidence,
and build a similar feature for my project.

To install the CLI globally:

npm install --global rea-agents
rea doctor --json

Static JavaScript, .NET, website, and capture analysis work without an additional analysis engine.

Deep native analysis requires one of the following:

• Hopper
• Ghidra 12.1 with JDK 21 or newer
• IDA

Setup can install Hopper with your approval, but Hopper is commercial software with its own license. Ghidra on Windows is marked experimental.

What REA is good at

The project’s case studies provide a better benchmark than broad “rebuild an entire app” demos.

In the DX-Ball study, the agent:

1. Followed a sound call into a position-to-pan helper.
2. Converted incomplete pseudocode into C.
3. Passed 3,205 original x86 test cases.
4. Reproduced all 63 compiled function bytes.

In the Notion study, it traced the clipboard API from the renderer through preload and IPC into the Electron main process.

Another example recovered a bullet-ring angle calculation from a 1990s PC-98 game’s 16-bit instructions.

The common pattern is important: each task asks a specific question about one function or data path and provides a way to verify the answer.

That is where agent-driven reverse engineering is most useful today. Whole-application reconstruction demos may produce something that resembles the target, but they do not necessarily reproduce its behavior. One early review that compared REA with a vanilla agent on a simple Mac app found the gap narrow and the REA run slower.

Use REA when the question is specific and the target is complex.

REA for API work: from capture to tested specification

REA is also useful for API reverse engineering. Its inspect_web_network_capture tool reads a HAR file or a native mitmproxy capture on Linux.

The tool:

• Reads captures offline
• Does not refetch recorded URLs
• Validates each entry
• Preserves request and response bodies with their digests
• Structurally excludes authorization headers, cookies, and URL credentials from the evidence

You can then pass the retained evidence to inspect_analysis_view with the api-surface view.

REA groups requests by:

• HTTP method
• Origin
• Inferred path template

It converts common dynamic values into placeholders:

• Numeric IDs become {numeric}
• UUIDs become {uuid}
• Long hexadecimal strings become {hex}
• Dates become {iso-date}

Each group cites the source records and flags mixed statuses or content types.

The capture guide makes an important limitation clear: this view does not claim to know the API schema or server handlers. It is an inferred inventory, not a formal specification.

That inventory is a useful starting point for the workflow described in our reverse engineering APIs guide. Apidog completes the workflow.

1. Capture the traffic

In Chrome DevTools, reproduce the user flow and save all requests as a HAR with content.

Use a test account whenever possible. HAR files can contain live tokens and other sensitive data.

2. Analyze the HAR with REA

Ask your agent to run REA against the HAR and summarize the API surface.

You should get:

• An endpoint inventory
• Detected ID patterns
• Calls that returned errors
• References to the raw capture records

3. Import the HAR into Apidog

Import the same HAR into Apidog. It can turn captured requests into endpoint definitions, generate a default test case per endpoint, and omit static assets during import.

See the HAR import walkthrough for cleanup steps.

4. Convert inferred templates into parameters

Use REA’s placeholders to identify dynamic path segments:

• {numeric}
• {uuid}
• {hex}
• {iso-date}

Promote those segments to actual path parameters in the Apidog endpoint definitions.

5. Mock and test the API

Enable Apidog’s smart mock so client code can run against the reconstructed API before connecting to the real service.

Then:

1. Write assertions against the captured response shapes.
2. Run the tests in Apidog.
3. Execute them from the Apidog CLI in CI.

The division of responsibilities is straightforward:

• REA reads evidence and explains what the traffic shows.
• Apidog turns that inventory into endpoints that your team can document, mock, test, and share.

Neither tool replaces the other.

Caveats before adopting REA

Release velocity can cause breaking changes

Seven minor versions shipped in nine days. The project’s always-bump-minor policy means a minor version may contain breaking changes.

The 6.2 migration guide changed the structure of every MCP result.

If you script against REA’s JSON output:

1. Pin the REA version.
2. Read the changelog before upgrading.
3. Test your integration against the new output format.

REA is a connector, not a sandbox

The project’s security policy states that its local provider bridge is not a sandbox. Opening an untrusted binary runs its parsing with your user permissions.

Analyze untrusted targets inside an isolated environment, just as you would isolate any agent’s tool calls.

Platform requirements are specific

Some features have strict platform requirements:

• Native mitmproxy decoding requires mitmdump 12.2.3 exactly.
• Native mitmproxy decoding requires Linux.
• Firmware extraction, EVM, and WASM paths require Linux x64.
• Hopper does not have a Windows build.

Legal responsibility remains with you

The README limits REA to lawful research, analysis, and reconstruction and states that users are responsible for obtaining authorization.

Copying a competitor’s feature raises the same legal questions it did before REA existed.

The project has also stated that it has issued no token and that coins using its name are unaffiliated.

The project is still early

The project had more than 100 contributors and over 170 open issues and pull requests at the time of writing.

The documentation is thorough, but expect rough edges outside the showcased workflows.

Frequently asked questions

Is REA free?

Yes. The code is MIT licensed and the npm package is free.

Hopper is a paid product if you choose it for native analysis. Ghidra is free.

Does REA upload my app or binary?

No. Analysis runs locally.

However, tool results are sent to whichever model your agent uses, so the model provider’s data policy applies.

Do I need Ghidra or IDA to get started?

Not for JavaScript, Electron, .NET, website, or capture analysis.

Native binary decompilation requires an analysis engine such as Hopper, Ghidra, or IDA.

Can REA produce an OpenAPI specification from traffic?

No.

REA’s api-surface view is an inferred inventory with path templates. Import the HAR into Apidog to create editable endpoint definitions, then export OpenAPI from there.

Download Apidog to try the import with a capture you already have.

Where this leaves you

REA earned its popularity by putting established reverse-engineering engines behind one MCP server and documenting the evidence returned by each analysis.

Use it for focused questions:

• How does one function work?
• Which IPC channel carries a message?
• What does an application’s network traffic look like?
• Which modules or routes are present?
• What request patterns appear in a saved capture?

Treat whole-application reconstruction demos as demonstrations rather than guarantees.

For API teams, the practical workflow is simple:

1. Capture the traffic.
2. Let an agent inspect the HAR with REA.
3. Import the same HAR into Apidog.
4. Convert the inferred inventory into endpoints.
5. Mock, test, and document the reconstructed API.

That gives you a repeatable path from captured behavior to a shareable, testable API contract.