Reverse Engineering & Binary Analysis

Prerequisites

Binary file to analyze: ELF, PE (.exe/.dll), Mach-O, raw firmware, .apk (native libs), .so, .dylib
PhantomYerra Binary Analysis Engine installed and configured
Symbolic execution engine available (included with PhantomYerra)
Claude API key configured (Settings → AI Configuration)
Python 3.12 runtime active (for adapter pipeline)
Written authorization covering binary analysis of the target software
Sufficient disk space for decompiled output (large binaries can generate 500 MB+ of analysis artifacts)

1

Select Reverse Engineering from Home Screen

Click the 🔬 Reverse Engineering card on the Home screen. You can either upload a binary file directly (drag and drop supported) or enter the full path to a binary on disk. PhantomYerra accepts the following formats:

Supported Formats: ELF Linux executables, shared objects (.so) PE Windows executables (.exe), DLLs (.dll), drivers (.sys) Mach-O macOS/iOS executables, frameworks (.dylib) Raw Firmware Bare-metal firmware images (.bin, .img, .fw, .hex) APK Android packages (native JNI libraries extracted automatically) Shared Libs .so (Linux), .dylib (macOS) — standalone analysis

PhantomYerra auto-detects the binary format using magic bytes and ELF/PE/Mach-O header parsing. No manual format selection is required.
2

Configure Analysis Settings

Set the analysis parameters before launching the pipeline:

Analysis Depth: Quick Checksec + strings + imports only (~2 min) Standard Full decompilation + pattern matching (~15 min) Deep All 13 adapters including symbolic execution + diffing (~60 min) Target Architecture (auto-detected, override if needed): x86 | x64 | ARM (32-bit) | ARM64 (AArch64) | MIPS | RISC-V Analysis Modules (all enabled by default in Deep mode): binary_detector Format identification (ELF/PE/Mach-O/firmware) symbol_extractor Imports, exports, dynamic symbols, debug info cfg_generator Control flow graph construction + visualization vuln_pattern_detector Dangerous function calls, buffer ops, format strings crypto_identifier Crypto constants, hardcoded keys, custom algorithms protocol_analyzer Network protocol reverse engineering from binary anti_analysis_detector Anti-debug, anti-VM, packing, obfuscation detection firmware_deep Firmware-specific: bootloader, partition table, RTOS binary_symex Symbolic execution for automated exploit path finding binary_differ Binary diffing for patch analysis + 1-day discovery malware_scanner Behavioral signature matching, YARA rules, IOC extraction attack_surface_mapper Input parsing, network listeners, IPC endpoints ai_narrator Claude AI-generated vulnerability narrative + PoC

You can disable individual modules by unchecking them in the module selection panel. For Quick analysis, only binary_detector, symbol_extractor, vuln_pattern_detector, and crypto_identifier run.
3

Complete Mission Control Wizard

Step 1: Environment → Lab / Staging / Production binary Step 2: Mode → Automated AI (selected) Step 3: Surfaces → Reverse Engineering (auto-selected) Step 4: Binary Input → File path or uploaded binary confirmed Step 5: Auth Token → Authorization document for binary analysis Step 6: AI Interview → Context questions: "What does this binary do?" "Is source code available for diffing?" "Known architecture or compiler?" Step 7: Review → Confirm modules, depth, architecture, launch
4

AI Binary Analysis Pipeline (13-Phase)

Claude orchestrates all 13 adapters in sequence. Each phase feeds its output into the next, building a complete binary security profile:

