Processing Key, Media Key and Volume ID found!!! [Archive]

arnezami

5th February 2007, 10:31

Wooow!

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

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 (http://www.aacsla.com/specifications/) 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 (http://forum.doom9.org/showthread.php?p=952889#post952889) of King Kong has been found now :D .
Update 2: The Processing Key (http://forum.doom9.org/showthread.php?p=952954#post952954) has been found too :D .

evdberg

5th February 2007, 11:35

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

5th February 2007, 19:44

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!! :D

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.

Download USB sniffer 1.8 (http://benoit.papillault.free.fr/usbsnoop/doc.php.en) then unzip and start it.
Select the "USB Mass Storage Device" (I use the xbox 360 HD DVD drive) and click install.
Unplug the HD DVD drive (the usb cable) and replug it again. It will be recognized by windows and the sniffer starts logging.
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.
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 ;)).
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.

Open WinDVD's memdump in WinHex
Hex search (with WinHex) for 002200004000 or alternatively 0020202020200000. **
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 (http://forum.doom9.org/showthread.php?t=121866&page=5) for more Blu-Ray instructions.

hajj_3

5th February 2007, 20:01

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

5th February 2007, 20:09

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

noclip

5th February 2007, 20:21

Manchurian Candidate Volume ID: 0531200601130020202020200000

Ishan

5th February 2007, 20:35

Nevermind ^_^

arnezami

5th February 2007, 20:42

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 (http://www.aacsla.com/specifications/) 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):

http://img349.imageshack.us/img349/5159/progress6km3.png

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

5th February 2007, 20:55

arnezami

5th February 2007, 21:16

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

5th February 2007, 21:19

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

5th February 2007, 21:36

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

5th February 2007, 22:06

noclip

5th February 2007, 22:08

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

evdberg

5th February 2007, 22:10

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

5th February 2007, 22:19

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

5th February 2007, 22:28

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

5th February 2007, 22:33

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

5th February 2007, 22:38

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

noclip

5th February 2007, 22:42

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.

madshi

5th February 2007, 22:43

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.
Ah - thanks!

arnezami

5th February 2007, 22:54

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

noclip

5th February 2007, 22:57

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?

arnezami

5th February 2007, 23:06

Why would we ever need to go anywhere near variant keys?

I was mostly referring to Volume and Media Variant Keys which you definitely need to decrypt all the content (otherwise you would miss like 1% or something and the video would basicly be broken at certain parts). This is the nastiest part of AACS in my opinion and I wonder when (and if) they will use it. Hopefully later than sooner. :)

noclip

5th February 2007, 23:21

I was mostly referring to Volume and Media Variant Keys which you definitely need to decrypt all the content (otherwise you would miss like 1% or something and the video would basicly be broken at certain parts). This is the nastiest part of AACS in my opinion and I wonder when (and if) they will use it. Hopefully later than sooner. :)

I thought the variant keys were used so that AACS-LA could track down which device had been compromised, from small differences introduced into the video and audio streams.

evdberg

5th February 2007, 23:27

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.

I just compared the MKBs of 2 disks and they are different. What makes you think they are all the same?

arnezami

5th February 2007, 23:51

I just compared the MKBs of 2 disks and they are different. What makes you think they are all the same?

Assuming thats the case we would indeed need Device Keys (well technically a Process Key would suffice and may be easier to obtain).

But the idea that one difficult to obtain key (in this case a Device/Process Key) would make it possible to decrypt discs using easier to obtain Volume IDs (or even guessable/computable). Therefore making a fairly independent decrypter (not needing too much updates) possible.

evdberg

5th February 2007, 23:58

A Process Key? Are you making that one up? As I said before, we need a device key to use the - easy to obtain - Volume ID. For the time being grabbing the VUK is the easiest in many ways ...

arnezami

6th February 2007, 00:26

A Process Key? Are you making that one up? As I said before, we need a device key to use the - easy to obtain - Volume ID. For the time being grabbing the VUK is the easiest in many ways ...

Well its called a Processing Key (if you want to split hairs).

Anyway. Here is the quote from AACS common specs dealing with Processing Keys:

Once the device has the correct Device Key D, it calculates a Processing Key K using AES-G3 as described
above. Using that Processing Key K and the appropriate 16 bytes of encrypted key data C, the device calculates
the 128-bit Media Key Km as follows:
Km = AES-128D(K, C) ⊕ (00000000000000000000000016 || uv)
The appropriate encrypted key data C is found in the Media Key Data Record in the Media Key Block.

The Processing Key (and a C value) results in the Media Key. Its generally wise not to reveal your Device Keys themselves (although the last Subsidiary Device Key or the resulting Processing key is least damaging because they won't be able to determine which exact stored Device Keys you have and thus cannot revoke at once) unless they already know/guessed which device (= eg WinDVD player) you got it from.

Anyway. I think we should start thinking about what happens in a few months or so. They will probably revoke the current version of WinDVD and possibly other software players (just to be safe). The questions is: How are non technical people without too much hacking/programming experience (but with lots of new movies) gonna retrieve keys?

I believe a higher order key (Processing/Subsidiary Device Key/Media Key) could be very helpful for them to extract volume keys (assuming the simple mem search used right now with WinDVD won't work anymore for them). I think we are not disagreeing on that part. And I agree its very easy now (even without higher order keys) because of WinDVD. But thats the only thing now that allows many people to get VUKs. But thats not gonna last.

I guess the thought behind all this is: lets prepare for what will happens next.

Let me be straight: I don't want to replace something that is clearly working (extracting VUKs) but I want to add something in the context of probable future events.

Regards,

arnezami

arnezami

6th February 2007, 07:40

Concerning the differences in the MKBROM.AACS files. I am wondering which parts of the MKBROM.AACS file differ from movie to movie (or from disc to disc?).

The most important part (for us here) is the Verify Media Key Record. In my MKBROM.AACS its at position 74h (just before the Copyright text):

00000070: xx xx xx xx 81 00 00 14 87 B8 A2 B7 C1 0B 9F AD
00000080: F8 C4 36 1E 23 86 59 E5 xx xx xx xx xx xx xx xx

The bolded part is the actual Verification Data (for the Media Key).

I am now very curious if this part if different for other movies. Or if some movies have the same one. So if somebody could check. That would be great ;).

arnezami

PS. The start of the MKBROM file is probably the same for everyone: 10 00 00 0C 00 04 10 03 00 00 00 01. The last four bytes represent the version number.

jokin

6th February 2007, 08:33

Is this the right area?

00 00 00 00 00 00 00 00 00 22 00 00 40 00 04 06 32 04 20 11 57 47 48 44 56 4D 00 00 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx

arnezami

6th February 2007, 10:07

Lentgh Code: 00 22 00 00
Volume ID: 40 00 04 06 32 04 20 11 57 47 48 44 56 4D 00 00
MAC: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx

Thats a Volume ID indeed. And the unique 12 bytes are much more random in this case (although the last six sort of look like ascii characters: assuming you got this from WinHex: how does it show up in the Ascii part of WinHex?). What movie/distributer is this from?

I still see structure. Maybe we can figure out what it stands for (like the date/time thing in my example).

arnezami

PS. Its best to remove the MAC bytes like I just did for your own protection.

evdberg

6th February 2007, 10:47

The Processing Key (and a C value) results in the Media Key.

But to calculate the processing key you still need the device key(s) ... and that's my whole point.

madshi

6th February 2007, 10:53

But to calculate the processing key you still need the device key(s) ... and that's my whole point.
As far as I understand it, if someone manages to get hold of a device key and posts it on the internet, the AACS guys will come and revocate this device key. But if you post a processing key on the internet, the AACS guys will not know from which device key this processing key was calculated, so they cannot revoke the device key.

In other words posting a processing key on the internet allows many people to decrypt their HD DVD discs without having to search for VUKs first. At the same time the device key is still secret and so cannot be revoked.

Did I get this right?

arnezami

6th February 2007, 12:03

But to calculate the processing key you still need the device key(s) ... and that's my whole point.

There are two ways to get Processing keys: using (1) Device Key(s) or (2) hacking them directly out of the software player. I'm not claiming you (or WinDVD) don't/doesn't need Device Keys to get the Media Key. The point is: you should only release the Processing Key or Last Sub Device key.

When I've got more time I may be able to explain this better. Personally I believe its much more likely we will only find one Device Key (while we should release a sub device key or processing key) when hacking a software player. But I can only explain that while also explaining the full subset difference algo.

arnezami

evdberg

6th February 2007, 12:06

In other words posting a processing key on the internet allows many people to decrypt their HD DVD discs without having to search for VUKs first. At the same time the device key is still secret and so cannot be revoked.

Did I get this right?
Yes, you got it right, although "discs" should be "disc" (single). The processing key will just like the VUK be different for every disks ... and the way you have to search for the processing key is the same as for the VUK, so why bother ?

arnezami

6th February 2007, 12:16

Yes, you got it right, although "discs" should be "disc" (single). The processing key will just like the VUK be different for every disks ... and the way you have to search for the processing key is the same as for the VUK, so why bother ?
I will go into this later. When I have more time.

But what I'm really interested in the the difference you mentioned between the MKBs. Are the versions different? Are the Verify Media Key Records different? Or is it for example the Copyright text (eg 2006 changed into 2007) which causes the signature to be completely different and it may therefore look like a quite different MKB (while the Media is still the same). I just don't know. I only have one disc. Please help us out here :).

arnezami

evdberg

6th February 2007, 12:34

I double checked the files at the location you showed in post #30 (0x78 to 0x88), and they are different for all movies (and different from your values).

K40

6th February 2007, 13:02

In the MKBROM.AA.. of Serenity are these values:

00000070: xx xx xx xx 81 00 00 14 F0 5A D7 30 E4 1A DE 4E
00000080: B4 2A 11 61 0B DC C5 41 xx xx xx xx xx xx xx xx

If this is helping you i can post some more later

zeroprobe

6th February 2007, 13:11

The processing key will just like the VUK be different for every disks ...

disc not disks.

jokin

6th February 2007, 13:12

Lentgh Code: 00 22 00 00
Volume ID: 40 00 04 06 32 04 20 11 57 47 48 44 56 4D 00 00
MAC: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx

Thats a Volume ID indeed. And the unqiue 12 bytes are much more random in this case (although the last six sort of look like ascii characters: assuming you got this from WinHex: how does it show up in the Ascii part of WinHex?). What movie/distributer is this from?

I still see structure. Maybe we can figure out what it stands for (like the date/time thing in my example).

arnezami

PS. Its best to remove the MAC bytes like I just did for your own protection.

It is a memory dump I still had when I found the volume key for Apollo 13 from Universal studios.

evdberg

6th February 2007, 13:52

disc not disks.
You mean disk ... disc is UK, disk US ... and since Silicon Valley is in the US ... disk is used with computer related round objects, disc is used for other round objects ... curious enough the CD is Compact Disc, most likely because the CD was not related to computers when it was invented.

The_ByteMaster

6th February 2007, 17:43

You mean disk ... disc is UK, disk US ... and since Silicon Valley is in the US ... disk is used with computer related round objects, disc is used for other round objects ... curious enough the CD is Compact Disc, most likely because the CD was not related to computers when it was invented.

OFFTOPIC
Actually "Disc" is in the definition, just like you said
CD = Compact Disc
DVD = Digital Versatile Disc

Usually, "The Queen's English" is used for these matters.

The trailing D's are defined to mean "Disc". That is why "backing up your compact disc to your hard disk" looks funny but is correct in U.S. english.
/OFFTOPIC

ONTOPIC
I think it's great when we can find another way in, aside from using the volume unique keys. You bet software players are going to be hardened against these kinds of attacks. Snooping keys off a USB bus combined with knowledge of a "secret" device key might be the only way to go 2 years from now. For now there's no reason not to use the volume unique keys, but you have to be prepared when AACS LA is taking it to the next level.

arnezami

6th February 2007, 19:47

Is this the right area?

00 00 22 00 00 40 00 04 06 32 04 20 11 57 47 48 44 56 4D 00 00

Does anybody have more Volume IDs of this form? Do you by any chance jokin?

In order to find a pattern or see what parts of the Volume IDs are different between different movies we need to have more Volume IDs. You can read the beginning of this thread to see how to extract Volume IDs. The more we have the better ;). Especially the one with no date/time (like the one from jokin). If we find a pattern we don't have to extract these Volume IDs anymore since we can then "guess" them (where "guessing" means: trying millions at a time using a computer). So even if we get a hint of a pattern that might be good enough.

Its also interesting to know that there are now two different versions.

First the ones with date/time in it:

- King Kong (USA) / 09-18-2006 / Universal studios / IME
- Manchurian Candidate (???) / 05-31-2006 / ??? / IME??

Then the one(s) with 6 ascii characters in it (and maybe two 24 bit numbers?) :

- Apollo 13 (???) / Universal studios / IME?? (ascii chars: WGHDVM - is this an Acronym?)

It would be good to have more of these (and there may be more groups) so we can maybe figure this out.

As for the different MKBs and Media Keys: I think its pretty clear that they are different on every disc. So we need to get a Processing Key (or sub Device keys) to be able to decrypt different discs**. ;)

arnezami

** It can be proven whether or not one Processing Key can be used to decrypt every disc released so far: if the Explicit Subset-Difference Record is the same on every disc (I'm pretty sure it is) then the same Processing Key can be used. This Subset Record starts at position 0x0704 in my MKBROM.AACS file and the first 16 bytes are: 04000A1017000000011700800001. Please somebody check if its the same on at least two discs.

evdberg

6th February 2007, 20:13

arnezami

6th February 2007, 20:34

You won't give up, won't you? :) But anyway, I checked 2 disks for you and guess what: the value starting at 0x704 is indeed the same! Please note that you only gave 14 bytes of data, but most likely the last 2 bytes are 1701.
I am not sure what you looking at. All I see is a repeating 5 bytes pattern in which the 2nd byte is increased by 1 every 2 patterns, and the 3rd byte is alternatively 0x00 and 0x80. It looks like counting 0, 0.5, 1, 1.5, 2, etc.
Well you were right about the Media Keys being different. I assumed they wouldn't do that and I was wrong.

In this case though I know the Processing Key is able to decrypt multiple discs (which is what our aim is :)) because of the algo used leads to the same position in the tree (because all the subsets are identical) with all these discs. And the position essentially determines which Processing Key you end up with. Its the C-values that make the Media Key different on every disc. These C-values are inside the Media Key Data Record which start at 0x1114 in my MKBROM.AACS file and starts with 0500xxxx followed by many C-values of 16 bytes each. If Media Keys are different then these C-values should be too. Just check it.

arnezami

blutach

6th February 2007, 21:32

Can we leave the spelling and grammar to another place please?

Regards

pacman2006

6th February 2007, 22:50

- Apollo 13 (???) / Universal studios / IME?? (ascii chars: WGHDVM - is this an Acronym?).

HDVM is the basic subset of graphics for menus and subtitles. According to a discussion here:
http://forums.appleinsider.com/archive/index.php/t-59917-p-5.html

It's just a guess. Also, Don't know about WG.

arnezami

6th February 2007, 22:59

HDVM is the basic subset of graphics for menus and subtitles. According to a discussion here:
http://forums.appleinsider.com/archive/index.php/t-59917-p-5.html

It's just a guess. Also, Don't know about WG.

Ok. Thanks. This definatly feels like its not random. And thats important.

It would be sweet if we could get another one of these Volume IDs extracted and see if the "WG HDVM" changes. If not than we wouldn't have to worry about that part being random/changable (this is important is you have to guess parts of the Volume ID: the more is fixed the better).

Ishan

7th February 2007, 00:10

I got the VID for Serenity (US), you're gonna laugh I guess :D

00000000: 00 22 00 00 40 00 53 45 52 45 4e 49 54 59 20 20
00000010: 20 20 00 00 xx xx xx xx xx xx xx xx xx xx xx xx
00000020: xx xx xx xx

Wich of the 12 bytes "UniqueNumber" translate in ascii to :

"SERENITY "

I'm not kidding, check for yourself :D

mrazzido

7th February 2007, 00:43

hey

is volume id in blu-ray avaible is it useable? i can try to put my bluray burner in a usb case and sniff the usb port.

awhitehead

7th February 2007, 04:56

Title: Full Metal Jacket (US)
Studio: Warner Brothers
Modification Date: 4/17/2006 8:57 PM
UDF volume name: FULL_METAL_JACKET

USBsnoop log:

TransferBufferMDL = 83b06f88
00000000: 00 22 00 00 40 00 46 55 4c 4c 4d 45 54 41 4c 4a
00000010: 41 43 00 00 xx xx xx xx xx xx xx xx xx xx xx xx
00000020: xx xx xx xx
UrbLink = 00000000
[56868 ms]

HEX to ASCII translates this to FULLMETALJAC

MKBROM.AACS:

00000070 8D FF 1D E9 81 00 00 14 02 74 7B 32 9D 76 6C C7
00000080 C4 7F E4 04 DA 71 94 3D 7F 00 00 70 28 43 29 20
00000090 43 6F 70 79 72 69 67 68 74 20 32 30 30 36 2C 20

Hope this helps!

Andy

Mug Funky

7th February 2007, 06:15

finding patterns in volume IDs is a red herring i suspect.

if there is a pattern, it would likely vary per replicator. there's no requirement for them to follow a pattern (or in fact to be well hidden), so it's no surprise they convey mundane information like title, date, etc instead of random numbers.

however, it does give us a bit more known plain-text. whether that helps us or not remains to be seen.

that's my 2 cents anyway...

SBeaver

7th February 2007, 06:33

however, it does give us a bit more known plain-text.

Could you explain what you mean by this?
Don't you mean that it gives us a bit of the key?

edit: and in any case, if the remainder of the key can't be guessed, bruteforced, or somehow calculated, it's of no use, is it?

arnezami

7th February 2007, 08:01

I got the VID for Serenity (US), you're gonna laugh I guess :D

"SERENITY "

Title: Full Metal Jacket (US)
Studio: Warner Brothers
Modification Date: 4/17/2006 8:57 PM
UDF volume name: FULL_METAL_JACKET

HEX to ASCII translates this to FULLMETALJAC

Thanks all! :)

This is indeed funny. A week ago I was really concerned about this Volume ID. I thought it would be very hard to get. But well...

I guess there are now 3 types of Volume IDs

1) With Date/Time
2) With 2x24bit? + 6 Captials WGHDVM (possibly fixed)
3) With the name of the movie! :)

I'm not sure how many replicators there are. But the person that fills in the Volume ID can do this after the Media Key/MKB are made and signed by the AACS LA (in their little "bunker"). So yes Replicators could do that. I'm curious who makes this decision and to what extend they can be "forced" to use a more random code. Well anyway. Maybe we can use barcodes to see if we can categorize them? I wonder if we have found all types used so far.

Of course they could change this Volume ID into a more random number. But as long as they don't we might aswell take advatage of it.

Does anybody have more of the WGHDVM type? The other 2 are pretty clear now ;).

hey

is volume id in blu-ray avaible is it useable? i can try to put my bluray burner in a usb case and sniff the usb port.

Ooh yes! :) I would be very interested if this also works for Blu-Ray (according to the common specs it should). I'm also curious if they use a standardized system or something.

I would also be interested if this works with PowerDVD. Since it detects debuggers I wonder if it will detect sniffers too. If not then maybe we can devise a way to cloack it (the sniffer also uses a service so that may be hard to do).

And for those application/GUI programmers out there: since USB sniffer is open source maybe we can strip it from all things we don't need and make it a one-click type of application to retrieve the Volume ID only: "Volume ID Sniffer" :D. That could be very helpful in the future. Maybe we could also make one for directly connected IDE drives.

I'm going hunting for a Media and Processing Key :devil: .

Regards,

arnezami

jokin

7th February 2007, 11:39

Does anybody have more of the WGHDVM type? The other 2 are pretty clear now ;).

Here are two more:

Batman Begins:

http://img152.imageshack.us/img152/7533/batmanbeginshf1.jpg

King Kong:

http://img512.imageshack.us/img512/9884/kingkongsc8.jpg

Mtz

7th February 2007, 11:57

sorry for offtopic. jokin, remove the .th from your screnshots links.

enjoy,
Mtz

jokin

7th February 2007, 12:25

sorry for offtopic. jokin, remove the .th from your screnshots links.

enjoy,
Mtz

Thanks.

Momotte

7th February 2007, 13:58

jokin

7th February 2007, 14:08

arnezami

7th February 2007, 14:38

Is there something that I do not understand or is the VolumeID not enough to be able to perform decryption ?
All of this sniffing is interesting, but for us people who do not completely understand the math, how to we get to the VUK or to a key that allows us to perform the data decryption ?

thanks...
You need a VUK to decrypt the data.

There are essentially two ways of getting the VUK:

1) Use jokin's key finder while WinDVD is playing the movie (this may not work in the future)
2) Get the Volume ID and use a (still to be found) general Processing/Device key to get the VUK. (as long as a general key will be found for each MKB version this will pretty much always work)

So in this thread we are talking about an alternative way of getting VUKs. But for now just use the keyfinder.

arnezami

Momotte

7th February 2007, 16:34

You need a VUK to decrypt the data.

There are essentially two ways of getting the VUK:

1) Use jokin's key finder while WinDVD is playing the movie (this may not work in the future)
2) Get the Volume ID and use a (still to be found) general Processing/Device key to get the VUK. (as long as a general key will be found for each MKB version this will pretty much always work)

So in this thread we are talking about an alternative way of getting VUKs. But for now just use the keyfinder.

arnezami

OK, you confirmed I was at least following a little. If you look at my first question, I was confused because I thought we could decrypt it only with the volumeid but it is not the case, we need more.

Thanks for your time,

Ishan

7th February 2007, 18:20

...I would also be interested if this works with PowerDVD. Since it detects debuggers I wonder if it will detect sniffers too. If not then maybe we can devise a way to cloack it (the sniffer also uses a service so that may be hard to do)...

Works fine with PowerDVD 7.2 Ultra. And it seems there's no way to ununstall the service :angry: could be a problem in the future...

jkenzie

7th February 2007, 18:34

Another issue I had when I ran it with PowerDvd. Closing the service did not stop the log. It grew to 500K before I finally had to reboot with out the USB drive. :scared:

arnezami

7th February 2007, 18:43

Works fine with PowerDVD 7.2 Ultra. And it seems there's no way to ununstall the service :angry: could be a problem in the future...

Another issue I had when I ran it with PowerDvd. Closing the service did not stop the log. It grew to 500K before I finally had to reboot with out the USB drive. :scared:

Its good to hear PowerDVD works as well. :) There was a small possibility it would use bus encryption but clearly it doesn't.

