[.NET]利用Mono.Cecil的Bug来Anti .NET Decompiler

wwh1004

不知道有人看得懂么，我就简单的说一说吧

据我分析，.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出来，不懂的可以看我以前在52pojie发的教程
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认为有效的表流和堆

不破不立

学习了，谢谢楼主分享经验，楼主有没有编译好的dnspy和dnlib提供？