.Net加密壳的运行库加载方式目前主要分两种。
用得比较多的一种是
向程序集中注入Loader代码,然后给程序集中的每个类型添加静态构造函数。在静态构造函数中调用Loader代码。
目前的加密壳大部分都是这种模式。这种模式,利用了静态构造函数的特性。
应该注意到静态构造函数和Loader代码执行时 运行库是还没有加载的,所以这部分代码是却对不能加密的。
程序集执行起来后,运行库才会被载入。
另外一种,是直接利用windows pe加载器来自动加载加密壳的运行库。
这个熟悉win32的,应该知道修改导入表插入dll方法,这个基本上也就是这个原理。
.Net程序集至少都会有一条导入记录
exe的是 mscoree.dll _CorExeMain
dll的是 mscoree.dll _CorDllMain
可以在运行库中导入这样两个函数,然后直接修改程序集的导入记录。
remotesoft 的 新版 protector好像就是这么做的,它以前的版本也是用的第一种方式。
remtesoft protector 也是属于jit层的加密壳,原理几乎和 CliProtector 一样,
也存在Jit层的漏洞。
这个方式的优点就是程序集加载时,运行库就加载进去了。所以程序集的所有方法都可以加密。
当然这种方法的实现并不像说的这么简单,启动时的运行库安装问题。
需要在框架dll加载的第一时间,安装运行库,
比较保险的方案是在dll的load里面就hook loadlibrary相关函数。
这种方式有一点不好
就是无法实现32位,64位运行库的自适应,需要部署时就明确。虽然在xp以上的系统上可以通过manifest来做,但老的系统就不行了。
所以我在最新的 DNGuard HVM 2.8 中依然采用了第一种方式。
再说说第一种方式,.Net 的静态构造函数中有一个特许的,就是全局静态构造函数(模块静态构造函数)。
这个正常开发使用 C#,VB.Net是做不出来的,用IL或者C++/CLI可以做出来。
这个静态函数是在模块第一次被访问事触发的。
所以有了它可以不用再给所有类型添加静态构造函数了。
兼容性怎么样就不知道了。会不会有例外情况?
用得比较多的一种是
向程序集中注入Loader代码,然后给程序集中的每个类型添加静态构造函数。在静态构造函数中调用Loader代码。
目前的加密壳大部分都是这种模式。这种模式,利用了静态构造函数的特性。
应该注意到静态构造函数和Loader代码执行时 运行库是还没有加载的,所以这部分代码是却对不能加密的。
程序集执行起来后,运行库才会被载入。
另外一种,是直接利用windows pe加载器来自动加载加密壳的运行库。
这个熟悉win32的,应该知道修改导入表插入dll方法,这个基本上也就是这个原理。
.Net程序集至少都会有一条导入记录
exe的是 mscoree.dll _CorExeMain
dll的是 mscoree.dll _CorDllMain
可以在运行库中导入这样两个函数,然后直接修改程序集的导入记录。
remotesoft 的 新版 protector好像就是这么做的,它以前的版本也是用的第一种方式。
remtesoft protector 也是属于jit层的加密壳,原理几乎和 CliProtector 一样,
也存在Jit层的漏洞。
这个方式的优点就是程序集加载时,运行库就加载进去了。所以程序集的所有方法都可以加密。
当然这种方法的实现并不像说的这么简单,启动时的运行库安装问题。
需要在框架dll加载的第一时间,安装运行库,
比较保险的方案是在dll的load里面就hook loadlibrary相关函数。
这种方式有一点不好
就是无法实现32位,64位运行库的自适应,需要部署时就明确。虽然在xp以上的系统上可以通过manifest来做,但老的系统就不行了。
所以我在最新的 DNGuard HVM 2.8 中依然采用了第一种方式。
再说说第一种方式,.Net 的静态构造函数中有一个特许的,就是全局静态构造函数(模块静态构造函数)。
这个正常开发使用 C#,VB.Net是做不出来的,用IL或者C++/CLI可以做出来。
这个静态函数是在模块第一次被访问事触发的。
所以有了它可以不用再给所有类型添加静态构造函数了。
兼容性怎么样就不知道了。会不会有例外情况?