It does indeed seem that the sniffer has some bugs in it. Those (at some point) have to be removed (and it has to be stripped of not required stuff) or we could use a different one (or an software IDE sniffer?).

Ishan

7th February 2007, 19:15

This sniffer is a bit buggy but works fine for me. I'll get some more VID when I'll get more HDDVD movies...

arnezami

7th February 2007, 19:42

Thanks to jokin ;).

Appollo 13:
Hex: 40 00 04 06 32 04 20 11 57 47 48 44 56 4D 00 00
Dec: 04 06 50 04 32 17
Ascii: W G H D V M

Batman Begins:

Hex: 40 00 40 06 26 08 10 15 57 47 48 44 56 4D 00 00
Dec: 64 06 38 08 16 21
Ascii: W G H D V M

Anybody see what these six numbers stand for? They are all pretty low (<= 64) so I have the feeling they mean something.

melakai

7th February 2007, 20:05

@arnezami

this is really minor, but i thought i should point out, there is an error in your apollo 13 hex2dec conversion. 06 should be 06, not 05 ;) interesting to note that this one value is the same on both WGHDVM titles (aside from the WGHDVM values themselves)

arnezami

7th February 2007, 20:18

Thanks melakai

Some things I've noticed (when looking at these six numbers):

- The second number is very low (=< 6) and is the same for both
- The fourth number is also very low (<= 8)
- The sixth number is odd, all others are even
- The third number is somewhat higher than the last 5 numbers
- The first number has only 4's in it

It think we could use more of these to figure it out a little better. :)

SBeaver

7th February 2007, 20:28

I think it's just an acronym that they use one their discs, it doesn't even have to mean anything.
As long as you can still sniff them out anyway, why not try and break something else more important instead.
Try and get the device keys (or is it host keys?) from the software players to start with and then go on from there.
If all xbox players have the same device keys and you can manage to extract it, that would be a big step forward.

edit: btw, how many iterations would it take to bruteforce the discs with the WGHDVM?
Can't be that many, like (2^3)^6 possible values, that's no work at all.

arnezami

7th February 2007, 20:32

I think it's just an acronym that they use one their discs, it doesn't even have to mean anything.
As long as you can still sniff them out anyway, why not try and break something else more important instead.
Try and get the device keys (or is it host keys?) from the software players to start with and then go on from there.
If all xbox players have the same device keys and you can manage to extract it, that would be a big step forward.

Ok. I'll try to concentrate on extracting keys. But if somebody or I succeeds then being able to calculate the Volume IDs would make it possible to decrypt all discs without sniffing or memdumps or anything. That would be nice ;).

SBeaver

7th February 2007, 20:53

If someone has a volume id decrypted and encrypted, and just say how to check if it's correct (that's done through hashing if I understand correctly) I could try fiddle around with it in some mathematics software and benchmark and try to refine the way to get the number with as few interations as possible while keeping it functional.
I'm doing a lot of this stuff at university right now and this would be a lot more interesting to try.
If the different manufacturers all use different naming schemes, it's likely they also have some other thing on their discs that is unique to only them which could make for a good detection system, unless the manufacturer differences is only between the different movie companies in which case you can just enter select the manufacturer in a list an the app selects the best way to bruteforce the key.
Since this key still isn't very useful maybe it doesn't matter but it's a fun exercise still.

edit: btw i made edit in above post

evdberg

7th February 2007, 23:03

Before people spend any more time on this ... as can be read from the documents and follows from the fact that you can 'sniff' the data from the USB, the Volume ID is exchanged unencrypted between the drive and the player. Hence getting hold of the Volume ID is not an issue ... please focus on the means to get from the Volume ID to the VUK ... just my 2 cents ...

arctor

8th February 2007, 03:11

arnezami

8th February 2007, 08:08

I'm a little confused if this line of attack will be a massive gain.

Essentially it seems that by finding the device key you will be able to get the volume key directly without the need to do a memory dump while the player is playing it.

However if AACS take action against the compromised player they should start issuing new discs with a MKB file that does not contain the Media Key encrypted with the compromised player device key. Therefore the player could try and paly the media but it would not be able to decrypt it. Likewise any decryption utility using that device key would fail.

It got me thinking about what is in a Media Key Block file. Presumably AACS have generated all the device keys for all future players and when a new player is developed the AACS will release a key to that player. Also all discs (and all discs that have been made in the past) must have there media keys encrypted with the the total set of device keys. However the moment that a player is "revoked" then that device key is not used to encrypt future media keys.

In saying that it may take a long time for a key to get revoked. And the creation of a utility that can get the Volume Key without using a player would be nice as you don't need a VUK finder program. Don't want to discourage just want to check if my reasoning right :)

There are several arguments to expand our capabilities to this approach:

Retrieval of the Volume ID is standardized: a very specific response comes from a drive (even Blu-Ray I think) and happens outside the software player. They can do much less about preventing the sniffing than they can about hiding/removing the VUK in memory.
The bulk of the future VUKs will have to be found by non-hackers (hackers do not own all discs) and therefore if its easy for most people (but hard for one) the spreading of VUKs can be fast. But if its (somewhat) easier for a hacker to only retrieve a VUK it will be harder for others since they do not know how to do extract VUKs like the hacker does. As an example: there are people now who do not have the Japanese version of WinDVD (but have for example PowerDVD) and they can't retrieve VUKs. But with retrieving volume ids its more straightforward: if you can play the disc you can get the volume id.
A company who presses discs can change each batch (generating a new title key file and volume id) wihtout having to go to the AACS LA signing process. So its probably much easier for them to change VUKs than it is to change the Media Key on a disc. This way there could be many different VUKs for one movie but just one or a few Media Keys.
When new discs are sold in the stores (with new subsets using different device keys) there should already be software players ready to play those discs. So there is always a window where a hacker can retrieve Device Keys (from the new or still non-revoked player) even when no new discs have been released yet! This could mean the decryption process may practically always work :). This also means the hacker does not need to have the new discs to make them decryptable he just needs the new player.
Releasing a Processing Key only will still not allow "them" to (clearly) identify the compromised player. This could strenghten WinDVD's legal position: this is a bussiness, WinDVD has a contract, and I guess they will only have to revoke their own player if the AACS LA can show/prove that their player (the device keys that is) was comprimised.
And of course the more ways to get a volume key the better. I see this method as a additional attack vector. Its also a quite different technique.

Of course there are also problems with this technique:

It may be really hard to get to the Processing/Device Keys. I've testing a bit and it doesn't look promising... yet ;).
There is a possibility they are going to encrypt the bus to the drive. This can only be done with drives that are capable of bus encryption (and since the scheme isn't finished yet I suspect no drive right now can). I do not know if these bus encryption capable drives are/will be common or not.
Even releasing a Processing Key releals a little bit about the player. But then again: they probably already know or can guess which player it is. I'm not sure how this works legally between Player company and AACS LA.

An even more ambitious approach would be to retrieve both the Processing Key and the Host private key (of a software player). That way we wouldn't even have to sniff Volume IDs anymore. But keep in mind that hosts are subject to revocation aswell and this is even harder for the hacker.

Hope I cleared it up a bit.

Regards,

arnezami

HyperHacker

8th February 2007, 08:22

btw, how many iterations would it take to bruteforce the discs with the WGHDVM?
Can't be that many, like (2^3)^6 possible values, that's no work at all.
6 bytes = 48 bits. 2^48 = 281,474,976,710,656. :-/ Hopefully I did that wrong. And that's assuming "WGHDVM\0\0" is always in the same place.

jokin, you blanked out some of the hex in your screenshot, but not the ASCII that goes with it. It wouldn't be difficult to figure out what the hex was from the ASCII, since this editor doesn't appear to ignore characters 00-1F and 7F-FF.

jokin

8th February 2007, 09:01

6 bytes = 48 bits. 2^48 = 281,474,976,710,656. :-/ Hopefully I did that wrong. And that's assuming "WGHDVM\0\0" is always in the same place.

jokin, you blanked out some of the hex in your screenshot, but not the ASCII that goes with it. It wouldn't be difficult to figure out what the hex was from the ASCII, since this editor doesn't appear to ignore characters 00-1F and 7F-FF.

Thanks for pointing that out. I am not sure why I am blanking it out. Someone said it was a MAC address but it is different for each disc I have done. Could someone explain that more. I have 3 more movies to do the dumps for.

SBeaver

8th February 2007, 11:32

arnezami

8th February 2007, 11:44

ok i counted without the 06, but i still typed the wrong number.
Anyway, that, combined with patterns of the code, like all numbers are under 70 or something.

I googled to check and found this:

"Swiss-based Ph.D. Student Solves 48-bit
Key in RSA Data Security's Secret-Key Challenge; Search rate by 3,500 computers reaches 1.5 trillion keys per hour"

Note that this was from 1997

Brute forcing these Volume IDs is not really an option (and not really required). But I believe we may be able to reduce it much further so it can be very easely guessed.

But we need more examples for that! :)

arctor

8th February 2007, 22:34

Thanks arnezami, thats a good answer and covers a lot of the things I didn't think of. Like the idea of finding the host private key. Maybe it will be easier to find as its bit bigger and may be stored very close in memory to the host public key (which should be viewable in the USB sniff.)

arnezami

9th February 2007, 12:30

I think I've found the Volume ID of a Blu-Ray disc. :) Well its from a memdump of WinDVD playing Lord of War.

Anyway here it is:

Length Code: 00 22 00 00
Volume ID: 9F A6 47 7B B0 10 30 A5 63 7F 36 E1 9D C4 ED 11
MAC: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx

As you can see this is properly random and not at all guessable. I'm not sure if its possible the volume ID is encrypted here because then the 00 22 00 00 would probably have been encrypted too (although the protocol might not allow that). Not sure. My gut says its not encrypted. We can check this though if we have two dumps of the same disc (but the second dump after a restart of WinDVD) and compare the Volume IDs. They should be the same.

Because it has no 40 00 in it (like with HD DVDs) its much harder to find in a memdump but sniffing should be easier (searching for "00000000: 00 22 00 00"). But if you have a Blu-Ray burner and have a memdump of WinDVD you can try to hex search for 00 22 00 00. You will find many occurrences of that but only one with 32 random bytes behind it (= Volume ID + MAC). Thats the way I found it anyway ;) (I mainly looked at the ascii part when pressing F3 so I could quickly see if it was followed by random bytes. I found it around Offset 4ABxxx but it could vary: between 300000 and 500000 would be my guess).

Something different. Regarding Device Keys. Could some people count the number of 0xx.fcl files their PowerDVD version has? (where xx are sequenced numbers) I suspect the newer versions have more of them. This is still a "feeling" but it could be interesting (its possible the new PowerDVD version got a different set of Device Keys already...)

Back to hunting :devil:

Regards,

arnezami

PS. I just found out my xbox 360 HD DVD is not capable of Bus Encryption :D. If you do a text search in your sniff log on "00000000: 00 72" you'll find two occurrances. The one with 01 (not 02) at the blue byte is the Drive Certificate. The byte right next to it should be 00 (red) if not then you're screwed otherwise you will always be able to sniff volume IDs :p. Here is mine:

00000000: 00 72 00 00 xx xx xx xx xx xx xx xx xx xx xx xx
00000010: xx xx xx xx xx xx xx xx 01 00 00 5c xx xx xx xx
Be careful with posting this stuff. If you are not you could reveal your drive id. Btw. if you have a PC drive and a memdump you may be able to find it using a hex search for 00720000 or 0100005C or 0101005C (but there are either lots or none of those so its hard).

PPS. Apparently WinDVD isn't capable either. Seems they really haven't implemented Bus Encryption yet.

jkenzie

9th February 2007, 22:00

Something different. Regarding Device Keys. Could some people count the number of 0xx.fcl files their PowerDVD version has? (where xx are sequenced numbers) I suspect the newer versions have more of them. This is still a "feeling" but it could be interesting (its possible the new PowerDVD version got a different set of Device Keys already...)

My version has two. .000 and .001. What new version are you speaking of?

arnezami

10th February 2007, 07:51

My version has two. .000 and .001. What new version are you speaking of?

Only two. Hmmm... So not 23 or 27. Interesting... Whats their size: roughly 630 bytes each?

I ask because a full set of Device Keys would have 31 + 30 + 29 + .. + .. + 1 =~ 500 Keys. So that would require 500 x 16 =~ 8000 bytes. Now they could do without certain Keys and only give 31 Keys (or even a little less) but that would mean that when two non-adjacent Players are revoked this PowerDVD version has to get new Keys by default. Because it wouldn't have keys for sub-trees. Hard to explain quickly.

Of course this is only relevant if these fcl files ineed contain the Device Keys that is ;).

Do you have Power DVD 6.5 or 7.1 or 7.2 installed?

jkenzie

10th February 2007, 08:02

jkenzie

10th February 2007, 08:05

I have both 7.1 and 7.2 installed
000.fcl is 14KB
001.fcl is 19KB
both versions

arnezami

10th February 2007, 08:36

Some interesting things about the 001.fcl file.
I noticed the original file date was 9/21/2006 from an install I had on a separate partition, but it had recently been modified in my main install. It showed a date of 2/5/2007.
The files were infact different, but not by much, it was actually smaller than the original.
Every time you put in a new movie it writes to the 001.fcl.

Hmm. Interesting. Thanks. :) A few questions:

- Are you sure its every time you put in a new movie? Not every time Power DVD gets new keys from the internet? Can you re-install and insert a new movie (for that new installation) and check whether the file(s) has/have changed? What movies do change it? Does it change only once or with every new movie?
- How many versions do you know of?
- Is 000.fcl still original?
- Is there any difference in behaviour between 7.1 and 7.2 in this matter?
- What do you mean by "not by much": how many bytes of difference are we talking about and where? Are you talking about a difference in the content or just the size? Are they different in content?

General question: does anybody have an (old) PowerDVD version that doesn't support HD/BD playback? Does it also have *.fcl files?

Thanks.

arnezami

PS. Its possible they have given a separate Key Set for BD. Which means two full sets would need roughly 16kb.
PPS. It might be possible Power DVD is removing Device Keys it knows it will never need (which it can see from the MKB on the first disc it sees) which might explain the "shrinking" here.

arnezami

10th February 2007, 09:20

I've got a related idea. :)

It just may be possible to create a perfect (but still encrypted) backup which is still playable. It would require re-encrypting the title key file and mac-ing it (with a new VUK) This new VUK would derive from the Volume ID of a re-writable (here lies the possible problem) and the unchanged Media Key (derived from the MKB).

To test if this even could work somebody with a HD DVD burner (and maybe a usb connected HD DVD drive) would have to try the following:

- Burn all (still encrypted) files to the new rewritable disc (do a bit-for-bit copy)
- Put it in a (preferably usb) HD DVD drive (and with usb turn on the sniffer) and start a software player (btw the movie won't play)
- See if the log contains a Volume ID (or if you don't have it usb connected and can't use the sniffer: if its in Jap WinDVD's memdump, see page 1 of this thread for instructions but leave out the 40 00 part like with Blu-Ray). If so it just might be possible...

Its entirely possible the disc is first somehow checked if its a pre-recorded one (eg. the drive missing the HRL in the lead-in area: or does the bit-for-bit copy that too? or something in the so called "system lead-in") which ends the story right away. But its worth a try I think. ;)

arnezami

jkenzie

10th February 2007, 10:07

It's hard to tell when it is actually changing the file. This is the original file header:
00000000 43 4C 46 43 4C 30 30 31 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 03 01 05 CLFCL001
0000001C 00 06 00 00 00 02 01 00 00 07 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 02
00000038 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000054 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30 30 00

If I overwrite my 001.fcl file with the original, as I play the first disc, it changes to this. With no other changes to the file.

00000000 43 4C 46 43 4C 30 30 31 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 03 01 05 CLFCL001
0000001C 00 06 00 00 00 03 01 05 00 07 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 02
00000038 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000054 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30 30 00

My current version looks like this but ia also 1576 bytes smaller
00000000 43 4C 46 43 4C 30 30 30 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 07 00 06 CLFCL000
0000001C 00 06 00 00 00 02 00 05 00 07 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 02
00000038 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000054 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 20

arnezami

10th February 2007, 10:59

mrazzido

10th February 2007, 11:52

i have bd burner i made an complete image of a encrypted movie, burn bd yet on rw 30mins to go :-). i try windvd then what memdumb says then.

arnezami

10th February 2007, 12:13

i have bd burner i made an complete image of a encrypted movie, burn bd yet on rw 30mins to go :-). i try windvd then what memdumb says then.

If you can't find the Volume ID easely you may want to try to find the VUK using ape's hd-dvd volume key finder (http://forum.doom9.org/showthread.php?t=120970) or use jokin's while WinDVD is running (there is also a possible timing issue: when WinDVD sees its a corrupt disc it may remove all information from memory or even crash, if that happens than just before that the dump has to be made). And see if it finds the VUK (which almost certainly is different from the one retrieved from the original disc)...

[edit] Sorry you need the bluray key finder (http://forum.doom9.org/showthread.php?t=121021) of course... (but it checks for title/CPS keys so i'm not sure if this is a good test. Well maybe..)

mrazzido

10th February 2007, 13:01

i try to start the decrypted movie with windvd , windvd crached after push start. windvd try to load ( drive is working) the movie . then 2sec later crahed.

arnezami

10th February 2007, 13:32

i try to start the decrypted movie with windvd , windvd crached after push start. windvd try to load ( drive is working) the movie . then 2sec later crahed.

I think there are several possibities here. One (relatively easy) way would be to install Visual C++ (just an example). After starting Visual C++ and then pushing the start button in WinDVD it (= MSDEV.exe which should be in memory) will intercept the crashing application and ask if you want to debug the application. At that moment (before clicking 'ok' on the pop-up) you can do a memdump of WinDVD.

There are probably many other ways (maybe somebody else can give suggestions) but this will most likely work fine.

Its interesing it actually crashes because that could mean we really fooled it (which is good news) :).

mrazzido

10th February 2007, 15:10

powerdvd says this movie is aasc crypted cant play the movie.

arnezami

10th February 2007, 15:22

powerdvd says this movie is aasc crypted cant play the movie.

That sounds right. The movie is encrypted and the current volume ID (which is unknown for the moment) and Media Key won't produce a VUK that decrypts the Title Key file correctly.

In order to make this completely work we need to know (1) if the VUK is calculated at all (2) what that VUK is (3) encrypt the decrypted Title Key file with this new VUK (4) change the iso with the new Title Key file bytes (5) burn the new iso.

Keep in mind we are still at step 1 and 2.

But for the moment it appears the Software player notices that decrypting the Title keys (with the "strange" VUK) isn't working. Which is correct since we haven't changed the Title Key file yet.

In order to get any further we need to know if the Volume ID is extracted (which could be a sign that 1 is working) or extract the VUK directly (which sovles 1 and 2). But we can only do that with either a sniff log or a memdump.

It might be possible to do a memdump (or use the key finder) during the 2 seconds you mentioned. Its tricky though... The best way is to let the crash be intercepted.

mrazzido

10th February 2007, 15:27

just an idea ?? we need a "hd dvd or blu-ray emu" that powerdvd or windvd think a original disc is inside. then the programm has a databse with the keys. ripped from windvd memdump.

arnezami

10th February 2007, 15:45

just an idea ?? we need a "hd dvd or blu-ray emu" that powerdvd or windvd think a original disc is inside. then the programm has a databse with the keys. ripped from windvd memdump.

Then its probably better to decrypt and play it (with an open source player). The gest of the above idea is that you might fool for example a PS3 or fool WinDVD/PowerDVD without the need of any software to be installed and without needing to decrypt the entire disc: a simple fix to the title key file in the iso would do the trick (if this works of course ;)). In principle you could even let a burning program do it on-the-fly for you.

Anyway maybe the posts (by mrazzido and me replying to him and my original idea-starter-post) about this subject (making an encrypted perfect copy) should be moved to separate thread because it really is a related idea. But has nothing much to do with trying to find Device/Processing/Media Keys and Volume IDs (sorry mods didn't really anticipate this).

jkenzie

10th February 2007, 17:54

@jkenzie (or anybody else who has PowerDVD): could you try the following:

Open the 001.fcl file in WinHex (make a backup first) and see if there are any random stuff in it (I suspect the bulk is random is it?) Now change one byte in that area and try if Power DVD will play a movie. And try changing the file at different places (but only change at most one byte compared the the backup) and see what happens.

This could pin-point the exact position of the Device Keys used. But its possible there is some kind of checksum which disables this technique. If it works all the time then I suspect there are no Device Keys in it at all.

If I change one byte at any point in the file the player will not initialize. I get the 1103 error.
I’ve watched the changes several times with several different disc’s inserted as first play. I always end up with a different .fcl file.
I don't think the changes are from am internet update, because the computer I'm testing this on has no connection.

arnezami

10th February 2007, 18:16

If I change one byte at any point in the file the player will not initialize. I get the 1103 error.
I’ve watched the changes several times with several different disc’s inserted as first play. I always end up with a different .fcl file.
I don't think the changes are from am internet update, because the computer I'm testing this on has no connection.

Ok. Thanks.

arnezami

11th February 2007, 07:23

After some (sometimes frustrating) work I found the Media Key of King Kong:

07 4E 1F C8 8F B9 B7 80 A2 25 CA A2 3B C3 DB 56

:D :D :D :D :D

With that we are one step closer to finding a Processing Key :) .

Adub

11th February 2007, 08:54

Excellent job!
This is really great as it provides another manner of attack, thus preventing, well, "prevention".
Now, how the heck did you do it?

arnezami

11th February 2007, 13:17

Wooow. I think I did it :).

Processing Key found!!!

:D :D :D :D :D :D :D :D :D

More info later.

To be sure I need to confirm my finding. I need the following (from anybody with a HD DVD disc):

1) - Movie Title (not King Kong please ;))

2) - The Verify Media Key Record in the MKBROM.AACS file. It starts with 81 00 00 14 followed by the 16 byte Record. In my case this it at Offset 00000120h. Here is mine:
81 00 00 14 87 B8 A2 B7 C1 0B 9F AD F8 C4 36 1E 23 86 59 E5 7F 00 00 xx

3) - The first C-Value in the MKBROM.AACS file (also called Media Key Data). It starts with 05 00 20 14 (the 20 14 could be different but is probably the same) followed by the first 16 byte C-Value. In my case this it at Offset 00004376h. Here is mine:
05 00 20 14 6D 02 CA C6 7B 1A 7E 95 C2 16 EF D4 C9 28 09 CF D3 CE 9A DC

If you react quickly I can check if the Processing Key is really valid (for multiple discs).

