Mazda RX-8 rom

equinox92 · **Joined:** Tue Nov 21, 2017 7:56 pm **Posts:** 61

fenugrec wrote:

equinox92 wrote:

The tool is then going to send this kernel, and the kernel will handle the rest of the incoming sent data from the tool?

- SID 36 TransferData, send the kernel encrypted with the "sid 36" key; ECU decrypts+copies to &RAMjump (often FFFF8438 but varies)

Could explain a bit more what you mean by "encrypted with the "sid 36" key"?? This may contain the missing link in my brain.

From my log of a Mazda reflash (used by an external tool so feel free to delete if not allow) This is basically what's going on:

Code:

     Time         Chn     ID    Name   Event Type   Dir    DLC   Data                      
     102.692861   CAN 1   7E0          CAN Frame    Rx     8     02 10 81 00 00 00 00 00   
     102.693251   CAN 1   7E8          CAN Frame    Rx     8     02 50 81 00 00 00 00 00   
     102.732255   CAN 1   7E0          CAN Frame    Rx     8     02 10 85 00 00 00 00 00   
     102.732747   CAN 1   7E8          CAN Frame    Rx     8     02 50 85 00 00 00 00 00   
     102.733701   CAN 1   7E0          CAN Frame    Rx     8     02 27 01 00 00 00 00 00   
     102.734089   CAN 1   7E8          CAN Frame    Rx     8     05 67 01 1D BB D6 00 00   
     102.734837   CAN 1   7E0          CAN Frame    Rx     8     05 27 02 FF 78 96 00 00   
     102.735927   CAN 1   7E8          CAN Frame    Rx     8     02 67 02 00 00 00 00 00   
     102.736837   CAN 1   7E0          CAN Frame    Rx     8     04 B1 00 B2 00 00 00 00   
     102.737623   CAN 1   7E8          CAN Frame    Rx     8     03 F1 00 B2 00 00 00 00   
     102.746499   CAN 1   7E0          CAN Frame    Rx     8     10 09 34 00 00 40 00 00   
     102.746773   CAN 1   7E8          CAN Frame    Rx     8     30 00 00 00 00 00 00 00   
     102.747043   CAN 1   7E0          CAN Frame    Rx     8     21 07 F8 00 00 00 00 00   
     102.747319   CAN 1   7E8          CAN Frame    Rx     8     03 74 04 01 00 00 00 00   
     102.749063   CAN 1   7E0          CAN Frame    Rx     8     14 01 36 9D 6F 4D 0B 00   
     102.749339   CAN 1   7E8          CAN Frame    Rx     8     30 00 00 00 00 00 00 00   
     102.749990   CAN 1   7E0          CAN Frame    Rx     8     21 09 EE 00 D3 3F 6C E3   
     102.750236   CAN 1   7E0          CAN Frame    Rx     8     22 43 2E 92 69 22 E2 91   
     102.751642   CAN 1   7E0          CAN Frame    Rx     8     23 68 90 68 20 12 93 67   
     102.751884   CAN 1   7E0          CAN Frame    Rx     8     24 91 67 21 31 94 66 D3   
     102.752132   CAN 1   7E0          CAN Frame    Rx     8     25 3A 62 41 22 39 24 21   

