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 24th February 2007, 20:05   #1  |  Link
ATARI Vampire
Registered User
 
ATARI Vampire's Avatar
 
Join Date: Feb 2007
Posts: 14
WinDVD 8 Device Key Found!

Although this is my first post, I have been actively sitting in the shadows for the last 6-8 weeks reading every Doom9 thread that I could find on HD DVD and Blu-Ray decryption. I have followed the postings of muslix64, Janvitos, and Arnezami, trying my best to recreate their steps to learn even more about the under workings of AACS. I even printed out all 70 pages of the AACS Introduction and Common Cryptographic Elements document, painfully reading through this material.

A few nights ago, something that Arnezami had written about slowing WinDVD 8 down though intensive memory dumps had started me thinking. So, I brought up my favorite Java IDE and begun writing code. Using a combination of VUK Finder (by Jokin), pmdump, psuspened (Sys Internals) and WinHex I was able to get enough data to find the VID, Media Key, and Processing Key by using the "bottom up" approach that Arnezami spoke about.

As soon as I had the processing key in a memory dump I knew that I was close to a Device Key. I then quickly implemented a version of AES-128G(k, d), where k = key and d = the data to be decrypted, however in this case I seeded d with the constant 0x7B103C5DCB08C4E51A27B01799053BD9 + 1, or 0x7B103C5DCB08C4E51A27B01799053BDA (per page 13 of the AACS Common Crypto doc), and ran the entire contents of my memory dump through decryption at 1 byte incremental offsets.

About 35,000 bytes into the file I extracted a 16 byte value that was able, using the constant as the d value, to create the processing key. If my interpretation of the AACS specification is correct, I have found a device key. Here is the device key, along with the memory offset where it can be re-discovered assuming that you dump memory in WinDVD 8 early enough in the runtime process. By the way, psuspened helps tremendously with slowing processes down so that pmdump can accurately dump memory!

[WinDVD 8]

Device Key: AA856A1BA814AB99FFDEBA6AEFBE1C04
Found at memory location: 0x000089EC

Device Key: AA856A1BA814AB99FFDEBA6AEFBE1C04
Found at memory location: 0x00008A20

An interesting thing to note is that the device key is found only a few bytes before the location where Arnezami found the processing key, and in contiguous memory! It is also interesting to note that WinDVD8 keeps the device key in 2 difference memory locations, very close by each other. My guess is that this would be the result of some sort of deep copy, maybe even the result of a function call.

Anyway, this is what information I have been able to pull together with 3-4 hours of free time this week. I'd like the Doom9 decryption forum to validate my findings since I have not had the time to step through any MKB's with this device key yet. Be that as it may, I am pretty sure that I have found a device key. Enjoy!

:-E

Last edited by ATARI Vampire; 25th February 2007 at 02:04.
ATARI Vampire is offline   Reply With Quote
Old 24th February 2007, 21:18   #2  |  Link
noclip
Registered User
 
Join Date: Dec 2006
Posts: 154
Can someone confirm this?
noclip is offline   Reply With Quote
Old 24th February 2007, 22:00   #3  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by noclip View Post
Can someone confirm this?
It is noteworthy to say that to confirm this it is NOT necessary to find again the Device Key in memory. Anybody with a program that implements AES-G3 with seed 0x7B103C5DCB08C4E51A27B01799053BDA can confirm it.

AES-G3 is a one-way function. It is not posible to inverse it (it is not posible to compute the Device Key from the Processing Key). If your input is Atari Vampire's DK and the output of AES-3G with that seed is arnezami's PK, then this DK is the true one.

Last edited by xyz987; 24th February 2007 at 22:09.
xyz987 is offline   Reply With Quote
Old 24th February 2007, 22:05   #4  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
You say you are using AES-D, but the real function to use is AES-G3 (with an aditional XOR operation at the end). Do you xored the output of AES-D with the seed?

Last edited by xyz987; 24th February 2007 at 22:57.
xyz987 is offline   Reply With Quote
Old 24th February 2007, 23:22   #5  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Confirmed. This is a (sub) Device Key.

