Sorry if this has been posted before but I couldnt find any references to it.
There's a function in Ape Escape to change the name you use for the save file name. After a quick look through the SFO I found that the name was stored in the save data file ("sarusave.dat"). So when we use this function the whole save is re-written.
I backed up my save (currently using default name of "File1"), booted up ape escape and changed the name to "File2". I backed this up, booted AE again and changed the name back to "File1". A simple comparison of the param.sfo files of the saves with identical names ("File1") points us to a difference of 16-bytes at address 0x057D.
Possible Key? I don't have much knowledge of AES so I don't know how to go about decrypting the dat file.
Heres a screenshot of the comparison (new file on top, old file below):
skyfox01_99,
Each letter of your save name represents a spot on the hex grid. So, you could go about finding out how the letter A is represented, then B, to Z and so on. Each time doing a diff to see the representation in the file. Anyways, just wanted to give you that tip so you could further those skills you got. Nice work so far.
> Possible Key? I don't have much knowledge of AES so I don't know how to go about decrypting the dat file.
There are two interesting binary fields in the saves.
As part of the SAVEDATA_FILE_LIST data it includes the filename for the .DAT file, as well as a 16byte value. I agree it looks a lot like an AES key for the separate .DAT file
Also the SAVEDATA_PARAMS data includes 32 bytes that look like a couple of keys or hashes.
(gorim's psfparse doesn't dump that data, but you can figure it out from the file offsets)
NOTE: if you change any byte in the PARAM.SFO file, it will no longer work. My guess is part of the SAVEDATA_PARAMS includes some sort of signing hash to detect that case (one of the two 16 byte values?)
NOTE2: there is no SAVEDATA_PARAMS field in the EBOOT.PBP flash update file - and you *can* tweek the structure of those files (as people have done to change the .PNG or string name)
AES nice aye, but the .sfo do have plain text. It's very possible that a hash is locking those plain text fields from change too, just have not tried it yet. Guess I'll add it to the long list of thing to look at.. Boy is that list getting long...
> but the .sfo do have plain text. It's very possible that a hash is locking those plain text fields from change too, just have not tried it yet.
They are locked. Try changing any of the strings (even something as simple as "A" -> "a" in one string) and it will report it as corrupted data
I've also tried deleting and moving around the sections - but the validation also flags thes as corrupt (theoretical hash, my guess it is in "SAVEDATA_PARAMS")
Smart thing for them to do.
As mentioned you can play around with strings in the EBOOT.PBP files. I wonder if they will be adding more security once MS downloadable games come out.
PspPet wrote:They are locked. Try changing any of the strings (even something as simple as "A" -> "a" in one string) and it will report it as corrupted data
I've also tried deleting and moving around the sections - but the validation also flags thes as corrupt (theoretical hash, my guess it is in "SAVEDATA_PARAMS")
