PS3 PS1 libcrypt support on PS3 official emus - research thread
- Thread starter solomonbyte
- Start date
PS1 emulators do include hardcoded Magic Words for three games - Disney's Mulan, V-Rally 2 and Soul Reaver UK, according to the wiki. I have tested the Soul Reaver and it does work indeed without the patching using both ps1_emu and ps1_netemu (no softlock on the first battle encounter). Overall the game does play better on the netemu, because there is a stopping effect on the ps1_emu (the game does stream a lot in the background, maybe that is the cause). I have spotted a slowed and pitched down audio on the PS1 boot screen when loading the game through the netemu, but I did not pay any attention if the audio is right in game.
MonkeyFistz
Member
i have been reading this thread out of curiousity ... and saw aldo's explaination on how the disc file sectors are read when stored in filesystem , would it not be possible to fake the disc type using get type command so that the disc faked in storage event can read the disc even if the iso is mounted?
MonkeyFistz
Member
https://psxdatacenter.com/sbifiles.html
sbi files for all pal region games that were released with it
sbi files for all pal region games that were released with it
Ronnie Sahlberg
Developer
Can you try VagrantStory UK?
On PSP it hangs on the "now loading" screen after selecting NewGame from the main menu unless I apply a PPF for it.
On PS3, creating a PS3 PKG from the same disk image it works even without a PPF. Also, the ISO.BIN.DAT does NOT have the magic word in it at offset 0x16b0
It is very confusing.
According to the netemu hardcoded table, available on the wiki, flag in the parenthesis, bold value is the Magic Word):
1. LC games with a forced Magic Word:
- Disney's Mulan (00000015000089ea),
- V-Rally 2 (000000150000c0ee),
- Soul Reaver UK (000000150000b722).
2. LC games with a some kind of patch, I do not know what is it for:
- Crash Team Racing (000000020017d3d4),
- MediEvil (000000020017d57c),
- Vagrant Story (000000020017d67c).
1. LC games with a forced Magic Word:
- Disney's Mulan (00000015000089ea),
- V-Rally 2 (000000150000c0ee),
- Soul Reaver UK (000000150000b722).
2. LC games with a some kind of patch, I do not know what is it for:
- Crash Team Racing (000000020017d3d4),
- MediEvil (000000020017d57c),
- Vagrant Story (000000020017d67c).
sandungas
Developer
Is outdated/incomplete, the most relliable way is by using this link http://redump.org/discs/libcrypt/2/
The weird thing of that link is that is using the redump search engine, but this settings are not availables in a user friendly way to select them with a mouse, is explained here
http://forum.redump.org/topic/16358/done-search-by-category-andor-edition/
Basically, is telling to display PSX games tagged as libcrypt = yes
The good thing is it seems it loads the contents dinamically, so if at some point some of the other redump users does a change related with the lybcrypt status (or the SBI data) the changes should appear in the list
Anyway... if you click in the games of that list you are going to see they are displaying the SBI file (containing the subchannel data in raw) as a hexeditor view (easy for us to take a look at it for research purposes)
As example, for CTR: Crash Team Racing (SCES-02105) they have 2 entries in the list (im not sure why), but lets use this as example: http://redump.org/disc/798/
At top there is a download link for the SBI file... and at bottom there is a hexview of it
Now is needed to see if the "garbage" data found by devildwarf at the ending of the ff8 and crash disc images is the same than the data in the redump SBI files
Im assuming is not exactly the same, because probably devildwarf and ronnie already took a look at it and they didnt mentioned an "eureka" about it yet
My guess is sony did something with it, either to reduce the size of the data, to do some kind of sanity check, to increase performance or whatever
solomonbyte
Member
i performed some check on games ppf given by kracken.
see excel file
i also join you sbi & lsd patch for those interested. ( 223 & 229 )
i highly doubt one ppf patched game would go wrong considering the amount of data modified on the recognized complex games, but nonetheless, i'll test them.
the question i got now is how do we manage to get the edc code present on the ppf, i have no clue about that at all, if one good soul want to explain to me.
see excel file
i also join you sbi & lsd patch for those interested. ( 223 & 229 )
i highly doubt one ppf patched game would go wrong considering the amount of data modified on the recognized complex games, but nonetheless, i'll test them.
the question i got now is how do we manage to get the edc code present on the ppf, i have no clue about that at all, if one good soul want to explain to me.
Attachments
Last edited:
Berion
Developer
If "disc archives" contains subchannel data in separate from disc images section (based on dev wiki page), and Sony emulators using them, then it means psxtract ignoring this during decryption and extraction. From this came wrong assumption that those emulators patching stuff on the fly. :/
I confirm the Vagrant Story UK passes the loading screen using the ps1_netemu. So the hardcoded settings I posted do affect the LC too. There is a need to debug the emulator to understand the flags (and the whole PBP handling). All that blind guessing is not worth any time, I think.
sandungas
Developer
From the 3 posible ways we was speculating most probably is going to be needed to update some tools, after all the hack used to run PS1 and PS2 classics in PKG format has been always about trying to copy the official structures in the best way posible because are running with official functions
The good one
The concept is simple, the subchannel data needs to be packed together with the disc image (every disc have his own)
Some days ago when i was learning about all this i had a tendence to think that the most probables was the others, mostly because ive heard many times before that sony was defeating his own libcrypt protection by applying patches in the disc image in the official PS1 classics, and is the kind of history that is catchy because is a bit laughable
I mean... if sony was using "dirty" hacks it would mean the emulator doesnt supports subchannel data at all... so implementing it would be a completly different story and something very tricky theoretically
libcrypt patches hardcoded inside the emu
This was my second way of thinking, just because is easy and i was still considering the emulator doesnt support subchannel data... in other words still a "dirty" hack but a bit more handy to deal with it, more time costly and prone to human errors because it would be needed to check and debug every patched area individually, this is also why i was wondering if the emulator could include the complete collection for the 229 discs... lot of work, but is the kind of thing after it done it becomes "legacy" (not needed to touch it ever with a 10 feet pole, 100% working)
And it would be like the kind of area inside the emu .elf that most of the people reverse enginerring the PS1 emulators was labeling as "unknown clusterfuck of data", you know... completly unknown and zero hopes to identify it... so forget about it and better spend the time in something more interesting
subchannel data hardcoded inside the emu
Pretty much like the previous, it would be another clusterfuck inside the emu .elf but this is way easyer to do, can be automatized and is failproof... is just... it would imply the emulator supports the subchannel and in that case it seems they prefered to pack the subchannel data with the disc image
Btw, in the PS2 emulators they was doing this with the game configs, is not so crazy for other tools, the concept is we create a clusterfuck with the data for the 229 games (1 file instead of 229) like if it was some kind of database where can be applyed other features (to prevent duplicated entries, compression, to give them a different ID, whatever) and then that database is shipped with the tool, basically is like doing a .zip with all the files and preparing some functions to access the .zip content (but im not telling it only for the compression, the configs in the PS2 emulators are not compressed but the way how they reduced size is nice stuff)
-----------------
Anyway, this feature is nice for PS1 classics in PKG format/HEN, and some PS3 backup mamagers that could do the conversions in betwen encrypted/decrypted disc images, and the swaptrick with the placeholder
But for CFW where is used the standard disc image is going to be needed to implement new checks in cobra/mamba to deal with the new structure and send the correct info to the emu
So the PPF patches are still handy in the meantime because we are sure are going to work in all cases (ironically are the most compatibles in between platforms/emus), so the list of PPF patches i made in wiki will be useful after all, in the last days when i was trying to figure what to do with the list i changed my mind many times and i was not so sure
Now my tasks in that wiki page are increasing, displaying the PPF patches was a good idea, but if the last specualtions are confirmed and that "garbage" found by devildwarf is subchannel data we can display it in the wiki page too (and this will be legacy, kind of thing that could take some work to complete, but is not needed to modify it ever again)
The PPF patches on the otherside... i want the page to be like the others for PS2 configs, with some people publishing "partial fix" and later some other replacing it by "version 2" and so on until we reach a point where we get the "holy grail LC.ppf" for every disc, lol
Last edited:
sandungas
Developer
Very handy to have a view of them together, the other day (at some point after i made the initial versions of the "PS1 Custom Patches" page) i was doing some dirty searchs in the web browser (CTRL+F) with the ID of the libcrypt protected games in the "PS1 Emulation" page and i realized there was a few, dont remember the number but something around the list you made, is complete ?
At that point i was focusing my attention in libcrypt only and my reasoning was that the amount of coincidences in between the 2 pages should be way bigger (up to 229 matches incase all them had his ID hardcoded inside the emu), so i thought that this could not be related because there are many libcyrpt protected games that are not listed, that other libcrypt protected games are dealing with libcrypt in a complete "dynamic" way
Or was assigning a different ID with a CRC algorythm different than the one used in PS2 emu + the other theory of the clusterfuck of data that could be "hiding" all this data even deeper
So... in the worst case scenario we could "bypass" the settings hardcoded inside the emu for that 6 games just by changing the ID of the game when we build the PKG
In some way is nice the experiments made by devildwarf was with 2 games that doesnt appears in that lists of IDs hardcoded in the emu (ff8, and crash racing), it means that settings was not "conficting" with anything he did
By now is better to do the experiments with games that doesnt appears in that lists to simplify it, we can consider them as an "addon" to investigate later
That settings are interesting anyway
Either to bypass them incase they creates some problem we cant predict at this time mostly because are unknown flags, the only way to be 100% sure that are not conflictive is by identifying what each flag does and this is a challenge in itself
Or... to patch the emu and rebuild the whole list of games for the user preferences, lets say... for someone interested only in euro/usa games is posible to replace all the japan/asia settings by euro/usa games with different settings for them
We should think in it as a table with a strict number of "slots" availables, we cant increase or decrease the number of slots, but we can replace the contents of all them
*this kind of emu patch only could work in CFW (not HEN/HAN because is not posible to patch the emus), and it would be the kind of patch it should be distributed in "flavours" because the decission about which games worths to be removed from the list of settings hardcoded in the emu is very personal and controversial
Last edited:
Devildwarf
Member
well its all interesting finds, and yeah the patch data doesn't look anything like the SBI or the .SUB so i have no idea how to read that (it could be encrypted or in some weird format),
and @Agrippa how do you calculate the magic number ? i would be interesting in trying that method, if we can generate that number for any game it would be possible to patch a lot of games that way (probably)
and @Agrippa how do you calculate the magic number ? i would be interesting in trying that method, if we can generate that number for any game it would be possible to patch a lot of games that way (probably)
solomonbyte
Member
https://red-j.github.io/Libcrypt-PS1-Protection-bible/index.htm
section : Patching - First step : Find the Magic word value
https://psx-spx.consoledev.net/cdromdrive/#cdrom-protection-libcrypt
Ronnie Sahlberg
Developer
Ok, so do you think this is correct?
To summarize so far.
1, some libcrypt games, e.g. VagrantStory,work out of the box on PS3. Possibly by some hardcoded patch built into the emulator.
2, some libcrypt games, e.g. CTR, works on PS3 IFF you store the magic word at offset 0x12b0 in in the PSISOIMG0000 section of the ISO.BIN.DAT
3, other libcrypt games require the subchannel to be provided (in an unknown format) at the end of the ISO.BIN.DAT
Should we document in the wiki for these games which type they fall under?
Or,
4, create a PPF, it always works for (almost?) all games
Ronnie Sahlberg
Developer
That first link looks very promising.
That entire process looks like it should be fairly straightforward to automate, and build into pop-fe unless a curated ppf patch is available.
PPF files are an attractive solution because they can be used to create working EBOOTs for both PS3 and PSP while for methods that modify ISO.BIN.DAT it is unclear how they works on PSP as there is no ISO.BIN.DAT afaik on PSP.
@krHACKen , your list of professionally made PPF files for that decently large chunk of games,
would you be ok with me adding your PPFs to pop-fe once I get time to seriously work on it again in january? Also, leaning on your expertese in these matters, how accurate is the Libcrypt-PS1-Protection-bible in your view?
Last edited:
Devildwarf
Member
well the Magic word method seems to work so far on CTR and FF8, i just tried it on Disc1 of FF8 and it seems to be working fine, for magic words add them at
0x12B0 for single disc or 0x16B0 for Multidisc
I kinda expected it not to work so well but it seems to play fine (only played the opening but everything seems to be working)
So that could be 1 method for PS3 PS1Classics (not sure if it works with all games but it works with those 2)
And yeah i am interested in how the PSP runs, from what i remember it has its own launcher inside the eboot.psp called DATA.PSP (or eboot.bin depending on the program used to extract) so it would be interesting to see if this could be made possible for psp owners, if not then the PPF method is probably best like you said, there are so few libcrypt games anyway
0x12B0 for single disc or 0x16B0 for Multidisc
I kinda expected it not to work so well but it seems to play fine (only played the opening but everything seems to be working)
So that could be 1 method for PS3 PS1Classics (not sure if it works with all games but it works with those 2)
And yeah i am interested in how the PSP runs, from what i remember it has its own launcher inside the eboot.psp called DATA.PSP (or eboot.bin depending on the program used to extract) so it would be interesting to see if this could be made possible for psp owners, if not then the PPF method is probably best like you said, there are so few libcrypt games anyway
1. These six games I listed should work with the ps1_netemu without any crack applied.
2. CTR should work with the ps1_netemu without any crack.
3. I do not really know. More info needs to be gathered by inspecting the Classics. But what is more important to me, we will not go further until somebody starts debugging the emulator itself. In my opinion, the best way to sort it out is to add a subchannel support into the Cobra core. It would work with the ps1_emu, but may not work with the ps1_netemu. After all, I am not a programmer, so I do not know how complicated is to do that.
4. PPF patches are working as always. After the latest @krHACKen contributions, only the Sydney 2000 UK version is still uncracked properly (I may take a look on it someday).
I am not @krHACKen, but most of the write-up is very accurate. Apart from the FF8 info, written originally for the NTSC version and its anti-mod protection.
Ronnie Sahlberg
Developer
Good info.
Can you update CTR and FF8 with this info about PS3 on https://www.psdevwiki.com/ps3/PS1_Custom_Patches
solomonbyte
Member
guys, open the file here i made the list of most of kraken checks and you have big endian magic words in plain cell on sheet 2...
------------
edit : fixed another error from libcrypt magic word finder for formula one 99 the correct value is 9D 0D.
the error comes from fact the first four bytes are null an not counted on the script of the program.
Excel 1 - coder 0
------------
edit : fixed another error from libcrypt magic word finder for formula one 99 the correct value is 9D 0D.
the error comes from fact the first four bytes are null an not counted on the script of the program.
Excel 1 - coder 0
Attachments
Last edited:
Similar threads
-
-
-
PSP PSP-GO Pause support for PS1 emulator
- Started by Ronnie Sahlberg
- Replies: 2
-
