Protect .Net Code from Reverse Engineering

How can I protect my .NET assemblies from decompilation?

One thing to keep in mind is that you want to do this in a way that makes business sense. 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 for products like Windows and Photoshop) is proof a determined hacker can always gain access.

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 the 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 costs. It takes effort, which means adding cost somewhere in the process, and so reduces that side of the equation. Protecting your product also fails 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 the reality is this will never happen. There is some hyperbole here, but it generally holds that pirates who are unable to crack your security will either find a similar product they can crack or do without. They will never buy it instead, and therefore they do not represent lost sales.

Additionally, securing your product actually reduces revenue. There are two reasons for this. One is the small percentage of customers who have trouble with your activation or security, and therefore decide not to buy again or ask for their money back. The other is the small percentage of people who actually try a pirated version of software to make sure it works before buying. Limiting the pirated distribution of your product (if you are somehow able to succeed at this) prevents these people from ever trying your product, and so they will never buy it. Moreover, piracy can also help your product spread to a wider audience, thus reaching more people who will be willing to pay for 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:

How do i prevent my code from being stolen?

Securing a .NET Application

What do you use to protect your .NET code from reverse engineering?

I've had a lot of success with Xenocode Postbuild. The tool can obfuscate .NET assemblies, protect agaist Reflector disassembly, combine .NET assemblies into a single executable ("virtualization") and even compile .NET applications to standalone executables that do not need .NET runtime installed.

Prevent Decompiling

You cannot prevent decompiling, if you compile into MSIL (intermediate language). In such case you need to use obfuscation

For a deeper discussion on the subject check out this post .NET obfuscation tools/strategy

You can find a similar discussion here How can I obfuscate my c# code, so it can't be deobfuscated so easily?

You can also opt to generate a native image using Ngen.exe for a specific platform - that will bypass the IL and generate compiled processor specific machine code, and that one is pretty much safe from standpoint of reverse - engineering.

Using an IL is a quite common design choice - and it has it's drawbacks and benefits - the main ones being easier support of multiple languages on one platform, and multiple target platforms, i.e cross platform

To get a glimpse of some of the benefits of using IL - check this out - stackoverflow.com/questions/1926386/…

Java also uses an intermediate language - java bytecode - javaworld.com/article/2077233/core-java/bytecode-basics.html

Protecting my code from reverse engineering

You should obfuscate the complete code since it gets harder to reach that small valuable part. The smaller the code gets, the easier it becomes to understand it. Most obfuscators should not mess with public interfaces since there are many obfuscated libraries out there.

However I think you should rather convince users that there are no special tricks there instead of trying to hide it. To quote Kaiser Soze, "the greatest trick The Devil has ever pulled is to convince the world that he doesn't exist".

And of course you can always file a patent for your invention and protect yourself legally.

Best practice to protect resources against reverse engineering

Placing text resources in a DLL is a technique of hiding resources, not protecting them. If the goal is to protect your resources against reverse engineering, this technique would qualify only as the lowest and the least effective measure of "security by obscurity," which provides no security against anyone with minimal amount of determination to hack your resources.

For any degree of real protection you need to use encryption, because encrypting your resources with a custom key would require much higher degree of sophistication from anyone trying to reverse-engineer your system. This wouldn't made it completely impossible to reverse-engineer your system, but it would do enough to discourage hackers with limited knowledge from messing around with your code.

Protect IL from Reverse Engineering

dotfuscator

is a .net obfuscator.

Using an obfuscator doesn't mean that the code cannot be reverse engineered. But it makes reverse engineering a bit harder.

So it is not 100%.

There are other obfuscators also like

Spices.Net Obfuscator

smartassembly

Eazfuscator.NET

Free

Skater .NET Obfuscator