Why Rosyna Can't Take A Movie Screenshot

adc - Sun 04 January 2015 - reverse-engineering, exploitation, cryptography, intel

If you're on an Intel machine that you've purchased in the past 2-3 years, that computer almost certainly has an Intel Management Engine. You might not know what that is, and that's okay. You may also be unaware that the operating system on your computer could be leveraging features in the Intel Management Engine when consuming DRM Media.

What is the Intel Management Engine?

It's a coprocessor sitting on the same die as your CPU(s). "The computer next to your computer" from Igor Skochinsky's [1] presentation is a really fitting description. It's the hardware component that runs Intel's Accessibility Management Technology firmware. The device evolved out of a conglomeration of technologies that were targeted towards enterprises -- for feature upgrades, anti-theft, and remote machine management. It can run specialized java code, a web-server, work with the Wi-Fi and ethernet cards, run off the power-rail when the main CPU is off, and much, much more. Any project manager reading this is already breaking into a cold-sweat thinking about all the bugs in this feature-packed technology. It almost sounds like I'm making this up, as this is seriously a lot of stuff for an embedded technology.

What does it have to do with DRM?

One of the features of Intel's Accessibility Management Technology is an implementation of an Intel technology known as "Protected Audio/Video Path" (PAVP). The goal of the technology is to deliver media content in a manner which prevents piracy, even in realtime. That is, an attacker trying to rip content is unable to employ simple screen-recording software to grab those pixels.

How does this even work?

Without diving into the details or reverse engineering much of this, this is roughly how PAVP via the Intel ME works on Mac OS X. Applications such as iTunes and Safari are able to communicate directly to an IOKit service in the Intel Graphics drivers via an IOUserClient. They can negotiate and send in encrypted DRM blobs with keys to the Intel Graphics drivers. In turn, the graphics drivers are able to arbitrate communication with the PAVP application in the Intel Management Engine over the PCI bus, and deliver those encrypted keys and DRM content blob addresses. The Intel Management Engine then has some magic sauce (re: secret keys) that allows it to decrypt DRM keys and then decrypt the DRM blobs. Next, the Intel Management Engine writes directly to protected video memory to allow the Intel Graphics hardware to display to a computer monitor.

So why can't Rosyna take a screenshot of a movie?

Because the pixels aren't there. They're in a protected region of memory that the host CPU can't access without a security bypass. Sorry, Rosyna [2]. And there you have it.

Obligatory Security Rant

Before I leave you with some links for further research, I'd like to share some personal thoughts about the Intel ME.

Given that the ME sits in a position where it can configure the chipset and operate on the PCI bus, there are some serious security implications here I wish I could mitigate. Among them is the ability of the ME to run arbitrary code on the host CPU via option ROMs or presenting a disk-drive to boot from. Also among those abilities is the possibility to perform DMA to access host CPU memory. And another one is the ability to configure and use PCI devices present in the system (such as the ethernet card).

As a consumer, I didn't ask for these features. It'd be great to turn them all off. A hardware switch even. And BIOS settings do have a way to "Disable" the ME. But is it truly disabled? It will still run some code at startup I assume. And given that the Intel ME's security model requires that the host CPU is less privileged than the Intel ME, how can the host CPU really turn it off? One example of how the ME is more privileged is the ability to walk around VT-d configuration when performing memory access, which is possibly something required to make PAVP secure.

What it comes down to is that I like to think I own my computer since I bought the hardware. But in reality, I can't own all of it since there's much more privileged firmware running than any of my code, and I can't truly turn it off as far as I know, and I can't really look at it, without an exploit...


To find your ME look in 'lspci' or device manager for Intel HECI/Intel ME or AppleIntelMEIDriver in 'ioreg' on a mac.

Proudly powered by bootstrap, pelican, python and Alex!