:D :D :D :D :D :D :D :D :D

Yeah I'm happy...

arnezami

hajj_3

11th February 2007, 13:38

im confused with all these keys lol. hopefully all the keys will be found on the disc soon, rather than in memory, so we can scan the disc and find all the keys.

Eeknay

11th February 2007, 14:01

1.) The Departed
2.) FF 29 11 E9 96 16 5D 97 29 2D BB A0 3C A9 0D E0
3.) 68 07 C3 23 7E 18 6F 7F BC 78 E2 DC 26 C5 84 0B

Hope that helps.

EDIT: Here's another disc just for kicks.

1.) Spy Game
2.) 7C AD 1D 65 D5 9E C1 67 A7 96 E5 C2 13 23 08 22
3.) 59 28 94 3F 5C 09 19 2C 8D 54 0A 77 45 BE 3E 6D

arnezami

11th February 2007, 14:09

1.) The Departed
2.)
3.)

Hope that helps.

EDIT: Here's another disc just for kicks.

1.) Spy Game
2.)
3.)

YES YES YES!! It works! :D :D :D

I'm going to take some rest now (I need it ;)). But will tell all later.

Here is the Processing Key which should work on all HD DVD discs (and maybe even Blu-Ray discs) released so far:

09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Save it. Store it. :)

Regards,

arnezami

PS. As explained before in order to get a VUK you now only need a Volume ID (which should be fairly easy to get or even to guess...).

hd1080p

11th February 2007, 14:53

Congrats everybody for the thrill of witnessing how DRM was defeated. February 11, 2007 is a day to be remembered.
I predict that movies will one day be liberated without DRM and we are all going to loose all the fun and excitement.
Fairuse wins!!

PS. As in LOR, this is the KEY(RING) to conquer all!!
Now, we have to find the processing key for blueray to help out HD-DVD market position. Movie studios may just stop releasing new movies on HD-DVDs. There should be a level playing field for the competing formats.

blutach

11th February 2007, 14:54

Nice work arnezami

Regards

arnezami

11th February 2007, 17:12

Thanks you all :). Its been a pleasure.

As I can understand some of you are interested in how I retrieved the Media and Processing Keys. I will tell what i did.

Most of the time I spend studying the AACS papers. A good understanding of how things worked have helped me greatly in knowing what to find in the first place (and how to recognize something). I may write an explanation of (my understanding) of how AACS works in particular the subset-difference technique (which is by far the hardest to understand) at a later date if you guys want to.

But anyway. Since the moment I found the Volume ID (which was much simpler than I had thought) my thought was to try to find the Media Key. But after some discussion I thought it might be better to go directly for the Device Keys (bad mistake). After looking at files created and changed by software player and trying to recognize Device Keys in memory dumps I was starting to get worried a bit. I wasn't making any progress.

So I went back to my original idea: do a bottom-up approach. So first I tried to find the Media Key. One of the logical things to do even before that was to search for the Verify Media Key Record in memory. But it wasn't there. I then started to work on a little proggy that would scan a memdump and see everything as a Media Key: thus trying to verify it with the Verify Media Key Record. No luck.

This was frustrating: all kinds of information was in the memdump but not the Media Key (I sort of assumed/hoped it would). I made several memdumps at different moments but nada, nothing. After throwing it all away I remembered I still had a "corrupt" memdump from WinHex (it failed to finish it because WinHex said the memory had changed). It was really small compared to the others so I didn't have much hope. But when running it with my proggy: voila! I found it. Which finally gave me hope I was going in the right direction.

There were just two major problems left: how do you detect the Processing Key and if its not in memory how do you find it at all? Well since I now knew how things worked I knew the Processing Key had to be combined with a C-value to produce the Media Key. The problem was there are 513 C-values in the MKB! Searching the memory (several megabytes) for a Processing Key and assuming just one C-value would take minutes (if not hours depending on the size of the dump). So doing them all would take very long. And that while I didn't even know for sure there was a Processing Key in memory to begin with. I made a proggy that did this but using my favorite "corrupt" memdump I didn't find any Processing Key in the first megabyte (not for any C-value). It didn't look good.

But then I realized why I first didn't find the Media Key: it was removed from memory after the Volume ID was retrieved and the VUK calculated. I also saw that in my "corrupt" memdump the VUK, Vol ID, Media Key and the Title Key MAC were all closely clustered in memory: in the first 50kb (of the entire multi megabyte file!) but there were large empty parts around it. Almost as if it was cleaned up.

This gave me an idea: what I wanted to do is "record" all changes in this part of memory during startup of the movie. Hopefully I would catch something insteresting. In the end I did something a little more effiecient: I used the hd dvd vuk extractor (thanks ape!) and adapted it to slow down the software player (while scanning its memory continously) and at the very moment the Media Key (which I now knew: my bottom-up approach really paid off here) was detected it halted the player. I then made a memdump with WinHex. I now had the feeling I had something. :)

And I did. Not suprisingly the very first C-value was a hit. I then checked if everyting was correct, asked for confirmation and here we are. :D

Hope you enjoyed the ride. I'm thinking about a concept of proof proggy which does all the steps (from Processing Key to C-value to Media Key to Volume ID to VUK). It would require a Volume ID as input (which might be retrieved/guessed in another program or extension whatever). But the most important part is done: we have a Processing Key.

I'm also thinking about doing a full explanation of the AACS protection system (or at least the subset-difference technique). But only if there is any demand for it ;).

Regards,

arnezami

PS. For the keen observer: I'm not telling which player I used (well you can guess but you might guess wrong) to retrieve the Processing Key because I don't want to give the AACS LA any extra legal ammunition against any player company. Nothing was hacked, cracked or even reverse engineered btw: I only had to watch the "show" in my own memory. No debugger was used, no binaries changed.

jokin

11th February 2007, 17:18

Awesome awesome work.

And when you have time please explain the subset-difference technique.

Thanks again.

hd1080p

11th February 2007, 17:22

It is better than the real movie show. You are a genius!!
Please continue the work with blueray.:thanks:

zeroprobe

11th February 2007, 17:24

great stuff. More write ups of the whole process would be greatly appreciated. More information the better.

How about one for bluray :)

arnezami

11th February 2007, 17:25

It is better than the real movie show. You are a genius!!
Please continue the work with blueray.:thanks:

If somebody can give the same info Eeknay gave above (but for a Blu-Ray disc) I could see if this Processing Key works for Blu-Ray aswell.

pacman2006

11th February 2007, 17:29

Amazing work Arnezami! :D

I'm trying to understand the full aspect of having a processing key. Will this work for future discs too, or is this key also revokable?

hd1080p

11th February 2007, 17:40

Unfortunately, they (MPAA) can change the keys for future releases. At least now all current HD-DVD releases are deemed DRM free.
Fortunately, using ARNEZAMI's methodology, we can find them again using the particular player. Of course, they (player vendor) can change the way they implement the AACS DRM or even MPAA people can even change the AACS specs.

Amazing work Arnezami! :D

I'm trying to understand the full aspect of having a processing key. Will this work for future discs too, or is this key also revokable?

LokiHD

11th February 2007, 18:14

nice!

too funny..

mb2696

11th February 2007, 18:15

@arnezami - Amazing work!!! I'd really like to hear your in-depth take on AACS as well.

madshi

11th February 2007, 18:18

That sounds very nice!

But what happens if Volume IDs are created with real random numbers in the future? Will a Processing Key then still help?

Thanks!

buttfacepoop

11th February 2007, 19:33

Regards,

arnezami

PS. For the keen observer: I'm not telling which player I used (well you can guess but you might guess wrong) to retrieve the Processing Key because I don't want to give the AACS LA any extra legal ammunition against any player company. Nothing was hacked, cracked or even reverse engineered btw: I only had to watch the "show" in my own memory. No debugger was used, no binaries changed.

arnezami,

thanks for your fantastic work.

i think by describing your exact method in finding the key, however, may lead people/MPAA to the exact player that is being used. perhaps when you in the future crack the player just post the key, no explanation?

SBeaver

11th February 2007, 20:40

I wasn't expecting this so soon.
You really did a great job, and whomever made the software player f**ked up serverely.

You shouldn't give up on the device keys though, we should steal all the keys they have.

btw is it possible to find the processing key with the usb sniffer, now that you know what the key is?
or is it moved over in encrypted form?
and finding it on the disk would be great, even if it's encrypted in several layers.

Anyway, you rock

tonyp12

11th February 2007, 21:53

SBeaver

11th February 2007, 22:34

So now that we have a Processing key,
How time consuming would it be to guess the VID (instead of USB sniffing)?

For example a decrypter that says
"please wait, I'm trying 2million possible keys"
And do that in about 30 seconds.

That would take some time to figure out.
A good start would be if we could get more sniffed volume IDs and unencrypted Volume IDs from different discs so we can figure out the patterns in the keys, if there are any.
If you can guess the key down to 6 unknown bytes by jst knowing the manufacturer then it's will work, but the more unknown bytes the more impossible it gets.
Finding a pattern is the only way i think, and it will work as long as the discs follow these patterns.
As soon as they fall outside the box then you have to go sniff again.

Ishan

11th February 2007, 22:44

I don't think there's any pattern, it seems it's different for each manufacturer.

SBeaver

11th February 2007, 22:53

I don't think there's any pattern, it seems it's different for each manufacturer.

well that is a patterns, there is just a few manufacturers making all (edit: most) the discs anyway so if we know patterns for each that is enough.
not a perfect solution though.

madshi

11th February 2007, 22:54

I rather think if the manufacturers/studios get notice of this thread they will probably make Volume IDs much more random than before. So I rather doubt that guessing will work in the future.

tonyp12

11th February 2007, 23:09

It probably will take 2 months before we start seeing
any changes in the values they use for Processing Key and VID.

It would be cool to have a HDDVD-decrypter that can decrypt
any disc from the top10 manufactures before this date without memdump/sniffing/keydb.cfg

After that it will be a cat and mouse game.

evdberg

11th February 2007, 23:19

Arnezami did great work, but he played out his cards much too soon ...

blutach

11th February 2007, 23:35

You shouldn't give up on the device keys though, we should steal all the keys they have.
Rather poor choice of words. Nobody here is stealing anything - they are exercising their rights to play their legally bought material however they want to.

Regards

Adub

11th February 2007, 23:39

@evdberg
What exactly do you mean about playing his cards to soon? Are you saying he should have waited until the VUK memdump search method was retired?

What would you have done?

SBeaver

12th February 2007, 00:15

Rather poor choice of words. Nobody here is stealing anything - they are exercising their rights to play their legally bought material however they want to.

Regards

Well stealing is their definition of what people are doing.
Let's just say we are making copies of their keys just in case they lose them. :)

evdberg

12th February 2007, 00:23

@evdberg
What exactly do you mean about playing his cards to soon? Are you saying he should have waited until the VUK memdump search method was retired?

Definitely !

What would you have done?

I can understand his enthusiasm (it clearly showed from his posts), he was on to something and I know how that feels. But since the current method is still not counteracted, it's better to keep it to yourself ... don't bring other people on ideas ... well, the rabbit is out of the hat now, we will see what happens, but my guess is that a very promising method is wasted now.

xyz987

12th February 2007, 00:48

I'm also thinking about doing a full explanation of the AACS protection system (or at least the subset-difference technique). But only if there is any demand for it ;).

Congratulations :-)

And yes, there is demand ;-)

:thanks:

xyz987

12th February 2007, 01:08

I can understand his enthusiasm (it clearly showed from his posts), he was on to something and I know how that feels. But since the current method is still not counteracted, it's better to keep it to yourself ... don't bring other people on ideas ... well, the rabbit is out of the hat now, we will see what happens, but my guess is that a very promising method is wasted now.

May be they can revoke this Processing Key. So what?. In fact i want to see them revoking tons of keys. More easy will be to guest the Master Key.

noclip

12th February 2007, 01:59

Some of you are missing the true meaning of this compromise. If they revoke this processing key, we just take a player compatible with a new processing key, put in one of the titles that's already cracked, and go around in memory looking for the known key. We find it, insert a new title, look in the same place and we have a new processing key.

Adub

12th February 2007, 04:22

That's what I was thinking, I just wasn't sure that it would be so simple to find the new key quickly.

tonyp12

12th February 2007, 05:53

memory looking for the known key. We find it, insert a new title, look in the same place and we have a new processing key.

AACS-LA probably will revoke both windvd and powerdvd device keys,
give out new device and processing keys.
But only after the makers of the software players shows that
no keys whatsoever are in memory in plain view at any time.

The keys will only be in the CPU's register for a brief time.

Galileo2000

12th February 2007, 05:56

Great job.

And yes, we DEMAND explanations! :D

BTW, I think I guessed your player all right.

You gave me a processing key in one of your posts.:devil:

evdberg

12th February 2007, 10:42

That's what I was thinking, I just wasn't sure that it would be so simple to find the new key quickly.

I am pretty sure that Cyberlink and InterVideo have to make sure it won't be as easy as it is now ... or worst case: their keys are revoked and they do not get new ones at all !

cyber1

12th February 2007, 12:13

AACS-LA probably will revoke both windvd and powerdvd device keys,
give out new device and processing keys.
But only after the makers of the software players shows that
no keys whatsoever are in memory in plain view at any time.

The keys will only be in the CPU's register for a brief time.

This is probably what is going to happen, the only reason that the search-memdump-method have worked so far is that one HD-DVD application have a terrible AACS implementation. It's going to be much harder in the future.

zeroprobe

12th February 2007, 12:37

This is probably what is going to happen, the only reason that the search-memdump-method have worked so far is that one HD-DVD application have a terrible AACS implementation. It's going to be much harder in the future.

I really can't see them stopping us finding the VUK's . As we already know them for 150 titles.

We know what to look for as you just use the new "improved" software player to playback an old hddvd disc. Then we just search for the old vuks. They messed up now and we now know what we are looking for.

pacman2006

12th February 2007, 13:38

We know what to look for as you just use the new "improved" software player to playback an old hddvd disc. Then we just search for the old vuks.

The new software players will do everything to hide the vuk's. A simple search for the keys won't work. The keys will be scrambled. They could also do several other things to hide the keys, but I won't give them any good ideas. :p

evdberg

12th February 2007, 14:05

The new software players will do everything to hide the vuk's.

And because of Arnezami's work most likely also the other keys like the Media and Processing key ... and that is what I meant with 'playing his cards too soon'.

arnezami

12th February 2007, 14:18

And because of Arnezami's work most likely also the other keys like the Media and Processing key ... and that is what I meant with 'playing his cards too soon'.

Nonsense. I have no time now but will have later.

But this for now: the Processing Key and/or Device Keys of a player were already compromised before this thread even started. Keep your facts straight. I started this topic knowing AnyDVD had already done it. But that was not the only reason. Will explain more later.

Please concentrate now on doing something constructive. Like trying to build sniffing software, giving more Volume IDs, getting Blu-Ray C-values/Validate Media Key etc.

Regards,

arnezami

evdberg

12th February 2007, 16:17

I started this topic knowing AnyDVD had already done it.

Where did you read this? I can only find speculation and phrases like "So just how does AnyDVD HD work? Has SlySoft managed to really crack AACS? For now, no one is sure just how AnyDVD HD will work exactly.". I agree with you to keep the facts straight ...

zeroprobe

12th February 2007, 22:16

Where did you read this? I can only find speculation and phrases like "So just how does AnyDVD HD work? Has SlySoft managed to really crack AACS? For now, no one is sure just how AnyDVD HD will work exactly.". I agree with you to keep the facts straight ...

Every post you make is negative, you don't have a clue what your talking about.

Theres only two possible ways AnyDVD can work and I can 99.9% say that they didn't break aacs so it must be this way.

evdberg

12th February 2007, 22:17

Anyway ... in the meantime that this forum was down due to moving to another server, I made a small program that implements what is discussed in this thread. I can only conclude it works perfectly fine, and I am amazed that this one processing key every time works on the very first c-value (of 512 available). Obviously someone at the mastering facility was very lazy ...

Dethis

12th February 2007, 22:19

.... For now, no one is sure just how AnyDVD HD will work exactly.". ...

Except beta testers..;)

evdberg

12th February 2007, 22:20

Every post you make is negative, you don't have a clue what your talking about.

I can only conclude that you have no idea who I am ...

Theres only two possible ways AnyDVD can work and I can 99.9% say that they didn't break aacs so it must be this way.

For all we know they just include a lookup table with all known VUKs. Since they release twice a week a new version of AnyDVD, they can keep that table up-to-date. And since you can not read the Volume ID directly from a disk (must go through secured handshake commands through MMC commands), they can't use this new method. So indeed there are 2 methods: either the above mentioned lookup table of VUKs, or they use a device key and perform the whole protocol.

xyz987

12th February 2007, 22:20

arnezami

12th February 2007, 22:20

Every post you make is negative, you don't have a clue what your talking about.

Theres only two possible ways AnyDVD can work and I can 99.9% say that they didn't break aacs so it must be this way.

Thank you so much. For a moment I thought I was biased. I really considered spending (or should I say wasting) useful time on a response. But you said it very clearly in two sentences.

evdberg

12th February 2007, 22:22

Except beta testers..;)

They can only test functionality of the program, they do not know anything about its workings.

Electrox3d

12th February 2007, 22:32

I've got blu-ray drives coming out of my ears... anything you want me to try?

arnezami

12th February 2007, 22:36

Source code please :-)

Some sample code for those eagerly waiting:

// Processing Key
static unsigned char processing_key[16] = {0x09,0xF9,0x11,0x02,0x9D,0x74,0xE3,0x5B,0xD8,0x41,0x56,0xC5,0x63,0x56,0x88,0xC0};

// Encrypted C Value
static unsigned char encrypted_c_value[16] = {0x6D,0x02,0xCA,0xC6,0x7B,0x1A,0x7E,0x95,0xC2,0x16,0xEF,0xD4,0xC9,0x28,0x09,0xCF};

//Decrypted C Value
static unsigned char decrypted_c_value[16];
static unsigned char uv[4] = {0x00,0x00,0x00,0x01};

// Media Key
static unsigned char media_key[16];

//Encrypted Verification Data (King Kong)
static unsigned char encrypted_verification_data[16] = {0x87,0xB8,0xA2,0xB7,0xC1,0x0B,0x9F,0xAD,0xF8,0xC4,0x36,0x1E,0x23,0x86,0x59,0xE5};

//Decrypted Verification Data Should Be
static unsigned char decrypted_verification_data_should_be[8] = {0x01,0x23,0x45,0x67,0x89,0xAB,0xCD,0xEF};

//Decrypted Verification Data
static unsigned char decrypted_verification_data[16];

// Volume ID
static unsigned char volume_id[16] = {0x40,0x00,0x09,0x18,0x20,0x06,0x08,0x41,0x00,0x20,0x20,0x20,0x20,0x20,0x00,0x00};

//Decrypted Volume ID
static unsigned char decrypted_volumeid[16];

//Volume Unique Key
static unsigned char volume_unqiue_key[16];

// First decrypt the C-value with the processing key
oRijndael.MakeKey((char *)processing_key, CRijndael::sm_chain0, 16, 16);
oRijndael.DecryptBlock((char *)encrypted_c_value, (char *)decrypted_c_value);

// Then XOR it with with the uv (of the corresponding C-value)
for (j = 0; j < 16; j++)
{
if (j < 12)
{
media_key[j] = decrypted_c_value[j];
}
else
{
media_key[j] = decrypted_c_value[j]^uv[j-12];
}
}

// Then check if the resulting media key is correct using the verify media key record
oRijndael.MakeKey((char *)media_key, CRijndael::sm_chain0, 16, 16);
oRijndael.DecryptBlock((char *)encrypted_verification_data, (char *)decrypted_verification_data);

if (!memcmp(decrypted_verification_data_should_be, decrypted_verification_data, 8))
{
for (j = 0; j < 16; j++)
{
printf("%02X ", decrypted_verification_data[j]);
}
}
printf("\n");

// Then do a AES-G (basicly a decrypt and an XOR) on the media key + volumeID
oRijndael.MakeKey((char *)media_key, CRijndael::sm_chain0, 16, 16);
oRijndael.DecryptBlock((char *)volume_id, (char *)decrypted_volumeid);
for (j = 0; j < 16; j++)
{
volume_unqiue_key[j] = volume_id[j]^decrypted_volumeid[j];
}
printf("\n");

// This results in the Volume Unique Key
for (j = 0; j < 16; j++)
{
printf("%02X ", volume_unqiue_key[j]);
}
printf("\n");

xyz987

12th February 2007, 22:42

Some sample code for those eagerly waiting:

Great!!

:thanks:

xyz987

12th February 2007, 22:50

I've got blu-ray drives coming out of my ears... anything you want me to try?

Of course, we want to know if arnezami's Processing Key works with BluRay movies.

I suppose arnezami will give you instructions soon.

evdberg

12th February 2007, 22:51

And a small PC prog to play around with it ... (had to convert it from my Mac test version)

Usage: mkb <mkb_file> [volume_id]

blutach

12th February 2007, 22:52

Guys - I wake up to something building to a flame a war?

Let's keep it on an even keel and stick to the technical please. We all have something to contribute - let's do it in a postive way!

Regards

xyz987

12th February 2007, 22:57

And a small PC prog to play around with it ... (had to convert it from my Mac test version)

Usage: mkb <mkb_file> [volume_id]

:thanks:

appleguru

12th February 2007, 23:01

And a small PC prog to play around with it ... (had to convert it from my Mac test version)

Usage: mkb <mkb_file> [volume_id]

Can I get the mac version? :)

evdberg

12th February 2007, 23:04

Can I get the mac version? :)

Sure ... if you explain me how you can read a HD-DVD using the Xbox-360 drive on the Mac? Because if I insert a disk in the drive, OS-X comes up with the message "Unknown format, Ignore or Eject".

Electrox3d

12th February 2007, 23:08

Of course, we want to know if arnezami's Processing Key works with BluRay movies.

I suppose arnezami will give you instructions soon.

So... Should I run the USBsniffer program using a blu-ray drive / movie / WinDVD like the HDDVD instructions did? or is it something else that needs to be tested w/blu-ray?

Arnezami - what test would you like done w/blu-ray?

appleguru

12th February 2007, 23:11

Sure ... if you explain me how you can read a HD-DVD using the Xbox-360 drive on the Mac? Because if I insert a disk in the drive, OS-X comes up with the message "Unknown format, Ignore or Eject".

Leopard my friend ;)

evdberg

12th February 2007, 23:13

Here you go ... the Mac OS-X Universal binary ! :)

appleguru

12th February 2007, 23:13

