Freigeben über

SYSK 86: .NET Reflector Revisited

  • Artikel

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):

 

obfuscation example.gif

Comments

  • Anonymous
    March 20, 2006
    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?

  • Anonymous
    March 21, 2006
    The comment has been removed

  • Anonymous
    August 24, 2009
    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).

  • Anonymous
    September 14, 2009
    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

  • Anonymous
    February 17, 2012
    .Net code protection combines and includes method level code encryption, anti-reverse engineering, anti-debugging, anti-tracing, and more to prevent unauthorized access and modification of your assemblies. You can check... www.maycoms.net/fxprotect-obfuscator