opencode-skills-collection 4.1.11 → 4.1.12

package/bundled-skills/reverse-engineer-anything/SKILL.md

@@ -0,0 +1,239 @@
+---
+name: reverse-engineer-anything
+description: Use REA to investigate shipped apps, binaries, packages, and runtimes; trace features with evidence, compare versions, or guide reconstruction. Skip ordinary source-code analysis.
+risk: safe
+source: "https://github.com/morluto/rea/tree/main/skill-src/reverse-engineer-anything"
+source_repo: "morluto/rea"
+source_type: community
+date_added: "2026-10-10"
+license: "MIT"
+license_source: "https://github.com/morluto/rea/blob/main/LICENSE"
+metadata:
+  version: "34"
+---
+
+# REA
+
+## 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
+   `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`, `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:
+   `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:
+
+```bash
+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`.
+- 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"`; do not pass an `.idb` or `.i64` database.
+The legacy attached profile binds the already-open GUI input by SHA-256 and
+leaves its database open. The modern headless profile creates and closes an
+owned private database without saving. Installation and registration reuse
+[mrexodia/ida-pro-mcp](https://github.com/mrexodia/ida-pro-mcp); see the
+[IDA provider guide](https://github.com/morluto/rea/blob/main/docs/ida-provider.md).
+Proceed directly to `analyze_function`, pseudocode, or function/string searches
+after opening; IDA does not supply `binary_overview`. Consult session availability
+when composing broader workflows. Modern direct callers and unsupported dossier
+facets remain unknown; live IDA results are not replayed from snapshots.
+
+If the app is missing, ask which app to inspect. Resolve a human-readable app
+name to one clear installed artifact when possible; ask only when matches are
+ambiguous. Never choose an example app on the user's behalf.
+
+In a target-free session, use `open_binary` to bind any archive/package or
+native target whose analysis tool operates on the active target. Do not call an
+unadvertised tool; inspect `binary_session` with `{}` and its
+`result.tool_availability` for availability reasons and remediation. The tool
+list stays complete; availability depends on the operation, target, and host.
+
+## Work summary-first
+
+Start with the default result and use its inline Evidence and graph context.
+Do not repeat an identical tool call. Make a focused follow-up only when the
+returned result leaves a specific question unanswered.
+
+If MCP reports `resource_constraint` with `details.resource: "transport"`, call
+`inspect_analysis_view` with its reported same-session Evidence reference for a
+summary, one section/module, or a stable page. Use `trace_application_feature`
+once a seed is known, or call `export_evidence_bundle` to write the complete
+session to a selected path. The analysis remains complete in the ledger; avoid
+repeating it merely to request the same oversized response. Complete CLI JSON
+output also streams without a single MCP frame.
+
+Every conclusion must distinguish observations, inferences, and unknowns. Cite
+Evidence IDs, preserve limitations and incomplete coverage, and never imply
+that static analysis observed execution. Runtime requests execute the declared
+target and lifecycle; do not broaden the target or action beyond those fields.
+
+Within the user's requested investigation, call available analysis tools
+directly. REA does not require permission grants or per-call approval flags.
+Follow the declared request scope and the host's actual access requirements.
+
+## Plan broader investigations
+
+For requests that span multiple features or subsystems, use a staged workflow:
+
+1. Turn the request into a checklist of questions and the evidence each answer
+   needs. Resolve target identity and constraints from the conversation and
+   workspace before asking for information again.
+2. Inspect the current REA session, artifact identity, saved analysis database,
+   bookmarks, and prior evidence. Reuse matching state; do not open duplicate
+   sessions or repeat identical analysis.
+3. Start with the smallest useful overview or inventory. Follow each question
+   from its entry point through relevant data and state changes to its result.
+   Batch related operations around a specific hypothesis, then expand only when
+   the returned evidence leaves a concrete gap.
+4. Inspect relevant packaged resources and configuration alongside code when
+   they affect the question. Use format-aware inventory and parsers; do not
+   infer behavior from filenames, strings, or layout alone.
+5. Corroborate a conclusion with the evidence type it requires. Use runtime
+   observation only when static evidence cannot answer the question and the
+   required host runtime and OS access are available. For JavaScript behavior,
+   run probes against the actual app through the available browser, Electron,
+   or process capture workflow.
+6. Decompose work into independent questions. When parallel workers are
+   available and the questions do not depend on one another, assign distinct
+   scopes, point workers to existing evidence, and ask them to return sources,
+   conclusions, and unresolved gaps. Otherwise, work sequentially.
+7. Keep a concise finding ledger linking each conclusion to Evidence IDs,
+   confidence/evidence type, search boundary, and remaining unknowns. Update
+   the shared index or investigation report so later passes can reuse results.
+
+Before finishing, revisit the original checklist. Mark each question as
+answered, partially answered, or unresolved based on its evidence; keep
+bounded negative searches bounded, and do not describe a broad investigation
+as complete while required questions remain open.
+
+## Read only the relevant guide
+
+- Native binaries, managed assemblies, archives, and extraction:
+  [references/native-and-artifacts.md](references/native-and-artifacts.md)
+- ASARs, extracted JavaScript, feature tracing, and version comparison:
+  [references/javascript-applications.md](references/javascript-applications.md)
+- Android APK declarations, classes, methods, and static references:
+  [references/android-applications.md](references/android-applications.md)
+- Passive browser/Electron observation and static/runtime reconciliation:
+  [references/runtime-observation.md](references/runtime-observation.md)
+- Evidence paging, comparisons, residual unknowns, and verification:
+  [references/evidence-workflows.md](references/evidence-workflows.md)
+
+## Finish the task
+
+Explain findings in plain language and tie them to returned evidence. When the
+user asks to build something, use normal coding tools and separate observed
+behavior from design choices. Close an opened native session with
+`close_binary` when the investigation is complete.

package/bundled-skills/reverse-engineer-anything/references/android-applications.md

@@ -0,0 +1,34 @@
+# Android application artifacts
+
+Use the connected server's advertised Android tools. Repository main and npm
+4.1.0 include this family. A skill installation alone cannot add it to an
+older server.
+
+Start with `inspect_android_package` on the caller's APK path for package
+identity, manifest declarations, coverage, and inline Evidence. Use
+`search_android_classes` to find candidates, `inspect_android_class` for one
+class's members, `inspect_android_method` for decompilation, and
+`trace_android_references` for incoming static references. Each call takes its
+own APK path and explicit selectors; do not open a native session first.
+Choose an `overload_index` from the class inventory when methods are ambiguous
+instead of guessing.
+
+The provider requires a separately supplied headless JADX MCP JAR 0.7.1 and
+Java 17 or newer. `REA_JADX_MCP_JAR` selects the absolute JAR path; `JAVA_HOME`
+can select Java. REA setup does not install or configure that JAR, and doctor
+provider scopes cover Hopper/Ghidra rather than JADX. Use existing tools and
+report missing prerequisites for the Android task specifically.
+
+Linux and macOS use the POSIX owned-process boundary. Windows x64 requires the
+matching bundled native controls and uses an owned Job Object with bidirectional
+stdio. A full JDK, including `jdk.compiler`, is required on every host; Windows
+`JAVA_HOME` selects `bin\java.exe`. Consult the Android guide for actual host
+verification coverage. Calls use one worker and provider deadlines; optional
+`REA_JADX_HEAP_MIB` selects the JVM heap. The APK is never launched,
+and no emulator is required.
+
+Manifest entries and decompiled text are static observations, not execution or
+policy enforcement. Incoming references are recovered static relationships;
+reflection, dynamic loading, and unresolved calls remain unknown. Preserve
+artifact digests, locations, diagnostics, and incomplete coverage. For archive
+members rather than code analysis, use `open_binary` and `inspect_artifact`.

package/bundled-skills/reverse-engineer-anything/references/evidence-workflows.md

@@ -0,0 +1,40 @@
+# Evidence, comparison, and verification workflows
+
+Evidence-producing tools return the complete Evidence record directly in MCP
+`structuredContent` and CLI JSON. Read `normalized_result` for operation data,
+and cite `evidence_id` when another tool or your explanation needs a stable
+reference. Preserve authority, limitations, coverage, and residual unknowns. If a result
+is incomplete or paginated, continue only when the remaining data matters to
+the task; do not fetch a bundle or resource merely to read a result already
+returned inline. When complete `inspect_binary_layout` or
+`analyze_javascript_application` Evidence is already retained, call
+`inspect_analysis_view` for a summary, one section/symbol/module, or a stable
+page instead of repeating the producer.
+
+Use `record_unknown` to track unresolved questions in the user's investigation
+and name the authority or environment still required. Supply supporting and
+contradicting evidence IDs. It updates the session registry directly.
+Use `update_unknown` with the current revision; reread after a stale revision
+instead of retrying blindly. Only qualifying observed evidence can verify a
+resolution.
+
+Use comparisons with complete, compatible page sets when claiming equivalence
+or absence:
+
+- `compare_artifacts` compares inventory pages by occurrence path, content,
+  metadata, and graph relations.
+- `compare_functions` compares explicit function Evidence, not fuzzy
+  whole-binary matches.
+- `compare_bundles` compares canonical bundle membership and unknown history.
+- `find_changed_behavior` combines existing comparisons; static differences
+  remain candidates, not causal proof.
+- `build_call_path` needs explicit function dossiers from one artifact/provider;
+  an incomplete frontier makes absence unknown.
+- `correlate_static_and_runtime` uses explicit mappings; matching patterns are
+  hypotheses, not causality.
+- `verify_reconstruction` evaluates a finite typed specification. A pass covers
+  only declared comparable claims, not global equivalence.
+
+Process captures are opt-in behavioral evidence, not a security sandbox. V3
+captures cannot be upgraded to V4; rerun the original scenario. Distinguish root
+exit from descendant settlement and require freshness when the task needs it.

package/bundled-skills/reverse-engineer-anything/references/javascript-applications.md

@@ -0,0 +1,70 @@
+# JavaScript and Electron application artifacts
+
+Use `analyze_javascript_application` directly on the operator-supplied ASAR or
+extracted tree. The complete result, graph, and Evidence context are returned
+inline when they fit the MCP frame. Source-map contents are part of the static analysis. Start from its
+findings, coverage, unknowns, and graph context, then make a focused follow-up
+only when a specific question remains unanswered.
+
+An oversized response reports `resource_constraint` and
+`details.resource: "transport"`. Reuse
+`details.reported_limits.evidence_reference` with `inspect_analysis_view` for a
+summary, one module, or a stable page of module identities. Use
+`trace_application_feature` once a module, route, or string seed is known.
+`export_evidence_bundle` writes the complete canonical session to a
+caller-selected file. These workflows keep the original Evidence and coverage;
+a broad follow-up can also exceed framing.
+
+BrowserWindow preferences, preload and contextBridge surfaces, IPC
+registrations, utility processes, and native binding requests are static syntax
+observations. Only a unique exact literal IPC channel match supports an inferred
+pairing. Dynamic or ambiguous channels remain unresolved. A requested `.node`
+member is not a verified native export. Never claim runtime reachability,
+registration, defaults, or policy enforcement from static analysis.
+
+Use `trace_application_feature` on existing application Evidence for one
+literal node ID, route, string, API, IPC channel, module, or native export.
+Choose a direction and reuse the returned application Evidence ID when the
+connected server advertises retained references, or supply complete Evidence
+inline. Include
+Hopper or Ghidra Evidence only when its artifact digest matches exactly.
+
+For version comparison, analyze each version once, then call
+`compare_application_versions`. Accept only its digest, source-map, structural
+fingerprint, or non-module semantic matches. Module ordinals and minified names
+are not persistent identity. Report added or removed only with complete
+opposite-side coverage; otherwise report unknown.
+
+When the question asks how one exact exported callable's returned object shape
+changed, analyze each version once and then call
+`compare_javascript_export_shapes` with explicit module paths and export names.
+Use the returned IDs on the same connection, or complete inline Evidence
+records, from both analysis calls. Accept variant
+pairing only through the tool's unique exact literal discriminant. Read
+`property_inventories` and each change's `presence` before treating `unknown` as
+"the name was not observed": inventories list observed property names even when
+values stay unknown, with a `source_range` for each paired or unpaired variant.
+Array holes and mutation-invalidated slots are not observed properties.
+Complete parent coverage reports presence-only
+`added`/`removed` independently of unresolved values. Cite the
+comparison Evidence and report JSON Pointer changes; dynamic values, ambiguous
+variants, and incomplete parent-property coverage stay unknown. This is static
+inference, not runtime behavior. When runtime semantics are needed, run
+behavioral probes against the relevant application versions and capture them
+through the available browser, Electron, or process workflows.
+
+## Reusing application Evidence
+
+When advertised by the connected server, application trace and compare tools
+accept complete inline Evidence or
+`{"kind":"retained-evidence","evidence_id":"ev_<64 lowercase hex characters>"}`
+for their application input (`application`, or `left`/`right`). `inspect_analysis_view`
+uses the same retained-reference form in `source`, or portable inline Evidence,
+to project a summary, module page, or one module with its recorded observations. This notation is
+a template: replace it with the actual returned ID. Versions before 4.1.0 accept only full
+inline Evidence. Use the exact ID
+returned by the producer on the same MCP connection. Resolution does not run
+analysis or select a provider; findings remain inline. Native observation
+arrays still take full Evidence. `close_binary` clears retained references;
+export a bundle before closing, or supply portable inline Evidence in another
+connection. A missing reference includes its ID and recovery guidance.

package/bundled-skills/reverse-engineer-anything/references/native-and-artifacts.md

@@ -0,0 +1,146 @@
+# Native, managed, and packaged artifacts
+
+## Recorded Linux crashes
+
+Use `inspect_recorded_crash` with an explicit Linux x86-64 ELF core path to
+inspect historical thread registers, signals, raw notes and original file
+ranges. It is independent of the active disassembler target. Source-bound
+register values and note bytes are observations; missing notes, signal-thread
+association and current executable/library identity remain unknown. PIDs are
+historical metadata and never authorize live attach or control.
+
+The optional `include_debugger_context` facet adds mapping candidates through
+caller-supplied GDB/pwndbg in an owned core-only session. Display names do not
+establish current file identity; zero reported flags leave permissions unknown.
+Requested unavailable context fails with setup guidance. See
+[recorded crashes](https://github.com/morluto/rea/blob/main/docs/recorded-crashes.md)
+for exact upstream profiles, bounds and verification coverage.
+
+## Offline ELF layout
+
+Use `inspect_binary_layout` with an explicit local ELF path for file-backed
+sections, symbols, relocations, linkage names, and static mitigation inferences
+without opening a disassembler target. When that complete record is already
+retained, call `inspect_analysis_view` for a summary, mitigations or linkage
+facet, one section or symbol, or a stable page. Do not re-run the decoder to
+read a single object.
+
+## Native targets
+
+After `open_binary`, use focused search, procedure, or function tools directly.
+Use `binary_overview` when target metadata or inventory context helps answer the
+question. Prefer literal search, names, decompilation, callers, callees, and
+cross-references. Addresses and recovered pseudocode are analysis observations,
+not original source. Provider unavailability and unsupported metadata remain
+unknown rather than false.
+
+To see which functions or Objective-C methods a Mach-O actually calls in one
+run, use `observe_native_calls` with explicit breakpoints and a bounded
+`duration_ms`/`max_events`. It launches a new process under LLDB, so the target
+runs and may change files or use the network. Hardened-runtime targets need the
+`get-task-allow` entitlement.
+
+Use `binary_session` with no arguments to check the open target, selected
+provider, and alignment. Its default `result.tool_availability` includes the
+complete tool inventory with availability reasons and remediation. When choosing
+a tool, use its entry in that result; `tools/list` retains the complete catalog
+when the target or provider state changes.
+
+## DOS MZ with Ghidra
+
+For an admitted DOS MZ target, use `inspect_native_load_image` to check measured
+loaded bytes, file mappings, relocations and the entry against the immutable
+snapshot. Keep `mismatch` and `unsupported` explicit. Verified import covers the
+reported static image, not runtime DOS or PC-98 hardware behavior.
+
+Use `read_bytes` for initialized analysis memory and `address_to_file_offset` to
+anchor one observed address to original file bytes. Loader fixups can change a
+word; a source offset does not imply byte equality. Complete function body ranges
+use inclusive ends and can contain gaps. Do not treat the enclosing span as code.
+For packed targets, retain the original and separately derived artifact identities;
+decompiling an unpacking stub does not recover the unpacked program.
+
+When reading Objective-C dispatch metadata, distinguish class implementation
+methods from protocol requirements: class methods report null requirement
+flags, while decoded protocol declarations retain required and optional facts.
+Property attributes remain raw name/value tokens; use the property's
+`atomicity` field for the decoded `N` marker or the default atomic behavior.
+Null class/meta flags, ivar counts, atomicity, or read-only values mean the
+selected provider did not establish that fact. Symbol names alone do not prove
+that a class is a root class or has no ivars.
+
+## Managed PE/CLI
+
+Start with `inspect_managed_artifact`. REA's canonical managed inspection is
+execution-free: do not claim it loaded, reflected, executed, or resolved the
+assembly. Keep managed/native boundaries and unavailable reconstruction facts
+explicit. A bring-your-own reconstruction oracle is separate from the canonical
+parser and must not become an implicit setup dependency.
+
+### .NET NativeAOT
+
+NativeAOT binaries contain native machine code, so ordinary CIL decompilers
+cannot recover the original method bodies. When managed metadata/CIL is absent,
+classify that as a native-analysis route rather than claiming source recovery.
+Open the native image with the selected deep provider and inspect functions,
+strings, calls, and references; describe decompiler output as pseudocode and
+inference.
+
+NativeAOT images can be PE/COFF, ELF, or Mach-O executables and shared
+libraries. Use file bytes and loader metadata rather than suffixes to identify
+them. For packaged apps, inventory/extract with REA's artifact tools and retain
+the exact contained image identity. PDB, ELF debug, or dSYM sidecars are
+additional evidence only when the provider accepts and matches them.
+
+For deeper type recovery, the optional third-party
+[Ghidra NativeAOT analyzer](https://github.com/Washi1337/ghidra-nativeaot)
+rehydrates ReadyToRun metadata and can recover method tables, type relationships,
+frozen objects, and strings. This is a Ghidra extension with its own install and
+interactive workflow; it is not currently part of REA's managed parser or
+headless Ghidra bridge. Treat its annotations as analysis evidence, retain the
+binary identity, and do not present recovered types as original source. Header
+discovery may require a symbol or analyst identification of the ReadyToRun
+header, depending on the binary and analyzer version.
+
+## Packages and extraction
+
+Use `inspect_artifact` for application bundles, archives, ZIP/APK/IPA/MSIX/AppX,
+ASAR, or DMG inputs when the artifact graph and findings help answer the
+question. It returns the complete artifact graph inline. Cite graph manifest
+IDs when using them.
+
+For an IPA or a macOS `.app`, ZIP, or DMG, pass the inventory Evidence to
+`project_apple_application_graph`. It reports application roots and nested
+bundles by path convention: app extensions, XPC services, frameworks, login
+items, system and driver extensions, and plug-ins. It also lists privileged
+helpers, launchd plists, symlinks, and each bundle's `info_plist_path` and
+executable candidates. Roles are path conventions, not parsed plists; read the
+listed plists with `inspect_plist`.
+
+After `open_binary` on a `.app` or Mach-O, use `trace_dylib_resolution` to see
+which file each `@rpath`, `@loader_path` and `@executable_path` load reaches for
+every executable in the bundle. It also lists missing or weak loads and earlier
+`@rpath` candidates that are absent. Narrow large bundles with `roots` or
+`architecture`. System paths stay undetermined because the dyld shared cache
+provides them.
+
+Use `extract_artifact` when materialized files are needed. It takes no arguments
+and materializes all regular files into a fresh temporary directory chosen by
+REA. Symlinks and encrypted entries are inventory facts, not extractable files.
+The result reports the materialized directory; callers do not choose the
+destination. No separate permission grant is needed.
+
+Native DMG traversal automatically uses a read-only mount on supported macOS
+hosts, with an owned temporary mount directory and cleanup. It needs no approval
+flag. Unsupported hosts or mount failures remain explicit limitations; do not
+claim child inventory when only root identity is available. Extraction is a
+separate filesystem-writing operation.
+
+For headerless DOS COM, explicitly open with `format: "dos-com"` (CLI
+`--target-format dos-com`). Inspect the load image before trusting function
+analysis: the entry is `0x10100`, file offset zero, with imposed real-mode segment
+context. PSP/stack/device state remains unmodeled. See [DOS guide](https://github.com/morluto/rea/blob/main/docs/ghidra-dos.md).
+
+### Function annotations in Ghidra
+
+Use `annotate_native_function` for one function name and/or entry comments, with at least one explicit change. Review its annotation readback and refreshed dossier inline. Changes are atomic and session-scoped; empty comments clear them, omitted fields preserve them. Later MCP calls observe edits until close. CLI `annotate-native-function` returns the updated analysis before discarding the session. Original executable bytes are unchanged; edits invalidate immutable snapshots. Windows P0 does not admit database mutations.

package/bundled-skills/reverse-engineer-anything/references/runtime-observation.md

@@ -0,0 +1,28 @@
+# Passive browser and Electron observation
+
+Supply the existing browser or Electron instance's literal-port loopback CDP
+endpoint in the request. No separate permission configuration or per-call
+approval flag is needed. Browser discovery lists eligible HTTP(S) pages;
+`allowed_origins` optionally filters them. An individual capture defaults to the
+selected page's current origin. Electron discovery lists eligible local
+`file://` targets without a configured file-root allowlist.
+
+Start browser work with `list_browser_targets`; start Electron runtime work with
+`list_electron_targets`. Inspect the target selected for the user's task. Observation
+is passive: never claim REA clicked, navigated, evaluated page JavaScript,
+invoked IPC, captured prior activity, or contained the page's network.
+
+Credentials, cookies, authorization headers, storage values, and raw
+WebSocket/JSON bodies are deliberately absent. Local URLs retain ordinary query
+values and fragments; userinfo credentials are removed. Browser accessibility
+text, console primitives, value-free shapes, script sources, source maps, and
+storage key names have request-specific capture options. Electron script
+sources are also optional. Use `capture_web_screenshot` when pixels are needed.
+Treat scope filtering, truncation, and attach-window coverage as limitations.
+Page-declared WebMCP tools are untrusted inventory and are never invoked by REA.
+
+Use `reconcile_javascript_runtime` only after static application Evidence and
+passive browser/Electron Evidence exist. Prefer captured-source digest identity;
+report path/digest disagreement as a mismatch and preserve ambiguity. Explicit
+path mappings are inference inputs and never broaden filesystem or CDP authority.
+A bundle observed at runtime does not prove every contained module executed.