Friday, April 29, 2011

What is Decompiling an Assembly in .NET and Some Good Tools To Do It

From time to time I like to mix some new information with some basic concepts. I am not always going to compete with the bleeding edge blogs that have full drill down articles 5 minutes after WebMatrix was announced. And what I always remember is not every developer out there is pushing the envelope or is seasoned in this field yet. So I like to cover some basic concepts occasionally to hopefully add a fresh perspective on something more junior devs out there may not understand.

Decompiling. What is it in reference to .NET assemblies? Well in the most abstract form of description, it is the process of reverse engineering MSIL or Microsoft Intermediate Language back into a more familiar, readable set of code to which it was developed. But wait (some might say)! I thought once I compiled my .NET project, the output library was cryptic and unreadable low-level machine code just like my old VB6 or C++ .dlls. Not in our case when doing .NET Managed code development. When you compile a .NET assembly, it is compiled into the afore mentioned intermediate language named MSIL. The MSIL is then compiled to native machine code via a Just-In-Time (JIT) compiler; in our case the .NET Framework JIT compiler is used.

Some of you might remember (or maybe not if you are newer to the industry which is OK), all the buzz around all the different *.NET* languages when the Framework 1.0 was 1st released in late 2001. All this talk about VB.NET, C#, COBOL.NET, Fortran.NET, etc. and everyone scratching their heads going, huh? Well this was because the equation was simpler now:

[Language X] + [.NET Compiler for Language X] = MSIL

So with all of these languages, the goal is to have them compiled to this intermediate language named MSIL. Since MSIL can be interpreted by a JIT compiler and is not unreadable in itself, also presented the opportunity to go the opposite direction and turn the MSIL back into readable code. Hence a 'Decompiler'.

With a decompiler tool, you can open a compiled .NET assembly (i.e. a .dll from the /bin directory) and reverse engineer the MSIL back into more readable code close it its original uncompiled version (some tools are much better at this than others). Why is this useful to me (you might ask)? You will not use it all the time, but imagine if you got a 3rd party .dll without the source code and wanted to see how it worked? Use a decompiler. What if a rogue developer jumped ship and took all the .NET source code with him, only leaving the installed assemblies behind. Use a decomplier. What if you wanted to see how Microsoft builds the very Framework .dlls we use daily (like System.Text, System.NET, etc.; non-meta data versions only)? Use a decompiler.

VS.NET actually shipped with a decompiler tool named ILDASM.exe. This tool was not that bad early on, and I used it for several years. If you ever want to try it out it is located in C:\Program Files\Microsoft Visual Studio [Version]\SDK\v2.0\Bin. I believe the tool was only shipped through VS.NET 2008, but to be honest it was so primitive it really isn’t worth investigating too far, because there are much, much better tools available.

However I wanted to briefly mention (2) very nice *free* tools available for decompiling those compiled .NET assemblies. The 1st is made by a company called RedGate and is named .NET Reflector. Now I mentioned *free*, and there has been a lot of upset devs out there because RedGate announced it was going to be charging $35 once version 7 was available. However, because the community reeled, they made an announcement this past week stating that all version 6 users would get an update with a perpetual free license. You can read about the announcement here:

You can still download version 6 of .NET Reflector, and then have it auto-update itself to the latest version of 6 (6.8 as of this post). Although at $35, version 7 is not a bad price either, but apparently they upset a lot of devs claiming to always make Reflector free, and ended up deciding to charge. Once you have installed .NET Refelctor it will give you the option of integrating itself into any installed version of VS.NET you have on your machine. This gives the developer the option of actually debugging assemblies referenced in your project which is a really nice feature.

At the perfect time a company named Telerik (well known for their 3rd party rich controls and reporting tools for different .NET Technologies) pounced in this week with their own decompiler named "Just Decompile". And as they state on their webpage: "Powerful, Free Decompiling. Forever." Notice the 'Forever'. A nice little dig at RedGate and .NET Reflector I am sure. Anyway, this is a nice decompiler as well, but it is in Beta and not as mature or well working to my experience as Reflector. You know what I say though, "Get both, they are free!!"

To use either decompiler, open the shortcut to which ever tool you want to use; the shortcut probably on the desktop, or you might have to go to installation directory:

Once the decompiler tool is open, they all function similarly. Select "Open" and browse to any compiled .NET .dll. Once opened, you typically navigate the binary on the left, and when selecting a method, property, etc. from the left, you will be able to see the code on the right:



Now hopefully some things have become clearer on the topics of .NET compiled binaries and how to decompile them. With this understanding, you do not want to place things like passwords, connection string, secret proprietary algorithms, etc into a .NET .dll that will be shipped out or sold. This is because anyone with a little knowledge could decompile your code and see what is inside of it.

One way to complicate the decompiling process is to "Obfuscate" the compiled code. This renames and rearranges the code to make it difficult to decompile and read, but not impossible. There are some good obfuscation tools available like Dotfuscator, but they can get quite pricey for a full version. A better solution to hiding values you do not want seen or hacked, is to place them in your application’s .config file and then use a tool like aspnet_regiis to encrypt them. Nothings bullet proof, but anything is probably better than Dim MySecrectPassword As String = "VeryToughPwd123"

So there isn’t much to loose. Go ahead and download both decompilers and give them a try!

Telerik JustDecompile

(you will have to search and find a freeware site to download Reflector version 6 since RedGate does not offer it for obvious reasons from thier site directly anymore)

Another one to add to the list as well:

JetBrains dotPeek

The 'My' Namespace in a VB.NET Application is Missing Members

OK I ran across this little snag in a VB.NET application, and thought I might share an easy solution to the problem. If you ever have a .NET solution that originated in a previous version other than 2010 and has been upgraded, you might have some difficulty accessing members of the 'My' namespace. Specifically I was missing the auto generated 'MyWebExtensions.vb' code file displayed below:

This resulted in the "'Application' is not a member of 'My'" error:

There are probably a few tricks you could make to the solution (.sln) file by opening it in Notepad and fixing the appropriate settings, but the easiest way to fix the error is to remove the 'My' extension and add it back into the project. To do this open the project's properties of the project where the error is occurring, and click on the "My Extensions" tab.

The 'My' extension you need for your project is dependent on the type of project you have created (Web, WPF, etc.), so make sure to select the proper one when re-adding. First though, right-click the current extension already added and select “Remove Extension”

Then press the "Add Extension" button in the bottom right-hand corner, and add the appropriate extension back into your project. This should auto-generate the 'MyWebExtensions.vb' code file and fix any previously non-accessible members in the 'My' namespace.

For more information on the 'My' namespace, check out the (2) MSDN links below:

My Namespace

How My Depends on Project Type (Visual Basic)

Thursday, April 28, 2011

Honored to Receive the "Microsoft Community Contributor Award"

I received a wonderful email today that I have been recognized with the 2011 "Microsoft Community Contributor Award"! This entry is not to toot my own horn, but rather to say thank you to Microsoft for the recognition. I have used Microsoft products and software almost my entire life, and now am very proud to make my career and hobby in software engineering revolve around Microsoft and the .NET Framework technologies. As I continue to hone and grow my own skills, I will continue to share and contribute that knowledge to help others in our community in whatever way I can. It might be a small token of recognition, but one that I am proud and happy about. Thank you Microsoft.