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.
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.
May contain traces of nut.
Made from the freshest electrons.
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!
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.