Well done! Welcome in joining our efforts .

Technically there could be more Device and sub Device Keys (that are parents of the found device key) in memory. But I've yet to find one. Given the right memdump it should be possible to retrace it back to the "given" Device Key (the one given to WinDVD 8).

Last edited by arnezami; 24th February 2007 at 23:25.
arnezami is offline   Reply With Quote
Old 24th February 2007, 23:57   #6  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by arnezami View Post
Technically there could be more Device and sub Device Keys (that are parents of the found device key) in memory. But I've yet to find one. Given the right memdump it should be possible to retrace it back to the "given" Device Key (the one given to WinDVD 8).
What I am going to say is just an speculation, but may be it helps. Atari Vampire's DK is repeated at 2 positions in memdump. So may be WinDVD works this way:

1- Program stores DK at one of the positions.
2- Program computes sub DK and stores it at the other position
3- Program copy sub DK (output DK) to the first position, so the new DK becomes the input of the new iteration of AES-G3.

If the above is true, parent DK of Atari Vampire's DK is at one of these 2 positions sometimes.

Last edited by xyz987; 25th February 2007 at 00:59.
xyz987 is offline   Reply With Quote
Old 25th February 2007, 01:22   #7  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by xyz987 View Post
What I am going to say is just an speculation, but may be it helps. Atari Vampire's DK is repeated at 2 positions in memdump. So may be WinDVD works this way:

1- Program stores DK at one of the positions.
2- Program computes sub DK and stores it at the other position
3- Program copy sub DK (output DK) to the first position, so the new DK becomes the input of the new iteration of AES-G3.

If the above is true, parent DK of Atari Vampire's DK is at one of these 2 positions sometimes.
You might be on to something here . Putting it in c-terms: it looks like a stucture (or something similar) with maybe an "in" and "out" key which is used iteratively.

In my memdump:

1) address 00008A00
2) address 00008A34

This is exactly the same distance (34h) as with ATARI Vampire.

Last edited by arnezami; 25th February 2007 at 01:45.
arnezami is offline   Reply With Quote
Old 25th February 2007, 00:00   #8  |  Link
abcx
Registered User
 
Join Date: Jan 2007
Posts: 21
Quote:
Originally Posted by arnezami View Post
Confirmed. This is a (sub) Device Key.

Well done! Welcome in joining our efforts .

Technically there could be more Device and sub Device Keys (that are parents of the found device key) in memory. But I've yet to find one. Given the right memdump it should be possible to retrace it back to the "given" Device Key (the one given to WinDVD 8).
First post here, but I've been following this saga since the beginning...

Am I right in understanding that this is the last sub Device key in the tree? That is, the one right before the Processing Key?

EDIT: One more question, do the memory locations\addresses (the ones with the DK) remain static on every run?

Thanks

Last edited by abcx; 25th February 2007 at 00:03.
abcx is offline   Reply With Quote
Old 25th February 2007, 00:58   #9  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by abcx View Post
Am I right in understanding that this is the last sub Device key in the tree? That is, the one right before the Processing Key?
Yes

Quote:
EDIT: One more question, do the memory locations\addresses (the ones with the DK) remain static on every run?
I don't know, but this not very important. What it is important is that the relative positions of both are always the same.

DKs are 128 bit pseudo-random keys. Once you know a DK, it is easy to locate first copy in memory. So it is easy to locate the other position if you know the offset of the second DK relative to the first DK. If both copies are not identical, you have probably found a new DK (the parent of the first DK).

Last edited by xyz987; 25th February 2007 at 01:05.
xyz987 is offline   Reply With Quote
Old 1st March 2007, 16:06   #10  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by arnezami View Post
Confirmed. This is a (sub) Device Key.
....
Technically there could be more Device and sub Device Keys (that are parents of the found device key) in memory. But I've yet to find one. Given the right memdump it should be possible to retrace it back to the "given" Device Key (the one given to WinDVD 8).
It looks like there should be 22 device keys given out to each device for use on this tree (the tree rooted at level 22 - one of the 512 largest trees in use and defined in the current MKB). There is one original device key for each level of a tree, except the root.

