Post by thread:[PIC]: Code protect is not secure!

We have been programming our OTP chips with code protect using the PicStart Plus. This makes the chip un-writeable and if you try to read it with the PicStart Plus it fails. That sounded good. We recently acquired a hi end universal chip programmer, we programmed a 16c54 with code protect enabled, then we tried to read it with the hi end programmer and it read the code. We where shocked to see that the hex file was easy to view and save to floppy, it was all there. We took the chip over to the PicStart and tried to read it and it failed. What is the point in code protect if all you need is a $10k programmer to circumvent the security. We have not tested this with any other chips then the 16c54 but we will and I will post more info as we find out. I reposted this because I forgot to modify the subject for [PIC]: -- Roy Souther <spam_OUTroyTakeThisOuTsilicontao.com> 01100010 10101110 11000110 11010110 00000100 10110010 10010110 11000110 01001110 11110110 11001110 00010110 10010110 00101110 10000100 10000100 -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestKILLspam@spam@mitvma.mit.edu

Just a thought, but did you clear the screen before reading back? Regards, Kevin -----Original Message----- From: pic microcontroller discussion list [PICLISTKILLspamMITVMA.MIT.EDU]On Behalf Of Roy Souther Sent: 18 September 2001 16:22 To: .....PICLISTKILLspam.....MITVMA.MIT.EDU Subject: [PIC]: Code protect is not secure! We have been programming our OTP chips with code protect using the PicStart Plus. This makes the chip un-writeable and if you try to read it with the PicStart Plus it fails. That sounded good. We recently acquired a hi end universal chip programmer, we programmed a 16c54 with code protect enabled, then we tried to read it with the hi end programmer and it read the code. We where shocked to see that the hex file was easy to view and save to floppy, it was all there. We took the chip over to the PicStart and tried to read it and it failed. What is the point in code protect if all you need is a $10k programmer to circumvent the security. We have not tested this with any other chips then the 16c54 but we will and I will post more info as we find out. I reposted this because I forgot to modify the subject for [PIC]: -- Roy Souther <EraseMEroyspam_OUTTakeThisOuTsilicontao.com> 01100010 10101110 11000110 11010110 00000100 10110010 10010110 11000110 01001110 11110110 11001110 00010110 10010110 00101110 10000100 10000100 -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestspam_OUTmitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList @spam@piclist-unsubscribe-requestKILLspammitvma.mit.edu

I have a £200 programmer that claims to be able to defeat CP. Never bothered trying it. Peter This email, its content and any attachments is PRIVATE AND CONFIDENTIAL to TANDBERG Television. If received in error please notify the sender and destroy the original message and attachments. -- http://www.piclist.com hint: To leave the PICList KILLspampiclist-unsubscribe-requestKILLspammitvma.mit.edu

The hi-end programmer that was able to read from the code protected chip never had a copy of hex loaded on it. The code was accurate and could only have come from the chip. The code matched the contents of the hex file from the source computer across the room. There was no network connection between the two programmers. We did not test the hi-end programmer to see if it could write to a chip the same code and have a fully working chip when done, but the data that was visible was sufficient to cause us to be concerned about how we store data in the chips. Up till now some of our chips stored passwords that where in plane text assuming that code protect was safe. Now we will be obscuring this information assuming that it is not. -- Roy Souther <RemoveMEroyTakeThisOuTsilicontao.com> 01100010 10101110 11000110 11010110 00000100 10110010 10010110 11000110 01001110 11110110 11001110 00010110 10010110 00101110 10000100 10000100 -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestspamBeGonemitvma.mit.edu

> We recently acquired a hi end universal chip programmer, we programmed a > 16c54 with code protect enabled, then we tried to read it with the hi end > programmer and it read the code. We where shocked to see that the hex file > was easy to view and save to floppy, it was all there. We took the chip over > to the PicStart and tried to read it and it failed. Are you sure you weren't reading back what was in the fancy programmer's memory? High end programmers usually have a memory for saving all the data locally. This allows you, for example, to read one sample chip, then program a bunch more just like it without a host connection. ******************************************************************** Olin Lathrop, embedded systems consultant in Littleton Massachusetts (978) 742-9014, TakeThisOuTolinEraseMEspam_OUTembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

