PS3 Apollo save tool (development thread)

Bonjour @bucanero.

J'avais modifié en Français les textes de certains des codes de triches (Cheat Codes) de quelques jeux ainsi que quelques valeurs qui à mon humble avis étaient trop grandes en utilisant l'éditeur du "Brute Force Data". Je recopiai les "Cheats" via Ethernet par câble dans le Disque dur de la console visée. Ceci n'est plus possible car lors du démarrage de "Apollo Save Tool v1.0.9" il les remets à leurs valeurs initiales via une extraction qu'il fait en interne.

Pourriez-vous permettre à nouveau que les "chat codes" installés par l'extérieur ne soient pas modifiés lors du démarrage de "Apollo Save Tool v1.0.9" via une extraction incertaine qu'il réalise sans prévenir ni demander si le propriétaire est d'accord ?

Merci par avance.


In English via "Google Trad" :

Hello @bucanero.

I had modified in French the texts of some of the cheat codes of some games as well as some values which in my humble opinion were too large using the editor of "Brute Force Data". I copied the "Cheats" via Ethernet cable to the hard drive of the target console. This is no longer possible because when starting "Apollo Save Tool v1.0.9" it resets them to their initial values via an extraction which it does internally.

Could you allow again that the "chat codes" installed by the outside are not modified when starting "Apollo Save Tool v1.0.9" via an uncertain extraction that it performs without warning or asking if the owner is okay ?

Thanks in advance.
 
Algol said:
I had modified in French the texts of some of the cheat codes of some games as well as some values which in my humble opinion were too large using the editor of "Brute Force Data". I copied the "Cheats" via Ethernet cable to the hard drive of the target console. This is no longer possible because when starting "Apollo Save Tool v1.0.9" it resets them to their initial values via an extraction which it does internally.

Could you allow again that the "chat codes" installed by the outside are not modified when starting "Apollo Save Tool v1.0.9" via an uncertain extraction that it performs without warning or asking if the owner is okay ?

Thanks in advance.
Click to expand...

the unpacking of *.ps3savepatch files should only happen once on first run. If each time you start Apollo the app is unpacking files, then there's a bug or issue on your setup.
A simple work-around, just browse to /dev_hdd0/game/NP0APOLLO/USRDIR/CACHE/ and remove the "appdata.zip" file.

I'd like to know from other users their experience installing the latest version, and if they're also having this repeated unpacking each time they open Apollo.
 
Il n'y a pas d'erreur dans la configuration de mon installation d'Apollo, j'utilisais auparavant la v1.0.2 qui me convenait parfaitement.

Lorsque j'ai installé cette nouvelle version (la v1.0.9), j'ai copié ensuite mes fichiers "ps3savepatch" modifiés par dessus ceux qui étaient présents et j'ai lancé "Apollo Save Tool". C'est la première fois que je constate cette décompression de fichiers lors du lancement de votre "Tool".
Là, je viens de contrôler l'absence du fichier ZIP en cache, il est absent. J'ai recopié mes fichiers "modifiés" dans le dossier adéquat et "Apollo Save Tool v1.0.9" a bien fonctionné cette fois-ci.

Merci par avance pour votre aide très sympathique.


English via Google-trad :
There is no error in the configuration of my installation of Apollo, I used before v1.0.2 which suited me perfectly.

When I installed this new version (v1.0.9), I then copied my modified "ps3savepatch" files over those that were present and launched "Apollo Save Tool". It is the first time that I notice this decompression of files when launching your "Tool".
There, I just checked the absence of the cached ZIP file, it is missing. I copied my "modified" files into the appropriate folder and "Apollo Save Tool v1.0.9" worked well this time.

Thank you in advance for your very kind help.

Algol "le papy".
 
Algol said:
When I installed this new version (v1.0.9), I then copied my modified "ps3savepatch" files over those that were present and launched "Apollo Save Tool". It is the first time that I notice this decompression of files when launching your "Tool".
There, I just checked the absence of the cached ZIP file, it is missing. I copied my "modified" files into the appropriate folder and "Apollo Save Tool v1.0.9" worked well this time.
Click to expand...

