[Diy_efi] Reversing EPROM decryption board

[Stevan Glogovac]

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