I have an interesting conundrum involving a mishap I made with some save files. It may be related to #21 and your code to ignore padding.
This week, I attempted to upgrade the USB storage of my PSTV, but the USB drive I purchased caused data corruption. I switched back to the old drive, but in the process many games were corrupted. I had difficulty backing up save data for the title PSCH10001 with Vita Save Manager (it would choke on the input for some reason), so I copied the files out using VitaShell.
I thought I copied the decrypted files (using VitaShell's 'Open decrypted' function), but further investigation revealed otherwise. In fact, when Vita Save Manager failed to back up my data previously, it managed to decrypt a certain number of saves before giving up (and also not copying the crucial sce_sys folder). I even managed to not copy the sealedkey file or db/icv files alongside the encrypted saves I accidentally copied, meaning I lack the required information to decrypt the files in question.
With some work, the game will recognize the encrypted save files once they're in place, but state they're corrupted (because the data is scrambled by the encryption process). I thought I could use the clean sealedkey and other PFS information to decrypt the saves using VitaShell, but VitaShell threw errors every time. Thus, I came to psvpfstools.
After satisfying the dependencies of psvpfstools 2.0 release version (namely, it requires libcurl3 and won't use libcurl4) on Ubuntu, the tool throws up an error about the sealedkey file:
fiona@lauren:~/Desktop/testdisk-7.1-WIP/release_ubuntu64$ ./psvpfsparser -i ./SLOT1/ -o ./SLOT1_dec/ -f http://cma.henkaku.xyz
Missing option --klicensee or --zRIF
sealedkey will be used
using sealedkey...
sealedkey does not exist
This is expected, as the only files in sce_sys are param.sfo and sdslot.dat. Using a sealedkey from the current save file changes the output as follows:
./psvpfsparser -i ./SLOT1/ -o ./SLOT1_dec/ -f http://cma.henkaku.xyz
Missing option --klicensee or --zRIF
sealedkey will be used
using sealedkey...
sealedkey: matched retail hmac
failed to find unicv.db file or icv.db folder
I copy the sce_pfs folder from the existing save into the encrypted backup, causing [WARNING] output that the file sizes are invalid and the file types are invalid and assumed to be encrypted, eventually leading to:
Flattening file pages...
Building dir paths...
Building file paths...
Linking dir paths...
Linking file paths...
File ./SLOT1/SCE_SYS/SAFEMEM.DAT does not exist
Copying in the rest of the sce_sys files that were missing from the backup eventually leads to this and the program halting:
Unexpected padding
Which is the error referenced in #21 you said you would add code to ignore.
Unfortunately, compiling either the master or io-api branches couldn't be done. After installing libcurl4 to satisfy updated dependencies, and then correcting a file name's capitalisation (on Linux, files are case sensitive, thus LIBTOMCRYPT and LibTomCrypt are two different names), various errors were tossed that I can't identify. A current build for either (even a Windows build; I can't try myself as I have no Windows build environment) would let me test if I could decrypt the files with the current codebase.
The reason I said it was interesting is because I have encrypted files seemingly without the necessary information to decrypt, but I also have decrypted copies of some of these saves. I have a zip file containing the decrypted saves (which are only part of the saves, missing the critical system save), the encrypted saves, and the sce_sys and sce_pfs folders from the game's current save folder. Since the Vita's cryptography is entirely wide open now, I wonder if you can use the decrypted files, compare them with the encrypted ones, and reconstruct what is necessary to decrypt the remaining encrypted files?
I do not understand cryptography myself, I'm afraid, so this is only conjecture. The zip file is also too large to attach to this post. If you wish to have this zip file yourself, I can upload it elsewhere if you wish. If not, simply helping to provide a current build of the master or io-api branches would suffice, or solving the halt on the 'Unexpected padding' error.
Thank you in advance for any help! If you cannot assist, I apologise in advance as well.
I have an interesting conundrum involving a mishap I made with some save files. It may be related to #21 and your code to ignore padding.
This week, I attempted to upgrade the USB storage of my PSTV, but the USB drive I purchased caused data corruption. I switched back to the old drive, but in the process many games were corrupted. I had difficulty backing up save data for the title PSCH10001 with Vita Save Manager (it would choke on the input for some reason), so I copied the files out using VitaShell.
I thought I copied the decrypted files (using VitaShell's 'Open decrypted' function), but further investigation revealed otherwise. In fact, when Vita Save Manager failed to back up my data previously, it managed to decrypt a certain number of saves before giving up (and also not copying the crucial sce_sys folder). I even managed to not copy the sealedkey file or db/icv files alongside the encrypted saves I accidentally copied, meaning I lack the required information to decrypt the files in question.
With some work, the game will recognize the encrypted save files once they're in place, but state they're corrupted (because the data is scrambled by the encryption process). I thought I could use the clean sealedkey and other PFS information to decrypt the saves using VitaShell, but VitaShell threw errors every time. Thus, I came to psvpfstools.
After satisfying the dependencies of psvpfstools 2.0 release version (namely, it requires libcurl3 and won't use libcurl4) on Ubuntu, the tool throws up an error about the sealedkey file:
This is expected, as the only files in sce_sys are param.sfo and sdslot.dat. Using a sealedkey from the current save file changes the output as follows:
I copy the sce_pfs folder from the existing save into the encrypted backup, causing [WARNING] output that the file sizes are invalid and the file types are invalid and assumed to be encrypted, eventually leading to:
Copying in the rest of the sce_sys files that were missing from the backup eventually leads to this and the program halting:
Which is the error referenced in #21 you said you would add code to ignore.
Unfortunately, compiling either the master or io-api branches couldn't be done. After installing libcurl4 to satisfy updated dependencies, and then correcting a file name's capitalisation (on Linux, files are case sensitive, thus LIBTOMCRYPT and LibTomCrypt are two different names), various errors were tossed that I can't identify. A current build for either (even a Windows build; I can't try myself as I have no Windows build environment) would let me test if I could decrypt the files with the current codebase.
The reason I said it was interesting is because I have encrypted files seemingly without the necessary information to decrypt, but I also have decrypted copies of some of these saves. I have a zip file containing the decrypted saves (which are only part of the saves, missing the critical system save), the encrypted saves, and the sce_sys and sce_pfs folders from the game's current save folder. Since the Vita's cryptography is entirely wide open now, I wonder if you can use the decrypted files, compare them with the encrypted ones, and reconstruct what is necessary to decrypt the remaining encrypted files?
I do not understand cryptography myself, I'm afraid, so this is only conjecture. The zip file is also too large to attach to this post. If you wish to have this zip file yourself, I can upload it elsewhere if you wish. If not, simply helping to provide a current build of the master or io-api branches would suffice, or solving the halt on the 'Unexpected padding' error.
Thank you in advance for any help! If you cannot assist, I apologise in advance as well.