This post originated from an RSS feed registered with .NET Buzz by Eric Gunnerson. Original Post: How do I protect my C# code against reverse engineering? Feed Title: Eric Gunnerson's C# Compendium Feed URL: /msdnerror.htm?aspxerrorpath=/ericgu/Rss.aspx Feed Description: Eric comments on C#, programming and dotnet in general, and the aerodynamic characteristics of the red-nosed flying squirrel of the Lesser Antilles Latest .NET Buzz Posts Latest .NET Buzz Posts by Eric Gunnerson Latest Posts From Eric Gunnerson's C# Compendium

One of the questions that comes up often - usually after somebody comes across one of the C# decompilers, such as RemoteSoft's Salamander or Lutz Roeder's Reflector - is “how do I keep somebody from reverse-engineering my assemblies and stealing my code?”.

While reverse engineering of code has been around for a long time, the combination of IL and rich metadata in systems such as Java and .NET make it easier. Reverse engineering optimized x86 code is harder, but it's still quite feasible, as many companies that used copy protection back in the 80s found out.

One way to think about securing your code is to consider how you secure your house or business. There are some possessions that are not protected, some that are secured with simple locks, some are put in safes, and some warrant a vault with a 24-hour guard. I think it depends upon how valuable a specific piece of software is, and that obviously is something you'll have to decide for yourself.

As for protection, there are a number of different schemes that customers have told me about.

1. No protection. Some companies sell products that either ship with source code or have source code that can be bought separately, or have chosen not to protect certain parts of their application that have little IP.
2. Some companies use the obfuscator that ships with VS 7.1 (a “Community Edition“ of PreEmptive Solution's Dotfuscator)
3. Some companies use one of the commercial obfuscators out there. There's a list on the C# Developer Center on MSDN.
4. Some companies write the sensitive parts of their code in C++, compile that to an unmanaged DLL, and then use interop to call into the unmanaged DLL.

I should also point out that there are some products that claim to use encryption-based approaches to prevent reverse-engineering, but I don't have any credentials to evaluate such schemes, so I won't venture an opinion.

If you know of any other schemes, please add them in the comments