[Diy_efi] Re: Reversing EPROM decryption board (Don Paauw)

[Stevan Glogovac]

Hello Don,
   
  thanks for the answer.
   
  I tried to make the checksum of vectors correct by some trivial mehods - assuming 8 and 16 bit ADD and 8 bit XOR is done on the area. That didn't work, and I had always fear that they could check the vector table against actual addresses of ISRs... (unused entrys point to the reset entry point). But I will try again with the checksum, adding some bit shifting in between....
   
  If address bus is not "walked" in correct sequence, PEELs do not decrypt data anymore. And I do not know the sequence...
   
  As for the monitor board, could I do it like this:
  1) use NVRAM
  2) connect it in parallel to address and data bus
  3) connect its /W to /R of EPROM
  4) keep its /R high
  5) connect its /CS to /CS of EPROM
   
  Regards,
  NG 
   
  Message: 1
Date: Sun, 11 Jun 2006 23:58:27 -0400
From: Don Paauw <dpaauw at netwiz.net>
Subject: Re: [Diy_efi] Reversing EPROM decryption board
To: diy_efi at diy-efi.org
Message-ID: <3.0.6.32.20060611235827.00907bf0 at 216.251.43.97>
Content-Type: text/plain; charset="us-ascii"

NG (related to Stevan?),
It seems that since the address lines are direct, the decryption cannot be
changing on-the-fly (i.e. LFSR, state machine, etc.) so I would think that
every
address would be decrypted the same way every time. A brute force approach
would be
to have a RAM bank twice the width of the data bus and on every EPROM read,
write the
EPROM and the decrypted data into the RAM. Over time, you will get lot of
adresses
and their decoding. Some software munging may show a pattern and/or you
may be able
to use a non-critical area to try your trojan again. I'm not familiar with
the
PEEL or 68hc11 but it wouldn't take much to make sure that 128 bytes plus
some vectors
exactly match but, obviously, it's silly check the entire EPROM, other than
by checksum
or by sectored checksum. Actually, you may want to consider that and make
sure that
the unprotected area checksum always matches. The rest of this could be
moot. But
checksums can be easily convoluted by simply shifting bytes or feeding
through LFSRs
so this could be a frustrating exercise.

This assumes that passive measures are required. The first brute force
method would
be to just walk the address bus and observe the results but from your
experiences, I
would think they've anticipated that and found a way to detect it.

I realize that you are trying to achieve this by just reprogramming the
EPROM but I
don't see, offhand, anything you've missed in that approach, except
experimenting with
encrypted bytes, which could be dangerous (engine-wise) and probably
inconclusive.
Just to ease the hardware
approach, assuming you don't have access to a logic analyzer and the PEEL
(and everyting
else) isn't clock-speed-sensitive, you could use a PC to drive the clock
and drive/monitor the
address/data lines. I'm not sure this would be easier than building a
dedicated monitoring
board, but it would allow you to put just about everything under software
control and make
other attacks easier.

-- Don


 Send instant messages to your online friends http://uk.messenger.yahoo.com