The PK key from arnezami matches up with an S-D set of devices rooted at level 22 and having a difference set ("revoked" pseudo device) in the lower left corner. Everyone below the upper root can calculate that PK key either from an assigned DK or a calculated sub DK.

If the device this key came from is adjacent to the lower left "revoked" device on this tree, then this would be the original device key assigned to that device. If not, then this must be a sub DK and there must be at least one other original DK at a higher level. The farther away this device is from the lower left, the more levels the device had to work through to get to the sub DK used to calculate arnezami's PK.

Are the device numbers for PowerDVD and WindDVD known? If they are different, then at least one of them must have another original DK at a higher level.

Last edited by FoxDisc; 1st March 2007 at 20:06.
FoxDisc is offline   Reply With Quote
Old 25th February 2007, 02:03   #11  |  Link
ATARI Vampire
Registered User
 
ATARI Vampire's Avatar
 
Join Date: Feb 2007
Posts: 14
Quote:
Originally Posted by xyz987 View Post
You say you are using AES-D, but the real function to use is AES-G3 (with an aditional XOR operation at the end). Do you xored the output of AES-D with the seed?
Yes, you are correct. The correct function is AES-G since I xor the AES-D result with the seed value of 0x7B103C5DCB08C4E51A27B01799053BDA. I will correct the type-o in my original post. Thanks!
ATARI Vampire is offline   Reply With Quote
Old 25th February 2007, 18:00   #12  |  Link
sirus20x6
Registered User
 
Join Date: Aug 2006
Posts: 13
Nice

Awesome work!
__________________
~Sirus~
sirus20x6 is offline   Reply With Quote
Old 25th February 2007, 19:05   #13  |  Link
christopherw
Registered User
 
Join Date: Mar 2006
Posts: 24
Hah, well done mate!

I love the fact that I'm witnessing history in the making, they build up the walls and the people with the know how and the patience don't even knock 'em all down again, they just find the back door...
christopherw is offline   Reply With Quote
Old 25th February 2007, 23:31   #14  |  Link
tonyp12
Registered User
 
Join Date: Oct 2002
Location: Florida, USA
Posts: 90
So what does this mean?

You can now write a decrypter program that can
handle all disc to this date?

Or do you need the major device key for that and
not this sub-device key?
tonyp12 is offline   Reply With Quote
Old 25th February 2007, 23:39   #15  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by tonyp12 View Post
So what does this mean?

You can now write a decrypter program that can
handle all disc to this date?

Or do you need the major device key for that and
not this sub-device key?
We need a Private Host Key (to get volume ids) for fully independent decryption of all existing discs. I'm working 24/7 on this (and hopefully others do too) but haven't had any luck yet . My ecdsa crypto setup is working now though (eg. can verify stuff using pub keys from drive and/or host) and its quite speedy now. Using openssl.

The above sub device key has the same value as the Processing Key atm. But its nice to have a (sub) Device Key . More Device Keys (although nice) won't help decrypt existing discs (since we already have the Processing Key and on every disc this same Processing Key is used).



We've conquered the green part. We still need to get the Host Private Key (red) to get Volume IDs (we can sniff/guess them but thats not very userfriendly).

Last edited by arnezami; 26th February 2007 at 00:06.
arnezami is offline   Reply With Quote
Old 26th February 2007, 09:26   #16  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by arnezami View Post
The above sub device key has the same value as the Processing Key atm. But its nice to have a (sub) Device Key . More Device Keys (although nice) won't help decrypt existing discs (since we already have the Processing Key and on every disc this same Processing Key is used).
However if we want to break the revocation system, what we need is Device Keys, so many and so hight in the trees as possible.

Probably the most important discovery of Atari Vampire is not the Device Key itself, but the fact that this DK is stored at 2 different positions at memory.
xyz987 is offline   Reply With Quote
Old 26th February 2007, 10:04   #17  |  Link
evdberg
Registered User
 
