.NET Decompilation is Common: Be Aware

A while ago I ran a poll asking .NET developers whether they reverse engineer applications that weren't created by them. The results were predictable, and from 110 total votes we got, 84 were cast for yes. As I mentioned before, .NET decompilation is extremely easy in multiple situations where developers do not obfuscate their code. Whether you want it or not, but if no precautions are taken, your code will most likely be torn apart.

I should mention, that code reflection is not a bad thing. Despite the common misconception, disassembling other's code has educational value. If you were developing with the .NET platform at least a year, you probably peeked at existing Microsoft .NET assemblies at least once. It is a great way to see how a re-usable codebase is built. It also allows (in very seldom cases) to see how existing framework code can be optimized and adapted to a specific task.

But does this mean that .NET code is not secure and should not be used for applications that have sensitive elements integrated in their source? No. Are there any solutions that can reduce the chances of your source code being disassembled? Yes.

The answer is obfuscation. Here are some resources that might help you learn more about obfuscation:

• CLR and .NET Security - Obfuscation
• Thwart Reverse Engineering of Your Visual Basic .NET or C# Code
• Best .NET obfuscation tools/strategy
• .NET Obfuscation using Dotfuscator for Source Code Protection
  
  

Obfuscation, however, is not a completely bulletproof solution. At the end of the day, there is always going to be a slight risk with your code being decompiled, whether it is written in managed or native code. Decompilers exists even for obfuscated code.