Hskr8

iTrader: (1)

you all know how the ecu has a long term fuel map right?

CZ has proven this... I don't know the details... is it a combination of A/F ratio and timing, over a range or who knows?

instead of trying to crack the ecu... why not just get the flash in code form... edit with a hex editor, and change the long term fuel map to run where you want it to run at?

Wouldn't that in essence crack the ecu for everyone? while keeping what it is supposed to do?

Seems overly simplistic, yes?

I haven't heard of anyone looking at it from this perspective though...

K.I.S.S.

Thoughts, ideas welcomed.

kw1k

correct me if im wrong but, didnt team astra or w/e its callled crack it already?

lurch519

i am sure that is entirely possible, but how would you upload it to the ecu. i believe thats the real issue

TeamRX8

iTrader: (25)

they didn't crack it, they just circumvented the factory PCM control of the fuel tables with their own,. It's essentially a mini-piggyback except that instead of being external to the ECU they fit it inside the factory PCM box where it resides with the rest of the PCM internals.

tuj

Well its a bit more complex than that. Modifying open loop operation works just like you say. Get the binary dump and try to find the fuel tables and modify them. In closed loop operation, you can't just change the LTFT, since that is stored in NVRAM. When its reset, that table goes to all zeros, and is then adjusted by the ECU in accoradance with its lamda strategies. As I understand it, there is more than one table of lambda targets, each of which represents a lamda strategy.

zoom44

ok so lets say you aquired the flash and opened it in a hex editor like the image below




now just how does one go about finding the timing tables and the fuel maps and the etc etc in the thousands of lines of hex?

timbo

That's exactly what one learned rotor tuner here in Australia said to me!

zoom44

well some people do it

Japan8

Electrical engnieers are amazing, aren't they?

tuj

Compare one flash to another. The data areas are generally at the beginning or end of the file, and the execution segments are generally contiguous. With memory being as cheap as it is, the data areas usually are not. There are usually gaps between logical sets of data. And as you can see in your hex editor, ASCII strings and the like are sometimes still visible. Often, debug symbols are still present in the production code.

As I understand it, Denso writes many of the basic subroutines for the device, leaving Mazda to deal with application-specific details like fueling, etc. The Denso code is unlikely to change from flash to flash, so those areas should be easy to identify. With knowledge of the processor's opcodes, its easy to rule out what is and is not a valid instruction. Data sets like fuel tables typically have ascending patterns.

But you're right, its certainly not easy.

tuj

Yes, this is the issue the Honda guys have had to deal with. Most devices like this calculate checksums for areas like the fueling tables. If you change data without recalculating the checksum, the ECU will reject your flash. This is a safety mechanism, in case an address in the ECU's memory would go bad and report a different value than the one that should be stored at that location. Some of the Honda ECU's apparently have multiple mechanisms for calculating checksums, some of which are rather obtuse.

The basic upload, as I understand it, can be done with a CAN-compliant pass-thru programmer. You can actually download the flashes online for a nominal fee. I do not know the technical details of the flashing procedure, but its my understanding that there is nothing sinister, like encryption, involved in the transaction to accept a new flash.

zoom44

ok so you weed out the data areas- now how do you know which data is which? it doesnt just say "fuel table 1"

again obviously some people do it- i just have never done this. the first time i ever looked at hex was when i opened that flash i attached the pic of above. ive looked at several for several models since. 6,3,8. dont have an MX-5 to look at yet.

MrJynx

Is there anywhere to actually download one of these flashes? I wouldn't mind taking a look at it in a hex editor..

If only someone could make an emulator for the ECU code.. then you can make changes to the code on the fly and test it out. If you could determine what all the sensors are feeding into the ECU you could potentially mimic what the car tells it and modify those fake variable to see how the ECU reacts to certain conditions. But good luck making that happen we need game console hackers in here!


MrJynx

zoom44

two issues but both can be done.

1. Astra racing dealt with the check sum issue. They had to get someone outside their company to do it but the did it. Find out who did it for them and your golden

2. They way the Mazda reflashing software works is that it checks the Flash of the vehicle then looks to see if there is a newer one for your vehicle. there are a few ways around this.

