PS3 Cobra improvement for PSX/PS2 emulation

aldostools said:
Have you tried to remove them from the "whitelist" in game_ext_plugin.sprx ?

Maybe the emulator is assuming that these games are PS2 Classics and the emulator tries to decrypt them.
Click to expand...

With noped build_netemu_params function, no games will boot properly through payload crashing the same way like the unpatched SOCOM does. The issue seems to be more complicated, it seems. Even with disabled Cobra/Mamba and official PS2 Classics package, the ps2bootparam.dat file does not match the one on the wiki.

Anyway, I changed approach and started to reverse engineer game_ext_plugin. I have already found ps2bootparam.dat and HDD games references. I think patching the module is more clean than modifying the .ISO by the webMAN. It will take some time, as it is my second time with PPC assembler and I have got no experience and knowledge in static debugging. But I suspect taking the branch at 0x170F0 should be sufficient to disable the check of the PS2 HDD games.
 
@aldostools at the moment there are 230 psx discs protected by libcrypt, while on your link there are only 227

http://redump.org/discs/libcrypt/2/

since there isn't an automatized tool to download the lsd files at the moment on redump i'm sharing an up to date package to speed up your work:

https://mega.nz/file/BI4wHL7Z#-FVyLiOHqhFRgHaFDzmpYoKSddzCfe8FL2QQZcM-MIc

However the lsds must be attached in the same folder as the cue/bin or will be included in some payload?
Just because lsd package is in continuos update on redump, maybe it's better to use lsd from folders where cue/bin is located.
You could make a tool to automatically download from redump and place lsds in default folder for cue/bin.
 
Rallye89 said:
@aldostools at the moment there are 230 psx discs protected by libcrypt, while on your link there are only 227

http://redump.org/discs/libcrypt/2/

since there isn't an automatized tool to download the lsd files at the moment on redump i'm sharing an up to date package to speed up your work:

https://mega.nz/file/BI4wHL7Z#-FVyLiOHqhFRgHaFDzmpYoKSddzCfe8FL2QQZcM-MIc

However the lsds must be attached in the same folder as the cue/bin or will be included in some payload?
Just because lsd package is in continuos update on redump, maybe it's better to use lsd from folders where cue/bin is located.
You could make a tool to automatically download from redump and place lsds in default folder for cue/bin.
Click to expand...

Thank you for the files. I'll try to synchronize them with the ones already in the database.

If you update webMAN MOD, the files are installed in /dev_hdd0/tmp/lsd (they take less only a few KB in HDD), while the PSX compatibility is increased.

The files can be searched & downloaded manually from https://ps3.aldostools.org/lsd.html
 
Missing titles in your list:

http://redump.org/disc/92303/
http://redump.org/disc/56471/
http://redump.org/disc/85814/

Note that introduction of new dumps could modify metadata of other dumps with addition of (Alt) and other tags, however this could happen very hardly becuase there aren't many missing discs from redump database, but it's a safe operating task to delete every lsd and rebuild ex-novo another updated database and list to prevent this mismatchings, and also to refresh any data stored into lsd files (very sensible to read errors on dumping process).
 
Rallye89 said:
It could be an useful feature to refresh your lsd database from redump at every webman mod main update! :)
Click to expand...

The files are already included in the online update. You can update right now if you want.

However, there are only 225 files of 230 (98%) due there are 5 duplicated title ids.
These 5 title ids must be downloaded manually if the user wants to use them.
They are basically previews, betas, alternative versions, etc.

Rallye89 said:
Missing titles in your list:

http://redump.org/disc/92303/
http://redump.org/disc/56471/
http://redump.org/disc/85814/

Note that introduction of new dumps could modify metadata of other dumps with addition of (Alt) and other tags, however this could happen very hardly becuase there aren't many missing discs from redump database, but it's a safe operating task to delete every lsd and rebuild ex-novo another updated database and list to prevent this mismatchings, and also to refresh any data stored into lsd files (very sensible to read errors on dumping process).
Click to expand...

The database was updated using a binary file compare:
- 3 LSD were added
- 10 LSD were renamed with your nomenclature
- 1 LSD was updated (Hogs of War had a 1 wrong byte when copied from Kippykip's database)
 
Last edited:
aldostools said:
The files are already included in the online update. You can update right now if you want.

However, there are only 225 files of 230 (98%) due there are 5 duplicated title ids.
These 5 title ids must be downloaded manually if the user wants to use them.
They are basically previews, betas, alternative versions, etc.
Click to expand...

But lsd data differs from version to version, so the libcrypt protection couldn't be exploited. You can check lsd hashes from the zip file i uploaded in the previous posts.
 
Rallye89 said:
But lsd data differs from version to version, so the libcrypt protection couldn't be exploited. You can check lsd hashes from the zip file i uploaded in the previous posts.
Click to expand...

226 of 227 LSD matched. Only 1 was wrong. It's fixed now.
Now there are 230 LSD files in the online database. 225 in the installed database.

The centralized database is used only for net/exFAT/NTFS or if the LSD file is not included with CUE/BIN.
 
i see one distinct issue but ir can be fixed...
where are the ntsc-u /ntsc-j psx libcrypt titles.
i'm lookin forward to more awesomeness...

Cheers
-RetroFan90
 
Agrippa said:
The most common Libcrypt specific formats are: .SBI and .LSD. The problem is they do contain only the Libcrypt sectors inside (16 or 32) and the .SBI lacks the CRC checksum, so the recalculation is additionally needed (ironically, the protection relies on corrupted checksum and the format does lack any of them).
Click to expand...

In v7 I added support for .sbi just for fun, and I found something interesting: The CRC-16 checksum calculation in SubQ can be omitted from the payload. I've commented out the checksum, reducing the payload size almost 1KB, and the PSX games still work.

It seems like the SCSI driver performs the CRC-16 calculation internally using the first 10 bytes of the subchannel Q.
In the case of the LibCrypt games, it looks like the protection does not validate the checksum or it is recalculated internally.
Probably that's the reason why the .SBI format doesn't include it.
 

Attachments

hello i have a ps2classic shin megami tensei nocturne. game start 60hz (epilettic disclaimer) but turn immediatly to 50hz. who select the hz? exist a way for force resolution/hz on pkg installed games? a force options can be added to cobra options?
 
aldostools said:
In v7 I added support for .sbi just for fun, and I found something interesting: The CRC-16 checksum calculation in SubQ can be omitted from the payload. I've commented out the checksum, reducing the payload size almost 1KB, and the PSX games still work.

It seems like the SCSI driver performs the CRC-16 calculation internally using the first 10 bytes of the subchannel Q.
In the case of the LibCrypt games, it looks like the protection does not validate the checksum or it is recalculated internally.
Probably that's the reason why the .SBI format doesn't include it.
Click to expand...

It is actually the other way around. The protection does rely on the checksum in fact. Here is how it works:
1. Try to read the M:S:F position from the LC corrupted sector.
2. CD-ROM controller reads the checksum from the LC corrupted sector.
3. The checksum is wrong - report the position of the previous sector.
4. A total sum of 16 unsuccessful read attempts of LC sectors consists of a Magic Word key.

As you can see, letting the controller to recalculate the checksum itself would make some games to not pass the protection check. Because there is a LC variant where only the CRC-16 checksum is modified with the rest of subchannel Q values left intact.

The .SBI format does not include it, because it was just a lazy attempt to play the warez games. The emulator reads from this file which sectors are corrupted and reports them back. In other words, when the LC validation routine wants to access the corrupted data from the 14105 sector, it does really expect the data from the previous sector to receive.
 
@aldostools, here is the patched game_ext_plugin to bypass the crash when launching the HDD whitelisted games through the Cobra:
Code: 
search:
40 FE 00 34 3B FF FE D4  98 1E 00 0B 7F E3 FB 78
48 02 CF 35 3D 60 80 02  2B 83 00 1F 61 6B 8F 00
41 9D 00 78
replace:
60 00 00 00 3B FF FE D4 98 1E 00 0B 7F E3 FB 78
48 02 CF 35 3D 60 80 02 2B 83 00 1F 61 6B 8F 00
48 00 00 78
I do not know how it will behave on the BC consoles (probably there will be no PS2 virtual HDD support), neither I am sure the patch is clean. But it does work with the SOCOM 2 NTSC and official PS2 Classic game (to make sure PS2 Classics are not broken).
 
Agrippa said:
@aldostools, here is the patched game_ext_plugin to bypass the crash when launching the HDD whitelisted games through the Cobra:
Code: 
search:
40 FE 00 34 3B FF FE D4  98 1E 00 0B 7F E3 FB 78
48 02 CF 35 3D 60 80 02  2B 83 00 1F 61 6B 8F 00
41 9D 00 78
replace:
60 00 00 00 3B FF FE D4 98 1E 00 0B 7F E3 FB 78
48 02 CF 35 3D 60 80 02 2B 83 00 1F 61 6B 8F 00
48 00 00 78
I do not know how it will behave on the BC consoles (probably there will be no PS2 virtual HDD support), neither I am sure the patch is clean. But it does work with the SOCOM 2 NTSC and official PS2 Classic game (to make sure PS2 Classics are not broken).
Click to expand...

Thank you for the patch. It would be great if users with BC consoles report their results.

Here are various installers. They install the patch in /dev_hdd0/tmp/gameboot
webMAN MOD already remaps game_ext_plugin.sprx if it is found in that path.

I don't have that game, so I haven't tested the patches. It should be safe to use, since it isn't touching dev_flash.
But as it is a system file, I warn that install them at your own risk.
 

Attachments

@RetroFan90
there aren't ps1 librcypt ntsc games, ntsc protected games use antimodchip protection, pal protected games use libcrypt protection

@Agrippa @aldostools
sbi doesn't contain CRC bytes, while LSD does. i don't remember exactly how the librcypt works, but it's certainly based on modified MSF data, this means that subchannels data is used to make a check with magic word at a certain point in the game. if MSF has been corrected (to the pattern that is supposed to be typical for cd rom subchannels) by the drive in burning process or rebuild if missing by the imaging software during the generation of the image file or simply corrected from the imaging software the check fails and game freezes. CRC right data from lsd I think is not necessary for the protection itself but for completition purposes of the dumpers, maybe for error detection and correction during the reading process of the subchannels (I THINK) but i don't even remember if suchannels have error detection and correction. there are also different types of LC protection schemes, you can find useful info on the web.
 
Rallye89 said:
sbi doesn't contain CRC bytes, while LSD does. i don't remember exactly how the libcrypt works, but it's certainly based on modified MSF data, this means that subchannels data is used to make a check with magic word at a certain point in the game. if MSF has been corrected (to the pattern that is supposed to be typical for cd rom subchannels) by the drive in burning process or rebuild if missing by the imaging software during the generation of the image file or simply corrected from the imaging software the check fails and game freezes. CRC right data from lsd I think is not necessary for the protection itself but for completion purposes of the dumpers, maybe for error detection and correction during the reading process of the subchannels (I THINK) but i don't even remember if subchannels have error detection and correction. there are also different types of LC protection schemes, you can find useful info on the web.
Click to expand...

From my research, LibCrypt uses custom subchannel Q data for 32 sectors (16 on minute 3 and 16 on minute 9). Each subchannel has 12 bytes (control_adr + track_number + index_number + MSF + 0 + aMSF (+2secs) + CRC16). Cobra has 4 bytes of padding. Only MSF and aMSF are changed (usually 1 byte on each). The resulting CRC-16 changes too, but the PSX game works even if CRC-16 is passed with zeroes to the SCSI driver using Cobra payload, so I assume that the CRC-16 is re-calculated internally by the SCSI driver.

SBI and LSD formats have very similar formats with little differences. SBI has a signature header (4 bytes), and each subchannel data has 14 bytes: MSF + index (01) + 10 bytes of subchannel data. LSD doesn't have the signature header, and the subchannel data is 15 bytes: MSF + 12 bytes of subchannel data including CRC-16. SBI is 452 bytes (4 + 32*14). LSD is 480 bytes (32 * 15).

MSF bytes are stored as BCD (binary-coded decimal). e.g. 49 seconds are coded as 0x49.
Each second has 75 frames or sectors. LBA or absolute sector number is calculated as 75*(60*M + S) + F.
 
Last edited:
I have already explained how the LC validation does work. @aldostools, I have tested the newest version of the MAMBA payload and the Ape Escape does not pass the LC check. The CRC-16 is not meant to be recalculated, it needs to be read from the .LSD file precisely, because of the issue I mentioned earlier (sectors could have altered checksum only without the data at all, recalculation will repair them as a result). That is why .SBI files could not work right out of the box, as the most important CRC value is missing there.

aldostools said:
Thank you for the patch. It would be great if users with BC consoles report their results.

Here are various installers. They install the patch in /dev_hdd0/tmp/gameboot
webMAN MOD already remaps game_ext_plugin.sprx if it is found in that path.

I don't have that game, so I haven't tested the patches. It should be safe to use, since it isn't touching dev_flash.
But as it is a system file, I warn that install them at your own risk.
Click to expand...

I am not sure if it is the right solution. I think the game_ext_plugin needs to be patched on the fly when the ps2_netemu mounted game is launched by the payload. Because of the LV2 reset, the changes are temporary and they will be reverted after exiting the PS2 game.
 
Agrippa said:
I have already explained how the LC validation does work. @aldostools, I have tested the newest version of the MAMBA payload and the Ape Escape does not pass the LC check. The CRC-16 is not meant to be recalculated, it needs to be read from the .LSD file precisely, because of the issue I mentioned earlier (sectors could have altered checksum only without the data at all, recalculation will repair them as a result). That is why .SBI files could not work right out of the box, as the most important CRC value is missing there.

I am not sure if it is the right solution. I think the game_ext_plugin needs to be patched on the fly when the ps2_netemu mounted game is launched by the payload. Because of the LV2 reset, the changes are temporary and they will be reverted after exiting the PS2 game.
Click to expand...

I tested the Spain version and I couldn't pass the main menu.
It doesn't read the controller. I'm not sure if there is a compatibility issue with Ape Escape or if it is related to LibCrypt.
 
You must log in or register to reply here.

Similar threads

Back
Top