Searching \ for 'WARNING: CODE-PROTECT CAN BE HARMFUL TO WINDOWED P' 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/index.htm?key=code+protect+can
Search entire site for: 'WARNING: CODE-PROTECT CAN BE HARMFUL TO WINDOWED P'.

Truncated match.
PICList Thread
'WARNING: CODE-PROTECT CAN BE HARMFUL TO WINDOWED P'
1996\05\03@233219 by PETE KLAMMER

flavicon
face
> Date: Fri, 03 May 1996 18:17:00 -0700 (PDT)
> From: Eric Smith <spam_OUTericTakeThisOuTspamGOONSQUAD.SPIES.COM>
> Subject: Re: Windowed PIC16C622
>
> Kim Cooper of Microchip wrote:
> > Sorry, ocde protect on the newer devices, the PIC16C622 included, is
> > permanent.
>
> This is really disastrous, as sometimes the code protect bit is set
> erroneously by the programmer.  I've seen this happen on both the PICSTART
> and the Parallax programmers.  Maybe it's really a design defect in the
> device?  Anyhow, two out of five of my windowed '622 parts are now only
> suitable to be used as jewelry.
>
> Eric

I agree; they changed the rules without telling us.  There should be a
bright RED warning label on every new windowed PIC:
  WARNING: USING CODE-PROTECT ON THIS PART MAY BE BAD FOR ITS HEALTH!

I learned the hard way with a couple dearly-needed, direly-begged,
and painfully-lost 17C44 early engineering samples.  I got one shot of code
in each -- ``Wot!  OTP parts with windows!!?'' -- and now one is a doorstop
and the other is a paperweight.

I understand what Microchip did, but I still don't like it.  They put the
code-protect fuse (or *one* of them, anyway) under metalization, so it is
UV-proof.  The reason being, that the same dice are used for windowed or OTP
production parts, and Microchip wanted to thwart a certain kind of hacking:
popping the lid off an OTP and then selectively erasing just the
code-protect bit(s).  Worthy justification, I guess.  But even if I am smart
and careful enough to never leave embedded code-protect fuse settings in my
development code, its an inconvenience to have to either build different
files for development and production, without and with embedded fuse
settings, or else rely on manufacturing personnel to always remember to set
the code-protect fuse at the programming station.  Either way, it's an
invitation to forget one way or the other, and either accidentally lock up a
windowed part, or accidentally release unprotected code.

In truth, I have greater luxury than I admit: I use the PicMaster (ICE) for
most of my development, and -- SO FAR -- it hasn't become permanently
locked when I download code-protected hex files into it.

Peter F. Klammer, Racom Systems Inc.                   .....PKlammerKILLspamspam@spam@ACM.Org
6080 Greenwood Plaza Boulevard                            (303)773-7411
Englewood, CO  80111                                  FAX:(303)771-4708

1996\05\05@164114 by Przemek Klosowski

flavicon
face
Peter F. Klammer wrote

  I understand what Microchip did, but I still don't like it.  They put the
  code-protect fuse (or *one* of them, anyway) under metalization, so it is
  UV-proof.  The reason being, that the same dice are used for windowed or OTP

I believe that E(E)PROM cells can also be erased by soft Xrays. The problem
with Xrays is that they are 10-50 times more energetic than UV (UV quanta
by definition have energies in the range between 3 and 200 eV, and Xrays
are above that, with most typical Xray generators using 5,000-50,000 eV).
Thus, Xrays can induce radiation damage in the semiconductor, so you have to
be very careful with the dose. On the other hand, a little metalization won't
prevent the erasure by Xrays.

I suppose that a friendly dentist or crystallographer would let someone use
their Xray machine; would someone be willing to experiment a little with
the times necessary?

       p

1996\05\05@204255 by John Payson

flavicon
face
> I believe that E(E)PROM cells can also be erased by soft Xrays. The problem
> with Xrays is that they are 10-50 times more energetic than UV (UV quanta
> by definition have energies in the range between 3 and 200 eV, and Xrays
> are above that, with most typical Xray generators using 5,000-50,000 eV).
> Thus, Xrays can induce radiation damage in the semiconductor, so you have to
> be very careful with the dose. On the other hand, a little metalization won't
> prevent the erasure by Xrays.
>
> I suppose that a friendly dentist or crystallographer would let someone use
> their Xray machine; would someone be willing to experiment a little with
> the times necessary?

This would leave us back at square 1 it seems, in terms of security (though
no worse than many other OTP micros).  On the other hand, if X-rays work,
OTP's could be used as EPROMs :-)

