PS3 PS1 libcrypt support on PS3 official emus - research thread

the only game to be tested on rpcs3 is crash ctr.

install pkg, it will run, no freeze.

put exctracted eboot.pbp or BINCUE on retroarch = freeze.

the procedure to trigger LC on this game is ENGLISH > ADVENTURE > NEW > default crash toon selection > any name > with or without save game , whatever, on game, when the tablet mask has spoken, just go straight with X button to "crash cove" race. the 2nd loading will freeze.

PKG FF games not load on any support excepted reel ps3
 
I compared CD2+3 and they are perfect 1=1 copies of the original CD's (nothing patched at all), but CD4 is idential until 281F687 then changes happen so they left CD2+3 alone but modified CD4 and if PSXTRACT is correct they cut the end of CD1 off, its really weird.

Also at @solomonbyte they do work on RPCS3 but you need to switch ps1_netemu to ps1_newemu then it will load. (well the offfical ff8 package does)
in
dev_flash\ps1emu
 
Last edited:
also new find, been going back through old firmware and just found a old version of ps1_netemu.self that has a line in it saying
libcrypt_key=%08x
this is in the 1.93 firmware's version of the file, i havent finished looking through every version of firmware yet i was just poking around randomly (checked every firmware from 3.55-4.60 so far and nothing like that so i decided to randomly pick a few older firmwares to check)
But this could mean that 1.93 had libcrypt support on ps1_netemu.self
 
If you guys want to experiment reading the subchannel off disks I have added a branch 'read_cd' to:
https://github.com/sahlberg/python-scsi Use the branch read_cd

It implements the READ_CD command and has an example utility you can use to read various things including the subchannel.
Example to read both the SYNC 12 bytes as well as 'Formatted Q sub-channel' :

$ PYTHONPATH=. python examples/read_cd.py /dev/sr0 -lba 0x0 -tl 0x8 -est 3 -mcsb 0x10 -scsb 0x02
LBA 0
SYNC 00ffffffffffffffffffff00
SUB-CHANNEL 4101000000000000017404a100000080
LBA 1
SYNC 00ffffffffffffffffffff00
SUB-CHANNEL 41010100000000000200283200000080
LBA 2
SYNC 00ffffffffffffffffffff00
SUB-CHANNEL 41010100000100000201924200000000
LBA 3
SYNC 00ffffffffffffffffffff00
SUB-CHANNEL 410101000002000002024cf300000000
LBA 4
SYNC 00ffffffffffffffffffff00
SUB-CHANNEL 41010100000300000203f68300000000
LBA 5
SYNC 00ffffffffffffffffffff00
SUB-CHANNEL 41010100000400000204e1b000000000
LBA 6
SYNC 00ffffffffffffffffffff00
SUB-CHANNEL 410101000005000002055bc000000000
LBA 7
SYNC 00ffffffffffffffffffff00
SUB-CHANNEL 41010100000600000206857100000000

It is in python so it should be very easy to tweak and modify for various types of tests you might want to do.
Note, as always for SCSI devices, many devices have very incomplete firmware where uncommon features are either not implemented
or just return bad data. For example on my laptops dvd drive I can read subchannel type 2 just fine but if I try to read
subchannel type 4 then the drive just returns noting, not an error but just nothing. YMMV

