BackupHDDVD, a tool to decrypt AACS protected movies

[cyber1]

I can confirm it has been done....only a matter of time before it spreads.

Nice, wonder what the people who called Muslix64 "a moron" is thinking now...

As a programmer I never doubted Muslix64 claims, since the key always (at some point) will reside in memory, in every software player, otherwise it will not be able to play HD-DVD files at all.

[Warren]

calinb, the Japanese WinDVD HD 8 doesn't display that error - at least it didn't for me and I don't even have the Japanese language pack installed.

[calinb]

calinb, the Japanese WinDVD HD 8 doesn't display that error - at least it didn't for me and I don't even have the Japanese language pack installed.
Weird! I downloaded WinDVD8.exe from www.intervideo.co.jp. It's 120,270 KB. Following the guide up to the point where you set Japanese for "Language for non-Unicode programs" allowed me to install it, however.

I should have followed the avsforum guide. I can't read kanji.

[mixanobios]

I have been reading this thread since it begining, and i would like to post my thoughts.

1) As i understand it, actual content on a AACS protected disc is encoded with ONE(1) key, or at most a handful of keys, correct? i could refrase that by saying that there is a AES-128 key that can decrypt content on each AACS protected disk. lets call that "final decryption key". i think that these are the title keys refered in muslix's FAQ.

2) if we manage to hack a drive firmware (if it is needed) and create a program that can read HDDVD or BD sector by sector, bypassing the whole AACS authentication process, then, provided we have title keys, we can decode any disk we want to, regardless of any revocation stuff correct?


So, all we need to completely break AACS is a list with title keys for every disk, a program that can extract HDDVD and BD sector by sector, read their structure and decode them using the title keys, and possibly a drive with hacked firmware if such procedure is not allowed by current firmwares.

The good thing about this is that title keys need only be extracted ONCE per batch of disks, and posted to a site.

Is my line of thinking correct? please comment

Related : http://www.freedom-to-tinker.com/?p=1106

[jlobee]

no errors here during install, or playback

[hajj_3]

I can confirm it has been done....only a matter of time before it spreads.

tell us how to do it or release the keys for movies that you own:)!

i can get them spread as a scene release in an nfo if you want.

[feizex]

This has been covered before, but here it is. One more time for the dummies...

Yes there is one key - the volume unique key. Use this to decode the title keys. There's more than one title (video) to a disc. There is one title key for each video. Use the title key to decode the matching video.

BTW, the videos are stored as encrypted files on the disc. There's no need to linearly read the each sector of the disc. All you need is the encrypted video file and the title key.

The AACS authority can revoke drives, hosts and content. Drive as in the physical optical drive. Host as in the software player on the PC. Content as in the HDDVD itself.

They can't revoke volume or title keys. But they can revoke what allows you to get them in the first place IE. drive, software player or disc.

All revocation info is stored on the HDDVD. This info is stamped with a version number. Before anything is played back the revocation lists are checked and updated from the info on the disc (if it has a later version). Copies of the latest revocation lists are stored on the HDDVD drive (in flash ram) and on your PC.

This means that if you insert a disc with info on it that revokes your drive or your player, it will not play anymore certified content (HDDVDs).

There doesn't appear to be anything in the specs to say under what circumstances they would revoke anything. Reality suggests that they would revoke anything which has been compromised.

As has been suggested before the most likely to happen is revocation of the software player because it is too easy to obtain decryption keys from. It has also been suggested that under these circumstances the software provider would produce an update for their product which is more secure. This would need to be recertified by AACS (new Host Certificate and Host ID). Once updated it could play HDDVDs again, but you may not be able to get your decryption keys.

Check out Figure 4-6 Drive Authentication Algorithm for AACS

Here is some more info that explain some of the Revocation process...
"the drive and the PC host verify each counterpart is not revoked by checking the Host
Revocation List (HRL) and the Drive Revocation List (DRL), respectively. To do this, the drive shall store the
most recent HRL it has encountered and the PC host shall store the most recent DRL it has encountered."

It gets revocation info (DRL and HRL) from the Media Key Block (MKB) on the disc. First it checks the DRL that the drive is not revoked. Then it checks the HRL that the Software player is not revoked.

The latest version of HRL is what is stored on the HDDVD drive in it's NVRAM.
"the drive reads an MKB recorded on the media to check if its version is higher than the version of HRL that it has stored in its non-volatile memory. If not, the drive determines to use the HRL in its non-volatile memory for the subsequent drive authentication procedure"

