A chip decryption service reads the program memory out of a locked microcontroller and gives it back to you as a .hex or .bin file you can reflash onto the same part number. That’s the whole deliverable. No source code, no comments, no variable names — a byte-for-byte image of what the factory programmer put in there, verified by writing it to a blank sample and running it.
If you have a dead board, a discontinued MCU, or a firmware image that walked out the door with a former contractor, that file is usually what you actually need.
What you get back, and what you don’t
Be clear on this before you spend money. Chip decryption recovers machine code, not a project you can edit.
- Program flash / ROM image — Intel HEX or raw binary, sized to the part’s memory map, with the address offsets stated so you don’t reflash 0x08000000 content at 0x00000000.
- Data EEPROM contents, where the part has separate EEPROM and it matters — calibration constants, serial numbers, run hours, unit-specific trim values.
- Configuration and fuse settings — oscillator selection, watchdog, brown-out level, lock bits, boot pin behavior. Get these wrong on the reflash and a perfectly good dump won’t boot.
- A verification report — which blank sample we programmed, what the board did afterward, what we checked and against what.
You do not get C source. Turning ARM Thumb-2 or PIC assembly back into readable, buildable code is a separate and far larger job that belongs under chip-level reverse engineering rather than a straight readout. If your real goal is to modify behavior — change a setpoint, add a CAN message, lengthen a timeout — say so at the quote stage, because it changes what we recommend and what we quote.
Where the file goes next
Most customers use the dump one of three ways: reprogram replacement MCUs so production can restart; keep it in the archive as a maintenance spare against future field failures; or pair it with a board-level copy so an obsolete assembly can be rebuilt end to end. The last case is where a dump on its own isn’t enough and MCU firmware extraction gets bundled with PCB work — you need copper, BOM, and code to rebuild a board nobody makes anymore.
One more honest note on scope: if the firmware contains per-unit data such as a machine serial number, motor hours, or an encrypted license blob tied to a specific board, a copied image may run but behave as though it is on the wrong machine. Tell us if the equipment is licensed or node-locked. That single sentence in your first email saves a week of confusion.
How our chip decryption service handles a locked part
Order matters. We start cheap and non-destructive and escalate only when we have to, because every step up costs more and consumes more samples.
- Identification. Full top marking, package, date code, revision letter. An STM32F103C8T6 from one silicon revision does not behave like another, and a “PIC16F877” and a “PIC16F877A” are different projects. If the marking is sanded off or the part is under epoxy, we say so before quoting.
- Electrical triage. We power the part on a test fixture and see what it admits to. Does the debug port respond at all? Does it enumerate and then refuse to read? Does it report a protection level? A part that answers on SWD but returns zeros is a different problem from a part that is electrically dead.
- Read the protection state. Lock bits on an 8051 or AVR, RDP level on an STM32, the JTAG fuse or BSL password arrangement on an MSP430, code-protect configuration words on PIC — each family exposes its state differently, and that state is the single biggest input to feasibility. Our overview of how read-out protection works covers the levels in more depth.
- Non-invasive attempt first. Where a known weakness exists in a given family and die revision, we try it on the customer’s part or on a matching sample we hold in stock. Nothing is opened. Nothing is consumed.
- Semi-invasive work, only if needed. This is where the die is exposed and worked on optically or electrically under a probe station. It typically consumes at least one sample, sometimes several, and it is why we ask for spare parts up front.
- Dump, sanity-check, reflash, run. We look at the image before we call it done: is there a plausible vector table or reset vector at the right address, does the code section end where flash usage should end, are there recognizable strings, does the checksum region look consistent? Then we program a blank device and run it in the actual application if you sent a board.
- Delivery. Files, fuse and option-byte values, programming notes, and the verification record. If we tested on your board, we tell you exactly what we observed — not “works fine”.
Verification against the real hardware is the step that separates a usable dump from a file that looks right. A blank part programmed with a good image and the wrong oscillator fuse will sit there doing nothing, and without a board to test on, nobody catches it until you do.
Which chips are easy, which are hard, and which we may decline
Nobody can honestly promise every part. Feasibility depends on family, die revision, protection level, and how many samples you can spare. Here is the shape of it in plain terms.
| Situation | Typical difficulty | What changes the answer |
|---|---|---|
| Older 8-bit MCUs (8051 derivatives, classic PIC, early AVR) | Usually straightforward | Exact suffix and date code; some later revisions closed known holes |
| Mainstream 32-bit Cortex-M parts at a low protection level | Often workable | Which protection level is actually set, and the die revision |
| Serial EEPROM and external SPI/NOR flash | Generally a read, not an attack | Whether the contents are encrypted or bound to the host MCU |
| Parts at the highest protection level, with debug permanently disabled | Hard, sometimes not feasible | Sample count, whether decapsulation is acceptable, budget |
| Modern parts with on-die flash encryption or secure boot | Frequently declined | Key storage arrangement; we will tell you straight if it’s a no |
| Physically damaged die, cracked package, prior failed attempt | Case by case | Whether the memory array survived; a second good sample helps a lot |
Two specific things make a job harder that customers rarely expect. First, a previous attempt by somebody else — a part that has already been decapsulated badly, or had its fuses rewritten, is a worse starting point than an untouched one. Second, a single irreplaceable sample. If you send one chip and nothing else exists on earth, we will restrict ourselves to non-destructive methods only, and that narrows what’s possible.
We also decline work where the request looks like straight cloning of someone else’s product rather than recovery or maintenance. You are responsible for holding the rights to the design, and for complying with applicable IP law in your jurisdiction; every project runs under NDA, and we don’t keep or resell your image.
What to send us, and what comes back
A useful quote takes about five minutes of your time to enable. Send this:
- The exact chip marking, all lines of it, photographed close enough to read — including the suffix and date code.
- Clear photos of both sides of the board on a dark background, whole board in frame, in focus, no flash glare across the IC.
- Board dimensions and, if the MCU is under a shield, potting, or a heatsink, a note saying so.
- Sample count — how many programmed parts and how many blanks you can supply, and whether the parts are still purchasable.
- One line on deliverables: dump only, dump plus reflashed samples, or firmware bundled with a board copy.
- One line on why: lost source, obsolete part, failure analysis, migration to a current MCU. This genuinely affects our recommendation.