EDIT: usually, for consumer SCSI devices, in my experience, IF the feature or command is used by basic windows/linux itself then it is expected to be implemented and work as the standard specifies. If it is things that is NOT used in day-to-day operations from windows/linux then it is very much a matter of YMMV. It is mostly due to a lack of industry wide testing tools, but with my libiscsi-test-tool that validates scsi standard compliance things are much better nowadays than a decade ago when it comes to normal block devices (SBC commandset: scsi disks or usb memory sticks)((even seagate/wd and sandisk now use my test/compliance tool in production nowadays and it has REALLY made a difference. I do not yet have any tests for MMC (cd/dve/bd) devices so maybe I should expand the test tool to also cover the MMC standard. ) Oh man. I have to do this and add MMC compliance tests. As if I don't have too much on my plate already.


See the MMC standard I mentioned earlier for explanation of what all these arguments mean.
 
Last edited:
after checking through a LOT of firmwares i found
libcrypt_key=%08x
only appears in 2 firmware versions
1.92 and 1.93
i checked all the others around it and nothing
(checked OFW
1.02
1.80-1.90
2.00-2.10
3.55
3.73-4.55
and those don't have it)
So ps1_netemu.self may have a argument for libcrypt (or had), not sure if this is helpful @bguerville but i thought it was interesting
 
Devildwarf said:
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)
Click to expand...

FF8 is a 4 disc game and most tools fail in various interesting ways to create EBOOT.PBP and/or PS3 PKGs that big.
Can you try to re-build the EBOOT.PBP using pop-fe.py instead? That tool does handle large EBOOTS correctly.
 
Ronnie Sahlberg said:
FF8 is a 4 disc game and most tools fail in various interesting ways to create EBOOT.PBP and/or PS3 PKGs that big.
Can you try to re-build the EBOOT.PBP using pop-fe.py instead? That tool does handle large EBOOTS correctly.
Click to expand...
already made it with pop-fe.py (although for some reason even though it all went through successfully it made the pkg but i think it deleted it too when cleaning up, so i ran it a 2nd time and closed it when it started making the PKG and just made the PKG myself), it generates a eboot.pbp but still won't go past Europe PS logo, they really must have added some stuff into these official eboot.pbp
 
Devildwarf said:
already made it with pop-fe.py (although for some reason even though it all went through successfully it made the pkg but i think it deleted it too when cleaning up, so i ran it a 2nd time and closed it when it started making the PKG and just made the PKG myself), it generates a eboot.pbp but still won't go past Europe PS logo, they really must have added some stuff into these official eboot.pbp
Click to expand...

Very interesting. That suggests that the original PKG contains the subchannel data. I guess either in the EBOOT.PBP in some unknown place or in some other file that is part of the PKG.
Have you checked if any of the files in the original package contains anything that resembles the subchannel data?
Either sequences of bytes from the SBI file (which contains both file metadata as well as the subchannel data itself)
or the strings of subchannel data that are reported at http://redump.org/disc/866/ , for example this sequence:
41 01 01 03 06 11 00 03 88 10 6c e8


(there is also a possibility that they have something that patches the binary on the fly, akin to patching with PPF, but what would the point of that be? It would have been much easier to have just patched the binary BEFORE they build the eboot/pkg anyway than patch it on the fly when it is loaded.)
 
Ronnie Sahlberg said:
Very interesting. That suggests that the original PKG contains the subchannel data. I guess either in the EBOOT.PBP in some unknown place or in some other file that is part of the PKG.
Have you checked if any of the files in the original package contains anything that resembles the subchannel data?
Either sequences of bytes from the SBI file (which contains both file metadata as well as the subchannel data itself)
or the strings of subchannel data that are reported at http://redump.org/disc/866/ , for example this sequence:
41 01 01 03 06 11 00 03 88 10 6c e8


(there is also a possibility that they have something that patches the binary on the fly, akin to patching with PPF, but what would the point of that be? It would have been much easier to have just patched the binary BEFORE they build the eboot/pkg anyway than patch it on the fly when it is loaded.)
Click to expand...


Anyway, I wont have time to spend on this until Jan, at the earliest, but then I want to have pop-fe either:
* warn: this is a libcrypt disc, have you pathched it?
or,
* if PPF is availble for the disc, automatically apply the patch while building the EBOOT.

The only issue for me is to create a curated list of PPF-that-disables-libcrypt-but-no-other-bs
Curating this list will be timeconsuming but as there are only 229 disks it is not impossible
 
Ronnie Sahlberg said:
Very interesting. That suggests that the original PKG contains the subchannel data. I guess either in the EBOOT.PBP in some unknown place or in some other file that is part of the PKG.
Have you checked if any of the files in the original package contains anything that resembles the subchannel data?
Either sequences of bytes from the SBI file (which contains both file metadata as well as the subchannel data itself)
or the strings of subchannel data that are reported at http://redump.org/disc/866/ , for example this sequence:
41 01 01 03 06 11 00 03 88 10 6c e8


(there is also a possibility that they have something that patches the binary on the fly, akin to patching with PPF, but what would the point of that be? It would have been much easier to have just patched the binary BEFORE they build the eboot/pkg anyway than patch it on the fly when it is loaded.)
Click to expand...
well i did a search through the files extracted from PSXTRACT and those bytes didn't show up so i tried narrowing it down even more to 41 01 01 and still nothing, so the subchannel data is missing (or psxtract can't extract it but seems unlikley) so im guessing it has a on the fly patch or maybe there is a switch/flag that gets set to disable libcrypt (since we have no idea how actual official PS1 classics are made)
At first i thought the patch could be in ISO.BIN.EDAT since it also has extra data at the end but then i thought "since it works on PSP that can't be it" so there must be something in the eboot.pbp
 
