Signing .NET assemblies: Does this protect my assembly from tampering really?

Question

I am implementing a "locking" system in my app which protects my app against being copied and used illegally. The system checks the signature of a hardware-based code and expects it to be signed with a Private Key that only my company owns. (The app has got the Public Key to validate the signature.)

I want to make sure that no one changes my locking mechanism in the app, so I want to sign my app's assembly and I think it makes sense.

1. Since I haven't seen the CLR ever talk about an assembly's signature being invalid, I want to make sure this system really works. Does it? What should I do to make it work?
2. Can an attacker concentrate his efforts on the CLR to make it not care about my signature? That is, if he can't tamper with my code because I've signed it, can he tamper with CLR?
3. Generally, I would like to know your experience about such safe-guards and protection technologies. Can any one suggest anything else?

Answer 1

Signing your code only allows tamper detection, it doesn't prevent it. Somebody who knows what they are doing can remove your signature and if necessary add their own.

Really most copy protection schemes are a waste of time and can be subverted, and they also tend to annoy the hell out of your paying customers. Ultimately you can't prevent somebody from modifying and running your code on hardware that they control. Just make it sufficiently difficult that it is easier to go to the purchasing department and get a check written, and that it is difficult to forget that you haven't got a licensed copy. Those who care will eventually pay, and those who don't never will.

Also note that even if you think that most people won't bother cracking your scheme, or haven't the skill to do it, it doesn't matter. Because once one person has subverted your copy protection scheme, they can make it available on a torrent site for those without the skill to do it, and it is game over.

Answer 2

Assembly signing is designed to allow applications/assemblies to reference an assembly and be sure that they get the assembly they originally referenced. If someone wanted to, they could in theory decompile your entire app and recompile with no signing. (ie: they could recompile the referencing assembly so that it referenced an unsigned version of the referenced assembly).

They would then be able to modify the code as they wanted, because the client (exe) would now reference an unsigned (or 're-signed') dll.

To make the process of decompilation and recompilation more difficult, you could try creating a mixed-mode C++/CLI assembly containing both managed and native code. But yeah... ultimately people have all your binaries to hand and with enough effort can probably get round any licensing system you think up.

Answer 3

There's a certaining amount of misconception about signed assemblies. Assembly signing is not, as mackenir pointed out, a secure mechanism to be used to prevent your assemblies from being tampered with. The following article on codeproject gives a pretty good treatment of the subject:

http://www.codeproject.com/KB/security/StrongNameExplained.aspx

Answer 4

One technique you can use is to prevent tampering is to use the public key of your assembly to encrypt essential parts of your software such as application/algorithm parameters. If the public key has been changed, the decryption will not work and your app will crash.

Some obfuscators such as Crypto Obfuscator use this technique with the string encryption feature. It uses the public key of your assembly to encrypt all strings. If the public key has been changed or removed, decryption will fail and your app wont even start.