An IC unlock service reads the program memory out of a microcontroller whose read protection is set, and hands you back a working binary — a hex or bin file you can reprogram into the same part, or into a replacement part when the original goes obsolete. You send the chip (or the board with the chip on it), we evaluate the specific die and protection level, and you get a feasibility answer and a price before any work starts. Some parts are routine. Some are not, and we’ll say so.
Why engineers end up needing this
Almost every job that comes through the lab traces back to one of four situations, and none of them involve stealing anyone’s design.
- The source is gone. The contractor who wrote the firmware closed shop, the build machine was retired, or the only hex file lived on a laptop that died. The product still ships; you just can’t program a new board.
- Legacy equipment needs to stay running. A 1998 packaging line runs on a PIC16C with OTP program memory. The spare is a single chip in a drawer, and when it fails the line stops.
- The part went end-of-life. You need the code out of an ST72 or an NEC 78K so you can port it, or so you can flash a drop-in replacement while a proper migration gets budgeted.
- Failure analysis. A returned unit misbehaves and you want to compare what’s actually in flash against what you believe you shipped — including the EEPROM area where calibration and hour counters live.
You need to hold the rights to the firmware, or written authorization from whoever does. That’s the line we work behind, and every project runs under NDA before the chip ships.
What actually happens to your chip
1. Identification, before anything else
The top marking is the starting point, not the answer. Silicon revisions matter enormously — two chips with the same part number but different date codes and mask revisions can behave completely differently under protection. So the first step is reading the marking, the revision code, and where possible the die identity, then matching that against what we’ve already characterized.
This is why a vague inquiry (“can you unlock an STM32?”) gets a vague answer, and a photo of the actual chip marking gets a real one.
2. Electrical assessment on the bench
The part gets powered up on a test fixture and interrogated through whatever interfaces the silicon still exposes — SWD, JTAG, ICSP, a bootloader UART, whatever the family uses. The engineer is looking at what the protection actually blocks. Can the device ID still be read? Does the debug port enumerate and then refuse memory access, or is it dead entirely? Is option-byte or configuration-word memory readable even though flash isn’t?
Those answers narrow the approach dramatically. An STM32 sitting at RDP Level 1 is a fundamentally different job from the same part at Level 2, where the debug interface is permanently disabled. On MSP430, whether the JTAG fuse is blown or the BSL is merely password-protected changes the whole conversation. On 8051-derived and AVR parts, which specific lock bits are programmed determines whether external code fetch is blocked, verify is blocked, or both.
3. Choosing the least invasive route that works
Work always starts non-invasively, because a chip that stays intact can be retried and can be handed back. Only when non-invasive routes are exhausted does the job move toward semi-invasive or invasive techniques — and at that point we come back to you with a revised assessment, because the risk profile and cost both change. Decapsulation consumes the part.
4. Verification, which is where jobs are won or lost
A dump is not a deliverable. Any read is repeated and compared byte-for-byte across passes. Then the binary gets sanity-checked as code: does the reset vector point somewhere plausible, does the interrupt vector table look coherent, do string constants and lookup tables read as real data instead of noise, does the checksum the firmware itself computes match?
The strongest verification is functional. Where you can supply a blank or scrap sample of the same part, we program the extracted image into it and confirm the board behaves. That test catches problems a hex dump alone never will — a missed EEPROM region, a calibration block, a protected sector that came back as 0xFF.
What we need from you, and what comes back
Send this and you’ll get a straight answer, usually the same working day:
- A clear, sharp photo of the chip marking. Full part number including the suffix, package code, and date code. Angle a light across the top so the laser marking reads.
- Photos of both sides of the board on a dark, non-reflective background, whole board in frame, in focus. This tells us the package, whether it’s socketed or soldered, and whether there’s conformal coating or potting in the way.
- Quantity available. One irreplaceable unit is a different job from five identical boards. Spares expand what we can attempt.
- What you actually need. Program flash only? Flash plus data EEPROM? A programmed replacement chip? Or the code disassembled and documented for a port to a new MCU?
- One line of background. What the equipment does and why the firmware is unavailable. It helps, and it establishes the legitimate basis for the work.
What comes back at handover: the binary in hex and bin format, a report on which memory regions were recovered and which weren’t, verification results, and your original hardware unless the approach consumed it. If you asked for programmed parts, they come tested. Where the job feeds a wider recovery effort — say you also need the board reproduced — code extraction from the MCU is usually run alongside the board work so schematic and firmware land together.
How feasible is your specific part?
Difficulty tracks the era and the security architecture of the silicon, not the brand on the package. Rough guidance, with the caveat that revision-level detail always overrides the family-level generalization:
| Chip category | Typical difficulty | What tends to decide it |
|---|---|---|
| Older 8051 derivatives, classic AVR, early PIC | Usually straightforward | Which lock bits are set; whether the part is OTP or flash |
| Mainstream Cortex-M0/M3 (STM32F1, GD32, LPC17xx) | Case by case | Protection level; silicon revision; debug port state |
| MSP430 and similar with hardware fuses | Case by case | JTAG fuse blown vs. BSL password only |
| Newer Cortex-M4/M7 and M33 with hardware crypto | Often hard, sometimes not feasible | Whether flash is encrypted at rest; secure boot; TrustZone config |
| Secure elements, smart card ICs, certified secure MCUs | Generally not feasible | Purpose-built countermeasures, active shielding |
Vendor-specific quirks matter more than the table suggests. Chinese-market parts are their own landscape — GigaDevice devices that look pin-compatible with an ST equivalent don’t necessarily share its protection behavior, and Megawin 8051 variants follow their own scheme entirely.
Where we say no, and why that’s useful to you
Any lab that tells you every chip can be unlocked is either guessing or lying. The honest list of hard cases:
- Encrypted flash. If firmware is stored encrypted with a key held in one-time-programmable fuses inside the die, reading the flash array gets you ciphertext. A dump you can’t decrypt isn’t a recovery.
- Permanently disabled debug access. STM32 RDP Level 2 is the well-known example. The disable is irreversible by design and there’s no supported path back in.
- Single unique samples. With one board and no spares, invasive routes carry a real chance of destroying the only copy of what you’re trying to save. Sometimes the right recommendation is not to try.
- Physically damaged die. A part that took an overvoltage event or was heat-damaged during removal may have corrupted flash cells. Nothing recovers data that no longer exists.
- Certified secure hardware. Payment ICs and secure elements are engineered specifically to resist this class of work, and they generally succeed.
You get that assessment before you pay for the attempt, not after. If a read protection bypass isn’t viable for your part, we’ll usually suggest the alternative — rewriting from behavior, or reverse engineering the board and porting to a modern MCU, which is sometimes cheaper anyway.
Cost and lead time drivers
Pricing is per part family, not per chip, and it’s driven by: how well characterized that specific silicon revision already is; whether the job stays non-invasive; whether EEPROM and configuration memory are needed alongside program flash; how many samples you can supply; and whether you want documentation and porting support on top of the raw binary.
Lead time follows the same logic. A well-known 8-bit part with a documented approach is fast. A modern 32-bit MCU that requires characterization work first takes meaningfully longer, and the evaluation stage is where that becomes clear. Rush handling is possible on families we already have workflows for.
FAQ
Do I have to send the whole board, or just the chip?
Either works, but the whole board is often better. Having the board lets us verify the recovered firmware in situ, and it shows the surrounding circuitry — pull-ups on the debug pins, external memory, coating. If shipping the assembly isn’t practical, send the desoldered chip plus clear photos of the board it came from.
Will the chip still work afterward?
With non-invasive methods, yes — the part comes back functional and reusable. Invasive approaches that require opening the package destroy the device, which is exactly why we ask about spare samples early and why we tell you before switching to that route. You approve the change first.
Can you get the EEPROM contents too, not just program flash?
Usually, and you should ask
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