crash-analysis

Crash Analysis

Reproduce, classify, and attribute crash artifacts from fuzzing campaigns using the project's sidecar format and existing analysis tooling.

---

When to Use This Skill

• "analyze this crash"
• "why did it segfault"
• "build a regression test for this crash"
• "generate a FINDINGS.md entry for this bug"
• "root cause this SIGFPE"
• "find the mutation site"
• "ASAN heap-buffer-overflow" / "UAF" / "UAF in libfoo"
• "crash forensics"
• "crash report" / "crash artifact"
• "minimize this crash input"

---

Crash Artifact Format

The fuzzer writes a quintet of sidecar files per crash (via save_crash in adapters/filesystem.py):

crashes/
  crash_<ts>_<cluster_id>_<sig>.bin   ← raw input bytes (only file counted as "crash")
  crash_<ts>_<cluster_id>_<sig>.txt   ← human-readable report (target, returncode, GDB replay)
  crash_<ts>_<cluster_id>_<sig>.json  ← same fields, machine-readable (CrashMetadata.to_dict())
  crash_<ts>_<cluster_id>_<sig>.hex   ← xxd-style hexdump + text repr
  crash_<ts>_<cluster_id>_<sig>.sh    ← base64 reproducer script

The .bin is the authoritative input; the .txt and .json carry the same triage fields (sanitizer, error_type, fault_addr, frames, registers, gdb_replay, nearest_corpus, raw_stderr) — .txt for humans, .json for dashboards and downstream tooling. The two are written together by save_crash; treat them as a single artifact.

---

Core Methodology

1. Discover

Glob crashes/*.bin to enumerate inputs. Each .bin already has a companion .json sidecar with the parsed triage fields — read those directly:

jq '.[] | {signal, sanitizer, error_type, fault_addr}' crashes/*.json

The .json is written by save_crash and mirrors CrashMetadata.to_dict() (sanitizer, error_type, fault_addr, frames, registers, gdb_replay, nearest_corpus, raw_stderr, target_sha256, returncode). No re-parse of the .txt is needed.

2. Classify

Every crash falls into exactly one bucket: