REA (Reverse Engineer Anything): Install & Use Reverse-Engineering Skills in Claude Code / Codex
REA is morluto/rea on GitHub: an MIT-licensed MCP server, a CLI and a reverse-engineer-anything agent skill that let Claude Code, Codex, Cursor and other clients inspect binaries, Electron apps, .NET assemblies, APKs and websites — locally, with evidence. Here is the verified install, the first commands, and where the legal line actually sits.
REA at a glance
- One project, three pieces: the `rea-agents` npm package ships the `rea` CLI, a local MCP server, and the `reverse-engineer-anything` skill that tells the agent which tool fits which target.
- The install is one reviewed command: `npx rea-agents setup` lists the exact config paths, backups and skill destinations, then waits for your approval. Nothing is written before you approve.
- Claude Code, Codex and Cursor each have a native route too — two `/plugin` prompts, two `codex plugin` commands, or a Cursor Marketplace plugin — and setup can configure 28 clients directly.
- REA is not a sandbox and does not decide what is legal: it runs with your user permissions on targets you must be authorized to analyse, and the project's own disclaimer lists what it refuses to help with.
morluto/rea — README
Source: github.comchecked 2026-11-13
docs/getting-started/installation.md
Source: github.comchecked 2026-11-13
.agents/skills/reverse-engineer-anything/SKILL.md
Source: github.comchecked 2026-11-13
docs/getting-started/cli.md
Source: github.comchecked 2026-11-13
rea-agents — npm registry
Source: registry.npmjs.orgchecked 2026-11-13
DISCLAIMER.md + SECURITY.md
Source: github.comchecked 2026-11-13
dsh-rea — DeepSeek Harness directory
Source: deepseekharnessplugins.comchecked 2026-11-13
dsh-reverse-skill — DeepSeek Harness directory
Source: deepseekharnessplugins.comchecked 2026-11-13
Every command, client ID, version and number on this page was read from the sources above on 2026-11-13: the repository README, docs/getting-started/installation.md, the bundled SKILL.md, docs/getting-started/cli.md, DISCLAIMER.md and SECURITY.md, and the npm registry. Repository facts come from the GitHub API on the same day: 455,720 stars, 111,916 forks, created 2026-04-14; latest npm release `rea-agents` 6.9.0, published 2026-11-12. Star counts move daily, so treat them as a dated snapshot. This page quotes no performance figure at all: the README and docs we checked cite no benchmark results, so none is repeated here.
What REA actually is
REA stands for Reverse Engineer Anything. It is a third-party open-source project by morluto, MIT licensed, at github.com/morluto/rea, with the site rea.tools. It is not an Anthropic, OpenAI or Cursor product, and it is not a decompiler: it is the layer that lets a coding agent drive decompilers and static parsers, then explain what it found.
The distribution is the `rea-agents` npm package. It exposes the `rea` command, a local MCP server, and the `reverse-engineer-anything` skill — a workflow document that tells the agent to route the target first (ASAR/Electron, archive, APK, .NET, firmware, native binary, browser page, capture) and to keep every conclusion tied to Evidence. Analysis runs on your machine; the agent receives the tool results, and its model provider applies its own data policy.
Deep native analysis is bring-your-own: Hopper, Ghidra, IDA or Kuna. Setup can install Hopper after a separate approval, and it reuses an existing Ghidra, IDA or Kuna. Static JavaScript/Electron and .NET inspection need no native engine at all — which is why a first test on an Electron app is the cheapest way to find out whether REA earns its place in your workflow.
- npm release
- rea-agents 6.9.0
- License
- MIT
- GitHub stars
- 455,720
- Repository created
- 2026-04-14
What it can look at
The README's target table has 39 rows; this is the part that decides whether you install it. The last column is the requirement the docs actually give — most rows need nothing beyond Node.js.
| Target | What you get back | Needs |
|---|---|---|
JavaScript / Electron | Modules, imports, source maps, routes, IPC boundaries and native add-ons — static, without running the app. | Node.js + npm (on Linux, a procps `ps`) |
Native binaries | Pseudocode, assembly, strings, symbols, calls and cross-references. | Hopper, Ghidra, IDA or Kuna |
.NET assemblies | Metadata, CIL instructions, declared native dependencies, build comparisons. | Nothing extra (static only) |
Android APK | Manifest declarations, classes, decompiled methods and references; APK signature facts. | Headless JADX + a full JDK (signatures need nothing) |
Websites / captures | Page structure, scripts, network observations, requested screenshots; HAR and SAZ captures. | A Chrome-family browser (captures: HAR or SAZ) |
Go / Rust / PE / WASM | Go build info, Rust cargo-auditable crates, PE imports and certificates, ELF notes, WASM, hardening flags. | Nothing extra (static only) |
Archives / firmware | Member inventory and extraction for ZIP/APK/IPA/MSIX/DMG, Godot PCK, UnityFS, wxapkg; firmware regions. | Binwalk or Unblob on Linux, for firmware |
GGUF / safetensors | GGUF and safetensors metadata, tensor declarations, optional full-file hash. | Nothing extra (static only) |
Release exposure | A release-exposure report with stable check ids, statuses and remediation: shipped source maps, Electron fuses, credential markers. | Nothing extra (static only) |
Two boundaries are worth reading twice. Static inspection parses files and does not run the target; runtime capture, browser scenarios and device workflows do run or interact with it, under your user permissions. And every result carries its own limitations and unknowns — the docs say plainly that a clean release-exposure report does not mean an application is secure.
Install: one reviewed command, then per-client routes
Setup is interactive by default: it lists supported clients, shows the exact files it will touch plus backups, and asks before writing. The npm download approval and REA's own approval are separate prompts, so approving npm does not approve the config changes.
1. The guided setup — works for every supported client
Run it with Node.js and npm on PATH. Select clients (existing REA registrations are pre-selected, newly detected ones are not), read the plan, approve. Then fully restart the agents named in the completion message: a running client can overwrite its own registration. For scripts, add `--client <id>` and start with `--dry-run --json` to get a read-only plan.
Commands
npx rea-agents setupnpx rea-agents setup --client claude_code --dry-run --json2. Claude Code: two /plugin prompts, no setup run
REA's npm package is also a Claude Code plugin. Add the repository as a marketplace, then install `rea@rea`. A plugin does not run `rea setup`, so provider configuration (Ghidra/IDA paths) still comes from the sections below, and `rea doctor` reports the plugin as `missing` — check it with `/plugin` and `/mcp` instead. Use the plugin or a setup registration for a given client, never both, or two `rea` servers start.
Commands
/plugin marketplace add morluto/rea/plugin install rea@rea3. Codex: the same plugin, two codex commands
The same npm package carries a `.codex-plugin` manifest. Add the marketplace, then install `rea@rea`. The client needs a standalone `node` on PATH. As with Claude Code, a plugin install is invisible to `rea doctor`; use `codex plugin list` to check it.
Commands
codex plugin marketplace add morluto/reacodex plugin add rea@rea4. Cursor: setup registration or the Marketplace plugin
`rea setup --client cursor` writes `~/.cursor/mcp.json` plus the setup-owned skill. Cursor's Marketplace also lists the repository as a plugin that bundles both the skill and an `rea` MCP server pinned to a published version; that route is a Git checkout and does not put `rea` on PATH. Pick one of the two, not both.
Commands
npx rea-agents setup --client cursor5. Skill only — instructions without tools
If you only want the instructions, for example to pair them with an MCP server you registered by hand, install the skill from skills.sh. That gives the agent the routing rules and bundled references but registers no tools, so REA calls stay absent until an MCP server exists.
Commands
npx skills add morluto/rea --skill reverse-engineer-anything6. Verify before you trust it
`rea doctor` is read-only. Check one client, the installed skill and one engine separately: a provider failure does not block target-free tools, and a client check verifies registration, not a successful investigation. Doctor reads files and prerequisites; it cannot see the live session, so a registered server still needs a restart or reconnect.
Commands
rea doctor --client claude_code --jsonrea doctor --skill --jsonrea doctor --provider ghidra --jsonRequirements, as documented
- 1Node.js 22.x (>= 22.23.4), 24.x (>= 24.22.1) or 26.12.1+, plus the npm paired with it. Node 23, 25, earlier 26.x releases and prereleases are unsupported.
- 2A client that supports local MCP servers. Setup knows 28 client IDs, including claude_code, claude_desktop, codex, cursor, gemini_cli, windsurf, opencode, copilot_cli, antigravity, kimi, dsh and pi.
- 3A native engine only for native work. Static JavaScript/Electron and .NET analysis need nothing else; Android needs headless JADX and a JDK; firmware needs Binwalk or Unblob on Linux.
- 4Run package acquisition from a trusted directory outside the target project, and pass absolute paths to analysis commands — a package runner can select project-local packages, and REA cannot validate what happened before its entrypoint started.
A first session that proves something
The cheapest honest test is a feature you already understand, in an app you own, on a target with no native engine in the way. Ask for the evidence, not just the answer: the point of REA is that the agent has to show the code path it claims.
Ask the agent
The README's own example, verbatim. Replace Notes with your target and the feature with something you can verify by hand. Expect the agent to call REA tools, read the Evidence, and name the parts it could not establish — if it answers without evidence, the MCP connection or the skill is probably missing.
Prompt
Understand how search works in the Notes app, show me the evidence,and build a similar feature for my project.Or drive the CLI yourself
Every MCP workflow has a CLI twin, which is the fastest way to check whether a claim about REA is true. The first command returns an Evidence record for an extracted Electron directory or ASAR without any engine; the second audits a shipped artifact and exits 3 when an exposed check meets the severity you pass.
Commands
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --jsonrea audit-release-exposure ./dist/MyApp.app --fail_on high --jsonWhy the output is big — and what to do about it
Real application Evidence can reach hundreds of megabytes. The documented answer is to save it and project a view: `rea analyze-javascript-application … > app-evidence.json`, then `rea inspect-analysis-view` with a summary or one page of modules. Over MCP, `REA_MCP_MAX_RESPONSE_BYTES`, `REA_MCP_INPUT_SCHEMA_PROFILE=full` and `REA_MCP_OUTPUT_SCHEMA_PROFILE=compact` tune how much of that the model sees.
Update and remove
`rea update` updates the global npm or Bun installation that owns the running CLI; an `npx` setup is refreshed by rerunning `npx rea-agents@latest setup`. `rea uninstall` removes only REA-owned registrations and skill files, `--purge-data` also drops cache and state, and neither touches Hopper, Node.js, Evidence files or unrelated skills.
Commands
rea updatenpx rea-agents@latest setuprea uninstallrea uninstall --purge-dataREA vs. doing it by hand vs. an instruction-only skill pack
The honest comparison is not REA against a human reverse engineer. It is REA against the same agent with a shell and no tools, and against skill packs that ship instructions but no server.
| Aspect | Agent + shell, no REA | Agent + REA |
|---|---|---|
| Tool wiring | You paste commands and paths into the chat and the model guesses which decompiler flag to use. | The skill routes the target to a tool with a schema; the server validates arguments and returns structured Evidence. |
| Evidence | Whatever the agent quotes, with no record of which file or offset it came from. | Findings carry their evidence and their limits, and unknowns stay listed instead of being smoothed over. |
| Large output | A 300 MB dump either blows the context window or gets truncated by `head`. | Evidence is saved and projected — summary, module page or a single module — before it reaches the model. |
| Instruction-only packs | A reverse-engineering skill pack teaches method but registers no tools, so the agent still shells out. | REA ships both halves: the skill and the MCP server/CLI it describes. Skill-only installs are supported but leave the tools missing. |
Legal and safety boundaries — from the project, not invented here
REA's own DISCLAIMER.md and SECURITY.md draw the line, and it is stricter than the marketing around such tools usually is. The short version: being able to analyse software is not the same as being allowed to.
- Intended uses: security research, malware and incident analysis, vulnerability research and coordinated disclosure, CTFs and education, interoperability, software preservation, and auditing software you own or are authorized to examine.
- Explicitly not supported: circumventing DRM, licence checks, anti-cheat or other technical protection measures; game cheats or tampering with online services; bypassing authentication or access controls you are not authorized to test; copying proprietary code and assets; evading model-provider policies.
- Authorization is yours to establish. Public availability of a binary, possession of a file or access to a debugging endpoint does not by itself grant permission, and reverse engineering may be restricted by law or by the software's licence in your jurisdiction.
- Commercial tools stay commercial: IDA Pro/Hex-Rays, Hopper and JEB must be legally obtained and licensed. REA grants no key, licence or activation, and cracked copies or shared keys are not authorized.
Two more practical points from SECURITY.md: REA is not a sandbox — CLI and MCP run with your account's permissions — and target files, captures and web pages are untrusted data, so an instruction embedded in a binary is not an instruction from you. Use a throwaway VM or container for anything you did not build, and never point runtime workflows at systems you do not own.
Before you install: five honest caveats
None of these is a reason to skip REA; all of them are reasons to try it on one target first.
- 1It is a fast-moving third-party project: npm went from 6.8.0 to 6.9.0 inside three weeks, and the docs warn that a skill installed from `main` can describe capabilities an older npm release does not have. Trust the connected server's tool list, not the skill text.
- 2Client coverage is wide but uneven: some client IDs need a newer rea-agents (droid, dsh, kimi, qoder, trae, workbuddy and zcode from 6.5.0; freebuff from 6.8.0), and `lm_studio` needs a release after 6.8.0.
- 3Setup writes into your agent configuration and skill directories. It keeps `.rea.backup` snapshots and refuses to overwrite files it cannot verify, but it cannot coordinate with another writer editing the same file — quit the client first, as the docs ask.
- 4Engine setup is the part that bites. Hopper is commercial with a limited demo, the automated installer covers macOS and x86_64 Linux only, and other architectures are documented to use Ghidra. A missing engine can leave doctor's overall `healthy` false; the docs say that is normal while your chosen workflow works, and it only blocks native pseudocode.
- 5Context and privacy: the agent sees the Evidence, so your model provider sees it too. Analysis is local, but the results are not — keep sensitive targets on a local model or out of the loop entirely.
DeepSeek Harness and the skill-pack neighbours
REA's README does not mention DeepSeek Harness, but the package can register there: `dsh` is one of setup's client IDs, and the DSH directory lists both the REA project itself and community adapters. zhaofeng130/dsh-rea is an unofficial adapter that registers the `reverse-engineer-anything` skill plus `rea` and `rea_doctor` tools, and it explicitly does not bundle REA. dhicoc/dsh-reverse-skill is a different thing again: a port of the reverse-skill pack (87 SKILL.md files for reverse engineering, authorized pentesting and CTF) with no REA dependency. Neither is affiliated with morluto/rea — read them before installing.