利用Mono.Cecil的Bug来Anti .NET Decompiler by Wwh / NCK

wwh1004

原理与实践篇： https://www.52pojie.cn/thread-778602-1-1.html

据我分析，.NET内部加载未压缩的元数据表流的流程应该是这样：

代码我自己写的，意思是：
遍历所有流头，记录下第一次出现的CLR需要的表流和堆。



为什么这么说呢，我们用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吧！

cyhcuichao

纯小白直接看蒙了

sajuuk1129

厉害，有机会学习下。。

昊昊哥

小白看得头晕

czyjcx

收藏学习

MR.Jee

谢谢@Thanks！