目前大部分加密壳都直接利用了dotNet的元数据来保存这种对应关系，我们知道在元数据中每个方法都会对应一个RVA值，加密壳可以直接把这个关系记录在RVA的地址处。在框架运行中RVA处的数据会被作为“方法体”在处理流程中直接传递，加密壳通过拦截框架处理流程中的函数，来对“方法体”进行分流处理。即先判断RVA处的数据是否“方法体加密对应信息”，如果是进入加密壳运行库的内部处理，不是则按原框架流程处理。
对于这个“方法体加密对应信息”，最简单的方式是指记录一个指针信息，指向另一处数据块，四字节空间就够了。但是为了和普通没有加密的方法体进行区分，除了这个之外还需要增加一些唯一标识以便能被运行库在运行时安全无误的区分出来。
大家可以用UE打开，加密后的程序集，看看一个方法体RVA处的数据，应该能很容易分别出来哪些是记录的“方法体加密对应信息”。
正是这个原因，所以DNGuard v1.0和同类处理方式的加密壳，对方法体小于某个指定字节数的，就不能进行加密。
因为“方法体加密对应信息”的大小超过的方法体的空间大小，写入的话会覆盖到后面方法体的信息。这实际上也是因为偷懒造成的。可以通过对方法体进行重排来解决这个问题，当然要麻烦很多了。
这种模式实际上就是在元数据保存了一个虚拟表实现了 MethodToken => “方法体加密对应信息” 的对应记录。这个表可以看着是公开的。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
