Hardware Penetration Test: How It Works, Step by Step

A hardware penetration test asks one question: what can an attacker with the device on the bench do, and what does that mean for all the other devices in the field? The answer comes from a fixed sequence of steps, from opening the case to a report with fixes. This is how a hardware pentest runs at Zyberum, with the typical findings at each stage.

Step 0: Scope and what we need from you

The test starts with a scoping call and a written authorisation. We agree the target (the whole device, one board, one controller), the goals (firmware extraction, key recovery, secure boot bypass, local root), the depth (black box or with documents) and which units may be destroyed.

What we ask for	Why
Two to three units, ideally production hardware	Reference, probing, destructive steps
Schematics or at least a block diagram (grey box)	Find test points and buses faster
Firmware image and update package, if available	Compare dump with build, test the update path
Access to a test account in the backend or app	Judge what a compromised device can reach
Contact for questions during the test	Avoid guessing about intended behaviour

A hardware test typically runs five to fifteen days, depending on how many protection layers the device has and how deep the firmware analysis goes.

Step 1: Teardown and component identification

The first day is spent with a screwdriver, a camera and datasheets. We open the device, photograph every board, read the markings on every chip and look up what they are: the main SoC or microcontroller, external flash (SPI NOR, NAND, eMMC), RAM, radio modules, power management, any security element. From that we draw a picture of where code and secrets can live and which buses connect them.

Typical finding at this stage: a populated but unlabelled pin header near the main controller. In most consumer and industrial devices we see, it is a debug port.

Step 2: Debug and serial interfaces

Next we find and test every interface that was meant for the factory or the developer: UART, JTAG, SWD, sometimes a vendor bootloader mode on USB.

• UART. A logic analyser identifies the pins and the baud rate. The boot log alone tells us the bootloader, the kernel version and often the partition layout. A shell without a password or with a default password is still one of the most frequent findings in our tests. On an appliance from a household manufacturer the serial console gave root before the device had finished booting.
• JTAG and SWD. With the pinout from the datasheet or a pin finder we try to connect a debug probe. If the port is open we can halt the CPU, read RAM and flash and write our own code. The check here is whether the lock bits, eFuses or debug authentication are actually set in production units, not only described in the design document.
• Bootloader modes. Many controllers have a ROM bootloader on UART or USB (ESP32 download mode, bootstrap loaders on TriCore/AURIX, DFU on STM32). If it is reachable and unprotected, the chain of trust can be bypassed before it starts.

Step 3: Firmware extraction

If no debug port gives us the firmware, we take it from the memory itself. In order of effort: read the external SPI flash in circuit with a clip, desolder the chip and read it in a programmer, read eMMC through its test points or after chip-off, or pull the image through a vulnerable update mechanism. Where flash encryption is on, the test becomes whether the key is protected or sits in a readable eFuse, and whether the decrypted image can be reached in RAM through a debug port.

For ECUs the same logic applies, with different tools: on power-electronics ECUs with TriCore/AURIX controllers we have read the application flash through the debug interface because the read-out protection had not been enabled, and the reverse engineering of the firmware then explained every UDS service the ECU exposed.

Step 4: Firmware analysis

With the image on disk the work moves to the computer. We unpack file systems, identify the operating system and libraries, extract certificates, keys and credentials, and reverse engineer the parts that matter: the update verification, the authentication of the local and the cloud interface, the handling of radio frames. Secrets found here are checked for what they open: a shared API key means every device in the field, a per-device key means one device.

Common findings: a private key for the cloud connection that is the same in every unit, hard-coded credentials for a maintenance interface, an update signature check that compares a hash but no signature, outdated libraries with known CVEs.

Step 5: Protection mechanisms

Now we test the mechanisms that were supposed to stop steps 2 to 4: secure boot, flash encryption, eFuse configuration, anti-rollback, debug authentication. The question is not whether they exist but whether they are enabled and complete on the production unit. The most frequent gap is a secure boot chain that verifies the bootloader and the kernel but not the root file system, or an eFuse that was planned but never burned on the production line. For high-value targets we add fault injection (voltage glitching) to see whether a single comparison in the boot ROM or the bootloader can be skipped.

Step 6: Exploit chains and impact

Single findings are turned into chains that show the real impact: open UART plus unencrypted flash equals the cloud key for the whole fleet; open SWD plus a shared key equals the ability to impersonate any device. Where the device talks to a backend or app we test what a compromised device can do there, within the authorised scope. This is where a hardware test connects to the IoT or ECU pentest.

Step 7: Report and retest

The report lists every finding with CVSS score and vector, the steps to reproduce, photos and pinouts, and a fix that fits the hardware you have: which eFuses to burn, how to disable the console in the production image, how to move from a shared key to per-device keys, what to change in the update verification. Findings that need a hardware revision are marked as such, because they decide the roadmap. After the fixes we retest the affected findings on new units.

What a hardware test does not do

It does not certify anything. It gives you evidence of what an attacker with physical access achieves and what to change, which is also the evidence that EN 18031, the Cyber Resilience Act and the OWASP ISTG expect for debug interfaces and software integrity. Zyberum issues no certificates and never tests without written authorisation.

More about scope and prices on the hardware pentest page, or book a free 15-minute call.