Position of mscorwks. dll in. NET and Its Application in. Net Code Protection

Mscorwks. dll is the core file of DOTNET, especially in net2.0. previously scattered functions are concentrated in this DLL.
In net1.1, there is also a file mscorsvr. dll and mscorwks. dll which are of the same status.
They correspond to Windows ServiceProgramAnd Desktop programs.
In net2.0, they are all integrated into mscorwks. DLL.
At the same time, the mscorsn. dll function in net2.0 is also merged into mscorwks. dll.
It is the core of the DOTNET Runtime Library.
The execution engine (EE) of DOTNET and the implementation of internal objects are all in this DLL.

You can use reflector to view the DOTNET class library.Source codeSometimes some functions do not see the sourceCode, But mark it as an internal implementation. Basically, the Code actually implemented by these functions is in this DLL, which is implemented by native. For example, the objects and implementations of the reflection function are described in this section.

Net program execution is mainly done by it, and another important file mscorjit. dll is called by it.
Now we divide mscorwks. DLL into two zones, A and B,
A is the main execution engine (EE) and native implementation.
B is the processing part for EE to call JIT.

The reflection function of net2.0 is implemented in Area. Encryption shells should be mounted to the kernel in Zone A if they require perfect compatibility (that is, they do not undermine any features and features of DOTNET itself.
There is a function in area A to get the content of the method body. The EE layer needs to get the content of the method body through this function. Therefore, the perfect method is to replace this function and implement it with the kernel of the encrypted shell.

The biggest drawback is the reflection vulnerability, because reflection also calls this function to obtain the method body.

On this basis, how can we destroy reflection?
In reflection, you need to call the method member function getmethodbody. This function is implemented by native and is implemented by mscorwks. DLL, so the encryption shell can hook this function for some prevention.
However, the effect is not satisfactory. The hacker can restore the original implementation of this function.

There is another method, which is not perfect but valid, that is, the function for getting the method body is not directly replaced,
Instead, it only replaces the place where the method body is obtained before compilation. In this way, the kernel decryption service is provided only when the compilation method is required.

What is the effect? This can modify the reflection implementation function and directly use JMP to encrypt the kernel service of the shell.

This is the method used by dnguard V1.0. It seems to be the method of the current version of a shell.
Of course, dnguard 1.0 also simply adds memory modification, but this effect can be too optimistic, and hackers can also block this part.
Because reflection is implemented in Area A, such as when the kernel of the shell is mounted to Area A, reflection is easier to fix.

Before I made dnguard 2.0, I had thought of a way to make reflection ineffective or even difficult to fix.
That is, the kernel is mounted to Zone A and Zone B at the same time.
First, we will introduce how a function is executed.
First, ee checks whether the function is compiled? It is called directly after compilation. Compile without compilation. Implemented by a prestub.
Then, the EE obtains the method body, parses the method header and seh table, and converts it into a structure.
(These are completed in Area A), and the JIT compilation is called in Area B.

In Area A, ee only relates to method headers and sehtable, while in Area B, il bytecode is meaningful when JIT is called.
Therefore, the kernel can be mounted to these two zones respectively. Only the header and seh are provided in Zone A, and the Il bytecode is provided in Zone B.

However, I gave up this idea after I started dnguard V2.0, because it is still insecure.
For more information, see JIT to implement DOTNET code encryption and decryption.

Whether the kernel is in Zone A or Zone B, if the kernel of an encrypted shell is only mounted in mscorwks. dll. Therefore, the JIT-layer shelling machine cannot be escaped. I'm writingArticle"Go deep into JIT and implement DOTNET code encryption and decryption" has been tested.

Here, we will introduce mscorjit next time. DLL.