Content revocation...
"Certified Content may be revoked. When this occurs, corresponding revocation information is added to a Content Revocation List". "Licensed replicators shall include the most recent CRL on each pre-recorded medium that they produce".
In the AACS directory there is a file called CONTENT_REVOCATION_LIST.AACS

[cyber1]

Please dont go public which software-player you used to extract keys!

You can publish the volume key and the title keys, but never talk in public which player you used, because then its easy for them to revoke that players key.

[hajj_3]

you might aswell post which player it is, we all presume the xbox 360 as its the most common one. if they update the keys in future revisions we can just find the key for that!

[cyber1]

you might aswell post which player it is, we all presume the xbox 360 as its the most common one. if they update the keys in future revisions we can just find the key for that! :D
I'm talking about software-players!, you cant extract volume or title keys from an Xbox HD-DVD player, the decoding take place in the computer when using Xbox HD-DVD player.

[DerKönig]

Continuing CowBell's line of thought with what I understood from feizex's post:

Wouldnt it be, in theory, possible to create an HD-DVD image like the one Borbus created, with an MKB file that has empty DRL and HRL but a very high version number. Burn that image and play it in the HD-DVD drive (probably the XBOX drive as this is most popular). This would force the authentication process to be skipped in future as the system now thinks it has the highest versions of the DRL and HRL (but they are empty)???

@IsoChroma:

Since you are the one who contacted Eclipse... would the above idea need a license from the AACS LA (to create a "valid" HD-DVD image I mean)??

[DerKönig]

BackupHDDVD requires either the Volume Key or Title Keys... is having a player key of any use??? I mean, if I had a player key, where is the encrypted Volume Key on the Disc? so that it can be decrypted using the Player Key...

[cyber1]

BackupHDDVD requires either the Volume Key or Title Keys... is having a player key of any use??? I mean, if I had a player key, where is the encrypted Volume Key on the Disc? so that it can be decrypted using the Player Key...

You can read the specs at www.aacsla.com.
At this point the player key is not interesting.
Its only AACS LA that can create signed MKBs.

[ilaps]

read chapter 3 of AACS_spec_common_0.91: they describe the algo Kd (you call it player key) , MKB (you read it on the dvd)-->Km: media key ; there is an example in java!

then you go to AACS-spec_prerecorded_0.91 and in §3.3 you see how to compute from media key the volume key and title key

Have you got Kd keys?

[evdberg]

Hi Neviens,

I have made a program which can log the input and output of any function in PowerDVD. I now used it to monitor the function you disassembled and commented in post #490 (http://forum.doom9.org/showthread.php?p=929376#post929376). These are the results of the 4 input parameters:
33d1e40 300a520 30061dc 2190
33d1e40 30125e8 7e002e4 2190
33d1e40 301b008 2fd72cc 2190
33d1e40 2ff4148 2fefe04 2190
33d1e40 7eeb1e0 2fc77c4 2190
33d1e40 2ff1b38 2fed7f4 2190
33d1e40 2fc51e0 2fed7f4 2190

Obviously the 1st 3 parameters are pointers, so I might log the memory to which they point. Is this of any use to you? Do you want to see other results or logs of different function calls?

P.S.: I can not play HD-DVD on my system, so these are the calls to the point that PowerDVD displays the error message that my system is not sufficient to play HD-DVD.

[Syris2k4]

Rather off topic, but I thought a nice thing to... share.

"Many media content owners believe web surfers should pay to watch their material, just like other audiences, and protect their files with digital rights management (DRM) constraints that prevent people making copies. A recent Treasury report on intellectual property concluded that this kind of protection actually encourages innovation and creates the next big thing that consumers seek."

Source : http://tinyurl.com/yxyoxq

Please could I have some DRM, ohh please? :)

And good job so far on the hunt, I'm enjoying the reading so far, wish I could join in. I do like the idea of re-writing the stored cache of banned keys - perhaps check with "the dangerous brothers" if they could look at a firmware hack?

[neviens]

Hi Neviens,

