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, 00:00 | #7 | 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 | #8 | 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. |
||
25th February 2007, 01:22 | #9 | 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, 19:05 | #12 | 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 | #14 | 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 | #15 | 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 | #16 | 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).
|
26th February 2007, 10:52 | #18 | Link | |
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
Sure, keyspace is huge, but it is limited anyway. Last edited by xyz987; 26th February 2007 at 11:20. |
|
26th February 2007, 23:06 | #19 | Link |
Registered User
Join Date: Dec 2006
Posts: 142
|
I have developed a little program that outputs a PK (arnezami's) from the "central" seed (s0+1) and a DK (Atari Vampire's) previously stored at source code.
It is easy to modify it to output a DK from any DK. To do so, just modify seed (last byte is 0xd9 (to output left DK) or 0xdb (to output right DK)) and set inputkey to the parent DK. To run: javac devkey.java java devkey Code:
/* * devkey - By xyz987. Released under GPL v2 * * asHex() method is an example method from Sun Microsystems, Inc. website * and Sun licensed it under BSD license * http://developers.sun.com/license/berkeley_license.html * * Some routines are based on BackupHDDVD by muslix64 */ import javax.crypto.Cipher; import java.security.NoSuchAlgorithmException; import java.lang.Exception; import javax.crypto.spec.SecretKeySpec; import javax.crypto.SecretKey; import java.io.*; public class devkey { static Cipher AES = null; static{ try{ AES =Cipher.getInstance("AES/ECB/NOPADDING"); }catch(Exception e){ e.printStackTrace(); } } public static byte[] decrypt(byte[] inputKey, byte[] seed){ try{ SecretKey AESKey = new SecretKeySpec(inputKey,0,16,"AES"); AES.init(Cipher.DECRYPT_MODE,AESKey); return AES.doFinal(seed); }catch(Exception e){ e.printStackTrace(); } return null; } public static String asHex (byte buf[]) { StringBuffer strbuf = new StringBuffer(buf.length * 2); int i; for (i = 0; i < buf.length; i++) { if (((int) buf[i] & 0xff) < 0x10) strbuf.append("0"); strbuf.append(Long.toString((int) buf[i] & 0xff, 16)); } return strbuf.toString(); } public static void main(String [] args) { int i; // testing values of seed, inputkey, and outputkey (in that order): // 7B103C5D CB08C4E5 1A27B017 99053BDA // AA856A1B A814AB99 FFDEBA6A EFBE1C04 // 09F91102 9D74E35B D84156C5 635688C0 byte[] seed = { (byte)0x7b, (byte)0x10, (byte)0x3c, (byte)0x5d, (byte)0xcb, (byte)0x08, (byte)0xc4, (byte)0xe5, (byte)0x1a, (byte)0x27, (byte)0xb0, (byte)0x17, (byte)0x99, (byte)0x05, (byte)0x3b, (byte)0xda }; byte[] inputkey = { (byte)0xaa, (byte)0x85, (byte)0x6a, (byte)0x1b, (byte)0xa8, (byte)0x14, (byte)0xab, (byte)0x99, (byte)0xff, (byte)0xde, (byte)0xba, (byte)0x6a, (byte)0xef, (byte)0xbe, (byte)0x1c, (byte)0x04 }; byte[] outputkey = { (byte)0x62, (byte)0x65, (byte)0x65, (byte)0x65, (byte)0x65, (byte)0x65, (byte)0x65, (byte)0x65, (byte)0x65, (byte)0x65, (byte)0x65, (byte)0x65, (byte)0x65, (byte)0x65, (byte)0x65, (byte)0x65 }; outputkey= decrypt(inputkey, seed); for (i=0; i<16; i++){ outputkey[i]= (byte) (outputkey[i] ^ seed[i]); } System.out.println("Output key is: " + asHex(outputkey)); } } Last edited by xyz987; 26th February 2007 at 23:18. |
27th February 2007, 00:50 | #20 | 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 |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|