. Net encryption principle, pure JIT layer encryption Shell Core Implementation (7)

We have introduced the core implementation principles of mainstream double-layer encryption shells,
And compatibility, while simplifying the encryption Shell Core with security considerations.
The compatibility and security of the encryption Shell Core are discussed, and the Implementation Mode of the encryption Shell Core compatibility and Security win-win is mentioned, pure JIT layer core.

This document introduces the implementation of the encryption Shell Core.

Previously, we have simplified the encryption Shell Core to only hook two functions of the Framework kernel, one of mscorwks. dll and one of mscorjit. dll.
At the same time, we know that mscorwks. dll is a bottleneck problem in terms of compatibility, so we will discard the core hook for mscorwks. dll. Only one hook for mscorjit. dll is retained.

Many of you may have learned about the kernel mode of the dnguard hvm trial version, which is implemented on the JIT-only layer. This is an example.

First, cancel the dependency on the EE layer.
That is, the encryption shell does not install any services on the EE layer. In this way, the bottleneck of mscorwks. dll is completely put aside in terms of compatibility.
Security improvements are also made to avoid the vulnerability that may be intercepted by the EE layer to leak the method body's local variable signature and Exception Handling table.
Reference: http://www.cnblogs.com/rick/archive/2007/08/13/852999.html

Implement method body preprocessing in the encrypted shell Runtime Library
Because the encryption shell does not pre-process the method body at the EE layer hook, We need to pre-process the current compilation method at the JIT layer.
ProgramThe contents of the relevant struct contained in the running database of the encrypted shell are not the correct content of the current method body. We need to rebuild the structure content here.
As for how to implement the method body preprocessing, we can analyze the implementation of its virtual machine preprocessing layer through reverse mscorwks. dll.Code.
All the implementation code must be transplanted to the encrypted shell Runtime Library, otherwise the dependency on mscorwks. dll will still not be available.

What can be processed by method body preprocessing?
1. You can directly convert the local variable signature and Exception Handling table of the method body to the corresponding object entity in the JIT layer.
2. Restore the Il bytecode.
Note: The IL bytecode is directly transmitted in the JIT layer, which has the risk of being intercepted by the JIT layer.

Select the hook location of the JIT Layer
The dnguard hvm trial version uses the direct hook compilation method. Encryption Shell Core onlyDirectIntercepted JITOneLocation.
This mode is available in dnguard hvm Standard Edition and Professional Edition.Basic Mode.

In the new compilation entry function provided by the encryption shell, the first thing we need to do is determine the method body. If it is an encrypted method body, compile and pre-process the method body (the dnguard standard destroys intermediate data after preprocessing ).
Then pass the control to JIT.

Improvement of "method body encryption corresponding information" to cope with static shelling
In front of the. NET encryption principle, the implementation of the method body encryption information ing describes the implementation of "method body encryption ing information.
We have been using the method of direct storage in metadata, mainly to facilitate operations in the EE layer.
Now we use the pure JIT layer core, which can be improved by the way.

After this improvement, you can use a custom structure table to save the information and encrypt the structure table. This method can increase the strength of anti-static shelling. Of course, it does not have much impact on dynamic interceptors.

Local detection of JIT layer framework to cope with dynamic interception of JIT Layer
At present, the encryption Shell Core cannot guarantee the security of the Il bytecode In the JIT layer, that is, it may be intercepted and cause the Il bytecode leakage.
Therefore, for the pure jit-layer encryption shell, we must at least ensure that it is not inferior to the double-layer Shell in this respect. In the dual-layer core, three functions are intercepted at the same time. Therefore, the attacker must intercept the functions at the lower levels of the three functions to intercept them.
Here, because the core only intercepts entry functions, hackers can directly intercept these functions to intercept the Il bytecode.
The solution is simple, that is, to detect the three functions in the encrypted shell Runtime Library.
Of course, you can expand the scope of detection.

In addition, if you focus on compatibility, you can not detect any function at all, such as the trial version of dnguard hvm.
The dnguard hvm Standard Edition detects some framework functions.

This core still cannot guarantee the Il bytecode. What is its protection significance?
This core is an improvement in the current encryption Shell Core mode. Currently, the core encryption mode of the encrypted shell on the market has vulnerabilities that can be used to directly intercept the framework function to obtain the complete method body, this mode ensures that the local variable signature of the method body and the exception handling table cannot be obtained from outside the encrypted shell runtime. That is, if the attacker starts from the framework, the two parts cannot be obtained.

The IL bytecode cannot be guaranteed. What is the significance of other protections?
First, the Il bytecode is only part of the method body. Protection of other parts can effectively prevent the attacker from completely shelling.
In this way, the attacker will not be able to obtain a complete shelling assembly, and will not be able to perform overall analysis, optimization, anti-obfuscation, and other related processing on the Assembly.
The attacker can only obtain the independent bytecode of a single method body. This can basically protect the copyright of the code and greatly increase the difficulty of Cracking Analysis. In combination with code flow obfuscation, the effect is better.
The local variable signature has no effect on the program process and should have little impact on the analysis of the Il code. The exception handling table affects the code process (such as the final block fault block ). Another point is that there is no exception handling table, and it will be more difficult to perform process anti-obfuscation.

However, it is always not perfect, so the hvm feature is added in dnguard Professional edition to protect the Il bytecode In the JIT layer, so that the attacker cannot intercept correct and complete il bytecode.

Next, we will introduce how hvm core works.