Binary Re

Binary Reverse Engineering

Purpose

Comprehensive guide for binary reverse engineering. This skill provides the overall methodology, philosophy, and reference material. Related skills handle specific phases:

Related Skills

Note: Each skill auto-detects based on keywords. You don't need to explicitly route - just ask what you need.

Pre-Flight Verification

Before beginning any analysis, verify tooling availability:

Core Tools (Required)

rabin2 -v  # Should show version
r2 -v      # Should show version

Decompilation (Optional)

# Check r2ghidra availability
r2 -qc 'pdg?' - 2>/dev/null | grep -q Usage && echo "r2ghidra OK" || echo "r2ghidra missing - install with: r2pm -ci r2ghidra"

Dynamic Analysis Platform Check

If dynamic tools unavailable: Proceed with static-only analysis, note reduced confidence in synthesis phase.

Fallback Tooling (No r2/Ghidra)

When radare2 or Ghidra aren't available, use standard binutils/LLVM tools:

# Metadata (replaces rabin2 -I)
readelf -h binary              # ELF header
readelf -d binary              # Dynamic section (dependencies)
file binary                    # Quick identification

# Imports/Exports (replaces rabin2 -i/-E)
readelf -Ws binary | grep -E "FUNC|OBJECT" | awk '{print $8}'
nm -D binary 2>/dev/null       # Dynamic symbols

# Strings (replaces rabin2 -zz)
strings -a -n 8 binary | grep -Ei 'http|ftp|/etc|/var|error|pass|key|token|api'

# Disassembly (replaces r2 pdf)
objdump -d -M intel binary | head -500
# Or LLVM (better cross-arch support):
llvm-objdump -d --no-show-raw-insn binary | head -500

# Dependencies (replaces rabin2 -l)
ldd binary 2>/dev/null || readelf -d binary | grep NEEDED

Limitations of fallback approach:

• No cross-references (axt/axf) - must trace manually
• No decompilation - assembly only
• No function boundary detection - raw disassembly
• Reduced accuracy for stripped binaries

Philosophy

The LLM drives analysis; the human provides context.

Human provides:

• Platform info (device type, OS, hardware)
• Suspected purpose (what the binary might do)
• Constraints (no network, isolated env, etc.)

LLM executes:

• Tool selection and invocation
• Hypothesis formation from evidence
• Experiment design
• Knowledge synthesis

The Agentic Loop

┌─────────────────────────────────────────────────┐
│           HYPOTHESIS-DRIVEN ANALYSIS            │
├─────────────────────────────────────────────────┤
│                                                 │
│  0. I/O SANITY → Compare known inputs/outputs   │
│  1. OBSERVE → Gather facts via tools            │
│  2. HYPOTHESIZE → Form theories from facts      │
│  3. PLAN → Design experiments to test theories  │
│  4. EXECUTE → Run tools (gate risky ops)        │
│  5. RECORD → Capture observations               │
│  6. UPDATE → Confirm/refute hypotheses          │
│  7. LOOP → Until understanding sufficient       │
│                                                 │
└─────────────────────────────────────────────────┘

Step 0: Compare Known I/O First (CRITICAL)

Before diving into code analysis, always check if known inputs/outputs exist.

This step prevents hours of wasted analysis by establishing ground truth first.

⚠️ REQUIRES HUMAN APPROVAL - Even for I/O comparison, get explicit approval before execution.

# SAFE: Use emulation for cross-arch binaries (after human approval)
# ARM32 example:
qemu-arm -L /usr/arm-linux-gnueabihf -- ./binary input.txt > actual_output.txt

# x86-64 native (still requires approval):
./binary input.txt > actual_output.txt

# Docker-based (macOS - safest option):
docker run --rm --platform linux/arm/v7 -v ~/samples:/work:ro \
  arm32v7/debian:bullseye-slim /work/binary /work/input.txt > actual_output.txt

# Compare outputs:
diff expected_output.txt actual_output.txt
cmp -l expected_output.txt actual_output.txt | head -20  # Byte-level

