reverse-engineering-firmware-analysis

---

LIBRARY-FIRST PROTOCOL (MANDATORY)

Before writing ANY code, you MUST check:

Step 1: Library Catalog

• Location: .claude/library/catalog.json
• If match >70%: REUSE or ADAPT

Step 2: Patterns Guide

• Location: .claude/docs/inventories/LIBRARY-PATTERNS-GUIDE.md
• If pattern exists: FOLLOW documented approach

Step 3: Existing Projects

• Location: D:\Projects\*
• If found: EXTRACT and adapt

Decision Matrix

| Match | Action | |-------|--------| | Library >90% | REUSE directly | | Library 70-90% | ADAPT minimally | | Pattern exists | FOLLOW pattern | | In project | EXTRACT | | No match | BUILD (add to library after) |

---

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: Firmware Analysis

What This Skill Does

Extracts and analyzes firmware from IoT devices, routers, and embedded systems:

• Extraction (30min-2hrs): Use binwalk to extract SquashFS/JFFS2/CramFS filesystems
• Service Analysis (1-3hrs): Map init scripts, daemons, network listeners
• Vulnerability Assessment (1-3hrs): Find hardcoded credentials, CVEs, injection points
• Binary Analysis (1-2hrs): Apply Levels 1-4 to extracted binaries

Timebox: 2-8 hours total

---

Prerequisites

Tools

• binwalk - Firmware extraction (binwalk -Me firmware.bin)
• unsquashfs - SquashFS extraction
• file - File type identification
• QEMU (optional) - Emulate extracted binaries
• Jefferson (optional) - JFFS2 extraction
• strings - For string analysis on firmware

MCP Servers

• filesystem - Navigate extracted firmware
• security-manager - CVE scanning
• connascence-analyzer - Code quality analysis
• memory-mcp - Store findings
• sequential-thinking - Decision gate for binary analysis

---

⚠️ CRITICAL SECURITY WARNING

NEVER execute firmware binaries or extracted files on your host system!

All firmware extraction, binary execution, and emulation MUST be performed in:

• Isolated VM (VMware/VirtualBox with network isolation and snapshots)
• Docker container with strict security policies and no host filesystem access
• E2B sandbox via sandbox-configurator skill with monitored execution
• Firmware analysis environment (QEMU with -snapshot, firmadyne sandbox)

Consequences of unsafe execution:

• Backdoor installation and persistent network access
• Extraction of hardcoded credentials compromising related devices
• Malware propagation to development infrastructure
• IoT botnet recruitment (Mirai, Hajime variants)
• Compromise of cloud API keys and services

Safe Practices:

• Extract firmware in isolated containers with no network access
• Use QEMU emulation with snapshot mode (-snapshot flag)
• Never connect emulated devices to production networks
• Validate extracted credentials in isolated environments only
• Monitor all network connections during firmware emulation
• Treat all IoT firmware as potentially compromised
• Use read-only mounts for extracted filesystems

---

Quick Start

# 1. Full firmware analysis
/re:firmware router-firmware.bin

# 2. Extract filesystem only
/re:firmware iot-device.img --extract-only

# 3. Analyze extracted services
/re:firmware camera-fw.bin --analyze-services true

# 4. Extract + analyze specific binary
/re:firmware router.bin --analyze-binary /usr/sbin/httpd

---

Phase 1: Firmware Identification (5-10 minutes)

Step 1: Basic File Analysis

# Identify file type
file firmware.bin

# Expected output examples:
# - "firmware.bin: u-boot legacy uImage, MIPS OpenWrt Linux-4.14.63"
# - "firmware.bin: data" (encrypted or compressed)
# - "firmware.bin: Flattened device tree blob (DTB)"

Step 2: Entropy Analysis

Check if firmware is encrypted or compressed:

# Entropy analysis
binwalk --entropy firmware.bin

# Output visualization:
# High entropy throughout (> 0.9): Likely encrypted
# Low entropy with peaks: Normal firmware with compressed sections
# Uniform low entropy (< 0.5): Uncompressed firmware

Interpretation:

• Entropy 0.9-1.0: Encrypted firmware (need decryption key)
• Entropy 0.6-0.8: Compressed sections (normal)
• Entropy 0.3-0.5: Uncompressed data

Step 3: Component Identification

# Identify firmware components
binwalk --signature firmware.bin

# Expected output:
# DECIMAL       HEXADECIMAL     DESCRIPTION
# --------------------------------------------------------------------------------
# 0             0x0             uImage header, header size: 64 bytes
# 64            0x40            LZMA compressed data
# 1048576       0x100000        Squashfs filesystem, little endian
# 15728640      0xF00000        JFFS2 filesystem, little endian

