Decap C016: GMS' MJ-DFMJ (PIC16F84)

We got this PCB:

Sounds like there's some debate as to what this game is called, and we couldn't find much info elsewhere about it either. The EPROM's have "MJ-DFMJ" stickers, so we're rolling with that for now.

It has a secured PIC16F84 here:

A sample PIC16F84 was decapped to yield:

With the main memory areas as:

We then live decapped a few:

And put them into a UV EPROM eraser but, while flash and EPROM were erased, the security fuse was not. No dice either using angled erasure even with varying angles and long erasure time.

Time to regroup. Where are the fuses on the die? These seem like a good candidate:

Such that the metal rectangles are shielding. Configuration words correspond to 4 14 bit (56 bit total) user configurable words and 1 general configuration word that's either 4 or 14 bits depending on how literally you interpret the datasheet. The left grouping has 6 * 8 rectangles above and 2 * 3 rectangles below = 54. Close, but not quite right. This area is still plausible if you count adjacent rectangles, but more likely these are capacitors for ADC or something of that sort.

But not to worry. Part of the reason we agreed to do this part is that there are several known attacks against it. First, there are voltage glitching attacks. Second, the same author also mentions that PIC16F84 is vulnerable to optical glitching (pg 104): "The light from the 20 W halogen bulb installed inside our probing station microscope’s illuminator".

Optical glitching is somewhat straightforward to try out, so we started with that. One risk with optical glitching though is that it can cause the chip to latchup (short out), destroying it. Fortunately we have a high end programmer that cuts power if it detects unusual power draw. Anyway, first a sample chip was decapped live. Then, we enabled protection and started repeatedly reading the chip. At the same time we shined a red 5 mW laser pointer randomly across the die and observed responses. Unfortunately, this didn't do much...maybe gave a few bad reads. However, we re-tried with a green 5 mW laser pointer and got it to dump its contents despite being protected!

Unfortunately, this was really hard to reproduce. Fortunately Tim the Toolman Taylor taught us the solution to every problem: MORE POWER! We switched to a 200 mW 650 nm red laser and got more reliable dumps.

We were able to roughly narrow it down to the lower right of the die (relative to above images) but for various reasons decided to get more specific information. Targeting a region also reduces the chances of latchup, although tests showed that the programmer was sufficiently protecting against everything we tried.

Towards that goal we put the sample on our microscope XY stage and tried to trigger glitches using its illuminator. Unfortunately, we were unable to get any responses at all, protection or otherwise. However, we know the high power red laser works reliably. So we mounted it to the microscope XY stage and recorded responses. This roughly gave:

Where:

• Red: power out of spec / overcurrent shutdown
• Green: protection disabled
• Gray (hard to see): no response
• The left and bottom (beyond the red/gray) are not entirely in the scan

Close up of this region:

There are 14 repeated units, so its plausible this is the configuration word. Presumably shining the laser here forces the entire configuration word to all 1's, unlocking the chip.

With this in mind we decapped the real PIC16F84 and repeated the attack, successfully dumping its flash and EEPROM. Victory!

We also did a few follow up experiments. First, we added neutral density filters to the high power red laser, attenuating the beam by 64x (ie <5 mW), and was still able to dump. Second, we re-tried microscope illumination glitching and were able to get this region to glitch:

Which is in this area:

Shrinking the region or moving away removes the glitch. Other regions may work; it wasn't investigated thoroughly. 100x magnification was required at max power (50W bulb, no polarizers, etc).

We also have an AT89C51 in the pipeline from the same board, but are hitting a snag related to getting samples successfully programmed. Hopefully this will be resolved soon and we'll shortly have a follow up post.

Special thanks to EdHunter for supporting this project!

Enjoy this post? Please support us on Patreon! Note: with the Indiegogo campaign over we unfortunately don't currently have a way to accept one time donations.