BackupHDDVD, a tool to decrypt AACS protected movies

[hartiberlin]

Okay, 2 keys are in this thread:

http://www.avsforum.com/avs-vb/showthread.php?t=774256

Please can somebody try it ?

It seems, it is forbidden here by the rules to post the keys...
as the text was already deleted above in the posting...

[feizex]

Good eyes. One is 32 bytes (chars). But it looks to be HEX chars. IE. 16 HEX pairs = 16 bytes = 128 bits.

The other is a strange length and looks to be date time plus padding.

271020061204

27/10/2006 12:04 and 02 padding

[VistaVick]

These are not the keys....but interesting finding nonetheless.

If they were the keys, plenty of people would have tried them already, as that thread was posted a while ago at one of the most popular forums on the net.

[aicjofs]

Come on guys. Look at the the specs for the love of....

The shorter number would be a Volume ID if anything (not Volume Unique Key), the second number says DKF (logically a Directory Key File, inside that file is the Directory Key encrypted, which needs the Volume Unique Key to be decrypted. Is this possibly the hashed version of DKF?). I don't see these as either the Title Key nor the Volume Unique key.

Defiently worth a try though, doesn't take any time if you have the equipment. At least the 2nd number is the correct length to try for HDDVDbackup.

I do see the pattern year/week/month/whatever which would mean decrypted. I can't even remember if the VolumeID is encypted or not, and I have read through those damn tech docs 3 times, once was just last night...(hard stuff to digest). The guy said he only posted part of the file so the rest would be fun to look at.

Either way this is not the solution we are looking for, it would just be one mistake on one movie, and that's about it.

[feizex]

"Either way this is not the solution we are looking for, it would just be one mistake on one movie, and that's about it."

Looking for a known key in memory is a lot easier.

But I agree these are not the keys. Here's your key...
TKF.BIN_FILE=<RANDOM>

[tjf]

...The shorter number would be a Volume ID if anything (not Volume Unique Key), the second number says DKF (logically a Directory Key File, inside that file is the Directory Key encrypted, which needs the Volume Unique Key to be decrypted. Is this possibly the hashed version of DKF?).

I bet it is the Encrypted Directory Key which is the last part of the DKF.AACS file (see chapter 6.3 of the AACS_Spec_HD_DVD_and_DVD_Prerecorded_0_912.pdf). Anybody with Hulk can confirm?

Also the rest of the txt file is in the hardforum thread I was linking before. To me it looks like some forgotten configuration file for the AACS encryption process.

[feizex]

Oh that's gold! He now claims that muslix's program does not work because he couldn't get it to play back.

DUH, you didn't have the correct key! :P

He effectively fed it garbage.

OverlordQ is spot on. ;)

[Adub]

Here is an interesting opinion upon the "motives" of Muslix64.
Insightful, to say the least.

Edit: Here is the link, sorry.
http://www.hdnowonline.com/Comment_Who_Is_Muslix.html

[tonyp12]

I just bougt a X360 HD DVD drive for $159 at circuit city

$199- $40 coupon
http://www.zshare.net/download/cccoupon12_24_06-pdf.html

I bet MS will see a spike in sales this month.

Getting HULK from netflix on Tuesday.

[blutach]

@tonyp12

And the relevance to this thread is what? Please read rule 3. You've been around long enough to know better.

I know you are not alone, so let me ask all posters to keep on topic please - and that is the decrypting of HD-DVD via HDDVDBackup.

I have also asked posters not to publish keys. We are clarifying this situation, but until then, I would ask you all to please not do so.

Thanks.

Regards

[aicjofs]

Looking for a known key in memory is a lot easier.

