How does Windows decide whether to display the UAC

问题:

In my VB6 application I open other EXE files. My application runs without any UAC prompt, but I have an EXE which checks for updates to software. This prompts the UAC prompt. So how does Windows decide whether to show the UAC prompt? I saw this link . So does it depend on the code I wrote in my application? It is interesting that my application (that is the main EXE file) does not prompt UAC whereas a small EXE which checks and downloads updates prompts the UAC. I have all the EXE files digitally signed. I already had a glance at following links:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa511445.aspx

http://technet.microsoft.com/en-us/library/cc505883.aspx and some other.

But still I am not clear about it.

回答1:

You are almost certainly hitting a Windows Installer Detection Technology compatibility heuristic. Windows will try to detect when an application is an installer, and probably needs to be elevated.

Installer Detection only applies to:

1. 32 bit executables
2. Applications without a requestedExecutionLevel
3. Interactive processes running as a Standard User with LUA enabled

Before a 32 bit process is created, the following attributes are checked to determine whether it is an installer:

• Filename includes keywords like "install," "setup," "update," etc.
• Keywords in the following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name.
• Keywords in the side-by-side manifest embedded in the executable.
• Keywords in specific StringTable entries linked in the executable.
• Key attributes in the RC data linked in the executable.
• Targeted sequences of bytes within the executable.

So, as you said:

but i have a exe which checks for updates to software

My guess is that this CheckForUpdates.exe is triggering the compatibility heuristics.

The correct thing to do is to an an assembly manifest to your "checking" executable, informing Windows that it should not elevate the utility. This is done with a requestedExecutionLevel of asInvoker in the manifest:

AssemblyManifest.xml:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
   <assemblyIdentity 
      version="1.0.0.0"
      processorArchitecture="X86"
      name="client"
      type="win32"
   /> 

   <description>Update checker</description> 

   <!-- Run as standard user. Disable file and registry virtualization -->
   <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
      <security>
         <requestedPrivileges>
            <requestedExecutionLevel level="asInvoker" uiAccess="false"/>
         </requestedPrivileges>
      </security>
   </trustInfo>
</assembly>

That way your "Check For Updates" application will never elevate, and never mistakenly gain administrative privileges.

If you want your updater to actually apply updates (updates which require administrative privileges), then you would launch your updater application as an administrator.

Sample Code

//Check if there are updates available
if (!CheckForUpdatesAvailable())
   return; //no updates. We're done

//If the user is an administrator, then get the update
if (IsUserAnAdmin())
{
    //Maybe throw in a "Hey, user, wanna get the update now?" dialog
    DownloadAndApplyUpdates();
    return;
}

//The user is not an admin. 
//Relaunch ourselves as administrator so we can download the update
//Maybe throw in a "Hey, user, wanna get the update now?" dialog. A button with a UAC shield on it
ExecuteAsAdmin(Application.ExecutablePath, "/downloadUpdate");

with the helper functions:

private Boolean IsUserAnAdmin()
{
    //A user can be a member of the Administrator group, but not an administrator.
    //Conversely, the user can be an administrator and not a member of the administrators group.
    var identity = WindowsIdentity.GetCurrent();
    return (null != identity && new WindowsPrincipal(identity).IsInRole(WindowsBuiltInRole.Administrator));
}

private void ExecuteAsAdmin(string Filename, string Arguments)
{
    ProcessStartInfo startInfo = new ProcessStartInfo(Filename, Arguments);
    startInfo.Verb = "runas";
    System.Diagnostics.Process.Start(startInfo);
}

Then you just need to look for the /downloadUpdate command line parameter on startup to know that you're job is to actually do work:

public Form1()
{
    InitializeComponent();

    //Ideally this would be in program.cs, before the call to Application.Run()
    //But that would require me to refactor code out of the Form file, which is overkill for a demo
    if (FindCmdLineSwitch("downloadUpdate", true))
    {
        DownloadAndApplyUpdates();
        Environment.Exit(0);
    }
}

Note: Any code is released into the public domain. No attribution required.

回答2:

Your programs probably lack application manifests that mark them as non-legacy. As a result Windows will apply scripted installer detection heuristics to decide whether your program is an installer. This is pretty much the only way an "unexpected" UAC prompt gets raised.

These heuristics include keyword searches within the EXE file name and several of the extended properties of the EXE, and may even look for well-known binary signatures (i.e. byte strings) inside the file.

BTW, your crypto-signing doesn't enter into this at all. And it doesn't help a thing if it wasn't issued by a trusted CA.

For that matter anyone who trusts code just because Windows reports the commpany name on the UAC prompt is a fool. Malware authors steal these all the time, and for that matter they are trivial to obtain and almost never reported by users when crap programs cause problems. Save your money, code signing certs are a failed concept.

回答3:

Someone can specify in the configuration of the exe that this file needs to be executed with higher Privileges.

How to request Admin Privileges

I don't know what this update is for, but I'd suggest that it needs to update a component like a service, or some files that are located in the ProgramFiles-Dir. Therefore it needs Admin Privileges.

回答4:

The UAC prompt is used when a privilege elevation is needed. Your own VB6 app doesn't need it, and therefore the default behavior is OK. An updater would need the privilege, so its author marked the executable as requiring it. Windows spots that and puts up the UAC prompt.

Now depending on the exact Windows version and security updates, that privilege remains available for a while, even to other (child) processes. This may prevent duplicate UAC prompts.