What Is a Code Extraction Service?
A code extraction service recovers the embedded firmware—machine code, bootloaders, calibration data, or configuration tables—from a microcontroller or flash memory IC whose read-protection fuses have been set. When the original source code is lost, the development team has moved on, or a legacy product needs maintenance, extracting the existing binary from silicon is often the fastest path back to a working build. Our engineers use a combination of electrical, optical, and protocol-level techniques to read protected devices while preserving the data integrity of every extracted byte.
Why Engineers Need Firmware Extracted From Locked Chips
Locked chips are everywhere. Manufacturers set read-protection bits during production to guard IP, but that same protection becomes a barrier when you are the rightful owner and need the code back. Common scenarios include:
- Legacy equipment repair — the OEM is defunct, the programmer file was never archived, and a failed MCU must be cloned onto a fresh part to restore a production line.
- Product redesign or second-sourcing — migrating firmware to a pin-compatible MCU from a different vendor requires a verified binary dump of the original.
- Failure analysis — comparing a field-returned unit’s firmware against the golden image to rule out corruption or unauthorized modification.
- IP recovery — retrieving your own firmware after a contractor relationship ends without a proper source-code handover.
In every case, proof of ownership or written authorization is required before we begin work. We operate under NDA and maintain a documented chain of custody for every device we process.
How Code Extraction Works — Technique by Technique
Non-Invasive (Electrical / Protocol-Level)
Many MCUs expose debug interfaces—JTAG, SWD, UART bootloader, ISP—that can be leveraged when protection is incomplete or when known silicon errata allow a read-protection bypass on vulnerable device revisions. This is the fastest and lowest-risk method: the chip stays on the board, and turnaround is typically 5–8 working days.
Semi-Invasive (Fault Injection)
Voltage glitching, clock glitching, and laser fault injection can force a protected MCU to skip the security-check instruction and dump its flash contents through a normal read command. Success depends on the specific silicon revision, decoupling layout, and glitch timing window—often measured in single-digit nanoseconds. Our glitch rigs cover pulse widths from 2 ns to 500 ns with 100 ps resolution.
Invasive (Decapsulation + Micro-Probing)
When electrical attacks fail, we decapsulate the package with fuming nitric acid or laser decap, then use focused-ion-beam (FIB) editing or micro-probing to access internal bus lines. This approach is viable on older-process nodes (≥90 nm) where metal layers are accessible without destroying the die. It carries the highest cost and longest lead time (10–20 working days) but reaches devices that resist every other method.
External Flash / EEPROM Read
For systems where firmware lives on a separate SPI NOR, parallel NOR, or serial EEPROM, a dedicated flash read service can dump the contents in-circuit or after desoldering. Typical read times are under one hour; the challenge shifts to decrypting or deobfuscating the image if the host MCU encrypted it before writing.
Which Chip Families Can Be Extracted?
Feasibility depends on the vendor, part number, protection level, and silicon revision. The table below summarizes our current coverage across major families.
| Vendor / Family | Typical Protection | Primary Technique | Estimated Success |
|---|---|---|---|
| STM32 (Cortex-M0/M3/M4) | RDP Level 1 / Level 2 | Glitch / FIB (Level 2) | 85–95 % (Level 1); case-by-case (Level 2) |
| PIC16 / PIC18 (Microchip) | CP bit, Code-Protect | UV / Electrical | > 90 % |
| ATmega / ATtiny (Microchip-Atmel) | Lock bits (LB1/LB2) | HV parallel, glitch | > 90 % |
| LPC series (NXP) | CRP1 / CRP2 / CRP3 | Glitch (CRP1-2); invasive (CRP3) | 80–95 % |
| Renesas RL78 / RX | OCD security, ID code | Protocol exploit, glitch | 75–90 % |
| MSP430 (TI) | JTAG fuse | BSL exploit, glitch | 85–95 % |
| STC 8051-based | Proprietary lock | Electrical / timing | > 90 % |
| Cypress PSoC 1–4 | Flash protection rows | Glitch, semi-invasive | 70–85 % |
For ARM Cortex-M parts specifically, our ARM Cortex-M firmware readout technical guide details the protection architecture and the exact conditions under which extraction succeeds or fails.
What You Receive After Code Extraction
Every completed job ships with a documented deliverable package:
- Binary image — raw .bin or Intel HEX (.hex) file, byte-verified with CRC-32 and SHA-256 checksums.
- Memory map — start address, end address, flash size, EEPROM section (if applicable), option/configuration bytes.
- Fuse / option-byte dump — the exact protection and clock configuration registers so you can replicate the device state on a fresh part.
- Read report — technique used, number of consistent reads performed (we require ≥ 3 identical dumps), and any anomalies observed.
If you also need the binary disassembled or ported to a new MCU, that is a separate engagement—but having a verified dump is the prerequisite.
Realistic Constraints and Failure Modes
No honest code extraction service claims 100 % success. Here are the situations where extraction may fail or return incomplete data:
- Highest-level protection on modern nodes — STM32 RDP Level 2 and NXP CRP3 are designed to trigger a mass-erase on tamper detection. Invasive work is possible but not guaranteed, and cost can exceed the value of the firmware.
- Die damage during decap — aggressive chemical or laser decapsulation can destroy bond wires or top-metal interconnects, especially on fine-pitch BGA packages below 0.4 mm pitch.
- Encrypted external flash — if the host MCU encrypts data before writing to SPI flash with a device-unique key stored in OTP, the raw dump is useless without the key.
- One-time-programmable (OTP) devices — some OTP MCUs have no electrical read path at all once programmed; only FIB micro-probing can attempt a read, with success rates below 50 %.
We always run a feasibility assessment before quoting. If we determine the job is unlikely to succeed, we tell you upfront rather than charge for an attempt.
Authorization, Legality, and Trust
Code extraction touches intellectual-property law in every jurisdiction. We require one of the following before starting any job:
- Proof that you designed or commissioned the firmware (purchase orders, development contracts, copyright registration).
- Written authorization from the IP holder permitting readout.
- A statutory right to repair or interoperability under your local law, documented in writing.
All work is performed under mutual NDA. Extracted binaries are delivered only to the authorized requester and purged from our systems within 30 days of delivery. For a deeper look at our legal and ethical framework, visit our IC unlock service and trust overview.
Pricing and Turnaround Ranges
| Complexity Tier | Typical Price Range (USD) | Turnaround (Working Days) |
|---|---|---|
| Standard (non-invasive, common MCU) | $300 – $800 | 5 – 8 |
| Advanced (glitch / semi-invasive) | $800 – $2,500 | 8 – 15 |
| Invasive (decap + FIB / micro-probe) | $2,500 – $6,000+ | 15 – 25 |
| External flash read (SPI / parallel) | $150 – $400 | 2 – 5 |
Pricing depends on the specific part number, protection level, and quantity. Volume discounts apply when extracting the same firmware from multiple units for verification.
How to Request a Code Extraction
- Submit your chip details — vendor, full part number (including revision suffix), package type, and a brief description of why you need the firmware.
- Feasibility review — we check our internal database of 4,000+ device records and reply within 1–2 business days with a success estimate and quote.
- Ship the device — send the target IC (or the complete board) via tracked courier. We recommend anti-static packaging and insurance.
- Extraction and verification — we perform the read, verify with multiple passes, and compile the deliverable package.
- Delivery — encrypted file transfer of the binary plus the read report. The physical device is returned unless invasive techniques were required.
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 reviewRelated Chip Vendor Pages
If you already know the manufacturer, jump to the relevant vendor page for family-specific feasibility notes:
- Microcontroller unlock services across all major vendors
- Chip decryption techniques and current feasibility
Is code extraction the same as chip decryption?
They overlap heavily. “Code extraction” emphasizes the end goal—getting the firmware binary out. “Chip decryption” emphasizes the security mechanism being defeated. In practice, both terms describe the same service: bypassing a locked chip’s read protection to recover its embedded program. The technique chosen depends on the chip’s protection architecture.
Will code extraction damage my chip?
Non-invasive and most semi-invasive methods leave the chip fully functional. Invasive techniques (decapsulation, FIB) are destructive to the package and sometimes to the die. If preserving the original IC matters, we attempt non-invasive methods first and only escalate with your approval. For external flash reads, the chip is always returned intact.
Can you extract firmware from a chip that has been erased?
If the flash has been mass-erased (all bytes read 0xFF), there is no firmware left to recover. However, some “erase” commands only reset protection bits without wiping data—our feasibility check determines which scenario applies. Partially corrupted flash can sometimes yield a usable image with gap-filling from a known-good reference.
How do I know the extracted binary is accurate?
We perform a minimum of three independent read passes and compare SHA-256 hashes. If all three match, the dump is considered verified. On request, we can program the binary onto a blank device of the same part number and perform a functional boot test—this is the strongest validation but requires a spare IC.
Do you support encrypted firmware on external SPI flash?
We can always dump the raw ciphertext. Decrypting it requires either the key (often stored in the host MCU’s OTP area) or a successful extraction of the host MCU itself. We can quote both extractions as a combined job if needed.
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