Blu-ray Cracked

The Blu-ray DRM system has been broken, although details are scant. It’s the same person who broke the HD DVD system last month. (Both use AACS.)

As I’ve written previously, both of these systems are supposed to be designed in such a way as to recover from hacks like this. We’re going to find out if the recovery feature works.

Blu-ray and HD DVD both allow for decryption keys to be updated in reaction to attacks, for example by making it impossible to play high-definition movies via playback software known to be weak or flawed. So muslix64 work has effectively sparked off a cat-and-mouse game between hackers and the entertainment industry, where consumers are likely to face compatibility problems while footing the bill for the entertainment industry’s insistence on pushing ultimately flawed DRM technology on an unwilling public.

EDITED TO ADD (1/29): You should read this seven part series on the topic.

Tags: , , , , ,

Posted on January 26, 2007 at 12:47 PM • 26 Comments

Comments

nzruss • January 26, 2007 1:51 PM

They talk about this on Security Now, Episode #76 (http://www.grc.com/securitynow.htm)

It seems muslix64 just had a snapshot of the entire .exe running in memory, then used selective keying – serially trying bytes 1-4, then 2-5, 3-6 etc as the keys until the mpeg frame decrypted. (which, of course this is much faster than a pure brute force attack, and took only seconds).

So as long as a software player has the key in the clear and is loaded in memory ‘somewhere’, this type of attack will continue to work.

AACS is still ‘unbroken’ but like many failed encryption schemes, it was circumvented due to poor implementation.

Kalimba Mbira • January 26, 2007 1:55 PM

What is really broken is the whole “intellectual property” system in the USA and, I presume, in quite a few other countries. It irked me when I was a musician, and it now irks me in my current gig. Of course it’s about the money, but the money isn’t going to the places the laws intended it to go.

Aaron • January 26, 2007 1:57 PM

I wonder how this will affect the format competition… compatibility is a big deal here. It might be beneficial to let it stay cracked.

rastap • January 26, 2007 2:00 PM

“…for example by making it impossible to play high-definition movies via playback software known to be weak or flawed.” Appearantly they did not only find the key unique to the software player in memory, but also the volume key. Once the volume key is out and you block the player in question, the decrypted movie can still be watched in every other player. Also, if you keep it a secret which player you are attacking and only release the volume key, it could be difficult to find out which player to block.

Joel • January 26, 2007 4:12 PM

This isn’t actually a crack though, as I understand it that would mean the decryption keys aren’t necessary. From what I’ve seen this is just an implementation of the decryption algorithm.

AJ • January 26, 2007 4:16 PM

There’s a really good series about the AACS, HD and Blu-Ray cracking by Alex Halderman on Freedom-To-Tinker dot com, well worth reading if you want to know more details about the DRM aspects of this story.

X the Unknown • January 26, 2007 4:33 PM

@Joel: “This isn’t actually a crack though, as I understand it that would mean the decryption keys aren’t necessary. From what I’ve seen this is just an implementation of the decryption algorithm.”

@nzruss: “It seems muslix64 just had a snapshot of the entire .exe running in memory, then used selective keying – serially trying bytes 1-4, then 2-5, 3-6 etc as the keys until the mpeg frame decrypted. (which, of course this is much faster than a pure brute force attack, and took only seconds).”

I dunno – that technique seems pretty close to a reusable crack to me. Just implement your key-search code in some way that has access to the memory of the player-software (perhaps as a driver or other privileged executable). It’s then a simple matter of “press a button, wait for a sync” to crack the next set of keys.

Alexandre Carmel-Veilleux • January 26, 2007 4:57 PM

@Joel: It’s a crack in terms of AACS as a whole. Since while the block cipher hasn’t been broken, key recovery from memory is (on current PC hardware) an effective crack of the key management part of AACS.

In fact, unless the keying function gets put into a tamper-resistant package on the physical HD-DVD/Blu-ray drives, software players will always have this flaw. All they can do is make key recovery more difficult.

