PS3 Disc Layer Encryption

[Vigilante]

Does anyone here have any details about how the PS3 decrypts the software cryptographic layer (layer protection) from PS3 BD game discs?

As some of you may know, game data that is read out in PS3 linux (from /dev/cdrom) or from certain PC Bluray drives (for instance, the ASUS BC-08B1LT with 1.03 firmware and Samsung SH-B083L), still contains a layer or protection. Here is some old info from mathieulh about this subject:

Disclaimer: I am not perfect, although I believe this thread to be accurate I may still have done mistakes, if you find any feel free to correct me about it.

Here is how I believe (after a bit of investigation) the playstation 3 discs' authentication procedure is being held:

Whenever you insert a disc (bluray one that is) the ps3 drive will look at a special area of the disc called the Pic Zone (the BD ROM Mark is actually used in movie discs but not in game unlike what I first thought).
The PIC Zone which stands for Permanent Information & Control data Zone contains informations/data related to the disc's authentication which is done by the playstation 3 bluray drive. This area cannot easily be dumped (you'd pretty much need a bluray drive with a hacked firmware) and of course that specific area cannot be burned on any kind of discs or with any kind of burners commercially available.

There is no absolute certainty to what data the PIC zone actually contains, I initially thought that Sony would use a public/private cryptography cypher to authenticate the discs but that is quite unlikely considering the limited resources of the drive controller. There isn't any kind of hard cryptographic layer on the discs as I first expected, so the security on the discs themselves is much less invasive as I initially thought. Yet the fact that the PIC zone can't be rewitten without any kind of special equipment (basically a bluray discs factory) does its job well when it comes to preventing backups.

The authentication procedure itself is done through the use of a per bluray drive key pair, one being located on the drive controller itself while the other is stored encrypted in the playstation 3's EID area located on NAND. This key is also used while updating the drive which firmware's will be physically re-encrypted using that very same key and stored that way. As such you cannot swap a drive controller board from one ps3 to another, at least on earlier "fat" models. I have no idea if the drives are still paired with unique keys on the newer "slim" systems, though I do not know why it would be done another way. This also means that physically dumping the drive's firmware would lead nowhere with it being stored in an encrypted form. The only way to get a plain version of it would be to dump the drive controller's ram at runtime. Beside although I am not entirely sure about this, it is very unlikely that a command exists to read the firmware from the drive, should it exist, the dumped binary would still be encrypted, thus connecting the drive to a computer (the ps3 slim bluray drive uses a regular SATA or PATA bus depending on the model) literally leads nowhere..

Finally once the authentication procedure is done, there is another protection which happens to be a per sector software cryptographic layer, which I have the algorithm for (but which I can't share because I wasn't the one that initially reversed it) that cryptographic layer is the very same used on playstation 3 master discs as on retail ones with the exception of the key being used, masterdiscs are identified through their special masterdisc sectors locted at offset 0x7000 (sector 14) on the disc. The encryption itself is done in sector ranges rather than files, where the key for each sector is defined by the address of the said sector in correlation with an initial static key, on retail discs, there is a per disc key located at offset 0x800 on the disc with a header composed of "Playstation3" and the discs' title id such as "PlayStation3 BCES-00141" I assume that this key is in encrypted format and likely decrypted through lv2 by appldr.
The software cryptographic layer is done in such way that the disc sectors will be transparently decrypted so long as you are running a game or a playstation 3 application, this explains how easy it is to dump a disc's content whenever you can run playstation3 code on top of lv2.

The EBOOT.BIN as well as other self and sprx binaries themselves aren't tied to the disc's encryption, however their metadata may contain specific flags (in fact the ones on game discs always do) that will prevent them from being loaded from anywhere other than an authenticated disc (masterdiscs != authenticated discs) This would explain why someone on a debug console for instance can't just grab the games' binaries, put them on a masterdisc and hope for the game to just play. Other flags are being involved such as a "no debug" flag that will pretty much prevent you from loading your binary into sony's debugger.

Because the binaries on the discs still have to be signed as they are verified and decrypted by appldr, in the event that you would somewhat trick the drive into thinking that your disc is a genuine playstation 3 disc, you could still not have your own fself ("fake" secure elf, complied with Sony's sdk) in there and get it to run, thus this would never lead to homebrews no matter what some clueless people may claim about it.

Does anyone have more info on the algoritm that mathieulh is mentioning? Is it somehow related to the ENCDEC device?

I've also tried graf's ps3dm_sm tool with his kernel with the following commands that are used for authenticating BD discs (hoping that this would somehow decrypt the game data):

drive_auth 0x29
drive_auth 0x46
drive_ctrl 0x53

Where the drive_auth is called 0x5004 in some of the documentation and drive_ctrl is called 0x5007... However, the /dev/cdrom output remains the same, so maybe the BD drive is already authenticated in linux, and the layer encryption is processed at a later stage.

The purpose of this post is to basically open the road to decrypted sector-based (.iso format) game dumps rather than the current (jailbreak) file-based dumps, and to increase the understanding of how the PS3 decrypts the game data, by finding out how to descramble the software cryptographic layer. Maybe this can also be done without the need of a console.

Thanks in advance for any feedback

[tiefputin1]

from what i debugged, its a bunch of xors
with many table(s)..
done sectorwise (0x810 bytes)
i havent checked for more yet...but definitely want to.
i dont got any encryped retail bd iso tho - we dont need it actually as we can just copy everything decrypted from ps3

[Vigilante]

from what i debugged, its a bunch of xors
with many table(s)..
done sectorwise (0x810 bytes)
i havent checked for more yet...but definitely want to.
i dont got any encryped retail bd iso tho - we dont need it actually as we can just copy everything decrypted from ps3

Is there any way to obtain those tables?

Also, do you know which keys are being used in the process? The disc key in sector 2 of the iso for instance, is it encrypted like mathieulh was saying?

And if you say the sector is 0x810 bytes, does that mean it needs the extra 2064-2048 = 16 bytes for decrypting?

Thanks

[Vigilante]

Thought it was time to dig up this old topic, because the algoritm appears to be shared now on the developer wiki (look under 'Basic Bluray disc authentication procedure')

// do crypt
unsigned char sector_key[16];
memset(sector_key, 0, 16);
sector_key[12] = (sector_num & 0xFF000000)>>24;
sector_key[13] = (sector_num & 0x00FF0000)>>16;
sector_key[14] = (sector_num & 0x0000FF00)>> 8;
sector_key[15] = (sector_num & 0x000000FF)>> 0;

// encrypt sector
aes_context aes_ctx;
aes_setkey_enc(&aes_ctx, G_DEBUG_KEY, 128);
aes_crypt_cbc(&aes_ctx, AES_ENCRYPT, aligned_size, sector_key, buff, buff);

// decrypt
aes_context aes_ctx;
aes_setkey_dec(&aes_ctx, G_DEBUG_KEY, 128);
aes_crypt_cbc(&aes_ctx, AES_DECRYPT, aligned_size, sector_key, buff, buff);

However, it's still unclear to me how the per disc key can be obtained... Game discs have a 512 bytes block in sector 2 (or 0x800), of which 448 bytes appear to be scrambled. Since the disc key is only supposed to be 16? bytes, I wonder if anyone knows how to retrieve this key.. I suppose the block is a table that is encrypted?

TIA