When to Use This Skill

Use this skill when analyzing malware samples, reverse engineering binaries for security research, conducting vulnerability assessments, extracting IOCs from suspicious files, validating software for supply chain security, or performing CTF challenges and binary exploitation research.

When NOT to Use This Skill

Do NOT use for unauthorized reverse engineering of commercial software, analyzing binaries on production systems, reversing software without legal authorization, violating terms of service or EULAs, or analyzing malware outside isolated environments. Avoid for simple string extraction (use basic tools instead).

Success Criteria

• All security-relevant behaviors identified (network, file, registry, process activity)
• Malicious indicators extracted with confidence scores (IOCs, C2 domains, encryption keys)
• Vulnerabilities documented with CVE mapping where applicable
• Analysis completed within sandbox environment (VM/container with snapshots)
• Findings validated through multiple analysis methods (static + dynamic + symbolic)
• Complete IOC report generated (STIX/MISP format for threat intelligence sharing)
• Zero false positives in vulnerability assessments
• Exploitation proof-of-concept created (if vulnerability research)

Edge Cases & Challenges

• Anti-analysis techniques (debugger detection, VM detection, timing checks)
• Obfuscated or packed binaries requiring unpacking
• Multi-stage malware with encrypted payloads
• Kernel-mode rootkits requiring specialized analysis
• Symbolic execution state explosion (>10,000 paths)
• Binary analysis timeout on complex programs (>24 hours)
• False positives from legitimate software behavior
• Encrypted network traffic requiring SSL interception

Guardrails (CRITICAL SECURITY RULES)

• NEVER execute unknown binaries on host systems (ONLY in isolated VM/sandbox)
• NEVER analyze malware without proper containment (air-gapped lab preferred)
• NEVER reverse engineer software without legal authorization
• NEVER share extracted credentials or encryption keys publicly
• NEVER bypass licensing mechanisms for unauthorized use
• ALWAYS use sandboxed environments with network monitoring
• ALWAYS take VM snapshots before executing suspicious binaries
• ALWAYS validate findings through multiple analysis methods
• ALWAYS document analysis methodology with timestamps
• ALWAYS assume binaries are malicious until proven safe
• ALWAYS use network isolation to prevent malware communication
• ALWAYS sanitize IOCs before sharing (redact internal IP addresses)

Evidence-Based Validation

All reverse engineering findings MUST be validated through:

1. Multi-method analysis - Static + dynamic + symbolic execution confirm same behavior
2. Sandbox validation - Execute in isolated environment, capture all activity
3. Network monitoring - Packet capture validates network-based findings
4. Memory forensics - Validate runtime secrets through memory dumps
5. Behavioral correlation - Cross-reference with known malware signatures (YARA, ClamAV)
6. Reproducibility - Second analyst can replicate findings from analysis artifacts

Reverse Engineering: Quick Triage

What This Skill Does

Performs rapid reverse engineering triage through two progressive levels:

• Level 1 (≤30 min): String reconnaissance - Extract URLs, IPs, IOCs, file paths, crypto indicators
• Level 2 (1-2 hrs): Static analysis - Disassemble with Ghidra/radare2, map control flow, decompile to C

Decision Gate: After Level 1, automatically evaluates if Level 2 is needed or if string analysis answered the question.

Timebox: ≤2 hours total

---

Prerequisites

Required Tools

• strings - GNU binutils (pre-installed on most Linux/macOS)
• file - File type identification
• sha256sum - Hashing utility
• xxd - Hex dump utility

Required for Level 2

• Ghidra - Headless analysis capability OR
• radare2 - Alternative disassembler
• graphviz - For callgraph visualization (dot command)

MCP Servers (Auto-Configured)

• memory-mcp - Store findings across sessions
• filesystem - Access binaries and create outputs
• connascence-analyzer - Analyze decompiled code quality
• sequential-thinking - Decision gate reasoning

---

⚠️ CRITICAL SECURITY WARNING

NEVER execute unknown binaries on your host system!

All dynamic analysis and binary execution MUST be performed in:

• Isolated VM (VMware/VirtualBox with snapshots enabled)
• Docker container with security restrictions (--security-opt seccomp=unconfined)
• E2B sandbox via sandbox-configurator skill
• Dedicated malware analysis environment (REMnux, FLARE VM)

Consequences of unsafe execution:

• Malware infection and persistent backdoors
• Data exfiltration and credential theft
• System compromise and lateral movement
• Ransomware deployment

Safe Practices:

• Always analyze binaries in an isolated environment
• Take VM snapshots before analysis
• Monitor network traffic during execution
• Never use your primary development machine
• Assume all unknown binaries are malicious until proven otherwise

---

Quick Start (3 commands)

# 1. Analyze suspicious binary (fastest path)
/re:quick malware.exe

# 2. String analysis only (Level 1, ≤30 min)
/re:quick suspicious.bin --level 1

# 3. Static analysis only (Level 2, 1-2 hrs)
/re:quick crackme.exe --level 2 --output ./analysis/

Auto-Decision: Skill will ask after Level 1: "Suspicious IOCs found. Proceed to Level 2?" (Yes/No/Auto)

---

Step-by-Step Guide

Level 1: String Reconnaissance (≤30 minutes)

Step 1: Launch String Analysis

# Invoke RE-String-Analyst agent via slash command
/re:strings binary.exe --min-length 10 --output re-project/artifacts/strings.json

What Happens:

1. Computes SHA256 hash of binary
2. Checks memory-mcp for prior analysis (avoids duplicate work)
3. Extracts printable strings with adaptive min-length
4. Categorizes findings: URLs, IPs, emails, file paths, protocols, crypto indicators
5. Generates strings.json with categorized IOCs

Expected Output:

{
  "binary": {"hash": "sha256:abc123...", "size": 1048576},
  "iocs": [
    "http://malicious-c2.tk/checkin",
    "192.168.100.50",
    "attacker@evil.com"
  ],
  "urls": [...],
  "file_paths": ["C:\\Windows\\System32\\malicious.dll"],
  "crypto": ["AES-256-CBC"],
  "analysis_time": "2025-11-01T10:15:00Z"
}

Step 2: Review String Findings

The skill will display:

• IOCs Found: 15 suspicious indicators
• Known-Good URLs: 42 (Microsoft, Google - likely benign)
• Private IPs: 5 (internal communication)
• Crypto Usage: AES-256, RSA-2048 detected

Step 3: Decision Gate

Automated Evaluation (via sequential-thinking MCP):

QUESTION: "Should we proceed to Level 2 static analysis?"
FACTORS:
- Suspicious C2 domain found (malicious-c2.tk) ✅
- Hardcoded credential strings present ✅
- Obfuscation indicators (encoded strings) ✅
- User's analytical question answered? ❌ (need deeper analysis)
DECISION: ESCALATE TO LEVEL 2

User Override:

• Type skip to exit after Level 1 (findings sufficient)
• Type continue to force Level 2 (even if not recommended)
• Type auto (default) to follow recommendation

---

Level 2: Static Analysis (1-2 hours)

Step 1: Launch Disassembly

# Invoke RE-Disassembly-Expert agent via slash command
/re:static binary.exe --tool ghidra --decompile true --callgraph true

What Happens:

1. Detects binary architecture (x86/x64/ARM/MIPS)
2. Loads into Ghidra headless analyzer
3. Performs auto-analysis (function discovery, CFG)
4. Decompiles key functions to pseudo-C
5. Generates callgraph visualization
6. Runs connascence-analyzer on decompiled code

Timeline:

• Small binary (<1MB): 30-45 minutes
• Medium binary (1-10MB): 1-1.5 hours
• Large binary (>10MB): 1.5-2 hours

Step 2: Review Disassembly Results

Output Structure:

re-project/
├── ghidra/
│   ├── binary.gpr                 # Ghidra project
│   ├── decompiled/
│   │   ├── main.c                 # Decompiled entry point
│   │   ├── check_auth.c           # Authentication function
│   │   └── encrypt_data.c         # Crypto function
│   ├── callgraphs/
│   │   └── main-callgraph.png     # Call graph visualization
│   └── cfg/
│       └── main-cfg.dot           # Control flow graph
├── notes/
│   ├── 001-strings-l1.md          # Level 1 findings
│   └── 002-static-l2.md           # Level 2 findings
└── artifacts/
    ├── strings.json               # From Level 1
    ├── imports.txt                # External library calls
    └── suspicious-functions.txt   # Flagged vulnerabilities

