AACS decrypted... keys in memory

[manwithnoname]

Nice post chrestomanci, food for thougth - so much so I've got a bit of indigestion.

Interesting idea of allowing firmware updates of hardware players once keys have been leaked. This might be a catch 22 for Hollywood, how do protect the firmware? Encrypt it – but you need the to allow the hardware player to decrypt it, but the reason why you need the update is because the current key that you could decrypt it with has been leaked

Does any one know if a DVD hardware key has ever been leaked?

[Funkstar]

All the DVD keys were discovered when someone broke CSS. It had holes which made a brute force approach possible. AACS doesn't have these holes and no new ones have been found yet.

[Gordy]

(Yikes!, that was a much longer post than I expected)

Superb post very informative

[chrestomanci]

Interesting idea of allowing firmware updates of hardware players once keys have been leaked. This might be a catch 22 for Hollywood, how do protect the firmware? Encrypt it – but you need the to allow the hardware player to decrypt it, but the reason why you need the update is because the current key that you could decrypt it with has been leaked

It would still be worth encrypting firmware, as not everyone will have access to the player key after it has been compromised. Also routine firmware updates will be put on discs as well as emergency ones so if Hollywood thinks that hackers are close to cracking a player key they can release an update to close the loophole. Finally there will also be rouge firmwares out there that ignore region coding, macrovison or HDCP, so those will need replacing as well.

Even if the firmware is in the clear, the key will be well hidden within the binary. It will be stored encrypted and then decrypted on the fly. It may be in several partly overlapping parts that produce the encrypted key when they are XORed together in the right way. The key that decrypts the main key will be similarly hidden (or built into the player hardware). The machine code that does the decryption (HDCP, Region coding etc) might also be encrypted so that it cannot be found by searching the binary, and cannot be patched to disable it. Basically the only way to recover the key will be to for someone to read and understand almost every part of the firmware binary, and emulate the relevant sections to recover encrypted, obfuscated keys.

If the player hardware is implemented properly it will be very hard to recover keys from it, as all the debug interfaces will be removed from production hardware, the main buses will be put on a middle layer of a multi-layer board so they are hard to reach, or just encrypted.

Basically what I am saying, is that if the player manufacturers get all their ducks in a row, key recovery will be very hard. On the other hand there will be players designed in a rush with corners cut, and those cut corners will make key recovery possible. For example all that key obfuscation should have been present in the software player that muslix64 cracked. Obviously it was not. There will be more similar mistakes.

[manwithnoname]

Informative once again chrestomanci.

I must admit I'd be surprised if someone managed to extract a key from a hardware player.

The software players, at my very simplistic '101 encryption decryption' level, the key must be in memory somewhere while the disc is been played. You mention Windows Vista disallowing memory been read by other programs, my simplistic '101 programming' could any of these work?
1) Development tools and debugger not allowed on Vista?
2) Is it not feasible to a write a window program that could host another (ok that sounds like a bugger)
3) OK I am collecting straws ... How about that suspend to disk function I sure someone could scan the ~4GB file for the key quite quickly - assuming you can hibernate during the playback

[chrestomanci]

Informative once again chrestomanci.

Thanks.

I must admit I'd be surprised if someone managed to extract a key from a hardware player.

True, but rember that hardware players are just specialised computers, but unlike PCs they have much simpler operating systems and hardware, so for someone familar with the tools it would be easer to reverse engeneer than a whole windows PC.

Also hardware players are deleloped by regular guys like us. Some of those people might not agree with DRM, and might choose to leak the source code for firmware, or keys. They will also know the weaknesses and cut cornners in the designs they are working on, so they could give hackers instuctions similar to a walkthrough in an adventure game so they could go straight to the player key and brag about it without evidence getting back to the sofware developer who leaked.

The software players, at my very simplistic '101 encryption decryption' level, the key must be in memory somewhere while the disc is been played.

The disc key has to be in memory, but the player key need not be. Also as the disc key only needs to be decrypted once, the decryption algorithom can be obsucated to make it harder to follow with a debugger.

