Microcontroller Unlock | Recover Firmware From a Locked MCU

What Is Microcontroller Unlock?

Microcontroller unlock is the authorized extraction of firmware from an MCU whose code-protection fuses, security bytes, or read-back-disable bits have been set. When a developer programs a microcontroller, the toolchain typically offers a “lock” option that prevents external debuggers or programmers from reading the flash contents. If the original source code or project files are later lost — due to a departed engineer, a crashed workstation, or an obsolete development environment — the only copy of the firmware may sit inside that locked chip. Our engineers recover that code as a verified .hex or .bin file, typically within 5–15 working days depending on the MCU family and protection level.

Why MCUs Get Locked — and Why You May Need Them Unlocked

Manufacturers embed code-read protection (CRP) to safeguard intellectual property during mass production. The intent is good: it stops casual JTAG/SWD readout. But protection becomes a liability in several legitimate scenarios:

• Lost source code — The original developer left, the repository was corrupted, or the project predates version control.
• Legacy equipment repair — A production line depends on a board whose MCU has failed. No firmware backup exists.
• Design migration — An end-of-life chip must be replaced with a pin-compatible successor, and the firmware needs to be ported.
• Prototype recovery — A pre-production sample carries the only working build of a firmware revision.

In every case, the requestor owns the IP or holds documented authorization. We require proof of ownership or a signed NDA before starting any microcontroller unlock engagement.

How Protection Mechanisms Work Across Major MCU Families

Not all locks are created equal. The difficulty — and feasibility — of a microcontroller unlock depends on the specific protection scheme the silicon vendor implemented. Below is a practical comparison of common families our lab handles.

For vendor-specific detail, see our dedicated pages — for example, our STM32 IC unlock guide breaks down RDP Level 1 vs. Level 2 behavior, while our Microchip IC unlock page covers PIC and dsPIC config-bit nuances.

What Techniques Do Engineers Use for Microcontroller Unlock?

The specific approach depends on the chip architecture and protection level. Our lab uses a combination of non-invasive, semi-invasive, and — where warranted — invasive methods:

Non-Invasive (Protocol-Level)

Exploiting known vulnerabilities in the debug interface, bootloader, or ISP protocol. For example, certain NXP LPC parts with CRP1 allow partial SRAM access through the ISP serial protocol, which can be leveraged to dump flash contents. This category carries the lowest cost and fastest turnaround — often 5–7 working days.

Semi-Invasive (Fault Injection)

Glitching the supply voltage or clock signal at a precise moment during the boot sequence to bypass the security check. Voltage glitch attacks on STM32 RDP Level 1 are a well-documented example. Success depends on the silicon revision; newer steppings often patch earlier glitch windows. Turnaround: 7–12 working days.

Invasive (Die-Level)

Decapsulating the package, exposing the die under a microscope, and using UV light, micro-probing, or focused ion beam (FIB) techniques to disable or bypass fuse cells. This is reserved for high-value recovery where non-invasive methods have failed. It requires specialized equipment (chemical decap station, IR microscope, probe station) and adds cost. Turnaround: 10–15+ working days. The original chip is typically consumed in the process.

We always attempt the least invasive viable method first. If a non-invasive path exists, the chip is returned intact and fully functional.

Realistic Success Rates and Limitations

No honest service provider claims 100% success across all MCUs. Here is what shapes the outcome:

• Protection level matters most. A PIC16F with CP set is straightforward. An STM32 at RDP Level 2 or an NXP Kinetis with FSEC = 0x00 may be unrecoverable without invasive work — and even then, success is not guaranteed.
• Silicon revision. Vendors patch vulnerabilities between die revisions. A technique that works on Rev A may fail on Rev C of the same part number.
• Physical condition. A chip that has suffered ESD damage, corrosion, or cracked bond wires may not survive decapsulation.
• Encrypted flash. Some newer Cortex-M33 and RISC-V MCUs use AES-256-encrypted flash with device-unique keys. If the key is destroyed when protection is tripped, the data is mathematically unrecoverable.

We offer a free feasibility assessment before quoting. If we determine recovery is unlikely, we tell you upfront — no charge, no wasted time.

Our Microcontroller Unlock Process Step by Step

1. Intake & authorization check — You submit the chip part number, describe the use case, and provide proof of IP ownership or a signed authorization letter.
2. Feasibility assessment — Our engineers identify the protection scheme, silicon revision, and the most appropriate technique. We report back within 1–2 business days with a go/no-go and a quote.
3. Chip shipment — You ship the locked MCU (or the entire PCB) to our lab. We handle worldwide logistics under NDA.
4. Recovery work — The chip goes through our unlock workflow. We verify the extracted binary against flash size and checksum.
5. Delivery — You receive the firmware as a .hex or .bin file, along with a brief report noting the memory map and any observations (e.g., EEPROM contents, fuse-byte state). For details on output formats, see our MCU code extraction page.

Supported Vendors and MCU Families

Our lab maintains tooling, fixtures, and documented techniques for over 50 MCU families. Major vendor coverage includes:

• STMicroelectronics — STM32 (F0/F1/F2/F3/F4/F7/H7/L0/L1/L4/G0/G4), STM8S, STM8L
• NXP — LPC1100–LPC4300, Kinetis K/KL/KE/KW, S12/S12X, S08
• Microchip — PIC10/12/16/18, PIC24, dsPIC30/33, PIC32, SAM (Atmel legacy)
• Atmel / Microchip AVR — ATtiny, ATmega, XMEGA, AVR-DA/DB
• Texas Instruments — MSP430F/G/FR, CC26xx, CC13xx (limited)
• Renesas — RL78, RX, R8C, M16C, SH series
• Infineon / Cypress — PSoC 4/5/6, XMC1000/4000, TC2xx (limited)
• Nuvoton — M0/M4 series, N76E003
• Holtek — HT66F, HT68F, HT32

If your chip isn’t listed, contact us anyway. We regularly add new families and can often extend existing techniques to closely related parts.

Authorization, Legality, and Our NDA Policy

Microcontroller unlock is legal when performed on firmware you own or are authorized to access. Typical authorized scenarios include recovering your own production firmware, supporting legacy equipment you operate, or extracting code from a prototype you commissioned. We require at minimum one of the following before starting work:

• A signed declaration of IP ownership
• A purchase order or development contract linking you to the firmware
• Written authorization from the IP holder

Every engagement is covered by a mutual NDA. We do not retain copies of extracted firmware after delivery. For a deeper look at our compliance framework, visit our IC unlock service homepage.

Pricing Signals

Cost depends on the MCU family, protection level, and technique required. As a rough guide:

We quote a fixed price after the feasibility assessment. No charge if we determine recovery is not viable.

Related reading

• Oct 2026Texas Instruments IC Unlock | Families We Can Read
• Oct 2026AT90 Unlock | Feasibility, Cost & Lead Time
• Oct 2026AVR IC Unlock | Which Families We Can Read