Author: AlexIonescu

# Views: 1704

I apologize for the lack of news, but after attending CUSEC, I had to spend my time on catching up the two weeks of school and work that I had missed, and exploiting Vista ended up going on the backburner, especially as I had to re-install VMWare 6.0 (which wasn’t being helpful with me) and a new Vista 64-bit image.

That being said, it turns out the code I’ve written does not work out of the box on a Vista RTM system. Although it can be effective when combined with a reboot, this doesn’t provide any advantage of any of the myriad other ways that this could be done (including booting with the disable integrity checks BCD option or the /TESTSIGN flag).

However, it does bypass DRM. As part of the Protected Media Path, (PMP), Windows Vista sets up a number of requirements for A/V software and drivers in order to ensure it complies with the demandes of the media companies. One of these features, which has been heavily criticized as being the actual reason behind driver signing, is that “some premium content may be unavailable” if test signing mode is used. Originally, I assumed that this meant that the kernel would set some sort of variable, but this didn’t make sense: once your unsigned driver could load, it could disable this check. After reading the PMP documentation however, it seems to me that the “feature” explained is more likely the cause of this warning on premium content.

This feature is the ability of the PMP to notify A/V applications that there are unsigned drivers on the system, as well as provide a list of unsigned drivers. The idea is that the application can either outright refuse to play content, or that it can scan for known anti-DRM drivers which might be attempting to hook onto the unencrypted stream. This leads me to believe that it’s up to applications, not the OS, to enforce this DRM check.

The great thing about the code I’ve written is that it does NOT use test signing mode and it does NOT load an unsigned driver into the system. Therefore, to any A/V application running, the system seems totally safe — when in fact, it’s not. Now, because I’m still booting with a special flag, it’s possible for Microsoft to patch the PMP and have it report that this flag is set, thereby disabling premium content. However, beause I already have kernel-mode code running at this point, I can disable this flag in memory, and PMP will never know that it was enabled. Again, Microsoft could fight this by caching the value, or obfuscating it somewhere inside PMP’s kernel-mode code, but as long as it’s in kernel-mode, and I’ve got code in kernel-mode, I can patch it.

To continue this game, Microsoft could then use Patchguard on the obfuscated value…but that would only mean that I can simply disable Patchguard using the numerous methods that Skywing documented in his latest paper.

In the end, the only way that PMP is going to work is with a Hypervisor, and even that will probably fail.

Unfortunately, with almost 0% use for the open source community (which can use test signing mode for their drivers), documenting my method and/or releasing a sample might be viewed as an anti-DRM tool, and defintely a DMCA violation. Although used on its own, this POC doesn’t do anything or go anywhere near the PMP (I don’t even have Protected Media, HDMI, HD-DVD, nor do I know where PMP lives or how someone can intercept decrypted steams), a particularly nasty group of lawyers could still somehow associate the DMCA to it, so I’m not going to take any chances.

It’s quite ironic — Microsoft claims driver signing is to fight malware and increase system stability, so if I get sued under DMCA, wouldn’t that be an admission that driver signing is a “anti-copyright infringment tool”?.

I’d really love to release this tool to the public though, so I will look into my options — perhaps emphasizing the research aspect of it and crippling the binary would be a safe way.