Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Encryption Security Hardware

HD-DVD and Blu-Ray AACS DRM Cracked 432

EGSonikku writes "According to this article on Endgadget, the AACS DRM used in HD-DVD and Blu-Ray has been cracked. The program allows one to decrypt and dump the video for play on a users hard drive, or it can be burned to a blank HD-DVD and played on a stand-alone player. According to the accompanying video, a source release for the program will be made available in January. Time to get that $200 Xbox 360 HD-DVD drive?" Warning: this link contains video.
This discussion has been archived. No new comments can be posted.

HD-DVD and Blu-Ray AACS DRM Cracked

Comments Filter:
  • It takes a while... (Score:5, Informative)

    by FuturePastNow ( 836765 ) on Thursday December 28, 2006 @01:56AM (#17384754)
    The site's Farked, Digged, and everything else already, but here's the forum this was first posted to: []

    It contains a download link to the program.
  • by interiot ( 50685 ) on Thursday December 28, 2006 @02:03AM (#17384794) Homepage

    Duggmirror [] has a copy of the doom9 thread, as well as a link to the source code [].

    As another poster said, the package contains several title keys already extracted via some method. It's not clear how the author extracted the keys, or whether it's possible for the AACS people to revoke a player in order to prevent future keys from being leaked the way they currently are.

  • P2P links then... (Score:2, Informative)

    by _Shorty-dammit ( 555739 ) on Thursday December 28, 2006 @02:07AM (#17384808)
    ed2k://|file||17964|4860e9248663d52 dc47bfc98d61ec6d7|/ magnet:?xt=urn:bitprint:ZHZI65X7J4NIX7TU7KLDIZXIJA 62SXX7.OBRERVSGGVO4OMWW7JN7BPC2BPDCE2U5NBUVU3Y&xt= urn:ed2khash:4860e9248663d52dc47bfc98d61ec6d7&dn=B
  • Link (Score:5, Informative)

    by h4rdc0d3 ( 724980 ) on Thursday December 28, 2006 @02:07AM (#17384812)
    If anyone wants to try it out, here is a link to the executable and source code (Java)... []

    There is more detailed info in the included FAQ. The bad news is, the program itself isn't actually "cracking" anything. The author used publicly available AACS documents to write his own decrypter (e.g. just as PowerDVD or WinDVD would). The catch is, you must provide the decryption keys to this software in order to rip the movies from the disk.

    However, the good news is, it looks like he may have found a way to extract the needed decryption key(s) from the HD-DVDs. He doesn't explain how in the documentation or provide any keys, but if he figured it out I'm sure others will - and that means more advanced and powerful tools shouldn't bee too far off.
  • by Anonymous Coward on Thursday December 28, 2006 @02:14AM (#17384846)
    By giving out the actual per-disc keys, the guy has avoided the fate of the original decss hack which used a player key that was "revoked". Unless the "AACS people" can figure out what player key he used to get those disc keys, they can't revoke it, though they can re-author the disc with a different disc key for the next batch (which one supposes could be leaked the exact same way as the first, whatever that way is).

    (For those that don't know, every disc's content is encrypted with a key particular to that disc. That key is then encrypted repeatedly with all of the device keys that are currently authorized to play that disc. Presumably there are dozens or hundreds of spare unassigned device keys in there for future use, as well. Thus, the player uses it's device key to decrypt the matching copy of the disc key, then uses the disc key to decrypt the disc. In the DVD days, device keys wouldn't be "revoked" as such, they would simply quit being used on new discs, so the device could play all old discs, but would be unable to get a disc key for new ones. Not sure if AACS actually added an actualy revocation list for device keys that would completely disable the device, as it is apparently able to do for other cryptographic keys like the HDCP keys)
  • Sort of Cracked (Score:5, Informative)

    by Jah-Wren Ryel ( 80510 ) on Thursday December 28, 2006 @02:16AM (#17384858)
    It sounds like he didn't "crack" AACS, he just extracted the disc keys for certain titles.

    A quick and dirty and probably somewhat inaccurate description of the way AACS works is that each disc is encrypted with a single 'disc key' and then that key is encrypted once with every known 'player key,' and each of those is stored on the disc. So, if you have an authorized player, it will find the version of the disc key that it knows how to decrypt and then use that to decrypt the disc for playback.

    My guess is that he used one of the software players like WinDVD or PowerDVD that now sort of support HD-DVD and BLU-RAY. But instead of extracting their player key and publishing that, he played a disc in a debug environment and extracted the 'disc key' for that specific title.

    The studios thought that they would be able to 'revoke' disclosed player keys by just not using them on any discs pressed after the disclosure was made public. This guy's approach seems to be to distribute disc keys and then anyone with the same disc can decrypt that specific title, thus making it harder for the studios to guess which player keys need revoking.

    I think that this guy's approach will be most useful to widescale pirating because all it takes is for one person to decrypt a movie and share it with a billion of his closest friends. But the 'regular joe' who just wants to copy his BD-HDs to his hard disk for ease of playback or maybe to cut clips from it for his own home movie won't benefit because chances are, the keys for his particular discs won't be widely known enough for him to find them.

    So, I now look forward to various HD titles from disc (rather than from broadcast, which are already common if you know where to look) showing up on P2P and elsewhere, I'm still not purchasing any AACS playback system since the "crack" is not (yet) useful enough for me to exercise typical fair-use rights of format shifting and personal editing.
  • BackupHDDVD FAQ (Score:5, Informative)

    by Black Acid ( 219707 ) on Thursday December 28, 2006 @02:54AM (#17385050)
    B a c k u p H D - D V D F A Q

    -What is "Backup HDDVD" for?
    It can do backup copies of HD DVD movies that YOU OWN! I don't want anyone to do piracy here! This software is a good way to protect your investment, because I have notice that this type of media seems very fragile, if it's scratched a little or dirty, it won't play. It seems less tolerent than DVD format. (Higher density!)

    -What "Backup HDDVD" is doing exactly?
    This is a java based command line utility that decrypt video files (.evo) from a HD DVD disk that you own, to your hard drive and you can play them back with a HD DVD player software.

    -What are the system requirements to use "Backup HDDVD"
    1 - A Windows based system
    2 - A HDDVD disk drive
    3 - A HDDVD player software (like PowerDVD)
    4 - A HDDVD movie(s)
    5 - Java rutime 1.5
    6 - The possibility to access the content of the disk with a drive letter under windows.
    (you may need UDF 2.5 file system driver for this)
    7 - A lot of free hard disk space to backup your movies!

    -Was your first HDDVD movie hard to decrypt?

    It took me around a week to do. But I have wasted few days
    trying to work on too complicated approach. In fact, it is very simple.

    -How do you do that?

    The program itself has nothing special. It simply implement the AACS decyption protocol. I have followed the freely available documents about AACS
    Have a look at: The trick, is to find what they call the "Title keys". So I figure out how to extract them.

    -How do you extract the "Title keys"?

    I won't explain it in detail. Read the AACS doc first. You will understand. The title keys are located on the disk in encrypted form, but for a
    content to be played, it has to be decrypted! So where is the decrypted version of the title key? Think about it...

    -What kind of crypto algorithms are involved?
    Standards algorithms:
    Look in the AACS doc for more details.

    -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.
    Next fields are pipe "|" delimited.
    -Movie Title
    -A variable number of Title key, pipe delimited
    You have a key number followed by the key value like:

    Key values are 128 bits long, so 16 bytes, or 32 hexadecimal characters long.

    -The TKDB.cfg file provided with your program is empty or incomplete, what can I do?
    Here is my TKDB.cfg:

    CE6339246F34087AB355681DEB656D23DCD5BD86=Full Metal Jacket | 1-0000000000000000000000
    486198E3855B57CD40F6DC0C60645BDE8E1E9AC5=Van Helsing |19-0000000000000000000000
    3D357B0653A66176583C5218FD0149EAF8832FB0=The Last Samurai | 1-0000000000000000000000

    -What do you think of the technical aspects of AACS?

    The design is not that bad, but it's too easy to have an insecure player implementation somewhere. And just one bad implementation is all it needs
    to get the keys! There will always be insecure implementations of a player somewhere! And the "Revocation system" is totaly useless if you use
    the Title key directly.

    -Is there any known problems with the decryption?
    Yes. I call this problem the "Nav chain" bug. I realize that I have a lot of frame skipping at playback after the decryption, so I hunted down the problem. To avoid the frame skipping, I patch the video file. This fix allows smooth playback of the movie, but there are some side effects.

    -What are the side effects of the "Nav chain" bug fix?

    You cannot do fast forward, or backward using the round dial, but you can still use the progress bar to navigate through the film. So it's not that bad... For some reason, the sub-titles don't seems to work anymore. It may be a side
  • by dtfinch ( 661405 ) * on Thursday December 28, 2006 @03:55AM (#17385238) Journal
    They have many keys now, one for each model of player. I don't remember the exact terminology, but the player private keys are used to decrypt the disk key stored on the disk. There are many copies of the disk key, each encrypted with a different player's public key. If they want to revoke a player, they just don't include a copy of the disk key encrypted with that player's public key on future disks. So that player can play old disks, but they'll need to replace it to play new disks.
  • by Sancho ( 17056 ) * on Thursday December 28, 2006 @04:10AM (#17385282) Homepage
    Trusted Computing solves this 'problem'. Debuggers won't be allowed to run on 'protected' programs, and this will be enforced on the hardware level (each program will effectively have to ask for permission to run).

    For right now, not everything has TPM. We'll see how this changes in a few years (almost all new computers do include the TPM chip).
  • by bigberk ( 547360 ) <> on Thursday December 28, 2006 @04:22AM (#17385346)
    I haven't studied this implementation, but techniques like salts can easily avoid known PT/CT pair attacks
  • by Rufus211 ( 221883 ) <[gro.hsikcah] [ta] [todhsals-sufur]> on Thursday December 28, 2006 @04:33AM (#17385384) Homepage
    Who said the source was 320p? The source for most movies is a 35mm film print. The current digital cinema spec calls for resolutions that are essentially 1080p and 2160p.
  • by Anonymous Coward on Thursday December 28, 2006 @04:46AM (#17385416)
    Commercially available 35mm negative scanners can extract in excess of 10 MPixel per frame. The Digital Imaging Project reflects this by stating that 35mm film should be encoded as native 4200 pixel in longest dimension (depending on actual aspect used this could mean 2600x4200 px). How much data is actually present in a given movie will depend on grain, process, age of film etc. The bits, in point of fact, are there.

    Oh, and there is no 70mm version of FMJ, it was shot spherically on 35mm and cut to 1.66:1 which means loss of 20% of image data, let's say no more than 4TB of uncompressed native resolution video. You'll get more from anamorphic movies, and a lot more from 70mm.
  • Re:Cheers! (Score:4, Informative)

    by Fred_A ( 10934 ) <fred@freds[ ] ['hom' in gap]> on Thursday December 28, 2006 @07:09AM (#17385898) Homepage
    Anyone over the age of 40 I've talked to about the two formats has said, "What, you mean like Betamacs and VHS?"
    Or even (for the ones with the better memory), "What, you mean like Betamax, VHS and V2000 [] ?"
  • by Kjella ( 173770 ) on Thursday December 28, 2006 @07:22AM (#17385958) Homepage
    Since you have the plain text (of the title key) and each of the cypher texts(the encrypted title key), aren't there attacks to figure out all the player keys?

    The short answer: No, AES is a strong crypto (though fundamentally broken when applied as DRM) and there's no known way to extract the player key no matter how many title key plain/ciphertext pairs you have. A typical example would be a SSH connection where you don't know the key, but can send plaintext, it doesn't help you. It might possibly help in reverse engineering the player key though, but only because it's broken as DRM (the decryption keys and decryption machine is under your control).
  • by Kjella ( 173770 ) on Thursday December 28, 2006 @07:57AM (#17386074) Homepage
    How much data is actually present in a given movie will depend on grain, process, age of film etc. The bits, in point of fact, are there.

    That's not a meaningful statement, I can have endless bits which will consist of nothing but random noise. As for how many lines of resolution is actually achieved by film, you can read here []. The actual study referred to is here (pdf) []. The summary:

    Measurement Lines
    Answer Print MTF 1400
    Release Print MTF 1000
    Theater Highest Assessment 875
    Theater Average Assessment 750
    So basicly, good film is HDTV (between 720p and 1080p somewhere). Film transfered directly to digital has about 1400 lines of resolution, which is better than current direct digital productions, but not by much (most production grade is 1080 lines, and so are people's HDTVs). Of course, while this is done using 'typical' equipment it's of a resolution chart under excellent conditions, I expect an actual movie would have less.
  • by simm1701 ( 835424 ) on Thursday December 28, 2006 @07:59AM (#17386082)
    Actually thats only true in secret single key cyphers - having the plain text (the disc key) and the cypher text (the encrypted disc key) gives you a point of comparison.

    Obviously if you are using something like a ceaser cypher its now trivial to get the player decryption key.

    With public/private key cyphers you are given the public key. This means you can have an unlimited number of plan text, cypher text pairs and in theory it will still not get you any closer to discovering the private key than when you just had the public key.

    I doubt that these data points will be particularly useful in decoding the entire collection of player keys.

    However given the size of zombie networks out there.... what do you think profession dvd pirates are going to do?
  • by punterjoe ( 743063 ) on Thursday December 28, 2006 @09:14AM (#17386460)
    Maybe if the powers behind the format had put aside their petty squabbling and released a single format, they could have devoted their energy to finding a market for the format. Now they're busy battling each other for market share, yet this competition doesn't seem to be benefitting consumers. By the time they have a format inexpensive & useful enough, a new format will have likely come along & crptured the public's attention anyway.
        HD is not a selling point. It may be useful as a marketing term. I hear many stories - and know some firsthand - of people who connect their flatscreen to a DVD or SD cable and think they have HD. Most people don't know the difference & can't be bothered to learn. Until their is one high capacity disc format, and it's affordable enough to compete against hard drives for storage or flash memory for portability, the manufacturers are wasting their time - and ours. Lack of DRM alone won't sell this.
  • Re:Cheers! (Score:5, Informative)

    by ajs318 ( 655362 ) <[ku.oc.dohshtrae] [ta] [2pser_ds]> on Thursday December 28, 2006 @09:29AM (#17386598)
    And the Sony C6 Betamax recorder, given a decent aerial, could record the Teletext signal along with the picture (even if your set was non-Teletext, since it's being picked up by the recorder's internal receiver). I never even realised VCRs weren't supposed to be able to do that. All those old Betamax cassettes in lofts and cupboards are hiding not only subtitles, but little vignettes of the news and sporting events of the day they were recorded.

    The only problem was that in order to get that resolution better than 280 lines (think about it - that's only chucking away 32.5 of 'em, which isn't bad), a Beta machine needed more moving parts than its VHS cousin (although they moved less often. VHS laced the tape when you pressed PLAY and unlaced it when you pressed STOP. All fast-winding was done inside the cassette -- which allows you to move the tape faster, but you cannot switch to picture-search without lacing it. Betamax laced the tape the first time you pressed PLAY and unlaced it when you pressed EJECT. Fast-winding was done inside the cassette until you first pressed PLAY [to allow for rapid rewinding before watching], and thereafter, with the tape laced; making it possible to switch instantaneously from fast-wind to picture-search.) Thus, VHS recorders were easier to field-maintain. And in an era before everything was made to be disposable, that was the deal-clincher.
  • by cpt kangarooski ( 3773 ) on Thursday December 28, 2006 @10:32AM (#17387068) Homepage
    The difference being that the (U.S.) law specifically protects the copyright holder from others selling his/her works without permission.

    No it doesn't. It says that no one can sell copies unless those copies were lawfully made, in which case, anyone can sell them (or give them away, or in most cases, rent them, etc.) without permission.

    However, cracking the encryption in order to copy the disc for backup purposes (or to transfer to a different medium) is protected by law (even the DMCA has a fair use clause) and in this case there's nothing illegal with cracking the DRM to get at the content you paid for (or otherwise obtained legally).

    No it isn't. Circumventing protection measures is nearly always unlawful, and fair use does not change that. This is because fair use only applies to making copies, not to circumvention. Circumvention is a distinct step for which fairness has no legal relevance. In order to not break the law, you'd have to make a copy without having circumvented the protection measure, i.e. without ever having decrypted the disc in the process, so that your backup copy was still encrypted. What the DMCA has to say about fair use is merely that it doesn't alter fair use, meaning that it doesn't reduce it (so that it didn't cover certain kinds of copyright infringements, which circumvention is not anyway), and that it doesn't enlarge it (so that it doesn't apply to circumvention, which was never covered under fair use to begin with). And there's everything illegal about circumventing DRM to get at the content you paid for.

    Also, making a backup, or shifting media, is not necessarily fair use. It will depend on the circumstances in each case. For some people, under some circumstances, it will be fair (yet still illegal if they circumvent in the process), and yet other times, not fair. It depends, and there is no bright-line rule.
  • by swillden ( 191260 ) * <> on Thursday December 28, 2006 @02:08PM (#17389580) Homepage Journal

    Trusted Computing solves this 'problem'. Debuggers won't be allowed to run on 'protected' programs, and this will be enforced on the hardware level (each program will effectively have to ask for permission to run).

    Yes and no. You're right about the effect, but wrong about the mechanism.

    The TPM can't control what programs can or cannot be run, so it's not correct to say that disallowing debugging of protected programs will be enforced on the hardware level.

    The enforcement will be done purely in software, by the operating system. What the TPM will do, though, is to provide a place to securely store the player key, and to bind that key to a specific operating system environment. Boot a different OS, or modify some part of the OS that is considered important for security and the player key will no longer be available.

    So, if you use the unmodified OS, it will note that the DVD playing software is not "debuggable" and will not allow your debugger to attach to it. If you try to patch the OS to force it to allow debugging, then the player key won't be available to the player, so you can't grab it with the debugger.

    Note that in order for this to work, there must be no exploitable security holes in the OS that allow you to patch the OS after it's been booted into its fully functional state. This is because of the way that the TPM "binds" a key to a given system state.

    Basically, during the boot process each chunk of code feeds data to the TPM. The TPM hashes all of this information into a Program Control Register (PCR). This hash value in the PCR is what represents the system state. To bind a key to the PCR, the TPM simply XORs the PCR with its internal master key and uses the result as an encryption key to encrypt the bound key (in this case, the player key). Retrieving a bound key works the same way: The TPM reads the encrypted bound key from disk, XORs the current PCR value with the master key and uses the result to decrypt the bound key.

    If you boot into a different OS, or in any other way change the data that is fed to the TPM during boot, then you change the PCR value. Different PCR means different result when XORed with the master key, means different result when the bound key is decrypted.

    So, to make such a protection system work, it is necessary that all of the software that is used to enforce the protection be part of the data that is fed to the TPM for hashing into the PCR. BUT, if you can exploit some hole to patch the software *after* the PCR has been fully initialized, then you're golden.

    Another way that attackers can try to work around the TPM is by snatching the key before it's bound to the TPM, or by arranging for it to be bound to an already patched OS. Most likely, software player manufacturers will try to work around this by asking the TPM to "attest" to its configuration (meaning its PCR value) before giving out a key.

    It's not clear how well that will work, though, because it means that every booted Vista system has to have bit-for-bit identical software so the player mfg can know what the "valid" PCR value is (well, large groups of Vista systems have to be identical, giving the mfg a set of valid PCR values). That doesn't seem like a problem until you realize that part of the data that has to be hashed into the TPM to make the system secure is the BIOS/EFI code. Because if an attacker compromises the code at that level, any protections the operating system tries to implement are irrelevant.

    It may be possible to use a string of attestations, one for the PCR value from each stage in the boot process to work around *that* problem, but it's not clear how feasible that is.

    Bottom line: The TPM will be used to strengthen DRM systems, but it seems pretty likely that it will be defeatable (and defeated) in many ways. This is because TCPA wasn't designed as a copy protection system, or to prove to third parties that the machine won't violate DRM. Rather, it was designed as

"If it's not loud, it doesn't work!" -- Blank Reg, from "Max Headroom"