I have made a program which can log the input and output of any function in PowerDVD. I now used it to monitor the function you disassembled and commented in post #490 (http://forum.doom9.org/showthread.php?p=929376#post929376). These are the results of the 4 input parameters:
33d1e40 300a520 30061dc 2190
33d1e40 30125e8 7e002e4 2190
33d1e40 301b008 2fd72cc 2190
33d1e40 2ff4148 2fefe04 2190
33d1e40 7eeb1e0 2fc77c4 2190
33d1e40 2ff1b38 2fed7f4 2190
33d1e40 2fc51e0 2fed7f4 2190

Obviously the 1st 3 parameters are pointers, so I might log the memory to which they point. Is this of any use to you? Do you want to see other results or logs of different function calls?

P.S.: I can not play HD-DVD on my system, so these are the calls to the point that PowerDVD displays the error message that my system is not sufficient to play HD-DVD.

1. Unfortunately, it's useless to hook AES functions in program
that actually don't play a content. You see, there isn't any call
with fourth argument = 10h, but most (all ?) AES operations on
keys are exactly with 10h bytes of data.
We need to cooperate with somebody who can play a HD-DVD.

2. What data output from your program is necessary.
a) the key. Pointer to AES key is a 2nd argument of AES_KeyExpand(),
and key length allways is 10h (16 decimal).
b) input buffer (for operations with keys only). Pointer to
input buffer is a 2nd arg of AES_SwitchFunc*()
c) output buffer (for operations with keys only). Pointer to
output buffer is a 3rd arg of AES_SwitchFunc*()
length of buffers = 10h

If we want to begin with title key, then it's necessary to hook
the CBC decrypt function @100C34E8, I think. One call to this
function decrypts device keys file 001.fcl with hexadecimal key
00010203000102030001020300010203
One of two remaining calls must be content decyphering!
We need only 2nd arg of AES_KeyExpand(), the title key.
Oh, it's so difficult to live without debugger ):

[Janvitos]

Just a little comparison i made between PowerDVD and WinDVD,
i noticed the contents of the VTKF000.AACS file is there a few times in PowerDVD's memory,
but it isn't at all in WinDVD's memory. I'm not sure if this means anything, just a thought.

[evdberg]

I prepared below log earlier this evening. It is the 32 bytes of each of the 3 argument pointers before (Input) and after (Output) the function call. You can clearly see the key you mentioned in the 1st argument.

I will see tomorrow if I can log what you asked for ...
What do you mean with your last sentence? Don't you have a debugger?


Input:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00 GenuineIntel

43 2c e9 fe 25 1c a3 0f bb 80 27 e9 8b 19 8c c4
a4 d4 f4 91 ad c3 43 a2 8b db 29 52 d5 79 3f 07

34 33 32 63 65 39 66 65 32 35 31 63 61 33 30 66 432ce9fe251ca30f
62 62 38 30 32 37 65 39 38 62 31 39 38 63 63 34 bb8027e98b198cc4

Output:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

a0 e0 12 00 dc 03 2f 03 01 00 00 00 ac e0 12 00
5c 0f 2f 03 00 00 00 00 00 00 00 00 90 2d 00 03

46 43 4c 46 49 45 4c 44 78 4c f5 c3 63 97 a4 39
04 06 a4 9f 78 00 c7 7d e9 0c b3 4c 00 1d f3 6b

Input:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

43 2c e9 fe 25 1c a3 0f bb 80 27 e9 8b 19 8c c4
a4 d4 f4 91 ad c3 43 a2 8b db 29 52 d5 79 3f 07

34 33 32 63 65 39 66 65 32 35 31 63 61 33 30 66
62 62 38 30 32 37 65 39 38 62 31 39 38 63 63 34

Output:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

ac df 12 00 dc 03 2f 03 01 00 00 00 b8 df 12 00
5c 0f 2f 03 00 00 00 00 00 00 00 00 88 ee 00 03

46 43 4c 46 49 45 4c 44 78 4c f5 c3 63 97 a4 39
04 06 a4 9f 78 00 c7 7d e9 0c b3 4c 00 1d f3 6b

Input:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

43 2c e9 fe 25 1c a3 0f bb 80 27 e9 8b 19 8c c4
a4 d4 f4 91 ad c3 43 a2 8b db 29 52 d5 79 3f 07

34 33 32 63 65 39 66 65 32 35 31 63 61 33 30 66
62 62 38 30 32 37 65 39 38 62 31 39 38 63 63 34

Output:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

60 db 12 00 dc 03 2f 03 01 00 00 00 6c db 12 00
5c 0f 2f 03 00 00 00 00 00 00 00 00 90 2d 00 03

