New AACS Device Keys Found!

[ATARI Vampire]

Hello again, everyone.

Last February I posted an AACS device key to this forum (AA856A1BA814AB99FFDEBA6AEFBE1C04). Today I wanted to share a little bit more of my work with the community. Here are some new AACS device keys for your hacking pleasure. :devil:

Parent Key: 6A5AA1DCC8CD7D2257EF6F6A68C5B5B0
LChild Key: CCBF73F2D2330555A6F1594B093572E6
PChild Key: 0C1D02FDF1BDAF22FE6304C26C251C6C
RChild Key: D884CE857061381984C9B8D1844F0681

Parent Key: CCBF73F2D2330555A6F1594B093572E6
LChild Key: AA856A1BA814AB99FFDEBA6AEFBE1C04
PChild Key: 06DEAF911DD975AF677E6C2F96B81CF4
RChild Key: D98F5F1D7EF0B93E77E6F135E1152A34

Parent Key: AA856A1BA814AB99FFDEBA6AEFBE1C04
LChild Key: 17BDED008DAC2E1FC06266D5AABA65E1
PChild Key: 09F911029D74E35BD84156C5635688C0
RChild Key: 9E73ED25EB25E233DEF94AF25D346717

Parent Key: D98F5F1D7EF0B93E77E6F135E1152A34
LChild Key: 8D90071B45147D39BD3348B39782F194
PChild Key: 21D06D2007446ABDA5F138AD1B0E379D
RChild Key: 118BD7021A1FCCB6FF53870F5031782C

Parent Key: D884CE857061381984C9B8D1844F0681
LChild Key: C49C501CEF87D89A355FB5509FA10C39
PChild Key: 3B2C35A8929BCFBDAC5367BDB2ED8C7C
RChild Key: BF235CACAACE5B4F4AFBB98723EA4E74

Parent Key: C49C501CEF87D89A355FB5509FA10C39
LChild Key: 8CC12E76EA6007A43942FB088A62B78E
PChild Key: D6B875A664E385DA6BE405F298E5438D
RChild Key: B286658B1F48CF5D7C4B4391B44A65A7

Parent Key: BF235CACAACE5B4F4AFBB98723EA4E74
LChild Key: F2DF20494D2698ED4235F6599E2DF1FA
PChild Key: 65AB4D41CE2AB5677CA860C0DE61BE39
RChild Key: 40BB859BD8326EC23E52FF33C628C21E

Basically, I have posted the left branch parent and grandparent of AA856A1BA814AB99FFDEBA6AEFBE1C04. However, you'll also notice that this opens up the right side of the 6A5AA1DCC8CD7D2257EF6F6A68C5B5B0 and CCBF73F2D2330555A6F1594B093572E6 sub-trees, hence the larger number of keys.

The astute hacker will also realize that these new device keys have already been revoked by MKB v3.

Isn't AACS fun? :stupid:

I created a little utility for doing your own AACS key derivations. Just open a command prompt in Windows, navigate to where you saved the program, type TreeGen.exe [key] [depth] and the program will derive all left branch, right branch and processing keys via recursion. The key parameter should be a 32 character HEX value. The depth parameter is an optional zero-based value that determines how many levels to derive child keys. Have fun!

TreeGen (http://rs57.rapidshare.com/files/37390307/TreeGen.exe)

[arnezami]

Here are some new AACS device keys for your hacking pleasure. :devil:

6A5AA1DCC8CD7D2257EF6F6A68C5B5B0

CCBF73F2D2330555A6F1594B093572E6

AA856A1BA814AB99FFDEBA6AEFBE1C04

The astute hacker will also realize that these new device keys have already been revoked by MKB v3.

Isn't AACS fun? :stupid:

AACS is indeed a lot of fun :).

Good work!

arnezami

[andread]

Here are some new AACS device keys for your hacking pleasure. :devil:


You are right, the AACS invested millions for our pleasure.
Nice work ATARI Vampire.

andread

[FoxDisc]

Basically, I have posted the left branch parent and grandparent of AA856A1BA814AB99FFDEBA6AEFBE1C04.
....
The astute hacker will also realize that these new device keys have already been revoked by MKB v3.


