PIC Microcontroller Unlock: Code Protection Across All Families

Why PIC Microcontrollers Still Need Unlocking

Microchip’s PIC family has been shipping since the mid-1980s. Decades later, billions of PIC-based boards sit inside industrial controllers, medical devices, automotive modules, and consumer products. When a product reaches end-of-life and the original firmware source is lost, or when a legacy board must be duplicated for continued production, PIC microcontroller unlock becomes the only practical path forward.

Every PIC device contains one or more configuration words that control oscillator mode, watchdog behaviour, brown-out reset—and, critically, code protection. When the CP (Code Protect) bit is programmed, the device blocks external readout of flash or OTP memory through the normal ICSP (In-Circuit Serial Programming) interface. Understanding exactly what each bit blocks, and what it does not block, is the foundation of any unlock effort.

This article walks through the protection architecture of each major PIC family—PIC10/PIC12 baseline, PIC16 mid-range, PIC18 high-performance 8-bit, and PIC24/dsPIC 16-bit—then explains the methods used to recover firmware when those protections are active.

How PIC Code Protection Works: The Basics

Before diving into family-specific details, it helps to understand the common mechanism that Microchip uses across all PIC devices.

Configuration Words and the CP Bit

PIC configuration words are stored in a special region of non-volatile memory, typically at the top of the address space. A programmer writes these words during the initial flash cycle. The most important security-relevant bits include:

• CP (Code Protect) — prevents external read of program memory.
• CPD (Data Code Protect) — prevents external read of the EEPROM data area.
• WRT (Write Protect) — prevents self-write to specific flash blocks.
• WRTC (Configuration Write Protect) — prevents overwriting the configuration words themselves.

When CP is cleared (active-low on most families), the ICSP interface will return all zeros or all ones instead of the actual flash contents. The device still executes the code internally; only external readout is blocked.

ICSP and Debug Interfaces

PIC devices use a two-wire ICSP interface (PGC clock and PGD data) plus MCLR for high-voltage entry. Some newer parts also support a debug interface (ICD/REAL ICE), but code protection applies to debug readout as well. Unlike some ARM Cortex-M firmware readout scenarios where different debug-port lock levels exist, PIC protection is typically a single on/off gate per memory region.

PIC10 and PIC12: Baseline and Enhanced Baseline

Architecture Overview

PIC10F and PIC12F devices are the smallest members of the family. Baseline parts (PIC10F200, PIC12F508) use a 12-bit instruction word and have no interrupt capability. Enhanced baseline parts (PIC12F1822, PIC12F1840) use a 14-bit instruction word with more peripherals.

Protection Scheme

Baseline PIC10/PIC12 devices typically offer a single CP bit in the configuration word. When set, the entire program memory is unreadable through ICSP. There is no block-level granularity—it is all-or-nothing.

Unlock Considerations

Because these devices have very small die areas and simple process nodes (typically 350 nm or larger), they are among the most accessible targets for physical-layer techniques. The small flash array means fewer bits to recover, and the older fabrication process makes the transistor structures easier to image. However, the limited value of the firmware on a tiny 256-word device means that unlock is usually only justified when it controls a critical calibration routine or a proprietary communication protocol.

PIC16: Mid-Range Family

Architecture Overview

The PIC16F series is arguably the most popular PIC family ever produced. Devices like the PIC16F84A, PIC16F877A, and the newer PIC16F18xxx enhanced mid-range parts are found in everything from hobbyist projects to industrial motor controllers.

Protection Scheme

Older PIC16F devices (PIC16F84A, PIC16F628A) use a single CP bit. The PIC16F87xA series introduced block-level code protection, dividing program memory into two or four blocks, each with its own CP bit. This allows a developer to protect proprietary routines in one block while leaving a bootloader block readable.

Enhanced mid-range parts (PIC16F1xxx) added a dedicated Boot Block protection bit and separate EEPROM data protection (CPD). The configuration words also gained write-protect bits for each block.

Unlock Considerations

The PIC16F84A is historically significant because it was one of the first PIC devices subjected to widespread unlock research. Early methods exploited timing vulnerabilities in the ICSP protocol—glitching the voltage on MCLR during the read sequence to bypass the CP gate. Microchip patched these vulnerabilities in later silicon revisions, but the techniques established a template that influenced work on other MCU families.

For modern PIC16F1xxx devices, protocol-level attacks are generally ineffective. Recovery relies on semi-invasive or invasive techniques: UV exposure on windowed (JW) packages where available, or microprobing after die-level preparation on plastic-packaged parts.