Phase 1: Format Detection (binary_detector) Identify file type via magic bytes, parse ELF/PE/Mach-O headers, detect compiler (GCC/Clang/MSVC/Go/Rust), determine linkage type Phase 2: Header & Section Parsing Parse section table, segment permissions (R/W/X), entry point, detect overlay data, embedded resources, certificate tables Phase 3: Symbol Extraction (symbol_extractor) Extract imports/exports, dynamic symbols, PLT/GOT entries, debug symbols (DWARF/PDB if present), reconstruct function names Phase 4: Control Flow Graph Generation (cfg_generator) Build per-function CFG, identify loops/branches/switch tables, compute cyclomatic complexity, detect unreachable code blocks Phase 5: String Analysis Extract ASCII/Unicode/wide strings, run FLOSS for obfuscated strings, regex match: URLs, IPs, credentials, API keys, file paths, SQL queries, error messages, debug strings Phase 6: Crypto Identification (crypto_identifier) Detect AES S-box constants, DES permutation tables, RSA moduli, SHA/MD5 init vectors, custom XOR/RC4 patterns, hardcoded keys, certificate pinning bypass opportunities Phase 7: Vulnerability Pattern Matching (vuln_pattern_detector) Flag dangerous calls: strcpy, gets, sprintf, system, exec, popen, dlopen, LoadLibrary. Trace data flow from input to sink. Match CWE patterns: CWE-120 (buffer overflow), CWE-134 (format string), CWE-78 (OS command injection), CWE-676 (dangerous func) Phase 8: Protocol Reverse Engineering (protocol_analyzer) Identify network protocol handling: socket/bind/listen/accept, reconstruct packet structures, detect custom binary protocols, map TLS/SSL usage, identify plaintext transmission Phase 9: Anti-Analysis Detection (anti_analysis_detector) Detect anti-debugging (ptrace, IsDebuggerPresent, timing checks), anti-VM (CPUID, registry checks, MAC address checks), packing (UPX, Themida, VMProtect), code obfuscation (control flow flattening, opaque predicates, junk code insertion) Phase 10: Symbolic Execution (binary_symex) Automated path exploration from entry/input points to dangerous sinks. Constraint solving for buffer overflow trigger inputs. Generate concrete exploit inputs for confirmed vulnerabilities. Timeout: configurable (default 300s per function) Phase 11: Binary Diffing (binary_differ) Compare against known-good version or previous patch level. Identify patched functions, new code paths, removed checks. Flag silently patched vulnerabilities (1-day discovery) Phase 12: Attack Surface Mapping (attack_surface_mapper) Enumerate all input vectors: CLI args, env vars, file parsers, network listeners, IPC endpoints (pipes, shared memory, D-Bus), registry reads, config file parsing. Score each by exposure Phase 13: AI Narrative Generation (ai_narrator) Claude reviews all findings, writes professional narrative per vulnerability, generates copy-paste PoC code, assigns CVSS, maps to CVE/CWE, writes executive summary + remediation plan
5

Monitor Analysis Dashboard

The RE Dashboard updates in real time as each phase completes:

Left Panel: Function list with complexity scores and risk indicators Click any function to view its decompiled C pseudocode Red markers indicate vulnerable functions Orange markers indicate functions calling dangerous APIs Center Panel: Decompiled code viewer with syntax highlighting Vulnerability annotations inline (hover for details) Cross-references: click any call to jump to callee Right Panel: Call graph visualization (interactive, zoomable) Vulnerability markers on graph nodes Attack path highlighting from input to vulnerable sink Bottom Panel: Findings stream — new vulnerabilities appear as confirmed Phase progress bar showing current adapter status Real-time activity log with adapter output
6

Review Findings and Generate Report

Click any finding to see the full details:

Finding Detail View: CVE Match If the vulnerability matches a known CVE, it is linked CWE Reference CWE-120 Buffer Overflow, CWE-134 Format String, etc. CVSS Score AI-assigned with full vector string Exploit Diff. Easy / Medium / Hard — based on mitigations present Decompiled Code The vulnerable function with the flaw highlighted Call Chain Entry point → intermediate calls → vulnerable function PoC Code Copy-paste exploit script (Python/C) generated by Claude Remediation Binary-specific: "Enable PIE compilation flag", "Replace strcpy with strncpy at line 47", "Upgrade OpenSSL from 1.0.2 to 3.x"

Click Reports → Generate → Binary Security Report for the full PDF with executive summary, technical findings, attack surface map, and remediation roadmap.

What Claude Tests (Reverse Engineering)

Buffer overflows: stack-based, heap-based, off-by-one, integer overflow leading to buffer overflow
Format string vulnerabilities: printf family with user-controlled format parameter
Use-after-free and double-free: heap management errors in decompiled code
Command injection: system/exec/popen with controllable arguments
Hardcoded credentials: passwords, API keys, tokens, certificates embedded in binary
Weak cryptography: MD5/SHA1 for security, ECB mode, hardcoded keys, predictable IVs
Missing security mitigations: no NX, no ASLR, no PIE, no stack canary, no RELRO, no CFI
Anti-analysis and evasion: packing, obfuscation, anti-debug, anti-VM techniques
Protocol vulnerabilities: plaintext transmission, weak authentication, replay attacks
Insecure deserialization in binary protocol handlers
Race conditions: TOCTOU in file operations, thread-unsafe shared state
Information disclosure: debug strings, verbose error paths, symbol leaks

