Chip decryption is the process of reading protected code out of a locked microcontroller or memory device so you get a usable binary back — a .bin or .hex you can reprogram into a fresh part. You send the chip (or the whole board), we identify the security state, evaluate feasibility, and return the dump plus a programmed sample if you want one. Most requests come from people maintaining equipment whose source code is gone.
If that’s your situation, the rest of this page tells you what actually happens, what makes one part easy and another one a dead end, and exactly what to send for a quote.
When chip decryption is the right call
The typical caller has a machine on the floor that still runs, one spare board in a drawer, and a design engineer who retired in 2009. The firmware exists — it’s sitting in the flash of the MCU — but the project files, the toolchain, and the hex file are all gone.
Legitimate cases we see week after week:
- Lost source or hex. A contractor closed, a server died, or a repo was never backed up. The only surviving copy of the firmware is inside the chips on the boards you already own.
- Obsolete MCU. The part went end-of-life and you need the binary before you can plan a migration to a current device.
- Legacy equipment support. Elevator controllers, textile machines, medical instruments, industrial drives — long service lives, short vendor memories.
- Failure analysis. You need to compare the code in a field-returned unit against what production should have loaded.
- Field-updated units. Someone patched a fleet in the field years ago and nobody archived the patched image.
Chip decryption solves a firmware problem, not a hardware problem. If you also need the board itself rebuilt, that’s a separate track that runs in parallel — schematic and Gerber recovery from the physical PCB. The two are often quoted together because a spare board is worthless without both.
One point, stated once: you need to hold the rights to the firmware you’re asking us to recover, and you’re responsible for compliance with applicable IP law in your jurisdiction. Every project runs under NDA, and we don’t take work aimed at cloning somebody else’s product.
What actually happens to your chip
Step 1 — Identification and security state
The first thing an engineer does is read the marking under a stereo microscope and confirm the exact die revision, not just the family. An STM32F103C8T6 from one date code can behave differently from another. Then we determine what protection is actually set. On an STM32 that means finding out whether you’re looking at RDP Level 1 or Level 2. On an MSP430 it’s whether the JTAG fuse is blown and whether the BSL has a password. On 8051 derivatives and AVR parts it’s which lock bits are programmed.
That single determination drives everything else — method, cost, lead time, and whether we quote the job at all.
Step 2 — Non-invasive attempts first
Nothing gets opened until the cheap options are exhausted. Debug interfaces, factory bootloaders, test modes, and glitch-sensitive timing windows are all evaluated on a bench rig with the part socketed and powered separately from the board. Many older 8-bit parts and a fair number of Chinese ARM clones fall out here. A read protection bypass at this stage is fast and leaves the chip alive and reusable.
Step 3 — Semi-invasive or invasive work, if needed
When the electrical route is closed, the package comes off. Decapsulation exposes the die so the security logic can be probed or the memory array accessed directly. This is where sample count matters — we usually ask for two to five identical chips, because the first one is often spent characterizing the die and the second one produces the readable dump. Chips destroyed in the process do not come back.
Step 4 — Verification
A dump is not a result until it’s been proven. We check the reset vector and interrupt table for sanity, look for coherent constant data and string tables, confirm the image size matches the device memory map, and read a second chip to compare byte for byte. Where you can supply a working board, the strongest check is programming a blank part with the recovered binary and confirming the board behaves identically — same startup sequence, same I/O, same display output. Two independent dumps that match, plus a functional test, is the standard we work to.
What we need from you, and what you get back
Feasibility questions are usually answered in a short exchange. Send this and you’ll get a real answer instead of “please contact us”:
- Clear photos of the chip marking. Sharp, well-lit, straight on. Every line of the top marking, including the date code. A phone macro shot on a dark background works fine.
- Photos of both sides of the board if the chip is still mounted, whole board in frame, so we can see the programming header, the package type, and whether anything is potted.
- The package. DIP, SOIC, LQFP, QFN, BGA — QFN and BGA change the handling.
- Quantity of spare chips available. Be honest here. “One and it’s the only one that exists” is a different job from “I have ten.”
- What you need out of it. Binary only? Binary plus programmed samples? Also a board copy?
- Any history. Was it ever field-updated? Does an external EEPROM or serial flash hold calibration data? Does the unit have a serial number tied to the firmware?
Back from us: a feasibility assessment for that specific part and security state, a lead time, a price, and a statement of what happens if the attempt fails. On success you receive the verified binary in .bin and .hex, notes on memory layout and any option bytes or fuse settings needed to reproduce behavior, and programmed samples on request. If external memory carries calibration or configuration, a flash memory read of those devices is normally bundled in, because the MCU image alone often won’t make the board run.
How hard is your part, honestly
Difficulty tracks the security architecture, not the year of manufacture. Below is the shape of it. Treat it as orientation, not a promise — the specific die revision in front of us can move a part up or down a row.
| Part class | Typical protection | Difficulty |
|---|---|---|
| 8051 derivatives, older AVR, PIC16/PIC18 | Lock bits, security fuse | Usually straightforward, often non-invasive |
| STM8, older STM32 (F1/F0), GD32, CH32 | Read-out protection Level 1 | Generally workable |
| MSP430 | JTAG fuse, BSL password | Depends heavily on variant and fuse state |
| TMS320 DSP, dsPIC/PIC24, LPC, Kinetis | Code security module, CRP levels | Case by case, more samples needed |
| STM32 at RDP Level 2, modern secure-boot parts | Debug permanently disabled, encrypted flash | Hard, frequently not feasible |
| Secure elements, smart card ICs, hardware-encrypted flash | Dedicated tamper resistance | Normally declined |
Things that make a job harder or kill it outright: only one sample available; a die you’ve already damaged with a hot air gun; potted or epoxy-encapsulated modules; MCUs whose flash is encrypted with a key held in one-time-programmable fuses; and any part where the debug port was permanently and irreversibly disabled at the factory. RDP Level 2 on STM32 is the honest example — it’s designed so the debug interface can never be re-enabled, and we don’t pretend otherwise. If your part is in that group we’ll tell you at the quote stage, not after taking your money.
Price follows the same logic. It’s driven by the security mechanism, whether decapsulation is required, how many samples we get, the package, and whether external memories are included. Anyone quoting a flat rate for “any chip” hasn’t looked at your chip. Nobody can offer a guaranteed success rate on a specific device either, and a lab that does is guessing.
Chip decryption versus rewriting the firmware
There’s a real alternative worth weighing: skip the recovery and reimplement the behavior from scratch. That’s the right choice when the code is small, the function is well understood, and the part is already obsolete anyway — a motor controller running a PWM loop and a couple of limit switches can be rewritten faster than a decap job takes.
Recovery wins when the firmware contains things you cannot reconstruct: calibration constants, tuned control loop coefficients, protocol quirks that a downstream device depends on, or regulatory-approved behavior you don’t want to re-certify. It also wins when the code is large — nobody rewrites 200 KB of undocumented application logic to save a lab fee. If you’re weighing both paths, the tradeoffs between IC unlock and chip decryption as approaches are worth reading before you commit either way.
FAQ
Do you need to destroy the chip?
Not always. Non-invasive routes leave the part fully functional, and those are tried first. If decapsulation is required, that chip is consumed — the package is opened and it won’t run again. That’s why we ask how many spare samples you have before quoting. Your original board is unaffected either way, since we work on removed chips or supplied spares.
Can you get firmware out of an STM32 at RDP Level 2?
Usually no. Level 2 permanently disables the debug interface at the hardware level, and it’s specifically designed to make readout impossible. We’ll check your exact die revision, because behavior varies, but you should plan around the answer being no. Level 1 is a different conversation and is generally workable.
How long does chip decryption take?
A common 8-bit MCU with lock bits set is often days. A part needing decapsulation and die-level work is meaningfully longer, because characterization on the first sample has to succeed before the second one produces a dump. We give a lead time with the quote once we know the exact part and its security state, and we tell you when a schedule is uncertain.
What if you can’t read my chip?
We say
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