View Full Version : Processing Key, Media Key and Volume ID found!!!
Adub
11th February 2007, 08:54
Excellent job!
This is really great as it provides another manner of attack, thus preventing, well, "prevention".
Now, how the heck did you do it?
arnezami
11th February 2007, 13:17
Wooow. I think I did it :).
Processing Key found!!!
:D :D :D :D :D :D :D :D :D
More info later.
To be sure I need to confirm my finding. I need the following (from anybody with a HD DVD disc):
1) - Movie Title (not King Kong please ;))
2) - The Verify Media Key Record in the MKBROM.AACS file. It starts with 81 00 00 14 followed by the 16 byte Record. In my case this it at Offset 00000120h. Here is mine:
81 00 00 14 87 B8 A2 B7 C1 0B 9F AD F8 C4 36 1E 23 86 59 E5 7F 00 00 xx
3) - The first C-Value in the MKBROM.AACS file (also called Media Key Data). It starts with 05 00 20 14 (the 20 14 could be different but is probably the same) followed by the first 16 byte C-Value. In my case this it at Offset 00004376h. Here is mine:
05 00 20 14 6D 02 CA C6 7B 1A 7E 95 C2 16 EF D4 C9 28 09 CF D3 CE 9A DC
If you react quickly I can check if the Processing Key is really valid (for multiple discs).
:D :D :D :D :D :D :D :D :D
Yeah I'm happy...
arnezami
hajj_3
11th February 2007, 13:38
im confused with all these keys lol. hopefully all the keys will be found on the disc soon, rather than in memory, so we can scan the disc and find all the keys.
Eeknay
11th February 2007, 14:01
1.) The Departed
2.) FF 29 11 E9 96 16 5D 97 29 2D BB A0 3C A9 0D E0
3.) 68 07 C3 23 7E 18 6F 7F BC 78 E2 DC 26 C5 84 0B
Hope that helps.
EDIT: Here's another disc just for kicks.
1.) Spy Game
2.) 7C AD 1D 65 D5 9E C1 67 A7 96 E5 C2 13 23 08 22
3.) 59 28 94 3F 5C 09 19 2C 8D 54 0A 77 45 BE 3E 6D
arnezami
11th February 2007, 14:09
1.) The Departed
2.)
3.)
Hope that helps.
EDIT: Here's another disc just for kicks.
1.) Spy Game
2.)
3.)
YES YES YES!! It works! :D :D :D
I'm going to take some rest now (I need it ;)). But will tell all later.
Here is the Processing Key which should work on all HD DVD discs (and maybe even Blu-Ray discs) released so far:
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Save it. Store it. :)
Regards,
arnezami
PS. As explained before in order to get a VUK you now only need a Volume ID (which should be fairly easy to get or even to guess...).
hd1080p
11th February 2007, 14:53
Congrats everybody for the thrill of witnessing how DRM was defeated. February 11, 2007 is a day to be remembered.
I predict that movies will one day be liberated without DRM and we are all going to loose all the fun and excitement.
Fairuse wins!!
PS. As in LOR, this is the KEY(RING) to conquer all!!
Now, we have to find the processing key for blueray to help out HD-DVD market position. Movie studios may just stop releasing new movies on HD-DVDs. There should be a level playing field for the competing formats.
blutach
11th February 2007, 14:54
Nice work arnezami
Regards
arnezami
11th February 2007, 17:12
Thanks you all :). Its been a pleasure.
As I can understand some of you are interested in how I retrieved the Media and Processing Keys. I will tell what i did.
Most of the time I spend studying the AACS papers. A good understanding of how things worked have helped me greatly in knowing what to find in the first place (and how to recognize something). I may write an explanation of (my understanding) of how AACS works in particular the subset-difference technique (which is by far the hardest to understand) at a later date if you guys want to.
But anyway. Since the moment I found the Volume ID (which was much simpler than I had thought) my thought was to try to find the Media Key. But after some discussion I thought it might be better to go directly for the Device Keys (bad mistake). After looking at files created and changed by software player and trying to recognize Device Keys in memory dumps I was starting to get worried a bit. I wasn't making any progress.
So I went back to my original idea: do a bottom-up approach. So first I tried to find the Media Key. One of the logical things to do even before that was to search for the Verify Media Key Record in memory. But it wasn't there. I then started to work on a little proggy that would scan a memdump and see everything as a Media Key: thus trying to verify it with the Verify Media Key Record. No luck.
This was frustrating: all kinds of information was in the memdump but not the Media Key (I sort of assumed/hoped it would). I made several memdumps at different moments but nada, nothing. After throwing it all away I remembered I still had a "corrupt" memdump from WinHex (it failed to finish it because WinHex said the memory had changed). It was really small compared to the others so I didn't have much hope. But when running it with my proggy: voila! I found it. Which finally gave me hope I was going in the right direction.
There were just two major problems left: how do you detect the Processing Key and if its not in memory how do you find it at all? Well since I now knew how things worked I knew the Processing Key had to be combined with a C-value to produce the Media Key. The problem was there are 513 C-values in the MKB! Searching the memory (several megabytes) for a Processing Key and assuming just one C-value would take minutes (if not hours depending on the size of the dump). So doing them all would take very long. And that while I didn't even know for sure there was a Processing Key in memory to begin with. I made a proggy that did this but using my favorite "corrupt" memdump I didn't find any Processing Key in the first megabyte (not for any C-value). It didn't look good.
But then I realized why I first didn't find the Media Key: it was removed from memory after the Volume ID was retrieved and the VUK calculated. I also saw that in my "corrupt" memdump the VUK, Vol ID, Media Key and the Title Key MAC were all closely clustered in memory: in the first 50kb (of the entire multi megabyte file!) but there were large empty parts around it. Almost as if it was cleaned up.
This gave me an idea: what I wanted to do is "record" all changes in this part of memory during startup of the movie. Hopefully I would catch something insteresting. In the end I did something a little more effiecient: I used the hd dvd vuk extractor (thanks ape!) and adapted it to slow down the software player (while scanning its memory continously) and at the very moment the Media Key (which I now knew: my bottom-up approach really paid off here) was detected it halted the player. I then made a memdump with WinHex. I now had the feeling I had something. :)
And I did. Not suprisingly the very first C-value was a hit. I then checked if everyting was correct, asked for confirmation and here we are. :D
Hope you enjoyed the ride. I'm thinking about a concept of proof proggy which does all the steps (from Processing Key to C-value to Media Key to Volume ID to VUK). It would require a Volume ID as input (which might be retrieved/guessed in another program or extension whatever). But the most important part is done: we have a Processing Key.
I'm also thinking about doing a full explanation of the AACS protection system (or at least the subset-difference technique). But only if there is any demand for it ;).
Regards,
arnezami
PS. For the keen observer: I'm not telling which player I used (well you can guess but you might guess wrong) to retrieve the Processing Key because I don't want to give the AACS LA any extra legal ammunition against any player company. Nothing was hacked, cracked or even reverse engineered btw: I only had to watch the "show" in my own memory. No debugger was used, no binaries changed.
jokin
11th February 2007, 17:18
Awesome awesome work.
And when you have time please explain the subset-difference technique.
Thanks again.
hd1080p
11th February 2007, 17:22
It is better than the real movie show. You are a genius!!
Please continue the work with blueray.:thanks:
zeroprobe
11th February 2007, 17:24
great stuff. More write ups of the whole process would be greatly appreciated. More information the better.
How about one for bluray :)
arnezami
11th February 2007, 17:25
It is better than the real movie show. You are a genius!!
Please continue the work with blueray.:thanks:
If somebody can give the same info Eeknay gave above (but for a Blu-Ray disc) I could see if this Processing Key works for Blu-Ray aswell.
pacman2006
11th February 2007, 17:29
Amazing work Arnezami! :D
I'm trying to understand the full aspect of having a processing key. Will this work for future discs too, or is this key also revokable?
hd1080p
11th February 2007, 17:40
Unfortunately, they (MPAA) can change the keys for future releases. At least now all current HD-DVD releases are deemed DRM free.
Fortunately, using ARNEZAMI's methodology, we can find them again using the particular player. Of course, they (player vendor) can change the way they implement the AACS DRM or even MPAA people can even change the AACS specs.
Amazing work Arnezami! :D
I'm trying to understand the full aspect of having a processing key. Will this work for future discs too, or is this key also revokable?
LokiHD
11th February 2007, 18:14
nice!
too funny..
mb2696
11th February 2007, 18:15
@arnezami - Amazing work!!! I'd really like to hear your in-depth take on AACS as well.
madshi
11th February 2007, 18:18
That sounds very nice!
But what happens if Volume IDs are created with real random numbers in the future? Will a Processing Key then still help?
Thanks!
buttfacepoop
11th February 2007, 19:33
Regards,
arnezami
PS. For the keen observer: I'm not telling which player I used (well you can guess but you might guess wrong) to retrieve the Processing Key because I don't want to give the AACS LA any extra legal ammunition against any player company. Nothing was hacked, cracked or even reverse engineered btw: I only had to watch the "show" in my own memory. No debugger was used, no binaries changed.
arnezami,
thanks for your fantastic work.
i think by describing your exact method in finding the key, however, may lead people/MPAA to the exact player that is being used. perhaps when you in the future crack the player just post the key, no explanation?
SBeaver
11th February 2007, 20:40
I wasn't expecting this so soon.
You really did a great job, and whomever made the software player f**ked up serverely.
You shouldn't give up on the device keys though, we should steal all the keys they have.
btw is it possible to find the processing key with the usb sniffer, now that you know what the key is?
or is it moved over in encrypted form?
and finding it on the disk would be great, even if it's encrypted in several layers.
Anyway, you rock
tonyp12
11th February 2007, 21:53
So now that we have a Processing key,
How time consuming would it be to guess the VID (instead of USB sniffing)?
For example a decrypter that says
"please wait, I'm trying 2million possible keys"
And do that in about 30 seconds.
SBeaver
11th February 2007, 22:34
So now that we have a Processing key,
How time consuming would it be to guess the VID (instead of USB sniffing)?
For example a decrypter that says
"please wait, I'm trying 2million possible keys"
And do that in about 30 seconds.
That would take some time to figure out.
A good start would be if we could get more sniffed volume IDs and unencrypted Volume IDs from different discs so we can figure out the patterns in the keys, if there are any.
If you can guess the key down to 6 unknown bytes by jst knowing the manufacturer then it's will work, but the more unknown bytes the more impossible it gets.
Finding a pattern is the only way i think, and it will work as long as the discs follow these patterns.
As soon as they fall outside the box then you have to go sniff again.
Ishan
11th February 2007, 22:44
I don't think there's any pattern, it seems it's different for each manufacturer.
SBeaver
11th February 2007, 22:53
I don't think there's any pattern, it seems it's different for each manufacturer.
well that is a patterns, there is just a few manufacturers making all (edit: most) the discs anyway so if we know patterns for each that is enough.
not a perfect solution though.
madshi
11th February 2007, 22:54
I rather think if the manufacturers/studios get notice of this thread they will probably make Volume IDs much more random than before. So I rather doubt that guessing will work in the future.
tonyp12
11th February 2007, 23:09
It probably will take 2 months before we start seeing
any changes in the values they use for Processing Key and VID.
It would be cool to have a HDDVD-decrypter that can decrypt
any disc from the top10 manufactures before this date without memdump/sniffing/keydb.cfg
After that it will be a cat and mouse game.
evdberg
11th February 2007, 23:19
Arnezami did great work, but he played out his cards much too soon ...
blutach
11th February 2007, 23:35
You shouldn't give up on the device keys though, we should steal all the keys they have.
Rather poor choice of words. Nobody here is stealing anything - they are exercising their rights to play their legally bought material however they want to.
Regards
Adub
11th February 2007, 23:39
@evdberg
What exactly do you mean about playing his cards to soon? Are you saying he should have waited until the VUK memdump search method was retired?
What would you have done?
SBeaver
12th February 2007, 00:15
Rather poor choice of words. Nobody here is stealing anything - they are exercising their rights to play their legally bought material however they want to.
Regards
Well stealing is their definition of what people are doing.
Let's just say we are making copies of their keys just in case they lose them. :)
evdberg
12th February 2007, 00:23
@evdberg
What exactly do you mean about playing his cards to soon? Are you saying he should have waited until the VUK memdump search method was retired?
Definitely !
What would you have done?
I can understand his enthusiasm (it clearly showed from his posts), he was on to something and I know how that feels. But since the current method is still not counteracted, it's better to keep it to yourself ... don't bring other people on ideas ... well, the rabbit is out of the hat now, we will see what happens, but my guess is that a very promising method is wasted now.
xyz987
12th February 2007, 00:48
I'm also thinking about doing a full explanation of the AACS protection system (or at least the subset-difference technique). But only if there is any demand for it ;).
Congratulations :-)
And yes, there is demand ;-)
:thanks:
xyz987
12th February 2007, 01:08
I can understand his enthusiasm (it clearly showed from his posts), he was on to something and I know how that feels. But since the current method is still not counteracted, it's better to keep it to yourself ... don't bring other people on ideas ... well, the rabbit is out of the hat now, we will see what happens, but my guess is that a very promising method is wasted now.
May be they can revoke this Processing Key. So what?. In fact i want to see them revoking tons of keys. More easy will be to guest the Master Key.
noclip
12th February 2007, 01:59
Some of you are missing the true meaning of this compromise. If they revoke this processing key, we just take a player compatible with a new processing key, put in one of the titles that's already cracked, and go around in memory looking for the known key. We find it, insert a new title, look in the same place and we have a new processing key.
Adub
12th February 2007, 04:22
That's what I was thinking, I just wasn't sure that it would be so simple to find the new key quickly.
tonyp12
12th February 2007, 05:53
memory looking for the known key. We find it, insert a new title, look in the same place and we have a new processing key.
AACS-LA probably will revoke both windvd and powerdvd device keys,
give out new device and processing keys.
But only after the makers of the software players shows that
no keys whatsoever are in memory in plain view at any time.
The keys will only be in the CPU's register for a brief time.
Galileo2000
12th February 2007, 05:56
Great job.
And yes, we DEMAND explanations! :D
BTW, I think I guessed your player all right.
You gave me a processing key in one of your posts.:devil:
evdberg
12th February 2007, 10:42
That's what I was thinking, I just wasn't sure that it would be so simple to find the new key quickly.
I am pretty sure that Cyberlink and InterVideo have to make sure it won't be as easy as it is now ... or worst case: their keys are revoked and they do not get new ones at all !
cyber1
12th February 2007, 12:13
AACS-LA probably will revoke both windvd and powerdvd device keys,
give out new device and processing keys.
But only after the makers of the software players shows that
no keys whatsoever are in memory in plain view at any time.
The keys will only be in the CPU's register for a brief time.
This is probably what is going to happen, the only reason that the search-memdump-method have worked so far is that one HD-DVD application have a terrible AACS implementation. It's going to be much harder in the future.
zeroprobe
12th February 2007, 12:37
This is probably what is going to happen, the only reason that the search-memdump-method have worked so far is that one HD-DVD application have a terrible AACS implementation. It's going to be much harder in the future.
I really can't see them stopping us finding the VUK's . As we already know them for 150 titles.
We know what to look for as you just use the new "improved" software player to playback an old hddvd disc. Then we just search for the old vuks. They messed up now and we now know what we are looking for.
pacman2006
12th February 2007, 13:38
We know what to look for as you just use the new "improved" software player to playback an old hddvd disc. Then we just search for the old vuks.
The new software players will do everything to hide the vuk's. A simple search for the keys won't work. The keys will be scrambled. They could also do several other things to hide the keys, but I won't give them any good ideas. :p
evdberg
12th February 2007, 14:05
The new software players will do everything to hide the vuk's.
And because of Arnezami's work most likely also the other keys like the Media and Processing key ... and that is what I meant with 'playing his cards too soon'.
arnezami
12th February 2007, 14:18
And because of Arnezami's work most likely also the other keys like the Media and Processing key ... and that is what I meant with 'playing his cards too soon'.
Nonsense. I have no time now but will have later.
But this for now: the Processing Key and/or Device Keys of a player were already compromised before this thread even started. Keep your facts straight. I started this topic knowing AnyDVD had already done it. But that was not the only reason. Will explain more later.
Please concentrate now on doing something constructive. Like trying to build sniffing software, giving more Volume IDs, getting Blu-Ray C-values/Validate Media Key etc.
Regards,
arnezami
evdberg
12th February 2007, 16:17
I started this topic knowing AnyDVD had already done it.
Where did you read this? I can only find speculation and phrases like "So just how does AnyDVD HD work? Has SlySoft managed to really crack AACS? For now, no one is sure just how AnyDVD HD will work exactly.". I agree with you to keep the facts straight ...
zeroprobe
12th February 2007, 22:16
Where did you read this? I can only find speculation and phrases like "So just how does AnyDVD HD work? Has SlySoft managed to really crack AACS? For now, no one is sure just how AnyDVD HD will work exactly.". I agree with you to keep the facts straight ...
Every post you make is negative, you don't have a clue what your talking about.
Theres only two possible ways AnyDVD can work and I can 99.9% say that they didn't break aacs so it must be this way.
evdberg
12th February 2007, 22:17
Anyway ... in the meantime that this forum was down due to moving to another server, I made a small program that implements what is discussed in this thread. I can only conclude it works perfectly fine, and I am amazed that this one processing key every time works on the very first c-value (of 512 available). Obviously someone at the mastering facility was very lazy ...
Dethis
12th February 2007, 22:19
.... For now, no one is sure just how AnyDVD HD will work exactly.". ...
Except beta testers..;)
evdberg
12th February 2007, 22:20
Every post you make is negative, you don't have a clue what your talking about.
I can only conclude that you have no idea who I am ...
Theres only two possible ways AnyDVD can work and I can 99.9% say that they didn't break aacs so it must be this way.
For all we know they just include a lookup table with all known VUKs. Since they release twice a week a new version of AnyDVD, they can keep that table up-to-date. And since you can not read the Volume ID directly from a disk (must go through secured handshake commands through MMC commands), they can't use this new method. So indeed there are 2 methods: either the above mentioned lookup table of VUKs, or they use a device key and perform the whole protocol.
xyz987
12th February 2007, 22:20
Anyway ... in the meantime that this forum was down due to moving to another server, I made a small program that implements what is discussed in this thread. I can only conclude it works perfectly fine, and I am amazed that this one processing key every time works on the very first c-value (of 512 available).
Source code please :-)
arnezami
12th February 2007, 22:20
Every post you make is negative, you don't have a clue what your talking about.
Theres only two possible ways AnyDVD can work and I can 99.9% say that they didn't break aacs so it must be this way.
Thank you so much. For a moment I thought I was biased. I really considered spending (or should I say wasting) useful time on a response. But you said it very clearly in two sentences.
evdberg
12th February 2007, 22:22
Except beta testers..;)
They can only test functionality of the program, they do not know anything about its workings.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.