Log in

View Full Version : BackupHDDVD, a tool to decrypt AACS protected movies


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 [15] 16 17 18 19 20 21 22 23

hajj_3
13th January 2007, 12:38
calinb, please can you re-compile this to do the hashes, that would be amazing, the more automated this can become the better!

He-Man
13th January 2007, 12:47
calinb, please can you re-compile this to do the hashes, that would be amazing, the more automated this can become the better!
It could be build into the Backup HD-DVD GUI that "Polly" is already working on: http://forum.doom9.org/showthread.php?p=929912#post929912
But it should still be put into the correct field in the KEYDB.cfg file toghter with the key, title, etc.
And since you need WinHex or similar to find the key, it's just as easy to use this tool to find the hash too.

Only recompiling the BackupHDDVD code to report the hash will not make the process any more automated than using WinHex to show the hash.

calinb
13th January 2007, 12:51
I was under the impression from the quick glance I had the chance to grab that the volume unique keys would work with any player
once we've gotten them we have them and no longer need the player KeyThe opportunity to grab decrypted keys and the difficulty of doing so varies from player to player. Yes--once you've figured out how to exploit any given player and used it to calculate the volume unique key, you no longer need the player for any further decryption of that disc. You have BackupHDDVD for that!

But what about discs, new or old, for which you've not yet obtained a volume unique key in the clear (unencrypted)? You'll need the player again. If the player is listed in your drive memory (presumably flash memory) as revoked, the player will no longer work to generate volume unique keys or even play any HD-DVD discs--even if you reinstall a fresh copy of the software on your computer. This will require you to learn how to exploit another player, hack the drive, or hack the player.

zeroprobe
13th January 2007, 12:58
The opportunity to grab decrypted keys and the difficulty of doing so varies from player to player. Yes--once you've figured out how to exploit any given player and used it to calculate the volume unique key, you no longer need the player for any further decryption of that disc. You have BackupHDDVD for that!

But what about discs, new or old, for which you've not yet obtained a volume unique key in the clear (unencrypted)? You'll need the player again. If the player is listed in your drive memory (presumably flash memory) as revoked, the player will no longer work to generate volume unique keys or even play any HD-DVD discs--even if you reinstall a fresh copy of the software on your computer. This will require you to learn how to exploit another player, hack the drive, or hack the player.

The new updated players have to playback old material though, thus having the same title keys????????? and as we already know them it will be easy to locate on the new software players.

Title keys will stay the same so will reveal where the location is on new software players. Am I right???

hajj_3
13th January 2007, 13:00
It could be build into the Backup HD-DVD GUI that "Polly" is already working on: http://forum.doom9.org/showthread.php?p=929912#post929912
But it should still be put into the correct field in the KEYDB.cfg file toghter with the key, title, etc.
And since you need WinHex or similar to find the key, it's just as easy to use this tool to find the hash too.

Only recompiling the BackupHDDVD code to report the hash will not make the process any more automated than using WinHex to show the hash.

he may just be a 1hit poster, we need someone to release a gui version on here with sourcecode so that we can all improve it. pref a c++ version or something that dosent require java or .net to be installed.

calinb
13th January 2007, 13:09
<snip>
Only recompiling the BackupHDDVD code to report the hash will not make the process any more automated than using WinHex to show the hash.I agree. We could discuss whether or not the hash check in Muslix64's code is a good usability feature. It appears the only reason it's there is to support multiple entries in the KEYDB.cfg file. (It identifies discs by matching the hash to the user's entry in KEYDB.cfg.) Given that a user generally decrypts an HD-DVD only once, it might make sense to remove this feature from the code and support only a single entry in KEYDB.cfg. Or even better, simply add a command line option to permit placing the volume unique key on the command line and completely ignore KEYDB.cfg. That way we could have both functionalities, as desired for the situation. :)

I've been looking for a reason to learn a "modern" programming language -- having been more of an assembly and C guy in the past. I'm sure others will whiz right past me in developing new tools and features but I could add this command line volume unique key option, if there's interest. (I feel like I should contribute something--damn day job had me shut down during most of this action!)

hajj_3
13th January 2007, 13:15
yeah Calinb, create an updated version of this and release the sourcecode, even if it is commandline, someone can then create a gui version from it by knowing the sourcecode.

calinb
13th January 2007, 13:15
The new updated players have to playback old material though, thus having the same title keys????????? and as we already know them it will be easy to locate on the new software players.The updated players will play old media but, if they go to the trouble to revoke a player, the new one will certainly be more resistant.
Title keys will stay the same so will reveal where the location is on new software players. Am I right???Hmm--that would help considerably. Are you gonna make me go read that spec again? ;)

