What Is Firmware Recovery and When Do You Need It?
Firmware recovery is the extraction of embedded program code—typically delivered as a .hex or .bin file—from a microcontroller, DSP, CPLD, or EEPROM whose read-protection fuses or encryption are active. Engineers request firmware recovery when original source code is lost, a vendor has gone out of business, or a legacy production board must be replicated under authorized ownership. The process is non-destructive in most cases, though certain chip families require physical decapsulation of the package when software-level attacks are blocked.
How Does Firmware Recovery Actually Work?
There is no single universal technique. The method depends on the silicon vendor, the protection architecture, and the specific revision of the die. Our engineers evaluate each device individually before committing to an approach. Below are the primary categories.
Non-Invasive (Electrical / Protocol-Level)
Voltage glitching, timing attacks, debug-port re-enablement, and bootloader exploits fall into this category. These techniques leave the chip physically intact and reusable. Typical targets include older PIC16/PIC18 devices, certain STM32 parts at RDP Level 1, and some Atmel AVR families. Turnaround is usually 3–7 working days once feasibility is confirmed.
Semi-Invasive (UV / Laser Fault Injection)
After removing the epoxy package with acid or laser, UV light or focused laser pulses reset individual fuse bits without destroying the flash array. This is common for 8-bit and some 16-bit MCUs where the protection fuse is a single OTP cell. The chip cannot be resoldered afterward, but the firmware image is fully intact.
Invasive (Micro-Probing)
For high-security parts—think certain Renesas RH850 or NXP S32K devices with encrypted flash—micro-probing the internal bus with a focused ion beam (FIB) workstation may be the only path. Success rates drop, costs rise (often above $5,000), and turnaround extends to 15–30 working days. We are transparent about these constraints before you commit.
Which Chips Are Recoverable?
Feasibility hinges on the protection scheme. The table below summarizes common families and realistic outcomes. For a broader device list, check our unlockable chip reference.
| Chip Family | Protection Type | Typical Recovery Path | Success Likelihood |
|---|---|---|---|
| PIC16F / PIC18F | CP fuse (OTP) | UV reset or glitch | High (85–95%) |
| STM32F1 / F4 (RDP1) | Read-out protection L1 | Voltage glitch / debug exploit | Moderate–High |
| STM32 (RDP2) | Permanent lock | FIB micro-probing (if die rev allows) | Low–None on newer revisions |
| Atmel ATmega / ATtiny | Lock bits | HV reset or glitch | High |
| STC 8051-core | Encrypted download | Protocol-level extraction | Moderate |
| dsPIC30 / dsPIC33 | Code-protect fuse | UV or electrical | Moderate–High |
| ARM Cortex-M (various) | Vendor-specific RDP/CRP | Depends on vendor & level | Varies widely |
| EEPROM (24Cxx, 93Cxx) | Write-protect, rarely read-locked | Direct SPI/I²C read | Very High |
Parts like STM32 at RDP Level 2 or NXP LPC with CRP Level 3 are often permanently locked by design. We will tell you upfront if a device falls into that category—no charge for the initial assessment.
What Does the Firmware Recovery Process Look Like?
- Device submission. Ship the programmed chip or the complete board. We need the part number, package marking, and any known revision info.
- Feasibility analysis (1–3 days). Our lab identifies the die revision, protection level, and viable attack vector. You receive a written feasibility report with a quoted price and estimated turnaround.
- Recovery execution. Once approved, the extraction proceeds. Non-invasive jobs typically finish within a week; semi-invasive or invasive work may take 2–4 weeks.
- Verification & delivery. The recovered binary is verified against a checksum (CRC32 or SHA-256) and delivered as a .hex, .bin, or .s19 file via encrypted transfer.
For a deeper look at what determines pricing, see our IC unlock cost breakdown.
Firmware Recovery vs. Code Extraction—Is There a Difference?
In practice the terms overlap. “Firmware recovery” usually implies the original developer has lost access and needs the code back, while “code extraction” is a broader label covering any read-out of protected memory. The lab techniques are identical. If your goal is specifically extracting code from a locked production chip, the workflow and deliverables are the same .hex/.bin output described here.
Common Failure Modes and Honest Limitations
Not every firmware recovery attempt succeeds. Here are the most frequent reasons a job fails or is declined:
- Permanent fuse (OTP) with no known bypass. Some newer silicon revisions patch vulnerabilities that worked on earlier steppings. A technique that unlocked an STM32F103 C8T6 in 2019 may not work on a 2024-dated part.
- Encrypted flash. If the MCU stores code in AES-128/256-encrypted flash and the key is derived from an on-die PUF (physically unclonable function), decryption without the key is computationally infeasible.
- Physical damage. Corrosion, cracked die, or ESD damage to the flash array can make the stored data unreadable regardless of protection status.
- Anti-tamper wipe. Certain automotive and payment-terminal MCUs erase flash upon detecting a glitch or decap attempt. We evaluate this risk before proceeding.
Our success-rate assessment guide explains how we score each device before quoting.
Authorization and Legal Requirements
We perform firmware recovery only for parties who can demonstrate ownership or authorization over the target device. Typical documentation includes a purchase order for the original hardware, a company letterhead request, or a signed declaration of IP ownership. All work is covered by a mutual NDA executed before the chip enters our lab. This protects both your intellectual property and ours. For full details on our compliance framework, visit our IC unlock service overview.
Deliverable Formats and Post-Recovery Options
| Deliverable | Format | Typical Use |
|---|---|---|
| Raw binary image | .bin | Direct flash programming, archive |
| Intel HEX | .hex | Programming via JTAG/SWD/ISP tools |
| Motorola S-Record | .s19 / .srec | Legacy programmers, automotive ECUs |
| EEPROM dump | .bin or .eep | Configuration data, calibration tables |
| Annotated memory map | Identifying bootloader vs. application regions |
If your board also contains EEPROM configuration data that must be preserved alongside the MCU firmware, we can handle both extractions in a single engagement. Our EEPROM data recovery guide covers the specifics of serial-memory readout.
Turnaround and Pricing Ranges
Exact pricing depends on the chip family, protection level, and chosen attack vector. The ranges below reflect completed jobs over the past two years:
- Standard 8-bit MCU (PIC, AVR, STC): $150–$500, 3–7 working days.
- 16-bit DSP / dsPIC: $300–$800, 5–10 working days.
- 32-bit ARM Cortex-M (non-permanent lock): $400–$1,500, 7–15 working days.
- Invasive / FIB-assisted: $3,000–$8,000+, 15–30 working days.
- Feasibility assessment only: No charge if we determine the chip is unrecoverable.
Rush service (≤3 days for non-invasive jobs) is available at a 40–60% surcharge.
Check feasibility for your project
Send the chip marking or board details and tell us what you need to recover. Add clear photos if available.
Request a feasibility reviewCan firmware be recovered if the chip is physically damaged?
It depends on the type of damage. If the flash array itself is intact—meaning the die is not cracked through the memory region—we can often still read the data even if bond wires or external pins are damaged (we reball or probe directly). Severe corrosion or heat damage that reaches the silicon layer usually makes recovery impossible.
Will the chip still work after firmware recovery?
With non-invasive methods (glitching, debug exploits), the chip is physically unmodified and can be resoldered. Semi-invasive and invasive methods require removing the package, so the chip cannot be reused on a board, though the extracted firmware can be programmed onto a fresh, identical part.
Do I need to send the whole board or just the chip?
Either works. If you can desolder the MCU safely, ship just the chip in an anti-static container. If desoldering risks damage—especially with QFN or BGA packages—send the entire board. We desolder in-house with IR rework stations calibrated per IPC-7711/7721 guidelines.
How do I know the recovered firmware is correct?
We verify every extraction with a CRC32 or SHA-256 checksum and, where a second sample chip is available, perform a comparative read. You also receive the raw binary so you can load it into a disassembler or program a blank chip and validate board-level functionality yourself.
Is firmware recovery legal?
Recovering firmware you own—or are authorized to access—is legal in most jurisdictions under maintenance, repair, and interoperability provisions. We require proof of ownership or written authorization before starting any job, and all work is performed under NDA. We do not assist with unauthorized copying of third-party IP.
Working on a board like this?
Send the chip marking or two photos. You get feasibility, lead time and price within 24 hours, and the check costs nothing.
Get a free quote