Firmware Extraction: Verified Binary Off a Locked Board

What Firmware Extraction Actually Means

Every embedded board runs code. That code lives inside a microcontroller’s on-chip flash, an external SPI NOR, a parallel NAND, or sometimes an EEPROM that holds calibration data alongside a small bootloader. Firmware extraction is the act of reading that code out—byte for byte—so you can archive it, analyse it, or program it into a replacement chip on a cloned or redesigned board.

The phrase sounds straightforward, but in practice the difficulty ranges from trivial (an unlocked external SPI flash you can clip onto) to borderline impossible (a modern secure-boot MCU with encrypted storage and anti-tamper fuses). Understanding where your target sits on that spectrum is the first decision that matters.

Why You Need the Firmware in the First Place

Firmware extraction is not an academic exercise. It comes up in real engineering scenarios every week:

• End-of-life spare production. The OEM no longer sells the board, but your factory line still depends on it. A board-level duplication service can reproduce the PCB, but without the firmware the clone is a paperweight.
• Failure analysis. A field-returned board works electrically but behaves wrong. Comparing the flash contents against a known-good image can reveal corruption, partial erase, or a misflashed revision.
• Regulatory archiving. Medical, aerospace, and nuclear equipment often require a retrievable copy of every firmware revision deployed in the field.
• Board redesign. When you pursue a PCB redesign that modernises the board without losing its behaviour, the legacy firmware is the behavioural specification. Without it, you are guessing.

Protection Mechanisms You Will Encounter

Before choosing an extraction method, you need to identify what stands in the way. Protection comes in layers, and most locked boards use more than one.

Read-Out Protection (RDP / CRP / Code Protection Fuses)

Nearly every ARM Cortex-M MCU (STM32, LPC, NXP Kinetis, etc.) ships with a configurable read-out protection level. At Level 1, JTAG/SWD read is blocked but the chip can still be unlocked—at the cost of a mass erase. At Level 2, the debug port is permanently disabled. Similar mechanisms exist in PIC, AVR, and Renesas parts under names like Code Read Protection or Security Fuse.

Secure Boot and Encrypted Flash

Higher-end parts—NXP i.MX RT, STM32H7, TI Sitara with OP-TEE—encrypt the flash contents with a device-unique key stored in OTP fuses. Even if you read every byte, you get ciphertext. Extraction here means either obtaining the key (extremely difficult) or finding a side-channel that leaks plaintext.

Anti-Tamper and Glitch Detection

Some automotive and payment-grade MCUs monitor supply voltage, clock frequency, and even light exposure on the die surface. Triggering any of these can zeroize the key material before you get a single byte out.

External Flash with Encrypted XIP

Boards that execute in place from an external QSPI flash may still encrypt the bus. Reading the flash chip directly gives you encrypted data unless you also recover the key from the MCU’s OTP.

Understanding these layers is essential. A thorough pre-assessment to check whether recovery is realistic saves weeks of wasted effort.

Firmware Extraction Methods: From Least to Most Invasive

1. Debug Port Read-Out (JTAG / SWD / cJTAG)

If the debug port is still open—or locked only at Level 1 where a voltage-glitch or laser-fault attack can temporarily bypass the lock—this is the cleanest path. You connect a debug probe (J-Link, ST-Link, CMSIS-DAP), halt the core, and dump flash memory through the AHB bus.

2. Bootloader / UART / USB DFU Extraction

Many MCUs have a factory ROM bootloader that can read flash if protection is not set, or a custom bootloader the OEM left accessible. STM32’s system bootloader, for example, supports a “Read Memory” command—unless RDP is active. NXP LPC parts expose ISP over UART. If the OEM’s own bootloader has a “dump” command (surprisingly common in industrial equipment), you may be able to extract firmware with nothing more than a serial cable.

3. External Flash Chip-Off or In-Circuit Read

When firmware lives on an external SPI NOR, NAND, or EEPROM, you can often read it without touching the MCU at all. Two sub-methods exist:

• In-circuit read: A test clip (SOIC-8, WSON-8) connects to the flash while it is still soldered. You must hold the MCU in reset or cut its chip-select line to avoid bus contention.
• Chip-off read: Desolder the flash, place it in a socket programmer (Xeltek, Elnec, TNM), and read it directly. This is the gold standard for EEPROM and flash data recovery.

If the data is unencrypted, you get a perfect image. If the MCU encrypts the bus, you get ciphertext—useful only if you can also recover the key.

4. Glitch Attacks (Voltage Fault Injection)

A precisely timed voltage dip on the MCU’s VCC during the boot-up protection check can cause the security logic to skip the “lock” decision, leaving the debug port open for a fraction of a second—long enough to dump flash. Tools like the ChipWhisperer or NewAE’s Husky automate this.

