binary-re-synthesis

name	binary-re-synthesis
description	Use when ready to document findings, generate a report, or summarize binary analysis results. Compiles analysis findings into structured reports - correlates facts from triage/static/dynamic phases, validates hypotheses, generates documentation with evidence chains. Keywords - "summarize findings", "generate report", "document analysis", "what did we find", "write up results", "export findings"

Analysis Synthesis (Phase 5)

Purpose

Compile all gathered knowledge into actionable intelligence. Validate hypotheses against evidence. Produce structured reports with traceable findings.

When to Use

• Sufficient facts gathered from triage + static + dynamic analysis
• Ready to document understanding for handoff or archival
• Need to present findings to stakeholders
• Before closing analysis session

Synthesis Process

Step 1: Evidence Review

Gather all recorded knowledge:

FACTS collected:
- From triage: arch, ABI, dependencies, capabilities
- From static: functions, xrefs, decompilation
- From dynamic: syscalls, network, file access

HYPOTHESES formed:
- With supporting evidence
- With contradicting evidence
- Unresolved hypotheses

QUESTIONS remaining:
- Blocking questions (prevent conclusion)
- Open questions (future investigation)

Step 2: Hypothesis Validation

For each hypothesis, determine status:

Evidence State	Status	Action
Strong support, no contradictions	Confirmed	Include in conclusions
Some support, some contradictions	Uncertain	Document both sides
Strong contradictions	Refuted	Explain why wrong
No evidence either way	Unvalidated	List as unknown

Step 3: Correlation Analysis

Connect findings across phases:

Static finding: Function at 0x8400 calls socket(), connect(), SSL_read()
Dynamic finding: connect() to 192.168.1.100:8443 observed
Strings found: "api.vendor.com/telemetry"

CORRELATED CONCLUSION:
Function 0x8400 is network initialization for telemetry submission
to api.vendor.com:8443 over TLS.

Step 4: Capability Mapping

Summarize what the binary CAN do:

## Capabilities

### Network
- [x] HTTP/HTTPS client (libcurl, libssl imports)
- [x] Custom TCP connections (socket/connect observed)
- [ ] Server functionality (no bind/listen/accept)

### File System
- [x] Read configuration (/etc/config.json accessed)
- [x] Write logs (/var/log/app.log)
- [ ] Execute other programs (no exec* calls)

### Cryptography
- [x] TLS encryption (SSL_* imports)
- [ ] Symmetric encryption (no AES/DES imports)
- [ ] Hashing (no SHA*/MD5 imports)

Step 5: Behavioral Summary

Document observed/inferred behavior:

## Behavioral Analysis

### Startup Sequence
1. Load configuration from /etc/config.json
2. Initialize network subsystem (function 0x8400)
3. Establish TLS connection to api.vendor.com:8443
4. Enter main loop (function 0x10800)

### Main Loop Behavior
- Polls sensor data every 30 seconds (timing from sleep() calls)
- Formats data as JSON (jsmn library identified)
- Submits via HTTPS POST
- Logs results to /var/log/app.log

### Error Handling
- Network failures: retry with exponential backoff
- Config errors: exit with code 1
- Unknown errors: continue with default values

Report Template

# Binary Analysis Report

## Executive Summary

[2-3 sentence overview of what was found]

## Artifact Information

| Property | Value |
|----------|-------|
| Filename | [name] |
| SHA256 | [hash] |
| Architecture | [arch] |
| Libc | [glibc/musl/uclibc] |
| Stripped | [yes/no] |
| Analysis Date | [date] |
| Analyst | [human + Claude] |

## Identification

**File Type:** ELF [32/64]-bit [LSB/MSB] [executable/shared object]

**Purpose (Hypothesis):** [What we believe this binary does]

**Confidence:** [High/Medium/Low] - [Brief justification]

## Capabilities Summary

### Confirmed Capabilities
- [Capability 1] - Evidence: [source]
- [Capability 2] - Evidence: [source]

### Potential Capabilities (Unverified)
- [Capability] - Reason: [why suspected]

## Technical Findings

### Key Functions

| Address | Inferred Name | Purpose | Confidence |
|---------|---------------|---------|------------|
| 0x8400 | network_init | Initialize network connection | High |
| 0x9200 | parse_config | Parse JSON configuration | Medium |
| 0x10800 | main_loop | Main execution loop | High |

### External Communications

| Destination | Port | Protocol | Purpose |
|-------------|------|----------|---------|
| api.vendor.com | 8443 | HTTPS | Telemetry submission |

### File System Access

| Path | Access | Purpose |
|------|--------|---------|
| /etc/config.json | Read | Configuration |
| /var/log/app.log | Write | Logging |

## Evidence Log

### Confirmed Hypotheses

**H1: Binary is a telemetry client**
- Status: CONFIRMED
- Supporting evidence:
  - Import of libcurl (HTTP client)
  - String "telemetry" found at 0x12340
  - connect() to api.vendor.com:8443 observed
