The ps3 disc authentication procedure explained.

[qqqqqqqqqq]

"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."

"Some more news, I have managed to dump the per drive pairing key. On retail consoles the key is random, however on debug ones the key is filled with 0xFF. I am fairly confident that the drive key is OTP. Also after doing a drive unit to pair the drive, I noticed that a debug console won't accept burned masterdiscs as I use a retail drive on it (retail bluray discs work fine, masterdiscs appear as data discs) considering the firmware on debug and retail drives are the same, my guess is that the firmware will check its per drive key and will only allow masterdiscs if that key is set to 0xFFFFFFFFFFFFFFFF furthermore, the fact that the drive key is always the same on debug consoles suggests that we can swap 2 debug controller boards without doing a drive init/pairing."

"The key on the drive side seems OTP to me. The pairing changes the key on the motherboard side, it retrieves the key from the drive and applies it to the EID."

"SCE was dumb enough to put the OTP key outside of the protected drive firmware, and made it 32 bits."


Source: The ps3 disc authentication procedure explained. - LAN.ST

[qqqqqqqqqq]

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 don't think this is completely correct. It is true that it looks to be impossible to switch drive boards[*] but I don't think the firmware is encrypted with the unique key simply because it appears possible to swap flashroms between bluray boards. In fact, this is a necessary step according to the sellers of replacement bluray boards. I have yet to actually try swapping flashes myself, so I'm not actually 100% sure this is true, but I see little reason to doubt it, taking into consideration that when using a non-matched board, the drive is not actually completely dead: everything works (eject button, motors etc.) except the communication with the mainboard.

My speculation is that it might work something like this: the unique "pairing key" that binds together bluray board and mainboard is stored in the bluray board flash, and the flash is then encrypted with a (different) cipher key that's shared between all bluray boards. If Sony were smart they have kept this cipherkey strictly in the CXD5063 chip to make it difficult to obtain. Obviously there is also no reason for a cleartext (or even encrypted) firmware to ever leave the RAM embedded in the chip either, but who knows? Security is never the number 1 objective...

During an update, the bluray firmware comes already pre-encrypted in the update package, but the pairing key is naturally set to a dummy value. The Cell can't actually set the proper pairing key because even it does not know how to decrypt/encrypt the bluray firmware (separation of privileges).

Instead the Cell sends the encrypted firmware package to the Bluray processor (CXD5063) which is the only component in the PS3 able to decrypt and authenticate it. The proper pairing key is finally set and the firmware re-encrypted and written to the flashrom.

If this scenario is actually true, it is indeed a weakness that the cipherkey is not unique. Should an adversary be able to obtain it, it would be possible to alter the firmware and have it work on "all" consoles. Of course, the problem is still to obtain it...[*] Despite rumours to the contrary, eg that if numbers and digits on the two drive boards match then it's possibel to swap them. Whatever! I have empirically tried more than a dozen different boards - none of them had the same key; obviously none of them worked.

[qqqqqqqqqq]

"I never tried actually swapping the nand on the drive controller boards, I do know however than when you dump the firmware on drives that are on the same revision and on the same firmware, the content is different between both (although they share a common header) the firmware also happens to be different from the one extracted from the bluray drive update package if I remember well, so something is definitely at hand here, of course I could be wrong about this.

As for the drive itself, it should work properly even if not paired with the mainboard for pretty much everything but the disc authentication procedure, which seems to be more or less the only time when the key is in use. Of course I could be wrong about this too.

Also your theory is precisely what I thought of, while updating, it isn't the cell that re-encrypts the firmware, the firmware is re-encrypted on the drive controller where the per drive key is likely stored and never leaves that place. My belief is that the pre-encrypted "to be flashed" firmware is encrypted with a generic key which the previously flashed firmware has, this key is then used to decrypt and authenticate the new firmware which is then cached in the drive controller ram somehow (it doesn't need to be entirely cached, it can be splitted and encrypted in chuncks) then the drive controller firmware which is still running will re-encrypt the new one using the per drive key and write it to the nand. The real question is if there is enough ram available for the drive controller to perform this operation while still being cached into memory? Also it is very unlikely that a new pairing key is set every time the firmware is updated because the EID never changes and that's where the key pair for the motherboard is stored.

