headless-ghidra-frida-evidence
Headless Ghidra Frida Evidence
Use this phase skill when planning must integrate externally captured
Frida-derived dynamic evidence without making live Frida execution part of the
supported headless-ghidra workflow.
The canonical contract is ./planning-brief.md. Use it
to shape planning outputs and to audit generated artifacts for weakened Frida
evidence requirements.
Phase Focus
This phase covers:
- imported Frida traces, logs, and hook context
- runtime-capture manifest consumption and evidence-manifest normalization
- provenance, replay, and verification expectations for dynamic observations
- explicit static-vs-dynamic conflict adjudication
- audit expectations for generated planning artifacts
Non-Negotiable Constraints
- Import-only scope. This skill does not execute Frida, provide live hook commands, or depend on GUI-driven capture activity.
- Runtime evidence must link back to a reviewable runtime-capture manifest from
../headless-ghidra-frida-runtime-injection/. - Headless-only workflow. Imported evidence must remain compatible with headless Ghidra planning and review.
- Evidence-backed claims. Dynamic observations must trace to captured artifacts, provenance notes, or explicit verification surfaces.
- Observed claims stay distinct from inferred or unresolved claims.
- Conflicts with static analysis preserve both evidence surfaces until a reviewer records an explicit adjudication decision.
- Reproducible workflow expectations. Reviewers must be able to see what was captured, when it was captured, and how it maps back to the target.
- Reviewable Markdown outputs. Generated planning artifacts and findings remain inspectable as Markdown.
- Runtime artifacts stay under
.work/ghidra-artifacts/and are referenced explicitly rather than copied into the skill package. - No downstream
speckitextension or constitution change is required.
Required Inputs
- existing intake summary or normalized target context
- linked runtime-capture manifest and produced artifact references
- externally captured Frida evidence bundle
- provenance details for the capture, including source and timing context
- replay or verification expectations that a reviewer must confirm
- static evidence context when the runtime evidence might disagree with existing analysis
- known evidence gaps, ambiguities, or follow-up questions
- optional local overlays that only tighten the contract
How To Use This Skill
- Fill in
./planning-brief.mdwith the imported Frida evidence bundle, linked runtime-capture manifest, provenance, and replay expectations. - Pass that brief into
speckitas a file or inline paste. - Review the generated planning artifacts against the same Frida evidence checklist before treating them as ready for implementation.
- Summarize the imported runtime outputs in
./templates/frida-evidence-manifest.md, keeping observed claims, inferred claims, and open questions separate. - If Frida-derived evidence conflicts with static analysis, record the conflict and an explicit reviewer decision instead of silently choosing one side.
- If the plan introduces reusable normalization, translation, or manifest-generation scripts, route the follow-up through script review rather than weakening this import-only boundary.
Examples
- Frida evidence handoff example:
./examples/frida-trace-handoff.md - Frida request rejection example:
./examples/contract-violation-example.md - Frida conflict-preservation example:
./examples/frida-trace-contract-violation.md
Next Step Routing
- Use this phase after intake is stable and the planning request already has externally captured Frida-derived evidence plus a runtime-capture manifest.
- Return to the runtime-injection phase when the request still needs capture planning, reusable script selection, or runtime audit gates before evidence can be trusted.
- Return to generic evidence when the source is no longer Frida-specific or the dynamic capture format does not matter to the planning contract.
- Move to script authoring and review when the plan introduces reusable normalization, translation, manifest-generation scripts, or common-library behavior changes.
- Return to intake if target identity, provenance, or scope is still unstable.
More from bytelandtechnology/headless-ghidra
headless-ghidra
Entry skill for the Headless Ghidra YAML-first reverse-engineering pipeline. Use when the user asks to analyze, decompile, triage, resume, or iterate on a binary target with Ghidra/headless-ghidra. Reads artifacts/<target>/pipeline-state.yaml, routes P0–P4 phase skills, runs gate checks, and manages review pauses. Performs zero analysis work itself.
36headless-ghidra-intake
P0 phase skill for Headless Ghidra intake. Use when a target binary/archive needs identity confirmation, workspace initialization, Ghidra discovery, binary inspection, or analysis scope setup before any Ghidra analysis runs.
35headless-ghidra-evidence
P2 phase skill for Headless Ghidra third-party evidence. Use after P1 to review baseline/runtime artifacts, identify or rule out third-party code, record pristine sources, classify functions, and capture evidence before metadata recovery.
35headless-ghidra-batch-decompile
P4 phase skill for Headless Ghidra selected function substitution. Use after P3 when an approved batch of functions should have metadata applied, be decompiled through Ghidra, and be recorded as per-function capture/substitution YAML.
33headless-ghidra-baseline
P1 phase skill for Headless Ghidra baseline and runtime evidence. Use after P0 when the target must be imported into Ghidra, auto-analyzed, exported to baseline YAML, and given reproducible runtime or hotpath observations without decompiling function bodies.
30headless-ghidra-discovery
P3 phase skill for Headless Ghidra metadata discovery. Use after P2, or after a P4 batch exposes missing context, to enrich function names, signatures, types, constants, strings, and hotpath metadata in YAML before serialized CLI apply.
30