PS3 PS1 libcrypt support on PS3 official emus - research thread

In other words, correct me if I am wrong, with a few changes in the Cobra source, it would be perfectly feasible, easy even, to add subchannel data on the fly.

If so, only one question remains..
Does the emu itself handle that subchannel data?
Has someone tried running the emu with an official libcrypt protected CD in the BD drive? Does it work??

If the emu doesn't support the subchannel data, then it would be game over, too complicated to research then patch the emu to hook some of its functions when you have an alternative like ripping the discs with libcrypt & removing the protection altogether.

Yes it is feasible. As the payload size is limited to only 127KB, if the size of the code is too large, it may require to implement it in rawseciso or in ps3netsrv.

Maybe the emulator handles the subchannel data. However, I don't know if the subcode can be sent to the emulator process, since the current code in storage_ext.c only sends the user data (2352 bytes or 2048 bytes).

I think the ppf patch is an easier route.

Here are some links about the subject
https://consolecopyworld.com/psx/psx_protected_games.shtml
https://consolecopyworld.com/psx/psx_libcrypt_tutorial.shtml

EDIT:
I was wrong. storage_ext.c has a section that calculates the subchannelQ.

I managed to override the data sent with the subchannel data obtained from a LSD file. Now the LibCrypt protected games are playable reading the subchannel data from an external file without having to use ppf patches.
 
Last edited:
Yes it is feasible. As the payload size is limited to only 127KB, if the size of the code is too large, it may require to implement it in rawseciso or in ps3netsrv.

Maybe the emulator handles the subchannel data. However, I don't know if the subcode can be sent to the emulator process, since the current code in storage_ext.c only sends the user data (2352 bytes or 2048 bytes).

I think the ppf patch is an easier route.

Here are some links about the subject
https://consolecopyworld.com/psx/psx_protected_games.shtml
https://consolecopyworld.com/psx/psx_libcrypt_tutorial.shtml
Agreed. ;-)

As of now, the only serious question mark that still remains is the 2 ps1 emus' libcrypt native support level.

If it's supported then we can investigate whether or not the storage_ext.c code can actually send it to the emu process without modifying the emus, it would be the last possible hurdle on the way.
 
well im using Final Fantasy VIII SLES-02080 and it plays fine for CD1-3 but CD4 has never worked on PS3 (for anyone, i started a thread on gamefaqs a lot of years ago and it seems to be a common problem) so i ended up buying digital so i could play CD4,
And thats also assuming the libcrypt list is correct, is there anyway to actually check this ?

EDIT: Ok found my original discs and inserted them into my PS3 and its refusing to load now, over 10 years ago these worked fine, a change in the ps3 ps1 emulator ?

Yeah, the FFVIII PAL releases have got the LC included. I don't remember where the protection check kicks in, but I think early enough to see. It's interesting why the CD4 is not being verified by PS3. But you can always force start the emulator on the CFW I think.

Maybe the emulator handles the subchannel data. However, I don't know if the subcode can be sent to the emulator process, since the current code in storage_ext.c only sends the user data (2352 bytes or 2048 bytes).

The emulator has to support the subchannels, because they are a part of the Red Book. And a lot of games have got the audio tracks included in the mixed mode discs. Libcrypt abuses the Q subchannel only, so there is no need for full subchannel support for emulation.

At least the ps1_emu has to, I am not sure about the ps1_netemu. And yes, in general only few games do not have a working LC patch, at least I do not know about such one (Spyro 3, Sydney 2000 UK, Lucky Luke: Western Fever). Some old patches could be available in the different format than PPF, with the patcher not compatible with the 64-bit systems, though.
 
Last edited:
Yeah, the FFVIII PAL releases have got the LC included.
...
The emulator has to support the subchannels, because they are a part of the Red Book. And a lot of games have got the audio tracks included in the mixed mode discs. Libcrypt abuses the Q subchannel only, so there is no need for full subchannel support for emulation.
...
At least the ps1_emu has to, I am not sure about the ps1_netemu
...
Well, if all these affirmations are true, libcrypt support should not be very difficult to add, to ps1_emu at least.
 
