name: rea description: "Find out exactly how a feature is implemented in a shipped tool or app you don't have the source for (desktop apps, Electron apps like Claude desktop, native CLIs like Codex, websites, APKs, .NET assemblies) using REA - Reverse Engineer Anything (github.com/morluto/rea). Sets REA up when it is missing (CLI, MCP registration, Hopper or Ghidra), routes the target to the right REA tool, keeps evidence out of the context window, and turns findings into a clean-room spec before any rebuild. Use when the user says 'use REA', 'reverse engineer', 'how does <app> do X', 'how is this feature implemented in <tool>', 'clone this feature', 'decompile', 'look inside the app', or asks how a closed-source competitor works. Skip it when the source is available - read the repo instead." version: 1.0.0 license: MIT repository: anton-abyzov/vskill mcp-deps: [rea] metadata: tags: reverse-engineering, rea, decompile, electron, asar, hopper, ghidra, binary-analysis, clean-room, feature-research

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.

1. Agent registration. Plan first, then apply:

``bash 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.

1. 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

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.

1. Implement from that spec with normal coding tools, in your own design.
2. 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.