IoT & Hardware Hacking

An IoT product has four stacked surfaces. The hardware is the board, its chips and debug pads such as UART, JTAG and SPI. The firmware is the code stored in the flash chip, often holding secrets. The radio is how the device talks wirelessly over Wi-Fi, BLE, Zigbee or raw RF. The companion is the mobile app, local web panel and vendor cloud. Skilled researchers move between all four.

Begin with triage on a Linux box. Run file to see what the image is, binwalk to map embedded sections such as a kernel and a Squashfs filesystem, and binwalk -e to extract them. Then search the image with strings for plain-text passwords, URLs and keys. This needs no soldering and often reveals hardcoded credentials, which is why it is the usual first step.

You can start modestly. Three core tools do most early work: a USB-to-serial adapter for talking to UART interfaces, a logic analyser for decoding pin signals, and a multimeter for finding voltage, ground and continuity. A flash-reader clip that reads memory chips in place and open-source software for serial terminals and firmware analysis round out a capable starter kit.

You may open, probe and modify hardware you own outright, or that you have explicit written permission to test. Owning the device does not extend to attacking the vendor's cloud, the companion app's backend, or other users, which are separate targets needing separate authorisation. Buy inexpensive devices specifically to practise on and never touch someone else's hardware.

Most small IoT boards operate at 3.3 volts, and applying a 5 volt signal to a 3.3 volt pin can permanently destroy the chip. Using a multimeter to confirm voltage and ground, and never supplying power to a pin you have not identified, prevents you from killing the board with a wrong guess. A few minutes of measuring saves hardware.

An embedded flash image is usually split into partitions laid end to end: a bootloader such as U-Boot that starts the kernel, the kernel itself (often with a uImage header binwalk recognises), a root filesystem that is commonly a compressed Squashfs, and a config or NVRAM partition for per-device settings. The root filesystem is the prize, since extracting it exposes the device's /etc, startup scripts and web server files.