| 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