Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucsdhub!hp-sdd!hp-pcd!hpvcfs1!johne
From: johne@hpvcfs1.HP.COM (John Eaton)
Newsgroups: sci.electronics
Subject: Re: Re: 1764 UVEPROM
Message-ID: <1430012@hpvcfs1.HP.COM>
Date: 26 Feb 90 23:37:20 GMT
References: <2575@uwm.edu>
Organization: Hewlett Packard, Vancouver, WA
Lines: 36

<<<<
< But I know both Motorola and Zilog produce MCUs with
< protection for on chip EPROMs.
----------
Some of the MCU's with on chip EPROM's are not as secure
as you might think. I used one from Motorola where you
placed your code in a transfer eprom that was connected
to the pins of the micro.You then put the micro into
bootstap mode and it would read the eprom and copy the
data into its internal eprom. Afterwords you could
power it up and it would execute your code. There was
no instruction that could force it to dump its bits out.


In playing with the programmer I discovered that if you invoke
bootstrap mode with out applying the -12 Volts that it would
go through a quick (2 seconds) attempt to program and then
fail if the part did not match the external eprom. You could
use this as a verify mode to see if the part exactly matched
its transfer eprom.


The verify would step through the addresses and stop if it found
one that did not match the internal eprom. I thought of a interesting
way that this feature could be used to "unload" the code out of
the internal eprom. You build a programmer with ram instead of EPROM.
Load the ram with all 00's and verify against the eprom. Read the
address that fails, increment the data and repeat. I figured that with 
an average byte value of 128 that it would take about 6 days to
extract all the bits from a 2 K eprom. Running the clock overspec
and using opcode frequency analysis could cut that even lower.



John Eaton
!hpvcfs1!johne