申请会员ID：dengxiboy

Hmily，刚才那篇好像一不小心把会员ID填成了QQ好了。非常不好意思，重新发一下申请，谢谢。

1、申 请 I D：dengxiboy
2、个人邮箱：6458450@qq.com
3、原创技术文章：地址是http://www.cnblogs.com/dengxi/p/5750170.html，现有二千多浏览量。

.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值再存于非托管代码中再生成，放于安装包中，步骤略显复杂，但是为了安全，这个应该可以接受吧。

Hmily

总结挺好，但暂时没有达到申请要求，请继续提供一些实际的技术文章，比如详细分析一款net加密壳脱壳去混淆的方法。