Would it narrow it down if you did the following? (I know you posted this from a difference reference, but it had different wording so I thought I'd add this one too) Reference from page 130 of HDDVD prerecorded book of the boot sequence.

In the boot sequence, the AACS module in the Player may keep the Title Keys in a secure manner. In
that case, the AACS module in the Player shall be reset and the decrypted Title Keys shall be cleared from the
system when the following conditions hold in the boot sequence:
i) A Player starts an initial boot sequence.
ii) The associated Disc is ejected.
iii) The Player loses power.
iv) Another boot sequence starts.
• This may be caused by a call of the API, Playlist.load().

example would be to eject the disc and see what memory is freed?

EDIT: You know another thing I was thinking about your date time observation. What if the unique key(volume or title) was just like what you described and not some creation of a random number generator? The key is the date time hour at creation and some padding, that key would always be unique...haha...I would bet tons of money that's not how it's done but I have seen many passwords over the years like this, can't imagine they would do it but it would be funny if we spent all this time and they used such a weak key.

[kmac61]

The root of this forum is about fair use and all the various ways you can exercise that right. Making a backup copy of your optical media to proect your investment, while valid, is just a small slice of the concerns and needs of those using Doom9. In the case of HD and BD media it's a non starter, you can't do it. Even if you could,why bother, it'd be much cheaper and easier to buy a new disk.
The only fairuse value of this program and thread is limited the needs of the op and the small # of people in a similar position, having HD compatible equipment with a break in the hdcp chain.The only question(s) then is can you bypass hdcp and should you be allowed to. Considering 99.99% of the people purchase Hd and BD discs do so because they can play them back this is an issue no great importance. Whether it's fair or not the few people in the op's position can simply upgrade the deficent hardware or wait till they can before buying into Hd or BD. Considering the mislead notoriety of the subject and the drift of this thread towards defeating aacs I would hope the mods lock it

[woah!]

Even if you could,why bother, it'd be much cheaper and easier to buy a new disk.


so i should just throw more money at the film industry? dont tell them that, as they will then make discs that corrupt themselves after say 6 months and you have to go buy it again, as that is surely cheaper than being allowed to make a backup of your bought media...

why dont they then just LEASE the discs out instead of using the word BUY a dvd.

[blutach]

it'd be much cheaper and easier to buy a new disk.
Why should you have to?

The only fairuse value of this program and thread is limitedAnd does the same hold true for a regular DVDs? The argument is spurious as well as being off topic.

I would hope the mods lock itThere is no need to do that and I'd be grateful if you would leave such decisions to the mod team.

Regards

[moshmothma]

Ok, tried the Hulk - here are my observations

1. The Hulk does not play in Powerdvd or Windvd for me. A few screens flash by and then a black screen.

2. However, while the flashing takes place I did a memory dump.
Turns out the clear text file from the Hulk disc is loaded with both programs probably because they are both in the root. I grep on the title string from the file and it is loaded several times into memory.

3. However, the contents of the file is the only place I find those keys.

4. Maybe someone else with the Hulk disc who can actually play it can try the same.

[Zag]

The root of this forum is about fair use and all the various ways you can exercise that right. Making a backup copy of your optical media to proect your investment, while valid, is just a small slice of the concerns and needs of those using Doom9. In the case of HD and BD media it's a non starter, you can't do it. Even if you could,why bother, it'd be much cheaper and easier to buy a new disk.
The only fairuse value of this program and thread is limited the needs of the op and the small # of people in a similar position, having HD compatible equipment with a break in the hdcp chain.The only question(s) then is can you bypass hdcp and should you be allowed to. Considering 99.99% of the people purchase Hd and BD discs do so because they can play them back this is an issue no great importance. Whether it's fair or not the few people in the op's position can simply upgrade the deficent hardware or wait till they can before buying into Hd or BD. Considering the mislead notoriety of the subject and the drift of this thread towards defeating aacs I would hope the mods lock it

I don't agree with you stance. I want to do is be able to buy an HD-DVD disc, rip it to my media server, put the disc back in it's case and up on my shelf where it will be safe. Play the movie from my media server as many times as I want without having to keep pulling the disc out of it's case. Total additional cost to me; None. If this program will allow me to do that you bet I will be doing it, I don't care what the suits in Hollywood say.

