Mscorwks.dll status in. NET and Code protection applications

Mscorwks.dll is the core file of dotnet, especially in net2.0, where previously dispersed functionality is concentrated in this DLL. net1.1, there is also a document Mscorsvr.dll and Mscorwks.dll are equal status. They correspond to Windows service programs and desktop programs, respectively. In the net2.0, they are all unified to the mscorwks. DLL. At the same time, the function of Mscorsn.dll in net2.0 is also merged into Mscorwks.dll.
It is the core of the Dotnet Runtime library.

Dotnet's execution engine (EE), the inner object's implementation is inside this DLL.

When we use reflector to view the Dotnet class Library source code, we often encounter functions that do not see the source code, but mark it as an internal implementation. The code that basically implements the functions is in this DLL, and is native implemented. such as the reflection function of related objects and implementation is this inside.

NET program execution is mainly done by it, there is another important file Mscorjit.dll is called by it.

Now we divide the mscorwks.dll into two zones A and B.

A is the primary execution engine (EE) and native implementations.

B is the processing part of the EE call JIT.

The reflection function of net2.0 is realized in area A. If you want to achieve perfect compatibility (that is, without destroying any of the features and features of the dotnet itself), the shell should hang its kernel in area A.

In a region there is a function to achieve the content of the method body, the EE layer needs to obtain the method body content is obtained through this function. So the perfect way is to replace this function and use the kernel of the shell to implement the function.

The biggest disadvantage of this is the reflection vulnerability, because reflection is also the call to the function to obtain the method body.

What is the way to destroy reflection on this basis? In reflection it is necessary to invoke the member function of method Getmethodbody, this function is native implemented, just in Mscorwks. DLL, so the shell can hook this function to do some preventative processing.

But the effect is not ideal, the cracker can restore the original implementation of this function.

There is also a method that is not perfect, but effective, that is, instead of directly replacing the function that gets the body of the method, it replaces only the place where the method body was acquired before compiling. This provides the kernel decryption service only if the method is to be compiled.

What's the effect? Also not ideal, cracked this can modify the reflection of the implementation function, directly jmp to the shell of the kernel service. This is the way Dnguard v1.0 is used, and it seems to be the current version of a shell.

Of course, Dnguard 1.0 also simply added a memory modification, but the effect can be too optimistic, the cracked can also be shielded from this part. Because reflection is implemented in area A, reflection is easier to repair if the core of the shell is also hooked up to area A.

Before I did Dnguard 2.0, I thought of a way to make reflection ineffective or even difficult to fix. That is, at the same time in the kernel hook in area A, and Area B.

Let's first explain how a function is going to be executed.

First, EE checks to see if the function compiles? The compiler is called directly. compiles without compiling. Implemented by a prestub. Then EE obtains the method body, and makes a simple parsing of the method header and Seh table, and transforms it into a structure. (These are done in area a), go into area B and call JIT for compilation. EE only relational method headers and sehtable in area A, while the Il byte code in B region invokes JIT has practical meaning. Therefore, the kernel can be hooked up to these two zones, and only provide IL byte codes in the header and Seh,b areas in zone A.

But after I started doing Dnguard v2.0, I gave up the idea because it was not safe.

Whether the kernel is in area A or B, if the kernel of an encrypted shell is limited to mscorwks.dll for hook implementation. Then you can't escape the shell of the JIT-layer sheller. I have been testing the article "deep JIT, implementation of dotnet code encryption and decryption."