* feat(setup): register DeepSeek Harness through setup, doctor and uninstall DeepSeek Harness registers MCP clients through a Cordis YAML patch sequence in the home patch rather than a server table, so setup could not configure it and users had to append the documented entry by hand. Add a dsh client: the home patch $DSH_HOME/cordis.patch.yml (~/.dsh/cordis.patch.yml when unset) is parsed as a patch list, the REA entry owns the stable rea-mcp id, and setup appends or replaces exactly that entry while preserving unrelated patches and comments in place. Doctor reports the registration through the same entry, and uninstall removes it, dropping insert operations it emptied. Skill destinations follow ~/.agents/skills ($DSH_AGENTS_HOME/skills when configured), the home the rest of the client machinery already uses. Fixes #1839 * fix(setup): carry environment and identity validation into DSH registrations Address review: the DSH entry discarded discovered provider overrides; config.env is now emitted and retained like the other dialects. An entry carrying the rea-mcp id under a wrong or missing package name, or duplicated entries, reads back as absent so setup rewrites exactly one canonical entry instead of reporting unchanged. Doctor now requires serverName rea and stdio transport before calling a DSH registration aligned, and the Harness skill identifier in the docs matches the installed reverse-engineer-anything skill. * fix(setup): apply Cordis patch order and collapse DSH registrations Address review: a later direct { id, config } operation replaces the row's config under the native patch DSL, so the registration view now applies patches in order instead of only reading insert operations; doctor reports the effective command rather than the inserted one. Setup rewrites exactly one canonical entry: duplicate id-matching rows collapse to the first, direct patches to the entry are dropped from the document and from the edited YAML, and uninstall removes them with the entry. The client-location test fixture now clears DSH_HOME and DSH_AGENTS_HOME so a developer environment cannot point the suite at real Harness homes. * fix(setup): repair direct-only registrations and preserve Cordis entry state Serialize now edits the first insertion carrying rea-mcp in place, so a grouped entry keeps its scope, neighbors, and comments instead of moving to a fresh root-level insertion, and later carrying insertions and direct patches collapse away. Entry-level disabled state projects into the registration the doctor and setup compare, so a disabled row reads as stale and the repair re-enables it. A direct-only registration no longer suppresses the canonical insert append, and an update retains the registration environment. Duplicate entries collapse across operations, not only within one. * fix(setup): preserve Harness row state through identity and refresh repairs A wrong-package row still reads back as a server record carrying its environment and caller fields, projected with a package marker the alignment path treats as stale, instead of vanishing and dropping config.env from the repair. A direct Cordis patch without a preceding insertion configures nothing, so a direct-only registration reads as absent even when its config matches and the repair appends the insert. Caller-owned config fields beyond the REA-owned keys, such as the cwd the native verifier sets, survive a refresh instead of being silently dropped. * fix(setup): preserve Cordis tags and collapse aligned Harness rows A refresh rebuilt Harness config from parsed values, so a caller !!js expression was written back as a literal. Owned keys are now overlaid on the winning config node and other nodes stay in place. Two already-aligned rea-mcp insertions read as stale, so setup collapses them to one row, and the bundled skill lists dsh with the other clients. * fix(setup): drop the unused DSH configuration type Knip reports DshConfigurationFormat as an unused export. The format union does not depend on that alias. * fix(setup): keep Harness env tags and comment-only patches A refresh replaced the whole env map, so a caller !!js value was written back as a literal. Environment entries now stay in place unless the value changed. A comment-only cordis.patch.yml parses as an empty patch list and keeps those comments when the registration is appended. Docs describe plain rea uninstall, which scans supported clients and has no --client flag. * fix(setup): own Harness rows by entry id and expression state Uninstall removes a rea-mcp row even when the launcher is stale or the patch never established a server record. A non-boolean disabled value, including a Cordis expression, reads as stale. Expression text on a known environment setting is not validated as a literal path, so a refresh can keep the tag. * fix(setup): collapse aliased Harness insertions An anchored insert followed by an alias parses as two rea-mcp rows, but the YAML edit kept the alias, so readback stayed duplicated and setup restored the file. Aliases that resolve to the owned entry are now dropped, including an alias of the entry inside one insert. Aliases of other patches stay. * fix(setup): resolve aliased Harness lists and config maps An insert value that aliases another entry list still loaded a second rea-mcp row after the operation-level alias collapse. That alias is now dropped once the anchored list is rewritten. A config: *cfg map is resolved and cloned before the refresh, so a caller !!js field on the aliased map is not rewritten as a plain literal. * fix(setup): follow Harness aliases for ids, lists, and env tags An insert alias whose anchor is not another insert is copied so unrelated rows stay while the owned row is rewritten. An aliased entry id is resolved before ownership checks, and an environment alias of an unchanged !!js scalar is left in place. * fix(setup): keep aliased Harness env maps through uninstall An env alias is cloned before a refresh so tagged values are not rebuilt as literals, and expression-key scans follow aliases before path checks. Insert aliases that carry REA are recorded before uninstall empties their anchor, so the later alias is dropped instead of dangling. * fix(setup): follow root Harness aliases and mark dsh as main-only Winning-config walks resolve a root alias before patch order, so a replayed direct config's !!js env is not validated as a literal path. Root aliases that own rea-mcp are recorded before uninstall empties their anchor. An insert whose only owned member is an external alias is cloned so Cordis tags survive. Docs state dsh is not in npm 6.4.0. * fix(setup): keep rows behind inert Harness aliases A root alias whose anchor is not a loaded operation is copied and only the owned row is edited, so unrelated rows stay active. Entry id aliases become a scalar before their anchor patch is dropped. Root-alias ownership follows insert-list aliases, so a replay is removed instead of dangling after uninstall. * refactor(setup): centralize Cordis source ownership * fix(javascript): share Electron mutation proof with wrapped calls * test(mcp): align graph and catalog checks with current contracts * fix(setup): separate Cordis ownership from editability * docs: clarify ownership and interpretation boundaries * fix(setup): preserve Cordis applicability and caller metadata --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: morluto <76467478+morluto@users.noreply.github.com>
English · 简体中文 · 繁體中文 · 日本語 · 한국어 · Türkçe · Русский · Tiếng Việt · ไทย · Deutsch · Español · Français · Українська · Polski · Português (Brasil) · العربية · فارسی · Bahasa Indonesia · Italiano
REA: Reverse Engineer Anything
One MCP for reverse engineering across binaries, applications, and runtime behavior.
See a feature you like. Understand how it works, down to the binary level.
Quick start · How REA works · What you can analyze · Showcases · FAQ · Documentation
npx rea-agents setup
|
Join the Reverse Engineering Community Discord · Q&A · Show and Tell |
See a feature in an app that you want in your own product? Ask your agent to investigate it with REA. It can inspect the app without its source code, explain how the feature works, show the evidence, and build a version for your project.
REA connects your agent to tools for inspecting native binaries, JavaScript and Electron apps, .NET assemblies, and websites. You can also use the same tools from your terminal. Analysis runs locally, and results include the evidence and limitations behind each conclusion.
Setup registers REA with your agent and installs matching workflow instructions. Native analysis can use an existing Hopper, Ghidra, or IDA installation; setup can optionally install Hopper with approval. Static JavaScript analysis needs no native analysis engine.
Visit the REA website for setup instructions, illustrated guides, and real case studies.
Quick start
Set up your agent
With Node.js and npm installed, run:
npx rea-agents setup
Choose your agents, review the proposed changes, and approve them. Setup adds REA's MCP server and matching workflow instructions, with backups of existing configuration. Restart your agent afterward.
Setup supports Claude Code, Codex, Cursor, Gemini CLI, Grok Build and other agents. See installation and setup for provider configuration and manual MCP registration.
Ask your agent
Understand how search works in the Notes app, show me the evidence, and build a
similar feature for my project.
Replace Notes with your target app and the feature you want to understand.
Use the terminal
Inspect an extracted JavaScript/Electron app directory or ASAR:
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json
The result includes modules, imports, Electron boundaries and their evidence.
Replace the path with your target, such as "D:/apps/example" on Windows.
To install the rea command for regular use:
npm install --global rea-agents
rea --help
For native analysis, configure a provider first. See the CLI and Evidence guide for native commands, provider selection, snapshots and scripting.
Update REA
REA changes quickly, and new releases include frequent bug fixes. Keep your installation up to date.
For a CLI installed with npm install --global or bun add --global:
rea update
Bun global updates require Bun 1.2.17 or later. With an older Bun release,
upgrade Bun manually before running rea update.
To refresh your agent registrations and skill, run the setup command printed by the update.
If you use npx, update your agent setup with:
npx rea-agents@latest setup
Review the setup changes and restart your agent. For one-off CLI commands,
use npx rea-agents@latest followed by the command. With Bun, use
bunx rea-agents@latest in place of npx rea-agents@latest.
How REA works
Your agent calls REA through MCP to inspect the target and trace relevant code. REA returns findings with their evidence. The agent uses them to ask follow-up questions, explain the behavior, or write and test an implementation. CLI commands use the same workflows.
What you can analyze
REA requires Node.js 22.x (>=22.19), 24.x (>=24.11), or 26+, plus npm. Additional tools and host support depend on the target:
| Target | What REA returns | Requirements and guide |
|---|---|---|
| Native binaries | Pseudocode, assembly, strings, symbols, calls and references | Hopper, Ghidra or IDA; native analysis |
| Offline ELF layout | Sections, segments, original symbols/relocations and static mitigation candidates | Caller-supplied pwntools on Linux x64; binary diagnostics |
| WASM artifact | Validation, sections, exact import/export WAT forms and decoded WAT | Caller-supplied WABT 1.0.42; inspect_wasm_artifact |
| EVM bytecode | Dispatch selectors, byte offsets, inferred arguments and mutability | Local raw/hex carrier on Linux x64; offline EVM guide |
| Recorded Linux crashes | Raw notes, every recorded thread's registers/signals and optional mapping candidates | Caller-supplied pwntools on Linux x64; optional GDB/pwndbg; recorded crashes |
| JavaScript / Electron | Modules, imports, source maps, routes, IPC and native add-on relationships | Node.js and npm; application analysis |
| Websites | Page structure, scripts, network observations and requested screenshots | A Chrome-family browser; browser analysis |
| Saved network captures | Requests, responses, exposed payloads and source locations | HAR; mitmdump on Linux for native mitmproxy captures; capture guide |
| .NET assemblies | Metadata, CIL instructions, declared native dependencies and build comparisons | None (static only); managed-code guide |
| Android APKs | Manifest declarations, classes, decompiled methods and references | Headless JADX and a full JDK on Linux/macOS/Windows x64; Android guide |
| Android devices | Devices, packages, processes, logs, dumps, screen captures, and APK/file transfers | Caller-supplied adb (emulator or hardware); ADB guide |
| JEB projects | Engine-backed project units, artifact digests and type/method pseudo-code | A caller-started JEB client serving MCP, selected with REA_JEB_MCP_URL; JEB guide |
| Android resources | Decoded manifest, string tables, locales and version facts | Caller-supplied Apktool launcher; resource guide |
| Firmware | Regions, extraction results and native-analysis handoffs | Binwalk / Unblob on Linux; firmware guide |
| Packages and resources | File inventories, digests, plists, Apple bundle anatomy and extracted resources | Artifact and JavaScript guide, Apple applications |
| Process behavior | Terminal output, interactions, exit and filesystem observations, and run comparisons | Linux/macOS with a native PTY; process capture |
Static JavaScript and .NET inspection read the supplied files without running the application. Runtime capture runs or interacts with the selected target using your user permissions; each runtime guide describes its effects.
Native formats and host support vary by provider. See
Hopper and Ghidra setup, the
IDA guide, and
experimental Windows Ghidra support.
Ghidra also supports 16-bit DOS analysis.
For large binaries, raise the provider's startup deadline with
REA_GHIDRA_STARTUP_TIMEOUT_MS or REA_HOPPER_STARTUP_TIMEOUT_MS.
For provider selection, see the CLI guide.
Check release availability
for features added since the latest npm release.
Showcases
DX-Ball: reconstruct a sound-pan calculation
Follow a sound call into its position-to-pan helper, inspect the instructions, and turn incomplete pseudocode into C. The reconstruction passes 3,205 original-x86 cases and reproduces all 63 compiled function bytes.
Read the case study · Reconstruction repository
Notion: trace the Electron clipboard bridge
Find the renderer's clipboard API, follow it through preload and IPC into the main process, and inspect the rich clipboard format.
TH04: recover a DOS bullet-ring calculation
Inspect the original PC-98 game's 16-bit instructions, recover the fixed and aimed angle calculations, and compare the reconstructed C++ with the historical compiler output.
Read the case study · Reconstruction repository
If you've used REA on something interesting, we'd love to see it. Share your case in an issue or a pull request, including the target, your question, how REA helped, and what you found.
FAQ
Which agents can use REA?
Any agent that supports local MCP servers. Setup configures the supported agents; other clients can use manual MCP registration.
Do I need Hopper, Ghidra or IDA?
Deep native analysis uses one of them. Static JavaScript and .NET inspection work without a native analysis engine. Setup can install Hopper after approval; Ghidra and IDA use your existing installations. See provider setup.
Do I need to start Hopper first?
REA starts Hopper when an operation needs it. On macOS, a first-run dialog may ask you to choose demo mode or activate your license. Complete that prompt in the same user session before your first CLI/MCP operation or unattended job. Open Hopper manually if needed. See Hopper startup and troubleshooting.
What does installing the skill from skills.sh do?
The skill supplies investigation instructions for your agent. Use npx rea-agents setup
to register REA's MCP server and install the matching instructions, then restart
your agent. See skill-only installation.
What code does REA return?
Native analysis returns pseudocode and assembly. JavaScript/Electron analysis recovers modules and their relationships. Your agent uses these findings to write and test an implementation; the showcases give worked examples.
Does REA upload my app?
REA analyzes targets locally. Your agent receives the tool results, and its model provider has its own data policy.
What should I do if I hit a bug?
Update first; a recent release may already fix it.
For a CLI installed with npm install --global or bun add --global:
rea update
For agent setup through npx:
npx rea-agents@latest setup
If you're using an agent, complete the setup refresh and restart it. Retry the same task. If the problem persists, open an issue with your REA version, target type, steps to reproduce and error output.
Documentation
Start with the website's worked guides. For exact options, prerequisites and result contracts:
- Installation and setup: agent registration, provider configuration, updates and uninstall.
- Readiness and troubleshooting: diagnose one agent or analysis engine.
- CLI and Evidence: commands, provider selection, snapshots, import/export and exit statuses.
- MCP contracts and agent prompts: tool results, sessions and guided investigations.
- Tool catalog: generated inventory of tools, providers and CLI commands.
- Roadmap: planned work and capability trackers.
Report vulnerabilities through SECURITY.md.
Star history
🎉 90,000 GitHub stars — thank you!
Thanks to everyone using REA, reporting bugs, requesting features, testing builds, and contributing fixes.
Disclaimer
REA provides tools for lawful reverse-engineering research, analysis, and reconstruction. You are responsible for obtaining any required authorization and complying with applicable laws. The project does not endorse illegal or unauthorized use.
REA is an open-source software project. We have not issued or endorsed any cryptocurrency or token. Tokens using the REA name are not affiliated with the project.
Contributing
We'd love your help with REA! Open an issue to report a bug or suggest a feature, or send a pull request to improve the code or docs.
See CONTRIBUTING.md for development setup and checks, testing for verification lanes, and the architecture map for the project structure.
