Chip Decryption | Recover Firmware From a Locked Chip

What Is Chip Decryption?

Chip decryption is the authorized recovery of firmware or configuration data from a microcontroller, DSP, CPLD, or other programmable IC whose read-protection mechanisms have been enabled. When a manufacturer sets security fuses, enables read-out protection (RDP), or activates code-protect bits, standard programming tools return blank or error states. Chip decryption uses a combination of electrical, physical, and protocol-level techniques to recover the original binary — typically delivered as a .hex or .bin file — so the rightful owner can maintain, migrate, or reproduce legacy hardware.

This process is not about circumventing someone else’s intellectual property. Every chip decryption project we accept requires proof of ownership or written authorization. For details on our legal and ethical framework, see our authorization and NDA policies.

Why Chip Decryption Becomes Necessary

Engineers request chip decryption under a surprisingly narrow set of real-world scenarios. The common thread is that the original source code or programming files are no longer available.

• Legacy equipment repair: A 15-year-old industrial controller uses an obsolete MCU. The OEM is defunct, and the only copy of the firmware lives inside the chip on the board.
• Disaster recovery: A development server crash, a departed engineer, or a ransomware event destroys the only repository. The production board becomes the source of truth.
• Product migration: A chip goes end-of-life. Porting firmware to a pin-compatible replacement requires reading the original binary first.
• Quality audit: An OEM needs to verify that a contract manufacturer programmed the correct firmware version — but the read-protect fuse was set during production.

In every case, the requesting party owns the IP or has contractual rights to the code. That distinction matters, and we enforce it before any lab work begins.

How Chip Decryption Works: Methods Compared

No single technique works on every chip. The method depends on the silicon vendor, the protection architecture, and the specific device revision. Our lab evaluates each part individually, but most projects fall into one of these categories.

For a deeper comparison of invasive versus non-invasive approaches, see our guide on decapsulation vs. glitching.

What Determines Whether Chip Decryption Will Succeed?

Honest assessment up front saves time and money. Not every locked chip can be read. Here are the factors our engineers evaluate during a feasibility review.

Protection Level

Many vendors implement tiered protection. STM32, for example, offers RDP Level 1 (reversible — flash erased on unlock) and RDP Level 2 (permanent, JTAG disabled at the hardware level). Level 1 parts are recoverable with the right glitching setup. Level 2 parts often require invasive techniques or may be unrecoverable entirely depending on die revision.

Silicon Revision

A vulnerability that works on Rev A of a chip may be patched in Rev B. We maintain an internal database tracking known exploits by device revision and date code. Our supported IC list reflects current capabilities, but feasibility assessment on unlisted parts is available on request.

Physical Condition

Corroded pins, cracked packages, or heat-damaged die reduce success probability. If the flash array itself is degraded — common on parts that have been in service for 10+ years at elevated temperatures — the extracted binary may contain bit errors. We flag this risk before quoting.

Encryption vs. Access Control

Read protection and encryption are different things. Most 8-bit and many 32-bit MCUs only implement access control: the debug port is locked, but the flash contents are stored in plaintext on the die. True AES-encrypted flash (e.g., some Infineon AURIX, newer STM32H7 with secure boot) means that even a successful physical readout yields ciphertext without the key. We distinguish these cases clearly during evaluation. For Infineon-specific scenarios, our Infineon chip decryption guide covers what is and isn’t feasible.

Chip Decryption Process: Step by Step

1. Inquiry and authorization: You submit the chip part number, date code, and proof of ownership or a signed authorization letter. We countersign an NDA if required.
2. Feasibility assessment: Our engineers check the device against known protection architectures and prior success records. You receive a feasibility report within 1–2 working days — including an honest “not feasible” verdict if that’s the case.
3. Quotation: Pricing depends on the method required. Non-invasive glitching or debug exploits start around $300–$500 per device. Invasive decapping with FIB work can range from $1,500–$5,000+ depending on die complexity.
4. Chip shipping: You send the target chip (or the entire PCB). We recommend shipping at least two samples when possible — one for primary extraction, one as backup if destructive methods are needed.
5. Lab work: Extraction is performed in our shielded lab. For non-invasive methods, the chip is typically returned functional. Decapping is destructive to the package.
6. Verification and delivery: The recovered binary is verified by programming it into a blank device of the same part number and confirming functional operation where possible. Deliverables are a .hex or .bin file, transmitted via encrypted channel.

