Savedata Encryption/Decryption

[Hykem]

Hi Hykem, welcome back and thanks for trying to make JPCSP and PSP saves portable. I tried porting my JPCSP saves of Persona 1, Persona 2, and Resistance Retribution to my PSP and they're still detected as corrupted. I also made a fresh save of a new game of Persona 2 on my PSP, port it over to JPCSP, made a save in JPCSP, then port it back to PSP, and it's still detected as corrupted with error code 80110306.

Ah! Thanks for checking this out, Itaru!
If you check the new PARAM.SFO file with an hex analyzer you should be able to see a section where the SAVEDATA file name (often called DATA.BIN) is stored. 0xD bytes after the file name this section must have the secret SAVEDATA key written on.
However, after comparing several save files, I've found that this key seems to go through one round of encryption before being written there. The current implementation is still missing this and the PSP is probably attempting to the decrypt the already decrypted key.

Btw Tekken 6 gives me Error 0x80110326 when it tries to load its savegame (on JPCSP).

Hmm...
Thanks for the report! I'll check this one too.

[AthenaADP]

I've been playing around with the updated (r2382) hash generation some more. Seems like hleSdGetLastIndex() is still returning incorrect values. I compared its output to known, actual-PSP-generated hashes and they were different. :/

hleSdRemoveValue() seems OK.

[Itaru]

In Persona 2, the encrypted save file (named P2PTUMI.SAV) that is generated by JPCSP is always 8 bytes larger than the one generated by a real PSP. The game's system data save generated by a real PSP is 1048 bytes, but the one generated by JPCSP is 1056 bytes. For the savegame, the one generated by a real PSP is 21528 bytes, whereas the JPCSP one is 21536 bytes. So, I think the crypto engine is still not generating the encrypted saves properly.

[Hykem]

In Persona 2, the encrypted save file (named P2PTUMI.SAV) that is generated by JPCSP is always 8 bytes larger than the one generated by a real PSP. The game's system data save generated by a real PSP is 1048 bytes, but the one generated by JPCSP is 1056 bytes. For the savegame, the one generated by a real PSP is 21528 bytes, whereas the JPCSP one is 21536 bytes. So, I think the crypto engine is still not generating the encrypted saves properly.

Hmm... Yes, indeed. Thanks for pointing this out.
Seems like not only there's a padding issue, but the PARAM.SFO is still not matching the hashes properly.
I'll have to investigate deeper into this, as the BBMac algorithm is pretty much fully reversed there should be a tiny error somewhere.

[serio]

i wonder if this might be why valkyria chronicles 2 creates corrupted savefiles when in crypto mode. as soon as it tries to read the savefile (using READSECURE) that was created using WRITESECURE and MAKEDATASECURE save modes it gives a message that it's corrupted and deletes almost all of it. it doesn't delete param.sfo and gets stuck in constant attempts to delete it.

while it creates data0-data4 with data, the param.sfo file is created blank (0 kb) in crypto mode and the emulator denies access to it, while in normal mode it has data. in non-crypto mode you can also remove the whole savedata folder after it's created, but in crypto param.sfo is under constant access denied status.

[serio]

btw. i tried to load valkyria's savefile that i created on a psp into the emulator, but it fails no matter if it's in crypto mode or not. is it because of all those secure modes, or is something still missing/unimplemented to load the save normally?

save in question attached.

the emulator also doesn't create the icons for whatever reason when you create a save with it, no matter if crypto's on or not.

[Hykem]

btw. i tried to load valkyria's savefile that i created on a psp into the emulator, but it fails no matter if it's in crypto mode or not. is it because of all those secure modes, or is something still missing/unimplemented to load the save normally?

save in question attached.

the emulator also doesn't create the icons for whatever reason when you create a save with it, no matter if crypto's on or not.

Ahhh. Thanks a lot for reporting this!
It seems like there is something missing in regular save/load to get this game working properly, so I've started investigating this aswell.
But more importantly, it seems that the PARAM.SFO can support the encryption of multiple files. This is something not commonly observed in older games (since most of them limit themselves to create one main .BIN file), but in newer games the ability to split the SAVEDATA into several files allows them to have different keys for each one.
With the SAVEDATA you just posted I should now be able to implement this feature and also crack the encryption behind the game key that is stored in the PARAM.SFO.

[popsdeco]

Hi there:
As Savedata En/Decrypter on PSP isn't so handy, I tried to create PC version.
But it seems PARAM.SFO's hash isn't proper (as of r2038). New saves can be read on Jpcsp but not on PSP.
I hope your investigation will be completed...

BTW the source code to "Savedata En/Decrypter on PSP" isn't available, so I don't know how PARAM.SFO hashing is done...

Savedata Decrypter on PC: http://pastebin.com/RFDXKCAf
I think ScrambleSD()'s buf handling is buggy (due to improper ByteBuffer porting). Encryption result is different from Jpcsp(but re-decryption still works)...

PS. It seems ScrambleSD against libkirk ( C ) requires if(kirk==4||kirk==5)memmove(buf,buf+0x14,size);

[Hykem]

Hi there:
As Savedata En/Decrypter on PSP isn't so handy, I tried to create PC version.
But it seems PARAM.SFO's hash isn't proper (as of r2038). New saves can be read on Jpcsp but not on PSP.
I hope your investigation will be completed...

BTW the source code to "Savedata En/Decrypter on PSP" isn't available, so I don't know how PARAM.SFO hashing is done...

Savedata Decrypter on PC: http://pastebin.com/RFDXKCAf
I think ScrambleSD()'s buf handling is buggy (due to improper ByteBuffer porting). Encryption result is different from Jpcsp(but re-decryption still works)...

PS. It seems ScrambleSD against libkirk ( C ) requires if(kirk==4||kirk==5)memmove(buf,buf+0x14,size);

Hi!
Thanks a lot for this! Porting this routine to C will sure make testing it much easier.
I had a small sample application for this purpose, but I stopped working on it when the development of the algorithm began growing up intensively, so I really appreciate this contribution.
Indeed, the only current issue resides in the hashes located in the PARAM.SFO. I'm currently analyzing several games and matching their data to track down which function is giving the wrong result.
With your application this process should be much faster now.

[AthenaADP]

...to track down which function is giving the wrong result.

Pretty sure only hleSdGetLastIndex() has errors. It's only used in the PARAMS.SFO hash generation, not the en/decryption.