RomRaider

At a quick glance it looks a lot like low-level 7055 (the older 350nm variant) flash routines. The equivalent func in npkern is flash_write128() here : https://github.com/fenugrec/npkern/blob ... 0nm.c#L374

I don't advise looking at that part of your kernel too closely, unless you enjoy pain, and you're very familiar with that section of the datasheet.
Is it possible other ECUs you've tried have the newer 180nm 7055 ? (entirely different, incompatible flash routines)

Although it shouldn't matter if the ROM always contains the correct built-in kernel ... or I misunderstood the issues you're having.

Oh yes, it's the end of racing season so I'll have time to get back into this.. and y'all have taken off!

@fenugrec thanks i hadn't considered the NM changes being the issue. that's a good thing to check. As far as i know all RX8 ecus use the same but i should double check. I think you misunderstood just a little bit, the kernel i have is not the same as what's built into the ROM itself. It's a special bootloader that must be loaded into ram at a specific address (0xffffa0000 if i remember correctly) and only has a handful of features features.

The flash procedure is a handful of UDS commands to the ECU, something along the lines of

7e0 10 81 - enter diag mode 81 (this one doesn't seem to actually be required)
7e0 10 85 - enter diag mode 85
7e0 27 00 - request seed
7e0 27 02 [XX XX XX] - send key calculated w/ seed. (i actually found a way to bypass this check)
7e0 34 0400 7800 - request download, 0400 chunk size, 7800 length
7e0 36 [payload] - transfer data.

The transfer sends over the kernel + ROM. When the ECU reads in the string "SBL_END", it sends a 78 (request received, response pending) then does an unconditional jump to ffffa0000. This is where things fall apart, and i haven't quite determined why.

When i load the kernel on my working ECU, the kernel then completes the download, writing to flash as packets are transfered. (PSA: do not cancel a download halfway thru ). When the transfer completes, the ECU sends a 76 transfer OK, then waits for a 37 Transfer Exit command. This handler checks that the number of bytes transfered equals 0x80000, and replies with 77 (transfer exit ok). Finally, the PC sends a 11 01 (request ECU reset) which the kernel replies with 51 (reset ok) when enters a while look that does nothing forever. Power must be cut then reapplied. the ECU boots into the new rom now.


Now. When i load the kernel on any non-working ECU, the ROM sends 78, jumps to the kernel then instantly sends 72 (generalProgrammingFailure). in the code, i can find that this is basically the fallback response, if nothing else works, this is what it sends. I'm still trying to find exactly what causes it, but upon reading the code, pretty much the only thing that can fail is the flash write function i posted last night.

[edit: previous post was duplicated twice.]

Ah I see. Similar to some Nissans. Do you control the loading address or is it hardcoded in the ROM ? For Nissan it's the latter, and the address sometimes changes; this means the kernel must be compiled in a very specific way (or customized for each possible load address). Hopefully this is not the case here.

I'm still investigating that. I suspect what you are saying is correct, but i haven't confirmed. Of my 6 ECUs, the kernel i have allows me to upload a ROM onto two of them. I send the kernel to the others, but they go out to lunch after that. the code says it SHOULD send back a GeneralProgrammingError, so i don't think it's even making it that far. What i can assume is that they jump to the kernel and then crash. I'm not 100% sure how to proceed with those yet but i'd love to hear some ideas if anyone has them.

What i know so far is that there's a RequestPayload UDS command that gets sent to the ECU, you supply a "chunk size" and a "payload size" with this command. The ROMs i've decompiled so far indicate that both of those params must be supplied, IE they are checked when supplied, and they can't change, no matter what you supply in either param, it uses hard coded values of 0x400 and 0x80000 anyway. ReadMemByAddress is the same, you can supply a chunk size there, but it uses 0x100 no matter what you supply. The annoying thing about both of these is that the code doesn't check for the values to equal what they are hard coded to be, so it'll happily read out more memory but then increment the address by 0x400 or 0x200 anyway. as it turns out, i didn't know this and had a bug in my rom dump code because of it that lead me to not be able to recover a backup i've confirmed the download/upload code works correctly now, i'm still cleaning up the code for it, but it seems pretty solid for the ECUs it does work on.

As for the non-working ones, i think there must be another kernel compiled to be in a different location in RAM or something. sniffing the logs doesn't help much as once they jump to the kernel, they stop responding. I guess i could write a script to patch the kernel, most of the addresses seem to be stored in pointers that are in the kernel itself. It sounds like too much work tho to me.

Mazda actually has a thing where you can pay $35 for a day use pass of sorts i'm considering doing that and collecting the different kernels to see what their general difference is. Feels like cheating to me tho, so i'm gonna struggle with it for a little longer.

I don't remember if i've said this already, but i got npkern working as a replacement kernel already, so it might be easier to just use that. if i'm being honest, that does sound more fun to me.

Any success looking at the ROM disasm to find the part where they jump-to-ram ?


Unless it's a type of relocation table that says where the addresses-to-adjust are, it is indeed going to be a pain to maintain.


I would really consider it - you could harvest a nice variety of different kernels and different ROMs. Can be useful to confirm whether your assumptions are valid , like e.g RAMjump target. Granted you're up against a restricted set of vehicles if you're just after RX-8 tuning, but still.


Haha that's awesome, I was going to suggest it. I'm starting to think seriously about reworking npkern a bit more to accomodate different platforms - started as Nissan-only, then Subaru, now maybe Mazda...
If you plan on going forward in that direction please open a ticket on my github repo and we can discuss there.

I found the jump to ram. It unfortunately doesn't disassemble very well for some reason, but if you look at the assembly, it's a little easier to figure
out what's going on. there's quite a few jumps that disassemble like this, i haven't been able to figure out exactly why, but i think it's something to
do with areas being marked as writable/executable in ghidra.




Anyway the rest of that function is pretty readable, it basically checks for the string "SBL END", then marks a global variable as true, and when the transfer completes, it jumps to that address. You can also see the hard coded 0x400 here as well.

To be expected, since ghidra can't follow the code flow past that jump. I think you can mark functions / jumps as "no-return" but it won't be a miracle.

Ok, so that one jumps to ffff dfa0. Interesting, that's a pretty big payload if it starts at 'A000 ?


Make sure the ROM area is marked RX, not RWX. If you used my ghidra scripts it should do that automatically (as well as marking interrupt vectors and IO peripheral regs)

yeah i used your script, thanks for it by the way! saved me a ton of work. I found your issue on the Ghidra github about the RX/RWX thing as well.


I'm double checking this as i don't remember where i came up with this number.



So after the security checks pass around line 21, it does a check that the SBF (UDS subfunction) equals 0x8. I'm not exactly sure how i overlooked this, but i never send 0x8 in the RequestDownload payload, nor does one get sent in the confirmed good log i have..

What gets sent looks like: (7e0 is the CANID for request from my software on the PC, 7e8 is the response from the ecu)



to decompose that a bit, (apologies if the UDS/ CAN-TP primer isn't needed)
1[0] - UDS "first frame" this is actually to nibbles, 1 is "first frame", the other half is the start of a 12 bit length field
[0]09 - 0x009 bytes long (34 00 00 40 00 00 07 F8 00 [00 00 00 00 <- padding to fit in a CAN frame] )
34 - UDS request download
00 - UDS SBF? (this should be 0x8 according to the code..)
00 00 40 - 0x400000 - at first glance, i thought this was 0x400 which is a critical number, see below. I'm realizing i'm probably wrong about this now
3000000000000000 - from ECU, control flow frame "continue sending payload", because this message is 09 bytes, it must be split over two CAN frames
[2][1] - UDS Consecutive Frame, frame index=1 (this number increments for every Consecutive frame, this payload only requires one)
07 F8 00 - 0x7f800 - payload length. Kernel=0x1800, ROM = 0x80000. Rom is offset by 0x2000, first 0x2000 are the SBL.


Now, originally as you can see in the disassembly, i thought the first param, 0x400000 was the chunk size so the functions and variable names reflect that, but i'm now realizing that it's actually meant to be an address(?) or something like this in RAM. It's added to RAM_START which is an address 0xffff6000, so following the code, it assigns the uds_transfer_start_ptr pointer to ffffa000.


I've updated the variable and function names to something that looks a little better. I can't get the pointer math to cleanup, but the gist of it is making sure the address is lower than the payload length such that all the data fits.


I haven't tried changing that first param (0x400000) yet. When i load the kernel into ghidra, it only cleanly disassembles if the base address is set to ffffa000

another issue i'm having is disassembling the entry point, i know it's not particularly important but it's been scratching the inside of my brain for a few days and i'm getting frustrated by not understanding why ghidra doesn't like it.

this is what it spits out in the decompiler window (after enabling unreachable code)

and this is the bulk of the actual code


I'm quite certain this is what handles the checksum validation, i'm just having a hard time making sense of it because ghidra (rightfully) doesn't think that the data can change at these addresses since it's marked RX not RWX.

If i mark the ROM as writable, it makes code that at least makes sense, but completely butchers everything else


any ghidra experts out there know what's going on here?

What entry point is that ? after power-on reset ? Doesn't look like it deals with a RAMjump in there ...

I'm not sure what you're missing in the first excerpt, I can't see it at a glance. I find the last one nearly unreadable with the PTR_FUNC_XYZ , PTR_DAT_0000054 etc.
Incidentally, posting screenshots like that is not always great. Some of them are barely readable, I need to open in a new tab to zoom in...

You could always just paste the code in a formatted-code block e.g.


Granted you lose the syntax highlighting but at least it's readable.


Ok, and a different function is calculating the checksum and saving it to the "CHECKSUM" variable ? Still not seeing the problem here, and not seeing the connection with kernels / ramjump.

Heh sorry this is POR entrypoint, has nothing to do with the kernel, just had a bit of an ADHD moment and got a little distracted. I'll use Code Blocks in the future, was just being lazy. My main issue with this entrypoint is that ghidra is optimizing out conditionals that it thinks can't change, right before all this business happens, the checksum does seem to get calculated, it works exactly the same as dbw subarus.



Anyway, in other news i chatted with a friend who reversed the NC Miata ECU, it uses a 7058 MCU so it isn't exactly the same, but the process for updating calibrations for that ECU is much the same as the RX8. He told me there are 2 unique kernels for the ECU of that car even tho the hardware is the same, so that leads me to believe there must be (at least) another kernel out there for the S1 rx8 as well. After work today, i will try to pay mazda about it to harvest the kernels.

so i spent a bit of time today with my hacked up version of npkern. took me ages to get the cross compiler working correctly, then even longer to get the right linker config to boot the kernel. I finally succeeded in getting it to sent out a familiar frame - deadbeef



Still a ton of work to do, notably the watchdog resets the ECU. the npkern routine for disabling it doesn't seem to work for some reason, couldn't figure out why exactly. More to come..

OOoooooo baby!

If you want some donation cash for buying up Mazda related things.. let me know. I'm short on time, and more so knowledge at this point, so I would like to substitute money if that is a roadblock for the community!