RomRaider

There are J2534 flashing procedures for both CAN and K-Line but it looks like tools like PCMFlash and MMC Flasher only support read for CAN Bus. I've started some cursory investigation of a K-Line sh7058 ROM (37805-PRB-A080) and it looks like it shares some CAN init stuff with the PZX but I haven't looked for reflash code yet.

Did you mean to say PCMFlash only supports 'write' for 'K-Line'? Because that's what the PCMFlash website says.


I am not skilled enough to code a reflashing utility by examining the ECU binary in IDA. Not sure if that is what you're planning to do at some point. I don't know if it's needed at this point if PCMFlash works as is.

Getting a file that can be interactively disassembled would be cool. I know you posted about some of this stuff (memory layout, register names, etc.) a couple pages back but I haven't yet had a chance to play with it.

I'm tuning my S2000 with Flashpro currently but it has very limited maps available. They try to keep it a 'walled garden' as much as possible and either don't want to or don't have the time to define the interelated maps for a given function. Once I get a file to disassemble semi-elegantly in IDA I will be able find the other associated maps like we've done with BMW MS41. I've even written custom code for it after many years of working on the project.

But anyway, I'd love to be able to read my stock ECU and then lay it out in IDA and start defining subroutines and variables. I can also write RomRaider ECU Definition files as I go.

Yeah, that's the way I meant it. I haven't seen K-line read advertised yet for a Renesas based Honda ECU, but I haven't looked too hard. I'd have to go back and look to see if Piasini had something K-line for the Oki ecus.

As for flashing, I've got the procedure down except for the SID27 auth, but that's only a matter of time.

For a little more complete disassembly of calibration files (0x8000-0xFFFFF) that I don't have full dumps of I mocked up a kernel (0x0-0x7FFF) in a separate file where the Reset Vector points to the entry point of the calibration (0x8008) and copied the IVT that starts at the address stored at 0x8004. It doesn't disassemble quite the same, but looks like more is automatically linked than not having the mock kernel.

*EDIT
The addresses above are for a sh7058 full dump. If looking at just the calibration, Entry=0x08, and IVT2=@0x04 for sh7058 and sh7254 and probably sh7059

Sure... J2534 is an API that defines a common set of functions to interface with a J2534 compliant cable. The cable supports various protocols vehicle and physical interfaces to communicate with ECUs.

I wrote rwd-xray to try to extract the firmware for the bosch radar in a 2017 Honda CR-V. The goal was to make it a general purpose rwd firmware extractor (and eventually generator), and it definitely still needs some work!

I recently updated it to brute force the simple substitution cipher by searching for the part number in the decrypted firmware. There are situations where multiple ciphers exist that result in the part number showing up in the firmware, but it is pretty good now. I know I should be validating checksums; should there be a way to identify and validate firmware checksums in a generic way?

Also, for what you guys refer to as the k-line file format (first byte 0x31) I currently output a single file, and if there are address jumps I insert 0x00 to fill all gaps. It sounds like I shouldn't do that; what is a better format to output the decrypted firmware?

I also recently figured out the last 4 bytes in the file is the sum of all the bytes in the file (except the last 4) little endian.

Good day to all.
Who learned how to read the checksum for sh7058 or sh7055?
Can you share the algorithm?

Hey, folks

Did anyone try to reflash any modules in Honda/Acura?
I managed to extract a firmware from .rwd (honda calibration file) and modify it. However, I'm having hard time trying to reflash modules.
First things first, I'm trying to obtain information about ECMs: their addresses and current firmware versions. In order to do that, I launch the latest Honda j2534 pass thru software using a Tactrix device. I'm sniffing CAN bus while the tool checks if any ECMs require updates. I expect to see at least a dozen ECMs on board, but there are only five ECMs (PGM, MICU, ACC, SRS, meter) that report their firmware versions. The Honda tool doesn't seem to bother checking ECMs like EPS and ABS. I'm sure those ECMs can be updated since there are calibration files corresponding to them. The j2534 communication sequence looks quite standard:
The ECMs are asked one by one with a specific command (below is a request to PGM MCU):
18DA0EF1 8 03 22 F1 90 00 00 00 00
then, the PGM replies with multiple messages that represent its firmware version:
18DAF10E 8 21 30 35 2D 52 34 48 2D ...

Does anyone have a clue why the Honda tool checks only certain ECMs?

I have not actually reflashed anything yet, but I have noticed there is a database that can be opened with ms access which seems to have something to do with keeping track of which modules have firmware updates. If you are starting the j2534 rewrite tool and it is not checking the version of all the modules you expect, is there something other than j2534 that honda may use to perform some firmware updates? Also, make sure the firmware update part numbers match your vehicle because I believe things like country come into play.

