Modifying compiled executable memory allocation

I have a compiled executable with no access to the source code. Every time it runs a variable is assigned to memory address 0x7B008C. I am trying to make it use a different address rather than that one each time. It does not have to be dynamic because my purpose is only to break currently existing applications that modify the behavior of the 开发者_如何学Gosource program.

So my question is, what is the easiest way to achieve this without breaking the behavior of the program?

In general, you can't.

When executables are compiled, references to static variables are resolved by the linker, in the machine code, to the raw address of the variable. No indication that such a reference existed is left, and due to the nature of x86 machine code, it is very difficult to find these references later (you can't necessarily tell where instructions begin unambiguously).

Moreover, you don't know if that's just an ordinary variable. It might be part of a static class or structure. These distinctions are lost after compilation, but when trying to move variables, it makes it that much more difficult - it could be that code is referencing it based on an offset from another variable (ie, the start of the struct).

What are you really trying to accomplish here? There may be a better way than just messing with virtual memory layouts.

If you're just trying to break existing trainers, one approach (untested!) might be to alter the process ACL. When creating the process, use CreateProcess and pass in a custom security descriptor for lpProcessAttributes and lpThreadAttributes (for a process that's already running, you can do this with SetSecurityInfo). Set the DACL in the security descriptor so that only SYNCHRONIZE | PROCESS_QUERY_INFORMATION | PROCESS_SUSPEND_RESUME | PROCESS_TERMINATE rights are granted (ie, revoke all other rights on all DACL entries). This technique is not foolproof - a trainer aware you're doing this can simply set the DACL back to default; however it should break existing trainers, by denying them debug access.

You could probably do it by going through the entire executable with BEAEngine (I say probably because I've never done it, thought I've used BEAEngine and it's capable of doing it), but it would be very involved and probably pretty complicated.

I wouldn't waste my time trying to do it though, because, like bdonlan, I wouldn't care about people using trainers on a single player game. And there are other, less complex ways of breaking trainers than what you describe.