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

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

 

Go Back   Doom9's Forum > General > Decrypting

Reply
 
Thread Tools Search this Thread Display Modes
Old 7th February 2007, 14:38   #61  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by Momotte View Post
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

Last edited by arnezami; 7th February 2007 at 14:41.
arnezami is offline   Reply With Quote
Old 7th February 2007, 16:34   #62  |  Link
Momotte
Registered User
 
Join Date: Apr 2004
Posts: 55
Quote:
Originally Posted by arnezami View Post
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,
Momotte is offline   Reply With Quote
Old 7th February 2007, 18:20   #63  |  Link
Ishan
Anime Vampire
 
Ishan's Avatar
 
Join Date: Nov 2002
Location: Earth, Solar system, Milky way, Universe.
Posts: 126
Quote:
Originally Posted by arnezami View Post
...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 could be a problem in the future...
Ishan is offline   Reply With Quote
Old 7th February 2007, 18:34   #64  |  Link
jkenzie
Registered User
 
Join Date: Jan 2007
Posts: 40
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.
jkenzie is offline   Reply With Quote
Old 7th February 2007, 18:43   #65  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by Ishan View Post
Works fine with PowerDVD 7.2 Ultra. And it seems there's no way to ununstall the service could be a problem in the future...
Quote:
Originally Posted by jkenzie View Post
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.
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?).

Last edited by arnezami; 7th February 2007 at 18:50.
arnezami is offline   Reply With Quote
Old 7th February 2007, 19:15   #66  |  Link
Ishan
Anime Vampire
 
Ishan's Avatar
 
Join Date: Nov 2002
Location: Earth, Solar system, Milky way, Universe.
Posts: 126
This sniffer is a bit buggy but works fine for me. I'll get some more VID when I'll get more HDDVD movies...
Ishan is offline   Reply With Quote
Old 7th February 2007, 19:42   #67  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Thanks to jokin .

Appollo 13:
Code:
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:

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

Last edited by arnezami; 7th February 2007 at 20:17.
arnezami is offline   Reply With Quote
Old 7th February 2007, 20:05   #68  |  Link
melakai
Registered User
 
Join Date: Jan 2007
Posts: 28
@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)
melakai is offline   Reply With Quote
Old 7th February 2007, 20:18   #69  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
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.

Last edited by arnezami; 7th February 2007 at 20:27.
arnezami is offline   Reply With Quote
Old 7th February 2007, 20:28   #70  |  Link
SBeaver
Registered User
 
Join Date: Dec 2002
Posts: 86
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.

Last edited by SBeaver; 7th February 2007 at 20:34.
SBeaver is offline   Reply With Quote
Old 7th February 2007, 20:32   #71  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by SBeaver View Post
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 .
arnezami is offline   Reply With Quote
Old 7th February 2007, 20:53   #72  |  Link
SBeaver
Registered User
 
Join Date: Dec 2002
Posts: 86
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
SBeaver is offline   Reply With Quote
Old 7th February 2007, 23:03   #73  |  Link
evdberg
Registered User
 
Join Date: Dec 2006
Posts: 202
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 ...
evdberg is offline   Reply With Quote
Old 8th February 2007, 03:11   #74  |  Link
arctor
Registered User
 
Join Date: Jan 2007
Posts: 7
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
arctor is offline   Reply With Quote
Old 8th February 2007, 08:08   #75  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by arctor View Post
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

Last edited by arnezami; 8th February 2007 at 23:14.
arnezami is offline   Reply With Quote
Old 8th February 2007, 08:22   #76  |  Link
HyperHacker
Resident DRM Hater
 
HyperHacker's Avatar
 
Join Date: Oct 2006
Location: International waters
Posts: 242
Quote:
Originally Posted by SBeaver View Post
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.
__________________
Because Moogles pwn.
HyperHacker is offline   Reply With Quote
Old 8th February 2007, 09:01   #77  |  Link
jokin
Dwight Schrute's homeboy
 
Join Date: Jan 2007
Location: The Office
Posts: 136
Quote:
Originally Posted by HyperHacker View Post
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.
jokin is offline   Reply With Quote
Old 8th February 2007, 11:32   #78  |  Link
SBeaver
Registered User
 
Join Date: Dec 2002
Posts: 86
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
SBeaver is offline   Reply With Quote
Old 8th February 2007, 11:44   #79  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by SBeaver View Post
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!
arnezami is offline   Reply With Quote
Old 8th February 2007, 22:34   #80  |  Link
arctor
Registered User
 
Join Date: Jan 2007
Posts: 7
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.)
arctor is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

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

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

Forum Jump


All times are GMT +1. The time now is 14:55.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.