PS3HEN Messed up save file, trying to restore to a good state

[Sahbi]

Sooooo I accidentally removed a PARAM.PFD from one of my save games (Drakengard 3) through FTP. Immediately afterwards I copied whatever remained to a different location (not on the PS3) so I could work on restoring the save data to a working state. The PFD should only contain file signatures/hashes so I figured it would be pretty straightforward to fix: copy a PARAM.PFD from a different Drakengard save and run pfdtool -g NPUB31251 -u SAVEDIR_PATH.

When importing this newly edited save to the PS3 from USB (to prevent the need for a full database rebuild, which takes much longer) it accepts it as good, but when I load up the game all game files are blank. I don't get a warning about the data being corrupt though. I deleted all saves off the PS3 and recreated a blank one for comparison, then went on to download a save off the net as well.

For some reason, the original save decrypts to something entirely different than the blank and downloaded ones. I'm assuming the game simply discards this unknown data and handles it as if it were a blank save. I've compared the first few bytes of every file against known file headers/signatures and it doesn't seem to be a compression of some kind. Some online tools reported some of them as being PGP-encrypted but I don't think that's actually the case, although it does look like another layer of packing/encryption. Just to be sure I also verified that all tested save files use the same encryption key (secure_file_id).

I've attached the PAYLOAD files (both encrypted and decrypted) for the original save as well as the one I've downloaded off the net. I only worked with copies of the backed up save data so the attached encrypted PAYLOAD should be exactly the way it was when it was still stored on the PS3's internal HDD.

My PS3 firmware is 4.87 CEX PS3HEN 3.02. Hopefully someone can tell me how to get my save data back. :>

 

[Berion]

You do not need decrypting save if You don't want modify it (and You even cannot, because game will not understand decrypted save; also You cannot encrypt it after PFD rebuilding because PFD will have not it's checksum). Only thing which You must do is rebuild PFD with old save, maybe old SFO and new PFD (so Your idea is fully correct).

Could You paste here syntax of pfdtool? I don't have this app on hand, and also don't remember what all switches doing.

 

[Sahbi]

You do not need decrypting save if You don't want modify it

Yeah I know, I was just comparing both encrypted and decrypted forms of the saves. Initially I just ran the exact command from my first paragraph, which only rebuilds the PFD and doesn't do anything else. It was only after that that particular save came up empty that I started comparing them on the binary level. And then it turned out that the data I'm attempting to rescue is completely different somehow.

A quick overview of the pfdtool syntax can be found here.

 

[sandungas]

Try in this order:

1) Decrypt your save (the one with the missing PARAM.PFD)
2) Decrypt the placeholder save (made by you in your console)
3) move the files from your save to the placeholder
4) update the PFD
5) overwrite all the new files in your PS3 (on top of the placeholder save)
6) boot the game

 

[Sahbi]

1) pfdtool refuses to decrypt without a PARAM.PFD, so I copied it from the blank save to the original one's directory first.
5) You didn't mention to re-encrypt so I'm assuming you meant it that way.

Unfortunately after booting the game it still shows all saved games ("Recordings" as they call it) as empty. Even if I do re-encrypt the save data before step 5 the same thing happens.

 

[sandungas]

I wrote that from memory, but take a read at this post i wrote, i was doing something similar than you
https://www.psx-place.com/threads/apollo-save-tool-development-thread.27964/page-17#post-261250

The point is that you need to decrypt them because the PFD is "tied" with the other encrypted data, when you decrypt the other files the PFD is going to be "updated" (and untied), and is ready to acept new files
After that is when you can swap files in between the 2 saves
And at the end is needed to encrypt them, yeah i forgot to mention that part

 

[Sahbi]

I see, so there does seem to be an additional layer of encryption involved. However, I don't have the original PFD so your description from the other thread doesn't quite apply I think? Is there any way to verify if this particular game does use per-save encryption keys stored within the PFD, before we waste time on that angle? :>

