. Net encryption principle, implementation principle of the hvm core (8)

At present, after the encryption shell transfers the core to the JIT layer, the kernel mode has little room for increased strength. Currently, encryption shells on the market have at least one common defect, which cannot prevent the JIT from intercepting the Il bytecode at the underlying layer.

Some shells increase the intensity from the surrounding area (such as Anti hook). Because of the diversity of hooks and shell mounting, you need to consider your own compatibility, so this effect is not very ideal.
Starting with the prevention of shelling, the local variable signature and Exception Handling table are protected to prevent the restoration of the method body from shelling. In this way, although the interception of IL bytecode cannot be prevented, obfuscation with the process can still provide relatively effective protection.
It is still a bit regrettable to prevent the JIT layer from intercepting the complete il bytecode.

Http://www.DNGuard.Net/
The core of dnguard hvm is to achieve this-the JIT layer cannot intercept complete and correct IlCodeIt reduces the protection granularity from the original "per method body" to "per operation code (hvm pseudocode )". The actual principle is also different. During JIT compilation and processing, the hvm pseudo code will not be directly restored to the Il code. Instead, the hvm Runtime Library will participate in compilation to implement the direct hvm pseudo code-local code. In fact, the core of hvm implements the compilation function of a subset of IL code.

Efficiency:
If the common ilcode needs to be processed by the hvm core, will it cause performance loss?
This problem does not exist. The hvm core is dynamically loaded using Win32 exception handling mechanism. Only hvm pseudocode triggers hvm core loading. After an hvm method is compiled, the hvm core is automatically uninstalled.

Does hvm code compilation cause performance loss compared with ilcode compilation?
The answer is yes. hvm provides a strength option that can be set to 1-5. indicate the ratio of pseudo-code replacement to ilcode.
For example, if it is set to 1, only the function call instruction is replaced. Compilation of function call commands is actually very simple.
The default value is 3, which indicates that the actual performance loss is relatively small. Compared with the pure encryption method, this parameter is basically ignored.

 

Dynamic pseudo-code:
Hvm code is dynamic. In static mode (strength less than or equal to 3), each encryption module has more than 5 different solutions. Each encryption module has different solutions. The solution is dynamically generated by the module ID code + customer ID code.
In dynamic mode, the code is processed twice in the hvm core, and each method has a dynamic random solution.
Pseudo Code intercepted in JIT is dynamically random, and the pseudo code intercepted in each method does not necessarily correspond to each other.