Checksums

= Checksum algorithms =

Depending on model year, the checksums are a combination of sums + xors of the whole ROM. But newer ROMs have an implementation of RIPEMD-160 which needs to be investigated (see 1KA6A, etc).

ck_std : "std"
Two u32 locations in the rom, "sumt" and "xort", are used to save this checksum. sumt = simple u32 sum of all u32 values of the ROM, excluding the sumt and xort locations. i.e.

for (i=0; i< romsize; i+=4) { if ((i == sumt_location) || (i == xort_location)) continue; sumt += rom[i]; xort ^= rom[i]; }

This checksum is constantly calculated and verified during runtime.

ck_alt : "secondary" / "alt"
most (all ?) ROMs have this one, as well as another cks. It is also calc'd + verified continuously.

It is the same "std" algo as described above, but applied to a region of the ROM described in the RAMF struct. On the ROMs I've seen, the u32 "alt_sumt" and "alt_xort" values are stored after the secondary IVT (&IVT2 + 0x400). The region seems to always start after the alt_* values (&IVT2 + 0x408; RAMF.altcks_start). It ends @ ( RAMF.altcks_end) : either &struct FID, or some random shit (i.e. Juke) if the FID struct is before IVT2. The calc loop skips 2 locations (the cks_alt1 vals) => this seems to be unnecessary since they are stored outside the cks_alt1 area ?

ck_alt2
Seems to be present in ROMs that also have RIPEMD-160. Limited information due to "recentness"


 * Area : &ECUREC to ROM_END; ECUREC is something also not found in older ROMs
 * Skips 4 locations :
 * alt2 values (sumt and xort)
 * ?? (defined in longer struc RAMF) (8200 == RAMF.ECUREC - 4)
 * ?? (&IVT2 - 4) ?

RIPEMD-160
TODO; see 1KA6A ROM. This algo is very similar to SHA1; it uses the same magic "initial numbers" as SHA1. Both should generate a 20-byte hash ? To locate the RIPEMD code in a ROM, searching for those magic numbers (such as 0x67452301) is a good method.


 * RIPEMD160 pseudocode
 * SHA1 pseudocode.