Firmware Recovery Explained | Locked Chip to Working Code

What Is Firmware Recovery and Why Does It Matter?

Firmware recovery is the process of reading executable code (the binary or hex image) out of a microcontroller or programmable IC when the original source files are lost, corrupted, or otherwise unavailable. It matters because a board without its firmware is just inert copper and silicon — the code is what makes the hardware function. When a product’s original developer disappears, a sole-source MCU goes end-of-life, or a production programmer fails mid-run, firmware recovery is often the only path back to a working system.

This article walks through the five primary recovery methods, the chip-level security mechanisms that make extraction difficult, realistic success-rate factors, and the authorization framework that keeps the process legal and ethical. If you need a practical overview of firmware recovery explained in engineering terms — no marketing gloss — read on.

How Chip Security Blocks Firmware Readout

Before discussing recovery methods, you need to understand what you’re working against. Modern MCUs ship with layered protections designed to prevent exactly the kind of read access recovery requires. Our engineers encounter these mechanisms daily, and each one changes the difficulty calculus.

Common Protection Mechanisms

For a deeper dive into fuses, lock bits, and encryption layers, see our guide on chip security mechanisms including fuses, lock bits, and encryption. Understanding the protection level on your specific part is the single most important variable in predicting whether recovery will succeed.

Five Methods Engineers Use for Firmware Recovery

There is no single universal technique. The method depends on the MCU family, the protection level, the condition of the chip, and the tools available. Here are the five approaches our lab evaluates for every incoming job, ranked roughly from least to most invasive.

1. Standard Debug-Port Readout

If the chip’s JTAG, SWD, or ICSP port was never locked — or if the protection was set to a lower level that still permits partial read — a standard programmer or debug probe can dump the flash contents in minutes. This is the fastest path: connect, authenticate (if needed), read, verify checksum. Success rate on unprotected parts: effectively 100%.

Limitation: On any production board where the developer followed basic security practices, this port is disabled or locked. We see unlocked parts on roughly 15–20% of boards that come through the lab — mostly older designs or prototypes.

2. Bootloader-Level Extraction

Many MCU families have a factory ROM bootloader (UART, I²C, USB-DFU) that can read flash under certain conditions. For example, STM32 parts at RDP Level 0 allow full readout via the system bootloader. Some chips at intermediate protection levels allow write but not read — which is useless for recovery but occasionally exploitable through known protocol-level vulnerabilities that have been publicly documented by the vendor or security researchers.

Limitation: Bootloader extraction fails on any part with full read protection enabled. It also requires the BOOT0/BOOT1 pins to be accessible, which means desoldering or probing the package.

3. Voltage Glitching and Fault Injection

This technique introduces precisely timed power-supply glitches (typically 3–50 ns pulses) during the chip’s boot sequence to cause the security-check routine to skip or misexecute. When it works, the chip boots into an unlocked state and the debug port becomes readable. Our lab uses sub-nanosecond glitch generators with automated parameter sweeps — a single successful glitch can take anywhere from 2 hours to 3 days of automated cycling.

Limitation: Newer chips with brown-out detectors, voltage monitors, and glitch filters resist this approach. Success depends heavily on the specific silicon revision. We estimate a 40–65% success rate on mid-range Cortex-M0/M3 parts without active glitch detection, dropping below 10% on parts with dedicated countermeasures.

4. UV or Laser Fault Injection

Focused UV light or a near-infrared laser aimed at specific transistors in the security-fuse latch can flip the protection state. This requires decapping the IC (removing the epoxy package with fuming nitric acid or a CNC decapper) and then using a precision optical bench to target the fuse area. The chip must survive decapping intact — ball-grid packages and multi-die modules are particularly risky.

Limitation: Destructive to the package. The die must be mapped first, which adds 1–3 days. Some vendors (notably Microchip’s newer PIC32MZ and dsPIC33C families) have moved security fuses to buried metal layers that are physically unreachable by UV. For parts where this applies, see our notes on reading fuse-locked chips through security fuse recovery.

5. Micro-Probing and FIB Editing

The most invasive approach: after decapping, a focused ion beam (FIB) workstation cuts or deposits metal traces on the die to bypass security logic, or micro-probes directly tap internal bus lines during execution. This is the method of last resort — FIB time costs $300–$800/hour, and the total job can run 40–120 hours depending on the node geometry.

Limitation: Not economically viable for most commercial recovery jobs. Practical only when the firmware’s value (production continuity, safety-critical system) justifies five-figure costs. Feature sizes below 90 nm make reliable probing increasingly difficult.

What Determines Whether Firmware Recovery Will Succeed?

