Normally you can’t read out the One Time Programming (OTP) memory in Microchip’s PIC MCUs that have code protection enabled, but an exploit has been found that gets around the copy protection in a range of PIC12, PIC14 and PIC16 MCUs.
This exploit is called PIC Burnout, and was developed by [Prehistoricman], with the cautious note that although this process is non-invasive, it does damage the memory contents. This means that you likely will only get one shot at dumping the OTP data before the memory is ‘burned out’.
The copy protection normally returns scrambled OTP data, with an example of PIC Burnout provided for the PIC16LC63A. After entering programming mode by setting the ICSP CLK pin high, excessively high programming voltage and duration is used repeatedly while checking that an area that normally reads as zero now reads back proper data. After this the OTP should be read out repeatedly to ensure that the scrambling has been circumvented.
The trick appears to be that while there’s over-voltage and similar protections on much of the Flash, this approach can still be used to affect the entire flash bit column. Suffice it to say that this method isn’t very kind to the Flash memory cells and can take hours to get a good dump. Even after this you need to know the exact scrambling method used, which is fortunately often documented by Microchip datasheets.
Thanks to [DjBiohazard] for the tip.
The OG Xbox scene is the gift that keeps on giving
You can always resort to Bunnie’s trick of etching open the package, carefully covering the ROM on the chip with tape, then zapping the chip with UV light to reset the OTP fuses…
https://www.bunniestudios.com/blog/hacking-the-pic-18f1320/
Indeed, that is the other well-known hack. A few friends from the Xbox scene tried that already on the PIC16LC63A and had no luck, having issues with device reliability after decap and trouble erasing the protection bits.
It’s funny to me because PIC and AVR OTP use Flash registers as logical fuses, and there’s test modes for dumping the program flash regardless of OTP status.
For PIC the test mode entry is triggered by half-clock pulses, and AVR uses half-voltage pulses similarly. The exact pattern varies by mask family, of course. If you build a basic programmer that let’s you do those, you can brute force the sequence easily enough.
Is there more information regarding the approach for the AVRs available? Sounds very interesting and I have an ATmega88 which’s firmware I wanted to reverse for years…
Can you give a source for information about that PIC test mode? I can only find a hint towards it in a datasheet.
Pic12 and 14 were routinely hacked since at least 2003 by spiking supply voltage during fuse read/write operation, thats when I was cloning pic based phone unlock dongles…untill they caught a wind of it and switched to AVR(atmega16 anyone?) and etching case open then zapping exposed die was the only way.
I can confirm that. I’ve worked for a flash programming company back in the days and had to implement the test mode readout for a “special customer”.