--- name: Crash Analysis slug: crash-analysis category: Quality description: Crash Analysis triages crash dumps and debugger output to determine if a vulnerability is exploitable. Use it when assessing fuzzer crashes, reading stack traces, or identifying root causes with WinDbg, GDB, ASAN, or MSAN. github: "https://github.com/SnailSploit/Claude-Red/tree/main/Skills/exploit-dev/offensive-crash-analysis" language: Python stars: 2930 forks: 479 install: "npx degit https://github.com/SnailSploit/Claude-Red/tree/main/Skills/exploit-dev/offensive-crash-analysis ~/.claude/skills/offensive-crash-analysis" installs_to: ~/.claude/skills/offensive-crash-analysis source_path: Skills/exploit-dev/offensive-crash-analysis/SKILL.md collection_size: 25 category_size: 1354 collection_url: "https://dirskills.com/collections/SnailSploit/Claude-Red" added: 2026-08-17T07:09:54.736Z last_synced: 2026-08-17T07:09:54.736Z canonical_url: "https://dirskills.com/skills/crash-analysis" --- # Crash Analysis Crash Analysis triages crash dumps and debugger output to determine if a vulnerability is exploitable. Use it when assessing fuzzer crashes, reading stack traces, or identifying root causes with WinDbg, GDB, ASAN, or MSAN. **Install:** ```bash npx degit https://github.com/SnailSploit/Claude-Red/tree/main/Skills/exploit-dev/offensive-crash-analysis ~/.claude/skills/offensive-crash-analysis ``` ## README # SKILL: Week 4: Crash Analysis and Exploitability Assessment ## Metadata - **Skill Name**: crash-analysis - **Folder**: offensive-crash-analysis - **Source**: https://github.com/SnailSploit/offensive-checklist/blob/main/4-crash-analysis.md ## Description Week 4 exploit development curriculum. Crash triage and analysis methodology: WinDbg/GDB analysis, ASAN/MSAN output interpretation, exploitability assessment, register/stack trace reading, root cause identification. Use when analyzing crash dumps, assessing exploitability, or understanding fuzzer-generated crashes. ## Trigger Phrases Use this skill when the conversation involves any of: `crash analysis, crash triage, WinDbg, GDB, ASAN, MSAN, exploitability, stack trace, register dump, segfault, null deref, access violation, week 4` ## Instructions for Claude When this skill is active: 1. Load and apply the full methodology below as your operational checklist 2. Follow steps in order unless the user specifies otherwise 3. For each technique, consider applicability to the current target/context 4. Track which checklist items have been completed 5. Suggest next steps based on findings --- ## Full Methodology # Week 4: Crash Analysis and Exploitability Assessment ## Overview _created by AnotherOne from @Pwn3rzs Telegram channel_. After finding potential vulnerabilities through fuzzing (Week 2) or patch diffing (Week 3), the next critical step is analyzing crashes to determine if they're exploitable. This week focuses on crash triage, debugger mastery, and techniques for identifying how to reach vulnerable code paths from attacker-controlled input. Once you've confirmed a crash is exploitable and built a PoC, you'll be ready for Basic Exploitation in Week 5. ### Prerequisites Before starting this week, ensure you have: - A Windows VM (for WinDbg labs) and a Linux VM (for GDB/ASAN/CASR labs). - Completed Week 2 fuzzing labs, including running AFL++ or libFuzzer against at least one C/C++ target - Completed (or skimmed) Week 3 patch diffing labs: - Familiar with Ghidriff/Diaphora diff reports and how to interpret changed functions - Understand how to extract Windows updates and Linux kernel patches - Reviewed at least one case study (CVE-2022-34718 EvilESP, CVE-2024-1086 nf_tables, or 7-Zip symlink bugs) - Comfortable understanding from Week 1 of basic vulnerability classes (buffer overflow, UAF, integer bugs, info leaks) and their exploit primitives ### Crash Analysis Decision Tree Use this decision tree to select the appropriate tools and workflow for any crash you encounter: ``` ┌─────────────────────────────────────────────────────────────────────┐ │ CRASH RECEIVED │ └─────────────────────────────────────────────────────────────────────┘ │ ▼ ┌───────────────────────┐ │ Source code available?│ └───────────────────────┘ │ │ Yes No │ │ ▼ ▼ ┌─────────────────────┐ ┌──────────────────────────┐ │ Recompile with │ │ What platform? │ │ ASAN + UBSAN │ └──────────────────────────┘ │ (Day 2) │ │ │ │ └─────────────────────┘ │ │ │ │ Windows Linux Mobile │ │ │ │ ▼ ▼ ▼ ▼ ┌─────────────────────┐ ┌───────┐ ┌───────┐ ┌───────────┐ │ Run crash input │ │WinDbg │ │Pwndbg │ │ Tombstone │ │ Get detailed report │ │+ TTD │ │+ rr │ │ + Frida │ └─────────────────────┘ │(Day 1)│ │(Day 1)│ │ (Future) │ │ └───────┘ └───────┘ └───────────┘ │ │ │ │ └─────────────┴────┬────┴─────────┘ │ ▼ ┌─────────────────────────────────────┐ │ Crash requires special environment? │ └─────────────────────────────────────┘ │ │ Yes No │ │ ▼ │ ┌─────────────────────────────┐ │ │ Setup reproduction env: │ │ │ - Network (tcpdump, proxy) │ │ │ - Files (strace, procmon) │ │ │ - Services (docker, VM) │ │ └─────────────────────────────┘ │ │ │ └──────────────┬───────────────┘ │ ▼ ┌─────────────────────┐ │ Crash type known? │ └─────────────────────┘ │ │ Yes No │ │ ▼ ▼ ┌─────────────────────┐ ┌─────────────────────┐ │ Run CASR for │ │ Manual analysis: │ │ classification │ │ - Examine registers │ │ (Day 3) │ │ - Check memory │ └─────────────────────┘ │ - Disassemble │ │ │ (Day 3) │ │ └─────────────────────┘ │ │ └────────┬────────┘ │ ▼ ┌─────────────────────────┐ │ EXPLOITABILITY ASSESS │ │ - Check mitigations │ │ - Control analysis │ │ - Reachability (Day 4) │ └─────────────────────────┘ │ ▼ ┌─────────────────────────┐ │ Multiple crashes? │ └─────────────────────────┘ │ │ Yes No │ │ ▼ ▼ ┌─────────────────────┐ ┌─────────────────────┐ │ Deduplicate (Day 5) │ │ Minimize (Day 5) │ │ - CASR cluster │ │ - afl-tmin │ │ - Stack hash │ │ - Manual reduction │ └─────────────────────┘ └─────────────────────┘ │ │ └────────┬───────────┘ │ ▼ ┌─────────────────────────┐ │ Create PoC (Day 6) │ │ - Python + pwntools │ │ - Verify reliability │ │ - Document findings │ └─────────────────────────┘ ``` **Quick Reference - Tool Selection by Scenario**: | Scenario | Primary Tool | Secondary Tool | Sanitizer | | --------------------------- | -------------------------- | ---------------- | ------------ | | Linux binary, have source | GDB + Pwndbg | rr | ASAN + UBSAN | | Linux binary, no source | GDB + Pwndbg | Ghidra | N/A | | Windows binary, have source | WinDbg + TTD | Visual Studio | ASAN | | Windows binary, no source | WinDbg + TTD | IDA/Ghidra | N/A | | Fuzzer crash corpus | CASR | afl-tmin | ASAN | | Non-deterministic crash | rr (Linux) / TTD (Windows) | Chaos mode | TSAN | | Kernel crash (Linux) | crash utility | GDB + KASAN | KASAN | | Kernel crash (Windows) | WinDbg kernel | Driver Verifier | N/A | | Android app crash | Tombstone + ndk-stack | Frida | HWASan | | Rust/Go crash | Native debugger | Sanitizer output | Built-in | ## Day 1: Debugger Fundamentals and Crash Dump Analysis - **Goal**: Learn Windows Debugger (WinDbg) and Linux debugger (GDB + Pwndbg) for analyzing application crashes. - **Activities**: - _Reading_: - "Practical Malware Analysis" by Michael Sikorski - Chapter 9 and 10 - [WinDbg Official Documentation](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/) - [Pwndbg Documentation](https://pwndbg.re/stable/) - _Online Resources_: - [Common WinDbg Commands](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/commands) - [Debugging Tools for Windows](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools) - [GDB Quick Reference](https://darkdust.net/files/GDB%20Cheat%20Sheet.pdf) - _Tool Setup_: - **Windows**: Install WinDbg Preview from Microsoft Store - **Linux**: Install GDB with Pwndbg enhancement - Install Windows SDK for symbol support - _Exercise_: - Analyze 5 pre-generated crash dumps (Windows and Linux) - Identify crash type and root cause for each ### Reproduction Fidelity > [!IMPORTANT] > Before any crash analysis, ensure you can reproduce the crash reliably. > A crash that only happens "sometimes" or "on the fuzzer's machine" is nearly impossible to analyze or exploit. > This section establishes the mandatory checklist for achieving reproduction fidelity. #### Reproduction Fidelity Checklist Before analyzing any crash, verify these match between discovery and analysis environments: ```text ┌─────────────────────────────────────────────────────────────────┐ │ REPRODUCTION FIDELITY CHECKLIST │ ├─────────────────────────────────────────────────────────────────┤ │ System Environment │ │ [ ] OS/Kernel version : ________________________________ │ │ [ ] libc version : ________________________________ │ │ [ ] CPU architecture : [ ] x86 [ ] x86_64 [ ] ARM64 │ │ [ ] Container/VM : [ ] Native [ ] Docker [ ] VM │ │ [ ] ASLR state : [ ] Enabled [ ] Disabled │ ├─────────────────────────────────────────────────────────────────┤ │ Process Environment │ │ [ ] argv (command-line) : ________________________________ │ │ [ ] Environment variables : ________________________________ │ │ [ ] Working directory : ________________________________ │ │ [ ] Locale (LC_ALL, LANG) : ________________________________ │ │ [ ] umask / permissions : ________________________________ │ ├─────────────────────────────────────────────────────────────────┤ │ Input Path │ │ [ ] Input source : [ ] stdin [ ] file [ ] network │ │ [ ] Input file path : ________________________________ │ │ [ ] Network port/protocol : ________________________________ │ ├─────────────────────────────────────────────────────────────────┤ │ Build Configuration │ │ [ ] Compiler version : ________________________________ │ │ [ ] Optimization level : [ ] -O0 [ ] -O1 [ ] -O2 [ ] -O3 │ │ [ ] Sanitizers : [ ] ASAN [ ] UBSAN [ ] TSAN [ ] None│ │ [ ] Debug symbols : [ ] Yes [ ] No │ │ [ ] Mitigations : [ ] PIE [ ] Canary [ ] RELRO │ └─────────────────────────────────────────────────────────────────┘ ``` #### Essential Environment Knobs **ASAN/UBSAN Options** (Linux/macOS): ```bash # Full ASAN options for crash analysis export ASAN_OPTIONS="\ abort_on_error=1:\ symbolize=1:\ detect_leaks=1:\ disable_coredump=0:\ halt_on_error=1:\ print_stats=1:\ check_initialization_order=1:\ detect_stack_use_after_return=1:\ quarantine_size_mb=256" # UBSAN options export UBSAN_OPTIONS="\ print_stacktrace=1:\ halt_on_error=1:\ suppressions=ubsan_suppressions.txt" # Symbolizer path (required for readable stack traces) export ASAN_SYMBOLIZER_PATH=$(command -v llvm-symbolizer) ``` **glibc Allocator Tuning** (Linux): ```bash # Enable glibc heap consistency checks (catch corruption early) export MALLOC_CHECK_=3 # Modern glibc tunable interface (glibc 2.26+) export GLIBC_TUNABLES="\ glibc.malloc.check=3:\ glibc.malloc.perturb=165" # What these do: # MALLOC_CHECK_=3: Abort on heap corruption detection # glibc.malloc.perturb=165: Fill freed memory with 0xA5 (helps detect UAF) ``` **Core Dump Configuration** (Linux): ```bash # Enable unlimited core dumps ulimit -c unlimited # Verify core pattern (where dumps go) cat /proc/sys/kernel/core_pattern # For local dumps in CWD (temporary, affects system): # echo 'core.%e.%p' | sudo tee /proc/sys/kernel/core_pattern ``` **ASLR Control** (Linux - for deterministic analysis): ```bash # Check current ASLR state cat /proc/sys/kernel/randomize_va_space # 0 = disabled, 1 = conservative, 2 = full # Disable ASLR for current shell (temporary, per-process) setarch $(uname -m) -R ./target < crash_input # Or system-wide (DANGEROUS - only for isolated VMs): # echo 0 | sudo tee /proc/sys/kernel/randomize_va_space ``` #### Input Path Matching The crash may behave differently depending on HOW input reaches the target: ```bash # If fuzzer used stdin: ./target < crash_input # If fuzzer used file argument: ./target crash_input # If fuzzer used network: cat crash_input | nc localhost 8080 # WRONG: Mixing input paths can change behavior! # Fuzzer: ./target @@ (file) # You: ./target < crash (stdin) # May not reproduce! ``` **Example: stdin vs file difference**: ```c // Some programs behave differently: // - stdin may be line-buffered // - File may be memory-mapped // - Network may have different read chunk sizes // This can affect: // - Buffer contents at crash time // - Heap layout (different allocation patterns) // - Race conditions (timing changes) ``` #### Quick Reproduction Test Script ```bash #!/bin/bash # repro_test.sh - Verify crash reproduction CRASH_INPUT="$1" TARGET="$2" EXPECTED_SIGNAL="${3:-11}" # Default: SIGSEGV (11) echo "[*] Testing reproduction of $(basename $CRASH_INPUT)" echo "[*] Target: $TARGET" echo "[*] Expected signal: $EXPECTED_SIGNAL" # Set up environment ulimit -c unlimited export ASAN_OPTIONS="abort_on_error=1:symbolize=1" # Run 10 times CRASHES=0 for i in {1..10}; do timeout 5s $TARGET < "$CRASH_INPUT" 2>/dev/null EXIT_CODE=$? # Check for crash signal (128 + signal number) if [ $EXIT_CODE -gt 128 ]; then SIGNAL=$((EXIT_CODE - 128)) if [ $SIGNAL -eq $EXPECTED_SIGNAL ] || [ $SIGNAL -eq 6 ]; then ((CRASHES++)) fi fi done echo "[*] Crash rate: $CRASHES/10" if [ $CRASHES -ge 9 ]; then echo "[+] Reproduction: RELIABLE" elif [ $CRASHES -ge 5 ]; then echo "[!] Reproduction: FLAKY - investigate environment" else echo "[-] Reproduction: FAILED - check environment checklist" fi ``` ### Installing WinDbg and Symbol Support **WinDbg Preview** (recommended - modern UI): ```batch winget install Microsoft.WinDbg ``` **Windows SDK Debugging Tools** (includes cdb.exe for command-line/batch analysis): ```bash # Option 1: Install via winget (Windows SDK) winget install --source winget --exact --id Microsoft.WindowsSDK.10.0.26100 # Option 2: Download from Microsoft # https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/ # During installation, select "Debugging Tools for Windows" # After installation, cdb.exe is located at: # C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe # Add to PATH for convenience (run as Administrator): setx PATH "%PATH%;C:\Program Files (x86)\Windows Kits\10\Debuggers\x64" /M # Or use full path in scripts: "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe" -z dump.dmp -c "!analyze -v; q" ``` **Configure Symbol Path**: ```bash # In WinDbg Settings -> Default Symbol Path, or: # In WinDbg command window: .sympath SRV*C:\Symbols*https://msdl.microsoft.com/download/symbols # Or set environment variable permanently (recommended): setx _NT_SYMBOL_PATH "SRV*C:\Symbols*https://msdl.microsoft.com/download/symbols" # Create symbols cache directory mkdir C:\Symbols # Reload symbols (in debugger) .reload /f ``` ### Linux Crash Dump Generation and Pwndbg Setup > [!HINT] > While Windows uses WinDbg, Linux crash analysis uses GDB enhanced with Pwndbg. This section covers parallel Linux setup. **Installing Pwndbg**: ```bash # Install GDB sudo apt install gdb # Install Pwndbg (recommended for crash analysis) cd ~/tools git clone --depth 1 https://github.com/pwndbg/pwndbg cd pwndbg ./setup.sh # Verify installation gdb -q -ex "quit" 2>&1 | grep -q "pwndbg" && echo "pwndbg installed successfully" ``` > [!WARNING] > Pwndbg is installed per-user in `~/.gdbinit`. If you run `sudo gdb`, it uses root's home directory and won't find your pwndbg config. Solutions: > For crash analysis of your own compiled test programs, you typically don't need sudo. Only use sudo when attaching to system processes or analyzing setuid binaries. ```bash # Option 1: Use gdb as regular user (recommended for most analysis) cd ~/crash_analysis_lab gdb ./vuln_no_protect -c core.dump # Option 2: If you MUST use sudo (e.g., attaching to privileged process) sudo -E gdb ./program # -E preserves your environment including HOME # Option 3: Install pwndbg for root as well sudo su - cd /root git clone https://github.com/pwndbg/pwndbg cd pwndbg && ./setup.sh exit # Option 4: Explicitly source pwndbg in sudo gdb session sudo gdb -ex "source /home//tools/pwndbg/gdbinit.py" ./program ``` **Configuring Core Dumps on Linux**: ```bash # Check current core dump configuration cat /proc/sys/kernel/core_pattern # Enable core dumps for current shell (recommended for learning) ulimit -c unlimited ``` > [!TIP] > **For the exercises in this course**, you typically only need: > > ```bash > ulimit -c unlimited # In your current shell > ``` > > On modern Ubuntu/Debian with systemd, cores are handled by `systemd-coredump` even if you set `ulimit`. > Use `coredumpctl` to list and debug them. > [!WARNING] > **Optional: Local core files in CWD** (modifies system-wide settings) > > If you specifically need core files in your working directory instead of systemd-coredump: > > ```bash > # This is SYSTEM-WIDE and may interfere with other tooling > echo 'core.%e.%p' | sudo tee /proc/sys/kernel/core_pattern > ``` > > Additional kernel settings that affect core dumps: > > - `kernel.core_uses_pid`: Append PID to core filename > - `fs.suid_dumpable`: Controls dumps for setuid binaries (0=disabled, 1=enabled, 2=suidsafe) ### Building a Vulnerable Test Suite for Linux Create these vulnerable C programs to generate real crashes: ```bash # Create a directory for crash analysis practice mkdir -p ~/crash_analysis_lab/{src,crashes,cores} cd ~/crash_analysis_lab/src ``` **vulnerable_suite.c** - Save this file for testing multiple vulnerability types: ```c // ~/crash_analysis_lab/src/vulnerab