在前面介绍mscorwks的时提到了,.net的程序是以函数为单位编译。而在 mscorjit中提供了一个函数 
compileMethod 。mscorwks就是通过调用这个函数来编译.Net方法的。
对于EE层,或者虚拟机预处理层的加密壳,只需要hook这个函数就可以dump出方法体的代码了。
需要注意一点,这个函数是 thiscall 调用约定的。

.Net方法体进入 compileMethod  之后是怎么样的处理流程呢?

限于篇幅,这里只能简单介绍一下,具体详情可以参考 sscli 2.0的源代码。
compileMethod 实际上只是一个接口函数,它没有做实际什么工作,
只是简单的 调用另一个函数:jitNativeCode。

在jitNativeCode 函数是一个线程安全的函数,在它里面实际上只是做了一些准备工作。
安装异常处理,然后实例化一个Complier对象。初始化Complier类,再调用
这个类的一个成员函数 compCompile 。

在 compCompile 就开始了实际的编译工作。

所以hook jit来实现脱壳的话,我们有三个选项:
 hook compileMethod  (thiscall)
 hook jitNativeCode (fastcall)
 hook compCompile (thiscall)

对于这三个方案 实现脱壳是完全一样的。在这三个函数里面我们都能够获取到脱壳所需要的结构体。
实际上脱壳需要的结构体是 CORINFO_METHOD_STRUCT,CORINFO_MODULE_STRUCT,CORINFO_METHOD_INFO这三个。

我在脱某壳个人版加密的程序时是采用的方法2,hook jitNativeCode 函数。
hook方法:采用的替换方式,即直接修改 compileMethod  函数,将 call jitNativeCode 改为 call myhook。
在 myhook函数里面处理脱壳工作,然后再调用 call jitNativeCode 。

实际上有一个技巧。一般我们通过反射invoke让一个方法体进入jit处理过程的,然后在 myhook 里面截取dump方法体。
假设我们在dump一个 Exit函数时,如果让它执行了会导致进程退出,因为invoke会执行方法,而我们需要的只是让方法体进入
jit处理过程,以方法dump,而不希望这个方法被执行。所以我们可以不用回调 jitNativeCode 函数,直接返回一个nop地址。

maxtocode 2007企业版具称是虚拟机处理层的壳,那它在虚拟机处理层做了什么工作呢?
具分析 mscorjit.dll 的内存镜像,它实际上做了和 jit层脱壳 差不多的工作,
同时使用了 方案2 和 方案 3. 显然它hook jit的目的不是脱壳,而是实现 方法体的还原。

我们可以很容易确定 在程序运行到 compCompile 中后,加密壳的运行库已经完成了所有解密工作,
因此在 compCompile 函数里面,或者它下级的函数里面是脱壳的好时机。

如是我修改了一下jithook程序,只改了hook位置,即hook compCompile 的下级函数。
然后测试dump。效果如下:


可以dump出源代码。
看来企业版相对个人版来说只是hook位置的变化,对于脱壳来说,基本上没有增加任何难度,
只需要更改一下hook位置,就可以dump了。

另外发现企业版运行库的一个bug,可以用简单的方法脱壳。

如果只是分析程序注册算法,我们只需要 CORINFO_METHOD_INFO 就够。
在tankaiha  大以前的文章介绍过。
直接获取这个结构体中 的ILCode,而后用ilbytedecoder 取得il汇编代码。异常处理表不用修复也不影响分析代码。