PS3 PS1 libcrypt support on PS3 official emus - research thread

that's what i am lookin it at before mister lifeguard put back my head under the water like a real...gentleman.

i extracted ff9 psn EU version and the bin behave like normal LC game on emu. i patched the bin with what i learnt and indeed game protection removed and game start.

so the bypass occur on ps3. and the time ps3 take to validate the protection check is kinda long, like 5,6 seconds
 
the iso of FF9 (without the patch) isn't working (when you mount it with cobra) ? Can you give me the game ID ?

so, we may have an answer inside the pkg. ¨Perhaps if we RE the EBOOT ? it may be an unknown argument... There is a list a ID with flags inside the emu : https://www.psdevwiki.com/ps3/PS1_Emulation it may be related to libcrypt...
 
SLES02965 = FF9 UE ( english )

i just swapped the installed 1.5gb EBOOT.PBP from psn english version with homemade french version ( no compression ) 2.7gb, when i launch from xmb i got 08828f17 error.

i'll redo homemade pbp with different game id to see how console behave.

edit for cobra test :
as expected, bin-cue exctracted from psn version not boot after psx logo on ps3, the LC protection trigger. the disc image are really genuine.

edit 2:
permutating EBOOT.PBP from retroarch/beetle, since it handles pbp format, with homemade eboot.pbp file, game works fine, on the other side, psn version is not recognized.

are we sure something is not forgotten on the pbp decompression stage ?

and why ISO.BIN.EDAT is 4mb ?

RPCS3 with evilnat firmware, installing psn ff9 pkg, launching game, stuck blackscreen after PS logo, just like LC triggered does on this game.
 
Last edited:
I have tested the Classics unpacked FF8 UK image by psxtract. But the classic ID should not be crucial when it comes to trigger the patch eventually. Because the single NPEF00070 ID is valid for many language versions and each version has got a different Magic Word key. Even the ID inside the PARAM.SFO file does match the regular SLES title ID, not the store one.

It would be good to pack the CD1 properly into the PBP container, make a proper Classics package with the title ID specified and test without any Cobra involvement.
 
Last edited:
  • Like
Reactions: Zar
At this stage what we need are specific answers regarding libcrypt support in each official ps1 emu, including the classics format.

To avoid user error as well as potential confusion over image validity and/or doubts over the validity of performed tests, testers should probably favour using a retail libcrypt protected ps1 disc if they can rather than a disc image & generally speaking when testing things, Cobra/Mamba should be kept disabled by default unless the test absolutely requires it.

If libcrypt turns out not to be supported by any official ps1 emulation software, there will be little point spending much more time on this research, adding libcrypt support would be much more complicated, research & development would require a developer with good hacking skills & I am guessing that ultimately no scene dev will want to take that kind of project on.

However if libcrypt cannot be easily supported, we may consider the next best thing ie implementing runtime ppf patching, luckily enough the C code to add ppf support looks basically ready to deploy too.
 
Last edited:
bguerville said:
@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.
Click to expand...

I won't have any time to look at or help with this in the near future but I did significant amount of SCSI work in the past (STGT target and libiscsi inititor).
The READ CD command is part of the MMC standard (multi media commandset) and you can goolge for and find copies with this filename : mmc6r02g.pdf
READ CD is covered in section 6.19

You can likely not add the subchannel unconditionally because if the command is to read multiple lbas then you need to know whether or not the application asked for subchannel or not, and which type of subchannel data becasue this is added at the end of the data for each lba and if you add too much/too little then it messes up the offset where the next lba will be in the read buffer.

The type of subchannel is specified as the three bits of subchannel-selection-bits in byte 10 of the cbd.
A good start is likely to log what these bits are in cobra when you play a libcrypt game, especially if / when they are not 000.
I bet that most/all the time libcrypt would use 100 == Corrected and de-interleaved R-W sub-channel data shall be
transferred, which is 96 bytes in size.

Just knowing WHICH types of subchannel queries are made from libcrypt means you will only need to implement handling of those types and not all types, saving some work.



But spontaneous. If you already have a fucntion SCSI_CMD_READ_CD that already knows how to deal with those bits, then to me it sounds like it should be very easy to add the support.
 
Devildwarf said:
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
Click to expand...

The EBOOT.PBPs only stores the 2352 byte sectors and there is no way to store the subchannel inside an EBOOT.
So the way the PS1 Classics work is not SBI but PPF.
I.e. PS1 Classics is basically the same as if you patch the game with the PPF, you patch the code to remove the libcrypt checks.