yeah Calinb, create an updated version of this and release the sourcecode, even if it is commandline, someone can then create a gui version from it by knowing the sourcecode.Okay...but I gotta get some sleep first. There are so many excellent programmers around here and this thread is moving so fast, someone will have probably beaten me to it by the time I awaken. ;)

zeroprobe
13th January 2007, 13:26
The updated players will play old media but, if they go to the trouble to revoke a player, the new one will certainly be more resistant.Hmm--that would help considerably. Are you gonna make me go read that spec again? ;)

Okay...but I gotta get some sleep first. There are so many excellent programmers around here and this thread is moving so fast, someone will have probably beaten me to it by the time I awaken. ;)

If decrypted title keys are the same on powerdvd and winddvd then it obviously has no effect what the players key is.

He-Man
13th January 2007, 13:33
I agree. I only compiled Muslix64's code to report the hash because my hash calculator was having trouble. We could discuss whether or not the hash check in Muslix64's code is a good usability feature. It appears the only reason it's there is to support multiple entries in the KEYDB.cfg file. (It identifies discs by matching the hash to the user's entry in KEYDB.cfg.) Given that a user generally decrypts an HD-DVD only once, it might make sense to remove this feature from the code and support only a single entry in KEYDB.cfg. Or even better, simply add a command line option to permit placing the volume unique key on the command line and completely ignore KEYDB.cfg. That way we could have both functionalities, as desired for the situation. :)
I think most users wish to store all the extracted keys somewhere anyway. You might only need to extract once, but it would be nice to keep they keys so you can always extract again if your hard rive crashes or something. Or maybe you want to share the keys with a friend. Or using the already extracted keys as reference for hacking a new player if the old player gets revoked.
So if you are going to store keys for all the extracted files anyway, you might as well just store them all in the same KEYDB.cfg file along with the title name and hash.

I think a better solution would be to automate writing/updating to the KEYDB.cfg file by entering the movie title, + volume/title key value in the the a GUI for BackupHDDVD and then have it automatically calculating and writing the hash to the KEYDB.cfg along with it.

hajj_3
13th January 2007, 13:38
yeah, a .txt plaintext file of previously found keys would be good, like anydvd does.

zeroprobe
13th January 2007, 13:44
can anyone confirm the end result decrypted title keys are the same regardless of which player is used.

If so is that not game over as we know what to look for on any updated software player?

He-Man
13th January 2007, 13:50
If decrypted title keys are the same on powerdvd and winddvd then it obviously has no effect what the players key is.
If a player key gets revoked by new HD-DVD movies, so this player wont be allowed to play anymore HD-DVD's, then you need to install a new player version. This new player version might be better at hiding title and volume keys in memory. If you can't find these keys in memory anymore in a new version of the player, then you can't extract anymore movies because you can't find keys anymore, not in the old player version because it has been revoked so it's not allowed to play anymore HD-DVD's, nor in the new player version if you can't find the keys in memory anymore in this new version.

I don't know if anyone is able to extract title/volume keys using PowerDVD. Has anyone tried to search for the keys in memory using PowerDVD?
If WinDVD gets updated to be more secure it might not be possible to extract keys with this anymore either. And then it doesn't help to have the old player version still installed because it can be revoked from new movie titles without even being connected to the internet.

Please correct me if I'm wrong, but that's how I understood the revocation process.

jackchen
13th January 2007, 13:55
can anyone confirm the end result decrypted title keys are the same regardless of which player is used.

If so is that not game over as we know what to look for on any updated software player?


yes, in the AACS spec. it's 100% true that every player including the software and hardware player will always decryt the title key table and then get the same result. But AACS can revoke these titles so that you won't be able to play these disks any more. But that will be a critical impact since there are already so many titles released in the filed.

For those people with both software players, could you give it a little trial to see whether we can find the keys in PowerDVD's memory or not?

JarrettH
13th January 2007, 14:00
this thread has revealed the true crackers of this community :D

Hellreaper
13th January 2007, 14:30
"heise online" spoke with Cyberlink on the "CES Unveiled" event and reports that they deny any AACS-key-in-memory issue in PowerDVD.

http://www.heise.de/newsticker/meldung/83289 (german) and a badly translated version (http://translate.google.com/translate_p?hl=de&ie=UTF-8&oe=UTF-8&langpair=de%7Cen&u=http://www.heise.de/newsticker/meldung/83289&prev=/language_tools)

