(This post is moved here from the TweakUAC web site, where it was first published on February 27, 2007)
Vista Elevator 2.0 is an updated version of the sample application Vista Elevator that uses a different approach to solving the problem of starting a non-elevated task from an elevated one.
The first version of Vista Elevator used a trick that created a non-elevated process by programming Vista Task Scheduler to start such a process immediately upon its registration. It worked even if the parent process was elevated. However, there were a few problems with that:
- It worked well when the process was started by an administrator (that is, by an account with a “split token”). However, if the account was of a standard user (or a Guest account) it did not work as expected: the secondary non-elevated process was created by Task Scheduler to be executed in the administrator’s context, rather than in the original context of the standard user account. The task would launch not when it was registered, but later on, when the administrator logged on to the system.
- The target machine could have Task Scheduler disabled. In such a case, this method would fail to start the secondary non-elevated task at all.
To solve these problems, a different approach is necessary. An obvious method of achieving the goal would be to have a separate helper executable that would help the main application launch a non-elevated task, when necessary. Specifically, it would work as follows:
- When a user wants to run the application (main.exe), s/he would start by launching the helper executable (helper.exe) first.
- The helper process would start non-elevated, but it would launch main.exe, and request it to start elevated (for example, by using the Run Elevated() function).
- After the administrator would have approved the launch of main.exe, the user would work with it, as usual. Helper.exe would keep running non-elevated, waiting for a signal from main.exe.
- When main.exe would need to start a non-elevated task, it would send a signal to helper.exe, using some sort of inter-process communication, and helper.exe would start a non-elevated process on main.exe’s behalf.
Such an approach would solve both problems described above: it would not require Task Scheduler to be running on the target system, and it would launch the non-elevated task in the context of the original user, whether it is an administrator, a standard user, or a guest.
What is not good about this approach, it requires a separate helper process to be running all the time, wasting the CPU cycles. It also requires to design a communication protocol between the helper and the main executable, which is not a trivial task and is subject to errors. Wouldn’t it be better if we could use some other non-elevated process already running on the target system to launch a non-elevated process on the main.exe’s behalf? Let’s see… There actually is a process that is guaranteed to run all the time while the user is logged on to the system: the Windows shell! And it runs non-elevated, just what we need. Seems like a perfect candidate for our helper process. But how can we ask Windows shell to launch a process on our behalf? Simply calling ShellExecute() or Start Process() would not work, because they would be executed by our process, not by the shell. What we need to do is inject our code into the shell process and make it launch a process on our behalf!
So, the plan of the attack could be as follows:
- Our process would find a window that belongs to the shell, and that is guaranteed to be available at any time. A good window for this purpose is Progman, that is responsible for displaying the desktop. We can call the FindWindow() API to obtain a handle to this window.
- Our process would call RegisterWindowsMessage() API to register a unique message that we would use to communicate with the shell’s window. It must be unique to avoid possible conflicts and side effects if we would have accidentally picked a message that is already used by the shell for some purpose.
- Our elevated process would call SetWindowsHookEx() API to install a global hook, to be invoked when a windows message gets processed by any process running on the system.
- Once the hook is installed we would send our unique message to the shell’s window, and that would make our hook procedure to get invoked. (That’s how we inject our code into the shell’s process!)
- When the hook procedure is called (in the context of the shell process), it would call ShellExecute() API to launch the non-elevated process that we need. The process would start non-elevated because the shell’s process is not elevated, and our process would inherit the shell’s elevation level.
- Finally, we would remove the hook, as we no longer need it and it should no longer be called and waste system resources and CPU cycles.
That’s the plan that is implemented as the RunNonElevated() function in the VistaTools.cxx file that VistaElevator 2.0 uses. To make it work, the design of the VistaElevator application had to be changed significantly:
Firstly, in order to be able to install a global hook, the hook procedure must reside in a DLL. It means that we can no longer have a single executable, we must create a DLL to go with it, as well.
Secondly, in order to be able to pass data from our process to our code injected in the shell’s process, we must set up a special code section to be shared between several processes.
Finally, to be able to use this method with both 32-bit and 64-bit versions of Vista, we must produce two separate builds, one 32-bit and another one 64-bit. The reason for that is that on a 64-bit Vista the shell is a native 64-bit process, and in order to be able to hook it, we need to use 64-bit code, too.
To see the details, use the download links below:
THIS CODE AND INFORMATION IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
(the compiled executables only, without the source code)
(the source code, a Visual Studio 2005 project)
Note: If you want to compile the source code on your own, make sure you have the latest Windows SDK (see msdn.microsoft.com for more information).
Did you know? Our USB Encryption Software can protect any USB flash drive or any other external drive with a password and strong encryption. Try it free for 30 days! Read more…
February 17th, 2007 at 10:10 pm
I believe that this is because there is an NTFS fork on the directory that says that anything in that directory shouldn’t be trusted. This is similar to XP in how it knows that a file was downloaded recently by IE.
February 19th, 2007 at 6:06 pm
Hi Andrei,
Have a quick question about TweakUAC. Can I suppress UAC messages only for a single application using TWeak? Or does it suppress all UAC messages, system wide?
Thanks.
Regards,
Soumitra
Hi Soumitra,
> Can I suppress UAC messages only for a single application using TWeak?
No, it’s impossible.
> Or does it suppress all UAC messages, system wide?
Yes, that’s how it works.
Andrei.
February 20th, 2007 at 11:22 am
Hi Myria,
> I believe that this is because there is an NTFS fork on the directory that says that anything in that directory shouldn’t be trusted. This is similar to XP in how it knows that a file was downloaded recently by IE.
It may very well be so, but it does not make it any less of a bug. If a file contains a valid digital signature, Windows should not misrepresent it as coming from an unidentified publisher.
Andrei.
February 26th, 2007 at 1:09 pm
How did you take a screenshot of the UAC? I can’t get Print Screen to copy it to the clipboard, and the snipping tool isn’t working either.
February 26th, 2007 at 9:55 pm
Hi Chris,
> How did you take a screenshot of the UAC? I can’t get Print Screen to copy it to the clipboard, and the snipping tool isn’t working either.
Those tools don’t work because UAC displays its messages on the secure desktop, to which the “normal” user tools have no access. To solve this problem, I’ve changed the local security policy to make the UAC prompts to appear on the user’s desktop. After that, I used the regular Print Screen key to capture the screenshots.
Hope this helps,
Andrei.
March 4th, 2007 at 2:58 am
Hi Andrei,
I sell software to a *very* non-technical customer base. My setup procedure includes installation of an .ocx file into the \windows\system32 folder and registration of it using regsvr32. In order to copy anything into the \windows\system32 folder under Vista I have to turn off UAC. I would like to be able to do this automatically, programmatically, so I don’t have to make my users mess with UAC. I’d like to be able to turn off UAC for a second or two programmatically, then turn it back on. Will your software enable me to do that?
Thanks
March 4th, 2007 at 11:42 am
Hi Matthew,
> I’d like to be able to turn off UAC for a second or two programmatically, then turn it back on.
Unfortunately it’s impossible: if you enable or disable the UAC, Windows must be restarted before the change would have take effect.
To solve your problem:
> In order to copy anything into the \windows\system32 folder under Vista I have to turn off UAC.
It looks like your setup process is executing non-elevated, that’s why it cannot do that. You may want to try to start it elevated and see if it would have solved the problem without turning off the UAC.
HTH
Andrei.
March 25th, 2007 at 10:24 am
don’t use TweakUAC because this program makes your Vista unsafe!
March 29th, 2007 at 10:30 pm
> How are you supposed to make the decision whether to trust a certain program or not if UAC does not provide you with the correct information? (Nevermind, it’s a rhetorical question).
The answer is you are not. A guest should not be allowed to make any decision about installing software. If you log on as a valid user, the prompt works just fine. If you log on as a guest, you shouldn’t be installing software, so any dire warning is fine.
Yes, this might be unintended behavior (or perhaps it is not), but its impact is null.
March 31st, 2007 at 4:47 pm
Hi Herbys, you wrote:
> The answer is you are not. A guest should not be allowed to make any decision about installing software.
Sorry, but you are missing the point: the UAC displays this information for the _administrator_ to use and to make a decision, not for the guest user. The administrator is supposed to review the information and enter his or her password to approve the action. Take a look at the screenshot and see for yourself.
> If you log on as a guest, you shouldn’t be installing software
Why shouldn’t I? What if I want to install a program for use by the guests only? For example, I use only one web browser (IE), but I never know what browser a guest may want to use. So, being a good host
I want to install also Firefox and Opera, but I don’t want them to clutter my desktop, etc., I want them to be used by the guests only. To achieve that, I would log in to the guest account and install the additional browsers from there.
> so any dire warning is fine.
Wrong.
> Yes, this might be unintended behavior (or perhaps it is not), but its impact is null.
May be, may be not. In any case, it does not make it any less of a bug!
April 10th, 2007 at 9:28 pm
Is there any plan to adapt your program into a Control Panel Applet? I think that would be very clever.
April 11th, 2007 at 9:07 am
Hi Timothy, you wrote:
> Is there any plan to adapt your program into a Control Panel Applet?
No, we don’t have such plans at this time, sorry.
June 18th, 2007 at 9:19 pm
Anyone know why Vista won’t let me rename any new folder?
The permissions are all checked for me as administrator, still I get an error message, “folder does not exist”. I can put things in folder and move it, but can’t rename it?
January 29th, 2008 at 9:46 am
To be honest, I have always thought that digitally signing was merely a way of generating more revenue. It doesn’t offer you any more security and windows will always moan at you regardless of an application having a signature or not.
Even if your application has the “all powerful” and completely unnecessary Windows Logo certification, it still offers nothing to you as a user other than the reassurance that the person/s developing the software has allot of spare cash.
February 24th, 2008 at 10:34 am
Bob Said:
> To be honest, I have always thought that digitally signing was merely a way of generating more revenue.
I have to agree. I’ve heard the argument of how it’s all designed to protect users from malicious software, and that’s all well and good as far as that goes — but since Vista, and most mobile OSes, don’t offer a way for users to say “okay, I understand the risk, I accept full responsibility, please go ahead and run this unsigned application without restrictions, and never bother me again when I try to run this application”… That makes it pretty clear it’s just a racket initiated by VeriSign and the like, and happily endorsed by Microsoft.
May 17th, 2008 at 9:03 am
This is not a bug.
The first screen shot shows that Windows doesn’t trust the identity contained in the certificate. In other words, “I can read this, but I don’t know if I should trust the person who wrote it.”
The second screen shot just shows that the certificate is well-formed, that Windows can understand the information contained within it. It says nothing about what Windows will do with that information.
Who did you did you pay to sign the certificate for you? If they’re not someone with a well-established reputation, then I don’t WANT my computer to automatically trust them.
It’s just like how web browsers automatically trust SSL certificates signed by Thawte or Verisign, but will ask you before accepting a certificate from Andy’s Shady Overnight Certificate Company. As always, it’s a balancing act between usability and security.
May 17th, 2008 at 10:04 am
Andrew, you wrote:
> This is not a bug.
OK, there is a fine line between a bug and a feature, let’s assume for a moment that it’s a feature rather than a bug. If so, what benefit is this feature supposed to provide? As the second screen shows, the file is digitally signed, and Vista can detect that. Yet, it shows the publisher as “unidentified” on the first screen. Note also (as I mentioned in the post), that if you move the file to one a few specific folders (such as C:/Program files), Vista would magically begin to recognize the publisher. Move the file to some other folder, and it’s unidentified again.
If you can explain why they designed it that way, I would agree with you. Until then, it’s a bug. Guilty until proven innocent!
> Who did you pay to sign the certificate for you?
That particular file was signed with a Verisign certificate, but the same problem occurs with _any_ file, signed with _any_ certificate. Try it yourself and you will see.
June 1st, 2008 at 12:53 pm
I think that it occurs because of IE7 protected mode – see http://victor-youngun.blogspot.com/2008/03/internet-explorer-7-protected-mode-vs.html, it’s a guide to run firefox in protected mode, and this explains very good how the protected mode works… the prompt is because the “Download” Folder is a protected folder (level “low”) and I think it only displays at the guest, because Windows forces UAC to display certificate in normal user mode in “low” level folders, but NOT for the MUCH MORE RESTRICTED “guest” account. This would be my explanaition.
It doesn’t mean that I like it how Microsoft handels this but this would eventually explain WHY the warning appears sometimes and sometimes not.
June 1st, 2008 at 12:55 pm
sorry, in my last post there is a comma in the link, the correct link is:
http://victor-youngun.blogspot.com/2008/03/internet-explorer-7-protected-mode-vs.html
June 3rd, 2008 at 7:16 pm
Farthen: thank you for the information and explanation!