RE: reading HD DVD discs in leopard.. they mount, but show up in the finder as empty. If you ls -a them in the terminal you can see that it does indeed show the files. Seems apple updated the UDF drivers for leopard in preparation for next gen video support.

arnezami

12th February 2007, 23:14

So... Should I run the USBsniffer program using a blu-ray drive / movie / WinDVD like the HDDVD instructions did? or is it something else that needs to be tested w/blu-ray?

Arnezami - what test would you like done w/blu-ray?

The things we need to see if this processing key works with Blu-Ray aswell (I've already heard the proc key is in a Blu-Ray memdump so its very likely now) is in this post (http://forum.doom9.org/showthread.php?p=952954#post952954).

So we need:

(1) Title of the Movie (not really needed but is nice to know)
(2) The Verify Media Key Record in the MKBROM.AACS
(3) The first C-Value in the MKBROM.AACS file

Then we will know if it works for Blu-Ray aswell.

And if you will (optional) :

(4) To go towards the VUK we also need the Volume ID (you either should use a sniffer or if you don't have it usb connected: a memdump which is harder, read the instruction in this thread)

appleguru

12th February 2007, 23:14

Here you go ... the Mac OS-X Universal binary ! :)

Thanks... Not quite sure what it does yet, but I like to play around :)

xyz987

12th February 2007, 23:20

So... Should I run the USBsniffer program using a blu-ray drive / movie / WinDVD like the HDDVD instructions did? or is it something else that needs to be tested w/blu-ray?

No, in fact arnezami just needs 2 data from your BluRay disk (Verify Media Key Record and first C-Value) to test the Processing Key.

On HD-DVD disk these data are stored in MKBROM.AACS file. Unfortunately I don't know if file name or key offsets inside file are the same in BluRay.

Electrox3d

12th February 2007, 23:33

The things we need to see if this processing key works with Blu-Ray aswell (I've already heard the proc key is in a Blu-Ray memdump so its very likely now) is in this post (http://forum.doom9.org/showthread.php?p=952954#post952954).

So we need:

(1) Title of the Movie (not really needed but is nice to know)
(2) The Verify Media Key Record in the MKBROM.AACS
(3) The first C-Value in the MKBROM.AACS file

Then we will know if it works for Blu-Ray aswell.

And if you will (optional) :

(4) To go towards the VUK we also need the Volume ID (you either should use a sniffer or if you don't have it usb connected: a memdump which is harder, read the instruction in this thread)

OK, so where do I find the MKBROM.AACS file? It is not located on the BD movie disc, is this file created when the movie is played somewhere?

I can use the sniffer for (4), and I read the instructions for it, so when I make the log file using the sniffer, is it called VolumeID in the log?

xyz987

12th February 2007, 23:38

OK, so where do I find the MKBROM.AACS file? It is not located on the BD movie disc, is this file created when the movie is played somewhere?

No, it is on BluRay disk (may be with another name, but it is on disk). Did you look at AACS directory on disk?

Edit:

From ACCS specification for prerecorded BluRay:

"Each BD-ROM disc that contains content encrypted by AACS [using a CPS Unit Key that is provided in the
AACS directory] shall include two Read-Only Media Key Blocks (MKB). The MKB “MKB_RO.inf” shall be
stored in the “\AACS” directory and in the “\AACS\DUPLICATE” directory."

arnezami

12th February 2007, 23:39

No, in fact arnezami just needs 2 data from your BluRay disk (Verify Media Key Record and first C-Value) to test the Processing Key.

On HD-DVD disk these data are stored in MKBROM.AACS file. Unfortunately I don't know if file name or key offsets inside file are the same in BluRay.

Sorry. (i'm not used to Blu-Ray yet) it should be called MKB_RO.inf. And I think it should have the same layout of that of a MKBROM.AACS file (on a HD DVD disc). So my other directions should stay the same. Keep us informed ;).

Keep in mind you have to open it with a hex editor (best is WinHex).

ioakougroup

12th February 2007, 23:51

YES YES YES!! It works! :D :D :D

I'm going to take some rest now (I need it ;)). But will tell all later.

Here is the Processing Key which should work on all HD DVD discs (and maybe even Blu-Ray discs) released so far:

09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Save it. Store it. :)

Regards,

arnezami

PS. As explained before in order to get a VUK you now only need a Volume ID (which should be fairly easy to get or even to guess...).

WELL DONE MATE!!! :thanks:

Electrox3d

12th February 2007, 23:57

Sorry. (i'm not used to Blu-Ray yet) it should be called MKB_RO.inf. And I think it should have the same layout of that of a MKBROM.AACS file (on a HD DVD disc). So my other directions should stay the same. Keep us informed ;).

Keep in mind you have to open it with a hex editor (best is WinHex).

Ok, so far here's what I've got:

(1) Title: Talladega Nights (disc included w/PS3, not uncut retail copy)
(2) The Verify Media Key Record in the MKB_RO.inf file:
81 00 00 14 B3 85 A4 20 78 21 99 80 71 06 27 B2 7B F7 C5 41 7F 00 00 xx
(3) The First C-Value in the MKB_RO.inf file:
05 00 20 14 CB B1 61 65 DD C1 96 FC 65 D0 E6 A0 33 30 45 F5 32 62 2D 6D

So for (4), when I use the USB sniffer and I open the program, I have over ten "USB Mass Storage Device" items listed... is there a way of being sure I've selected the correct one? EDIT: I think I got it... post in a minute.

arnezami

13th February 2007, 00:07

Ok, so far here's what I've got:

(1) Title: Talladega Nights (disc included w/PS3, not uncut retail copy)
(2) The Verify Media Key Record in the MKB_RO.inf file:
81 00 00 14 B3 85 A4 20 78 21 99 80 71 06 27 B2 7B F7 C5 41 7F 00 00 xx
(3) The First C-Value in the MKB_RO.inf file:
05 00 20 14 CB B1 61 65 DD C1 96 FC 65 D0 E6 A0 33 30 45 F5 32 62 2D 6D

So for (4), when I use the USB sniffer and I open the program, I have over ten "USB Mass Storage Device" items listed... is there a way of being sure I've selected the correct one?

It works!!! :D :D :D :D :D

Much thanks.

Blu-Ray is also decryptable with this Processing Key. You just confirmed this.

The Media Key that is. As for selecting the right USB Mass Storage Device I really don't know. What else have you attached on your usb? Maybe just try: whatever generates large log files after starting your Software Player is the right one ;).

evdberg

13th February 2007, 00:08

My small prog should also work with BluRay, just use the MKB_RO.INF as 1st parameter (instead of MKBROM.AACS). Les, can you approve the attachment?

Founditalso

13th February 2007, 00:08

arnezami

13th February 2007, 00:15

Another one (if I did everything right)

House Of Flying Daggers
81 00 00 14 0E 6C 59 50 9C 1C 9D 8C CC DD 5F 26 CF C7 28 8F
05 00 20 14 8D C1 F2 60 95 D0 6B 48 B4 F2 01 C3 30 D8 35 2D
Does it help?

Works too! :) Another confirmation...

xyz987

13th February 2007, 00:16

It works!!! :D :D :D :D :D

Blu-Ray is also decryptable with this Processing Key.

Congratulations again :-)

They are using the same root/master key for both BluRay and HD-DVD. So any Processing/Device Key should work for both.

Are you reading this, AnyDVD guys?. Start developing the new version with BluRay support ;-D

xyz987

13th February 2007, 00:20

(1) Title: Talladega Nights (disc included w/PS3, not uncut retail copy)
(2) The Verify Media Key Record in the MKB_RO.inf file:
81 00 00 14 B3 85 A4 20 78 21 99 80 71 06 27 B2 7B F7 C5 41 7F 00 00 xx
(3) The First C-Value in the MKB_RO.inf file:
05 00 20 14 CB B1 61 65 DD C1 96 FC 65 D0 E6 A0 33 30 45 F5 32 62 2D 6D

Now you can say everybody you helped to break BluRay :-)

:thanks:

arnezami

13th February 2007, 00:22

Congratulations again :-)

They are using the same root/master key for both BluRay and HD-DVD. So any Processing/Device Key should work for both.

Are you reading this, AnyDVD guys?. Start developing the new version with BluRay support ;-D

Don't forget AnyDVD do not need to extract the Volume ID. Which could mean 1 of 2 things: they have the Host private key or they are guessing the HD DVD Volume IDs.

Which brings us to our most needed information from those who have HD DVD discs.

Please post Volume IDs of this type (if you find any)

Appollo 13:
Hex: 40 00 04 06 32 04 20 11 57 47 48 44 56 4D 00 00
Ascii: W G H D V M

Batman Begins:

Hex: 40 00 40 06 26 08 10 15 57 47 48 44 56 4D 00 00
Ascii: W G H D V M

Please help us here. :)

This could be very useful in determining a way of guessing the Volume IDs for HD DVDs (which might be the reason AnyDVD is only supporting HD DVD atm ;)).

Electrox3d

13th February 2007, 00:23

Ok, so far here's what I've got:

(1) Title: Talladega Nights (disc included w/PS3, not uncut retail copy)
(2) The Verify Media Key Record in the MKB_RO.inf file:
81 00 00 14 B3 85 A4 20 78 21 99 80 71 06 27 B2 7B F7 C5 41 7F 00 00 xx
(3) The First C-Value in the MKB_RO.inf file:
05 00 20 14 CB B1 61 65 DD C1 96 FC 65 D0 E6 A0 33 30 45 F5 32 62 2D 6D

So for (4), when I use the USB sniffer and I open the program, I have over ten "USB Mass Storage Device" items listed... is there a way of being sure I've selected the correct one? EDIT: I think I got it... post in a minute.

OK, for the VolumeID, I *think* you are asking for the 6 bytes after the 00 22 00 00, right? Here's what I found for this disc:
00000000: 00 22 00 00 7f 58 3c b4 6c 30

EDIT: I read a little more about the blu-ray VolumeID, and it seems more complicated than this... From what I understand, there is only one place that has 32 random bytes after the 00 22 00 00... how do I find the correct one? Do I have to get multiple logs and compare them?

arnezami

13th February 2007, 00:46

OK, for the VolumeID, I *think* you are asking for the 6 bytes after the 00 22 00 00, right? Here's what I found for this disc:
00000000: 00 22 00 00 7f 58 3c b4 6c 30

EDIT: I read a little more about the blu-ray VolumeID, and it seems more complicated than this... From what I understand, there is only one place that has 32 random bytes after the 00 22 00 00... how do I find the correct one? Do I have to get multiple logs and compare them?

I need 16 bytes (not 6 bytes) after the 00 22 00 00. So 10 more ;). But not more than that! (for your own protection)

Electrox3d

13th February 2007, 00:49

I need 16 bytes (not 6 bytes) after the 00 22 00 00. So 10 more ;).

Here's the full string, making it 16 bytes including the 00 22 00 00:
00000000: 00 22 00 00 7f 58 3c b4 6c 30 99 e5 c8 99 44 08

Is this it? It seems the 00 22 00 00 shouldn't be part of the 16 bytes... after 99 44 08 there's a period, then it starts a new line with "0000010: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx"

arnezami

13th February 2007, 00:58

Here's the full string, making it 16 bytes:
00000000: 00 22 00 00 7f 58 3c b4 6c 30 99 e5 c8 99 44 08

Is this it?

Sorry no still 4 bytes short.

What is the title of the movie? For full confirmation I probably also need the encrypted title key in the CPS unit key file. I'll try to find out where you can find that.

Electrox3d

13th February 2007, 00:58

Yes thats it :). Perfect.

What is the title of the movie? For full confirmation I probaly also need something the encrypted CPS unit key. I'll try to find out where you can find that.

Talladega Nights The Ballad of Ricky Bobby (the edition that comes with ps3, not the uncut retail edition)

Ok, in addition, I found that the three lines in the hex editor equal up to 32 characters total (minus the 00 22 00 00) and this is probably the VolumeID and MAC, wouldn't you think?
00000000: 00 22 00 00 7f 58 3c b4 6c 30 99 e5 c8 99 44 08
00000010: 07 f7 41 4b xx xx xx xx xx xx xx xx xx xx xx xx
00000020: xx xx xx xx

So VolumeID is probably: 7f 58 3c b4 6c 30 99 e5 c8 99 44 08 07 f7 41 4b

xyz987

13th February 2007, 01:07

Don't forget AnyDVD do not need to extract the Volume ID. Which could mean 1 of 2 things: they have the Host private key or they are guessing the HD DVD Volume IDs.

No, there is another method. They can redirect through Internet the USB conection between HD-DVD device (at home of AnyDVD user) and an authorized HD-DVD host (WinDVD, PowerDVD, whatsoever) running on an AnyDVD developers server. They can sniff VolumeID that way.

And another method: a hacked device firmware can algo give you the VolumeID sans Host Private Key.

arnezami

13th February 2007, 01:14

Talladega Nights The Ballad of Ricky Bobby (the edition that comes with ps3, not the uncut retail edition)

Ok, in addition, I found that the three lines in the hex editor equal up to 32 characters total (minus the 00 22 00 00) and this is probably the VolumeID and MAC, wouldn't you think?
00000000: 00 22 00 00 7f 58 3c b4 6c 30 99 e5 c8 99 44 08
00000010: 07 f7 41 4b xx xx xx xx xx xx xx xx xx xx xx xx
00000020: xx xx xx xx

So VolumeID is probably: 7f 58 3c b4 6c 30 99 e5 c8 99 44 08 07 f7 41 4b
Yes this is right.

This results in the following Volume Unique Key:

9A C3 7C 74 93 F6 BA 64 A7 AE E2 D4 E8 6C 0F 8C

Now if you have a memdump its probably in it. Otherwise we would have to use it to decrypt the encrypted CPS Unit Key (=Title Key for HD DVD).

PS. I have to go to sleep ....

Electrox3d

13th February 2007, 01:20

Yes this is right.

This results in the following Volume Unique Key:

9A C3 7C 74 93 F6 BA 64 A7 AE E2 D4 E8 6C 0F 8C

Now if you have a memdump its probably in it. Otherwise we would have to use it to decrypt the encrypted CPS Unit Key (=Title Key for HD DVD).

PS. I have to go to sleep ....

Tell me how to get a memdump. (aww... sleep?? where do u live??, its mid-day here)

xyz987

13th February 2007, 01:28

Now if you have a memdump its probably in it. Otherwise we would have to use it to decrypt the encrypted CPS Unit Key (=Title Key for HD DVD).

CPS Unit Key of Talladega Nights (US PS3 version) is a previously published key. It was published at Janvitos thread. Here is the key:

243302819492872FB60BF20BCCE28531

guile

13th February 2007, 01:36

WOW!! A LOT has happened in a few days. Excellent work here. Please approve Edvberg's file, I would like to play with it.

HyperHacker

13th February 2007, 01:49

General question: does anybody have an (old) PowerDVD version that doesn't support HD/BD playback? Does it also have *.fcl files?

Do you still need this? I have PowerDVD 6 "2CH" that came with a DVD burner I bought recently. I see no mention of Blu-ray or HD-DVD on the disc; I've never actually used it (just now, to check the version, was the first time I ever even took it out of the sleeve) since VLC does the job nicely. (It wasn't an HD-DVD or Blu-ray drive, though, so I highly doubt they included software that could play those. ;))

arnezami

13th February 2007, 05:18

Tell me how to get a memdump. (aww... sleep?? where do u live??, its mid-day here)

I'm sort of awake again ;). My biological clock is totally screwed.

Anyway.

Here is an easier check (I did the reverse by doing some encrypting). If all is correct (no typos, no mistakes, exact same movie, no bus encryption etc) this should be the encrypted CPS Unit Key:

81 9C CC E5 F7 FC F2 C8 F3 0F D5 59 F0 DD CA 0E

To check if this is correct you can open your Unit_Key_RO.inf file with winhex and hex search for 819CCCE5 and if found you can check if all 16 bytes are the same. If they are then we know the sniffed Volume ID is working for Blu-Ray aswell... (that would be great news)

Btw: anybody with this movie (Talladega Nights - US PS3 version) can check this: the unit key file is on the disc.

arnezami

13th February 2007, 07:34

And a small PC prog to play around with it ... (had to convert it from my Mac test version)

Usage: mkb <mkb_file> [volume_id]

I can confirm it works correctly. Well done :).

Thanks. That also saves me quite some time.

Regards,

arnezami

blutach

13th February 2007, 07:48

For people suggesting AnyDVD do things:

1. We are not Slysoft's forum, although I know they read us.

2. I fervently hope that the work done freely and with such fervour, intellect and imagination by our members will not simply result in a commercial product being launched that takes advantage of all your good work. I truly hope that the work done here can merge into a user friendly freeware product to enable the soon to be many HD-DVD/BR users to backup their material.

Regards

xyz987

13th February 2007, 09:48

[color=blue]For people suggesting AnyDVD do things:

I was just making a joke :-)

In fact I am a Linux user and a free software zealot, so I am not interested on AnyDVD :-)

He-Man

13th February 2007, 09:54

Tell me how to get a memdump. (aww... sleep?? where do u live??, its mid-day here)
You don't actually need a memdump to get the Blu-ray Volume Unique Key and CPS Unit Key, just use ape's Blu-ray Key Finder while WindDVD is playing the Blu-ray disc:
http://forum.doom9.org/showthread.php?t=121021

ape has also made a similar HD DVD Voulme Unique Key Finder:
http://forum.doom9.org/showthread.php?t=120970

christopherw

13th February 2007, 15:53

Happy days :D Can't believe I only just heard about this!

Well done to all involved. Place your bets on when the movie industry'll finally take a hint :D

FoxDisc

13th February 2007, 17:47

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

http://img349.imageshack.us/img349/5159/progress6km3.png

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.

oddball

13th February 2007, 18:12

mrazzido

13th February 2007, 18:40

sorry offtopic..

on german news site HEISE (http://www.heise.de/newsticker/meldung/85258) is an article all about this *g.

FoxDisc

13th February 2007, 18:46

I predict by the time they start revoking (If ever) the whole thing will have been broken wide open. Well I hope so anyhow. Everything that can be made by man can also be broken with some enginuity. The first Quantum computer was recently announced. When those start appearing on desktops the encrytion used will become moot. But it will probably be cracked before then even looking at the speed it's moving right now.

It may look like things are moving fast, but IMHO, nothing being done here comes anywhere near to breaking the cryptography that AACS relies on. Let's face it. The **AA has a near hopeless task. They have to let people watch movies, so no matter how much advanced cryptography they use, they have to give the users the keys to decrypt the data. The keys have to be inside the player, so the best they can do is make it hard to get those keys. That's what's being done here - people are finding the keys that they give us. I see no sign that anyone is breaking any encryption by figuring out keys they don't give us (the master key held by the AACS LA) or even calculating the keys they've already given us (device keys) as opposed to finding them in memory when being used.

Of course, no one needs to break the encryption - finding keys they give us is good enough. It's probably harder for the AACS LA to change device keys and MKBs than it is for others to find them.

Perhaps quantum computing will eventually allow the encryption to be broken, but until then, the AACS system still technically "works" and they can revoke device keys and force them to be found again. All they manage to do is piss off their customers when authorized equipment won't work and DRM free backups do. Eventually, they are bound to see the light.

Electrox3d

13th February 2007, 18:59

I'm sort of awake again ;). My biological clock is totally screwed.

Anyway.

Here is an easier check (I did the reverse by doing some encrypting). If all is correct (no typos, no mistakes, exact same movie, no bus encryption etc) this should be the encrypted CPS Unit Key:

81 9C CC E5 F7 FC F2 C8 F3 0F D5 59 F0 DD CA 0E

To check if this is correct you can open your Unit_Key_RO.inf file with winhex and hex search for 819CCCE5 and if found you can check if all 16 bytes are the same. If they are then we know the sniffed Volume ID is working for Blu-Ray aswell... (that would be great news)

Btw: anybody with this movie (Talladega Nights - US PS3 version) can check this: the unit key file is on the disc.

Yup, I opened Unit_Key_RO.inf and found that CPS Unit Key.
81 9C CC E5 F7 FC F2 C8 F3 0F D5 59 F0 DD CA 0E

Awesome!

XStylus

13th February 2007, 19:15

Wooow. I think I did it :).

Processing Key found!!!

Arnezami, I'll tell you the same thing I told muslix64. Unless you're DVD Jon's neighbor in Norway, PROTECT YOUR IDENTITY. Fixing these DRM crippled technologies is only 75% of the victory. The remaining 25% is in making sure you don't become a martyr.

The greatest victories against the rights-thieving media industries are ones where they are denied their pound of flesh.

I'm also mildly curious as to what Doom9's policies are in case it was ever subpoenaed for IP address info. I know it'd certainly be the toughest decision they'd ever have to make.

Electrox3d

13th February 2007, 19:19

Arnezami, I'll tell you the same thing I told muslix64. Unless you're DVD Jon's neighbor in Norway, PROTECT YOUR IDENTITY. Fixing these DRM crippled technologies is only 75% of the victory. The remaining 25% is in making sure you don't become a martyr.

The greatest victories against the rights-thieving media industries are ones where they are denied their pound of flesh.

There's no law against opening up a .aacs or .inf file on a disc and looking around. Or looking at what your computer is putting into memory... or what information is streaming across usb...

XStylus

13th February 2007, 19:30

There's no law against opening up a .aacs or .inf file on a disc and looking around. Or looking at what your computer is putting into memory... or what information is streaming across usb...

For the purpose of argument, I will agree. However, if the information you discover is disseminated and implemented for the purpose of circumventing a copy protection measure, it is illegal in countries with DMCA-like legislation.

Doom9

13th February 2007, 19:37

didn't we head down that road again before and didn't I put up a hefty roadblock?

bob0r

13th February 2007, 19:45

Electrox3d

13th February 2007, 19:58

fyi, anydvd hd is in beta... http://forum.doom9.org/showthread.php?t=122174

XStylus

13th February 2007, 20:24

didn't we head down that road again before and didn't I put up a hefty roadblock?

I'll have to plead felony stupid on this one and ask which/when/where/what you're referring to. ^^;;;

arnezami

13th February 2007, 20:57

Yup, I opened Unit_Key_RO.inf and found that CPS Unit Key.
81 9C CC E5 F7 FC F2 C8 F3 0F D5 59 F0 DD CA 0E

Awesome!

Great! No Bus decryption on Blu-ray drives yet and its confirmed Blu-ray uses the same Processing Key as HD DVD. :D

Very good news indeed :).

@FoxDisc: i'm working on something. Please have patience. I need to take time to put it all together and make it comprehensible for everyone (given my available time this could take a couple of days). You've got pretty much everything right. The role of the Processing Key will be explained ;).

hd1080p

