rea

REA: learn how a shipped feature really works

When you need to know how a feature is implemented in a specific tool or app, do not guess from docs, marketing pages or memory. Look at the shipped artifact with REA and cite what you found.

REA (Reverse Engineer Anything) is an MIT-licensed CLI and MCP server by morluto. It decompiles and inspects native binaries (through Hopper, Ghidra or IDA), Electron/JavaScript bundles, websites, Android APKs, .NET assemblies, firmware and more, and returns Evidence records with IDs you can cite.

This skill is the entry point: set up, route, run, report. REA's own reverse-engineer-anything skill holds the detailed per-tool workflow; load it when it is installed.

0. Is the source available?

If the code is in a repo you can read (open source, the user's own project, an npm package with readable source), read it with normal tools. REA is for shipped artifacts: compiled binaries, minified bundles, signed apps.

1. Check the setup (once per machine, not per task)

If the REA MCP tools (open_binary, analyze_javascript_application, ...) are already in your tool list, or rea --version works, skip straight to step 2. Don't run diagnostics before every investigation. Only when something is missing or a call fails:

rea doctor --client claude_code --json         # or --client codex

Missing pieces, in order:

1. CLI. Official package only: npm i -g rea-agents@latest (Node ^22.19, ^24.11 or >=26; 23 and 25 are unsupported). No install scripts; npm provenance is attached.
2. Agent registration. Plan first, then apply:

   rea setup --client claude_code --client codex --skill=false --dry-run --json
   rea setup --client claude_code --client codex --skill=false --yes --json
   

   Add --install-hopper on macOS to download Hopper from hopperapp.com (codesign-verified, installed to ~/Applications). Setup then opens the Hopper app once: tell the user before you run it, because a person has to click "Try the Demo" (or enter a license) in its first-run window before REA can drive it unattended. Hopper is only needed for native binaries; Electron, JavaScript, web, APK and .NET work without it. Restart the agent afterwards so it sees the tools. Setup writes HOPPER_LAUNCHER_PATH only into the agents' MCP entries. The rea CLI looks in /Applications, so when Hopper went to ~/Applications export it in the shell profile too: export HOPPER_LAUNCHER_PATH="$HOME/Applications/Hopper Disassembler.app/Contents/MacOS/hopper". A first open can time out while Hopper is still starting; retry once.
3. REA's own workflow skill (optional, recommended): rea setup --skill --dry-run --json shows the destinations (~/.agents/skills plus each registered agent's skill folder), then --yes installs. If the machine keeps one canonical copy in ~/.agents/skills with links from agent folders, replace the per-agent copy with a link to the shared one.

rea doctor reporting Ghidra or IDA as "not configured" is fine when Hopper works. Other unregistered clients show as config drift; ignore them.

Only trust github.com/morluto/rea and the npm package rea-agents. @morluto/rea is the superseded legacy name (old Hopper-only release); don't install it. Look-alike repos offering an "official free download" zip or a Windows installer are malware lures. Never run them.

2. Route the target

Target	First move
Electron app (Claude desktop, Slack, VS Code, Cursor)	analyze_javascript_application on <App>.app/Contents/Resources/app.asar, or on the unpacked Contents/Resources/app/ folder when there is no ASAR (VS Code, Cursor)
Native CLI or app (Rust, Go, Swift, C++: e.g. the Codex CLI binary)	open_binary, then function and string search; close_binary when done
npm-distributed CLI (minified JS)	analyze_javascript_application on the package directory
Website or web app	The user opens the page in a browser with its debug port on localhost; list_browser_targets, then analyze_web_bundle with that endpoint and target ID
Android APK	inspect_android_package
.NET assembly	inspect_managed_artifact
Archive, DMG, IPA, ZIP	open_binary / inspect_artifact for the member inventory

The CLI mirrors the MCP tools (rea analyze-javascript-application <path>, rea decompile, rea function, rea inspect-artifact); run rea <command> --help for flags.

3. Run it without drowning the context

• Ask for summaries. A full Electron analysis is large (Claude desktop's ASAR produced a 100 MB Evidence record). Over MCP, call analyze_javascript_application with detail: "summary", then drill in with inspect_analysis_view or trace_application_feature on the returned parent_evidence_id. Retained Evidence IDs live only within one MCP connection.
• On the CLI, write to a file. --json > file, then slice with --filter-output / --token-limit, or rea inspect-analysis-view, which takes workflow JSON (see its --schema), not the raw file. Never paste a whole record into the conversation.
• Signed Electron apps fail integrity by default. Code signing rewrites unpacked native modules after packaging, so the declared ASAR hash no longer matches. When the error names an unpacked .node file, rerun with --integrity-policy record-and-continue (MCP: integrity_policy: "record-and-continue"). Those bytes are marked untrusted and coverage is reported as partial.
• Go from the user-visible string inward. Find the UI text, setting name, CLI flag or API path the feature exposes, locate it in the bundle or binary, then follow callers and data flow to the implementation.
• Static before runtime, CLI before GUI. Run the target (Electron or process capture) only when static evidence can't answer the question and the user agreed to launch it. Don't open GUI apps that wait on a prompt.
• Batch around one hypothesis. Reuse the open session and existing Evidence instead of re-running identical analysis.

4. Report

Separate three things, every time:

• Observed: what the artifact contains, with Evidence IDs and file or function locations.
• Inferred: what you conclude from it, and how confident you are.
• Unknown: what static analysis could not show (server-side behavior, runtime-only branches, encrypted payloads).

Lead with the plain-language answer to the user's question, then the evidence.

5. Rebuilding a feature (clean room)

When the goal is to build the same capability:

1. Write a behavior spec from the evidence: inputs, outputs, states, edge cases, error handling. Describe what it does, not their code.
2. Implement from that spec with normal coding tools, in your own design.
3. Do not copy decompiled code, embedded assets, keys, tokens, model prompts or proprietary text into the user's project.

Boundaries

• Analyze software the user is licensed to run, for interoperability, research, security review or understanding a feature. Check the vendor's terms when the user plans to ship a clone.
• Secrets found inside an artifact (API keys, tokens) are reported as a finding, never used and never written to files or commits.
• Don't bypass DRM, licensing checks or anti-tamper, and don't attack servers. REA reads local artifacts and observes what the user runs.