PS3 PS1 libcrypt support on PS3 official emus - research thread

I have never insulted you, just mentioned wrong endianness of bytes in your list. I saw your message before the edit where you called me an idiot. You lack not only the proper communication skills, but the good manners too.

And no, I am not gonna dance with you, nor shake your hand at all.
 
et il continue.... un champion....

i dont know if you have english version of " diner de cons" but you should try , at least with subtitles.

you prooved me right by insisting that my file is wrong, i have reintegrated original message about your idiocy. and just in case you are also blind doubled dickhead mentality, in the excel sheet, the column are flipped... i hate ppl telling shit wide open thinking others are wrong, i am sorry, i cannot handle your fucked up mentality just because you cannot check and read something properly, + not excusing yourself about your error.

i wanted to help with ppf but i think you gonna put your 100ppf in your ass and contribute yourself to put your 4 byes in the way you think it must be placed on the bin files.

dont forget to dance for christmas.
 
Last edited:
If you want to generate the magic words for (almost) all the libcrypt disks you can run the following python program from the directory where pop-fe is installed.

It is almost all lc disks but I think I am missing ~10 disks. Anyone have an authorative list of all disks that have libcrypt I can cross-check with and add the missing entries?


It should work on both windows and linux:

#!/usr/bin/env python
# coding: utf-8
#
from gamedb import libcrypt
import requests
import requests_cache
import importlib
pf = importlib.import_module("pop-fe")


if __name__ == "__main__":
for game_id in libcrypt.keys():
print(game_id, '0x%04x' % pf.generate_magic_word(libcrypt[game_id]['url']))​
 
Ronnie Sahlberg said:
If you want to generate the magic words for (almost) all the libcrypt disks you can run the following python program from the directory where pop-fe is installed.

It is almost all lc disks but I think I am missing ~10 disks. Anyone have an authorative list of all disks that have libcrypt I can cross-check with and add the missing entries?


It should work on both windows and linux:

#!/usr/bin/env python
# coding: utf-8
#
from gamedb import libcrypt
import requests
import requests_cache
import importlib
pf = importlib.import_module("pop-fe")


if __name__ == "__main__":
for game_id in libcrypt.keys():
print(game_id, '0x%04x' % pf.generate_magic_word(libcrypt[game_id]['url']))​
Click to expand...

http://redump.org/discs/libcrypt/2/
 
Ronnie Sahlberg said:
It is almost all lc disks but I think I am missing ~10 disks. Anyone have an authorative list of all disks that have libcrypt I can cross-check with and add the missing entries?
Click to expand...
The most relliable is redump because is popular and some people registered in it uses to be very technical
They have 229 discs marked as libcrypt, but are 63 games (same game code) with different languages
Right now the best place to see the complete list is in the page in wiki, i was reviewing and organizing them several times. Note the index at top of the page in wiki have 63 entries... but if you scroll down counting the IDs are 229

Btw, after looking at this in the last days i think redump is missing some libcrypted games... if some of you is registered in it and knows a good way to advise them i think this worths to be reviewed