⏱ Automated analysis: 5 minutes (Quick) to 60 minutes (Deep). Binary decompilation of large binaries (100 MB+) can take up to 30 minutes. Symbolic execution adds 5-15 minutes per targeted function.

Prerequisites

Same as Automated AI mode
Select "Semi-Automated" in Wizard Step 2
Familiarity with binary analysis concepts recommended for approval decisions

1

Upload Binary and Approve Initial Assessment

Proposal: "Run format detection and security posture check on uploaded binary" → [Approve] → Format: ELF 64-bit LSB executable, x86-64, dynamically linked → Compiler: GCC 11.4.0 → Security posture: NX: enabled | ASLR: compatible | PIE: disabled | Canary: disabled RELRO: partial | Fortify: disabled | CFI: disabled → WARNING: PIE and stack canary disabled — exploitable buffer overflows likely → WARNING: No CFI — control flow hijacking viable if code pointer corrupted
2

Approve Analysis Phases Sequentially

Claude proposes each analysis phase. Review and approve, edit parameters, or skip:

Proposal: "Extract all strings — search for credentials, keys, hardcoded URLs, debug info" → [Approve] → Found 14,287 strings. Flagged: "admin:P@ssw0rd123" (hardcoded credential) "DEBUG_MODE=1" (debug flag) "AKIA3EXAMPLE..." (AWS key prefix) "mongodb://localhost:27017/prod" (database connection string) Proposal: "Decompile all functions with Binary Analysis Engine — focus on network handlers" → [Approve] → 247 functions decompiled — 3 flagged as high-risk: handle_request() at 0x401a30 — uses sprintf with user input parse_header() at 0x4023f0 — unbounded memcpy from network buffer auth_check() at 0x403100 — strcmp timing leak on password Proposal: "Run symbolic execution on handle_request() — check for buffer overflow" → [Edit: set timeout to 120 seconds] → [Approve] → Buffer overflow CONFIRMED: 512-byte stack buffer, no bounds check Concrete input generated: 520 bytes triggers EIP overwrite Exploit difficulty: EASY (no PIE, no canary) Proposal: "Scan for crypto weaknesses — identify hardcoded keys and weak algorithms" → [Approve] → Found: AES-128-ECB with hardcoded key at 0x40b200 Found: MD5 used for password hashing at 0x40c100 Found: Custom XOR cipher at 0x40d400 (trivially reversible) Proposal: "Map full attack surface — enumerate all input vectors and network listeners" → [Approve] → 7 input vectors identified: TCP port 8080, UDP port 5353, stdin parser, config file reader, 3 environment variables
3

Review AI-Generated Narratives and Approve Report

Proposal: "Generate professional vulnerability narratives and PoC code for all 6 confirmed findings" → [Approve] → 6 findings with full write-ups: CRITICAL: Stack buffer overflow in handle_request() — PoC exploit attached HIGH: Hardcoded AWS credentials — account takeover risk HIGH: AES-ECB with static key — encrypted data fully recoverable MEDIUM: MD5 password hashing — offline cracking in seconds MEDIUM: Debug mode enabled in production build LOW: Timing side-channel in auth_check() — password extraction possible
4

Add Manual Notes and Generate Report

Add any manual observations from your own analysis. Click Complete Engagement to generate the final Binary Security Report with all approved findings.

⏱ Typical duration: 2-5 hours with active approval and manual review of decompiled code.

Prerequisites

PhantomYerra Binary Analysis Engine configured (Settings → Tools → Binary Analysis)
checksec, pwntools, symbolic execution engine installed (via PhantomYerra setup)
PhantomYerra Runtime Debugger installed for dynamic analysis
Binary diffing tools available for patch analysis
Target binary accessible on local filesystem

1

Binary Identification

Determine the binary format, architecture, compiler, and linkage type before any deeper analysis:

# Identify binary type and architecture file ./target_binary ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=a1b2c3d4..., not stripped # ELF header details readelf -h ./target_binary Type: EXEC (Executable file) Machine: Advanced Micro Devices X86-64 Entry point: 0x401080 Number of section headers: 31 # PE binary (Windows) dumpbin /headers target.exe machine (x64) 14C8 time date stamp subsystem: Windows CUI # Mach-O binary (macOS) otool -h ./target_binary otool -L ./target_binary # list linked libraries # Detect compiler and build info strings ./target_binary | grep -i "gcc\|clang\|msvc\|rustc\|go build"
2

