PS3 Apollo save tool (development thread)

thanks for the info, I understand that the DEX mode is meant for DEX firmwares, but it doesn't work and the workaround they did was to patch the files with the CEX stuff, so actually even on dex you need to create PS2 classic images with the 'CEX' flag.
I'll leave my code fixed to 'cex' mode then. :)



I checked with the redump link you sent, and it matches. It's a US version game (CD)

btw, if anyone wants to look at the ps2classic source I used, it's here:
https://github.com/bucanero/apollo-ps3/commit/3fa74e13b1158ce57162b94c7b63f7e3d41aef83
I suggest to try DVD9 game (GT4, Yakuza2, etc. ) At some point they were tricky to convert. Nice work btw. ;)
 
btw, if anyone wants to look at the ps2classic source I used, it's here:

Although the following code is working fine, :
https://github.com/bucanero/apollo-...iff-48ac682d3f68f993b19b04bbb45c4cf5R276-R279

It could be wrong in some cases where the DVD is smaller than 700MB. It would assume that it's a CD 2352.

The code could be improved validating the magic code CD001 in the Volumen Descriptor at sector 17 (offsets 0x8000 if it's DVD or 0x9300 if it's CD 2352).
 
I suggest to try DVD9 game (GT4, Yakuza2, etc. ) At some point they were tricky to convert. Nice work btw. ;)

oh well for importing big games I'd have to support split .ISOs or add ntfs/exfat support, because right now it only reads data from standard fat32-USB. I'll keep it in mind for the future

Apollo's main focus is savegame handling, I wanted to add the VME/VMC management and since I added ps2classics code, the iso conversion was almost for free :)

Although the following code is working fine, :
https://github.com/bucanero/apollo-...iff-48ac682d3f68f993b19b04bbb45c4cf5R276-R279

It could be wrong in some cases where the DVD is smaller than 700MB. It would assume that it's a CD 2352.

The code could be improved validating the magic code CD001 in the Volumen Descriptor at sector 17 (offsets 0x8000 if it's DVD or 0x9300 if it's CD 2352).

yes, some improvements can be added for better detection. Thanks for the feedback! :encouragement:
 
oh well for importing big games I'd have to support split .ISOs or add ntfs/exfat support, because right now it only reads data from standard fat32-USB. I'll keep it in mind for the future

Maybe it would be easier to add support for /dev_hdd0 and /dev_bdvd (for remote folders mounted using ps3netsrv)
Also consider add support for/dev_sd, /dev_ms, /dev_cf. These devices support FAT32 and they are available on phat consoles.

ntfs/exfat would be a great addition. BTW I suggest you to add fm_psx by @tps (github.com/lmirel)
It's a complete file manager with very low coupling that supports exFAT/NTFS/ext2/FAT32/UFS file systems.

You can find a modified version with some improvements @ https://github.com/aldostools/IRISMAN/tree/master/fm_exFAT

Basically you need to add the libs libsfm_ps3.a and libfatfs.a, then call the function fmapp_run();
 
yes, probably the easiest option will be to allow ps2 image encryption from HDD (no special requirement and no size limit there)

/dev_bdvd could be a nice option, but I'd need to fix some of the LIMG code: right now the function modifies the original .ISO when adding the LIMG data, and in this case (reading from a read-only media) this stuff must be made on the fly.

back on the memory card stuff, after some under-the-hood changes, now Apollo can scan PS2 and PSP saves too :)

Apollo Save Tool.png

note: since I only have a super-slim, the only PS2 saves I have are from PS2 classics (the encrypted VME files). I'll have to check later about the "regular" ps2 saves. I'm sure Berion already posted the info somewhere in this thread.
 
My ideas for PS2 saves, if time allows it:

- encrypt VMC images
- decrypt VME
- add ECC to raw images
- fix PSV files

if there's a good reason, I might also add import options to formats like action replay.

Since I don't use my PS3 for retro games I don't have many test files. I'll probably just release and wait for reports.
 
My ideas for PS2 saves, if time allows it:

Excuse my insistence, but you didn't commented about the idea of add fm_psx library by lmirel / @tps.

IMO it would add a lot of new features and benefits for the user with a minimal effort:
- It already supports almost all available local file systems (ntfs/exfat/fat32/ufs) / remote fs are not supported yet.
- The user don't need to exit from your application for real file management between different file systems
- fm_psx returns to your app when you close it (it acts like a modal window). So you can call it from anywhere in your code.
- It can be used as a framework for addition of your new libraries (rar/7z/tar/smb/nfs). zip is currently supported (with your custom lib).

If you have questions tps or I could help to find an answer.
 
I mentioned MemcardRex because the PSV format, the difference in between PSV format and the others is the PSV is a single save (not a whole memory card image, composed by multiple saves)

The PSV is pretty much a container with some security added intended to protect the data when is exported/imported to/from USB
But the PSV format is common for PS2 and PS1 (not exactly the same though, there are small differences), inside a PSV file there could be a PS2 save or a PS1 save




