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: http://eon.businesswire.com/news/eon/20110426007021/en/.NET-Reflector/Reflector/Red-Gate
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:
Reflector:
JustCompile:
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
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: http://eon.businesswire.com/news/eon/20110426007021/en/.NET-Reflector/Reflector/Red-Gate
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:
Reflector:
JustCompile:
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
No comments:
Post a Comment