PS3 Apollo save tool (development thread)

Only important thing which is on flash and comes to my mind is "/dev_flash2/etc/xRegistry.sys" (but copy whole etc dir because backup file and xRegistry.val can be valuable in some very rare case when console force user to clean and he need some IDs or passwords to restore). However, in restore manner, do this to only xRegistry.sys file, ignoring the rest (because if user restore it on another console, backup file will be used and some "fields" from current restored one to forge new valid).

Nothing more on dev_flash is worth to backup IMO. If someone will get semi-brick, it is sufficient to just reinstall CFW. If someone break XMB but FTP works in background he still can replace XMB files from other users or from unpacked *.pup|*.tar's.

I'm not sure but on NAND consoles, exdata with licenses for each user are somewhere on eFlash (one of those dev_flash mount points).
 
I agree, the contents of dev_flash are not much important because you can recover the files from the PUP you installed. Are just generic stuff

The feature that i miss from apollo (not sure if you implemented it yet) is the batch export/import of all savegames. The goal is to backup all the saves before formating or replacing the hdd... and later to import all the savegames in the new hdd
Both things made in a automated way
 
Berion said:
Only important thing which is on flash and comes to my mind is "/dev_flash2/etc/xRegistry.sys" (but copy whole etc dir because backup file and xRegistry.val can be valuable in some very rare case when console force user to clean and he need some IDs or passwords to restore). However, in restore manner, do this to only xRegistry.sys file, ignoring the rest (because if user restore it on another console, backup file will be used and some "fields" from current restored one to forge new valid).
Click to expand...

Alright, good to know that the only valuable stuff is the xRegistry. Even if solutions like PS3HEN include a "Backup xRegistry" option, I'll try to add a "backup to .Zip" of the "/dev_flash2/etc/" folder. :encouragement:

sandungas said:
I agree, the contents of dev_flash are not much important because you can recover the files from the PUP you installed. Are just generic stuff

The feature that i miss from apollo (not sure if you implemented it yet) is the batch export/import of all savegames. The goal is to backup all the saves before formating or replacing the hdd... and later to import all the savegames in the new hdd
Both things made in a automated way
Click to expand...

Right now there's an option to "bulk copy" all PS3 saves to USB. (on the User Backup menu), but there's no bulk import option.
A first step I can surely add, is a "bulk resign/unlock" of all the saves found on USB.

The import feature for saves still has an issue, I mean, I can copy everything to HDD and resign, but the saves won't show up and will require a database rebuild. Is that OK for a general user? I'm just wondering if some might complain "oh I imported saves and nothing shows up!"
If I just do a bulk resign/unlock and leave the files on USB, the user could just copy/import the saves from the XMB and in that way it won't need a DB rebuild.

Well, I guess I can put both options, "bulk resign/unlock" and "bulk copy to hdd", and if the user wants to use "copy" they'll have to rebuild db later.
 
bucanero said:
I've been refining the license import/export functions in Apollo:

Now you can:
- import a single .rap (from usb)
- bulk import all .raps (from usb)
- export a single .rif license (to usb)
- bulk export all licenses (to usb)
- backup all .rif licenses as .zip (to usb)

I think that now it's a complete feature :) Talking about backups, I was thinking what @sandungas usually says about the importance to backup the whole /dev_flash folders/files in case you have a serious crash, so you can restore stuff like the activation, etc.
Does it makes sense to add an option to backup the flash folders to .ZIP from Apollo?

if it makes sense to do it, which folders from dev_flash? or should it just .zip everything "just in case" ?
Click to expand...

I think you mean to backup /dev_flash2 or xRegistry.sys, since /dev_flash contains static files that are restored by PUP installation ...unless the user have made customizations like I use to do :)

For "backup all .rif licenses as .zip (to usb)" it would be useful if you could include in the zip a file with the IDPS and act.dat corresponding the *.rif files. If you backup "all" .rif licenses, I suppose that you mean from a user single account in /dev_hdd0/home. Each account use a different act.dat

A full backup in zip format for the individual accounts in /dev_hdd0/home would be cool too.
It would backup the saves, trophies, rifs, edats and configs.

The eid0_root_key would be an important backup too. Although only CFW users can get it.
Apollo could call the ELF included in Rebug Toolbox if you decide to add this feature.
 
aldostools said:
I think you mean to backup /dev_flash2 or xRegistry.sys, since /dev_flash contains static files that are restored by PUP installation ...unless the user have made customizations like I use to do :)
Click to expand...

yes I guess the proper reference is /dev_flash2 and the xRegistry as @Berion mentioned :)