Components:

• Bootloader: u-boot, Das U-Boot
• Kernel: Linux kernel (compressed with LZMA/gzip)
• Root Filesystem: SquashFS, JFFS2, CramFS, UBIFS
• Configuration: JFFS2 partition for persistent data

---

Phase 2: Filesystem Extraction (30 minutes - 2 hours)

Step 1: Automatic Extraction

# Extract all filesystem components automatically
binwalk --extract --matryoshka firmware.bin

# --extract (-e): Extract identified components
# --matryoshka (-M): Recursively scan extracted files

# Output directory structure:
# _firmware.bin.extracted/
# ├── 0.lzma              # Compressed kernel
# ├── 100000.squashfs     # Root filesystem
# ├── squashfs-root/      # Extracted root filesystem
# └── jffs2-root/         # Extracted configuration partition

Step 2: Verify Extraction

# Navigate to extracted filesystem
cd _firmware.bin.extracted/squashfs-root/

# Verify critical directories exist
ls -la

# Expected structure:
# drwxr-xr-x  bin/        # Binaries
# drwxr-xr-x  etc/        # Configuration files
# drwxr-xr-x  lib/        # Shared libraries
# drwxr-xr-x  usr/        # User programs
# drwxr-xr-x  www/        # Web interface
# drwxr-xr-x  sbin/       # System binaries

Step 3: Manual Extraction (if automatic fails)

For SquashFS:

# Find SquashFS offset from binwalk
binwalk firmware.bin | grep -i squashfs
# Output: 1048576       0x100000        Squashfs filesystem

# Extract from offset
dd if=firmware.bin bs=1 skip=1048576 of=squashfs.img

# Unsquash manually
unsquashfs -dest ./squashfs-root squashfs.img

# Verify
ls ./squashfs-root/

For JFFS2:

# Install jefferson (JFFS2 extractor)
pip install jefferson

# Extract JFFS2
jefferson jffs2.img --dest ./jffs2-root

# Or use firmware-mod-kit
extract-firmware.sh firmware.bin

For CramFS:

# Install cramfs tools
sudo apt install cramfsprogs

# Mount (requires root)
sudo mount -t cramfs -o loop cramfs.img /mnt/cramfs

# Or extract
cramfsck -x ./cramfs-root cramfs.img

Step 4: Handle Encrypted Firmware

# Check entropy
binwalk --entropy firmware.bin

# If high entropy (encrypted):
# 1. Search for decryption keys in vendor documentation
# 2. Check for known encryption schemes (AES, 3DES, RSA)
# 3. Use firmware-mod-kit or binwalk plugins for known devices

# Example: TP-Link firmware decryption
tplink-safeloader -d firmware.bin -o decrypted.bin

# Example: D-Link firmware decryption
binwalk -e --dd='.*' firmware.bin

---

Phase 3: Service Discovery (1-3 hours)

Step 1: Identify Init System

# Check for init scripts
ls ./squashfs-root/etc/init.d/

# Common init systems:
# - init.d/ scripts (SysVinit)
# - rc.d/ scripts (BSD-style init)
# - systemd/ units (systemd)
# - procd/ configs (OpenWrt procd)

Step 2: Analyze Startup Services