First game that REALLY looks libcrypt protected is SCES-02183 (Disney's Tarzan for Norway/Norwegian)
Look at the list in wiki, all this IDs for europe releases are marked as libcrypt in redump:
SCES-01431 United Kingdom (English)
SCES-01516 France (French)
SCES-01517 Germany (German)
SCES-01518 Italy (Italian)
SCES-01519 Spain (Spanish)
SCES-02181 Denmark (Danish)
SCES-02182 Sweden (Swedish)
SCES-02184 Finland (Finnish)
SCES-02185 Netherlands (Dutch)

By looking at the numbers we can get an idea at the chronological order where sony gave the licenses to the game company
First it was published for UK only... and a few time later (not so much) 1516, 1517, 1518, 1519 (to complete the "euro multi 5" languages)... and some more time later was released for other north euro countries 2181, 2182, 2183, 2184, 2185
Im marking the 2183 in bold because thats the mistake in redump, is listed as libcrypt=no but i bet is libcrypt=yes ---> http://redump.org/disc/62029/

------------
The other games that looks really fishy are the "Formula One's", check in this list
https://www.psdevwiki.com/ps3/PS1_Classics_Emulator_Compatibility_List#F
Someone reported "Formula One 2000", "Formula One 2001", "Formula One 99", "Formula One Arcade" as unplayable
The fact is "Formula One 99" appears as libcrypt protected in redump lists (and krHACKen made a PPF patch for it)... but it looks the others are going to be libcrypt protected too and redump is not mentioning it
I need to check if all them was made by the same company (and keeping in mind that formula one 99 is older than 2000 and 2001). If is the same company and formula one 99 is libcrypt protected, then the others are going to be libcrypt protected too
This ones are not mentioned in redump either
 
Last edited:
Yeah, is the same company named Studio 33 ---> https://gamefaqs.gamespot.com/company/13196-studio-33

Year 1999 ---> https://gamefaqs.gamespot.com/ps/197373-formula-one-99
Year 2000 ---> https://gamefaqs.gamespot.com/ps/257233-formula-one-2000
Year 2001 ---> https://gamefaqs.gamespot.com/ps/580857-formula-1-2001
Year 2002 ---> https://gamefaqs.gamespot.com/ps/582140-formula-one-arcade

It seems they started playing around with libcrypt in 1999 so... " Destruction Derby Raw" is another candidate for having libcrypt (same company, year 2000)
SCES-02060 ---> https://gamefaqs.gamespot.com/ps/257229-destruction-derby-raw/data
 
Last edited:
sandungas said:
The most relliable is redump because is popular and some people registered in it uses to be very technical
They have 229 discs marked as libcrypt, but are 63 games (same game code) with different languages
Right now the best place to see the complete list is in the page in wiki, i was reviewing and organizing them several times. Note the index at top of the page in wiki have 63 entries... but if you scroll down counting the IDs are 229

Btw, after looking at this in the last days i think redump is missing some libcrypted games... if some of you is registered in it and knows a good way to advise them i think this worths to be reviewed

First game that REALLY looks libcrypt protected is SCES-02183 (Disney's Tarzan for Norway/Norwegian)
Look at the list in wiki, all this IDs for europe releases are marked as libcrypt in redump:
SCES-01431 United Kingdom (English)
SCES-01516 France (French)
SCES-01517 Germany (German)
SCES-01518 Italy (Italian)
SCES-01519 Spain (Spanish)
SCES-02181 Denmark (Danish)
SCES-02182 Sweden (Swedish)
SCES-02184 Finland (Finnish)
SCES-02185 Netherlands (Dutch)

By looking at the numbers we can get an idea at the chronological order where sony gave the licenses to the game company
First it was published for UK only... and a few time later (not so much) 1516, 1517, 1518, 1519 (to complete the "euro multi 5" languages)... and some more time later was released for other north euro countries 2181, 2182, 2183, 2184, 2185
Im marking the 2183 in bold because thats the mistake in redump, is listed as libcrypt=no but i bet is libcrypt=yes ---> http://redump.org/disc/62029/

------------
The other games that looks really fishy are the "Formula One's", check in this list
https://www.psdevwiki.com/ps3/PS1_Classics_Emulator_Compatibility_List#F
Someone reported "Formula One 2000", "Formula One 2001", "Formula One 99", "Formula One Arcade" as unplayable
The fact is "Formula One 99" appears as libcrypt protected in redump lists (and krHACKen made a PPF patch for it)... but it looks the others are going to be libcrypt protected too and redump is not mentioning it
I need to check if all them was made by the same company (and keeping in mind that formula one 99 is older than 2000 and 2001). If is the same company and formula one 99 is libcrypt protected, then the others are going to be libcrypt protected too
This ones are not mentioned in redump either
Click to expand...

yeah you're right, they do miss some games. Here are some more:

https://www.consolecopyworld.com/psx/psx_protected_games_uk.shtml
https://www.consolecopyworld.com/psx/psx_protected_games_jap.shtml
https://www.consolecopyworld.com/psx/psx_protected_games_us.shtml
 
Fedor Wearing A Fedora said:
yeah you're right, they do miss some games. Here are some more:

https://www.consolecopyworld.com/psx/psx_protected_games_uk.shtml
https://www.consolecopyworld.com/psx/psx_protected_games_jap.shtml
https://www.consolecopyworld.com/psx/psx_protected_games_us.shtml
Click to expand...
But dont take that lists as reference, they contains a lot of patches not related with libcrypt ("EDC", "anti-modchip", and other things like that)
There are some talks about it in other forums, the resume of the story is... we only care about the libcrypt because is the only protection that breaks the compatibility with emulators. The other protections like the anti-modchip doesnt matters because are specifically designed to detect the modchip (hardware), when we run the game in the emulator the game doesnt finds any modchip so the game works fine (a.k.a. the anti-modchip code is running but the protection is not triggered)

Also, i been reading many talks in other forums where there was people complaining that the "labels" given to some of the PPF old-school patches was innacurate, this is why sometimes we could find a patch labeled as "libcrypt" but is really an "anti-modchip" (in that case we dont need it)

This is other of the reasons why the list in redump is the most accurte, because they are showing a sample of the "magic shit" in the subchannels, thats the definitive proof that this specific disc is using libcrypt :D
As far i understand... the list in redump with 229 libcrypt discs is 100% confirmed because of that, but yeah, it seems they are missing a few more


Edit:
I made a list at the bottom of this page of some games i suspect that are libcrypt protected but are not listed in redump, just to keep a record of them
https://www.psdevwiki.com/ps3/Talk:PS1_Custom_Patches
 
Last edited:
sandungas said:
But dont take that lists as reference, they contains a lot of patches not related with libcrypt ("EDC", "anti-modchip", and other things like that)
There are some talks about it in other forums, the resume of the story is... we only care about the libcrypt because is the only protection that breaks the compatibility with emulators. The other protections like the anti-modchip doesnt matters because are specifically designed to detect the modchip (hardware), when we run the game in the emulator the game doesnt finds any modchip so the game works fine (a.k.a. the anti-modchip code is running but the protection is not triggered)

Also, i been reading many talks in other forums where there was people complaining that the "labels" given to some of the PPF old-school patches was innacurate, this is why sometimes we could find a patch labeled as "libcrypt" but is really an "anti-modchip" (in that case we dont need it)

This is other of the reasons why the list in redump is the most accurte, because they are showing a sample of the "magic shit" in the subchannels, thats the definitive proof that this specific disc is using libcrypt :D
As far i understand... the list in redump with 229 libcrypt discs is 100% confirmed because of that, but yeah, it seems they are missing a few more


Edit:
I made a list at the bottom of this page of some games i suspect that are libcrypt protected but are not listed in redump, just to keep a record of them
https://www.psdevwiki.com/ps3/Talk:PS1_Custom_Patches
Click to expand...

That is a good initiative!

If redump does not show them as using libcrypt or show the interesting sectors, then I think we have no other choice than to track down physical disks and investigate.
In order to do so I have ordered Formula1 2000/ SCES-02777 from ebay and will let you know once I have it.
EDIT: I also ordered F1 2001 and will check that too. While I don't play much racing games (I amd JRPG through and through) they are inexpensive and will nicely pad my ps1 game shelf.
 
Last edited:
Agrippa said:
There were two F1 video game series - one made by Sony (Formula One) and one by EA Sports (F1). F1 2000 is Libcrypt protected and Formula One 2000 is not.
Click to expand...
The game names are confusing, but is a lot more clear if you look at the game company
sandungas said:
Yeah, is the same company named Studio 33 ---> https://gamefaqs.gamespot.com/company/13196-studio-33
Click to expand...

The story of the company was convulted though, it was in the hands of psygnosis, sony and EA
https://en.wikipedia.org/wiki/Studio_33

The point is, at he time they was publishing games for PS1 they was property of sony, this is why the games was given IDs starting with "SCES" (instead of "SLES")
C = Copyrighted by sony
L = Licensed by sony (sony licenses the game of other company)

Formula One 99 = SCES-01979, SCES-02222 <--- this one is libcrypt protected, 100% confirmed
Formula One 2000 = SCES-02777, SCES-02778, SCES-02779
Formula One 2001 = SCES-03404, SCES-03423, SCES-03424, SCES-03524
Formula One Arcade = SCES-03886
Destruction Derby Raw = SCES-02060

In the practise it means the developers from Studio 33 was in close contact with sony, probably sony was suggesting them to implement libcrypt in all his games and they said... "why not ?, we have the full support from sony, so is a feature that should work"
 
Last edited:
LibCrypt was sold to the Infogrames eventually. That is why most of the late LC releases were published by that company. It is not worth to assume every Sony published game was released with LC, because one specific release had it implemented back then. I would rather trust the redump database, because they put a really big effort in documenting a lot of protections, including PC ones.
 
I think i might be onto something, but i've to dive a bit deeper to fully understand what it is and see if it's legit. Here's a short summary so far:

1. I dumped my eboot of soul reaver (NPEF-00115 = SLES-01301) with psxtract, and converted it to a PSOne CD-ROM format.
2. Compared the converted eboot dump with a disc dump of soul reaver that equaled the redump checksums...and the converted dump was missing 2 sectors. But other than those 2 missing sectors they matched.
3. Found the missing 2 sectors in \ISO folder of psxtract in a file called JUNK_176FDD40.BIN. Once I pasted those 2 sectors below the converted dump it matched the disc dump and also had the correct redump checksums.
4. In the Junk file I also found a third and fourth sector below the missing 2 sectors, containing 2 sectors of data.
5. I tried to find if it had anything that would match a SBI, LSD or SUB file...but so far no bueno (also tried it with different endianness).
6. However when I searched for the hex value 41 (where the LC sectors begin with) I found 32 matches, which equals the amount of LC sectors for this game! This means absolutely nothing tho, might be coincidence.

upload_2021-12-25_0-18-43.png
 
Agrippa said:
It is. The 41 01 01 pattern is not specific to the Libcrypt at all.
Click to expand...

it turned out to be a coincidence, couldn't find the pattern in other games. But I wasn't talking about the 41 01 01 pattern ;) (that's being used as a prefix for subchannel Q position IIRC). 41 is used in the eboot TOC for entries, so I thought maybe 32 entries for 32 LC sectors.
 
Fedor Wearing A Fedora said:
it turned out to be a coincidence, couldn't find the pattern in other games. But I wasn't talking about the 41 01 01 pattern ;) (that's being used as a prefix for subchannel Q position IIRC). 41 is used in the eboot TOC for entries, so I thought maybe 32 entries for 32 LC sectors.
Click to expand...
The only reference we have to see what sony was doing to deal with the subchannel data are the 3 "configs" i extraced from ps1_netemu.self published here for Crash Team Racing SCES_021.05, MediEvil SCES_003.11, and Vagrant Story SLES_027.54
https://www.psx-place.com/threads/p...mus-research-thread.35836/page-10#post-317262

We need to think in them as an initial implementation, sony only used it for 3 games, and this 3 configs was kept inside the .self forever because sony doesnt uses to remove working features... but...
This implementation had a flaw, because storing all that data for every libcrypt protected game is not efficient, is a lot of data and would make the .self too big
So... most probably what they did is to implement another feature that allows to load that same data externally (from the "PSOne classic" PKG)

Back to that files... the most weird thing of them is the amount of data is not a multiplyer of the libcrypt protected sectors, when looking at them in a hexeditor is better if you change the hexeditor settings for the lines lenght (reduce it to display 4 bytes each line, or 8), is needed also to convert them to decimal, the result is this, im using medievil for this example becuse is the smallest

Original format
sandungas said:
MediEvil SCES_003.11 (located at absolute offset 0x17d57c - 0x1ABF0 = 0x16298C)
Code: 
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00162980                                      00 00 06 15              ....
00162990  00 00 2A 75 00 00 37 19 00 00 3A 33 00 00 3A D0  ..*u..7...:3..:Ð
001629A0  00 00 3B 1A 00 00 3B 8A 00 00 3C 12 00 00 3E 2F  ..;...;Š..<...>/
001629B0  00 00 3E E5 00 00 5D FC 00 00 71 8E 00 00 7C 17  ..>å..]ü..qŽ..|.
001629C0  00 00 80 35 00 00 A4 3D 00 00 A7 3D 00 00 A8 04  ..€5..¤=..§=..¨.
001629D0  00 00 A8 A9 00 00 A9 19 00 00 A9 90 00 00 AB BB  ..¨©..©...©...«»
001629E0  00 00 AC 7F 00 00 BA B2 00 00 BE E3 00 00 C0 AF  ..¬...º²..¾ã..À¯
001629F0  00 00 C1 93 00 00 C1 C4 00 00 C3 A1 00 00 DA DE  ..Á"..ÁÄ..á..ÚÞ
00162A00  00 00 E7 C1 00 00 FD 3A 00 01 1A 1C 00 01 1D 6A  ..çÁ..ý:.......j
00162A10  00 01 1D CF 00 01 29 EF 00 01 45 E2 00 01 6A 98  ...Ï..)ï..Eâ..j˜
00162A20  00 01 7F BB 00 01 B7 A0 00 01 BB 05 00 01 BF 12  ...»..· ..»...¿.
00162A30  00 01 EE 64 00 02 02 6E 00 02 0B CA 00 02 10 19  ..îd...n...Ê....
00162A40  00 02 37 24 00 02 45 EC 00 02 54 06 00 02 55 A1  ..7$..Eì..T...U¡
00162A50  00 02 5D 48 00 02 62 C8 00 02 81 12 00 02 9B 2D  ..]H..bÈ......›-
00162A60  00 02 BD 04 00 02 C2 AF 00 02 D9 2A 00 02 DC 90  ..½...¯..Ù*..Ü.
00162A70  00 02 E1 3A 00 02 F2 18 00 02 FC C8 00 03 51 CF  ..á:..ò...üÈ..QÏ
00162A80  00 03 52 AA 00 03 72 3F 00 00 00 00              ..Rª..r?....
Click to expand...

