PS3 Apollo save tool (development thread)

I'm also going to add 2 small ps2classic tweaks I had pending:
- "config" file encryption
- encrypt PS2 isos using "original-file-name.BIN.ENC" as filename, instead of creating a folder "original-file-name/ISO.BIN.ENC"

small changes that I kept in the backlog for too long... I better include them before I forget
 
DeViL303 said:
If you wanted you could add an optional tick box for "force database rebuild on next reboot" , all it requires is to copy this db.err file to dev_hdd0/mms/ https://www.psdevwiki.com/ps3/Recovery_Menu#4._Rebuild_Database
Click to expand...

@DeViL303 I haven't tried Apollo yet but reading about this suggestion made me think, If the tool forces Database rebuild, probably the user would lose all his catalog of games organized by custom album names. And if that's the case, it would be nice to warn the user about it. It's a pain in the ass when you have created custom albums for each game genre and suddenly you loose because of a sytem crash (happened a lot with me using Retroarch because it freezes with some features).

@bucanero Following my theory If for some reason it will rebuild the database, if there was way to backup all albums in your tool, it would be cool.

Keep the good work!
 
Databases structure is not fully known yet. If it will be, then we could stop rely on system database rebuilding functionality. And this is where albums are written.
 
Lambada said:
@DeViL303 I haven't tried Apollo yet but reading about this suggestion made me think, If the tool forces Database rebuild, probably the user would lose all his catalog of games organized by custom album names. And if that's the case, it would be nice to warn the user about it. It's a pain in the ass when you have created custom albums for each game genre and suddenly you loose because of a sytem crash (happened a lot with me using Retroarch because it freezes with some features).
Click to expand...
Yeah, this is why it would need to be optional and a warning would be good, I did add a warning to Ultimate Toolbox on the database rebuild option for this reason. It would be great if we completely understood the database and could edit it freely, Maybe someday, it would allow for some cool stuff. For example we could just have 1 launcher for PS2 and PSP and ROMs, or we could have multi installers that install loads of apps at once, like a complete set up of emulators and launchers and apps all in one pkg.
 
Just for reference, Apollo doesn't force the database rebuild.

In the latest version (1.6.0) it will ask the user if they want to schedule a database-rebuild, only if they apply some trophy modification. You can always answer "no" and Apollo won't create that db.err file to schedule the rebuild.

If you answered 'yes' by mistake, before rebooting, just erase the 'db.err' file using FTP or a file manager (irisman, multiman, mgz, etc)
 
I've added/reversed another save-game checksum fixer that I found around, for "DBZ Ultimate Tenkaichi":
https://github.com/bucanero/ps3-save-decrypters/tree/master/dbz-checksum-fixer

Notes: the checksum is a WADD (input in little endian), and the 32-bit output is saved in a custom way: first 3 bytes, then some zeros, and then the last byte.

(btw, there are no save-game patches/cheats for the game, so the checksum-fix is not really needed, unless you're doing manual hex-edit :) )
 
Last edited:
Here's another checksum fixer that I missed before, this time for "Samurai Warriors 4":
https://github.com/bucanero/ps3-save-decrypters/tree/master/sw4-checksum-fixer

Notes: the checksum algo is ADD(). It generates 4 different checksums based on different offsets (offsets also change between US and JP saves). Then it applies some additional math to those ADD results, and save the 4 CRCs back to the file.

There are some save-game cheats for this game, so in this case adding this custom fixer to Apollo will actually help if someone wants to patch SW4 saves.
 
a 2-in-1 decrypter (also regenerates checksums), for Metal Gear Solid 2 HD and MGS 3 HD:
https://github.com/bucanero/ps3-save-decrypters/tree/master/mgs-hd-decrypter

Notes: I started by reversing a mgs2 decrypter by Red-eyeX32, but I kept doing some research and found Xbox decrypters for MGS2 and MGS3 by Philymaster. Since the encryption was the same across all platforms, I went with the Xbox code as it was built in C# and easier to re-build as C code.

Note 2: I'm pretty sure that this decrypter should also work with the PS Vita saves, as it seems that Konami kept the same custom encryption everywhere without changes.
 
Last edited:
a couple of new checksum fixers I made, based on Xbox notes from Philymaster:

- Alien Isolation: https://github.com/bucanero/ps3-save-decrypters/tree/master/alien-checksum-fixer

Notes: a custom 64-bit checksum, I guess you could call it "SHA1_XOR64". You need to get the sha1 hash, split it in 3 uint64 values, and then XOR the 3 values.
No cheats or patches available for this game, so it's only useful for someone who wants to do manual hex-editing.

- DuckTales remastered: https://github.com/bucanero/ps3-save-decrypters/tree/master/ducktales-checksum-fixer

Notes: a custom 64-bit checksum, I only ported the C# code snippet from Philymaster. Matches 100% the xbox hash.
There's one "max money" cheat patch from BSD, so that should help if someone wants to mod a savegame.
 
I added 3 new checksum fixers:

- Digimon All-star rumble: https://github.com/bucanero/ps3-save-decrypters/tree/master/digimon-checksum-fixer

Note: based on Philymaster notes, algorithm is like ADD(...) but using signed chars. This should help with the current BSD cheats for the game.

- LEGO games: https://github.com/bucanero/ps3-save-decrypters/tree/master/lego-checksum-fixer

Note: based on Philymaster notes, algorithm is a fnv1 hash, with init value = 0xFFFFFFFF. I tested it with LEGO Lord of the Rings, but it should also work with some other new LEGO games. (needs further testing)

- Call of Duty Ghosts (MPDATA): https://github.com/bucanero/ps3-save-decrypters/tree/master/cod-checksum-fixer

Note: based/reversed on Red-eyeX32's fixer. Algorithm is a standard CRC32, but adding 4 null bytes at the end of the input data stream.
This is a fixer for the CoD splitscreen saves. This should work for Call of Duty: Ghosts, and Call of Duty Advanced Warfare.
 
I've been working on "PS3 offline activation" with Apollo, and I have a working solution based on cobra/mamba/reactpsn code.

I know that for CFW there are tools that cover this already (and it comes native in Evilnat 4.88), but I was mostly thinking about HEN users, where there might be unable to update (broken wifi/bt), or unable to connect due to console ban.
For those cases, if they can't connect and activate the console, any digital content they had was lost.

The good news is that I tested my code and the fake accountID and 'act.dat' file generated by Apollo works fine with HEN (tested on 4.84 HEN 3.03). I also tested it with Rebug 4.84 REX and it works fine on CFW too :)