46 43 4c 46 49 45 4c 44 78 4c f5 c3 63 97 a4 39
04 06 a4 9f 78 00 c7 7d e9 0c b3 4c 00 1d f3 6b

Input:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

43 2c e9 fe 25 1c a3 0f bb 80 27 e9 8b 19 8c c4
a4 d4 f4 91 ad c3 43 a2 8b db 29 52 d5 79 3f 07

34 33 32 63 65 39 66 65 32 35 31 63 61 33 30 66
62 62 38 30 32 37 65 39 38 62 31 39 38 63 63 34

Output:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

6c da 12 00 dc 03 2f 03 01 00 00 00 78 da 12 00
5c 0f 2f 03 00 00 00 00 00 00 00 00 70 d9 00 03

46 43 4c 46 49 45 4c 44 78 4c f5 c3 63 97 a4 39
04 06 a4 9f 78 00 c7 7d e9 0c b3 4c 00 1d f3 6b

Input:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

43 2c e9 fe 25 1c a3 0f bb 80 27 e9 8b 19 8c c4
a4 d4 f4 91 ad c3 43 a2 8b db 29 52 d5 79 3f 07

34 33 32 63 65 39 66 65 32 35 31 63 61 33 30 66
62 62 38 30 32 37 65 39 38 62 31 39 38 63 63 34

Output:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

a0 db 12 00 dc 03 2f 03 01 00 00 00 ac db 12 00
5c 0f 2f 03 00 00 00 00 00 00 00 00 90 2d 00 03

46 43 4c 46 49 45 4c 44 78 4c f5 c3 63 97 a4 39
04 06 a4 9f 78 00 c7 7d e9 0c b3 4c 00 1d f3 6b

Input:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

43 2c e9 fe 25 1c a3 0f bb 80 27 e9 8b 19 8c c4
a4 d4 f4 91 ad c3 43 a2 8b db 29 52 d5 79 3f 07

34 33 32 63 65 39 66 65 32 35 31 63 61 33 30 66
62 62 38 30 32 37 65 39 38 62 31 39 38 63 63 34

Output:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

ac da 12 00 dc 03 2f 03 01 00 00 00 b8 da 12 00
5c 0f 2f 03 00 00 00 00 00 00 00 00 e8 2f 00 08

46 43 4c 46 49 45 4c 44 78 4c f5 c3 63 97 a4 39
04 06 a4 9f 78 00 c7 7d e9 0c b3 4c 00 1d f3 6b

[muslix64]

There is a problem with the playback of movies having the
"In movie experience" (IME) feature. This is not a BackupHDDVD problem but a PowerDVD problem

PowerDVD cannot play decrypted content having the extra streams required for the IME feature.
It simply Crash...

In order to play the content, you have to remove these extra streams. I have identify:

Audio substream 0xc8 and video substream 0xd3
I manage to get smooth audio playback, but not smooth video playback so far...

If you want to experiment with BackupHDDVD, make sure your movie don't have the IME feature.

or just use one of the movies I have listed I my first post.

I hope we will have an open source player to play decrypted evob file soon. (VideoLan!)

[muslix64]

Do you know about "known-plaintext attack"?
It takes only few seconds to my keyfinder tool to locate the key in the memory dump file using the known-plaintext attack.

You don't have to mess with tracing/debugging the code. Just dump the memory...

[muslix64]

Anyone have the BD+ SPDC virtual machine specifications?
This one will be a real challenge...

[Warren]

Hrm which known plaintext attack are you referring to muslix? What information do we have that when encrypted could lead us to the key?

[muslix64]

Warren...

Do you know what is the structure of an encrypted PACK?
Take a look at that first and think about it.
If I have figure it out, anyone can...

[DanITman]

Welcome back muslix I hope you vacation went well :)

[noclip]

Do you know about "known-plaintext attack"?
It takes only few seconds to my keyfinder tool to locate the key in the memory dump file using the known-plaintext attack.

You don't have to mess with tracing/debugging the code. Just dump the memory...

All the AACS constants appear at least half a dozen times in memory.

On a different note, are the keys padded with 00 00 00?

Are you talking about taking a some data from an unencrypted EVOB that is constant for all EVOBs and bruteforcing memory for a key that yields a result which contains that data?

[muslix64]

