views:

34

answers:

4

I want to protect my applications from reverse engineering.

What I would like to do is protect the executable from any tampering, such as with hex editors, resource editors, and dis-assembly tampering.

My idea is to have the application check the hash value of itself against an imported value in a version file from the service server (probably an xml file or flatfile), then shut down the application or somehow disable it's functionality completely if the values do not match.

I am in strange waters here, so if anyone has any comments, suggestions, ideas, or code examples, I would appreciate it.

The Development Language is C++ but I would happily take examples from any language.

Thanks in advance for any assistance.

+4  A: 

I'm afraid it's not that easy.

If someone has the ability to modify the executable, then they have the ability to remove any check the application does against a known hash.

You can do more complicated things, such as encrypt the application's data using the hash of the known executable as the key, but that only makes it slightly more difficult to circumvent.


The makers of all kinds of very expensive software have been trying to come up with a solution to this for decades - and their efforts have always been worked around by people with far fewer resources.

Joe Gauterin
+1  A: 

The short answer is you can't. You can make it more difficult, but ultimately your code has to run on the processor, so the instructions can be read, modified or ignored on the fly.

If you can control the hardware, then you can make it harder, but ultimately if people are determined enough, they can break through whatever you do.

Appeal to people's honesty, it's easier for you and probably just as effective!

Peter
A: 

The only solution that really prevents your software from being tampered is encrypting the executable and decrypting only that parts of it which are currently executed - and only if the decryption is done in a "trusted device", e.g. a USB dongle.

There are some products available which are pretty good, e.g. a product of my employer.

All software-only protection schemes can more or less easily be cheated.

ur
This doesn't really protect it. Such protection schemes have been cracked by simply fishing out the code as it was being decrypted, and reconstructing a decrypted version. If part of the code was being executed on the dongle itself, that would be a different situation. Rule of thumb: if it ever runs on my CPU, I can steal it.
CyberShadow
@CyberShadow: Generally speaking you're right, but it is possible to make it too hard to be economically reasonable. There are countermeasures and one I already mentioned: Never decrypt the whole binary at once. Use more than one key for different parts of the executable. Fight known debuggers. ...
ur
A: 

Try obfuscating the code so that it would frustrate anyone trying to reverse-engineer it or have it self-destroy itself if anyone tried to tamper with it!

Frank Computer