reverse-engineer-anything – skill Dữ liệu & Khoa học cho agent AI

REA

External tool prerequisite

Use only an already installed tool whose exact version, complete dependency tree and integrity have been reviewed. This skill does not bootstrap tools or activate external plugins. If the prerequisite is missing, stop that executable path and report it; continue with static analysis when possible. A separate installation task must pin immutable artifacts, stage them outside active agent directories with lifecycle scripts disabled, inspect every bundled file and executable entry point (including tests and hooks), and obtain approval before activation or host configuration changes. Do not substitute a same-named workspace script or fetch a moving branch.

Current upstream location

The active authored skill is at [morluto/rea — reverse-engineer-anything](https://github.com/morluto/rea/tree/main/.agents/skills/reverse-engineer-anything). The source frontmatter retains the historical import location to preserve provenance identity; that old path is not a current installation URL. Use the active link for upstream inspection and retain the reviewed local reference bundle. A moving upstream branch is reference material, not approval to install or execute it.

When to Use

• Use when a claim depends on a shipped application, binary, package, or requested runtime evidence.
• Use for decompilation, evidence-backed feature traces, version comparisons, or investigation-guided reconstruction.
• Skip REA for ordinary source-code analysis of a complete repository.

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.

Limitations

• The skill supplies investigation guidance; it does not register the REA MCP server or install analysis engines.
• Native-analysis availability depends on the selected provider, host, and target format. Hopper is separate licensed software; Ghidra and IDA are bring-your-own.
• Static analysis does not establish runtime behavior or recover original source code. Report provider-specific coverage, partial results, and unknowns.
• REA runs analysis locally, but the connected model provider may have separate data-handling policies.

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

rea-agents doctor --client codex --json. Substitute the current

supported client: claude_code, claude_desktop, codex, cursor,

gemini_cli, windsurf, devin, opencode, antigravity, copilot_cli,

commandcode, vscode, grok_build, omp, or grok_bot. grok_bot has no local

file registration: doctor reports the Grok Bot chat step, and setup does not

write mcp.json. 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:

rea-agents 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

rea-agents 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:

rea-agents 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.
• Explicit local EVM bytecode carrier: inspect_evm_interface with caller-selected

raw or hex encoding. Preserve carrier/decoded digests and treat selectors,

argument strings and mutability as inferred candidates; this performs no chain

lookup or target execution. See the

[EVM bytecode guide](https://github.com/morluto/rea/blob/main/docs/evm-bytecode.md).

• Explicit Linux ELF file for offline layout, symbols, relocations or static

mitigation evidence: inspect_binary_layout. This target-free operation uses

caller-supplied pwntools without opening a disassembler database. Preserve its

raw locations and inference/coverage limits; see the

[offline binary guide](https://github.com/morluto/rea/blob/main/docs/binary-diagnostics.md).

• Supplied Linux x86-64 ELF core: inspect_recorded_crash. Read every recorded

thread, raw note and source-bound register without opening a live target.

Historical PIDs do not select live processes. Request include_debugger_context

only when core-only mapping candidates help; see the

[recorded crash guide](https://github.com/morluto/rea/blob/main/docs/recorded-crashes.md).

• Native executable, library, or analysis database: open_binary, then

use focused analysis tools directly; call binary_overview when metadata or

inventory context is useful and available from the selected provider.

For an existing IDA MCP configuration, use open_binary with the original

input binary and provider_id: "ida"; d

… (nội dung đầy đủ có trong gói tải về)