Main Process Image Module Base Address Restriction

An attacker seeking to execute the Lockdown module in an untrusted process would need to bypass the restrictions on the base address of the main process image. The most likely approach to this would be a combination attack, whereby the attacker would use something like a set of hardware breakpoints to alter the hardcoded restrictions on module base addresses, and import table or code patch style hooks on the GetModuleHandleA API in order to defeat the secondary check on the module base address for the main executable image.

Another approach would be to simply create the main executable image as a process, suspended, and then either create a new thread in the process or assume control of the initial thread in order to execute the Lockdown module. This gets the would-be attacker out of having to patch checks in the module, as there is currently no defense against this case implemented in the module.

In order to strengthen this protection mechanism, the following approaches could be taken:

1. Manually traverse the loaded module list (and examine the PEB) in order to validate that the main process image is really at 0x00400000. All of these mechanisms could be compromised, but checking each one creates additional work for an attacker.
2. Verify that the game has initialized itself to some extent. This would make the approach of creating the game process suspended more difficult. It would also otherwise make the use of the Lockdown module in an untrusted process more difficult without tricking the module into believing that it is running in an initialized game process. The scope of determining how the game is initialized is outside of this paper, although an approach similar to the current one based on a checksum of Storm video memory (though with more "redundancy", or an additional matrix of requirements for a legitimate game process).