Rootkit To Intercept Encrypted Video Stream - Possible?

[Jimerb]

Does anyone know if it would possible for a kernel level rootkit to intercept a video stream after it has been decrypted? (AACS encrypted video)

Since XP openly allows rootkits and Vista has a circumvention to enable it (patchguard can be disabled) that would mean that kernal level rootkits would -- in theory -- have the ability to get whatever information they are looking for from the operating system. They could also maintain a degree of stealth.

Or would tilt bits and the fact that Patchguard is set to disabled (in vista) prevent this type of monitoring?

[noclip]

Why not just use a kernel debugger on a second computer?

[Fahzuu]

Does anyone know if it would possible for a kernel level rootkit to intercept a video stream after it has been decrypted? (AACS encrypted video)

Well if it was - what would you plan to do with it?
We're talking about apx. 185 MB/s (!) of raw video data (audio not even counted).
If you want to capture that amount of data raw, you end up with 600GB per Hour.
And don't even start thinking about a decent realtime compression with anything below the CPU that is going to get to the market somewhere around 2010 :)

[legoman666]

not to mention finding a hard drive you could write to at 185mb/s :P

[Shinigami-Sama]

switched fabric SAN anyone?

Rackmount RAID-0 VIA GigE or Ultra-320 SCSI?

[HyperHacker]

It need not be realtime. Kernel access is more than enough to slow the movie way down or pause it after each frame to process. Or, just capture and compress as fast as you can, and then re-run the movie to get the frames you missed (may well take a few attempts, but should work).

The funny part is even if the OS does notify the programs about you having kernel access... you have kernel access. You can just hack that notification away. :p

[Fahzuu]

It need not be realtime. Kernel access is more than enough to slow the movie way down or pause it after each frame to process. Or, just capture and compress as fast as you can, and then re-run the movie to get the frames you missed (may well take a few attempts, but should work).

Well ok, then let's agree on it being "do-able" - somehow.
It sounds like at least a weeks work to rip a single disc though, and I'm not going to be lining up to do that :)

[Jimerb]

It need not be realtime. Kernel access is more than enough to slow the movie way down or pause it after each frame to process. Or, just capture and compress as fast as you can, and then re-run the movie to get the frames you missed (may well take a few attempts, but should work).

The funny part is even if the OS does notify the programs about you having kernel access... you have kernel access. You can just hack that notification away. :p

Correct. Once you have kernal level access all bets are off. You could technically create a program that communicates with a rootkit to enable or disable capture of protected content that has just been decrypted. (So you are watching a movie in one window with capture turned on in another program -- for example.)

Remember in this scenerio you wouldn't need to decrypt anything -- saving time and CPU resources. Your just processing already decrypted content. Your letting the media player do the hard work for you.

The part that I don't understand is what the insertion points would be in a typical media player that is capable of playing this media.

Do decrypted video streams reside in memory prior to being pushed out of the dvi port to a display? Or better yet -- prior to being scaled for the resolution of the display?

[3r1c]

couldnt the rootkit inspect every memory operation of the player and get the decryption key.

Regardless of what method they use (XOR etc..) to hide the key, the full decrypted key has to be available to decrypt the movie, so its got to be in memory at least for a split second for every decrypt operation.

[Mutant_Fruit]

the full decrypted key has to be available to decrypt the movie, so its got to be in memory at least for a split second for every decrypt operation.
Not necessarily. The full key might only be in memory for a single instant where it is converted (i.e. using a SHA1 hash) into a different "key" which is used to do the decryption. Then every 100 (or whatever) frames the actual key might be loaded back into memory where it is used to generate another psuedo-key for the next 100 (or whatever) frames.

So not only do you have to find the write variable in memory, it might only there for a split second every few hundred seconds.

Note: this may or may not be how AACS works. It's just an example ;)

[FoxDisc]

The full key might only be in memory for a single instant where it is converted (i.e. using a SHA1 hash) into a different "key" which is used to do the decryption. ....
Note: this may or may not be how AACS works. It's just an example ;)
That's not how AACS works. They need the key for the bulk of the movie, not some encrypted version of the key It will be hard to hide, since it is used so much. However, if they implement SBKs, then they need multiple additional keys, and each one of those will be used only briefly. They might be harder to find.

[stewwy]

Not necessarily. The full key might only be in memory for a single instant where it is converted (i.e. using a SHA1 hash) into a different "key" which is used to do the decryption. Then every 100 (or whatever) frames the actual key might be loaded back into memory where it is used to generate another psuedo-key for the next 100 (or whatever) frames.

So not only do you have to find the write variable in memory, it might only there for a split second every few hundred seconds.

Note: this may or may not be how AACS works. It's just an example ;)


If that is the case it would be simple to look for duplicate keys that loaded up every so often, it would actually be easier if they took that route as you would not have to guess when the key loaded!

[richardlee]

Something i've stumbled accross which very much prooves the concept is the VBootkit (Rootkit) from Nitin & Vipin Kumar. Which gives you full kernel access to vista. From that point you should be able to do anything at all.

Check the link for more info and interviews with the developers.

http://www.theregister.com/2007/04/26/vbootkit_authors_interview/

Here is a little snippet to whet your whistle.

Questioner: Can your vbootkit be used to avoid the DRM ?

Nitin & Vipin: Yes, the vbootkit can be modified to bypass the DRM stuff. Since the DRM has been implemented in such a way, so as if unsigned drivers are loaded, then DRM will not let you play the content. What vbootkit does is let you load code without the OS knowing that it has been compromised, and thus the vbootkit can be misused to bypass DRM.

They havn't released the vista source code yet, but versions for XP, 2000 and 2003, are availible. Might be worth looking into for those of you that know what your doing.

[mikeathome]

Hi,
just curios, would it be posssible to write/patch a display driver which outputs to a virtual -HDCP capable- DVI port and route that to a file? I guess it could give YUV compressed video data at full res. What would be the video rate here, something able to capture?

AND

Wow, I see a new quality of Trojan Horses coming, well done MS. Thank You!

mike

[Jimerb]

Hi,
just curios, would it be posssible to write/patch a display driver which outputs to a virtual -HDCP capable- DVI port and route that to a file? I guess it could give YUV compressed video data at full res. What would be the video rate here, something able to capture?



The catch with Vista is that all drivers must be signed. This is (in part) to prevent this type of tampering.

Also, the protected content can control on what devices and drivers they will run on.

However, having the ability to access to the kernel means that you have access directly to the hardware. You are also "on par" with the operating system itself. So in theory you could make the operating system suddenly not care if a driver was signed or not. You could also make the operating system think that your driver was another legitimate one.

Tricky but possible.