Slashdot Mirror
HD-DVD and Blu-Ray AACS DRM Cracked
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.
The site's Farked, Digged, and everything else already, but here's the forum this was first posted to: http://forum.doom9.org/showthread.php?t=119871
It contains a download link to the program.
Give a man fire, and you warm him for the night. Set a man on fire, and you warm him for the rest of his life.
ed2k://|file|BackupHDDVD.zip|17964|4860e9248663d52 dc47bfc98d61ec6d7|/
magnet:?xt=urn:bitprint:ZHZI65X7J4NIX7TU7KLDIZXIJA 62SXX7.OBRERVSGGVO4OMWW7JN7BPC2BPDCE2U5NBUVU3Y&xt= urn:ed2khash:4860e9248663d52dc47bfc98d61ec6d7&dn=B ackupHDDVD.zip&xl=17964
If anyone wants to try it out, here is a link to the executable and source code (Java)...
http://forum.doom9.org/showthread.php?t=119871
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.
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.
When information is power, privacy is freedom.
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: 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
Tired of free ipod spam sigs? Opt ou
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.
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).
I haven't studied this implementation, but techniques like salts can easily avoid known PT/CT pair attacks
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.
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.
May contain traces of nut.
Made from the freshest electrons.
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).
Live today, because you never know what tomorrow brings
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: 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.
Live today, because you never know what tomorrow brings
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.
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.
Je fume. Tu fumes. Nous fûmes!
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.
-- This and all my posts are in the public domain. I am a lawyer. I am not your lawyer, and this is not legal advice.
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
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.