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, 00:00   #7  |  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   #8  |  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 25th February 2007, 01:22   #9  |  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, 02:03   #10  |  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   #11  |  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   #12  |  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   #13  |  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   #14  |  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   #15  |  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   #16  |  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 26th February 2007, 10:44   #17  |  Link
zeroprobe
Registered User
 
Join Date: Jan 2002
Posts: 155
Quote:
Originally Posted by evdberg View Post
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).
Its more information. It won't hurt anything not to do it as they will be changing the keys anyways.
zeroprobe is offline   Reply With Quote
Old 26th February 2007, 10:52   #18  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by evdberg View Post
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).
However it is possible to get a full set of Device Keys from nowadays version. One of these keys is key 2 (or 3) of master tree (22 level), other of these keys is key 2 (or 3) of one of the two 21 level subtrees and so on. This is a big chunk of keyspace, and this chunk is no longer available for future revocations.

Sure, keyspace is huge, but it is limited anyway.

Last edited by xyz987; 26th February 2007 at 11:20.
xyz987 is offline   Reply With Quote
Old 26th February 2007, 23:06   #19  |  Link
xyz987
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.
xyz987 is offline   Reply With Quote
Old 27th February 2007, 00:50   #20  |  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
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 10:52.


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