Abstract: PowerDVD doesn't store the keys in memory, therefore they can't be found there. Since there's no loophole, nothing needs to be fixed. If there was one, they would have to report it to AACS LA, and new HD DVDs would contain a new keyset that would make them unplayable with the compromised PowerDVD version. Furthermore, all 18 months, there is a mandatory change of keys.


In theory, this is about collecting and archiving keys.

With this weakness, you could find out the keys from all HD-DVDs released within about 18 months.

Then you would have to find another weakness, because newer HD-DVDs wouldn't work with the old software player. (even if it wasn't compromised)

zeroprobe
13th January 2007, 14:39
someone already mentioned they found a title key in powerdvd. The only way they can have a good chance at stopping this is blacklisting every single hddvd released thus far.

As it stands even if they update the players, the title keys already out can be used to track down the new locations. When you know what to look for it would be easy. The only way they stop this is blacklisting the titles out now. Can you really see them doing this.

jackchen
13th January 2007, 14:46
Abstract: PowerDVD doesn't store the keys in memory, therefore they can't be found there. Since there's no loophole, nothing needs to be fixed. If there was one, they would have to report it to AACS LA, and new HD DVDs would contain a new keyset that would make them unplayable with the compromised PowerDVD version. Furthermore, all 18 months, there is a mandatory change of keys.


I believe that he was talking about the player key instead of the title key or the Volume unique key.

Eeknay
13th January 2007, 14:55
I'm having trouble with WinDVD... I installed the HD version, it opens, but then sits there and does nothing if I select "HD DVD source" or hit Play. Any ideas?

EDIT: never mind, fixed it. Needed to roll back my ATI drivers to 6.7.

He-Man
13th January 2007, 14:56
someone already mentioned they found a title key in powerdvd.
Who mentioned this and where?
So far in this topic I have only read people mentioning finding keys in memory using WinDVD.

zeroprobe
13th January 2007, 15:06
Who mentioned this and where?
So far in this topic I have only read people mentioning finding keys in memory using WinDVD.

wasn't on a forum. Someone mentioned they had found one so I presume he's right.

markrb
13th January 2007, 15:54
Once a movie is on your HD a few questions since I can be thick.
Do you need to use PowerDVD 6.5 or will any HD capable player play the movie?
Do you need to run anything other then the player or is the movie completely decrypted already?

I just get the impression that you still need to use the keys even after copying with the keys?

I have a HTPC and I copy my most watched movies that I own onto the HD so I can just click to watch and would like to continue this way with HD-DVD.

Thanks,
Mark

MrDVD
13th January 2007, 18:03
Anyone know it the X360 HD-DVD is recognized by linux so that its possible to run the java soft under it ?

noclip
13th January 2007, 18:57
In case you're having trouble finding the keys, search for the second occurrence of file:///required/ and scroll down until you see something in the sea of 00s, that's the TK block. Scroll down some more and the VK will be there.

moshmothma
13th January 2007, 19:43
Could someone please tell me how they are handling the .map files? They are not being copied during the backup process. Is everyone just copying files from the disc to the their backup folders? Thanks

LordSloth
13th January 2007, 20:02
Now that the key memory locations are easily determinable, we need to figure out how the Volume Unique Key derived from the Volume ID and whatever other parts that may go into it.

If we can figure out that algorithm we can start work on making a Linux HD-DVD (possibly even BluRay) player that can play all our discs!

I don't have much use for backing up my discs (I tend to take good care of them) and making an open source Linux HD-DVD/BD player is only reason I care about working on any of this.

Hope we can get some smart people to help out in this. I guess this should be a separate thread.

~Cheers!

Bystander
13th January 2007, 20:13
I just tried WinDVD HD. Seems I can't get Olly to get past an error... " Don't know how to bypass command at address 00FBCE2A. Try to change EIP or pass the exception to the program". I tried adding the exception in the debugging options and no go.

Which brings me to my next question. If you are not using a debugger when dumping memory with WinHex, at what point do you inspect the memory? do you pause or stop the movie?

Then for Winhex, you can select WinDVD but what exactly do you click on to search? I find only one instance of VPLST000.XPL and no keys are present.

The version of WinDVD I am using is: 7.5 B42.052 in the information tab

Eeknay
13th January 2007, 20:21
Now that the key memory locations are easily determinable, we need to figure out how the Volume Unique Key derived from the Volume ID and whatever other parts that may go into it.

