1

I'm currently learning MSIL and wanted try, if I can "crack" an assembly only editing byte codes via Notepad++ (with Hex-Editor plugin). So I wrote a simple console application taking one argument, hashing it (SHA256), comparing it with an already set hash and writing "Right" or "Wrong" to the console. I opened this little application with ildasm.exe and saw that I only have to change 2 bytes to make my application say "Right" everytime. So I opened it in Notepad++, changed these two bytes and it worked. Now I wanted to try to protect my application against attacks like the one I tried. I came across strong name key files, but I was still able to change these to bytes two make my application say "Right" everytime.

So my question: Is there a way of protecting an .NET assembly from editing opcodes? I don't mean to protect it from opening in Notepad++, but I mean a mechanism that allows my application to detect changes made to the executable's file (without checking the file's modification date). I know that there is no full protection and there will be gaps everytime, but there have to be a way to give applications at least a little bit of modification protection.

For example: I could try to make a hash out of my application and compare to a given hash, but this can't work, because when I make a hash and put this hash into my application the application's hash will change.

JasonMArcher
  • 14,195
  • 22
  • 56
  • 52
Cubi73
  • 1,891
  • 3
  • 31
  • 52
  • Your last paragraph eloquently describes the problem. No matter how many locks you put in your software, you still have to give keys to your legitimate users to get the program to run, and if the legitimate users have the keys, so do the illegitimate ones. – Robert Harvey Jul 29 '14 at 20:50
  • 1
    @MainMa: The OP never mentioned assembly signing. – Robert Harvey Jul 29 '14 at 20:54
  • @Robert Harvey: Nope. I mean that the hash representing my application is built into the application, so I don't have to give the hash to the users. The hash would come with the excutable. The file and thus the hash would still be modifiable and of course the little piece of code validating not changed code is also attackable. That's the reason why I'm asking for a way of code protection. (And yes, I heard know programs like Codefuscator, but I wanted to try something like a built-in protection) – Cubi73 Jul 29 '14 at 21:07
  • 1
    The best (and probably only viable) way to protect software nowadays is to have a dependency on an Internet resource somewhere that you control (i.e. online registration). It's still not foolproof, however. – Robert Harvey Jul 29 '14 at 21:09
  • @RobertHarvey: he's concerned about someone savvy enough to operate ildasm or a hex editor.. in the case of an internet service dependency you would just change the function that checks for valid keys to always return true - wouldn't matter what the server said. – Sam Axe Jul 13 '15 at 05:09
  • Security is the enemy of usability (they say). One method of protecting your assembly *might* be via asymmetric encryption. Place vital functionality in a separate assembly. When the user registers their license, issue them an encryption key. Send the user the DLL and the public side of the key. Then your app can decrypt and load the assembly from memory. While this would probably slow down all but the most determined - its a LOT of overhead on your side. Probably not worth it unless you are charing tens of thousands of dollars per license. – Sam Axe Jul 13 '15 at 05:16
  • @SamAxe True. You would have to keep some critical resource on the server. – Robert Harvey Jul 13 '15 at 13:57

0 Answers0