Finally you should also consider that something (a rom) also happens to hold the code that will decrypt the firmware on the drive, otherwise it would be impossible for the drive's cpu to jump to it."

[qqqqqqqqqq]

"Well, that the resultant cipher texts are different despite same board revisions and firmware, doesn't necessarily mean different keys are used. The "pairing key" would be different between the two, and some IV could be used precisely to make the outputs different.

Yeah, I'm thinking the initial code resides in an embedded ROM. It fetches the contents of the flashrom, decrypts it and then runs it. Although it is possible there is a hardware fetching and decrypting the flash. In either case, it means the key is not changeable.

Heh, please forget about the part I wrote about "swapped bluray boards still work". There's no reason they wouldn't of course (the MCU and flash are still matched regardless) and it's completely irrelevant to my point about swapped flashes, don't know what I was thinking there!

Only actually moving a flashrom to a new bluray board and verify whether it still works will determine whether "cipher keys" are unique or shared.

I would try it, except most of my PS3 wares are non-functional, and it's not that valuable information anyway, at least not for me to want to risk one of my live units. There are more interesting areas to research, and time is precious. Well, maybe I will try it anyway, I need more BGA soldering practice."

[qqqqqqqqqq]

I've seen in hacking old consoles where people would overclock a chip to the point it'd cause some form of race condition and write out it's code to some other bus. This Sony chip also probably has a cache somewhere internally.

it seems CFW isn't all that's needed for backups, unless you do some hardcore cryptography reversing and make an emulator. Isn't it possible under this system to rebuild these game binaries and load through otherOS? It seems outside that disc authentication it's still possible to rebuild their actual code base with patches, then package game disks also by rebuilding(all based on RCE findings.)

Game binaries still have to run on top of lv2, not to mention that they actually need to be decrypted by appldr (though the last part can be done from otheros)

It'd be easier to decrypt lv2, patch it and load the patched version (which would always mount your discs as authenticated ones). That's if you want backups, homebrews need much more invasive patches on retail systems, This is mostly due to the fact that appldr is the one checking the binaries' signatures which will only be returned to the xdr if the check and decryption passes. You cannot load fself either because appldr will check your console's target id and if it doesn't match the one of a debug system (0081 or 0082) it wont return the binary to the xdr. (it will return an error instead). lv2 itself has no code to check the selfs signatures, decrypt them, deflate them or load them into memory. It would have to be added straight into the kernel should you want to run unsigned "application" code, that or you would have to exploit appldr. More than that, I wont tell.

[garyopa]

Welcome to year 2007, this is so F*cking old it is not funny any more. I didn't know we had invented a "time-machine". Thanks

[qqqqqqqqqq]

Have you even checked the link posted?

"UPDATE: Thread now updated with much more accurate informations." - Mathieulh 08-15-2010

Besides, not only because something is old it should be ignored. With development this can become a huge step in authenticating discs for the PS3

[afiser]

Have you even checked the link posted?



Besides, not only because something is old it should be ignored. With development this can become a huge step in authenticating discs for the PS3

its not like it is something that was worth reversing in the first place, im not really sure why mathieulh wasted his time with it to begin with.

[garyopa]

Mathieulh 08-15-2010 - Well even if it was updated, it was week before the first PSJailbreak dongle was released.

Since then people have advanced long past this information, we can decrpyt binaries, we know how the chain of trust works now, we can even re-marry drive boards, even restore lost blu-ray function!

[xPreatorianx]

Well even the PIC zone isn't that absolute. As on 3.15 CFW you were able to use Swiss army knife and rip a BD disc with it directly on the PS3. I ripped my copy of Evangelion 1.11 with the PS3. I don't know about 3.55 CFW but I would imagine swiss army knife could be ported over to it if someone can find the distro/source code.

As for CFW on the BD drive - I have no idea but I love the information at the top.

EDIT: NVM further down the post pretty much explains why it is so easy to dump either a game or a movie on the PS3. Plus all of this info is old. Please check the dates on things before posting them. Everything that is being described has been done in some way or another.