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. |
|
24th February 2007, 20:05 | #1 | Link |
Registered User
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. |
24th February 2007, 22:00 | #3 | Link |
Registered User
Join Date: Dec 2006
Posts: 142
|
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. |
24th February 2007, 23:22 | #5 | Link |
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. |
24th February 2007, 23:57 | #6 | Link | |
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
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. |
|
25th February 2007, 01:22 | #7 | Link | |
Registered User
Join Date: Sep 2006
Posts: 390
|
Quote:
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. |
|
25th February 2007, 00:00 | #8 | Link | |
Registered User
Join Date: Jan 2007
Posts: 21
|
Quote:
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. |
|
25th February 2007, 00:58 | #9 | Link | ||
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
Quote:
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. |
||
1st March 2007, 16:06 | #10 | Link | |
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
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. |
|
25th February 2007, 19:05 | #13 | Link |
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... |
25th February 2007, 23:39 | #15 | Link | |
Registered User
Join Date: Sep 2006
Posts: 390
|
Quote:
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. |
|
26th February 2007, 09:26 | #16 | Link | |
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
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. |
|
26th February 2007, 10:04 | #17 | Link |
Registered User
Join Date: Dec 2006
Posts: 202
|
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).
|
27th February 2007, 00:50 | #18 | Link | |
Registered User
Join Date: Feb 2007
Posts: 123
|
Quote:
I could probably write it in Matlab, but that would not be efficient=( In psudo I guess it would be something like
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 |
|
1st March 2007, 22:22 | #19 | Link | |
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
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. |
|
28th February 2007, 02:41 | #20 | Link |
Resident DRM Hater
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 |
Thread Tools | Search this Thread |
Display Modes | |
|
|