Yes my vacation went well, thanks DanITMan.
Ok, let's call it "guessed-plaintext attack" if you want.
Get it?
Take a look at actual packs in the stream. Anything special?

[noclip]

Take a look at actual packs in the stream. Anything special?
The packs in the encrypted EVOBs on the HD-DVD? The packs of the unencrypted EVOB as it's decrypted for playback?

Is the known (guessed) data in the unencrypted portion of each pack?

Edit: Also, could you please come to the #doom9 channel on efnet?

[Janvitos]

Muslix64, without disrespect, i would like to know why you are giving us everything but precise information and how you believe this might help us out in the long run.

I am no assembly programmer myself, and have been following this thread since the beginning, but have found little if no help with the "clues" you have been providing. In my understanding, you are trying to make a riddle out of this, which is, in my opinion, throwing people on different tracks and not necessarily "helping" out.

If you are trying to help with good intentions though, then i am simply not "wise" enough to connect with your clues or sayings. Memory locations, constants and key locations are what everybody is seeking here. I think many have been working really hard on this, but it seems to be going round and round for most.

Furthermore, i do appreciate the work you have put in writing the code for BackupHDDVD and it will surely serve a purpose some day when we hopefully, and finally, get our hands on the keys.

[feizex]

Uh... Plausible deniability.

As for the known plaintext, perhaps some header info? "The HD DVD-Video format is licensed by the DVD Forum, which publishes the HD DVD-Video Specifications." I haven't found that yet. Anyone want to post a link?

Besides that, the same aproach could be used to find the volume key once you have the title key.

[jackchen]

well, in the view point of reverse engineering or cracking, the clue given by Muslix64 is quite enough even though he never point out which software and where exactly to find the keys. but this shall be enough for those who are experienced in the cracking field.
we have different software players, each player have multiple executeable files, DLLs, filters, and each of these files might be encrypted to prevent reverse engineering. so it will take some time to find out which file contents the code which uses the title key to decrypt the contents on disk, and then it will take more time to search the memory space for the key. it's only a matter of time.
for sure that if he could give us more clue than we can certainly shortern this trial and error iteration time. But that's his freedom. None of us has the right to push him showing off any unreveiled info.
I actually encountered similar situation when I was in the team announced the first success in cracking xbox360 DVD firmware to allow backup game disk being played. I can understand his situation.
If you are not familiar with software reverse engineering, here are some hints.
1. Try to understand your target with as many ways as possible.
Here our target is the HDDVD and AACS, so we shall gather and read the spec. of HDDVD and AACS.
2. Find feasible tools.
debugger which can trace the code in real time and access the memorys such as olly debugger, softIce, etc.
disassembler which can give you the asm source code of certain program. IDA Pro is the best choice.
Other tools such as PE tools which can dump the code and memory space of program/DLLs running in OS. this might help when the code was encrypted and the disassembler is not working.
Sometimes you have to program your own tool. Like Muslix's key finder, that can help him search the keys in the memory dump.

well, looks like easy, but it was never a easy thing. So if you are interested in this cracking thing, than you can start to joing the game. If you're not willing to learn these stuff, than you can sit tight and watch the show. Maybe soon there will be someone releasing a tool which can help you grab the keys in realtime which the players is running.

Just one more thing. Since we can copy the encrypted content from the HDDVD disks to HDD directly, than the only thing stopping us from using the software player to play it is the AACS restriction which was coded in the software player. If we can find this code and change it, then the software player can still play the encrypted content directly since it has all the keys necessary for the play back. In that case, we no longer need to decrypt the content, just use the cracked software player than we play anything we want. too bad I don't have HDDVD drive and disks here. I am more interested in this cracking way.

[neviens]

1. Try to understand...
2. Find feasible tools...


You forget 3rd. HD-DVD drive, and at least one disc is necessary.
It's (near) impossible to reverse nonworking code. Authopsy
(deadlisting) is not enough, vivisection (live debugging) is
the king of reverse engineering.
And it is not a mess! It's a matter of hours not days to find
a code and data (including AACS specs reading :) in this way.

[evdberg]

Do you know about "known-plaintext attack"?
Ofcourse ... as long as you know both the encrypted data and the decrypted data you can try out keys, in this case from a memory dump, quite fast. I guess you refer to the weakness of the way video data is encoded in the stream, which is also exploited by VobDec? The last pack is padded with a padding block, so you know how this has to look after decryption ... this way you can verify the title key ... and once you know a title key you can use the same method to verify the volume unique key ...

