Microsoft plans for .NET framework to revolutionise the way developers work - both in terms of productivity and features. It has, however, introduced some problems that until now, many developers have not needed to worry about. Whatever language you choose to write your .NET programs in - C#, VB.NET, J# etc - your code is converted to what is known as MSIL (Microsoft Intermediate Language) and then to Portable Executable (PE) file.

So what, you may well ask. The problem is, that unlike byte-code (which is what a program written in C++ or VB would normally be compiled to), IL is much higher-level and so ultimately understandable to a human. Furthermore, the conversion to a PE file does not change the underlying IL - which means you can get from your language of choice, to IL, to PE, and all the way back again. Indeed, Microsoft includes a tool called ildasm (IL disassembler) in the Framework, that will convert any .NET assembly (the compiled dll or exe file) back to IL automatically. As a result, anyone with a copy of this tool can obtain your IL code, and with the help of tools such as Anakrino and Salamander, you can easily return to something close to the original source code.

Original C# code

private void button1_Click(object sender, System.EventArgs e)
{
   int j=0;
   for(int i=0; i<100; i++)
   {
      j=j+i;
   }
   MessageBox.Show(j.ToString());
}

Sample of the IL code (obtained using the ildasm tool included with the .NET framework)

.method private hidebysig instance void
button1_Click(object sender, class [mscorlib]System.EventArgs e) cil managed
{
   // Code size 33 (0x21)
   .maxstack 2
   .locals init (int32 V_0,int32 V_1)

   ....

   IL_0013: ldloca.s V_0
   IL_0015: call instance string [mscorlib]System.Int32::ToString()
   IL_001a: call valuetype [System.Windows.Forms]System.Windows.Forms.DialogResult    [System.Windows.Forms]System.Windows.Forms.MessageBox::Show(string)
   IL_001f: pop
   IL_0020: ret
} // end of method Form1::button1_Click

... and back again (using Anakrino)

The incredible ease of decompilation - something that didn't really affect C++ and VB programmers before - raises a major problem (and one that Java programmers have had to face for many years). Although many from the open source movement hail this as great news for the software industry, for commercial companies it certainly provides some food for thought.

Although not a complete protection, a process known as obfuscation can help deter all but the most determined hacker. The trick is to makes changes to the IL that make it difficult for a human/automated analyzer to discover meaning to the code, without changing the actual effect of the code when run through the Common Language Runtime (CLR) which processes the IL. In the words of PreEmptive, "Obfuscation works like putting a six item meal into a blender and sending it to the diner in a baggie. Sure everyone can see the food in transit, but besides a lucky pea or some beef-colored goop, they don’t know what the original meal is. The diner still gets the intended delivery and the meal still provides the same nutritional value as it did before (luckily, CLRs aren’t picky about taste). The trick of an obfuscator is to confuse observers, while still giving CLRs the same delivery".

It was hoped that Microsoft would address this issue before the original release of .NET, but these plans were abandoned. There are now, however, a number of commercial obfuscation tools available specifically targeted at .NET. Indeed, Visual Studio 2003 will include bundled software from PreEmptive to provide some basic obfuscation. Here, we will review the professional edition of their product Dotfuscator, along with its main competitor Demeanor from WiseOwl.