I know keeping backups is advised, I actually was trying to make a copy of this save before I borked it. ;_;

 

[Berion]

No decryption is needed. He needs to recreate new PFD. Save decryption is only if You want modifying it. PFD doesn't contain informations about how save is encrypted. It is used only for content validation, not security (and even not always, some games aren't "protected" by PARAM.PFD).

Process is the same as for resigning save because in both cases, PFD is forging a new. So BTW: maybe just try import and resign save with PFD from different save (for the same game of course) and old save + it's SFO. You can do this easily by Apollo.

I believe we have deal here with some security layer made by game (if we assuming that messing with PFD goes proper).

All saves are encrypting at least once, all in the same way because it is part of save data handling on PS3. 2nd layer can be custom, made and verifying by game itself.

Correct me if I'm wrong but I don't see anything in PARAM.PFD which could proofs different.
https://www.psdevwiki.com/ps3/PARAM.PFD#Cryptography_and_Speculation

@bucanero? ^^"

 

[Sahbi]

No decryption is needed. He needs to recreate new PFD. Save decryption is only if You want modifying it. PFD doesn't contain informations about how save is encrypted. It is used only for content validation, not security (and even not always, some games aren't "protected" by PARAM.PFD).

Process is the same as for resigning save because in both cases, PFD is forging a new. So BTW: maybe just try import and resign save with PFD from different save (for the same game of course) and old save + it's SFO. You can do this easily by Apollo.

I believe we have deal here with some security layer made by game (if we assuming that messing with PFD goes proper).

All saves are encrypting at least once, all in the same way because it is part of save data handling on PS3. 2nd layer can be custom, made and verifying by game itself.

Either I'm misunderstanding something here or my explanation of the issue wasn't as clear as I thought. I copied the PFD from a brand new save into the directory of my borked one, followed by rebuilding the PFD. This doesn't restore my save data as the game simply shows all-empty save games, while the first slot should contain my play data.

The problem is that after decryption, the PAYLOAD files (which contain the actual save data) are vastly different on the binary level. For both the new and downloaded saves the 4 bytes are 00 00 00 06 (followed by a bunch of FF), while for my original one it's BA 4E D9 50. I have a strong feeling the game simply discards this unknown/invalid data and treats it as a blank save. Sandungas mentioned a key embedded in the PFD, which does seem plausible. But you say there is none?

I dunno if either of you have (yet) looked at the files I attached to my original post, but the problem will probably become much clearer if you do.

 

[Berion]

Yes, I fully understood You. At least in theory You did everything properly, and game doesn't see a save. That's why I'm asked for pfdtool syntax to verify if You have used properly switch.

There is none or I'm blind. Look at PFD specification: https://www.psdevwiki.com/ps3/PARAM.PFD#Mechanism_Diagrams Or maybe I misunderstood it and not entries are enrypted in PFD but files itself? But then You could also used PFD as template from another save because SFID and SCMK doesn't change, and also save decryption is pointless.

 

[Sahbi]

Actually I did post a link to the pfdtool syntax (it's under the word "here"). :> I can't post it directly it seems, I'm getting an error about inappropriate content if I try.

A quick overview of the pfdtool syntax can be found here.

Also, I just checked by using my blank save as base, then copied the PARAM.PFD from the downloaded save into it. After decryption the contents are not the same as they were with the original PFD, meaning there does seem to be a key embedded within that file.

EDIT: I just checked out the psdevwiki link you mentioned and I do see a "for each individual file => file key" thing, which is used to derive the final decryption key. So perhaps certain games always use the same "file key" for every save, while others do not.

 

[Berion]

Sorry, I missed that. So based on syntax it looks like I was wrong and PFD is involved in files encryption/decryption. And what is worst, You did everything properly.

"PAYLOAD_original_decrypted" is not decrypted (decrypted by wrong key, so output is garbage) in compare to save from the net.

You could try Apollo resign. You could also in theory try file recovery software which supporting UFS2 on decrypted mapper from PS3 HDD on PC if You didn't yet overwrite it, there is still a chance to retrieve it.

 

[Sahbi]

No problem. =] I think we're looking at bruteforcing the key used for the PAYLOAD file? To me that seems at least somewhat feasible since I know what the end result should look like. Are there currently any tools available for that, that any of you know offhand? I don't think I've been the first with this particular problem so I'm thinking there might just be. :>

 