is it possible to verify what Mister T wrote on 1999 on a ps3 or rpcs 3 with ff8 PSN when he explains what he did to crack it on console ? not has same process, because extracted bin-cue are clean, but in the behavior of the executed program ? should be similar hack, if so could you locate source of the modification ??

My solution was as follows: Attach a "waiting" piece of code to the part of the EXE that decompresses the protection code. As soon as the decompression code decompressses copy protection code, my program kicks in and hacks it. However, this solution adds a new problem: how to add in this code. There is simply no space in the EXE to add code, as the 00'd areas in the EXE get overwritten and the code needs to stay. I ended up choosing the reserved RAM area at 8000F800 as the place for my code, which caused yet another problem: how to get code into 8000F800. The PSX EXE format does not allow for using 8000F800 simply by loading an EXE. In order to fix this, my final solution was made:
  1. Take over the start of FF8. This allows me to have my code execute before FF8 even starts.
  2. In the code that starts before FF8, copy the "attachment" to the decompression code I described before into 8000F800.
  3. Patch the decompression code to call 8000F800 every byte that is decompressed (slow, but only adds 1 second to load time).
  4. Start FF8.
  5. When the copy protection code is decompressed, first make sure that it is the right code that is being modified. (This occurs in 8000F800).
  6. If so, write 0x10000046 to 0x8009B2E0 (as shown in the GS code).
  7. Resume normal FF8 operation.
I hope this clears up the many misconceptions about FF8.

Mr. T
Author
Click to expand...
 
solomonbyte said:
is it possible to verify what Mister T wrote on 1999 on a ps3 or rpcs 3 with ff8 PSN when he explains what he did to crack it on console ? not has same process, because extracted bin-cue are clean, but in the behavior of the executed program ? should be similar hack, if so could you locate source of the modification ??
Click to expand...
well he is cracking the US versions Anti Modchip protection and not the UK libcrypt version so im not sure how useful that info is
 
LibCrypt is composed of two separate routines:

the first one performs a control check on the disk to discover if it is a copy, the second, based on the result of the first one, decrypts a block of data and crashes the PSX in the case of an incorrect result. Although based on the same code, the two routines have been altered a few times, to the point that in the last evolution (LC3) they have very little in common with the initial basic code.

The second routine, that that checks the presence of the MagicWord in the BPC, is implemented in different ways in the various games that use it: some perform the check immediately (FF8 for example), others wait until a certain level (Spyro2), others perform the check cyclically during some CD loading (SoulReaver). Or at specific moments (Mulan).
Click to expand...

to me he says sub channel checks are immediately done after mod chip. and this explains why the game without sbi on don't display a single image post PS logo on regular emulator.

am i wrong ?
 
Yes, you are. Libcrypt is a copy protection. Modchip countermeasures were forbidden by the SCEE, so there are no games with antimod protection in the PAL region (it was usually antimod in the US/JAP and LC in the EU region of the same game).
 
Im quoting you from this talk
Ronnie Sahlberg said:
Yes, a list/table like https://www.psdevwiki.com/ps3/PS1_Classics_Emulator_Compatibility_List
but just for the 229 libcrypt games.

And for each one there would be a column with a link to the corresponding SBI file which should be timeconsuming but easy to make as all these SBI files are all readily available.

