.NET DLL 保护措施详解(非混淆加密加壳)

为什么要保护DLL,我就不多说了,各人有各人的理由。总的来说,就是不想核心逻辑泄露及授权验证被破解两大方面的因素。

 

首先,我来介绍一下发布出去的DLL所面临的风险:

一、直接引用

二、反编译

三、反射

如果DLL一点措施都不做的话,上面任意一种都可以达到破解目的的。

 

然后,通常网上能搜到如下的保护方式,但真心的来说,用处不大,当然对小白破解者增加了难度。

一、混淆类的工具(如Dotfuscator,但是可以通过ILSpy、Reflector等反编译哦,直接COPY代码也能运行)

二、加密类的工具(如MaxToCode,网上有相应的破解教程)

三、加壳类的工具(如Sixxpack,网上有相应的破解教程)

四、强签名(签名只是防止项目中的某一个DLL被篡改了,不能防止反编译或反射的哦)

 

说了那么多,难道没有相对靠谱的方式了吗?

最后,我们进入正题

上面那些工具的目的归结出来大约完成两个目的,一是不能看,二是不能调,当然,我们也是实现这两个目的,只是手段不同。

一、不能看:.NET DLL可以包含托管堆代码(可以被反编译的)与非托管堆代码(不能被反编译,要反编译也是更高层次的了,不在讨范围内),我们将核心逻辑代码置于非托堆代码中,由托管堆代码提供接口供外部调用,调用时将非托管代码通过.NET动态编译特性编译后返回执行结果。这样就保证了不能看。

二、不能调:我们在非托管代码中加入验证调用者来源功能,判断调用者的HASH值是不是与在非托管代码中约定的HASH值(发布时需要提前生成相关引用者的HASH值存于非托管代码,最后生成非托管代码的DLL放于安装包中)一致,如一致则通过执行返回结果,不一致则返回空。这样就解决了非合法来源不能调的问题。

 

注:由此带来的问题

一、性能问题:每次调用都动态编译肯定会影响性能,但是我们可以通过缓存来解决这个问题,第一次调用时就将编译后的对象存于缓存中。

二、平台问题:非托管代码不能生成ANYCPU类型的DLL,所以需要发布时指定两个版本(X86/64)生成相应的版本的DLL,由安装包判断目标平台属性,然后输出对应的DLL。

三、发布问题:每次发布时需要先生成相应项目依赖者的HASH值再存于非托管代码中再生成,放于安装包中,步骤略显复杂,但是为了安全,这个应该可以接受吧。

 

----------------------------------------------------------------------------

转自:http://www.cnblogs.com/dengxi/p/5750170.html

你可能感兴趣的:(Winform开发技术)