Post by thread:[PIC]: Reburning OTP code protected chips with new

Along these same lines, has anyone tried re-programming a code protected chip (one in which the first few locations are purposefully left blank)? I would assume it doesn't allow it, only because a crafty hacker would place a code spewing algorithm at the end, and make the start point to it. If you can't, it limits the usefulness of this trick, but if you can then it would be fairly trivial to get the code out of any device whose remaining memory locations haven't been cleared. -Adam Lorick wrote: {Quote hidden}> > Someone suggested the next time I put something in an OTP device, I make the > ORG higher so I can later reburn the lower region and overwrite the reset > area with the new lower ORG as long as the new ORG only has bits changing > from 1 to 0 in the number so that they can be burned and updated. > > Does this work, or is it a nice fairy tale? I would first think the > picstart would yell at me that it's not a blank device even if I technically > can burn the untouched 1's sitting in the OTP. > > The reason all this came up is because I put some 16c65 code in an OTP and > now I find I would like longer output port On times so I'm forced for this > one unit to add hardware RC/Transistor delays between the pic and the other > control lines being driven...the next burns will have software increased > delays of course. > > -- > http://www.piclist.com hint: PICList Posts must start with ONE topic: > [PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements -- 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

The chips do not accept the new code if protection is enabled, no mattter how hard you try. Which is good. Andy "M. Adam Davis" <spam_OUTadavisTakeThisOuTUBASICS.COM> on 08/03/2000 10:51:18 AM Please respond to pic microcontroller discussion list <.....PICLISTKILLspam@spam@MITVMA.MIT.EDU> To: PICLISTKILLspamMITVMA.MIT.EDU cc: (bcc: Andrew Kunz/TDI_NOTES) Subject: Re: [PIC]: Reburning OTP code protected chips with new ORG? Along these same lines, has anyone tried re-programming a code protected chip (one in which the first few locations are purposefully left blank)? I would assume it doesn't allow it, only because a crafty hacker would place a code spewing algorithm at the end, and make the start point to it. If you can't, it limits the usefulness of this trick, but if you can then it would be fairly trivial to get the code out of any device whose remaining memory locations haven't been cleared. -Adam Lorick wrote: {Quote hidden}> > Someone suggested the next time I put something in an OTP device, I make the > ORG higher so I can later reburn the lower region and overwrite the reset > area with the new lower ORG as long as the new ORG only has bits changing > from 1 to 0 in the number so that they can be burned and updated. > > Does this work, or is it a nice fairy tale? I would first think the > picstart would yell at me that it's not a blank device even if I technically > can burn the untouched 1's sitting in the OTP. > > The reason all this came up is because I put some 16c65 code in an OTP and > now I find I would like longer output port On times so I'm forced for this > one unit to add hardware RC/Transistor delays between the pic and the other > control lines being driven...the next burns will have software increased > delays of course. > > -- > http://www.piclist.com hint: PICList Posts must start with ONE topic: > [PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements -- 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 -- 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

On Thu, 3 Aug 2000, M. Adam Davis wrote: > Along these same lines, has anyone tried re-programming a code protected chip > (one in which the first few locations are purposefully left blank)? > > I would assume it doesn't allow it, only because a crafty hacker would place a > code spewing algorithm at the end, and make the start point to it. > > If you can't, it limits the usefulness of this trick, but if you can then it > would be fairly trivial to get the code out of any device whose remaining memory > locations haven't been cleared. That's clever! Most code on a mid-range pic has something like org 0 goto start org 4 interrupt_routine: .... start: ... ------- So, then you could clear location 0 making it a NOP, program location 1 with a goto SomePlaceInHighMemory. Add the code in high memory to do what ever is needed... However, I don't think a thief would be able to read out the contents of the pic except if it were an 16f87x device. The other mid-range pics can't access program memory (other than to execute it). -- 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

> The chips do not accept the new code if protection is enabled, no mattter how > hard you try. > And this brings me to wonder something else, which I would think is a yes, how about if development is in progress and an OTP is burned, and no protection is enabled just in case updating is desired. Maybe then it is reburned, maybe not, but it is decided that it is polished. Can you burn just the security bits and protect it? -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestKILLspam.....mitvma.mit.edu>

Yes. That is how a code protected chip is verified: Burn program area Burn all fuses except CP Read program area Read fuses Burn CP fuses Actually, the program area and fuse areas are addressed seperately, ie, you can't burn the program and fuse in one fell swoop, you have to burn the program area, issue a new burn command (contains the address of the fuses) then burn the fuse area. -Adam Lorick wrote: {Quote hidden}> > > The chips do not accept the new code if protection is enabled, no mattter > how > > hard you try. > > > > And this brings me to wonder something else, which I would think is a yes, > how about if development is in progress and an OTP is burned, and no > protection is enabled just in case updating is desired. > Maybe then it is reburned, maybe not, but it is decided that it is polished. > > Can you burn just the security bits and protect it? > > -- > http://www.piclist.com hint: To leave the PICList > EraseMEpiclist-unsubscribe-requestspam_OUTTakeThisOuTmitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestspam_OUTmitvma.mit.edu>

At 10:51 AM 8/3/00 -0400, you wrote: >Along these same lines, has anyone tried re-programming a code protected chip >(one in which the first few locations are purposefully left blank)? >I would assume it doesn't allow it, only because a crafty hacker would place a >code spewing algorithm at the end, and make the start point to it. > >If you can't, it limits the usefulness of this trick, but if you can then it >would be fairly trivial to get the code out of any device whose remaining memory >locations haven't been cleared. > >-Adam This works only for a few PICs, the 16C5x, 12C50x, 16C61, 71 as the first 40h locations can be reprogrammed even if code protection is fully enabled. However you cannot read the program memory via code with these parts in any case so no go with your idea as Scott rightly pointed out. -Jim > >Lorick wrote: >> >> Someone suggested the next time I put something in an OTP device, I make the >> ORG higher so I can later reburn the lower region and overwrite the reset >> area with the new lower ORG as long as the new ORG only has bits changing >> from 1 to 0 in the number so that they can be burned and updated. >> >> Does this work, or is it a nice fairy tale? I would first think the >> picstart would yell at me that it's not a blank device even if I technically {Quote hidden}>> can burn the untouched 1's sitting in the OTP. >> >> The reason all this came up is because I put some 16c65 code in an OTP and >> now I find I would like longer output port On times so I'm forced for this >> one unit to add hardware RC/Transistor delays between the pic and the other >> control lines being driven...the next burns will have software increased >> delays of course. >> >> -- >> http://www.piclist.com hint: PICList Posts must start with ONE topic: >> [PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements > >-- >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 > Regards, Jim Robertson NEWFOUND ELECTRONICS Email: @spam@newfoundKILLspampipeline.com.au http://www.new-elect.com MPLAB compatible PIC programmers. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

Lorick wrote: > > > The chips do not accept the new code if protection is enabled, no mattter > how > > hard you try. > > > > And this brings me to wonder something else, which I would think is a yes, > how about if development is in progress and an OTP is burned, and no > protection is enabled just in case updating is desired. > Maybe then it is reburned, maybe not, but it is decided that it is polished. > > Can you burn just the security bits and protect it? > > -- > http://www.piclist.com hint: To leave the PICList > KILLspampiclist-unsubscribe-requestKILLspammitvma.mit.edu Yes, all the programmers I have seen have a fuse only program command. However, once code protect is set, you cannot rewrite the fuse to unprotect the chip without erasing the code first. -- Best regards Tony ICmicro's http://www.picnpoke.com RemoveMEsalesTakeThisOuTpicnpoke.com -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements