What Is an MCU Crack and When Is It Needed?
An MCU crack is the process of bypassing a microcontroller’s read-out protection to extract the firmware stored in its internal flash or OTP memory. The extracted binary—typically a .hex or .bin file—can then be used for authorized purposes: recovering lost source code you own, maintaining legacy equipment, or verifying production firmware against a known-good reference. Whether an MCU crack is feasible on a given part depends on five concrete, measurable factors that our engineers evaluate during every incoming assessment.
The Five Factors That Determine MCU Crack Feasibility
1. Read-Out Protection Level
Most modern MCUs implement tiered protection. ST’s STM32 family, for example, defines three levels:
- RDP Level 0 — No protection. Flash is freely readable via SWD/JTAG. No crack needed.
- RDP Level 1 — Debug access is blocked, but the protection can often be reversed through known attack vectors without destroying data, depending on the specific die revision.
- RDP Level 2 — Permanent. The debug port is physically disabled by blowing internal fuses. Recovery typically requires invasive die-level techniques and success is not guaranteed on all process nodes.
Other vendors use different nomenclature—Microchip PIC calls it Code Protect (CP), Renesas uses the ID Code—but the principle is the same: the higher the protection tier, the more complex and uncertain the MCU crack becomes. Our engineers maintain a continuously updated database covering over 4,000 MCU part numbers with their observed protection behavior.
2. Silicon Process Node
Older MCUs fabricated on 350 nm or 180 nm processes have larger feature sizes, making physical probing and fault injection more practical. Parts built on 90 nm, 55 nm, or 40 nm nodes shrink the attack surface dramatically. A 40 nm flash cell is roughly 0.003 µm² versus 0.1 µm² on a 350 nm process—over 30× smaller. This matters because many MCU crack techniques rely on UV exposure, voltage glitching, or micro-probing, all of which become harder as geometry shrinks.
3. Fuse and OTP Configuration
Security fuses are one-time-programmable bits that gate access to flash readout, JTAG, and boot-mode selection. Once blown, they cannot be reset electrically. The number, placement, and redundancy of these fuses vary by vendor and even by die revision within the same product family. Some MCUs use a single fuse bit; others use redundant pairs with cross-checking logic that defeats simple glitch attacks. During our feasibility check, we identify the exact fuse map for your specific part number and revision code.
4. Package Type and Die Accessibility
Invasive MCU crack methods—decapsulation, FIB (Focused Ion Beam) editing, micro-probing—require physical access to the silicon die. Package type affects both cost and risk:
| Package | Decap Difficulty | Die Damage Risk | Typical Added Cost |
|---|---|---|---|
| PDIP / SOIC | Low | Low | Minimal |
| QFP / TQFP | Low–Medium | Low | $50–$150 |
| QFN / DFN | Medium | Medium | $100–$300 |
| BGA / WLCSP | High | High | $200–$600+ |
BGA and wafer-level CSP packages expose the die from the bottom side, which can complicate acid decapsulation and increase the chance of bond-wire damage. If your target MCU is in a BGA package, plan for the possibility of needing multiple samples. Learn more about the physical process in our IC decapsulation service overview.
5. Vendor Generation and Known Vulnerabilities
Security implementations evolve across product generations. Early STM32F1 devices had well-documented RDP Level 1 bypass paths. Later families like the STM32H7 introduced TrustZone, secure boot chains, and encrypted flash regions that substantially raise the bar. Similarly, Microchip’s dsPIC33C line added enhanced code-guard partitions absent from earlier dsPIC30F parts.
Our success rate on STM32F1 series MCU cracks exceeds what we see on newer families like the STM32H7 series, where RDP Level 2 combined with a 40 nm process makes non-invasive recovery far less predictable.
Common MCU Crack Techniques Ranked by Invasiveness
| Technique | Invasiveness | Typical Turnaround | Best Suited For |
|---|---|---|---|
| Voltage glitching / power analysis | Non-invasive | 3–7 working days | MCUs with single-fuse RDP L1 |
| Boot-loader exploit | Non-invasive | 2–5 working days | Parts with known ROM-boot vulnerabilities |
| UV exposure (older EPROM/OTP) | Semi-invasive | 1–3 working days | Legacy 8-bit MCUs (PIC16, AT89C51) |
| Micro-probing after decap | Invasive | 7–15 working days | High-value targets with redundant fuses |
| FIB circuit edit | Highly invasive | 10–20 working days | Advanced MCUs with encrypted flash |
Non-invasive approaches are always attempted first because they preserve the original device and cost less. If those fail, we escalate—with your approval—to semi-invasive or invasive paths. Each escalation step is quoted separately so you control budget exposure.
How We Evaluate Your MCU Crack Request
- Part identification — You send the full part number, revision/date code, and package marking photos. We cross-reference our internal database.
- Protection-level assessment — Using a debug probe (J-Link, ST-Link, or vendor-specific), we attempt to read the protection register. This tells us the active protection tier.
- Feasibility report — Within 1–2 working days we return a written assessment: estimated success probability, recommended technique, turnaround range, and cost bracket.
- Authorization verification — We require proof of ownership or a signed NDA/authorization letter before proceeding. This step is non-negotiable.
- Extraction and verification — Firmware is read out, checksummed, and optionally programmed into a blank device for functional verification.
The deliverable is a .hex or .bin file matching the original flash contents. For related services covering broader IC types, see our IC crack service page.
What Can Go Wrong — Honest Constraints
No responsible lab promises 100% success on every MCU crack. Here are real failure modes we encounter:
- Die damage during decapsulation — Acid over-etch or thermal shock can sever bond wires, especially on QFN and BGA packages. We mitigate this by using laser decap on high-value parts, but risk is non-zero.
- Redundant fuse structures — Some newer MCUs verify fuse state from multiple locations on the die. Defeating one fuse without the other triggers a security lockout or flash erase.
- Encrypted flash — If the MCU stores firmware encrypted with a device-unique key derived from PUF (Physical Unclonable Function), reading raw flash yields ciphertext, not usable code.
- Anti-tamper sensors — Certain automotive and payment-grade MCUs include active mesh layers or voltage/temperature monitors that wipe flash on tamper detection.
When our feasibility report flags any of these risks, we state them plainly so you can make an informed go/no-go decision.
MCU Families We Handle Most Frequently
The table below lists families where we have extensive experience and documented success paths. For specific protection-level details on STM32 sub-families, follow the links:
- STM32F0 series — Cortex-M0, RDP L1 bypass well-characterized
- STM32F4 series — Cortex-M4F, multiple die revisions with varying glitch susceptibility
- Microchip PIC16 / PIC18 / dsPIC30 — Mature UV and glitch paths
- Atmel/Microchip ATmega / ATxmega — Lock-bit bypass via high-voltage parallel programming exploits
- NXP LPC1xxx / LPC2xxx — CRP levels 1–3; CRP3 is often unrecoverable
- Renesas RH850 / RL78 — ID code protection; feasibility depends on mask version
If your MCU isn’t listed, submit it for evaluation. Our database covers over 4,000 part numbers, and we add new entries weekly.
Authorization and Legal Requirements
Every MCU crack engagement requires documented authorization. We accept purchase records, design-ownership declarations, or a signed letter from the IP holder. This protects both parties and ensures the work stays within the bounds of legitimate firmware recovery, not IP theft. For full details on our compliance framework, review our microcontroller unlock authorization requirements.
Check feasibility for your project
Send the chip marking or board details and tell us what you need to recover. Add clear photos if available.
Request a feasibility reviewIs an MCU crack possible if the chip uses RDP Level 2?
RDP Level 2 permanently disables the debug interface. Recovery is theoretically possible through invasive die-level techniques—micro-probing or FIB editing—but success depends on the process node and fuse redundancy. On 180 nm and larger nodes, we have documented successful extractions. On 40 nm nodes with redundant fuses, the probability drops significantly. We always disclose the realistic odds in our feasibility report before you commit.
How many sample chips should I provide for an MCU crack?
For non-invasive methods, one device is usually sufficient. For invasive approaches that involve decapsulation, we recommend providing 2–5 samples. BGA-packaged parts carry higher decap risk, so 3–5 samples is the safer minimum. If only one sample exists, we can still attempt recovery but the margin for error is tighter.
What file format will I receive after a successful MCU crack?
The standard deliverable is a .hex (Intel HEX) or .bin (raw binary) file containing the full flash contents. If the MCU has separate EEPROM, that data is extracted as a second file. We also provide a SHA-256 checksum and, on request, a verification report showing the firmware programmed into a blank device and tested for basic function.
How long does an MCU crack typically take?
Non-invasive methods complete in 2–7 working days after authorization is confirmed. Semi-invasive (UV, partial decap) adds 1–5 days. Fully invasive paths—decap plus micro-probing or FIB—range from 7 to 20 working days depending on die complexity and the number of samples available.
Does voltage glitching damage the MCU?
Voltage glitching is classified as non-invasive because it does not require opening the package. However, repeated glitch attempts can stress the power regulator or flash charge pump. In rare cases this causes permanent flash corruption. We mitigate this by using controlled pulse parameters calibrated per MCU family, but the risk is non-zero—another reason to supply a backup sample when possible.
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