Conclusion

Although the Lockdown module and associated authentication system represent a major break in Blizzard's ongoing battle against non-genuine Battle.net client software, there are still many improvements that could be made in a future release of the version check and authentication system which would fit within the constraints imposed on the version check system, and still pose a significant challenge to an adversary attempting to spoof Battle.net logons using a non-genuine clients. The author would encourage Blizzard to consider and implement enhancements akin to those described in this paper, particularly protections that overlap and complement each other (such as the debug register clearing and memory checksum schemes).

In the vein of improving the Lockdown system, the author would like to stress the following principles as especially important in creating a system that is difficult to defeat and yet still workable and viable from a development and deployment perspective:

Defense in depth with respect to the various protection mechanisms in place within the module is a must. Protection systems need to be designed to complement and reinforce eachother, such that an attacker must defeat a number of layers of protection schemes for any one significant attack to succeed to the point of being a break in the system.
Countermeasures intended to frustrate reverse engineering or easy duplication of critical algorithms need to be viewed in the light of what an adversary might do in order to 'attack' (or duplicate, re-implement, or whatnot) a 'guarded' (or otherwise important) algorithm or section of code. For example, an attacker could ease the work of reimplementing parts of an algorithm or function of interest by wholesale copying of assembler code into a different module, or by loading an "authentic" module and making direct calls into internal functions (or the middle of internal functions) in an effort to bypass "upstream" protection checks. Keeping with this line of thinking, it would be advisible to interleave protection checks with code that performs actual useful work to a certain degree, such that it is less trivial for an adversary to bypass protection checks that are entirely done "up front" (leaving the remainder of a secret algorithm or function relatively "vulnerable", if the check code is skipped entirely).
Countermeasures intended to create "time sinks" for an adversary need to be carefully designed such that they are not easily bypassed. For instance, in the current Lockdown module implementation, there are twenty flavors of the Lockdown module; yet, in this implementation, it is trivially easy for an adversary to discover the differences (in a largely programmatic fashion), making this "time sink" highly ineffective, as the time for an adversary to breach it is likely much less than the time for the original developers to have created it.
Measures that depend on external, imported APIs are often relatively easy for an attacker to quickly pinpoint and disable (for example, the method that debug register breakpoints are disabled by the Lockdown module is immediately obvious to an adversary, if they are even the least bit familiar with the Win32 API (which must be assumed). In some cases (such as with the debug register breakpoint clearing code), this cannot be avoided, but in others (such as validation of module base addresses), the same effect could be potentially implemented by use of less-obvious approaches (for example manually traversing the loaded module list by locating the PEB and the loader data structures from the backlink pointer in the current thread's TEB). The author would encourage the developers of additional defensive measures to reduce dependencies on easily-noticible external APIs as much as possible (balanced, of course, against the need for maintainable code that executes on all supported platforms). In some instances, such as the manual resolution of Storm symbols, the current system does do a fair job of avoiding easily-detectable external API use.

All things considered, the Lockdown system represents a major step forward in the vein of guarding Battle.net from unauthorized clients. Even so, there is still plenty of room for improvements in potential future revisions of the system. The author hopes that this article may prove useful in the strengthening of future defensive systems, by virtue of a thorough accounting of the strengths and weaknesses in the current Lockdown module (and pointed suggestions as to how to repair certain weaker mechanisms in the current implementation).