FYI, J2534 is not a communications protocol, it's an API. You might be better off looking at the vehicle communications protocol formats for ISO9141, IOS14320, J1850VPW/PWM, CAN etc.
In this sequence it appears to me as if 18DA is a header of some sort. 0EF1 (F10E) may be the addresses of the ECM and tester and visa versa in the reply. The reset most likely are length and command codes/ACK. But all is most likely manufacturer specific. It's not generic ISO9141, IOS14320 format.

18DA0EF1 is a 29 bit CAN address

To give you some context: I work on Acura ILX 2017 (USA) EPS module.
I explored the database back and forth trying to trick Honda Pass Thru to think there is a new callibration file. No luck. I also dissassembled the software to see where the version checks are. I was able to see that the tool compares versions only for the following modules:
37805-r4h-a120 pgm-fi
38808-tx6-a020 micu
36161-tv9-a140 acc/cmbs
77959-tx6-a230 srs
78109-tv9-a110 meter

I expect '39990-TV9-A910' (btw, your repository helped a lot. Thanks!) to show up for the EPS, but it never pops up anywhere in the Honda J2534 Pass Thru when it scans the car. Btw, I use a Tactrix device. Maybe I'm using a wrong tool or/and a device?


It doesn't matter how you call it - the bottom line: the tool communicates to the modules via CAN bus (correct me if I'm wrong). It is manufacturer specific but I can clearly see firmware versions. Chec this out:
107677 64168.208 18DAB0F1 8 03 22 F1 81 00 00 00 00  " ñ 
107681 64170.939 18DAF1B0 8 10 13 62 F1 81 33 36 31   b ñ  3 6 1
107682 64171.259 18DAB0F1 8 30 00 00 00 00 00 00 00 0
107693 64174.378 18DAF1B0 8 21 36 31 2D 54 56 39 2D ! 6 1 - T V 9 -
107696 64175.161 18DAF1B0 8 22 41 31 34 30 00 00 55 " A 1 4 0 U
107698 64176.095 18DAB0F1 8 03 22 E6 01 00 00 00 00  " æ

107704 64180.937 18DAF1B0 8 03 7F 22 31 55 55 55 55   " 1 U U U U

18DAB0F1 8 03 22 F1 81 00 00 00 00 - is a request from Honda's Pass thru tool. I interpret the '..B0F1' address part as 'module F1 to B0'. Then the B0 module replies (hence, the address is '...F1B0') with its firmware version: 3 6 1 6 1 - T V 9 - A 1 4 0. If you are curious I attached the whole CAN bus dialog with corresponding ASCII interpretation. It is the same situation as with the Honda Pass Thru software sniffing: I can only see five modules report their firmware versions over the CAN bus.

There is a bunch of unanswered request and it might be the case that some of the modules don't bother to respond (but why?). I also checked Honda Civic 2017 with the same Tactrix and Honda Pass Thru and I got the same result: only four modules report their versions, but this time, only one message didn't have a follow-up reply (logs are also attached). Which means the tool doesn't even bother to check all the modules! Maybe I'm really using a wrong set of tools?

Any thoughts?

Okay, so the comms is via CAN.

Here's the addressing breakdown:
18 DB xx F1 - 29 bit CAN identifier for functionally address request messages sent by external test equipment to ECU #xx
18 DA xx F1 - 29 bit Physical request CAN identifier from external test equipment to ECU #xx
18 DA F1 xx - 29 bit Physical response CAN identifier from ECU #xx to external test equipment

It seems that comms starts off with a query to see which modules are on the bus and gather there addresses for subsequent queries.
Subsequent query/replies follow ISO 15765-2 format.

In this sequence it appears the '22 E6 01' command (SID:readDataByCommonIdentifier) is not supported, hence the response of 7F 22 reason 31 (requestOutOfRange).

Maybe those other modules don't speak CAN or respond to the initial broadcast query. But if that's the case then the Honda software (I presume it's genuine) you are using should know that and attempt comms with other modules using other medium/protocols.

It turned out that the device I used (Tactrix OpenPort 2.0) is not friendly with Honda's K-Line (an EPS unit I was looking for was on the K-Line).
I got another device which was able to communicate to the EPS and I was able to reflash it with a custom firmware.

I'm just curious - what was the reason of yours EPS reflash and firmware mod? Did you encountered some software bug, or simply for training?

I'm using my car as a hobby project for self-driving systems and I need an ability to be able to control steering with CAN bus commands.