Firmware analysis

Firmware analysis starts by getting the firmware off the device. If the manufacturer publishes an update image, that is the easy route; otherwise it is extracted from the hardware through a debug interface such as UART or JTAG, by reading the flash chip directly, or in the hardest case by removing the chip. Once obtained, the image is unpacked: identifying the format, carving out the filesystem, and recovering the individual files. From there the analysis reads what the device actually contains: the code that runs, the configuration, the certificates and keys, and the way the device talks to the network and to any cloud service. It is a bottom-up view of a device that a black-box test of its network interface would never reach.

Embedded devices are built to a cost and a deadline, and firmware analysis exposes the shortcuts. The findings that recur are hard-coded credentials and keys sitting in the filesystem in the clear (a secrets management failure that ships in every unit), debug interfaces left enabled in production, and services that take input from the network and pass it to a shell, which is command injection on a device that cannot easily be patched. From an attacker’s side, one extracted image reveals the same weakness across every device of that model, so the effort of analysis pays off against the whole fleet, not one unit. The device’s isolation is only skin deep once the firmware is in hand.

We test a device from the firmware up: how the image is obtained, what it exposes (secrets, debug interfaces, vulnerable services), and whether the device verifies the integrity of what it runs through secure boot. Findings are written against the specific weakness in the firmware, with the impact demonstrated, and severity reflects that a firmware flaw usually affects every device of the model. Hardware-level extraction connects to the side-channel work where relevant. This is part of how we test a device from its firmware up.