Considering the possibility of obfuscate the code, I would like to add:
1) .NET language is interpreted, therefore much more easy to decompile.
2) the obfuscators, even more powerful, usually delete the spaces in the various comments and renaming functions and variables with random names and maybe mixing them.
More, they can't do in order not to alter the program.
Obfuscator makes just a little bit more complicated the analysis of the source. But not very much.
It is not impossible to restore reasonable names.
Sure the obfuscator technique can also be more complex, such as declaring variables, insert cycles without goal and useless.These "bloat/crap" instructions, however, are translated in assembly code and intertwined with those useful, then an attacker would be in difficulty to understand the logic of my program.
My intention would be, once a set of transformation rules of the code, to create a tool to deal with them.
So, in the standard case a programmer :
- writes the source code, clean and understandable
- translates the clean source code with a obfuscator tool*
- compile the code
* ideal condition: the tool is written by the programmer himself who decides the rules for obfuscate the code.
