mscorwks.dll在.Net中的地位连同在.Net代码保护…

2008-02-23 05:40:50来源:互联网 阅读 ()

新老客户大回馈,云服务器低至5折

  mscorwks.dll是dotNet的核心文档,尤其是在net2.0中,以前分散的功能都集中到了这个dll中。
  net1.1中,更有一个文档mscorsvr.dll 和 mscorwks.dll 是同等地位的。
他们分别对应于 windows service程式连同 desktop 程式。
  在net2.0中,他们都统一到了 mscorwks。dll中。
  同时在net2.0中mscorsn.dll 的功能也合并到了 mscorwks.dll中。
  他就是dotnet运行库的核心。
  DotNet的执行引擎(ee),内部对象的实现都在这个dll里面。

  在我们用reflector查看dotnet类库源代码时经常会碰到一些函数看不到源代码,只是标记成内部实现。这些函数基本上实际实现的代码就在这个dll里面,是native实现的。如反射功能的相关对象连同实现就是这里面。

  net程式的执行主要由他来完成,更有另外一个重要的文档mscorjit.dll 被他所调用。
现在我们把 mscorwks.dll 分成两个区 A 和 B,
A 是主要执行引擎(ee)和native 实现。
B 是ee调用jit的处理部分。

  net2.0的反射功能是在A区实现的。加密壳假如要实现完美的兼容性(即不破坏DotNet本身的任何功能和特性)就应该在 A 区挂入其内核。
在A区有一个函数实现获取方法体的内容,ee层需要取得方法体内容是通过这个函数来获得的。因此完美的方法就是 替换这个函数,用加密壳的内核实现这个函数。

  这样的最大缺点就是反射漏洞,因为反射也是调用这个函数取得方法体的。

  在这个基础上要要破坏反射有什么办法呢?
  在反射是需要调用Method的成员函数GetMethodBody,这个函数是native实现的,就在mscorwks。dll中,因此加密壳能够hook这个函数做一些预防处理。
但是效果不理想,破解者能够恢复这个函数的原始实现。

  更有一个方法,不是完美,但是有效,即不直接替换获取方法体的函数,
而是只替换编译前获取方法体的地方。这样只在要编译方法时才提供内核解密服务。

  效果如何?也不太理想,破解这能够修改反射的实现函数,直接jmp到加密壳的内核服务。

  这种方式就是DNGuard v1.0采用的方法,似乎也是某壳现在版本的方法。
当然,DNGuard 1.0还简单的加入了放内存修改,但是这个效果也能太乐观,破解者也能够把这部分屏蔽掉。
因为反射在A区实现,假如壳的内核也挂接A区,反射就比较容易修复。

  在我做DNGuard 2.0之前,我曾想过一种方法,能使反射无效,甚至难于修复。
  即同时在内核挂接在 A 区,和 B区。
  先来介绍一下一个函数要被执行是是怎么个流程。
  首先,EE会检查函数是否编译?编译了就直接调用了。没有编译就进行编译。由一个prestub实现。
  然后EE取得方法体,对方法头和SEH TAble进行简单解析,转换成结构。
(这些在A区完成),进入B区调用Jit进行编译。

  在A区ee只关系方法头和sehtable,而B区调用jit时 il字节码才有实际意义。
所以能够将内核分别挂接这两个区,A区中只提供header和seh,B区中提供il字节码。

  但是在我开始做DNGuard v2.0后就放弃了这个想法,因为这样还是不安全。
参考这里:深入Jit,实现dotNet代码的加解密

不管内核是在A区还是B区,假如一个加密壳的内核只限于在mscorwks.dll进行挂接实现。那么都无法脱逃 jit层脱壳机的脱壳。我在写文章“深入Jit,实现dotNet代码的加解密 ”时已进行过测试了。




标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇: 泛型:volatile——多线程程式员最好的朋友volatile修正符及让

下一篇: C 基本数据类型和输入输出

热门词条
热门标签