13th February 2007, 21:11

Arnezami did no wrong. He studied the publicly available AACS specs and really understood them in and out. And then he knew when, where and when to look. There is no law against someone who looked and he didn't steal anything. He just found the keys under the doormat and he didn't go in. Arnezami has nothing to worry about and he didn't violate any copyright laws. He did it for the challenge and the thrill of discovery.

Arnezami, I'll tell you the same thing I told muslix64. Unless you're DVD Jon's neighbor in Norway, PROTECT YOUR IDENTITY. Fixing these DRM crippled technologies is only 75% of the victory. The remaining 25% is in making sure you don't become a martyr.

The greatest victories against the rights-thieving media industries are ones where they are denied their pound of flesh.

I'm also mildly curious as to what Doom9's policies are in case it was ever subpoenaed for IP address info. I know it'd certainly be the toughest decision they'd ever have to make.

Doom9

13th February 2007, 21:13

For those who didn't catch my hint: stay on topic. Stuff about "protect your identity", and legal discussion don't belong neither in this thread nor in this subforum. I've warned people about that in the backuphddvd thread a while back and I'm very disappointed that I have to sing the same song again so soon.

Founditalso

13th February 2007, 22:14

Please post Volume IDs of this type (if you find any)

Appollo 13:
Hex: 40 00 04 06 32 04 20 11 57 47 48 44 56 4D 00 00
Ascii: W G H D V M

Batman Begins:

Hex: 40 00 40 06 26 08 10 15 57 47 48 44 56 4D 00 00
Ascii: W G H D V M

Please help us here. :)

This could be very useful in determining a way of guessing the Volume IDs for HD DVDs (which might be the reason AnyDVD is only supporting HD DVD atm ;)).

Are you still interested in HD DVD Volume ID's?

Name and file date and time (mm/dd/yyyy hh:mm):
VID:

Constantine 05/12/2006 5:05
40 00 30 06 53 05 16 11 57 47 48 44 56 4d 00 00

16 Blocks 05/18/2006 2:48
40 00 07 06 02 05 17 17 57 47 48 44 56 4d 00 00

Kiss Kiss Bang Bang 05/25/2006 4:07
40 00 12 06 51 05 15 24 57 47 48 44 56 4d 00 00

Lady in the Water 10/19/2006 8:36
40 00 08 06 16 10 23 18 57 47 48 44 56 4d 00 00

MI3 10/03/2006 15:34
40 00 20 06 10 03 07 19 00 20 20 20 20 20 00 00

Miami Vice 11/17/2006 8:13
40 00 11 16 20 06 08 28 00 20 20 20 20 20 00 00

Swordfish 04/15/2006 2:10
40 00 53 57 4f 52 44 46 49 53 48 20 20 20 00 00

The Matador 10/19/2006 20:41
40 00 ba be 00 00 00 00 00 00 00 00 00 1c 00 00

Enjoy!

melakai

13th February 2007, 22:26

Are you still interested in HD DVD Volume ID's?

Yes, we've got a sticky for them: http://forum.doom9.org/showthread.php?t=120611

FoxDisc

13th February 2007, 22:36

@FoxDisc: i'm working on something. Please have patience. I need to take time to put it all together and make it comprehensible for everyone (given my available time this could take a couple of days). You've got pretty much everything right. The role of the Processing Key will be explained ;).

@arnezami: Thanks for the quickie reply - it's truly appreciated. There's certainly no hurry - take your time. Do whatever you think is most important first. I'm just trying to understand the whole picture.

Founditalso

13th February 2007, 22:38

Yes, we've got a sticky for them: http://forum.doom9.org/showthread.php?t=120611

The sticky is for VUK's.
Mine are VID's ;)

arnezami

13th February 2007, 23:01

@Founditalso: Thanks. I'm just looking if there is an easy way to predict these Volume IDs. Maybe there are too many types and we have to find and reveal the private host key (or just accept sniffing as part of the process).

Constantine 05/12/2006 5:05
Hex: 40 00 30 06 53 05 16 11 57 47 48 44 56 4d 00 00
Ascii: W G H D V M

16 Blocks 05/18/2006 2:48
Hex: 40 00 07 06 02 05 17 17 57 47 48 44 56 4d 00 00
Ascii: W G H D V M

Kiss Kiss Bang Bang 05/25/2006 4:07
Hex: 40 00 12 06 51 05 15 24 57 47 48 44 56 4d 00 00
Ascii: W G H D V M

Lady in the Water 10/19/2006 8:36
Hex: 40 00 08 06 16 10 23 18 57 47 48 44 56 4d 00 00
Ascii: W G H D V M

Appollo 13:
Hex: 40 00 04 06 32 04 20 11 57 47 48 44 56 4D 00 00
Ascii: W G H D V M

Batman Begins:
Hex: 40 00 40 06 26 08 10 15 57 47 48 44 56 4D 00 00
Ascii: W G H D V M

The 06 is very likely YY. So I suspect the other numbers have something to do with time/date or something aswell. The last two bolded ones look like HHMM.

MI3 10/03/2006 15:34
40 00 20 06 10 03 07 19 00 20 20 20 20 20 00 00
This is YYYYMMDD HHMM probably (ISO format).

Miami Vice 11/17/2006 8:13
40 00 11 16 20 06 08 28 00 20 20 20 20 20 00 00
This is MMDDYYYY HHMM probably (US format).

Swordfish 04/15/2006 2:10
40 00 53 57 4f 52 44 46 49 53 48 20 20 20 00 00
Simple: SWORDFISH

The Matador 10/19/2006 20:41
40 00 ba be 00 00 00 00 00 00 00 00 00 1c 00 00

This seems to be a new type. Are you really sure this one is correct?

FoxDisc

13th February 2007, 23:03

I'm just trying to understand the whole picture.

I realized that I had been looking at the wrong part of the AACS specs. I was looking at the HD-DVD recorded specs, when I needed to look at the introduction and common crypto specs. Section 3.2.4 tells how to calculate the Media key:

Once the device has the correct Device Key D, it calculates a Processing Key K using AES-G3 as described
above. Using that Processing Key K and the appropriate 16 bytes of encrypted key data C, the device calculates
the 128-bit Media Key Km as follows:
Km = AES-128D(K, C) ⊕ (00000000000000000000000016 || uv)
The appropriate encrypted key data C is found in the Media Key Data Record in the Media Key Block.

This gives me the big picture - we don't have a device key, but we've got an intermediate key that the device key gives us that is disk independent and leads to the same answer as the device key would get us. Of course, I'd still love to read arnezami's description later. I'm still working on the whole leaf/node business.

SvT

13th February 2007, 23:20

[code]Constantine 05/12/2006 5:05
Hex: 40 00 30 06 53 05 16 11 57 47 48 44 56 4d 00 00
16 Blocks 05/18/2006 2:48
Hex: 40 00 07 06 02 05 17 17 57 47 48 44 56 4d 00 00
Kiss Kiss Bang Bang 05/25/2006 4:07
Hex: 40 00 12 06 51 05 15 24 57 47 48 44 56 4d 00 00
Lady in the Water 10/19/2006 8:36
Hex: 40 00 08 06 16 10 23 18 57 47 48 44 56 4d 00 00

The 06 is very likely YY. So I suspect the other numbers have something to do with time/date or something aswell. The last two bolded ones look like HHMM.

The 2 before that look like MM or is that just luck ?

Founditalso

13th February 2007, 23:24

The Matador 10/19/2006 20:41
40 00 ba be 00 00 00 00 00 00 00 00 00 1c 00 00[/code]

This seems to be a new type. Are you really sure this one is correct?

Matador is a special case. The disc doesn't play with WinDVD 8 HD. WinDVD stops working and I do not even see the black screen. I do have a log file with the VID however.
When I play it with PowerDVD 7.1 HD it starts but then I get a screen that says that because of parental settings of the player the disc does not play. When I sniff PowerDVD I get the same VID however.

BTW Did you know that the VID's can be found with WinDVD as wel as with PowerDVD? I checked with King Kong and it works (but maybe that is normal).

So with respect to The Matador, as PowerDVD and WinDVD give the same VID, I guess that is what it is?

If you want me to check other things, I have both HD and BD, just let me know.

salkku

13th February 2007, 23:43

Great work indeed :) ( tho I don't have either of those players )

I wonder why some people don't want to "reveal the cards". I mean, in general sense, nothing gets done if we keep postponing things.

I also wonder why the media corporations try to produce some naive protection technology on audio and/or video at all, because the protections can and and will be broken. If nothing else helps, one can just record the HD-show with his HD-videocam.

He-Man

14th February 2007, 01:07

@Founditalso: Thanks. I'm just looking if there is an easy way to predict these Volume IDs. Maybe there are too many types and we have to find and reveal the private host key (or just accept sniffing as part of the process).

Constantine 05/12/2006 5:05
Hex: 40 00 30 06 53 05 16 11 57 47 48 44 56 4d 00 00
Ascii: W G H D V M

16 Blocks 05/18/2006 2:48
Hex: 40 00 07 06 02 05 17 17 57 47 48 44 56 4d 00 00
Ascii: W G H D V M

Kiss Kiss Bang Bang 05/25/2006 4:07
Hex: 40 00 12 06 51 05 15 24 57 47 48 44 56 4d 00 00
Ascii: W G H D V M

Lady in the Water 10/19/2006 8:36
Hex: 40 00 08 06 16 10 23 18 57 47 48 44 56 4d 00 00
Ascii: W G H D V M

Appollo 13:
Hex: 40 00 04 06 32 04 20 11 57 47 48 44 56 4D 00 00
Ascii: W G H D V M

Batman Begins:
Hex: 40 00 40 06 26 08 10 15 57 47 48 44 56 4D 00 00
Ascii: W G H D V M

The 06 is very likely YY. So I suspect the other numbers have something to do with time/date or something aswell. The last two bolded ones look like HHMM.
Blue = YY (year)
Red = MM (month)
Orange = DD minus 1 (date)

I guess the two bytes in between YY, MM & DD are mm (minute) and hh (hour) respectively and the byte before YY is probably ss (second).
So the embedded time and date stamp is probably in this order: 40 00 ss YY mm MM hh DD 57 47 48 44 56 4D 00 00

melakai

14th February 2007, 01:34

The sticky is for VUK's.
Mine are VID's ;)

terribly sorry, i stand corrected!

xyz987

14th February 2007, 02:39

So for the retards like me:

I have a movie, encrpyted, copied via the PS3 on my HDD, no computer hddvd player or bluray player, only a computer with software.

I have mkb.exe and BackupBluRay, can one now make a working copy on a computer using just this software, or do i still need a hddvd player or in this case bluray player?

Nowadays you still need an USB BluRay player, an USB sniffer, and an authorized BluRay soft player (WinDVD or alike).

However, it is just a cuestion of time (probably months) you will just need the PS3 conected to your PC through home network, with appropiate programs running on both sides.

Basically what you need is an "USB sniffer and network redirector". In fact two: a host version for PC and a client version for PS3.

jokin

14th February 2007, 02:49

Nowadays you still need an USB BluRay player, an USB sniffer, and an authorized BluRay soft player (WinDVD or alike).

However, it is just a cuestion of time (probably months) you will just need the PS3 conected to your PC through home network, with appropiate programs running on both sides.

Basically what you need is an "USB sniffer and network redirector". In fact two: a host version for PC and a client version for PS3.

Theoretically you can put any IDE / SATA Blu-Ray drive in an external USB case.

xyz987

14th February 2007, 02:55

Theoretically you can put any IDE / SATA Blu-Ray drive in an external USB case.

So it becomes an USB BluRay player ;-)

jokin

14th February 2007, 04:33

Just found a little tidbit of information on the 360 HD drive. My friend installed my HD drive on his 360 a week or so ago to try it out. He then returned it to me and borrowed it again yesterday and it still worked without installing the software again. Today he bought his drive and plugged it in. It asked for the install disc to update the software. Could this be installing the device keys on the drive or the 360 itself with the included disc?

arnezami

14th February 2007, 05:55

Blue = YY (year)
Red = MM (month)
Orange = DD minus 1 (date)

I guess the two bytes in between YY, MM & DD are mm (minute) and hh (hour) respectively and the byte before YY is probably ss (second).
So the embedded time and date stamp is probably in this order: 40 00 ss YY mm MM hh DD 57 47 48 44 56 4D 00 00
Just Brilliant. I think you nailed that one :).

Founditalso

14th February 2007, 07:25

Just Brilliant. I think you nailed that one :).

Does anybody know the date and time of the files on Batman Begins and Apollo 13?

HD Hell

14th February 2007, 07:30

Congratulations, arnezami (and others!) - stunning!

Exiton

14th February 2007, 13:07

So will this make a stand alone app to retrieve keys? Or still work with a software player and get the key from an error memory dump?

FoxDisc

14th February 2007, 15:47

So will this make a stand alone app to retrieve keys? Or still work with a software player and get the key from an error memory dump?

I'm going to take a shot at answering this. I'm nowhere near to fully understanding the whole system, so take this for what it's worth - and wait for someone to correct me if I'm wrong.

I think the answer is yes, this could make a stand alone app. I think there's enough here for someone to make a software player.
I think the app would stop working if and when the AACSLA changes the MKB.

Obviously, the app would have to read data off the disk. I'm assuming that's possible IOW, I'm assuming that there is nothing in the firmware of the drives being sold that reads an HD or BD disk and says to itself "I'm not authorized to tell the PC what's in the MKB of this disk" or that if there is such a thing that the drive firmware could be cracked/hacked to allow the MKB to be read. I've read the AACS specs about Drive Revocation Lists (drive=the optical drive) and Host Revocation Lists (host=the software player) and I'm not fully certain of the implications of those lists.

I'm also assuming that the Processing Key we have now would not equal a new Processing Key calculated from a future disk released with a new MKB. After a drive revocation and new MKB, someone would again have to find the new Processing Key/Device Key. (It would be stupid to design AACS so that a revoked device key could not calculate the Processing key from the new MKB, but if it could calculate it, the answer would be the same as it would have gotten by calculating the processing key from an older MKB with the revoked device key. Of course, I can't really say with any authority how stupid/smart the AACS system might be.)

brand1130x

14th February 2007, 17:47

how impossible would it be to find the master key? and what could you do with it?

evdberg

14th February 2007, 17:59

As far as I know there is no such thing as a 'master key', so it will be very hard to find ...

brand1130x

14th February 2007, 18:12

so is this processing key the "holy grail" of keys?

SBeaver

14th February 2007, 18:30

so is this processing key the "holy grail" of keys?

A complete list of device keys would be great aswell

xdvst8x

14th February 2007, 18:51

i have both a sony internal blu-ray drive and a plextor drive.
it will not let me watch the movie.. i have both win dvd bd and power dvd bd neither will even try to play the disc.

i can read the drive contents though my computer.
and i have copied Mission Impossible. but i am unable to get win dvd bd to open the disc so i can extract keys.. i have about 64 bd titles now.. please advise.

Electrox3d

14th February 2007, 18:54

So, after more research, I found that a month ago there was a post here at doom9 ( http://forum.doom9.org/showthread.php?t=120988 )with tons of blu-ray keys, and even a program that pulls the keys automatically if you have WinDVD. Why did we do this all over again in this thread?

BTW- using the keys already found in the other thread I was able to get a 1080p blu-ray preview playing in WMV on the Xbox 360... next to try it with H.264 for PS3...

madshi

14th February 2007, 19:15

FoxDisc

14th February 2007, 19:24

As far as I know there is no such thing as a 'master key', so it will be very hard to find ...

Your posts demonstrate a high level of knowledge, so I'm reluctant to disagree, but the AACS LA has the ability to generate a new MKB that revokes some device keys, but not others, and they can generate new device keys that will work with new and old MKBs. No one here can do any of this. The AACS LA has secret keys that are used to perform those functions. If people here had the key(s) they have locked in their vaults, they could generate device keys, new MKBs, etc. and the system would be forever broken.

That's why no one here can say that the AES/AACS system has been cracked - it's only been bypassed. Getting the secret keys stored in the AACS LA vault will be very very very hard. Cryptographically, the AES/AACS system is very very good and not likely to be broken soon.

It was bypassed because the whole concept of encrypting something that you have to let the recipient decrypt is a fundamentally flawed concept. They have to give out the keys to millions of people so they can watch the encrypted movies - how can they expect to keep them secret? The only thing they can keep secret is how to make the keys they give out.

FoxDisc

14th February 2007, 19:52

so is this processing key the "holy grail" of keys?

No. It's a key derived from a device key and other information on a disk that allows other keys to be calculated, ultimately leading to the final title key that decrypts the video data. It appears to have the advantage that every device key currently issued (these are in the players) when used with the current MKB on every disc currently issued (BuRay and HD-DVD) results in this same Processing Key, which then leads to the correct Title Key. If I understand it correctly, this Processing Key will no longer work with new disks if the new disks are provided with a new MKB.

There are currently two AACS bypass methods. One is this Processing Key, which works for all disks and comes from sniffing the USB connection, and one is the Title Key/Volume Unique Key which works for only the specific disk it was obtained from and comes from the memory dump of a player while playing that disk.

What can they do to stop future bypasses? I don't honestly know for sure, and I'd trust Arnezami's analysis, more than anything I say here, but I'll take a stab at it:

To stop the first method (described in this thread), they will have to make the Processing Key that is currently being calculated from the current device keys and MKBs not work. I think that means they have to change the MKB on new disks (this is a fairly big deal, but it's part of their designed in system). Second, they'll have to try to prevent the new Processing Key from being sniffed as this one was.

To stop the second method (title key from mem dump), they could simply have the offending software rewritten to try to make it harder to locate the title key.

I suppose they could stop allowing software players altogether, making it harder to implement either method, as hardware extraction is more difficult than hacking a PC. The battle goes on, but I'm putting my money on the people here who don't want DRM and do want to make fair use of what they buy. Either way, it's interesting to watch.

Electrox3d

14th February 2007, 19:52

Perhaps you should reread this thread.

I have been following this thread... I in fact tested if Blu-ray worked the same as HD-DVD... but I guess I needed to learn more about what happened a month ago before I really understood what we were doing here.

From what I understand a month ago every movie had a different key, but now we've found a type of universal key that both hd-dvd and blu-ray use? Hope thats close.

EDIT: FoxDisc, your post above mine really helped me to understand this thread better. Thanks!

oddball

14th February 2007, 19:54

Which is why it's probably worthless even trying. Just bypass it altogether like it is now and wait for updates once/if they change things. They are probably relying on this fact to slowdown the process.

FoxDisc

14th February 2007, 20:26

EDIT: FoxDisc, your post above mine really helped me to understand this thread better. Thanks!

You are welcome, but I've tried to emphasize that I do not see the entire picture yet, and what I do see is not all that clear. I hope this isn't just thread clutter. There are lots of things I said that are perhaps not true, and lots of details I glossed over that might change things. For example, I said the Processing Key works with all disks and all device keys used with all MKBs to end up with the same processing key. I really doubt that all disks have been checked - This thread only seems to list a dozen or so. Perhaps it won't work with some.

Also, there are lots of details in the whole chain of decryption from device keys to title keys via the MKB. Device Keys are used to calculate Subsidiary Device Keys and Processing Keys. The Processing Key is used with the encrypted key data C (found in the MKB) to create the Media Key....etc.

I think they can make the Processing Key invalid without revoking any Device Keys, simply by changing the MKB (maybe changing the key data C), but I'm not sure. I think they have some options with encrypting the USB communication, but I'm not sure. I think they have some options relating to interaction between the optical drive and the disk before any data gets delivered by the drive to the PC via the USB bus, but I'm not sure. You get the idea. As I said, it will be interesting to see how this all plays out.

guile

14th February 2007, 22:02

Silly question. I am VERY interested in this amazing development and have been following this thread. My question is with regards to Blu Ray. I do NOT have a hdcp compliant rig but do in fact have a Blu Ray drive (which I plan on housing in an external usb enclosure for experimenting). Powerdvd blu ray will not play but....will play for about 5 seconds (as we all know) before giving me the usuall "Non compliant setup" message.

Will this few seconds of playback be enough to extract anything? Or would it actually have to be the "Movie" (rather then the FBI warning that is usually in the first few seconds of playback). Thanks

g

Electrox3d

14th February 2007, 22:26

Multiplex

14th February 2007, 22:39

Q. Will this few seconds of playback be enough to extract anything?
A. Yes. By the time you see video, the VID is posted to the bus.

Q. What about non-usb connections?
A. Two words: Bus Hound.

Q. Can the drive read the MKB?
A. If I read AACS correctly, part of the MKB can live in the disc lead-in. That is outside file space, so it could be tricky on the host end to get at that part. Still, a read is a read. It's not like CSS, where you can't even read the sectors without a encrypted handshake.

Q. I hate searching gobs and gobs of bus traces
A. The VID is returned in response to a READ DVD STRUCTURE command AD 01 00 00 00 00 00 80. Find that going to the drive, and the data back contains the VID. There are maybe 7 total AD 01 commands in a whole disk trace.

Q. Can somebody just write a utility to grab a media VID from the drive?
A. Yes. It's trivial. Just send around 8 ATAPI commands in a row. The difficulty is that you'll need a trusted player key to establish a bus handshake before READ DVD STRUCTURE will give you a key back. Exposing a trusted player key this way will lead to its being killed sooner than later.

xyz987

15th February 2007, 01:06

Q. Can the drive read the MKB?
A. If I read AACS correctly, part of the MKB can live in the disc lead-in. That is outside file space, so it could be tricky on the host end to get at that part. Still, a read is a read. It's not like CSS, where you can't even read the sectors without a encrypted handshake.

No, MBK is entirely on a file. VolumeID is outside file space.

Note VolumeID is not encrypted. If you hack your device firmware you don't need USB sniffing, neither bus handshake.

Xbox HD-DVD drive and PS3 are good candidates for firmware hacking. It is necessary a hight level to hack a firmware, but not so hight to "update" firmware to a hacked one.

xyz987

15th February 2007, 02:09

As far as I know there is no such thing as a 'master key', so it will be very hard to find ...

You are probably right (I am still trying to understand AACS).

Note however there are just 253 Device Keys per product (a BluRay home theater, for instance). As far as i can see, if there is no such "master key", after 253 Device Key revocations some legitime players will stop playing newly released movies.

Is it so easy?. Do we need just to get 253 Device Keys from different players to break the revocation system?

arnezami

15th February 2007, 07:15

You guys are asking all the right questions ;).

Because you are so eager I will give you a little sneak peak of what is to come:

http://img264.imageshack.us/img264/9025/tst7iu8.png

Thats a blue truck with a looong trailer and no reverse... (and some Parking spots)

Regards,

arnezami

PS. I will have lots of time tomorrow (and in the weekend) so hopefully you won't have to wait too long :).

jokin

15th February 2007, 07:20

Lol , ok looks good but I hope the truck has brakes to keep from rolling back down the hill.

xyz987

15th February 2007, 14:22

I think I am starting to understand how this thing works. AACS LA gives each player manufacturer a set of Device Keys (probably just ramdom keys). Each time a movie is printed AACS LA gives disk replicator a Media Key (a ramdom key) and a MKB, i.e. a set of copies of the encrypted Media Key. Each copy is just the Media Key encrypted with a different Device Key. AACS LA chooses the Device Keys to generate MKB in a way that any non-revoked player has at least one Device Key that can decrypt one of the copies of the encrypted Media Key.

Disk replicator combine Media Key with a VolumeID they choose (VolumeID is just to avoid bit-per-bit home disk copying) to produce Volume Key. The movie is encrypted using a random key (Title Key) and the Title Key is encrypted with the Volume Key.

Players just read MKB, look for the fist copy of the encrypted Media Key they can decrypt (because player has the Device Key it was used to encrypt this copy of the Media Key), and get it decrypted. Then they read VolumeID (with a previous cryptographic handshake in case of soft players), calculate Volume Key, use it to decrypt Title Key, and decrypt the movie.

However, I still don't understand the role of the Processing Key. It seems that the Processing Key is just a Device Key. Why it is named differently?

cyber1

15th February 2007, 14:28

AACS LA have an elliptical curve Root private key, this key is used for signing different things, like Drive Certificate, Revocations List, Media Key Blocks. The public key of AACS LA:s Root key is stored inside every HD-DVD/Blu-ray compatible player. But it will be impossible to get the Root private key since probably only a handful of people at the AACS LA have access to it. But if you only want to play an decrypted move from your harddisk you dont need this Root key.

FoxDisc

15th February 2007, 15:49

I still don't understand the role of the Processing Key. It seems that the Processing Key is just a Device Key. Why it is named differently?

I'm not going to comment on the part I didn't quote, only this part. Arnezami's tree diagram is part of the "subset difference" crypto system used by AACS and his explanation should help a lot, but I can add some preliminary details. At the top of his tree (the root) will be the AACS LA. At the bottom will be players/devices (leaves).

Each player gets a "set of device keys." Each player has a "leaf key" associated with itself. The set of device keys allows the player to decrypt the Media Key in the MKB when the Media Key is encrypted with any other leaf key (associated with another device and another set of device keys), but not its own. That's how revocation works. As the AACS common crypto spec puts it: To revoke only a single Leaf Key
(i.e., to enable calculation of the Media Key by any set of device Keys except the set containing that Leaf Key), the Media Key Block will include the Media Key encrypted only by the master tree’s Leaf Key that is being revoked.

The Processing Key is an intermediary key calculated in the decryption process going from the Device Keys to the Media Key.

In the master tree (the one that starts at the AACSLA as the root), every node from the leaf to the root has an associated key, and the set of device keys for a player won't work when the Media Key has been encrypted with a key that is in its own upward chain of nodes from its own leaf to the root. By using a higher level key in the master tree to encrypt the media key, a whole group of adjacent devices (devices with adjacent leaf nodes in the tree) gets revoked (becasue they will all have that node and its key in their upward chain of nodes to the root).

There is a whole parallel system of multiple subtrees and keys associated with all the nodes of those subtrees that start at a node below the AACSLA. They are used to allow revocation of noncontiguous groups of devices.

Blkbird

15th February 2007, 16:17

Everybody who's confused about how AACS works should read Prof. Ed Feltons fascinating series about circumventing AACS:

http://www.freedom-to-tinker.com/?p=1110 (7 articles)
http://www.freedom-to-tinker.com/?p=1121 (today's entry about the newst development - the one this very thread is about; it explains - in very few words - exactly what a processing key is)

Actually it should be a very interesting read even for those who do understand how AACS works.

jkenzie

15th February 2007, 16:50

Not sure if this means anything, but I have seen the seed register
7B103C5DCB08C4E51A27B01799053BD9 pop up in memory a few times

SvT

15th February 2007, 17:00

Not sure if this means anything, but I have seen the seed resister
7B103C5DCB08C4E51A27B01799053BD9 pop up in memory a few times

From the AACS specs page 25:

3.2.2 Calculation of Subsidiary Device Keys and Processing Keys
For the purpose of processing an MKB to calculate Km, Device Keys are used to calculate subsidiary Device
Keys and Processing Keys using the AES-G3 function depicted in Figure 3-2.

A 128-bit input Device Key (which may be a subsidiary Device Key) is denoted ‘k’ in this diagram. This loop
is executed three times to produce 384 output bits, incrementing the seed register by one each time. The output
of AES-128D is XORed with the seed register’s output at each step. For each AES-G3 calculation, the seed
register is initialized by the 128-bit value “s0”, which is given by the following constant:
7B103C5DCB08C4E51A27B01799053BD916

So it means something but it's not the key we want.

FoxDisc

15th February 2007, 17:02

Everybody who's confused about how AACS works should read Prof. Ed Feltons fascinating series about circumventing AACS:

Thanks for the link. I'd read the original series, but not the post today, and it does fill in some holes about the processing key. The situation appears to be about what we thought. They'll be able to make this processing key useless if they want to.

evdberg

15th February 2007, 17:06

jkenzie

15th February 2007, 17:11

So it means something but it's not the key we want.

I understand what it is.

FoxDisc

15th February 2007, 17:28

Feltons fascinating series about circumventing AACS:

BTW, I just realized that todays post is by J. Alex Halderman.
I think Halderman is accurate when he characterizes the current situation as a "gradual meltdown" of the AACS system. Felton and Halderman appear to have studied the system closely, so anyone interested in how it works should read those links.

They're also interested in game theory - what is the best strategy for the AACS LA and what is the best strategy for those breaking the AACS system. In that vein, since the processing key allows decryption of all current disks, anyone who has extracted a device key can hold off disclosing it until the AACS LA reacts to the processing key disclosure. Perhaps there are lots of device keys already extracted that are just sitting in the background waiting to pop up.

FoxDisc

15th February 2007, 17:36

Unfortunately this guy is plain wrong in what he writes about the processing key ... sigh ... he should have read this thread more carefully ...

Can you give us a lead on how you think he's wrong? I'm not agreeing or disagreeing with you, just trying to divine the truth. There were some parts of his post that I couldn't verify from my own study of the AACS, but I didn't see anything I was certain was wrong, and his conclusions seemed to fundamentally match my own. The earlier posts in the series (by Felton) seemed to show a high level of understanding of the AACS system.

evdberg

15th February 2007, 18:03

It's about this:
Each AACS movie is encrypted with a unique title key, and several copies of the title key, encrypted with different processing keys, are stored on the disc.

1) Movie data is encrypted with different title keys.
2) Title keys are encrypted with the Volume Unique Key.
3) There is only 1 copy of the titlekeyfile in the backup folder.

