AspAlliance.com LogoASPAlliance: Articles, reviews, and samples for .NET Developers
URL:
http://aspalliance.com/articleViewer.aspx?aId=1108&pId=-1
ILDASM and Obfuscation in .NET
page
by Sandeep Acharya
Feedback
Average Rating: 
Views (Total / Last 10 Days): 37001/ 67

Introduction

ILDASM and Obfuscator. These two words are not very common to the beginners of .NET. So before going over these two things, we must know their background. First, we have to know what is the significance of ILDASM and Obfuscation.

.NET architecture in brief

.NET is a platform independent framework. The major advantage that any .Net developer can avail is the MSIL (Microsoft Intermediate Language). Any .NET source code will be converted to MSIL. These are CPU independent instructions. The .NET assemblies contain MSIL as well as the metadata about it. At runtime, these MSIL instructions get converted to the CPU dependent code by JIT (Just in time). Every .NET developer knows the advantages of this architecture, but the disadvantage is that the MSIL and metadata in the assembly provide enough information to recover the original source code. Developers used to spend years making good bug free applications and it is obvious that they really do not want to make their work public.

What Actually Is ILDASM

As we have just discussed, it is very easy to get the source code out of the .NET assemblies. The process is known as De-Compilation. Microsoft is providing a native de-compiler known as ILDASM (IL Disassembler). This ILDASM can convert the entire assembly to the understandable instructions and then it is not a far reach to get the source codes back. Let us have a look at how we can do this.

Go to the Visual Studio .NET Command prompt as shown below.

Figure 1

 

Enter ILDASM at prompt.

Then the ILDASM window will come up. Here you can browse your dll or exe. After which, you will get the complete set of instructions for your assembly.

In this case I have used a Vb.net exe (mfsapp.exe) and got the result as shown in the image below.

Figure 2

 

 

 

 

 

 

 

 

 

 

 

 

 

The above image shows an example of runtime ILDASM. It also explains the meaning of the symbols used in the process. Double clicking any item gives the set of instructions that will be executed. For example, here we have double clicked on the Method doDBconnection () and received the following.

Figure 3

Once this structure is obtained, the source code is not far away. One can easily decode these instructions into the source code by using the code charts given at the location [Drive name]:\Program Files\Microsoft Visual Studio .NET\FrameworkSDK\Tool Developers Guide\docs\Partition III CIL.doc.

The Microsoft itself gives this DOC file. It contains the meanings of all the instructions from the above process. So, now the source code is almost in your hand exposing the whole logic behind the dll/exe.

Bring obfuscator into Picture

Obfuscator- this word really brings relief for the developers who do not want to expose their logic publicly. The image below shows how this can be used effectively.

Figure 4

 

 

 

 

 

 

 

 

 

 

 

 

 

 

         

The diagram above gives an idea about the flow of the complete cycle. One can easily point out what we are missing by not using the Obfuscators.

Obfuscation is based upon

The obfuscation process is not built on a very new concept. If someone is asked to hide something (still making it publicly accessible), then the way is encryption and decryption. The encryption is nothing but converting an understandable language to a non-understandable language; decryption is just the vice versa. However, the method for encrypting data may not be identical to decryption. So there exists a one-to-one relation between the data to be encrypted and the encrypted presentation of data.

The Obfuscators used to work in almost a similar fashion (How they differ: Obfuscators really do not need decryptions) as we have just discussed above. Obfuscation is a general word used for protecting programming codes and not the general data. This has become very much popular in recent years as languages like Java and .NET gained their popularities. Unlike C or C++ (where we are directly getting the machine codes), in modern languages we are getting an intermediate stage which makes reverse engineering easier. And it already helped many hackers to bypass the license, take the pieces out of the programs, steal them and make it own.

Here is a point for those who are still thinking that Obfuscators are the same as the encryption and decryption process. It is not exactly like that. Actually, the obfuscators do not need decryptions. An obfuscated program keeps staying in plain view, but reaches far away from human beings/hackers. An obfuscated program runs much faster than the normal programs as few optimizations are also getting associated in the process of obfuscation.

References
Conclusion

It is fact that obfuscators cannot protect your codes completely since dedicated hacker can understand the logic behind the screen by spending a lot of time and carefully observing the results (and stack outputs). However, it is always advisable to go for obfuscators when application demands high security or a developer does not want to expose the implemented logic.

By: Sandeep Acharya

Mindfire Solutions

 


Product Spotlight
Product Spotlight 

©Copyright 1998-2024 ASPAlliance.com  |  Page Processed at 2024-03-28 3:35:59 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search