[Diy_efi] Reversing EPROM decryption board

[Don Paauw]

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




At 10:23 PM 6/11/06 +0100, you wrote:
>Hello all,
>   
>  I have an ECU based on 68hc11 microcontroller. It has an external EPROM
for storing firmware and calibration data. However, the contents of the
EPROM is encrypted, the image my EPROM programmator is reading is clearly
different from the one 68hc11 is seeing when running.
>   
>  Two (read protected) PEEL chips are used to make decryption. One is
intercepting data bus lines between EPROM and CPU, the other is "listening"
the address bus and is also connected to the first PEEL. Addresses are fed
directly to the EPROM (no folding whatsoever).
>   
>  There are two unencrypted zones in the EPROM: the one is at the very
end, where the interrupt vectors addresses are stored and the other is
where reset vector is pointing to (area of about 128 bytes is unencrypted
there).
>   
>  First, I wrote a small program to send the chip contents to the serial
port, with a PC listening on the other side. The code runs fine if I
connect the chip directly to the data bus (so code is ok). I located the
code in unencrypted area of the EPROM to avoid PEELs atempting to decrypt
it... however, it did not run when the EPROM was connected to the data bus
using PEELs... Nothing was comming out of the serial port, so I realized my
code has not been executed at all. 
>   
>  So PEELs somehow realized that I was executing a fake code... 
>   
>  Ok, I tried next thing - I changed one of the interrupt vectors to point
to my "trojan" code. This was input capture interrupt, and it should be
triggered at any time crank trigger sends a pulse... The rest of the chip
contents was stock, just one vector address changed and a few bytes written
for the actual code of the trojan... however, this did not work again...
although stock code was all over the place, it was clear that nothing was
executing as it should... 
>   
>  Then, used completely stock code, and only altered one address in the
interrupt vector table. UNUSED interrupt vector!!! The code didn't run
anymore. So, PEELs somehow realized that the interrupt vector table has
been tampered. 
>   
>  Then I rewrote my trojan to let the interrupt table remain the same and
to let the stock code execute in the unencrypted section... and added just
one jump to my trojan at the end of unencrypted section... this didn't work
either....
>   
>  I went one step forward - I "booted" the ECU with stock chip, then while
keeping the /RESET low, I changed the chip to the one containing my trojan.
I expected the PEELs to be fully unlocked by then - and ready to execute my
code... however, PEELs got it even this time and the thing didn't run...
How on Earth... PEELs are only connected to the address and data buses...
no way could they recognize a reset. But they got locked, probably by
seeing the reset vector being read again...
>   
>  It can't be the chip checksum, as any checksum routine could be executed
only after my trojan has finished it job...
>   
>  I am getting desperate about this, as I could not think of something new
to try. 
>   
>  If somebody can give me assistance, that would be great. Also an
explanation of how such systems work would be of use...
>   
>  I could email original chip contents and the trojan that I wrote for
dumping the contents of the EPROM... if anyone is interested...
>   
>  many thanks,
>  NG
>
> Send instant messages to your online friends http://uk.messenger.yahoo.com 
>_______________________________________________
>Diy_efi mailing list
>Diy_efi at diy-efi.org
>http://lists.diy-efi.org/mailman/listinfo/diy_efi
>
>