Hardcoding of Module Base Addresses

As mentioned previously, the Lockdown module now implements a checksum over game executables in-memory instead of on-disk. Taking advantage of this change, the Lockdown module can hardcode the base address of the main process executable at the default address of 0x00400000. This is safe because no Blizzard game executable includes base relocation information, and as a result will never change from this base address.

By virtue of hardcoding this address, it becomes more difficult for an untrusted process to successfully call the Lockdown module. Unless the programmer is particularly clever, he or she may not notice that the Lockdown module is not actually performing a checksum over the main executable for the desired Blizzard game, but instead the main executable of the untrusted process (the default address for executables in the Microsoft linker program is the same 0x00400000 value used in Blizzard's main executables comprising their game clients).

While it is possible to change the base address of a program at link-time, which could be done by a third-party process in an attempt to make it possible to map the desired Blizzard main executable at the 0x00400000 address, it is difficult to pull this off under Windows NT. This is because the 0x00400000 address is low in the address space, and the default behavior of the kernel's memory manager is to find new addresses for memory allocations starting from the bottom of the address space. This means that in virtually all cases, a virgin Win32 process will already have an allocation (usually one of the shared sections used for communication with CSRSS in the author's experience) that is overlapping the address range required by the Lockdown module for the main executable of the Blizzard game for which a challenge response is being computed. While it is possible to change this behavior in the Windows NT memory manager and cause allocations to start at the top of the address space and search downwards, this is not the default configuration and is also a relatively not-well-known kernel option. The fact that all users would need to be reconfigured to change the default allocation search preference for an untrusted process to typically successfully map the desired Blizzard game executable makes this approach relatively painful for a would-be attacker.

The Lockdown module also ensures that the return value of the GetModuleHandleA(0) Win32 API corresponds to 0x00400000, indicating that the main process image is based at 0x00400000 as far as the loader is concerned. The restriction on the base address of the game main executable module has the unfortunate side effect that it will not be possible to take advantage of Windows Vista's ASLR attack surface reduction capabilities, negatively impacting the resistance of Blizzard games to certain classes of exploitation that might impact the security of users.

This protection mechanism is primarily considered to be an anti-emubot scheme, as it is designed to guard against an untrusted process from succcessfully calling the Lockdown module.