Fixing the way Vista Auto-detects Installers

From Ben's Writing

Jump to: navigation, search

Contents

Introduction

The following is a simple way to get applications that MS Vista has auto-detected as installers, like patch.exe, to work without user intervention (i.e. not making the user click ok for every security dialog).

The tool we use, mt.exe, is freely available with the Platform SDKs, so for the purposes of this article, we assume they are installed.

Using Manifests

Here is how to fix patch.exe (available here) using a manifest as an example.

<?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="patch.exe" type="win32"/> 
 <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
  <security>
   <requestedPrivileges>
    <requestedExecutionLevel level="asInvoker" uiAccess="false"/>
   </requestedPrivileges>
  </security>
 </trustInfo>
</assembly>


NOTE: We use old versions of the schemas because they are known to work better with unloved XP machines (i.e. not fully updated).

mt.exe /manifest patch.exe.manifest /outputresource:patch.exe;#2

Notes

The above should work on other executables that have the misfortune of having the words: "setup", "install", "update", "patch", etc. in their name; or keywords in the "following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name"; etc.

The reason we need to embed the manifest is because of the heuristic used by Windows to detect installers. We short-circuit the heuristic by adding a requestedExecutionLevel to an embedded manifest vs. a side-by-side manifest. See Installer Detection Technology in Understanding and Configuring User Account Control in Windows Vista for more details. The short of it is that side-by-side manifests are checked well after the above keyword checks are done (leading to the false positive).

There are two caveats to this solution: The first is that the application may, in fact, need administrative privileges: in which case, the above will not help—it will not give you access to resources that you do not already posses. The second problem has to do with the executables resources: by convention, manifests must be the second resource, so if there is already a resource under that id, the above will not work either. Fortunately, most programs which this fix applies to do not have resources.

Turning Installer Detection Off

It turns out this is also a policy that can be changed using the Group Policy Object Editor:

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox