RomRaider

Is there anybody here capable of developing definitions for the new range of Honda ECU's, mostly post 2010 models using SH7058/9 processors. I can support with providing full bin reads off most of these ECU's. I'm attaching one off a 2010 CRZ for checking.

Anybody keen on this please pm me.

Regards,

Zakie

Were you able to read this bin using the tactrix?

As far as i know, not all Hondas are capable of using J2534, which is used in Tactrix.



Older ECUs (about 2004 -> 2007 MY) are equipped with SH7055. Posted dump from such one.
If anybody is interested about helping me include those ECUs into Romraider - feel free to contact.
I've got bins and hardware to work onto. Some things like maps addr/size are already done.

Has the J2534 reflash process been reverse-engineered ? How are you guys dumping / reflashing the ECUs ?

I've done a few civic, accord/tsx & some crv


the bin posted
hardware id 36F8: 37805-RBA-3060

Speaking of older (<2008) ECUs:
Let's say "commercially avaiable" datalog+reflash tools are using OBD to flash control unit (and one of them has tactrix-look-like interface).
Unfortunatelly they require specific ECU from US market to work with - probably because of known or decrypted SID key mechanism.
If your'e not lucky, you have to rip off ECU and flash it using AUD port.

Heard of success work using Openport with CAN-equipped cars, using 3rd party software like Chiploader, MMCflash, PCMFlash. Anybody did job with K-line?

I currently have to use a FlashPro to tune my Honda ECU but I would love to do it with a Tactrix cable since then I can add more maps to be tuned on my own after disassembly. Anyone figure out how to read and/or write with the Tactrix OpenPort 2.0?

PCMFlash have a good K-Line database. For the one they don't have I use my serial suite to read it.
I'm also looking to work on Honda from 2004+.

It does not seem anyone on here is interested in collaborating.

I am! I have been leading and developing the project to disassemble the BMW MS41 ECU and have written all the definitions for it. Feel free to gauge my level of ability by skimming through some threads here. viewforum.php?f=42
I've been able to even write custom code for the ECU to repurpose some existing inputs/outputs with different logic etc.

I was a total reverse-engineering n00b 4 years ago but have learned a lot since then. Long ways to go still but I'm sure I can help this effort.
The biggest thing though is to get the processor operation manual, and get the file setup in IDA to display properly. I had the luxury of having an old-school disassembler guru help setup the pages, segments, and figure out which areas of the binary are program vs bootblock vs. RAM, etc.

Any chance you have 37805-PZX-A080? My AUD dumps haven't been consistent, probably due to both flaky hardware and software. For what it's worth It looks like at least some of the 7058 based roms have a second IVT at 1004 like what Fenugrec observed with some of the Nissan roms.
I've been working on decoding the HDS Rewrite files and have most of the structures identified but I don't have the algo to unscramble the calibration portion. It appears the calibration is scrambled on a per byte basis similar to what you'd see in the reflash traffic on the CAN bus.
I've also been making headway with the reflash procedure but the SID27 and scramble algos are tripping me up, I'm still new to reverse engineering firmware.
Last year I wrote a sim to talk to reflash software and had started on brute force collecting the SID27 seed/key pairs for the PZX-A08 and guessing the next pair but after so many pairs the iteration pattern would change. I've been kinda ADD about things so progress has been sporadic.

Actually any dump that is the same program version as an HDS Rewrite file would be helpful. The approach I'm leaning towards right now is decrypting the calibration in the HDS Rewrite file. If my speculations about the .RWD file header are correct, this is probably how Hondata/KTuner and the like are adding support for as many program versions as fast as they do.

Attached bunch of collected information from romraider Subaru thread. It might be useful for disassembly, cause some Subi ECUs got Renesas SH processors as well.
-Renesas family description: mem size, addr;
-IDA SH3 additions;
-SH3 Register names

@fenugrec is currently doing great Nissan job at: https://github.com/fenugrec Thought that would be kind helpful, since older Nis Ecus are also based on 705X.

