第二题如果说就让人望而却步的话，这道题怕是要让人吐血身亡了。自己写wp感觉也要写得头发掉光，非常慌。不过既然到了最后一题，为了完整性，硬着头皮也得做下来吧，打开程序一开，里面有dll，采用的是mono框架，是不折不扣的.net的程序。我是第一次接触.net，更别说里面的IL code，jit什么的妖魔鬼怪了，反正现学现卖，不过鬼怪见多了也就慢慢习惯它们的样子了，慢慢就适应了，呃。我还是选择的安卓平台的题目，从评分标准来看，这个题目就分为了3小问，所以我把这个题目分为三大部分，一一阐述每个部分。

正如标题所说，三战寻路--寻到一个坑。本来ida里的函数多数都被我标记得差不多了，因为用IDA F9动态调试的缘故，函数名都丢了(这里我曾崩溃)，凑合着看吧，请见谅。
先贴一个main函数：

说一下反调试先，我一共发现两处。init_array段有一处反调是，虽然不知道怎么判断的，反正把exit nop掉就行了。然后在main函数的起始位置起了一个反调试的线程，把启动的内容nop掉就可以了，这样就可以调试了，也就是可以正式开始漫漫长征路。

先分析一下程序的流程，程序开始会释放一个4.5kb的dll，称之为关键dll，然后通过mono框架加载这个dll 以及在外面的mscorlib.dll，调用mono框架中的一系列函数，寻找到指定的类，再找到sayhello函数，最后调用method_runtime_invoke，print出hello 。

先不管那么多，既然它偷偷的加载dll，直接dump出来看看再说。dump出来的dll为非法文件，使用010editor 已经跟踪代码发现几处问题，Patch了5字节，至少成为了一个看起来正常的dll。
问题1.
5字节之第1字节：PE文件的签名，正常的pe文件签名位PE00，而这个文件的签名为PE01，这会导致NT头找不到，无法被正常识别。
原因：通过跟踪代码可以知道，mono框架只检查了PE，没有检查后面的00是否正确。
附上一个pe文件格式链接：
642K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6E0M7$3c8F1i4K6u0W2L8h3W2U0M7X3!0K6L8$3k6@1i4K6u0W2j5$3!0E0i4K6u0r3k6h3&6Q4x3X3c8#2M7#2)9J5c8X3I4A6j5Y4u0S2M7Y4W2Q4x3V1k6%4K9h3&6V1L8%4N6K6i4K6u0r3k6r3g2K6K9%4c8G2M7q4)9J5c8X3#2K6y4U0R3H3y4e0b7%4i4K6t1^5N6W2)9K6c8s2k6K6i4K6u0W2z5o6g2Q4x3U0W2Q4x3X3g2S2M7%4m8^5i4K6t1K6L8%4c8Z5k6i4u0Q4y4h3k6U0L8$3&6@1k6h3&6@1M7#2)9#2k6X3!0X3i4K6g2X3N6r3S2W2i4K6g2X3k6X3W2D9k6b7`.`.

5字节之第2字节：.net程序里面有一项叫做元数据流，附上链接：
8a1K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6h3y4F1j5X3I4G2k6%4y4Q4x3X3g2U0L8$3#2Q4x3V1k6e0K9r3q4k6k6f1u0D9L8$3N6Q4x3V1k6S2M7X3y4Z5K9i4k6W2i4K6u0r3x3U0l9I4x3#2)9J5c8U0l9%4i4K6u0r3x3U0m8Q4x3V1j5K6x3U0l9J5x3e0V1I4i4K6u0W2K9s2c8E0L8l9`.`.
导致dll继续报错的原因是一个#String的堆，未能识别，导致后面一系列失败，将后面的00 patch成 73即可。
原因：找到解析元数据中堆的地方，贴代码如下：

可以看到，"s"字节没有比较，从这里可以看出来这个mono框架被修改过，而且有点猥琐。而在正常的mono框架中，strncmp的是9位，这就是元数据流异常的原因。

5字节之后3字节：
都在解析和装在MetaData的过程中，有3处高位被改了，导致一般的工具报数组越界的错误。
原因：mono框架修改了read函数，在read的时候只取了低位，这样的话不影响它自身对dll的解析。

修复这5字节，大概dll可以算得上“正常”了，至少扔到反编译工具中不出错了。

第一寻
一开始没想太多，想的就是可能在loadtable的时候把IL code还原了，然后追踪了很多遍，并没有发现真正的IL code，这里被坑了。局面开始显得僵化，突然发现这样的一个文章：
edcK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6h3y4F1j5X3I4G2k6%4y4Q4x3X3g2U0L8$3#2Q4x3V1k6F1L8%4u0@1K9s2y4@1j5i4u0D9K9h3N6Z5N6q4)9J5c8X3q4J5j5$3S2A6N6X3g2Q4x3V1j5J5x3o6p5H3i4K6u0r3x3o6N6Q4x3V1j5H3y4q4)9J5c8U0p5%4y4K6p5H3x3U0q4Q4x3X3g2Z5N6r3#2D9
以为是隐藏IL code，加了壳，于是就开始了漫漫长路第二寻

第二寻
既然是壳，总会解密，继续跟就行了，外面既然没修改IL code的话，那肯定在更底层了。为了方便调试跟踪以及分析，我把源码下载下来了，地址在这：
23bK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6E0L8$3&6G2i4K6u0r3L8h3!0F1L8H3`.`.
然后就变成了苦逼的阅读代码，好，突然发现一个函数，mono_jit_compile_method_with_opt，再跟到mono_jit_compile_method_inner，再跟到mini_method_compile，再跟到mono_runtime_invoke，sayhello都已经执行了，我并没有定位到恢复的IL code，又过了不久，开始第三寻。

第三寻
直接定位mono_method_to_ir，这是最底层解析IL opcode的函数了，我在这下断点跟踪，总能搞定吧。这个函数也是够大，20000行，摘出来，一点一点看，一直跟不到修改IL code 的地方，最后发现，这个函数出题方居然动了，居然用自己的一套来解析Opcode，难怪dll中的IL code乱七八糟也能被执行，终于找到原因了，剩下的就是人肉还原IL code了。

先贴一张Opcode 对应表:

还原好之后效果（贴一个最大的函数）：

算法是XTEA的变种，链接这里：
da4K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6W2L8W2)9J5k6i4N6A6K9$3W2H3k6h3c8A6j5g2)9J5k6h3!0J5k6#2)9J5c8Y4N6A6K9$3W2Q4x3V1k6j5g2p5g2m8

说实话，我这方法有点麻烦，你们出题有点猥琐。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课