reverse engineering anything

View saved version →

---
name: rea-analysis-companion
description: Coordinate authorized reverse-engineering investigations with the REA toolset. Use when a user asks to understand shipped software, binaries, package contents, app behavior, runtime traces, or implementation evidence; do not use for ordinary source-repository architecture analysis.
---

# reverse engineering anything

This independent guide helps plan and interpret work with [REA: Reverse Engineer Anything](https://github.com/morluto/rea). It does not include or invoke REA's local MCP server or CLI. Never imply that this skill inspected a file unless actual analysis tools or outputs are present in the current conversation.

## 1. Establish scope and authorization

- Ask what exact artifact, application, or user-owned page is in scope and what question the user needs answered.
- Proceed only when the user states they own the target or have authorization. If ownership/authorization is unclear, pause before guidance that would enable access to a third-party target.
- Keep requests bounded to a named target, feature, version, and evidence question. Do not expand into adjacent apps, hosts, accounts, or endpoints.
- Decline credential theft, malware deployment, stealth/evasion, exploitation of third-party systems, bypassing DRM/licensing/access controls, or unauthorized extraction of proprietary data. Offer legitimate debugging, defensive assessment, compatibility, or interoperability alternatives.

## 2. Verify the capability boundary

- If REA tools are present, inspect the active tool inventory and input schemas before selecting a workflow. Use only advertised tools and supported arguments.
- If tools are absent, say the current chat cannot execute REA analysis. You may provide a plan or explain how the user can configure REA locally; do not claim setup, installation, registration, or analysis occurred.
- Prefer an existing installation or supplied results. Do not run setup/doctor on every request.
- A skill-only installation does not register an MCP server, install analysis engines, or add tools to the active session.

## 3. Route by target

Use `rea-target-routing` for the detailed map. Choose one initial route from the supplied target type. When a route requires an active target and none is selected, ask for the missing path/app rather than choosing an example. For source repositories, use normal repository tools unless a claim depends on shipped artifacts or behavior not represented in available source.

## 4. Investigate summary-first

1. Convert the request into a short checklist of questions and required evidence.
2. Reuse matching sessions and existing findings if available; avoid duplicate identical calls.
3. Start with the smallest overview or inventory that can answer the question.
4. Trace only the relevant module, code path, call, state transition, or observation.
5. Follow up only when a named question remains unresolved.
6. Distinguish direct observations, inferences, and unknowns. Preserve evidence IDs and limitations.
7. Do not equate strings, symbols, pseudocode, or a static graph with execution. Runtime behavior needs runtime evidence.

## 5. Runtime and untrusted-artifact boundary

Before any operation that executes or interacts with a target, confirm the exact target and lifecycle. Warn that local REA providers use the user's permissions and are not a sandbox; processing an untrusted binary can expose the host to parser/provider risk. Never install an engine or change configuration silently. Setup plans, dependency installation, target launch, and interaction must stay within user authorization and host rules.

REA analyzes targets locally, but tool results are delivered to the model provider. Do not include proprietary binaries, credentials, private project files, or sensitive logs in prompts unless the user confirms this is allowed under their policies.

## 6. Deliver a traceable answer

Use `rea-evidence-and-reporting` to produce a concise answer with:

- finding and confidence;
- evidence IDs and what each directly shows;
- inference and reasoning, clearly labeled;
- scope, version, host/provider, and coverage boundary when known;
- unresolved questions and the smallest useful next step.

Check the original checklist before calling the investigation complete. Close tool-created native sessions when supported and the investigation is finished.

View saved version →

---
name: rea-browser-and-network
description: Plan passive observation of a user-owned browser or Electron app and interpret retained HAR/mitmproxy captures without turning historical records into live network claims.
---

# Browser and network evidence

## Browser/Electron observation

- Prefer the already-open, user-owned page/runtime and the documented REA target-listing workflow.
- Confirm the exact target and interaction. Avoid authentication changes, purchases, destructive actions, production mutations, or private account traversal.
- Distinguish DOM/page structure, loaded scripts, observed requests, screenshots, and runtime effects. A screenshot or page snapshot covers only one state.
- Do not open URLs discovered in a capture or replay requests. Do not claim a historical request came from the live page without fresh attribution evidence.

## Retained HAR or mitmproxy capture

- Confirm the user is authorized to analyze the supplied capture; it may contain cookies, authorization headers, personal data, internal endpoints, or private payloads.
- Use the advertised capture-inspection workflow on the retained file. Treat it as historical evidence, not live traffic.
- Preserve original record ordinals where useful and identify producer-specific fields/sidecars. Do not normalize away distinctions that affect interpretation.
- Redact credentials, tokens, personal data, and unrelated hosts before sharing results. Never print secrets back in the report.
- If capture evidence is incomplete, identify missing records or fields and the limited conclusion; do not fill gaps with assumptions.

Use only read-only analysis unless the user explicitly requests an authorized, tightly scoped interaction. Captured requests must not be replayed against live services.

View saved version →

---
name: rea-evidence-and-reporting
description: Interpret REA results and prepare a reviewable report that separates observations, inferences, unknowns, and coverage limits; use for analysis summaries, feature traces, comparisons, and handoffs.
---

# Evidence and reporting

## Evidence ledger

For each conclusion, record the claim; actual evidence ID(s) and source/artifact/version; whether it is direct observation, inference, or unknown; confidence and why; coverage boundary, failed/unsupported routes, and relevant environment; and the narrowest next check if uncertain.

Retain inline Evidence when no durable reference exists. Use stable same-session references when available. Do not invent evidence IDs, cite omitted details, or refer to evidence from another session without proof.

## Interpretation rules

- A string, symbol, import, filename, route, decompiled fragment, or graph edge can suggest a hypothesis; alone it does not prove behavior.
- Static analysis describes the inspected artifact and analysis coverage. It does not show that a code path executed.
- Runtime observation supports only the observed target, state, environment, and interval; it does not establish universal behavior.
- A difference between versions may come from build/configuration or incomplete coverage. Attribute it only when evidence identifies the cause.
- Preserve raw addresses, offsets, selectors, and original carrier details where relevant. Keep inferred values labeled as candidates.
- “Not found” means not found within the stated search boundary, not absent everywhere.

## Suggested report

### Answer
One sentence with confidence and scope.

### Evidence
Bullets keyed by actual Evidence IDs, with what each result directly establishes.

### Interpretation
Clearly labeled inferences and alternatives.

### Limits and unknowns
Provider/tool limitations, target/version/environment, unsearched regions, and missing runtime confirmation.

### Next step
One minimal follow-up tied to an unresolved checklist item.

For evidence bundles, write only to a user-selected path. Before sharing a report externally, remove credentials, private binary paths, proprietary artifacts, personal data, and unrelated local details.

View saved version →

---
name: rea-javascript-electron
description: Analyze an authorized JavaScript/Electron app directory or ASAR, map modules and process boundaries, or trace a requested feature through source and runtime evidence.
---

# JavaScript and Electron investigations

For a supplied app directory or ASAR, route to REA's advertised `analyze_javascript_application` capability. Static analysis needs Node.js/npm, but no native disassembler. If this tool is missing, offer the documented CLI route without claiming it was run.

1. Identify the app build/version, exact input path, and one feature/question (for example, where search is handled).
2. Start with the module/import and process-boundary overview, then trace from the user-visible entry point through relevant renderer, preload/IPC, main-process, and native-addon relationships.
3. Inspect source maps, routes, package metadata, and configuration when they affect the question; filenames and string matches are leads, not proof.
4. If comparing two versions, state how each artifact was identified and distinguish observed code differences from inferred behavioral impact.
5. Use a runtime/browser/Electron capture only when static evidence cannot resolve the named uncertainty and the user has authorized that exact target/flow. Keep the path and interaction narrow.

Describe whether evidence is static or runtime. A reconstructed implementation is a new design choice, not evidence that the original used the same architecture. Never copy proprietary code into a new product or bypass third-party access controls.

View saved version →

---
name: rea-mobile-and-firmware
description: Route authorized Android APK or firmware investigations to REA's static inspection and extraction workflows, with platform prerequisites and safe output handling.
---

# Android and firmware

## Android APK

- For archive/member inventory, use the general package route; for manifest, classes, methods, or references, use `inspect_android_package` and only advertised focused tools.
- Verify host prerequisites: upstream documents headless JADX and a full JDK for Linux/macOS; exact support varies by release.
- Separate manifest declarations, decompiled code, and inferred behavior. Static APK analysis does not establish device/runtime behavior.
- Do not install or launch the APK, access its services, or bypass signature/account/DRM controls unless the user explicitly authorizes a lawful test in a controlled scope.

## Firmware

- Use `inspect_firmware_regions` first when available. Request extraction only when the user explicitly needs it, using a caller-selected new absolute output directory.
- Upstream documents caller-supplied Binwalk/Unblob on Linux; don't install tools or write to a guessed directory.
- Treat extracted files as untrusted. Avoid launching binaries. Report format recognition/extraction boundaries and resource limits.
- Do not probe or exploit devices on a network. Keep firmware analysis offline unless the user authorizes a specific test device and action.

If required tools are absent, report the missing prerequisite and offer a static/manual alternative; do not fabricate analysis results.

View saved version →

---
name: rea-native-and-managed-artifacts
description: Plan authorized analysis of native binaries, libraries, package contents, managed .NET assemblies, Linux ELF layouts, or supplied crash cores using available REA providers.
---

# Native and managed artifacts

Use only user-supplied artifacts the user owns or is authorized to analyze. Before opening a target, state the format and question, check provider availability, and warn that the provider parses untrusted input with the user's permissions; it is not a sandbox.

## Route and scope

- For a native executable/library/database: open the exact path with `open_binary`; inspect the selected provider and active target before focused calls.
- For package member inventories, open only the supplied ZIP/APK/IPA/MSIX/AppX/DMG. Use artifact graph/findings only when they answer a named question.
- For managed PE/CLI assemblies, use static inspection and preserve metadata/CIL coverage and unresolved native boundaries.
- For offline Linux ELF layout, use `inspect_binary_layout` only when available and the target is an explicit ELF; preserve section/symbol/relocation evidence and static mitigation candidates.
- For an explicitly supplied Linux x86-64 core, use `inspect_recorded_crash`; read recorded notes/threads and raw evidence. Historical PIDs must never be used to select live processes.

## Avoid overreach

- Do not disable, bypass, patch, or remove licensing, access controls, anti-cheat, DRM, or integrity checks.
- Do not extract or disclose secrets, private keys, credentials, tokens, personal data, or proprietary information.
- Do not execute a binary merely to see what it does. If runtime evidence is necessary, explain target effects and request the exact target/lifecycle within a controlled, authorized environment.
- Do not save to or modify user-owned analysis databases or projects unless specifically requested and the tool's action is understood. Verify provider save semantics first.
- If output is partial, say so. Never report pseudocode as source or static mitigation hints as a full security verdict.

Report artifact identity, provider/version if available, evidence IDs, methods used, coverage, and the difference between observations and hypotheses.

View saved version →

---
name: rea-readiness-and-setup
description: Diagnose whether REA is available in the current agent and explain its setup prerequisites; use when REA tools are missing, stale, or the user asks how to connect a supported client.
---

# REA readiness and setup

Do not install software or alter agent configuration just because a workflow is requested.

1. Check whether the active conversation already exposes REA tools. If yes, inspect its actual tool names and schemas; proceed without running a doctor command.
2. If unavailable and the user wants local setup, first explain the host requirements. Upstream currently specifies Node.js 22.19+, 24.11+, or 26+ and npm. Native analysis can additionally require a user-installed Hopper, Ghidra, or IDA; Android and firmware routes have separate prerequisites. Static JavaScript/.NET analysis may not require a native engine.
3. Offer read-only diagnosis for a confirmed client, e.g. `npx -y rea-agents@latest doctor --client codex --json`. Use the client's documented identifier, not an assumed one.
4. If configuration repair is needed, first prepare and show a dry-run plan, e.g. `npx -y rea-agents@latest setup --client codex --dry-run --json`. Review exact paths, backups, changes, and any bundled skill replacement before applying.
5. Obtain explicit approval before a setup command writes agent configuration or installs an engine. Add `--install-hopper` only if separately necessary and specifically approved. Do not install/upgrade Node, npm, Java, Ghidra, IDA, JADX, Binwalk, or Unblob as an automatic repair.
6. After approved setup, ask the user to restart/reconnect the affected client and verify the tools actually appear. A matching config file alone does not prove an active connection.

For a JavaScript app tree or ASAR, an upstream CLI fallback is `npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json`; this needs no MCP registration or native engine. Explain that running `npx` downloads/executes a package and should be reviewed as such. Do not run it yourself unless explicitly requested and the environment/action is authorized.

Never paste secrets, private paths, proprietary binaries, crash dumps, or private analysis projects into public issues. Upstream asks for vulnerabilities to be reported privately through its Security tab.

View saved version →

---
name: rea-runtime-safety
description: Evaluate authorization and host risks before REA opens, executes, or interacts with a target, processes untrusted input, installs prerequisites, or changes client configuration.
---

# Runtime and host safety

REA is a local analysis tool, not a sandbox. A local provider can parse a supplied binary with the current user's permissions; runtime workflows can execute or interact with a selected target. Same-user malicious processes are outside the provider bridge's boundary.

Before proposing or invoking a stateful/runtime operation, enumerate:

1. Exact target identity, ownership/authorization, version, and source.
2. Whether the workflow is static, parses untrusted data, launches code, attaches to a process, uses a browser, or changes files/settings.
3. The exact action, target lifecycle, filesystem/network scope, runtime/provider, and permissions.
4. Expected effects, cleanup, time/resource limits, and a safer static alternative.

Proceed only within the user's explicit requested scope and host policy. Do not silently install a prerequisite, modify agent configuration, run a target, attach to an unrelated process, browse a discovered URL, or write over a user project. If authorization or target identity is missing, pause and ask; do not guess.

For public vulnerability disclosure, follow the upstream security policy: do not post exploit details, credentials, private binaries, Hopper/Ghidra projects, capability tokens, or sensitive local paths in public issues. Use the repository's private vulnerability-reporting channel.

View saved version →

---
name: rea-specialized-formats
description: Handle focused REA workflows for ELF layout, recorded crashes, EVM bytecode, process runs, and other nonstandard carriers while preserving raw evidence and inference boundaries.
---

# Specialized formats

- **Offline ELF layout:** on a caller-supplied Linux ELF, use `inspect_binary_layout` only if advertised. It relies on caller-supplied pwntools, does not open a disassembler database, and may list static mitigation candidates. Preserve raw offsets, symbols, relocations, and coverage.
- **Recorded Linux x86-64 core:** use `inspect_recorded_crash` for the explicitly supplied core. Keep every recorded thread and raw note as evidence; historical PIDs are not live-process selectors. Optional mapping/debugger context requires an explicit relevant question.
- **EVM bytecode:** use `inspect_evm_interface` only on an explicit raw/hex carrier with caller-selected encoding. Preserve carrier and decoded digests. Selectors, inferred arguments, and mutability are candidates—not verified ABI or chain state. Do not perform chain lookups or execute transactions.
- **Process capture or run comparison:** inspect the live tool schema before use. It may execute a command and observe output, interactions, filesystem changes, or exit state with the user's permissions. Confirm the exact command, target, cwd, environment, limits, and intended effects first.
- **Other formats:** do not force a target into the closest route. Ask for the exact format and question, then consult current upstream documentation and live capabilities.

Never treat malformed input, missing dependencies, timeouts, or partial coverage as successful analysis. Explain the returned status and safest next step.

View saved version →

---
name: rea-target-routing
description: Select the appropriate REA workflow and prerequisites for a supplied binary, archive, JavaScript/Electron app, web target, capture, Android package, firmware image, managed assembly, ELF, EVM bytecode, or process trace.
---

# REA target routing

Use the user's actual target and question. This is a routing guide, not a claim that REA tools are connected. Verify the installed REA version and live tool availability because main-branch documentation can exceed an older package.

| Target and question | Initial route | Important boundary |
| --- | --- | --- |
| Native executable/library/database | `open_binary`, then focused analysis; use `binary_overview` if advertised and useful | Select a supported provider; do not infer runtime behavior from static output |
| ZIP/APK/IPA/MSIX/AppX/DMG member inventory | `open_binary`; then `inspect_artifact` only if graph/findings answer the question | Inventory is not proof of behavior |
| JavaScript/Electron tree or ASAR | `analyze_javascript_application` | Static analysis needs Node.js/npm but no native disassembler; source completeness matters |
| Existing user-owned browser page | `list_browser_targets` | Do not open guessed URLs or access third-party systems without scope |
| Existing user-owned Electron runtime | `list_electron_targets` | Observe only the selected running app and requested flow |
| Retained HAR/mitmproxy capture | `inspect_web_network_capture` | Historical capture only; do not fetch captured URLs or claim live attribution |
| .NET managed PE/CLI assembly | `inspect_managed_artifact` | Static metadata/CIL is not runtime evidence |
| Android APK/classes/methods | `inspect_android_package`, then focused advertised Android tools | Requires host-specific JADX/JDK prerequisites; use only authorized APKs |
| Firmware image | `inspect_firmware_regions`; `extract_firmware` only if asked | Caller-supplied Binwalk/Unblob on supported Linux; output directory must be user-selected |
| Linux ELF section/symbol/relocation/static mitigation layout | `inspect_binary_layout` | Caller-supplied pwntools; offline operation, not a disassembler database |
| Linux x86-64 core dump | `inspect_recorded_crash` | Historical PIDs do not select live processes; parse recorded threads only |
| EVM bytecode in explicit raw/hex carrier | `inspect_evm_interface` | Select encoding; selectors/arguments/mutability are inferred; no chain lookup or execution |
| Process capture/run comparison | Use the process-capture workflow advertised by connected REA | Runtime commands have effects; restrict command, cwd, env, timeout, and expected lifecycle |

Do not call unavailable or unadvertised commands. If a tool reports a capability constraint, relay its exact reason and prerequisite rather than retrying a different target or silently installing software. For a target-free session, bind a caller-supplied target first when the tool requires it.