# OpenWrt/procd example
cat ./squashfs-root/etc/rc.d/*

# SysVinit example
cat ./squashfs-root/etc/init.d/rcS

# Example output:
# #!/bin/sh
# /usr/sbin/telnetd -l /bin/sh
# /usr/sbin/httpd -p 80 -h /www
# /usr/sbin/dropbear -p 22

Key Services to Map:

• telnetd: Telnet server (port 23)
• httpd: Web server (port 80/443)
• dropbear/sshd: SSH server (port 22)
• ftpd: FTP server (port 21)
• upnpd: UPnP daemon
• dnsmasq: DNS/DHCP server

Step 3: Find Network Listeners

# Search for network binding code
grep -r "0.0.0.0" ./squashfs-root/etc/
grep -r "bind(" ./squashfs-root/usr/sbin/ 2>/dev/null
grep -r "listen(" ./squashfs-root/usr/sbin/ 2>/dev/null

# Search for port numbers
grep -rE ":[0-9]{2,5}" ./squashfs-root/etc/ | grep -E "(80|443|23|22|21)"

# Example findings:
# ./squashfs-root/etc/config/uhttpd:  option listen_http '0.0.0.0:80'
# ./squashfs-root/etc/config/dropbear: option Port '22'
# ./squashfs-root/etc/inetd.conf:telnet stream tcp nowait root /usr/sbin/telnetd

Step 4: Map CGI Scripts and Web Interface

# Find web root
ls ./squashfs-root/www/
ls ./squashfs-root/usr/www/

# Find CGI scripts (potential injection points)
find ./squashfs-root/www/ -name "*.cgi" -o -name "*.sh"

# Example CGI scripts:
# ./squashfs-root/www/cgi-bin/login.cgi
# ./squashfs-root/www/cgi-bin/admin.cgi
# ./squashfs-root/www/cgi-bin/status.sh

# Analyze for command injection
grep -E "(system|popen|exec)" ./squashfs-root/www/cgi-bin/*.cgi

Output Summary:

Network Services Detected:
- telnetd on 0.0.0.0:23 (CRITICAL: Unauthenticated shell access)
- httpd on 0.0.0.0:80 (Web interface)
- dropbear on 0.0.0.0:22 (SSH with password auth)
- upnpd on 0.0.0.0:1900 (UPnP potential SSRF)

CGI Scripts Found:
- /cgi-bin/admin.cgi (Command injection vulnerable)
- /cgi-bin/login.cgi (Credential check)
- /cgi-bin/upgrade.cgi (Firmware upload)

---

Phase 4: Credential Hunting (30 minutes - 1 hour)

Step 1: Check Shadow and Passwd Files

# Unix password files
cat ./squashfs-root/etc/passwd
cat ./squashfs-root/etc/shadow

# Example vulnerable shadow file:
# root:$1$12345678$abcdefghijklmnopqrstuv:0:0:root:/root:/bin/sh
# admin:admin:0:0:admin:/root:/bin/sh  # CRITICAL: Plaintext password!

Common Issues:

• Empty password hashes (passwordless login)
• Weak/default passwords (admin/admin)
• Hardcoded hashes (crackable)

Step 2: Search Configuration Files

# Search for common password keywords
grep -ri "password" ./squashfs-root/etc/ 2>/dev/null
grep -ri "passwd" ./squashfs-root/etc/ 2>/dev/null
grep -ri "pwd" ./squashfs-root/etc/ 2>/dev/null
grep -ri "secret" ./squashfs-root/etc/ 2>/dev/null

# Example findings:
# ./etc/config/wireless: option key 'default_wifi_password_12345'
# ./etc/shadow: root:5up:0:0:root:/root:/bin/sh
# ./etc/config/system: option admin_password 'admin'

Step 3: Find API Keys and Tokens

# Search for long alphanumeric strings (API keys)
grep -rE "[A-Za-z0-9]{32,}" ./squashfs-root/etc/config/

# Search for common API key patterns
grep -ri "api_key\|token\|secret_key" ./squashfs-root/etc/

# Search for cloud service credentials
grep -ri "aws\|azure\|gcp\|s3" ./squashfs-root/etc/

# Example findings:
# ./etc/cloud-config.json: "api_key": "sk_live_abcdef1234567890"
# ./etc/mqtt.conf: mqtt_token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."

Step 4: Extract SSL Certificates and Private Keys

# Find SSL certificates
find ./squashfs-root/ -name "*.pem" -o -name "*.key" -o -name "*.crt"

# Example findings:
# ./etc/ssl/private/server.key (CRITICAL: Private key embedded)
# ./etc/ssl/certs/ca.crt

# Check for weak/default keys
openssl rsa -in ./etc/ssl/private/server.key -text -noout

# If key is weak (512-bit RSA), flag as critical

Credential Summary:

Hardcoded Credentials Found:
- Root password: "5up" (plaintext in /etc/shadow)
- Admin password: "admin" (default credentials)
- WiFi password: "default_wifi_password_12345" (weak)
- API key: "sk_live_abcdef..." (exposed in /etc/cloud-config.json)
- SSL private key: /etc/ssl/private/server.key (512-bit RSA, weak)

---

Phase 5: Vulnerability Scanning (1-3 hours)

Step 1: Identify Library Versions

# Find shared libraries
ls ./squashfs-root/lib/
ls ./squashfs-root/usr/lib/

# Check library versions
strings ./squashfs-root/lib/libc.so.0 | grep -i version

# Example output:
# OpenSSL 1.0.1e (VULNERABLE: Heartbleed CVE-2014-0160)
# BusyBox v1.24.1 (CHECK: Known CVEs)
# Dropbear 2014.63 (CHECK: Known CVEs)

Step 2: CVE Scanning with MCP

# Use security-manager MCP for automated CVE scanning
/re:firmware router.bin --cve-scan true

Under the Hood:

// Automatically invoked by skill
const cveResults = await mcp__security-manager__scan_vulnerabilities({
  filesystem_root: "./squashfs-root/",
  library_scan: true,
  cve_database: "nvd",  // National Vulnerability Database
  check_versions: true
})

// Example output:
// {
//   "vulnerabilities": [
//     {
//       "cve": "CVE-2014-0160",
//       "severity": "CRITICAL",
//       "component": "OpenSSL 1.0.1e",
//       "description": "Heartbleed vulnerability allows memory disclosure",
//       "cvss": 7.5
//     },
//     {
//       "cve": "CVE-2019-12345",
//       "severity": "HIGH",
//       "component": "httpd CGI handler",
//       "description": "Command injection via admin.cgi parameter",
//       "cvss": 8.8
//     }
//   ]
// }

Step 3: Manual Vulnerability Assessment

Check for Command Injection:

# Analyze CGI scripts for command injection
grep -E "(system|exec|popen|shell_exec)" ./squashfs-root/www/cgi-bin/*.cgi

# Example vulnerable code in admin.cgi:
# system("ping -c 1 " . $QUERY_STRING);  # CRITICAL: Command injection!

Check for SQL Injection:

# Find database queries
grep -rE "(SELECT|INSERT|UPDATE|DELETE)" ./squashfs-root/www/

# Example vulnerable query:
# $query = "SELECT * FROM users WHERE username='" . $_GET['user'] . "'";

Check for Path Traversal:

# Find file operations
grep -rE "(fopen|readfile|include)" ./squashfs-root/www/

# Example vulnerable code:
# readfile("/www/" . $_GET['file']);  # Path traversal: ?file=../etc/shadow

Step 4: Check for Backdoors

# Search for suspicious listening ports
grep -rE "port.*[0-9]{4,5}" ./squashfs-root/etc/

# Search for reverse shell code
grep -rE "(nc.*-e|bash.*>&|/dev/tcp)" ./squashfs-root/

# Search for hidden services
find ./squashfs-root/ -name ".*" -type f

# Check for suspicious cron jobs
cat ./squashfs-root/etc/crontabs/*

Vulnerability Report:

CRITICAL Vulnerabilities:
1. CVE-2014-0160 (Heartbleed) - OpenSSL 1.0.1e
2. Command Injection - admin.cgi (unauthenticated)
3. Hardcoded credentials - root:5up

HIGH Vulnerabilities:
4. Path Traversal - download.cgi
5. Weak SSL certificate - 512-bit RSA key
6. Telnet enabled on 0.0.0.0:23 (no authentication)

MEDIUM Vulnerabilities:
7. Default credentials - admin:admin
8. UPnP enabled (SSRF potential)
9. SQL Injection - login.cgi

---

Phase 6: Binary Analysis (1-2 hours)

After extracting firmware, apply Levels 1-4 to interesting binaries.

Step 1: Identify Target Binaries

# Web server binary
ls ./squashfs-root/usr/sbin/httpd

# Telnet daemon
ls ./squashfs-root/usr/sbin/telnetd

# Custom binaries
find ./squashfs-root/usr/bin/ -type f -executable

Step 2: Apply Level 1 (String Analysis)

# Analyze web server strings
/re:strings ./squashfs-root/usr/sbin/httpd

# Look for:
# - Hardcoded URLs (C2 servers, update servers)
# - Debug messages revealing logic
# - Version strings
# - Hardcoded credentials

Example Output:

Strings Found in httpd:
- "admin:5up" (hardcoded credential)
- "http://firmware-updates.vendor.com/check" (update URL)
- "DEBUG: Command executed: %s" (command injection point)
- "OpenSSL/1.0.1e" (vulnerable version)

Step 3: Apply Level 2 (Static Analysis)

# Disassemble httpd binary
/re:static ./squashfs-root/usr/sbin/httpd --tool ghidra

# Find critical functions:
# - handle_cgi_request()
# - authenticate_user()
# - execute_command()

Decompiled Code Example (Ghidra output):

// Function: handle_admin_cgi
void handle_admin_cgi(char *query_string) {
  char command[256];
  char *cmd_param;

  // VULNERABILITY: No input validation!
  cmd_param = get_param(query_string, "cmd");
  sprintf(command, "sh -c '%s'", cmd_param);
  system(command);  // CRITICAL: Command injection!
}

Step 4: Apply Level 3 (Dynamic Analysis) - Optional

# Emulate binary with QEMU
qemu-mipsel-static ./squashfs-root/usr/sbin/httpd

# Or use full system emulation with firmadyne
firmadyne.sh router-firmware.bin

# Debug with GDB
gdb-multiarch ./squashfs-root/usr/sbin/httpd
(gdb) set architecture mips
(gdb) break handle_admin_cgi
(gdb) run

Step 5: Apply Level 4 (Symbolic Execution) - Advanced

# Use Angr for symbolic analysis
/re:symbolic ./squashfs-root/usr/sbin/httpd \
  --target-addr 0x401234 \  # execute_command function
  --input-symbolic cmd_param \
  --find-exploits true

---

Comprehensive Workflow Examples

Workflow 1: Router Firmware Complete Analysis

Scenario: Analyze TP-Link router firmware for vulnerabilities

Step 1: Extraction (30 min)

# Download firmware
wget http://vendor.com/TL-WR841N-v14-firmware.bin

# Identify and extract
binwalk -E TL-WR841N-v14-firmware.bin  # Check entropy
binwalk -Me TL-WR841N-v14-firmware.bin # Extract

# Navigate to filesystem
cd _TL-WR841N-v14-firmware.bin.extracted/squashfs-root/

Step 2: Service Discovery (1 hr)

# Find init scripts
cat etc/rc.d/S*

# Services found:
# - telnetd on 0.0.0.0:23 (CRITICAL)
# - httpd on 0.0.0.0:80
# - dnsmasq on 0.0.0.0:53

# Map CGI scripts
find www/ -name "*.cgi"

# CGI scripts found:
# - www/cgi-bin/admin.cgi (admin interface)
# - www/cgi-bin/upgrade.cgi (firmware upload)

Step 3: Credential Hunting (15 min)

# Check shadow file
cat etc/shadow
# Output: admin:5up:0:0:admin:/root:/bin/sh

# Check config files
grep -ri "password" etc/config/
# Output: option admin_password 'admin'

# CRITICAL: Default credentials admin:5up

Step 4: CVE Scanning (30 min)

# Check library versions
strings lib/libc.so.0 | grep version
# OpenSSL 1.0.1e (CVE-2014-0160 Heartbleed)

# Automated CVE scan
/re:firmware TL-WR841N-v14-firmware.bin --cve-scan true

# Results:
# - CVE-2014-0160 (CRITICAL): Heartbleed
# - CVE-2019-12345 (HIGH): Command injection in admin.cgi

Step 5: Binary Analysis (1 hr)

# Analyze admin CGI
/re:strings www/cgi-bin/admin.cgi
# Found: "system(sh -c %s)" - command injection

# Static analysis
/re:static www/cgi-bin/admin.cgi --tool ghidra

# Decompiled code shows:
# char *cmd = getenv("QUERY_STRING");
# system(cmd);  # CRITICAL: No sanitization!

Final Report:

TP-Link TL-WR841N Firmware Analysis
====================================

CRITICAL Vulnerabilities:
1. Hardcoded credentials: admin:5up
2. Unauthenticated telnet on port 23
3. Command injection in admin.cgi
4. Heartbleed (CVE-2014-0160) in OpenSSL 1.0.1e

HIGH Vulnerabilities:
5. Weak default WiFi password
6. No CSRF protection on admin interface

Attack Scenario:
1. Telnet to router (no password required)
2. Or exploit command injection: http://router/cgi-bin/admin.cgi?cmd=reboot
3. Gain root shell access

Recommendation: Update to patched firmware version

Time: 3.25 hours total

---

Workflow 2: IoT Camera Firmware Security Audit

Scenario: Audit Wyze camera firmware for cloud API security

Step 1: Extraction (45 min)

# Extract firmware
binwalk --extract --matryoshka wyze-cam-v3-firmware.bin

# Filesystem type: UBIFS (NAND flash filesystem)
# Manual extraction required
jefferson ubifs.img --dest ./wyze-root/

Step 2: Service Discovery (1.5 hrs)

# Find cloud service configuration
grep -ri "api\|cloud\|server" ./wyze-root/etc/

# Found:
# ./etc/cloud-config.json:
# {
#   "api_endpoint": "https://api.wyze.com/v1",
#   "device_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
#   "api_key": "sk_live_abcdef1234567890"
# }

# CRITICAL: Hardcoded API credentials!

Step 3: Analyze Cloud Communication (1 hr)

# Find MQTT broker configuration
cat ./wyze-root/etc/mqtt.conf

# Broker: mqtt.wyze.com:8883
# Username: camera-12345
# Password: hardcoded_mqtt_pass

# Analyze cloud binary
/re:strings ./wyze-root/usr/bin/cloud-agent

# Found:
# - "Bearer eyJhbGci..." (hardcoded auth token)
# - "https://firmware-updates.wyze.com/" (update URL)

**Step 4: CVE Scan (30 min

<!-- Content truncated for initial SEO render. Open the source file tab for the full file. -->