Save data checksums

From Boktai Hacking Wiki
Revision as of 14:32, 3 August 2024 by Raphi (talk | contribs) (Created page with "The save files of Boktai games contain checksums that are verified when the save is loaded. After modifying save files with a hex editor or another tool, these checksums must be updated so the save will load correctly again. The save file is divided into blocks. Each block size is a multiple of 8 bytes. After the last 8-byte chunk in a block, there is another 8-byte chunk containing the checksum. The checksum are these 4 halfwords: #. Constant 0xffff #. Byte size of th...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The save files of Boktai games contain checksums that are verified when the save is loaded. After modifying save files with a hex editor or another tool, these checksums must be updated so the save will load correctly again.

The save file is divided into blocks. Each block size is a multiple of 8 bytes. After the last 8-byte chunk in a block, there is another 8-byte chunk containing the checksum. The checksum are these 4 halfwords:

  1. . Constant 0xffff
  2. . Byte size of this block, excluding this checksum
  3. . Sum of halfwords in this block, excluding this checksum
  4. . XOR-sum of halfwords in this block, excluding this checksum

Hex dump of the first block in Boktai 1 saves, with the checksum in bold:

00000000: 0000 00e4 0003 cc18 0000 0101 0000 0000
00000010: 0000 0000 0000 0000 ffff 0018 ce00 cdfe

Byte order

Some emulators store EEPROM save data in a different byte order compared to hardware (like GBI). The example calculation above uses "emulator byte order". In "hardware byte order", the bytes in each 8-byte doubleword are reversed (so 0011 2233 4455 6677 becomes 7766 5544 3322 1100). Notably, this means that numbers in emulator byte order are big-endian, while numbers in hardware byte order are little-endian.