[quoll]

so where is DVD Jon amongst all this ?

[blutach]

quoll - you have waited 5 days to post this off topic remark?

I have asked and asked about keeping this thread on topic.

Please observe rule 3 - strike issued.

Regards

[blutach]

After discussion with Doom9, it has been decided to allow publication of decryption keys and logs. This in no way implies a relaxation of rule 6 - certain information still may not be published, such as IFO files (or extracts therefrom).

Regards

[Lord_KiRon]

Here is an interesting opinion upon the "motives" of Muslix64.
Insightful, to say the least.

Edit: Here is the link, sorry.
http://www.hdnowonline.com/Comment_Who_Is_Muslix.html

Loved this :)
Most of the comments either untrue or can be easily rebut but the conspiracy theory state of mind looks funny.

[CiTay]

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

[noclip]

After discussion with Doom9, it has been decided to allow publication of decryption keys and logs. This in no way implies a relaxation of rule 6 - certain information still may not be published, such as IFO files (or extracts therefrom).

Regards

I hope this helps the process, but I imagine everyone will be too scared of WIPO/MPAA lawsuits to post them anyway.

[Doom9]

Here is an interesting opinion upon the "motives" of Muslix64.
Insightful, to say the least.

Edit: Here is the link, sorry.
http://www.hdnowonline.com/Comment_Who_Is_Muslix.htmlA few pages ago, that's one of the articles I was thinking of when I wrote that I'm fed up with unfounded speculation. I realize we've been too lax in the past and have allowed this forum, or especially this subforum, with this thread and the fairuse4wm thread before it, to become a gossip column. It's time to correct that mistake so let me remind you to stay on topic or face the full brunt of the forum rules. If you ain't got nothing backed up by facts to say, then you must not post here - I'm sure there are places out there for speculation and gossip but this is not the place.

[Sureshot324]

Can anyone who's read the AACS spec tell me how the HD-DVD drive transfers the title key to the monitor? The title key is decrypted in the drive so it must be unencrypted when it is sent to the monitor. What stops this unencrypted key from being intercepted? Does it go directly through hardware without going into system memory?

[Doom9]

I think you're mixing up a couple things here. AACS is decrypted on your machine.. between your GFX card and the monitor we then have HCDP which is something else entirely (and afaik, but I could be wrong here, no disc uses ICT yet so the connection doesn't necessarily have to be encrypted).

[Jerky_san]

So.. if HD-DVD player companies claims its not in memory. If you take their comments with something more then a grain of salt what does it leave you?

1. Registers
2. Perhaps the heap? or swap memory on the hard drive
3. What about the video card memory? Couldn't it be possible to use the video card as a storage place? Mainly since it seems Vista is more toward using the video card then any windows platform.
4. Where else? I'm a programmer but I can't think of many other places..

We as a group need to start at one end of the rope and slowly climb up the hill knocking out each place where it could perhaps be. Where ever it is it has to be the for the entirety of the movie shouldn't it? Since you have to decrypt each key as it comes and I doubt they left 1 key to protect a whole feature. Thus it would perhaps call on the key before each section comes up for decryption and will have it ready.

[hvatum]

Here is an interesting opinion upon the "motives" of Muslix64.
Insightful, to say the least.

Edit: Here is the link, sorry.
http://www.hdnowonline.com/Comment_Who_Is_Muslix.html

Insightful? More like a bunch of conspiracy mongering and unfounded gossip. Try using your critical thinking skills: He used Java, Sun uses Java, so he MUST be working for Sun! I mean, it's not like there is anyone else who uses Java except for Sun. Seriously, it's not like there's over 100,000 projects on sourceforge.net written in Java, and it's not like Java is a good langauge for cross-platform development, obviously this guy must be working for Sun!

