# Firmware Extraction: What It Reveals and How to Prevent It

Why firmware extraction matters in IoT and ECU pentests, which protections actually stop it (eFuses, flash encryption, secure boot), and how to close the gaps.

Source: https://zyberum.com/insights/firmware-extraction-guide · Updated: 2026-10-07

The first question in almost every hardware pentest is whether the firmware can be obtained. Once a tester has the firmware image, the code can be read, hard-coded keys and hidden commands surface, and the rest of the assessment moves from the bench to the desk. This guide explains the routes that exist, roughly in the order a tester tries them, and what a manufacturer has to do to close each one.

## Why it matters

Firmware is where the secrets live: Wi-Fi credentials, MQTT passwords, cloud API keys, signing keys, debug accounts. In IoT tests of ESP32-based communication modules we have repeatedly found broker credentials shared across an entire fleet. A single recovered image then exposes every device in the field. The Cyber Resilience Act makes this the manufacturer's problem: Annex I, Part I requires protection of stored data and of the integrity of the product, so an unprotected flash chip is a compliance finding as much as a technical one.

## The routes, and what stops them

We work from the cheapest route to the most invasive, and stop as soon as one works.

**The device hands it over.** Often the firmware is where the vendor put it on purpose: an update file on the download page, the image inside the companion app, or the URL the device fetches for an over-the-air update. If that update is served without a signature, the same path lets an attacker load modified firmware. The fix is signed, encrypted update packages and a server that never serves a plain image.

**A debug console is open.** A serial console (UART) that drops to a shell, or a bootloader that accepts commands, is still the most common way in. The fix is to disable the console in production or lock it behind authentication, and to strip bootloader commands that dump memory.

**On-chip debug is live.** JTAG and SWD give direct access to memory and the CPU. On many chips these ports stay enabled in shipped products. The fix is to blow the relevant eFuse to disable the debug interface before the device leaves the factory.

**The flash is read directly.** When the ports are closed, a tester can still read the external flash chip itself. The only real defence here is flash encryption tied to a key held inside the chip, so a dumped image is useless on its own.

## What actually holds

Three protections, set together, make extraction genuinely hard:

| Protection | What it does | Common mistake |
|---|---|---|
| eFuse-disabled debug | Turns off JTAG, SWD and the serial console in the field | Left enabled "for service", or only on some units |
| Flash encryption | Makes a dumped image unreadable without the on-chip key | Key readable, or development mode left on |
| Secure boot | Stops modified firmware from running | Signature check present but not enforced |

On the ESP32 family, for example, this means enabling flash encryption in release (not development) mode and enabling Secure Boot V2, then verifying the eFuses are actually burned. We see each of these skipped often enough that we check them one by one.

## What we see in practice

The pattern across appliance and IoT projects is consistent. Debug ports are left open "for the service team". Flash encryption is enabled in development mode, which leaves the key recoverable. Secure boot is configured but the check is never enforced, so unsigned firmware still runs. Each of these turns a days-long effort into a minutes-long one. In household and medical appliance work we have helped manufacturers close exactly these gaps with eFuse hardening and a locked-down production image, so the same device that gave up its firmware in the first round held in the retest.

## What a manufacturer should do

- **Decide what the firmware is worth.** If it holds fleet-wide credentials or signing keys, treat extraction as a real threat and budget for all three protections.
- **Harden the production image, not the dev board.** The settings that matter (burned eFuses, release-mode encryption, enforced secure boot) are the ones that differ between your bench unit and the shipped product.
- **Rotate secrets and scope them per device.** Even perfect hardware protection fails the day one image leaks, so no secret should be shared across the fleet.
- **Have it tested.** A hardware pentest tells you how far a motivated attacker gets, and gives you the evidence the CRA expects.

Zyberum tests IoT devices, modules and ECUs on the bench, always under written authorisation, and never issues certificates or type approvals. See our [hardware pentest](/hardware-pentest) service, or book a [free call](/contact?meeting=intro).

## FAQ

**Is firmware extraction part of a normal pentest?**

Yes, for hardware and IoT tests it is a standard step. We assess it only on devices the client owns and has authorised us in writing to test. Extracting firmware from a device you do not own, or defeating protection on someone else's product without authorisation, can be a criminal offence in Germany under sections 202a and 202c of the Criminal Code.

**How long does this part of a test take?**

Anywhere from an hour to several days. A device with an open debug console gives up its firmware quickly. A device with disabled debug ports, encrypted flash and secure boot can take days or prove impractical within the budget, which is itself a useful result that shows the defences hold.

**Does encrypted flash mean the firmware is safe?**

Not by itself. Encryption protects the image at rest. If the key is readable, if the device decrypts and exposes the content over a debug port, or if the update server hands out plain images, the encryption does not help. We check all three.

## Sources

- [Espressif: ESP32 Flash Encryption (ESP-IDF Programming Guide)](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/security/flash-encryption.html)
- [Espressif: ESP32 Secure Boot V2 (ESP-IDF Programming Guide)](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/security/secure-boot-v2.html)
- [OWASP Firmware Security Testing Methodology (FSTM)](https://github.com/scriptingxss/owasp-fstm)
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Annex I](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)

## Related

- [Firmware Extraction](https://zyberum.com/glossary/firmware-extraction)
- [Debug Interfaces (JTAG, SWD, UART)](https://zyberum.com/glossary/debug-interfaces-jtag-uart)
- [Secure Boot](https://zyberum.com/glossary/secure-boot)
- [Hardware Penetration Test: How It Works, Step by Step](https://zyberum.com/insights/hardware-pentest-process)
- [Secure Boot: Eight Mistakes We Keep Finding in Devices](https://zyberum.com/insights/secure-boot-common-mistakes)
- [We open the case. Then the firmware.](https://zyberum.com/hardware-pentest)

---
Zyberum GmbH. Canonical page: https://zyberum.com/insights/firmware-extraction-guide