Personally I wanted to make a method that just grabs the volume unique key when a title key is being decrypted, which I find a more elegant way ... although slightly more work to figure out ... :)

[generalnewbie]

hmm when i was thinking all hope was lost and no progress would be given.. the man thats caused all this ruckus is back. For anyone curious as to what he ment by Know plaintext attack or referred to guessed attack the analogy best states it:Encrypted file archives such as ZIP are also very prone to this attack. For example, an attacker with an encrypted ZIP file needs only one unencrypted file from the archive which forms the "known-plaintext". Then using some publicly available software they can instantly calculate the key required to decrypt the entire archive

[jackchen]

You forget 3rd. HD-DVD drive, and at least one disc is necessary.
It's (near) impossible to reverse nonworking code. Authopsy
(deadlisting) is not enough, vivisection (live debugging) is
the king of reverse engineering.
And it is not a mess! It's a matter of hours not days to find
a code and data (including AACS specs reading :) in this way.

haa.. you're right, I missed the most important part.
if the drive and disks are popolar, then we might already have lots of keys floating around the P2P sites.

btw, anyone with the HDDVD drive and powerDVD can verify that whether the PowerDVD can play the EVO files directly from the HDDVD disk? I am now trying to go with different way, that is to crack the software players to play the encrypted contents from none-HDDVD medias. any comments or inputs?

[Bystander]

You're talking about a lot of trial and error to find keys by dumping memory. PowerDVD removes the code as it goes along.

There are no less than 1,911 calls to: CALL <JMP.&MSVCR71.??3@YAXPAX@Z> to remove code from memory to cover its steps.

This leads me to think HD DVD japan version was used. Unless there is another HD DVD player out there?

[arturner]

Hey Everyone,

I've been following this thread for about 3 weeks now and thought I'd some up my own thoughts on the matter.

First of all it seems 100% plausible to me that the keys are dumped from memory, seeing as the "host" (as defined in AACS LA specs) has to construct the Volume Unique Key (based on Volume ID cipher...) to decrypt the Title keys, which are in turn used to decrypt the content.

(BTW I'm neither a programmer, cracker, or anything, just someone that likes to read specs, solve puzzles and think)

Now, in muslix64's last posts he refers to the known plain text (or GUESSED plain text) method to get the keys form a memory dump.

Now let's think about this for a second:

If you do AES 128 encyption of some plain text, you have (forgive me for not using EXACT numbers) say X^Y (X and X are VERY large) possibilities for the key, which you could only crack by brute force (and will take forever).

Now what about known plaintext (I nicked this example off the internet btw):

Say I want to send some highly confidentiel info (in XLS format) to a colleague. I encypt it and send it, but someone intercepts (who knows me, i.e. coporate spy. He/She can then start a known-plaintext attack based on:

*XLS header (constant and known)
*Words like dollar, total, subtotal, revenue

Other things you either KNOW or GUESS. The more you really know the smaller you can make X^Y, say you reduce it to 2^20

Well thenj you're only looking at a million key possibilities. Run these through your memory dump (at the appropriate time, although this seems to be a snag where PowerDVD is concerned if it hides it's tracks) matching say, partial or whole pattern and if your key is in memory, you'll find exactly the key. Might take a little time but still relatively quiick :)

So, this brings us to what plaintext do we know (or guess??), well I haven't done any research on the actual video content on HD-DVD, but I presume it's either MPEG 2 HD or H.264 (MPEG 4 part 10) which both have pretty standard header descriptors :) On the either hand you have the padding that was talked about earlier, should be standard. Maybe by reading the specs you can find more info on 'guessed' plaintext content.

I'll do some research later and also see if I can find a publicly avilable tool for doing AES known-plaintext attacks (as I can't program Java for ***) LOL :)

Hope I was of some help, I'll get back to this thread later!

[DerKönig]

We know the ciphertext (encrypted EVO)... We can get the plaintext i.e. decrypted video stream (or can we?? Im not sure... but if we can) then a known-plaintext attack is possible...

Also, regarding evdberg's post:

Do we know or is it possible to know the padding for the last block???

[evdberg]

Do we know or is it possible to know the padding for the last block???

