RomRaider

Greetings, I've been working on a checksum correction algorithm for this specific ECU "19LE4B", and found 16bit sumt at 0x8200, 32bit sumt & 32bit xort at 0x99E2 and 0x99EA, there's another sumt checksum at 0x20000 but it looks like isn't important since it's out of the map calibration area.

Already implemented the correction in a python script (attached to the post), but it looks like there's another algorithm I'm missing which value is stored just behind the 32bit sumt and xort.

It looks like it's RIPEMD160 encryption since I found the keywords while disassembling at 0x798. I'm stuck at this point, what I've found is that this checksum covers the area just ahead of the sumt and xort values (starting from 0x99EC I guess). The values are stored as 16bit bytes at 0x99E0 & 0x99E8 (Just behind the 16 bit values from sumt and xort) but why are two values?

The script works with Python 3.11, and does not edit or create a new file, it only prints the corrected values, the values need to be updated manually since It's still a work in progress.

Any help or suggestions will be greatly appreciated. If I'm wrong about something please correct me.

Here's all I have about that algo : https://nissanecu.miraheze.org/wiki/Che ... RIPEMD-160

I hadn't looked very closely at it, but I think it'generates a 20-byte hash.

Did several corrections for such ROMs, never needed for RIPEMD checksum fix. It seems to cover only code area and unless you are doing some hacks on this level you won't probably need to amend it. Just try fixing checksums @ 0x8200, 0x20000, xort / sumt and check if it still fires the wrong checksum error, most probably it will not.

And be careful with the correction order - first you put sumt & xort values on their places in ROM, then calculate checksums for @ 0x20000 and 0x8200 locations as these values are included into calculation area.

Yes, it's supposed to generate 5 32bit bytes which can be read as 20 8-bit bytes. I did the crypto implementation in python using hashlib which has built in the RIPEMD160, but don't know if it's intended for the whole bin file or just sections, yesterday did a research in the sh7058 datasheet looking for the memory block length and currently planning on brute-forcing every block to find the region where the algo is applied, but I'm unsure if the process will work.

Yes, I realized that 0x8200 includes the sumt and xort values and has to be corrected at last.

... why not look at the disasm / decompiled code ?

Tried to do that, but I'm still very inexperienced with disassembling, can find data and subfunctions but not translate/interpret the assembly code