Anyway, here's the idea I was thinking of for code-protect: rather than using
a "fuse" (EPROM location), why not have a RAM flag [i.e. latch] for that
purpose?  Require that in order for programming or reading to be performed
on the device, the PC must first feed the device a copy of the program within
it.  Have this behavior apply regardless of whether a "code-protect" flag is
set or not (there wouldn't have to be a code-protect flag).

While some care would need to be taken to prevent an unscrupulous person from
glitching the RAM flag, these semantics would allow a device with known cont-
ents to be verified (or programmed more) and a blank device (whose contents
are known implicitly) to be programmed and verified.

What do people think of this idea?

1996\05\08@143755 by PETE KLAMMER

flavicon
face
> Date: Sun, 05 May 1996 19:42:41 -0500
> From: John Payson <supercatspamKILLspamMCS.COM>
> Subject: Re: WARNING: CODE-PROTECT CAN BE HARMFUL TO WINDOWED PARTS
>
> Anyway, here's the idea I was thinking of for code-protect: rather than using
> a "fuse" (EPROM location), why not have a RAM flag [i.e. latch] for that
> purpose?  Require that in order for programming or reading to be performed
> on the device, the PC must first feed the device a copy of the program within
> it.  Have this behavior apply regardless of whether a "code-protect" flag is
> set or not (there wouldn't have to be a code-protect flag).
>
> While some care would need to be taken to prevent an unscrupulous person from
> glitching the RAM flag, these semantics would allow a device with known cont-
> ents to be verified (or programmed more) and a blank device (whose contents
> are known implicitly) to be programmed and verified.
>
> What do people think of this idea?

You would have to be sure that the part did not ``betray'' where the
mismatch occurred, so that incremental trial-and-error contents guessing
would not work.

For reading a part, this seems pointless.  But for verification, it is
better than the scrambled-signature bytes we get now: send in a whole second
copy of the program, which is compared internally, without betrayal of where
any mismatch occurs, and return a single ``yes'' or ``no''.  In fact, who
needs readout capability at all (who ever ``forgot'' what hex file is stored
in a programmed part?).  Why not make PIC code (E)PROM write-only?  (from the
point of view of pins or pads, of course.)

Code-protection must also defeat another mechanism: incremental bit-burning.
Suppose location 0000 in a protected part contains FFF2, and when you read
it you get the scrambled signature C6C6 (I'm making this up).  Then you
attempt to burn location 0000 with FFFE, and read back, and nothing has
changed: bit 0 was already 0.  Then you attempt to burn location 0000 with
FFFD, and read back, and the signature changed to B2B2 (or whatever).  That
tells you bit 1 must have been a 1; you just cleared it.  The code-protect
fuse should prevent this (does it?).

Peter F. Klammer, Racom Systems Inc.                   .....PKlammerKILLspamspam.....ACM.Org
6080 Greenwood Plaza Boulevard                            (303)773-7411
Englewood, CO  80111                                  FAX:(303)771-4708

1996\05\08@153152 by Andrew Warren

face
flavicon
face
PETE KLAMMER <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU> wrote:

> Code-protection must also defeat another mechanism: incremental
> bit-burning. ....  The code-protect fuse should prevent this (does
> it?).

Not on the first 64 bytes of the original 16C5x parts, Pete.

-Andy

Andrew Warren - fastfwdspamspam_OUTix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499

1996\05\08@165312 by Eric T. Brewer

flavicon
face
At 12:37 PM 5/8/96, PETE KLAMMER wrote:
{Quote hidden}

I think a best of both world situation would be to have two bits. The first
bit is a ReadWrite/*WriteOnly mode bit. Once cleared, the bit cannot be set
by being erased (as the code protect bit is today with having metal over
the EPROM
cell). This allows the code array to be read during testing at the factory
or by a
programmer.

The second bit would be a Verify/*NoVerify bit. Once cleared, the array can
no longer
be verified, but the bit can be set via UV erasure. If the bit is set, the
array can be
verified by entering verify, setting the PC to 0, sending all of the code
for the code array
to the PIC and then reading a Yes/No result. Failure to sequence through
all of the
code space will result in a No response.

Given this, a part can have the ReadWrite/*WriteOnly bit accidentally
cleared without
making the part into jewelry. The part is very secure. A person trying to
"crack" it
would have to set the Verify/*NoVerify bit, then send 512x12 words of data
to a 16c54,
and then see if it verified. If they are one bit off in the 6144 bit
sequence, they get back a
No. If they don't sequence through all of the code array, they get a No.
This means
they have 2^6144 combinations to try. The average case would be 2^3072.
That is pretty
damn secure. You couldn't cycle through that number of combinations in a
number of
lifetimes!

I would put forth, that the average company would leave the the Verify/*NoVerify
alone as the part is already secure enough. By not clearing the bit, it
allows for some
failure analysis to be done when you get a bad part back. Since you have
the code
which is supposed to be programmed into the part, you can verify the part
still has the
correct code. If it does not, you still do some simple checks such sequence
through 512
different verify operations with successive words of code being zero. If
you got a Yes,
then you know a location got zapped somehow. You could check to see if the whole
part got zapped. You could see if a column of bits are zapped. Anyways, you
get the
idea.

You might ask why even have a Verify/*NoVerify bit. You don't have to. It is for
the extra paranoid companies out there! I certainly wouldn't need it.

cheers,
eric

PS. I haven't seen this in practice or print anywhere before. If someone
actually
implements this, they should give credit (Peter and myself) where credit is
due! Not
asking for royalties or anything, just a fleeting glimpse of fame!

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