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.

 

Go Back   Doom9's Forum > General > Decrypting

Reply
 
Thread Tools Search this Thread Display Modes
Old 30th March 2018, 11:28   #21  |  Link
candela
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.
candela is offline   Reply With Quote
Old 30th March 2018, 12:44   #22  |  Link
candela
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
Unfortunately this doesn't help us for FW4.76 and higher

Last edited by candela; 30th March 2018 at 13:04.
candela is offline   Reply With Quote
Old 30th March 2018, 17:41   #23  |  Link
Rupan
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?
Rupan is offline   Reply With Quote
Old 30th March 2018, 17:42   #24  |  Link
candela
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
I honestly still don't understand the device_node, I'm just looping over them until one works . Anyone?
candela is offline   Reply With Quote
Old 30th March 2018, 17:48   #25  |  Link
Dandu
Registered User
 
Join Date: Feb 2014
Posts: 14
I have tested, it works
Dandu is offline   Reply With Quote
Old 30th March 2018, 17:49   #26  |  Link
candela
Registered User
 
Join Date: Jun 2005
Posts: 259
Quote:
Originally Posted by Rupan View Post
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?
I found it better explained on Wikipedia

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.
candela is offline   Reply With Quote
Old 30th March 2018, 21:07   #27  |  Link
candela
Registered User
 
Join Date: Jun 2005
Posts: 259
I'm starting to think they are making mistakes on purpose...

Quote:
aacskeys 0.4.0f by arnezami, KenD00, Key, Nobu1789, anon

Current path: C:\Utils\aacskeys-0.4.0f\bin\win64

MKBv: 62
Device key: 7FD1F7966AD2B0E4F4901205E32A69BA
Processing key: 0EB5F81CF17405CAFDB97832F5EA11B4
Encrypted C-value: DA55F8F00D01BEE1CDFDD2826FE49422
Corresponding uv: 00000900

Decrypted C-value: 3536B900E154A0CEE94C142B28F3D12F
Media key: 3536B900E154A0CEE94C142B28F3D82F

Encrypted verification data: DD99628399378ECB39130426DF29F788
Decr verif data should be: 0123456789ABCDEF
Decrypted verification data: 0123456789ABCDEFC29A1707D50D04F9
I suddenly had this hunch that if they exchanged new keys in 4.81/4.82 for keys that didn't change between 4.70 and 4.76 I would still be able to do this XOR thing. I'm not sure I fully understand it yet but I just tried it and bingo
candela is offline   Reply With Quote
Old 30th March 2018, 22:45   #28  |  Link
candela
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
It doesn't work for FW4.82, I guess the other keys are in positions that already changed from FW4.70 to FW4.76
candela is offline   Reply With Quote
Old 1st April 2018, 06:21   #29  |  Link
Rupan
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
Rupan is offline   Reply With Quote
Old 1st April 2018, 06:23   #30  |  Link
Rupan
Registered User
 
Join Date: Nov 2008
Posts: 62
Where did you get the key for the 4.82 isoldr? It seems not to be in the ps3mfw repository.
Rupan is offline   Reply With Quote
Old 1st April 2018, 10:12   #31  |  Link
candela
Registered User
 
Join Date: Jun 2005
Posts: 259
Quote:
Originally Posted by Rupan View Post
Where did you get the key for the 4.82 isoldr? It seems not to be in the ps3mfw repository.
They are the same as for 4.81, look on ps3devwiki. So you can just search&replace versions in the data/keys file for scetool. I don't really understand this. Sony doesn't even bother to change them anymore? Or would different FW keys be found immediately anyway?

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.
candela is offline   Reply With Quote
Old 1st April 2018, 20:48   #32  |  Link
candela
Registered User
 
Join Date: Jun 2005
Posts: 259
Quote:
Originally Posted by Rupan View Post

4.70:
HPK: 0x20160
HC: 0x20100
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.
candela is offline   Reply With Quote
Old 13th April 2018, 07:34   #33  |  Link
maetel99
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
maetel99 is offline   Reply With Quote
Old 14th September 2018, 12:51   #34  |  Link
MartyMcNuts
Registered User
 
Join Date: Aug 2018
Posts: 16
Quote:
Originally Posted by maetel99 View Post
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
maetel99, I'd love to know how you are finding these processing keys. Do you have an application that can do this? Could you share your method in more detail?
MartyMcNuts is offline   Reply With Quote
Old 16th September 2018, 06:02   #35  |  Link
maetel99
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.
maetel99 is offline   Reply With Quote
Old 21st September 2018, 04:07   #36  |  Link
MartyMcNuts
Registered User
 
Join Date: Aug 2018
Posts: 16
Quote:
Originally Posted by maetel99 View Post
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.
Thanks, that makes sense.

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.
MartyMcNuts is offline   Reply With Quote
Old 24th September 2018, 05:45   #37  |  Link
maetel99
Registered User
 
Join Date: Apr 2018
Posts: 21
Quote:
Originally Posted by MartyMcNuts View Post
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.
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.
maetel99 is offline   Reply With Quote
Old 24th September 2018, 12:11   #38  |  Link
dizzier
Registered User
 
Join Date: Jan 2010
Posts: 74
Just use the aacskeys utility, available since 2007 If you give it a set of valid device keys it will happily print you the processing keys and various other keys.
dizzier is offline   Reply With Quote
Old 2nd October 2018, 13:00   #39  |  Link
MartyMcNuts
Registered User
 
Join Date: Aug 2018
Posts: 16
Quote:
Originally Posted by maetel99 View Post
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.
Hi maetel99,

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.
MartyMcNuts is offline   Reply With Quote
Old 4th October 2018, 07:12   #40  |  Link
maetel99
Registered User
 
Join Date: Apr 2018
Posts: 21
Quote:
Originally Posted by MartyMcNuts View Post
Hi maetel99,

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.
The idea is that there is an array of subset difference records stored in the MKB file. For each record, there is an encrypted data key and a "uv number" and "mask". There is an iterative process in which you combine the uv number and mask to determine a direction to move, then you process the encrypted data key along with the device key using the AES-G one-way function to find the next potential processing key. You then test that processing key to see if it is valid. If it is, then you are done. If not, you shift the uv number and mask and iterate again. If at the end of the iterations you have not found a valid processing key, then the device key is either revoked or you started at an invalid node. This is essentially the logic in the libaacs _find_dk function.
maetel99 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 21:44.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.