For "backup all .rif licenses as .zip (to usb)" it would be useful if you could include in the zip a file with the IDPS and act.dat corresponding the *.rif files. If you backup "all" .rif licenses, I suppose that you mean from a user single account in /dev_hdd0/home. Each account use a different act.dat
Click to expand...

oh, good catch, I totally forgot about IDPS and it would be really useful to have it saved in the .Zip backup.
Edit: act.dat was already included in the .zip :D. Still, IDPS can be added to the backup.

Yes, good thing to point out: when I said "all", I meant "all the licenses from the current user running Apollo". If the PS3 has many users with licenses on each, you'd have to run Apollo on each account and make a backup.

A full backup in zip format for the individual accounts in /dev_hdd0/home would be cool too.
It would backup the saves, trophies, rifs, edats and configs.

The eid0_root_key would be an important backup too. Although only CFW users can get it.
Apollo could call the ELF included in Rebug Toolbox if you decide to add this feature.
Click to expand...

another good idea, a global user backup (/dev_hdd0/home/0000xxx/*) could be handy too. It might take some time for the Zip library to compress and backup everything, but I guess that the user will have patience in that case, as it's an action that you won't be doing every time.

for the eid0 I'd need somebody with CFW to help testing, as I'm using ps3hen (superslim) .

I guess that I can release the rap/rif stuff that I've now, and then work on the things commented with @Berion @sandungas @aldostools
 
Last edited:
bucanero said:
Alright, good to know that the only valuable stuff is the xRegistry. Even if solutions like PS3HEN include a "Backup xRegistry" option, I'll try to add a "backup to .Zip" of the "/dev_flash2/etc/" folder. :encouragement:



Right now there's an option to "bulk copy" all PS3 saves to USB. (on the User Backup menu), but there's no bulk import option.
A first step I can surely add, is a "bulk resign/unlock" of all the saves found on USB.

The import feature for saves still has an issue, I mean, I can copy everything to HDD and resign, but the saves won't show up and will require a database rebuild. Is that OK for a general user? I'm just wondering if some might complain "oh I imported saves and nothing shows up!"
If I just do a bulk resign/unlock and leave the files on USB, the user could just copy/import the saves from the XMB and in that way it won't need a DB rebuild.

Well, I guess I can put both options, "bulk resign/unlock" and "bulk copy to hdd", and if the user wants to use "copy" they'll have to rebuild db later.
Click to expand...
Hmmm, if there is no import i guess the bulk resign of saves in USB is good enought, and not conflictive or confusing

To update the contents displayed in XMB is enought to run a "rebuild database", and there is an easy way to do it. When the PS3 boots it checks for the presence of a file named /dev_hdd0/mms/db.err
Is needed to create that file with contents = 0x000003E9 (i dont know what means this value though)
https://www.psdevwiki.com/ps3/Recovery_Menu#Rebuild_Database_without_Recovery_Menu

So you can do...
1) Resign all saves in USB
2) Copy them to dev_hdd0
3) Display a warning to explain to the user what is going to happen in the next steps
4) Create the file db.err
5) Force a "soft reboot" (like the option in rebug toolbox)
 
Last edited:
bucanero said:
Alright, good to know that the only valuable stuff is the xRegistry. Even if solutions like PS3HEN include a "Backup xRegistry" option, I'll try to add a "backup to .Zip" of the "/dev_flash2/etc/" folder. :encouragement:
Click to expand...

^^

but the saves won't show up and will require a database rebuild. Is that OK for a general user? I'm just wondering if some might complain "oh I imported saves and nothing shows up!"
Click to expand...

Then Your will write magic acronym: RTFM. ;) Personally I'm fully ok with this because:
  • It is not big deal to boot PS3 is special mode (by hand or just by setting file flag in mms or whatever way doing it the xai plugin).
  • We didn't reverse database format, right? ;) So we have no choice to be honest. At least for now.
  • And You can also put such warning on screen after bulk saves/trophies recovery.
Yes, good thing to point out: when I said "all", I meant "all the licenses from the current user running Apollo". If the PS3 has many users with licenses on each, you'd have to run Apollo on each account and make a backup.
Click to expand...

What do You think to enlarge the owner.txt to all found accounts?

In example You can use some parser like XML or INI to keep separate IDs for each one and merge also idea of keys management to just one place. i.e
Code: 
<owner>
   <per_console_ids>
     <eid_root_key="000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" />
     <idps="000000010089000B1400EFDDCA255266" />
     <psid="0000000000000000" /> <!-- I forgot how long it is ;p -->
   </per_console_ids>
   <user id="00000001" name="Zdzichu" np_account_id="FFFFFFFFFFFFFFFF" />
   <user id="00000007" name="Czesiek" np_account_id="0123456789ABCDEF" />
   <user id="00000256" name="Bucanero" np_account_id="AAAAAAAAAAAAAAAA" />
</owner>
 
Last edited:
Berion said:
Then Your will write magic acronym: RTFM. ;) Personally I'm fully ok with this because:
  • It is not big deal to boot PS3 is special mode (by hand or just by setting file flag in mms or whatever way doing it the xai plugin).
  • We didn't reverse database format, right? ;) So we have no choice to be honest. At least for now.
  • And You can also put such warning on screen after bulk saves/trophies recovery.
Click to expand...
After writing my previous post i realized the warning should be displayed in step 1 (before doing any other thing), mostly because the next steps can be automated completly by using the file db.err, so it looks a bit pointless to interrupt the importing procedures at an intermediate step just to display the warning
So instead of what i wrote in my previous post i think it would be better to display the warning at first step and then run all other actions automatically, it should not take much time, even with a big amount of saves
Not sure though, it depends of how this is going to be implemented, im just trying to imagine it, anyway, in the warning is needed to advise about:
-The PS3 is going to reboot
-Is going to start a database rebuild process, please allow the process to complete, dont stop it
-The playlists (music, etc...) are going to be lost
-The custom folder categories are going to be lost
-The dictionary with the most used custom words is going to be lost
-Some other things are going to be lost (we need to check the PS3 user manual, there is a description of how many things are lost)

I reversed the db structure of the most deeper level of the "game" hierarchy almost fully (only 1 important unknown left), the problem is i could not find how is connected with his "parents", but this is not enought to add or remove entries in the db
The only way to add or remove entries is by "asking gently" to the firmware to do it for us by using the official functions
You know, the db is not really protected in that sense, we dont need to crack or bypass any security, is just a matter of telling to the firmware what needs to be made
Thats the part we dont know, is needed to reverse the sprx files involved in the db manteinance and to find the communications channel (i guess technically is named an interface) in between vsh and db :/
 
Last edited:
About writing to dbs: isn't Hermes made tool to install applications from ZIP instead from PKG? For sure he must deal with database somehow. Maybe it's good lead? But I forgot the app name and don't know if source was available.
 
sandungas said:
To update the contents displayed in XMB is enought to run a "rebuild database", and there is an easy way to do it. When the PS3 boots it checks for the presence of a file named /dev_hdd0/mms/db.err
Is needed to create that file with contents = 0x000003E9 (i dont know what means this value though)
https://www.psdevwiki.com/ps3/Recovery_Menu#Rebuild_Database_without_Recovery_Menu
Click to expand...

oh, I had no idea about that trick with the db.err file. Indeed it could be a nice solution ! thanks @sandungas :encouragement:

Berion said:
^^
What do You think to enlarge the owner.txt to all found accounts?

In example You can use some parser like XML or INI to keep separate IDs for each one and merge also idea of keys management to just one place. i.e
Code: 
<owner>
...
</owner>
Click to expand...

I like the idea, using XML (or JSON?) to keep every account in a global owner.txt file. I wouldn't provide an Editor for that file, but I'd support an "account selector" in the Settings menu. For example with your file, the user could select:
- Automatic (use the userid, account-id, etc that was auto-detected by Apollo)
- Zdzichu
- Czesiek
- Bucanero

I'll keep this in mind as I add more stuff to Apollo :D
 
The choice is Yours of course but as I remember, JSON doesn't allow commenting. And would be good idea to add in per console ids something like this: "Do not share Your Console IDs, or someone can steal it, leading to BAN hammer for Your console".

Special editor is not needed as they are just text files. If You want keep user name, think about UTF-16 encoding or Base64 for this specific field (but simple editors on Windows like notepad in Windows 10 support only UTF-8, which doesn't cover i.e Japanese or Arabic (I could be wrong, didn't check this)).
 
Berion said:
The choice is Yours of course but as I remember, JSON doesn't allow commenting. And would be good idea to add in per console ids something like this: "Do not share Your Console IDs, or someone can steal it, leading to BAN hammer for Your console".
Click to expand...

well, thinking about Xml & Json, I think that XML is also used in the Trophies, right?
So I guess that makes sense to just use xml for the owners too.

I've implemented the /dev_flash2 -> to .ZIP function, so that's one thing less to backup. :)
Now I'm working on the mass resign/unlock option (for saves on USB).

Also, I was looking into the "region change" option for the save games. As I understand, for this to work I need to change the TITLE_ID from the PARAM.SFO, change the folder name and references (param.sfo), and then resign everything.

I must say that each time I add something new, I end up pushing Artemis GUI code to the limits :D ... for now I can still find ways to hack it and stretch the UI code to support something new, but I might hit a wall at some point
(I hope I can avoid writing a new GUI from scratch) :-p
 
Critical issue found:

A user reported an issue with a "The last of us" save-game, and at first I thought that maybe was a bug in my code related to a CRC check/hash, but then I discovered a bigger issue that I completely missed when working with the BSD cheats:
some save-games (like TLOU) have an additional layer of encryption :confused:

aldo's Bruteforce Data is using some specific tools to handle those files, e.g. "tlou_save_data_decrypter.exe". So, right now using Apollo to apply cheats in such games will corrupt the save-game (and render the file garbage)

First I need to know all the games that have such encryptions to disable the cheats on Apollo.

@aldostools , could you tell me which games in BSD have this 2nd layer of encryption, so I can remove the cheats to avoid unaware users destroying their savegames?
I saw a bunch of decrypt tools in the BSD files, but I want to double-check and filter any game that requires using those kind of tools.

Once I clear the unsupported cheats from Apollo, then an option would be to get the source code (probably impossible) of those tools and port them to Apollo, or else the only way would be to reverse-engineer the tools. (lots of time and patience with Ghidra or IDA)

Anyways, for now I'll only remove the cheats for the unsupported games.
If anyone wants to help hunting the source code or reverse engineer those savegame decrypt tools, I'll really appreciate it
 
bucanero said:
Critical issue found:

A user reported an issue with a "The last of us" save-game, and at first I thought that maybe was a bug in my code related to a CRC check/hash, but then I discovered a bigger issue that I completely missed when working with the BSD cheats:
some save-games (like TLOU) have an additional layer of encryption :confused:

aldo's Bruteforce Data is using some specific tools to handle those files, e.g. "tlou_save_data_decrypter.exe". So, right now using Apollo to apply cheats in such games will corrupt the save-game (and render the file garbage)

First I need to know all the games that have such encryptions to disable the cheats on Apollo.

@aldostools , could you tell me which games in BSD have this 2nd layer of encryption, so I can remove the cheats to avoid unaware users destroying their savegames?
I saw a bunch of decrypt tools in the BSD files, but I want to double-check and filter any game that requires using those kind of tools.

Once I clear the unsupported cheats from Apollo, then an option would be to get the source code (probably impossible) of those tools and port them to Apollo, or else the only way would be to reverse-engineer the tools. (lots of time and patience with Ghidra or IDA)

Anyways, for now I'll only remove the cheats for the unsupported games.
If anyone wants to help hunting the source code or reverse engineer those savegame decrypt tools, I'll really appreciate it
Click to expand...
I think it could be related with this (both are unknown)

The first 7 bytes of SAVEDATA_LIST_PARAM
https://www.psdevwiki.com/ps3/PARAM.SFO#SAVEDATA_LIST_PARAM
https://www.psdevwiki.com/ps3/Talk:PARAM.SFO#SAVEDATA_LIST_PARAM
This value is weird, but it seems directly related with some kind of anti-tampering protection
I found how it works in the game "the orange box: BLES00153, BLES00171, BLES00172, BLUS30055" (is explained in the talk page), in this game the value is the folder size in sectors, but at the time i was looking at this i was considering maybe this field is available for the game developers to store whatever they wants (for this game is just the folder size, but for other games could be other stuff)
Note some of the examples in the link in wiki frontpage are storing something very different, just to mention some weird ones:
Dead island riptide = PTRONAS (this seems to be a name, taken from somewhere)
Venetica = 3-47755 (weird, are 2 numeric values)
Hunted: The Demon's Forge = UNKNOWN (i guess the game devs didnt know what to do with it)

A value inside PARAMS
https://www.psdevwiki.com/ps3/PARAM.SFO#PARAMS
https://www.psdevwiki.com/ps3/Talk:PARAM.SFO#PARAMS
The first 7 bytes of PARAMS seems to indicate special features, we dont know his purpose so... is always needed to consider them as posible candidates to the problems that appears when we try to mess around with savegames :D
 
sandungas said:
I think it could be related with this (both are unknown)
Click to expand...

thanks for the info @sandungas !

in this TLOU case there's a dedicated encryption layer that is handled by this tlou_decrypter ... I was playing a bit with Ghidra, reversing the tool, and the encryption looks very much like the crypt_64bit...() function from >> https://github.com/RocketRobz/NTR_L...r/twlnand-side/BootLoader/source/encryption.c

again, a proper implementation would require a lot of work & patience, so for the moment cheats for these games will have to be removed.
 
You must log in or register to reply here.

Similar threads

Back
Top