GlossaryHardwareEmbedded

Firmware Extraction

Firmware extraction means getting the code and data out of a device for analysis. The methods from update files to chip-off, what attackers find, and how to make it hard.

Updated October 7, 2026This page as Markdown

In short

Firmware extraction is the process of obtaining the software and configuration stored in an embedded device, for example by downloading an update package, reading flash through a debug interface, dumping a memory chip in-circuit or after desoldering, or exploiting a boot loader. It is the first step of most hardware attacks and of every serious embedded security test, because the extracted image reveals keys, credentials, hidden interfaces and vulnerabilities.

What is firmware extraction?

Firmware extraction is getting a copy of the software that runs on a device. Depending on the device and its protections the route differs:

Update packages from the vendor’s website, the mobile app or captured update traffic. Often unencrypted or only obfuscated; the cheapest route.
Debug interfaces: JTAG, SWD or a vendor port that allows reading flash directly, or a UART boot loader with a memory dump command.
In-circuit reading of an external SPI NOR flash or eMMC with a clip or test points while the main CPU is held in reset.
Chip-off: desoldering the flash or eMMC and reading it in a programmer. Reliable, but needs tooling and a second device if the first does not survive.
Software exploits in the boot loader, the update process or a network service that let you read memory or run a dumper.
Fault injection (voltage or clock glitching) to defeat readout protection on microcontrollers that have it enabled.

The result is a binary image, which is then unpacked and analysed.

Where is it defined?

Firmware extraction is a technique, not a standard, but the requirements that make it hard are. ETSI EN 303 645 provision 5.4 requires that sensitive security parameters are stored securely and that hard-coded critical parameters in device software are not used; 5.6-4 requires debug interfaces to be disabled. The Cyber Resilience Act, Regulation (EU) 2024/2847, requires in Annex I Part I that products protect the confidentiality of stored data and the integrity of software and firmware. NIST SP 800-193 covers firmware protection for platforms. The OWASP IoT Security Testing Guide describes firmware acquisition and analysis as a test phase.

What it means in practice

Almost every hardware penetration test starts with extraction, because the image tells us what the device really does. From power-electronics ECUs with TriCore firmware we have reconstructed the UDS security-access algorithm and found that the “seed and key” was a fixed XOR, which turned the diagnostic interface into an open door. From infotainment units on embedded Linux we have taken root file systems with private keys for the back-end connection and hard-coded Wi-Fi credentials. From ESP32-based communication modules we have dumped MQTT credentials shared by every device of the series.

What protects against this, in increasing order of effort for the attacker: encrypted update packages signed per device, locked debug ports and readout protection burned in production, firmware encryption with keys in a secure element or eFuses, secrets provisioned individually per device so one extracted image does not compromise the fleet, and a design that assumes the firmware is public and keeps security in the keys.

Common misunderstandings

Firmware extraction is not defeated by obscurity: unlabelled chips, removed markings or exotic file systems add hours, not weeks. It is also not something only well-funded attackers do; a flash clip, a programmer and free tooling cost less than the device itself. The useful question is not “can the firmware be extracted” but “what does an attacker gain when it is”, and the answer should be: nothing that works on other devices.

FAQ

Frequently asked questions

Is firmware extraction legal?

On a device you own and for security research or interoperability it is generally allowed in Germany and the EU, subject to the terms of the copyright law on decompilation and to contract terms. In a penetration test the written authorisation of the manufacturer covers it. Zyberum extracts firmware only from devices that are in scope of an authorised engagement. If you plan to extract firmware from a product you do not make, get legal advice first.

Does encryption prevent firmware extraction?

It prevents reading the plain code from a dumped flash chip, if the key is not on the same chip in readable form. Many designs store the key in flash next to the encrypted image or decrypt into external RAM where it can be read. Encryption with the key in a secure element or in locked eFuses, combined with a locked debug port, raises the effort considerably.

What do you do with an extracted image?

Identify the layout (boot loader, kernel, file systems, configuration partitions), unpack it, and look for credentials, private keys, certificates, debug services, update mechanisms and third-party components with known vulnerabilities. For microcontroller images we load them into a disassembler and reverse engineer the parts that handle authentication, diagnostics and updates. The findings feed the rest of the penetration test.

Sources

← Glossary