|
|
Microsoft Game Technology Group
April 2006
Windows Vista adds a number of features to make the operating system more secure. Added security means that applying patches to software is not as simple as it was in the past. This article examines some methods of patching that will work well in Windows Vista and Windows XP.
There are two main categories of games that require patches:
This article also offers a brief introduction to the Windows Vista User Account Control (UAC) to serve as background about the privileges that developers can expect users to have in Windows Vista.
Windows Vista has 2 primary types of user accounts: Standard User and Administrator. A Standard User account has several access restrictions; for example, it cannot write data to the file system in %SystemDrive%\Program Files or to the registry in the HKEY_LOCAL_MACHINE. This has implications for applying patches to a game if it is installed in a read-only location. Unlike in 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 of the operating system, like parental controls. Parental controls in Windows Vista requires that the child account be Standard User, and elevating such an account to Administrator for even 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 asks 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 prompts for administrator approval.
Some games only require a few patches throughout their lifecycle. Two methods that you can employ for this frequency of patching are to distribute patches as Windows Installer packages, which does not generally require Administrator rights, or to use some other type of distribution that directly modifies game files.
Note Regardless of whether a game requires frequent patching, applications typically require Administrator privileges to be installed or removed.
In this method, a Windows Installer is used to install a package (.msi file) and a Windows Installer patch (.msp file) is 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:
The disadvantage to this method is that if the game was not installed from removable media on Windows XP, then patching requires Administrator privileges. However, this not likely to be too restrictive, because most users administrators on Windows XP, and the restriction to software installed from removable media is not present on Windows Vista.
The main advantage of this method is that patches can be applied by a Standard User account without requiring a prompt and authentication for elevated rights. This provides a better user experience, because to play a game, a user with a Standard User account doesn't need to ask someone with an Administrator account to install the patch or to provide the Standard User account with permanent Administrator privileges.
It is possible that this method might work for games that require frequent patches, but the overhead of using Windows Install packages, in terms of build integration and supporting large numbers of files, might make this method less desirable than others.
In this method, the executable file that applies the patch requires Administrator rights to run. With Administrator rights, the patching executable can directly modify the game files located in %SystemDrive%\Program Files.
The advantage of this method is its simplicity. However, this method is unsuitable if the game needs frequent patches, because if a user with a Standard User account wants to play a game that requires frequent patches, like a massively multi-player online game, then that user has two choices:
Note The latter solution not only weakens the security of the system as a whole, but it prevents important features, like parental controls, from working.
When implementing this method, the executable file that applies the patch must be different from the game executable. The manifest of the patching executable should specify requireAdministrator for requestedExecutionLevel to denote it as an application that requires Administrator rights. 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 their lifetimes.
Many Internet-based games are being improved continuously, and they usually require regular patches. For these games, patches could be applied per-user or per-computer, as discussed in the follow topics. Other possible solutions include altering the ACL that protects %SystemDrive%\Program Files or creating a custom service.
One recommended and easy approach is to install the entire game to a per-user subfolder of the local application data folder, which you can find by calling SHGetFolderPath wih CSIDL_LOCAL_APPDATA. An example path is C:\Documents and Settings\user_name\Local Settings\Application Data\ExampleGame. Such a location allows an application running with Standard User rights to directly modify game files.
However, there is a disadvantage to this approach when a computer has multiple users: each user has a copy of the game installed, and patches must be downloaded and applied by each user. This wastes not only users' time and disk space, but it also increases use of network bandwidth to the server that provides patches. Also, because any application with standard user privileges can modify the game, game executables are less protected; it is up to the game manufacturer to decide if this is acceptable or not.
Another method is to install the non-executable game data to a subdirectory of the path specified by SHGetFolderPath CSIDL_COMMON_APPDATA; an example path is C:\Documents and Settings\All Users\Application Data\ExampleGame. This is a shared location for all users, and it can be modified by applications that run with Standard User rights. This method minimizes the need to reapply large patches when the game is played from more than one account. Executable files for the game should be kept in %SystemDrive%\Programs Files to minimize the risk to other accounts on the system. The executable files should verify the integrity of the new content in the shared directory, since that location can be modified by a program or person with Standard User rights; consider using MapFileAndCheckSum to compute a checksum of the files.
This method has the advantage of working equally well on both Windows XP and Windows Vista, and it doesn't require Administrator rights.
Outside of the methods already discussed, another possibility is to alter the ACL of %SystemDrive%\Program Files when installing the game so that a patching tool can write directly to the game's files even when run with Standard User rights. While this is not difficult, it does bypass the security protection that the system offers to the game's files and provides an opportunity for 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. In general, writing a custom service to patch games is not a good idea, because doing so is complicated and error-prone. It is recommended that patching be done by use of 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 patch files and write only to the installation directory for the target game. It is important that the service be small, have a minimal surface area vulnerable to attack, and use as few system resources as possible when the game is not running.
Ultimately it is up to you to decide which method to implement. You need to weigh the factors are that are important to you. Security, frequency of patching, ease of use by customer, workload required to implement, complexity of solution, and platform feature compliance are the factors that each developer must consider before deciding on a particular method.
You can find more information about user account protection in Windows Vista in Developer Best Practices and Guidelines for Applications in a Least-Privileged Environment.