reverse-engineer-anything skill

REA

Use REA when a claim depends on a shipped binary or package, decompilation, requested 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. The exception is a Claude Code, Codex, or Cursor Marketplace plugin install: the plugin bundles this skill and registers its own rea server, outside the state that rea setup and rea doctor manage.

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.

If tools are absent, a call is blocked by the client, or a required provider is unavailable, read connection and recovery. Diagnose the observed blocker, continue useful supported work, and resume the original task after repair. Client approval, shell PATH, registration and engine availability have different remedies; avoid repeating setup for all of them. If the host times out without a REA result, do not repeat the unchanged call or assume work stopped. Read the recovery guide's deadline distinction before retrying. If the MCP connection drops, retry that call once only when it is safe to repeat or known not to have started. If it may already have changed the target, or it fails again, tell the user and ask them to restart the MCP client. If REA could not start its connection, retry once, then tell the user and ask them to restart the MCP client. Do not retry a startup failure that returns the same unchanged result. For plugin installs, follow plugin recovery. For setup-owned registrations, run rea doctor when REA could not start or tools stay missing after that restart. For cleanupincomplete, a retryable capacity limit, or configurationinvalid, follow the recovery guide's ladder before asking for a restart. Read that guide before a second repair attempt.

Choose the installation owner before repairing registration. Plugin installs use plugin recovery; only setup-owned registrations use the guide's registration repair plan. A plugin-only doctor result of missing does not call for rea setup.

REA setup never installs or upgrades Node.js, npm, Homebrew, Java, Ghidra, IDA, JADX, Kuna, Binwalk, or Unblob. Use existing prerequisites; do not install unrelated software to repair MCP registration. For an unsupported client, use manual stdio registration with an existing installation’s absolute runtime and entry script, 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. Prefer an existing rea CLI. When none is installed and REA package acquisition is within the authorized scope, use npx -y rea-agents@latest in its place from a trusted directory outside the target project, with absolute target paths. Managed setup binds the current installation directly; retain its runtime and package cache entry, or restore that installation before repairing its registration. For setup-owned registration, configuration repair starts with a read-only setup plan; show paths, backups and skill replacement before applying authorized changes. Preserve existing approval and target-execution boundaries.

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.

analyzejavascriptapplication.

• ASAR or extracted JavaScript/Electron tree:

executable): openbinary with the supplied local path; use inspectartifact when its graph and findings help answer the question. A PyInstaller CArchive is the application layer; the bootloader is only the native prefix. Start with detail: "summary" for large inventories, then use retained inventory views for selected member fields/pages. A complete small inventory can cost less than extra calls and schemas. Runtime options are metadata, not files. Compact delivery still inventories and hashes members. See the Python packaged applications guide.

