Introduction

The Lockdown module is a part of several schemes that attempt to make it difficult to connect to Battle.net with a client that is not a "genuine" Blizzard game. For the purposes of this paper, the author considers both modified/"hacked" Blizzard game clients, and third-party client software, known as "emubots", as examples of Battle.net clients that are not genuine Blizzard games. The Battle.net protocol also incorporates a number of schemes (such as a proprietary mechanism for presenting a valid CD-Key for inspection by Battle.net, and a non-standard derivative of the SRP password exchange protocol for account logon) that by virtue of being obscure and undocumented make it non-trivial for an outsider to successfully log a non-genuine client on to Battle.net.

Prior to the launch of the Lockdown module, a different system took its place and filled the role of validating client software versions. The previous system was resistant to replay attacks (caveat: a relatively small pool of challenge response values maintained by servers makes it possible to use replay attacks after observing a large number of successful logon attempts) by virtue of the use of a dynamically-supplied checksum formula that is sent to clients (a challenge, in effect). This formula was then interpreted by the predecessor to the Lockdown module, otherwise known as the "ver" or "ix86ver" module, and used to create a one-way hash of several key game client binaries. The result response would then be sent back to the game server for verification, with an invalid response resulting in the client being denied access to Battle.net.

While the "ver" module provides some inherent resistance to some types of non-genuine clients (such as those that modify Blizzard game binaries on disk), it does little to stop in-memory modifications to Blizzard game clients. Additionally, there is very little to stop an attacker from creating their own client software (an "emubot") that implements the "ver" module's checksum scheme, either by calling "ver" directly or through the use of a third-party, reverse-engineered implementation of the algorithm implemented in the "ver" module. It should be noted that there exists one basic protection against third party software calling the "ver" module directly; the "ver" series of modules are designed to always run part of the version check hash on the caller process image (as returned by the Win32 API GetModuleFileNameA). This poses a minor annoyance for third party programs. In order to bypass this protection, however, one need only hook GetModuleFileNameA and fake the result returned to the "ver" module.

Given the existing "ver" module's capabilities, the Lockdown module represents a major step forward in the vein of assuring that only genuine Blizzard client software can log on to Battle.net as a game client. The Lockdown module is a first in many respects for Blizzard with respect to releasing code that actively attempts to thwart analysis via a debugger (and actively attempts to resist being called in a foreign process with non-trivial mechanisms).

Despite the work put into the Lockdown module, however, it has proven perhaps less effective than originally hoped (though the author cannot state the definitive expectations for the Lockdown module, it can be assumed that a "hacking life" of more than several days was an objective of the Lockdown module). This paper discusses the various major protection systems embedded into the Lockdown module and associated authentication system, potential attacks against them, and technical counters to these attacks that Blizzard could take in a future release of a new version check/authentication module.

Part of the problem the developers of the Lockdown module faced relates to constraints on the environment in which the module operates. The author has derived the following constraints currently in place for the module:

The server portion of the authentication system is likely static and does not generate challenge/response values in real time. Instead, a pool of possible values appear to be pregenerated and configured on the server.
The module needs to work on all operating systems supported by all Blizzard games, which spans the gamut from Windows 9x to Windows Vista x64. Note that there are provisions for different architectures, such as Mac OS, to use a different system than Windows architectures.
The module needs to work on all versions of all Blizzard Battle.net games, including previous versions. This is due to the fact that the module plays an integral part in Battle.net's software version control system, and thus is used on old clients before they can be upgraded.
Legitimate users should not see a high incidence of false positives, and it is not desirable for false positives to result in automated permanent action against legitimate users (such as account closure).

As an aside, in the author's opinion, the version check and authentication system is not intended as a copy protection system for Battle.net, as it does nothing to discourge additional copies of genuine Blizzard game software from being used on Battle.net. In essence, the version check and authentication system is a system that is designed to ensure that only copies of the genuine Blizzard game software can log on to Battle.net. Copy protection measures on Battle.net are provided through the CD-Key feature, wherein the server requires that a user has a valid (and unique) CD-Key (for applicable products).