RomRaider

Hey all!

So I was checking out some KWP code in the ECU, and I decided to go over some of the other SID tree handler functions. That's when I stumbled across another $1A function that appears to rewrite a byte in ROM.

As you can see, Ghidra is saying that it's setting 0x418A = 0x59. I ran it through HEW and HEW said it actually does that. Checking my ROM dump shows that the normal value is 0x4E, meaning, HEW is even saying that it rewrote that value. Then at the end of that function block, you see it setting 0x418A = 0x4E (the normal value), implying that this would actually be something that can happen.

So my question is, can the ECU actually rewrite bytes in the ROM even when running from ROM? I know that it potentially wouldn't matter too much, as long as it doesn't mess with any critical code. (In this case, 0x418A is just an offset for an address) But it just seems hard to believe that you could actually rewrite whatever bytes you wanted just by treating it like a RAM address (in terms of the "@"). And if it actually can rewrite the ROM, what would the limits be? What's stopping you from rewriting any section of ROM (probably moreso data sections rather than code) at once?

To my knowledge, a block of flash memory, not a single byte location must be erased before it can be written.
Are you sure the address to write to is ROM and not RAM?

That's how I've always understood it as well. You've always had to erase the block and then rewrite the entire block, rather than just specific bytes.


That's the thing, it's most certainly showing as an address write to ROM. @(r0, r2) = 0x26 + 0x4164 = 0x418A. IIRC, everything <0x8000 is treated as a ROM value when called without the leading 0's, and anything >=0x8000 is treated as a RAM address when called without the leading 0's. On top of this, the fact that it returns 0x418A to 0x4E, which lines up exactly with the value found at 0x418A in my ROM dump, just makes it even more confusing. But I just don't see how you could ever write to ROM on the fly. I mean, it sorta goes against the entire concept of read-only memory. I was hoping that HEW would catch something funky, but it says it's writing to a ROM address.

The entire function is called as a response to a $1A (Read ECU ID) request, just under a different SID tree than the normal one. I've tracked the entire main comm function now, so I'm going to go through it and see if I can come to an understanding as to exactly WHEN it would use that separate SID tree. But that won't explain what's actually occurring here.

Not only that, there are registers that need to be set to very specific states to be able to do that, and you definitely shouldn't write to the same block you're executing from .


You're reading the code correctly, it's exactly what it *appears* to be doing. I remember posting about that a while ago maybe ? never made progress; my guess was

- at some stage of the production process, the ROMs have some minimal bootloader code, likely running that alternate SID tree you found - as I mentioned the other day I've never found a way to trigger that tree, which is unfortunate because the 1A handler returns the some interesting info, including the LOADERxx and 705XYZ strings.

- they must have a RAM emulation (RAMER) mode going on, where some pages of the ROM are mapped in RAM. See the datasheet for how that works.

- in normal ops, as I recall the 705x doesn't hardfault if you try to write to ROM ? it just drops the data. If you wanted to determine whether or not you're running with RAMER, that would be one way of checking : try to write to ROM, if the value stayed, then it's actually mapped to RAM.

I looked more than once for any evidence entering / leaving RAMER , both in the Nissan kernels and the ROMs, and never found anything.

Note that the values it's writing / checking can be seen as 'Y' and 'N' , inside the FID struct : I can't help but make the connection between 'YES ' and 'NO' although what it refers to is unknown.

I swear, if any of these SID trees go completely unused, I'm gonna be real upset The more commands, the better!


Do remember that just because it's not referenced by Nissan stuff doesn't mean that it doesn't exist! Look at $A0, for example haha I'd kill to have some help from Consult files with that one! But obviously the code would sorta HAVE to be able to do so.


Actually, the 0x418A value is the SH705823 "N" value. I included screenshots of the data and a function that reads the 0x418A value. Interestingly enough, it appears like it's actually used??? Going through the function references shows that it's (through enough BSR's/JSR's), linked to even the ROM signature and ROM written flag checks! (That function is all the way back at 0x13C) So I think this just got a whole lot more interesting. Now, the "cmp/eq" part not mattering is a bit underwhelming, but that code doesn't have anyway of not being ran (AFAIK). So every single time the ECU runs through that beginning function, it'll always have to go through this function. But this area of the ECU I know very little about, so I could be misinterpreting some things as a result haha

But thanks for sharing all that information! I'm glad I wasn't misinterpreting what was occurring haha

Edit; Forgot to mention, the destination address checks are for 01, 10, and 11 while the Tester Address checks are for FD. Those all CAN play a role in which SID tree gets called. There’s so much crap going on tho, so it’s not JUSTTTT that. But those are probably part of the reason why you haven’t been able to get them called. Oh, and the format byte gets checked a lot as well.