Nice work! Those who are interested in this will also notice that the "PChild" in the third group is the original famous 09 f9 Processing Key of song, story and the Digg revolt. Atari V's post shows how the revoked player calculated that key from a device key.

[aKzenT]

Great work indeed!

btw: Has anyone tried finding the public aacs key (used for signing the mkb, etc.) in the memory dumps? Finding and being able to manipulate this key could enable very interesting attacks (like revealing all 253 device key a player has or even finding device keys in a player that are protected with a simple xor-'encryption'*).

Also has anyone checked if the signature is actually checked in the early versions of powerdvd/windvd?

I would love to play with these things if I could afford the necessary hardware :-(

* If I understand correctly there is an easy way for players to 'hide' their device keys with a simple xor while still being able to use AES. So I suspect that this could be a method used by the recent versions of powerdvd/windvd.

[arnezami]

Great work indeed!

btw: Has anyone tried finding the public aacs key (used for signing the mkb, etc.) in the memory dumps? Finding and being able to manipulate this key could enable very interesting attacks (like revealing all 253 device key a player has or even finding device keys in a player that are protected with a simple xor-'encryption'*).

Also has anyone checked if the signature is actually checked in the early versions of powerdvd/windvd?

I would love to play with these things if I could afford the necessary hardware :-(

* If I understand correctly there is an easy way for players to 'hide' their device keys with a simple xor while still being able to use AES. So I suspect that this could be a method used by the recent versions of powerdvd/windvd.

Here they are:

http://forum.doom9.org/showthread.php?p=989832#post989832

:)

[KenD00]

Has anyone tried finding the public aacs key (used for signing the mkb, etc.) in the memory dumps? Finding and being able to manipulate this key could enable very interesting attacks (like revealing all 253 device key a player has or even finding device keys in a player that are protected with a simple xor-'encryption'*).


The public AACS keys have been posted here (http://forum.doom9.org/showpost.php?p=989832&postcount=126). But i'm not sure how that what you intent to do should work. You want to modify the public key to modify the content which is signed with the private key to still match the signature? I'm not a crypto expert but i would say forget it.

:rolleyes:

[aKzenT]

The public AACS keys have been posted here (http://forum.doom9.org/showpost.php?p=989832&postcount=126). But i'm not sure how that what you intent to do should work. You want to modify the public key to modify the content which is signed with the private key to still match the signature? I'm not a crypto expert but i would say forget it.

:rolleyes:

The interesting thing is not to create content which is signed by the aacs key (which we can't do without the private key), but to (temporarily) change (in the player memory) the aacs public key to our own public key (to which we have a matching private key). We can then use our private key to generate fake mkbs, etc. which appear to be valid to the player (because it checks the signature with our key instead of the aacs key).

Here they are:

http://forum.doom9.org/showthread.php?p=989832#post989832

:)

Good find, but it is still only half the way. Changing the key in the player is the interesting part...

[abcx]

The interesting thing is not to create content which is signed by the aacs key (which we can't do without the private key), but to (temporarily) change (in the player memory) the aacs public key to our own public key (to which we have a matching private key). We can then use our private key to generate fake mkbs, etc. which appear to be valid to the player (because it checks the signature with our key instead of the aacs key).



Good find, but it is still only half the way. Changing the key in the player is the interesting part...Sounds like an interesting attack...it seems to me that the key can just be changed in real-time in the memory using a debugger....

[aKzenT]

Sounds like an interesting attack...it seems to me that the key can just be changed in real-time in the memory using a debugger....

We don't know how or where this key is stored... The first thing to try should be to see if we can find the key in a mem dump taken at the right moment like the other keys.

Also does anyone know if PowerDVD/WinDVD have any protections against debuggers (checking if a debugger is running, etc).

[lightshadow]

The interesting thing is not to create content which is signed by the aacs key (which we can't do without the private key), but to (temporarily) change (in the player memory) the aacs public key to our own public key (to which we have a matching private key). We can then use our private key to generate fake mkbs, etc. which appear to be valid to the player (because it checks the signature with our key instead of the aacs key).

So what you are saying is, that when you have replaced the public key, and generated fake MKB's you want to search for these in memory (now that you know what they are), and when you know their memory location, you look at that address when the AACS public key is used?

[xyz987]

Nice work. No traitor tracing is possible (you have published just revoked keys) but everybody can use your keys to write and test a Device Key tree generator.

[aKzenT]

So what you are saying is, that when you have replaced the public key, and generated fake MKB's you want to search for these in memory (now that you know what they are), and when you know their memory location, you look at that address when the AACS public key is used?

Once you know where to find a device key in memory you can simply give the player different fake mkbs which will yield every device key a player has (e.g. all 253 'main' keys). If you are limited to 'official' disks, that are signed by AACS LA, you can get a maximum of 1 'main' device key (main device key meaning that it is directly assigned from the AACS LA instead of being computed from another 'main' device key, like the keys in this thread) for each MKB version. And even getting this main key is more difficult because if you don't time it right, you will only get a subsidiary/derrived key. With your own MKB you can make entries where the main device key is already the final device key used to get a processing key.

Another interesting thing is to be able to unrevoke players (maybe forever) from the HRL. The HRL, DRL and CRLs are also verified by one of these public keys and the player stores only the most recent version of it. If you can fake the public key you can create an mkb with the highest possible version where these lists are empty.
(You will still not be able to playback new content however, because of the explicit revocation through the subset difference technique).

[ATARI Vampire]

Nice work. No traitor tracing is possible (you have published just revoked keys) but everybody can use your keys to write and test a Device Key tree generator.

I created a little utility for doing your own AACS key derivations. Just open a command prompt in Windows, navigate to where you saved the program, type TreeGen.exe [key] [depth] and the program will derive all left branch, right branch and processing keys via recursion. The key parameter should be a 32 character HEX value. The depth parameter is an optional zero-based value that determines how many levels to derive child keys. Have fun! :p

TreeGen (http://rs57.rapidshare.com/files/37390307/TreeGen.exe)

[frogman]

I am having trouble with your treegen.exe file! It does not want to execute at all.

[Zotty]

Am I having trouble your treegen.exe file! It does not want to exacute at all.

Same here

C:\>treegen.exe
The system cannot execute the specified program.

[arnezami]

+-----------------------------+
| TreeGen v1.0 |
| AACS Key Derivation Utility |
| ATARI Vampire |
+-----------------------------+

Usage: TreeGen [key] [depth]

C:\>treegen 6A5AA1DCC8CD7D2257EF6F6A68C5B5B0 2
+-----------------------------+
| TreeGen v1.0 |
| AACS Key Derivation Utility |
| ATARI Vampire |
+-----------------------------+

Depth: 2
Init Key: 6A5AA1DCC8CD7D2257EF6F6A68C5B5B0

Parent Key: 6A5AA1DCC8CD7D2257EF6F6A68C5B5B0
LChild Key: CCBF73F2D2330555A6F1594B093572E6
PChild Key: 0C1D02FDF1BDAF22FE6304C26C251C6C
RChild Key: D884CE857061381984C9B8D1844F0681

Parent Key: CCBF73F2D2330555A6F1594B093572E6
LChild Key: AA856A1BA814AB99FFDEBA6AEFBE1C04
PChild Key: 06DEAF911DD975AF677E6C2F96B81CF4
RChild Key: D98F5F1D7EF0B93E77E6F135E1152A34

Parent Key: AA856A1BA814AB99FFDEBA6AEFBE1C04
LChild Key: 17BDED008DAC2E1FC06266D5AABA65E1
PChild Key: 09F911029D74E35BD84156C5635688C0
RChild Key: 9E73ED25EB25E233DEF94AF25D346717

Parent Key: D98F5F1D7EF0B93E77E6F135E1152A34
LChild Key: 8D90071B45147D39BD3348B39782F194
PChild Key: 21D06D2007446ABDA5F138AD1B0E379D
RChild Key: 118BD7021A1FCCB6FF53870F5031782C

Parent Key: D884CE857061381984C9B8D1844F0681
LChild Key: C49C501CEF87D89A355FB5509FA10C39
PChild Key: 3B2C35A8929BCFBDAC5367BDB2ED8C7C
RChild Key: BF235CACAACE5B4F4AFBB98723EA4E74

Parent Key: C49C501CEF87D89A355FB5509FA10C39
LChild Key: 8CC12E76EA6007A43942FB088A62B78E
PChild Key: D6B875A664E385DA6BE405F298E5438D
RChild Key: B286658B1F48CF5D7C4B4391B44A65A7

Parent Key: BF235CACAACE5B4F4AFBB98723EA4E74
LChild Key: F2DF20494D2698ED4235F6599E2DF1FA
PChild Key: 65AB4D41CE2AB5677CA860C0DE61BE39
RChild Key: 40BB859BD8326EC23E52FF33C628C21E

Works like a charm. :)

[SvT]

I get a "Can't run programm" error...
I'm using XP. What are we missing ?

[honai]

You need to have the MS Visual C++ runtime library in your system path:

MSVCP80.dll
MSVCR80.dll

(older versions might also work)

[ATARI Vampire]

Same here

The program doesn't rely upon any outside DLLs (except possibly the standard files that @honai pointed out above). I am running Windows XP Professtional, with Visual C++ 2005 installed. Can you give me any additional information on the error? Thanks...

[Zotty]

It doesn't give much feedback. After a quick check this is all I can tell you.

When running from the console:
The system cannot execute the specified program.

From explorer (just to get additional info)
The program has failed to start because the application configuration is incorrect

Both DLLs mentioned above are not present on my system and I do have Visual Studio 2005 (express) installed.

A look with a hexeditor revealed the following though:

000049d2:4d 53 56 43 50 38 30 2e 64 6c 6c MSVCP80.dll
00004abc:4d 53 56 43 52 38 30 2e 64 6c 6c MSVCR80.dll

Looks like both DDLs are needed after all. Hmmmz... Will hunt them down on the net in the morning. Right now it's way past bedtime for me. Working on AACS decryption code is way too addicting ;)

Using WinXP Professional 2002 SP2

[SvT]

EDIT: I solved my problem ! I was using Visual C++2005 Version 8.0.50727.42.

You are using .762 (Zotty thanks for the hexeditor tip !)

I installed SP1 for Visual C++ from MS and that did the trick !

It's working like a charme now on my Windows XP system using Visual C++2005 Version 8.0.50727.762 !

Thanks !

[Peer van Heuen]

Another interesting thing is to be able to unrevoke players (maybe forever) from the HRL. The HRL, DRL and CRLs are also verified by one of these public keys and the player stores only the most recent version of it. If you can fake the public key you can create an mkb with the highest possible version where these lists are empty.
(You will still not be able to playback new content however, because of the explicit revocation through the subset difference technique).

The trouble with these HRLs is that they are stuck in the drive and you'll not get them out of there by fooling the player ;)

[aKzenT]

The trouble with these HRLs is that they are stuck in the drive and you'll not get them out of there by fooling the player ;)

Yeah, I was speaking generally. Changing the HRL would of course require finding (and changing) the public keys in the firmware.

[arnezami]

The program doesn't rely upon any outside DLLs (except possibly the standard files that @honai pointed out above). I am running Windows XP Professtional, with Visual C++ 2005 installed. Can you give me any additional information on the error? Thanks...

Did you build as a 'Release' or a 'Debug' exe?

A program shouldn't need VC to be run...

[fengtao]

Hi ATARI, you should do "static link" to runtime library, or else it's tricky to install new runtime library dlls.

[ATARI Vampire]

Hi ATARI, you should do "static link" to runtime library, or else it's tricky to install new runtime library dlls.

No problem. I'll rebuild tonight as static instead of dynamic and upload a new link. Thanks for the feedback. :thanks:

[KoD]

Th runtimes are a free download from Microsoft (http://www.microsoft.com/downloads/details.aspx?FamilyID=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en). What's so hard to figure it out ?

[ATARI Vampire]

I recompiled TreeGen so that the VC dependency libraries would not be needed. Let me know if you still have problems running the program in Windows XP.

TreeGen (static link) (http://rs57.rapidshare.com/files/37390307/TreeGen.exe)

:thanks:

[lightshadow]

I recompiled TreeGen so that the VC dependency libraries would not be needed. Let me know if you still have problems running the program in Windows XP.


Could you release the source code, so Linux users and other hackers could tickle with it? =)