PS3 PS1 libcrypt support on PS3 official emus - research thread

I did a quick test on Vagrant Story SLES-02754 that is libcrypt enabled.
Building an EBOOT and running it on a PSP boots the game, plays the intro movie and brings up the start menu.
After selecting NEW GAME libcrypt kicks in and the game just hangs with a "now loading" screen.

Downloading and extracting this zip file:
https://dl.consolecopyworld.com/dl.php?c=psx&f=pdx-vsuk!zip
which contains the ppf file for the game pdx-vsuk.ppf

$ md5sum pdx-vsuk.ppf
294324e7142573df9eee82cfe5220b59 pdx-vsuk.ppf

This is a PPF2 file and after applying this this patch to the .bin and building a new EBOOT.PBP
the game now works and starts.
Unfortunately this PPF also adds an annoying intro-screen immediately after the game has booted with annoying music but it goes away once you click X. the important part is that the patch works and the game boots.

It would definitely be possible to remove the individual patches that are just the intro and are not about libcrypt
but the PPF contains 2503 different segments all ranging from a handful of bytes to many that are up to 255 bytes in size.
I would imagine that the libcrypt part of the PPF would all be relatively small segments of a few bytes to just NOP out a conditional jump or similar in the machine-code and that all the larger ones would be the segments containing the music graphics and the code for the intro.
But still, it would be a LOT of work to go through and test which ones you can remove and which ones you can not.
(and remove the wrong one it means that maybe you removed the libcrypt check that happens at some cut-scene when you are 20 hours into the game, wic would suck)
So I am inclined to just leave the PPFs as is. As annoying as the intro is I can live with it since it is just a click on the X button and it goes away. I see it this way, Paradox spent a lot of time finding and removing all the libcrypt code if in exchange for that they want me to watch their intro for a few seconds then so be it.


Anyway, this is a very long-winded way of saying : this particular patch works for SLES-02754 and that is all that matters for me.
So that is one game taken care of, now just find, test and curate a list of the remaining 228 games :-)
 
Minimizing the patch data would be great but some are a lot more complicated then just patch data, some of them its like a seperate exe in there and some groups protected their work too so it would need a lot of work for some of them (so its not just a compare job in a hex editor),

Im still think its very interesting how official ps1classics are clean though, they don't seem to have a patch in there (or its hidden somewhere in eboot.pbp) but i think its more likley there is a flag or something used to ignore/bypass it, in firmware 1.92 and 1.93 there was
libcrypt_key=%08x
although i have no idea how to use it, its there so its possible the flag still exists somewhere in the eboot.pbp but i have no idea where to start looking
Are you sure the "PS1 Classics" for PS3 in the PSN store are clean disc images (without any patch applyed) ?, i did read several times before that sony was applying patches to them to disable the libcrypt, but after reading you im wondering if it was an urban myth
Anyway... check different games, i think you are overcomplicating things by using final fantasy (a game with 4 discs) for the experiments
Better try with the smallest game size posible, a tiny guinea pig is always better than a fat one :D

To me the libcrypt_key=%08x looks like it was used to load a crypto key in that function (whatever that function does we dont know, but we can assume it was doing some kind of decryption), and thats good news because i guess it means the emulator can handle subchannel data

What i dont get is why it was intended to be changed dinamically... i mean is more efficient to hardcode the key inside the .self this way there is no need to ask for it to external functions

Anyway... we need to keep in mind also that there are some arguments supported by the PS1 emulators that are still labeled as "unknown", we dont even know its lenghts but the libcrypt_key=%08x is 8 bytes in hex
https://www.psdevwiki.com/ps3/PS1_Emulation#Arguments

Cobra/mamba is the responsible to pass that arguments to the emulator when the game boots, maybe one of them is for the libcrypt_key
 
Are you sure the "PS1 Classics" for PS3 in the PSN store are clean disc images (without any patch applyed) ?, i did read several times before that sony was applying patches to them to disable the libcrypt, but after reading you im wondering if it was an urban myth
Anyway... check different games, i think you are overcomplicating things by using final fantasy (a game with 4 discs) for the experiments
Better try with the smallest game size posible, a tiny guinea pig is always better than a fat one :D

That would be relatively easy to check. Unpack the EBOOT and then convert the IMG/BIN file to an ISO and mount it. Do a md5sum of the main executable.
Then do the same thing for the executable on a libcrypt protected disk and compare.


Anyway, maybe we are losing focus. SBI files are readily available and if added to cobra's scsi emulation should solve the issue for all libcrypt protected games.
PPF files exist too for all(?) libcrypt games and would solve the issue for EBOOT.PBP based games. the only thing we need for PPF files is to create a curated list of where to find the actual patches.
 
