The Discovery

Well, I'm amazed!  I think I resurrected a windowed 17C44 (-JW) from the
dead, after it had assumed the lowly role of code-protected paperweight for
most of a year.

[In our last episode, the ambitious developer begged and cajoled his
faithful Microchip FAE, Tonto, for a couple early engineering-sample
17C44-JW parts.  Before Tonto could say, ``But Kimosabe...'' our hero
raced off and programmed them with his favorite 17C42 code.  But little did
he know, the 17C42 source contained an ingredient which was POISON to the
new 17C4X die family: PMC_MODE!  It seems the Microchip tribe was afraid that
too many hackers with forked tongues could steal protected code by erasing
the code-protect bit, so they decided to protect the code-protect bit, by
making it unerasable.  Thus, our hero could program his parts once, and they
ran fine that one time, but they could never be erased and used again.  It
was as if the coyote-spirit, the trickster, had given him OTP parts with
windows.  Our hero learned to never code-protect his JW test code anymore,
but, read on...]

I had come to believe that the new 17C4X parts had an extra code-protect
bit; that this new code-protect bit was shielded from erasure, even in
windowed parts; and that this shield was permanent, perhaps by a layer of
metallization over the code-protect EPROM site.

But I read some other things in PICLIST lately, so I tried several hours of
erasure, and -- lo and behold -- my 17C44-JW (Engineering Sample) is now
programmable again!  I just downloaded a 17C42-sized program into it, and it
runs!

But, my Promate programmer warned, ``Configuration bits are not blank,
continue?'' and it found errors in the address range 1BXXh, which this
program does not use.

Someone on PICLIST suggested the new code protect shielding is not actually
metallization, but something more like ``sunglasses'' -- so that the
code-protect bits will take much longer to erase, and therefore all code
will be erased long before code-protect is removed.  Indeed, under a
microscope, I can see a little black (or Foster-Grant deep green?) square
near one corner of the die.  If this, indeed, is where the code-protect bits
reside, then isn't this where the hacker would focus a selective UV erase
beam?  Is code-protect metal-shielded or not?  My Engineering Sample may be
different.  I'm grateful to have it back for development work, but now I'm
disappointed, or at least confused, about the strength of code-protect.

                       THE PROPOSAL

One of the challenges of code protection is to defeat the hacker (as well as
the pirate; the former being a noble seeker of knowledge, the latter, a
thief) who would selectively erase just the code-protect bit(s) of EPROM,
and then read out the remainder of (un-erased) EPROM.  I think this
challenge can be met by introducing some additional states to the on-chip
programming algorithm, in conjunction with a more delicate, ``fragile''
code-protect bit configuration.

The problem with the current situation is that erasure of fuse bits gains
greater access to the chip.  It should be the opposite: as fuse bits are
erased, the chip should become more protected, less vulnerable.

Furthermore, if fuse redundant fuse bits of several different meanings are
mingled together in EPROM words (hence, presumeably, physically proximate),
it becomes very difficult to erase one kind of fuse without erasing
neighboring (presumeably, physically adjacent) bits of other meanings.

First, let the fuse bit configuration all-erased (all FF's) mean the chip is
in state ``ERASED''.  In the ERASED state, the chip will NOT accept
programming, will NOT execute code, will NOT divulge code for verification,
will NOT respond to anything outside, except maybe signal that it is ERASED.
Whenever powered up in this state, the on-chip programming algorithm will
scan itself, without outside interference, to see if the entire code space
is erased or not.  Once it completes this scan successfully, the chip itself
marks the fuse array with several bits in several words to set the next
state, ``PROGRAMMABLE'':  11011011 01101101 10110110.

In the PROGRAMMABLE state, the chip responds to programming in the usual
way, except that the configuration fuse array is not accessible to an
external programmer.  A PROGRAMMABLE chip can be programmed, can execute
code when powered up normally, can be programmed further, etc.

The ``CODE-PROTECT'' state is entered by a special command to the
programming algorithm, not by programming the bits directly.  (The special
command might even look just like commands to program those bits directly,
to deceive the casual observer, but in fact the on-chip algorithm should
execute them itself).  CODE-PROTECT is signified by several more bits in the
same words as above: 10010010 01001001 00100100.

In the CODE-PROTECT state, the chip does not respond to any external
programmer access, except to confirm that it is in the CODE-PROTECT state.
When powered up normally, it executes its code.

Any other fuse configuration is ``UNDEFINED''.  In any UNDEFINED state, the
chip does nearly nothing, other than perhaps to confirm to a programmer that
it is in an UNDEFINED state.  No scanning for erasure, no execution of code,
no acceptance of programming commands, no divulging of code.

Thus, any selective erasure would have to successfully erase several bits in
several words (8 in the example above) without erasing any adjacent bits.  I
think this can be made quite challenging, perhaps by increasing the number
of redundant bits, using clever geometry, etc.

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