And an additional column with a hyperlink to where a PPF file can be found. This would be a lot harder to do as these PPF files seems to be spread around many different sites and also they, as you say, come in different formats and we are only interested libcrypt-only PPF files. These links could be added manually one game at a time as people contribute to the effort. I would volunteer to try to add as many such links as my time permits to seek them out.

Having a curated list of these games, the SBI and the PPF to deal with libcrypt at a single central place would be very helpful. Even if the PPF section would be incomplete.
Click to expand...
I made the page in wiki, named PS1 Custom Patches with the list of libcrypt protected games by crosschecking:
https://psxdatacenter.com/sbifiles.html <--- is incomplete
http://redump.org/sbi/psx/ <--- the files doesnt have the TITLE_ID
http://redump.org/discs/libcrypt/2/

And while doing it i was grouping game names, because in total there are 229 discs libcrypt protected, but are only 65 games or so
As example the game "LMA manager 2001" have a name completly different for other regions, what i did was to group all them under page section "LMA manager 2001", so now is a bit more tricky to compare them, but imo is easyer to organize them, is just a matter of renaming them conveniently

Ronnie Sahlberg said:
Anyway, I wont have time to spend on this until Jan, at the earliest, but then I want to have pop-fe either:
* warn: this is a libcrypt disc, have you pathched it?
or,
* if PPF is availble for the disc, automatically apply the patch while building the EBOOT.

The only issue for me is to create a curated list of PPF-that-disables-libcrypt-but-no-other-bs
Curating this list will be timeconsuming but as there are only 229 disks it is not impossible
Click to expand...
The warning should be based in the TITLE_ID, if at some point you make the complete list please check the list in wiki, probably i missed something

I dont know about the PPF patches required for each game, if are incompatibles or even if are availables, by now i dont have the intention to add that links to PPF files in the wiki page because i cant verify them
If someone knows about an specific PPF patch tell me, or edit wiki to add it, we mostly need:
-link to the PPF file
-MD5 of the PPF file
-A description of his compatibility, either a "yes" or "no"

By now i think that kind of short description is good enought, the page have room to discuss every patch in detail though, in long term the page can be expanded a lot using an style similar than PS2 Custom Configs where the reader can "download" the config by copypasting, and there are technical descriptions about what the config/patch does

Eventually the skills learnt by @solomonbyte in the last weeks could help with that, most probably is going to be needed to "trim" some of the popular PPF patches (the first one that comes to mind is soul reaver)
This procedure could be a pain, but theoretically is something relatively easy because the only thing we need to do is to reduce the amount of patched data... lets say, if the original PPF was patching 50 things we need to reduce them to the point where the emulator accepts the game
 
1. It is not easy to just trim the changes made by the patches. They often included a crack intro. The data needed to be packed/manipulated inside the main executable.
2. The patch needs to be robust. While I appreciate @solomonbyte job, many games included more sophisticated anti-tamper protections. All the protection patches are available at the consolecopyworld. We know that 95% of them do the job fine, so they are tested and working 100%.
3. Unfortunately, patches made before the PPF format started to be an "industry standard" are often a DOS programs, totally incompatible with the current 64-bit operating systems.
4. A lot of people dislike the cracktros, forgetting the groups spent their spare time and knowledge to provide the best patch available. They had the right to do everything they wanted with the release. Removing the intros is just a lack of any respect towards them.
 
1. Removing patches from a single PPF file is always easyer than adding them, for someone that doesnt knows anything about how the patches are working is very hard because is not posible to follow any pattern to identify the ones that can be removed, but for someone like solomonbyte that started understanding them maybe there is some pattern that he could use to identify which data is intended to defeat a libcrypt protection code from the other patches "not required"
2. Where you took that 95% ?
3. is always posible to "port" patches in between formats, just by applying it with the original tool, then use a different tool to generate the new patch by doing a comparison in between "source" and "target" files, xdelta does this very well
4. Is not a matter of respect, we need to minimize the patched data to only patch the functions that triggers the libcrypt code and remove the other that "breaks" the emulator
 
Last edited:
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
 
You must log in or register to reply here.

Similar threads

Back
Top