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

[arnezami]

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]

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

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

Reserved fields are always filled with 0x00.

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

[arnezami]

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

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

09 18 20 06 08 41

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

King Kong |V|09/18/06|

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

What does this mean?

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

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

get cracking guys!

[evdberg]

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

[noclip]

Manchurian Candidate Volume ID: 0531200601130020202020200000

[Ishan]

Nevermind ^_^

[arnezami]

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]

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

[arnezami]

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

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

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

[evdberg]

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

[noclip]

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

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

[evdberg]

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

[noclip]

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

[evdberg]

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]

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]

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]

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

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

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

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

[madshi]

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

[noclip]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

disc not disks.

[jokin]

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]

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]

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]

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]

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.

[arnezami]

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]

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

Regards

[pacman2006]

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

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]

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