Are you sure the "PS1 Classics" for PS3 in the PSN store are clean disc images (without any patch applyed) ?, i did read several times before that sony was applying patches to them to disable the libcrypt, but after reading you im wondering if it was an urban myth
Well i have only checked FF8 (since its the only Libcrypt game i have the original CD for so i can verify it myself), Berion also confirmed this on the previous page with crash team racing saying the extracted ISO is 1vs1 with redumps archive
In FF8's case CD1 has the last few bytes cut off (could be psxtracts fault though) but its identical 1=1 (checked with HxD compare function since the MD5 is different since the end is cut off) and CD2+CD3 are 1=1 identical to my original CD's, CD4 on the other hand seems slightly different so maybe something there got patched (or psxtract doing weird stuff again)
 
In FF8's case CD1 has the last few bytes cut off (could be psxtracts fault though) but its identical 1=1 (checked with HxD compare function since the MD5 is different since the end is cut off) and CD2+CD3 are 1=1 identical to my original CD's, CD4 on the other hand seems slightly different so maybe something there got patched (or psxtract doing weird stuff again)

Have you tried to just decrypt the EBOOT.PBP using psxtract but then extract the IMG/BIN files using a different tool?
In the pop-fe repository there is a popstarter.py tool that can dissect an EBOOT.PBP and extract (among other things) all the IMG files it contains.
 
Have you tried to just decrypt the EBOOT.PBP using psxtract but then extract the IMG/BIN files using a different tool?
In the pop-fe repository there is a popstarter.py tool that can dissect an EBOOT.PBP and extract (among other things) all the IMG files it contains.
I haven't yet, i wasnt even aware of that, what commands do i use in "popstation.py" to convert the extracted DATA.PSAR into IMG/BIN files ?
 
I did a quick test on Vagrant Story SLES-02754 that is libcrypt enabled.
Building an EBOOT and running it on a PSP boots the game, plays the intro movie and brings up the start menu.
After selecting NEW GAME libcrypt kicks in and the game just hangs with a "now loading" screen.

Downloading and extracting this zip file:
https://dl.consolecopyworld.com/dl.php?c=psx&f=pdx-vsuk!zip
which contains the ppf file for the game pdx-vsuk.ppf

$ md5sum pdx-vsuk.ppf
294324e7142573df9eee82cfe5220b59 pdx-vsuk.ppf

This is a PPF2 file and after applying this this patch to the .bin and building a new EBOOT.PBP
the game now works and starts.
Unfortunately this PPF also adds an annoying intro-screen immediately after the game has booted with annoying music but it goes away once you click X. the important part is that the patch works and the game boots.
I added an entry in the PS1 Custom Patches with your report :encouragement:
By now im not sure the best way to do it, so for simplification purposes is just a short description in a single line for every patch, this way we can add other lines later for alternative patches and comment them

By now the main goal is to have at least one valid patch for each libcrypt protected disc, incase there are several valid patches the lighter in size is the winner imo
For the matter of giving credits to the people that made the original patch... lets say... if the original patch was 300kb and someone "trims" it down to 50kb by keeping only the libcrypt code of the original we can add a comment in it like "this patch is inspired in the paradox libcrypt patch"
By default your tool should use the lighter in size (in other words, the less invasive the better to preserve the original game as most as posible, there are many emulation purists over there :D) but you could allow the user to select the others
Im not sure if the PAL/NTSC selectors are much handy though, as far i know this is managed by cobra/mamba in a previous loading stage
 
I haven't yet, i wasnt even aware of that, what commands do i use in "popstation.py" to convert the extracted DATA.PSAR into IMG/BIN files ?
./popstation.py dump_pbp eboot.pbp

It creates the files in the local directory. It was never really intended for anything else than as a debugging tool when I developed pop-fe
to be able to extract and compare the various section from genuine EBOOTS with the ones I generate to find out why my EBOOTS didn't work :)
 
Last edited:
I added an entry in the PS1 Custom Patches with your report :encouragement:
By now im not sure the best way to do it, so for simplification purposes is just a short description in a single line for every patch, this way we can add other lines later for alternative patches and comment them

By now the main goal is to have at least one valid patch for each libcrypt protected disc, incase there are several valid patches the lighter in size is the winner imo
For the matter of giving credits to the people that made the original patch... lets say... if the original patch was 300kb and someone "trims" it down to 50kb by keeping only the libcrypt code of the original we can add a comment in it like "this patch is inspired in the paradox libcrypt patch"
By default your tool should use the lighter in size (in other words, the less invasive the better to preserve the original game as most as posible, there are many emulation purists over there :D) but you could allow the user to select the others
Im not sure if the PAL/NTSC selectors are much handy though, as far i know this is managed by cobra/mamba in a previous loading stage

