PS3 Apollo save tool (development thread)

I hope that Berion doesn't mind, but I decided to restore the broken jar on the left... ;)

Apollo Save Tool.png
 
@bucanero This UX wasn't designed for so many options. It was made for saves only. Currently is a little chaotic. But of course I'm happy from all functionality, especially bulk resign saves and as I hope trophies too; with user defined IDs! ^^ Tool is definitely literally awesome and one of the most important app on PS3 scene, that's no doubt!

But You know what I want to say about GUI. :} I hope once You add missing feature, then also look into graphic library. It is disaster from aesthetic point of view (really) and this blurry, strange image stretching, colour reduction to 16bit hurts my eyes and black heart. I see that all homebrews which using Tiny3D have exactly the same problems (Artemis etc.). Just like the colouristic and icon butchering from original project (but this can be fixed via skinning so You would have Yours "ancient wall" (need to be fix anyway because You got from me gfx with various of effects, not possible to fit into new vision about which I didn't know back then ;]) and I would have my "green Greece" as it should be). I hope You don't take this to much serious but "programmers art" term was created for a reason. :D

PS: Are You deal also with index file? You know, to not need launch game at least once after trophies resigning to registered a new set. This was problems on PC apps as I remember.

PS2: It was exactly a purpose of "broken jar". ^^ To be a place holder for future option need to be placed in main menu.
 
Last edited:
Berion said:
@bucanero This UX wasn't designed for so many options. It was made for saves only. Currently is a little chaotic. But of course I'm happy from all functionality, especially bulk resign saves and as I hope trophies too; with user defined IDs! ^^ Tool is definitely literally awesome and one of the most important app on PS3 scene, that's no doubt!
Click to expand...

oh yes, I've been stretching things to the limit, but not only the UI ! :) ... for example, the original Artemis code had fixed size data structures, that I ended up replacing for dynamic linked lists so I could add more stuff on the fly.

Still, having the artemis code or using your UI saved me a lot of time, because "stretching" is not "building from scratch" :D

But You know what I want to say about GUI. :} I hope once You add missing feature, then also look into graphic library. It is disaster from aesthetic point of view (really) and this blurry, strange image stretching, colour reduction to 16bit hurts my eyes and black heart. I see that all homebrews which using Tiny3D have exactly the same problems (Artemis etc.). Just like the colouristic and icon butchering from original project (but this can be fixed via skinning so You would have Yours "ancient wall" (need to be fix anyway because You got from me gfx with various of effects, not possible to fit into new vision about which I didn't know back then ;]) and I would have my "green Greece" as it should be). I hope You don't take this to much serious but "programmers art" term was created for a reason. :D
Click to expand...

hahah I can imagine your pain regarding the graphics and artifacts from tiny3D...
I still think that maybe the best option would be to build a simple 2D library (could be based on tiny3d), but without all the "virtual coordinates" and 3D stuff from tiny3d. My only concern would be on how to handle when a user has a lower definition TV, for example you design for 1920x1080 but the user is running in 720.

PS: Are You deal also with index file? You know, to not need launch game at least once after trophies resigning to registered a new set. This was problems on PC apps as I remember.

PS2: It was exactly a purpose of "broken jar". ^^ To be a place holder for future option need to be placed in main menu.
Click to expand...

My plans for the 1.5.x (Juliet) branch is to start with the basics first, listing the trophies and allow the PFD resigning. (no file modifications)

I was checking and in trophies, the account_id is stored in a few files (not just the .SFO as in savegames), so changing the account_id will be a feature I'll add later because I want to be sure that I'm changing the files correctly.
The good thing is that the "TrophyIsGood" app source code is available on Github, so I don't need to waste time re-discovering the TROPUSR, TROPTRNS, etc file format and structure.
Also, at some point further edition of the trophy files should be possible too.

btw, I've tried to use the PSL1GHT trophy addition that I've found here: https://github.com/an0nym0u5/PSL1GHT/tree/master/ppu/include/np , but I couldn't make it work. I mean, I build the library, I can include it in my source code, but every test I did, when I try to call sysTrophyInit(...) I get an error, so I can't do anything with it.
I even tried following examples from the original SDK, and the PSL1GHT version doesn't work... so I'm not sure if it's really supported or not.

I also remember there's a .sprx plugin that unlocks trophies, but I think there's no source code of it available, so I can't check it to see if I can learn something from it
 
I'm using SDTV for a long time with PS3 before switch to 1080p and game developers in only one case design GUI for SD. Almost all just put scaled wide screen into low resolution (whatever is 640x480 or 1080x720). It is most reasonable way because You don't have to fight with coordinates for obsolete proportions and resolution. Unfortunately I don't know how to program such thing.

Fingers crossed. ^^
 
Imo a good solution for tiny3d would be to initiate by reading the TV settings from xregistry.sys, right now i dont know how many info can be recovered from it but all the info related with the screen output stored in the PS3 is located in xregistry.sys
After that "init" tiny3d with the exact TV resolution and without the "virtual grid", so the values for positions, sizes, scales, etc... are exatly what is written in the code (that was calculated using 1080p as default)

And for the other aspect ratios and resolutions different than 1080p... well, the correct way is very close to what sony did in the XMB... they are loading the values externally from a plain .txt file (the XMB layouts)
Probably they had some kind of "XMB emulator" workng in PC with some controls to move, scale, edit, etc... the different XMB objects, you know like in the 3D apps that have a "floating window" with the attributes of every tool or object... you can type directly in the edit box or just use the mouse to "drag and edit" objects in a easy way
Also, the fact that all that values was stored in a plain .txt file made them very easy to update them, reload XMB and test (without need to compile anything, just modifying a .txt file)

The way how they stored all that values maybe was a bit excessive though, just because there are many values that are written explicitelly... but is a lot more convenient to calculate everythig using scale factors... this way you dont need to write the value explicitelly, you just need to tell the scale factor that should be something generic for all the interface objects

Actually... it would be superhandy to try to find how to apply a single general scale factor at the first step, when tiny3d is initiated (or well, a couple, one scale factor for widths and another for heights)
 
Last edited:
I did some tests with my new trophy code in Apollo, and tried to resign a trophy set without any external modification.
(Game: After burner climax)

I did a standard resign, but when I tried to load the game the system detected that the trophy-set was corrupt and gave error 0x80022D74. Then it forced the game to quit.
As I said, I didn't do any modification to the original files, I just tried to resign it to test the pfdtool in Apollo.

When I have a chance, I'll try to resign the same trophy in my computer with the regular build of pfdtool and compare the results.
 
Last edited:
I solved the issue with the trophy set resigning, and I actually discovered something, and I think that I've been using the wrong id for a long time....

so, looking for more information about trophy resigning, I found this message from user shaddai59 about the TrophyIsGood tool: https://consolecrunch.org/threads/ps3-trophy-is-good.10564/

then he mentions that you need to set up pfdtool, and when he talks about the "console_id", he says
- Put your consoleid behind console_id= (like this > console_id=00000001008500012345678912345678)
Click to expand...

clearly, this is an example of a IDPS, and not the PSID. !!!
So I changed my code in Apollo to use the IDPS (and not the PSID) when resigning the trophies, and that worked like a charm! :D

I believe that the same mistake has been happening when resigning save-games, but for some reason using the PSID instead of the IDPS didn't break the security checks for save-games.

anyways, now that I have the trophy resign working, I can start preparing the first release for the 1.5.x branch :)
 
Last edited:
PSID (or OpenPSID?) is used along with user number as validator for none SEN-bind accounts (binded using only NP Account ID (category node in xRegistry.sys), or in short Account ID (parram in PARAM.SFO)). I never thinks mixing this two systems can results valid. ^^

BTW: I also don't know from what IDPS vs PSID names comes from but they are misleading.
 
bucanero said:
well, as I didn't get any news in my email, I sent a message on twitter to see if chaoszage replies or not... I do wonder if he sees the messages or maybe he's just ignoring them (???)... oh well, let's see!
Click to expand...

I'm not affiliated to that site in any way and I haven't talked with chaoszage is years. Maybe he is not active and only have the site running alone.

If you need access I can give you my user/password so you can enter. Anyway I barely use it as I no longer update BSD.
 
Berion said:
PSID (or OpenPSID?) is used along with user number as validator for none SEN-bind accounts (binded using only NP Account ID (category node in xRegistry.sys), or in short Account ID (parram in PARAM.SFO)). I never thinks mixing this two systems can results valid. ^^

BTW: I also don't know from what IDPS vs PSID names comes from but they are misleading.
Click to expand...

indeed, "IDPS" and "PSID" names can be misleading and prone to confusion :dejection:

but yes, PSID is used in the savegame PARAM.SFO and stored inside, no encryption or special security there.

the issue here is that the IDPS (the one that starts with 00000001008xxxx) is used in the trophy PARAM.PFD to generate a hash key used to sign files... and of course if you use the other value, the key is different and the results don't match (and the PS3 detects the trophy set as corrupt)

if someone wants to check it themselves, try with pfdtool. Just copy a trophy set from your PS3, then run:
Code: 
./pfdtool -c /path/to/NPWR00981_00

in your global.conf file, if you set your console_id=PSID, you'll get:
Code: 
[*]       Console ID Hash:         FAIL

if you change your console_id=00000001008xxxx (IDPS), you'll get the correct result:
Code: 
[*]       Console ID Hash:         OK
 
bucanero said:
indeed, "IDPS" and "PSID" names can be misleading and prone to confusion :dejection:

but yes, PSID is used in the savegame PARAM.SFO and stored inside, no encryption or special security there.

the issue here is that the IDPS (the one that starts with 00000001008xxxx) is used in the trophy PARAM.PFD to generate a hash key used to sign files... and of course if you use the other value, the key is different and the results don't match (and the PS3 detects the trophy set as corrupt)

if someone wants to check it themselves, try with pfdtool. Just copy a trophy set from your PS3, then run:
Code: 
./pfdtool -c /path/to/NPWR00981_00

in your global.conf file, if you set your console_id=PSID, you'll get:
Code: 
[*]       Console ID Hash:         FAIL

if you change your console_id=00000001008xxxx (IDPS), you'll get the correct result:
Code: 
[*]       Console ID Hash:         OK
Click to expand...

I haven't used BSD in a long time, but if I recall correctly,
you can set the Console ID to 00000000000000000000000000000000 and it will be work.
 
aldostools said:
I'm not affiliated to that site in any way and I haven't talked with chaoszage is years. Maybe he is not active and only have the site running alone.

If you need access I can give you my user/password so you can enter. Anyway I barely use it as I no longer update BSD.
Click to expand...

oh thanks a lot @aldostools! that would be amazing! :encouragement:

if you can, send me a PM with the details and I'll try it out. (as I'm not sure if you have my email address or not, but a pm here should be secure enough I think)

thanks again!
 
bucanero said:
oh thanks a lot @aldostools! that would be amazing! :encouragement:

if you can, send me a PM with the details and I'll try it out. (as I'm not sure if you have my email address or not, but a pm here should be secure enough I think)

