Demystifying .NET Reverse Engineering - Part 1

This will be a kind of “saga” of papers that will talk essentially talk about dot NET oriented reverse engineering, we are already on the stable version 4.5 (4.5.50709) / 15 August 2012 of Microsoft .NET Frameworks for Visual Studio 2012 and distributed with Windows 8, Windows Server 2012, but we still not seeing enough papers about reversing applications developed using dot NET technology. I’ll try to fill this lack of papers, and this first article is supposed to be a part of an upcoming others that would explain some basics and clarifying dot NET architecture to the extent of making some few concepts clearer for reverse engineers. 

Before starting, I strongly recommend you to take few hours teaching and learning yourself at least one of the dot NET languages and I recommend either Visual Basic .NET or C#, it may seems to some that reversing dot NET programs is way easier then reversing “traditional” programs which is in my point of view wrong. 

The concept of dot NET can be easily compared to the concept of JAVA and Java Virtual Machine, at least when talking about compilation, unlike most of traditional programming languages like C/C++, application developed using dot NET frameworks are compiled to a Common Intermediate Language (CIL or Microsoft Common Intermediate Language MSIL) - which can be compared to bytecode when talking about Java programs - instead of being compiled directly the native machine executable code, then the Dot Net Common Language Runtime (CLR) will translate the CIL to the machine code at runtime. This will definitely increase execution speed but has some advantages since every dot NET program will keep all classes’ names, functions’ names variables and routines’ names in the compiled program, and this, from a programmer’s point of view is such a great thing since we can make different parts of a program using different programming languages available and supported by frameworks.