I was not very clear about this so I will point it out now. I programmed a 16c54 with the PicStart Plus and code protect enabled. I took the chip from the PicStart and walked across the room. I turned on the hi-end programmer and placed the chip into the ZIF socket. I selected read and watched as my hex code appeared on the screen. The code was very short so I was able to compare the hex values and find that what was on both computers was identical. I then took the chip back to the PicStart Plus programmer and tried to read and got nothing back from it as the PIcStart Plus could not read data from the chip, but the hi-end programmer could. -- Roy Souther <royEraseME.....silicontao.com> 01100010 10101110 11000110 11010110 00000100 10110010 10010110 11000110 01001110 11110110 11001110 00010110 10010110 00101110 10000100 10000100 -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestmitvma.mit.edu

Maybe your expensive programmer is only marginally programming the code-protect bits ? On Tue, 18 Sep 2001 09:22:21 -0600, you wrote: {Quote hidden}>We have been programming our OTP chips with code protect using the PicStart >Plus. This makes the chip un-writeable and if you try to read it with the >PicStart Plus it fails. That sounded good. > >We recently acquired a hi end universal chip programmer, we programmed a >16c54 with code protect enabled, then we tried to read it with the hi end >programmer and it read the code. We where shocked to see that the hex file >was easy to view and save to floppy, it was all there. We took the chip over >to the PicStart and tried to read it and it failed. > >What is the point in code protect if all you need is a $10k programmer to >circumvent the security. > >We have not tested this with any other chips then the 16c54 but we will and I >will post more info as we find out. > >I reposted this because I forgot to modify the subject for [PIC]: >-- >Roy Souther <RemoveMEroyEraseMEEraseMEsilicontao.com> > >01100010 10101110 11000110 11010110 00000100 10110010 10010110 11000110 >01001110 11110110 11001110 00010110 10010110 00101110 10000100 10000100 -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestspam_OUTKILLspammitvma.mit.edu

> Are you sure you weren't reading back what was in the fancy programmer's > memory? Impossible, the hi-end programmer that was able to read from the code protected chip never had a copy of hex loaded on it. The code was accurate and could only have come from the chip. The code matched the contents of the hex file from the source computer across the room. There was no network connection between the two programmers. -- Roy Souther <RemoveMEroyTakeThisOuTspamsilicontao.com> 01100010 10101110 11000110 11010110 00000100 10110010 10010110 11000110 01001110 11110110 11001110 00010110 10010110 00101110 10000100 10000100 -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestspamspamBeGonemitvma.mit.edu

Looking at my 16C5X data sheet from 1991 it is not clear if addresses below 040h are protected. It says: When code protected, the contents of the program EPROM cannot be read out in a way that the program code can be reconstructed. In addition, all memory locations starting at 040h and above are protected against programming. It is still possible to program locations 000h - 03fh, the ID locations and the configuration fuses. Note that the configuration fuses and the ID bits can still be read, even if the code protection logic is active. Considering the way EPROM programmers work, I think if you can still program locations below 040h that implies you can still read them too. EPROM programmers read what they have just written in order to know how long they have to burn each location. Sherpa Doug > {Original Message removed}

To verify your statement, please make sure to use all memory available and try the same thing again. Many devices do not code protect all of the memory, but I don't know if this is the case here. The code protection feature is of course a physical feature inside the device and not only a logical feature in the programmer! Anders {Original Message removed}

>I then took the chip back to the PicStart Plus programmer and >tried to read and got nothing back from it as the PIcStart Plus could not >read data from the chip, but the hi-end programmer could. I get the feeling that if you programmed it on the high end programmer (which presumably verifies at voltage limits) then you would find that the code protect would stop it being read on both devices. Do remember that the Picstart Plus is a development programmer, not a production programmer. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Are you sure it was the original hex file ? The C54 reads scrambled data for verification purposes when protected, as opposed to higher PICs which read zeros when protected. This is covered in the data sheets. Also some high end programmers have buffers where you store one or more images. Maybe you read back the image instead of the chip ? I have not yet seen a protected PIC that was in fact 'not protected'. Peter -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

This does sound very worrying. I have written a programmer for the 16F876, which I use to program all our production boards, from reading the programming spec I don't see how this is possible unless there are some hidden commands which us mere mortals don't know about. Any chance of probing the legs of the chip while it's being read to see what is going on? Eprom programmers do read each location back, but the code protection bit is usually programmed after all the others have been done (it's in the configuration space at the end of normal code space), so it won't affect reading back each byte as they are written. Martin {Original Message removed}

