Vista uac programming

General options of …". In the "Help" tab, select "Use the local help database" and specify if necessary the path of the "Help" directory of your product. The help used by default will be the local help installed on your computer. Windows Vista. Programming standard in Windows Vista and later. Programming tips. Adapting an existing application to Windows Vista and later. Examples of functions affected by the management of user rights in Vista and later.

See also. Difference of behavior in Windows Vista and later. But guess what? We ain't done yet. I sort of gave up trying to figure out what it did. My general impression was that it most likely has something to do with the pop up dialogs received when launching an EXE downloaded from the Internet IZoneIdentifier.

Identifier' so it can pop up that nifty and annoying dialog you see for downloaded files before executing them. The call stack turned hilarious:. Gotta love the names given to the functions. It sort of eggs you on to see what's next. Okay, now we're going to create the process. Oh, wait, never mind, now we're going to create the process. The marketing engine has gotten into the source code. Poor developers. I feel sorry for you guys who have to work with that mess every single day. At any rate, the function of interest is AicLaunchAdminProcess.

Turns out, not only is a new thread started and a half dozen COM objects instantiated, but RPC is brought into the mix as well.

It combines with MIDL and allows you to, uh, call remote procedures. The target function could be on another computer or the same computer. Sort of one of those unexploited security holes because it is also an obscure technology that few know how to use. And, this is where things get interesting. AppInfo is where the magic happens. But before I get to the magic, a short discussion on Sessions and Integrity Levels is in order.

They are also occasionally referred to as "Secure Desktops". Vista has two Sessions, but could technically have many more than that.

Session 0 and Session 1 are the official names. Session 0 is where all NT Services reside. Just to clarify, Window Stations are not Sessions. It is important to note that some documentation on Vista UAC implicitly claims each Session is supposedly completely segmented from communication with other Sessions.

This is not true. Most likely, the authors are referring to window messages or an early beta. It is important to note that objects created by elevated and system processes, by default, have a Medium Integrity Level. For the observant person, that last sentence is the key to why the Elevate package works. AppInfo is, obviously, the key to UAC elevation. As the name implies, this is the executable that brings up the dialog that the user consents to. However, consent. What you see is a desktop on Session 0.

Hence the reason it is called a "secure desktop". It only looks like Session 1's desktop. You can't click on anything but the dialog, because there literally isn't anything to click on. AppInfo then takes the results from consent. AppInfo then creates a process using the full administrative token remember that split token thing? If you fire up Task Manager, you can see that elevated processes indeed run as the current user. We know it also runs on the Session 1 desktop because GUI windows can be created, seen, and interacted with.

To create a process as the current user on a different desktop in a different Session is a seven stage process:. Once AppInfo succeeds in launching the process, it transfers some information back over the RPC interface to the application that called ShellExecuteEx. ShellExecuteEx meanders around a bit, and cleans up after itself, and eventually returns through the whole mess of function calls, closes the thread, and returns to the caller.

This process took me about three days to complete, and was quite exhausting. I eventually narrowed everything down to a few lines of assembler inside AicLaunchAdminProcess :. For you non-assembler gurus, this is essentially passing the address of the address of a data block from Title to ShowWindow. This tells me that AppInfo doesn't handle very much information. At this point, I chucked the idea of doing my own RPC thing with AppInfo out the window, cried for two seconds for wasting a couple days, and then went to figure out how to use ShellExecuteEx to do what I wanted.

My target audience was initially my own customer base, so it needed to be clean and easy to understand. The DLL would then package up each function's data and shuttle it across to the EXE, which would take that data, unpack it, and execute the correct function as an elevated process. To my surprise, doing that caused an extremely meaningless error message to pop up: "The data area passed to a system call is too small.

It took a lot of experimentation, but apparently sending more than bytes 2K of data in the lpParameters member causes that error message to occur. But I'm getting way ahead of myself there.

I got the idea for using named pipes once I learned about Integrity Levels and the fact that objects created at higher ILs only have a Medium Integrity Level And, there's the "gotcha". Remember that whole roundabout mess to get a process elevated? Someone may point out that AppInfo's method of starting a process does actually inherit the handles of the original process and would include the Standard HANDLE s stdin, stdout, stderr.

The solution lies in named pipes. Named pipes have, um, names. Active Oldest Votes. Improve this answer. That's cool, I didn't think of that. Process Monitor does show the "real" directory. Unfortunately, running Process Monitor is probably more than the typical user can handle.

Still, good idea. I was hoping for a way to do this from within my program, but since nobody has a better answer, I guess this is the winner. Stefan Stefan Any user can write to it, though any file you create can't be read by another user unless it's created with "allow everyone" access.

This location is usually written to by installers, not by applications themselves. It would be a security risk if one user can set options or worse, replace binary files another user will then have to use.

From msdn. By default, this location is read-only for normal non-admin, non-power Users. I didn't write the installer, that must be what we are doing. Below is the code that gets called when the LoaderService is started:. Information about the newly created process will get stored into the variable procInfo.

To begin, we will obtain the Session ID of the currently logged on User. Now that we have obtained the PID of the winlogon. There are many advantages to duplicating an access token. Most notable in our case is that we have a new copy of a primary access token which also contains within it the associated logon Session of that copied token. If you refer to the Task Manager screenshot above that shows the two winlogon.

To summarize, the code below runs in Session0, but will launch a new process in Session The above code will launch a command prompt that is running as an Administrator under the System account.

This is a hard-coded String that Microsoft arbitrarily chose to indicate to the OS that the process we are about to spawn in CreateProcessAsUser should have full access to the interactive windowstation and desktop, which basically means it is allowed to displayed UI elements on the desktop. The most efficient way to deploy our code is to create an MSI installer for it. However, we have to first perform a couple of tasks to prepare our service for installation.

To begin, we need to add an installer for our LoaderService. To add an installer, open up the LoaderService. Then, right-click, and select Add Installer:. The above action adds a new class to the project called ProjectInstaller. This class inherits from the Installer class. There are two components visible on the designer of ProjectInstaller. The loaderServiceProcessInstaller control allows us to specify the account under which the LoaderService will run. This account has been set to System :.

Now, we are ready to add a Setup project. The primary output of the Setup project is set to the Toolkit project, which contains our LoaderService.

This step is fairly trivial, and I will not be going through the details of adding it. If we do not, then the contents of the Toolkit project will be deployed, but the LoaderService will not get registered as a Windows Service. From here, you can add a custom action. Specifying the custom action as the primary output from Toolkit is enough to hint to it that there is a custom installer, in our case ProjectInstaller , that needs to be run.