What Is MCU Code Extraction?
MCU code extraction is the process of reading the embedded firmware stored inside a microcontroller’s internal flash or EEPROM and delivering it as a standalone .hex or .bin file. Engineers need this when source code has been lost, a vendor has gone out of business, or a legacy product requires maintenance and the original development environment no longer exists. The extracted file is a byte-for-byte copy of the on-chip program memory, ready to be loaded into a replacement MCU or analyzed in a disassembler.
Our lab handles MCU code extraction across more than 50 microcontroller families — from 8-bit PIC and AVR parts through 32-bit ARM Cortex-M devices. Typical turnaround ranges from 3 to 15 working days depending on the chip’s protection scheme, package type, and whether invasive techniques are required. Every project begins with a free feasibility assessment so you know the realistic probability before committing.
Why MCU Code Extraction Matters for Hardware Teams
Firmware is the most fragile link in any electronic product’s lifecycle. A single obsolete MCU with locked code can halt a production line, ground a fleet of industrial controllers, or orphan a medical device. MCU code extraction restores that link. Common scenarios include:
- Legacy product maintenance — the original developer is unavailable, and a failing MCU must be cloned to keep equipment running.
- Vendor lock-in recovery — a contract manufacturer holds the only copy of firmware and the relationship has ended.
- Second-source qualification — verifying that a replacement MCU runs identical code to the original.
- Failure analysis — comparing extracted code against a known-good build to isolate a field defect.
Authorization is required for every project. We work under NDA and verify ownership or legal right before extraction begins. For details on our compliance framework, see our guide to MCU protection mechanisms and realistic recovery.
How Does MCU Code Extraction Work?
Step 1 — Feasibility Analysis
You ship us the target MCU (or the entire PCB). Our engineers identify the exact part number, read the device signature, and determine the active protection level — read-protect bits, fuse settings, security locks, or encrypted boot regions. We then classify the job into one of three tiers:
| Tier | Protection Level | Typical Method | Turnaround |
|---|---|---|---|
| 1 — Low | No lock bits or weak fuse protection | Standard JTAG / SWD / ICSP readout | 3–5 working days |
| 2 — Medium | Read-protect enabled, no secure boot | Glitch attacks, voltage fault injection, UV exposure | 5–10 working days |
| 3 — High | Encrypted flash, anti-tamper, secure boot chain | Decap + micro-probing, FIB circuit edit | 10–15+ working days |
We report feasibility within 1–2 business days at no charge. If extraction is not viable, we tell you directly — roughly 8–12 % of submissions fall into a “not currently recoverable” category, primarily newer parts with hardware-encrypted flash and active tamper detection.
Step 2 — Non-Invasive Extraction Attempts
Whenever possible, we start with non-destructive techniques: debug-port readout via JTAG, SWD, ICSP, or UART bootloader commands. Many 8-bit MCUs — particularly older PIC12/16/18 families and Atmel ATmega parts — can be unlocked through well-documented voltage-glitch or timing attacks that reset the lock bits without damaging flash contents. This preserves the original chip for reuse. Our PIC microcontroller unlock reference covers family-specific protection details.
Step 3 — Invasive Techniques (When Required)
For higher-security devices — STM32 with RDP Level 2, Renesas RX with ID-code authentication, or NXP LPC with CRP Level 3 — non-invasive methods may not suffice. In these cases our engineers decapsulate the die using fuming nitric acid, expose the flash array, and use micro-probing or focused-ion-beam (FIB) edits to disable protection circuitry at the silicon level. This is a destructive process: the original package is consumed, so you should supply at least one spare device when possible.
Step 4 — Verification and Delivery
Extracted data undergoes a CRC-32 integrity check and, where a second sample is available, a byte-level comparison between two independent reads. We deliver the final file in Intel HEX (.hex), raw binary (.bin), or Motorola S-record (.srec) format — whichever your programming toolchain requires. A brief extraction report accompanies the file, documenting part number, fuse/option-byte states, and any configuration data (e.g., EEPROM contents, bootloader region).
Supported MCU Families and Protection Schemes
The table below lists the most common families we extract, along with their typical protection and our current success posture. This is not exhaustive — we evaluate any microcontroller on request.
| Vendor / Family | Common Protection | Extraction Viability |
|---|---|---|
| Microchip PIC12 / PIC16 / PIC18 | CP bit, code-protect fuse | High — most variants recoverable |
| Microchip PIC24 / dsPIC | General Code Protect, Write Protect | High for GCP; case-by-case for JTAG-locked parts |
| Atmel / Microchip AVR (ATmega, ATtiny) | Lock bits (LB1/LB2/LB3) | High — voltage-glitch effective on most |
| STMicroelectronics STM32 | RDP Level 0/1/2 | Level 0–1: high; Level 2: limited, die-level only |
| NXP LPC series | CRP Level 1/2/3 | CRP1–2: high; CRP3: case-by-case |
| Renesas RL78 / RX / R8C | ID code, on-chip debug security | Moderate — varies by sub-family |
| Nuvoton N76E / NUC / M0 | Security lock, ISP lock | High for most N76E; NUC varies |
| Texas Instruments MSP430 | JTAG fuse (physical blow) | Moderate — fuse bypass on older revisions |
| Freescale / NXP HC08 / HCS08 | Security bytes | High |
For Renesas-specific parts, our Renesas MCU unlock guide details RL78, RX, and R8C protection nuances. Nuvoton users can refer to our Nuvoton MCU unlock reference.
What You Receive After MCU Code Extraction
- Firmware file — .hex, .bin, or .srec at your choice, covering the full flash address range.
- EEPROM dump — separate file if the MCU contains data EEPROM (e.g., calibration tables, serial numbers).
- Fuse / option-byte map — exact configuration register states so a replacement MCU can be programmed identically.
- Extraction report — part number, date code, protection level encountered, method used, CRC of delivered file.
All files are encrypted and transferred via secure link. If you also need the firmware reverse-engineered into commented assembly or C pseudocode, that is a separate IC reverse engineering engagement.
Factors That Affect Success and Turnaround
Not every MCU code extraction succeeds. Transparency about limitations is part of our process:
- Silicon revision — newer die revisions of the same part number sometimes patch glitch vulnerabilities present in older revisions.
- Package condition — corroded or heat-damaged leads can prevent reliable debug-port contact; BGA reball may be needed first.
- Secure boot / encrypted flash — parts like STM32H7 with hardware AES-encrypted flash require the OEM key; without it, raw ciphertext is all we can deliver.
- One-time-programmable (OTP) locks — blown JTAG fuses (e.g., MSP430) demand invasive bypass, adding time and cost.
- Sample quantity — for invasive work, having 2–3 samples significantly improves success probability and allows cross-verification.
MCU Code Extraction vs. Related Services
The terminology around firmware recovery overlaps. Here is how MCU code extraction relates to adjacent services we offer:
| Service | Scope | When to Choose |
|---|---|---|
| MCU code extraction | Read firmware from a locked microcontroller | You need the .hex/.bin from a specific MCU |
| Chip code extraction | Broader — covers MCUs, CPLDs, FPGAs, serial flash | Target device may not be a standard MCU |
| Firmware cloning | Extract + program into replacement devices | You need programmed replacement chips, not just the file |
| Memory readout | Read external flash, EEPROM, NAND, NOR | Code lives in off-chip memory, not inside the MCU |
Frequently Asked Questions About MCU Code Extraction
Is MCU code extraction legal?
Yes, when performed on firmware you own or have legal authorization to access. Typical lawful scenarios include recovering your own lost source code, maintaining legacy equipment you operate, or auditing devices under a licensing agreement. We require proof of ownership or written authorization before starting any project, and all work is performed under NDA.
Will the original MCU survive the extraction process?
For Tier 1 (non-invasive) jobs, the chip is read through its debug port and remains fully functional. Tier 2 glitch attacks also preserve the device in most cases. Tier 3 invasive extraction — decapping and micro-probing — destroys the package. We always attempt non-invasive methods first and only escalate with your approval.
What if extraction fails?
If we cannot recover usable firmware, you pay nothing beyond any agreed shipping costs. Our feasibility report is free, and we are upfront about estimated probability before work begins. Roughly 8–12 % of submissions are classified as not currently recoverable.
Can you extract code from a chip soldered to a PCB?
Yes. For non-invasive reads we can often probe debug pads or test points directly on the board. If desoldering is required, our rework station handles packages from SOIC-8 through BGA-256. We recommend sending the entire board so we can assess the best access path.
How do I get started?
Send us the MCU part number (or a photo of the chip markings) and a brief description of the project context. We will return a feasibility assessment within 1–2 business days. If viable, ship the device or board to our lab and we handle the rest.
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 reviewWorking 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