Memory Checksum Performed on the Lockdown Module

The Lockdown module, contrary to the behavior of its predecessor, implements a checksum of several key game executable files in-memory instead of on-disk. In addition to the checksum over certain game executables, the Lockdown module includes itself in the list of modules to be checksumed. This provides several immediate benefits:

1. Attempts to set conventional software breakpoints on routines inside the Lockdown module will distort the result of the operation, frustrating reverse engineering attempts. This is due to the fact that so-called software breakpoints are implemented by patching the instruction at the target location with a special instruction (typically `int 3') that causes the processor to break into the debugger. The alteration to the module's executable code in memory causes the checksum to be distorted, as the `int 3' opcode is checksumed instead of the original opcode.
2. Attempts to bypass other protection mechanisms in the Lockdown module are made more difficult, as an untrusted process that is attempting to cause the Lockdown module to produce correct results via patching out certain other protection mechanisms will, simply by virtue of altering Lockdown code in-memory, inadvertently alter the end result of the checksum operation. The success of this aspect of the memory checksum protection is related to the fact that the Lockdown module attempts to disable hardware breakpoints as well. These two protection mechanisms thus complement eachother in a strong fashion, such that a naive attempt to compromise one of the protection schemes would usually be detected by the other scheme. In effect, the result is a rudimentary "defense in depth" approach to software protection schemes that is the hallmark of most relatively successful protection schemes.
3. The inclusion of the version check module itself in the result of the output of the checksum is entirely new to the version check and client authentication system, and as such poses an additional, unexpected "speed bump" to persons attempting to reimplement the Lockdown algorithm in their own code.

This protection mechanism has characteristics of both an anti-debugging, anti-hack, and anti-emubot system.