.NET Obfuscation - A Waste of Time?
Obfuscation, aside from being a tongue-twister to pronounce, is an important topic within the realm of .NET development. While some folks around the inter-webs might have you believing that obfuscation is a useless, needless or worse - a complete joke and waste of your time - they couldn't be any further from the truth.
In a nutshell, any code written on top of the .NET framework will get compiled into IL or .NET's intermediary language, which is something between machine code and the higher level languages such as VB.NET or C# or even Managed C++. The IL code then runs against the CLR or Common Language Runtime, this is essentially what allows developers to use the language that best suits them (VB.NET, C#, Managed C++, among others) and still rely on the fact that it will be converted to roughly the same IL code and function identically when it comes time to execute the code.
The need for obfuscation comes into play with respect to the nature of the .NET framework. The .NET framework was built with an extremely impressive suite of classes that allow code to look into assemblies at runtime, essentially allowing a program to query itself for data types and information. This ability is mostly provided by the Reflection classes within .NET. Through these classes a programmer can create new types at runtime, query existing objects for information and do all sorts of incredibly powerful things, such as dynamically creating executable code on the fly. However, a major caveat to this is that it also allows a programmer to write a program that can peer into the internals of a compiled .NET assembly and transform the compiled IL code into whichever .NET language he might be interested in. For example, Lutz Roeder's .NET Reflector program allows you to peer into the physical code of any .NET assembly. The problem with this is that it basically exposes your companies or personal intellectual property to the world, or at least to other developers who have a tool like .Net Reflector (many of which are freely available). If your new to obfuscation, I'd encourage you to grab this program and open up one of your own .NET assemblies you or your company may have written. You might be a little surprised at what you see.
Obfuscation is pretty simple (in concept), the idea is to alter your code in such a way that it makes the code much harder for a human to understand if they look at it using .NET reflection. The most obvious way to do this is to change the name of class variables, local variables, private and protected method names, etc. such that the function "GetName()" becomes perhaps "AGg324a()". The program will still behave the same way, it's just that a human who might see that function name is going to have a harder time figuring out what exactly that does without looking at the internal code, which presumably is also obfuscated.
A couple general notes about obfuscating a .NET assembly: (1) the assembly will likely grow or shrink in size, this is because of all the renaming that will occur. Usually this shouldn't be an issue, but it may present its own problems in unique situations; (2) generally obfuscating public information will break an application. This happens when some other consuming application might expect to call the public method "GetName()", but now that it's changed to something else, that link is now broken and the calling program now can't find that public method.
If you don't have a problem with the potential likelihood of others knowing your code, you don't need to worry about obfuscating it. But if you're selling an application for profit, unless it's being sold in some unique way or garnering profits from some other avenue, you probably want to think about obfuscation, earlier in a project rather than later. The way in which an application is deployed will also help answer whether or not obfuscation is for you.
For example, years ago after the release of .NET 1.1, a former colleague came across a very useful application written in .NET, and like many products it required a serial number to register and unlock its full potential. He used reflection against the assembly downloaded from the company's web site (non-registered) and within a matter of 5-10 minutes was able to isolate the section where it validated serial numbers and generate one of his own that promptly unlocked the trial software and gave him his own copy of the registered application. The code simply wasn't obfuscated and unfortunately the developers at that company where unaware of the issues around it, as they went through the trouble to cook up a serial key licensing scheme but didn't protect their code (or at least the section dealing with serial key validation) in the first place.
It's important to understand that obfuscation and the myriad of other techniques available for altering your applications code and better securing it, are not fool-proof. If a product claims it can obfuscate your code to the point where nobody can hack it, they are lying to you. While in many cases it can probably deliver on it's promise, it's a very naive statement, because as with anything, if one is determined enough, he can crack, hack or break into anything. The real point of obfuscation is to create enough of a hassle for the would-be hacker that it ends up costing hime too much time and energy to bother. If it takes 5-10 minutes to hack something, many people are likely to do so, but if it takes many months or years to unravel some obfuscated application, it's very unlikely anyone is going to bother reverse-engineering it.
Choosing to ignore obfuscating your .NET code, is essentially like leaving the doors to your home unlocked. It doesn't mean your going to be robbed, but in the event someone does want to rob you, you've just made it a lot easier to do.
There are many commercial tools available to obfuscate your code, or you could roll your own obfuscator if you feel inclined. There are many sites out there explaining the basics, some including a tutorial or two.