Obfuscators for .NET

    From the compiled assemblies (exe and dll) for the platform .NET can easily restore the code to high-level languages (C#, VB.net). This means that your source code can be copied. To protect themselves against such threats, most commercial software developers use various obfuscators.


Why and of who is protected?


    Obfuscation as one of the stages is relevant only for the protection of commercial software. Can be used as protection against a variety of industrial espionage. Here all 
easy: simply delete the metadata and confuse the rest of the program so that a competitor will be cheaper to write a program from scratch than to disassemble your. Usually for viewing metadata assembly is used .NET Reflector. It has a simple and intuitive interface, as well as the opportunity to expand the functionality of plug-ins. There are also several commercial browsers and assemblies decompiler(trial versions understand only half of the assembly, and "happy owners" licensed version reported is not very large differences from the reflector).

Obfuscators and packers

    .NET-applications are trying to protect the two main methods: direct obfuscation IL-code (when the output is almost is valid .Net-assembly, and it can perform on nemodfitsirovannom MS.NET or mono). And the packaging - a modification of the assembly so that the output is obtained winapi-application contains in itself unpacked module and IL-packed code. With obfuscation like everything is clear: given as input. Net assembly, we get the output .Net assembly, it works in much the same. No extra "hidden" data, everything is on the spot, only confused and changed its name to something useless. In the case of a packer, we will face some problems:

• Our assembly is now done only under the WIND (or accurately tuned mono + wine) 
• Packer, who passes the input mscoree original assembly was withdrawn for 1 minute, and it makes no sense for the defense. Packers that intercept the internal function mscoree strongly depend on the version of the framework, and cause some antivirus false positive reaction. Interception of internal functions in general a delicate and thankless. 
• Packers are native-programs, and do not give compile your application in the x86-64 code, where it is available (and in some cases, this gives a large increase performance)
• For the normal execution environment .Net in any case require access to the original IL-bytecode. And even preJITted-assembly should it contain in itself. And this means that to get This bytecode is also realistic.