Incomplete Analysis of a strong shell in. net

Incomplete Analysis of a strong shell in. net
In fact, the question is somewhat different from the content, because this article does not conduct in-depth analysis on the shell itself, but analyzes its protection and cracking from another perspective. I won't even mention this shell. (The shell author is my idol.

1. Introduction to shell protection methods
Many articles on the shell website have introduced his method, but they are not in-depth. (This is of course because it has been commercialized .) In general ,. the operating mechanism of net is different from that of win32 platform, for example. after the PE of net is loaded into the memory, it does not immediately compile all the code from MSIL to native code, but compile a method every time a method is run. After a method is compiled, the native code of the method always exists in the memory for the next direct call. Due to a garbage collection system, the resources occupied by this method may be released after a period of time.
This shell is used. net, the size of the code block of all the methods of the protected program is set to 0, and the real code is stored encrypted by multiple algorithms, but the definition of each method is still in, when the jit engine calls a method, the program to be linked is forwarded to the decryption code of the shell, and the source code is decrypted before being passed to jit. This includes recreating the structure of the method table because the size of the code block in the method table of the original program is 0. These encryption and decryption codes are all in a local dll, so the only drawback of this shell is that the encrypted program cannot be used across platforms. In fact, this is not important for the authors of shared software. It is sufficient for a program to run on all platforms where the. net framework is installed.
As we all know,. net Has Profiler, which can output IL code when JIT starts compiling. In this case, can I directly use Profiler to output the IL code? None. The author of Shell also said on the website that he understands the communication between profiler and jit and can easily avoid Profiler monitoring. Next, let's take a look at how profiler communicates with jit.

Code :--------------------------------------------------------------------------------
TADDR MethodDesc: MakeJitWorker (COR_ILMETHOD_DECODER * ILHeader, DWORD flags)
{
...
...
If (CORProfilerTrackJITInfo ()&&! IsNoMetadata ())
{
{
PROFILER_CALL;
G_profControlBlock.pProfInterface-> JITCompilationStarted (ThreadID) GetThread (), (CodeID) this, TRUE );
}
COR_ILMETHOD * pilHeader = GetILHeader ();
New (ILHeader) COR_ILMETHOD_DECODER (pilHeader, GetMDImport (), NULL );
}
...
...
--------------------------------------------------------------------------------
The red code indicates that JIT notifies Profiler through the interface to start JITCompilationStarted. At this time, we can dump the il code in the Profiler memory. What if the IL code is not decrypted yet? (This is also true) the shell can call the decryption code after the notification is sent, so that the source code of the program cannot be obtained by using Profiler alone.

For example, if you use Profiler to dump a program encrypted with the shell in JITCompilationStarted, the following content is obtained:

JITCompilationStarted:
Class name is:
CFunction name is: x
Enter fat codeFlags: FFF
MaxStack: 9600
CodeSize: FFFF07E7
LocalVarSigTok: FFFFFFF
E707FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Ffffffffffffffffffffffff

Ffff0083e707ffffffffffffffffffffff1a28790000062affff8089e707ffffff
Ffffffffffffff8088e707

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC08BE707FFFFFFFFFFFFFF
Ffffffffffffffff80b6e707

Ffffffffffffffffffffffffff03300a002b00000000000000000028790000062800003000
A80ED0B000428F807000A

80ee0b000428f700000a80ef0b00042000116802ce52affff80a6e707ffff1a287900
00062AFFFF80A3E707FFFF

1a28790000062affff80a0e707ffffffffffffff80a1e707fffffffffffffffff
Fffffffffffffffffffffff

Ffffffffff40bbe707ffffffffffffffffffffffffffffffffffffffffffffffffffff
Ffffffffffffffff00b7e707

Ffffffffffffffffffffffffffffffffffffffffffffffffc0b1e707ffffffffffff
Ffffffffffffffffffffffff

FF ........

Needless to say, a bunch of garbled characters. Next, let's start to see how to dump the real source code.

2. Obtain the decrypted source code
The main content of this article is to analyze how to obtain the source code that has been decrypted by the shell, and the real and complete shelling is not available yet. Of course, it is even unnecessary. Our idea is that since the SHELL hook the jit and ee (execute engine) communication, we can also interrupt it. The code is always decrypted just a moment before jit is about to be compiled, we need to find this breakpoint.
Rotor is a good source code for us to understand the above content. We can see this function in fjit. cpp:

Code :--------------------------------------------------------------------------------
/*************************************** ***************************************

******/
/* Jit the method. if successful, return number of bytes jitted, else return 0 */
FJitResult FJit: jitCompile (
BYTE ** ReturnAddress,
Unsigned * ReturncodeSize
)
--------------------------------------------------------------------------------

The name is similar to the key function of jit, but the rotor code is not the. net framework Code on windows. Therefore, jitCompile is not the name of the corresponding function in the framework. Think about other methods.
Mscorjit. dll is the core file of the jit engine. Among them, there must be a function that reads IL from ee. Decompile the file with ida. When ida prompts you to download the file symbol from the Internet, click "OK. Search for such a function.
. Text: Plain private: virtual enum CorJitResult _ stdcall CILJit: compileMethod (class ICorJitInfo *, struct CORINFO_METHOD_INFO *, unsigned int, unsigned char **, unsigned long *) proc near

CompileMethod: Compile method. Take a look at the input parameters. The second parameter is struct CORINFO_METHOD_INFO *
Search for the structure in the source code of the rotor and get the following definition (although you do not know whether the two structures are completely the same, you may first assume that the two structures are the same)

Struct CORINFO_METHOD_INFO
{
CORINFO_METHOD_HANDLE ftn;
CORINFO_MODULE_HANDLE scope;
BYTE * ILCode;
Unsigned ILCodeSize;
Unsigned short maxStack;
Unsigned short EHcount;
CorInfoOptions options;
CORINFO_SIG_INFO args;
CORINFO_SIG_INFO locals;
};

The first two pointers to the structure
Typedef struct CORINFO_MODULE_STRUCT _ * CORINFO_MODULE_HANDLE;
Typedef struct CORINFO_METHOD_STRUCT _ * CORINFO_METHOD_HANDLE;
I searched the local machine and the network and did not find the specific definition of them. It seems that they are uninitialized ented again. It doesn't matter. The key is the third and fourth members. ILCode and ILCodeSize. Is this the memory address that points to the IL code? Is the code that points to the password decrypted? If yes, we can interrupt it here to output the decrypted code.

3. debugging
Now that mscorjit. dll is deep in the system, you don't need to use. net debugging. You can use OllyDbg, which is the most familiar one. Run the encrypted program first, append it to the process with OD, and then bp 7906E7F4. Soon, the OD is interrupted. View stack values

0012D750 79E9776F returned to m