Roy, you said the "code was very short", is it possible that your entire code resided within the 64 bytes of UNPROTECTED rom that the smaller PICs have at the start of memory??? Try relocating your code to >64 up or program the ENTIRE memory and see how much you can read back. I think you might have discovered the less than perfectly documented "feature" that the smaller PICs have where the first chunk of code memory is NOT code protected ever. :o) -Roman Roy Souther wrote: {Quote hidden}> > I was not very clear about this so I will point it out now. > > I programmed a 16c54 with the PicStart Plus and code protect enabled. I took > the chip from the PicStart and walked across the room. I turned on the hi-end > programmer and placed the chip into the ZIF socket. I selected read and > watched as my hex code appeared on the screen. The code was very short so I > was able to compare the hex values and find that what was on both computers > was identical. I then took the chip back to the PicStart Plus programmer and > tried to read and got nothing back from it as the PIcStart Plus could not > read data from the chip, but the hi-end programmer could. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Roy Souther <RemoveMEroyKILLspamsilicontao.com> wrote: > I programmed a 16c54 with the PicStart Plus and code protect enabled. > I took the chip from the PicStart and walked across the room. I turned > on the hi-end programmer and placed the chip into the ZIF socket. I > selected read and watched as my hex code appeared on the screen. The > code was very short so I was able to compare the hex values and find > that what was on both computers was identical. Roy: On the 16C54, the first 64 words of program space (into which I assume your "very short" code fits) are always accessible, even after code-protection is enabled. This is well-documented, has been discussed numerous times on the list before, and I'm surprised that none of the list members who've replied has pointed this out. > I then took the chip back to the PicStart Plus programmer and tried > to read and got nothing back from it as the PIcStart Plus could not > read data from the chip, but the hi-end programmer could. The curious thing here is not that your Data I/O (or whatever) programmer read the data, but that the Picstart Plus appeared not to. Since code-protected 16C54s are unquestionably readable (the first 64 words are totally unprotected and the rest of the memory shows up as x00), I suspect that the Picstart Plus software simply refuses to SHOW you the data that it reads when the part's code-protect bit is set. -Andrew === Andrew Warren -- aiwSTOPspamspam_OUTcypress.com === Principal Design Engineer === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

On Wed, Sep 19, 2001 at 11:18:55AM +0200, Peter L. Peres wrote: > Are you sure it was the original hex file ? The C54 reads scrambled data > for verification purposes when protected, as opposed to higher PICs which > read zeros when protected. This is covered in the data sheets. Also some > high end programmers have buffers where you store one or more images. > Maybe you read back the image instead of the chip ? Is it possible that the high-end programmer can descramble the data? OTOH is the scrambling process lossy? If it is not, it is possible to recover the original data :-(. -- Wojciech M. Zabolotny http://www.ise.pw.edu.pl/~wzab <--> spamBeGonewzabSTOPspamEraseMEise.pw.edu.pl http://www.opendvd.org Don't allow others to decide what can you play on YOUR hardware, and what OS you need to watch DVD!!! -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

> Is it possible that the high-end programmer can descramble the data? > OTOH is the scrambling process lossy? If it is not, it is possible to > recover the original data :-(. The scrambling process consists in XORing all three nybbles of each ROM location with each other and masking off the upper two nybbles. Maybe Andrew Warren knows about a more recent mask revision, I still use 16C54 and 16C54A CERDIP for development (from 1995!). The only thing that does not work anymore is the writing on the chips so I had to scribe them with a needle. Everything else works fine ;-). Peter -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

In article <KILLspam6907C19278A7D411849F0008C70D42F801A04ED6spamBeGonetvtsehmail1.tvtravelshop.ltd.uk>, Justin Fielding <EraseMEJFieldingEraseMEtvtravelshop.ltd.uk> wrote: > Well, would anyone that can afford a 10k programmer really want to steal > your code? Anyway I thought it was a feature of the high end programmers For pirate copying a mass product it may be _way_ cheaper to buy a $10K programmer than to reverse engineer the software. I don't think the CD copying machines used in China are much cheaper than $10K. -- Harald Milz | @spam@hm@spam@spam_OUTlinux-magazin.de | (1) Everything Linux New Media AG | phone +49 (0) 89 993411-20 | depends. (2) Nothing is Stefan-George-Ring 24 | fax +49 (0) 89 993411-99 | always. (3) Everything D-81929 Muenchen | http://www.linux-magazin.de | is sometimes. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

>For pirate copying a mass product it may be _way_ cheaper to buy a $10K >programmer than to reverse engineer the software. I don't think the CD >copying machines used in China are much cheaper than $10K. In matter of fact the CDs are injection molded not copied as the CDRs and the CD production line may cost about $500K, but will produce millions of CD per month so it pays-off very quick. Best regards Tsvetan --- PCB prototypes for $26 at http://run.to/pcb (http://www.olimex.com/pcb) Development boards for PIC, AVR and MSP430 (http://www.olimex.com/dev) -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.