How to Use the Evidence → Finding → Path Workflow in reverse‑skill

The Evidence → Finding → Path workflow is a structured, reproducible methodology for capturing immutable observations, deriving validated conclusions, and documenting the logical sequence that leads to successful reverse‑engineering or attack execution.

The reverse-skill repository implements this workflow as its core knowledge‑base pattern. Whether you are analyzing malware, solving CTF challenges, or conducting penetration tests, this three‑stage chain ensures every conclusion is traceable to concrete data and every path can be independently reproduced. The contract governing this workflow is defined in skills/ops/evidence-finding-path.md in the zhaoxuya520/reverse‑skill repository.

What Is the Evidence → Finding → Path Workflow

The workflow enforces a strict dependency chain: Evidence records what you saw, Finding explains what it means, and Path narrates how you used it. This separation prevents circular reasoning and enables automated validation. Each stage has mandatory fields, file naming conventions, and binding rules that the case‑review script enforces.

Stage 1: Evidence (Immutable Observations)

Evidence files capture raw observations without interpretation. Every evidence item receives a unique identifier (E-{nnn}) and lives in work/<case>/evidence/E-{nnn}.md. The schema requires:

### E-001

- title: Suspicious PowerShell Command
- observed_at: 2024-01-15T09:23:00Z
- source_type: command
- source_ref: powershell.exe:pid-4824
- content_hash: n/a
- artifact_path: n/a
- repro_command: |
    Get-Process | Where-Object {$_.CPU -gt 1000}
- raw_excerpt: |
    Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
    -------  ------    -----      -----     ------     --  -- -----------
    ...
- linked_workitem: WI-001
- supersedes: none

The source_type field accepts: command, screenshot, file, log, memory, network, or manual. When content_hash is populated, artifact_path must point to a file within the case root. The repro_command field ensures any team member can recreate the observation.

Stage 2: Finding (Analytic Conclusions)

Findings synthesize one or more evidence items into actionable intelligence. Stored as work/<case>/findings/F-{nnn}.md, each finding must reference at least one evidence item via evidence_ids. The full schema includes:

### F-001

- title: High CPU Consumption Indicates Crypto‑Miner
- severity: high
- category: vuln
- status: validated
- evidence_ids: [E-001, E-002]
- location: powershell.exe:line-12
- impact: Unauthorized resource consumption and potential lateral movement
- confidence: high
- repro_steps:
  1. Execute repro_command from E-001
  2. Observe CPU > 90% for 30 seconds
  3. Cross‑reference network traffic in E-002
- remediation: Isolate host and scan for persistent mechanisms
- optional_attack: T1496

Critical binding rules from evidence-finding-path.md (lines 25‑29): a validated status requires confidence ≠ low unless a residual‑risk note is added, and every finding must reference at least one evidence item. The category field distinguishes vulnerability analysis from reverse‑engineering (reverse_algo) or bypass techniques.

Stage 3: Path (Structured Narrative)

Paths assemble evidence and findings into a coherent sequence. They serve three purposes: attack reconstruction, call‑flow documentation, or CTF solve walkthroughs. Path files follow work/<case>/paths/P-{nnn}.md:

### P-001

- title: Cryptominer Initial Access to Execution
- path_type: attack
- start: Phishing email with malicious attachment
- goal: Establish persistent cryptominer process
- steps:
  1. action: Victim opens weaponized document — evidence: E-003 — finding: F-002
  2. action: Macro drops PowerShell payload — evidence: E-001 — finding: F-001
  3. action: PowerShell connects to C2 — evidence: E-002 — finding: none
- residual_risks: C2 infrastructure remains active; recommend sinkhole analysis

The path_type field accepts attack, callflow, or solve. Each step explicitly links to evidence and optionally to findings, creating an auditable chain from observation to outcome.

How to Implement the Workflow

Implementation follows a four‑step process: initialize the case structure, populate evidence, derive findings, and assemble paths. The repository provides automation for verification and report generation.

