Offset in DLL file is different from virtual address. Basically a PE file (which includes DLLs) consists of sections, each section loads at different address and that information can be found in the file header. Here's some information about PE file format.

You're going to have to write a PE module parser, because DLLs have relocation sections which modify the code depending on where it is loaded, and even then you can only compare the memory segment.

Honestly, if you just want to make sure the file hasn't been modified, you're better off using some kind of machine code obfuscator. It's trivial to reverse engineer the kind of check you're trying to write and make it refer to some other file (like the original dll renamed to "original.dll.org") instead of the file you want it to refer to.

You can't have very good anti-hacker "security" at all in software - it simply isn't possible to thwart talented reverse engineers, and anybody that does reverse engineering is going to be talented because it's not something that everyday people do. The closest thing to an amateur reverse engineer is a student doing something for class, but they're not going to hacking your program anyways so you don't need to worry about them.

If you still insist on doing basic checks for whatever reason, then you absolutely must learn how DLLs are loaded and processed by the system, and how reverse engineering and debugging is done. Two starting places: What Goes On Inside Windows 2000: Solving the Mysteries of the Loader; Windows Anti-Debug Reference.

Another simple trick is using the process and thread permission system implemented in windows - the common trick (by cheaters far more than by reverse engineers) of using WriteProcessMemory can be somewhat circumvented by having the process revoke all permissions to it's token at the very start of the program, which can make it difficult for the cheater to get it's process permission to open the process with write priveleges. In order to take advantage of that, though, you'll need to have the main executable launch a copy of itself using CreateProcess and pass the "CREATE_BREAKAWAY_FROM_JOB | DETACHED_PROCESS | CREATE_NEW_PROCESS_GROUP" with the appropriate permissions. Another simple way is to make a number class that stores important numeric values in two separate variables. For example, for a 32-bit int, you'd store it as one 32-bit int that is a random number and then all accesses to the value would be based on the random number XOR an appropriate value to get the final value. That way, searching memory for a specific number will never find it, and actual reverse engineering is required.

[Edited by - Extrarius on November 25, 2008 11:25:03 AM]

Points to Extrarious for the link to the loader article! (That's the first thing I thought of when I saw the thread title). Points to muse1987 as well. Pietrek owns spelunking the PE File.

There's more to be gleaned via wikipedia: Portable Executable. There are few links here that aren't there. There's info about debugging info here. There are additional links here.

Let's not forget that Windows is going to dynamically rebase DLLs as necessary, plus Vista may apply ASLR to the thing. That's going to alter all sorts of addresses, even within the code segment.