Honestly, if Sun were actually behind this why would they have it written in a language which would obviously lead back to them. Doesn't make any sense, this is far too risky given the possible repurcussions for their entire corporation, which cannot afford any kind of financial loss right now. Secondly, they don't really stand to gain very much if Blu-Ray wins, Java is an open platform, that's why it was chosen, not because it's profitable for Sun.

Secondly, the "it's mueslix son," um, NO. Very few actual Germans are going to write Mueslix if they can't use an Umlaut, because it looks dumb. Also they tend to be lazy, in online chat with Germans I have NEVER not ONCE seen a German type a "ue" or "ae" in place of a "ü" or "ä." The only person who would do that is an AMERICAN writing for their GERMAN class. If anything this strongly suggests he is a European, and shows how ignorant that poster on hdnowonlinefanboys.com is.

"4) As a defence, he claims to only own an HD DVD player, which would indicate to most that he is an exclusive supporter of the HD DVD format. Yet he releases a so-called "tool" like this, and publicises it in a big way, knowing full well the damage that it could cause the format."

Come on, this site is not even pretending to be unbiased. It's equally possible that he happens to have an HD-DVD drive because it's the cheapest way of getting a next generation HD-Drive for your computer right now.

I'm not going to bother tearing down the other points on that HDnow site, suffice it to say that whole article is a farce. Please stop posting links to it, first of all it makes you look dumb, secondly it distracts from the issue at hand...

PS. CSS was broken by a 16 year old Norwegian kid.

[hvatum]

So.. if HD-DVD player companies claims its not in memory. If you take their comments with something more then a grain of salt what does it leave you?

1. Registers
2. Perhaps the heap? or swap memory on the hard drive
3. What about the video card memory? Couldn't it be possible to use the video card as a storage place? Mainly since it seems Vista is more toward using the video card then any windows platform.
4. Where else? I'm a programmer but I can't think of many other places..

We as a group need to start at one end of the rope and slowly climb up the hill knocking out each place where it could perhaps be. Where ever it is it has to be the for the entirety of the movie shouldn't it? Since you have to decrypt each key as it comes and I doubt they left 1 key to protect a whole feature. Thus it would perhaps call on the key before each section comes up for decryption and will have it ready.

I just called Cyberlink R&D about this. And I must say, there is absolutely no way Muslix could have gotten the keys from WinDVD.

This is for one very simple reason: The keys are stored Cyberlink's new patented "MAGIC MEMORY." Yes, instead of using any physical method of saving data (Memory, Magnetic Hard Drive, CPU Register) they have avoided any security issues by storing the keys in a new super-secret memory which only WinDVD can access. When the operating system or any other process tries to access this memory the data there magically dissapears, and then re-appears when WinDVD needs it. Pretty cool, eh?

The data is moved around by a bunch of DRM gremlins, who live inside of your computer. :P

[VistaVick]

Magic Memory? Sounds pretty lame, not cool.

[blutach]

Insightful? More like a bunch of conspiracy mongering and unfounded gossip. Try using your critical thinking skills: He used Java, Sun uses Java, so he MUST be working for Sun! I mean, it's not like there is anyone else who uses Java except for Sun. Seriously, it's not like there's over 100,000 projects on sourceforge.net written in Java, and it's not like Java is a good langauge for cross-platform development, obviously this guy must be working for Sun!

Honestly, if Sun were actually behind this why would they have it written in a language which would obviously lead back to them. Doesn't make any sense, this is far too risky given the possible repurcussions for their entire corporation, which cannot afford any kind of financial loss right now. Secondly, they don't really stand to gain very much if Blu-Ray wins, Java is an open platform, that's why it was chosen, not because it's profitable for Sun.

