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. |
30th March 2018, 11:28 | #21 | Link |
Registered User
Join Date: Jun 2005
Posts: 259
|
But isn't it likely that the bd+ module just asks the aacsmodule to perform some AES calculation with bd+ keys just like the bdplayer does for the regular aacs? Then it would make sense to store bd+ keys also in the aacs module. There's a list of commands on ps3devwiki. Although it does say it's not a complete list I'm wondering why there are no commands like "get volume unique/unit key" or would the aacsmodule decrypt the video streams internally? Anyway, array1 is present since FW4.00 and is still the same in FW4.82. If we assume it's in the same relative location to the host certificate in FW3.50, we can find a different array1 in FW1.02-3.76. So I don't think it's going to help getting device keys from FW4.50.
My AES knowledge is extremely limited but I keep reading that for AES-CTR using the same IV multiple times is unsafe. Can we exploit this somehow if we assume: - FW4.50 still uses aes-ctr to encrypt the device keys (but with unknown aes-ctr-key/iv) - FW4.50 has the same device keys as FW4.46 (because the device key masks are the same) - FW4.50, FW4.53, FW4.70 use the same aes-ctr-key/iv to encrypt the device keys (because we can see some identical encrypted device keys if we compare the 4048 byte block) The main hint on ps3dewiki is still the "private key enc/dec" which only appears since FW4.50. Last edited by candela; 30th March 2018 at 11:37. |
30th March 2018, 12:44 | #22 | Link |
Registered User
Join Date: Jun 2005
Posts: 259
|
Thanks to stackoverflow and LibreOffice BITXOR function: FW4.50_enc XOR FW4.70_enc XOR FW4.46_dec = FW4.70_dec
Code:
aacskeys 0.4.0f by arnezami, KenD00, Key, Nobu1789, anon Current path: C:\Utils\aacskeys-0.4.0f\bin\win32 MKBv: 57 Device key: FDAD855E9A89E5335288AF2805DC0497 Processing key: 8FBDD8452146552EF76136B0A348590B Encrypted C-value: 7FA6B41E0846BFC4C6C3F724E0C709AC Corresponding uv: 000008F9 Decrypted C-value: EB5B7CF99384647AC73E94D01E72F3A9 Media key: EB5B7CF99384647AC73E94D01E72FB50 Encrypted verification data: 145DB381FC3E7595D341B2E07F9281AC Decr verif data should be: 0123456789ABCDEF Decrypted verification data: 0123456789ABCDEF10E219C1E08AD5B8 Last edited by candela; 30th March 2018 at 13:04. |
30th March 2018, 17:41 | #23 | Link |
Registered User
Join Date: Nov 2008
Posts: 62
|
Impressive! If I've understood you correctly, you conducted a known plaintext attack between 4.50 and 4.70 to recover the XOR key, then confirmed your guess by applying the XOR key to 4.46 and observed that the result is identical to the same byte area in 4.70. Then they reused the same encryption key? They won't make that mistake again.
Why do you say that this won't help for 4.76 and up? |
30th March 2018, 17:42 | #24 | Link |
Registered User
Join Date: Jun 2005
Posts: 259
|
From FW4.70
Code:
| DK | DEVICE_KEY 0x5FB86EF127C19C171E799F61C27BDC2A | DEVICE_NODE 0x08F0 | KEY_UV 0x00000400 | KEY_U_MASK_SHIFT 0x17 ; MKBv01-MKBv48 | DK | DEVICE_KEY 0x31A194B61D3119D2B09DC0D8B9A73A00 | DEVICE_NODE 0x08F0 | KEY_UV 0x00000840 | KEY_U_MASK_SHIFT 0x0B ; MKBv49-MKBv52 | DK | DEVICE_KEY 0x25F9782764D026413C3D4868F891E81E | DEVICE_NODE 0x08F0 | KEY_UV 0x000008A0 | KEY_U_MASK_SHIFT 0x07 ; MKBv53-MKBv54 | DK | DEVICE_KEY 0xFDAD855E9A89E5335288AF2805DC0497 | DEVICE_NODE 0x08F0 | KEY_UV 0x000008FC | KEY_U_MASK_SHIFT 0x04 ; MKBv55-MKBv57 |
30th March 2018, 17:49 | #26 | Link | |
Registered User
Join Date: Jun 2005
Posts: 259
|
Quote:
If you encrypt 2 different messages with the same key/iv (e.g. device keys in FW4.50 and FW4.70) and you know the plaintext for 1 of these messages (yes because FW4.50 = FW4.46 keys, I guess this because the device masks are identical) you also know the plaintext from the other message (i.e. device keys for FW4.70) It doesn't work for FW4.76 because FW4.76 keys are not the same as FW4.70. So even though we have the different device keys encrypted with the same key/iv (e.g. FW4.76 and FW4.82) we don't know the plaintext for FW4.76 so we can't get the plaintext for FW4.82. Well some keys will still be the same as in FW4.70 probably, but those are revoked and useless. We need the XOR for the changed keys. (update: Actually we can find keys that change from 4.76 to 4.81/4.82 if the key in the same position doesn't change from 4.70 to 4.76) Maybe there is some other attack possible, I barely know anything about AES encryption. But I'm guessing we need someone using a debugger to figure out how to get the aes-ctr key sets for FW4.50-FW4.70 and FW4.76-FW4.82 that are used to encrypt the device keys. Maybe it has gotten easier since we now also know the plaintext FW4.70 device keys. Maybe the aes-ctr keys are in the aacs module but encrypted with a different key, or the keys are being sent to the aacs module by another module... Last edited by candela; 30th March 2018 at 23:43. |
|
30th March 2018, 21:07 | #27 | Link | |
Registered User
Join Date: Jun 2005
Posts: 259
|
I'm starting to think they are making mistakes on purpose...
Quote:
|
|
30th March 2018, 22:45 | #28 | Link |
Registered User
Join Date: Jun 2005
Posts: 259
|
Fw4.81
Code:
| DK | DEVICE_KEY 0x5FB86EF127C19C171E799F61C27BDC2A | DEVICE_NODE 0x0A00 | KEY_UV 0x00000400 | KEY_U_MASK_SHIFT 0x17 ; MKBv01-MKBv48 | DK | DEVICE_KEY 0x7FD1F7966AD2B0E4F4901205E32A69BA | DEVICE_NODE 0x0A00 | KEY_UV 0x00000900 | KEY_U_MASK_SHIFT 0x0B ; MKBv49-MKBv62 |
1st April 2018, 06:21 | #29 | Link |
Registered User
Join Date: Nov 2008
Posts: 62
|
I thought it might be worthwhile attempting to recover a newer (unrevoked) host certificate and private key. From previous posts we know that in 4.46 the host certificate is at file offset 0x17680 and the host private key is at 0x175E0. After some investigation I put together the following table:
4.46: HPK: 0x175E0 HC: 0x17680 4.70: HPK: 0x20160 HC: 0x20100 4.76 HPK: 0x21250 HC: 0x20E00 4.81 HPK: 0x21250 HC: 0x20E00 The 4.76 / 4.81 content is identical. I'm still catching up on the trick you did with XOR and I wonder if it would be easier for you to just apply the same attack to these offsets and see if it works |
1st April 2018, 10:12 | #31 | Link | |
Registered User
Join Date: Jun 2005
Posts: 259
|
Quote:
I think the host certificate FFFF80000146 is a "decoy" (or they just didn't bother to remove it) because it's revoked in MKBv58 and the device keys for FW4.70 are also revoked in MKBv58. So starting from FW4.76 the real used host cert and private keys are located elsewhere and encrypted with other aes-keys If the content in your offsets doesn't change from 4.76 to 4.82, we can't apply the XOR trick, since XOR results in 0 Last edited by candela; 1st April 2018 at 17:38. |
|
1st April 2018, 20:48 | #32 | Link |
Registered User
Join Date: Jun 2005
Posts: 259
|
Why do you think the HPK in 4.70 is at 0x20160 ?
I just thought of using the XOR in the reverse for 4.70 because we know from keydb.cfg that the private key for cert FFFF80000146 is HPK=0027263F402E2D6DB56B1FB7BB4524C6CD5C9F2EF4. If we assume that they use the same aes-ctr (for which we do not know the key/iv) to encrypt the device keys and the host private key then: HPK_part_1 = byte 01-16 HPK_part_2 = byte 17-21+padding HPK_part1_enc = HPK_part1_dec xor DeviceKey1_enc xor DeviceKey1_dec = 05974EA73D2019A1FE03A7F685DCBD5A This matches the first 16 bytes of "private key enc" on ps3devwiki and is located at 0x17B00 Now the question is why does ps3devwiki lists the value "004FC12D7464FBFB3E0D5754016AE6867A256C16EA" as "private key dec" when the real value is "0027263F402E2D6DB56B1FB7BB4524C6CD5C9F2EF4" Update: I noticed that HPK_part2_enc = HPK_part2_dec xor DeviceKey2_enc xor DeviceKey2_dec != 7D2F07E5BF15DA291B31586C8840C75B (the second 16 bytes of "private key enc") Since the same method works correct for the device keys and private key in FW4.45 it seems the device key 2 for FW4.70 I found is incorrect. So some keys did change from FW4.45 to FW4.50. Or someone knows what else could be the problem? Update2: Figured out that for padding the HPK from 21 to 32 bytes, they didn't use HPK_part1_dec = 0027263F402E2D6DB56B1FB7BB4524C6 HPK_part2_dec = CD5C9F2EF4 + padding but HPK_part1_dec = 0027263F402E2D6DB56B1FB7BB4524C6 HPK_part2_dec = CD5C9F2EF40000000000000000000000 xor HPK_part1_dec In this case we get the correct encrypted value HPK_part2_enc = 7D2F07E5BF15DA291B31586C8840C75B Last edited by candela; 2nd April 2018 at 13:41. |
13th April 2018, 07:34 | #33 | Link |
Registered User
Join Date: Apr 2018
Posts: 21
|
Summary of new processing keys
I've been following this thread with great interest. I find it very impressive how candela has been able to make such progress on the newer PS3 firmware versions.
Using my own AACS and subset difference implementation derived from libaacs, I was able to run the new device keys against a number of MKB files on various discs. I also used the complete list candela published in another thread. Here is my list at this point of processing keys that are not in the latest keydb.cfg file: | PK | 0x973940BB180E83266231EE596CEF65B2 ; v3-12 | PK | 0xCC72242D4CC8156B960502805987DED0 ; v14-23 | PK | 0xD11E3DBA323D37DE3DE0D6A0DC5EC807 ; v24-25 | PK | 0xAAAF8A16F829DA16A124D837F64EE2D8 ; v26-28 | PK | 0xC0F535929D59CD071BEE9CB53F0C21C2 ; v30-35 | PK | 0x99AB6AE0A7E13504CE284B7CA401B26A ; v31-36 | PK | 0x19DF7DA3A1FB75AC4DC34CCB6AF6A5C7 ; v36-38 | PK | 0x3FB9D3314AAC7F76581190A624A5C578 ; v39-43 | PK | 0x3ADE0AB7C9E4270055506C449E8EE6CF ; v24-48 | PK | 0x186D1BBA19487F6450C1FD5ADA9407E6 ; v44-51 | PK | 0xF2C416A45D806D964F567B5D7FED209D ; v49-52 | PK | 0x7A8BAB1B0C66C39D1A2EEE6883E4DD3C ; v53-54 | PK | 0x1F70D403A6D39B20A3F7131750ACAA22 ; v53-54 | PK | 0x8FBDD8452146552EF76136B0A348590B ; v55-57 | PK | 0x0EB5F81CF17405CAFDB97832F5EA11B4 ; v55-62 |
14th September 2018, 12:51 | #34 | Link | |
Registered User
Join Date: Aug 2018
Posts: 16
|
Quote:
|
|
16th September 2018, 06:02 | #35 | Link |
Registered User
Join Date: Apr 2018
Posts: 21
|
The idea is to make a list of all the device keys (like those in this thread) and then make a directory full of MKB records (such as posted by candela). You then test each device key against each of the MKB records in turn and look at the processing key that gets generated. If a processing key is generated, then the device key is valid for that MKB version and you can see if the processing key is also in the keydb.cfg file. If no processing key is generated, then the device key is not valid for that MKB version.
The process of testing the device keys is described in the AACS common spec in sections 3.2.1 - 3.2.4. Each MKB file has a set of subset difference records that are used to derive the processing key from the device key. In libAACS, the function _find_dk() does this. There is some ambiguity about where to start the subset difference tree iteration, so in libAACS they test all the possible nodes as a starting point until finding one that works (or that none work). Let me know if you have more questions. |
21st September 2018, 04:07 | #36 | Link | |
Registered User
Join Date: Aug 2018
Posts: 16
|
Quote:
I'm currently working on something else at the moment but once that is finished, I might take a closer look at this and see if I can maybe write a small program for this task. |
|
24th September 2018, 05:45 | #37 | Link |
Registered User
Join Date: Apr 2018
Posts: 21
|
I can put together a command line tool to help evaluate device keys if there is any interest. The tool would take two path arguments, one to a keydb.cfg file with test device keys, and one to an MKB file or a folder of MKB files. The output would tell you which device keys worked for which MKB files and what the resulting processing keys are. The tool would be Mac-based.
|
2nd October 2018, 13:00 | #39 | Link | |
Registered User
Join Date: Aug 2018
Posts: 16
|
Quote:
I've just been having a bit of a look at this. I've read through the AACS specs and 3.2.4 is confusing to me. I'm not sure I understand step 1 (the UV) & step 3 (initialization m). I understand about AESing & XORing the device key with the seed to get the left child, right child and one processing key, but this has nothing to do with the MKB file. What do you test the device key with in the MKB file to generate processing keys? Thanks for your help. |
|
4th October 2018, 07:12 | #40 | Link | |
Registered User
Join Date: Apr 2018
Posts: 21
|
Quote:
|
|
Thread Tools | Search this Thread |
Display Modes | |
|
|