5dd2ce3125
* fix(ida): let one-shot commands exit after retaining cleanup When a headless IDA request outlives timeoutMs (for example idb_open on a large binary still running auto-analysis), REA cannot prove the worker stopped and correctly retains the upstream connection and private workspace. The retained stdio child and its pipes stayed referenced, so a one-shot CLI printed its cleanup_incomplete result and then never exited, keeping the supervisor, worker and database alive. Detach the retained connection's child process and pipes from the event loop when cleanup fails. A long-lived MCP server can still retry through the retained connection; a one-shot CLI exits with status 1, and the supervisor observes end of input. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(ida): report an unverified upstream worker after failed cleanup Upstream ida-pro-mcp spawns headless workers in their own session and deliberately leaves them running when its supervisor exits, so neither a retained connection nor REA exiting proves that a timed-out worker stopped. When cleanup fails before the owned worker's release is confirmed, the cleanup diagnostics now name its private session and state that it may still be running until it finishes and reaches its idle timeout. Failures after a confirmed release, or before any open was attempted, do not report a worker. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(ida): name the inventory sessions that block worker release When idb_close confirmed the requested worker gone but the follow-up inventory still found a different peer on the private input, the upstream_worker diagnostic named the released session and could misdirect manual cleanup. Record the session ids of the inventory entries that actually blocked release and report those; fall back to the requested private session only when no inventory evidence exists (an incomplete open or an unanswered request). The field becomes session_ids, since more than one entry can block release. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(ida): keep blocker evidence and backend in cleanup diagnostics The release diagnostic reset its observed blockers on every close, so a retry whose inventory was unavailable fell back to the already-released session; and it kept only session ids, describing a blocking GUI session with detached-worker guidance. Blocker evidence is now replaced only by a successful inventory, and the diagnostic becomes upstream_sessions with each session's id and backend, with guidance that distinguishes workers from GUI sessions. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(ida): stop naming a worker after its close was confirmed When idb_close confirmed the requested worker's release but the following inventory failed, no blocker evidence existed yet and the diagnostic fell back to the confirmed-absent worker. After a confirmed close the diagnostic now reports an empty session list, meaning any remaining same-input sessions are unknown. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test(ida): group cleanup diagnostic cases in their own suite The added cases pushed the reaped-worker describe block past the 150-line limit enforced by lint:built. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(ida): keep ownership and pre-close peers in cleanup diagnostics Blocking sessions dropped the parsed ownership fact, so an external unowned worker looked the same as REA's own; and recovery inventory recorded same-input peers only when the requested worker was missing, so a peer seen beside it was lost if the following close failed. Each reported session now carries owned (null when no inventory has reported it), and recovery records every same-input session until a later successful inventory replaces that evidence. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(ida): drop a confirmed worker from retained cleanup blockers Recovery inventory now records the requested worker beside any peers, so once idb_close confirmed its release a failing follow-up inventory still reported it as unreleased. Remove the confirmed session from the retained blockers at close confirmation and keep the remaining peers. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test(ida): retry cleanup through a detached stdio connection The retry coverage used a recording connection whose detach() only counts calls, so it could not show that detaching keeps a retained connection usable. Run a real stdio supervisor in a long-lived host, fail the first post-close inventory, and require the retry through the same detached connection to confirm release and remove the workspace. The test fails if detach() destroys the pipes instead of unref-ing them. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(ida): close the stdio supervisor in failed retry tests Merge main and give its new IdaNativeProtocol connection double the required detach() method. The real-stdio retry test now closes its connection in an unconditional teardown, so a failing assertion cannot leave the supervisor waiting on stdin. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test(ida): share the cleanup diagnostic expectation in session tests Repeated upstream_sessions assertions and the unrelated live peer literal pushed repository duplication over the jscpd threshold. Build the expected diagnostic with one helper and reuse one peer constant. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test(ida): distinguish observed ownership from unreported input bindings * fix(ida): keep requested-ID conflicts in recovery cleanup Recovery inventory kept only same-input entries, unlike the startup and post-close filters. After an explicitly rejected open, an entry under the requested session ID on another input was dropped, so cleanup could close the connection, remove the private workspace and report success while that session stayed registered. Match the requested ID as well so the entry is retained as a blocker and cleanup stays incomplete. Also split the cleanup diagnostics suite under the lint:built function length limit, and make two startup-inventory fixtures pass a defined session id so the test file typechecks. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Xingchuan Ma <xingchuan.ma@msn.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: morluto <morluto@users.noreply.github.com> |
||
|---|---|---|
| .agents/skills | ||
| .github | ||
| .husky | ||
| bridge | ||
| docs | ||
| experiments/analysis-efficiency | ||
| licenses | ||
| native/windows | ||
| scripts | ||
| src | ||
| tests | ||
| third_party | ||
| website | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .jscpd.json | ||
| .npmrc | ||
| .nvmrc | ||
| .oxfmtrc.json | ||
| .oxlintrc.json | ||
| .release-please-manifest.json | ||
| AGENTS.md | ||
| CHANGELOG.md | ||
| CONTRIBUTING.md | ||
| DISCLAIMER.md | ||
| LICENSE | ||
| README.md | ||
| README_ar.md | ||
| README_de.md | ||
| README_es.md | ||
| README_fa.md | ||
| README_fr.md | ||
| README_id.md | ||
| README_it.md | ||
| README_ja.md | ||
| README_ko.md | ||
| README_pl.md | ||
| README_pt-BR.md | ||
| README_ru.md | ||
| README_th.md | ||
| README_tr.md | ||
| README_uk.md | ||
| README_vi.md | ||
| README_zh-TW.md | ||
| README_zh.md | ||
| SECURITY.md | ||
| THIRD_PARTY_NOTICES.md | ||
| install.sh | ||
| knip.json | ||
| package-lock.json | ||
| package.json | ||
| release-please-config.json | ||
| server.json | ||
| tsconfig.build.json | ||
| tsconfig.frida-verification.json | ||
| tsconfig.json | ||
| turbo.json | ||
| vitest.config.ts | ||
README.md
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 |
| Go binaries | Embedded compiler version, modules, replacements and build settings | Built-in static ELF/PE/thin Mach-O inspection; no Go installation required |
| 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 |
| SQLite databases | Tables, columns, indexes, views, triggers and selected ordinary-table rows | Local database/WAL snapshot; Node.js 24.x >=24.15 or 26+ with native SQLite limits |
| 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 or Fiddler Everywhere SAZ; mitmdump on Linux for native mitmproxy; 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 |
| Flutter apps | Dart snapshot hash, per-ABI library digests and engine build provenance | None (static APK parsing); Flutter guide |
| Firmware | Regions, extraction results and native-analysis handoffs | Binwalk / Unblob on Linux; firmware guide |
| Recorded packets | Selected fields, repeated values, filters and decode-as rules | Linux: TShark 4.x + prlimit; capture guide |
| Packet summaries | Endpoints, DNS, TLS SNI, protocol distribution and HTTP requests | Caller-supplied tshark and capinfos (Linux-verified); pcap guide |
| Recorded logic signals | Decoder annotations, sample ranges and diagnostics | Linux: sigrok-cli 0.7.2 + prlimit; signal recordings |
| 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 (including an optional native MCP bridge), 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
🎉 170,000 GitHub stars — thank you!
Thanks to everyone using REA, reporting bugs, requesting features, testing builds, and contributing fixes.
Disclaimer
See DISCLAIMER.md for responsible-use guidance.
The project's position on illegal or unauthorized use covers all REA versions, distribution channels, and platforms; each copy retains its applicable licenses.
REA is for lawful research, education, interoperability, software preservation, and analysis of software you own or are authorized to examine.
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.
License
REA-authored code is licensed under MIT. Third-party material retains its own licenses and copyright notices; see Third-party notices for the dependency inventory, preserved license texts, and external-tool terms.
You must legally obtain and be authorized to use commercial tools, including IDA Pro / Hex-Rays decompilers, Hopper, and JEB, under their applicable licenses. REA grants no tool license, key, or activation entitlement. Trials and demos remain subject to vendor terms, including user, feature, automation, and output sharing restrictions. Cracked copies, stolen keys, unauthorized key sharing, and bypassing license restrictions are not authorized. This guidance does not amend MIT or third-party licenses.