Module 2 · IoT Device Security Testing 🔒

IoT device security testing combines firmware analysis, hardware interfacing, network protocol testing, and mobile companion app review. Many findings come from the firmware — default passwords, hardcoded keys, unsafe update mechanisms, debug ports left enabled. This module covers a practical IoT testing workflow with the tools that matter.

Scoping an IoT engagement

Before testing, agree:

• Which device(s) — model, firmware version, lab samples available?
• Which protocols and cloud APIs are in scope?
• Is hardware tampering allowed (case opening, JTAG/UART access)?
• Mobile companion apps in scope?
• Customer cloud account in scope?
• Constraints — production cloud account vs sandbox; live vs test devices

The testing surface

1. Hardware — debug ports (UART, JTAG, SWD), exposed flash chips, secure boot
2. Firmware — binary extracted from flash or downloaded; analyzed for credentials, vulnerable services
3. Network protocols — what the device speaks (Wi-Fi, BLE, Zigbee, Z-Wave, LoRa, cellular)
4. Cloud APIs — REST endpoints the device + app communicate with
5. Mobile companion app — full mobile pentest scope (covered in Mobile track)
6. Web management interface — if device serves a web UI

Hardware reconnaissance

Open the device. Map the board:

• Identify SoC (System on Chip) — manufacturer, model. Datasheet reveals capabilities
• Identify flash chips — usually SPI; can be read with a clip and a SPI programmer (CH341A, FlashCat)
• Look for unpopulated headers — UART (3-4 pins), JTAG (10-20 pins), SWD (4-5 pins)
• Check for test points — sometimes the same as headers, harder to interface

UART access

# Identify UART pins (TX, RX, GND) with multimeter
# (TX is the pin with periodic activity at boot; RX is silent)

# Connect USB-UART adapter at 3.3V
# Common baud rates: 115200, 57600, 38400, 9600
screen /dev/ttyUSB0 115200
# Or: minicom, picocom

# Many devices drop into a U-Boot shell or root shell
# Default credentials sometimes printed on the bootlog itself

JTAG / SWD

If UART is locked or not present, JTAG/SWD provide debug-level access to the CPU. Tools: SEGGER J-Link, Bus Pirate, OpenOCD. Can dump RAM and ROM, set breakpoints, manipulate registers. Slower setup but more powerful than UART.

flashrom -p ch341a_spi -r firmware.bin
# Or with chip removed: socket reader + programmer

binwalk -e firmware.bin           # extract embedded filesystems
ls _firmware.bin.extracted/        # explore

# Common: SquashFS root filesystem
cd squashfs-root/
grep -ri "password\|api_key\|secret" etc/ usr/
strings bin/httpd | grep -iE "pass|user|admin"
cat etc/passwd                     # shadow with weak hashes
file usr/sbin/dropbear             # SSH server, often unpatched