Eprom Security Board

[John Dammeyer]

At 08:11 AM 09/08/1996 UTC-0700, you wrote:
>
>> It makes the Eproms unreadable in a standard reader, but it is
>> transparent to the MCU.  


Actually,  there are several rather clever ways of making an eprom appear
like garbage,  all of which are suitable for confusing the amateur but only
slow down the serious 'reverse engineer'.

1.  Make an adapter for the EPROM that has some of the data lines swapped.
The eprom is placed into the adapter and the adapter into the programer.  As
far as the programmer is concerned the correct bits are set into the eprom.
On the circuit board the same leads are exchanged, perferably under the
EPROM socket (out of sight).  As far as the Micro is concerned it still gets
the correct opcodes.

2.  Same deal.  An adapter that swaps the address lines.  The reset vector
is in the correct place.  It just vectors to garbage if the adapter is not
available to swap back the address lines.  Done correctly with a few DB or
DW constants in the code (if you have room),  you can send the reversing
engineer off on a wild goose chase for a while where the code looks correct
but isn't.

3.  Mix the two.  Again with a judicious use of define bytes and swapping
the correct address and data lines the code when dissassembled from the
eprom, without the adapter looks correct but isn't.

4.  The professional 'reverse engineer' just hangs a logic analyzer or an
ICE on the processor and tracks the program from reset.  Verifies that with
the contents of the eprom and builds a suitable adapter.  Then proceeds to
dissassemble the code.  Remember,  if you have the hardware in front of you;
and you know the purpose of the application;  and you have the knowledge of
what the sensors are supposed to do;  reverse engineering is not all that
difficult.

As for encrypting the code and then first decrypting in to RAM and running
from there.... see point 4.  Freeze the processor after the system is
running and dump the RAM using a processor emulator.

ie: For the pro reverse engineering isn't that tough;  for the amateur it
just requires some time and perhaps some equipment.  recall too that if it's
a big Micro,  nowadays most of the application whill be written in a high
level language.  This shows up in stack frame manipulations that are
consistant from function to function.  Local variables are always accessed
the same as are lookup tables.  Good assembler is also easy to figure out.  

Poor assembler (hack code) is the toughest;  both to reverse engineer and to
debug while being developed.

John.
Pioneers are the ones, face down in the mud,
with arrows in their backs.
Automation Artisans Inc.      Ph. 604-544-4950
6468 Loganberry Place         Fax 604-544-4954
Victoria BC CANADA V8Z 7E6