Binary Analysis

Binary Analysis Methodology

Extract behavioral intelligence from compiled artifacts when source code is unavailable. Static analysis only — the binary is never executed.

When This Mode Applies

Binary analysis activates when:

• The /analyze command detects compiled artifacts in the target
• The discovery inventory identifies compiled binaries at the target path
• Other modes discover compiled artifacts during analysis (e.g., a bundled native binary inside an npm package)

Binary Type Taxonomy

Agents

The surveyor always runs first. The deep analyzer runs on modules the surveyor recommends.

Tool Reference

Identification

file target.bin                        # Magic-based type identification

Native Binary Tools (ELF)

readelf -h target.bin                  # ELF header
readelf -S target.bin                  # Section headers
readelf --dyn-syms target.bin          # Dynamic symbol table
readelf -d target.bin                  # Dynamic section (dependencies)
readelf --debug-dump=info target.bin   # Debug info (DWARF)
nm target.bin                          # Symbol table (empty if stripped)
nm -D target.bin                       # Dynamic symbols only
ldd target.bin                         # Shared library dependencies
strings -a -n 4 target.bin            # ASCII strings
strings -a -el -n 4 target.bin        # Wide-character (UTF-16LE) strings
objdump -d --section=.text target.bin  # Disassemble text section

Native Binary Tools (Mach-O)

otool -h target.bin                    # Mach-O header
otool -l target.bin                    # Load commands
otool -TV target.bin                   # Exports trie
otool -L target.bin                    # Linked libraries

Native Binary Tools (PE)

objdump -x target.exe                 # All headers
objdump -p target.exe                 # Private headers (imports/exports)

Disassemblers (Deep Analysis)

# Ghidra headless mode
$GHIDRA_HOME/support/analyzeHeadless \
  /tmp/ghidra-project project-name \
  -import target.bin \
  -postScript ExportDisassembly.java \
  -scriptPath /analysis/scripts/

# radare2: function disassembly
r2 -q -c 'aaa; pdf @ sym.main' target.bin

# radare2: function list
r2 -q -c 'aaa; afl' target.bin

# radare2: string cross-references
r2 -q -c 'aaa; axt @ str.error_message' target.bin

JVM Tools

jar tf target.jar                      # List contents
unzip -p target.jar META-INF/MANIFEST.MF  # Extract manifest
javap -public com.example.MainClass    # Public API surface
java -jar cfr.jar target.jar --outputdir decompiled/  # Decompile

.NET Tools

dotnet ildasm target.dll               # Type/method listing
ilspycmd target.dll -o decompiled/     # Decompile to C#

Python Tools

# Version identification from magic number
python3 -c "
with open('target.pyc', 'rb') as f:
    magic = f.read(4)
    print(f'Magic: {magic.hex()}')
"
uncompyle6 target.pyc > decompiled.py  # Decompile

Electron/ASAR Tools

npx asar list app.asar                 # List contents
npx asar extract app.asar extracted/   # Extract (lossless)

WebAssembly Tools

wasm-tools print target.wasm | head -100  # Text format summary
wasm2wat target.wasm -o target.wat     # Full WAT conversion

Analysis Methodology

digraph binary_analysis {
    rankdir=TB;

    "Start binary analysis" [shape=doublecircle];
    "Survey: identify type, strings, symbols, metadata" [shape=box];
    "Extract behavioral claims from strings" [shape=box];
    "Is it managed code?" [shape=diamond];
    "Attempt decompilation" [shape=box];
    "Decompilation succeeded?" [shape=diamond];
    "Hand off to source code mode agents" [shape=box];
    "Perform deep disassembly analysis" [shape=box];
    "Document gaps explicitly" [shape=box];
    "Binary analysis complete" [shape=doublecircle];

    "Start binary analysis" -> "Survey: identify type, strings, symbols, metadata";
    "Survey: identify type, strings, symbols, metadata" -> "Extract behavioral claims from strings";
    "Extract behavioral claims from strings" -> "Is it managed code?";
    "Is it managed code?" -> "Attempt decompilation" [label="yes (JVM/.NET/Python/Electron)"];
    "Is it managed code?" -> "Perform deep disassembly analysis" [label="no (native ELF/Mach-O/PE)"];
    "Attempt decompilation" -> "Decompilation succeeded?";
    "Decompilation succeeded?" -> "Hand off to source code mode agents" [label="yes"];
    "Decompilation succeeded?" -> "Perform deep disassembly analysis" [label="no"];
    "Hand off to source code mode agents" -> "Document gaps explicitly";
    "Perform deep disassembly analysis" -> "Document gaps explicitly";
    "Document gaps explicitly" -> "Binary analysis complete";
}

Step 1: Survey First

Always run the binary-surveyor before deep analysis. The survey:

• Identifies the binary type and selects the right tool chain
• Extracts everything accessible through lightweight tools (strings, symbols, metadata)
• Determines which modules warrant the cost of deep analysis
• Attempts decompilation for managed code and triggers source code mode handoff

Step 2: Strings Are Gold

