openecu.org

Hi,

I am a senior in college and i am doing a senior design project in which i am trying to build an android app that will be able to tune or reflash an ecu using the obd II port.

However, the only car i have to test this on is a 98 honda accord. Also i have no idea of the protocol or where to get the protocol on how to change the maps. Nor do i know which ports i need to talk to to go about tuning the car. Currently i know how to go about reading data from the obd port but havent found much documentation on how to write to that port. I am still in the research phase of this project and any help will be greatly appreciated .

I can't help you out with the reflashing protocol on these, but what I can say is that you should avoid any sort of reflashing using a wireless connection (wifi, bluetooth), even though at least one big player is doing this already. IMO it's asking for trouble, and the risk of bricking your ECU is far higher.
If you can wrangle a wired vehicle interface via USB to your Android device instead, that would be far safer.
Logging via BT/WiFi is no problem (it doesn't matter if the link drops out).

hmm u do have a point there... i may need to rethink whether im willing to go into this or not. Thank you for your input.

Could u possibly give me some more information on exactly what can cause ur ecu to be bricked or atleast how to avoid doing that. Some links to research material would also be quite helpful

thank you in advance!

EVO 7/8/9: no problem, ECU can always be recovered AFAIK.
Subaru: If the key is turned off mid-flash, game's over. If the software falls over and is unable to continue on, then eventually the ECU will lose power- bad.
It's pretty much only Subaru ECUs that are easily bricked. This is because the kernel load code, including security algorithm, is embedded in the ECU's normal running code. If that is corrupt or unable to execute, there is no way to upload a reflashing kernel and 'fix it'.
It's bad design, but what we have to deal with if we want to reflash these cars.

radsdau wrote:EVO 7/8/9: no problem, ECU can always be recovered AFAIK.
Subaru: If the key is turned off mid-flash, game's over. If the software falls over and is unable to continue on, then eventually the ECU will lose power- bad.
It's pretty much only Subaru ECUs that are easily bricked. This is because the kernel load code, including security algorithm, is embedded in the ECU's normal running code. If that is corrupt or unable to execute, there is no way to upload a reflashing kernel and 'fix it'.
It's bad design, but what we have to deal with if we want to reflash these cars.

It is not correct.
32 bit Denso ecu for Subaru contains secondary bootloader within 0x0000-0x1FFF ROM area. It is old ecuFlash kernel that overwrites this bootloader ( that should not be done) and makes it possible to corrupt the ROM if flashing fails for some reason.

Security is probably currently overcome from within "ECU's normal running code". There are some different bootloaders and appropriate protocols that should be hacked in order to reflash those ecu's in a safety manner.

Alternatively, those Denso ROMs maybe patched with a "safe" bootloader ( that does not rely upon normal running ecu code and does not reflashes itself each session) during the first reflash.

Thanks for the info Sasha, I was unaware of that. That must be late model vehicles only, right?, i.e., CAN?

All 32 bit SH processor based Denso ECU's ROMs have:

- primary CAN bootloader, the appropriate CAN bus channel is not available outside the ECU ( at least for the first 32bit DENSO ecu generation, not sure for current ) that probably used in manufacturing stage. After some tests this bootloader jumps to the secondary bootloader if exists. This code is usually at 0-0xFFF ROM location.

- secondary serial communication bootloader. That serial port is available outside the ECU as k-line ( not sure for current ecu generation ). If diagnostic equipment does not force this bootloader to go to flash mode and checksum verified engine management code exists this secondary bootloader jumps to engine management code. This code is usually at 0x1000-0x1FFF ROM location.

- Serial \ CAN ( if enabled ) code to force the ecu into flash mode from within engine management code.

"ECU bricked" problem comes when a bruit force kernel overwrites any of those bootloaders or engine management code ( if this code is used to force the ecu into flash mode ) and fails.

"Native factory\dealer" algorithm should work with the secondary bootloader and should not overwrite primary and secondary bootloaders. In such a case it is impossible to brick the the ECU ( if engine management section of the ROM is still able to be reflashed ) since bootloaders are not corrupt and the engine management code will not start being corrupted.

so exactly how do these programs run.

Is it simply just loading the specific port on the ecu with a value? And what i need to do is figure out what those values are? Because thats how reading works correct?

You collect messages from the port and then parse them to collect the proper data?

SO does writing back work the same? If so how do i find out what needs to be written on the port to change what?

I Need to be able to write to the ecu to change things such as timing and what not. I do not need to make it work good really. I just need it to work lol...

Sasha_A80 wrote:All 32 bit SH processor based Denso ECU's ROMs have:.....

So uploading a reflashing kernel must be slightly different in this scenario. Do you know what the differences are to the hookup protocol?

There is a number of bootloaders and I am not sure that it is reasonable to crack most of them from the market point of view.
It is much cheaper to provide "IC manufacturer's" style reflash utility. SHboot mode for Renesas SH chip for example.

Sure, got it. Thanks.
radsdau