Damon Cortesi's blog

Musings of an entrepreneur.

Different Privileges in Visual Studio Debug Mode

| Comments

I’m mucking around with process tokens in C++ lately (stealing tokens and whatnot…) and was having an odd problem when I would run my application in Visual Studio versus when I would run it from a command prompt.

In the case of running the program from Visual Studio, I could use the OpenProcess function fine, but OpenProcessToken would fail with access denied.

In the case of running it from a command prompt, OpenProcess would fail with access denied. I figured it must have something to do with certain privileges debug mode enables in the application.

Using Process Explorer, I fired up the application from both cases and compared the security attributes. Exactly the same. Despite that, I was still convinced that it had something to do with privilege levels.

After a few failed searches, I decided to dig into why OpenProcessToken was failing in the first place and try to figure out the Visual Studio problem at a later point. It was then that I stumbled on this gem. I had almost ignored it because I missed the reply at the top of the page that reads

Make sure you’re not impersonating while calling OpenProcessToken.
Oh man…I know I’m calling ImpersonateSelf, but could that really be what’s causing the difference in Visual Studio? After adding a RevertToSelf after properly adjusting my token privileges, the application ran the same in both Visual Studio and the command prompt. smack

Now I just need to figure out why I can’t use OpenProcessToken on those few applications like CSRSS and other users’ processes. It’s obviously possible as both Task Manager and Process Explorer are able to get usernames associated with processes, but I’m having the most difficult time figuring out how they do that.