WinDVD 8 Device Key Found!

[ATARI Vampire]

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]

Can someone confirm this?

[xyz987]

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]

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]

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

[xyz987]

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]

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]

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]

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]

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]

Awesome work!

[christopherw]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

My memory dumps have been 300 MB or so.

[HyperHacker]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

[mb2696]

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.


if every person on the planet could uniquely test millions of keys per second it would still take forever

[BlazingMind]

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]

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]

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]

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]

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]

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]

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]

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]

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