PS4 Moving Saves from Working, Non-Booting HDD

[chipdouglas]

ps4 slim CUH-2015A 5.05 FW

SHORT ASK: i have a mechanically-functional drive. passes all surface scans, was able to get my EAP key and mounted it to linux, however it does not boot in PS4. i REALLY want to get my save states from this drive if possible. or find out why it's not booting and repair it, without losing user data (less likely, not possble that i'm aware of)

POTENTIAL WORKAROUNDS?

• EXPORT FORMAT: obviously there is a way to create an exportable and importable save state file. are there any scripts/bins that are available in any modding menus that export saves, that can then be imported to another. if so, there may be a way to run them against the linux mounted drive to create this format. my fear here is that these scripts may also modify/require the sqlLite DB in /system_data which currently requires the SUMA key, not the EAP key to access outside of the PS4. which then this would be unable to be done
• EXTERNAL DRIVE: when you guys are using an external drive with some of the mods (i haven't read much about it yet), could i possible use my old drive as an external drive and it could potentially access any of the data through the PS4 since it would then be able to be decrypted? (this is a question, not sure if this is how it works)
• SOME OTHER TOTALLY AWESOME THING I'M NOT AWARE OF?

LONG BORING BACKSTORY:

midgame, crash, happens, boots fine, apply hen, crashes. one more time just in case (clear all the browser stuff), crashes. leave machine on, all menus and things are up, keep it up for 30m just to see. kicking myself in hindsight that i could have taken a backup of the data at this very moment, however i went to backup to USB, and it barked about requiring an update for it to work. so i bailed

in fear of my hdd starting to go, start a clone to another drive. first tried active @, but was going so slow. tired aoimei, but was also very slow, same with easeUS

did a clone via DD, ripping fast, moving on

put old drive back in, now it goes to safe mode, no option but to re-initialize is highlighted. same with cloned drive

wondering if one of the cloning softwares did something to the original drive as it was working when i took it out of the machine

did a full surface scan of the drive, passes with flying colors. drive is functional something is corrupt

was able to get my sflash0, retrieve EAP key, and mount /user to my linux system with cryptmount. can navigate to all my user data, so i know the drive appears to be working, just corrupt in some manner

one odd thing that happened was while in 'easeUS' the drive was listed as 'offline', i had to flip it to 'online', that is the only known command that may have sent anything to the drive. every other time i was 1000000% certain that it was the source drive, not the destination

 

[Charles_n_town]

To export saves officially you need to be activated. Your username will be italicized if you are. It's the same on the PS5 as an indicator. Anyway, I think you can use Apollo or account activator. I remember account activator freezing if you deployed goldhen first due to a bug, so you'd want to use bin loader and deploy the debug.bin, then run account activator. Then, when finished, deploy goldhen. I don't know how it works on Apollo as I've never used it.

 

[chipdouglas]

thanks, but i cannot get into the ps4 with the busted hdd, so i cannot export my saves from a ps4

 

[Berion]

Make two kind of backups: saves backup on Linux and full disk image from source drive (I hope still untouched). After that, use update 5.05 or newer PUP for reinstallation fw (the larger one). After that, try Apollo to restore those saves (in theory he should be able to mount it as no keys has changed, due to it is the same console @bucanero [?]). If that will not work, then restore partition 27 from disk image, then use update fw type if OrbisOS will complain. If both methods will fail (I didn't test it, just an idea), probably not possible to retrieve Your saves.

PS: PS4 External Storage cannot be used for anything else than games, patches and dlc moving on. It is custom junk, encrypted and unknown for now. While exported saves can be exported/imported to/from FAT32/exFAT on MBR/GPT or none pt. Two different logic structures.

And no, You cannot use copied saves from internal drive on Linux to dir from which they are importing. Containers the same but keys different (static vs pck).

In this weekend, I will release update for PS4HDH which will include also Backuper script. Everything was tested and works, I just waiting for English correction made by @Colek .

wondering if one of the cloning software did something to the original drive as it was working when i took it out of the machine

On some spectrum of models, few partitions have HFS+ signature to fooling cloning apps (while in reality they are only HFS+ sig on first sector, after then the encrypted UFS2...). It is possible that this app will formatted those partitions as HFS+ (moving HFS+ to expand it, which kill everything beyond false signature), as Sony intended...

 

[chipdouglas]

Make two kind of backups: saves backup on Linux and full disk image from source drive (I hope still untouched). After that, use update 5.05 or newer PUP for reinstallation fw (the larger one). After that, try Apollo to restore those saves (in theory he should be able to mount it as no keys has changed, due to it is the same console @bucanero [?]). If that will not work, then restore partition 27 from disk image, then use update fw type if OrbisOS will complain. If both methods will fail (I didn't test it, just an idea), probably not possible to retrieve Your saves.

ok, just want to restate to ensure i understand

i have a new, different drive (hd2) in the ps4, have reinstalled the 5.05 and is up and running just fine

have left the original drive (hd1) untouched from when i pulled it out

1) mount the (hd1) drive in linux, copy out the save files to a USB. plug in USB, and see if apollo will import (love this idea!!)
2) if that doesnt work, try and clone over the entire /user partition. it is known that the /system_data does contain some save state DB as well, so that partition may need to be copied over as well. but i would start with the /user partition (also a good idea!)

PS: PS4 External Storage cannot be used for anything else than games, patches and dlc moving on. It is custom junk, encrypted and unknown for now. While exported saves can be exported/imported to/from FAT32/exFAT on MBR/GPT or none pt. Two different logic structures.

And no, You cannot use copied saves from internal drive on Linux to dir from which they are importing. Containers the same but keys different (static vs pck).

yeah, figured this would be a dead end

On some spectrum of models, few partitions have HFS+ signature to fooling cloning apps (while in reality they are only HFS+ sig on first sector, after then the encrypted UFS2...). It is possible that this app will formatted those partitions as HFS+ (moving HFS+ to expand it, which kill everything beyond false signature), as Sony intended...

lame, yeah i wonder if there was something that triggered to shut this down from working in the ps4

 

[Berion]

Ad1. & 2. Yes.

I don't have hacked PS4 and donated dump have only EAP HDD Key ("/system_data" is behind SAMU HDD Key wall). So I dunno. Worth a try anyway; you risking loosing only time.

3. Third thing which came to my mind is placing saves on internal HDD and use Apollo to export it decrypted. Apollo not need databases as it works on fs. So that way, even if save cannot be imported from USB, maybe can be exported from HDD as decrypted and then imported decrypted to newly created by game encrypted - like normally user should doing to backup/restoring saves.

 

[chipdouglas]

1) mount the (hd1) drive in linux, copy out the save files to a USB. plug in USB, and see if apollo will import (love this idea!!)