-Two diag session levels 10 81 and 10 85 (though it doesn't seem to care about getting a 10 81 first)
-seed/key exchange 27 01, 27 02
-04 B1 00 B2 looks like it puts the ECM into bootloader mode (regular CAN traffic stops, so I just assume app software stops running), doesn't appear to be a UDS thing but a Mazda thing. Doesn't respond to a transfer request without this command
-Transfer Request 34 00 00 40 00 00 07 F8 00 with the relevant info..
-Data transfer 36 ... and then just cranks out data from there until forever as far as the log goes. I've redacted it since it would contain other flash software that could be parsed out.

In this situation I am having a hard time understand where the kernel is flashed or running vs flash programmed code.

Any insight from anyone would be loved!

I've got a bit of a ghetto python program to be able to do all of this handshaking with a taxtrix, just need to add the code to parse a .bin file to upload... but stuck not understanding how I need to send a kernel, and obviously which content the kernel needs to contain, which is where all of the Qs stem from.

fenugrec · **Joined:** Wed Jan 08, 2014 11:07 pm **Posts:** 593

equinox92 wrote:

Could explain a bit more what you mean by "encrypted with the "sid 36" key"??

It's a nissan thing. They encrypt both the kernel on the way in, and (when using the Nissan kernel), the ROM data. Probably not applicable to your ECU.

Quote:

-Two diag session levels 10 81 and 10 85 (though it doesn't seem to care about getting a 10 81 first)
-seed/key exchange 27 01, 27 02
-04 B1 00 B2 looks like it puts the ECM into bootloader mode (regular CAN traffic stops, so I just assume app software stops running), doesn't appear to be a UDS thing but a Mazda thing. Doesn't respond to a transfer request without this command
-Transfer Request 34 00 00 40 00 00 07 F8 00 with the relevant info.

You might not need a kernel at all. More recent CAN Nissan ecus have the kernel builtin; they just need to copy it to RAM and execute there. I presume the B1 00 B2 00 stuff takes care of that. Unless : if you notice a clear break in your traffic log after 3-10kB, then some different UDS requests, then again 512k / 1024k of traffic, you might be dealing with a kernel. Or, if you have a complete capture, and you know for sure (after removing the UDS protocol overhead) you have an even 512*1024 or 1024*1024 bytes, then that's almost a guarantee there is no kernel required.

equinox92 · **Joined:** Tue Nov 21, 2017 7:56 pm **Posts:** 61

The lack of kernel thing is what I originally thought since it's just UDS transfer data until transfer exit.. however when I look at the data sent to the module, a chunk of 595 bytes doesn't show up in my dumped rom (read by address starting at 0x0 after this reflash) so I just assumed there was a kernel being loaded, but it's REAL small

Any thoughts on that? I can share the full dump via PM, like I said it's an external tool so I don't want to throw IP out there.

equinox92 · **Joined:** Tue Nov 21, 2017 7:56 pm **Posts:** 61

here's snip from the ECU's response after the first 1k (i believe, I can double check if it matters. It's whatever amount of data is specified by the 0x36 in the previous post) is transmitted

Code:

     Time         Chn     ID    Name   Event Type   Dir    DLC   Data                      
     102.788447   CAN 1   7E0          CAN Frame    Rx     8     2F 0B 60 41 E6 02 2F E6   
     102.788704   CAN 1   7E0          CAN Frame    Rx     8     20 E1 08 2F C6 EE 02 2F   
     102.788956   CAN 1   7E0          CAN Frame    Rx     8     21 B6 EC 00 4F 22 7F F4   
     102.789210   CAN 1   7E0          CAN Frame    Rx     8     22 85 41 6B F3 00 00 00   
     102.790382   CAN 1   7E8          CAN Frame    Rx     8     01 76 00 00 00 00 00 00   
     102.791932   CAN 1   7E0          CAN Frame    Rx     8     14 01 36 67 03 7B 04 63   
     102.792206   CAN 1   7E8          CAN Frame    Rx     8     30 00 00 00 00 00 00 00   
     102.792556   CAN 1   7E0          CAN Frame    Rx     8     21 03 73 01 2B 30 36 BC   
     102.792804   CAN 1   7E0          CAN Frame    Rx     8     22 60 40 65 63 80 B1 74   
     102.793052   CAN 1   7E0          CAN Frame    Rx     8     23 04 2F 62 63 7D 43 15   

The ECU just response with a 01 76 and the server keeps going with a 36 transfer data.

I recall about a year ago (or more) I tried to send it a full block of code, and the ECM gave me a 0x7F after the block. I could be mistaken but. yeah. dunno

fenugrec · **Joined:** Wed Jan 08, 2014 11:07 pm **Posts:** 593

equinox92 wrote:

a chunk of 595 bytes doesn't show up in my dumped rom

I find that suspicious. Not saying it's impossible to have a 595 byte UDS on CAN kernel, but I would say extremely unlikely, would have to be extremely minimal and hand-written assembly.

Either they don't modify a part of the ROM (is there anything interesting in the first / last 600 bytes ? Just the reset vector tables take up at least 0x400 (1k) at address 0...

Is your interpretation of the data the same as mine ? : (note, if you can somehow load this traffic in wireshark, it can decode the UDS frames for you)

Code:

749063   CAN 1   7E0          CAN Frame    Rx     8     14 01 36 9D 6F 4D 0B 00   
749339   CAN 1   7E8          CAN Frame    Rx     8     30 00 00 00 00 00 00 00   
749990   CAN 1   7E0          CAN Frame    Rx     8     21 09 EE 00 D3 3F 6C E3  

14 01 36 9D 6F 4D 0B 00 : I see "multi-frame message, payload length 0x401 , first data 36 9D ...
30 00 00 00 : flow control reply
21 09 EE 00 .... : first "continuation frame", data 09 EE 00 ...
22 : second continuation frame , etc

e.g. 7 bytes of data per CAN frame.
For the very last "continuation frame", I think it will still fill an 8-byte CAN frame but some bytes may be just padding. Are you perhaps including some padding for every block ?

equinox92 · **Joined:** Tue Nov 21, 2017 7:56 pm **Posts:** 61

fenugrec wrote:

equinox92 wrote:

a chunk of 595 bytes doesn't show up in my dumped rom

I find that suspicious. Not saying it's impossible to have a 595 byte UDS on CAN kernel, but I would say extremely unlikely, would have to be extremely minimal and hand-written assembly.

Either they don't modify a part of the ROM (is there anything interesting in the first / last 600 bytes ? Just the reset vector tables take up at least 0x400 (1k) at address 0...

I agree, it's a weird number of bytes. It could be hand written assembly though... but yeah. Weird.

fenugrec wrote:

Is your interpretation of the data the same as mine ? : (note, if you can somehow load this traffic in wireshark, it can decode the UDS frames for you)

Code:

749063   CAN 1   7E0          CAN Frame    Rx     8     14 01 36 9D 6F 4D 0B 00   
749339   CAN 1   7E8          CAN Frame    Rx     8     30 00 00 00 00 00 00 00   
749990   CAN 1   7E0          CAN Frame    Rx     8     21 09 EE 00 D3 3F 6C E3  

14 01 36 9D 6F 4D 0B 00 : I see "multi-frame message, payload length 0x401 , first data 36 9D ...
30 00 00 00 : flow control reply
21 09 EE 00 .... : first "continuation frame", data 09 EE 00 ...
22 : second continuation frame , etc

e.g. 7 bytes of data per CAN frame.
For the very last "continuation frame", I think it will still fill an 8-byte CAN frame but some bytes may be just padding. Are you perhaps including some padding for every block ?

your interpretation matches mine.

I don't think there is any padding, and I say that because as soon as the first 595 bytes are sent, all of the data shows up in the dumped ROM without padding. I suppose it's possible those first had some padding in it.. but damn that's not a lot of data.

I can share the log with you via PM. what file formats work best for you? I can do .asc, .blf, and .mdf.

equinox92 · **Joined:** Tue Nov 21, 2017 7:56 pm **Posts:** 61

EDIT: Nevermind wrong again

fenugrec · **Joined:** Wed Jan 08, 2014 11:07 pm **Posts:** 593

equinox92 wrote:

I don't think there is any padding

I tend to disagree : e.g. this frame

Code:

102.790382   CAN 1   7E8          CAN Frame    Rx     8     01 76 00 00 00 00 00 00

Clearly the response is "01 76" , but it's still an 8-byte frame.

Quote:

what file formats work best for you? I can do .asc, .blf, and .mdf.

Hm, looks like wireshark may be able to open .blf files. I can take a quick look.

equinox92 · **Joined:** Tue Nov 21, 2017 7:56 pm **Posts:** 61

fenugrec wrote:

equinox92 wrote:

I don't think there is any padding

I tend to disagree : e.g. this frame

Code:

102.790382   CAN 1   7E8          CAN Frame    Rx     8     01 76 00 00 00 00 00 00

Clearly the response is "01 76" , but it's still an 8-byte frame.

Quote:

what file formats work best for you? I can do .asc, .blf, and .mdf.

Hm, looks like wireshark may be able to open .blf files. I can take a quick look.

Ah yep, fair enough. Those are most definitely padded haha.

Those have not been taken into account.

I'll PM you with a log sir.

RomRaider

Mazda RX-8 rom

Who is online