Windows Internals, Thoughts on Security, and Reverse Engineering
I’m not one to boast, but today marks my entry into the US “Adult” world. While I’ve been happily enjoying fine beers in Montreal for over 3 years, I can now finally do the same in the US!
I apologize as well for the lack of recent posts, I am currently finishing my semester and in exam session. I will have more exciting things to share upon my return.
Down at the Disparity Bit, Dan Armak has a very good discussion on why exactly he thinks protected processes are bad, and a sort of addendum to my post on the subject. Check out “Making it Clear Just Why Protected Processes are a Bad Idea.” for a more detailed explenation on the problem.
A few people have started to reverse engineer the binary I posted, and some have come up with some partial explenations and analysis. I just wanted to clear up a few things: Yes, the method uses a driver. It’s based on the Microsoft documentation which says “Please don’t use a driver to bypass this”, which led me to believe that it would be possible to do this (which wouldn’t work on 64-bit Vista, of course).
Secondly, almost everything inside the binary I provided is a low-level obfuscation to confuse any kiddies that might try to grab a hold of the expanded driver and use it for the own purposes. It was not meant for, nor is it an example of, proper techniques to obfuscate/protect a program against advanced reverse engineers.
As promised in my earlier blog post, I’ve finalized the utility and made it available for download here. I won’t be releasing source code for the moment because I don’t want to encourage people to start adding this kind of code into their own malware programs, nor to encourage the Symantec folks to start unprotecting every process on the system.
So until then, have fun with the tool, whether it is to explore previously protected processes, or to try out various system and application behaviour when certain processes are made protected. Here’s a screenshot of audiodg.exe after being unprotected. Try it on your own system to see the before/after difference.
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.
A typical process cannot perform operations such as the following on a protected process:
· 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
A typical process cannot perform the following operations such as the following on the threads 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:
c:\>dpinpurr
DPINPURR processid [/P]
Description:
   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
[C0000156] – STATUS_TOO_MANY_SECRETS:
        Process modified successfully!
c:\>
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.