Ok, good to know that you didn't find the file, it's working as expected:
The unpacking of data files only happens on first run, and then Apollo removes the .zip file as it's a one-time task only.

Once the installation is done, you can overwrite and change any data file you want, just as you were doing before.
 
From the rif2rap thread , I was talking about adding an option "Export licenses to .RAPs" to Apollo.

I've added some code and I've a first version working... I'll be doing some tests and see if I can make a quick release.

The only issue would be to find a clean way to get the console IDPS on the app. I would like to avoid adding firmware-specific code, but from what I've found there's no other way to achieve it.
 
Last edited:
I did a quick workaround, so Apollo can gather the IDPS from webMan Mod.
I know is not the best solution, but it's a quick way to release the "export licenses to .RAP" feature

I have tested it and I was able to get all the .raps from my games correctly. Quite handy for data backup.

(on a related question, I wonder if I should add rap -> rif conversion to PKGi)
 
Isn't IDPS can be read from specific NAND/NOR offsets? I don't know if access to it is available on HEN but if yes, then it would be better approach IMO (not everyone installing WMM).
 
Berion said:
Isn't IDPS can be read from specific NAND/NOR offsets? I don't know if access to it is available on HEN but if yes, then it would be better approach IMO (not everyone installing WMM).
Click to expand...
Yes, i was thinking about it, if you access flash contents in "raw" the location of IDPS is always at the same offset, so is failproof
But later i thought that there is people "spoofing" IDPS... and that spoof happens in RAM (actually at 3 or 4 different offsets in RAM)... and that offsets changes "by firmware" :/

I guess the source of rebug toolbox should have some code related with this https://rebug.me/rebug-toolbox-source-code/
 
thanks @Berion , @sandungas !

I wasn't aware that IDPS could be found from specific flash offsets. Most of the code I saw was getting values from memory (and addresses changed with each firmware), but probably that's related to spoof settings.

I'll dig into the rebug code and see what I can find.

Edit: indeed, rebug has a function to get IDPS from flash
https://github.com/evilsperm/Rebug-...5ebc33a546fe506f0074/source/toolbox.cpp#L6673

only question is, this would work on HEN? or is limited to CFW?

In any case, my code right now just needs a /dev_hdd0/tmp/idps.hex file, to create the raps from existing user's .rif licenses. The "wMM trick" is only a workaround, as webman just saves a idps.hex file on request. If someone doesn't have wMM, they just need to upload the idps.hex file to the PS3, and then they can export all the licenses.
(the idps file can be generated in many ways, with HAN/HEN you could use the webpage from ps3xploit )
 
Last edited:
bucanero said:
thanks @Berion , @sandungas !

I wasn't aware that IDPS could be found from specific flash offsets. Most of the code I saw was getting values from memory (and addresses changed with each firmware), but probably that's related to spoof settings.

I'll dig into the rebug code and see what I can find.

Edit: indeed, rebug has a function to get IDPS from flash
https://github.com/evilsperm/Rebug-...5ebc33a546fe506f0074/source/toolbox.cpp#L6673

only question is, this would work on HEN? or is limited to CFW?

In any case, my code right now just needs a /dev_hdd0/tmp/idps.hex file, to create the raps from existing user's .rif licenses. The "wMM trick" is only a workaround, as webman just saves a idps.hex file on request. If someone doesn't have wMM, they just need to upload the idps.hex file to the PS3, and then they can export all the licenses.
(the idps file can be generated in many ways, with HAN/HEN you could use the webpage from ps3xploit )
Click to expand...
I believe it should work in HEN because is the same flash access used to make a complete flash dump, the difference is you just dump 16 bytes instead of the whole flash contents
 
I kept digging around the psdevwiki, and I realized that there are some syscalls available related to IDPS and PSID

Code: 
#define SYS_SS_GET_CONSOLE_ID                                       870
#define SYS_SS_GET_OPEN_PSID                                        872

so I wrote some basic functions:

Code: 
s32 lv2_get_console_id(uint8_t *idps)
{
    lv2syscall1(SYS_SS_GET_CONSOLE_ID, (uint64_t) idps);
    return_to_user_prog(s32);
}

s32 lv2_get_open_psid(uint64_t psid[2])
{
    lv2syscall1(SYS_SS_GET_OPEN_PSID, (uint64_t) psid);
    return_to_user_prog(s32);
}

getting the PSID with the lv2 syscall works fine, but the IDPS syscall (870) doesn't work on HEN.
I was googling around, and found a REBUG 4.81 changelog saying that they had to patch syscall 870 to allow IDPS dump. From what I understand, it seems that the 870 syscall was removed/locked at some point in OFW, and Rebug team re-enabled it.

As I don't have a CFW PS3 with Rebug I can't test if my code works OK with custom firmware or not, but I assume it should.

Anyways, I continued my research, and remembered that PS3MAPI also provides calls for IDPS and PSID, so I wrote:
Code: 
int ps3mapi_get_idps(uint64_t *idps)
{
    lv2syscall3(8, SYSCALL8_OPCODE_PS3MAPI, PS3MAPI_OPCODE_GET_IDPS, (uint64_t)idps);
    return_to_user_prog(s32);
}

int ps3mapi_get_psid(uint64_t *psid)
{
    lv2syscall3(8, SYSCALL8_OPCODE_PS3MAPI, PS3MAPI_OPCODE_GET_PSID, (uint64_t)psid);
    return_to_user_prog(s32);
}

in this case, both functions worked fine, and I could get IDPS and PSID on HEN. :)

so, the question now would be: is it safe to assume that any recent CFW and HEN supports these PS3MAPI calls?

I like this approach as it's clean, and doesn't require to access the ps3 flash. (I could also use the original syscalls as backup/fallback method if the PS3MAPI is not available)

I'll be happy to hear your feedback! ( @sandungas @Berion @Zar @zecoxao )

cheers
 
bucanero said:
so, the question now would be: is it safe to assume that any recent CFW and HEN supports these PS3MAPI calls?
Click to expand...

It will work only if HEN, Cobra or Mamba is loaded *AND* the CFW syscalls are enabled.

Why don't get the idps from eid0?
Code: 
static void get_eid0_idps(void)
{
u64 buffer[0x40], start_sector = 0x178; // NOR
u32 read;
sys_device_handle_t dev_id;
if(sys_storage_open(FLASH_DEVICE_NOR, 0, &dev_id, 0) != CELL_OK)
{
sys_storage_close(dev_id);
sys_storage_open(FLASH_DEVICE_NAND, 0, &dev_id, 0);
start_sector = 0x204; // NAND
}
sys_storage_read(dev_id, 0, start_sector, 1, buffer, &read, FLASH_FLAGS);
sys_storage_close(dev_id);
eid0_idps[0] = buffer[0x0E];
eid0_idps[1] = buffer[0x0F];
if((eid0_idps[0] & 0xFFFFFFFFFFF0FF00ULL) != 0x0000000100800000ULL) eid0_idps[0] = eid0_idps[1] = 0;
}

Or just peek one of the following addresses if FW CEX >= 4.75:
Code: 
const uint64_t idps_offset1 = 0x80000000003E2E30ULL;  // on DEX 4.80+: 0x8000000000409A30ULL
const uint64_t idps_offset2 = 0x8000000000474AF4ULL;  // on DEX 4.80+: 0x800000000049CAF4ULL;

const uint64_t psid_offset = idps_offset2 + 0x18ULL;

IDPS[0] = peekq(idps_offset2    );
IDPS[1] = peekq(idps_offset2 + 8);

PSID[0] = peekq(psid_offset     );
PSID[1] = peekq(psid_offset  + 8);

This will work only the CFW syscalls are enabled.
 
The syscalls were indeed removed in OFW.

There is several way to get them.

**** Use them in rebug
**** PS3MAPI like you said, it takes the values from lv2, the offsets are hardcoded in the payload (mamba/cobra)
**** hardcode the lv2 offsets in your tools, and use lv2peek
**** get them from the flash in EID0, or EID5.
Pro : the offset can't change from an update firmware. Look at aldostools post.
Con : it's not the idps used when you connect to psn. The idps used is the one from lv2. And it may be changed by a tool like webMAN MOD.