thanks again!
Click to expand...

hi @aldostools ! I imagine you're busy with work, so whenever you have a chance, please don't forget to share that login for the bruteforce savedata forum, so I can go and grab all the info for improving Apollo.
(btw, my email: siberianlord @ yahoo.com.ar )

thanks again for your help!!!
 
Algol said:
@aldostools, @bucanero.
Thank you gentlemen for your research.

From what I just read, maybe we should eliminate a line of code or simply reverse the first two between them ???
Did you find a solution for this error please ???
Click to expand...

hello @Algol , about GT5:

check the new version Apollo v1.5.0, I've added support for the code type 88xxxxx so the cheat for GT5 should work now. :)
I've also added the BSD script equivalent "search next" that was missing from Apollo too

Along with the added support for global BSD script variables across patch items, I think that Apollo is getting 99% close to support everything from the original tool by Aldo. :) Looking back, when I started I honestly wasn't sure that I could achieve it!
 
Hello @bucanero (Buk).

En effet, je peux te confirmer que ton travail a été excellent avec APOLLO. La révision 1.5 est parfaite. Aujourd'hui, j'ai pu tester la modification de la SAVE de GT5 via le "cheat code" de la "Money" et tout va bien, la valeur que j'ai installé (19 990 190 cr) est parfaitement prise en compte par GT5.
Ton logiciel "APOLLO v1.5.0" est très abouti maintenant, j'ai moins besoin de lancer le PC pour faire quelques modifications de SAVE. Il n'y manque qu'un éditeur de "cheats" (les textes) intégré pour qu'il soit parfait.

Que de chemins parcourus, toi mon ami !!!

Un énorme MERCI.

Très cordialement.


In English via G-Trad :

Indeed, I can confirm that your work has been excellent with APOLLO. Revision 1.5 is perfect. Today, I was able to test the modification of the SAVE of GT5 via the "cheat code" of the "Money" and all is well, the value that I installed (19 990 190 cr) is perfectly taken into account by GT5.
Your software "APOLLO v1.5.0" is very successful now, I have less need to start the PC to make some modifications of SAVE. It only lacks an integrated "cheats" editor to make it perfect.

So many paths traveled, you my friend !!!

A huge THANK YOU.

Kind regards.

Algol "le papy".
 
You must log in or register to reply here.

Similar threads

Back
Top