Processing Key, Media Key and Volume ID found!!!

[arnezami]

Wooow!

I think I just found the Volume ID of King Kong.

But I'm shocked! It doesn't appear to be anywhere near random as I expected it to be!! This could mean (just maybe) its guessable/computable...

If so then if we find the Media Key** we wouldn't have to use WinDVD to grab keys anymore . And the Media Key doesn't tell the AACS LA which software player was hacked so... This could also be the reason why AnyDVD supposedly can decrypt without the need for grabbing keys from WinDVD's memory which puzzled be deeply.

I don't want to get ahead of things but if this is true this could be very deadly for AACS. I wonder if this is due to some technical limitation. I will tell more later. Have to go to work now .

Oh yeah here it is:

    00000000: 00 22 00 00 40 00 09 18 20 06 08 41 00 20 20 20
    00000010: 20 20 00 00 xx xx xx xx xx xx xx xx xx xx xx xx
    00000020: xx xx xx xx

Look at Section: 4.10.3.1 Volume Identifier in Introduction and Common Cryptographic Elements for more details.

Regards,

arnezami

PS. For some reason (even though i'm pretty sure this is the volumeid) I just can't believe it. But it really seems like the id is split in two parts of 64 bit: one part only 00's and 20's while the other part is a little more "random" (which to some degree would make sense seeing its also split in half on the disc).

** Later in this thread it became clear we need a Processing Key. But it amounts to basicly the same thing.

Update: The Media Key of King Kong has been found now .
Update 2: The Processing Key has been found too .

[evdberg]

According to section 2.3.3 of "HD DVD and DVD Pre-recorded Book" the above might indeed be the Volume ID.

struct VolumeID {
uchar MediaType; // 0x40
uchar Reserved;
uchar UniqueNumber[12];
uchar Reserved[2];
};

Reserved fields are always filled with 0x00.

You are also right about the ID split in 2 parts. One half is stored in the BCA (Burst Cutting Area) and the other half in the Control Data Zone (whatever that may be).

[arnezami]

Thanks evdberg. That confirms this is in fact the Volume ID.

Its incredible how not random this Volume ID is. I just figured out what these "unique" 6 bytes are:

09 18 20 06 08 41

Here is part of the entry in our volume key list:

King Kong      |V|09/18/06|

Yep its a date (09/18/2006) and time (08:41) of the production. Although its done very weird since the hex is interpreted as decimals. But most importantly the Volume ID is not just guessable its even predictable! Incredible.

What does this mean?

This means that (especially for future software player updates) there would be no need for anyone to do a memdump/debug or anything. Only once per Media Key Block Version does the Media Key have to be extracted by one person in the world. If this is released everyone can decrypt any disc!!

This is opposed to having to design a reliable and working keyfinder program for a new version of a software player which may not be possible. And that would mean that everyone who would want to retrieve a volume key would have to be pretty savvy (using a real debugger etc) and this would limit the amount and speed of volume key discovery.

What the above (date/time) essentially does is vaporize the whole Host and Drive revocation scheme. Have they gone mad? Even if they do use proper unique Volume IDs from now on it will still be possible (using a very simple USB software sniffer I used) for less savvy people to get Volume IDs. And having Volume ID + Media Key equals to Volume Unique Keys . And the beauty is that a released Media Key doesn't reveal the (software) player that has been compromised.

To confirm the above it would be nice if we had some more Volume IDs. Maybe this date/time thing is only done by one distributer or something. Don't know. We have to figure it out. Since I only have one movie others would have to extract the Volume ID.

Finding the Volume ID

How did I find the Volume ID?

There are essentially two ways (now). I used the USB sniffer (with the xbox 360 HD DVD) because I knew I didn't have to bother with the (possibly obscured/wiped) memory of the software player.

1. Download USB sniffer 1.8 then unzip and start it.
2. Select the "USB Mass Storage Device" (I use the xbox 360 HD DVD drive) and click install.
3. Unplug the HD DVD drive (the usb cable) and replug it again. It will be recognized by windows and the sniffer starts logging.
4. Insert the Disc into the drive while the sniffer is.. well sniffing. Then start WinDVD and immediatly quit when the video (even the first black screen) starts. Then click 'Close' on the sniffer.
5. You now have a huge log file (60+ MB or something). Open it in WinHex (pressing F7 for ascii only) and search for the ascii string (not hex search!) "00000000: 00 22 00 00" including the spaces (but excluding the quotes of course ).
6. There was only one occurence of this in the whole file. So it has to be the Volume ID. Tata!

Btw: I used WinDVD but the above should also work for other players.

A different method (but less reliable I think) is to use WinDVD's memdump.

1. Open WinDVD's memdump in WinHex
2. Hex search (with WinHex) for 002200004000 or alternatively 0020202020200000. **
3. There you will (usally) find the Volume ID. But I'm not sure this will always work. There may be more than one occurance. You can check if the last 16 bytes (of the 36 beginning with 0022) are random since that would have to be the MAC. If its not random you haven't found it yet so you should go on searching until you do.

I'm going to try to extract the media key. I have no idea how difficult that will be (if at all). But if we have that we could make a program that decrypts all discs without needing any keys (apart from the one media key).

I hope we can find at least a few Volume IDs. If you retrieve one please also check the creation dates of the files/dirs on the disc and post it aswell.

Greetz,

arnezami

PS. Almost forgot: make sure you remove the last 16 bytes from the Volume ID log (which is the MAC) like I did in my first post. This is because in theory they might be able to track down your drive with that part... (you don't want that). The Volume ID itself is for everybody the same (with the same movie) so that won't reveal anything about yourself .

** See this post for more Blu-Ray instructions.

[hajj_3]

if this works this is freaking amazing, that was the only bad part, having to use a player to find the key in memory, wondered how long it would take someone to find it.

get cracking guys!

[evdberg]

Sorry for sounding a bit ignorant, but how does the Volume ID and MKB lead to the Volume Unique Key?

[noclip]

Manchurian Candidate Volume ID: 0531200601130020202020200000

[Ishan]

Nevermind ^_^

[arnezami]

Originally Posted by evdberg

Sorry for sounding a bit ignorant, but how does the Volume ID and MKB lead to the Volume Unique Key?

I'm sorry for not explaining. The Media Key is a key resulting from the MKB (Media Key Block) and the Device keys. When combined with the Volume ID it gives the Volume Unique key.

Here is the part from the Pre-recorded Video Book section 3.3:

2. Calculate the Volume Unique Key (Kvu):
The licensed replicator chooses a Volume ID (IDv) to be placed on the pre-recorded media and calculates a
Volume Unique Key (Kvu) as follows:
Kvu = AES-G(Km, IDv)
where AES-G represents the AES-based one-way function defined in the Introduction and Common
Cryptographic Elements book.

That basicly means that having a Volume ID (IDv) and a Media Key (Km) you can calculate the Volume Unique Key (Kvu).

Or to illustrate it (I removed the currently unused parts):



The red part is the hard part: getting the Media Key** (usually from a software player by debugging/memory snooping). But this only has to be done once per MKB and can be done by a pro.

The yellow part is what I described above: we either can (nearly) predict the Volume ID or we can get it via simple USB sniffing (the software player can't do much about that apart from bus encryption which is not implemented yet).

The blue part is the easiest: if we have the Volume ID (also called IDv) and the Media Key (Km) we can calculate the Volume Unique Key (Kvu) and then the Title Keys (Kt). This of course enables us to decrypt the content itself.

Hope that clarifies a bit.

Regards,

arnezami

** Later in this thread it became clear we need a Processing Key. But it amounts to basicly the same thing.

[noclip]

We can get the media keys now the same way muslix got the VUKs. We get a memory dump, take the first 16 bytes and the volume ID to decrypt, and see if the result is the VUK. If not, increment the offset by 1 and try again, it should be a very quick attack.

[arnezami]

Originally Posted by noclip

We can get the media keys now the same way muslix got the VUKs. We get a memory dump, take the first 16 bytes and the volume ID to decrypt, and see if the result is the VUK. If not, increment the offset by 1 and try again, it should be a very quick attack.

Yes exactly. Or we can even use the Verify Media Key Record (3.2.5.4 in common aacs specs) on the disc. So we have two choices there. Feel free to try (I'm currently quite busy so I expect somebody else who is better at this to beat me to it ).

So far every key (title/volume key/volume id) has been in WinDVD's memory so I don't see why the Media Key wouldn't be in it...

[evdberg]

OK, I already wondered that I missed something, because I was sure we also need a device key. But if I am correct, PowerDVD keeps its device keys (although in encrypted form) in a file (001.fcl) ...

[noclip]

Originally Posted by evdberg

OK, I already wondered that I missed something, because I was sure we also need a device key. But if I am correct, PowerDVD keeps its device keys (although in encrypted form) in a file (001.fcl) ...

Who needs 'em? The only reason we would want a device key would be to decrypt the media key, which itself is already in memory.

[evdberg]

Reading the media key from memory is not really useful: in that case you can better grab the volume unique key as we do now ... the whole point of this exercise is that we want a method for decrypting without reading program memory, because this will most likely get harder in the future.

[noclip]

You're missing the point. With the media key we can decrypt all disks released so far.

[evdberg]

Originally Posted by noclip

You're missing the point. With the media key we can decrypt all disks released so far.

You are wrong. Please look at the above schematic. The media key is the result (decrypting?) of the MKB and the device key.

[noclip]

Originally Posted by evdberg

You are wrong. Please look at the above schematic. The media key is the result (decrypting?) of the MKB and the device key.

The device key decrypts the media key block to yield the media key. All the disks released so far use the same version of the media key block, thus the same media key.

[arnezami]

Originally Posted by evdberg

Reading the media key from memory is not really useful: in that case you can better grab the volume unique key as we do now ... the whole point of this exercise is that we want a method for decrypting without reading program memory, because this will most likely get harder in the future.

The point I am trying to make is that it should only be hard for one (or a few) people while it should be easy for many. Only that way will you get people to keep gathering volume unique keys. That means getting some crucial information (like the Media Key or even harder: an appropiate device key from a player's set of device keys) that can be used to decrypt discs. These discs also need specific information for decryption (the Volume ID) which can be obtained from outside the software player (by sniffing) thus making it impossible for the software player to make it harder and thus easier for the average Joes (who probably have many more movies than a few gurus have).

I do however (in principle) agree with you that it is not better (or worse) to go for the media in the memory of a player instead of the device keys. However its right now probably easier to retrieve the media key from memory than it is to extract a Device key (although technically we only need a process key but thats a different matter).

Btw I believe we should never (keep) releasing Device Keys. Its much better to release Media Keys. Unless somehow one version of an MKB can have multiple Media Keys (and as far as I understand that is not the "rule").

[noclip]

Originally Posted by arnezami

The point I am trying to make is that it should only be hard for one (or a few) people while it should be easy for many. Only that way will you get people to keep gather volume unique keys. That means getting some crucial information (like the Media Key or even harder: an appropiate device key from a player's set of device keys) that can be used to decrypt discs. These discs also need specific information for decryption (the Volume ID) which can be obtained from outside the software player (by sniffing) thus making it impossible for the software player to make it harder and thus easier for the common Joes (who probably have many more movies than a few gurus have).

I do however (in principle) agree with you that it is not better (or worse) to go for the media in the memory of a player instead of the device keys. However its right now probably easier to retrieve the media key from memory than its is to extract a Device key (technically we only need a process key but thats a different matter.

Btw we should never (keep) releasing Device Keys. Its much better to release Media Keys. Unless somehow one version of an MKB can have multiple Media Keys (and as far as I understand that not the "rule").

To go after a device key with known plaintext you must first have a known plaintext (the media key). We should focus on working our way up the chain of command from Volume to Media to Device to possibly (but unlikely) Root key.

[madshi]

What would stop studios from using a different media key for every disc?

[noclip]

Originally Posted by madshi

What would stop studios from using a different media key for every disc?

The logistics of revocation. Essentially, every time a revocation happens a new MKB is issued which can't be decrypted by the revoked devices.

They may be able to change the MKB so that all current device keys are still valid, but then they risk an easy attack on their root key, which will have them running for the hills.