Going Deep: Dumping the memory of a "protected process"

Some of you may know that Windows Vista introduced a new type of process, called a "protected process". This type of process has restrictions placed on it regardless of the ACL and integrity level of it. The following operations are allowed on a protected process from outside of the protected process integrity space:

• Termination (PROCESS_TERMINATE)
• Suspension and resumption (PROCESS_SUSPEND_RESUME)
• Synchronization (SYNCHRONIZE)

Note that these must be in the DACL for the process (just like a normal process) - but all other process rights are skipped when checking the DACL. Similar access checks are applied to threads that belong to protected processes. Because how the system checks process rights is not the topic of this thread, we won't go into much detail and skip straight to the chase...

I am trying to find out what is going on inside a "protected process" by dumping its user-address space, but I can't. Why is this?

Put simply - in order to dump the user-address space of a protected process, you must yourself be running as a protected process - but Microsoft limits usage of protected processes by third parties. Here I will show you how to use a kernel debugger to (on your own, local machine) generate a user-mode memory dump of a process that is protected. It involves knowledge of using WinDbg (as this is the debugger we will use, but other kernel debuggers can be used, too) and the various commands associated with kernel debugging (kd and lkd).

Essentially what we are required to do is use the kernel debugger to modify the EPROCESS structure of our own program. Inside the structure we are interested in the ProtectedProcess member, which is a single bit of a union representing 22 bits of information defining various aspects of the process. Its layout looks like this:

In order to set the process as a protected process, we must turn on the 11th bit (starting at zero) using the kernel debugger. Assuming all other bits are turned off, turning on just the 11th bit gives us 0x800, or 2048 in decimal, so we must modify the memory location for these flags to be at least this value. To do this, we can simply take the the value of the Flags2 member and bitwise OR it with 0x800, and then write the resulting value to the memory location. Let's start shall we?



Stage 1: Turning on local kernel debugging

The following will show you how to boot your system with kernel debugging enabled. The easiest way is to use the BCDEdit utility from the command line:

1. Start a Command Prompt elevated (Run as administrator).
2. Type the following command and then press ENTER: bcdedit /debug on
3. Restart the computer.

Stage 2: Start the local kernel debugger (WinDbg only)

The following steps are for WinDbg only. If you prefer to use another kernel debugger (that can utilize the same commands that are to follow, setup local kernel debugging according to it).

1. Open WinDbg elevated (Run as administrator).
2. Press CTRL+K to launch the Kernel Debugging window.
3. Select the Local tab and click OK.
4. If everything succeeded you should see your local kernel debug session start like the following image:



With that out of the way, it is time to run some commands!

Stage 3: Modify the EPROCESS structure of your program

The following steps outline how to make Task Manager (taskmgr.exe) a protected process so that we can use it to create user-address space memory dumps of other protected processes. This can be achieved by right clicking the process in the list in Task Manager and selecting Create Dump File. Creating a user dump requires, amongst others, the PROCESS_VM_READ access right - which is unavailable to a process which opens a handle to a protected process, unless of course, it is a protected process itself. You can try this by trying to create a dump file of the audiodg.exe process - it will fail with an access denied error message. After completing the following steps, however, you will successfully be able to create a dump file of audiodg.exe from Task Manager. In other news, replace my example of taskmgr.exe with YOUR OWN program that you want to make a protected process.

1. First, we need to get a list of all the processes on the machine - to do this execute the !dml_proc command in the debugger.
2. We are now presented with each running process in the system. Here is output from my machine:

The Address column is the one we are most interested in. For our example, taskmgr.exe has an address of fffffa80`05608060. We will use this next. Replace fffffa80`05608060 EVERYWHERE in the below steps with the address of the process you wish to modify.

3. Dump the value of the _EPROCESS!Flags2 member with the following command: dt _EPROCESS fffffa80`05608060 -y Flags2. Here is my output:

4. With my Flags2 member having the default vale of 0xd00, I must now modify it so that it causes the ProtectedProcess bit to be set. As explained earlier, we can bitwise OR this value with 0x800 to turn on the ProtectedProcess bit. (0xd00 | 0x800 = 0xd800). Note down the value you get when performing this operation - my value (and likely yours too) is 0xd800.

5. Rewrite the memory for our Flags2 member. In Step 3 above, we see that the Flags2 member is offset 0x43c bytes from the process address. The memory address we will be writing to therefore will be process address+0x43c, in this case it is fffffa80`05608060+0x43c. Execute the following command: ed fffffa80`05608060+0x43c 0xd800.

6. Verify that the ProtectedProcess bit has been set. Execute the following command: dt _EPROCESS fffffa80`05608060 -y ProtectedProcess. Here is my output:

The 0y1 tells us that the bit has been set correctly. You can now proceed to creating a dump file of a protected process.

---

NOTE: On some systems I have seen Task Manager throw up an error "Not enough storage space is available to process this command". If this occurs for you either using my Task Manager example, or with your own program, you can reverse the process and REMOVE the ProtectedProcess bit from the process that you want to create a dump file of. The steps are the same, however you modify the EPROCESS structure of the target process, and you remove the value 0x800 (by using bitwise AND from NOT of 0x800) from the Flags2 member instead.
Edited by tompsonn - 8/31/12 at 7:59am

Indeed my goal! Thanks!