When the target board also carries external memory, an EEPROM and flash data recovery step can supplement the MCU unlock by capturing calibration tables or configuration data stored off-chip.

PIC18: High-Performance 8-Bit

Architecture Overview

PIC18F devices brought a 16-bit instruction word, hardware multiplier, and significantly larger flash (up to 128 KB). They remain popular in USB, CAN, and Ethernet-enabled embedded systems. The PIC18F4550 (USB), PIC18F2580 (CAN), and PIC18F97J60 (Ethernet) are well-known representatives.

Protection Scheme

PIC18F devices have the most granular code protection in the 8-bit PIC lineup. Program memory is divided into multiple blocks (often 4 to 12 depending on total flash size), and each block has three independent protection bits:

• CPn — code-protect block n (read protect).
• WRTn — write-protect block n.
• EBTRn — external block table read protect for block n.

The EBTR bit is particularly interesting. Even when CP is cleared for a given block, EBTR prevents other blocks from reading that block using table-read instructions. This closes a loophole where an attacker could write a small stub into an unprotected block and use it to read protected blocks via internal table reads.

Boot Block and Configuration Protection

PIC18F parts also protect the boot block independently (CPB, WRTB, EBTRB) and offer WRTC to lock the configuration registers and WRTD to lock the EEPROM data area. A fully locked PIC18F device has every block code-protected, table-read-protected, write-protected, and configuration-write-protected—a total of 30+ individual bits on a large-flash part.

Unlock Considerations

The layered protection on PIC18F devices means that a simple voltage-glitch or timing attack on the ICSP port is not sufficient. Even if an attacker could somehow bypass CP on one block, EBTR prevents leveraging that block to read others. Practical PIC18F unlock therefore requires physical access to the die—either through decapsulation followed by UV flooding (to reset configuration fuses on older process nodes) or through microprobing of the flash array.

Some PIC18F parts (especially the “J” series like PIC18F67J60) use a single-voltage flash process that does not respond to UV erasure the same way as the traditional two-transistor cell. These devices require more advanced semi-invasive techniques. The process is conceptually similar to approaches used on Infineon XMC and TriCore series, where the protection cell architecture dictates the recovery method.

PIC24 and dsPIC33: 16-Bit Territory

Architecture Overview

PIC24F and PIC24H are Microchip’s 16-bit general-purpose MCUs, while the dsPIC30F and dsPIC33 families add DSP instructions. These devices have flash sizes up to 512 KB, run at up to 70 MIPS, and appear in motor control, power conversion, and audio applications.

Protection Scheme

PIC24 and dsPIC devices use a Flash Configuration Word system similar to PIC18 but with additional features:

• General Segment (GS) — the main program memory, divided into sub-segments with individual GSS bits.
• Secure Segment (SS) — an isolated region for sensitive code, with its own SSS protection bits.
• Boot Segment (BS) — a small protected boot area with BSS bits.
• JTAG Enable/Disable — controls debug access independently of code protection.

This segment-based architecture allows developers to place a secure bootloader in the boot segment, proprietary algorithms in the secure segment, and application logic in the general segment—each with independent read and write protection.

For a deeper look at the dsPIC-specific protection nuances, see the dedicated dsPIC code protection and recovery guide.

Code Guard and Security Levels

Microchip brands this feature as CodeGuard Security. Each segment can be set to one of three security levels:

1. No protection — full read/write access through ICSP and debug.
2. Standard Security — external read blocked, but the segment can still be erased and reprogrammed.
3. High Security — external read blocked, and the segment can only be bulk-erased (losing all contents).

At High Security, the only way to clear the protection is a full chip erase—which destroys the firmware you are trying to recover. This makes PIC24/dsPIC33 high-security parts among the harder PIC targets.

Unlock Considerations

Protocol-level attacks on PIC24 ICSP are impractical against Standard or High Security settings. The segment isolation means that even if one segment is unprotected, it cannot be used to read another segment’s flash. Physical techniques remain the primary path, and the smaller process geometries used in PIC24 (down to 130 nm on some parts) demand higher-resolution imaging and more precise probing than the older 8-bit families.

Engineers working on mixed-signal boards that combine a PIC24 with an external DSP may also need to explore TI TMS320 or ADI SHARC protection recovery in parallel, since firmware often spans multiple processors.

Comparison: Protection Across All PIC Families

Methods Used for PIC Microcontroller Unlock

Non-Invasive (Protocol-Level)