the bad news about HEN, is that the 'act.dat' file gets erased on reboot. (note: on Rebug CFW the act.dat is not erased after reboot)
Of course, the user can run Apollo and re-generate the act.dat, but doing that manually on every boot seems a bit painful.

So I was thinking, maybe we could add some plugin code, that gets executed when HEN is enabled, to just copy a backup "act.bak" to "act.dat". The plugin idea has some options:
  • use the "autoexec.bat" feature of webman Mod, to execute on boot and copy those files ( @aldostools )
  • add the copy "act.bak -> act.dat" to the HEN plugin itself, for example after the version notification ( @esc0rtd3w )
  • make a super simple plugin that copy "act.bak" -> "act.dat" and finish.

@aldostools , this boot_init.txt script should do the trick, right?
Code: 
copy /dev_hdd0/home/000000XX/exdata/act.bak=/dev_hdd0/home/000000XX/exdata/act.dat

if you guys have other ideas, please feel free to share them :)

Edit: I tested the boot_init.txt trick with wMM and it worked great. :D
I think that I can go with that option for now... Apollo can detect HEN and update the boot_init.txt file adding a line for the act.bak copy.
If a HEN user doesn't have wMM, then they can run Apollo and manually re-generate the act.dat
 
Last edited:
bucanero said:
I've been working on "PS3 offline activation" with Apollo, and I have a working solution based on cobra/mamba/reactpsn code.

I know that for CFW there are tools that cover this already (and it comes native in Evilnat 4.88), but I was mostly thinking about HEN users, where there might be unable to update (broken wifi/bt), or unable to connect due to console ban.
For those cases, if they can't connect and activate the console, any digital content they had was lost.

The good news is that I tested my code and the fake accountID and 'act.dat' file generated by Apollo works fine with HEN (tested on 4.84 HEN 3.03). I also tested it with Rebug 4.84 REX and it works fine on CFW too :)

the bad news about HEN, is that the 'act.dat' file gets erased on reboot. (note: on Rebug CFW the act.dat is not erased after reboot)
Of course, the user can run Apollo and re-generate the act.dat, but doing that manually on every boot seems a bit painful.

So I was thinking, maybe we could add some plugin code, that gets executed when HEN is enabled, to just copy a backup "act.bak" to "act.dat". The plugin idea has some options:
  • use the "autoexec.bat" feature of webman Mod, to execute on boot and copy those files ( @aldostools )
  • add the copy "act.bak -> act.dat" to the HEN plugin itself, for example after the version notification ( @esc0rtd3w )
  • make a super simple plugin that copy "act.bak" -> "act.dat" and finish.

@aldostools , do you know if the wMM boot_init.txt feature can be used to copy files?

if you guys have other ideas, please feel free to share them :)
Click to expand...

Yes wMM allows to copy files in boot_init.txt or autoexec.bat

Maybe a more integrated solution would be to update HEN payload to make the copy when it's loaded.

EDIT:
For copy you can use sysLv2FsLink (syscall 810).
 
Last edited:
If HEN allow that, maybe owner changing will block deleting it. Or file permissions, or both. Or LV1 will block attempts. ;p
 
@bucanero i think it should be added to HEN as well. :) it would have to search for act.bak in all possible locations, OR you could store the backup file somewhere with a txt file that tells where to copy it. maybe it would be a little faster, but also the user could still use the backuped files with hen even if they uninstall Apollo.

@aldostools is sysLv2FsLink a psl1ght or sony sdk command? (or maybe it is not a command but the syscall's name..)
 
Last edited:
Coro said:
@bucanero i think it should be added to HEN as well. :) it would have to search for act.bak in all possible locations, OR you could store the backup file somewhere with a txt file that tells where to copy it. may it would be a little faster, but also the user could still use the backup files with hen even if they uninstall Apollo.

@aldostools is sysLv2FsLink a psl1ght or sony sdk command? (or maybe it is not a command but the syscall's name..)
Click to expand...
The act.bak could be stored by default in an external USB, so that the act.dat copying process could be avoid by simply removing it. Not really sure when you wouldn't want to create the act.dat, though...
 
AlexRhine said:
The act.bak could be stored by default in an external USB, so that the act.dat copying process could be avoid by simply removing it. Not really sure when you wouldn't want to create the act.dat, though...
Click to expand...
if you wanted to avoid it sometimes, better to have finding a file with certain name on usb mean to skip the copying. otherwise somebody with broken usb port would not be able to use the feature.
 
You must log in or register to reply here.

Similar threads

Back
Top