a. get a copy of the next newer flash (wait for one to come out), modify it then replace the one in the database with your modified one or tell the software a new place to look for the updates. sounds difficult but could be done. of course you could be waiting along time for a newer one to come out. unless you find a way to convince the software that your older flash is a new one. you would still need a pass thru device along with the oem software. and a laptop or pda.

b. Astra takes the PCM out of the car, opens it, removes a chip, changes a jumper, connects to the chip and changes the hex with a program which you can download from their website. then replaces the chip and puts the pcm back in the car. sounds easy i suspect to computer types. however this is not esily done but alot of endusers. you'd have to send your pcm to someone if you didnt know how to do it yourself. they do this in japan. but really this becomes a real bottleneck-how long do you want your pcm out of your car?

c. modify the flash. then write or have written your own J2354 compliant(Make sure its compliant with the correct ISOs) pass thru programming software that doesnt look for a newer one. it just asks "which flash should i upload" then all you need is a J2354 compliant pass thru device and a laptop/pda and a good power source and a good charge on the battery.

now c sounds an awful lot like the flash tuning that fastsvtss's company is working on (see this thread https://www.rx8club.com/series-i-aftermarket-performance-modifications-23/rx8-hand-held-flash-tuner-79650/) as well as several others (see my interview with Racing Beat's Jim Mederer in the next issue of RXTuner- not the one that is on its way now, the one after that)

zoom44

i coull email you a flash.

read up on Jim Mederer's ecu bench. he did just what you suggested.

tuj

http://www.mazdatechinfo.com/home/ecmDetail.asp

tuj

Two ways to deterimine what data means what.

-look through the execution segment and try to figure out what the code does. The things to look for here will be the injector hooks, as that code will then go to an interpolation routine that will look up two points in the fuel maps.

-trial and error / comparing flashes. Like I said, generally speaking, data tables are going to be bounded with empty space, so identifying logical sets of data isn't so hard. There are only so many array's that would be the size of the fueling table, so there should only be a few suspects.

There actually might be another option if you are a Ford/Mazda employee and hacker. As I understand it, the WDS can actually modify the fuel tables and such while its hooked up for the vehicle. I wonder if they guys who are talking about their hand-held 'flasher' unit are doing something like that.

zoom44

grabbing from mazdatechinfo isnt as easy as it first would seem.

flash tuning companies can hook up and get a rom dump etc. i dont think they can change parameters on the fly while hooked up. but fastsvtss suggested it might be possible.

wouldnt it be nice if the companies just labeled everything?

timing table 1
knock retard table
fuel map

would make it all much easier

tuj

Indeed. Does anyone know what processor chip the CPU uses? I would like to find an instruction set and opcodes for the chip.

zoom44

Hitachi SuperH processor by Renesas.


Specs are-
High-performance single-chip RISC with SH-2E core
52 MIPS/40 MHz/3.3 V
High-speed multiplication/accumulation operations
Built-in 32-bit multiplier
Built-in single-precision floating-point operation unit
Built-in large capacity flash memory with a single power supply and large capacity RAM
Write and erase operations available with the single power supply 512 kB Flash ROM/32 kB RAM

Powerful peripheral functions
Timer: ATU-II (a maximum of 65 input and output process) Compare-match timer 2 ch
A/D: 10 bit x 32 ch
Serial: 5 ch DMAC: 4 ch
HCAN: 2 ch (1 ch is shared with a serial interface)
Package QFP-256


http://www.renesas.com/fmwk.jsp?cnt=...family/&site=i

zoom44

pics

tuj

Excellent. Renesas has all of the SDK stuff available on their site, which is great. Any ideas as to the exact chip number?

Probably the SH7050 or SH7055.

zoom44

7055
the number printed on the chip is 64F7055F40

tuj

As I thought, the ECU is running Hiatchi's Vehicle Operating System, ver. 2.1. Identifying strings are at 03f18h. 001e20 is the end of something called SBL. Not sure what that is. Some interesting stuff at 80fdbh. Everything from there to the end looks to be data structures. Next step is to find a disassembler and see what its really doing.

zoom44

what is interesting about 80fdbh?