[Diy_efi] eprom decryption

Wed Jun 14 23:06:24 UTC 2006

a simple way around this ( which has worked on about 90% of the time for 
me ) to make an adapter up to mix up your data and address lines 
.....then read through the scrambler ( most of these units are to stop 
you from doing a normal read of the chip ) save your image them program 
a blank chip with the scrambled image through your adapter you built 
then you should have a unscrambled image.....now you can remove your 
adapter and read the chip as normal. like i said ....this has worked 
with about 90% of the scramblers i have struck.......some of them use a 
clock sig from the ecu....most eprom programers wont allow you to change 
this. all the best

justin

mdacmail at optusnet.com.au wrote:
> It sounds as though the data bus intercepting chips are scrambling the data bits based on the address. I would be guessing at address X
>
> bit1 -> bit4
> bit2 -> bit6....etc
>
> and address Y
>
> bit1 -> bit 7
> bit2 -> bit1....etc
>
> Just a unique set of scrambling 'rules' depending on the address. Have you thought of writing a program that tries different descrambling rules on the eprom image, then analyses the result, looking for how much code is actually executable by the 68HC11? If your program never finds more than say 100 consecutive bytes of executable code using a particular descrambling rule, then that attempt could abort and try something else. This could be very time consuming but seems quite automatable. Obviously you would only do this if you feel you are entitled to be decoding someone elses work for your own use :)
>
>
>
>
>   
>> diy_efi-request at diy-efi.org wrote:
>>
>> Send Diy_efi mailing list submissions to
>> 	diy_efi at diy-efi.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> 	http://lists.diy-efi.org/mailman/listinfo/diy_efi
>> or, via email, send a message with subject or body 'help' to
>> 	diy_efi-request at diy-efi.org
>>
>> You can reach the person managing the list at
>> 	diy_efi-owner at diy-efi.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Diy_efi digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: Reversing EPROM decryption board (Don Paauw)
>>    2. Re: O2 says rich, car runs lean.. (Gary Spooner)
>>    3. Re: O2 says rich, car runs lean.. (Michael Richards)
>>
>>
>> ----------------------------------------------------------------------
>>
>> 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
>>
>>
>>
>>
>> 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
>>>
>>>
>>>       
>> ------------------------------
>>
>> Message: 2
>> Date: Mon, 12 Jun 2006 02:28:38 -0400
>> From: "Gary Spooner" <automotivelectronics at hotmail.com>
>> Subject: Re: [Diy_efi] O2 says rich, car runs lean..
>> To: diy_efi at diy-efi.org
>> Message-ID: <BAY114-F2193B5AEF4341157DA5930D88F0 at phx.gbl>
>> Content-Type: text/plain; format=flowed
>>
>> Hello.
>>
>> Regarding narrow band 02's I have to disagree with the opinion about 
>> narrow 
>> band inabilities to provide and accurate indication of 02 content. This 
>> sensor has proven over the years to maintain 02 content within emission 
>> specs where the algorithm is not biased to look for an alternate backup 
>> if 
>> closed loop info fails. Narrow band sensors are capable of millisecond 
>> response and range even to the point of indicating incomplete combustion 
>>
>> from a cylinder or cylinders if observed on a scope with resolution 
>> 200m/sec 
>> and .25Mhz.
>>
>> Tuning accompanying the use of a scanner to indicate 02 voltage, 
>> interrogator values and long term conditions, using the factory 
>> computer, 
>> have found tuning to be very easy and let the computer scrub the 
>> converter 
>> even at idle speed. Factory constants have to be changed but the result 
>> of 
>> the adjustments is impressive. I have setup numerous boats and even 
>> tailored 
>> a rat?s nest of mismatched parts creating algorithms that work. Don't 
>> jump 
>> on the wide band wagon (lol) yet. Narrow works well to...
>>
>> Gary/RPM Research
>> rpm-research.com
>>
>> _________________________________________________________________
>> Auto news & advice ? check out Sympatico / MSN Autos 
>> http://en.autos.sympatico.msn.ca/Default.aspx
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Mon, 12 Jun 2006 14:44:59 +0000 (UTC)
>> From: "Michael Richards" <michael at fastmail.ca>
>> Subject: Re: [Diy_efi] O2 says rich, car runs lean..
>> To: diy_efi at diy-efi.org
>> Message-ID: <20060612144508.B5AA886170D at mail.fastmail.ca>
>> Content-Type: text/plain
>>
>> On Mon, 12 Jun 2006 02:28:38 -0400, Gary Spooner wrote...
>>
>> The narrowband thing is not really an opinion, it's based on scientific
>> fact. Narrowband sensors are designed to discriminate between richer
>> than 14.7 and leaner than 14.7. Nothing more. You can get a vague idea
>> of the actual AFR is by looking at the actual output away from the
>> switching point but it is by no means accurate.
>>
>> OEMs have been using narrowband sensors for years because it is in a
>> fixed and tested location and since the tuning is fixed the temps are
>> also predictable. In the original poster's case we're dealing with a
>> modified engine producing more than stock output numbers. Very difficult
>> to predict the temps of that sensor and the setup is outside the OEM's
>> designed application.
>>
>> -Michael
>>
>>     
>>> Regarding narrow band 02's I have to disagree with the opinion about
>>> narrow band inabilities to provide and accurate indication of 02
>>> content. This sensor has proven over the years to maintain 02 content
>>> within emission specs where the algorithm is not biased to look for an
>>> alternate backup if closed loop info fails. Narrow band sensors are
>>> capable of millisecond response and range even to the point of
>>> indicating incomplete combustion from a cylinder or cylinders if
>>> observed on a scope with resolution 200m/sec and .25Mhz.
>>>
>>> Tuning accompanying the use of a scanner to indicate 02 voltage,
>>> interrogator values and long term conditions, using the factory
>>> computer, have found tuning to be very easy and let the computer scrub
>>> the converter even at idle speed. Factory constants have to be changed
>>> but the result of the adjustments is impressive. I have setup numerous
>>> boats and even tailored a rat?s nest of mismatched parts creating
>>> algorithms that work. Don't jump on the wide band wagon (lol) yet.
>>> Narrow works well to...
>>>
>>> Gary/RPM Research
>>> rpm-research.com
>>>
>>> _________________________________________________________________
>>> Auto news & advice ? check out Sympatico / MSN Autos
>>> http://en.autos.sympatico.msn.ca/Default.aspx
>>>
>>> _______________________________________________
>>> Diy_efi mailing list
>>> Diy_efi at diy-efi.org
>>> http://lists.diy-efi.org/mailman/listinfo/diy_efi
>>>       
>> _________________________________________________________________
>>     http://fastmail.ca/ - Fast Secure Web Email for Canadians
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Diy_efi mailing list
>> Diy_efi at diy-efi.org
>> http://lists.diy-efi.org/mailman/listinfo/diy_efi
>>
>>
>> End of Diy_efi Digest, Vol 16, Issue 11
>> ***************************************
>>     
> _______________________________________________
> Diy_efi mailing list
> Diy_efi at diy-efi.org
> http://lists.diy-efi.org/mailman/listinfo/diy_efi
>   