.Net加密壳认识的一个误区

自从.Net 2.0的新特性被公开用来获取IL代码后，加密壳就成了鸡肋。
就如tankaiha所说“.net下逆向暂时没啥新东西可搞，某软件的版本升级是一次不如一次强”，由于先天不足，这成了加密壳强度的一个瓶颈。

但是还有相当一部分人认为1.1的程序集加密后是安全的。
其实不然，绝大部分1.1的程序集加密后也能用发射的方式进行脱壳。
（注：这里的脱壳仅指加密保护壳，混淆是无法还原的，如某软件现在同时提供了加密和混淆功能，脱壳仅能脱除加密保护部分）

.Net 1.1没有 2.0中有的新特性，怎么能用反射脱壳呢？原因很简单，因为大部分1.1的程序集能在 2.0的框架中运行。
如加密的 dll，我们可以用2.0写一个程序集来load它。我们就有了2.0的运行环境了。
那加密的 exe 呢，也好对付，微软允许用户通过修改程序配置来强制指定一个程序运行的 .net framework版本。
假设 a.exe 是被加密的1.1程序集。
我们只要建一个文件 a.exe.config 和它放在一起，文件内容如下：

<configuration>
 <startup>
 <supportedRuntime version="v2.0.50727"/>
 <requiredRuntime version="v2.0.50727" safemode="false"/>
</startup>
</configuration>

这样你再次运行a.exe时，系统就会自动启用 .Net 2.0 framework 作为运行环境。

如果说只能一个一个函数的获取IL代码，那么加密保护还有一定的利用价值。
然而反射脱壳已经有了成品脱机了，这就使加密保护彻底成了鸡肋。

对于反射，加密壳还是有一定作为空间的，但是作用很有限，治标不治本。
那就是破坏反射，让反射无法正常工作。
即通过破坏反射正常运行的系统地层代码或代码路径达到破坏反射的目的。
只要修复反射，就可以继续使用脱机脱壳。

这就将战场转移到了传统的Win32层面。
然而受限于.Net内核框架，破坏总是有限的，熟悉一点汇编，了解一些.Net底层机制，要修复是很比较容易的事情。

当然要修复总得需要先找一个sample来分析才行，如果没有sample神仙也没有办法。
这就有了某壳新版不再发布试用版本的事情出现。
这对于安全有那么一点点作用，即不至于新版一发布别人就找到的patch修复的办法。
但是只要有一个加密保护的程序发布，那就有了可分析的sample了，结果可想而知了。

单纯的加密壳强度已经得不到保障了，当然多一层保护总是好的。在众多的保护方式里，加密反而成了最脆弱的环节。