Protecting an executable file from being repaired
My APT (Anti-Paching Technology) logic is as follows ...
1) Store the md5 hash file of the executable file on the MSSQL server for protection.
2) Perform an md5 comparison (when running my application) the hash found on the server with the executable itself.
3) If the comparison does not allow you to exit the application silently.
And all of this above before it is finally engraved!
I mean, what's your best way to protect a file from being patched? Without using off-the-shelf tools (.net reactor, virtualizer, etc.)
Edit: Something else came to my mind.
Is there a way to check the integrity of the server side application? I mean my application only works on the internet. Can I do something on the server (my domain) that can check the integrity of the application?
source to share
The point is that the attacker fixed the application exactly in step 2 by removing the hash verification code.
So I wouldn't call it very effective against serious crackers.
EDIT: I think your best bet is defense in depth, given that your application needs to be online, I would:
- Require authentication. Authenticate users, hopefully, with a cryptographic key and require a key validation to send / receive data.
- Obfuscation: This makes it harder to work with crackers.
- Continuation of verification. In addition to checking who is submitting the data, check the application every time a request is sent.
All of these can be circumvented, but they make things much more difficult and can get away with them if your application isn't worth it.
source to share
A patch application means that the "cracker" has full control over the machine the code is running on (at least enough control to patch the executable). Thus, patch prevention, while it may be effective, has to do with the flow of control.
Complicating your binary can be enough to prevent a fix, so obfuscators are probably the best way to help you.
source to share
If the application is running on someone else's machine, you cannot prevent them from fixing it. You can make it harder, but this is a shell game: you cannot win. No matter how difficult you make it, some guy somewhere will see it as an interesting challenge to break your defenses and he will succeed. Then everyone else needs to download their version. The most extreme form of patch protection today is Skype (which I know of). It's insanely complex, and yet it was broken.
Since your application appears to be running on the web, you may be asking yourself why you want to prevent fixes in the first place (maybe this should prevent the user from entering some bad values? Or prevent them from seeing any information present in program?) and then the architect of your program so that whatever you want to hide or check happens on the server.
For example, if this is a game and you want players not to hack into the game to find out where other players are: change the server to only send coordinate information to the players you already see.
Another example: if this is an online store and you want users not to submit purchase orders with incorrect prices, check the prices on the server.
The only exception is if you control the hardware the program runs on. But even there it is very difficult to do it right (see: XBox, PS3 and many other consoles that have tried and failed). It may be even better to use a client / server architecture rather than relying on "trusted computing".
source to share
Crackers does not currently fix your executable; they simply change your program variables in memory to make their behavior more amenable to their requirements. Defending against this is very difficult and reasonably pointless; Most games' hacking protection only works by looking for signatures of known crack programs (like AV engine).
source to share
Everybody nailed it, you can't stop someone, but you can make it harder for them, you can even get away from the deep end and do some things to check in memory like the World Of Warcrafts Warden system.
If you tell us what language you are writing in, we can suggest some simple obfuscation techniques.
source to share