This works on a surprising number of older Cortex-M0/M3 parts and some PIC families. It does not work on parts with redundant security checks or hardware-enforced RDP Level 2. The IC crack service approach often includes voltage glitching as one of several techniques attempted during an engagement.

5. Laser Fault Injection

A focused infrared laser aimed at the security fuse latch or the boot ROM comparison logic can flip a single bit at the right moment. This requires removing the chip package to expose the die, a near-infrared laser station, and detailed knowledge of the die layout. It is expensive, slow, and reserved for high-value targets—but it can defeat protections that voltage glitching cannot.

6. Microprobing and ROM Extraction

The most invasive method: decapsulate the chip, image the die layers under a microscope, and either microprobe the internal bus during execution or visually read the ROM contents from the mask pattern. This is how security researchers defeat smartcard-grade protection—and it is priced accordingly. Understanding why unlock pricing differs so dramatically between chips often comes down to whether microprobing is required.

Choosing the Right Method: A Decision Framework

The table below maps common scenarios to the most practical extraction path.

Verifying the Extracted Binary

Getting bytes out of a chip is only half the job. You must confirm those bytes are correct before you trust them in a production clone.

CRC and Checksum Comparison

Many firmware images embed a CRC-32 or simple checksum in the last sector. After extraction, compute the checksum over the image and compare it to the stored value. A mismatch means corruption—re-read or try a different extraction path.

Multiple Independent Reads

Read the chip at least twice, ideally with different tools or probe setups. A bitwise diff between the two images should be zero. If it is not, the extraction method is unreliable for that part.

Disassembly Sanity Check

Load the binary into Ghidra or IDA at the correct base address. The reset vector should point to valid code. Interrupt vectors should be within the flash address range. String references should produce readable ASCII. If the disassembly is gibberish, you may have the wrong endianness, the wrong base address, or encrypted data.

Functional Test on a Golden Board

The ultimate verification: program the extracted binary into a known-good replacement chip, solder it onto a test board, and run the full functional test suite comparing against a golden sample. If every I/O, timing, and communication bus behaves identically, the firmware is verified.

Firmware Extraction in a Broader Board Recovery Workflow

Firmware extraction rarely happens in isolation. It is one step in a larger process that typically looks like this:

1. Board-level reverse engineering. The physical PCB is scanned, delayered if multilayer, and a schematic plus Gerber set is reconstructed. Understanding PCB reverse engineering workflows helps you plan the firmware step correctly.
2. Component identification and sourcing. Every IC is catalogued. Protected MCUs are flagged for firmware extraction.
3. Firmware extraction. Each programmable device is read out using the least invasive method that works.
4. Programming and assembly. New boards are populated, programmed with the verified binary, and tested.
5. Functional validation. The rebuilt board is compared against the original in a real system.

For industries like semiconductor equipment manufacturing, where a single board failure can idle a multi-million-dollar fab tool, this workflow is not optional—it is the standard approach to board reverse engineering for fab tool spares.

Common Mistakes That Corrupt or Destroy Firmware

• Powering the board during in-circuit read without holding the MCU in reset. The MCU wakes up, drives the SPI bus, and the programmer reads garbage.
• Using the wrong voltage for a chip-off read. A 1.8 V flash read at 3.3 V can latch up and destroy the die.
• Triggering a mass-erase by accident. On some STM32 parts, connecting a debugger while RDP Level 1 is set and then issuing a connect-under-reset command will erase the entire flash before you can read a single byte.
• Ignoring OTP and configuration bytes. The main flash image is useless without the option bytes, fuse settings, or EEPROM calibration data that accompany it.
• Reading only the first bank. Dual-bank MCUs (STM32H7, some Renesas RX) store code across two flash banks. Missing the second bank means missing half the firmware.

Legal and Ethical Boundaries

Firmware extraction for the purpose of producing spare boards for equipment you own or operate is generally lawful under maintenance and interoperability exceptions in most jurisdictions. However, redistributing extracted firmware, circumventing DRM for commercial piracy, or violating a license agreement crosses legal lines. Always document your purpose, retain proof of ownership of the original equipment, and consult legal counsel if the firmware contains third-party licensed code.

When to Outsource Firmware Extraction

If you have an unlocked external flash and a $30 programmer, you can handle extraction yourself. But the moment you face read-out protection, encrypted storage, or a chip family you have never worked with, the risk of destroying the only copy of the firmware is real. Professional IC unlock services for protected microcontrollers maintain the equipment, the fault-injection rigs, and the chip-family experience to maximise the chance of a clean read on the first attempt.

A verified firmware binary is only as good as the extraction method and the verification that follows. Skip either, and you are building production boards on a guess.

Related reading

• Oct 2026Rohm IC Unlock | Which Families We Can Read
• Oct 2026Maxim IC Unlock | Families We Can Read & Recover
• Oct 2026Dialog IC Unlock | Families We Can Read & Recover