2

I have decompiled DLL by dotPeek 1.4 to see what is happen inside, but there is something strage c# code (please look at attachments). There are

  • Var declaretion without var name
  • I think some var are numbers, they don't have name

Why that code was generated? Does dll could be protected from decompilation or dll was publish as realease?

enter image description here

The same problem exists when I decompile by trial version of Reflector

enter image description here

Jacek
  • 11,661
  • 23
  • 69
  • 123
  • It looks like the DLL was obfuscated, making it quite hard to understand the decompiled code. – Dirk Apr 30 '15 at 12:42
  • It's more than likely there *is* a valid identifier there, just not one you can readily see (think Unicode). – Lloyd Apr 30 '15 at 12:43
  • Give it a shot with .NET Reflector http://www.red-gate.com/products/dotnet-development/reflector/ and post it here. No problems for me with dotPeek. I have never seen smth like you encountered. – Razvan Dumitru Apr 30 '15 at 13:03

2 Answers2

5

Firstly you're breaking the licence agreement by trying to reverse engineer their code.

f. Disassembly. You may not reverse engineer, decompile, disassemble or in any other way try to gain access to information regarding the construction of THE PRODUCT.

This is because .NET allows for a whole lot more than a-z in variable names. You can read about it in the MSDN section on Identifiers (C#). Visual Studio won't like the variables though and will complain, but they're perfectly valid in IL (while not being valid in C#).

Having a look with other tools or dumping to hex, you can see the variables have been obscured and are things like   which is actually the ACK character ^F followed by the 'START OF TEXT' character that looks like the space character but is not the space character. Other characters used include the backspace character.

The IL for the above code is going to be something like

.field private static initonly string '\u0001'
.field private static initonly string '\u0002'
.field private static initonly string '\u0003'
.field private static initonly string '\u0004'
.field private static initonly string '\u0005'
.field private static initonly string '\b'
.field private static initonly string '\u0002\u2000'
.field private static initonly string '\u0003\u2000'
.field private static initonly string '\u0005\u2000'
.field private static initonly string '\b\u2000'

You get the idea.

I would like to actually know what they specifically used to obfuscate this code (because looks fun!). The code was clearly generated with something like http://reflexil.net/ which allows the compiled dll to retain hints about the variable name (but changes them to nonsense) which is why the decompiler shows up all strange names (the decompiler thinks it's being cleaver by retaining the variable names mentioned in the dll).

Seph
  • 8,472
  • 10
  • 63
  • 94
  • I know for certain RemObjects Oxfuscator can do this I've done it myself, it'll even mangle string literals - http://www.oxfuscator.com/oxfuscator/ – Lloyd Apr 30 '15 at 17:20
1

There's really no reason a decompiler would generate empty field and variable names, no matter how obfuscated or optimized the assembly is. Fields and method signatures are part of the assembly metadata which can't be removed. The names may be gone in an obfuscated assembly, but the type should still be there and the decompiler should be able to generate new names.

Maybe that decompiler just isn't very good?

A "clever" obfuscator may do something funny to throw people off by, for instance, using invisible Unicode characters as identifier names, but seeing that it has managed to generate a name such as param0 it's more likely the decompiler just doesn't work properly. You could check for that by looking at the file in a text editor made for programming that displays every character.

Matti Virkkunen
  • 63,558
  • 9
  • 127
  • 159