Step 3: Code Quality Analysis

Automatically applies connascence-analyzer to decompiled C code:

Detects:

• God Objects (functions > 500 lines)
• Parameter Bombs (functions > 7 parameters)
• Deep Nesting (> 4 levels)
• Complexity Issues
• NASA Power of 10 violations

Sample Output:

CONNASCENCE VIOLATIONS:
- check_auth.c:45 - God Object (723 lines)
- encrypt_data.c:12 - Parameter Bomb (11 parameters)
- network_handler.c:89 - Deep Nesting (6 levels)

Step 4: Store Findings in Memory

// Automatically stored by RE-Disassembly-Expert agent
mcp__memory-mcp__memory_store({
  content: {
    binary_hash: "sha256:abc123...",
    level_completed: 2,
    entry_point: "0x401000",
    critical_functions: [
      {name: "check_auth", address: "0x401234", decompiled: "check_auth.c"},
      {name: "encrypt_data", address: "0x401567", decompiled: "encrypt_data.c"}
    ],
    vulnerabilities: [
      {type: "buffer_overflow", function: "read_input", severity: "HIGH"},
      {type: "format_string", function: "log_message", severity: "MEDIUM"}
    ],
    callgraph: "callgraphs/main-callgraph.png",
    connascence_violations: 12
  },
  metadata: {
    agent: "RE-Disassembly-Expert",
    category: "reverse-engineering",
    intent: "static-analysis",
    layer: "long_term",
    project: `binary-analysis-${date}`,
    keywords: ["disassembly", "decompilation", "ghidra", "static"],
    re_level: 2,
    binary_hash: "sha256:abc123..."
  }
})

---

Advanced Options

Custom String Extraction

# Extract shorter strings for small binaries
/re:strings tiny-binary.exe --min-length 4

# IOCs only (skip non-IOC strings)
/re:strings malware.bin --ioc-only

# Unicode strings only
/re:strings international-app.exe --encoding unicode

Custom Disassembly Tools

# Use radare2 instead of Ghidra (faster, less accurate)
/re:static binary.exe --tool radare2

# Use objdump (very fast, no decompilation)
/re:static binary.exe --tool objdump --decompile false

# Focus on specific functions
/re:static binary.exe --functions main,check_password,crypto_init

Batch Analysis

# Analyze multiple binaries (Level 1 only for speed)
find ./malware-samples/ -name "*.exe" | while read binary; do
  /re:quick "$binary" --level 1 --store-findings true
done

# Cross-reference findings in memory-mcp
mcp__memory-mcp__vector_search({
  query: "malicious-c2.tk",  # Search for common IOC across all samples
  limit: 100,
  filter: {category: "reverse-engineering", re_level: 1}
})

---

Integration with Other Tools

Handoff to Dynamic Analysis

If static analysis reveals interesting runtime behavior:

# After Level 2 completes, check recommendations
cat re-project/notes/002-static-l2.md

# If recommended: "Proceed to dynamic analysis"
/re:deep binary.exe --breakpoints 0x401234,0x401567

Automatic Handoff: The skill stores handoff data in memory-mcp:

{
  key: "re-handoff/static-to-dynamic/${binary_hash}",
  value: {
    decision: "ESCALATE_TO_LEVEL_3",
    entry_point: "0x401000",
    critical_functions: ["check_password@0x401234"],
    breakpoint_suggestions: ["0x401234", "0x401567"],
    findings: {...}
  }
}

Export Findings

# Export to JSON for threat intel platform
cat re-project/artifacts/strings.json | jq '.iocs[]' > iocs-export.txt

# Export decompiled code
tar -czf decompiled-code.tar.gz re-project/ghidra/decompiled/

# Generate executive summary
cat re-project/notes/002-static-l2.md

---

