Patching Methods in Windows XP and Windows Vista

Microsoft Corporation

Updated June 2007

Summary: Learn the best methods for patching games running on Windows XP or Windows Vista. (4 printed pages.)

Contents

Introduction
Windows Vista User Account Control
Games that only need to patch occasionally
Games that need to patch often

Introduction

Windows Vista adds a number of features to make the operating system more secure. The added security means that patching is not as simple as on previous platforms. This article will take a look at some patching methods that will work well in Windows Vista and Windows XP.

There are two main categories:

• Applications that need occasional patching such as most offline games.
• Applications that need patching often such as most online games.

This article will also give a brief introduction to the Windows Vista User Account Control (UAC) to serve as background about what privileges game developers can expect users to have in Windows Vista.

Windows Vista User Account Control

Windows Vista has two primary types of user accounts: Standard User, and Administrator. A Standard User account has several access restrictions such as it can not write to Program Files or write to HKLM in the registry. This has implications on how to patch a game if it is installed to a read only folder. Unlike Windows XP, the Standard User account will be much more common in Windows Vista. The Standard User account type is also required for important features like parental controls. Parental controls in Windows Vista requires the child account to be Standard User, and elevating the account to administrator for one game prevents parental controls from working with all other games so it important for games to be designed for Standard User.

Windows Vista changes the traditional privilege model to help prevent users from running programs that attempt to perform operations that the user doesn't intend or authorize. To that end, User Account Control (formerly called Least-privileged User Account or LUA) enables users to run at low privilege most of the time, while being able to easily run applications requiring more privilege as necessary. This means that Standard User accounts and Administrator accounts both run applications with Standard User privileges, but only Administrator accounts have the ability to grant applications elevated privileges. The operating system will ask users with Administrator accounts for explicit consent before running an application with elevated privilege, and if a program that requires administrator rights is run on a Standard User account, the system will prompt for administrator approval.

Games that only need to patch occasionally

Some games only require a few patches throughout the games lifecycle. Two methods that developers can employ for this frequency of patches are discussed below. It should be noted that regardless of whether a game requires frequent patching or not, applications will typically require administrator privileges to be installed or uninstalled.

Method 1: Use Windows Installer for occasional patching

In this method, a Windows Installer would be used to install the package (.msi file) and a Windows Installer patch (.msp file) would be distributed to install patches. The package must have an MsiPatchCertificate table and the patch must be digitally signed by a certificate in the table. More information about digital signing can be found at Authenticode Signing for Game Developers.

More details and requirements to use this patching method can be found in the Windows Installer documentation:

• Windows Installer: Patching and Upgrades
• Windows Installer: Least Privileged User Account (LUA) Patching

The disadvantage to this method is if the game was not installed from removable media on Windows XP, then patching will require Administrator privileges, but this should not be that restrictive as most users are still Administrators on Windows XP. The removable media restriction is not present on Windows Vista.

The main advantage of this method is that patches can be applied with just a Standard User without requiring any elevation prompt. This provides a better user experience because the Standard User account doesn't have to ask an Administrator to install the patch or request permanent Administrator privileges to play the game.

It is possible that this method may work in situations that need frequent patches, but the overhead of using Windows Install patch files in terms of build integration and supporting large numbers of files may make this method less desirable than others.

Method 2: Require administrator privileges to patch

This is fairly straightforward. The patch executable simply requires administrator privileges to run. With administrator privileges, the patch can directly modify the game files located in Program Files.

The advantage of this method is its simplicity. However this method is unsuitable if the game needs frequent patching because if someone with a Standard User account wanted to play a game that required frequent patching, such as an MMO, then the user has two choices:

• Be inconvenienced by getting an administrator to login and patch the game for them.
• Have their account permanently elevated with administrator privileges.

If they did the latter, this would not only weaken the security of the system as a whole, but it would prevent important features like parental controls from working.

Also when implementing this method, the patch executable must be different from the game executable. The patch executable should be marked with a manifest RunLevel tag of requiresAdministrator to denote it as an application that requires administer privileges. More information about how to do this can be found at Developer Best Practices and Guidelines for Applications in a Least Privileged Environment, in the "Application Manifest Schema" section.

Overall, method 1 is preferable for games that need just a few patches over its lifetime.

Games that need to patch often

Many online games are being improved continuously, and usually require regular patching. For these games, following Method 3 or Method 4 may be more appropriate.

Method 3: Install per user

One recommended and easy approach is to install the entire game to a per user directory under SHGetFolderPath CSIDL_LOCAL_APPDATA. This allows a Standard User application to directly patch the game's files.

The main disadvantage to this approach however is when multiple users are using the same machine. This approach means that each user has a copy of the game installed, and patches will need to be re-downloaded per user. This will waste not only user's time and hard drive space, but also increase patch server bandwidth and because any application with standard user privileges can modify the game, it also doesn't protect the game executables as well. It is up to the game company to decide if this is acceptable or not.

Method 4: Install to a common per machine location

Another method is to install just the non-executable game data to a subdirectory of SHGetFolderPath CSIDL_COMMON_APPDATA. This is a shared location for all users and can be modified by Standard User applications. This method minimizes the need to re-patch large files if the game is played from more than one account. It is recommended that the game executables are kept in Programs Files to minimize the risk to other accounts on the system. The executables should verify the integrity of the new patch content in the shared directory since that can be modified by any Standard User application. Consider using MapFileAndCheckSum to compute a checksum of a file.

This method has the advantage of working equally well on both Windows XP and Windows Vista, and doesn't require Administer privileges.

Other Possibilities

Outside of the methods listed above, another possibility is to alter the ACL of the Program Files directory when installing the game so that a patching tool when run as Standard User can write directly to the game's files. While this is not difficult, it does bypass the security protection that the system offers to the game's files and allows malicious programs to alter the contents of the directory. This is not advisable, and it is strongly recommended that an alternative be used instead.

One final possibility is to write a custom service. Writing a custom service to patch games is in general not a good idea as it is complicated and error prone. It is recommended that patching be done using other methods discussed in this article. However, a custom service might be necessary when combined with anti-cheat or anti-piracy solutions. Such a service should support a large number of games, and be designed so that it can only download the updated files and write only to the games installation directory. It is important that the service is lightweight, has a minimal surface area, and uses as few system resources as possible when the game is not running.

Summary

Ultimately it is up to the developer to decide which method to implement. The developer will have to weigh what factors are more important than others. Security, frequency of patch release, ease-of-use by customer, workload required to implement, complexity of solution, and platform feature compliance are the factors that each developer has to consider before deciding on a particular method.

More information about user account protection in Windows Vista can be found in the MSDN library article Developer Best Practices and Guidelines for Applications in a Least Privileged Environment.