These techniques exploit weaknesses in the ICSP protocol implementation—voltage glitching, clock manipulation, or undocumented commands. They were effective on early PIC16F devices (notably the PIC16F84A and certain PIC16F87x revisions) but have been patched in all current silicon. Non-invasive methods leave the device intact and functioning.

Semi-Invasive (Die Exposure Without Probing)

The chip package is opened (decapsulated) to expose the silicon die. Techniques then include:

• UV flooding — intense ultraviolet light resets the configuration fuse cells to their unprogrammed (unprotected) state on older flash processes. After UV exposure, the device can be read normally through ICSP.
• Laser fault injection — a focused laser beam induces bit flips in the configuration register during a read cycle, temporarily disabling protection.

Semi-invasive methods require a chemical or mechanical decapsulation step but do not make physical contact with the die circuitry. They are the workhorse approach for PIC12, PIC16, and many PIC18 devices.

Invasive (Microprobing)

For devices where UV and laser methods are ineffective (newer process nodes, single-poly flash cells), microprobing stations contact individual metal traces on the die to read flash contents directly. This requires expensive equipment (FIB, probe stations) and deep knowledge of the die layout. It is typically reserved for high-value targets or PIC24/dsPIC33 parts at High Security.

The choice between these methods mirrors decisions made when unlocking other MCU families. For example, STC 8051-core MCU decryption also spans the full range from protocol attacks on older parts to physical techniques on newer ones, and AVR lock-bit and fuse recovery follows a similar escalation path.

Practical Workflow: From Board to Binary

A typical PIC microcontroller unlock project follows these steps:

1. Identify the exact part number — read the marking on the package. PIC part numbers encode the family, flash size, peripherals, and package. A PIC16F877A-I/P is very different from a PIC16LF877A-I/P (low-voltage variant) in terms of flash cell behaviour.
2. Read configuration words — connect a PICkit or compatible programmer and attempt a read. Even on a protected device, the configuration words themselves are usually readable, revealing which CP, CPD, WRT, and EBTR bits are active.
3. Assess the protection level — map the active bits to the device datasheet to determine what is blocked and what might still be accessible (e.g., unprotected blocks, EEPROM data area).
4. Select the unlock method — based on family, process node, and protection level, choose non-invasive, semi-invasive, or invasive techniques.
5. Recover and verify — read the firmware, compute checksums, and verify against known device behaviour. If the board also needs hardware duplication, the recovered hex file feeds into a complete PCB reverse engineering workflow.

Common Pitfalls

• Bulk-erasing a protected device — some engineers attempt to clear CP by performing a bulk erase, not realising this destroys the firmware. On PIC devices, bulk erase is the only way to clear code protection through the normal interface. Never erase before reading.
• Confusing WRT with CP — write protection prevents reprogramming but does not block readout. A device with WRT set but CP clear can be read normally.
• Ignoring EBTR on PIC18 — even if one block is unprotected, EBTR prevents using it as a read stub. Both CP and EBTR must be addressed.
• Assuming all PIC16F parts are identical — silicon revisions within the same part number can change the flash cell structure and the effectiveness of UV-based methods.

When PIC Unlock Is Part of a Larger Project

In many real-world scenarios, PIC microcontroller unlock is just one step in recovering a complete product design. An industrial control board may pair a PIC18F with an FPGA, external flash, and a complex multilayer PCB. Recovering the full system may involve FPGA bitstream extraction alongside MCU firmware readout, plus schematic and Gerber recovery from the board itself.

Designers who want to prevent this kind of recovery should study the twelve measures used to protect boards from reverse engineering, which covers both hardware obfuscation and firmware protection strategies.

Key Takeaways

• PIC code protection is controlled by configuration-word bits (CP, CPD, WRT, EBTR) that vary in number and granularity across families.
• PIC10/PIC12 devices have the simplest protection (single CP bit) and the most accessible die structures.
• PIC16 mid-range parts introduced block-level protection; early revisions had protocol vulnerabilities that are now patched.
• PIC18 added table-read protection (EBTR), closing the internal-read loophole.
• PIC24 and dsPIC use CodeGuard Security with three segments and three security levels, making High Security the hardest PIC target.
• The unlock method escalates from protocol-level to semi-invasive to invasive as the device family and process node advance.
• Never bulk-erase a protected PIC before attempting readout—the firmware will be destroyed.

Related reading

• Sep 202628-Layer PCB Reverse Engineering | Key Challenges
• Sep 2026Gerber Generation From PCB: Fab-Ready Data Without CAD
• Sep 2026Renesas RH850 Unlock | Feasibility, Cost & Lead Time