. Net encryption principle, encryption Shell Running Library Loading Method (9)

Currently, the. NET encrypted shell Runtime Library is loaded in two ways.
One of the most widely used is
Direction Program Centralized loader Injection Code And then add a static constructor for each type in the Assembly. Call the loader code in the static constructor.

Most of the encryption shells currently use this mode. This mode utilizes the characteristics of static constructor.

It should be noted that the static constructor and the Runtime Library for loader code execution are not loaded yet, so this part of Code cannot be encrypted.
After the Assembly is executed, the Runtime Library is loaded.

In addition, the Windows PE Loader is used to automatically load the Runtime Library of the encrypted shell..

If you are familiar with Win32, you should know how to modify the DLL Method for inserting an import table. This is basically the principle.

. Net assembly will have at least one Import Record
EXE is mscoree. dll _ corexemain
The DLL is mscoree. dll _ cordllmain.

You can import these two functions in the Runtime library, and then directly modify the import records of the Assembly.

Remotesoft's new version of protector seems to be doing this, and its previous version is also the first method.
Remtesoft protector is also an encrypted shell on the JIT layer, working almost the same way as cliprotector,
The JIT layer vulnerability also exists.

The advantage of this method is that the Runtime Library is loaded when the Assembly is loaded. Therefore, all methods of the Assembly can be encrypted.

Of course, the implementation of this method is not as simple as that mentioned, and the Runtime Library installation problems during startup.
Install the Runtime Library as soon as the framework DLL is loaded,
The safer solution is to hook the loadlibrary functions in the DLL load.

This method is a little bad.
It means that the 32-bit and 64-bit runtime libraries cannot be self-adaptive and need to be clearly defined during deployment. Although manifest can be used on systems above XP, the old system will not work.

So I still adopt the first method in the latest dnguard hvm 2.8.

In the first way, the. NET static constructor has a license, that is, the Global static Constructor (module static constructor ).
C # and VB. NET cannot be used in this normal development, and can be implemented using IL or C ++/CLI.

This static function is triggered when the module is accessed for the first time.
So you don't need to add a static constructor to all types.
I don't know about compatibility. Will there be exceptions?