"Reprint" vs Win7 dances: How does UAC get in the way of installing program detection?

Text tag:visual Studio Microsoft Windows 7

　　"IT168 Zhuangao" as Windows Vista introduces the UAC (user access Control) mechanism, the application runs under normal user rights by default. While Microsoft has introduced a UAC mechanism in Vista for its good intentions, in the Vista operating system, as long as the system changes slightly, it frequently pops up a dialog box to seek permission from the user, making it one of the most hated features in Vista. Nonetheless, Windows 7 inherits this mechanism and makes improvements based on user feedback. To reduce the risk of a computer system, the UAC mechanism reduces the user rights to execute the application, which is a problem that is compatible with the implementation of the application that was designed before the UAC mechanism occurred. These legacy applications are generally assumed to run with administrator privileges, and on Windows 7, because of the existence of UAC, this assumption is not tenable and eventually causes the application to not function properly. Some applications do require administrator privileges to function properly, especially when installing programs, and they need to write to areas that require special permissions, such as "program Files" or the HKEY_LOCAL_MACHINE of the registry. In this case, they encounter an access denied error, or the data is redirected to another location by UAC virtualization and cannot be executed correctly.

To solve this problem, "smart" Redmond programmers have come up with a way to do this: Install program detection. Starting with Windows Vista and, of course, Windows 7, the operating system will use heuristic algorithms to determine if the application is an installer, that is, whether the program needs to request administrator privileges at the time of execution, if the operating system determines that the application is a setup program, It will ask the user to obtain administrator privileges to allow the application to execute correctly when it executes.

　　how the operating system is detected ?

All 32-bit applications developed prior to Windows Vista that do not have manifest (both external and internal) will perform this heuristic setup detection. The operating system assumes that these applications are old, and that they all require setup detection to determine if the applications are administrator rights to function properly. In the face of such an application, heuristic installation detection of the operating system usually uses these paths to determine whether a 32-bit application is the installer:

• The file name contains keywords: "Install", "Setup" and "Update" and so on.

• Include keywords in the following fields of the version resource: Manufacturer (Vendor), company name (CompanyName), product name (ProductName), file description (filename Description), initial file name (Original filename), Internal file name (Internal name), export name (exported name).

• Include keywords within the manifest of the executable file.

• Include keywords in specific stringtable that are linked to an executable file.

• Resource file data that is linked to an executable file contains key attributes.

• The executable file contains a specific sequence of bytes.

If found, the operating system will assume that it requires administrator privileges to function properly. The icon for a UAC shield is overwritten with the application icon, which means that the application will request administrator permissions when it is started so that it can execute correctly.

Figure 1 Installation program detection

Content navigation

　　Setup must be the installer? ?

Although this heuristic installer detection allows an older installer to function directly on Windows Vista or Windows 7. However, it also brings many problems in itself. On the one hand, some applications that do not need administrator privileges can run normally, because the file name contains "Setup" and other related text, for example, StockUpdater.exe, is forced in the operation of the time to ask the user to request administrator permissions. This not only brings inconvenience to users, but also virtually reduces the security of the system. Even users can cancel the operation of the application because they are concerned that the system is compromised. On the other hand, some malicious software will also rely on the vulnerability of this mechanism to disguise themselves as a setup program, thus easily and openly to gain administrator rights and security risks to the system.

In contrast, many custom installers do not use Microsoft Windows Installer (MSI) technology and do not name the rules that are detected by the heuristic installer, so that the operating system does not consider it to be a setup program. Because the heuristic installer detects that it is not an installer, the user does not automatically request administrator privileges when running these applications, which can cause the application to encounter access denied errors when writing to some sensitive locations, and the installation process is done halfway through.

Like the lines in the movie, "must be a good person to drive a car?" Similarly, "is setup always the installer?"

　　Manifest indicate program run permissions

Since Microsoft's Heuristic installer detects this mental retardation, we have to bother ourselves by simply adding a manifest file to the application, telling the operating system whether we are installing the program or requesting administrator privileges. If the source code for the application is not available, we only need to add an external manifest file to the application in the same directory as the application. The name of the manifest file should be the application filename plus the ". manifest" suffix. For example, the filename of the StockUpdater.exe manifest file should be StockUpdater.exe.manifest. This manifest file should indicate whether the application needs administrator privileges when it is running, or whether it can run normally under normal user permissions.

A typical external manifest file is as follows:

Code highlighting produced by Actipro Codehighlighter (freeware) http://www.CodeHighlighter.com/<?xmlversion= "1.0" encoding= "Utf-8 "?><asmv1:assemblymanifestversion= "1.0"xmlns= "Urn:schemas-microsoft-com:asm.v1"Xmlns:asmv1= "Urn:schemas-microsoft-com:asm.v1"xmlns:asmv2= "Urn:schemas-microsoft-com:asm.v2"Xmlns:xsi= "Http://www.w3.org/2001/XMLSchema-instance">    <assemblyidentityversion= "1.0.0.0"name= "Myapplication.app"/>    <Trustinfoxmlns= "Urn:schemas-microsoft-com:asm.v2">        <Security>            <Requestedprivilegesxmlns= "Urn:schemas-microsoft-com:asm.v3">                <!--UAC Manifest option <requestedexecutionlevel level= "AsInvoker" uiaccess= "false"/> <requested Executionlevel level= "Requireadministrator" uiaccess= "false"/> <requestedexecutionlevel level= "HighestAva Ilable "uiaccess=" false "/> -                  <Requestedexecutionlevellevel= "AsInvoker"uiAccess= "false" />              </requestedprivileges>                 </Security>      </TrustInfo>    </asmv1:assembly>

Where the requestedExecutionLevel property indicates that our application performs the required permissions correctly. It has several optional values:

asinvoker– It means that the application needs to run with the same permissions as the creator. That is, the same permissions as Windows Explorer, usually normal user rights. This application is not a setup program and is not flagged incorrectly by the heuristic installer.

requireadministrator– It means that the application requires administrator privileges to function properly. (It may be a setup program.) )

highestavailable– It indicates that the application should run with the highest possible privileges. If the current user is an administrator user, then it is equivalent to requireadministrator. If the current user is a normal user, it will request administrator privileges at run time.

When we add an external manifest file for an application, the operating system formulates the appropriate UAC rules for the application based on the definitions in the manifest file. For example, with an external manifest file, we can request administrator permissions for a custom Setup program at execution time.

Figure 2 Customizing the Setup program

Content navigation

Embedded manifest

If we can get the source code for the application, we can add the embedded manifest to the application in Visual Studio 2010 to do the same thing. In the project properties, we set "linker->manifest File->uac execution Level" To specify the permissions that the application needs to execute.

Figure 3 Setting the UAC execution permission level

At the same time, we can embed the manifest file as a resource into the application, so that we just need a single application to do all the work without the need for an additional manifest file. Similarly, the Manifest file can be embedded in the application by setting it in the project properties "Manifest Tool->input and Output->embed Manifest".

Figure 4 Embedded Manifest

By default, new projects created by Visual Studio 2010 already contain embedded manifest.

With the manifest file, the application is like an ID card, and the operating system no longer wronged the good guys.

"Reprint" vs Win7 dances: How does UAC get in the way of installing program detection?