Why Protected Processes Are A Bad Idea

If you haven’t read or heard about Protected Processes yet, start by familiarizing yourself with the whitepaper here. MarkR also covered them in his 3-part series on Vista enhancements.

But basically, they’re another part of the next-generation high-definition audio/video support present into Vista, and related to the Protected Media Path, which I had covered a bit earlier, much to people’s attention. Before continuing, let me make clear that this post isn’t related to any previous PMP stuff I have posted, is not about the so-called crack or idea I had (Which, if you haven’t read previously, turned out to be false). This entry is strictly related to Protected Processes and their non-PMP use.

· Inject a thread into a protected process

· Access the virtual memory of a protected process

· Debug an active protected process

· Duplicate a handle from a protected process

· Change the quota or working set of a protected process

· Set or retrieve context information

· Impersonate the thread

Which means that all applications such as virus scanners, malware protectors, and any other kind of application that hooks all system processes, injects threads into them or even discretely reads their memory doesn’t work on Vista when it hits a protected process. For example, Warden (the application that World of Warcraft uses to catch cheaters) can’t determine if a protected process is evil or not, because it can’t go peek inside it. To help offset this dillema, protected processes can only be loaded if they are signed, and with a special license which comes with heavy restrictions on what the process can do, how it can behave, and so on. Because of this, only true media applications will ever be protected, and legitimate applications which were used to scanning address spaces will simply skip the process, inherently assuming that the DeCSS descrambler in Windows Media Player isn’t trying to hack their MMORPG.

Unforunately, it is trivial to make a process protected or unprotected by bypassing all the Code Integrity checks and sandbox in which protected processes are supposed to run. I wrote a small application which I called D-Pin Purr which does exactly this. I tried it on the only two protected processes I know on Vista (audiodg.exe and mfpmp.exe). While ProcessXP usually shows only limited information for them, after using my tool, I could see all the information. WinDBG attached to it fine:

ChildEBP RetAddr  Args to Child
01b4fbd4 770706a0 76f777d4 000000f0 00000000 ntdll!KiFastSystemCallRet
01b4fbd8 76f777d4 000000f0 00000000 00000000 ntdll!NtWaitForSingleObject+0xc
01b4fc48 6fd82e54 000000f0 ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xbe
01b4fc6c 6fd82da1 000ea420 01b4fcac 00000000 MFPlat!LFQueueGetWaitEx+0xec
01b4fc8c 6fd82d63 000ea400 01b4fcac 00000000 MFPlat!LFQueueGetWait+0x22
01b4fcb4 6fd82887 01b4fdb8 00000000 00000000 MFPlat!CCompletionPortQ::Get+0x1f
01b4fdbc 6fd889d7 01b4fdfc 761f62b6 001022e0 MFPlat!CWorkQueue::CThread::ThreadMain+0x80
01b4fdc4 761f62b6 001022e0 3da0e0d2 00000000 MFPlat!CWorkQueue::CThread::ThreadFunc+0xd
01b4fdfc 761f63de 01b4fe10 76f73833 00029420 msvcrt!_endthreadex+0x44
01b4fe04 76f73833 00029420 01b4fe50 7704a9bd msvcrt!_endthreadex+0xce
01b4fe10 7704a9bd 00029420 01b462fd 00000000 kernel32!BaseThreadInitThunk+0xe
01b4fe50 00000000 761f639b 00029420 00000000 ntdll!_RtlUserThreadStart+0x23

Here’s a simple overview of the application itself:

DPINPURR processid [/P]
    This tool is used to remove or add protection on a process.
Parameter List:
        processid       Specifies the PID of the process to be unprotected.
   /P                  Specifies to protect the process instead.
c:\>dpinpurr 312 /p

         Process modified successfully!

Being able to play with the PMP application isn’t really what I was interested in, since most of the high-level security is in the kernel anyway. The intersting thing is that I can make any application of my choosing protected, and thus undebuggable, uninjectable and with its address space secure. I’ll add dpinpurr to the download area soon, and provide a link.

While I don’t want to condone writing more powerul malware or MMORPG hacking tools (or whatever else can benefit from being protected), I think it’s time to signal a wakeup call to all the developers who were counting on simply ignoring protected processes and assuming they’re legitimate media applications.

26 Replies to “Why Protected Processes Are A Bad Idea”

  1. But antivirus and others can’t create a driver that scan protected proces memory? Well if MS let them do that.

  2. The tool need Admin priveledges to work, and guess what you can do with that? Yes! Anything you like! The same goes for Linux too – oddly, with root access you too can do/inject/patch anything at all too.
    Linux is unsafer than Vista because from a root account you’re able to replace the whole kernel with a single command line.

  3. Pingback: The Disparity Bit
  4. claudvand: I think you’re missing the point. Have you even *read* the Whitepaper? Under Vista 64-bit for example, being Administrator means nothing in terms of kernel access. Any under both modes, protected processes are supposed to be above root access.

  5. Nice job with this implementation. I’ve got a few questions, though.

    Assuming that the hard requirement for signed drivers in x64 can be circumvented, e.g. by offline patching of the kernel binary (at least I understand from comments by various MS staff that this is not unfeasible), is the same approach applicable in principle to x64 also?

    Moreover, where a TPM is installed in the machine, are Protected Processes also under hardware protection? Can this be addressed without first removing TPM functionality?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.