Basic Bluray disc authentication procedure: Difference between revisions
(Created page with "This is based on my (mathieulh) post in lan.st: http://lan.st/showthread.php?t=1722 and will need further editing and additions that will happen soon. So far this article is a 1:...") |
|||
| (11 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
== PIC Zone == | |||
Whenever you insert a Blu-Ray disc, the PlayStation 3 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). | Whenever you insert a Blu-Ray disc, the PlayStation 3 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 information/data related to the disc's authentication which is done by the Blu-Ray drive. This area cannot easily be dumped (you'd pretty much need a Blu-Ray 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. | The PIC Zone (which stands for Permanent Information & Control data Zone) contains information/data related to the disc's authentication which is done by the Blu-Ray drive. This area cannot easily be dumped (you'd pretty much need a Blu-Ray 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 cipher 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 does its job well when it comes to preventing backups. | There is no absolute certainty to what data the PIC Zone actually contains. I initially thought that Sony would use a public/private cryptography cipher 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 does its job well when it comes to preventing backups. | ||
See also [[Disk_Identification/Serialisation_Data]] | |||
== Authentication == | |||
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 AES256CBC encrypted in the EID2 area located on [[Flash]]. This key is also used while updating the [[Bluray Drive]], which firmware's will be physically re-encrypted using that very same key and stored that way. As such you cannot swap a [[Bluray Drive]] controller board from one ps3 to another - see [[Remarry Bluray Drive]]. | |||
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 [[Bluray 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 [[Bluray Drive]], should it exist, the dumped binary would still be encrypted, thus connecting the [[Bluray Drive]] to a computer literally leads nowhere. | |||
== Disc de-/encryption == | |||
Finally once the authentication procedure is done, there is another protection which happens to be a per sector software cryptographic layer. | |||
algo for masterdiscs | |||
{{info|content=<pre>// 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);</pre>}} | |||
genelib.dll (from SDK generator tools) has the static keys for masterdiscs | |||
{{info|content=<pre>genelib.dll (Build 1.20.2662.20880): | |||
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F | |||
00034C80 67 C0 75 8C gÀuŒ | |||
00034C90 F4 99 6F EF 7E 88 F9 0C C6 95 9D 66 ô™oï~ˆù.Æ•.f</pre> | |||
<pre>genelib.dll (Build 2.50.3551.37780): | |||
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F | |||
00063E80 67 C0 75 8C gÀuŒ | |||
00063E90 F4 99 6F EF 7E 88 F9 0C C6 95 9D 66 ô™oï~ˆù.Æ•.f</pre> | |||
<pre>genelib.dll (Build 2.89.3859.40033): | |||
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F | |||
00068E80 67 C0 75 8C gÀuŒ | |||
00068E90 F4 99 6F EF 7E 88 F9 0C C6 95 9D 66 ô™oï~ˆù.Æ•.f</pre> | |||
<pre>genelib.dll (Build 3.0.3912.20935): | |||
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F | |||
00069E80 67 C0 75 8C gÀuŒ | |||
00069E90 F4 99 6F EF 7E 88 F9 0C C6 95 9D 66 ô™oï~ˆù.Æ•.f</pre> | |||
<pre>genelib.dll (Build 3.12.4159.28611): | |||
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F | |||
0006BE80 67 C0 75 8C gÀuŒ | |||
0006BE90 F4 99 6F EF 7E 88 F9 0C C6 95 9D 66 ô™oï~ˆù.Æ•.f</pre> | |||
<pre>genelib.dll (Build 3.30.4566.37128): | |||
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F | |||
00072E80 67 C0 75 8C gÀuŒ | |||
00072E90 F4 99 6F EF 7E 88 F9 0C C6 95 9D 66 ô™oï~ˆù.Æ•.f</pre>}} | |||
you can also get it from sv_iso_spu_module | |||
{{info|content=<pre>sv_iso_spu_module 1.02-3.55 | |||
key_0: EF4F6A107742E8448BC1F9D8F2481B31 //key_0 is an aes_cfb128 iv | |||
iv_0: 2226928D44032F436AFD267E748B2393 | |||
key_0_0: 126C6B5945370EEECA68262D02DD12D2 //key_0_0 is used with iv_0 to generate gen_key_0 | |||
key_0_1: D9A20A79666C27D11032ACCF0D7FB501 //key_0_1 is used with iv_0 to generate gen_key_1 | |||
key_1: 7CDD0E02076EFE4599B1B82C359919B3 //key_1 is used with iv_0 | |||
iv_1: 3BD624020BD3F865E80B3F0CD6566DD0 //iv_1 is used with gen_key_0 and gen_key_1 | |||
key_2: 380BCF0B53455B3C7817AB4FA3BA90ED //key_2 + iv_2 are used to generate something from the disk name (id?) | |||
iv_2: 69474772AF6FDAB342743AEFAA186287 | |||
debug_disc_fallback: 67C0758CF4996FEF7E88F90CC6959D66 //this fallback is used if the disk name (id?) is 'PS3_L_DEBUG_DISC'</pre>}} | |||
The cryptographic layer is the very same one used on PS3 master discs as on retail ones with the exception of the key being used. Masterdiscs are identified through their special masterdisc sectors located 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 using proper syscalls (e.g. running a game or a playstation 3 application), this explains how easy it is to dump a disc's content whenever you can run PS3 code on top of lv2. | |||
== Software layer == | |||
See also [[SELF - SPRX]]. | |||
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. | 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 | 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 PS3 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. | ||
'''Old (very incomplete) source: https://web.archive.org/web/20111010182129/http://lan.st/showthread.php?t=1722''' | |||
{{Reverse engineering}} | |||
<noinclude>[[Category:Main]]</noinclude> | |||
Latest revision as of 09:30, 19 March 2022
PIC Zone[edit | edit source]
Whenever you insert a Blu-Ray disc, the PlayStation 3 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 information/data related to the disc's authentication which is done by the Blu-Ray drive. This area cannot easily be dumped (you'd pretty much need a Blu-Ray 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 cipher 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 does its job well when it comes to preventing backups.
See also Disk_Identification/Serialisation_Data
Authentication[edit | edit source]
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 AES256CBC encrypted in the EID2 area located on Flash. This key is also used while updating the Bluray Drive, which firmware's will be physically re-encrypted using that very same key and stored that way. As such you cannot swap a Bluray Drive controller board from one ps3 to another - see Remarry Bluray Drive.
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 Bluray 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 Bluray Drive, should it exist, the dumped binary would still be encrypted, thus connecting the Bluray Drive to a computer literally leads nowhere.
Disc de-/encryption[edit | edit source]
Finally once the authentication procedure is done, there is another protection which happens to be a per sector software cryptographic layer.
algo for masterdiscs
// 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);
genelib.dll (from SDK generator tools) has the static keys for masterdiscs
genelib.dll (Build 1.20.2662.20880): Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00034C80 67 C0 75 8C gÀuŒ 00034C90 F4 99 6F EF 7E 88 F9 0C C6 95 9D 66 ô™oï~ˆù.Æ•.f
genelib.dll (Build 2.50.3551.37780): Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00063E80 67 C0 75 8C gÀuŒ 00063E90 F4 99 6F EF 7E 88 F9 0C C6 95 9D 66 ô™oï~ˆù.Æ•.f
genelib.dll (Build 2.89.3859.40033): Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00068E80 67 C0 75 8C gÀuŒ 00068E90 F4 99 6F EF 7E 88 F9 0C C6 95 9D 66 ô™oï~ˆù.Æ•.f
genelib.dll (Build 3.0.3912.20935): Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00069E80 67 C0 75 8C gÀuŒ 00069E90 F4 99 6F EF 7E 88 F9 0C C6 95 9D 66 ô™oï~ˆù.Æ•.f
genelib.dll (Build 3.12.4159.28611): Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0006BE80 67 C0 75 8C gÀuŒ 0006BE90 F4 99 6F EF 7E 88 F9 0C C6 95 9D 66 ô™oï~ˆù.Æ•.f
genelib.dll (Build 3.30.4566.37128): Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00072E80 67 C0 75 8C gÀuŒ 00072E90 F4 99 6F EF 7E 88 F9 0C C6 95 9D 66 ô™oï~ˆù.Æ•.f
you can also get it from sv_iso_spu_module
sv_iso_spu_module 1.02-3.55 key_0: EF4F6A107742E8448BC1F9D8F2481B31 //key_0 is an aes_cfb128 iv iv_0: 2226928D44032F436AFD267E748B2393 key_0_0: 126C6B5945370EEECA68262D02DD12D2 //key_0_0 is used with iv_0 to generate gen_key_0 key_0_1: D9A20A79666C27D11032ACCF0D7FB501 //key_0_1 is used with iv_0 to generate gen_key_1 key_1: 7CDD0E02076EFE4599B1B82C359919B3 //key_1 is used with iv_0 iv_1: 3BD624020BD3F865E80B3F0CD6566DD0 //iv_1 is used with gen_key_0 and gen_key_1 key_2: 380BCF0B53455B3C7817AB4FA3BA90ED //key_2 + iv_2 are used to generate something from the disk name (id?) iv_2: 69474772AF6FDAB342743AEFAA186287 debug_disc_fallback: 67C0758CF4996FEF7E88F90CC6959D66 //this fallback is used if the disk name (id?) is 'PS3_L_DEBUG_DISC'
The cryptographic layer is the very same one used on PS3 master discs as on retail ones with the exception of the key being used. Masterdiscs are identified through their special masterdisc sectors located 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 using proper syscalls (e.g. running a game or a playstation 3 application), this explains how easy it is to dump a disc's content whenever you can run PS3 code on top of lv2.
Software layer[edit | edit source]
See also SELF - SPRX.
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 PS3 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.
Old (very incomplete) source: https://web.archive.org/web/20111010182129/http://lan.st/showthread.php?t=1722
