Board analysis
Identify components, test points and debug headers, and trace what connects to what.
Hardware & embedded pentest
We open the case. Then the firmware.
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.
- JTAG, SWD, UART
- Firmware extraction and reverse engineering
- Secure boot analysis
In short
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.
What we do
From the board to a root shell
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.
Why it matters
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.
Case studies
What we found on real devices
IoTAPI security
Case Study: Root on a Robot Vacuum, and Other People’s Cameras
Full root access on the device, and access to the live WebRTC camera of other users through the cloud API.
We tested a camera-equipped robot vacuum: root access on the device, and cloud API flaws that opened the live camera of other users. What went wrong and why.
Read the case studyIoTMQTT
Case Study: A Smart Irrigation System Anyone Could Control
We could see and activate other customers’ devices through MQTT, and geolocate where they are installed.
We tested a smart irrigation system: a broken MQTT setup let us see and switch the devices of other customers, and locate where they are installed.
Read the case studyFAQ
Hardware pentest 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.
Get started
Get your hardware pentest scoped in 15 minutes
Tell us about the device, its processor and its interfaces. You get a fixed-price offer after the call.
- Scope by interfaces and attack depth
- Fixed-price offer after the call
- Two or three sample devices are all we need
Your call is withTom ZaubermannFounder & CEO, Zyberum
Or send us a message
We reply within one business day.