Edit:
In MemcardRex you can open the PSV files generated in the official PS3 XMB by exporting to USB a PS1 save (single save)
But... MemcardRex is not able to create PSV files because at the time this feature was added in MemcardRex the encryption/security used by PSV format was unknown
 
Last edited:
Excuse my insistence, but you didn't commented about the idea of add fm_psx library by lmirel / @tps.

IMO it would add a lot of new features and benefits for the user with a minimal effort:
- It already supports almost all available local file systems (ntfs/exfat/fat32/ufs) / remote fs are not supported yet.
- The user don't need to exit from your application for real file management between different file systems
- fm_psx returns to your app when you close it (it acts like a modal window). So you can call it from anywhere in your code.
- It can be used as a framework for addition of your new libraries (rar/7z/tar/smb/nfs). zip is currently supported (with your custom lib).

If you have questions tps or I could help to find an answer.

my concern about adding a full file manager is about what you said some time ago, I'm afraid of turning Apollo into "a backup manager" (or at least users feeling it is) and then having to handle those kind of "support questions"... ("I can't mount this PSX image with Apollo!!! app is crap!")

I know that code-wise, it's not a big task, just adding the libraries and calling the fm_psx when needed... I'll think about it, as I don't want to go down the "backup manager" road nor I want to give the false impression that Apollo will become one.

btw, about smb/nfs, I'm trying to help the original author and get him into ps3 homebrew. We might get nfs/smb into Irisman in the long run :)
 
I mentioned MemcardRex because the PSV format, the difference in between PSV format and the others is the PSV is a single save (not a whole memory card image, composed by multiple saves)

The PSV is pretty much a container with some security added intended to protect the data when is exported/imported to/from USB
But the PSV format is common for PS2 and PS1 (not exactly the same though, there are small differences), inside a PSV file there could be a PS2 save or a PS1 save

Edit:
In MemcardRex you can open the PSV files generated in the official PS3 XMB by exporting to USB a PS1 save (single save)
But... MemcardRex is not able to create PSV files because at the time this feature was added in MemcardRex the encryption/security used by PSV format was unknown

thanks about the info, I knew a bit about the app but I had no idea it was open-sourced on Github. I might take some stuff from there to handle PS1/PS2 saves.

The PSV signing/security was solved by dots_tb , zecoxao (+others) . I already ported their code to Apollo. Now I need to run some tests to be sure I'm generating the exact same signatures.
I also have a working code for PS2 "raw memcard image" to PS2 "ECC image" conversion. Sided along with the ps2classics stuff, you could actually convert a 'raw memcard' to a VME card image.

I was also thinking, if you create a regular PS2.VM2 file in your ps3 (even on superslim), Apollo could decrypt a VME, overwrite the PS2.VM2 and you could actually browse the contents of the VME from the XMB . Then you could export/import PSV files to it, and let Apollo encrypt it back to .VME format :D

I guess that Apollo's next version will be totally PS1/PS2-related. :-p
 
my concern about adding a full file manager is about what you said some time ago, I'm afraid of turning Apollo into "a backup manager" (or at least users feeling it is) and then having to handle those kind of "support questions"... ("I can't mount this PSX image with Apollo!!! app is crap!")

I know that code-wise, it's not a big task, just adding the libraries and calling the fm_psx when needed... I'll think about it, as I don't want to go down the "backup manager" road nor I want to give the false impression that Apollo will become one.

btw, about smb/nfs, I'm trying to help the original author and get him into ps3 homebrew. We might get nfs/smb into Irisman in the long run :)

IMHO a File Manager would complement greatly the current features of Apollo without intending to be a Backup Manager.

IIRC fm_psx doesn't have support for mount games (although it could be added in the future if needed, eg. for IRISMAN).

About smb/nfs, although I would be more than happy to have your collaboration in IRISMAN, I suggest to consider to use fm_psx as framework for the following reasons:
1- It would support almost all available file systems (exFAT, ext2, ntfs, ufs, fat32, smb, nfs)
2- IMO the code is more organized and has less dependencies than IRISMAN's file manager.
3- As fm_psx is implemented as a standalone library, other homebrews could benefit of your additions (including Apollo, pkgi and IRISMAN)
 
@sandungas There are only four PSX memory card image formats, and to be honest, we can call them all the same because most are just raw copies, just differently named, and the rest three have just added useless header (vmp, gme, vgs).

In case of PSV, it was reversed few days after PS3 launch. ;] However signing was defeated few months ago (so we are now be able to recreate proper sign). So BTW: such option should be named "resign PSV", not "fix PSV", because it is not broken, just PS3 refuse to import. IMO.

@bucanero +import/export raw mc images? ^^
 
