谈antiILdasm的原理以及anit框架API的可行性

今天收到 maxtocode 的群发邮件&＃xff0c;提到对MaxToCode运行库兼容性进行了修正&＃xff0c;即降低了运行库anti的强度。
确实在兼容性和安全方面很难做到鱼与熊掌兼得。anti得太多&＃xff0c;程序的兼容性就成问题。codelib就是例子&＃xff0c;可用性太差。

在maxtocode的邮件中仍然发现了如下两条描叙:
* 增加了对ILdasm以及使用API 访问源数据的反编译工具的反制功能
* 经测试,目前没有一种反编译工具可以完整的读取加密后的结构,更不用说加密后的代码了

其对该功能的描叙为&＃xff1a;
*可以使微软提供的底层反编译器(ILdasm 2.0)无法工作。
*可以使引用框架API的反编译器无法工作
*但无法禁止反射的反编译程序。

其实anti ildasm这个功能最早是在 xenocode中发现的&＃xff0c;当时是anti ildasm 1.1&＃xff0c;这个东西应该算是Undocument的。
不过到了 net 2.0我们在 msdn文档中发现了&＃xff1a;
“注意&＃xff1a;此类在 .NET Framework 2.0 版中是新增的。
防止 MSIL 反汇编程序 (Ildasm.exe) 反汇编程序集。无法继承此类。
将 SuppressIldasmAttribute 属性应用于程序集或模块可防止使用 MSIL 反汇编程序 (Ildasm.exe) 反汇编程序集或模块。
此属性不防止使用反射查看程序集。
注意&＃xff0c;SuppressIldasmAttribute 属性不阻止 MSIL 反汇编程序 (Ildasm.exe) 查看标头信息和元信息。 ”

anti ildasm的原理其实很简单maxtocode作者在分析xenocode时就介绍过了&＃xff0c;基于一个“君子协定”&＃xff0c;即ildasm会检查一个标记&＃xff0c;如果发现了这个标记就会说是受保护的模块&＃xff0c;不能编译。

谈谈ILDasm的功能限制与解除

By aiasted
From http://www.cnblogs.com/aiasted/archive/2005/05/05/149639.html
OK&＃xff0c;分析一下吧&＃xff1a;经过短暂的分析&＃xff0c;让我出了一身汗。。。这样的版权保护有还不如无&＃xff0c;一定误导了很多朋友。
这已经很明显了,ILDasm只用了一个标志去阻止"已有版权"的程序集,而您只需要修改一个机器指令就可以畅通无阻的反编译任何程序集,并修改其内容再次编译。

只是1.1时代这个标记是Undocument的&＃xff0c;在2.0里面已经是document的了。可以肯定maxtocode能如其介绍的那样anti ildasm 2.0。
根据这个原理&＃xff0c;我们只要patch ildasm修改其中的一个跳转就能让它继续工作了。实际上已经有人完成了这些工作。

ildasm是使用 框架 API的反编译工具。那么anti了ildasm 是否就等于 anti 了 框架 api&＃xff1f;
我们只需要修改ildasm不让他判断那个标记&＃xff0c;他就能正常工作了&＃xff0c;显然框架 api仍然可以正常使用。
而第三方使用框架api的反编译工具是不会去判断那个标记的&＃xff0c;也就是说它们不需要被patch就可以正常工作。

那么 anit 框架API 是否可行&＃xff1f;
不过这个基本是不现实的&＃xff0c;除非自己实现.Net的执行引擎或者今后.Net执行引擎有什么变化。
为什么呢&＃xff1f;因为目前.Net的执行引擎也是使用的 框架 api。如果真的anti 了框架api&＃xff0c;那么.Net执行引擎也不能幸免。

很显然目前来说框架api成了一个绿色通道&＃xff0c;使用框架api的反编译工具是能够看到程序的完整结构的。如 修改版的ildasm&＃xff0c;dis#等。


刚才又上maxtocode官方网站看了网页上仍然有这些信息。
如果说之前是无意误导&＃xff0c;那么现在是不是故意误导呢&＃xff1f;