---

name: binary-re description: This skill should be used when analyzing binaries, executables, or bytecode to understand what they do or how they work. Triggers on "binary", "executable", "ELF", "what does this do", "reverse engineer", "disassemble", "decompile", "pyc file", "python bytecode", "analyze binary", "figure out", "marshal". Routes to sub-skills for triage, static analysis, dynamic analysis, synthesis, or tool setup.

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)

Copyrabin2 -v  # Should show version
r2 -v      # Should show version

Decompilation (Optional)

Copy# 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:

Copy# 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

Copy┌─────────────────────────────────────────────────┐
│           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.

Copy# 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:

CopyFACT: 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:

CopyFACTS: 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:

Copy[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

Copy1. 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

CopyUser: "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

CopyUser: "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:

Copy1. 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

Copy# 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