PlayStation 3 [Archive] - Doom9's Forum

candela

20th March 2018, 21:12

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

| 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

This means libaacs cannot use these keys. Although they are not needed (they can be used to calculate the processing keys that are also in KEYDB.cfg) I tried to make them work in VLC. With the libaacs source code, some trial and error, and info on the PS3DevWiki (http://www.psdevwiki.com/ps3/Hypervisor_Reverse_Engineering#AACS_Processing_Keys) I've managed to convert them to the correct KEYDB format for device keys.

| 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

I'm not sure the device node is correct, also 0x0388 and higher seems to work but I got the 0x389 from the PS3DevWiki command:
./aacs_proc_key -n 0x389 -k ps3_device_keys -u ps3_device_key_u_masks_uvs mkbs/MKB_RW_v3.inf

Then I noticed the following in the PS3DevWiki commands: "ps3_device_keys" and "ps3_device_key_u_masks_uvs". I found these 2 files on github (https://github.com/cfwprpht/mfw/tree/master/tools/.ps3) and they turn out to be 2 binary files:
- 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 (http://www.psdevwiki.com/ps3/Keys#AACS_keys) with a mysterious pastebin link [Another decrypted arrays with this key] (http://pastebin.com/kasHaXKp)

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 (https://forum.doom9.org/showthread.php?p=1746069#post1746069) 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?

amayra

20th March 2018, 23:31

i think this is not right place to ask about this

candela

22nd March 2018, 00:42

i think this is not right place to ask about this

Well you can always suggest better places to ask :)

Anyway, I found some more things. Here (http://psdevwiki.com/ps3/Hypervisor_Reverse_Engineering#AACS) we read

Host certificate, host private key and AACS LA public key are stored encrypted with AES-256-CTR in the SPU module and are decrypted when the SPU module is loaded or when it's accessed first. The AES-256-CTR key and IV are in the SPU module too.

And here (http://psdevwiki.com/ps3/Keys#AACS_keys) it says those 3 arrays were decrypted using the following two keys

aes-256-ctr_key: 995FE3C3AB857BFCD853F1ABE796799D0E2093B2F7E094AE39CD88A2AC879F96
aes-256-ctr iv: 802794556C7716719B40A175DB9A455E
[Another decrypted arrays with this key]

So I started looking at the PS3 firmwares and those keys are present in AacsModule.spu.isoself of FW4.76 and not in other versions I checked. So those arrays must be related to version 4.76. For anyone who is interested, I used these tools:
- 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 :)

candela

22nd March 2018, 01:40

Apparently openssl can do it

openssl enc -d -aes-256-ctr -K 995FE3C3AB857BFCD853F1ABE796799D0E2093B2F7E094AE39CD88A2AC879F96 -iv 802794556C7716719B40A175DB9A455E -in encrypted.bin -out decrypted.bin

but of course I don't know which data from AacsModule.spu.isoself.elf to use. And maybe the player needs to be executed on the PS3 before the encrypted data becomes available?

candela

22nd March 2018, 10:22

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

array3
decrypted134656.bin : hit at offset 0x0
>0201005C FFFF8000 01460000 952D611B< ...\.....F...-a. 00000000

array1
decrypted135808.bin : hit at offset 0x0
>053A003D 6A012859 02299503 1C680427< .:.=j.(Y.)...h.' 00000000

array2
decrypted136576.bin : hit at offset 0x0
>02000009 75030000 09720300 00097504< ....u....r....u. 00000000

So for example to get array3 you need to cut the file AacsModule.spu.isoself from offset 134656 until the end, and then run openssl on it.

So maybe there's more data in there but now the problem is we don't have any known bytes to search for

candela

23rd March 2018, 09:53

As mentioned on ps3devwiki, all FW seem to contain encrypted versions of the following keys

public key 1 dec = aacs_la_pub_key = 63C21DFFB2B2798A13B58D61166C4E4AAC8A0772137EC638818FD98FA4C30B996728BF4B917F6A27
public key 2 dec = aacs_cc_pub_key = 784CF5C36397A4390406A49F7800C77DE90CB34C001DF36B8F2ECF83CDEE438F7FD1F4806FD20DE7

Because it was possible to recognize the structure of the encrypted versions of these keys (zeroes, 40 bytes, zeroes, 40 bytes, zeroes) in AacsModule.spu.isoself, I managed to extract the aes-256-ctr keys from the rest of the data for 3 other firmware versions. These keys don't seem to be mentioned on ps3devwiki or anywhere else

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

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

So for FW3.50 I can confirm the device keys, masks, host private key, host cert are actually in AacsModule.spu.isoself, encrypted with aes-256-ctr (e.g. device keys decrypted100112.bin indicates encrypted device keys are located at offset 100112=0x18710 in AacsModule.spu.isoself)

For FW4.46

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

New host cert but still has the host private key. Also array1 is present

For FW4.50

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

Again new host cert but no more host private key.

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 (http://www.psdevwiki.com/ps3/Keys#AACS_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

dizzier

23rd March 2018, 11:50

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

https://en.wikipedia.org/wiki/Magic_number_(programming)#Magic_debug_values

candela

23rd March 2018, 12:01

holy crap, check this is out !!!!

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

candela

23rd March 2018, 18:00

https://en.wikipedia.org/wiki/Magic_number_(programming)#Magic_debug_values

So is this something we can use? Or you need to execute the code ?

From FW4.46

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

Now if someone can tell me what the device node is we can use this directly in VLC instead of aacskeys

candela

24th March 2018, 00:05

candela

24th March 2018, 00:22

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

private key enc: 05974EA73D2019A1FE03A7F685DCBD5A7D2F07E5BF15DA291B31586C8840C75B
private key dec: 004FC12D7464FBFB3E0D5754016AE6867A256C16EA

private key enc appears in FW4.50

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?

foxyshadis

25th March 2018, 18:40

I wish I understood, but it's fascinating watching the steady fall of the PS3 certs once again. Hopefully you get all the way to the end!

candela

25th March 2018, 22:37

I wish I understood, but it's fascinating watching the steady fall of the PS3 certs once again. Hopefully you get all the way to the end!

This means that with a working host certificate (if you haven't inserted an MKBv63 disc, there's still one that works), it's possible to play discs up to MKBv51 with VLC. I think that's maybe up to the beginning of 2015 so if you count release years that's like (2015-2007)/(2018-2007)~70% of Blurays.

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.

mick0

26th March 2018, 08:58

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

private key enc: 05974EA73D2019A1FE03A7F685DCBD5A7D2F07E5BF15DA291B31586C8840C75B
private key dec: 004FC12D7464FBFB3E0D5754016AE6867A256C16EA

private key enc appears in FW4.50

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?

Perhaps that private key and devkeys are encrypted using that curve in the wiki (and with that second set of aes-256-ctr keys)?

Unfortunately I've no idea how to actually use that curve.

candela

26th March 2018, 10:54

Perhaps that private key and devkeys are encrypted using that curve in the wiki (and with that second set of aes-256-ctr keys)?

Unfortunately I've no idea how to actually use that curve.

I already tried the second set of aes-256-ctr and the aes-128-ctr (?) set but nothing. Also that second aes-256-ctr set is available in all PS3FW, just like that aes-128-ctr set and the curve. So I don't think they would use it to hide new info. I also have no idea how to apply that curve to anything.

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

candela

28th March 2018, 00:42

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.

Rupan

29th March 2018, 05:56

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.

candela

29th March 2018, 09:06

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.

Old FW versions are on ps3devwiki (http://www.psdevwiki.com/ps3/).

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 (http://wololo.net/2015/05/19/ps3-blu-ray-renew-aacs-encryption-keys-on-mfw-4-46/) 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).

dizzier

29th March 2018, 18:16

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.

Rupan

30th March 2018, 05:59

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 (https://www.hex-rays.com/products/ida/support/download_freeware.shtml) 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.

candela

30th March 2018, 11:28

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 (http://www.psdevwiki.com/ps3/Hypervisor_Reverse_Engineering#AACS). 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.

candela

30th March 2018, 12:44

Thanks to stackoverflow (https://security.stackexchange.com/a/1097) and LibreOffice BITXOR function: FW4.50_enc XOR FW4.70_enc XOR FW4.46_dec = FW4.70_dec

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

Rupan

30th March 2018, 17:41

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?

candela

30th March 2018, 17:42

Dandu

30th March 2018, 17:48

I have tested, it works ;)

candela

30th March 2018, 17:49

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 (https://en.wikipedia.org/wiki/Initialization_vector#Properties)

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

candela

30th March 2018, 21:07

I'm starting to think they are making mistakes on purpose...

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

30th March 2018, 22:45

Rupan

1st April 2018, 06:21

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

1st April 2018, 06:23

Where did you get the key for the 4.82 isoldr? It seems not to be in the ps3mfw repository.

candela

1st April 2018, 10:12

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 (http://www.psdevwiki.com/ps3/Keys#Key_Scrambling). 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

candela

1st April 2018, 20:48

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

maetel99

13th April 2018, 07:34

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 (http://forum.doom9.org/showthread.php?t=173935). 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

MartyMcNuts

14th September 2018, 12:51

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 (http://forum.doom9.org/showthread.php?t=173935). 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?

maetel99

16th September 2018, 06:02

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.

MartyMcNuts

21st September 2018, 04:07

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.

maetel99

24th September 2018, 05:45

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.

dizzier

24th September 2018, 12:11

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.

MartyMcNuts

2nd October 2018, 13:00

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.

maetel99

4th October 2018, 07:12

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.

MartyMcNuts

29th October 2018, 00:12

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.

Your tool sounds very interesting. Although I am a Windows user, I'd still love to see it. Could you also provide the source code?

Thanks,
Marty

MartyMcNuts

19th November 2018, 02:15

@maetel99

Haven't heard from you in a while. Just wondering how you are going with creating your tool?

maetel99

29th November 2018, 06:46

@maetel99
Haven't heard from you in a while. Just wondering how you are going with creating your tool?
Sorry, I've been a bit busy. I will try to put together the command line tool and post it.

candela

19th May 2022, 19:41

So someone :thanks: pointed out that the partially correct XOR stream retrieved from FW4.70 -> FW4.76 (see previous post (https://forum.doom9.org/showthread.php?p=1837935#post1837935)) reveals a new key on FW4.86 that works up to MKBv71

| DK | DEVICE_KEY 0x38841673E2B4E05191659899606CFFB8 | DEVICE_NODE 0x0C00 | KEY_UV 0x00000A00 | KEY_U_MASK_SHIFT 0x0B ; MKBv49-MKBv71

DanTheMann15

23rd May 2022, 03:49

@candela

cool!

now people can play their blurays that use MKBv71 and lower. (assuming they have not attempted to play a >v72 disc)

so here's a new basic config that implements this new device key: ; KEYDB.cfg

; Processing Keys

; Device Keys
| DK | DEVICE_KEY 0x5FB86EF127C19C171E799F61C27BDC2A | DEVICE_NODE 0x0A00 | KEY_UV 0x00000400 | KEY_U_MASK_SHIFT 0x17 ; MKBv01-MKBv48
| DK | DEVICE_KEY 0x38841673E2B4E05191659899606CFFB8 | DEVICE_NODE 0x0C00 | KEY_UV 0x00000A00 | KEY_U_MASK_SHIFT 0x0B ; MKBv49-MKBv71

; Host Certificate
| HC | HOST_PRIV_KEY 0x909250D0C7FC2EE0F0383409D896993B723FA965 | HOST_CERT 0x0203005CFFFF800001C100003A5907E685E4CBA2A8CD5616665DFAA74421A14F6020D4CFC9847C23107697C39F9D109C8B2D5B93280499661AAE588AD3BF887C48DE144D48226ABC2C7ADAD0030893D1F3F1832B61B8D82D1FAFFF81 ; MKBv71

; Bluray Disc VUK Keys ;

i still find it funny that sony is still obligated to keep pushing updates to the PS3 firmware to keep it able to play the latest blurays, i believe it's how most of these keys get collected since the PS3 is the easiest to hack.

candela

13th March 2023, 22:33

Partially correct XOR stream retrieved from FW4.70 -> FW4.76 (see previous post (https://forum.doom9.org/showthread.php?p=1837935#post1837935)) reveals a new key on FW4.90 that works from MKBv72 up to ? (at least MKBv81, possibly higher)

| DK | DEVICE_KEY 0x861B3719B02F24BE6F1A30E2E3ABEE94 | DEVICE_NODE 0x0C40 | KEY_UV 0x00000D00 | KEY_U_MASK_SHIFT 0x0A ; MKBv72-...

nitro322

17th March 2023, 02:58

Partially correct XOR stream retrieved from FW4.70 -> FW4.76 (see previous post (https://forum.doom9.org/showthread.php?p=1837935#post1837935)) reveals a new key on FW4.90 that works from MKBv72 up to ? (at least MKBv78, possibly higher)

Just a quick thanks. I haven't been able to play blu-rays on my drive for several months now due to the previous key being revoked. Just updated this and now it's working again. Thanks!

RealSnoopyDog

24th July 2023, 14:14

One "dumb" question: If I have a Blu-Ray with MKBv76, a host certificate which was revoked from MKBv72 on and a device key which is valid for at least MKBv76 - can this Blu-Ray be played back even if the host certificate is not valid anymore?

candela

24th July 2023, 16:33

One "dumb" question: If I have a Blu-Ray with MKBv76, a host certificate which was revoked from MKBv72 on and a device key which is valid for at least MKBv76 - can this Blu-Ray be played back even if the host certificate is not valid anymore?

No, when the host authentication is performed for the MKBv76 disc, the drive will revoke the certificate and authentication will fail. The device key can still be used to retrieve the MK for that disc. Combined with the VID retrieved using a different means (e.g. from MakeMKV or even commercial players since VID is often not protected well) you can still get the VUK/UK and play the disc (unless it's BUS encrypted in which case you need to retrieve also the RDK)

You can keep using the cert on a drive as long as no disc >=MKBv72 was ever authenticated.

MrPenguin

29th October 2023, 16:16

Partially correct XOR stream retrieved from FW4.70 -> FW4.76 (see previous post (https://forum.doom9.org/showthread.php?p=1837935#post1837935)) reveals a new key on FW4.90 that works from MKBv72 up to ? (at least MKBv81, possibly higher)

I have a MKBv76 disk, but this device key doesn't extract its media key:

mkb.c:45: Retrieved MKB record 0x04 (0x1c57ecc)
mkb.c:45: Retrieved MKB record 0x05 (0x1c58ac4)
mkb.c:45: Retrieved MKB record 0x10 (0x1c57570)
mkb.c:45: Retrieved MKB record 0x81 (0x1c5783c)
aacs.c:385: Applying subset-difference for device 0xc40 is #18:
aacs.c:386: UV: 0x00000c70 U mask: 0xffffffc0 V mask: 0xffffffe0
aacs.c:297: could not find applying device key (device 0xc40)

Am I missing something please? (I mean, apart from the media key ;))

Thanks for any help here.