# Document the delta:
# - Where does output first diverge?
# - What pattern appears in the corruption?
# - Does file size match (logic bug) or differ (truncation)?

Record as FACT:

FACT: Output differs at byte {N}, expected "{X}" got "{Y}" (source: diff/cmp)
FACT: File sizes match/differ by {N} bytes (source: ls -l)

This single step often reveals the bug category before any disassembly.

Knowledge Model

Throughout analysis, maintain structured knowledge via episodic memory:

FACTS: Verified observations with tool attribution
HYPOTHESES: Theories with confidence and evidence
QUESTIONS: Open unknowns blocking progress
EXPERIMENTS: Planned tool invocations
OBSERVATIONS: Results from experiments
DECISIONS: Human-approved choices with rationale

Episodic Memory Integration

Knowledge persists across sessions via episodic memory. Use consistent tagging:

[BINARY-RE:{phase}] {artifact_name} (sha256: {hash})
FACT: {observation} (source: {tool})
HYPOTHESIS: {theory} (confidence: {0.0-1.0})
QUESTION: {unknown}
DECISION: {choice} (rationale: {why})

Starting analysis: Search episodic memory for artifact hash first After each phase: Findings are automatically captured in conversation Resuming: Search [BINARY-RE] {artifact_name} to restore context

Human-in-the-Loop Triggers

ALWAYS ask human before:

1. Executing the binary - Even under QEMU, confirm sandbox
2. Network operations - Prevent unintended phone-home
3. Conflicting evidence - Resolve contradictory findings
4. Privileged operations - Device access, root actions
5. Major direction changes - Significant analysis pivots

Session Management

Starting New Analysis

1. Compute artifact hash: sha256sum binary
2. Search episodic memory: "[BINARY-RE] sha256:{hash}"
3. If previous analysis found:
   → "Found previous analysis from {date}. Resume or start fresh?"
4. If resuming: Load facts/hypotheses, continue from last phase
5. If fresh: Begin with triage phase

Resuming Interrupted Analysis

User: "Continue analyzing that thermostat binary"

Claude:
1. Invoke episodic-memory:search-conversations
   Query: "[BINARY-RE] thermostat"
2. Retrieve previous session findings
3. Summarize: "Last session identified ARM32/musl, found network
   functions. We were about to run dynamic analysis."
4. Continue from that phase

Searching Past Analyses

User: "Have we analyzed any ARM binaries with hardcoded passwords?"

Claude:
1. Search: "[BINARY-RE] FACT: hardcoded" or "[BINARY-RE] ARM"
2. Return matching artifacts and findings

Standard Analysis Flow

For typical unknown binary analysis:

1. Triage (binary-re-triage)
   └─ Architecture, ABI, dependencies, capabilities

2. Static Analysis (binary-re-static-analysis)
   └─ Functions, strings, xrefs, decompilation

3. Dynamic Analysis (binary-re-dynamic-analysis) - if safe
   └─ Syscalls, network, file access

4. Synthesis (binary-re-synthesis)
   └─ Structured report with evidence

Quick Reference

Essential Commands

# Fast triage
rabin2 -I binary              # Metadata
rabin2 -l binary              # Dependencies
rabin2 -zz binary             # Strings

# Static analysis
r2 -q -c 'aa; aflj' binary    # Functions
r2 -q -c 'izj' binary         # Strings

# Dynamic (ARM example)
qemu-arm -L /usr/arm-linux-gnueabihf -strace ./binary

Architecture Detection

Libc Detection

Error Recovery

Documentation

See companion docs:

• docs/r2-commands.md - Complete r2 reference for LLMs
• docs/ghidra-headless.md - Ghidra scripting guide
• docs/arch-adapters.md - Per-architecture quirks
• docs/python-bytecode-re.md - Python .pyc/marshal obfuscation patterns

Integration

Works with other plugins:

• remote-system-maintenance: Extract binaries from devices via SSH
• fresh-eyes-review: Validate conclusions before documenting
• scenario-testing: Create reproducible analysis environments