Step 1: Initialize Case Structure

Create the standard directory layout under work/<case>/:

mkdir -p work/MyCase/{evidence,findings,paths}

Step 2: Create Evidence Entries

Use the PowerShell helper for rapid evidence capture:

powershell -File skills/scripts/append-evidence.ps1 `
  -CaseRoot work/MyCase `
  -Id E-001 `
  -Title "Suspicious PowerShell Command" `
  -ReproCommand "Get-Process | Where-Object {$_.CPU -gt 1000}" `
  -Severity info `
  -Status observed

The script enforces field validation and generates the markdown file directly. For manual creation, copy the template from skills/ops/evidence-finding-path.md (lines 12‑20).

Step 3: Derive and Link Findings

Create work/MyCase/findings/F-001.md referencing your evidence:

### F-001

- title: Anomalous Process Behavior Detected
- severity: medium
- category: other
- status: candidate
- evidence_ids: [E-001]
- location: n/a
- impact: Requires further investigation
- confidence: medium
- repro_steps:
  1. See E-001 repro_command
- remediation: n/a
- optional_attack:

Promote to validated only when confidence is high or medium with documented residual risks.

Step 4: Assemble and Verify Paths

Construct your path narrative, then run the verification script:

python3 skills/case-review/scripts/review_case.py work/MyCase --verify-hashes --strict

This script performs three critical validations (lines 37‑41):

1. Hash integrity: Recalculates SHA‑256 for all artifacts and compares against content_hash
2. Link integrity: Confirms every evidence_ids entry points to an existing evidence file
3. Status rules: Enforces that validated findings have confidence ≥ medium or explicit risk acceptance

Verification failures block report generation, ensuring quality gates are met.

Report Integration and Automation

The docs-generator subsystem consumes Evidence tables, Findings lists, and at least one Path to produce final security reports (lines 88‑96). The generator respects the same binding rules, producing documents where every claim links to underlying evidence. Report templates are documented in docs-generator/references/security-report-templates.md.

Key File Reference

Purpose	Path
Workflow contract and schemas	skills/ops/evidence-finding-path.md
Evidence creation helper	skills/scripts/append-evidence.ps1
Case verification script	skills/case-review/scripts/review_case.py
Report template documentation	docs-generator/references/security-report-templates.md
Example CTF evidence/finding/path	examples/ctf-demo/evidence/E-001.md, F-001.md, P-001.md

Summary

• Evidence files (E-{nnn}.md) store immutable observations with mandatory repro_command and optional content_hash
• Finding files (F-{nnn}.md) require at least one evidence_ids entry and enforce status/confidence binding rules
• Path files (P-{nnn}.md) link evidence and findings into attack, callflow, or solve narratives
• The review_case.py script validates hashes, links, and business rules with --verify-hashes --strict
• The docs-generator pipeline automatically transforms compliant cases into security reports

Frequently Asked Questions

How do I update evidence without breaking the chain?

Use the supersedes field to deprecated obsolete evidence. Create E-002 with supersedes: E-001, then update dependent findings to reference the new evidence. The verification script warns on orphaned supersedes references but permits the chain to remain auditable.

Can a finding reference evidence from another case?

No. The evidence_ids field uses relative references resolved against work/<case>/evidence/. Cross‑case linking would break portability and hash verification. Copy relevant evidence files or reference external cases in the linked_workitem field instead.

What happens if verification fails with --strict?

The script exits non‑zero and emits a JSON error report. Common failures include: missing evidence files referenced in findings, hash mismatches on artifacts, or validated findings with low confidence without residual‑risk documentation. Fix the underlying files and re‑run until clean.

Which path_type should I use for malware analysis?

Use callflow when documenting execution flow through decompiled functions. Use attack when reconstructing the adversary's operational sequence. Use solve exclusively for CTF or challenge walkthroughs where the goal is a flag rather than security impact assessment.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}