WinDVD 8 Device Key Found! [Archive]

ATARI Vampire

24th February 2007, 20:05

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

noclip

24th February 2007, 21:18

Can someone confirm this?

xyz987

24th February 2007, 22:00

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.

xyz987

24th February 2007, 22:05

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?

arnezami

24th February 2007, 23:22

xyz987

24th February 2007, 23:57

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.

abcx

25th February 2007, 00:00

Confirmed. This is a (sub) Device Key. :D

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

xyz987

25th February 2007, 00:58

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

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).

arnezami

25th February 2007, 01:22

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.

ATARI Vampire

25th February 2007, 02:03

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!

sirus20x6

25th February 2007, 18:00

Awesome work!

christopherw

25th February 2007, 19:05

Hah, well done mate! :D

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...

tonyp12

25th February 2007, 23:31

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?

arnezami

25th February 2007, 23:39

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).

http://img504.imageshack.us/img504/3025/hosttn8.png

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).

xyz987

26th February 2007, 09:26

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.

evdberg

26th February 2007, 10:04

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).

zeroprobe

26th February 2007, 10:44

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.

xyz987

26th February 2007, 10:52

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.

xyz987

26th February 2007, 23:06

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

/*
* 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));
}
}

lightshadow

27th February 2007, 00:50

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?

lightshadow

27th February 2007, 01:12

I have just come to think of DRM Tools (http://saf.bio.caltech.edu/drm_tools.html)

drm_tools contains the following small utilities:

accudate modified date utility with subsecond accuracy
columnadd adds columns of integers, decimals and/or times
datasniffer a tool for dumping binary data
execinput runs an input file as a series of commands
extract a tool for extracting row/column data from files
mbin input tool for buffering large binary data streams.
mbout output tool for buffering large binary data streams.
mdump a tool for dumping binary data.
msgqueue command line manipulation of message queues

jokin

27th February 2007, 03:02

My memory dumps have been 300 MB or so.

HyperHacker

27th February 2007, 06:24

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?
I could do this in C and I have 1GB of RAM, but what exactly would this accomplish? It just sounds like you're trying to make a list of memory locations that contain the same 16 bytes as other memory locations. I see no real use for this, and blocks of uninitialized memory would inflate the list to ridiculous proportions.

arnezami

27th February 2007, 07:26

We have 4 problems when working with memdumps:

1) The size of the memdumps
2) The low speed of checking if any x bytes is a key
3) The very short period the key is in mem
4) The inaccuracy of knowing when the key might be in mem (no easy sign)

So I have been thinking of something a little different (but i'm not sure yet if it would be very useful): make many memdumps (and keep making them) then scan one memdump for all unique 16 (or 20) bytes and write each of them in a hash table (or some binary tree tructured file) or simply a sorted file of 16/20 byte values. The idea is you can do this with all these memdumps and gather a set of already tried keys. This way only the unique sets of bytes have to be used for checking whether they are in fact keys or not. And you only have to check additions to the set (of unique 16/20 bytes) caused by new memdumps.

Why? Because when trying to find a key you need a memdump at the exact right time (this is the tricky part when with memdumps only and doing no altering of the code). In practice this means you need many memdumps at around the same time and you somehow have see whether a new memdump contains anything "better" then your last ones. But you can only do that if you know what you're tried so far. Simply trying (for example) each 20 byte value in each 150-300MB memdump at a speed of a few thousands per second (this is the speed of ecdsa...** see the problem?) is time consuming.

Of course we can try to pinpoint/anticipate where a private key/device key might be but we could be mistaken (and requires a more "hands-on" approach). Therefore the above might not be such a bad idea.

The biggest problems with this idea: (a) simply processing one memdump for new possible keys may be timeconsuming (many mem lookups, although some basic randomness checking will speed things up big time) and (b) maybe there will be too many unique values each startup of the Player so the hash table/tree will get too big (you do have to use the same movie and player each time of course).

Technically we could even share this stuff but only between people who own the same disc/movie and software player (and since memdumps contain lots of pc/drive identifying stuff it can't really be done publicly).

Alternatively maybe some kind of diff between an old dump and a new dump could work but when looking at dumps I'm not so sure they are organized exactly the same each time: looks quite dynamic... So diffs won't work so well.

I'm also thinking about releasing a proggy that can check a memdump for a private key so everybody can start trying to find it. What do you think?

Regards,

arnezami

PS. Personally I'm starting to think using a debugger and or altering binaries will be much more useful. But since I'm not experienced with those somebody else will have to try that. I've read somewhere about altering some kind of zeromemory-function (which was called by P DVD many times) so it wouldn't clear its mem. Something like that...

** I'm using pre-computation, "light" private key checking, fast entropy/randomness detection. So it won't go much faster...

lightshadow

27th February 2007, 08:47

I could do this in C and I have 1GB of RAM, but what exactly would this accomplish? It just sounds like you're trying to make a list of memory locations that contain the same 16 bytes as other memory locations. I see no real use for this, and blocks of uninitialized memory would inflate the list to ridiculous proportions.
Okay, I forgot to write the rest. When the locations have been collected, then it should write out the 16bytes of each location.

But I see the problem with uninitialized memory...

Pata

27th February 2007, 14:38

We have 4 problems when working with memdumps:
I'm also thinking about releasing a proggy that can check a memdump for a private key so everybody can start trying to find it. What do you think?

Boyer Moore is fast
http://en.wikipedia.org/wiki/Boyer-Moore_string_search_algorithm

Like GSAR.

Or maybe others..
http://www-igm.univ-mlv.fr/~lecroq/string/index.html

natronicus

27th February 2007, 17:31

PS. Personally I'm starting to think using a debugger and or altering binaries will be much more useful.
This is the best approach. If you can learn where to set the right breakpoints, you can step through and keep an eye on memory after every event, until you can reliably come to the same position.

Since you already know where the keys are stored in memory, it should be fairly trivial to identify when it first occurs, then back up and figure out exactly what is happening leading up to it.

BlazingMind

27th February 2007, 21:12

I've been following these decryption threads with great interest lately, and I would like to start off by congratulating you all for the progress you have made :-) Good work!!!

About debuggers though...
There arent really that many people that have access to SoftIce / IDAPro etc. and are capable of using them effectively. Even fewer I suppose, that also has access to HD DVD / BR hardware, software and a movie or two.

So... I've been thinking about how the "average" AACS cracker would be able to get some useful data out that later could be interpreted by someone with the right skills with reverse engineering.

This is why I would like to suggest that you take a look Cheat Engine and TSearch.

Both programs should be able to act as a debugger that should enable you to get to the routines that handle the keys.

Let's say you found a sub device key in memory... If you loaded CE and selected "add address manually" and then selected "find out what writes to this address", you should end up with a list of addresses to the actual code that handles the keys.

Even if the keys change, these addresses should be static for each build of the software, so it should be far easier to extract more keys by following these routines... (in theory)

If you were able to identify the routines that handles the keys, they can again be followed to see where other keys are stored. (find the AES-G algo and I believe you have what you need to get all keys by following the data output from it).

...Just a thought...

xyz987

27th February 2007, 22:00

This is why I would like to suggest that you take a look Cheat Engine and TSearch.

Both programs should be able to act as a debugger that should enable you to get to the routines that handle the keys.

Let's say you found a sub device key in memory... If you loaded CE and selected "add address manually" and then selected "find out what writes to this address", you should end up with a list of addresses to the actual code that handles the keys.

Even if the keys change, these addresses should be static for each build of the software, so it should be far easier to extract more keys by following these routines... (in theory)

If you were able to identify the routines that handles the keys, they can again be followed to see where other keys are stored. (find the AES-G algo and I believe you have what you need to get all keys by following the data output from it).

This seems to be a far good approach.

lightshadow

27th February 2007, 22:13

This is why I would like to suggest that you take a look Cheat Engine and TSearch.
I know the ScummVM folks are very happy (http://www.scummvm.org/?shownews=20070105.xml) with IDA - The Interactive Disassembler (http://www.datarescue.com/idabase/index.htm).

I have no idea how easy/complicated it is to use.

arctor

27th February 2007, 22:57

Another option is too have a look in AnyDVD for the private key. If they are using the PowerDVD 6.5 private key we may be able to grab this from AnyDVD.

Strikes me that it may not be as well protected as WinDVD and PowerDVD. Plus there is almost a sense of irony of hacking AnyDVD

BlazingMind

28th February 2007, 00:15

Strikes me that it may not be as well protected as WinDVD and PowerDVD. Plus there is almost a sense of irony of hacking AnyDVD

Usually software created by hackers is far better protected than commercial stuff. The reason is that the hacker knows all the common pitfalls, and how to avoid them, while commercial programmers (that write programs in high-level languages etc.) don't know how to protect their stuff properly. Besides, they are often on a "clock", and don't have time to go through all the details...

BlazingMind

28th February 2007, 00:20

I have no idea how easy/complicated it is to use.

IDAPro is the only disassembler you'll ever need, but you need to know a great deal of assembler to be able to make sense out of it. Assembler is not something you learn in 24 hours.

Driverstudio / SoftICE would probably be the tool of choice here though... You probably need to debug the code while it's running, and that is even harder than reading it in IDAPro :-P

Anyways...
The CE and TSearch are freeware programs, and not that hard to use. It is better suited for those with little or no assembler skill.

Edit: confusing sentance :P

HyperHacker

28th February 2007, 02:41

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 :)).

BlazingMind

28th February 2007, 09:39

If someone wants to buy me an HD-DVD drive, I know how to use a debugger... ;)

You and me both ;-)

There is however a pitfall which can make this approach a tad too heavy for the average user.

If self modifying code is used, the address of the routine may change. I doubt it is however, because SMC is a horrible thing to implement in such a routine as it takes huge performance penalties due to the code changing before execution.

Has anyone tested if the keys tend to stay at similar addresses, or will they appear at random?

From what I've seen so far, the addresses are placed so low that I doubt they are dynamically allocated. If this is the case, they should be consistent within the same build of the software... Anyone feel like checking?

Arne / ATARI, care to post the build numbers of your players? If this can't be found, check the version information on the exe file. Even the last modified date and filesize of your exe files may help identify the build.

Also check if the address changes after a reboot please.

BlazingMind

28th February 2007, 10:17

I see no real use for this, and blocks of uninitialized memory would inflate the list to ridiculous proportions.

Actually... it may not be such a bad approach after all.

Unused memory areas tend to be zeroed out (unless a buffer is reused without being unallocated). To do this, you should check for patterns. Of the 16 bytes, no byte should statistically appear more than twice, and the first 8 bytes should not match the last 8.

This should be enough to get rid of the mismatches.

If a buffer is reused, it will contain "random" data, that statistically will not match with 16 bytes at an offset of 034h.

I say it is worth a try...

(Grr.. I could do so much more if I had the actual hardware and software :P)

ATARI Vampire

28th February 2007, 20:11

Has anyone tested if the keys tend to stay at similar addresses, or will they appear at random?

WinDVD 8: Keys remain at the same memory locations (Device, Processing, Media, VUK and VID)

PowerDVD 6.5: Pending further analysis... keys migrate constantly between different memory locations. Currently working on documenting the pattern (still assuming it is not pseudo random).

BlazingMind

1st March 2007, 01:10

PowerDVD 6.5: Pending further analysis... keys migrate constantly between different memory locations. Currently working on documenting the pattern (still assuming it is not pseudo random).

Don't bother, they are random in the sense that windows decides where to put it based on how much free mem you have etc. Try using CE to trace the keys back to a routine that handles the keys. This should be a static address.

dirio49

1st March 2007, 02:07

IDAPro is the only disassembler you'll ever need, but you need to know a great deal of assembler to be able to make sense out of it. Assembler is not something you learn in 24 hours.

Driverstudio / SoftICE would probably be the tool of choice here though... You probably need to debug the code while it's running, and that is even harder than reading it in IDAPro :-P

Anyways...
The CE and TSearch are freeware programs, and not that hard to use. It is better suited for those with little or no assembler skill.

Edit: confusing sentance :P

I am not a professional but I also like OllyDbg ;)
I think easier than CE.

ffguy

1st March 2007, 03:41

mb2696

1st March 2007, 03:54

BlazingMind

1st March 2007, 09:34

I am not a crypto expert by any means, just an interested programmer.
Given enough of the keys, one could theoretically figure out the master key used to generate them all by guess-and-check, correct? It wouldn't be fast, but it could be theoretically done.
I ask because I have several computers with nothing to do. By splitting the potential solution space into many many parts, people like me with too much time on their hands could start chipping away at the problem. Divide the solution space and start handing out slots, if not to find the key than to verify where it is not.

I'm afraid the algorithms are too slow to do a brute force attack if we don't have a shortcut.

If you remember distributed.nets DES attack, it took ages to get anywhere, and that was with a fast algorithm and a tiny key (in comparison).

I'm not skilled enough with the underlying crypto to write this in assembler, but if anyone would be interested in joining forces, we might be to write highly optimized assembler code to attack these algos. This will help a little, but I fear it will still be an "impossible" task due to the nature of the algos.

Even if we managed to get 1 000 000 checks/second on an average computer (about the same speed as highly optimized MD5 brute force attacks run at today), we would still need 10 000 000 000 computers for 1 079 028 307 080 601 years to check all keys in the keyspace.

In other words... With Moores Law, we can't expect to do an effective brute force on such a key during the next 32 years, and it would still take 10 000 000 000 computers and 3-4 months.

ps. don't shoot me if it turns out that I've miscalculated this slightly, I'm not used to working with large numbers like these ;-)

HyperHacker

1st March 2007, 09:37

Yeah, that's the problem with brute-forcing keys, it takes forever. A 128-bit key can be one of 2^128 = 3.4028236692093846346337460743177e+38 keys; even if you could arrange a bunch of computers to test one billion keys per second, it'd take about 10782897524556318080696.079785274 years to try them all. :eek:

Of course you could get lucky and it ends up being the first key tried... or you could get unlucky and it ends up being the last. Statistically, odds are this solar system won't still exist by the time we find the key at that rate.

BlazingMind, what is the goal with this memory search idea? You're trying to find places where the same 16 bytes occurrs twice in memory? Why is this?

BlazingMind

1st March 2007, 10:17

BlazingMind, what is the goal with this memory search idea? You're trying to find places where the same 16 bytes occurrs twice in memory? Why is this?

From what I understand, it is possible to obtain the various keys for those skilled enough to find them. This tool would help make it easier to find these keys so that more people would be able to find them, and that again adds pressure to the revocation system.

If such a tool does not help, my post about it is irrelevant ofcourse ;-)

blutach

1st March 2007, 11:20

Yeah, that's the problem with brute-forcing keys, it takes forever. A 128-bit key can be one of 2^128 = 3.4028236692093846346337460743177e+38 keys; even if you could arrange a bunch of computers to test one billion keys per second, it'd take about 10782897524556318080696.079785274 years to try them all. :eek:

Of course you could get lucky and it ends up being the first key tried... or you could get unlucky and it ends up being the last. Statistically, odds are this solar system won't still exist by the time we find the key at that rate.Really putting it into perspective there HyperHacker!! :D

Regards

awhitehead

1st March 2007, 16:03

A 128-bit key can be one of 2^128 = 3.4028236692093846346337460743177e+38 keys; even if you could arrange a bunch of computers to test one billion keys per second, it'd take about 10782897524556318080696.079785274 years to try them all. :eek:

Theoretically, given a 128 qbit (or larger) quantum computer, Peter Schor's algorithm will be able to factor it. They supposedly got working quantum computers with up to 16 qbits now (that can factor 2^16 keyspace) , so in another 10, 20 years, once AACS is no-longer relevant, this might be feasible. But not until then.

Coincidentially, modelling a quantum computer with more then ~60 qubits using conventional computers requires more bytes of RAM, then there are electrons in universe. A slight problem.

FoxDisc

1st March 2007, 16:06

Confirmed. This is a (sub) Device Key. :D
....
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.

P0l1m0rph1c

1st March 2007, 16:40

Theoretically, given a 128 qbit (or larger) quantum computer, Peter Schor's algorithm will be able to factor it. They supposedly got working quantum computers with up to 16 qbits now (that can factor 2^16 keyspace) , so in another 10, 20 years, once AACS is no-longer relevant, this might be feasible. But not until then.

Coincidentially, modelling a quantum computer with more then ~60 qubits using conventional computers requires more bytes of RAM, then there are electrons in universe. A slight problem.

This is not RSA, so Shor's algorithm does not apply.

In a quantum computer the speedup is quadratic in the general case, so to break a 128 bit key we would still need sqrt(2^128) effort, i.e. about 2^64 iterations to succeed.

Still a bit too large.

FoxDisc

1st March 2007, 17:04

In a quantum computer the speedup is quadratic in the general case, so to break a 128 bit key we would still need sqrt(2^128) effort, i.e. about 2^64 iterations to succeed.

This discussion of breaking keys is interesting, but it's not clear what key you want to break (at least not to me). It is possible that the AACSLA set up a system with a single 128 bit key used as seed for a pseudorandom generator of master keys. That seed could then be used to derive all other keys in the entire AACS system. However, it's also possible that they set up a system with billions of randomly generated 128 bit master keys. No one knows for sure which system they set up. I suspect it was the latter, so breaking one key would not get you very far.

KornX

1st March 2007, 18:23

As i wrote some other time,
if you are talking about bruteforce cracking a 128bit cypher,
please keep the Landauer Limit in Mind...

http://en.wikipedia.org/wiki/Landauer%27s_Principle

Regards

KornX

BlazingMind

1st March 2007, 20:28

This is not RSA, so Shor's algorithm does not apply.

In a quantum computer the speedup is quadratic in the general case, so to break a 128 bit key we would still need sqrt(2^128) effort, i.e. about 2^64 iterations to succeed.

Still a bit too large.

Actually that would be an average of 2^127 (sorry for going slightly off topic :P)

FoxDisc

1st March 2007, 22:22

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.)

cwl7454

1st March 2007, 23:29

One must ask themselves, how did slysoft accomplish the break? Highly unlikely that they are using someone else's certificate without their permission or reverse engineered, as this would bring it's own set of problems; or would be still selling the program without AACS knowledge. They are making no bones about the program being availible on the open market.

xyz987

2nd March 2007, 01:32

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.

You are right when you say that just Device Keys are not enought to break it. However the capability to get full sets of Device Keys will break it. It is this capability what matters, not the Device Key itself, and the way to get this capability is getting previously some DKs.

As I previously posted, if attacker A gets a full set of DKs, he can simply publish the DK that directly computes the PK. They can not revoke the player because they don't know its identity. If they revoke the DK, attacker simply publish the new DK that is used to "encrypt" (to compute the new PK). So they must try traitor tracing, but this is probably not effective (i.e. "traitor" can not be traced).

However to get this capability (getting full sets of DKs) attacker A needs some people have experimented how to get DKs. Attacker A can use this previously found keys to know what to search, or to check if his method is really getting DKs, and previous practice is even more important than keys. That's why I said we need to get so many keys and so hight in the trees as possible.

They can not revoke any player if they don't know its identity. Traitor tracing is at the very center of the problem, if they can not do it effectively, AACS will become quickly broken.

Edit: just an example:

Let's say WinDVD 8 is player 9 at master tree (22 level), so it has keys 8,5,3 in its DK set. If you get its DK set, you know which is WinDVD 8 position at master tree (you know it is player 9). A lot of useful information can be extracted of DK sets. This includes knowing if some standalones share the same keys, if soft players are contiguous at master tree, where a model of standalone stores DKs and how they are protected, and a lot of awaiting discoveries. WinDVD 8 will be revoked, the first compromised standalone will be revoked. So what?. Discoveries will remain.

lightshadow

2nd March 2007, 02:14

arnezami

2nd March 2007, 07:41

Hi,

Just for clarity: we don't need a Device Key at this moment.

We need the Host Private Key.

I hope you guys and girls realize that. :)

Regards,

arnezami

BlazingMind

2nd March 2007, 10:33

About the pattern (key) matching in memdumps we were talking about. It seams that "pattern matching" is a huge field in computer science, so there might be many programs already we can use? Where would be a good place to search for such?

Can anyone conmit if they fit out needs?

Pattern Matching (http://freshmeat.net/projects/match/)
Designing Your Own Pattern Matching Routines (http://maven.smith.edu/~thiebaut/ArtOfAssembly/CH16/CH16-6.html)
Perhaps the most promissing pattern match? (http://www.dmitry-kazakov.de/match/match.htm)

Just to elaborate...
There is no pattern in the key. Also, don't expect all the 300MB of data to be matched to a pattern (leaving only the keys as non-patterned).

Arnezami:
Most of us are aware that it is the Host Private Key that is the holy grail.

The way I see it, we have only 3 ways to get it.

1. Continously taking memdumps from the app and go through all the data captured this way and search for the HPK.

2. Disassemble the code and follow its execution until you find the key.

3. Trace the device keys back to the AES-G algorithm and then trace its data back to the unmarked gray box in your drawing (sorry, havent checked what altorithm is used here... AES-D?) that mixes VID with HPK and log its input data until we find the HPK. This method can also be used to follow the VID to the HPK.

Option 1 is an extremely heavy task as you get huge amounts of data to analyze. On the positive side, a tool can be written to make the key searching automated so that non-programmers/hackers can contribute as well. The amount of data alone will however make this very computer intencive

Option 2... To be able to do this, you need to be a very experienced cracker with a huge amount of spare time. I speculate however that if PKs are known, this is the way they were found. This is by far the fastest way to get the HPK, but also the most demanding way.

Option 3 is what I would consider the best way for people with some programming skills to attack the HPK. Non-programmers can collect data, and with the right software/hardware in place, a semi competent cracker can analyze the data and find the key.

So...
Since I don't have hardware or software to help out, I can only guide you on the way.

Please help me clarify the following though...

From my understanding, you are still working with memory dumps taken during the "authentication/handshake" sequence of the process. This results in a file that is approx. 300MB?

You know when the VID is loaded into memory (right?).

Since the VID is used together with the HPK, it might also be worth wile to follow the VIDs to see if you can get to the HPK this way.

arnezami

2nd March 2007, 11:22

Ok. Let me clarify some stuff. It looks like I haven't been very clear about the Host Private Key.

First off the Volume ID is retrieved (not calculated). The Private Host Key is only used as a "passport" to let the drive give you the information it normally wouldn't give away (like the Volume ID).

Device/Processing/Media Keys have nothing to do with this process. Its a completely separate part of AACS. And I admin the gray box is a bit obscure and confusing. Sorry about that.

http://img504.imageshack.us/img504/3025/hosttn8.png

What's in the gray box? Basicly this:

http://img389.imageshack.us/img389/6513/aacsauthrm7.png

and this:

http://img105.imageshack.us/img105/3610/volidyb3.png

The above is the communication between Software Player (=Host) and drive.

What is very clear is that first the AACS-auth communication is done (the picture with the Hpriv in it) and after that the Volume ID is retrieved (the last picture). However when the volume ID is retrieved the Hpriv is long gone (its not in memory anymore).

What I have done is halt the player the very moment the Hsig (or Hv) gets into memory. Since the Hsig is the result and the Hv is part of the input of the ECDSA signing function (for which the player needs the Host Private Key!) this was my best bet at finding the Private Key. But its already gone. It looks like i'm a few ms too late... (btw I always see both the Hv and the Hsig in mem which is a problem, indicating I might be looking at a copy of the Hv and Hsig)

This is the problem I am facing: how to stop the player at just the right time. I've tried to stop it just before and just after the signing function but no luck yet. It keeps slipping through my fingers ;).

I've also thought about this: in order for the player to sign it first has to SHA1-hash the "message" it wants to sign: this "message" is: Dn || Hv (the || simply means they are concatenated or "glued" together: Dn = 20 bytes, Hv = 40 bytes, resulting "message" = 60 bytes, and of course the SHA1-hash of this "message" is 20 bytes). Technically the hashing is part of the ECDSA signing process/function so its ideal as a marker. But this hash is not in any of my memory dumps (and btw its always different so its not very easy to check). But if I could find it in memory its quite likely the Private Key will also be in memory. But in order for this to work I need to be able to guess where this SHA1-hash is going to be written in memory so I can scan that area on-the-fly. This is what I'm currently working on.

Hope that helps to clarify it a bit.

Regards,

arnezami

PS. Of course me being able to find the private key also hinges on the fact that my private-key-identifyer is working correctly... :)
PPS. I'm also believe i'm having a practical problem: my GetMemoryAddressFromPattern function (link (http://forum.doom9.org/showthread.php?t=120970)) doesn't seem capable of looking at the entire memory: it doesn't appear to be able to find patterns that are in the further portions of memory (those areas I can see using a WinHex dump). I'm not sure what "further" exactly is here. If somebody can give suggestions to solve this please do. :) The function uses lpMaximumApplicationAddress (http://msdn2.microsoft.com/en-us/library/ms724958.aspx) which seems to be correct. :confused:

BlazingMind

2nd March 2007, 12:20

BlazingMind

2nd March 2007, 12:23

PPS. I'm also having a practical problem: my GetMemoryAddressFromPattern function doesn't seem capable of looking at the entire memory: it can't find patterns that are in the further portions of memory (those areas I can see using a WinHex dump). I'm not sure what "further" exactly is here. If somebody can give suggestions to solve this please do. :)

It might be that it gets confused by signing? (addresses above 2GB may be interpreted as being negative or positive). Just a guess.

What language is it written in?

xyz987

2nd March 2007, 12:25

We need the Host Private Key

Just a question. Can they revoke a Host Private Key?

arnezami

2nd March 2007, 12:33

Arnezami:
Thanks for clearing things up... It seems i missed the fact that the optical drive also has a part in this play (Maybe you could add this to your drawing as well? :P)

I have another question or two though... (sorry for not reading all the details on how AACS works).

1. From my understanding, Hpriv is never relly needed for anything else but calculating Hsig. Why on earth would the Hsig be calculated in software, and not on the actual optical drive? Calculating it in the player would expose it to attacks like this, but from what I can see, the other components of Hsig is far less sensitive than Hpriv, and could be sent to the drive for Hsig calculation.

2. You have a complete sniff of the comunication with the drive during this sequence, correct? If these design specs are 100% correct, you should have a sniff of the Hpriv, so if you can't find it, it is probably because your analysis software has flaws.

All in all i do get a feeling that there is something missing from this picture though. The Hsig calculation seems like a red herring to me as I can't see any reason why the Hpriv should need to be accessible outside of the optical drive. Could it be that there are "secret specifications" that says "disregard figure x.x on page x. This is just written to throw off the hackers..." Or... "Hpriv should be encrypted before Hsig is calculated"...

Again, I don't have a good understanding of this system, so it may just be that I'm missing something...

Yeah you're missing something ;).

The private host key is kept private for the host (= software) while the private device key is kept private for the drive. The private host key is never send towards the drive (as you can see in the picture). That would defeat its purpose. But for a very short amount of time the private host key has to be used to sign the Dn||Hv (and this Hsig is sent to the drive) so the drive knows you have the private key. Only if this signature is given to the drive will it give the volume id later on.

And yes: I have sniffed my usb and can see the Hsig being sent to the drive. I'm even capable of verifying this Hsig using the Host Public Key. Its all working according to specs.

arnezami

2nd March 2007, 12:35

Just a question. Can they revoke a Host Private Key?

Yes. In fact they can make it impossible for the current WinDVD version to play discs that work now (if you insert a new disc with a new HRL on it). Your drive won't give away the Volume ID anymore using this Host Private Key (you will have to extract a new one from a new version of a software player).

Its called: the Host Revocation List. Please read the AACS Common specs...

Again: we always need two things to decrypt a disc:

- Device/Processing Key
- Host Private Key

Only then can we get to the (unrevokable) VUKs. :)

arnezami

2nd March 2007, 12:43

It might be that it gets confused by signing? (addresses above 2GB may be interpreted as being negative or positive). Just a guess.

What language is it written in?
I've edited my (red) posting and added some links.

xyz987

2nd March 2007, 12:58

Yes. In fact they can make it impossible for the current WinDVD version to play discs that work now (if you insert a new disc with a new HRL on it). Your drive won't give away the Volume ID anymore using this Host Private Key (you will have to extract a new one from a new version of a software player).

Its called: the Host Revocation List. Please read the AACS Common specs...

That's what I thought. Host Private Key is just a thing that is useful to get Volume IDs, but they can revoke HPK and Volume IDs can be read by other ways. So I can not understand why you give so big importance to HPK.

Again: we always need two things to decrypt a disc:

- Device/Processing Key
- Host Private Key

Only then can we get to the (unrevokable) VUKs. :)

No, you are wrong here. We need DK/PK and VolumeID. There are other ways to get VolumeID (USB sniffing, device hacked firmware and probably others).

arnezami

2nd March 2007, 13:36

No, you are wrong here. We need DK/PK and VolumeID. There are other ways to get VolumeID (USB sniffing, device hacked firmware and probably others).
Hacking firmware for every type of drive sold in the world is much more difficult than getting one HPK. And (sniffing) doesn't work on other platforms like linux and is not practical for non-savvy people.

What people want is a program that works completely independent from the current Software Players, is easy to use and works on all platforms.

BlazingMind

2nd March 2007, 13:37

I've edited my (red) posting and added some links.

I haven't had time to look into the details of the GetMemoryAddressFromPattern function, but I have a few ideas on what can be wrong...

First of all...

if ((mbi.Type == MEM_PRIVATE) && (mbi.State == MEM_COMMIT))

The type check excludes MEM_IMAGE and MEM_MAPPED. Reasons for excluding memory of this kind...

MEM_MAPPED might be memory mapped files (i.e. very slow), I doubt memory mapped files are used here. It is not likely to be used anyway...

MEM_IMAGE... The only reason I can see for excluding this is because it might represent large memory areas that are unlikely to hold the data we are interested in... This will give a performance boost, but again limit accuracy.

I say you should try to remove the exclusion and see how it goes from there.

arnezami

2nd March 2007, 13:39

if ((mbi.Type == MEM_PRIVATE) && (mbi.State == MEM_COMMIT))

The type check excludes MEM_IMAGE and MEM_MAPPED. Reasons for excluding memory of this kind...

MEM_MAPPED might be memory mapped files (i.e. very slow), I doubt memory mapped files are used here. It is not likely to be used anyway...

MEM_IMAGE... The only reason I can see for excluding this is because it might represent large memory areas that are unlikely to hold the data we are interested in... This will give a performance boost, but again limit accuracy.

I say you should try to remove the exclusion and see how it goes from there.

Thanks. Thats very helpful. Will try it. :)

BlazingMind

2nd March 2007, 13:43

Lol... my last post was written during a very stressful period at work, so it turned out to be quite messy...

What I meant to say, of course, was that you might want to try to change the line into something like this instead:

if (mbi.State == MEM_COMMIT)

(I'm sure you already got that, but just for the sake of clarity).

arnezami

2nd March 2007, 13:46

xyz987

2nd March 2007, 14:15

Hacking firmware for every type of drive sold in the world is much more difficult than getting one HPK. And (sniffing) doesn't work on other platforms like linux and is not practical for non-savvy people.

Just a handful of hackers will develop the hacked firmawe for a handful of widely sold devices, but several thousands of medium/advanced users can flash their devices and get VolumeIDs so they can publish VUKs.

What people want is a program that works completely independent from the current Software Players, is easy to use and works on all platforms.

We already have BackupHDDVD and supposedly BackupBluRay will support VUKs soon. It is command line, but there are people developing GUI versions.

I understand your idea, but the real problem is HPK can be revoked, and soft players can be hardened.

Things that can not be hardened:

A- USB conection
B- Already sold standalones
C- Already sold PC devices

You pointed A and B on previous posts (in fact you was the first person to point them AFAIK). Now you are trying to get a thing that can be revoked (HPK) from a thing that can be hardened (soft player).

arnezami

2nd March 2007, 14:50

Just a handful of hackers will develop the hacked firmawe for a handful of widely sold devices, but several thousands of medium/advanced users can flash their devices and get VolumeIDs so they can publish VUKs.

We already have BackupHDDVD and supposedly BackupBluRay will support VUKs soon. It is command line, but there are people developing GUI versions.

I understand your idea, but the real problem is HPK can be revoked, and soft players can be hardened.

Things that can not be hardened:

A- USB conection
B- Already sold standalones
C- Already sold PC devices

You pointed A and B on previous posts (in fact you was the first person to point them AFAIK). Now you are trying to get a thing that can be revoked (HPK) from a thing that can be hardened (soft player).
I know your arguments but I'm not going to debate this issue any further other than saying this:

Right now we do not have a program that can independently and easely retrieve a VUK. With the HPK we would have. That's why I believe the HPK is important right now.

Can we please leave it at this (for now).

arnezami

FoxDisc

2nd March 2007, 15:48

Just a question. Can they revoke a Host Private Key?

This was answered, but I thought I'd add that not only can they revoke the Host with the Host Revocation List (HRL) and/or the Drive with the DRL, there is even an AACS provision for revoking Content with a Content Revocation List. I can't really imagine that they would ever revoke major releases, or revoke all the titles that are currently out there, but they could!

BlazingMind

2nd March 2007, 16:18

This was answered, but I thought I'd add that not only can they revoke the Host with the Host Revocation List (HRL) and/or the Drive with the DRL, there is even an AACS provision for revoking Content with a Content Revocation List. I can't really imagine that they would ever revoke major releases, or revoke all the titles that are currently out there, but they could!

Lol.. call that an added bonus... I hardly think it was in the design specs, but if I'm not mistaken, the system can revoke any key, so why spend time removing this feature... right?

I can see this being a nice feature if some day a movie is rendered illegal in any way.

FoxDisc

2nd March 2007, 17:05

I hardly think it was in the design specs, but if I'm not mistaken, the system can revoke any key, so why spend time removing this feature... right?

They clearly went to a lot of effort to include Content Revocation in the design specs. The CRL is stored on the disc after the MKB and the Sequence Key Block, just before the encrypted content. The SKB is optional, but as far as I can tell, the CRL is not.

I can see this being a nice feature if some day a movie is rendered illegal in any way.

Maybe they'll eventually want to revoke some porno flicks (after they've made money from allowing them in the first place) ! Or perhaps they'll just decide to automatically revoke all licensed content five years after it was released.

I wonder how many people were told that the players or movies they purchased can be revoked? It's so nice to be able to reach into your customer's home and throw the permanent "off" switch whenever you want. Control is a wonderful drug.

BlazingMind

2nd March 2007, 17:15

Ok... my bad... I gotta start reading those docs before I assume things :P

FoxDisc

2nd March 2007, 21:29

the capability to get full sets of Device Keys will break [AACS]. It is this capability what matters, not the Device Key itself, and the way to get this capability is getting previously some DKs.

We agree on this. Knowing how to get DKs is more useful to an attacker than actually getting them.

As I previously posted, if attacker A gets a full set of DKs, he can simply publish the DK that directly computes the PK.

The DK that directly computes the PK has the same value and carries the same info as the PK itself. A PK is assigned to each unique S-D set of devices and everyone in that set was given the device key that directly computes that PK or they were given a higher DK that allows the direct DK to be computed as a sub DK.

They can not revoke the player because they don't know its identity.

This goes back to traitor tracing. I'm still slogging through the Sequence Key procedures, but I'm not at all convinced that they will have trouble identifying the device to be revoked. The entire SK system was designed exactly to do that job. My impression is that it will work when they get around to using it. Why they didn't use it from the start is the real mystery.

If they revoke the DK, attacker simply publish the new DK that is used to "encrypt" (to compute the new PK).

They don't actually revoke individual DKs. They revoke devices with whole sets of DKs. Until they know what device to revoke, they won't/can't revoke anything. As an example, in the software player group, right now they are revoking one pseudo device in the lower left corner. Everyone else is not revoked, so everyone else has the necesssary DKs to calculate the PK assigned to this group.

So they must try traitor tracing, but this is probably not effective (i.e. "traitor" can not be traced).

I don't know why you say that. They know the "traitor" now - it's PowerDVD and WinDVD. I presume they will revoke them (and all of their DKs) as soon as they are reasonably sure those two have been hardened against current attacks. When they make that revocation, I suspect they will add the Sequence Key tracing system to the disc.

However to get this capability (getting full sets of DKs) attacker A needs some people have experimented how to get DKs. Attacker A can use this previously found keys to know what to search, or to check if his method is really getting DKs, and previous practice is even more important than keys. That's why I said we need to get so many keys and so hight in the trees as possible.

I agree that previously located keys will be useful to an attacker who is attempting to break new discs. If he can find old keys being calculated by new software, it will help find new keys being calculated. However, I don't think it will help much to have old device keys after they are revoked. They won't be used again.

They can not revoke any player if they don't know its identity. Traitor tracing is at the very center of the problem, if they can not do it effectively, AACS will become quickly broken.

We agree - tracing is the key. What is not clear is how good their SK tracing system is, or when, if ever, they will start to use it.

Edit: just an example:
Let's say WinDVD 8 is player 9 at master tree (22 level), so it has keys 8,5,3 in its DK set.

OK, this is using your numbered tree again (very handy, but it's not reproduced in this thread.) If others want to follow you, they should see the Understanding AACS sticky thread.

If you get its DK set, you know which is WinDVD 8 position at master tree (you know it is player 9). A lot of useful information can be extracted of DK sets.

Yes. Knowing the DKs tells you the device nmber. I have asked a couple of times if anyone has figured out the "device number" for WinDVD or PDVD. I guess no one has. BTW, the original NNL paper talks about some advantages to assigning devices sequentially. We don't know if that was actually done.

This includes knowing if some standalones share the same keys,

Yes, if DKs can be found for several standalones, this would be very interesting. The implication is this: If the same DKs were given to multiple standalones (100s or 1000s), the AACSLA will be very reluctant to revoke them - it would revoke innocent customers. If every SA received different DKs, then revoking just the few owned by bad boys will not be a problem for them.

BTW, I know that arnezami is focused on the Host Private Key. He is right that he needs that for a standalone player. However, that key and the PK/DKs that are currently known are likely to be revoked eventually. I am particularly interested in understanding how revocation works.

xyz987

3rd March 2007, 01:49

Can we please leave it at this (for now).

Okay.

xyz987

3rd March 2007, 02:54

The DK that directly computes the PK has the same value and carries the same info as the PK itself. A PK is assigned to each unique S-D set of devices and everyone in that set was given the device key that directly computes that PK or they were given a higher DK that allows the direct DK to be computed as a sub DK.

You are right, but it is nicer to publish the DK :-)

I don't know why you say that. They know the "traitor" now - it's PowerDVD and WinDVD. I presume they will revoke them (and all of their DKs) as soon as they are reasonably sure those two have been hardened against current attacks. When they make that revocation, I suspect they will add the Sequence Key tracing system to the disc.

Yes, they know the traitor because there are just 2 soft players and attackers have published here they got the keys from these 2 soft players. This is right because we are just learning how AACS works and how to break it. However if someone finds a way to get the keys from a model of standalone, and an attacker uses this knowledge to get the keys from a unit of this model, LA will need to do real traitor tracing (not just reading Doom9's forum).

I agree that previously located keys will be useful to an attacker who is attempting to break new discs. If he can find old keys being calculated by new software, it will help find new keys being calculated. However, I don't think it will help much to have old device keys after they are revoked. They won't be used again.

Any player has 22 DKs at master tree. Some of the 22 DKs from player A can be computed from the 22 DKs from player B (the contrary is also true).

OK, this is using your numbered tree again (very handy, but it's not reproduced in this thread.) If others want to follow you, they should see the Understanding AACS sticky thread.

My fault. Here it is:

1
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
2 3
/ \ / \
/ \ / \
/ \ / \
/ \ / \
4 5 6 7
/ \ / \ / \ / \
/ \ / \ / \ / \
8 9 10 11 12 13 14 15

Yes, if DKs can be found for several standalones, this would be very interesting. The implication is this: If the same DKs were given to multiple standalones (100s or 1000s), the AACSLA will be very reluctant to revoke them - it would revoke innocent customers. If every SA received different DKs, then revoking just the few owned by bad boys will not be a problem for them.

A master tree (level 22) has 2^22 (4 millions) leaf keys (level 0) and each player has a leaf DK in its set. You conjetured there are 512 master trees, but spec mentions just one. If there is just one master tree they are dead. There are far more than 4 million players, so they need to give the same DK set to multiple standalones. This is precisely one of the most interesting things we can learn getting DK sets. If your conjeture is true, bad luck for us. If it is false, bad luck for them.

Edit: BTW keyspace is not determined by key length (128 bit) but path length (31 bit), so it is not posible to have 512 master trees because subtrees (21 level and lower) also spend keyspace. It is posible to have 512/22 = 23 master trees (subtrees spend 21 times the space master tree spends), but this allows just a maximum of 23*4 = 92 million players with different DK sets. Still a too low number to give a different DK set to each standalone.

BlazingMind

3rd March 2007, 09:15

Edit: BTW keyspace is not determined by key length (128 bit) but path length (31 bit), so it is not posible to have 512 master trees because subtrees (21 level and lower) also spend keyspace. It is posible to have 512/22 = 23 master trees (subtrees spend 21 times the space master tree spends), but this allows just a maximum of 23*4 = 92 million players with different DK sets. Still a too low number to give a different DK set to each standalone.

I take it there is no way of reducing the kyspace for brute force attacks, even if we managed to get a key further up in the chain?

FoxDisc

3rd March 2007, 10:44

A master tree (level 22) has 2^22 (4 millions) leaf keys (level 0) and each player has a leaf DK in its set. You conjetured there are 512 master trees, but spec mentions just one. If there is just one master tree they are dead. There are far more than 4 million players, so they need to give the same DK set to multiple standalones. This is precisely one of the most interesting things we can learn getting DK sets. If your conjeture is true, bad luck for us. If it is false, bad luck for them.

The current MKB defines 512 Subset Difference Sets. Those S-D sets start at different root nodes on level 22. Devices could have been placed in any one of those groups. Devices in different groups won't share any DKs. None of that is conjecture. What we don't know is whether any devices are in any groups other than the first group (where software players are). We agree that there will be some devices with identical sets of DKs if they put all devices in the first group (with software players) and there are more than 2^22 devices out there. Identical sets of DKs mean they would have to be revoked as a group (they would have the same device number). I don't know why they would do that, but who knows? They could even give all the same models from one manufacturer the same set of DKs. We just don't know. It would be interesting to find out.

Edit: BTW keyspace is not determined by key length (128 bit) but path length (31 bit), so it is not posible to have 512 master trees because subtrees (21 level and lower) also spend keyspace.

I disagree. The path length determines the number of nodes in the level 31 tree. All that is required is that each node have a different key. You and I have discussed whether those starting keys (that only the AACS LA has and which are used to derive all DKs) are assigned randomly and independently for each node, or whether they are derived from a single seed key at the top using a pseudo random generator, but even if they are derived from a single key, there would be 2^128 possible keys for that one key. The "keyspace" is defined by the number of different possible values for a key (key length).

The above discussion of "keyspace" is the usual definition and is relevant for a brute force attack. On further reflection, I think you are not referring to keyspace, but are referring only to the number of different keys given out. I agree that is related to path length, not key length, but I don't see how that helps.

It is posible to have 512/22 = 23 master trees (subtrees spend 21 times the space master tree spends), but this allows just a maximum of 23*4 = 92 million players with different DK sets. Still a too low number to give a different DK set to each standalone.

It's late, so I'll have to let you try to restate this for me, but it looks quite wrong to me. Each of the 512 trees (starting at level 22) has a single master key that allows all DKs on that tree (22 of them)to be derived. Each of the subtrees that starts at level 21 also has a single (different) master key allowing all Dks rooted on that tree to be calculated, etc. since the keyspace 2^128 is large, there is lots of room to assign randomly or pseudo randomly the different keys.

FoxDisc

3rd March 2007, 10:47

I take it there is no way of reducing the kyspace for brute force attacks, even if we managed to get a key further up in the chain?
Never say never, but the AACS system is cryptographically excellent. They give you the keys to watch the movie, so brute forcing is the long long way around, as compared to hunting for the keys they have tried to hide.

lightshadow

3rd March 2007, 11:05

Just to elaborate...
There is no pattern in the key. Also, don't expect all the 300MB of data to be matched to a pattern (leaving only the keys as non-patterned).
It is not a pattern in the keys we are talking about, but a pattern in the memdump, where the key is considered being the pattern.

The reason the subject was brought up, was because of the discovery that the sub device key ware stored more than once in memory, and therefore searching for 16byte patterns, would hopefully output a very limited number of combinationsof keys that could be tested.

When the first output is made, more sophisticated filters could be applied to limit the output even more. E.g. patterns repeated more than 3 times are not of interest etc.

lightshadow

3rd March 2007, 11:15

This is the problem I am facing: how to stop the player at just the right time. I've tried to stop it just before and just after the signing function but no luck yet. It keeps slipping through my fingers ;).
Is it possible in Windows to give a process less CPU time? That would slow it down.

Would it be useful to run the player under Linux using Wine (http://http://winehq.com/)? You can change the NICE (http://webtools.live2support.com/linux/nice.php) level as you like in Linux, and Wine have a very powerful debugger that the Wine developers use to debug Wine.

xyz987

3rd March 2007, 12:57

I take it there is no way of reducing the kyspace for brute force attacks, even if we managed to get a key further up in the chain?

You have to wait some decades until computers are powerful enought to brute force AES128 functions.

May be the word "keyspace" is confusing in the sense i am using it. I am not talking about possible values of the key, but possible positions of the key.

xyz987

3rd March 2007, 14:37

The current MKB defines 512 Subset Difference Sets. Those S-D sets start at different root nodes on level 22. Devices could have been placed in any one of those groups. Devices in different groups won't share any DKs. None of that is conjecture. What we don't know is whether any devices are in any groups other than the first group (where software payers are). We agree that there will be some devices with identical sets of DKs if they put all devices in the first group (with software players) and there are more than 2^22 devices out there. Identical sets of DKs mean they would have to be revoked as a group (they would have the same device number). I don't know why they would do that, but who knows? They could even give all the same models from one manufacturer the same set of DKs. We just don't know. It would be interesting to find out.

Spec says "A given set of Device Keys enables derivation of every key in the master tree except the keys between its leaf and the root". If informative section 3.2.1 is accurate master tree must be the "first" 22 level tree, not the 31 level tree, and all devices must be in that first 22 level tree.

Of course, it is possible spec authors have wrongly written the informative section, but this is hard to believe for me. It would be not so difficult to write devices are divided in isolated groups, each group associated to a different 22 level tree. On the other hand, it has no sense they limit themselves to a 22 level master tree if they can use a 31 level tree as master tree.

The above discussion of "keyspace" is the usual definition and is relevant for a brute force attack. On further reflection, I think you are not referring to keyspace, but are referring only to the number of different keys given out. I agree that is related to path length, not key length, but I don't see how that helps.

I am referring to the number of possible positions (number of nodes). It seems that "keyspace" is not a well chosen word.

It's late, so I'll have to let you try to restate this for me, but it looks quite wrong to me. Each of the 512 trees (starting at level 22) has a single master key that allows all DKs on that tree (22 of them)to be derived. Each of the subtrees that starts at level 21 also has a single (different) master key allowing all Dks rooted on that tree to be calculated, etc. since the keyspace 2^128 is large, there is lots of room to assign randomly or pseudo randomly the different keys.

Yes, it is probably wrong. I am starting to think section 3.2.1 is not entirely accurate. It helped me a lot at the beginning, but now it is giving me more problems than solutions.

BTW we agree that traitor tracing is far important, but we are not talking about it. May be it is time you read chapter 4 of "AACS Pre-recorded Video Book" ;-)

FoxDisc

3rd March 2007, 18:28

Spec says "A given set of Device Keys enables derivation of every key in the master tree except the keys between its leaf and the root". If informative section 3.2.1 is accurate master tree must be the "first" 22 level tree, not the 31 level tree, and all devices must be in that first 22 level tree.

The spec also says :"The figure on the right illustrates the system of keys from the point of view of a single device, with subtrees shadowing off to the right." The point of view from the AACS LA is from a tree that starts at level 31, not the smaller tree at level 22 that the device is confined to.

Of course, it is possible spec authors have wrongly written the informative section, but this is hard to believe for me.

It's not written incorrectly. In fact, the common spec says nothing about the size of the master tree. It could be 31 level or 22 level or anything. You only can deduce that it is a subtree of the master tree from the supporting specs that say an individual device gets only 253 DKs. Since each device is isolated into a subtree, from its point of view, that is its master tree.

If you don't think there are any devices in the other 511 S-D sets of devices defined in the MKB, why do you think they wasted the space to define them on every disc?

BTW we agree that traitor tracing is far important, but we are not talking about it.

I thought we were talking about that. It's critical to revocation. I think we agree they can't revoke unless they know who to revoke, and a leaked DK or PK only tells them that someone in a very large group leaked it. Tracing by DK/PK is slow. The SKs are for tracing.

May be it is time you read chapter 4 of "AACS Pre-recorded Video Book" ;-)

I have read it - twice.

xyz987

3rd March 2007, 20:19

The spec also says :"The figure on the right illustrates the system of keys from the point of view of a single device, with subtrees shadowing off to the right." The point of view from the AACS LA is from a tree that starts at level 31, not the smaller tree at level 22 that the device is confined to.

So what?. At that figure just one subtree per level is represented. The phrase "from the point of view of a single device" is referring at least to this fact. Any other "fact" from this phrase is speculative.

It's not written incorrectly. In fact, the common spec says nothing about the size of the master tree. It could be 31 level or 22 level or anything. You only can deduce that it is a subtree of the master tree from the supporting specs that say an individual device gets only 253 DKs. Since each device is isolated into a subtree, from its point of view, that is its master tree.

There are not "points of view" about master tree. It is the tree where all devices are in ("The system is based on a large master tree of keys, where each device is uniquely associated with a leaf node of the tree"). May be 31 level or 22 level or any other value, but spec says "A given set of Device Keys enables derivation of every key in the master tree except the keys between its leaf and the root".

I assumed a 22 level master tree just because of this phrase. However, if they are using a 22 level master tree they have not enought leaf keys at master tree to give each standalone a different DK set, and they are not using a lot of posible paths. On the other hand, if they are using a 31 level master tree the above phrase is simply not true.

I thought we were talking about that. It's critical to revocation. I think we agree they can't revoke unless they know who to revoke, and a leaked DK or PK only tells them that someone in a very large group leaked it. Tracing by DK/PK is slow. The SKs are for tracing.

I have read it - twice.

Last time we were talking about it (on other thread) you wrote "I really need to look at the Sequence Key and Sequence Key Block system and how it interacts with the Device Key/MediaKey and MKB system."

Well, I said these two systems are highly decoupled. Output of DKs and MKB is Media Key, and input of SKs and SKB is Media Key. We agree that Media Key is the same, no matter which PK has been used to decrypt it.

So they can use SKB system to trace which player SK is from, not which player PK is from.

HyperHacker

3rd March 2007, 21:32

Is it possible in Windows to give a process less CPU time? That would slow it down.
Yes, you can give a process one of 16 priority levels, and each thread within it can have a sort of sub-priority level as well (determining which threads have priority when that process is active). You can create a process with a given priority level, but there's no stopping it from adjusting its own priority once started. Also, unless something else is hogging up all your CPU time, it won't make a huge difference. You can also create a process suspended (it won't run at all until you let it); it might be worth experimenting with this. Suspend, scan memory, resume, wait a few milliseconds, repeat.

CHRONOMASTER

3rd March 2007, 23:50

Is it possible in Windows to give a process less CPU time? That would slow it down.As for slowing down a process, there is a program I used to use some time ago to slowdown old games and programs. If I remember correctly the program was called CpuKiller. You should give it a try and see if it meets your needs.

lightshadow

4th March 2007, 02:18

As for slowing down a process, there is a program I used to use some time ago to slowdown old games and programs. If I remember correctly the program was called CpuKiller. You should give it a try and see if it meets your needs.
Is it www.cpukiller.com (http://www.cpukiller.com/)?

It looks very promising, but can it slow down just one process?

FoxDisc

4th March 2007, 03:27

On the other hand, if they are using a 31 level master tree the above phrase is simply not true.

If it was true, then they defined 511 sets in the MKB that have no devices. I think that can't be true.

Last time we were talking about it (on other thread) you wrote "I really need to look at the Sequence Key and Sequence Key Block system and how it interacts with the Device Key/MediaKey and MKB system."

I did say that, and that's what I did :)

Well, I said these two systems are highly decoupled. Output of DKs and MKB is Media Key, and input of SKs and SKB is Media Key. We agree that Media Key is the same, no matter which PK has been used to decrypt it.

So they can use SKB system to trace which player SK is from, not which player PK is from.

Unfortunately, they are not highly decoupled. They are very closely coupled. The purpose of Sequence Keys is to track devices and allow them to be revoked. Both the SKs and the aassociated DKs are revoked when the AACS LA issues a new MKB and SKB for a new disc.

This subject of how traitor tracing and revocation works is better suited to the Understanding AACS sticky thread. It will become more important when AnyDVD and the broken WDVD/
PDVD software are revoked. I will continue this post there for future reference. (BTW, I see that a Host Private Key has been found.)

xyz987

4th March 2007, 10:14

If it was true, then they defined 511 sets in the MKB that have no devices. I think that can't be true.

Yeah, I also think so.

This subject of how traitor tracing and revocation works is better suited to the Understanding AACS sticky thread. It will become more important when AnyDVD and the broken WDVD/
PDVD software are revoked. I will continue this post there for future reference. (BTW, I see that a Host Private Key has been found.)

Okay, i will continue on the other thread.

ATARI Vampire

4th March 2007, 11:49

You can also create a process suspended (it won't run at all until you let it); it might be worth experimenting with this. Suspend, scan memory, resume, wait a few milliseconds, repeat.

I used a program called "psuspend" by Sys Internals (www.sysinternals.com (http://www.microsoft.com/technet/sysinternals/Processesandthreadsutilities.mspx)) to locate the WinDVD 8 device key. This program is free to download and robust enough to meet most of one's average process-dumping needs.

If you choose to use psuspend, make sure that you allow the memory dump program (pmdump was what I used) enough time to finish its work before WinDVD or PowerDVD resumes execution. I recommend 3 - 7 seconds for pmdump to finish its work, depending upon the computational power of your machine.

Just in case anyone is curious, I had to slow the execution of WinDVD down to 50ms intervals in order to consistently find the DK and PK. I never went below 50ms since I didn't want to generate more than 50GB of total data for a single dump.

Multiplex

5th March 2007, 05:19

>when AnyDVD and the broken WDVD/PDVD software are revoked

Someone in the know tells me that PC software AACS keys expire and must be renewed (typically via internet) every 6 to 18 months as standard operating procedure. So the AACS key controllers may see the current exposure as temporary and not act directly on it.

I've already encountered playback software with expired AACS keys. So this automatic expirey mechanism certainly exists.

This may not be the awful news it seems. Tools to record and analyze internet transactions are widely available. :sly:

arnezami

5th March 2007, 06:24

I've already encountered playback software with expired AACS keys. So this automatic expirey mechanism certainly exists.
Which software? Can you give details? Its interesting since I'm not aware of any revocation yet.

BlazingMind

5th March 2007, 09:18

Someone in the know tells me that PC software AACS keys expire and must be renewed (typically via internet) every 6 to 18 months as standard operating procedure. So the AACS key controllers may see the current exposure as temporary and not act directly on it.

This should not be a problem unless they decide to fix their leaking software first.

Replacing these keys before the software is fixed will not be a very smart move... I belive Hollywood titles are being postponed due to the situation, and if so, it would be a heavy price to pay not to push out new keys...

It would surprise me if the software players are not sanctioned for every day that goes by that AACS don't see an upgrade for this problem.

Software updates for the players are what we should fear, and not revocation...

lightshadow

5th March 2007, 18:46

This may not be the awful news it seems. Tools to record and analyze internet transactions are widely available. :sly:
What makes you think it requires an Internet connection?

If the key expires within the next 18 months, then there would be no need for an Internet connection to transfer any locking info.

zeroprobe

6th March 2007, 11:26

wrong thread..

Multiplex

6th March 2007, 19:25

Which software? Can you give details? Its interesting since I'm not aware of any revocation yet.

It was an older HD version of a very popular one. I can't be more specific, sorry.

The expiry mechanism was a message that said that the AACS keys had expired. There was a button to connect to a renewal server and a Cancel button to exit the player.

Note that revokation is not identical to expiry. On expiry the player must either get permission to continue or retrieve new keys. In my case the software retrieved new keys.

What makes you think it requires an Internet connection?

Software with expired AACS keys insisted upon an internet connection to get new ones.

It would surprise me if the software players are not sanctioned for every day that goes by that AACS don't see an upgrade for this problem.

Software updates for the players are what we should fear, and not revocation...

The player software vendors are producing, releasing, and selling new builds. So there isn't any sanction.

Players with better code armor and more key obfuscation will likely be released soon. This change won't be hard for Intervideo and Cyberlink, who have historically had access to very good code armor.