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.
It takes a while... (Score:5, Informative)
It contains a download link to the program.
Re:It takes a while... (Score:5, Informative)
Duggmirror [duggmirror.com] has a copy of the doom9 thread, as well as a link to the source code [rapidshare.com].
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)
Link (Score:5, Informative)
http://forum.doom9.org/showthread.php?t=119871 [doom9.org]
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.
Re:It takes a while... (Score:4, Informative)
(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)
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)
-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: www.aacsla.com 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:
ECC-160
AES-128
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:
12-08A3DC61910280F2...
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
0000000000
486198E3855B57CD40F6DC0C60645BDE8E1E9AC5=Van Helsing |19-0000000000000000000000
0000000000
3D357B0653A66176583C5218FD0149EAF8832FB0=The Last Samurai | 1-0000000000000000000000
0000000000
-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
Re:Not really cracked, more like circumvented (Score:5, Informative)
Re:nothing is perfect (Score:3, Informative)
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).
Re:Will every player key be cracked? (Score:3, Informative)
Re:What's the fuss,anyway? (Score:3, Informative)
Re:What's the fuss,anyway? (Score:1, Informative)
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)
Re:Will every player key be cracked? (Score:3, Informative)
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).
Re:What's the fuss,anyway? (Score:3, Informative)
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 [filmschoolonline.com]. The actual study referred to is here (pdf) [www.cst.fr]. The summary: 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.
Re:It takes a while... (Score:5, Informative)
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?
Cracked or no, still formats in search of a market (Score:2, Informative)
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)
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.
Re:Piracy not equal to Losses (Score:3, Informative)
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.
Re:nothing is perfect (Score:4, Informative)
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