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 


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 (5)

  1. jfk says:

    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?

  2. irenake says:

    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.

  3. Rolfhub says:

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

  4. George Yound says:

    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

  5. Mayur Chavda says:

    .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…

Skip to main content