He has no clue about the processing key ... just like me in the beginning to be honest !

arnezami

15th February 2007, 19:01

I can confirm that it is possible for “them” to make Processing Keys (found in the future) far less valuable.

This is because they can use different but equivalent Explicit Subset-Difference Records. In order to decrypt discs with different of these Records you really need Device Keys (because they can choose different Processing Keys).

But since that wasn’t required (AACS screwed up here big time) only the Processing Key was released (which doesn’t identify the software player it came from btw).

Whether they will actually do this “shuffling” inside this Record in the near future (do they even understand how this works? I started to doubt when I saw this record for the first time) is not clear. Maybe they have some (stupid) policy or their program to create these records isn’t up to this yet. I don’t know. We’ll see :) .

Not that any of this really/fundamentally matters though…

FoxDisc

15th February 2007, 19:48

I can confirm that it is possible for “them” to make Processing Keys (found in the future) far less valuable.....Whether they will actually do this “shuffling” inside this Record in the near future .... I don’t know. We’ll see :)

Yes, the AACS LA will probably move slowly. They aren't going to want to change things around, for example the "shuffling" you describe, and then find out that half the hardware players out there have poorly written decryption code and won't correctly play newly released discs with revised MKBs. There can certainly be a big difference between what seems to be technically possible under the AACS specifications and what will really work out in the real world with players already on the market.

@evdberg: Thanks for the comments.

awhitehead

16th February 2007, 01:26

The following look totally random to my untrained eye:

Dates are MM/DD/YYYY

Title: Rambo I
Studio: Studio Canal
Volume ID: 40 00 e0 d8 46 1e cd ff 74 50 92 11 0c dc 00 00
Timestamp: 10/4/2006 12:05 AM <= Must have been a late night render

Title: Rambo II
Studio: Studio Canal
Volume ID: 40 00 18 54 3b d6 24 9b 59 f3 31 1e 49 ee 00 00
Timestamp: 10/3/2006 11:38 pm

Title: Rambo III
Studio: Studio Canal
Volume ID: 40 00 95 ad 18 64 b0 4a 47 9a d2 11 b7 df 00 00
Timestamp: 10/4/2006 10:53 pm

Question: Are these even relevant any more? I was under impression that "people in the know" now know the device key for at least one player (And it was mentioned that SlySoft uses the key from PowerDVD 6.5, so most likely this player is compromised). It was also mentioned that it's about 8 IDE commands to get the drive to unlock and cough up the volume ID, once a proper device key is fed to it. So am I correct in assuming that a piece of code that does just that is now either "doing the rounds", or pretty close to being completed, and we won't need to do the complicated volume ID extraction using USB sniffer?

Personal Comment:Ordering all three Rambo HD-DVDs from Amazon.fr set me back ~160 USD (including shipping) and showed up in my neck of North American woods in 4 days. Studio Canal also released Basic Instinct and Total Recall on HD-DVD, so I urge anyone who liked old Sly to get a legal HD-DVD version :-)

guile

16th February 2007, 13:26

The things we need to see if this processing key works with Blu-Ray aswell (I've already heard the proc key is in a Blu-Ray memdump so its very likely now) is in this post (http://forum.doom9.org/showthread.php?p=952954#post952954).

So we need:

(1) Title of the Movie (not really needed but is nice to know)
(2) The Verify Media Key Record in the MKBROM.AACS
(3) The first C-Value in the MKBROM.AACS file

Then we will know if it works for Blu-Ray aswell.

And if you will (optional) :

(4) To go towards the VUK we also need the Volume ID (you either should use a sniffer or if you don't have it usb connected: a memdump which is harder, read the instruction in this thread)

Newbish question here. With all 4 of the above (and a VUK), how would this work with the config file in backupbluray?

All I see is a place for title hash and vuk.

xyz987

16th February 2007, 14:49

Each player gets a "set of device keys." Each player has a "leaf key" associated with itself. The set of device keys allows the player to decrypt the Media Key in the MKB when the Media Key is encrypted with any other leaf key (associated with another device and another set of device keys), but not its own. That's how revocation
works. As the AACS common crypto spec puts it:

"To revoke only a single Leaf Key (i.e., to enable calculation of the Media Key by any set of device Keys except the set containing that Leaf Key), the Media Key Block will include the Media Key encrypted only by the master tree’s Leaf Key that is being revoked."

I really don't understand this part of the specification. If Media Key is encrypted with that Leaf Key, and you have it, you can decrypt Media Key. But it seems as if specification is saying the contrary.

This is a Device Key tree:

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

Lets say we manufacture player 9. What Device Keys do we get from AACS LA? If we get 3,5,8 we can derive any key except 9,4,2,1. So I suppose we would get 3,5,8. However, I seems as specification says we get 9, not 8.

BTW, AACS specification clearly states that any lower key is a one-way result of any higher key. If an attacker gets the root key, he can get any Device Key and any Processing Key. I suppose it is far hard to get that root key, but an equivalent effect should be to get the 2 keys at level 1 (keys 2 and 3), or the 4 keys at level 2, and so on. Supposedly, any set of Device Keys includes one of the 2 keys at level 1.

FoxDisc

16th February 2007, 15:08

I realize that I've been making some assumptions that I'm now uncertain of. Has anyone been able to calculate a title key/volume unique key from the Processing Key? If so, is it necessary to use the sniffed volume ID or is there enough info in the processing key to read and decrypt everything on the disc that is required?

It seems reasonably certain that all device keys for HD and BD lead to the same processing key, but is there some other required encrypted component from the disc that still needs the device key to decrypt? Perhaps I'll have time this weekend to read the specs again and answer these questions for myself.

Basically, my Qs are:
1) Does this thread conclude that the processing key is currently equivalent to a device key allowing all discs to be fully decrypted? This would be the most powerful. (Originally, I wasn't sure, then I thought this was the case, now I'm not certain again.)
2) Or do we still need other encrypted content from the disc that is disc dependent that must be USB sniffed in order to get to the title key? (I really need to go back and look at the volume ID and C data stuff) This would make the processing key and the USB sniff procedure an alternative to the mem dump procedure, but require a different type of key DB.
3) or is it not yet possible to calculate the title key/volume unique key from the processing key and sniffed data?

xyz987

16th February 2007, 15:19

FoxDisc

16th February 2007, 15:51

I really don't understand this part of the specification. If Media Key is encrypted with that Leaf Key, and you have it, you can decrypt Media Key. But it seems as if specification is saying the contrary.

This is one of those situations where I know I don't know enough to answer this properly. I probably should stay silent, but I've been in the boat you are in - wanting to understand, not knowing where I've gone wrong and hoping for a hint, so I'll try to give you that hint. Take it with a grain of salt - Arnezami says he's going to address this exactly, so just skip this if you can wait, if not, read on.

You had exactly the same question I had, and like me, you confused the leaf/node keys in the tree with the device keys and simplified the system way too much. A device key is not a leaf or node key. The tree shown in the AACS system is a tree of node and leaf keys, not a tree of device keys, like you drew. In fact, there is a master tree that starts at the AACSLA root and ends at all devices, but there are other subtrees, that start one down from the root, and two down from the root, etc. These are not subtrees within the master tree, they are separate subtrees that are parallel to the master subtree, with another set of leaf keys and node keys.

Device keys allow you to get the answer when the data is encrypted with anyone elses leaf key or any node key for a node above their leaf that is not also in the path from your own leaf to the root. You can't get the answer when it's encrypted with your own leaf key or any node key above you, at least not for this subtree.

Here my own knowledge of the details goes hazy. I'm not sure if one media key is encrypted multiple ways using keys from different subtrees, or if multiple copies are encrypted using different subtrees/keys, but I do know that the decryption process keeps trying, cycling through different decryption attempts until it reaches an end. It's only after it gets to the end and hasn't gotten a valid decrypted answer, that it can conclude its own set of device keys has been revoked.

FoxDisc

16th February 2007, 16:09

Yes, arnezami calculated the VUK for Talladega Nights (BluRay US PS3 version), and it worked. But it was necessary to sniff VolumeID (no mistery here, it works that way).

Thanks, I missed that. I knew the VolumeID was being sniffed, but I also know it's stored on the disc, but not stored in a way that can be copied to a recordable disc. Do you know if it can be read directly, and if not, why not?

I should probably point out to anyone reading this, that I'm much like Professor Felton and the "Freedom to Tinker" guys. I'm simply interested in fair use, crypto, copyright and the social effects of the battle between those who are in favor of DRM and those who are opposed. I find this thread particularly interesting - pitting the most advanced and expensive DRM crypto system ever implemented against the real world of people who want to enjoy their fair use rights by watching their discs on Linux based systems or systems that have everything except HDCP.

xyz987

16th February 2007, 16:31

Thanks, I missed that. I knew the VolumeID was being sniffed, but I also know it's stored on the disc, but not stored in a way that can be copied to a recordable disc. Do you know if it can be read directly, and if not, why not?

VolumeID is stored in an especial area of disk, and it can not be directly read (except if you have a device with hacked firmware, but nobody has done it yet).

Its purpose is to avoid bit-by-bit (verbatim) home copying of the disk. You can not do a verbatim copy of all the disk because you (supossedly) don't know the VolumeID.

evdberg

16th February 2007, 16:42

Has anyone been able to calculate a title key/volume unique key from the Processing Key?

Yes, the MKB tool that I released can do this.

xyz987

16th February 2007, 16:55

You had exactly the same question I had, and like me, you confused the leaf/node keys in the tree with the device keys and simplified the system way too much. A device key is not a leaf or node key. The tree shown in the AACS system is a tree of node and leaf keys, not a tree of device keys, like you drew. In fact, there is a master tree that starts at the AACSLA root and ends at all devices, but there are other subtrees, that start one down from the root, and two down from the root, etc. These are not subtrees within the master tree, they are separate subtrees that are parallel to the master subtree, with another set of leaf keys and node keys.

Device keys allow you to get the answer when the data is encrypted with anyone elses leaf key or any node key for a node above their leaf that is not also in the path from your own leaf to the root. You can't get the answer when it's encrypted with your own leaf key or any node key above you, at least not for this subtree.

Thanks a lot. This is probably the right view.

guile

16th February 2007, 17:08

Newbish question here. With all 4 of the above (and a VUK), how would this work with the config file in backupbluray?

All I see is a place for title hash and vuk.

Anybody??

FoxDisc

16th February 2007, 17:38

Anybody??

It won't directly work with backupbluray.....yet.

FoxDisc

16th February 2007, 17:57

Yes, the MKB tool that I released can do this.

I'll look at it, but am I right to think you have to give your MKB tool the sniffed volume ID (plus the processing key, which you probably have hard coded in)?

It occurs to me (obvious things sometimes do that :-) that even with a device key, a player would need the volume id to get from the processing key to the media key and on to the title key. So this means the software player can get the volume id, presumably by asking the drive to send it over from the disc. I don't see any reason why hacked firmware or sniffing would be required to get the volume id if the player can get it. Perhaps this has been solved (does your tMKB ool do that?) or there's some part of this that hasn't sunk in yet.

evdberg

16th February 2007, 18:20

I'll look at it, but am I right to think you have to give your MKB tool the sniffed volume ID (plus the processing key, which you probably have hard coded in)?

Yes, you need to provide the Volume ID. Without it, the MKB tool only calculates the Media Key.

It occurs to me (obvious things sometimes do that :-) that even with a device key, a player would need the volume id to get from the processing key to the media key and on to the title key. So this means the software player can get the volume id, presumably by asking the drive to send it over from the disc. I don't see any reason why hacked firmware or sniffing would be required to get the volume id if the player can get it. Perhaps this has been solved (does your tMKB ool do that?) or there's some part of this that hasn't sunk in yet.

You need to 'sniff' the Volume ID, because you need a trusted connection with the drive before the drive will send it over. To setup a trusted connnection with the drive you need a Host Certificate which are issued by th AACS-LA. Therefor you need a software player setup that connection. See also my comments on how AnyDVD works.

arnezami

16th February 2007, 18:22

I'll look at it, but am I right to think you have to give your MKB tool the sniffed volume ID (plus the processing key, which you probably have hard coded in)?

It occurs to me (obvious things sometimes do that :-) that even with a device key, a player would need the volume id to get from the processing key to the media key and on to the title key. So this means the software player can get the volume id, presumably by asking the drive to send it over from the disc. I don't see any reason why hacked firmware or sniffing would be required to get the volume id if the player can get it. Perhaps this has been solved (does your tMKB ool do that?) or there's some part of this that hasn't sunk in yet.
You need the Private Host Key (+Certificate) for that. Otherwise your drive won't give away the Volume ID.

In principe: to decrypt a disc you need two things: Device Keys and a Private Host Key (+Certificate).

We can replace the Device Keys with one Processing Key but we still need the Private Host Key to give us the Volume ID. Otherwise we have to sniff it (or guess it etc)

SBeaver

16th February 2007, 18:48

You need the Private Host Key (+Certificate) for that. Otherwise your drive won't give away the Volume ID.

In principe: to decrypt a disc you need two things: Device Keys and a Private Host Key (+Certificate).

We can replace the Device Keys with one Processing Key but we still need the Private Host Key to give us the Volume ID. Otherwise we have to sniff it (or guess it etc)

how many bytes is this host key certificate as sent to the drive?

FoxDisc

16th February 2007, 19:37

Yto decrypt a disc you need two things: Device Keys and a Private Host Key (+Certificate).

Thank you! It's starting to make sense now. I've gone back to the specs and read the 29 steps for drive authentication (Section 4.3) followed by the 6 step protocol for delivery of the volume id (Section 4.4). This also filled in some questions I had about the drive revocation list and the host revocation list. It also filled in why you were asking about bus encryption.

Someone asked about size - Section 4.2 seems to say the whole host certificate data block is 92 bytes long. The Host ID is 8 bytes, the key is 40 bytes and the signature is 40 bytes.

SvT

16th February 2007, 20:33

Regarding the reported attacks on 2/13/2007, AACS has confirmed that an additional key (called a “processing key”) has been published on public websites without authorization. This is a variation of the previously reported attack (a compromise of a specific implementation) on one or more players sold by AACS licensees. Although a different key was extracted, this represents no adverse impact on the ability of the AACS ecosystem to address the attack. All technical and legal measures applicable to the previously reported attack will be applicable against this attack as well.

:helpful:

Sorry to go "Off Topic" I thought it was about "Processing Key, Media Key and Volume ID found!!!". so i added this artical about this thread.

blutach

16th February 2007, 23:10

Anybody??
I know this is a busy thread, but bumping posts is against forum rules. You've been around long enough to know this.

Please read the rules carefully and observe them in the future.

Regards

blutach

16th February 2007, 23:13

Regarding the reported attacks on 2/13/2007, AACS has confirmed that an additional key (called a “processing key”) has been published on public websites without authorization. This is a variation of the previously reported attack (a compromise of a specific implementation) on one or more players sold by AACS licensees. Although a different key was extracted, this represents no adverse impact on the ability of the AACS ecosystem to address the attack. All technical and legal measures applicable to the previously reported attack will be applicable against this attack as well.

:helpful:And this adds what to the discussion? Stay on topic please!

Regards

guile

17th February 2007, 02:53

I know this is a busy thread, but bumping posts is against forum rules. You've been around long enough to know this.

Please read the rules carefully and observe them in the future.

Regards

Please pardon that bit of "self indulgence" with the bump. I was up late last night extracting blu keys and just wanted some confirmation.

g

KenD00

17th February 2007, 17:38

You need to 'sniff' the Volume ID, because you need a trusted connection with the drive before the drive will send it over.

