Copy protection removal is the authorized extraction of firmware from a microcontroller whose read-protection fuses or option bytes have been set, preventing standard debug-port readout. Our engineers defeat these protection mechanisms — across STM32, PIC, AVR, dsPIC, and dozens of other families — and deliver the recovered binary as a clean .hex or .bin file, typically within 5–15 working days. The service exists for owners who have lost source code, need to maintain legacy hardware, or must migrate firmware to a replacement MCU.
What Exactly Is Copy Protection on a Microcontroller?
Nearly every modern MCU ships with configurable read-protection. The silicon vendor provides one or more protection levels — sometimes called RDP levels (STM32), Code-Protect bits (PIC), or lock bits (AVR) — that block external access to the internal Flash, EEPROM, or OTP memory through JTAG, SWD, ICSP, or ISP interfaces.
When protection is active, connecting a standard programmer returns either all-0xFF (blank reads) or triggers a mass-erase before unlocking the debug port. Copy protection removal circumvents this gate without destroying the stored firmware, using techniques that vary by chip architecture and protection tier.
Common Protection Levels
| Vendor / Family | Protection Scheme | Levels | Removal Feasibility |
|---|---|---|---|
| ST STM32F1/F3/L0/L4/G4 | RDP Level 0/1/2 | 3 | Level 1: high success; Level 2: case-by-case |
| Microchip PIC12/16/18 | CP, CPD, WRT bits | 2–4 | High success on most variants |
| Microchip PIC24/PIC32/dsPIC | Code-Protect + Write-Protect | 2–3 | Moderate to high; PIC32 MZ series is harder |
| Atmel/Microchip AVR (ATmega/ATtiny) | Lock bits (LB1/LB2/LB3) | 3 | High success through LB2; LB3 is limited |
| Atmel AT89C51/AT89S52 | Lock Bit 1/2/3 | 3 | LB1–LB2: high; LB3 restricts verify |
| Atmel ATxmega | Security bit + boot lock | 2 | Moderate; depends on revision |
RDP Level 2 on STM32 parts, for instance, permanently disables the debug port at the hardware level. Recovery from Level 2 requires invasive die-level techniques and is not always possible — we provide an honest feasibility assessment before quoting. For STM32F3 RDP-level recovery, Level 1 extraction typically succeeds within 7 working days.
How Copy Protection Removal Works — Method Overview
There is no single universal bypass. Our lab selects the technique based on the specific MCU die, its revision, and the protection tier engaged. The three broad categories:
1. Non-Invasive (Electrical / Protocol-Level)
- Glitch attacks: Precisely timed voltage or clock glitches during the boot sequence can cause the protection-check routine to skip, opening a brief read window. Effective on many STM32 Level 1 and older PIC parts.
- Bootloader exploits: Some factory bootloaders contain known vulnerabilities that allow partial or full Flash readout even when protection bits are set. These are revision-dependent — a chip manufactured in 2019 may respond differently from the same part number made in 2023.
- Side-channel analysis: Power-trace or EM-emission analysis can leak key bytes or protection-state information, aiding targeted glitch placement.
2. Semi-Invasive (Package-Level)
- UV exposure: Older EPROM-window and some OTP parts allow protection bits to be reset with controlled UV light without erasing program memory — effective on classic AT89C51 lock bits and certain PIC12 code-protect configurations.
- Laser fault injection: A focused IR or visible laser targets specific transistors in the security logic. Requires decapping but does not damage Flash arrays when performed correctly.
3. Invasive (Die-Level)
- Chemical decapping + micro-probing: The die is exposed with fuming nitric acid or laser decapping, then security fuses are physically bridged or bus lines are probed directly. This is the last resort for high-protection parts and carries a 70–90 % success rate depending on die geometry (90 nm and below is significantly harder).
- FIB (Focused Ion Beam) editing: For sub-100 nm nodes or multi-layer metal stacks, FIB can cut or reconnect specific traces to disable protection logic. Turnaround is longer (15–25 working days) and cost is higher.
For AVR-family parts like ATmega and ATtiny, non-invasive glitch attacks resolve the majority of cases. Details on lock-bit behavior for ATmega protection removal and ATtiny lock-bit bypass are covered in our chip-specific guides.
Deliverable Formats After Copy Protection Removal
Once firmware is extracted, we verify the binary against known checksum patterns (where available) and deliver it in the format you need:
| Format | Description | Typical Use |
|---|---|---|
| .hex (Intel HEX) | ASCII-encoded, address-tagged records | Direct programming via MPLAB, STM32CubeProgrammer, avrdude |
| .bin (raw binary) | Flat memory image, no address metadata | Bootloader flashing, DFU upload, production gang programmers |
| .s19 (Motorola S-record) | Address + data records, common in automotive | NXP/Freescale toolchains, legacy programmers |
| EEPROM dump (separate file) | Non-volatile data section extracted independently | Calibration tables, serial numbers, configuration |
If the target MCU stores calibration data in a separate EEPROM region (common on dsPIC and PIC24 parts), we extract it as a second file. For dsPIC33F code-protect removal, both program Flash and data EEPROM are included in the standard deliverable.
What Can Go Wrong — Honest Limitations
We do not guarantee 100 % success on every chip. Transparency about failure modes is part of our process:
- Permanent protection (STM32 RDP Level 2, some PIC32 MZ): Debug access is irreversibly disabled at silicon level. Invasive die-level work may still recover data, but success depends on metal-layer count and node geometry.
- Encrypted firmware: Some newer MCUs (STM32L4 with PCROP, STM32H7 secure boot) encrypt Flash contents. Even if raw bytes are read out, the data is useless without the AES key. We will tell you upfront if encryption is in play.
- Die damage during decapping: Chemical or mechanical decapping risks bond-wire detachment or passivation cracking. Our lab uses automated acid-dispensing rigs with <50 µm accuracy, but the risk is non-zero on BGA or WLCSP packages.
- Anti-tamper mesh: A handful of secure-element ICs (not typical MCUs) include active mesh layers that erase memory on physical intrusion. These are outside our standard service scope.
We run a no-charge feasibility check before committing. If the part cannot be recovered, you pay nothing.
Authorization and Legal Requirements
Copy protection removal is performed exclusively for authorized parties — the firmware owner, the original equipment manufacturer, or a licensee with documented rights. Before work begins, we require:
- Proof of ownership or written authorization from the IP holder.
- A signed NDA covering all extracted data.
- Confirmation that the work is for legitimate purposes: legacy maintenance, end-of-life component replacement, or authorized production continuity.
We do not assist with cloning third-party proprietary firmware for unauthorized reproduction. Our full policy and NDA framework are detailed on our trust and compliance page.
Typical Turnaround and Pricing Signals
| Complexity Tier | Example Chips | Turnaround | Starting Price Range |
|---|---|---|---|
| Standard | ATmega328, PIC16F877A, AT89S52 | 5–8 working days | $300–$600 |
| Moderate | STM32F103 RDP1, PIC18F46K22, dsPIC30F | 7–12 working days | $500–$1,200 |
| Advanced | STM32L4 RDP1, PIC32MX, ATxmega128A1 | 10–20 working days | $1,000–$2,500 |
| Invasive / FIB | STM32 RDP2, PIC32MZ, secure-boot parts | 15–30 working days | Quote required |
Pricing depends on the specific part number, protection level, and quantity. Volume orders (programming recovered firmware onto 100+ blank chips) receive discounted per-unit rates.
How to Request Copy Protection Removal
- Submit your chip details: Part number, package type, protection level (if known), and quantity. Upload any available datasheets or programmer error logs.
- Feasibility assessment: Our engineers evaluate the target within 1–2 working days and report expected success probability, method, and timeline.
- Ship the sample: Send 1–3 programmed chips (we recommend spares in case of invasive work). We provide shipping labels for trackable international courier.
- Extraction and verification: Firmware is read, checksummed, and verified against expected code size. Delivered as .hex, .bin, or both.
- Secure handoff: Files are transferred via encrypted channel. Physical chips are returned or securely destroyed per your instruction.
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 reviewCan copy protection removal damage my chip?
Non-invasive methods (glitching, bootloader exploits) do not damage the chip — the original part remains functional. Semi-invasive and invasive methods (decapping, micro-probing, FIB) physically alter the package and may render that specific unit non-functional, which is why we request 2–3 sample chips when invasive work is anticipated.
What if my MCU has encrypted firmware, not just read-protection?
Read-protection and encryption are different mechanisms. Copy protection removal bypasses the debug-port lockout to read raw Flash contents. If those contents are AES-encrypted (as on some STM32L4 PCROP or STM32H7 secure-boot configurations), the extracted binary will be ciphertext. We identify encryption during feasibility assessment and advise whether decryption is viable.
Do I need to provide proof of ownership?
Yes. We require written proof that you own the firmware IP or have authorization from the IP holder. This can be a purchase invoice for the original design, a letter of authorization, or equivalent documentation. A mutual NDA is signed before extraction begins.
Which file format should I choose — .hex or .bin?
If you are programming chips using vendor tools (STM32CubeProgrammer, MPLAB IPE, avrdude), .hex is usually more convenient because it carries address information. If you are flashing via a bootloader, DFU utility, or gang programmer that expects a flat image, .bin is the right choice. We can deliver both at no extra cost.
Is copy protection removal the same as cracking or hacking?
The underlying technical methods overlap, but the legal context is entirely different. Our service is restricted to authorized firmware recovery — restoring access to code you own or are licensed to use. We do not assist with unauthorized reproduction of third-party IP, and every engagement is covered by NDA and ownership verification.
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