Secondly, the "it's mueslix son," um, NO. Very few actual Germans are going to write Mueslix if they can't use an Umlaut, because it looks dumb. Also they tend to be lazy, in online chat with Germans I have NEVER not ONCE seen a German type a "ue" or "ae" in place of a "ü" or "ä." The only person who would do that is an AMERICAN writing for their GERMAN class. If anything this strongly suggests he is a European, and shows how ignorant that poster on hdnowonlinefanboys.com is.

"4) As a defence, he claims to only own an HD DVD player, which would indicate to most that he is an exclusive supporter of the HD DVD format. Yet he releases a so-called "tool" like this, and publicises it in a big way, knowing full well the damage that it could cause the format."

Come on, this site is not even pretending to be unbiased. It's equally possible that he happens to have an HD-DVD drive because it's the cheapest way of getting a next generation HD-Drive for your computer right now.

I'm not going to bother tearing down the other points on that HDnow site, suffice it to say that whole article is a farce. Please stop posting links to it, first of all it makes you look dumb, secondly it distracts from the issue at hand...

PS. CSS was broken by a 16 year old Norwegian kid.

Magic Memory? Sounds pretty lame, not cool.Please refer to Doom9's post 424 (http://forum.doom9.org/showpost.php?p=928419&postcount=424).

These posts simply perpetuate the discussion which is way off topic, which I have warned about many times before. It is clear my warnings have not been heeded.

Please confine your posts to BackupHDDVD and not about Muslix. Doom9 is not a chatline.

Strikes issued. Off post remarks will be struck in future.

Regards

[Jerky_san]

hmm if this "magic memory" is true then I wonder if it acts like a virus.. You know the ones when you attempt to delete them or go into the folder where you virus scan say they are they move to a different folder.. If this is true then its going to be a very hard climb up the mountain. Although I'm curious if anyone has been playing a movie and did a memory dump at the same time while still playing the movie? Does it keep playing? or Does it stop due to the key was just transfer to a different area. And how to does the program know where the transfer went? It would have to keep track of it somehow..

[hvatum]

hmm if this "magic memory" is true then I wonder if it acts like a virus.. You know the ones when you attempt to delete them or go into the folder where you virus scan say they are they move to a different folder.. If this is true then its going to be a very hard climb up the mountain. Although I'm curious if anyone has been playing a movie and did a memory dump at the same time while still playing the movie? Does it keep playing? or Does it stop due to the key was just transfer to a different area. And how to does the program know where the transfer went? It would have to keep track of it somehow..

hehe, as far as I know there is not actually any such thing as "Magic Memory." I was just satrizing Cyberlink, if the values are stored somewhere, then they must also be able to be accessed. Cyberlink's argument that it "could not possibly" come from WinDVD is a red herring, because Muslix never stated he got the values from memory .

[Jerky_san]

hehe, as far as I know there is not actually any such thing as "Magic Memory." I was just satrizing Cyberlink, if the values are stored somewhere, then they must also be able to be accessed. Cyberlink's argument that it "could not possibly" come from WinDVD is a red herring, because Muslix never stated he got the values from memory .

Yeah thats the kinda stuff blutach is talking about..

anyway


Btw: If HDDVDbackup works as it should and according to the above, it should set KEY_VF to 00b after decryption, otherwise a player would still asume the EVOB needs decryption - does hddvdbackup do that?? I´m no Java guy...

Well running through all the src I don't see where anything is set to that but it might be in a some part of the decryption that inside of the java stuff....

[Lange]

Finally i can post,

I'm not really into file hashes e.d. but i thought it is possible to get the original string back from a hash by the use of rainbow tables?

Same thing is done with MD5 hashed passwords on websites...

still offcourse Muslix64 has to have posted the original hashes from the keys

[He-Man]

Finally i can post,

I'm not really into file hashes e.d. but i thought it is possible to get the original string back from a hash by the use of rainbow tables?

Same thing is done with MD5 hashed passwords on websites...

still offcourse Muslix64 has to have posted the original hashes from the keys