Embedded strings are the highest-value, lowest-effort source of behavioral intelligence from binaries. They provide direct evidence without interpretation:

• Error messages reveal validation rules, failure modes, and error handling paths
• URLs and endpoints reveal API surface and external dependencies
• Help text reveals CLI interface, flags, and usage patterns
• SQL queries reveal data model, table names, and query patterns
• Configuration keys reveal tunable parameters
• Format strings reveal logging patterns and output formatting
• Regex patterns reveal input validation rules

Extract strings early. Categorize them. Cross-reference them during deep analysis.

Step 3: Managed Code Gets Decompiled

JVM, .NET, Python, and Electron artifacts preserve enough metadata for high-quality decompilation. When decompilation succeeds:

1. Place decompiled source in workspace/raw/binary/decompiled/{language}/
2. Write a handoff file at workspace/raw/binary/source-handoff.md
3. The orchestrator schedules source code mode agents on the decompiled source
4. All claims from decompiled source retain source=binary-analysis provenance (not source-code)
5. Decompiled source never reaches workspace/output/ or the implementer

Step 4: Native Binaries Get Deep Analysis

For native code (ELF, Mach-O, PE), decompilation to source is unreliable. Deep analysis uses disassembly:

1. Select target functions based on surveyor recommendations
2. Disassemble with Ghidra (headless) or radare2
3. Trace control flow and express as behavioral decision trees
4. Map data structures from memory access patterns
5. Identify algorithms from instruction patterns and constants
6. Cross-reference with strings for context

Step 5: Document Gaps Explicitly

Binary analysis frequently produces incomplete pictures. Every analysis file must include a "Gaps in Analysis" section listing:

• What could NOT be determined
• WHY it could not be determined
• Which other intelligence source could fill the gap

Confidence Calibration

Binary-derived claims follow the standard confidence levels from provenance-methodology, with these mode-specific guidelines:

When to Use confirmed

Only when two independent evidence types agree:

• Disassembly shows AES S-box constants AND strings include "AES-256"
• Symbol name says parse_json AND strings include JSON-related error messages
• Two different tools (e.g., radare2 and objdump) produce consistent results

When to Use inferred

Single authoritative evidence source:

• file command output (direct tool result)
• Literal strings extracted from the binary
• Symbol names from unstripped binaries
• Decompiled managed code (JVM, .NET, Python)
• Algorithm identification with strong constant/pattern match
• Dependency identification from linker metadata

When to Use assumed

Interpretation without direct evidence:

• Control flow interpretation from stripped native disassembly
• Data structure reconstruction from memory access patterns
• Purpose/intent attribution to unnamed code blocks
• Behavioral inferences that require analyst judgment
• Algorithm identification with partial or weak pattern match
• Anything where you are reasoning rather than observing

Default for native binaries: assumed. Native binary analysis is inherently interpretive. Be honest about uncertainty.

Default for managed code: inferred. Decompiled managed code is near-source-quality, but still single-source.

Provenance Citation Format

All binary-derived claims use source=binary-analysis:

- The binary accepts three output formats: json, csv, xml
  <!-- cite: source=binary-analysis, ref=workspace/raw/binary/survey/strings.md:15, confidence=inferred, agent=binary-surveyor -->

For decompiled source processed by source code mode agents:

- The UserService validates email addresses using a regex pattern
  <!-- cite: source=binary-analysis, ref=workspace/raw/binary/decompiled/java/com/example/UserService.java:45, confidence=inferred, agent=chunk-analyzer -->

Note: source remains binary-analysis even when a source code mode agent performs the analysis, because the ultimate origin is a binary artifact.

Corroboration Patterns

Binary analysis is most valuable as a corroborating source for claims from other modes:

Container Recipes for Analysis Tools

Analysis tools may be complex to install. Pre-built containers hold the tools (not the target):

Containers mount the target at /target:ro and write output to /output:rw. Containers run with --network=none. The target is never executed inside these containers.

Output Structure

workspace/raw/binary/
├── survey/
│   ├── binary-survey.md            # Overall survey
│   ├── strings.md                  # Categorized strings
│   ├── symbols.md                  # Exported/imported symbols
│   ├── dependencies.md             # Linked libraries, packages
│   ├── metadata.md                 # Version, compiler, build info
│   ├── type-info.md                # Class hierarchy (managed code)
│   └── deep-analysis-targets.md    # Recommendations for deep analysis
├── analysis/
│   ├── {module-name}.md             # Per-module deep analysis
│   └── ...
├── decompiled/                     # Managed code decompilation output
│   ├── java/
│   ├── python/
│   ├── csharp/
│   └── electron/
└── source-handoff.md               # Handoff notification (if decompilation succeeded)

Pipeline Position

Binary analysis is a Layer 1 input type. It runs independently and in parallel with other modes. It is typically scheduled last because:

1. It is the most labor-intensive mode
2. It produces the lowest-confidence claims
3. Other modes often provide the same intelligence at higher confidence
4. Its greatest value is filling gaps and corroborating claims from other modes