Troubleshooting

Issue: "Binary already analyzed" Message

Symptoms: Skill exits immediately with cached results

Cause: SHA256 hash found in memory-mcp from prior analysis

Solution:

# Option 1: Use cached results (recommended if binary unchanged)
mcp__memory-mcp__vector_search({query: "sha256:abc123...", limit: 1})

# Option 2: Force re-analysis
/re:quick binary.exe --force-reanalyze true

Issue: Ghidra Headless Analysis Fails

Symptoms: "Ghidra headless not found" or timeout errors

Cause: Ghidra not installed or not in PATH

Solution:

# Install Ghidra
wget https://github.com/NationalSecurityAgency/ghidra/releases/download/.../ghidra.zip
unzip ghidra.zip
export PATH=$PATH:/path/to/ghidra/support

# Verify installation
analyzeHeadless -help

# Alternative: Use radare2
/re:static binary.exe --tool radare2

Issue: Too Many Strings (Noise)

Symptoms: strings.json contains 50,000+ strings, hard to analyze

Cause: Min string length too short for large binary

Solution:

# Increase min length automatically (skill does this by default)
# Or manually:
/re:strings large-binary.exe --min-length 15

# For firmware (very large)
/re:strings firmware.bin --min-length 20

Issue: Decompilation Quality Poor

Symptoms: Decompiled C code is unreadable or incorrect

Cause: Heavy obfuscation, packing, or custom compiler

Solution:

# Step 1: Check for packing
binwalk -E binary.exe  # High entropy = likely packed

# Step 2: Unpack first (if packed)
upx -d binary.exe -o unpacked.exe

# Step 3: Re-run static analysis
/re:static unpacked.exe

# If still poor: Manual analysis needed or try different tool
/re:static binary.exe --tool ida-pro  # If IDA Pro available

---

Performance Optimization

Speed Up Level 1 (String Analysis)

# Parallel string extraction for multiple encodings
strings -n 10 -e s binary.exe > ascii.txt &
strings -n 10 -e l binary.exe > unicode.txt &
wait

# Grep in parallel
grep -oE 'http[s]?://[^\s]*' ascii.txt > urls.txt &
grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' ascii.txt > ips.txt &
wait

Speed Up Level 2 (Static Analysis)

# Use radare2 for speed (sacrifice accuracy)
/re:static binary.exe --tool radare2  # 3-5x faster than Ghidra

# Skip decompilation if only need CFG
/re:static binary.exe --decompile false --callgraph true

# Analyze only critical functions (from Level 1 findings)
/re:static binary.exe --functions check_password,validate_license

Memory-MCP Caching Strategy

# Store Level 1 results immediately (fast, always cacheable)
# Level 1 completes in 10-15 min, cache for 30 days

# Store Level 2 results after completion
# Level 2 completes in 1-2 hrs, cache for 30 days

# Benefit: Second analysis of same binary takes <1 second

---

Agents & Commands Used

Agents Invoked

1. RE-String-Analyst (Level 1)

   • Specialist: String reconnaissance and IOC extraction
   • Tools: strings, grep, regex patterns
   • Output: strings.json, IOC lists

2. RE-Disassembly-Expert (Level 2)

   • Specialist: Static analysis and decompilation
   • Tools: Ghidra, radare2, objdump
   • Output: Decompiled C code, callgraphs, CFG

3. code-analyzer (Level 2, automatic)

   • Applies connascence analysis to decompiled code
   • Detects code smells and complexity

4. graph-analyst (Level 2, automatic)

   • Generates callgraph and CFG visualizations

Slash Commands

