利用Mono.Cecil的Bug来Anti .NET Decompiler by Wwh / NCK
本帖最后由 wwh1004 于 2018-8-6 17:19 编辑原理与实践篇： https://www.52pojie.cn/thread-778602-1-1.html
据我分析，.NET内部加载未压缩的元数据表流的流程应该是这样：
代码我自己写的，意思是：
遍历所有流头，记录下第一次出现的CLR需要的表流和堆。
static/image/hrline/4.gifstatic/image/hrline/4.gif
为什么这么说呢，我们用dnSpy看看这个UnpackMe（文件名是UnpackMe，程序集名称是CrackMe，emmmm）
https://forum.tuts4you.com/topic/38164-ben-mhenni-protector-v50-moded/
没tuts4you账号的点下方
链接: https://pan.baidu.com/s/1yQWAJsAXay_Bo6IbndCHhg 密码: 2bd5这个UnpackMe启动极慢，最少要十几秒，混淆极端严重（主要是无效元数据导致的）
第一步先用各种Dump工具把.NET程序集Dump出来，不懂的可以看我以前发的教程 https://www.52pojie.cn/thread-762832-1-1.html
dnSpy将无效元数据流标记红色，有效为橙色
WTF？为什么dnSpy认为第二次出现的#US #Strings是有效的呢？
仔细查看第一次出现的#US，#Strings，其实可以发现这个不是真正的#US，#Strings
#Strings堆也是一样的，名字都是多了一个空格，即"#Strings "，从这里可以看出CLR是识别空格的
接下来我们看看真正的#Strings，和真#Strings之后的那些#Strings
可以看到，被识别到的真#Strings和之后的混淆选项的名字一样，都是"#Strings"
这样可以运行吗？答案是可以的，可以自行测试。
我们再来看看dnlib的代码是怎么写的
可以看到和我们分析的是一致的。
BUT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Mono.Cecil是这么写的，Mono.Cecil并不能识别未压缩的元数据
这是什么意思呢？
选择出最后一个CLR所需的表流和堆来使用
那就会出现什么问题呢？
如果用ILSpy .NET Reflector JustDecompiler等使用Mono.Cecil作为元数据解析类库的反编译器完全无法获得正确表流和堆
比如这样：
当然，0xd4d大神的使用dnlib的dnSpy和JB的dotPeek完全不受影响，因为这些工具正确识别了CLR认为有效的表流和堆 估计这种帖子有兴趣的人不多，看懂的人今后可能都会加上这个anti吧！ 纯小白直接看蒙了 厉害，有机会学习下。。 小白看得头晕 收藏学习 谢谢@Thanks！
页:
[1]