Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > Decrypting

Reply
 
Thread Tools Search this Thread Display Modes
Old 5th February 2007, 10:31   #1  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Processing Key, Media Key and Volume ID found!!!

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:

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

Last edited by arnezami; 11th February 2007 at 15:40.
arnezami is offline   Reply With Quote
Old 5th February 2007, 11:35   #2  |  Link
evdberg
Registered User
 
Join Date: Dec 2006
Posts: 202
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).

Last edited by evdberg; 5th February 2007 at 11:39.
evdberg is offline   Reply With Quote
Old 5th February 2007, 19:44   #3  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
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:

Code:
09 18 20 06 08 41
Here is part of the entry in our volume key list:

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

Last edited by arnezami; 10th February 2007 at 09:44.
arnezami is offline   Reply With Quote
Old 5th February 2007, 20:01   #4  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 1,120
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!
hajj_3 is offline   Reply With Quote
Old 5th February 2007, 20:09   #5  |  Link
evdberg
Registered User
 
Join Date: Dec 2006
Posts: 202
Sorry for sounding a bit ignorant, but how does the Volume ID and MKB lead to the Volume Unique Key?
evdberg is offline   Reply With Quote
Old 5th February 2007, 20:42   #6  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by evdberg View Post
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:

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

Last edited by arnezami; 11th February 2007 at 15:40.
arnezami is offline   Reply With Quote
Old 13th February 2007, 17:47   #7  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by arnezami View Post
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.
I would appreciate a summary/restatement/explanation of this. I've looked at some of the AACS source documents, but I still don't understand where the "processing key" fits into the picture. Specifically, it looked to me like the player stores a device key (in the player or player software) that was created from some master key in the secret possession of the AACS licensing authority. The device key is used to decrypt the MKB (on the disk) to get the media key (Km). The device key is subject to revocation by the AACSLA by changing the MKB on future disks such that the old revoked device key no longer works with the new MKB on the new disks to get a valid media key.

The media key is used with the volume ID (stored on the disk) to get the volume unique key (Kvu) After processing, this decrypted Kvu volume unique key is in the memory of WinDVD and can be grabbed by other tools developed here. It is specific to the disk. The volume unique key can be used to decrypt an encrypted title key (stored on the disk) to get the decrypted title key Kt which is now in memory of WinDVD and can also be grabbed by tools here when decrypted and being used in the memory.

If we had the device key, then the disk could be read directly to obtain the final decrypted title key without any of the memory reading. Memory reading to find title key/volume unique key is subject to attack by making it more difficult to find in memory simply by updating software players, without changing any issued device keys or MKBs. Knowledge of the device key makes it easy to write a decrypting program and is only subject to revocation using the MKB changing - device key revocation process, something the AACS LA may not be really anxious to do on a regular basis.

Where does the "processing key" of the title of this thread fit into this picture? Is it the same as the device key or am I missing an important piece of this puzzle and the decrypting process? Thanks for filling in any gaps/errors in my summary above.
FoxDisc is offline   Reply With Quote
Old 5th February 2007, 20:21   #8  |  Link
noclip
Registered User
 
Join Date: Dec 2006
Posts: 154
Manchurian Candidate Volume ID: 0531200601130020202020200000

Last edited by noclip; 5th February 2007 at 20:46. Reason: right
noclip is offline   Reply With Quote
Old 5th February 2007, 20:35   #9  |  Link
Ishan
Anime Vampire
 
Ishan's Avatar
 
Join Date: Nov 2002
Location: Earth, Solar system, Milky way, Universe.
Posts: 126
Nevermind ^_^

Last edited by Ishan; 5th February 2007 at 21:18.
Ishan is offline   Reply With Quote
Old 5th February 2007, 20:55   #10  |  Link
noclip
Registered User
 
Join Date: Dec 2006
Posts: 154
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.
noclip is offline   Reply With Quote
Old 5th February 2007, 21:16   #11  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by noclip View Post
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...
arnezami is offline   Reply With Quote
Old 5th February 2007, 21:19   #12  |  Link
evdberg
Registered User
 
Join Date: Dec 2006
Posts: 202
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) ...

Last edited by evdberg; 5th February 2007 at 21:23.
evdberg is offline   Reply With Quote
Old 5th February 2007, 21:36   #13  |  Link
noclip
Registered User
 
Join Date: Dec 2006
Posts: 154
Quote:
Originally Posted by evdberg View Post
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.
noclip is offline   Reply With Quote
Old 5th February 2007, 22:06   #14  |  Link
evdberg
Registered User
 
Join Date: Dec 2006
Posts: 202
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.
evdberg is offline   Reply With Quote
Old 5th February 2007, 22:28   #15  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by evdberg View Post
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").

Last edited by arnezami; 6th February 2007 at 08:15.
arnezami is offline   Reply With Quote
Old 5th February 2007, 22:33   #16  |  Link
noclip
Registered User
 
Join Date: Dec 2006
Posts: 154
Quote:
Originally Posted by arnezami View Post
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.

Last edited by noclip; 5th February 2007 at 22:38.
noclip is offline   Reply With Quote
Old 5th February 2007, 22:38   #17  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
What would stop studios from using a different media key for every disc?
madshi is offline   Reply With Quote
Old 5th February 2007, 22:42   #18  |  Link
noclip
Registered User
 
Join Date: Dec 2006
Posts: 154
Quote:
Originally Posted by madshi View Post
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.
noclip is offline   Reply With Quote
Old 5th February 2007, 22:54   #19  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by noclip View Post
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.
Thats not entirely accurate. Although I agree its probably easier to go after the Media Key right now.

Why is it not entirely accurate? Well to let a known plaintext work it doesn't have to involve just one encryption step (you do not have to know the Media Key in advance). Lets say we have a disc containing a MKB. In that MKB is a verify media key record. In essense this means: if you think you have found the media key using one of many possible Device Keys (which you try one by one using the memory dump as seed) then you can check if its valid. So yes you can go for Device Keys directly. But its a lot harder I think (because of the way the subset difference algo works).

The future will tell whether its easier to go for Device Keys (and then for Media Keys) or for Media Keys directly.

Ok. Lets go for this Media Key shall we?

And more Volume IDs are helpful too .

Regards,

arnezami

PS. And I'm not talking about variant keys. Those a (little) harder still...

Last edited by arnezami; 6th February 2007 at 08:16.
arnezami is offline   Reply With Quote
Old 5th February 2007, 22:57   #20  |  Link
noclip
Registered User
 
Join Date: Dec 2006
Posts: 154
Quote:
Originally Posted by arnezami View Post
And I'm not even talking about variant keys. Thats a little harder still...
Why would we ever need to go anywhere near variant keys?
noclip is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 05:57.


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