How can I protect my .NET assemblies from decompilation?

Question

One if the first things I learned when I started with C# was the most important one. You can decompile any .NET assembly with Reflector or other tools. Many developers are not aware of this fact and most of them are shocked when I show them their source code.

Protection against decompilation is still a difficult task. I am still looking for a fast, easy and secure way to do it. I don't want to obfuscate my code so my method names will be a,b,c or so. Reflector or other tools should be unable to recognize my application as .NET assembly at all. I know about some tools already but they are very expensive. Is there any other way to protect my applications?

EDIT:

The reason for my question is not to prevent piracy. I only want to stop competitors from reading my code. I know they will and they already did. They even told me so. Maybe I am a bit paranoid but business rivals reading my code doesn't make me feel good.

Answer 1

http://stackoverflow.com/questions/1276237/preventing-decompilation-of-c-application

Pretty much describes the entire situation.

At some point the code will have to be translated to VM bytecode, and the user can get at it then.

Machine code isn't that much different either. A good interactive disassembler/debugger like IDA Pro makes just about any native application transparent. The debugger is smart enough to use AI to identify common APIs, compiler optimizations, etc. it allows the user to meticuloulsy rebuild higher level constructs from the assembly generated from machine code.

And IDA Pro supports .Net to some extent too.

Honestly, after working on an reverse engineering ( for compatibility ) project for a few years, the main thing I got out of my experience is that I probably shouldn't worry too much about people stealing my code. If anyone wants it, it will never be very hard to get it no matter what scheme I implement.

Answer 2

host your service in the cloud.

Answer 3

I've heard about some projects that directly compile IL into native code. You can get some additional info from this post: http://stackoverflow.com/questions/140750/is-it-possible-to-compile-net-il-code-to-machine-code

Answer 4

If you want to fully protect your app from decompilation, look at Aladdin's Hasp. You can wrap your assemblies in an encrypted shell that can only be accessed by your application. Of course one wonders how they're able to do this but it works. I don't know however if they protect your app from runtime attachment/reflection which is what Crack.NET is able to do.

-- Edit Also be careful of compiling to native code as a solution...there are decompilers for native code as well.

Answer 5

We use {SmartAssembly} for .NET protection of an enterprise level distributed application, and it has worked great for us.

Answer 6

I know you don't want to obfuscate, but maybe you should check out dotfuscator, it will take your compiled assemblies and obfuscate them for you. I think it can even encrypt them.

Answer 7

At work here we use Dotfuscator from PreEmptive Solutions.

Although it's impossible to protect .NET assemblies 100% Dotfuscator makes it hard enough I think. I comes with a lot of obfuscation techniques;

Cross Assembly Renaming
Renaming Schemes
Renaming Prefix
Enhanced Overload Induction
Incremental Obfuscation
HTML Renaming Report
Control Flow
String Encryption

And it turned out that they're not very expensive for small companies. They have a special pricing for small companies.

(No I'm not working for PreEmptive ;-))

There are freeware alternatives of course;

Answer 8

One thing to keep in mind is that you want to do this in a way that makes business sense. And to do that, you need to define your goals. So, exactly what are your goals?

Preventing piracy? That goal is not achievable. Even native code can be decompiled or cracked; the multitude of warez available online (even products like Windows and Photoshop) is proof of that.

If you can't prevent piracy, then how about merely reducing it? This, too, is misguided. It only takes one person cracking your code for it to be available to everyone. You have to be lucky every time. The pirates only have to be lucky once.

I put it to you that your goal should be to maximize profits. You appear to believe that stopping piracy is necessary to this endeavor. It is not. Profit is simply revenue minus costs. Stopping piracy increases your costs, and so reduces that side of the equation. Protecting your product also does nothing to increase your revenue. I know you look at all those pirates and see all the money you could make if only they would pay your license fees instead, but that will never happen. If pirates are unable to crack your security, they'll either find a similar product that they can crack or do without. They will never buy it instead.

Additionally, securing your product actually reduces revenue. There are two reasons for this. One is that a small percentage of customers will have trouble with your activation or security, and will therefore decide not to buy again or ask for their money back. The other is that a small percentage of people actually try a pirated version of software to make sure it works before buying. So limiting the pirated distribution of your product (if you are somehow able to succeed at that) prevents these people from ever trying your product, and so they will never buy it.

A better strategy is to assume that your product will be pirated, and think about ways to take advantage of the situation. A couple more links on the topic:
http://stackoverflow.com/questions/2338337/how-do-i-prevent-my-code-from-being-stolen/2338556#2338556
http://stackoverflow.com/questions/651291/securing-a-net-application/651375#651375

Answer 9

Obfuscation is the only solution to this - some tools compile .Net assemblies to native assemblies, but I don't know how effective they are.

Look at Crypto Obfuscator - it employs a variety of obfuscation, protection and defensive techniques on your .Net assemblies. Your competitors will find it pretty hard to make sense of such assemblies. Most of the time, they will not even be able to open the assemblies in tools such as Reflector or other decompilers.