Well, this seems to be only the half truth. According to the AACS-Spec, the upper half of the VolumeID is stored on the disc in the BCA, the lower half in a Copyright Data Section of the Control Data Zone in the disc Lead-In in a manner described in the AACS HD DVD and DVD Pre-recorded Book, Confidential Part. The AACS-Spec defines extenions to the Mt. Fuji Protocol and indeed, these extensions (except the one to read the P-MKB) require the ACCS-Authentication.
I wanted to verify that and send these commands to the drive, so i've read the MMC-6 draft to get the missing information to do that and i found out something interesting. You can read the BCA and the Copyright Data Section of the disc directly with MMC-6 commands, and these commands do not require the AACS-Authentication! I've tested that and it works, but somehow only partially. I got the BCA with the first half of the VolumeID, but everything i got from the Copyright Data Section was zero. I could also read the Copyright Protection Information from the Control Data Section but i dont know whats this for.

If someday sniffing won't work anymore this would at least reduce the brute force amount to 48 bit, but thats still quite much.

:rolleyes:

SBeaver

17th February 2007, 17:47

Well, this seems to be only the half truth. According to the AACS-Spec, the upper half of the VolumeID is stored on the disc in the BCA, the lower half in a Copyright Data Section of the Control Data Zone in the disc Lead-In in a manner described in the AACS HD DVD and DVD Pre-recorded Book, Confidential Part. The AACS-Spec defines extenions to the Mt. Fuji Protocol and indeed, these extensions (except the one to read the P-MKB) require the ACCS-Authentication.
I wanted to verify that and send these commands to the drive, so i've read the MMC-6 draft to get the missing information to do that and i found out something interesting. You can read the BCA and the Copyright Data Section of the disc directly with MMC-6 commands, and these commands do not require the AACS-Authentication! I've tested that and it works, but somehow only partially. I got the BCA with the first half of the VolumeID, but everything i got from the Copyright Data Section was zero. I could also read the Copyright Protection Information from the Control Data Section but i dont know whats this for.

If someday sniffing won't work anymore this would at least reduce the brute force amount to 48 bit, but thats still quite much.

:rolleyes:

Very good to hear, still depends on having the processing key which they might take away but it could end up being a safe solution for a long time.
Someone should really try to hack a firmware to accept any host certificate it gets and just allow the volume key to be read regardless.
That way there isn't even the slightest chance that any backup app based on processing key might be illegal because of use of stolen host certificates.

arnezami

17th February 2007, 21:19

Well, this seems to be only the half truth. According to the AACS-Spec, the upper half of the VolumeID is stored on the disc in the BCA, the lower half in a Copyright Data Section of the Control Data Zone in the disc Lead-In in a manner described in the AACS HD DVD and DVD Pre-recorded Book, Confidential Part. The AACS-Spec defines extenions to the Mt. Fuji Protocol and indeed, these extensions (except the one to read the P-MKB) require the ACCS-Authentication.
I wanted to verify that and send these commands to the drive, so i've read the MMC-6 draft to get the missing information to do that and i found out something interesting. You can read the BCA and the Copyright Data Section of the disc directly with MMC-6 commands, and these commands do not require the AACS-Authentication! I've tested that and it works, but somehow only partially. I got the BCA with the first half of the VolumeID, but everything i got from the Copyright Data Section was zero. I could also read the Copyright Protection Information from the Control Data Section but i dont know whats this for.

If someday sniffing won't work anymore this would at least reduce the brute force amount to 48 bit, but thats still quite much.

:rolleyes:
This is good stuff :). Very very interesting. I don't know if this is easy but could you make the method/source available for sending these commands. So other programmers can try/experiment themselves (on other drives etc).

Which drive did you use btw?

Also: have you also tried this on a re-writable?

Regards,

arnezami

brand1130x

17th February 2007, 22:57

tehehe ... fox delays dozens of blu ray releases for BD+ ... check at techspot.com

blutach

18th February 2007, 00:18

@brand1130x

You seem not to be even aware of the last few posts I have made in this thread. I know you are new, but this item is hardly even worthy of a post in the news forum.

Read our rules please, especially the one about staying on focus (R3).

Regards

pedrito

18th February 2007, 00:52

Sure ... if you explain me how you can read a HD-DVD using the Xbox-360 drive on the Mac?

Er… I guess the outcome, but did you try "Ignore", manually opening the DVD Player application, going to menu File > Open DVD Media and browsing to any HVDVD_TS folder that might appear on the disc (which I guess is the showstopper, but I cannot check that)?

tonyp12

18th February 2007, 00:55

reduce the brute force amount to 48 bit, but thats still quite much.

That is 6 bytes that can be 0-255, does not sound to bad.

So 256*256*256*256*256*256 = 281,474,976,710,656 possible combinations.

That is 281.5 Trillion, if you can test a million key a second
it would still take 9 years !!!

KenD00

18th February 2007, 05:31

I don't know if this is easy but could you make the method/source available for sending these commands. So other programmers can try/experiment themselves (on other drives etc).

There is no secret about that, you even don't need to be a programmer to do that. First, you should read the MultiMedia Command Set - 6 (MMC-6) (http://www.t10.org/ftp/t10/drafts/mmc6/mmc6r00.pdf) to know how to build a CDB for the READ DISC STRUCTURE command. Then you can use DVDInfoPro to construct custom commands and send them to the drive. Works quite good, but this program cannot handle more than 4 KB of returned data. I'm not familiar with the windows API and how to access the HD-Drive, so i looked around and found CDToImg 1.01 posted at the CDFreaks forum. I modified the source and the result is a quick hack that writes the BCA and Copyright Data Section to file, i've attached this proggy with source if someone wants to play around with it.

Which drive did you use btw?

Also: have you also tried this on a re-writable?

This method does only work with HD-DVD, Blu-Ray stores the VolumeID somewhere else. I've done it with my XBox 360 HD-Drive, haven't seen any HD writables yet.

:rolleyes:

Multiplex

18th February 2007, 07:12

don't know if this is easy but could you make the method/source available for sending these commands. So other programmers can try/experiment themselves (on other drives etc).

Microsoft's Windows Driver Kit, SPTI example is the starting point to learn to talk to the drive directly from Win32 programs. It's not very hard and it doesn't require writing a driver.

MMC6 is a beast, but it contains just about everything you need to learn what commands to use. Like KenD00 said, there are many tools that allow you to send a command or two.

arnezami

18th February 2007, 08:33

There is no secret about that, you even don't need to be a programmer to do that. First, you should read the MultiMedia Command Set - 6 (MMC-6) (http://www.t10.org/ftp/t10/drafts/mmc6/mmc6r00.pdf) to know how to build a CDB for the READ DISC STRUCTURE command. Then you can use DVDInfoPro to construct custom commands and send them to the drive. Works quite good, but this program cannot handle more than 4 KB of returned data. I'm not familiar with the windows API and how to access the HD-Drive, so i looked around and found CDToImg 1.01 posted at the CDFreaks forum. I modified the source and the result is a quick hack that writes the BCA and Copyright Data Section to file, i've attached this proggy with source if someone wants to play around with it.

This method does only work with HD-DVD, Blu-Ray stores the VolumeID somewhere else. I've done it with my XBox 360 HD-Drive, haven't seen any HD writables yet.

:rolleyes:
Thanks! :)

I've tried it on my drive and it indeed gives back the bca (media id + half of volume id). cda is 60 kb of zeros (and it then hangs with me, but thats probably my system acting up or something) so that seems to be protected. This could be a useful little tool to experement with (especially to try to make the AACS-auth getting to work ;)).

Btw: its pretty incredible that a carefully thought of encryption system (with strong certs/private/public keys) is now reduced to at worst a 48-bit guessing game. Somebody should feel very ashamed. I wonder if all HD DVD drives do this.

arnezami

18th February 2007, 09:33

Some general remarks:

As you have probably seen by now I've been very busy writing my AACS explanation. This way everybody (including programmers) now know much better how things work.

The sample source I gave in this thread should in principle work for both HD DVD and BD. The mkb tool from evdberg actually works and (when he releases his source) other programmers can do the same in any language they see fit.

Currently I'm not sure which direction I want to go. It depends on what others are willing/can do. I believe somebody should extend/make a program like evdberg and make it more user friendly. Also since we can guess most Volume IDs (for HD DVD) somebody could extend it by first reading the disc name and the date of the files created on it. From that it could try guessing Volume IDs (pretty quick) with a fairly good change of succeeding. Meaning we would be able to make a key extractor for most HD DVDs without the need of a software player! We could also make a program that extracts Volume IDs from the memory of software player (for HD DVD/BD but to do this properly this requires some knowledge of entropy measurement or a another way of doing this reliably) And we could also make a Volume ID sniffer (USB or even IDE for BD internal burners etc) which will be very useful in the future too :).

These are all kinds of programs that could be build. I'm probably capable of creating them but I would like to concentrate on making the AACS-auth (+Host Cert/private key) work. This would really allow a independent player/decrypter (on any platform/OS). I also hope others will join in this quest. ;)

I only have a limited amount of time to spent. I can't do this alone. So please don't expect me to.

Regards,

arnezami

arnezami

18th February 2007, 12:48

Well, this seems to be only the half truth. According to the AACS-Spec, the upper half of the VolumeID is stored on the disc in the BCA, the lower half in a Copyright Data Section of the Control Data Zone in the disc Lead-In in a manner described in the AACS HD DVD and DVD Pre-recorded Book, Confidential Part. The AACS-Spec defines extenions to the Mt. Fuji Protocol and indeed, these extensions (except the one to read the P-MKB) require the ACCS-Authentication.
I wanted to verify that and send these commands to the drive, so i've read the MMC-6 draft to get the missing information to do that and i found out something interesting. You can read the BCA and the Copyright Data Section of the disc directly with MMC-6 commands, and these commands do not require the AACS-Authentication! I've tested that and it works, but somehow only partially. I got the BCA with the first half of the VolumeID, but everything i got from the Copyright Data Section was zero. I could also read the Copyright Protection Information from the Control Data Section but i dont know whats this for.

If someday sniffing won't work anymore this would at least reduce the brute force amount to 48 bit, but thats still quite much.

:rolleyes:

OK. I just realized something here. When using your proggy it hanged (as I said). But what is more interesting is where it hanged: it stopped at position F000h of the Copyright Data Section.

Now look at the HD DVD docs:

http://img64.imageshack.us/img64/7572/leadincdsbf0.png

Now if you didn't have this "hanging" problem (probably the time out acting up in my case, possibly caused by my OS) with your drive/OS then I would really like to know whats in your part of the cds.bin file at F000h through FFFFh (if anything). It could potentially contain the second half of the Volume ID encoded in a "Confidential way". Have you looked at this part?

Btw: others can try this too. :)

If there is anything there please also post the Volume ID of the disc used so we can see if/how its encoded.

Regards,

arnezami

[edit] Hmmm. I'm starting to get a little confused about what this cds (that is extracted) really is when looking at the docs. things don't seem to match...

evdberg

18th February 2007, 15:02

I also tried to read the CDS with my own software, but it always fails with no sense key data. Maybe that is the reason you get only zeros? Because the command fails and the buffer was already initialized with zeros? Reading the BCA is no problem however, that works perfectly fine.

KenD00

18th February 2007, 15:51

Following illustrates what is written into cds.bin:

http://img299.imageshack.us/img299/1724/dumpvidinforesizednk7.png

The Control Data Zone is 192 ECC blocks big. Each ECC block contains 32 Sectors. In this picture 1 Data Segment is 1 ECC block. The 16 Data Segments per Control Data Section and Copyright Data Section should be all the same, says the AACS-Spec. However, there are two of these sections, it is not mentioned if these sections are the same too. With the MMC-Commands you cannot specify which of these sections to read, you also cannot specify which of the 16 Data Segments you want to read. You can only specify at which sector to start reading from.
One read can return at most 31 sectors. Therefor i'm issuing two reads to get the 32 sectors, your filesize looks like the second read fails. In very rare cases the read commands fail on my machine too, but then i get a CHECK CONDITION error message and the program ends, it does not hang. I think the program does not hang, it is just waiting the maximum of 30 minutes until the read command completes. And there is actually data returned, the Disc Structure Data Length field states the correct size, but everything behind that is zero. I'm stripping this header when writing to file, thats why everything is zero.

:rolleyes:

arnezami

18th February 2007, 16:32

Following illustrates what is written into cds.bin:

[image]

The Control Data Zone is 192 ECC blocks big. Each ECC block contains 32 Sectors. In this picture 1 Data Segment is 1 ECC block. The 16 Data Segments per Control Data Section and Copyright Data Section should be all the same, says the AACS-Spec. However, there are two of these sections, it is not mentioned if these sections are the same too. With the MMC-Commands you cannot specify which of these sections to read, you also cannot specify which of the 16 Data Segments you want to read. You can only specify at which sector to start reading from.
One read can return at most 31 sectors. Therefor i'm issuing two reads to get the 32 sectors, your filesize looks like the second read fails. In very rare cases the read commands fail on my machine too, but then i get a CHECK CONDITION error message and the program ends, it does not hang. I think the program does not hang, it is just waiting the maximum of 30 minutes until the read command completes. And there is actually data returned, the Disc Structure Data Length field states the correct size, but everything behind that is zero. I'm stripping this header when writing to file, thats why everything is zero.

:rolleyes:

Thanks a lot! :) That clears up things for me. I guess there is really no information on the second half of the Volume ID there. Ok.

I guess here lies the problem ;):

http://img175.imageshack.us/img175/6144/15hra1.png

Btw: after a clean install of XP it works so there was clearly a problem on my side.

Regards,

arnezami

arnezami

18th February 2007, 17:16

Since we now have the ablity to read the first 8 bytes of the volume ID it gets even easier to guess the other 8 bytes:

Constantine 05/12/2006 5:05
Hex: 40 00 30 06 53 05 16 11 57 47 48 44 56 4d 00 00
Ascii: W G H D V M

MI3 10/03/2006 15:34
Hex: 40 00 20 06 10 03 07 19 00 20 20 20 20 20 00 00

Looking at these two types we can simply try the two possible different 6 bytes. Check if the resulting VUK with the MAC in the Title Key File and if its correct we know it was one of these two types of Volume ID. My feeling is this amounts to more than 50-70% of all HD DVDs.

Swordfish 04/15/2006 2:10
Hex: 40 00 53 57 4f 52 44 46 49 53 48 20 20 20 00 00
Ascii: S W O R D F I S H

Then we can try the name of the movie/disc (first maybe look if the first 6 chars equal the first 6 chars of the movie) with spaces behind it. By now can decrypt a lot of discs already (with only 3 tries!!). If we don't find it this way (maybe the disc name is slightly different?) we could brute force like 3-4 characters using Capitals only (= 26^4 ~ 450,000 tries). Again: we should test the VUK with the MAC each time.

If this works (and I think it will) we should have like 70-90% of all discs decryptable.

The Matador 10/19/2006 20:41
Hex: 40 00 ba be 00 00 00 00 00 00 00 00 00 1c 00 00

This one I don't know. So far only one found of this kind. We could try 256 different values in the last byte. Don't know.

Rambo: First Blood II
Hex: 40 00 18 54 3b d6 24 9b 59 f3 31 1e 49 ee 00 00

This type we can't guess since its random. We simply instruct the user to extract/sniff the VID.

I think by doing it this way we could make a proggy that decrypts most HD DVDs without the use of WinDVD (Jap) or even a sniffer :).

Anyone who feels like doing it feel free.

Regards,

arnezami

KenD00

18th February 2007, 17:21

I would like to concentrate on making the AACS-auth (+Host Cert/private key) work.

I think you need two things to do that:

1.) A Host Certificate. This can be revoked so it won't work forever. But until they enforce bus encryption everyone can get a new one ;)

Because of that

AACS_Spec_Common_0.91_.pdf

....

12. The drive generates 160 bits random number as nonce Dn
13. The drive sends the nonce Dn generated in step 11 and the Drive Certificate to the host.

...

25. The host creates a digital signature of the concatenation of the nonce Dn received in step 12 and the point
on the elliptic curve Hv calculated in step 22.
Hsig = AACS_Sign(AACS_Hostpriv, Dn || Hv)
26. The host sends the point on the elliptic curve Hv calculated in step 22 and the digital signature Hsig created
in step 23 to the drive.
27. The drive verifies the signature of the concatenation of the nonce Dn and the point on the elliptic curve Hv.
AACS_Verify(AACS_Hostpub, Hsig , Dn || Hv)
If the verification fails, the drive shall determine the host is not compliant and shall abort the drive
authentication procedure.

you need

2.) A Host Private Key. This is hard to get because it does not travel on the bus. But, correct me if i'm wrong, i don't see a mechanism for revoking a Private Key, so this will work forever?

The rest is sending the right commands to the drive.

:rolleyes:

arnezami

18th February 2007, 17:30

I think you need two things to do that:

1.) A Host Certificate. This can be revoked so it won't work forever. But until they enforce bus encryption everyone can get a new one ;)

Because of that

you need

2.) A Host Private Key. This is hard to get because it does not travel on the bus. But, correct me if i'm wrong, i don't see a mechanism for revoking a Private Key, so this will work forever?

The rest is sending the right commands to the drive.

:rolleyes:
Basicly the Certificate "belongs to" the Private Key so if one is revoked the other is too. And you are right the Private Key is the hardest to get ;).

The_ByteMaster

18th February 2007, 18:18

That is 6 bytes that can be 0-255, does not sound to bad.

So 256*256*256*256*256*256 = 281,474,976,710,656 possible combinations.

That is 281.5 Trillion, if you can test a million key a second
it would still take 9 years !!!

...assuming you have just one single processor. But brute-force keyspace searches are almost perfectly scalable. 48 bits encryption is laughable in crypto security terms these days. Even DES which is -in theory- 56 bits (or 8 orders of magnitude more difficult in binary speak) is no challenge at all. Don't worry, if it ever comes down to "cracking" a 48 bit key, this will be done. Either by an open distributed computing effort, or by people who have more means (f.e. admins of a large office network who will let it run after hours).

clsid

18th February 2007, 18:37

Most keys only contain only letters, numbers and spaces. So instead of 256 possible values for each byte, there are only 26x2+10+1=63 values.

63^6 = 62,523,502,209

How long does it approximately take to check a single key? Or how many keys can be checked per second?

hajj_3

18th February 2007, 19:11

i was thinking about a distributed project to crack the key, my core 2 duo is overclocked to 3.7ghz, im sure that would help alot!! 2gb ddr2 ram overclocked to 1000mhz too.

arnezami

18th February 2007, 19:21

i was thinking about a distributed project to crack the key, my core 2 duo is overclocked to 3.7ghz, im sure that would help alot!! 2gb ddr2 ram overclocked to 1000mhz too.

Don't forget what the objective is: making it easier than sniffing or extracting from a Software player. A distributed project clearly is overkill for getting only one Volume ID. Lets keep some perspective here :).

jkenzie

18th February 2007, 21:24

Basicly the Certificate "belongs to" the Private Key so if one is revoked the other is too. And you are right the Private Key is the hardest to get ;).

How many bytes is the Host Private Key?

arnezami

18th February 2007, 21:28

How many bytes is the Host Private Key?

If I remember correctly that would be 40 bytes (or 320 bits if you will). All ECDSA (ellipictic curve DSA).

jkenzie

18th February 2007, 21:34

If I remember correctly that would be 40 bytes (or 320 bits if you will). All ECDSA (ellipictic curve DSA).
That’s encouraging, any way to verify if it's correct or not?

evdberg

18th February 2007, 21:40

That’s encouraging, any way to verify if it's correct or not?

Actually a plain-text-attack should work ... since we know the public key, we can try out all keys from a memory dump as private key, just like musix64 found his first titlekey. Only difference is that ECDSA is quite slow ...

KenD00

18th February 2007, 23:31

Basicly the Certificate "belongs to" the Private Key so if one is revoked the other is too.

I should have read the spec more closely, the certificate contains the Drive Public Key, so a Drive Private Key only works with its Certificate. And funny things like changing the HostID to circumvent revocation does not work because the complete Certifcate is signed with AACS_LApriv :(.

Most keys only contain only letters, numbers and spaces.

I'm sure the people at the AACS LA have internet too, so i bet they will kick all their licensees in their b*tts to not use this scheme any more.

Looking for an alternative way to get the VolumeID i asked myself what happens when i hammer the drive with VolumeID requests, using every possible AGID, when a software player performs the AACS-Authentication? Well, i've tested that and the answer is: the drive gives you the VolumeID :)!!

But depending on your software player the timing is very tricky:

Your favorite software player A:
Start the hammering, start the software player, hit "play", wait a few seconds, receive a VolumeID :)

Your favorite software player B:
Don't dare to start the hammering until you pressed "play", then, if you start too early, the player simply stops. If you start too late, you miss the present. My advice: use software player A ;)

This method should also work on Blu-Ray, you just need to change the media type code in the CDB.

I've attached a new Version of DumpVID with hammering support (no Blu-Ray support!).

:rolleyes:

arnezami

19th February 2007, 05:53

Looking for an alternative way to get the VolumeID i asked myself what happens when i hammer the drive with VolumeID requests, using every possible AGID, when a software player performs the AACS-Authentication? Well, i've tested that and the answer is: the drive gives you the VolumeID :)!!

But depending on your software player the timing is very tricky:

Your favorite software player A:
Start the hammering, start the software player, hit "play", wait a few seconds, receive a VolumeID :)

Your favorite software player B:
Don't dare to start the hammering until you pressed "play", then, if you start too early, the player simply stops. If you start too late, you miss the present. My advice: use software player A ;)

This method should also work on Blu-Ray, you just need to change the media type code in the CDB.

I've attached a new Version of DumpVID with hammering support (no Blu-Ray support!).

:rolleyes:
I love it!! :D :D :D

Maybe we can "automate" the timing somehow or see what is the difference in commands to the drive (between Player A and B) what makes it stopping from working... (how does it "feel" there is something wrong?) Maybe less hammering more "precise bombing"? Maybe some playing around with AGIDs before it all starts?

But anyway its fantastic. Its another alternative method of retrieving the Volume ID! :)

(A = PowerDVD it seems...)

Btw: now that I think about it it makes perfect sense it gives away the VolumeID: the MMC command sent to the drive doesn't contain any authentification information (like a Bus-MAC). This done by the Software Player beforehand (AACS-Auth). And the drive simply thinks you are the Player!! There is only an AGID (0-3) to try. So this will always work :) (its another fundamental flaw in the system: as long as there is no Bus encryption this should work and my drive isn't capable of Bus encryption ;), so there are thousands of people with drives not capable of Bus encryption...). This may become the easiest way (apart from the Host Private Key) of getting the VID in the future because it happens outside the Player and doesn't install or change a (detectable) service or driver.

Cool.

arnezami

