Welcome to MSDN Blogs Sign in | Join | Help

SYSK 86: .NET Reflector Revisited

In SYSK 7, I discussed a tool created by Lutz Roder that can be used to decompile and analyze .NET assemblies.  The tool is available at http://www.aisto.com/roeder/dotnet/. 

 

This tool disassembles the raw assembly and translates the binary information to human-readable, showing you the code implementation. It can also be used to find assembly dependencies, and even windows dll dependencies, by using the Analyzer option.

 

One thing that did not occur to me at the time is that the same tool can be used to convert C# code to VB and vice versa.

 

Imagine you have some C# code that you want to convert to VB.NET.  You could compile this code, open and disassemble it with .NET Reflector, and then simply change the language from C# to Visual Basic in the drop down box, and you’ve got yourself same code in VB.NET!   Ok, it’s not a panacea, but it’s better and more accurate that online C# to VB code converters…

 

This is a very cool tool!  Make sure to test drive it and see for yourself…

 

Now, if this makes you concerned about protecting your intellectual property, there are a number of obfuscator tools available today that mangle function and variable names, and make it more difficult for hackers to decipher the meaning of the code.  Here is an example of non-obfuscated code and, below, obfuscated code, as seen in .NET Reflector (see attachment at the bottom)

 

Below are some of the obfuscators available today for .NET (in alphabetical order):

 

Published Monday, March 20, 2006 5:25 AM by irenak
Filed under:

Attachment(s): obfuscation example.gif

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# re: SYSK 86: .NET Reflector Revisited

Monday, March 20, 2006 8:36 PM by jfk
when code is obfuscated, how does the .net runtime know how to interpret it?

if the .net runtime knows how to interpret it, why can't a tool use the same technique to decompile and analyze the assembly?

# SYSK 86: Reply to jfk

Tuesday, March 21, 2006 9:54 AM by irenak
Obfuscators work by mangling names.  Good ones, do it in such manner that reverse transformation is not possible; i.e. pieces of names must be discarded when the substitution name is created.  It's done just so you can't use tools like .NET Reflectors to put it back together...

The runtime doesn't care what the name is... You can call your variable with a meaningful name (e.g. outputFile), or call pjl0fdsyckjn, or anything else for that matter.  It's just a token.  As long as whenever you are using that variable, you get the same name, the runtime will execute your code correctly.  Same applies to function names.


# re: SYSK 86: .NET Reflector Revisited

Monday, August 24, 2009 1:27 PM by Rolfhub

Yes, irenak is correct, most or all obfuscators rename everything that can be renamed (most classes, interfaces, variables, methods, etc.).

To make the new names as useless as possible, the same names are reused as often as possible, for example, the first method of a class may be named "a" in several different classes. The runtime references each method by the complete name (including the package name, class name, and method name), so it is still not ambiguous for the runtime, but very hard to understand for a human.

Also, since different methods with the same name, but different arguments may exist in the same class, there could be for example three methods, each of them named "a", but one expects an integer, the next one two integers, and the third one a string and an integer. Not easy to understand for a human, but completely obvious for the runtime.

If the name "a" can't be used, "b" is used, then "c" and so on. After "z" may come "aa", then "ab", etc. So the names are as short as possible, making the obfuscated file a bit smaller in most cases (sometimes a lot smaller).

# re: SYSK 86: .NET Reflector Revisited

Monday, September 14, 2009 10:15 AM by George Yound

Obfuscation is not only about renaming class & methods names, other forms of obfuscation include: string obfuscation, control flow obfuscation & per  method decryption.

For more information you may refer to http://www.secureteam.net

Leave a Comment

(required) 
required 
(required) 

  
Enter Code Here: Required
 
Page view tracker