Timm Murray • January 26, 2007 5:11 PM

Joel: “This isn’t actually a crack though, as I understand it that would mean the decryption keys aren’t necessary. From what I’ve seen this is just an implementation of the decryption algorithm.”

Clearly, he cheated, so it doesn’t count.

It’s easy enough for Them to revoke the player keys that were broken for software players. Once their keys are revoked, software players can be updated with new keys and reimplemented in increasing obfuscated ways. It would turn into a cat-and-mouse game, but it does mean that titles keys for all movies thus far released could be broken and distributed.

If someone were to break the hardware keys on widely-used player, then it’d be very difficult to revoke those keys without a huge consumer backlash. Due to manufacturing problems, most of the hi-def players out there right now are either PS3s or the XBox 360 HD-DVD add-on. This is unlikely to change before the next holiday season (if even then). Getting the player keys for those two would be a fatal blow to AACS.

Due to oversight of player implementations by the media industry, all players no doubt have a lot of tamper-proofing and other obfuscation methods that will make breaking the keys on hardware players difficult. However, since the PS3 and XBox are such big targets, it only takes one person with a lot of determination to break it wide open.

ghostDancer • January 26, 2007 5:41 PM

As Timm Murray says the hardware players keys are going to be the battle, and as we know sometimes in the past the easiest format to crack is always the winner, so i wouldn’t be surprised that if the popularity of both formats it’s similar “suddenly” someone breaks the security of one of them (PS3/XBOX360) and makes it the winner as machine and as HD format. And i can’t imagine people taking the machines to the shops to renew their players keys.

The other Roy • January 26, 2007 6:09 PM

@X: I’d bet automated tools are only weeks away.

Is this this the death knell for DRM on a general purpose PC? I see a lot of cat vs. mouse coming up.

billb • January 26, 2007 7:30 PM

ghostDancer: I’d be willing to bet that the player keys in a PS3 or Xbox360 can be updated over the Internet in the same manner the rest of the firmware and other software on these devices can be.

YAAC • January 26, 2007 7:39 PM

@The other Roy

Is this this the death knell for DRM on a >general purpose PC?

That’s why consumers will soon have TPUs foisted on them inside the processor, and it’s also why Free Software (aka, Linux) will not be given access to the TPU. The TPU transforms a general-purpose PC into a media delivery platform, but even the TPU doesn’t help without NDA’s and other contracts that enable you to beat the (peripheral, 3rd-party) driver vendors into the stone age if they should program the TPU in such a way as to “open up” the closed platform. Consumers don’t benefit from a TPU, but they will want the media that will be made available only on TPU-enabled platforms. And so, they’ll be locked in to commercially-provided software as an unadvertised consequence of their hardware choice.

Roger • January 27, 2007 1:50 AM

@nzruss:
“So as long as a software player has the key in the clear and is loaded in memory ‘somewhere’, this type of attack will a continue to work.”

Well, no. So long as a software player has the key in the clear and is loaded in memory ‘somewhere’ under the attacker’s control, there will be SOME way to winkle it out. But this particular attack is rather trivial to defeat. Simply don’t arrange the four words / 16 bytes consecutively in memory (Gibson misspeaks, he clearly means 4 words of memory). Just how much added complexity this provides depends on both the size of the (expanded) key and the size of the memory image over which it is feasible to scatter it, but even with 4 words and less than a meg of memory to search, the attack as it stands at present becomes infeasible (over 2^^70 key setups and trial decryptions). (Of course, actually coding the app to spread the words around in a more-or-less random way is nontrivial.)

For some ciphers with very fast key schedules (e.g. XTEA), it would also be a fairly effective measure to split the key by XORing and/or modulo addition (actually, a mixture is even better, since it requires the attacker to combine the chunks in the right order). As many chunks as necessary could be created in this way. For example with 4 words of key material split into 16 by +, xor, +, xor; and spread pseudorandomly across just 256 words (1 kB), reconstructing the key by muslix64’s method is as hard as brute-forcing it.

