Obfuscation, why it is needed, obfuscators and recommendations on the draft to the obfuscation

Obfuscation - there is such a word.
Warning - this article is very common term "obfuscation" and its derivatives, if you read the article out loud, it may seem that you are brainwashed. None of such appliances and replace the word "obfuscation" shorter did not find myself tired of that word. So do not read this article out loud at bedtime or before dinner, as the Soviet press, or replace the word with "entanglement" (let's see what you get) or Oh. ;)
Availability of metadata up to your code (of course this is MSIL, but more readable than assembly language code) in products. Net has become a headache for developers of commercial products and technologies. Net. How to protect code from prying public, how to protect the product that is the intellectual property (if it can be easily understandable to decompile the code, then you can remove the protection from unauthorized use, and even then assemble into a working assembly!)?
Here comes to help obfuscation.
Result. 

Here is an example of the original method (before obfuscation) 
  private void CalcPayroll (SpecialList employeeGroup) {
   while (employeeGroup.HasMore ()) {
     employee = employeeGroup.GetNext (true);
     employee.UpdateSalary ();
     DistributeCheck (employee);
   } 
 }
But the result (after):
  private void _1 (_1 _2)
  {While (_2._1 ())
   {_1 = _2._1 (True);
    _1._1 ();
    _1 (-1);
   }
 }
Try to understand the meaning of the algorithm after the obfuscation. It will take time - it is necessary to know what kind of classes are involved, try to understand their purpose in general to be a big job.
This is the task of obfuscation - make it difficult to understand the source code, confuse and eliminate the logical relationships in the code.
What makes obfuscation:
  1. The metadata, since not all members of the assembly, he can obfuscate. For example obfuscator not replace the names of the designers type - it can be dangerous. Although in some cases this is possible. Also sometimes impossible obfuscation of virtual or abstract methods.
  2. List of members of the assembly is ready for obfuscation. Obfuscator assigns them new names, based on a specific algorithm. Some obfuscators assigned names as long as the former were but devoid of meaning, others are based on the numbering of all members and obfustsiruyut mx corresponding numbers of the assembly, and others - based on the token (token) a member of the assembly - a unique identifier of a member of the assembly in MSIL, the fourth try to minimize length of the name, and often use the same name to the members of the assembly (in dotfuscator is called overload induction) - it gives the maximum effect of obfuscation (imagine that your class all the methods and fields are named as "1").
  3. After this data is written back to the assembly, or the generation of a new build - all in the hands of the authors obfuscators, its optimization - as many of the obfuscators are able to remove unnecessary information from the assembly (debug-information, the unused methods, fields, classes). Voila - ready to build. In fact, after the assembly obfuscation is different from the original one detail - the modified section of strings (String Heap or # Strings) - one of the five sections of the metadata is the result of a character obfuscation when the obfuscator does not modify the method bodies. Can be modified by another section (User Strings or # US) - but so far not seen such obfuscators. If interested, I can somehow tell you about the structure of metadata and PE-file. Net assemblies. (Editor's Note. Yeah, it's interesting. So - wait ;))) Open in ildasm or Reflector or another navigator, assemblies and evaluate results . Some obfuscators have additional features: entanglement namespaces (change accessories of different classes defined namespace), encryption string and image resources, control of obfuscation on the basis of specific attributes, which are marked with the members of the classes in the source code, some are trying to flirt with the MSIL-code assembly methods. Science never sleeps, seeking new opportunities to help you and offer a little more than offer (or require :)) competitors.
Pros and Cons
Pros:
  1. Obfuscators make disassembly difficult to study, making IsLicensed () to x ().
  2. Some obfuscators use ILDASM bugs for protection against disassembling it (Salamander).
  3. Some obfuscators even convert the code into native code, making it useless disassembling (Salamander).
  4. Some obfuscators encrypt and pack your exe and his ilk referenced assembly into one exe-file, so that the size of the bend can be reduced 2-4 times and can not be disassembling (Thinstall).
Cons
  1. The product is disassembled.
  2. Assemble the assembly after disassembling it is possible.
  3. IL code - available to read and understand than c assembler.
  4. "Protection" obfuscators who use bugs ILDASM disassemblers are powerless over other developers.
  5. Protecting obfuscators that use encryption character of the metadata string and binary resources prevent users of the product, debug, and test their products. Other than that - it's a risk because some character data used in Reflection - to get the type (GetType ("MyType")), or download the resource (GetManifestResourceStream ("MyResource")).
  6. Obfuscators often have a lot of settings, obscure or difficult to understand the normal user. Lack of information the user may lead to obfuscate his prog will not work as it should, and sometimes lead to the Crash, but still not caught by the debugger.
  7. Price - the price range - from 40 to 1,500 dollars for the program. And the price can not say anything about the quality of obfuscation. It may well be that the 40-dollar obfuscator to protect your project is much better than the more expensive.
  8. As for his 4-plus. Protected so prog "rigidly tied" to the used. Net Framework, and the service pack that you installed, "demolish" the correctness of the protected program. And this protection is available only for Intel-processors.
  9. As for the 5th plus. Yes indeed a defense is strong and overcomes the drawbacks of the 4th plus. The product is loaded from the resource required assemblies in memory and managed exe file and passes control to it, doing only razrulivaniya problems with assemblies, types, resources (through AssemblyResolve, TypeResolve, ResourceResolve). But - not all assemblies are needed immediately, loading them requires decryption and unpacking - extra time and CPU load. Not all produce exe-files. A Thinstall will only work with the exe, dll-as the assembly does not have a CPU before DllMain, from which it was possible to produce. But - the crack of her problems as it is possible. There is a program ProcDump - it can prodampit running process and thus easily decrypted and uncompressed protected exe, referenced assembly. Thinstall will have problems with loading into memory managed C + + assembly.
  10. Some obfuscators create a closed system obfuscated assemblies, which are neobfustsirovannymi party assemblies and MS-vskie. But here, everything is far from perfect - obfuscator does not know how to use assembly resources, so it can cause your program to a standstill. Although in this case the quality of obfuscation is ideal - to nothing to undermine. Again - this is only possible for the exe-programs. If you need to protect a class library, you will need to leave neobfustsirovannymi public members of classes and public classes - hence the cracker can begin its work.
Obfuscators and their capabilities:
Remotesoft Slamander Obfuscator -
It has a fancy navigation, allowing to climb not only the metadata, but also on the structure of PE-file, utilization analysis, binary data. Rich possibilities for the analysis of metadata. No callgraph analysis methods. There is a disassembler, but disassembles the whole class at once, no less - you have to wait. Can be used as editor sortsov. Good character obfuscation, declared protection disassembler does not work - I quietly opened the method obfuscated them. Does not work with projects and with sets of assemblies. Navigator (explorer) has a plug-in architecture that allows you to connect modules from Salamander to it. Apply overload induction - ie as soon and often Applicability names for the members of the assembly. Also offering Protector - which turns your methods in the native embedded code - do not disassemble, but are dependent on the current version. Net Framework. Do not try to give :)) Declared optimization assembly has not been made (does really?). Written in native code.
Preemptive Solutions Dotfuscator - Community Edition of the obfuscator is distributed with VS. Net 2003. The poor interface (Delphi?>obfustsiruet like everything, it's hard customizable, it is difficult to understand, but as integrated into the VS addin. Do not become set, far away. Works with the bodies of the methods confusing control flow, ie just for all sorts and while. Why dotfuscator distributed with VS - does not matter to me. Works with projects through integration sostudiey. Maybe the other versions of it abruptly - Community Edition but I did not like.
Rays.Net ILObfuscator - new version 2.5 is very different from the previous 2.0. A lot of high-quality changes. First came GUI. What makes the task much work with assemblies. ILOGUI - it's navigator assemblies, disassembler, the system will work with the project obfuscation, it is possible to view and extract the resources contained in the assembly. What is different from the others? Managed code - C # and managed C + +, working with a set of assemblies, and hence the cross-obfuscation, which allows to reach the maximum level of obfuscation, a good and intuitive GUI c VS IDE-like MDI interface that comes with the ILO SDK, allowing you to create your own system of obfuscation, easy to work with the properties of the project, there is a collection of substitutions and deletions, flexible opportunities for obfuscation - say a feature on the entanglement of namespaces (you can choose from Varant) are also offered a choice of options for names obfuscated classes. There is a function to optimize assembly after obfuscation, but only for managed assemblies without embedded native code. ILO samoobfustsirovan - you can see it as obfuscation. Of the declared on the next version fichey - support solutions - ie sets of projects, the generation of maps of obfuscation and import them to the obfuscation of the projects, these features will have to fix the result of obfuscation and use it in the next obfuscation of the project and reduce the test assembly after obfuscation and most obfuscating the project. Besides promised optimization function to supplement fichey remove unused members of the assembly and insert function analysis of the project to identify the add, add bookmarks, and navigation history.
Lesser Software LSW IL-Obfuscator - Easy and fast Tulsa, which for many will come up. A little setup, everything is clear and simple. Takes as Il-files and the compiled assembly. Though not all - sometimes gives some strange error, and does not raise skopilirovana assembly. The impression that he was her first disassembles. Does not work with sets of assemblies, but supports the replacement and elimination of obfuscation. Native code. But for $ 40.
Thinstall (now also from the Lesser Software) - This thing just works only with the exe-files. Creates a self-installing exe-file with all the files on the board, closing the disassembly of the assembly. This file is not without effort, but is revealed, we should not delude ourselves. As recognized by the producers themselves - is best used together with the obfuscator.
Owl wise demeanor - not yuzal not give. Many things can - and removes unnecessary information from the metadata, encrypts the string variables, works with multimodular assemblies (rarely used thing) and integrates with VS.Net. But it is worth nemeryannom $ 1,250. Rate this masterpiece not give.
So where do you start?
With the design of the system (application or class library) that you are going to write. Yes, if you want to write the most secure code, you have to consider several factors when designing your product.
Not to be confused with the programming design. What factors should be taken into account? Obfuscator not God just can not, so you should go to meet his or her abilities. Typical obfuscation is a character (taking into account all the pros and cons mentioned above) - when the obfuscation that's all changing names of the types, fields, methods, properties, and events for senseless. Say Obfuscator renames the type to 0, and its method Run () - also at 0, and the parameters of the methods just renumbered - 0,1,2,3,4. After such obfuscation is lost logical connection between classes, disassembled code - hard to read.
If you are going to obfuscate the closed system - then you will approach a complete obfuscation when changing all the names of the members of the assembly, and in this case, the ends to find an order of magnitude more difficult than in the case where some methods, the types you are not obfuscated (this is possible when obfuscation exe-files do not use Reflection).
By the way except for the character obfuscation is more obfuscation algorithms methods - simple multiplication when I * 3 can be represented by a more complex algorithm, for example - I * ((1 + 1/2) * 2), or confused while, and for. But we will only talk about the character of obfuscation, with reference to the obfuscation. Net assemblies.
In the future, I will call obfuscation Oh, for short. Rarely has a fully enclosed, self-contained system, so a typical case would be a partial Oh.Although the ideal goal for a better Oh! will be just writing the maximum closed-loop system assemblies. Here is the first factor.
Guidelines for the preparation of the project (product) to obfuscation:
  1. To complicate disassembly you can make a substitution types (which is not always possible to implement because of the sealed type) There is a view of such a trick in store - a system type SomeType inherited a new type AnotherType, which is suitable for O! (For instance, it lies within sight of your build, you can assign it as internal) and you have it easy obfustsiruete. The output we get instead ispozovanie SomeNamespace.0 known System.SomeType. Of course you can install it AnotherType - it's a simple successor from SomeType, but it will take time, do not you? And we need to spend time attacker encroached on your code.
  2. If you plan to use some types like public but would like them maximum protection, they should put a "protective shell" inheritance. Some type of public SomeType can be turned into two classes: internal _SomeType (underground class), which bears the implementation of the class, except for public properties needed for serialization and for use in an external assembly for the code, and public SomeType, which will be inherited by _ SomeType ( front class), but carry an external load - to have public properties that are required to serialize, conversion for use in an external assembly code. This way you will have the opportunity to use tricks 1. to generate a class of similar types SomeType-but inherited from SomeType.
  3. Closely with attributes. Do not forget about using attributes in your code. Many of them closely enough to help the environment interact. Net with your classes. For example attribute TypeConverterAttribute - you tie it to your class, class converter SomeConverter. Not every obfuscator "knows" about it - and so you should keep the converter class of obfuscation or check as obfuscator working with attributes. Otherwise, communication established between the two classes by the attribute can be destroyed.
  4. If your class is going under the knife obfuscation, we should also think about the mechanism of its serialization. Let's say a class that inherits from Form serializes itself in such a way that if the obfuscator changed the name of its type SomeForm to 0, then there is a problem during initialization deserialize this class - he just can not find a resource 0.resources, as serialized in a SomeForm.resources.
  5. Use static string announcements instead of const string - it's difficult to find the initialization of the field (in the metadata of both announcements will be presented as the field).
  6. If you have a list of strings that you are represented as a list of string constants, better declare a string list / describe as a string array, and in the constants needed to store the index of the line in a string array.
  7. If you want to protect a certain algorithm of excess viewer - give it to perform more than one class, you distribute this task can be unload memory, but certainly difficult for these researchers to understand the problem that you have going on here.
  8. Use these features done as nested types, it will not affect performance, but will affect the "trudnoizuchaemost" your code.
  9. If we talk about the protection of the algorithms it is necessary to shift their execution is not one method, as part of the algorithm to transmit to the implementation of the different classes, ie, in fact, the algorithm will be the interaction of several classes.
  10. Initialize the form class without using. Resx and. Resources files - it is better to consult the index in order to avoid problems in the obfuscation of resources.
After obfuscation:
  1. Mandatory test the obfuscated assembly. Obfuscator not God, again. He's just doing his job, and you - a. So do not neglect the tests assembly after obfuscation.
  2. After obfuscation, be sure to check out the assembly tool peverify, that comes with the. Net Framework SDK - This utility checks the metadata of your assembly is correct. If your assembly is marked as CLS-compliant - this testing is mandatory. There are riders who correctly obfuscated assembly cover the special permission of PermissionSet.SkipVerification to avoid meeting the resulting assembly with its verification. Check - if there are any such resolution in your assembly after obfuscation, it is clear that allude to. True managed C + + assemblies are initially such permission, even if you did not mention about it in your code, this is also a hint :)).
  3. A little about the quality of obfuscation - do not be lazy, look how he obfuscator obfuscated. If obfuscation is written in native code - perhaps the authors doubt the quality of his obfuscation?
  4. Create a test project that will test your quick assembly, the article is not about that, but as long as obfuscators do not have the ability to test your build on functionality, only one does check the resulting assembly at least for the download.
  5. And most importantly - in case of problems, contact the authors, send the assembly, write what you need to achieve the goal - a specialist like a flux, while working with their product of his eyes "zamylen", he needs to throw up material for testing - what it is, the higher quality of obfuscation.
So what is the best protection. Net assemblies? To date, the combination of the tread (software protection meant) and obfuscator obfuscation and complete the project (cross-obfuscation) give the best protection. Certainly it is necessary to recommend obfuscate zamnut project as a system where all the types used by the project - obfuscated, it is possible. Since the burglary who is engaged or falling and breaking a well-protected programs - the units, it is still only possible is the joint use of these two types of products.