detect modified .exe (build)

Question

Is there anyway for a program to know if it has been modified since it was compiled and built? I'd like to prevent the .exe from being modified after I build it.

Answer 1

even if you know.. the person who knows you had such a prevent, will change computer time to your build time than modify this exe..

so it can not be a prevention..

Answer 2

You could use a private key to sign the EXE, and public key to check that signature. I haven't worked with the EXE file format in nearly 20 years, but as I recall there are spaces where you could store such a signature. Of course, the portion of the file that you're checking would have to exclude the signature itself.

However, if you're trying to do this to prevent cracking your EXE, you're out of luck: the cracker will simply patch out the code that validates the signature.

Answer 3

Is it possible for a program to know if it has been modified since it was built?

Yes. A checksum of the rest of the program can be stored in an isolated resource string.

Is it possible for a program to know if it was maliciously modified since it was built?

No. The checksum, or even the function that executes and compares it, could be modified as well.

Answer 4

Are you talking about Tamper Aware and Self Healing Code?

The article demonstrates detecting hardware faults or unauthorized patches; back patching the executable to embed the expected hash value of the .text section; and demonstrates the process of repairing the effects of hostile code (for example, an unauthorized binary patcher). The ideas presented in the article work equally well whether the executable was patched on disk or in-memory. However, the self repair occurs in memory.

Answer 5

Most popular compilers have a switch to fill in the "Checksum" field of the PE header, or, you can leave it blank and supply your own custom vale. At any rate this is the 'standard' place to store such data.

Unfortunately there's no real way to stop someone tampering with a binary, because you'll have to put checks inside the exe itself to detect it, at which point they can be patched out.

One solution to this problem is to encrypt certain functions and use the checksum of some known data as the key (for example the checksum of another function). Then, when you leave the function you reencrypt it. Obviously you'll need to come up with your own prologue/epilogue code to handle this. This is not really suitable if your program is heavily multi-threaded, but if you're single-threaded or only lightly threaded (and can serizalize access to the functions and control all entry points) then this will 'raise the bar' if you will.

That is a step above most 'packers' which simply encrypt the .text/.data/.rdata/etc sections and decrypt it all at runtime. These are very easy to 'dump', as all you have to do is run the program, suspend all its threads, then dump the memory to a file. This attack works against Themida for example (one of the most aggressive packers). From there all you need to do is rebuild the IAT, fix up some relocs, etc.

Of course it's still possible for the attacker to use a debugger to dump out the unencrypted code and hence 'unpack' the exe, but obviously nothing is foolproof.