Tracing execution backward to find the pointers to all the pieces of key will eventually defeat this countermeasure, but that is true for any software running under the attacker’s control — and with sufficient obfuscation, can be considerably harder than muslix64’s straight-forward method.

Sparky • January 27, 2007 5:44 AM

@Roger: What you propose only yet another method of obfuscation, which would indeed be more difficult to defeat, especially use automated software. However, you must also consider the fact the player is using this key all the time; if you would build a debugger (which is absolutely trivial in windows using the debugger api), and somehow managed to stop the thread at the right time, the key you’re after would be in present in one of the processor registers, which the debugger can read (the registers are copied to the thread context when a breakpoint occures).

Does anybody know if the PS3 and Xbox360 have key management in software or hardware? If it’s in software, it would be easier to compromise, but also much easier to update. If, on the other hand, it is done is hardware, it may still be updateable because it is probably in some FPGA that can be reloaded. However, the update file would have to contain the new keys…

Roger • January 27, 2007 6:23 AM

@Sparky:
“However, you must also consider the fact the player is using this key all the time”

That probably isn’t right — although I admit I don’t know the details of Blu-Ray, so I could easily be wrong. Most video encryption protocols I have come across have a complex hierarchy of keys of varying importance and ephemerality. The key that is actually used to decrypt the video stream is a very low-ranking key which is used for just that one particular video stream (or possibly even just a few seconds of it). Cracking that key would in no sense compromise the entire system.

Whilst on the other hand, the highest ranking keys in the hierarchy — the ones that could compromise the whole system — would typically only be present in memory for a few dozen nanoseconds every few minutes. Thus stopping the thread at the right time could be exceptionally difficult.

(BTW, even with the low ranking keys, systems with software video decoding typically spend much long decoding the video stream than decrypting it. So stopping a thread at the right point to peak at a low ranking key may not be easy, either.)

greg • January 27, 2007 8:26 AM

First of all this is an attack. The attaker is alowed to cheat. Thats the rules of the game.

Another major point is how the keys are distributed. AACS is espesially weak agaist attacks across multiple players. Once you have enough keys they can no longer be revoked. This weekness was pointed out during the draft of AACS but they did not address it. That means you only a few poorly implemented products. HDDVD that won’t play on a computer will not go down well with conusmers or M$.

As for the standalone players, I doubt that there will be any serious tamper resitant hardware. Its just not cost effective.

The best solution is to not bother with DRM. It makes harware more expensive and unreliable and does not reduece piracy at all. Most folk think there is no protection on DVD’s because you just download copydvd.exe and then make a copy! And yet its more conveint for most to just buy the DVD for $10 (Thats all I pay, every title gets that low evetually).

Fact is pirates will pirate. Most will buy them from the shop anyway.

Oh and there is always the final way to “cheat” -Redigitize the signal from a hacked HDTV or computer monitor. You get some very small loss for you DRM free now digitial copy.

jbl • January 27, 2007 10:53 AM

I too heard the last three or so Gibson podcasts, which went into a lot of detail about the amount of resources in Vista devoted to DRM — for every version of Vista and for every PC, whether or not it will ever be used to play HD content or not.

I can’t help wondering what would have happened if Microsoft had “just said no” to the content providers. Among other things, all that work spent on building DRM into the OS could have been expended on enhancing the security of Vista. And how long would the content providers withstand the demand for the ability of PCs to play HD content?

bob • January 28, 2007 12:02 PM

@jbl
“I can’t help wondering what would have happened if Microsoft had “just said no” to the content providers.”

Why would they do that? It’s in Microsoft’s interest to become very cozy with Big Content. It’s in Big Content’s interest to become cozy with a Big Conduit company. Controlling content + conduit = profits, because it’s a toll road, not a free one.

And it’s also in MS’s interests to have DRM built-in, as distinct from added on. It makes the DRM that much harder to disable while still having a functional conduit (i.e. OS).