Join Date: Dec 2006
Posts: 202
Quote:
Originally Posted by xyz987 View Post
Probably the most important discovery of Atari Vampire is not the Device Key itself, but the fact that this DK is stored at 2 different positions at memory.
Actually the whole discovery is useless. At the time we really need this kind of info, the player will be rewritten to keep the keys better protected and much, much harder to find (at least not by simply searching a memory dump).
evdberg is offline   Reply With Quote
Old 27th February 2007, 00:50   #18  |  Link
lightshadow
Registered User
 
Join Date: Feb 2007
Posts: 123
Quote:
Originally Posted by xyz987 View Post
Probably the most important discovery of Atari Vampire is not the Device Key itself, but the fact that this DK is stored at 2 different positions at memory.
If there someone in this thread with a lot of memory, we can make pattern match script/program that takes the memory dump and compares patterns of 16bytes.

I could probably write it in Matlab, but that would not be efficient=(

In psudo I guess it would be something like
  • load memory dump into an array
  • initialize 2 arrays that will contain offsets of pattern matches.
  • take the 16byte starting at offset 0, and compare them with the 16bytes starting at offset 1.
  • if pattern match, save offsets and compare with 16bytes starting at offset 0 with 16bytes starting at offset 2.
  • when end of data is reached, take the 16bytes starting at offset 1, and start pattern match all over again.

if it is made general enough it could perhaps be used for finding other types of keys? Private host keys perhaps?

Good idea/bad idea?

How big is the memdump?

Last edited by lightshadow; 27th February 2007 at 01:09. Reason: typo
lightshadow is offline   Reply With Quote
Old 1st March 2007, 22:22   #19  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by xyz987 View Post
However if we want to break the revocation system, what we need is Device Keys, so many and so hight in the trees as possible.
Device keys won't do much to break "the revocation system." Even if there is only one valid player out there and you have all the device keys for all the other players, the revocation system will still work to allow that one player and keep all the rest revoked.

I can see two ways to really break the entire system:

1) Break the cryptography (very unlikely)

2) Have the AACS LA leak all their master keys (also unlikely, even if there is only one, and I suspect there are many more than one)

I can see two more ways to effectively break the system:

3) If the AACS LA issues the same device keys to many many standalone devices, and those keys can be extracted, they may be very reluctant to revoke all those devices. We don't know yet if they can revoke individual devices - it depends on what keys were assigned. (This only works if they are both stupid and greedy. Stupid to give too many devices the same keys and greedy because they don't want to revoke all the players for customers who might buy discs. Hmmmmmmmmmm - maybe this would work.)

4) Obtain title keys/device keys/processing keys faster than the AACSLA can harden players and change MKBs. (This seems likely to work (to me) but only time will tell.)

Last edited by FoxDisc; 1st March 2007 at 22:24.
FoxDisc is offline   Reply With Quote
Old 28th February 2007, 02:41   #20  |  Link
HyperHacker
Resident DRM Hater
 
HyperHacker's Avatar
 
Join Date: Oct 2006
Location: International waters
Posts: 242
If someone wants to buy me an HD-DVD drive, I know how to use a debugger...

This is certainly the approach to be taking. Load up your debugger and set a write breakpoint on the memory location that will hold the key, before it's actually there. If you can set it up to break only when a certain value is written, all the better. When you find this write you will be right in the routine that writes the key into memory. From here it'd be easy to make it just give you the key.

Since patching into existing apps is difficult, I'd go a simple route: Simply write the key to some unused memory location, along with some sort of "flag" byte. Another program can be written that will watch this memory region, and when the flag byte appears, read the key. This avoids the need to hack in a bunch of code to write the key to a file or what have you, and is more reliable than simply telling the other app where the key is being written already, since this could be overwritten later.

Once you can do this you can write a program that will launch the player, apply this hack in memory, wait for the user to load a movie, and read the key out. All they'd have to do is run the program (it could even launch the player for them ).
__________________
Because Moogles pwn.

Last edited by HyperHacker; 28th February 2007 at 02:42. Reason: spelling
HyperHacker 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 11:00.


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