Security Posture Assessment

Check all compile-time and link-time security mitigations. Missing mitigations directly affect exploit difficulty:

# Full security posture check checksec --file=./target_binary # Example output and what each mitigation means: RELRO: Partial RELRO # Full = GOT read-only; Partial = GOT writable Stack: No canary found # Canary = stack smash detected; None = easy overflow NX: NX enabled # NX = no execute on stack; Disabled = shellcode on stack PIE: No PIE # PIE = randomized base; None = fixed addresses (easy ROP) RPATH: No RPATH # RPATH = library hijack possible RUNPATH: No RUNPATH # Same as RPATH Fortify: No # Fortify = compile-time buffer overflow checks CFI: No # CFI = control flow integrity enforcement # Security mitigations summary table: # Mitigation Status Impact if Missing # ────────── ────── ───────────────── # NX YES Stack shellcode blocked # ASLR PARTIAL Base address fixed, heap/stack randomized # PIE NO Fixed code addresses — trivial ROP gadget use # Canary NO Stack buffer overflows exploit without detection # Full RELRO NO GOT overwrite attacks possible # Fortify NO No compile-time bounds checking # CFI NO Arbitrary control flow hijacking viable
3

String Analysis

Extract and analyze strings for credentials, debug information, embedded URLs, and other sensitive data:

# Basic string extraction (ASCII and Unicode) strings -a ./target_binary | wc -l # count total strings strings -a -el ./target_binary # extract UTF-16LE (Windows wide strings) # Search for credentials and secrets strings -a ./target_binary | grep -iE \ "(password|passwd|secret|token|api.key|auth|credential|private)" # Search for URLs, IPs, and endpoints strings -a ./target_binary | grep -iE \ "(https?://|ftp://|[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+|/api/|/admin)" # Search for SQL queries (indicates database interaction) strings -a ./target_binary | grep -iE \ "(SELECT|INSERT|UPDATE|DELETE|DROP|CREATE|ALTER).*FROM" # Search for file paths and config references strings -a ./target_binary | grep -iE \ "(/etc/|/tmp/|/var/|C:\\\\|\.conf|\.cfg|\.ini|\.env)" # FLOSS: extract obfuscated/encoded strings (decoded at runtime) floss ./target_binary --no-static-strings # Reveals strings hidden by XOR, base64, stack-constructed strings # Binwalk: find embedded files, certificates, compressed archives binwalk ./target_binary DECIMAL HEXADECIMAL DESCRIPTION 0 0x0 ELF, 64-bit LSB executable 154832 0x25CD0 Certificate in DER format 289456 0x46AB0 gzip compressed data 301200 0x49890 JPEG image data
4

Symbol and Import Analysis

Analyze imported functions and libraries to identify dangerous API usage and understand binary capabilities:

# List dynamic symbols (imports and exports) nm -D ./target_binary 2>/dev/null | head -50 # List imported shared libraries ldd ./target_binary readelf --dyn-syms ./target_binary # Find dangerous function imports (these are exploit targets) nm -D ./target_binary | grep -E \ "(strcpy|strcat|sprintf|vsprintf|gets|scanf|sscanf|realpath)" # strcpy/strcat/sprintf = buffer overflow (no bounds) # gets = always exploitable (reads unlimited stdin to buffer) # scanf without width = buffer overflow on input # Find execution-related imports (command injection indicators) nm -D ./target_binary | grep -E "(system|exec|popen|dlopen|LoadLibrary)" # system/popen = shell command execution # exec family = process replacement # dlopen/LoadLibrary = dynamic library loading (DLL hijack) # Find network-related imports (attack surface) nm -D ./target_binary | grep -E "(socket|bind|listen|accept|connect|recv|send)" # Find crypto-related imports nm -D ./target_binary | grep -E "(MD5|SHA|AES|DES|RSA|EVP_|HMAC|RAND)" # Disassemble calls to dangerous functions with surrounding context objdump -d ./target_binary | grep -A5 "call.*gets\|call.*strcpy\|call.*sprintf"
5

Control Flow Graph Generation

Generate control flow graphs to understand program logic, identify unreachable code, and find complex vulnerability patterns:

# PhantomYerra Binary Analysis Engine headless CFG generation # PhantomYerra → RE → Binary Analysis Engine → Import Binary # Project: /tmp/re_project # Enable: "Full Analysis" + "Decompile All Functions" # After analysis completes, export CFG: # PhantomYerra → RE → Export CFG → select function → DOT/SVG/PNG # Key things to look for in the CFG: # - Functions with high cyclomatic complexity (>20) = likely bugs # - Error handling paths that skip cleanup = resource leaks # - Loops without bounds checks = potential infinite loops or overflows # - Switch/case tables with missing default = undefined behavior # - Unreachable code blocks = dead code or hidden backdoors # Automated CFG analysis via PhantomYerra: # The cfg_generator adapter produces: # - Per-function CFG with basic block boundaries # - Loop detection (natural loops, irreducible loops) # - Dominator tree for data flow analysis # - Call graph showing inter-procedural flow
6

Crypto Analysis

Identify cryptographic implementations, hardcoded keys, and weak algorithms:

# Identifying crypto constants in binary data # AES S-box first row: 63 7c 77 7b f2 6b 6f c5 # DES initial permutation: 58 50 42 34 26 18 10 02 # SHA-256 init: 6a09e667 bb67ae85 3c6ef372 a54ff53a # MD5 init: 67452301 efcdab89 98badcfe 10325476 # RSA: look for large prime numbers (256+ bytes) # Search for crypto constants python3 -c " import binascii with open('./target_binary', 'rb') as f: data = f.read() # AES S-box sbox = bytes([0x63,0x7c,0x77,0x7b,0xf2,0x6b,0x6f,0xc5]) if sbox in data: print(f'AES S-box found at offset {data.index(sbox):#x}') # MD5 init md5 = bytes.fromhex('01234567896789ab') if md5 in data: print(f'MD5 constant found at offset {data.index(md5):#x}') " # Find hardcoded keys (fixed-length byte sequences near crypto funcs) # PhantomYerra → RE → Crypto Identifier → scan binary # Results show: # - Algorithm identified (AES, DES, RC4, ChaCha20, custom XOR) # - Key location in binary (offset + function context) # - Key material extracted (if hardcoded) # - Mode of operation (ECB = weak, CBC/GCM = better) # - IV/nonce handling (static = weak, random = acceptable) # Detect custom/homebrew crypto (major red flag) # Look for: XOR loops, byte substitution tables not matching known S-boxes, # bit rotation patterns, custom PRNG seeding
7

Symbolic Execution

Use the symbolic execution engine to automatically find inputs that trigger vulnerabilities:

# PhantomYerra → RE → Symbolic Execution Engine → open binary # Example: find input that reaches a vulnerable sprintf call python3 << 'EOF' import phantomyerra.re.symexec as symexec # Load binary without auto-loading external libraries proj = symexec.Project('./target_binary', auto_load_libs=False) # Create initial state at entry point state = proj.factory.entry_state() # Define target: address of vulnerable sprintf call VULN_ADDR = 0x401a30 # address of sprintf with user input SAFE_ADDR = 0x401b00 # address of safe exit path # Create simulation manager and explore simgr = proj.factory.simulation_manager(state) simgr.explore(find=VULN_ADDR, avoid=SAFE_ADDR) if simgr.found: found_state = simgr.found[0] # Extract the concrete input that reaches the vulnerability exploit_input = found_state.posix.dumps(0) # stdin print(f"Input that triggers vulnerability ({len(exploit_input)} bytes):") print(exploit_input) # Check if we can control EIP/RIP rip = found_state.regs.rip if found_state.solver.symbolic(rip): print("RIP is symbolic — control flow hijack possible!") # Solve for specific value target_rip = 0xdeadbeef found_state.solver.add(rip == target_rip) exploit = found_state.posix.dumps(0) print(f"Exploit payload for RIP={target_rip:#x}: {exploit}") else: print("No path found to vulnerable code (may need more time or constraints)") EOF # Tips for symbolic execution: # - Target specific functions, not the entire binary (state explosion) # - Set step limits: simgr.explore(..., num_find=1) stops at first hit # - Use blank_state at function start for isolated function analysis # - Hook library calls to avoid modeling libc internals # - Increase memory limit for binaries with large address spaces
8

Binary Diffing for Patch Analysis

Compare two versions of a binary to find patched vulnerabilities (1-day discovery) or introduced regressions:

# PhantomYerra → RE → Binary Differ → select two binaries # Binary A: original/vulnerable version # Binary B: patched/updated version # The differ produces: # - Matched functions (by signature, CFG shape, and code similarity) # - Modified functions (code changed between versions) # - Added functions (new in patched version) # - Removed functions (deleted in patched version) # - Similarity score per function (0.0 = completely different, 1.0 = identical) # Focus on modified functions with similarity 0.7-0.99: # These are the patched functions — the diff shows exactly what was fixed # The pre-patch version likely contains the vulnerability # Example diff output: # Function: parse_input() # Similarity: 0.92 # Change: Added bounds check before memcpy (line 47) # if (len > sizeof(buffer)) len = sizeof(buffer); // PATCH # Verdict: Buffer overflow patched — pre-patch version exploitable # For firmware patch analysis: # Compare firmware v1.2 and v1.3 to find silently patched security bugs # Vendors often patch without CVE disclosure — binary diffing reveals these

⏱ Duration: 1 day (simple binary) to 2 weeks (complex proprietary software with obfuscation and anti-analysis).

Configuration Options

Option	Values	Default	Description
Analysis Depth	Quick / Standard / Deep	Standard	Controls which adapters run and how thorough each analysis phase is
Architecture	x86 / x64 / ARM / ARM64 / MIPS / RISC-V	Auto-detect	Target CPU architecture; auto-detected from binary headers
Decompile All	Yes / No	Yes	Decompile every function or only flagged functions
Symbolic Exec Timeout	30s - 3600s	300s	Maximum time per function for symbolic execution
Symex Step Limit	1000 - 1000000	100000	Maximum simulation steps before abandoning a path
String Min Length	3 - 20 chars	4	Minimum string length to extract from binary
Diff Baseline	File path / None	None	Previous binary version for binary diffing comparison
YARA Rules	Built-in / Custom path	Built-in	YARA rule set for malware signature matching
Anti-Analysis Scan	On / Off	On	Check for packing, obfuscation, anti-debug, anti-VM
Auto-Unpack	On / Off	On	Attempt automatic unpacking of packed/compressed binaries
CFG Output	DOT / SVG / PNG / None	SVG	Format for exported control flow graphs
Report Format	PDF / HTML / JSON / SARIF	PDF	Output format for the binary security report

Common Scenarios

Goal: Find and exploit a vulnerability in a CTF challenge binary to capture the flag.

Recommended Settings: Deep analysis, all modules enabled, symbolic execution timeout set to 600s.

Approach: Start with checksec to identify missing mitigations. If no PIE and no canary, look for stack buffer overflows first. Use symbolic execution targeting the "win" function (the flag printer). The binary_symex adapter will generate the exact payload. If the binary is stripped (no symbols), the vuln_pattern_detector still identifies dangerous function patterns by opcode matching.

Expected Duration: 5-30 minutes for typical CTF challenges.

Goal: Analyze firmware extracted from an IoT device (router, camera, smart home hub) for vulnerabilities.

Recommended Settings: Deep analysis with firmware_deep adapter enabled, ARM or MIPS architecture (common for IoT), auto-unpack enabled.

Approach: Upload the full firmware image. PhantomYerra extracts the filesystem automatically. The firmware_deep adapter identifies the RTOS, bootloader, and partition layout. Each executable binary in the filesystem is analyzed individually. Focus on: web server binaries (httpd, lighttpd), network daemons (telnetd, sshd, upnpd), and custom management binaries. Check for hardcoded credentials, command injection in CGI scripts, and unsigned firmware update mechanisms.

Expected Duration: 30-120 minutes depending on firmware size and number of binaries.

Goal: Quickly triage a suspected malicious PE file to determine capabilities, IOCs, and threat classification.

Recommended Settings: Deep analysis, malware_scanner + anti_analysis_detector + crypto_identifier enabled, auto-unpack enabled, symbolic execution disabled (malware analysis prioritizes speed over exploit generation).

Approach: The anti_analysis_detector identifies packing (UPX, Themida, VMProtect) and evasion techniques. If packed, PhantomYerra auto-unpacks before analysis. The malware_scanner matches against YARA rules for known malware families. String analysis reveals C2 domains, registry keys, mutex names. The crypto_identifier finds encryption routines used for data exfiltration or ransomware payload. The attack_surface_mapper identifies all persistence mechanisms (registry, scheduled tasks, services, DLL injection targets).

