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

[mrazzido]

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]

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]

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]

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]

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]

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]

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

enjoy,
Mtz

[jokin]

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

enjoy,
Mtz

Thanks.

[Momotte]

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

[jokin]

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

http://forum.doom9.org/showthread.php?t=120970

[arnezami]

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]

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]

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

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]

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]

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]

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]

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

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]

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]

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]

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]

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]

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

[arnezami]

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]

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]

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]

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

[arnezami]

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]

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]

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]

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]

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]

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.

[jkenzie]

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

[arnezami]

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]

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]

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]

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

[mrazzido]

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]

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]

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]

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]

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

[arnezami]

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]

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]

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]

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

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]

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