@aldostools

I just had a quick look at storage_ext.c (in the latest HEN source actually but Cobra/Mamba should be the same), it looks like the process_cd_iso_scsi_cmd function code used in SCSI_CMD_READ_CD already adds subchannel Q data when the scsi command specifies it.

So at first glance I see no reason why we could not substitute insert/add externally provided libcrypt data in the same way..
What do you think?

Btw in that same project where I found that sub.c source, there is also source code for ppf handling. I dunno if you or Zar have looked at that stuff before.
 
Last edited:
what amount of work does that represent to you guys ?
No idea yet.

For the moment we are trying to establish the feasibility, nothing more, we don't even know for sure the level of native support in the 2 ps1 emus, even if ps1_emu has been reported to support a libcrypt protected title, it seems the most recent attempt to run it failed & we don't really have a clue about netemu at all.

If they are both ready to consume the libcrypt data then it should only be a matter of integrating the sub.c & sub.h files I linked before into the Cobra/Mamba stage2 source code & adding some code into storage_ext.c to insert libcrypt data to scsi output on the fly.
It could also require minor changes in the scsi commands used in backup manager code, I am not sure.

So if all the assumptions are true, unless there are unforeseen hurdles on the way, it may take a few hours work, coding & testing, maybe.. But that's an optimistic forecast.
 
Last edited:
@aldostools

I just had a quick look at storage_ext.c (in the latest HEN source actually but Cobra/Mamba should be the same), it looks like the process_cd_iso_scsi_cmd function code used in SCSI_CMD_READ_CD already adds subchannel Q data when the scsi command specifies it.

So at first glance I see no reason why we could not substitute insert/add externally provided libcrypt data in the same way..
What do you think?

Btw in that same project where I found that sub.c source, there is also source code for ppf handling. I dunno if you or Zar have looked at that stuff before.

I seems a PoC is needed to check if worth continuing the idea or not. What you say sounds feasible.

Currently I'm very busy with the work's projects. I could help but from back seat.
 
I seems a PoC is needed to check if worth continuing the idea or not. What you say sounds feasible.

Currently I'm very busy with the work's projects. I could help but from back seat.
Let's bring @Zar into this conversation too, I vaguely recall that he discussed this problem for his MGZ at some point, he may have some feedback & be interested in adding the feature.

I am willing to help from a backseat too but I don't exactly have time to take on this project either tbph. I have more than enough already on my plate with the PS3 Toolset update I am working on & in coming weeks whenever esc0rtd3w is available again there will be the HEN installer release to take care of too.

It like I keep saying, there is not enough devs...
 
Last edited:
just tried to put a subchannel inside a chd, no way. chd does not support subchannel.

what i find weird, sbitool can regenerate subchannel and get a ccd img sub, but any emulator you load with ccd will freeze whuile the subchannel is available.

duckstation already gamedatase refuse to run without the sbi file implemanted function, beetle and no$psx trigger protection. the file format is badly implemented or i missed something ?

it doesnt make sense, at least no$psx should not trigger LC with sbitools making ccd file:

https://red-j.github.io/Libcrypt-PS1-Protection-bible/index.htm

-----------

edit :

just understood the stupidity of mine, not indicating lsd/sbi to sbitools.exe will display batch off adding gap, not patching the sub files. i didnt notice.

and indicating lsd location file after cue location not patching neither, lsd/sbi MUST be same folder than cue/bin file to generate proper ccd/sub , then any emulator runs normally like genuine 1:1

my 2 cent. everybody else already know:very drunk:
 
