在 per method 的dotNet加密中，首要解决的方法体对应关系，即在运行时加密壳如何确定当前要解密的方法体所对应的加密信息。
目前大部分加密壳都直接利用了dotNet的元数据来保存这种对应关系，我们知道在元数据中每个方法都会对应一个RVA值，加密壳可以直接把这个关系记录在RVA的地址处。在框架运行中RVA处的数据会被作为“方法体”在处理流程中直接传递，加密壳通过拦截框架处理流程中的函数，来对“方法体”进行分流处理。即先判断RVA处的数据是否“方法体加密对应信息”，如果是进入加密壳运行库的内部处理，不是则按原框架流程处理。
对于这个“方法体加密对应信息”，最简单的方式是指记录一个指针信息，指向另一处数据块，四字节空间就够了。但是为了和普通没有加密的方法体进行区分，除了这个之外还需要增加一些唯一标识以便能被运行库在运行时安全无误的区分出来。
大家可以用UE打开，加密后的程序集，看看一个方法体RVA处的数据，应该能很容易分别出来哪些是记录的“方法体加密对应信息”。
正是这个原因，所以DNGuard v1.0和同类处理方式的加密壳，对方法体小于某个指定字节数的，就不能进行加密。
因为“方法体加密对应信息”的大小超过的方法体的空间大小，写入的话会覆盖到后面方法体的信息。这实际上也是因为偷懒造成的。可以通过对方法体进行重排来解决这个问题，当然要麻烦很多了。
这种模式实际上就是在元数据保存了一个虚拟表实现了 MethodToken => “方法体加密对应信息” 的对应记录。这个表可以看着是公开的。
在DNGuard 2007 中我没有选择使用对方法体重排的方式来解决这个问题，而是选择了另一个方法，自己记录一个 虚拟表实现：MethodToken => “方法体加密对应信息” 的对应记录。
因为这样有一个好处，就是 这个虚拟表也可以进行加密后保存。另外就是“方法体加密对应信息”中不需要添加标识符 和普通没有加密的方法体进行区分。
在 DNGuard 2007 试用版 中没有使用真正的加密算法来对程序集加密，只是采用了“代码直接挪位”的方式，运行库的“解密”操作只是从另一个位置直接读取的操作。
有个朋友分析到DNGuard 试用版里面有一个虚拟表记录了：MethodRid => ILCode。这个就是 虚拟表：MethodToken => “方法体加密对应信息” 在 试用版中退化的模式。
另外因为方法体只是挪位，所以它实际上还是在程序集文件内，加载到内存中后也在程序集模块的内存空间中。而不是那位朋友说的 运行库在解密后将 IL代码 填回到内存里面去了。
试用版只是提供给用户验证 DNGuard 是否适合自己的软件项目以及系统发布环境，请不要用试用版 加密程序集后直接分发。
共有条评论 网友评论