IC Decryption | What Determines Whether It Is Possible

What Is IC Decryption and When Does It Apply?

IC decryption is the process of reading protected firmware or data from a locked microcontroller, EEPROM, or other programmable IC by circumventing its on-chip security mechanisms. It applies when you need to recover your own firmware from a production chip after source code is lost, when maintaining legacy equipment whose original vendor no longer exists, or when verifying that a contract manufacturer programmed your design correctly. Every project requires proof of ownership or written authorization before work begins.

Five Factors That Determine IC Decryption Feasibility

Not every locked chip can be read. Our engineers evaluate five concrete variables before accepting a project. Understanding these factors saves weeks of guesswork.

1. Protection Scheme Type

Chip vendors implement security at different levels. A simple read-protect fuse on an older 8-bit MCU is a fundamentally different challenge from a multi-layer encrypted boot sequence on a Cortex-M33 with TrustZone. The table below groups the most common protection types by typical difficulty.

If your chip uses only a security fuse to lock read access, the odds of successful IC decryption are significantly higher than if it relies on encrypted storage with an irreversible fuse.

2. Fabrication Process Node

Die geometry matters. Chips manufactured on 350 nm or 180 nm processes have larger feature sizes, making physical-layer analysis (FIB editing, micro-probing) practical with standard lab equipment. Below 90 nm, metal layers multiply (often 6–9 layers), interconnect pitch shrinks below 200 nm, and the cost and time for physical approaches escalate sharply. Below 28 nm, physical IC decryption is rarely economical outside state-level labs.

• ≥ 180 nm: Most 8-bit and many 16-bit MCUs. Physical approaches well-documented.
• 130–90 nm: Many ARM Cortex-M0/M3 parts. Selective success depending on vendor countermeasures.
• 65 nm and below: Newer Cortex-M4/M7, advanced RF SoCs. Non-invasive glitching or side-channel methods may still work; physical die attack is cost-prohibitive for most commercial projects.

3. Package and Die Access

IC decryption methods that require die exposure—UV erasure of OTP fuses, laser fault injection, micro-probing—depend on the package type. Plastic QFP and DIP packages are straightforward to decapsulate with fuming nitric acid or CNC chemical decap stations. Wafer-level chip-scale packages (WLCSP) and flip-chip BGA with copper pillar bumps are harder: the die is face-down, and removing the substrate risks destroying bond pads. Our die exposure and decapsulation process handles most plastic-encapsulated parts under 300-pin count with a success rate above 90% for physical access alone.

4. Chip Age and Vendor Revision

Vendors patch known vulnerabilities in silicon revisions. A PIC18F452 from 2005 may respond to a well-known timing attack, while the same part number manufactured after a 2012 mask revision may not. Date codes, lot numbers, and revision letters printed on the package all influence feasibility. We maintain an internal database covering revision-specific behaviors for over 4,000 part numbers across Microchip, STMicroelectronics, NXP, Renesas, TI, and Atmel families.

5. Available Attack Surface

Even a strongly protected chip may expose a vulnerability through its debug interface, bootloader UART, power supply rail, or clock input. Non-invasive techniques—voltage glitching, electromagnetic fault injection (EMFI), differential power analysis (DPA)—exploit these surfaces without opening the package. The broader the attack surface, the more options our engineers have.

• JTAG/SWD still partially enabled: Fastest path; sometimes a single glitch during RDP check is enough.
• UART/I²C bootloader present: Protocol-level exploits may bypass protection under specific timing conditions.
• No external debug at all: Must rely on physical or side-channel methods, increasing cost and turnaround.

Which IC Families Are Most Commonly Decrypted?

The table below lists families we work with regularly, along with typical turnaround and a general feasibility note. These are not guarantees—each project requires individual assessment.

For 8051-core parts from STC, see our dedicated STC MCU decryption technical guide covering STC89, STC12, STC15, and STC8 series specifics.

How the IC Decryption Process Works

Every engagement follows the same structured workflow, regardless of chip family.

1. Feasibility assessment (free): You submit the chip part number, date code, package photo, and a brief description of why recovery is needed. Our team cross-references our internal database and returns a feasibility opinion within 1–2 business days.
2. Authorization and NDA: You provide proof of IP ownership or a signed authorization letter. We execute a mutual NDA covering all data handled during the project.
3. Chip receipt and inspection: We receive the physical IC (or the entire PCB assembly), inspect markings, and confirm the silicon revision under a microscope.
4. Attack selection: Based on the five factors above, engineers choose the optimal method—non-invasive first, then semi-invasive, then invasive only if necessary.
5. Firmware extraction and verification: Extracted binary is verified via CRC comparison, disassembly spot-check, and—where possible—functional test on a blank device of the same part number.
6. Delivery: You receive the firmware image (Intel HEX or raw BIN), a brief technical report, and optional full code reading documentation if requested.

What IC Decryption Cannot Do

Setting realistic expectations avoids wasted time and money. IC decryption is not a universal skeleton key.

• RDP Level 2 on STM32: Irreversible. The flash content is erased if the protection is tampered with. No known recovery path.
• Chips with active mesh / tamper detection: Some secure elements (e.g., NXP SmartMX, Infineon SLE series) destroy key material on physical intrusion.
• Encrypted firmware without key recovery: If the AES key is stored in a one-time-programmable eFuse that self-destructs on read attempts, decryption yields ciphertext, not usable code.
• Severely damaged dies: Corrosion, ESD damage, or cracked dies may make probe contact impossible.

When physical extraction is impractical, a related approach—cloning the chip’s behavior via black-box analysis—may provide a functional equivalent without reading the original firmware byte-for-byte.

Legal and Ethical Framework

IC decryption occupies a legally sensitive space. We operate strictly within these boundaries:

• Work is performed only for the IP owner, the authorized licensee, or under a documented legal mandate (e.g., court-ordered forensic analysis).
• Every client signs an authorization declaration before we begin.
• We do not accept projects aimed at counterfeiting, circumventing DRM for redistribution, or extracting trade secrets from a competitor’s product.
• All data is handled under NDA and destroyed from our systems within 30 days of delivery unless a retention agreement is in place.

Related reading

• Oct 2026AT90 Crack | Protection Levels & Firmware Recovery
• Oct 2026Texas Instruments IC Unlock | Families We Can Read
• Oct 2026AT90 Unlock | Feasibility, Cost & Lead Time