/reverse-engineer-anything

name: reverse-engineer-anything
description: Reverse engineer native, managed, Electron/JavaScript, packaged, firmware, and browser targets with REA. Use shipped-artifact or requested runtime evidence to explain features, compare versions, decompile code, or guide a reconstruction. Skip REA for ordinary source-repository architecture analysis.
metadata:
  version: "28"
  tool_count: 134
  catalog_digest: "e41a84b460b65f3a8d0d33498d958d249a1de81a9660c18580a0e3ab5d6941e1"

REA

Use REA when a claim depends on a shipped binary or package, decompilation, passive application runtime evidence, or comparison with behavior not established by available source. For ordinary analysis of a complete source repository, use normal repository tools and do not run REA readiness or provider commands.

Connect only when needed

Installing this skill supplies instructions; it does not register the REA MCP server, install analysis engines, or add tools to an already-running agent.

If REA tools are available and their registration is not known to be stale, proceed directly to the target. Do not run diagnostics or setup before every investigation. Use the connected server's actual tool list and input schemas; a skill installed from repository main may describe capabilities absent from an older npm release. Keep complete inline Evidence when that server does not advertise retained references.

When tools are absent or registration is stale:

1. Diagnose without changing files. For Codex, run `npx -y rea-agents@latest doctor --client codex --json`. Substitute the current supported client: `claude_code`, `claude_desktop`, `codex`, `cursor`, `gemini_cli`, `windsurf`, `devin`, `opencode`, `antigravity`, `copilot_cli`, `commandcode`, or `vscode`. If the client is unknown, use `doctor --json` and inspect its registration results before choosing a setup scope. 2. Distinguish the reason. Missing, malformed, or stale registration needs a scoped configuration repair. An aligned registration with no tools in the active session needs a restart/reconnection; doctor cannot prove that the current agent has connected. A missing provider affects only tasks requiring that provider: static JavaScript inspection needs neither Hopper nor Ghidra, and Android inspection has separate bring-your-own JADX/Java prerequisites. 3. For a configuration repair, prepare the read-only plan: `npx -y rea-agents@latest setup --client codex --dry-run --json`. Use the current client's ID, show its exact proposed paths, backups, and changes, and obtain approval before setup writes configuration or installs Hopper. Setup normally installs the matching bundled skill too; include that replacement in the reviewed plan. After approval, apply the same scope with `npx -y rea-agents@latest setup --client codex --yes`. Add `--install-hopper` only if that separate installation was needed and explicitly approved. 4. Restart/reconnect the affected agent. Verify that REA tools actually appear in the session, then resume the original investigation. If they remain absent, inspect the client's MCP launch error rather than repeating setup.

REA setup never installs or upgrades Node.js, npm, Homebrew, Java, Ghidra, IDA, JADX, Binwalk, or Unblob. Use existing prerequisites; do not install unrelated software to repair MCP registration. For an unsupported client, use manual stdio registration with a version-pinned `rea-agents` package or continue through the CLI.

A concrete CLI fallback for an operator-supplied JavaScript tree or ASAR is:

npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json

No MCP registration or native engine is required. Read the returned Evidence, graph, limitations, and unknowns with the same care as an MCP result; the CLI returns the Evidence record directly. This fallback does not establish that MCP is configured. Native CLI tasks still require their selected engine.

Route the target first

Choose the first tool from the target the user supplied. Use `open_binary` for active-target native or archive workflows; target-free tools take their own explicit path or endpoint and do not need it.

• ASAR or extracted JavaScript/Electron tree:

`analyze_javascript_application`.

• Archive/package member inventory (ZIP/APK/IPA/MSIX/AppX or DMG):

`open_binary` with the supplied local path; use `inspect_artifact` when its graph and findings help answer the question.

• Android APK code, classes, methods, or incoming references:

`inspect_android_package`, then focused Android tools when advertised. Archive member inventory still uses the archive route above.

• Managed PE/CLI assembly: `inspect_managed_artifact`.
• Firmware image: `inspect_firmware_regions` when advertised. Use

`extract_firmware` when extraction is requested, with a caller-selected new absolute output directory. These tools use caller-supplied Binwalk/Unblob on Linux; see the [firmware guide](https://github.com/morluto/rea/blob/main/docs/firmware-analysis.md).

• .NET NativeAOT PE/ELF: native Ghidra analysis. Native code can yield pseudocode;

consult the NativeAOT workflow in `references/native-and-artifacts.md` for optional metadata recovery and its supported host/layout boundary.

• User-owned browser page already open: `list_browser_targets`.
• Retained HAR/native mitmproxy capture: `inspect_web_network_capture`. Select

original record ordinals when useful; inspect producer fields and byte/number sidecars without fetching recorded URLs or claiming live attribution. See [historical captures](https://github.com/morluto/rea/blob/main/docs/web-network-captures.md) for the exact upstream profile and credential exclusions.

• User-owned Electron runtime already open: `list_electron_targets`.
• Native executable, library, or analysis database: `open_binary`, then

use focused analysis tools directly; call `binary_overview` when metadata or inventory contex