If we can figure out that algorithm we can start work on making a Linux HD-DVD (possibly even BluRay) player that can play all our discs!

I don't have much use for backing up my discs (I tend to take good care of them) and making an open source Linux HD-DVD/BD player is only reason I care about working on any of this.

Hope we can get some smart people to help out in this. I guess this should be a separate thread.

~Cheers!

Take a look at a few Warner discs (i.e. original Superman, V for Vendetta) if you could... I tried but couldn't find the key (or at least a working volume one) for either of those (Superman II just crashes).

cyberpass
14th January 2007, 00:05
Here is my worry...AACS refuse to license any software player...Is there anyway to dump the memory of a hardware player? I remember during the days of direct tv hacking, hardware memory dumps will flying everywhere....

DanITman
14th January 2007, 00:43
Here is my worry...AACS refuse to license any software player...Is there anyway to dump the memory of a hardware player? I remember during the days of direct tv hacking, hardware memory dumps will flying everywhere....

Yes, there is a good possibility that people will figureout how to extract keys from actual hardware players. This how DeCSS original became what it is today.

In regards to no software players, this will never happen. The first company that people does this will lose the format war.

xyz987
14th January 2007, 01:15
emule or torrents probably only way, and it would be not
organized and some people would just include random numbers
for keys just to waste your time.

Key poisoning is not a big problem. Any key collector can sign the file that stores his/her keys collection. Of course, a key collector can get keys from files from other key collectors he/she trusts.

blutach
14th January 2007, 01:51
Good morning/evening all.

May I ask members who have questions that are off this topic to start their own threads please?

I will move various posts to new threads in the meantime.

Regards

Mistar Muffin
14th January 2007, 02:41
I successfully ripped the entirety of King Kong to my drive with the volume key supplied in this thread. I do not have an HD copy of WinDVD, as I do not want to buy the jap copy. I do have the HD ver of Power DVD 6.5, and I can play everything except the feature film in it just fine. On Vista Ultimate x86, I can play the universal logo and various menu files after they are ripped, but attempting to play the FEATURE_1/2.evos causes PDVD to crash. Same goes on an XP Pro box with entirely different hardware. What I found interesting is that the Vista box I am on now only has a 3.0ghz P4 and 1024mb PC3200 and a meager Geforce 5200, and plays back on a 1280x1024 monitor without hiccups. Pretty sweet, but I wish I could get the feature to play.

Also, anyone successfully gotten a key from PowerDVD?

noclip
14th January 2007, 03:40
Also, anyone successfully gotten a key from PowerDVD?

The title key for whatever title is playing is in memory in PowerDVD, but no volume key.

jokin
14th January 2007, 03:59
I usually find the keys just above CONTENT_REVOCATION_LIST.AACS for World Trade Center and Batman Begins.

Jerky_san
14th January 2007, 04:36
To people wondering about PowerDVD last night when the keys first started appearing Janvitos spoke about finding keys in powerDVD but I believe he mentioned it was a little bit harder at first but he then discovered the 13 monkey key in PowerDVD hopefully he will come back soon and tell about the experience but I'm fairly certain he said he was able to find keys in powerdvd..

Ábudos
14th January 2007, 04:57
To the people who origionaly found the Volume Unique Keys and title keys:

How did you find them for the first time? Was there some logic behind it, or did you just grab 16 bytes that looked conveniently placed and get lucky?

Jerky_san
14th January 2007, 05:03
<Janvitos> simply do a text search for VPLST000.XPL
<Janvitos> and after a couple of instances
<Janvitos> all the title keys are there
<Janvitos> and below
<Janvitos> after some few 0s
<Janvitos> will be the volume unique key
<Janvitos> easily recognisable

thats what Janvitos said yesterday when explaining how he found them..

Ábudos
14th January 2007, 05:09
<Janvitos> simply do a text search for VPLST000.XPL
<Janvitos> and after a couple of instances
<Janvitos> all the title keys are there
<Janvitos> and below
<Janvitos> after some few 0s
<Janvitos> will be the volume unique key
<Janvitos> easily recognisable

thats what Janvitos said yesterday when explaining how he found them..

Yes... That's how he said to find where they are located.

That's not how he found them in the first place.

OverlordQ
14th January 2007, 06:23
http://rapidshare.com/files/11616301/BackupHDDVD.rar

2 'requested' features added:

1) Will report the calculated Disc Hash
2) If Hash not found in key file, will add it after prompting for the name of the movie.

Given I don't have neither HDDVD Drive nor any HD Movies, I'll need bug reports from somebody on if these work or not :)

