RomRaider

Hey everyone,

I was looking into the current state of reversing the MS43 and found Cloudforce's "Finding maps in IDA" thread [1] here on RR, where dschultz posted some awesome details a while back.

One question I had was if anyone ever located the OBD handlers, like mrf582 and Alec did for the MS41 [2].

I found one particular subroutine in seg16 with a jump table (at 0x84332), which defines cases 1,3,4,5,6,7,8,9 and then several more in the range of 0xB to 0x40. It seems to writes bytes before returning that look like OBD headers (i.e., 0x486B).

Can anyone confirm/debunk?


[1] viewtopic.php?f=43&t=11172

[2] viewtopic.php?f=42&t=11270

Yes that is the OBD message handling routine that you are describing.
But the address you mentioned is off, the routine starts at 0x94314 and the mode selection is at 0x94332.
Did you use the FormatMS43Segments.idc script when setting up the disassembly?

Thx for confirming that! Hm.. yea that is a bit weird, indeed, the beginning of the subroutine is 0x84314 in my file. I closely followed dschulz's description for setting everything up and used his formatting script that was linked in the post. Of course it's totally possible I just made a mistake somewhere along the way, but my file seems to be consistent with regards to xrefs and call sites being resolved correctly as far as I can see.

Let me check another full dump I pulled from a car recently.

Oh btw, I did not see it stated explicitly anywhere, but I'm just assuming I can patch up the program code section in those dumps and do a full write with Kim's flash tool (i.e., without putting the DME into bootmode and correcting any checksums).

As long as I keep the boot ROM section intact that should work, right?

I'll report back regarding the offset of that routine in the other file shortly..

What does the call instruction to the obd routine look like in your file? In my file the call instruction is DA 09 14 43, so segment 0x9 and absolute address 0x4314.



Yes you can do that, the boot sector will not be written during a DS2 protocol flash. If there is an error in the patch that makes the ecu loose control you can use boot mode to recover. But make it a habit to double/triple check any new patches before flashing them to the ecu.

Oops, sorry.. I was just being stupid about the way IDA lays out the addresses on the left. You are of course correct, the call on my first dump looks exactly the same and "copy address to clipboard" yields 0x94314. On the other file from a different car (which is at version 66), the offset is 0x94324.

I guess in this particular case the patch is really trivial, since I am essentially "just" setting byte 0x14DE6 from 40 to 00 (i.e., O2 heaters on the 66 version of the file). However, that made me wonder.. maybe I should cross-check the CRCs manually on the original dump, because god knows what kind of bit errors might have been introduced by these cloned FTDI cables or maybe the proverbial cosmic ray decided to strike in that very moment.

Is there any other way of verifying that the original dump pulled from the car is correct?

Update: At least chipster's checksum corrector for MS43 reported 0 of 5 corrected on the original dump, so I guess chances are the file I started with is somewhat consistent. It's kind of weird, though, the MS4X wiki documents 7 checksums (6 if we disregard the boot section, i.e., 2 CRCs and 4 additions).

Update2: Spoken too soon again LOL, after actually reading that part in the wiki the 4 additions are really just 2 additions, split into two parts each. So I should be good (famous last words? ).

final Update: Worked like a charm.. thanks @LKMT for the info!