apollo moved it over, but it showed as corrupted sadly

2) if that doesnt work, try and clone over the entire /user partition. it is known that the /system_data does contain some save state DB as well, so that partition may need to be copied over as well. but i would start with the /user partition (also a good idea!)

tried this as well, however some where on startup it must be detecting that the new user ID directory differs than the one it setup during first boot, and completely wipes and recreates the /user and /system_data during boot

3. Third thing which came to my mind is placing saves on internal HDD and use Apollo to export it decrypted. Apollo not need databases as it works on fs. So that way, even if save cannot be imported from USB, maybe can be exported from HDD as decrypted and then imported decrypted to newly created by game encrypted - like normally user should doing to backup/restoring saves.

yeah, i had the same thought! apollo barfed on the files....grrr

i have the files, i just need something to let me put them back! damn you ps4, i'm like 40h into this game!!!

 

[Charles_n_town]

I'm not sure how the process works, but a newly formatted drive will be given a random user id, not to be confused with account id. it's all over the system in both hex and decimal format. I was able to use an old app.db by hex editing/replacing the table names, which are named after the decimal version of your user id. as for saves, the savedata.db contains your user id and account id. the account id is located in the param.sfo of a decrypted save at offset 0x15c in little endian. I think this is how saves are resigned after SAMU decrypts them. you'll get a save corruption error if the account id differs. since it sounds like you didn't activate your account, which allows for save exporting, I'm not sure how to correct this problem. logically, the account id is all 0's by default. maybe check your savedata.db (forgot the location, but somewhere in the user partition) to see what it says as your account id, then try account activating through apollo with that id, and ftp the saves over. I do not know if this will work, but saves themselves don't contain the user id. I know exporting them won't work, at least when we tested what would happen with an ftp'd save and save wizard, it didn't work. it only works with official exports.

edit: remember to index a save first by activating your account with the right account id, then saving in that game, then try replacing the save via ftp. if that doesn't work, you may be sol.

 

[bucanero]

if you managed Apollo to copy the save to HDD:
- before doing anything else, have you tried to open the copied HDD save with Apollo? if you can access it, select the option "Export decrypted" (as zip, or whatever format you prefer)

If Apollo can get you the decrypted exported data files, then you can create a new blank save in your game, and then you only need to inject back the data files into the new "vessel" blank save. The new save should be valid because it was created by the game, and you only replace the data file. (injecting can be done with Apollo too)