LibCrypt protected PS1 games modchip question

Discussion in 'General Gaming' started by helakustorm, Oct 23, 2018.

  1. helakustorm

    helakustorm Robust Member

    Joined:
    Oct 16, 2016
    Messages:
    205
    Likes Received:
    10
    Somebody knows if it's possible to patch/crack libcrypt protection from the modchip on PlayStation consoles?
    I know you can manually patch a game using cracks but I wanted to know if exist a way to circumvent this protection.

    Thanks!
     
    Last edited: Oct 23, 2018
  2. djelaba

    djelaba Benzin !, Site Supporter 2013

    Joined:
    May 12, 2005
    Messages:
    256
    Likes Received:
    11
    No. Libcrypt protection uses data from the CD to create a key, used to check if the CD is a copy or an original.

    That's why crackers used tools to fetch that key, and use it for their cracks.
     
  3. helakustorm

    helakustorm Robust Member

    Joined:
    Oct 16, 2016
    Messages:
    205
    Likes Received:
    10
    I was thinking like a modchip that have a database inside with all cracked libcrypt games; when a game is checked and have a libcrypt protection to activate/apply that crack.
     
  4. iCEQB

    iCEQB Peppy Member

    Joined:
    Feb 22, 2008
    Messages:
    322
    Likes Received:
    36
    Why would you do that? Just create proper backups with the subchannel data present and you are golden.
     
  5. helakustorm

    helakustorm Robust Member

    Joined:
    Oct 16, 2016
    Messages:
    205
    Likes Received:
    10
    My question is from a developtment point; I know how to make a proper rip.
    I wanted to know if this is doable or not.

    Thanks!

    P.S. You will be amazed how many people do not know how to do a proper rip or to crack a game for example.
     
  6. Bad_Ad84

    Bad_Ad84 The Tick

    Joined:
    May 26, 2011
    Messages:
    8,346
    Likes Received:
    1,114
    No, modchips on ps1 dont work like that. They have no idea what game is being played.
     
    helakustorm likes this.
  7. iCEQB

    iCEQB Peppy Member

    Joined:
    Feb 22, 2008
    Messages:
    322
    Likes Received:
    36
    From a development point of view it's probably hard to accomplish because you'd have to figure out when the game wants to check for certain subchannel data. The chip would probably have to monitor requests to the drive when requests fly in to read libcrypt sectors - and then inject the data back to the playstation.
     
    helakustorm likes this.
  8. rama

    rama Gutsy Member

    Joined:
    Dec 17, 2015
    Messages:
    465
    Likes Received:
    107
    Yeah, super difficult.
    Capture and decode CD data to recognize the game (might build a PSIO at this point!), look for the key reading routine without knowing when it happens, patch the subcodes to be invalid in just the right way...
    This is too big :p
     
    helakustorm likes this.
  9. helakustorm

    helakustorm Robust Member

    Joined:
    Oct 16, 2016
    Messages:
    205
    Likes Received:
    10
    I always lived with the impression that a modchip can inject a code into the console to bypass a libcrypt game.
    By the way, from your point of view what cracks do, to a game that a modchip cannot???
    Can someone explain me?
    I don't understand very good how the libcrypt protection works :(

    Thank you very much!
     
  10. iCEQB

    iCEQB Peppy Member

    Joined:
    Feb 22, 2008
    Messages:
    322
    Likes Received:
    36
    There are two kinds of protections for PS1 games.
    - One method is that the game checks if the drive controller is spammed with the correct SCEx code the whole time. That's how first modchips worked. Later on when the first "stealth" chips appeared, the chips stopped to send the SCEx code to the drive controller after the game boot which rendered them undetectable.

    - The second method is the LibCrypt method, where subchannel data is "corrupted" on purpose and contains data that the game code can check at random points in the game. If the returned data is not correct, the game either locks up, or displays an error message.
    These modified subchannels can be copied when you have a SAO / DAO capable disc writer.
    Back in the day these were pretty expensive, so the alternative was to crack the game code to not look for this subchannel data and therefore continue to work.
     
    helakustorm likes this.
  11. helakustorm

    helakustorm Robust Member

    Joined:
    Oct 16, 2016
    Messages:
    205
    Likes Received:
    10
    Love you guys :D
    Now I understand, the modchip cannot access that area to inject the modified code for the console to let the game work like a crack do for the game.
    Correct?

    Thanks!
     
    Last edited: Oct 24, 2018
  12. rama

    rama Gutsy Member

    Joined:
    Dec 17, 2015
    Messages:
    465
    Likes Received:
    107
    The corrupted data is the CRC checksum for a sector (or an amount of them, not sure).
    If you burn an iso, your burner creates new CRC for the burned sectors.
    The CRC checksum is an important part of the error correction in CDs, so messing with it is not trivial.
    LibCrypt does it anyway, to produce sectors that the PSX will then detect as having errors, in just the right way as to produce a key.

    It is far easier to remove that key check from the software, than it is to recreate deliberate CRC errors in hardware.
     
    helakustorm likes this.
  13. TriMesh

    TriMesh Site Supporter 2013-2017

    Joined:
    Jul 3, 2008
    Messages:
    2,133
    Likes Received:
    630
    Not quite - LibCrypt doesn't do anything at all to the data CRC, it just (intentionally) corrupts the subcode CRC for certain sectors. The reason for this is that although the PSX CD-ROM drive can't directly read the subcode you can use CD command 0x11 to return the last position value extracted from the subcode. On a normal disc, this will increment on every sector, but if the CRC subcode is bad it will retain the previous value and hence if you get the previous sector address rather than the expected one you can infer the subcode is bad there.

    There are 16 sector numbers (one for each bit of the key) - if the sector is normal then the corresponding bit of the key is a '0' and if it's modified then the corresponding bit of the key is a '1'. In theory, these modified sectors could be anywhere on the disc, but in practice they are always stored in the same sectors. There is also an additional set of (potentially) modified sectors stored at a constant offset of 5 sectors from the first ones that are used as a confidence check.
     
  14. davesandell

    davesandell Member

    Joined:
    Oct 2, 2012
    Messages:
    17
    Likes Received:
    1
    So that is why you need to patch a game that comes from a BIN+CUE rather than a "correct" backup direct from a pressed disk?
    As I now avoid creating an image file on the PC first when creating backups of my PSX games.....
     
  15. TriMesh

    TriMesh Site Supporter 2013-2017

    Joined:
    Jul 3, 2008
    Messages:
    2,133
    Likes Received:
    630
    It depends what sort of backup it is. Programs like CloneCD write in a mode called DAO-RAW+96 where every bit that's written to the disc is contained in the image file and there is an additional 96 byte block for each sector that contains the subcode. A correct image of this type written on a drive that supports it will boot a libcrypt protected game without problems.

    If you image a disc in bin+cue mode then the resulting bin file contains only the sector data and no subcode, so the drive will generate a new subcode when it's written. The overall result of this is that when you try to boot it none of the subcode shows as modified and hence the resulting key value is "0x0000" (since non modified sector = 0).

    The reason for the extra set of modified sectors at an offset of 5 from the original ones is that the designers of libcrypt obviously recognized that you do get read errors on CDs - and if one happened to occur at the point in time where the drive was reading the subcode on one of those special sectors that had been written to encode a zero then it would result in that key bit being flipped to one, and the game crashing sometime later. Hence the pairs of sectors - if the code detects that one shows as "modified" but the other doesn't then it's assumed to be an actual disc error and the key bit is assigned the value of zero. Only if both the sectors read as modified is the key bit set to 1.

    This is also the reason that libcrypt backups were seen as being unreliable - if the read error occurs at the point of image creation then the resulting image will always show that sector as being modified and a subsequent random error on the other sector of the pair will result in the corresponding key bit (which should be zero) being flipped to a one and the game crashing.

    So the most reliable way is to start from an image type (like bin+cue) that contains no subcode, create a new clean subcode for it and then inject only the errors that are supposed to be there. The other approach is to patch the code so that it always uses the correct key no matter what it reads off the disc - this is generally simpler and was what was usually done.

    I did see one hacked game that used a different approach - it didn't make any changes to the code at all, but instead re-encoded the data on the disc so that it was expecting the 0x0000 key you get when you burn the image normally. Leaving the code like that means that you don't have to search for and remove any checks for modified code, since there isn't any.
     
  16. davesandell

    davesandell Member

    Joined:
    Oct 2, 2012
    Messages:
    17
    Likes Received:
    1
    Now I am understanding :)
     

Share This Page