• Archive/package member inventory (ZIP/APK/IPA/MSIX/AppX, DMG, or a PyInstaller

module graph is the application layer. Extract stored modules and analyze the JavaScript. See Bun standalone executables.

• Bun --compile executable: openbinary, then inspectartifact; the Bun

embedded virtual filesystem is the application layer. Extract stored files and analyze compatible JavaScript. Environment-file values and CA certificate bytes are retained in local Evidence with their counts and byte lengths. The npm snapshot length is reported and not decoded, and the executable is not run. See Deno compile executables.

• Deno deno compile executable: openbinary, then inspectartifact; the

openbundleresources, then the selected resource tool. This does not require CFBundleExecutable or a deep provider. Resource sessions have no executable digest or binary snapshot; use open_binary for native code.

• Apple app plist, Interface Builder, asset catalog, or keyed archive resources:

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

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

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.

• Managed PE/CLI assembly: inspectmanagedartifact.
• Firmware image: inspectfirmwareregions when advertised. Use

without a provider; see the ESP section of references/native-and-artifacts.md.

• ESP32-family app or bootloader image (0xE9 magic): inspect_artifact

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

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

choose the matching native runtime workflow. openbinary and tracenative_values establish static facts; they do not observe execution. Runtime tools have distinct launch, attach, mutation and cleanup effects, and do not require a preliminary static session unless their own contract says so.

• Native program behavior, live calls, instrumentation, or command-run effects:

and data APIs usually live on another origin. Discover API origins from absolute URLs in loaded bundles or script text via JavaScript analysis tools (another passive capture without those origins still scopes to the page origin, and completeness.excluded counts lack URLs). Pass both the page origin and those API origins in allowedorigins — the list replaces the default scope — and read completeness.excluded before reporting that an API is absent. For long captures with body shapes, use exportevidence_bundle instead of expecting an inline result.

• User-owned browser page already open: listbrowsertargets.
• Passive traffic capture of a SPA: the default scope is the page's own origin,

capturebrowserscenario with declared actions. See runtime observation for connect/launch and the focused follow-up browser tools.

• Browser action the agent must perform (click, type, navigate):

environments before recording; it records with capturebrowserscenario and writes the bundle with exportenvironmentbundle.

• Agent environment (AgentEnv bundle) of a web application: read

capture-desktop-application folder: read desktop application tasks.

• Task for a desktop application's exported environment, from a

"build me an Inkscape environment where the agent changes a poster's headline": read desktop builds. You drive the app on a build computer from startbuildcomputer, then export and witness.

• Environment of a Linux desktop app with a task, from a request such as

Fiddler workflow. Inspect saved SAZ with inspectwebnetwork_capture and format: "saz"; connect Everywhere's separate MCP server for live traffic.

• Fiddler Everywhere traffic or a native .saz capture: read the

original record ordinals when useful; inspect producer fields and byte/number sidecars without fetching recorded URLs or claiming live attribution. HAR/SAZ/qlog old-generation heap is REACAPTUREDECODEROLDGENERATIONMIB (default 192 MiB, floor 8, maximum 16384), set where REA starts. Host memory and NODEOPTIONS do not raise it. See historical captures for the exact upstream profile and credential exclusions. Qlog support starts with aioquic 1.5.0 JSON 0.3; stream coverage and endpoint loss declarations do not recover bodies or establish network loss. Prefer detail summary, then kind qlog trace/stream pages; select one trace, stream ID and direction for contribution/range pages. Facts retain all-recorded-events-before-selection scope. Other qlog layouts and PCAP correlation are unsupported.

• Retained HAR/SAZ/native mitmproxy/aioquic qlog capture: inspectwebnetwork_capture. Select

and field names/types before choosing fields for inspectpacketcapture. Query/page the relevant records; registrations do not establish observed traffic.

• User-owned Electron runtime already open: listelectrontargets. Before an electron-main Inspector attempt, check packaged fuses with inspectelectronfuses; disabled EnableNodeCliInspectArguments means the app ignores --inspect.
• Shipped application exposure for a local .app, install directory, ASAR, or executable: auditreleaseexposure / rea audit-release-exposure. Each check has a stable id, a status, and fixed remediation. Unknown and unassessed checks stay in the report. This does not establish that an application is secure. Credential-marker hits report the rule id and location only. See release exposure.
• Packet-field discovery: inspectpacketfields searches installed protocols

display filters and decode-as rules. Requires Linux, util-linux prlimit and TShark 4.x on an absolute PATH entry or via the optional absolute REATSHARKCOMMAND override; see capture guide. Packet limits count input packets before filtering. Output defaults to 50 matching frames; use matchoffset / matchlimit for later pages, or explicit null limit for complete matching output. Preserve the source digest across pages. This does not perform live capture. For address/DNS/SNI/protocol summaries use inspectpcapcapture with MCP detail summary, then retained kind pcap pages. Requires Wireshark 4.x tshark and capinfos, with Linux prlimit or Windows Job Objects; see packet summaries. Select an exact DNS question for address pages; page exhaustion does not prove network completeness. This reads recordings and does not acquire traffic.

• Recorded packet captures: inspectpacketcapture with selected TShark fields,

or selected decoder help, including channels and options. Query and page the relevant details before choosing settings; this does not scan hardware.

• Decoder discovery: inspectsignaldecoders searches installed decoder IDs

channel and protocol settings. On Linux with util-linux prlimit, supply sigrok-cli 0.7.2 through REASIGROKCOMMAND; see recording guide. Output defaults to 50 literal lines; select annotation classes and page with lineoffset / linelimit, or explicit null for all remaining output. Window counts are display lines, not annotations or samples. Preserve source digests across pages. This reads existing files; it does not acquire hardware signals.

• Recorded logic/signal traces: decodesignalrecording with explicit decoder,

through REAWABTBIN_DIRECTORY; retain exact byte/tool identity and decoded WAT. Select JavaScript glue and candidate paths explicitly and preserve URL/path ambiguity. No implicit fetch or target execution; WAT is not original source. See the WASM guide.

• Explicit local WebAssembly artifact: inspectwasmartifact. Supply WABT 1.0.42

Prefer its summary or selected signer/digest/lineage page; retain complete Evidence and use inspectanalysisview kind apk-signature for follow-ups. Reports which schemes are present (v1 JAR, v2, v3, v3.1), each signer's certificate SHA-256 fingerprint (v1 included, from its PKCS#7 block), v3 key-rotation lineage, source stamp, and whether each signed digest still matches the bytes (self-consistency). This is identity and integrity, not a trust or authenticity verdict. See the APK signature guide.

• Explicit local Android APK (or ZIP/AAB) signing: inspectapksignature.

raw or hex encoding. The owned worker deadline is timeoutms (default 30000 ms, range 1..2147483647, next call). Select byte, address-space and CPU allowances separately through producerlimits; tighter inherited OS limits remain enforced, and the 256 MiB worker heap is independent. Preserve carrier/decoded digests and treat selectors, argument strings and mutability as inferred candidates; this performs no chain lookup or target execution. For the complete inferred interface without hex or duplicate stdout, discover support and select detail: "summary"; complete Evidence stays retained under its original identity. Use the returned parentevidenceid for exact function or bytecode_hex/stdout/stderr pages. Candidate coverage does not establish interface completeness. See the EVM bytecode guide.