[Berion]

SFID is the same always for all specific title in specific region game edition, so there is nothing to bruteforcing here by available tools.

If SysCon Manager Key is per console key, then You are using for decryption PFD from another console which will not decrypt files from Yours. But if this would be true, then user cannot be used saves from different consoles on the same SEN account, which actually can... However, try PFD from the same console, for the the same game, but different save. And try decrypt it using it in such combination. For me it is not logical, but maybe again I'm wrong. ;p

 

[Sahbi]

Yeah I already am working with the exact same console everytime, i.e. the blank save I made is on the same console for the same game under the same PS3 user.

 

[bucanero]

No decryption is needed. He needs to recreate new PFD. Save decryption is only if You want modifying it. PFD doesn't contain informations about how save is encrypted. It is used only for content validation, not security (and even not always, some games aren't "protected" by PARAM.PFD).

@bucanero? ^^"

The PFD file actually contains the entry key to initialize the AES encryption for each protected file. See my code here:
https://github.com/bucanero/apollo-...7d0a68963276f9bede04cc/source/pfd_util.c#L307

I'm not sure if this initial key is reused or if it changes every time. It can be easily verified by creating a bunch of saves from the same game and comparing the value. If it's not the same, without the original file you won't be able to recover the data.

btw, the entry key is 64 byte long, so brute force will take a really long time
But only the first 16 bytes are used for AES encryption, so at least you can skip some

Edit: as suspected, those initialization bytes are random. From the psdev-wiki link from @sandungas :

The first 0x10 and the second 0x10 bytes are randomly generated (key/iv?).

 

[Sahbi]

But only the first 16 bytes are used for AES encryption, so at least you can skip some

Yeah I was looking at the code flatz's pfdtool uses and noticed aes_setkey_dec(&aes2, key, 128). Do you happen to know something about the algorithm used by the PS3 for generating the file entry key? Like, is it a naive rand() like function or is it using actually something cryptographically secure? Maybe it's even game-dependent? I wrote a few variants for bruteforcing some naive implementations, hoping something will turn up. :>

 

[bucanero]

Yeah I was looking at the code flatz's pfdtool uses and noticed aes_setkey_dec(&aes2, key, 128). Do you happen to know something about the algorithm used by the PS3 for generating the file entry key? Like, is it a naive rand() like function or is it using actually something cryptographically secure? Maybe it's even game-dependent? I wrote a few variants for bruteforcing some naive implementations, hoping something will turn up. :>

I don't know. Unless you reverse the firmware code and see how it works, it's a black-box and we can only assume it's a complete random 16-byte (128 bits) value.
So the only brute-force would be to actually try every value in that range.

honestly I'd suggest to get an "everything unlocked" save-game and use it... or start a new game, and use Apollo to patch the new savegame and apply a few cheats like having all the weapons, money, and materials for upgrades... and then do a speed run trough the game.

btw, I enjoyed playing Drakengard 3, specially all the history branches and the many endings.

 

[Sahbi]

btw, I enjoyed playing Drakengard 3, specially all the history branches and the many endings.

Yeah I did too, I was actually at the final boss of branch D and had to take a break from it. Decided to try and get the PS2 emulator working and wanted to back up my Drakengard save before I messed it up (ironic huh). I had already finished all DLC chapters too, so basically I've finished the game but I'm just a little annoyed by losing my own progress. :>

I'm currently running a bruteforce for some naive implementations, hoping for a stroke of good luck. ;_; At least that won't take like a billion years and it still has a chance (however slim) of finding the key.