This is the area I am most interested in, I want to create EBOOT.PBP for PSP and PS3 packages and for that use-case I can not use SBI files :-(
But I plan to try to create a curated list of PPF patches and have pop-fe automatically apply a PPF to the libcrypt games when it
detects it is a libcrypt disk. It is better than nothing.


For people that have an emulator that they can modify, SBI would be a completely superior solution because IF you can modify how the SCSI emulation of the READ_CD command work so that it can
1, detect the game-id for the disk and detect if it is one of the 229 libcrypt discs
2, ship the complete set of the 229 SBI files with the emulator
3, modify the READ CD emulation to return the correct SBI data for these disks
Then you have basically solved the libcrypt issue for every single libcrypt game that exists.
 
all single .PKG supposed to be LC protected title that i open on psn have a replaced exe with us/uk non protected version.

the only ones who give a eboot.pbp non booting on retroarch/beetle ( fixed issue, beetle read .pbp who requested scph5501 bios, making my earlier post about compatibility invalid ) is multi discs games ff8 & ff9.

i guess ff8 would be same case, but any single disc known as LC is packed as classic with real exe file ?

-- on the psxtract, what are the junk files at extracting stage ( picture ) ?
 

Attachments

  • ff8 cd1 extraction stage.jpg
    ff8 cd1 extraction stage.jpg
    69.9 KB · Views: 96
Last edited:
Ronnie Sahlberg said:
The EBOOT.PBPs only stores the 2352 byte sectors and there is no way to store the subchannel inside an EBOOT.
So the way the PS1 Classics work is not SBI but PPF.
I.e. PS1 Classics is basically the same as if you patch the game with the PPF, you patch the code to remove the libcrypt checks.
Click to expand...

So there is an additional data meant for patching the image on the fly inside the EBOOT.PBP (or more precisely DATA.PSAR) that emulator, or something else, does apply at some point of the launch process, am I right?
 
solomonbyte said:
all single .PKG supposed to be LC protected title that i open on psn have a replaced exe with us/uk non protected version.

the only ones who give a eboot.pbp non booting on retroarch/beetle ( fixed issue, beetle read .pbp who requested scph5501 bios, making my earlier post about compatibility invalid ) is multi discs games ff8 & ff9.

i guess ff8 would be same case, but any single disc known as LC is packed as classic with real exe file ?

-- on the psxtract, what are the junk files at extracting stage ( picture ) ?
Click to expand...
as i said on Page2 of this talk, Im not sure what all of the Junk data is but some of it is the end of the games ISO's, for example 1 of the JUNK files contains the last 24C0 of CD1 that is missing (well some of it is, the rest im not sure about), im guessing either PSXTRACT is extracting it wrong and cutting the end off or if the official eboot.pbp is doing something different with it, i compared with the original CD (made myself using cloneCD) and they are Identical ISO's apart from the ends of the CD's are cut off from psxtract (so maybe the patch for libcrypt is kept in that junk data) either way its different from a normal eboot.pbp
Also i would like it noted if you make your own ISO.BIN.EDAT from the official eboot.pbp it will also be 4mb but it will fail to work, in the official ISO.BIN.EDAT also had extra data at the end of it compared to a homemade one so maybe its also checking other things (or patching)
 
Last edited:
Isn't Sony emulators patching Libcrypt on the fly? Extracted Crash Team Racing from PAL (which in 100% using Libcrypt) from original PKG is the same as ReDump dump, and inside EBOOT.PBP or PSAR there is no place for sub-channels (and data outside is only for PS3, while PSP using only this + keys).
 
Berion said:
Isn't Sony emulators patching Libcrypt on the fly? Extracted Crash Team Racing from PAL (which in 100% using Libcrypt) from original PKG is the same as ReDump dump, and inside EBOOT.PBP or PSAR there is no place for sub-channels (and data outside is only for PS3, while PSP using only this + keys).
Click to expand...
possibly but if you make a homebrew PS1 classic from the FF8 images it just black screens after the Europe logo, so im guessing there is something in the eboot.pbp or ISO.BIN.EDAT that either patches or decides the game needs patching since the game themselfs still have libcrypt.
EDIT: Berion maybe try making a PSone Classic from the extracted game and see if it works (doesn't work with ff8 but might for others)
 
I'm trying to jailbreak my ps3 but I have to do a hard reboot and my left USB port is not working. Is there any way around this problem over then a new port?
 
It has to be SLES one, like in the official packages. But it looks like there is no automatic way to overcome the protection. A PPF patch is still the only option as of now.
 
Agrippa said:
It has to be SLES one, like in the official packages. But it looks like there is no automatic way to overcome the protection. A PPF patch is still the only option as of now.
Click to expand...
ah ok i was already trying the SLES one since that was the ID of the game i just kept it, also found i can test PS1 classics on RPCS3 which will help speed things up
 
You must log in or register to reply here.

Similar threads

Back
Top