Splitted in chunks of 4 bytes and converted to decimal
Code: 
00000615 --- to decimal ---> 1557
00002A75 --- to decimal ---> 10869
00003719 --- to decimal ---> 14105 (mentioned in the redump SBI file)
00003A33 --- to decimal ---> 14899 (mentioned in the redump SBI file)
00003AD0 --- to decimal ---> 15056 (mentioned in the redump SBI file)
00003B1A --- to decimal ---> 15130 (mentioned in the redump SBI file)
00003B8A --- to decimal ---> 15242 (mentioned in the redump SBI file)
00003C12 --- to decimal ---> 15378 (mentioned in the redump SBI file)
00003E2F --- to decimal ---> 15919 (mentioned in the redump SBI file)
00003EE5 --- to decimal ---> 16101 (mentioned in the redump SBI file)
00005DFC --- to decimal ---> 24060
0000718E --- to decimal ---> 29070
00007C17 --- to decimal ---> 31767
00008035 --- to decimal ---> 32821
0000A43D --- to decimal ---> 42045 (mentioned in the redump SBI file)
0000A73D --- to decimal ---> 42813 (mentioned in the redump SBI file)
0000A804 --- to decimal ---> 43012 (mentioned in the redump SBI file)
0000A8A9 --- to decimal ---> 43177 (mentioned in the redump SBI file)
0000A919 --- to decimal ---> 43289 (mentioned in the redump SBI file)
0000A990 --- to decimal ---> 43408 (mentioned in the redump SBI file)
0000ABBB --- to decimal ---> 43963 (mentioned in the redump SBI file)
0000AC7F --- to decimal ---> 44159 (mentioned in the redump SBI file)
0000BAB2 --- to decimal ---> 47794
0000BEE3 --- to decimal ---> 48867
0000C0AF --- to decimal ---> 49327
0000C193 --- to decimal ---> 49555
0000C1C4 --- to decimal ---> 49604
0000C3A1 --- to decimal ---> 50081
0000DADE --- to decimal ---> 56030
0000E7C1 --- to decimal ---> 59329
0000FD3A --- to decimal ---> 64826
00011A1C --- to decimal ---> 72220
00011D6A --- to decimal ---> 73066
00011DCF --- to decimal ---> 73167
000129EF --- to decimal ---> 76271
000145E2 --- to decimal ---> 83426
00016A98 --- to decimal ---> 92824
00017FBB --- to decimal ---> 98235
0001B7A0 --- to decimal ---> 112544
0001BB05 --- to decimal ---> 113413
0001BF12 --- to decimal ---> 114450
0001EE64 --- to decimal ---> 126564
0002026E --- to decimal ---> 131694
00020BCA --- to decimal ---> 134090
00021019 --- to decimal ---> 135193
00023724 --- to decimal ---> 145188
000245EC --- to decimal ---> 148972
00025406 --- to decimal ---> 152582
000255A1 --- to decimal ---> 152993
00025D48 --- to decimal ---> 154952
000262C8 --- to decimal ---> 156360
00028112 --- to decimal ---> 164114
00029B2D --- to decimal ---> 170797
0002BD04 --- to decimal ---> 179460
0002C2AF --- to decimal ---> 180911
0002D92A --- to decimal ---> 186666
0002DC90 --- to decimal ---> 187536
0002E13A --- to decimal ---> 188730
0002F218 --- to decimal ---> 193048
0002FCC8 --- to decimal ---> 195784
000351CF --- to decimal ---> 217551
000352AA --- to decimal ---> 217770
0003723F --- to decimal ---> 225855
00000000

This conversion to decimal seems to be the first step to convert that values to something a bit "understandable", we dont know what is it but maybe some of you figures it
The next step could be to divide the numbers by the size in bytes of 1 sector... or maybe we need to add/substract an offset because are adresses of the emulator RAM (instead of addresses of the disc image)

Anyway... some of the "garbage data" inside the official "PSOne classics" could be usign this same format... or a format derivated from it
 
Last edited:
You must log in or register to reply here.

Similar threads

Back
Top