Run the. NET program out of the. NET Framework framework (source code implementation instructions)

The previous section introduced "Let. netProgramHow to run without the. NET Framework framework ",
This method is mainly implemented using the fetion framework,
Today we will introduce how to implement functions of the fetion framework by yourself without using the fetion framework,
And provides related implementationsCode.

Fetionframework has two files: fetionvm.exe and fetionvm. RSM. For the second file, we have provided its implementation when introducing the native compile-protected local DOTNET program to the DOTNET il assembly.Source code.

The fetionvm.exe function is similar to the code.

First, use the remote trial version to create a demo program. Then, analyze the demo program and find that its loader is actually used by calling rsdeploy. the three functions exported by DLL are initialized and the control is transferred to the DOTNET assembly.

prototype definition of the three functions:
typedef bool (winapi * pinitialize) (hmodule H, lpcstr szmodule, lpcstr szmainexe );
typedef bool (winapi * preloc (hmodule, pimage_nt_headers pntheader);
typedef bool (winapi * presolveimportdll) (hmodule );

some friends are dissatisfied with this issue. Delete the complete implementation code and only describe the implementation code, if you are interested, you can refer to your own implementation.

first, load the DOTNET program file to run and obtain the hmodule handle, which is used in all three functions.
call the initialize function. szmodule is the name of the DOTNET program, and szmainexe is the name of the current execution file.
call reloc to process the relocated table. Pntheader is also the ntheader after the DOTNET program loads in the memory.
call resolveimport to process the imported DLL.
Finally, transfer the JMP to the entry of the DOTNET program to control the transfer.

In addition, I also found another implementation method, that is, the VM unpacker OF THE DOTNET encrypted shell mentioned last time. It also uses the remotesoft virtual framework, however, it does not use the three functions exported by rsdeploy.

The unpacker was updated in the reteam forum yesterday. I downloaded it and studied it. I haven't looked at its initialization of dotnetvm. I mainly looked at its changes to the framework hook and found that the hook position in the JIT layer was moved. It seems that a member function of the emitter object is hooked. the emitter object is called by complie, And the location should be relatively deep. The method body reconstruction method has not changed. Currently, the encryption Shell Core does not seem to have escaped the interception of its hook.
Its interception location is deep, and the standard version of dnguard hvm does not detect it. However, its shelling function is still harmless to the standard encrypted assembly of dnguard hvm. The trial version will not be spared.

Currently, I am more interested in using the dotnetvm method. After a brief look, I just load rsdeploy. dll. No three functions exported by rsdeploy are called. It seems that the function in mscorwks has been directly called, and it is possible that it has implemented the functions of these three functions.
If you are interested, let's take a look and share with you what you can do.