:readfaq: Read the FAQ.txt file in backupHDDVD.zip!
The hash is not from any keys but it is the SHA1 Hash of the VTKF000.AACS file on your HDDVD disk.

-What is the TKDB.cfg file?

This is the Title key Database file. It holds the decryption keys for the movies.


-What is the format of this file?

Field 1: SHA1 Hash of the VTKF000.AACS file on your HDDVD disk.

[Borbus]

Since title keys are now allowed, here is one that is supposed to be for "The Hulk" HD-DVD:

554E4956455253414C5F48442D445644

It isn't necessarily for the feature, it could be for some of the other things like the menu etc. I haven't got a HD-DVD drive so I can't try it.

[CiTay]

Cyberlink's argument that it "could not possibly" come from WinDVD is a red herring, because Muslix never stated he got the values from memory .

Please remind Cyberlink to stop impersonating InterVideo (the makers of WinDVD), and also remind them that they are the makers of PowerDVD instead :D

He also stated that he found a key in memory: "I was very surprise to realize that the title key is there, in memory!"

[cyber1]

Since title keys are now allowed, here is one that is supposed to be for "The Hulk" HD-DVD:

554E4956455253414C5F48442D445644

It isn't necessarily for the feature, it could be for some of the other things like the menu etc. I haven't got a HD-DVD drive so I can't try it.

Read the AACS spec first.
That's a Directory Key, DKF.DK.

The only keys that is interesting is Titlekeys or Mediakeys, only these types will work with backupHDDVD.

[SvT]

Since title keys are now allowed, here is one that is supposed to be for "The Hulk" HD-DVD:

554E4956455253414C5F48442D445644

It isn't necessarily for the feature, it could be for some of the other things like the menu etc. I haven't got a HD-DVD drive so I can't try it.

This value is the ASCII code for "UNIVERSAL_HD-DVD".

Doesn't look like a title key to me :sly:

[Borbus]

Yes, you're right it is a directory key. I haven't read the spec but I just thought I'd help. It came from a text file which Universal probably accidentally put on The Hulk HD-DVD. A bit more:

// Directory Settings
[COMMON]
IN.ROOT=G:\TheHulk\TheHulk
OUT.ROOT=G:\AACS_output\TheHulk

// Volume ID Setting
[VID]
VID.UNQ_NO=271020061204020202020202

// Title Key Setting
[TKF]
TKF.BIN_FILE=<RANDOM>

// Title Key Setting
[DKF]
DKF.DK=554E4956455253414C5F48442D445644

// Managed Copy Settings
[MCM]
MCM.V-ISAN=0000-0001-4F66-0000-F-0000-0001-R
MCM.SERVER_URI=http://smc.universalhomentertainment.com/

So, the title key was random, damn.

[Isochroma]

The biggest bottleneck in the player vulnerability discovery process is that we are searching for two unknowns. The first is the title key, and the second is the location in memory, registers, files, etc. where the software player might store it. The logical option would be to eliminate as many unknowns as possible.

There is a much easier method to determine whether PowerDVD or any other software 'leaks' title keys, and to also test BackupHDDVD's ability to properly decrypt HD-DVD content, given a correct title key, than to try playing commercial HD-DVDs with unknown title keys on a drive few have and which requires a hacked UDF 2.5 driver to work.

First, rather than have to acquire a commercial HD-DVD movie disc and HD-DVD drive to enable reading of its contents, it might be easier to just make some HD-DVD content. Sonic Scenarist can author HD-DVD content, and also provides the ability to protect the content using standard AACS encryption:

