views:

132

answers:

6

My logic of APT (Anti-Paching Technology) is as follows...

1) Store on the MSSQL server the md5 hash of the executable for protection.

2) Perform an md5 comparison (within my application startup) the hash found on the server, with the executable itself.

3) If comparison fails exit application silently.

And all these above before it is finally pached!

I mean what is your best way to protected a file from being patched? Without using ready tools (.net reactor, virtualizer etc)

Edit: Something else just came into my mind.

Is there any way of checking the application integrity on server side? I mean my app works only online. Could i execute something on the server (my domain) that could check the application integrity?

+5  A: 

The thing is a cracker would patch the application precisely on step 2, removing the hash check code.

So I wouldn't call that very effective against serious crackers.

EDIT: I guess your best bet is defense in depth, given that your app has to be online I'd:

  • Require authentication: Authenticate users, hopefully via a cryptographic key, and require a key check to receive/send data.
  • Obfuscation: It makes things harder for crackers.
  • Continued checks: Besides checking who is sending data, validate the application each time a request is sent.

These all can still be circumvented, but they make things a lot harder and might disuade some if your app is not worth that much to them.

Vinko Vrsalovic
Thats why i added "And all these above before it is finally pached!"Could you point me to something more secure?
Chocol8
Upvote for use of the proper term of cracker.
Ölbaum
@gipap: the cracker modifies your program *before* it runs. By deifnition your program can't do anything before it runs. And after it's been modified it's effectively no longer your program.
MSalters
@MSalters: My app uses webservices to connect to MSSQL server. Could i compute the md5 of the winforms application which tries to connect with a web service or anything else?
Chocol8
@Strakastroukas: in essence no. If they can modify programs on the system, they can modify whatever is that is supposedly calculating the md5 sums to make it return the sum of the unmodified versions of programs.
Stephen C
+2  A: 

you can't. once someone else has your file they can do what they like with it - first thing would be to patch out your anti-patching code.

wefwfwefwe
+2  A: 

A patched application means the 'cracker' has complete control over the machine the code is running on (at least enough control to patch the executable). So patch prevention however smart it might be is working against the flow of control.

Complicating your binary file might be enough to discourage patching so obfuscators are propably your best bet.

Barfieldmv
+1  A: 

If the application is running on someone else's machine, you cannot prevent them from patching it. You can make it harder, but it's a shell game: you cannot win. Regardless of how complicated you make it, some guy somewhere will see it as an interesting challenge to break your protection, and he will succeed. Then, everyone else just has to download his version. The most extreme form of patch-protection today is Skype (that I know of). It's insanely complicated, and yet it has been broken.

Since your application apparently runs online, you can ask yourself why you want to prevent patches in the first place (maybe it's to prevent the user from entering some bad values? Or to prevent them from seeing some information that's present in the program?), and then architect your program so that whatever you want to keep hidden or checked happens on the server.

For example if it's a game and you want to prevent players from hacking the game to know where the other players are: change the server so it only sends coordinate information for the players that you can already see.

Another example: if it's an online store and you want to make sure users don't submit purchase orders with incorrect prices, check the prices at the server.

The only exception there is if you control the hardware that the program's running on. But even there, it's very hard to do it right (see: XBox, PS3, and the many other consoles that tried to do that and failed). It's probably still better to leverage the client/server architecture rather than betting on "trusted computing".

redtuna
A: 

Crackers nowadays don't bother patching your executable file; they simply change your program's variables in-memory to make its behaviour more amenable to their requirements. Defending against this is very difficult and reasonably pointless; most games' crack-protection works only by searching for signatures of known crack programs (like an AV engine does).

MarkR
A: 

Everyone nailed it, you can't stop someone but you can make it harder for them, you could even go off the deep end and make some in-memory validation stuff like World Of Warcrafts Warden system.

If you tell us what language you are writing in we might be able to suggest some simple obfuscation methods.

Collin