BackupHDDVD, a tool to decrypt AACS protected movies

[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

  'AACS Content Protection Support - Secure your Blu-ray Disc titles with next-generation AACS Content Protection.'
  
  '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.'

• Movie Factory 5 Plus - Removed - Does not 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").

2. The Microsoft HD DVD Interactivity Jumpstart 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' 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]

Originally Posted by CiTay

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

Which version of vulnerable player software these companies produce doesn't really matter to me.

Originally Posted by CiTay

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]

Originally Posted by 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

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]

Originally Posted by 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.

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]

Originally Posted by hvatum

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

[Gradius]

Magic Memory = pure BS, don't believe on them!

[calinb]

Originally Posted by Isochroma

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.

The title keys also change between titles of the same disc. I proposed the same idea earlier in this thread and it could still be useful, if combined with other techniques, but a lot of other stuff (besides the keys) changes too.

I suggest that sensitive or perhaps even speculatiive brainstorming, that might be considered off-topic here, be conducted offline in an anonymous forum.

Install I2P and join the discussion:

http://forum.i2p/viewtopic.php?p=9157#9157

(The link doesn't work unless you've installed I2P)

Dear mods: if you've not ever used I2P and visited the I2P forum, I must assure you that it's not a warez site. It is simply a public site where users may speak freely with a high degree of anonymity. It is available to anyone who installs I2P software.

New I2P users: Let's keep it that way! This is about exercising Fair Use rights and no more/less!

[Isochroma]

@calinb: There is no need for secrecy: what was done in secret by the making of the HD-DVD and Blu-Ray copy protection schemes, will be undone in public.

Like good encryption, good decryption will not die by being exposed for all the world to see. In this case, the hardware standard is already set in stone, with thousands of players and lots of discs already sold, so that's not going to change.

As far as player software, that will always change, but it will be reverse-engineered too, using the same or better methods. Fundamentally, there is no way to keep the system closed as long as PC playback is a possibility.

The possibilities mentioned in my last two posts have no doubt already been thought of or are soon to be seen by player developers. The ideas are general, and apply to a wide range of possible cases; more like a sample guide for security auditing.

Perhaps most importantly, there is nothing player developers can do but issue an ever-growing stream of updates and new versions with ever more convoluted protection schemes, that will all be reverse engineered.

The only real threat to this kind of attack is a protective operating system, like Vista. But like russian dolls, cracks will be found and made at all layers, so even that will not stand long.

As for personal risk, I won't post anything here that is illegal in my country, or against forum rules, so I have nothing to fear. I hope this is the case for all posters, because all that needs to be accomplished can be done right here without any problems from either local policies or enforcement agencies, if users think carefully before posting.

[calinb]

Originally Posted by Isochroma

As for personal risk, I won't post anything here that is illegal in my country, or against forum rules, so I have nothing to fear. I hope this is the case for all posters, because all that needs to be accomplished can be done right here without any problems from either local policies or enforcement agencies, if users think carefully before posting.

Well--in the U.S. we have the DMCA. Other coutries have vairous "exported" versions if it. The DMCA contradicts Fair Use. As far as I can tell, this has not been resolved through either legislative or judicial process. Not everyone wants to risk becoming case law.

[Borbus]

I have tried to make a HD-DVD image with Scenarist. I can't test it because it's obviously UDF2.5 and mounting with Daemon Tools doesn't work. I can't find UDF 2.5 drivers. It's only 4.5MB so if it's not right it doesn't waste much bandwidth.

http://www.filehost.gr/643076

If anyone can get it to work, the keys should be:

C29E56D1E80EA92B010733C46A73DECA
6ACF5ADFCFD8A3D404D0DB6155229D36

I think the second one is for the main video. Not sure what the other one is for.

It's the first time I've used Scenarist so it probably is wrong...

By the way id anyone's interested I just made a blank 1920x1080 video with AVISynth and encoded it with Mainconcept h264. x264 doesn't work for creating compliant elementary h264 streams.

edit: the first one is the volume key, the second one is the title key for the single title in the ISO.

[Susana]

Daemon 4.0 works, I've just do it.

Played with windvd 8. 7 seconds clip.

Edit: extracting files with isobuster 2, plays same way. No aacs proteccion in that iso. ?? Remains in memory ??

[Isochroma]

Returning to the topic at hand - which in this case is the BackupHDDVD application - I'd like to extend my congratulations to Muslix64, who not only chose a username corresponding with my favorite cereal, but also made good effort to build an application which may help the cause of fair use.

The most valuable thing Muslix64 has provided by establishing this thread is not an application called BackupHDDVD, but an idea called YouCanBackupYourHDDVD.

Just by building an application which may or may not decrypt HD-DVDs, and dropping hints and clues in his posts and release notes, his ideas are now making lots of people think about how to make applications which can do the same or better.

Perhaps the YouTube video itself was the best inspiration; even if it was an utter fraud it provided and still provides a glimmer of the light at the end of the tunnel for fair use in the twenty-first century.

The hardest step to take is always the first one, but as soon as someone does, many more are both informed and inspired to follow. Of course, often that first step is over a cliff or into a deep quicksand, but that doesn't really matter.

What matters is that such an event changes many people's thought patterns from "we are victims" to "we can change this". The holdup is almost always a lack of will and faith in capability, not in intelligence per se., manpower, technology or money.

[Isochroma]

@Borbus: excellent work! I've downloaded the file but don't yet have the player to test with. Also it is late at night right now; I will write more tomorrow.

I can confirm that the ISO mounts fine with Daemon Tools, but Windows cannot recognize the filesystem; I don't have the UDF 2.5 driver installed (yet). I'd hoped that Scenarist might come with the driver, since it should also include the emulator.

@Borbus: can you confirm if anywhere in the package, is located the emulator?

Also, it is likely that the Microsoft HD DVD Interactivity Jumpstart includes a UDF 2.5 driver, since it would be rather pointless for a development kit of this type to not have it, hopefully?

I will install a UDF 2.5 driver tomorrow and report on further findings.

[Borbus]

Originally Posted by Susana

Edit: extracting files with isobuster 2, plays same way. No aacs proteccion in that iso. ?? Remains in memory ??

Really? But I set it up to use encryption, and the AACS files are there which aren't if you don't turn on encryption (edit: at least I think they are, they're in the output directory, are they in the ISO?). Any idea what I might have done wrong?

Here's a screenshot of me enabling AACS:

[condorito]

http://www.macfergus.com/niels/dmca/cia.html

Finally, 5 days, that's really, really @$@^$% up. I found that link. It's good reading, old though.