# We open the case. Then the firmware.

> A hardware penetration test attacks an embedded device physically: debug interfaces such as UART, JTAG and SWD, memory chips, the boot process and the firmware itself. The goals are to extract firmware and secrets, bypass secure boot, gain code execution and find flaws that affect every device of the same type. Zyberum performs hardware pentests in its own lab for IoT products, automotive ECUs and industrial components.

Hardware pentests for embedded devices: debug interfaces, firmware extraction, secure boot, fault injection and firmware reverse engineering in our lab.

Source: https://zyberum.com/hardware-pentest

Test points, debug ports, flash chips and boot loaders: everything an attacker with a screwdriver and a weekend will look at. We do it in our lab, with the same tools and more patience.

## From the board to a root shell

### Board analysis

Identify components, test points and debug headers, and trace what connects to what.

### Debug interfaces

UART consoles, JTAG and SWD: locked, unlocked, or only believed to be locked.

### Firmware extraction

Through the debug port, the update file or directly from the flash chip.

### Secure boot & keys

Does every stage verify the next one? Where are the keys, and who can read them?

### Fault injection

Voltage and clock glitching to skip checks that software alone cannot bypass.

### Reverse engineering

Firmware analysis in Ghidra: secrets, update logic, hidden commands and memory bugs.

## One opened device can expose the whole fleet

Hardware attacks need physical access, which sounds reassuring. It is not: an attacker buys one device, extracts the firmware, finds the shared key or the hidden service, and then uses that knowledge against every device in the field, remotely.

That is why regulations now ask for it. The Cyber Resilience Act, the RED cybersecurity requirements (EN 18031) and IEC 62443-4-2 all expect closed debug interfaces, protected secrets and secure updates.

**Related**

- Complete IoT product tests including app and cloud
- ECU testing for automotive
- Secure development and secure boot design
- CRA and EN 18031 evidence

## What we found on real devices

## FAQ

**How many devices do you need?**

Two or three. Hardware attacks can destroy a device, for example when we remove a flash chip.

**Do you also test the app and cloud?**

Yes, as a complete IoT product test. Many of the worst findings come from combining a hardware finding with a cloud weakness.

**Can you test locked microcontrollers?**

Often yes. Read-out protection can sometimes be bypassed by fault injection or known weaknesses of the chip. We tell you in the scoping call what is realistic for your device.

---
Zyberum GmbH. Canonical page: https://zyberum.com/hardware-pentest