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 16th February 2007, 20:33   #281  |  Link
SvT
Never Grow Up !
 
SvT's Avatar
 
Join Date: Mar 2004
Location: EU
Posts: 131
Reaction AACS

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.



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.

Last edited by SvT; 17th February 2007 at 02:35. Reason: Reason added to go "off topic"
SvT is offline   Reply With Quote
Old 16th February 2007, 23:10   #282  |  Link
blutach
Country Member
 
blutach's Avatar
 
Join Date: Sep 2004
Location: is everything!
Posts: 6,499
Quote:
Originally Posted by guile View Post
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
__________________
Les

Only use genuine Verbatim or Taiyo Yuden media.
blutach is offline   Reply With Quote
Old 16th February 2007, 23:13   #283  |  Link
blutach
Country Member
 
blutach's Avatar
 
Join Date: Sep 2004
Location: is everything!
Posts: 6,499
Quote:
Originally Posted by SvT View Post
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.

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

Regards
__________________
Les

Only use genuine Verbatim or Taiyo Yuden media.
blutach is offline   Reply With Quote
Old 17th February 2007, 02:53   #284  |  Link
guile
Registered User
 
Join Date: Oct 2002
Posts: 65
Quote:
Originally Posted by blutach View Post
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
guile is offline   Reply With Quote
Old 17th February 2007, 17:38   #285  |  Link
KenD00
Registered User
 
Join Date: Jan 2007
Location: Internet
Posts: 378
Quote:
Originally Posted by evdberg View Post
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.

KenD00 is offline   Reply With Quote
Old 17th February 2007, 17:47   #286  |  Link
SBeaver
Registered User
 
Join Date: Dec 2002
Posts: 86
Quote:
Originally Posted by KenD00 View Post
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.

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.
SBeaver is offline   Reply With Quote
Old 17th February 2007, 21:19   #287  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by KenD00 View Post
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.

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

Last edited by arnezami; 17th February 2007 at 21:26.
arnezami is offline   Reply With Quote
Old 17th February 2007, 22:57   #288  |  Link
brand1130x
Registered User
 
Join Date: Jan 2007
Posts: 5
tehehe ... fox delays dozens of blu ray releases for BD+ ... check at techspot.com
brand1130x is offline   Reply With Quote
Old 18th February 2007, 00:18   #289  |  Link
blutach
Country Member
 
blutach's Avatar
 
Join Date: Sep 2004
Location: is everything!
Posts: 6,499
@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
__________________
Les

Only use genuine Verbatim or Taiyo Yuden media.
blutach is offline   Reply With Quote
Old 18th February 2007, 00:52   #290  |  Link
pedrito
Registered User
 
Join Date: Feb 2007
Posts: 1
Quote:
Originally Posted by evdberg View Post
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)?
pedrito is offline   Reply With Quote
Old 18th February 2007, 00:55   #291  |  Link
tonyp12
Registered User
 
Join Date: Oct 2002
Location: Florida, USA
Posts: 90
Quote:
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 !!!
tonyp12 is offline   Reply With Quote
Old 18th February 2007, 05:31   #292  |  Link
KenD00
Registered User
 
Join Date: Jan 2007
Location: Internet
Posts: 378
Quote:
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) 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.

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

Attached Files
File Type: zip dumpvid_0.2.zip (44.6 KB, 412 views)
KenD00 is offline   Reply With Quote
Old 18th February 2007, 07:12   #293  |  Link
Multiplex
Registered User
 
Join Date: Feb 2007
Location: State of confusion
Posts: 7
More info

Quote:
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.
Multiplex is offline   Reply With Quote
Old 18th February 2007, 08:33   #294  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by KenD00 View Post
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) 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.

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.

Last edited by arnezami; 18th February 2007 at 12:32.
arnezami is offline   Reply With Quote
Old 18th February 2007, 09:33   #295  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
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

Last edited by arnezami; 18th February 2007 at 10:21.
arnezami is offline   Reply With Quote
Old 18th February 2007, 12:48   #296  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by KenD00 View Post
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.

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:



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

Last edited by arnezami; 18th February 2007 at 13:39.
arnezami is offline   Reply With Quote
Old 18th February 2007, 15:02   #297  |  Link
evdberg
Registered User
 
Join Date: Dec 2006
Posts: 202
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.

Last edited by evdberg; 18th February 2007 at 15:06.
evdberg is offline   Reply With Quote
Old 18th February 2007, 15:51   #298  |  Link
KenD00
Registered User
 
Join Date: Jan 2007
Location: Internet
Posts: 378
Following illustrates what is written into cds.bin:



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.


Last edited by KenD00; 18th February 2007 at 16:40.
KenD00 is offline   Reply With Quote
Old 18th February 2007, 16:32   #299  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by KenD00 View Post
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.

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 :



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

Regards,

arnezami

Last edited by arnezami; 18th February 2007 at 16:37.
arnezami is offline   Reply With Quote
Old 18th February 2007, 17:16   #300  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
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:

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

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

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

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

Last edited by arnezami; 18th February 2007 at 17:26.
arnezami 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 11:56.


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