The best solution for me is :

**** get them from aim syscall (apliance information manager), I think it return idps from lv2.
https://www.psdevwiki.com/ps3/Appliance_Information_Manager#0x19003_-_Get_Device_ID
https://www.psdevwiki.com/ps3/Appliance_Information_Manager#0x19005_-_Get_Open_PS_ID
for example :
u8 TEST_IDPS[0x10];
void GetIDPS()
{
lv2syscall2(867, 0x19003, (u64) TEST_IDPS);
}
Click to expand...


Edit:
I think a more 'proper way' to write it.

s32 sys_ss_appliance_info_manager(u32 packet_id, u64 arg){
lv2syscall2(867, packet_id, arg);
return_to_user_prog(s32);
}

s32 ss_aim_get_device_id(u8 *idps)
{
return sys_ss_appliance_info_manager(0x19003, idps);
}
Click to expand...
 
Last edited:
aldostools said:
It will work only if HEN, Cobra or Mamba is loaded *AND* the CFW syscalls are enabled.

Or just peek one of the following addresses if FW CEX >= 4.75:
Code: 
...

This will work only the CFW syscalls are enabled.
Click to expand...

oh you're right, in those cases the CFW syscalls need to be enabled, or else it won't work. I forgot about that.

Zar said:
The syscalls were indeed removed in OFW.

The best solution for me is :

**** get them from aim syscall (apliance information manager), I think it return idps from lv2.
https://www.psdevwiki.com/ps3/Appliance_Information_Manager#0x19003_-_Get_Device_ID
https://www.psdevwiki.com/ps3/Appliance_Information_Manager#0x19005_-_Get_Open_PS_ID
Click to expand...

yes, like you said, the issue with reading the IDPS from flash is that it might not match the memory value if it has been spoofed

I had no idea about the AIM info manager, it looks like the best way, getting the values from memory without using custom syscalls (it should always be available to the homebrew app) I'll give it a try for sure!

thanks @aldostools @Zar ! :encouragement:
 
quick update, I tested the AIM manager syscall and it worked like a charm :)
I'll go with it, since it takes the values from memory but doesn't require CFW syscalls enabled.

I'll pack things up and try to release this new version with "export licenses to .RAP" in the next few days

cheers
 
after talking with @aldostools about .rif generation, I've added a "mass rap import" for Apollo. Since Apollo was already able to export the user licenses to .raps, it made sense to have the import function to bring those files back to the system.

The idea is quite simple: if you have your backed up .raps in /dev_usb00x/exdata/ and your PS3 account has been activated, Apollo will read every .rap and generate the .rif files for you.

Again, if you're using HEN or COBRA 8.2 you already have a similar functionality embedded, so you might not need it.

stay tuned for the new release
 
Slowly but surely this app involving into "ultimate PS3 backup solution". Which I'm very glad and trying interesting someone in such project since... 3.55. :)

However, GUI wasn't designed for that and IMO needs to reorganize (separate menu: for saves and vmc, for trophies, for licenses, for settings etc.).
 
Berion said:
Slowly but surely this app involving into "ultimate PS3 backup solution". Which I'm very glad and trying interesting someone in such project since... 3.55. :)

However, GUI wasn't designed for that and IMO needs to reorganize (separate menu: for saves and vmc, for trophies, for licenses, for settings etc.).
Click to expand...

well, my original goal was mostly a savegame resign/patching tool like aldo's Bruteforce data (I just wanted to apply some cheats to my savegames without going to my computer). Then I started adding the backup options to the app :)

Probably the GUI can be improved, but it hasn't been my priority (I already experienced the amount of time you can spend just adjusting an icon, changing a screen menu, etc).
Since my attention changes frequently, I try to focus only on adding new features (or bug fixes) when I have a chance.
 
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" ?
 
You must log in or register to reply here.

Similar threads

Back
Top