One of the great things about developing applications in .NET is the language neutrality of it. One may choose to write code in VB.NET, C# or any such language which is framework compliant and one is guaranteed that the code will work. .NET internally achieves this by translating user code to an intermediate language called MSIL code. The MSIL code is generated when a higher level language code base (such as C#) is compiled by CSC or Rosalyn or any other .NET framework compiler.

Reverse Engineering MSIL

One not so great thing about MSIL is that it is human readable. In fact there are many tools such as IL Spy and Reflector which can be used to reverse engineer a .NET assembly into native C# code. While this has its own positive aspects one major drawback is that any proprietary intellectual property, algorithm or authentication key if embedded into the assembly is susceptible of falling into the wrong hands if someone with malicious intent uses one of the reverse engineering tools to peek through your code base. Here’s a screenshot of how powerful this reverse engineering can be.

il-spy

Obfuscation what?

One common way to mitigate this is by adopting a technique called “Obfuscation”. Obfuscation is essentially a process of renaming symbols and rearranging code blocks (and sometimes even code flows) to complicate decompiling. Obfuscation is a process that is carried out “after code has been compiled”. In other words an Obfuscator tool would accept a compiled .NET binary (dll or exe) as an input and would produce a corresponding binary with encoded or obfuscated MSIL code in it. The below screenshot shows an assembly which has been obfuscated.
Notice how the obfuscator tool has renamed original classes, their constituent members and the control statements in them. In fact a good obfuscator tool can make it quite impossible for a reverse engineering tool to even load the assembly once obfuscated!

obfuscated

 

And here is a screenshot from IL Spy that shows that this particular type couldn’t be reverse engineered.

can-not-decompile

ConfuserEx – The Tool

TMO uses once such tool for obfuscating the internal TMO assemblies. This is an open source project called ConfuserEx and is available on GitHub. This is an excellent tool which comes with a UI project that lets you easily work with the underlying obfuscator engine. The ConfuserEx tool can be automated by wrapping its internal engine in batch file calls or via PowerShell scripts. An excellent in depth walk through is provided in this codeproject article here .

Some of the TMO team members actually contributed back into the ConfuserEx project as the native project had some limitations in the way it handles WPF resources. We chose to let our team members contribute back into the community under their individual identities and not from the official Team TMO GitHub account. At TMO we are a fair team who believes in attributing credit where credit is deserved. So here’s a big official thank you to the team behind the ConfuserEx project and to the members of team TMO who enhanced the ConfuserEx project with their rich contributions back!

Warning!

We must forewarn our readers that Obfuscation is not a complete fail safe strategy against a determine hacker. Eventually all .NET assemblies must contain MSIL code. Obfuscated assemblies while make it nearly impossible to decipher original code as written by developers they too contain MSIL eventually and hence are susceptible to be reverse engineered as explained here

 

References
  1. IL Spy
  2. Reflector
  3. ConfuserEX
  4. Techniques for automating Obfuscation
  5. Don’t rely on Obfuscation
  6. Configuring Visual Studio for Automation