.Net 加密原理，加密壳核心的兼容性以及安全性讨论(六)

前面我们介绍了目前主流的双层加密壳核心实现原理，
同时提到了应对兼容性，同时考虑安全性的前提下对加密壳核心进行简化。
今回主要讨论一下安全性、兼容性需要注意哪些因素。

关于安全性，主要应对两类破解者。
1、静态分析脱壳
对于这一类，行之有效的方法就是增加加密算法的数量和复杂度。
加密壳核心的实现方式对其影响可忽略。

2、动态框架核心层拦截
对于这一类有两种防范，一是针对框架核心层进行检测，对Hook进行反制。
二是构造合理的加密壳核心模式，将核心数据局限在加密壳运行库范围内，
使破解者在加密壳运行库范围外拦截不到全部所需的信息。

关于兼容性，主要有两类
1、对未知框架环境的兼容
因为不同框架核心中各个函数的物理地址可能不一样，这就是兼容的最大麻烦，
所以尽可能少的hook框架核心函数能增加对未知框架的兼容性。

2、和其它加密壳并存的兼容性问题
这种情况比较少见，但也是不容忽视的。

如：某.Net中间件厂商使用A加密了其产品，另一家软件公司使用了该中间件，而这家公司又要使用B加密自己的产品。
这时就出现了一个软件环境中出现两种加密壳核心的情况。
不过这种情况基本上可以不用太多顾虑，一般这两家公司之间可以协调解决。

但是另外一种情况就比较难办了：
Web应用在虚拟主机上的问题，如果在同一虚拟主机上部署两种不同加密壳加密的web应用，也同样要面临这个问题。

怎么处理这个问题？
在安全性方面对框架进行检测，反制拦截破解者，这样将对第2个兼容性产生问题。

所以理想的方案是使用第二种构造合理加密壳核心来加强安全性，这样不会对兼容性造成负面影响。
当然，如果你决定不考虑和其它加密壳的兼容性问题也就不用理会这个问题了。

撇开兼容性的第二条，我们来看看第一条。
麻烦的根源是函数地址的未知性，尤其是对于mscorwks.dll中的函数地址，没有任何参考点。
唯一的兼容方法就是模糊搜索，所以尽量减少对mscorwks.dll中的hook能在一定曾度上提高兼容性。

mscorjit.dll中的函数比较容易准确确定，因为它又一个入口函数地址可以直接获取到，
然后顺藤摸瓜就能把下级函数地址获取到，当然这需要一个小型的反汇编引擎。搜索1到3层基本上是没啥问题的了。

结论：mscorwks.dll是双层加密壳兼容性的瓶颈所在。

前面提到对框架进行检测，会影响兼容性，其实，这种方法对安全性的提高并没有多大的实质性帮助。
主要原因，加密壳要考虑兼容性（兼容未知框架）以及程序效率，所以不可能对框架进行全面检测，检测范围有限，同时因为hook方式的多样性，检测成功率也比较低。
对付一些初级用户也许能收到一点效果。

那么怎么办呢？
下回我们将介绍加密壳核心兼容性和安全性共赢的实现模式，纯Jit层核心的实现。