Also, this was compiled against Java 5.0 so if it gives errors, try:

http://rapidshare.com/files/11615854/BackupHDDVD.rar which was compiled as 1.4 compat.

beaups
14th January 2007, 06:34
Okay, congrats to those who have won round one and yes--the keys are on the disk, but they are encrypted keys on the disk. We still need an (unrevoked) player to decrypt new keys for us or even play old encrypted disks. If your player is revoked, it's end of round one; you won't even be able to play old titles! Here's why: Take a look at Fig. 4-1 of AACS_Spec_Common_0.91.pdf. It appears that the drive holds a Host Revocation List and the host holds a Drive Revocation List. Maybe I'm missing something here but it seems that the first time you place a disk that contains any given player in its revocation list into the drive, that player will forever more no longer function with that drive--even after a fresh reinstall of the player software. Drive firmware hacks may soon be useful.
What would prevent somebody from modifying their "player key" so that it is unique and not in the "revocation list"?....

Warren
14th January 2007, 06:38
What would prevent somebody from modifying their "player key" so that it is unique and not in the "revocation list"?....

Nothing except for the fact that the player will no longer be able to decrypt anything to play it.

beaups
14th January 2007, 06:41
warren can you please explain why the software player would no longer work?

OverlordQ
14th January 2007, 06:50
http://www.thedarkcitadel.com/svn/BackupHDDVD/

Public checkouts, passworded commits.

woah!
14th January 2007, 06:52
http://rapidshare.com/files/11616301/BackupHDDVD.rar

2 'requested' features added:

1) Will report the calculated Disc Hash
2) If Hash not found in key file, will add it after prompting for the name of the movie.

Given I don't have neither HDDVD Drive nor any HD Movies, I'll need bug reports from somebody on if these work or not :)

Also, this was compiled against Java 5.0 so if it gives errors, try:

http://rapidshare.com/files/11615854/BackupHDDVD.rar which was compiled as 1.4 compat.


works great here to show the hash thx :)

Backup HD-DVD V1.00 (OQ Mod 0.1) Starting
Testing source
Found valid HD-DVD source.
Disc Hash: 0E75082678AAD5CD4410A28A662D6832D21EB325
Look for this movie in my database
Found movie: King Kong
Start backup on Sat Jan 13 21:50:06 PST 2007
Scaning video directory
Processing BLACK.EVO key = 3

also i have waterworld i havent done yet and yes it asked for the name and added it to the key list with the hash etc...

B5DE266362701D2E7C36A5F389855F2B7DB6A17F=waterworld |V|0/13/2007|00000000000000000000000000000000

but as i havent got the hang of getting the vlk from the memory myself i have no waterworld key yet.

melakai
14th January 2007, 07:02
warren can you please explain why the software player would no longer work?

If you change the device key arbitrarily, it won't be able to obtain the media key, which is needed to get the title keys. The value would have to be changed to a different Kd_i.

3.1 Device Keys
Each compliant device is given a set of secret Device Keys when manufactured. These Device Keys, referred to as Kd_i (i=0,1,…,n-1), are provided by AACS LA, and are used by the device to process the MKB to calculate Km (Media Key).

1.8 Terminology
Media Key
A key that is used to unlock the Title Keys stored on a media that contains Titles protected by AACS. The Media Key can be computed by successfully processing a MKB.

OverlordQ
14th January 2007, 08:57
works great here to show the hash thx :)


B5DE266362701D2E7C36A5F389855F2B7DB6A17F=waterworld |V|0/13/2007|00000000000000000000000000000000

but as i havent got the hang of getting the vlk from the memory myself i have no waterworld key yet.

Meh, looks like I flubbed up the Month.

popper
14th January 2007, 09:50
as a side note,i thought this was an interesting comment as regards HDDVD/BR
Flash will kill Blu-ray and HD DVD
http://uk.theinquirer.net/?article=36930

flash memory is all well and good but i find it iritating that the superslow USB became the standard for interfacing it. its about time we had a FAR faster interface so as to get far better read/write from any flash device ,it seems we need at the very least an updated far faster USB3 to be introduced and PDQ...

hajj_3
14th January 2007, 10:39
lets stick to uploading to sendspace.com, rapidshare is pants! wait times, things get deleted if they are reported etc.

keep up the good work adding features!

blutach
14th January 2007, 11:05
@popper

Apparently you do not read what Doom9 and I write. Strike issued.

Stick to the topic. "Interesting" things between BR/HDDVD do not belong in this thread.

Regards