Nice. It would look better as a table than as a list I think but that is just cosmetics. We should get all the information in there first before we worry about cosmetics.
 
Nice. It would look better as a table than as a list I think but that is just cosmetics. We should get all the information in there first before we worry about cosmetics.
The idea is to add a "tag" for each game at the most right column of the PS1 Classics Emulator Compatibility List, by now only vagrant story have it because i added it today (it was ready time ago, but is the first time i use it), it have a tiny red icon with a shield + tooltip description + if you click in it is a link to the PS1 Custom Patches page where there is a lot more room to organize the patches, identify them by filename, size, MD5, to indicate if they "adds" something, it also allows to list the incompatible patches (just to advise people to dont use them)
And if some people like solomonbyte gets involved eventually it would allow to add the "trimmed" patches
I been re-reading this thread right now and as far i understood there are some libcrypt games using simple implementations and he was able to understand and replicate them (wip3out, and 4 or 5 more games)

Being positive... we should think in the complete collection as 65 games (instead of 229) because a lot of them are the same game published by different regions (some games are repeated up to 7 times)
 
you want me to do some clean ppf for the wiki ? about 160 bytes each.

with a signature like from psx-place community to old 68k boys dickheads,

pretty sure they'll appreciate :chewie:
 
Last edited:
./popstation.py dump_pbp eboot.pbp

It creates the files in the local directory. It was never really intended for anything else than as a debugging tool when I developed pop-fe
to be able to extract and compare the various section from genuine EBOOTS with the ones I generate to find out why my EBOOTS didn't work :)
Tried it on the eboot.pbp and it fails since original eboots are encrypted, tried it on the data.psar that psxtract extracts and still fails so i guess that tool is only for homemode eboot.pbp and not official ones but it was worth a try
 
Small pack of untested LC patches for disc images...

edit1: swapped Wip3out (Europe) (En,Fr,De,Es,It).ppf
edit2: fixed Parasite Eve II (France) (Disc 2).ppf
edit3: fixed Galerians (France) (Disc 1).ppf and Galerians (France) (Disc 3).ppf
 

Attachments

Last edited:
i wanted to upload the 18 i made and verified but i think i just gonna F%$# off for the moment :-p

de fr à fr ( merci pour l'upload. faudra que tu m'expliques 2-3 trucs un jour pour que je devienne moins con sur la méthode pour les faire )

i'll check em with time. for now 1 is already bad, wipeout 3. size wise file is empty.
 

Attachments

Last edited:
OK made a small discovery, after Berion mentioned CTR EU was also a clean image i decided to buy it and started testing on it, Official version works but if i extract the ISO with psxtract and make a custom one it still fails, so next step was to grab and drop the official eboot.pbp onto the "make_psone_classic_metadata.exe" to make a custom ps1 classic with the official eboot, and libcrypt still activates.

so what this probably means is its NOT in the eboot but in the ISO.BIN.EDAT since a custom version crashed on libcrypt but the official one doesn't, so now we have it narrowed down to 1 much smaller file, i compared the official ISO.BIN.EDAT to the one made by the
"make_psone_classic_metadata.exe" and there are not many changes so the answer is probably here, im attaching a picture of the changes, Official on the left, custom on the right. @bguerville @Berion or any other Dev, i don't know how to edit the ISO.BIN (i can unpack it but if i hex edit it, it fails to start so im guessing a checksum ?)
DIFFERENCES.jpg
 
@krHACKen,

after the typical magic word, what is so big you have to replace after ? my curiosity is on fire.

i barely get my hand on IDA and diaphora can't find any difference on the both version when i compare to my own patch.
the tool must be broken, i should search another one, so, i'm asking you.
 

Attachments

  • Annotation 2021-12-12 153601.jpg
    Annotation 2021-12-12 153601.jpg
    206.7 KB · Views: 44
  • Annotation 2021-12-12 153601-2.jpg
    Annotation 2021-12-12 153601-2.jpg
    266.7 KB · Views: 47
Small pack of untested LC patches for disc images...

edit1: swapped Wip3out (Europe) (En,Fr,De,Es,It).ppf

Nice job. The pack does include patches for the games known to be unfixed for a long time - Spyro 3 and Lucky Luke: Western Fever. I think the last game still uncracked properly is Sydney 2000 UK for which the PDX released a broken patch, maybe intentionally (validation routine left during the loading of an event).
 
Nice job. The pack does include patches for the games known to be unfixed for a long time - Spyro 3 and Lucky Luke: Western Fever. I think the last game still uncracked properly is Sydney 2000 UK for which the PDX released a broken patch, maybe intentionally (validation routine left during the loading of an event).
I think all of these games have been patched by @krHACKen in POPStarter for years now, including Sydney 2000. Not sure if it's a full fix, though.
 

Similar threads

Back
Top