Protect your intellectual property - Encrypt your IL code!

DNGuard HVM protects the IL code stored in your assemblies. During execution the code is handed to the jitter in dynamic pseudocode form just before compilation occurs. The DNGuard HVM execution engine assures that your assembly is never decrypted in-memory. This makes it impossible to reconstruct your original assembly by using memory dump tools.

Through the use of a command-line utility DNGuard HVM takes your assemblies as input and applies a security envelope on them. The application is then distributed to the client with an additional library component that binds to the .NET execution engine, handing it the code for execution.

The DNGuard HVM package contains the following components:

1. The DNGuard HVM command line tool - a command line utility that lets you protect your assemblies.

2. The DNGuard HVM GUI based tool - a GUI based interface for your convenience.

3. The just-in-time decoder/HVM Runtime - a library component that binds to the .NET execution engine upon execution of your code.

The protected code and the just-in-time decoder/HVM Runtime library component can be freely distributed to unlimited number of end users.

Technology

One of the issues often arises when developing .NET applications is how one can protect its code from reverse-engineering.

While reverse engineering of code has been around for a long time, the fact that .NET assemblies contain IL code and rich metadata make it easier to hack, change and reassemble virtually any program. For developers who want to protect their intellectual property, this ease of disassembly poses a significant problem.

Lutz Roeder's Reflector, Microsoft's ILDASM and other .NET decompilers are all capable of exposing the IL code stored in your assemblies to the prying eyes of a potential hacker. Your intellectual property can be studied, and your program can be reconstructed after customization.

DNGuard Professional offers real protection for your intellectual property, it does so by encrypting the IL code stored in your assemblies. During execution the code is handed to the jitter in its decrypted form just before compilation occurs. The DNGuard execution engine assures that at most a single method will reside in memory in its decrypted form in any given time. This makes it impossible to reconstruct your original assembly by using memory dump tools.

DNGuard Enterprise with HVM Technology offers the best protection for your intellectual property, it does so by transforming the IL code stored in your assemblies to HVM pseudocode and encrypting the HVM pseudocode. During execution the code is handed to the jitter in its HVM pseudocode form just before compilation occurs and HVM Runtime Compiler helps the jitter to generate native code directly from the pseudocode. The HVM execution engine assures that no IL Code will reside in memory in any given time. This makes it impossible to reconstruct your original assembly by using memory dump tools.
HVM II is a dynamic virtual engine, a small part of the protected code will be interpreted and executed in the DVM engine and most of the code will be JITed and executed in the DVM context.

Through the use of a command-line utility DNGuard HVM takes your assemblies as input and applies a security envelope on them. The application is then distributed to the client with an additional library component that binds to the .NET execution engine, handing it the code for execution.

DNGuard HVM is not an Obfuscator and therefore doesn't suffer from some of the known limitations of obfuscation tools.

Usage of the Reflection API and dynamic class loading often breaks the application after it has been obfuscated. Stack dump information sent by the customer containing obfuscated method names makes it extremely difficult to infer the original methods that were called. DNGuard HVM keeps class, method, and other symbol names unchanged thus enabling the developer to use Reflection API freely without breaking the application, stack dump information contains the original method names.

Code Encryption Based Solutions

In an effort to limit the visibility of MSIL to the prying eye code encryption techniques are used to prevent a potential hacker from reverse engineering the code. Code encryption makes use of standard cryptographic algorithms to cipher the MSIL code, thus making it completely unreadable to human or a disassembler. In that respect obfuscation techniques fall short compared to code encryption techniques. ILdasm or other disassemblers can't dump the content of the assembly simply because it no longer contains MSIL instructions.

Evidently, the .NET framework understands only assemblies that comply wity the CLI (common language interface) standard. This means that eventually the code has to be deciphered in order for the .NET runtime to execute it.

Most code protection tools encrypts a whole assembly that is get decrypted at runtime. They often wrap the entry point assembly (that is the one containning the entry point of the application) with a native image loader.
Metadata information such as class, method names and other symbol information is not visible and can't be viewed using standard .NET tools.

Once the application is executed the code gets decrypted by the native image loader and it resides in-memory in its decrypted form, now it is ready for the .NET runtime to work against.

This raises a factor that most code protection tools fail to realize. Once the code is deciphered it's completely exposed to prying eyes of a potential hacker in-memory, because the entire assembly loads into memory in its MSIL form. This poses a security threat since once the assembly loads in-memory it can be dumped to a file using standard memory dump tools.

How is DNGuard different from other code protection tools?

DNGuard doesn't take the path described above. It assures that your MSIL code remains encrypted at all times. Upon execution it binds to the to the .NET execution engine, handing it the code for execution, one method at a time. The MSIL code is never kept inside the memory space of your application.

Our tool doesn't use a native image loader that wraps around the entry assembly, this is why you can use it to deploy ASP.NET web based applications.

Metadata information remains intact and can be viewed using standard .NET tools. This makes our tool perfect for distributing 3rd party library components. It is now possible to offer your customer a protected .NET component that he can program against to develop his own apps without exposing your IP.

How is HVM different from per method code protection tools?

HVM - A Virtual Machine Technology. it also handle the application code execution one method at a time, but never decrypt method to MSIL Code form. it decrypt method to dynamic pseudocode form just before compilation occurs and HVM Runtime Compiler helps the jitter to generate native code directly from the pseudocode. The HVM execution engine assures that no IL Code will reside in memory in any given time. See more about HVM