-
Product Categories
-
Live Support Chat
MCU Crack Service
MCU cracking is the recovery of the program image from a microcontroller whose code is protected. The deliverable is almost always a heximal or binary file plus the information needed to load it back into a toolchain — not a magic number that makes a device fall open.
Because the term covers a very wide range of difficulty, the useful question is not “can you crack it” but “which of the four attack classes applies to my specific part and die revision”. We answer that question first, in writing, before any destructive work.
The four attack classes
| Class | What it uses | Device condition afterwards |
|---|---|---|
| Interface attack | Debug port, bootloader, in-system programming path, update channel, silicon errata | Unchanged and fully functional |
| Side-channel attack | Power consumption or electromagnetic emission analysed while the device processes known data | Unchanged and fully functional |
| Semi-invasive attack | Package opened, then optical or laser injection against the protection state machine | Functional but package opened |
| Invasive attack | Micro-probing, FIB modification or direct array read on the die | Usually non-functional; deliverable is the code |
Families and typical methods
| Family | Typical protection | Usual route |
|---|---|---|
| 8051 derivatives (AT89, P89, W78, STC, Nuvoton) | Security fuse or lock bits | Fuse analysis, sometimes direct read |
| Microchip PIC10–PIC32, dsPIC | Code-protect and config fuses | Interface or config manipulation |
| Atmel/Microchip ATmega, ATtiny | Lock bits plus fuse | Interface attack on most revisions |
| STM32 and GD32 Cortex-M | RDP level 1 / level 2 | Interface attack at level 1; invasive at level 2 |
| MSP430, CC253x, CC26xx | JTAG fuse, BSL lock | Interface attack, occasionally semi-invasive |
| Legacy and Asian-market MCUs | OTP or security fuse | Invasive access to the array |
What you receive
- The recovered code as heximal (Intel HEX) or raw binary, depending on what your toolchain expects
- Load address, memory map and, where determinable, the original compiler family and memory model
- A verification statement: checksum of the recovered image and how it was validated against expected behaviour
- A written record of the protection found and the method applied, including whether the method is repeatable on further units of the same batch
Frequently asked questions
How long does it take and what does it cost?
An unprotected or lightly protected part is typically one to three working days. A read-out protected ARM or PIC part with a known method runs three to ten working days. A device requiring new method development is a research project measured in weeks, and we will tell you before starting whether it is worth doing at all.
Can you guarantee success?
No, and be cautious of anyone who does. The same part number can ship in several die revisions with different protection strength. We assess the actual die, then report the probability honestly — including a recommendation not to proceed when the odds do not justify the cost.
What do you need from me to start?
The part number, the quantity, the package, and ideally a working board so that the device sees its normal clock and boot environment. If you have already attempted an extraction and failed, tell us — knowing which methods have been tried saves both time and money.
Do you need to know what the firmware does?
No. The extraction is independent of function. Knowing the target architecture does help, though, because it tells us what memory layout and load address to expect, which makes verification of the recovered image much stronger.
Can you also modify the recovered firmware?
That is a separate piece of work. Disassembly, patch development and re-flashing are all available, but they are quoted separately because the difficulty depends entirely on the codebase rather than on the extraction.
Send a device for assessment
Provide the part number, the package, the quantity, and what you intend to do with the recovered code. We will confirm the protection type, the attack class that applies, the realistic probability of success, and the turnaround — before anything destructive happens. Work is accepted only where the requester can demonstrate ownership or written authorisation.