Go deep into JIT to implement DOTNET code encryption and decryption

During this period, the fault tolerance of. net jit is tested.CodeInserted to JIT for testing.
This method is the first method I mentioned before to increase the kernel strength to prevent reflection and shelling.
This technology can be used to protect DOTNET code, or to decrypt the DOTNET encryption shell.

Currently, all encryption shells Insert the kernel into the EE to provide decryption services. The reflection function of DOTNET is also implemented at the EE layer,
Therefore, the reflection vulnerability before the encrypted shell is exposed.

If the encryption shell inserts the kernel into JIT and integrates with JIT to provide decryption services, reflection will basically fail. The decrypted Code cannot be obtained at the EE layer.
In this case, it is basically unrealistic to fix reflection. JIT only provides compilation services for EE. Of course, if the JIT layer is de-shelled, and then a service is added from JIT to provide the EE layer call, reflection can also be repaired. However, if the JIT layer is de-shelled, there is more to do with fixing reflection.

If you directly remove the encrypted shell of the EE layer from the JIT layer, you do not have to consider fixing the reflection problem. NET 2.0 and 1.1 are all useful.
This method is effective for encryption Shells and their versions. There is only one problem to solve when the JIT layer is de-shelled, because only the methods are compiled into JIT, so to completely de-shell all methods need to be compiled.
However, this problem is not big. It can be solved from the EE layer or reflection. I used it before when dealing with an old shell version. At that time, the shell was not escaped from the profile and could be dumped from the profile to the code. Similarly, the code can be obtained through the profile only when the method is compiled.
Reflection is relatively simple, so you don't need to know ee. This method will be compiled when invoke is a method.

JIT-layer shelling can take advantage of the current ee-layer encryption shell. If the encryption shell is still in the EE-layer mixing, there is no future.

The encryption shell of the JIT layer is similar to that of the EE layer with reflection (or even slightly worse, different shelling cores can only be used for different encryption shell kernels.
The more complicated the JIT encryption shell and JIT fusion, the more difficult it is to shell. However, more work is required to ensure the stability and compatibility of the encryption shell.
This is the reason why I did the JIT fault tolerance test. The kernel of dnguard 2.0 uses the JIT layer, and the fault tolerance test is similar.
The current kernel tone of dnguard will not be adjusted.

Next we will start the dnguard H-VM test and test. This is also pure JIT layer. (H = half)

Dynamic restoration of dngruntime at runtimeProgramTo split the assembly method (that is, one method is split into two or more ),
The split method is about half JIT and half dng h-VM.

Follow the following conventions:
If method A uses JIT, all methods called by method A use dng h-VM.