Guardant Auto Protection is a tool that allows the program to be bound to the Guardant dongle in just a few minutes, thus protecting it from theft and unlicensed use. Guardant Auto Protection supports 32-bit Windows-based applications and is designed to handle executables of native applications (*.exe), as well as .NET assemblies (*.exe, *.dll).
The AP has a range of options (modes), which serve for adjusting an application for the dongle parameters (tie it to the ID, serial number, etc.), limiting the number of launches or running time of the application, encrypting it.
The main advantage of the automatic protection is that it is a simple and fast method of protection that requires almost no programming knowledge and saves the time of a software developer. Auto Protection implements a number of security technologies to achieve a high level of protection without use of the Guardant API.
Auto Protection of native executable files
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.
.NET Auto Protection
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.