Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
20th March 2018, 21:12 | #1 | Link |
Registered User
Join Date: Jun 2005
Posts: 259
|
PlayStation 3
As we all know, a long time ago the PS3 was hacked and its bluray device keys and host certificate were leaked. The device keys decrypt discs up to MKBv30 and host certificate FFFF80000039 was revoked in MKBv32. The device keys are in the latest KEYDB.cfg but are incorrectly listed as processing keys
Code:
| PK | 0x810827A76E5B2CC1685E3217A23E2186 ; DK_V01-V12 | PK | 0x44145A846F19D096F2C84A2E50C5C4F5 ; DK_V14-V16 | PK | 0xEB55A475080FBCF18534EFA0839A7373 ; DK_V17-V19 | PK | 0xFB4AC39009E82113D45ECF4B7EAEA467 ; DK_V20-V21 | PK | 0x8BF4FBD91A7FB7DB8576D1E5A15A8544 ; DK_V23-V28 Code:
| DK | DEVICE_KEY 0x810827A76E5B2CC1685E3217A23E2186 | DEVICE_NODE 0x0389 | KEY_UV 0x00000100 | KEY_U_MASK_SHIFT 0x17 | DK | DEVICE_KEY 0x44145A846F19D096F2C84A2E50C5C4F5 | DEVICE_NODE 0x0389 | KEY_UV 0x00000280 | KEY_U_MASK_SHIFT 0x09 | DK | DEVICE_KEY 0xEB55A475080FBCF18534EFA0839A7373 | DEVICE_NODE 0x0389 | KEY_UV 0x00000340 | KEY_U_MASK_SHIFT 0x08 | DK | DEVICE_KEY 0xFB4AC39009E82113D45ECF4B7EAEA467 | DEVICE_NODE 0x0389 | KEY_UV 0x00000384 | KEY_U_MASK_SHIFT 0x07 | DK | DEVICE_KEY 0x8BF4FBD91A7FB7DB8576D1E5A15A8544 | DEVICE_NODE 0x0389 | KEY_UV 0x00000384 | KEY_U_MASK_SHIFT 0x05 Code:
./aacs_proc_key -n 0x389 -k ps3_device_keys -u ps3_device_key_u_masks_uvs mkbs/MKB_RW_v3.inf - ps3_device_keys: contains 253 DEVICE_KEY (=253x16bytes) - ps3_device_key_u_masks_uvs: contains 253 KEY_U_MASK_SHIFT + KEY_UV (=253x5 bytes) corresponding to the 253 device keys Nothing we didn't know but then I found another AACS section on PS3DevWiki with a mysterious pastebin link [Another decrypted arrays with this key] The pastebin post contains 3 arrays: - array1 = ? - array2 = looks like an updated version of ps3_device_key_u_masks_uvs (253x5 bytes, same format just some updated values) - array3 = host certificate CFFFF80000146 which was revoked in MKBv58 Since the private key for this new host certificate was later posted here and array2 seems to be new uv data, I'm wondering if the PS3 device keys were found a second time. Those should work until around MKBv58 when the host certificate was revoked. However, they are not in array1. As far as I understand there should always be 253 keys which isn't the case. I also tried to use array1 with aacskeys which doesn't require the uv data but it doesn't work with any MKB version I tried. Anyone have an idea what array1 might be or if there is any updated version of the file ps3_device_keys floating around? Or is it a dead end? |
22nd March 2018, 00:42 | #3 | Link | ||
Registered User
Join Date: Jun 2005
Posts: 259
|
Well you can always suggest better places to ask
Anyway, I found some more things. Here we read Quote:
Quote:
- PS3tools v3.1 [Dev_Flash.exe] to extract dev_flash/bdplayer/AacsModule.spu.isoself from FW file PS3UPDAT.PUP - ps3mfw-builder-0.2.1-mod [scetool.exe] to decrypt AacsModule.spu.isoself Anyone have an idea how to decrypt data using those 2 AES keys? If those arrays are in there, maybe the device keys are too? Being naively optimistic |
||
22nd March 2018, 01:40 | #4 | Link | |
Registered User
Join Date: Jun 2005
Posts: 259
|
Apparently openssl can do it
Quote:
|
|
22nd March 2018, 10:22 | #5 | Link | |
Registered User
Join Date: Jun 2005
Posts: 259
|
Well at least those 3 arrays can be found. Did some dumb bruteforcing using command line tools in a batch file. I created a new file starting at each possible offset in AacsModule.spu.isoself and then decrypted that file using openssl with the 2 AES keys
Quote:
So maybe there's more data in there but now the problem is we don't have any known bytes to search for Last edited by candela; 22nd March 2018 at 11:29. |
|
23rd March 2018, 09:53 | #6 | Link | |
Registered User
Join Date: Jun 2005
Posts: 259
|
As mentioned on ps3devwiki, all FW seem to contain encrypted versions of the following keys
Quote:
Code:
FW3.50 aes-256-ctr_key=D2C573B43D8FCE69C106C8BE472E1464FB08266E53AAD81719A6D7488BDA34D5 aes-256-ctr_iv=A1753E597718BFB2D9FE7DA36F8844AA FW4.46 aes-256-ctr_key=7DFF2E072AC3FC925497DB370E8E2A6AA877F1D371A26B05E00DEFC486364F01 aes-256-ctr_iv=51FADF9CD999B5D0BFA2BCBB2940ADF8 FW4.50 aes-256-ctr_key=D70CEF052C23D824F345F06EDFA80383D0EBB73AD94A5276DF6CE925471C456A aes-256-ctr_iv=3526386D0557FA212013E9E733790708 With the FW3.50 keys I found the following Code:
ps3_device_keys decrypted100112.bin : hit at offset 0x0 >7F4D2002 C4E321EC 795865A8 2BBD7C9F 57CF419C A780B8BC 8CB41911 6AD9F412< .M ...!.yXe.+.|.W.A.........j... 00000000 ps3_device_key_u_masks_uvs decrypted98832.bin : hit at offset 0x0 >02000003 8B030000 038E0300 00038B04 00000384 04000003 8E040000 038B0500< ................................ 00000000 private host private key decrypted95712.bin : hit at offset 0x1 >00668C9A 75EEFC8D A4261938 E2712850 61BB09F0 DDA47C39 5BE465D6 DC7EDFB1< .f..u....&.8.q(Pa.....|9[.e..~.. 00000000 host certificate decrypted95872.bin : hit at offset 0x4 >0201005C FFFF8000 00390000 65EAC987 8B85EFF4 D77A62B1 D600024A CE68DD33 For FW4.46 Code:
host certificate decrypted95872.bin : hit at offset 0x4 >0201005C FFFF8000 00C40000 5BF6843E< ...\........[..> 00000000 host private key decrypted95712.bin : hit at offset 0x1 0088B245 EA25315F 46E6E99D 9D521EB1< ...E.%1_F....R.. 00000000 array1 = ? decrypted96016.bin : hit at offset 0x0 053A003D 6A012859 02299503 1C680427< .:.=j.(Y.)...h.' 00000000 For FW4.50 Code:
array1 = ? decrypted131488.bin : hit at offset 0x0 053A003D 6A012859 02299503 1C680427 E1051314 0639FF07 0FF2082E 6C091DC8< .:.=j.(Y.)...h.'.....9......l... 00000000 array3 = host certificate decrypted131328.bin : hit at offset 0x4 >0201005C FFFF8000 01460000 952D611B 06911B0E AEE577D3 715D1FA0 E4059140< ...\.....F...-a.......w.q].....@ 00000000 Also I did some bruteforcing with aacskeys (just copy decrypted data in ProcessingDeviceKeysSimple.txt) but didn't find any device key. Probably they are stored elsewhere or encrypted differently compared to FW3.50. If anyone knows what all those other keys on ps3devwiki are what things like "magic: CODEFACE" mean, please post. It would be nice to know, even if it doesn't lead to anything now. It's always possible the info sparks an idea in someone else Last edited by candela; 23rd March 2018 at 11:29. |
|
23rd March 2018, 11:50 | #7 | Link | |
Registered User
Join Date: Jan 2010
Posts: 74
|
Quote:
|
|
23rd March 2018, 12:01 | #8 | Link |
Registered User
Join Date: Jun 2005
Posts: 259
|
holy crap, check this is out !!!!
Code:
aacskeys 0.4.0f by arnezami, KenD00, Key, Nobu1789, anon Current path: C:\utils\aacskeys-0.4.0f\bin\win64 MKBv: 51 Device key: F2F56575C0C5448042298FA9B316AB9A Processing key: 186D1BBA19487F6450C1FD5ADA9407E6 Encrypted C-value: 6AF01227B7EAFDC3E74628AFAEE8DD66 Corresponding uv: 00000717 Decrypted C-value: 852539E075BC82629C3D469F8EC818B3 Media key: 852539E075BC82629C3D469F8EC81FA4 Encrypted verification data: 28D2CD40A2D8BDF3AA682E4269225E73 Decr verif data should be: 0123456789ABCDEF Decrypted verification data: 0123456789ABCDEF863EBC0C484A5719 |
23rd March 2018, 18:00 | #9 | Link | |
Registered User
Join Date: Jun 2005
Posts: 259
|
Quote:
From FW4.46 Code:
ps3_device_keys decrypted100112.bin : hit at offset 0x0 >8C2E93DD D56D416A 805C02CD F0049897< .....mAj.\...... 00000000 ps3_device_key_u_masks_uvs decrypted98832.bin : hit at offset 0x0 >02000007 1B030000 071E0300 00071B04< ................ 00000000 Last edited by candela; 24th March 2018 at 00:05. |
|
24th March 2018, 00:05 | #10 | Link | |
Registered User
Join Date: Jun 2005
Posts: 259
|
Quote:
Code:
| DK | DEVICE_KEY 0xA088BC72424478EACAF237A9E258351E | DEVICE_NODE 0x718 | KEY_UV 0x00000200 | KEY_U_MASK_SHIFT 0x17 ; MKBv01-MKBv23 | DK | DEVICE_KEY 0x6C02A9C4DF6DE9314F6F4BB44677BD67 | DEVICE_NODE 0x718 | KEY_UV 0x00000500 | KEY_U_MASK_SHIFT 0x0A ; MKBv24-MKBv35 | DK | DEVICE_KEY 0x4D84E4D6D434A08D6EF0B523B6D891B2 | DEVICE_NODE 0x718 | KEY_UV 0x00000680 | KEY_U_MASK_SHIFT 0x09 ; MKBv36-MKBv43 | DK | DEVICE_KEY 0xF2F56575C0C5448042298FA9B316AB9A | DEVICE_NODE 0x718 | KEY_UV 0x00000714 | KEY_U_MASK_SHIFT 0x04 ; MKBv44-MKBv51 |
|
24th March 2018, 00:22 | #11 | Link |
Registered User
Join Date: Jun 2005
Posts: 259
|
Still no idea what array1 is or how to get devkeys from 4.50 and higher. However, I'm now mostly intrigued by the ps3devwiki keys
Code:
private key enc: 05974EA73D2019A1FE03A7F685DCBD5A7D2F07E5BF15DA291B31586C8840C75B private key dec: 004FC12D7464FBFB3E0D5754016AE6867A256C16EA the name, length and leading 00 of private key dec suggests that this is a decrypted host private key. However, it doesn't match the known host private key for the certificate FFFF80000146 Also it's not decoding to that value using the aes-ctr keys. Anyone have idea? maybe encrypted with any of the other keys listed there? |
25th March 2018, 22:37 | #13 | Link | |
Registered User
Join Date: Jun 2005
Posts: 259
|
Quote:
But getting further will require smarter people than myself I'm afraid It seems they changed the protection of the device keys and private key starting from FW4.50. So probably requires debugging to figure it out. I basically just (partially) solved a riddle left by someone on ps3devwiki. Last known processing key was v31 for many years although strangely enough someone posted v36 just a few days ago. So I'm already very satisfied with getting v51. |
|
26th March 2018, 08:58 | #14 | Link | |
Registered User
Join Date: Dec 2017
Posts: 36
|
Quote:
Unfortunately I've no idea how to actually use that curve. |
|
26th March 2018, 10:54 | #15 | Link | |
Registered User
Join Date: Jun 2005
Posts: 259
|
Quote:
Edit: - libaacs crypto.c says the curve is from AACS spec - the aes-128-key/iv must also be in AACS spec, found it in firmware of a different player => so very unlikely these would be used to hide the keys The thing that's new in FW4.50 (and later version) is that "private key enc" so it's our only clue at the moment. Also the newer FW only seem to contain that FFFF80000146 certificate which was revoked in MKBv58. So they can't still be using that or the PS3 couldn't play the new discs. They apparently keep using the aes-256-ctr for device masks though which is odd. Those aren't really useful without device keys but still Last edited by candela; 26th March 2018 at 19:56. |
|
28th March 2018, 00:42 | #16 | Link |
Registered User
Join Date: Jun 2005
Posts: 259
|
So.. it seems the encryption method has changed from FW4.46 to FW4.50. The firmware is 30KB bigger and the private host key is no longer found
I compared FW4.50 and FW4.53 and found that one of the differences is a block of 4048 bytes (=253x16 bytes). It looks exactly the same as the difference between the device key block of FW4.20 and FW4.46. So that block very likely contains the device keys. However, they are not encrypted with the usual aes-256-ctr key like the device key masks. Also the device key masks in FW4.46 and FW4.50 appear to be the same. I'm not sure but I think this means the device keys are also the same. So possibly the only change in FW4.50 is a new host certificate and a different encryption method. Now only to figure out how they are encrypted. |
29th March 2018, 05:56 | #17 | Link |
Registered User
Join Date: Nov 2008
Posts: 62
|
It looks like Sony may be performing AACS authentication with assistance from online servers in some cases. It would make sense, given that modules written for the isolated SPU can be trivially decrypted these days. I read elsewhere that the penalty for a leaked device/processing key or host certificate is quite high.
By the way, where are you getting old versions of the firmware updates? Sony removes them from its public website after new versions are released, and I can only find references to unreliable mirrors on BitTorrent and similar. The ones I'm looking at appear to be for the Japan region, not sure whether the SPU modules will vary be region or not. Last edited by Rupan; 29th March 2018 at 06:00. |
29th March 2018, 09:06 | #18 | Link | |
Registered User
Join Date: Jun 2005
Posts: 259
|
Quote:
I don't have a PS3 but I would find it strange if online connectivity is required to play a Bluray. It could explain why that revoked host certificate is not being changed. Although the new host certificate could just be encrypted differently. I tried something similar to how I found the aes-256-ctr keys for the different FW (there are only 4 sets of those btw: FW1.02-3.74/FW4.00-4.46/FW4.50-4.70/FW4.76-4.82). I used every 48 byte sequence in the FW as an aes-256-ctr_key/iv combo on that 4048 byte block that I assume are device keys. Then I let aacskeys try all the resulting possibilities overnight but turned up nothing. So they are using a different cipher or the keys are no longer present in the FW in the clear. They must still be using the same key for FW that uses the same aes-256-ctr set and some cipher that works on 16 byte sequences since some encrypted keys in the block remain the same between different FW (just like in FW<4.50) I'm also wondering, do these modules have some crc check and stop working when you edit anything? Because otherwise you could take old FW, encrypt the new keys according to the FW version and hexedit them in. The only thing I found about updating AACS keys was signing the complete FW4.50 module with FW4.46 keys (which apparently doesn't work for later versions, but simply replacing keys should keep working, unless there's some check that the module itself hasn't changed). Last edited by candela; 29th March 2018 at 09:16. |
|
29th March 2018, 18:16 | #19 | Link |
Registered User
Join Date: Jan 2010
Posts: 74
|
BD+ also uses some AES keys. Maybe this is what you see in array1?
Connectivity is probably not enforced when using "plain" AACS. However, BD+ can call Java code or even load native platform code, both of which can do anything they want, including network connections. Those can easily require being online to play a movie, whatever the disc manufacturer wants basically. |
30th March 2018, 05:59 | #20 | Link |
Registered User
Join Date: Nov 2008
Posts: 62
|
I think it is unlikely that array1 contains keys for BD+. The code implementing BD+ is implemented in a separate SELF, run on one of the 6 "normal" SPUs. The AACS module on the other hand is run on the seventh "isolated" SPU, where inputs and outputs are heavily regulated in hardware. Further, array1 is located in the same data segment as the encrypted host key and certificate, and indeed in close proximity. Cross references to executable code segments also turn up related code, in some cases subroutines right next to each other. Locality of reference would seem to indicate that these values are related somehow, probably to code in the same source files.
Have you tried the free version of IDA to get a better view of how this code works and the relationship between these values? Have you noticed that the AES S-Boxes are in the 4.46 AACS module at file offset 0x16B50 (inverse at 0x16CF0)? Given that we know the values are encrypted with AES-256-CTR, it might be interesting to identify the AES primitives, then the CTR wrapper, and see how that code relates to the host certificate / private key. It might help identify how newer firmware hides the updated device keys. |
|
|