Microchip PIC12F683 teardown

I'm going to kick off the meat of this blog with a teardown of a chip that has a special place in my memories - the first microcontroller I ever worked with, the Microchip PIC12F683. It's an 8-bit RISC microcontroller made on what looks like a 350nm 3-metal process, with 14 bit wide instructions and a fairly nice set of peripherals:

• 2K words program Flash
• 128 bytes SRAM
• 256 bytes data EEPROM
• Two 8-bit and one 16-bit timer
• Four-channel multiplexed 10 bit A/D converter
• Comparator

I decapped one of these a few months ago and imaged it at 400x magnification. Pin 1 is at the top left. (At the time I was still experimenting with panorama stitching techniques so there are a few alignment glitches.)

PIC12F683 metal 3 with passivation, magnified 400x

The glass layer (reddish) was quite annoying and made it hard to resolve traces so I decided to remove it using my standard wet-etch procedure (heating in 3% HF). I'll be writing about this process in more detail over the weekend.

PIC12F683 metal 3 after wet etching, magnified 400x

We now have enough information to create a floor plan of the chip:

• The large block at bottom center (surrounded by power rails with 14 white capacitors at the bottom) is the program flash. Each capacitor is part of a charge pump used to generate high voltage for erasing one bit of flash.
• Immediately to the left is the RAM.
• Above the RAM is the EEPROM. As with the flash, there is one capacitor per bit of memory for high voltage generation.
• Above the flash, and slightly to the right, are the configuration fuses. Each of the small red plates is part of a single configuration bit.
• Analog peripherals are in an L-shape along the top and right sides

Top portion of PIC12F683 configuration fuse array (metal 3 after etching off glass)

The configuration fuses are single cells of EEPROM-style memory storing data such as the clock oscillator source and code / data protection bits. As with most other PICs, when the protection bit is in the "1" state the chip operates as normal; in the "0" state attempts to read firmware or EEPROM respectively via ICSP return all zeros. Configuration fuses can always be read.

EEPROM is typically susceptible to erasure (all bits set to 1) by strong UV light and the configuration fuses are no exception. If we can expose just the fuses (and not the flash or EEPROM, whose data we presumably want intact) to UV, the code protection can be removed and the firmware reverse-engineered using standard software RE tools. Note that PICs are thus a slightly easier target than Atmel chips. Atmel fuses in the "1" state indicates the chip is in the locked state (i.e. UV will set rather than clear the fuse).

Enough talking, time to try pwning the chip! As of this writing my decapping lab is offline, but Brooke Hill from Jimnson Research was kind enough to decap a few samples I sent him.

Decapped PIC12F683, magnified 10x. Rotated 90 degrees counterclockwise from other photos.

The first step was to plug the chip into a breadboard and verify it still worked. (Although decapping is normally a fairly low-risk procedure, bond wires do occasionally work loose during the rinse or cleaning steps.) The test firmware I used was a short piece of assembly that blinked an LED on GP2, and had the code-protection bit set.

I then laid down a mask over the memory areas I wanted to protect. I used the old classic, black nail polish applied with a lint-free swab under a stereo microscope. The brand of polish I purchased turned out to be very thick and gooey; in the future I intend to thin it with acetone for a more even coating.

Halfway through applying the mask

At this point the difficult work was over. I placed the chip inside my homemade UV erasure box, powered by two germicidal fluorescent bulbs.

UV exposure system

Two hours later the PIC was removed from UV and put back in the breadboard. I attempted to verify memory integrity with my PICKit 2.

Success! Program memory and EEPROM are undamaged (and unprotected) while configuration fuses read as all 1s.

Although the code protection on the PIC12F683 is clearly broken I am not finished with it; as an educational subject has not outlived its usefulness. Stay tuned for a future post with gate- and transistor-level analysis of interesting areas!