When customers ask “can you recover my firmware?” the honest answer is always “it depends.” Here are the variables our engineers evaluate during a feasibility assessment:

• MCU family and exact part number — The specific silicon revision matters. An STM32F103C8T6 with RDP Level 1 is a very different job than an STM32H753 with RDP Level 2.
• Protection level actually set — Many developers enable only the first protection tier. We can often determine the active level before committing to a method.
• Physical condition of the chip — Corrosion, cracked dies, heat damage from rework, or missing bond wires all reduce the odds. A clean, working board is ideal.
• Number of samples available — Invasive methods (decapping, glitching) carry a risk of destroying the chip. Having 2–3 samples dramatically improves overall success probability.
• Firmware size and verification method — A 32 KB image on a Cortex-M0 is straightforward to verify via CRC. A 2 MB image with external QSPI flash dependencies requires functional testing on the target board.

We provide a written feasibility report before any invasive work begins. If recovery is not realistic for your part, we say so — and we do not charge for the assessment if we decline the job. You can discuss feasibility with our engineering team before shipping anything.

The Authorized Recovery Process: Step by Step

Firmware recovery touches intellectual property, so authorization and chain-of-custody matter. Here is how a typical engagement moves from inquiry to deliverable.

1. Inquiry and documentation: You provide the board or chip, the MCU part number (if known), and proof of ownership or authorization — a purchase order, design history, or a signed declaration that you hold rights to the firmware.
2. Feasibility assessment (1–3 days): Our engineers identify the chip, determine the protection level, and select candidate methods. You receive a written report with estimated success probability, timeline, and cost range.
3. NDA and authorization agreement: Both parties sign. All work occurs under NDA, and the recovered binary is delivered only to the authorized party.
4. Extraction (3–15 working days): Actual recovery time depends on the method. Debug-port reads take hours; glitching campaigns may run for days. For a detailed breakdown, see our turnaround time from receipt to deliverables.
5. Verification: The recovered hex/bin is programmed onto a blank chip and tested on the original board (or an identical unit) to confirm functional equivalence.
6. Delivery: You receive the firmware image in Intel HEX, Motorola S-record, or raw binary format, along with a recovery report documenting the method used and any observations about the code structure.

Need to ship a board to our lab? Review the packing and shipping guide for PCB samples to avoid transit damage.

Firmware Recovery vs. Full PCB Reverse Engineering

Firmware recovery is one piece of a larger puzzle. If your goal is to replicate an entire board — not just the code — you also need Gerber files, a bill of materials, and a schematic. Our step-by-step board copy workflow covers how those deliverables come together. Firmware recovery slots into that process at the IC programming stage, but it can also be requested as a standalone service when you already have the PCB files and just need the code.

What Can Go Wrong — Honest Failure Modes

No responsible lab guarantees 100% recovery on locked parts. Here are the real failure modes we encounter:

• Chip destroyed during decapping: Acid exposure time is critical. Over-etch by 10–15 seconds on a fine-pitch die and bond wires detach. We mitigate this with CNC-controlled decapping, but the risk is never zero.
• Glitch campaign exhaustion: Some parts simply resist voltage glitching across the entire parameter space. After 72 hours of automated sweeps with no successful skip, we call it.
• Encrypted flash with no key recovery path: If the firmware is AES-encrypted and the key is stored in a one-time-programmable fuse bank that cannot be read, the binary is unrecoverable in any meaningful sense — you get ciphertext, not code.
• Partial reads: Occasionally we recover 95%+ of the image but a single flash sector is corrupted or unreadable. Depending on what that sector contains (lookup tables vs. boot vector), the image may or may not be functional.

We report all of these outcomes transparently. If recovery fails, you pay only for the assessment and any consumables (replacement chips, decapping materials).

When Should You Request Firmware Recovery?

Common legitimate scenarios where firmware recovery is the right call:

• Original developer is unreachable and source code was never escrowed.
• Production programmer corrupted the master HEX file and no backup exists.
• Legacy equipment needs a replacement control board, but the MCU is discontinued and pre-programmed stock is exhausted.
• You are migrating to a new MCU and need the existing binary as a functional reference for the rewrite.
• A field failure investigation requires analyzing the exact firmware revision running on a returned unit.

All of these require that you own or are authorized to access the firmware. Our FAQ answers common questions about authorization requirements and what documentation we accept.

Related reading

• Oct 2026Silicon Labs IC Unlock | Families We Can Read
• Oct 2026ATSAMD21 Unlock | Feasibility, Cost & Lead Time
• Oct 2026Infineon IC Unlock | Families We Can Read & How