PS. Not so important but good to know: the cds dumping doesn't work on W2K: it seems to always hang on that OS (and requires a hard reset of the system to shut it down). In XP it also takes one or two seconds (which is long for 64kb) but it does work (well give zeros that is: this is probably the most meaningless command they invented, or does it work after AACS-auth? or after some special secret AACS-auth?).

HyperHacker

19th February 2007, 10:18

The player could detect this program just as it could detect a driver, however, it wouldn't be exceptionally difficult to prevent it from doing either.

I suspect the reason the player reacts poorly is simply because the drive is having two "conversations" at once, and so the player isn't getting the replies it's expecting because some of them are replies to this program. Or, perhaps once the drive has given the volume ID it won't give it again, so the player doesn't get a copy.

Could the program not sniff to tell when the player is communicating, so it knows when to start hammering? Or have a button/command line which automatically starts the player, delays however long, and starts hammering (or vice-versa)?

Geremia

20th February 2007, 00:36

Hi all

first, congrats to all, very interesting reading here :)

just got an xbox360 dvd drive and started playing a little.

firmware: actually unable to know what cpu inside the main big chip, it'a unnamed, no brand, no model number...actually unable to deassemble. If any good firmware hackers out here, pm me to help find the main cpu.

just sniffed usb trafic between drive and powerdvd 7.2, unfortunally the authentication can not be reproduced, because every time i send the same host certificate challenge, i receive different drive certificate challenge and different drive key, then if i send the host key it returns error, so i suppose anydvd has the host private key (i've not sniffed anydvd, are you sure it asks aacs authenitcation to the drive?)
Sniffed drive keys and drive certificate challenge data are not present in firmware, at least not in clear, so i guess the drive has something like a master private key (i'm not cripto specialist, i'm not specialist in nothing, just hobbyst).

I'm using plscsi to send cdb commands, it's nice.

here some example of using plscsi:

plscsi.exe -v -x "A4 00 00 00 00 00 00 02 00 10 00 00" -i x8 // request Authentication Grant ID
plscsi.exe -v -x "A3 00 00 00 00 00 00 02 00 74 01 00" -o x74 -f hostchal1.bin // send host certificate challenge
plscsi.exe -v -x "A4 00 00 00 00 00 00 02 00 74 01 00" -i x74 // request drive certificate challenge
plscsi.exe -v -x "A4 00 00 00 00 00 00 02 00 54 02 00" -i x54 // request drive key
plscsi.exe -v -x "A3 00 00 00 00 00 00 02 00 54 02 00" -o x54 -f hostkey1.bin // send host key

plscsi.exe -v -x "AD 00 00 00 00 00 00 03 00 50 00 00" -i x50 // read BCA

About control data zone, it's hidden from the simple "read" cdb command, the drive forbid you to read negative LBA sectors.

Read command accept positive LBA sectors, LBA sector 0 is PSN (phisical sector number) 30000, so you can't read control data zone that is PSN 2F200-2FDFF, unless you hack the firmware to skip the LBA positive check.
I don't know what Kend00 have tried, anyway the read disc structure - (15h) read Copyright data section works, but output all zeroes :(, at least for kingkong, miami vice and the bourne supremacy.

plscsi.exe -v -x "AD 00 00 00 00 00 00 15 F8 04 00 00" -i xF804 -t CDS.bin

P.S.
i've tried to send read disc structure - read volume ID cdb command when powerdvd plays, but i was not luck.
plscsi.exe -v -x "AD 00 00 00 00 00 00 80 00 24 00 00" -i x24
It seems that the drive does not accept repetition of authentication procedure steps, in fact powerdvd repeats the procedure 3-4 times.
For procedure i mean:
- clear AGID
-request an AGID
-send host certificate challenge
-request drive certificate challenge
- request drive key
- send host key
- read disc structure, volume id (format code 80h) (btw, it seems to not read other stuff here, like pre recorded media serial number or MKB in the leadin)

Geremia

20th February 2007, 15:21

ops, i made some mistake, i'm just learnin on the way :)

The returned drive cetificate is always the same, it's the Nonce that changes everytime ( a random number), and Nonce is necessary for the next step, report key - drive key, but this is not the drive public key(which is inside the previous challenge), it's a signed (with drive private key) info for the host to calculate the bus key.

Anydvd must know the powerdvd private key to be able to sign the send key - drive key cdb command (and also must have the helliptic curve of whatever it is)

Into firmware, there is no visible drive ID or drive public key

KenD00

20th February 2007, 16:14

the cds dumping doesn't work on W2K: it seems to always hang on that OS (and requires a hard reset of the system to shut it down). In XP it also takes one or two seconds (which is long for 64kb) but it does work (well give zeros that is: this is probably the most meaningless command they invented, or does it work after AACS-auth? or after some special secret AACS-auth?).

Perhaps the second half of the VolumeID is stored like SafeDisc or SecuROM store their "digital signatures", corrupt a few sectors here and there. Maybe because of that it takes so long to read this area, any maybe because of that the storage method is described in the confidental part of the spec ;).

@arnezami, HyperHacker
This timing stuff depends on the player and maybe on the system, now only one software player makes trouble, maybe this "feature" will spread. These ideas like monitoring the player, prevent the detection of the prog, are beyond my knowledge, also i was looking for a more independend way to get the VID, i discovered this method by accident when probing fancy ideas. I won't go further this way and will concentrate on my "use of keys" application, not the "get of keys" way.

:rolleyes:

jqr

20th February 2007, 17:10

Congratulations :-)

And yes, there is demand ;-)

:thanks:

Well I was just reading this thread when I was linking to a blog post I wrote and I thought I might mention I have actually made an attempt to explain the subset-difference algorithm here (http://www.jquirke.com.au/index.php/2007/02/12/aacss-subset-cover-scheme-explained/). Hope it is of at least some help.

arnezami

20th February 2007, 18:27

Well I was just reading this thread when I was linking to a blog post I wrote and I thought I might mention I have actually made an attempt to explain the subset-difference algorithm here (http://www.jquirke.com.au/index.php/2007/02/12/aacss-subset-cover-scheme-explained/). Hope it is of at least some help.

Thanks :) I will read it.

Here you can read my explanation:

Understanding AACS (including Subset-Difference) (http://forum.doom9.org/showthread.php?t=122363)

Regards,

arnezami

Geremia

20th February 2007, 20:28

Perhaps the second half of the VolumeID is stored like SafeDisc or SecuROM store their "digital signatures", corrupt a few sectors here and there. Maybe because of that it takes so long to read this area, any maybe because of that the storage method is described in the confidental part of the spec ;).

// Allocation length for the return buffer, the maximum is 63488
sptd_sb.sptd.Cdb[8] = 0xF8;
sptd_sb.sptd.Cdb[9] = 0x02;
// No AGID
sptd_sb.sptd.Cdb[10] = 0;
// Control is 0, don't know whats this for
sptd_sb.sptd.Cdb[11] = 0;
// Zero the rest of the structure
sptd_sb.sptd.Cdb[12] = 0;
sptd_sb.sptd.Cdb[13] = 0;
sptd_sb.sptd.Cdb[14] = 0;
sptd_sb.sptd.Cdb[15] = 0;

ZeroMemory(data_buf, 63492);
ZeroMemory(sptd_sb.SenseBuf, MAX_SENSE_LEN);

If i'm not wrong, you send cdb command to retrieve FB02h bytes (including response header) but you expect FB04h (63492) bytes back
The correct value for the cdb is FB04 because you will have 4bytes oh header (2 bytes of lenght + 2bytes reserved)

plscsi.exe -v -x "AD 00 00 00 00 00 00 15 F8 04 00 00" -i xF804 -t dump.bin

these sectors are readable, because you don't get sense error, but presumibly the drive firmware doesn't output any data for us unauthenticated people.
The maximum data to retrieve is 63488=31 sectors, so the last sector is out, but even if you read it, it's the same all zeroes.

Geremia

20th February 2007, 21:06

awhitehead

20th February 2007, 22:38

I am providing these for four different movies: Full Metal Jacket, Rambo I, Rambo II and Rambo III.

Volume ID for Full Metal Jacket is:

TransferBufferMDL = 83b06f88
00000000: 00 22 00 00 40 00 46 55 4c 4c 4d 45 54 41 4c 4a
00000010: 41 43 00 00 xx xx xx xx xx xx xx xx xx xx xx xx
00000020: xx xx xx xx
UrbLink = 00000000
[56868 ms]

For Rambo movies VIDs and VUKs are here:
http://forum.doom9.org/showpost.php?p=955567&postcount=191

sectors.rar file contains the .bin files corresponding to the following session (My drive is also on letter I: (and plscsi -w seems to agree)):

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Administrator>cd Desktop

C:\Documents and Settings\Administrator\Desktop>set PLSCSI=\\.\I:

C:\Documents and Settings\Administrator\Desktop>plscsi.exe -v -x "AD 00 00 00 00 00 00 1
5 08 04 00 00" -i x804 -t FULLMETAL.bin
x 00000000 AD 00 00:00:00:00 00 15:08:04:00 00 .. .. .. .. "-@@@@@@UHD@@"
x 00000000 F8:02:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "xB@@@@@@@@@@@@@@"
x 00000010 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
...
x 000007F0 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
x 00000800 00:00:00:00 .. .. .. .. .. .. .. .. .. .. .. .. "@@@@"
// 0 = plscsi.main exit int

C:\Documents and Settings\Administrator\Desktop>plscsi.exe -v -x "AD 00 00 00 00 00 00 1
5 08 04 00 00" -i x804 -t RAMBO3.bin
x 00000000 AD 00 00:00:00:00 00 15:08:04:00 00 .. .. .. .. "-@@@@@@UHD@@"
x 00000000 F8:02:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "xB@@@@@@@@@@@@@@"
x 00000010 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
...
x 000007F0 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
x 00000800 00:00:00:00 .. .. .. .. .. .. .. .. .. .. .. .. "@@@@"
// 0 = plscsi.main exit int

C:\Documents and Settings\Administrator\Desktop>plscsi.exe -v -x "AD 00 00 00 00 00 00 1
5 08 04 00 00" -i x804 -t RAMBO2.bin
x 00000000 AD 00 00:00:00:00 00 15:08:04:00 00 .. .. .. .. "-@@@@@@UHD@@"
x 00000000 F8:02:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "xB@@@@@@@@@@@@@@"
x 00000010 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
...
x 000007F0 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
x 00000800 00:00:00:00 .. .. .. .. .. .. .. .. .. .. .. .. "@@@@"
// 0 = plscsi.main exit int

C:\Documents and Settings\Administrator\Desktop>plscsi.exe -v -x "AD 00 00 00 00 00 00 1
5 08 04 00 00" -i x804 -t RAMBO1.bin
x 00000000 AD 00 00:00:00:00 00 15:08:04:00 00 .. .. .. .. "-@@@@@@UHD@@"
x 00000000 F8:02:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "xB@@@@@@@@@@@@@@"
x 00000010 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
...
x 000007F0 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
x 00000800 00:00:00:00 .. .. .. .. .. .. .. .. .. .. .. .. "@@@@"
// 0 = plscsi.main exit int

C:\Documents and Settings\Administrator\Desktop>

Looking at the resulting .bin files in winhex, I see that with exception of the two bytes at the beginning of .bin files, the files are full of nulls.

Geremia

21st February 2007, 01:18

thanks

so, the second half of the volume id is not in that sectors, or better, not in the data portion of that sectors, maybe it's in what CPR_MAI field is for dvd-rom secotrs (6bytes of data before the 2048 data bytes), but i don't know the phisical structure of hd-dvd (does anyone has the not public hd-dvd phisical book?), and anyway an hacked firmware is needed for a raw reading.

HyperHacker

21st February 2007, 02:10

Read command accept positive LBA sectors, LBA sector 0 is PSN (phisical sector number) 30000, so you can't read control data zone that is PSN 2F200-2FDFF, unless you hack the firmware to skip the LBA positive check.
Is there a way you could exploit integer overflow? E.g. attempt to read sector 0x10002F200?

frogman

21st February 2007, 07:31

Hey, just sniffed my 3 movie, all from universal pictures
kingkong
the bourne supremacy
miami vice

in sniff dump, the volumeID has first 8 bytes 40 00 date and time, the next 8 bytes are 00 20 20 20 20 20 00 00

all the movie has copyright data section all zeroes, maybe it's ok like this, the second part is filled with 20 because no data in the CDS

Can anyone try to read control data segment from a movie that has a complete 16byte volume ID?

just the first sector should be enought

get plscsi here http://members.aol.com/plscsi/2002/09/22/win/plscsi.exe

Here's what I got. xbox 360 hd external drive with King Kong usa in F: Drive

plscsi.exe -v -x "AD 00 00 00 00 00 00 15 08 04 00 00" -i x804 -t CDS.bin
x 00000000 AD 00 00:00:00:00 00 15:08:04:00 00 .. .. .. .. "-@@@@@@UHD@@"
x 00000000 F8:02:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "xB@@@@@@@@@@@@@@"
x 00000010 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
...
x 000007F0 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
x 00000800 00:00:00:00 .. .. .. .. .. .. .. .. .. .. .. .. "@@@@"
// 0 = plscsi.main exit int

Hope this helps.

KenD00

21st February 2007, 16:55

If i'm not wrong, you send cdb command to retrieve FB02h bytes (including response header) but you expect FB04h (63492) bytes back

Yeah, indeed, im missing 2 bytes. Well, two zeros more or less ... ;)

all the movie has copyright data section all zeroes, maybe it's ok like this, the second part is filled with 20 because no data in the CDS

Can anyone try to read control data segment from a movie that has a complete 16byte volume ID?

Your VolumeID is complete, its missing nothing.

Is there a way you could exploit integer overflow?
As far as i know LBA is unsigned so there is no way.

I think enough people have proven that you only get zeros from the Copyright Data Section, no need for more proofs.
So there seems to be no way to get the second half of the VID directly off the disc without a hacked firmware, but why you want to read the sectors raw, why don't modify the drive to give it away without beeing authentified ;)?

:rolleyes:

Deity11

21st February 2007, 18:19

The Matador 10/19/2006 20:41
Hex: 40 00 ba be 00 00 00 00 00 00 00 00 00 1c 00 00

This one I don't know. So far only one found of this kind. We could try 256 different values in the last byte. Don't know.

Maybe it's just the 28th release?

Geremia

21st February 2007, 20:16

but why you want to read the sectors raw, why don't modify the drive to give it away without beeing authentified ;)?

hehehe, yes it's for sure the easyest way in theory, problem actually is to know what cpu is inside the main chip.

evdberg

21st February 2007, 21:09

I think enough people have proven that you only get zeros from the Copyright Data Section, no need for more proofs.

Actually, as I already wrote earlier, the function just fails without sense error. The zeros are there because the buffer is cleared before calling the function.

mb2696

22nd February 2007, 01:35

Babel 12/19/06 21:54:12
Vid: 40 00 20 06 12 19 05 35 00 20 20 20 20 20 00 00

The "20 06 12 19" is clearly the date, but I'm not sure what to make of the "05 35 00"

Punqtured

22nd February 2007, 13:49

Babel 12/19/06 21:54:12
Vid: 40 00 20 06 12 19 05 35 00 20 20 20 20 20 00 00

The "20 06 12 19" is clearly the date, but I'm not sure what to make of the "05 35 00"

Most likely, it's just the time of creation, like some of the others reported.

mb2696

22nd February 2007, 15:29

Most likely, it's just the time of creation, like some of the others reported.

Time of file creation is 21:54:12. Is there another time involved?

mb2696

22nd February 2007, 18:43

Four Brothers
05/15/2006 - 18:46:24
vid: 40 00 05 15 20 06 03 50 00 20 20 20 20 20 00 00

Note that Four Brothers and Babel are both Paramount titles, and that the vids are pretty similar.

40 00 YY YY MM DD 05 35 00 20 20 20 20 20 00 00 - babel

40 00 MM DD YY YY 03 50 00 20 20 20 20 20 00 00 - four bros

Those three bytes seem simple but i dont see a pattern, as they don't appear to be file creation times:

18:46:24 - babel
21:54:12 - four bros

>>>If anyone has any other Paramount titles, please post the VIDs and lets see if we can figure out this scheme.

lightshadow

22nd February 2007, 18:56

firmware: actually unable to know what cpu inside the main big chip, it'a unnamed, no brand, no model number...actually unable to deassemble. If any good firmware hackers out here, pm me to help find the main cpu.
If I recall correct then the XBox360 firmware hack all started by people posted photos of their drives PCB's where the chips could be seen.

Perhaps it would be a good idea to do there same here? There might be someone that can regonize the chip either based on the number of pins, or commen used components used in conjuction with that chip?

mb2696

22nd February 2007, 19:35

there are 2 barcodes near the inner hub of the disc. is this the "burst cutting area"? Could those two be the "prerecorded serial number" and first half of the VID?

KenD00

22nd February 2007, 23:46

Actually, as I already wrote earlier, the function just fails without sense error. The zeros are there because the buffer is cleared before calling the function.

But i do not get all zero, the first two bytes contain the correct Disc Structure Data Length. For a test, i initialized the whole buffer with 0xFF, and again, the same result, correct Disc Structure Data Length, the rest all zero.
Also the here posted results show the correct Disc Structure Data Length.

:rolleyes:

lightshadow

23rd February 2007, 05:14

there are 2 barcodes near the inner hub of the disc. is this the "burst cutting area"? Could those two be the "prerecorded serial number" and first half of the VID?
This reminds me of a disc layout image from the XBox360 firmware hack, where the different sections of the DVD was labeled.

The original thread is here (http://www.xboxhacker.net/index.php?topic=76.0), (42 pages of how the firmware was hacked), but I can't find this image right now=(

At this (http://wiki.free60.org/DVD) wiki there are the bar code of the XBox DVD. The reason they tried cover up the inner DVD section was to test if the disc contained any important information there. E.g. in our case, this could be the VID that was hidden there?

There was made a wiki of all the facts and speculations, and I think it is this one (http://wiki.free60.org/Documentation), or atleast part of it.

One of the things that speeded the XBox360 firmware hack a great deal up, was that the model numbers on the chip could be looked up, and deassembing could be done.

It seams that they have read the thread in great detail, and learned that removing this information would cause trouble.

The thread contains a lot of "I hope they didn't do that, because that would make it harder" and "why didn't they do that, because that would make it harder".

Taking in consideration that they removed the chip model numbers, I bet searching for the above techniques, will pay off. Depending on how you read it, it is either a guide on how to hacked the firmware or a guide on how to make your next firmware better.

Also, seaching for patents helped out hacking the firmware a lot, as a patent is more or less the specifiation. Google have just opened a patent search engine (http://www.google.com/ptshp), but I don't know if it is complete?

So if you ask me, these issues have to be resolved:

Post photos of PCB's, chips and surrounding components
Search for HD-DVD and Blue-Ray related patents.
Read the XBox360 firmware hack thread and find all "i hope they didn't..." and "why didn't they..."
Make a wiki with facts and speculations, so nothing is lost or forgotten.
Test if the inner section of the discs hold important information, be putting tape on it.

arnezami

5th March 2007, 21:38

Looking for an alternative way to get the VolumeID i asked myself what happens when i hammer the drive with VolumeID requests, using every possible AGID, when a software player performs the AACS-Authentication? Well, i've tested that and the answer is: the drive gives you the VolumeID :)!!

But depending on your software player the timing is very tricky:

Your favorite software player A:
Start the hammering, start the software player, hit "play", wait a few seconds, receive a VolumeID :)

Your favorite software player B:
Don't dare to start the hammering until you pressed "play", then, if you start too early, the player simply stops. If you start too late, you miss the present. My advice: use software player A ;)

This method should also work on Blu-Ray, you just need to change the media type code in the CDB.

I've attached a new Version of DumpVID with hammering support (no Blu-Ray support!).

:rolleyes:
I've build on KenD00's work and am now able to reliably extract a Volume ID from the drive using any Software Player without the need of the found Host Private Key.

It first involves some tweaking by the user (but the proggy each try gives advise on what to do: setting the time earlier or later). But once setup it will work perfectly. And it requires no sniffing. It uses the moment the AGID is allocated by the Software Player as a pretty precise time marker.

This technique uses the huge hole in AACS: no bus encryption. This allows us to pretend to be the Software Player at the exact right time. And I don't think they can plug this hole now since so many drives (without the capability to bus encrypt) are already sold.

They really f**ked up here :D. They should have waited longer and finished the job properly. Shame on them.

I will probably release the (now still experimental) program to do this in the future. Possibly combined with my other proggy that uses the now found Host Private Key. This technique can be used as a "fall-back position" in the case the found HPK gets revoked.

Oh yes. We really are busting AACS. Piece by piece. :)

In my mind the whole Drive-Host protection (Chapter 4 common AACS specs) is toast.

Regards,

arnezami

HyperHacker

5th March 2007, 22:25

OK, some people were wondering about barcodes and burst cutting areas, so here's an image that should help clarify. This is a Gamecube disc but other discs will be similar; Gamecube discs are only mini DVDs really.

The "barcode" is printed on the inner ring. This is, as best I know, not readable by any drive. It serves only to identify the disc and probably contains the same info as the text around it or a serial number.

The "burst cutting area" can be seen on the innermost section of the data area. This is phsyically pressed into the disc. Some drives can read this, but to write it requires very expensive disc pressing equipment. This could indeed hold things like volume ID.

ATARI Vampire

5th March 2007, 22:31

I will probably release the (now still experimental) program to do this in the future. Possibly combined with my other proggy that uses the now found Host Private Key.

I'd love to play around with this code. Please do release it. Thanks.

arnezami

6th March 2007, 06:48

ShadowFlare

6th March 2007, 09:22

Well here is something to play with. :)

fetchvid.exe (http://www.sendspace.com/file/als4m9)

For me it works with WinDVD (which is the most sensitive I believe) and the Xbox 360 HD DVD. My sweet spot is a time value between 390 and 420. I usually set it at 410 which works perfectly (btw time is measured in nr of AGID retrieval attempts counted from the moment the player accesses the drive).

Just try it and play with it a bit.

Remember: this program does not use the private key. It just "watches" the drive carefully and then pretends to be the software player.

It works for HD DVD only atm.

Screenshot:

http://img129.imageshack.us/img129/4074/fetchvidhd3.png

Regards,

arnezami

PS. This is experimental programming. There could be bugs in it.

So, theoretically your program could automatically find the correct value, only telling the user when to open the player to play and when to reopen the player to try again. It could do it by the same process you performed manually, but automatically changing to different values instead.

Once the value is found, it could be saved for later use, correct? Or would this value possibly change on the same computer and drive depending on factors such as the quality of the disc, etc.?