|Informative Information for the Uninformed
The original "ver" module scheme pioneered a system wherein there were multiple downloadable flavors of the version check module to be used by a client. The Battle.net server sends the client a tuple of (version check module filename, checksum formula and initialization parameters, version check module timestamp) that is used in order to version (and download, if necessary) the latest copy of the version check module. This mechanism provides for the possibility that the Battle.net server could support multiple "flavors" of version check module that could be distributed to clients in order to increase the amount of work required by anyone seeking to reimplement the version check and authentication system.
The original "ver" module and associated authentication scheme in fact utilized such a scheme of multiple "ver" modules, and the Lockdown scheme expands upon this trend. In the original system, there were 8 possible modules to choose from; the Lockdown system, by contrast, expands this to a set of 20 possibilities. However, the version check modules in both systems are still very similar to one another. In both systems, each module has its own unique key (a 32-bit values in the "ver" system, and a 64-bit value in the Lockdown system) that is used to influence the result of the version check checksum (it should be noted that in the Lockdown system, the actual Lockdown module itself is in essence a second "key", as the added checksum over the module represents an additional adjustment to the final checksum result that changes with each Lockdown module). This single difference is disguised by other minor, superficial alterations to each module flavor; there are slight differences by which module base addresses are retrieved, for instance, and there are also other superficial differences that relate to differences like code being moved between functions or functions being re-arranged in the final binary in order to frustrate a simple "diff" of two Lockdown modules as being informative in revealing the functional differences between the said two modules.
This protection mechanism is perhaps best classed as an anti-analysis scheme, as it attempts to create more work for anyone attempting to reverse engineer the authentication system as a whole.