For projects that involve reading external flash or EEPROM rather than on-chip protected memory, our flash read service may be a simpler, faster path.

Deliverable Formats and Verification

Realistic Limitations of Chip Decryption

We set expectations clearly because overpromising wastes everyone’s time:

• No guaranteed 100% success rate. Some protection schemes — particularly hardware-level RDP Level 2 on recent silicon or AES-encrypted secure boot chains — are not breakable with current techniques.
• Destructive methods destroy the package. If decapping is required, the original chip will not be reusable. Send a spare if you need the board back in service.
• Bit-level accuracy depends on flash health. On very old or thermally stressed parts, isolated bit errors are possible. We report confidence level alongside the binary.
• Source code is not recovered. Chip decryption yields a compiled binary, not C source. Disassembly or decompilation is a separate engineering effort.

Authorization and Legal Requirements

Every chip decryption engagement requires one of the following before lab work begins:

• Proof of product ownership (purchase records, design files, or a company letterhead declaration)
• Written authorization from the IP holder (e.g., a contract manufacturer confirming your right to the firmware)
• A signed NDA covering the extracted data

We decline projects that cannot provide documentation. This policy protects both parties and ensures compliance with international IP law.

[pcb_cta type=”feasibility”]

Frequently Asked Questions About Chip Decryption

Related Services and Resources

• IC decryption feasibility factors — what determines whether your specific IC can be read
• MCU firmware extraction — delivered as .hex or .bin for common ARM and 8-bit families
• DSP chip decryption guide — TI TMS320 and ADI SHARC specifics
• Bootloader recovery — reading locked boot regions separately

[pcb_cta type=”quote”]

{
“@context”: “https://schema.org”,
“@type”: “Service”,
“name”: “Chip Decryption Service”,
“description”: “Authorized recovery of firmware from read-protected microcontrollers and ICs using glitching, debug exploitation, and invasive decapping techniques.”,
“provider”: {
“@type”: “Organization”,
“name”: “PCB-Copy.com”,
“url”: “https://pcb-copy.com”
},
“serviceType”: “Chip Decryption / Firmware Recovery”,
“url”: “https://pcb-copy.com/chip-decryption/”
}

{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “How long does chip decryption typically take?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Non-invasive methods usually complete in 3–7 working days after receiving the chip. Invasive decapping projects take 10–20 working days. Feasibility assessment is returned within 1–2 days of inquiry.”
}
},
{
“@type”: “Question”,
“name”: “Will my chip still work after decryption?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “If a non-invasive technique succeeds, the chip is returned fully functional in most cases. Invasive methods like chemical decapping destroy the package.”
}
},
{
“@type”: “Question”,
“name”: “Can you decrypt any chip?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “No. Modern parts with hardware-enforced permanent lock bits or AES-encrypted flash may be unrecoverable. A feasibility assessment identifies these cases before you commit budget.”
}
},
{
“@type”: “Question”,
“name”: “What is the difference between chip decryption and firmware recovery?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Chip decryption emphasizes bypassing on-chip security mechanisms, while firmware recovery is a broader term that includes reading unprotected external flash, EEPROM, or boot regions.”
}
},
{
“@type”: “Question”,
“name”: “Do I need to send the whole PCB or just the chip?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Either works. Sending the chip desoldered is fine for standalone MCU decryption. Sending the full board helps if probing signals in-circuit is needed.”
}
}
]
}

{
“@context”: “https://schema.org”,
“@type”: “BreadcrumbList”,
“itemListElement”: [
{“@type”: “ListItem”, “position”: 1, “name”: “Home”, “item”: “https://pcb-copy.com/”},
{“@type”: “ListItem”, “position”: 2, “name”: “Chip Decryption”, “item”: “https://pcb-copy.com/chip-decryption/”}
]
}

Related reading

• Sep 2026BOM Reverse Engineering | Parts Lists You Can Order
• Sep 2026Renesas RH850 Crack | Protection Levels Explained
• Sep 2026PCB Copy Lead Time | 3 Days vs 3 Weeks Explained