Searching \ for '[PIC]: Reburning OTP code protected chips with new' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Reburning OTP code protected chips with new'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Reburning OTP code protected chips with new'
2000\08\03@105247 by M. Adam Davis

flavicon
face
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}

--
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

2000\08\03@111129 by Andrew Kunz

flavicon
face
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_OUTadavisTakeThisOuTspamUBASICS.COM> on 08/03/2000 10:51:18 AM

Please respond to pic microcontroller discussion list <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>








To:      PICLISTspamKILLspamMITVMA.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}

--
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

2000\08\03@111332 by Scott Dattalo

face
flavicon
face
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

2000\08\05@093025 by Lorick

picon face
> 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-requestKILLspamspam.....mitvma.mit.edu>

2000\08\05@124418 by M. Adam Davis

flavicon
face
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}

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu>

2000\08\06@035605 by Jim Robertson
flavicon
face
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}

Regards,

Jim Robertson
NEWFOUND ELECTRONICS
Email: @spam@newfoundKILLspamspampipeline.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

2000\08\06@190359 by Tony Nixon

flavicon
picon face
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-requestKILLspamspammitvma.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
RemoveMEsalesTakeThisOuTspampicnpoke.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...