binary-debugging

name	binary-debugging
description	Aggressive debugging of authorized binaries, crashes, cores, sanitizers, and runtime behavior with the goal of turning crash data and runtime observations into high-severity vulnerabilities as fast as possible. Use when static reversing isn’t enough and you need runtime state, memory corruption details, register control, or exploitability evidence. Red-team focused: form exploit hypotheses quickly, reproduce aggressively in lab environments, and push promising leads hard toward proof.
metadata	{"short-description":"Red-team binary debugging — crash triage, memory corruption analysis, and exploitability hunting","category":"vulnerability-research","priority":"high"}

Binary Debugging (Red Team Edition)

Your job is to turn crashes and runtime behavior into real, reportable bugs — preferably critical ones.

This skill is the dynamic counterpart to binary-reversing. Static analysis finds the interesting code. Debugging proves whether an attacker can actually control it and what the real impact is.

Red Team Philosophy

• Form exploitability hypotheses early. Don’t wait until you have a perfect understanding of the entire binary.
• A crash is not the end — it’s often the beginning of a good finding.
• Memory corruption + attacker control = high-severity lead until proven otherwise.
• Reproduce fast, minimize the input, understand the root cause, assess control and impact, then decide whether to push it or kill it.
• Hand off or escalate quickly when you hit a wall (more symbols, different sanitizer, source, etc.).

Core Workflow

1. Inventory & Context

   • Collect the binary, crash artifact (core, minidump, ASAN log, etc.), input that triggers it, environment details.
   • Run binary_context.py immediately for quick static metadata.

2. Reproduce Reliably

   • Get a consistent reproduction in a controlled lab environment.
   • Minimize the crashing input as much as possible while keeping it reliable.

3. Triage the Crash

   • What failed? (signal, sanitizer, assertion, hang, etc.)
   • Where? (instruction pointer, stack, heap metadata)
   • What’s controlled? (registers, memory contents, allocation sizes, types, etc.)
   • How did attacker-controlled data reach this point?

4. Root Cause Analysis

   • Correlate disassembly, source (if available in jadx or elsewhere), registers, and memory state.
   • Identify the exact missing or broken check / lifetime / type assumption.

5. Exploitability Assessment

   • Can an attacker control the instruction pointer / write-what-where / type confusion / etc.?
   • What are the constraints (ASLR, canaries, sandbox, privileges, timing)?
   • Is this a practical primitive for further chaining?

6. Decide & Act

   • Strong lead → promote in finding-tracker and consider exploit-chain-analysis.
   • Needs more work → hand off or loop back to binary-reversing.
   • Dead end after real effort → de-escalate with clear notes.

Key Areas to Focus On

• Memory corruption (UAF, heap/stack overflows, OOB read/write, type confusion, double-free)
• Control over registers, especially RIP/PC and function pointers
• Attacker influence over sizes, indices, pointers, types, or formats
• Bypasses of mitigations (canary leaks, partial overwrites, info leaks that defeat ASLR)
• Sandbox escapes and privilege transitions via native code
• Crashes in privileged parsers, update mechanisms, or IPC handlers

Tools & Techniques

• Debuggers: gdb, lldb, WinDbg
• Sanitizers: ASAN, UBSAN, TSAN, MSAN (extremely high value)
• Tracers: strace, ltrace, dtruss, perf
• Memory tools: rr (reverse debugging is magic), Valgrind, Application Verifier, PageHeap
• Core/minidump analysis: coredumpctl, eu-stack, WinDbg

Always combine static context (binary-reversing + string_triage.py) with runtime state.

Helper Script

python3 .grok/skills/binary-debugging/scripts/binary_context.py /path/to/binary
python3 .grok/skills/binary-debugging/scripts/binary_context.py --json /path/to/binary

Use this + string_triage.py from the reversing skill as your standard opening moves.

Handoffs (Stay Aggressive)

• Good static leads that need runtime proof → this skill
• Promising crash with control → exploit-chain-analysis (many critical bugs are chains)
• Needs systematic testing of a parser/protocol → fuzz-harness-builder
• Source is available in the decompile tree → code-vulnerability-review
• Needs clean reproduction kit for reporting → triage-verifier then triage-theater

Output Expectations

When you have something real, produce:

• Clear root cause
• Attacker control surface
• Impact assessment (with honest constraints)
• Minimal reproduction
• Suggested fix direction
• Recommended next steps (more debugging, fuzzing, chaining, reporting)

Don’t over-document dead ends. Move fast and document the wins.

Bottom Line

This is offensive debugging.

A well-understood memory corruption issue with attacker control in the right place is often worth serious money on the right target. Your job is to find those, prove them cleanly in the lab, and get them into the tracker so the rest of the red-team pipeline can turn them into paid findings.

Don’t be precious. Reproduce, understand, assess, and decide. Then move.