Auto Protection

When using Auto Protection for native executable applications, a small executable module, the so-called “internal vaccine”, is embedded in the protected application. The moment the application starts, the module loads a “vaccine” from a separate external file, which produces the necessary checks and code conversion.

Native Auto Protection employs an arsenal of unique technologies: from control over dongle removal from the port and verification of the digital signature to creating a mini interpreter in the application code that converts assembly language instructions, and protection of imported functions.

Native Auto Protection operation scheme:

• The Auto Protection utility embeds an executable module into the body of protected application — internal vaccine.
• At the moment of launching the application the internal vaccine calls the external vaccine from a separate file.
• The external vaccine runs the required checks and encryptions and launches the protected application.

There is a special technology for auto protection of .NET code. The specifics of such protection is that even when compiled, .NET code is a set of instructions in MSIL, a high level programming language. In the course of protection, part of the application’s functions is encrypted using the dongle and placed in special storage. Before being called for the first time, the function gets decrypted and transferred into memory, where it is executed immediately.

The advantage of .NET auto protection is that at any time only a part of the protected application is contained in memory, and the unused functions are unloaded automatically, which makes the removal of protection an extremely time consuming and expensive task. In addition, obfuscation of all application code is implemented using a separate utility; there are other additional safeguards as well.

A two-stage protection approach is used for the .NET assemblies’ automatic protection of with each stage performing its own tasks in the overall process:

• MSIL code symbol obfuscation;
• Transfer of a portion of MSIL-code into a protected storage.

This concept permits a significant increase in the overall level of .NET protection, since the widely distributed .NET reverse engineering tools (ildasm, reflector.net, etc.) become useless.

It is predicated upon the fact that most of .NET assembly’s code is stored in the protected native container, which in turn is protected by both pseudocode (software) and the dongle’s functionality (hardware solution).

When MSIL code previously encrypted by a hardware algorithm is called, the dongle itself is addressed first for decryption purpose and only after the execution of code begins.