Last edited:
how do PS1 Classics handle libcrypt ? i originally assumed they patched the games image but today i extracted the eboot.pbp from the ps1 classic on my console and decrypted it with psxtract and the ISO it produces is nearly identical a image i also made today using CloneCDv3 trial from my original disc1, i compared in HxD and they are the same up until the last 24C0 (hex) bytes where its cut off (after looking in psxtract's folder the end seems to be in the JUNK files), the the actual game data is 1=1
 
i finally learned to crack libcrypt.

something i do not understand is why when i open the original bin/cue with power iso or magic iso to change the psx exe then i resave or with new name elsewhere, the image disk do not work anywhere. i must use cdmage , import the modded file, no advertising of any same name existing, and then save elsewhere and the newly created bin/cue is modded and ready to go.

what is wrong with magic iso & other tools ?
 
i finally learned to crack libcrypt.

something i do not understand is why when i open the original bin/cue with power iso or magic iso to change the psx exe then i resave or with new name elsewhere, the image disk do not work anywhere. i must use cdmage , import the modded file, no advertising of any same name existing, and then save elsewhere and the newly created bin/cue is modded and ready to go.

what is wrong with magic iso & other tools ?

Many of them are nice tools but unfortunately their respective devs either didn't implement ISO standards according to full specs or simply failed or refused to implement all necessary features of an image manager.

You would expect a decent optical disc image manager to be able to reproduce all data that is reproducible by software (obviously it cannot do miracles if something cannot be reproduced or if there is no standard to make it so) & it should support all possible disc formats even when those don't respect standards.

Then again for everything that's freeware or open source, it is also up to others to improve things, the responsibility is not just on devs who do what they can when they can. For commercial software, it's quite unacceptable however.
For disc image makers & our libcrypt topic in particular, maybe some devs wanted to avoid the piracy issue altogether, I am not sure but that may have played a role.

In my own experience, I believe this specs issue to be true for some disc image making tools but also just as true for many other software implementing iso standards, from http/ftp protocols to USB, WiFi etc...
To this day, in 30+ years, since before Windows 95, I cannot recall ever using a FTP connection without some sort of glitch, depending on the client/server association, sometimes minor but still a glitch.

Look at the browser cross compatibility conundrum, that's the perfect example of the consequences of a "flexible approach" when it comes to implementing standards, there are compatibility issues at all levels, from html tags to javascript & even css, and worse yet, the compatibility issues vary also from one version of each browser to the next..
Total headf#ck, you would have wanted to make web programming pointlessly complicated & to push people into having to resort to using 3rd party runtime platforms, you would probably have chosen this way of doing things.. LOL
 
Last edited:
It is not a PC software issue. Many PS1 and PS2 games expect the files to be in a particular order on the disc. Breaking it will make such game crash.
 
It is not a PC software issue. Many PS1 and PS2 games expect the files to be in a particular order on the disc. Breaking it will make such game crash.
Maybe I misunderstand the question, I was under the impression that he wanted to know why there are differences in outcome when using different apps, why you should use one app & not another to get a valid image or burnt disc etc..
In which case the problem is software based.
For the rest, it is another matter..
 
while i am in the processing of learning some stuff, i managed to do this to go faster on sector comparing to get the magix word of libcrypt.

( the goal is to patch them by myself, )

i copy past redump libcrypt sectors and the sheet tells me if one of the pair is present, then i report on side, sheet does auto merge & auto hex conversion, just have to paste special cause formula doesn't work on 8+ bytes and not converting from cell address.

shitty, but it works.

i would love to make a drag an drop or databased sbi/lsd file on a small windows gui box that would just write the magic number to put in the 25 30 86 00 C6 34 zone, with eventually another drag n drop on psx.exe to do it automatically or even better a full auto patcher.

what language i can learn that would make this possible, ? string manipulation, windows GUI, drag n drop, with relative ease ?

( i understand how coding works, i made some arduino projects i globally understand declarations, variable , etc )

i know libcrypt magic word finder program already exists but i don't like it.

i have found a fun way to finally start to code with relatively ambitious program that will make all the basic function i need for futur stuff :)
 

Attachments

  • excel magic word libcrypt.jpg
    excel magic word libcrypt.jpg
    466.5 KB · Views: 62
Last edited:

Similar threads

Back
Top