If you are just using a debugger why not getting the crc routine start where you would find at least the startaddress of the buffer/buffersize being used.
I'm not quite sure how to do that. My main method for finding things involves searching for known values in memory and then setting a hardware breakpoint when that location is written to, or just watching it and its surrounding memory change live as I play. I can follow the result back a short way, but I'm not sure how to follow it from the beginning of the calculation.
It should be easy to test which portions of the save are checksummed by making changes and seeing if it still loads.
I am able to see what it thinks the checksum should be if I attempt to load a save that doesn't match it. Are you familiar with any methods that could narrow down the checksum by changing values in the file and seeing the new result? The reverse can also be done, modifying the save in memory before the checksum is written and the checksum is created based on the modified data.
Might be CRC32. Find bufferstart/size (see above), save it as a file and for a quick test use...
HxD is a hex editor. I'm able to open the save file with it, select various parts of the file, and calculate checksums on it. I'm not able to get anything resembling that checksum from it no matter what I select.
As a rule savegames are compressed so "decrypted" means uncompressed?
Anyway - I'm not sure when crc is calculated - before or after compression/encryption?
These save games are not compressed. They are basically small memory dumps of the game's checkpoint data.
The encryption comes from the PS3 user-signing, locking it to your account. That has been removed. The checksum is calculated before encryption, written to the file, and then the whole file including the checksum is encrypted. For my purposes, we can assume the encryption is not a factor.
CAFEBAD100000000 seems to be some sort of comparison value. It is present at the start of every save game, unchanged. I'm at work for the day, but the last thing I was trying to figure out last night was why the instruction "clrldi (checksum register), (CAFEBAD100000000), 32)" was being run. Thought I'd throw that out there in case it means anything to you.