So I managed to get a good read off my spare ECU finally. Comparing it to the CRZ and two other 7058 based dumps show a lot of similarities in the first 32k. I found what look like flashing routines, they look like what I'd expect based on Fenugrecs reflash kernel and what I've seen in the official docs. Unfortunately I've only got an xref to it's start address on the CRZ dump. On the PZX and RNA dumps they are just sitting in between other functions. I had noticed that sometimes the code will move a hex value to a register and later reference that register (@Rn) and the taget location doesn't get an xref. I'm still fiddling with the analysis settings but I think I've got most of it. Also I switched back to the regular IVT instead of IVT_1004. My thoughts on that initially were that I was seeing more subroutines automatically unfolded using IVT_1004 until I went back and tried the original IVT and it automatically unfolded code that I had manually marked in a previous run through. So my suspicions of the kernel(first 32k) holding the CAN handler are a little closer to being confirmed. During a J2534 reflash procedure I can confirm that no reflash kernel pass over the bus so it had to be getting it from somewhere in rom(confirmed). I also finished understanding the structure of the reflash file but there are two section whos values I still don't know the meaning of, I'll get up a pic shortly of it. Also the honda J2534 software doesn't check whether or not the FWE pin is pulled high and will try to flash as long as it gets the right messages.

Edit:
I may be using the term kernel wrong in regards to the first 32k. Iv'e got a hunch that the ECU can operate on just that if necessary to facilitate reflashing in the event of a bad flash

My bad, the FWE pin needs to be pulled low for write enable.


Here we have the header for a Honda J2534 reflash file.
I didn't mark all the areas, just enough to get across what to look for.
I'll be referring to sections by their hex addresses.

0x00 tells the reflash software what type of reflash this will be. 5A is for CAN based ECUs from what I can tell.
0x01 - 0x02 are a section boundary as far as I can see. 0D0A is used extensively in the K-Line reflash files, but only here on CAN reflash files.

From here to the flash start location at 0x8E each section has a two byte header.
The first byte is for how many objects are in this section, the second byte is for how many bytes(in hex) the next object is.
(Not sure what else to call them so I'll call them objects for now).

At 0x03 and 0x04 we have 01 and 01 so this section only contains one object at one byte long.
(I don't know the significance of the object and I've only ever seen 00 here.)

Section 2 (starts at 0x06) start with 01 and 04, so one object at 4 bytes long (01 F8 53 3E).
This is the CVN for this calibration.

Section 3 (0x0C) is the target CAN module address.
I've only had access to two different Honda ECUs but they both used 29bit CAN addresses(18DAF1XX), so the software will be looking for a module responding with 18DAF110.

Section 4 (0x0F) has all the Calibration versions in the program family up to this current version.
The program version shows up twice in a full dump as far as I've seen, once somewhere before 0x7FFF and once after.
The one before 0x7FFF will be of the initial program version, 37805-RTW-A010 in this case.

Section 5 (0x65) This one is an unknown but it does show up twice in a full dump, usually near the program version.
Maybe a hardware family identifier?

Section 6 (0x89) This is also an unknown but it gets passed over CAN just prior to "Request Download" as a "Write By Identifier" F101.
I have multiple traffic captures from third party software where the same calibration is being downloaded but this WBI is different and so are the scrambled bytes.
The Honda software doesn't do this though, it uses the same value each time and the scrambled calibration is the same each time.
This leads me to believe it is implicated in the scrambling process.

The next 8 bytes starting at 0x8E are the start address (0x00008000) and download size (0x000F8000) of the calibration.
These are used in the "Request Download" UDS message.

The rest of the file (0x96 and on) until the last 4 bytes are the scrambled calibration.
I'm unsure what the last 4 bytes are but they don't appear in the raw flash so maybe a checksum.

This probably won't be immediately useful as the meat of the J2534 reflashing still needs reversed (SID27 algo and what not) and also the calibration checksums.
If I get the calibration checksums and scrambling worked out I have half a mind to roll my own RWD reflash file as a POC before moving on to a from scratch reflash program.