Dean Harding • January 28, 2007 4:54 PM

I can’t help wondering what would have happened if Microsoft had “just said no” to the content providers.

Not much, I’d say. Playing DVDs on Windows is a fraction of 1% of the market. I don’t think content providers would have many qualms about simply not providing their content on Windows if Microsoft did not provide a DRM platform for them.

But Microsoft want to sell Media Center PCs, so they need DRM.

Hopefully, the cracks for the DRM come out faster than the fixes and the content providers will finally realise that they just can’t win.

Craig Hughes • January 28, 2007 9:35 PM

If the HD-DVD/bluray industry stops signing movies with the keys for a given player, what is the remedy for those innocent consumers who have purchased one of those players under the promise that it would play HD-DVD/bluray movies?

Class action lawyers, start your engines…

X the Unknown • January 31, 2007 4:04 PM

@Roger: “(BTW, even with the low ranking keys, systems with software video decoding typically spend much long decoding the video stream than decrypting it. So stopping a thread at the right point to peak at a low ranking key may not be easy, either.)”

Back in my less-responsible days as an up-and-coming programmer, I got more enjoyment out of breaking copy-protection on computer games than in actually playing them. I never published cracks or cracked games, but I did get fairly good at it – and learned many important programming techniques therefrom.

Some of the copy-protection schemes were fairly sophisticated. On the Commodore-64, many of the schemes involved causing peculiar hardware faults in ways that were difficult to duplicate, under randomly-varying conditions and time-frames.

Whenever I encountered a new approach, it took a while (usually about an hour, but once a full day) to track down the relevant place(s) in the code. With a decent debugger, it’s just not as hard as you seem to think. Some sort of processing exception has to happen and be tested for.

If it seems to happen “at the same place” regularly, you just start single-stepping with “jump over subroutine calls”, marking your code location before each of these. When a given subroutine encloses the condition, you singlestep into that subroutine, and repeat the process. This very quickly gets you to the relevant section of code. Then you start setting traps on particular registers and memory-locations, and voila!

If the copy-protection kicks in “randomly”, you simply start where-ever the failure leaves you, and back-trace the stack. Set a breakpoint where you “came from”, re-run to that point, then backtrack the instructions as much as possible, and repeat. Again, you quickly issolate the section of code where “the stuff” happens. Analyze as necessary (possibly inserting your own code to “wrap around” a relocated version of the original, for more-detailed monitoring).

Multithreaded or multitasking code is more difficult, and didn’t really exist back when I was engaged in such behavior. However, I program in multi-threaded code today, and can’t see it significantly affecting my technique. You just have to trace into the new thread or process, set suitable breakpoints (which, in extreme cases might require an additional debugger instance), and get back out to the main processing loop. From there, the procedure would be basically the same, except you would be tracking multiple threads simultaneously.

And, of course, none of this addresses an attacker who has access to an ICE (In-Circuit Emulator). Against an ICE-based debugger, no possible functional software can be protected. If it runs at all, the ICE can know everything about the machine state at every (carefully-controlled and simulated) clock cycle. I haven’t looked into it, but I would assume that the emerging popularity of Virtual Machines should (soon, if not already) lead to the development of “Virtual ICE” systems.

What it boils down to, is that a program is an algorithm. An algorithm that you MUST distribute for it to be useful. If your security system does not rely on the obscurity of the algorithm (as in public key cryptography), then it may still work. However, if any portion of your security relies on simply keeping part of what you distribute “hidden”, then it is doomed to fail against any serious attacker.

Sure, nowadays we have some sort of legal proscription against “reverse engineering” security-related code. You could argue (probably successfully) that a debugging session such as I describe would innately require violating that law. Somehow, I don’t think that someone really intent on pirating commercial copyrighted material is going to be too deterred. Especially if they don’t intend to publish “publicly” under their own names.

The Blu-Ray DRM system sounds inherently fragile, to me.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.