Sonic Scenarist (http://www.sonic.com/products/Professional/Scenarist/quicklook.aspx)
'AACS Content Protection Support - Secure your Blu-ray Disc titles with next-generation AACS Content Protection. (http://www.sonic.com/products/professional/scenarist/features.aspx)'

'HD DVD Support - Offer your clients both Standard and Advanced Content HD DVD title creation. With direct access to the HD DVD specification, the only limit is your creativity. (http://www.sonic.com/products/Professional/Scenarist/quicklook.aspx)'

Movie Factory 5 Plus - Removed - Does not (http://www.ulead.com/dmf/compare2.htm) have AACS functionality (sorry!)

The authoring software will make the required fileset, but may not provide ISO creation functionality. However, thanks to PowerDVD's ability to play an HD-DVD from files in a folder, that is not necessary to test this particular player software.

For other softwares which require an actual HD-DVD drive for playback, there are two options:

1. The Sonic Scenarist software already includes a drive emulator ("Multiplexed software emulation of HD DVD Advanced Content Volumes (http://72.14.205.104/search?q=cache:HB351aJtR9UJ:www.transtec.nl/download.php%3Fid%3D3%26file%3DPro%252Fsonic%252FScenaristBrochure0406.pdf+sonic+%22hd-dvd%22+emulation&hl=en&ct=clnk&cd=3)").

2. The Microsoft HD DVD Interactivity Jumpstart (http://www.microsoft.com/downloads/details.aspx?FamilyID=f8ada3f5-0ec6-4392-84ab-cb4860db30ed&DisplayLang=en) is available. It provides an HD-DVD emulator for testing applications and is free to download provided you can pass the Genuine Advantage check.
Now we can make up a tiny 1920x1080 MPEG-2, H264 or VC-1 file, and using Scenarist create the HD-DVD fileset.

Most importantly, we now know the title key - in both its encrypted and unencrypted forms, since we authored the files.

Should our authoring package not provide the facility, the 'HD-DVD Authoring to DVD --+ Media (http://www.avsforum.com/avs-vb/showthread.php?t=667462)' thread on the AVS forum provides the required method to convert the HD-DVD fileset to an ISO image, which has been tested and found compatible with at least one hardware player; thus it should be compatible with software players also.

At this point, the player software can be tested on the files, either by direct playback (PowerDVD) or by emulation. With either the Microsoft or Sonic emulator installed, the ISO file can be mounted and read by software players which cannot play raw filesets.

It now becomes a trivial task to search memory and other places for the keys. It also becomes easy to find if and where in the player code vulnerabilities exist; since we know what the original keys are, we can simply search for them.

[Jerky_san]

..dang Isochroma that is a very good idea lol.. I'm doing that right now.. I'll report my results if any.. Also Ulead does have ISO ability but I'm not seeing the encryption ability anywhere..

[Borbus]

Yes, good idea, I'll try it too. Also we can see if BackupHD-DVD actually can decrypt our HD-DVD before searching for the location of the title or volume keys.

[hvatum]

Please remind Cyberlink to stop impersonating InterVideo (the makers of WinDVD), and also remind them that they are the makers of PowerDVD instead :D
Which version of vulnerable player software these companies produce doesn't really matter to me.

He also stated that he found a key in memory: "I was very surprise to realize that the title key is there, in memory!"

Yes, Muslix did state he found a key in Memory, but he did not state that the key was sourced from the DVD playing software made by cyberlink. If I recall correctly.

Secondly I take Cyberlink's statement with a very large grain of salt, obviously their software plays HD-DVDs, so the Title key must be stored somewhere in unecrypted form, at least for a short while. If it's stored somewhere, then it can be read from this location. Perhaps Cyberlink discovered some new programming method, which allowes them to access data which does not exist, but this would be the first I've heard of it.

[Shinigami-Sama]

the only way I could think of that they could even say that the key wasn't in memory would to do something very simple with it

fragment it in memory

have the first 8 bits at location 4
second 8 bits at location 65535
next 8 bits at 217
so on and so forth

so it would be rather easy to reconstitute the key but more difficult to track it down

[hvatum]

the only way I could think of that they could even say that the key wasn't in memory would to do something very simple with it

fragment it in memory

have the first 8 bits at location 4
second 8 bits at location 65535
next 8 bits at 217
so on and so forth

so it would be rather easy to reconstitute the key but more difficult to track it down

That's possible. However that still means the key does exist in memory - contradictory to Cyberlinks statement which seems to suggest they have discovered a form of CS black magic.

BTW: Is it possible to dump the values stored in CPU registers? Because at some point the key would need to be reconstituted so it can be used for decryption. Afterall, you can divide something up, but you still have to remember what all the parts together are at some point.

[Isochroma]

Even better, using the method in my previous post, multiple copies of the exact same content can be authored, with the only difference being the title key.

Then each can be played in turn, and dumps of the suspected key storage areas made (memory, registers, files, etc.). Comparing the dumps, the differences between them will point to the location(s) where key information is stored.

This process will significantly increase the ease, speed and reliability of software player vulnerability testing, while decreasing its costs and implementation complexity.

Furthermore, by running a player capable of non-emulated (direct file) playback within a debugger environment, the process may be automated.

First, a set of small test filesets authored from the same content is created, with the only difference being title key. Next, these sets are segregated each in its own folder at a known location on hard drive.

Next, the player application, provided it is capable of commandline specification of source fileset for playback, is fed the parameters on its virtual commandline within the debugger environment. After a preset time period determined by the tested initialization time, the debugger does a total or partial memory or register dump to a file, and terminates the running debug environment.

Next, the debugger either exits as specified or is terminated by scheduled task, using third party software if necessary. The next scheduled task restarts the debugger with different commandline parameters, which are passed into the player's commandline within the new debug environment. These parameters sequentially specify the various authored HD-DVD filesets and debug dump files.

When the sequence has run to completion, a binary compare utility can be launched interactively or via commandline or scheduled task with parameters specifying the debugger's memory dump files.

The binary compare utility will produce a difference file or files which highlight differences between the test runs, which can be examined by the user to rapidly narrow and finally discover key locations.

Finally, even if the authoring software does not provide the end user with either or both the encrypted or unencrypted title key, and even if the player software encrypts or scrambles the title key in memory, this method will at least pinpoint the location(s) used by the player software to store the key data.

If the authoring software provides either the encrypted or plaintext key, then it is also possible to, using different keys and repeated test runs, discover the relationship between encrypted key and scrambled encrypted/decrypted key in the player application's memory space, or alternately, find the code responsible for key storage allocation and/or scrambling.

Knowing the location(s) used and also knowing the player's scrambling algorithm (if any), it will be possible to, for a given player, write a software which runs concurrently and, provided the operating system does not enforce protected memory space, snoop the values for any real disc which the software player plays.

Finally, the scrambling can be undone to provide the plaintext title key, which can be provided to secondary decryption software, such as BackupHDDVD.

[hvatum]

Even better, using the method in my previous post, multiple copies of the exact same content can be authored, with the only difference being the title key.

Then each can be played in turn, and dumps of the suspected key storage areas made (memory, registers, files, etc.). Comparing the dumps, the differences between them will point to the location(s) where key information is stored.

Absolutely. This is the best way to do it which I can see.

[Borbus]

If anyone manages to make a HD-DVD ISO, put it on a filehost and link to it so we can all try to use it. I can't work out how to use Scenarist and I don't know what settings to use with x264 to get a compliant video.

[Shinigami-Sama]

That's possible. However that still means the key does exist in memory - contradictory to Cyberlinks statement which seems to suggest they have discovered a form of CS black magic.

BTW: Is it possible to dump the values stored in CPU registers? Because at some point the key would need to be reconstituted so it can be used for decryption. Afterall, you can divide something up, but you still have to remember what all the parts together are at some point.

it has to exist in memory for anything to be done with it anyways, its basic digital electronics

so they must have done some sort of obfuscation or something on the key so that they key itself is not in memory as a whole, but parts, cyphered etc... could exist and not be readable unless you know where and how it was done