In case of PSV, it was reversed few days after PS3 launch. ;] However signing was defeated few months ago (so we are now be able to recreate proper sign)
Well, the process required to convert a PSV to a standard raw PS1 MC image is made just by deleting the first 0x84 bytes (as far i know this is the only thing MemcardRex does to import them), but i would not consider this deletion a reversing. Years ago i was creating some pages in psdevwiki about PS1 saves here, i realized that conversion was easy so i advised sendo in his blog about the PSV format (around 2016 or so, i cant find the messages i wrote in his blog though)... and he added support for them in MemcardRex (import only)
But the challenge was to identify how works everyone of that 0x84 bytes (i made it partially in the table that can be seen in the psdevwiki link i posted), and being able to generate them, but this is something that was completed around 2019 for PSV ... and for VMP
 
Last edited:
That was my faulty English. ^^
I been looking into saves and writing info about them in psdevwiki since lot of time ago :D
For PS1/PS2 i tryed to reverse the file structures as much i could, but i hitted with several unknown fields and stuff related with crypto so i could not complete it (i also wasted too much time in trying to reverse the raw formats for MC's and PS2 virtual HDD... later i realized i was reinventing the whell and that info was known), but im sure the people that was working with saves later took a read at what i wrote in psdevwiki so im happy to know i added my little "grain of salt" to the recipe

Now the research about some of that formats is completed and it allows to build some PS3 apps or PC tools supporting PS3 formats. MemcardRex has not been updated though, and by now there are not any PS3 apps related with them, incase bucanero adds support for them is going to be the first :encouragement:



Edit:
Btw, MemcardRex have some kind of "plugin" support that allows to apply cheats to the PS1 saves, you should take a look at that feature too @bucanero i dont know anything about how it works (and/or if there is some kind of database for PS1 save cheats), but it could be a feature that matches with apollo scope
 
Last edited:
Wait a minute. What? Virtual HDD in PS2 emulation on PS3? Where? How? ;)

MemCardRex was rewrited in version 1.9 (1.8 is still better) and author want move it to also Android but it looks like he drop the development. I also letting him knows about PSV cracking like several peoples does too and he goes silent. It's a shame, it is awesome piece of code. I can also recommending of PSXGameEdit for the same purpose.

Only few games for which saves was reversed (analysed?). There is no such thing like "cheats database" for saves (there are cheats only for running games).

BTW: There is some new emulator which using merged both memory cards into one file (256KiB) but I forgot the name, so we can talk about now another variation of raw PSX MC image.
 
Wait a minute. What? Virtual HDD in PS2 emulation on PS3? Where? How? ;)
Yes, a PS2 virtual HDD used in a PS3, is a feature officially available only for BC PS3 models. And it escaped a bit the radar of the scene, but i was taking a look at it because i always thought is very interesting :)
https://www.psdevwiki.com/ps3/PS2_Emulation#Virtual_PS2_HDD

The story is... at the end of the PS2 lifetime, there was released some PS2 games that supported to be installed in the internal hdd of the PS2 (and in the internal hdd of the PSX too)
The most popular games with this feature was final fantasy XI and socom. Final fantasy allowed to install the game completly (so you only needed to insert the disc to initiate the game, and after that all the game files was loaded from hdd), and socom allowed to install "game expansions" (pretty much what we consider a DLC nowadays), is just that game expansions for socom was shipped in optical discs

So... at the time the PS3 was released sony wanted to support this feature in the PS3... and they created a specific category in PARAM.SFO for them (2G), and a fileformat named IMAGE.DAT (located next tot he PARAM.SFO as far i remember) that is technically a "raw" copy of a real PS2 hdd

Well... someone gave me a sample of the IMAGE.DAT created by socom in the PS3 (of huge size, 5gb or more, i dont remember)... i realized it had APA partitions inside, some kind of security signature at top (that i could not identify), a main executable .kelf (used as the boot point), etc...
So after some/lot of research about that file format (but never published though) i started "crafting" some custom IMAGE.DAT of different kinds
-With a single APA partition of the smallest size posible (as far i remember 32mb... or 64mb)
-With a custom .kelf (different than the socom one, but i was not able to sign it correctly)
-etc...

I could not produce anything usable for the scene though... so i throw the towell and didnt published my experiments with it because i had the feeling i was reinventing the whell
You know... after all the IMAGE.DAT is exactly like a real PS2 hdd and there is a lot more people with more experience than me about it, specially about the signing and security stuff, this was a road end for me, and i knew since beginning i was not going to defeat it, i was just doing it for fun and curiosity sake :P

*Later i realized the info i wrote about the VM2 file format internal structure in psdevwiki was a bit pointless too, i mean... is interesting but it would be better to write some short explanation + some links to other webs/code where is explained better how the standard works
*At some point ada (another wiki editor) started documenting the VM1 format but i ignored it a bit for the same reason (i had the feeling we was reinventing the whell.... in the wrong way because there is many other people that could do it better than us)
 
Last edited:

Similar threads

Back
Top