We just know. The 1st 128 bytes of each pack is never encrypted and the pack header is thus readable, so we know how much video data is in the block. A fully used video block is 0x7ec (the packheader is 14 bytes, the video header + size is 6, totally 20 bytes), so if it is less we know that after the video block there will be a padding block. We also know exactly the size and start offset in the pack. The padding will look like this:

00 00 01 BF XX XX FF FF FF ..

XX XX is the size of the padding block (which is 0x7ec - <size of video block> - 6). If we have a memory dump of PowerDVD or WinDVD while it is playing a disk, we can try every 16 continuous bytes at long word offsets as key. This is most likely the way muslix64 did it. He only forgot to include his key checking prog to the distribution ...

[hoihoi]

i really am surprised that nobody posted a device key yet, because
a) there aren't that many (software) players out yet -> they will probably release a new MKB for future DVDs
b) there is no secret "voodoo-magic-yadayada-stealth" way to hide those device keys, ever. all you can do about it is make them harder to find; which might take 20-30 mins longer, at most. thats just how computers work. the registers have to point to the memory location(s) of the key at some point or another.

so i guess there are just not that many people, who have the equipment, interested in finding a key, and even less who want to brag about it / post a key.

muslix has given so many hints on how to find the keys.
so if you don't know how to interactivly debug or trace the key in the memory, one could as well just brute force the MKB using a memory dump of a player as possible device key list. should not take that long either.

[evdberg]

Fixed my playback problem! PowerDVD does not want to play on my iMac (has problems with my video driver), but WinDVD works perfectly fine and without any complaint!

[hajj_3]

muslix64, is it possible to create a program to find the key if you know where it is located? are the keys located at the same place each time.

give us some more clues please!:)

[evdberg]

hajj_3, did you read my posts?? You should have enough clues by now ...

[hajj_3]

hajj_3, did you read my posts?? You should have enough clues by now ...

get re-writing muslix64's program to scan for the keys then and release it anonymously in the wild.

an automated way is the only way this will be successful as only a handful of people would be able to rip their hd-dvd's. a gui program that did everything for you would be used by millions of people.

[cyber1]

I may be oldschool, but I think that many of todays young people want everything "served on a plate".... :o

Personally I think muslix64 gave too many clues.:cool:

[The_ByteMaster]

get re-writing muslix64's program to scan for the keys then and release it anonymously in the wild.

Let's first just see one working title key or volume unique key in the wild...

[Jerky_san]

I may be oldschool, but I think that many of todays young people want everything "served on a plate".... :o


Well if you look at it though the reason you must serve it to them on a plate. Is then you get the herd to adopt it. Once it spreads to the herd theres no stopping the stampede that will come after. If you don't make it easy like Xerox in the 70's thought that having a GUI is something that no one that used computers would want. Well look what happened.. we all have a GUI and it trampled everything else.

Onto other things like the subject at hand.. This basically sounds like when your a little kid and if you made a "secret code" but if someone knew 1 or 2 words in the letter you wrote then they could inturn find out what the other numbers and letters mean because persay A was 4 and B was 1 then you could assume that C would be something in the range of 2 or 4 and D 3 or 6.. Is this sorta what you all are talking about? Know a few characteristics in each block you'll know what every block is?

[calinb]

In that case, we no longer need to decrypt the content, just use the cracked software player than we play anything we want. too bad I don't have HDDVD drive and disks here. I am more interested in this cracking way.Yes, but please remember one of Muslix64's main motivations: playing his HD-DVD in full res over an unprotected (no HDCP) DVI interface. Apparently, his player provides this capability only with unencrypted files and media.

With the approach you suggest, a second hack to the player would also be required to permit this capability, in addition to the hack to merely enable the playing of copied encrypted files. Then there's the desire to transcode the video to formats that are compatible with other devices and operating systems. All in all, finding the keys is the most compelling endeavor, motivated by Fair Use and similar to the Hymn project for iTunes.

[cyberpass]

Finding the device keys are useless and a bad idea. If you do get the device keys, there is still way too much coding needed to calculate the title keys. They will just revoke the player for future use.

Finding the title keys is a good idea, even better if small brother doesnt find out which player was used. Let the player calculate the title key and steal it.

[bob0r]

@muslix64

Since you are now allowed to post keys, just do so.
And proof the people here wrong: http://www.hdnowonline.com/Comment_Who_Is_Muslix.html

If you dont dare posting keys, i am sure you can find a way to do this anonymous.

I myself hate fakers, and hope you are the real deal.