Expected Duration: 10-30 minutes for initial triage.

Goal: Analyze native JNI libraries (.so) from an Android APK or native frameworks from an iOS IPA for vulnerabilities.

Recommended Settings: Standard or Deep analysis, ARM/ARM64 architecture, protocol_analyzer enabled (for API communication), crypto_identifier enabled (for certificate pinning and key storage).

Approach: For Android, upload the APK directly — PhantomYerra extracts native libraries from lib/ automatically. For iOS, extract the .dylib frameworks from the IPA. Focus on: JNI bridge functions (Java_com_*), SSL/TLS pinning implementation, token/key storage, root/jailbreak detection logic (can it be bypassed?), and anti-tampering checks. The protocol_analyzer reconstructs the app's API protocol from the binary, revealing undocumented endpoints.

Expected Duration: 15-45 minutes per native library.

Common Issues

Verify the Binary Analysis Engine installation path in Settings → Tools → Binary Analysis. The headless analysis script must be in the engine's support/ directory. Check that the post-script path is correct and DecompileAll.py exists at config/binary_analysis_scripts/DecompileAll.py. For large binaries (100 MB+), increase the Java heap size in the engine's launch.properties file: MAXMEM=4G. Enable verbose logging in the settings panel to see detailed analysis output.

Symbolic execution suffers from state explosion on complex code paths. Reduce scope: use blank_state starting at the target function address instead of entry_state. Set the step limit in Settings → Tools → Symbolic Execution → Step Limit to 50,000 for initial runs. Hook library calls (especially malloc, printf, strlen) to avoid modeling libc internals. For large binaries, identify the vulnerable function via decompilation first, then target symbolic execution precisely at that function only.

Enable Auto-Unpack in the analysis settings. For UPX-packed binaries, PhantomYerra unpacks automatically. For custom packers: run the binary under the PhantomYerra Runtime Debugger, set a breakpoint at the original entry point (OEP), let the unpacking stub run, then dump the unpacked binary from memory. Alternatively, use the PhantomYerra System Call Tracer to trace the binary in a sandbox — it logs all API calls made during unpacking, revealing the OEP and the decryption routine. The anti_analysis_detector identifies the packing method used, which helps select the correct unpacking approach.

Verify the architecture override in the analysis settings. For ARM binaries, check if the binary uses Thumb mode (16-bit instructions mixed with 32-bit) — select "ARM + Thumb" mode. For MIPS, confirm endianness (big-endian MIPS vs little-endian MIPSEL). If the binary has no ELF header (raw firmware dump), you must manually specify the base load address and architecture in the Binary Analysis Engine import settings. Use readelf -h on ELF binaries or file on raw binaries to confirm architecture before analysis.

This typically occurs when the two binaries were compiled with different compilers, optimization levels, or architectures. Ensure both binaries target the same architecture and were built from the same codebase. If the binaries are stripped (no symbols), the differ relies on CFG shape matching, which requires both binaries to be fully analyzed first. Run full analysis on both binaries individually before attempting the diff. For heavily obfuscated binaries, try reducing the similarity threshold in Settings → Tools → Binary Differ → Match Threshold from 0.7 to 0.5.

Full Disclosure

264 modules · 30+ surfaces · 14 vuln families · 120+ classes

The sections above describe what this surface tests. For the complete enumeration of every vulnerability class PhantomYerra covers across all surfaces — with scanner module names — see the Coverage Matrix.

View Full Coverage Matrix →

Reverse Engineering & Binary Analysis

Prerequisites

Select Reverse Engineering from Home Screen

Configure Analysis Settings

Complete Mission Control Wizard

AI Binary Analysis Pipeline (13-Phase)

Monitor Analysis Dashboard

Review Findings and Generate Report

What Claude Tests (Reverse Engineering)

Prerequisites

Upload Binary and Approve Initial Assessment

Approve Analysis Phases Sequentially

Review AI-Generated Narratives and Approve Report

Add Manual Notes and Generate Report

Prerequisites

Binary Identification

Security Posture Assessment

String Analysis

Symbol and Import Analysis

Control Flow Graph Generation

Crypto Analysis

Symbolic Execution

Binary Diffing for Patch Analysis

Configuration Options

Common Scenarios

Common Issues

Related Topics

264 modules · 30+ surfaces · 14 vuln families · 120+ classes