Savedata Encryption/Decryption

[Hykem]

...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.

Yes, I suspect so too, but unfortunately this function relies on the amctrl.prx sceDrmBBMacXXX functions. I believe the algorithm behind those functions may have a flaw somewhere, since the hashes being produced are different than expected (both in SAVEDATA and NPDRM cases).

[serio]

i found another type of save that jpcsp doesn't support. it was created on a psp, and transfering it normally to jpcsp will always fail.

no matter what crypto option is selected, it'll crash the game when it tries to load it. i couldn't get it to work until i tried to decrypt it with savegame deemer plugin, and the decrypted data was like 9 times bigger. jpcsp loaded that without any hiccups and recognized it perfectly.

so, it looks like savefiles can be compressed as well as encrypted. attaching the save, with both original encrypted version and a decrypted one.

when a new savefile was made with jpcsp, it also missed extracting the pmf animated icon file.

[popsdeco]

Hi there...

Can CryptoEngine encrypt saves properly now?
i.e. Is jpcsp save readable by PSP?

Now that official "PSP Savedata En/Decrypter" distro is gone, we really need things done in usermode...

seems not maybe...
Let's post issue in jpcsp googlecode (after testing?)

[Zekro]

no it still wont work transfering a jpcsp save to psp

[serio]

i guess you have to wait for hykem to return with an update, he deals with all the encryption stuff as far as i know.

he's been away for almost 2 months now.

[popsdeco]

okay, seems so...

[serio]

found another savefile that doesn't load in jpcsp. r2589.

this one sort of loads, but always gives corrupted data, different types in crypto mode and without it. trying to load anything from it crashes jpcsp.

in this case even savegame deemer failed me, it didn't get any decrypted data out of it. the save still works fine on the psp though, so it's not corrupted.

[popsdeco]

Hi,

Could you try https://www.dropbox.com/s/mj92ccgvwoit74...ve_362a.7z ?

aww... maybe you can type "make -f Makefile_en" in MagicSave_362a/src/.

[Hykem]

As of r3404, SAVEDATA encryption/decryption has been drastically improved.
The encryption process is now working properly by successfully re-encrypting save games from external sources (gamefaqs.com) and decrypting them back again.
Certain games (mostly from FW 2.00 to 3.00) still have issues with the crypto methods, mainly because they use a different encryption scheme.
It's also possible now that savedata generated in JPCSP may be portable to PSP, since the PARAM.SFO hash generation has also been improved.
As always, any help further testing this is greatly appreciated. Thanks!

[popsdeco]

Hi hykem;

Sorry to have made you come here, but I'm glad that there are some opportunities to complete stuff.
So, I checked current SAVEDATA.java and I'm sure https://github.com/cielavenir/psp-saveda...ecrypter.c 's encryption is OK, but the hash isn't proper.
# Cleaning up the code will come later.

if inbuf is decrypted save file,
EncryptSavedata(inbuf, size, key);
fwrite(inbuf,1,size+0x10,stdout);
UpdateSavedataHashes(param,inbuf,size+0x10);
is OK?

You say "You need to add PSF file parsing", but I'm already able to search for SAVEFILE_PARAMS.
Since this is mostly for searching savedata exploit, passing param to UpdateSavedataHashes() is mandatory here. So I suppose this is enough, but... calculated hash for already-encrypted-bin isn't the same as the one in PARAM.SFO...