[.NET逆向] SightInside-.NET托管加密初探
SightInside-.NET托管加密初探前言
现阶段，.NET应用程序有几种主要保护方式：
混淆
名称混淆：对元数据进行处理，使反编译的代码命名的可读性降低。兼容性好，对性能影响较小。适用于Mono等多个分支。
传统控制流程混淆：对程序流程进行处理，使反编译的代码流程的可读性降低。兼容性好，对性能影响较大。主要技术有代码碎片化、代码乱序等。
虚拟保护控制流程混淆：在传统控制流程混淆的基础上，模拟处理器对指令集的处理，达到保护的效果。兼容性好，对性能影响大。
非托管层面加密：使用Native应用程序的保护手段保护程序集。如NT系统下的 ThemIDA 。
混合编译：利用CLR混合编译特性，将托管代码与非托管代码编译至一个应用程序中。如 DLLProtect 。
托管层面加密：通过原地解密或挂钩运行库等方式加密托管代码。根据挂钩来源，又可分为：
由托管代码挂钩：由托管程序集挂钩运行库，如 Reactor 。兼容性优于非托管挂钩形式的加密。
由非托管代码挂钩：由非托管程序挂钩运行库，如 MaxtoCode 。
其他方式
SupressIldasm属性。
利用一些特有特性。
本篇文章将针对托管层面加密展开。
看看非托管代码挂钩了什么
首先要说明的是，并非所有托管层面的加密都存在Inline HOOK，也并非所有的HOOK都来自非托管加密代码。
我们来看这样一个例子：
查看挂钩对象
可以发现， mscorwks.dll 中有函数被挂钩了。我们推断，这是一个虚拟机预处理层的加密。
为什么这么推断呢？
.NET程序运行时，先交由 mscoree.dll 检查所需版本运行库是否存在。因此，.NET应用程序只有一个导入函数，即 _CorExeMain 或 _CorDllMain 。
然后交由相应版本的执行引擎（Execution Engine，abbr. EE）处理。这一层称为虚拟机预处理层（EE层）。在.NET 2.0中，由 mscorwks.dll 承担这一角色，在.NET 4.0中，由 clr.dll 承担这一角色。
最后交由即时编译器（Just-in-Time compiler，abbr. JIT compiler）编译 MSIL 为 Machine Code 执行。这一层称为即时编译器层（JIT层）。在.NET 2.0中，由 mscorjit.dll 承担这一角色，在.NET 4.0中，由 clrjit.dll 承担这一角色。
结合 mscorwks.dll 的符号文件，搜索挂钩地址，我们可以定位到这样的函数中：
使用符号文件查看挂钩对象
对于这种情况，有两种思路可行。一种是分析 Word.dll ，找到解密的算法。另一种是直接截获解密的数据。
尝试分析 Word.dll
思路是正确的，因为确实是在挂钩的函数处将加密的方法体解密。但是，由于 Word.dll 是一个非托管程序，分析难度较大。此外，非托管程序可以被很多成熟的保护工具保护，如此处的 VMProtect ，分析难以进一步进行。相对于托管代码挂钩，非托管代码挂钩虽然降低兼容性，但强度更大。
**** Hidden Message *****
666666666666666
页:
[1]