Help/Advice Needed - PS2 - finding and deciphering save hashing routines

[Uncia Amethice]

Hi,

I've been trying for a while to figure out the hashing routines used in the PS2 game Fire Pro Wrestling Returns for its save files.

The main reason for this is that there is a fair sized community that use the game's considerable Edit mode to create their own characters, ring logos and the like, and being able to support them with an editor that can compile characters or do things like quickly create logos from image files rather than using the PS2 controller to enter them pixel by pixel would help them considerably.

The game doesn't have any kind of online netplay or similar, just FYI - this isn't something that's intended for cheating.

-----------------------

Now, I've already managed to decipher much of the game's save data, some of it with others and much on my own. The part relevant for this is that the save data consists of 888kb of actual save data (I won't go into too much detail of how this is structured unless needed for the hack, it seems like it'd only distract from the discussion), including some null padding at the end to make it an even kb. After this is 4580 bytes of what appears to be a hash or checksum, used to determine if the save data is legit or if it has been corrupted somehow.

I'll probably mess up a lot of the terminology, so if I'm being unclear, please don't hesitate to correct me and/or ask for more data. =)

The checksum/hash itself isn't one 4580 byte value, rather it is three blocks of hashes going through the save data two-dimensionally as follows:

Block 1
The first 3552 bytes are 888 32-bit hashes, each of which seems to correspond to a 1024 byte block of save data. I've figured this out by using the edit system to change specific values in the save data and compare the two, noting where a single byte of sava data changes as well as the changes in the hashes.
Interestingly, I went in with a hex editor and changed some of these hashes in a save file, and the savegame still loaded without being considered corrupted, possibly because block 2 and 3 (or at least 3, which seems to be the "final key") still checked out as being okay - but it still saves these blocks.

Block 2
The next 1024 bytes appears, from experimentation, to be a vertical hash of each the save data blocks - so that changing the 213th byte of any save data block will, apart from changing the Block 1 hash of that save data chunk also change the 213th byte of the block 2 hash. As such, I suspect that it is in fact 1024 8-bit hashes.

Block 3
The final 4 bytes are, and this is pretty much a guess though an informed one, a 32 bit hash using the same system as the Block 1 hashes, using Block 2 as its raw data.

---------------------------------------

Guessing the method used to calculate these hashes would probably be more or less futile. It gives some unconventional results (such as a block 1 "chunk" consisting if all zeroes will generate the hash BB 6B 82 F3) and the data samples I have managed to pick up don't follow any simple patterns discernable by myself or anyone I've worked with.
As such, it'll probably be far less work to use a disassembler and debugger to find the algorhithms or at least follow them as they happen. However, though I have played around with ps2dis and the pcsx2 debugger, I find that my skill in that field is sorely lacking.

From what I can figure, I need to figure out break points to set so that I can watch the loop of what happens when the save data is being saved or loaded, so that I could hopefully spot the calculations as it rebuilds the hashes for comparison's sake.

Might anyone be able to point to information or tools which would help this process? I've got some programming experience in multiple languages as well as hex editing and more basic savegame and game hacking or, so I'm not a complete beginner, but the complexity of this problem is a few steps beyond me to tackle alone.

[root670]

Have you tried searching for the save contents in RAM while the game's running in PCSX2? Many games keep the save data in memory during the game so it's easy to access when it needs to be written to the card. If you're lucky, the hash area will be here too. And if that's the case, try setting a write breakpoint to the first hash and see what happens when the game begins saving.

[Uncia Amethice]

Have you tried searching for the save contents in RAM while the game's running in PCSX2? Many games keep the save data in memory during the game so it's easy to access when it needs to be written to the card. If you're lucky, the hash area will be here too. And if that's the case, try setting a write breakpoint to the first hash and see what happens when the game begins saving.

I double checked to make sure, and unfortunately we don't seem to be that lucky - I did memdumps both after load and after save, and couldn't locate any blocks of save data (I tried a few chunks of save data between 32 and 128 bits in length) nor the checksums inside the memdump.

[Cronotrigga]

What you should be doing is forgetting about the actual structure. Everything you want to achieve can be done in a simple function cut in just about almost every case I have run across. First start by finding the memory card functions. If you are not familiar with mapping these types of functions out please refer to code master projects for a great tutorial. The memory card functions that are actually useful are open,read,write and sync. Using the memory card open function you should be able to map it back to a function that has a string hat represents the format of the file that is being saved to the card. Look around for a function that is taking data and compressing it. Remove this completely. Now you should also look for where write is and disable that as well. Now go into the game and save. Your save file should be in raw data and can now be read in raw data.

[Uncia Amethice]

Sorry about the thread necromancy - I didn't see the late reply until I came back on a whim today, but the advice is very useful.
Finding/mapping the memory card functions sounds like exactly what I need, but sadly I haven't been able to find the tutorial you're talking about at CMP (or elsewhere, for that matter - I'm probably searching using the wrong terminology) - any chance someone might be able to point me in the right direction to where I could learn this stuff?