You mention Windows Vista disallowing memory been read by other programs, my simplistic '101 programming' could any of these work?

1) Development tools and debugger not allowed on Vista?

Development tools are allowed, but some programs can ask windows to forbid them from being debugged. Also under current versions of windows you can't run two debuggers on the same program at once, so some current media players prevent the main program from being debugged by having a small fake debugger attach to the main binary to lock out other debuggers.

2) Is it not feasible to a write a window program that could host another (ok that sounds like a bugger)

What you are describing is a simple debugger, or an emulator. Programs can detect if they are running in such an environment by benchmarking themselves, and then not decrypting their keys. In theory you could control all a program's inputs to prevent it detecting that it is being debugged but it would be a mamouth task, especially once phoning home via the internet becomes involved.

3) OK I am collecting straws ... How about that suspend to disk function I sure someone could scan the ~4GB file for the key quite quickly - assuming you can hibernate during the playback

Suspend to ram is a slow orderly process. Windows will notify all applications that a suspend is about to take place. (This allows network drivers to disconnect for example). When it gets a notifiction, a movie player can easily delete it's player key before suspension.

Another way to get a dump of all memory is to configure windows for a full kernel memory dump when it crashes, and then trigger a blue screen of death using a hardware exception from modified to be faulty hardware. Of-hand I am not sure how Microsoft plans to prevent keys from being leaked that way, but I dare say Microsoft have thought of a way.

[manwithnoname]

2) Is it not feasible to a write a window program that could host another (ok that sounds like a bugger)

opps meant to type ... (ok that sounds like a debugger). Would be a bit tricky to implement, maybe run the software player on unix/linux via 'Wine'?

The disc key has to be in memory, but the player key need not be. Also as the disc key only needs to be decrypted once, the decryption algorithom can be obsucated to make it harder to follow with a debugger.

Would the player key not need to be in memory for a short interval to access the disc key for the first time (bare in mind my 101 encrypted understanding) or have I got the wrong end of the stick.

[badass]

but I dare say Microsoft have thought of a way.

But will they bother? All they have to do is show that they are doing everything they can think of to protect HD movies.

[chrestomanci]

but I dare say Microsoft have thought of a way.

But will they bother? All they have to do is show that they are doing everything they can think of to protect HD movies.

When two paranoids get together they can worry about anything.

Hollywood is terrified that the new High Def formats will get cracked and coppied the same way that normal DVDs and music has been. They have read all the scare mongering reports from the music Biz about Trillions of dollars of lost sales. (every bootleg copy is a lost sale) and believed all those cooked numbers. Because of this, the new Blu-Ray and HD-DVD formats have very much over engineered copy protection.

Microsoft is also worried about piracy because they don't want any more pirate copies of windows out there, so a lot of the copy protection in Windows Vista is there to prevent windows getting pirated as much as it is about protecting movies. Microsoft are also obsessed about being in the centre of the digital home. They have concluded that most people will only want one home computer, so if they want to sell more coppies of windows they need the find another use for PCs, media centre being an obvious one. Therefore they are going to great lengths to make windows a good platform for watching high def content.

However, thanks to Hollywood's (Justifiable) paranoia, they need a lot of convincing that the platform is safe, so Microsoft have done a lot of work, and compromised the stability of vista in order to demonstrate that safety. For example they have added a 'tilt bit' that performs the same function as the tilt sensor on an old pinball machine. If any hardware, software or device driver notices something unexpected, such as a voltage spike then it must set the tilt bit so that cracking can be prevented. The problem is that if you live in the country where the local power or phones are a bit flaky, the tilt bit will get set frequently, interupting your movie viewing, or forcing reboots.

[chrestomanci]

Would the player key not need to be in memory for a short interval to access the disc key for the first time (bare in mind my 101 encrypted understanding) or have I got the wrong end of the stick.

Yes it would.

