checksums

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

Hi,
I was vaguely looking at
src/main/java/com/romraider/maps/Rom.java :: saveFile()

and noticed that it's pretty hardcoded for the Subaru-type of checksums.
Would it be possible to adapt it slightly to accomodate Nissan-type checksums ? I'm not well-versed enough in RomRaider internals, and sufficiently incompetent at Java...

The Nissan algo is quite simple (enough that I could rewrite it in Java), and is entirely defined by 4 parameters, which can be stored in the xml defs :

Code:

(I just used the <checksum> tag because it seemed cleaner than defining a <table> type)

One non-intrusive solution I have in mind would be to continue using the default (Subaru specific) checkums in SaveFile, unless there is a <checksum> tag : then a switch/case construct would support extra types.

dschultz · **Posted:** Fri Jan 20, 2017 6:31 pm

I see no problem changing/expanding the checksum code.
As it stands if the definition has a checksum tag then two things happen:

On ROM open the checksum is calculated and verified, a warning is issued if they don't match
On save the new checksum is calculated and updated in the saved file, with an option to correct an invalid checksum found on opening

Adding an attribute to the checksum tag where the attribute is the name of the calculator class to be used makes it easy to drop in new calculators in the future.

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

dschultz wrote:

As it stands if the definition has a checksum tag then two things happen:

I'm not sure I understand, are you saying <checksum> is already recognized and parsed ? Or did you mean a <table> with name="Checksum Fix", like many of the existing defs in ecu_defs.xml have?

dschultz · **Posted:** Sat Jan 21, 2017 4:14 pm

Yes I was referring to the <table> named checksum. We can expand on that or create a new element.
If a new element is preferred then I suggest it goes in the <romid> section.

murphys_law · **Joined:** Tue May 24, 2016 1:45 am **Posts:** 216

I don't have much to add here, but I can say that adding a checksum function would greatly simplify working with Nissan rom files.

murphys_law · **Joined:** Tue May 24, 2016 1:45 am **Posts:** 216

dschultz wrote:

Yes I was referring to the <table> named checksum. We can expand on that or create a new element.
If a new element is preferred then I suggest it goes in the <romid> section.

Any thoughts on getting this going?

I've got 0 to add for Java, but would be willing to help any other way that I can.

dschultz · **Posted:** Thu Jun 22, 2017 9:20 am

I'm not that familiar with these ROMs, can you provide the background on the checksums?

I presume you need it to validate on opening and warn if mismatched, then after ROM editing calculate the new checksum. This is what happens currently for Subaru ROMs.

murphys_law · **Joined:** Tue May 24, 2016 1:45 am **Posts:** 216

dschultz wrote:

I'm not that familiar with these ROMs, can you provide the background on the checksums?

I presume you need it to validate on opening and warn if mismatched, then after ROM editing calculate the new checksum. This is what happens currently for Subaru ROMs.

That's exactly what I would envision it to work.

Feugrec has a cli tool that is currently used which I assume would provide all the intricacies of how it works(https://github.com/fenugrec/nissutils/b ... isckfix2.c) and I would imagine he could give insight into questions as well..

The definitions that we have for Nissan roms already have some checksum location information in them as fenugrec mentioned above as well.

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

dschultz wrote:

I'm not that familiar with these ROMs, can you provide the background on the checksums

Pretty much this :
https://nissanecu.miraheze.org/wiki/Che ... _.22std.22

in C, it looks like this (from https://github.com/fenugrec/nissutils/b ... lib.c#L428 )

(buf is the array of raw bytes; the calculated values are stored to *sum and *xor).

Code:

/* sum and xor all u32 values in *buf, read with SH endianness */
void sum32(const uint8_t *buf, u32 siz, uint32_t *sum, uint32_t *xor) {
   u32 bufcur;
   uint32_t sumt, xort;

   if (!buf || !sum || !xor) return;
   sumt=0;
   xort=0;
   for (bufcur=0; bufcur < siz; bufcur += 4) {
      //loop each uint32, but with good endianness (need to reconstruct)
      uint32_t lw;
      lw = reconst_32(&buf[bufcur]);
      sumt += lw;
      xort ^= lw;
   }
   *sum = sumt;
   *xor = xort;
   return;
}

dschultz · **Posted:** Fri Jun 23, 2017 2:55 pm

Would a ROM have more than one checksum type that needs to be updated?

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

dschultz wrote:

Would a ROM have more than one checksum type that needs to be updated?

For the typical use case of Romraider : never. A second/alternate checksum would only need to be corrected if someone does very low-level modifications to the ROM (inside a specific bootloader / core code area that has nothing to do with maps or tunable parameters). One wouldn't use RR for this anyway, so I don't expect it to become an issue.

dschultz · **Posted:** Fri Jun 30, 2017 2:55 pm

Can you point me to a ROM file and def which has current and correct checksum values in it?

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

dschultz wrote:

Can you point me to a ROM file and def which has current and correct checksum values in it?

sure -- stock 8U92A
with the defs in murph's repo, https://github.com/murphyslaw05/NissanDefs
we've split them so one needs to run "combine_all" to concatenate the table templates plus ROM defs into one XML file.

dschultz · **Posted:** Tue Jul 04, 2017 6:13 pm

Implemented in https://github.com/RomRaider/RomRaider/ ... a10c404c03

murphys_law · **Joined:** Tue May 24, 2016 1:45 am **Posts:** 216

dschultz wrote:

Implemented in https://github.com/RomRaider/RomRaider/ ... a10c404c03

WHOAH. That is AWESOME! Thank you so much!

RomRaider

Forum rules

checksums

Who is online