I recently overwrote the save game file of a video game that my girlfriend and I had been playing through. After trying to recover the file a few different ways (game didn't erase but overwrote the save file), I'm resigned to trying to rebuild the save data manually.
I've played with reverse engineering binary executables from crackmes.de in the past with Ollydbg, but this is different and I feel like I'm a bit out of my waters.
The game (Sonic All Stars Racing) uses a single .bin file to store records for four in-game accounts. Using a hex editor, pen and paper, I've begun to plot out the file structure and locate offsets for various records.
The problem I have is that whenever I make a modification to the file, same size or otherwise, the game declares the save file corrupted and fails to use it. I assume that this is because the game is implementing some form of CRC/checksum on the data to prevent using a corrupted file. (Aside: are CRC and checksum interchangeable terms?)
The game saves the data to a file named
"ssr_save.bin" which is responsible for four in-game profiles.
What I did was create four different save files by making a backup of the save file after creating each profile.
Each file is largely the same. 727040 bytes large. The only difference seems to be the first 12 bytes (0x00 to 0x0B inclusive). These first twelve bytes are completely unique between the four files.
There does, however, appear to be more than one data object in that range as there are 3 bytes of zero in the centre of the 12.
File 1: 19 8E 0B 60 13 00 00 00 F9 3E 00 B0 File 2: 93 7B 0F 36 13 00 00 00 B6 35 02 9B File 3: 69 71 1B 14 13 00 00 00 A1 30 08 8A File 4: D9 47 32 E8 13 00 00 00 D9 9B 13 74
What I'm trying to figure out is what these bytes represent and how I can manipulate them to let me modify the body of the save data and not throw the corruption error in the game.
Can anyone help me find out how the game is checksumming the file and reverse engineer the process so I can create a valid file?