In theory, it would be possible to only have part of the player key decrypted in memory at any one time, and decrypt it in sections and use that section before destroying it and decrypting the next, I am not sure that the authors of any software player would bother with such trickery unless the DVD-HD or Blu-Ray specs specifically require it.

However once the Disc key has been decrypted the player key is no longer needed, and should be destroyed. If a hacker finds a way to trace the player software with a debugger it would be easy to isolate the player key, but if the hacker is reduced to taking memory snapshots, the chances of them getting the player key for the few microseconds that it is decrypted and in memory is very small.

[JPreston]

...

(Yikes!, that was a much longer post than I expected)

Well at least you know what your specialist subject would be when you get on Mastermind

Ta for the info!

[SomeoneNotQuite]

Probably already been said, but the most useful thing for someone to come up with is a way to play protected video without a HDCP graphics card and monitor. Forgive me if this is already possible, the things I've seen all relate to copying

[TheAnimus]

muslix64 has not actually done anything terribly clever, other than demonstrate than one software player is crackable, and stimulated a debate. The software player will be patched shortly, and in any case when Windows Vista comes out, it will be able to protect player software from having their memory read by other programs, so this hack will be impossible.

Absolutely, this is hardly clever but symptomatic of what is going to happen, someone will build an (illegal) database of decryption for disks, meaning that everyone who is paying for HDCP the victim. Its worth noting that if you really want to, you can read any proccess's memory, as long as your clever, and the stream isn't fully encrypted. But again, this must be possible to get round.

Now its not something i disagree with in principle, when your having that nice friday pint in an area like bank, in a pub which is £5 a pint (hey it wasn't my round ) and some chinease imagrent comes in selling pirate DVDs, these will be single layer crap, and they want £2 a disk. I sudenly do feal sorry for the movie people.

Whilst most CD users are "mate check this out", i've never been harrased by someone selling me bootleg audio CDs. Quite frankly because £2 an album is still too much money imo.

Now we drunk, decide that we should ring 999 and see how long it takes the city of west minister finest to respond. They didn't bother.

The thing is, with the exception of over hyped new releases DVDs are priced imo rather fairly. Unlike music. £5-8 seams to be most films, crammed with those specail editions that you never watch.

So i don't mind in principle them putting protection system into place, as long as they pass the savings of increased title sale onto subsidise the hardware.... which they don't. But again, its not too much of a cost. I will live with it.

The problem is once someone has broken it, its all rather pointless, also we know its joe user that will be inconvienced by the next actions taken too curtail piracy!

[charleski]

in any case when Windows Vista comes out, it will be able to protect player software from having their memory read by other programs, so this hack will be impossible.

It's not the first time I've read people alluding to this, but will this be true on Vista 32bit? I know you need to boot with a custom option to run a kernel debugger, but what concrete security is in there? Anyone have any technical links?

[TheAnimus]

I'm not sure if its the same as the kernel protection, but can be bypassed.

I'd imagine it could in 64bit too, the main complaint crackers have with 64bit is to do with the IDT and the thunking of NT.DLL...... but this is off topic.

It will be possible when its using standard PC hardware.

[chrestomanci]

It's not the first time I've read people alluding to this, but will this be true on Vista 32bit? I know you need to boot with a custom option to run a kernel debugger, but what concrete security is in there? Anyone have any technical links?

To be honest I don't actually know for sure, or have any links, I am just repeating what I have read elsewhere.

It would defiantly be possible for windows to prevent program's from reading each other's memory as the only way to do so at the moment is via APIs that the operating system provides, so it would be easy enough for windows to refuse for privalaged processes. (The reason this is possible is because the memory management unit in 386 or later CPUs puts each non kernel process in a private address space, and it cannot address memory outside that space except via system calls.)

However, it may still be possible to read memory if windows itself is running as a virtual machine on another OS. I was reading recently on kerneltrap.org about the KVM (Kernel-based Virtual Machine) project for Linux. Apparently they can sucessfuly run Linux or windows as an emulated virtual machine, and as they are just normal processes to the host, it is easy to pause, read memory or debug, and there is nothing that Windows or any program running under it can do about it.