Question

I have intellectual-property coded into .net 2.0 fully-trusted assemblies (.exe + DLLs) on an end-user machine, which I would like to protect from being hacked / reverse-engineered (WebService / Cloud-Computing solutions are not an option). Below is a list of techniques I gathered in order to reach this goal.

My questions are:

1. Are my assumptions correct, or am I doing something wrong in one or more of the techniques?
2. Will this list be sufficient in order to prevent a malicious attack, or are there other protections I should add?

Thanks in advance.

—

Suggested Techniques

1. Sign all assemblies with the same strong-name key.
   This has two benefits:
   • A. Make sure any modification to an assembly will render it useless,
   • B. All assemblies will have the same public key, by which they can identify each other.
2. Digitally sign the assemblies: Both let the users know that the executed code came from the correct source, and – add another identification component by which assemblies could identify each other.
3. Enforce the above by crawling up the call-stack and verifying that all callers are inside the “community”.
   Possible leads:
   • Hallgrim’s idea in this S.O. thread.
   • Daniel Brückner‘s addition in this S.O. thread.
   • This .Net Security Blog Post, which combines both solutions.
4. Use AOP (e.g. Spring.NET) to inject the call-stack crawling code into some/all methods.
   • This is mainly done because there’s no single entry point (like DllMain() for Win32 DLLs) in a .net assembly.
5. Obfuscate all assemblies in order to hamper reverse-engineering and reflection-execution attempts (strong name signing will be performed after obfuscation, of course).
6. Integrate a System.ComponentModel.LicenseProvider mechanism.
7. Make use of the “InternalsVisibleTo” assembly-level attribute in order to expose internals among a pre-defined set of assemblies.
8. Possibly use NGEN in order to convert the solution to native code.

Points to Consider

• Implementing part or all of the above will most-likely introduce a performance penalty, so time-critical processing, for example, should be handled with care.
• CAS seems to be irrelevant for this type of fully-trusted assemblies.

Answer 1

I’m afraid you won’t get all the security you want. You see, this is a problem with these languages/platforms that use an itermediate language. It must be in a format that all of the runtimes implementations can consume and then produce the native code.

I’ve seen some blog posts about tampering signed assemblies. I haven’t tried yet, but I think it works. Besides that, the obfuscation tools will just make it harder, but not impossible to extract code (altough there are some pretty good tools that make it very hard). And NGEN is not for that. You still have do distribute the original assemblies.

I think that the most efective and secure way of protect your code, is to move it to a technology that you can’t decompile, for example, move your sensitive code to unmanaged C++ and use DLLImport on your C# code.

It doesn’t mean that you shouldn’t try to protect your code, but you should have in mind that you won’t be 100% protected. If you can’t afford to rewrite your sensitive code in another language, go with obfuscation and signing. You can’t get much more secure than that.