-2

If so, how can i protect my code from being decompiled?
Or from being reflected? If actually the two are very different from each other.
Tools like Dotfuscator for the .Net framework, do they help your code from being decompiled? Does that mean that i can still reflect on it and see it's contents??

Nithish Inpursuit Ofhappiness
  • 1,691
  • 3
  • 19
  • 36
  • http://www.iacr.org/archive/crypto2001/21390001.pdf – BlackBear Dec 07 '12 at 17:02
  • 2
    Why is this flagged for java if its a question about the .NET Framework? – Security Hound Dec 07 '12 at 17:27
  • 2
    @Ramhound The questino seems to apply equally to both C# and java. They both compile into IL, they both can be obfuscated, they both can be decompiled, they both can be reflected. The only major differences in this question is the brand of decompilers, which are only given as an example anyway. – Servy Dec 07 '12 at 17:31

2 Answers2

4

You can't ever stop either. You can make it so that decompiling the program returns incomprehensible and confusing code, but it still will be valid code that results in a program that functions identically to yours. Making subtle changes will be harder, but not impossible. Doing that is called obfuscation, which is what those tools are.

Obfuscators go around doing things like changing all variable names to meaningless alphanumeric values, performing all sorts of code refactors that don't change how the code works, but just are things that do the same thing in a different way (and is somehow harder for humans to understand, but not computers). They can also add in code that doesn't do anything, just to confuse people, etc. Different obfuscators will do all sorts of different things, and they can have some differences such as, whether or not they accidentally introduce bugs, what their effect is on the size of the compiled program, and how close the compiled program is from the original source (which, granted, is somewhat subjective).

It has the same effect on reflection, although reflecting and decompiling are completely different.

Servy
  • 202,030
  • 26
  • 332
  • 449
  • So although decompiling can be achieved through reflecting, the intentions of the two are different? Or are they in no way related to each other?? Could you please elaborate a little on their difference? Or point me to a good source ?? – Nithish Inpursuit Ofhappiness Dec 07 '12 at 17:14
  • 1
    @NithishInpursuitOfhappiness Reflection is inspecting types/variables/objects at runtime. For example, it can be used to determine all of the properties a particular type has. Decompilation is taking a compiled program and generating source code that, if compiled, would result in the same program. – Servy Dec 07 '12 at 17:16
  • Then again, the object that we inspect can also be a binary such as a dll right? In which case we are looking into a compiled code(binary machine executable) and understanding it's contents. So essentially one overlaps with the other with the difference in intentions?? – Nithish Inpursuit Ofhappiness Dec 07 '12 at 17:21
  • Decompilation doesn't always result in a valid code, although generally it does. There can be cases where a decompiled code doesn't compile again. But I don't think it relates to the context here. – Bhesh Gurung Dec 07 '12 at 17:22
  • @BheshGurung In *theory*, it does. If it doesn't, then it would be an unsuccessful attempt at decompilation. Decompilation isn't really an exact science, especially when the program author is actively trying to prevent decompilation. – Servy Dec 07 '12 at 17:28
  • @NithishInpursuitOfhappiness C# and Java code isn't compiled into machine code, they are both translated into intermediate languages that are *closer* to machine code than human readable code, but are then translated directly into machine code by a virtual machine. It's not that decompilation *can* be done on a binary file, it is *always* done on a binary file (which may be a .dll, it may be a .exe, etc.). – Servy Dec 07 '12 at 17:30
  • 1
    There is no overlap between the two. Reflection *only* uses the metadata stored in the assembly's manifest, it does not look at the actual IL code the compiler generated. You'd never be able to use reflection to infer how a method was actually *implemented*. – Mike Christensen Dec 07 '12 at 17:31
4

First, let's go over the difference between the two terms.

Reflection provides the ability to discover type information within an assembly at runtime. This is part of the framework, and makes possible features such as code completion in the IDE, references between assemblies, etc. It's also used in frameworks, such as ASP.NET (you can basically refer to classes, or web controls, in markup and instances will be dynamically created at runtime using reflection). This is also used in serialization, which is the core of web services, WCF, the web part framework, session state, AJAX, and more.

Decompiling is a term for converting machine code to a higher-level, human readable code. The .NET framework uses an intermediary language (IL) which is a machine-agnostic low level language somewhat similar to assembly, minus CPU specific things like registers. The runtime itself is what actually takes this IL and compiles it to the code that's actually specific to the local machine through a process called JIT'ing. Obviously, your code has to be in IL for the runtime to understand it (though there are processes to pre-compile or pre-JIT IL code).

There is no overlap between the two. Reflection only uses the metadata stored in the assembly's manifest, it does not look at the actual IL code the compiler generated. You'd never be able to use reflection to infer how a method was actually implemented

With that said, there are various tools to obfuscate IL code, making it harder to understand. One popular one tool Dotfuscator.

Mike Christensen
  • 88,082
  • 50
  • 208
  • 326
  • so both quite achieve the same things with differnt intentions? Cos although reflection is primarily meant for dynamic loading of instances, we can still use it to view the contents of an assembly or a library right? – Nithish Inpursuit Ofhappiness Dec 07 '12 at 17:18
  • @NithishInpursuitOfhappiness - Reflection doesn't work through any process of decompilation. Type information is stored in the assembly's metadata, which basically says *"This assembly has the following classes, enums, structs, namespaces, etc, etc"* - Reflection *could not be* used to inspect the actual implementation of a method, as that's part of the IL code and not the assembly manifest. – Mike Christensen Dec 07 '12 at 17:23
  • Agreed. But my question is the other way around. Does decompilation work through any process of reflection? – Nithish Inpursuit Ofhappiness Dec 07 '12 at 17:26
  • @NithishInpursuitOfhappiness - Decompilation is a general term for reverse engineering machine-readable code. You'd have to be more specific on exactly what *decompilers* or *tools* in the .NET world you're referring to before one could speculate on how they work. – Mike Christensen Dec 07 '12 at 17:28
  • @NithishInpursuitOfhappiness In theory one could possibly use reflection, or information that the binaries provide specifically to allow reflection. In practice, as Mike said, you'd need to have a particular decompiler to know what it chooses to use to try to decompile. – Servy Dec 07 '12 at 17:33