- Contradicting evidence: None

### Refuted Hypotheses

**H2: Binary acts as server**
- Status: REFUTED
- Reason: No bind/listen/accept imports or calls observed

### Unresolved Questions

- Q1: What triggers telemetry submission? (Timing or event-based?)
- Q2: What data is collected? (Need deeper dynamic analysis)

## Recommendations

### For Security Review
- [ ] Verify TLS certificate validation
- [ ] Check for hardcoded credentials
- [ ] Audit data collection scope

### For Further Analysis
- [ ] Capture network traffic during execution
- [ ] Analyze configuration format in detail
- [ ] Test behavior with malformed config

## Appendices

### A. Tool Outputs
[Truncated raw outputs from key analysis steps]

### B. Timeline
[Chronological log of analysis steps taken]

### C. File Hashes
[SHA256 of all analyzed files]

Confidence Calibration

Use consistent confidence levels:

Level	Meaning	Evidence Required
High	Near certain	Multiple independent sources confirm
Medium	Likely correct	Some evidence, no contradictions
Low	Possible	Limited evidence, some uncertainty
Speculative	Guess	Based on patterns, not direct evidence

Quality Checklist

Before finalizing report:

• All hypotheses have explicit status (confirmed/refuted/uncertain)
• Every conclusion has traceable evidence
• Remaining unknowns are documented
• Technical details are accurate (addresses, names)
• No speculation presented as fact
• Recommendations are actionable

Knowledge Journaling

After synthesis, record final summary for episodic memory:

[BINARY-RE:synthesis] {filename} (sha256: {hash})
Analysis completed: {date}
Phases completed: {triage|static|dynamic|synthesis}

=== FINAL CONCLUSIONS ===

Primary purpose: {what binary does}
Confidence: {HIGH|MEDIUM|LOW}

Confirmed hypotheses:
  CONFIRMED: {hypothesis} (evidence: {facts})

Refuted hypotheses:
  REFUTED: {hypothesis} (reason: {contradicting evidence})

Key capabilities:
  - {capability}: {evidence summary}

Security findings:
  {CRITICAL|HIGH|MEDIUM|LOW}: {finding} (location: {addr/function})

Remaining unknowns:
  UNRESOLVED: {question}

Recommendations:
  - {actionable recommendation}

=== EVIDENCE INDEX ===
Facts: {count} recorded across phases
Hypotheses: {confirmed}/{total}
Questions: {answered}/{total}

Example Final Entry

[BINARY-RE:synthesis] thermostat_daemon (sha256: a1b2c3d4...)
Analysis completed: 2024-01-15
Phases completed: triage, static, dynamic, synthesis

=== FINAL CONCLUSIONS ===

Primary purpose: IoT telemetry client that reports temperature/humidity to vendor cloud
Confidence: HIGH

Confirmed hypotheses:
  CONFIRMED: "Telemetry client reporting to api.thermco.com" (evidence: URL string, curl imports, connect() observed)
  CONFIRMED: "30-second reporting interval" (evidence: sleep(30) in main loop, strace timing)

Refuted hypotheses:
  REFUTED: "May have local web server" (reason: no bind/listen/accept imports or calls)

Key capabilities:
  - HTTPS client: libcurl + libssl, connects to api.thermco.com:443
  - Config parsing: reads /etc/thermostat.conf at startup
  - Logging: writes to /var/log/thermostat.log

Security findings:
  LOW: No certificate pinning detected (standard libssl usage)
  INFO: Config file may contain API credentials (needs review)

Remaining unknowns:
  UNRESOLVED: Exact data fields in telemetry payload
  UNRESOLVED: Authentication mechanism (API key location)

Recommendations:
  - Review /etc/thermostat.conf for sensitive data
  - Monitor network traffic to confirm payload contents
  - Consider blocking if telemetry is unwanted

=== EVIDENCE INDEX ===
Facts: 23 recorded across phases
Hypotheses: 2/3 confirmed
Questions: 4/6 answered

Output Formats

Structured JSON (for tools/databases)

{
  "artifact": { "sha256": "...", "arch": "arm" },
  "conclusions": [
    {
      "statement": "Binary is telemetry client",
      "confidence": 0.9,
      "evidence": ["fact_001", "fact_012", "obs_003"]
    }
  ],
  "capabilities": {
    "network_client": true,
    "network_server": false
  },
  "open_questions": ["Q1: Trigger mechanism"]
}

Markdown (for human readers)

See template above.

STIX/TAXII (for threat intelligence)

If binary is potentially malicious, format findings for sharing:

{
  "type": "malware",
  "spec_version": "2.1",
  "id": "malware--...",
  "name": "telemetry-client",
  "malware_types": ["spyware"],
  "capabilities": ["exfiltrates-data"],
  "implementation_languages": ["c"]
}

Next Steps

After synthesis:

• Archive analysis artifacts
• Share report with stakeholders
• Document lessons learned
• Update tool configurations if needed