• /re:quick <binary> - Full Level 1+2 analysis (this skill's primary command)
• /re:strings <binary> - Level 1 only
• /re:static <binary> - Level 2 only

MCP Servers

• memory-mcp: Cross-session persistence, deduplication
• filesystem: Binary access, output creation
• connascence-analyzer: Code quality analysis
• sequential-thinking: Decision gate logic

---

Related Skills

• Reverse Engineering: Deep Analysis - Levels 3-4 (dynamic + symbolic)
• Reverse Engineering: Firmware - Level 5 (firmware extraction)
• Code Review Assistant - Review decompiled code
• Functionality Audit - Validate reverse-engineered logic

---

Resources

External Tools

• Ghidra - NSA's reverse engineering suite
• radare2 - Open-source disassembler
• binwalk - Firmware analysis
• IDA Pro - Commercial disassembler

Learning Resources

• Practical Malware Analysis - Book
• Ghidra Documentation - Cheat sheet
• radare2 Book - Complete guide

Community

• r/ReverseEngineering - Subreddit
• Reverse Engineering Stack Exchange

---

Created: 2025-11-01 RE Levels: 1-2 (String Reconnaissance + Static Analysis) Timebox: ≤2 hours Agents: RE-String-Analyst, RE-Disassembly-Expert Category: Security, Malware Analysis, Binary Analysis Difficulty: Intermediate

Core Principles

Reverse Engineering: Quick Triage operates on 3 fundamental principles:

Principle 1: Low-Hanging Fruit First

80% of malware behavior is revealed through strings and static analysis without execution.

In practice:

• Extract URLs, IPs, file paths, and crypto indicators from printable strings
• Identify C2 domains, hardcoded credentials, and API endpoints in minutes
• Categorize IOCs (indicators of compromise) for immediate threat intelligence
• Use SHA256 hash to check memory-mcp for prior analysis (avoid duplicate work)

Principle 2: Decision Gate Escalation

Not every binary needs deep analysis - automated gates prevent over-analysis.

In practice:

• Level 1 (strings) completes in 10-30 minutes, answers simple triage questions
• Escalate to Level 2 (static disassembly) only when suspicious IOCs found
• Use sequential-thinking MCP to evaluate if user question is answered
• Stop analysis when findings are sufficient to avoid wasting time

Principle 3: Decompilation for Comprehension

Disassembly is for machines, decompiled C pseudo-code is for analysts.

In practice:

• Use Ghidra headless mode to generate readable pseudo-C code
• Apply connascence analysis to detect god objects and complexity violations
• Generate callgraphs to visualize function relationships
• Focus on critical functions (auth, crypto, network) identified in Level 1

---

Common Anti-Patterns

Anti-Pattern	Problem	Solution
Immediately running Level 2 without Level 1	Waste 1-2 hours on disassembly when strings would have answered question	ALWAYS run Level 1 first, check decision gate before escalating
Analyzing same binary multiple times	Redundant work, wasted analysis hours, inconsistent findings	Check memory-mcp for SHA256 hash before starting analysis
Using min-length=4 on large binaries	50,000+ strings with massive noise, impossible to analyze	Use adaptive min-length (10-15 for normal, 20+ for firmware), enable --ioc-only filter
Skipping architecture detection	Ghidra fails to disassemble, CFG incomplete, decompilation garbage	Run file command first, verify architecture before loading into Ghidra
Not validating decompilation quality	False positives from obfuscation, incorrect conclusions, wasted follow-up	Check for packing with binwalk entropy, unpack before re-analyzing

---

Conclusion

Reverse Engineering: Quick Triage is the first-responder skill for binary analysis - fast, focused, and decisive. By combining string reconnaissance (Level 1) with static disassembly (Level 2), this skill delivers actionable intelligence in under 2 hours, making it ideal for incident response, malware triage, and CTF challenges where speed matters.

The skill's automated decision gates ensure analysis effort matches threat severity. Simple malware with obvious C2 domains stops at Level 1, while sophisticated samples with obfuscation automatically escalate to Level 2 for deeper investigation. Integration with memory-mcp creates organizational memory - once a binary is analyzed, its findings are instantly retrievable by hash, preventing redundant analysis across teams.

Use this skill when you need rapid answers: Is this binary malicious? What C2 servers does it contact? Are there hardcoded credentials? What vulnerabilities does it exploit? The 2-hour timebox makes it suitable for high-velocity security operations where dozens of samples need daily triage. For samples requiring runtime analysis or input synthesis, the skill seamlessly hands off to Level 3-4 (reverse-engineering-deep) with pre-populated breakpoints and critical function addresses, maximizing overall analysis efficiency.