夏天来了，许久听不到蝉鸣，生活只剩下工作了，再这么下去感觉就要完蛋了。

Android Java层的混淆在一些风控安全类SDK比较常见，严格来说，一般对Java层逆向得到的代码都失去了原先的语义了，如命名为abc，这也属于混淆了。这个就不展开讨论了，但是这涉及一个重要的方法，静态分析非常依赖该方法，不少人都已经有用到了。IDA针对汇编的静态分析同样如此，常见的例如定义结构体。

ollvm混淆和Java层有一些不同，如F5之后默认都是混淆了符号的，ollvm打乱了原先的代码编写顺序，或者增加了一些虚假的代码块。下面我们来探讨一些IDA分析的问题，以及如何在ollvm混淆的情况下分析代码，这不是处理ollvm混淆高效的方法，这是为了保证至少能够手动处理ollvm混淆。就如处理花指令一样，很多手动处理一下就行了。简单来说，既然它都混淆了，就按它现在的样子来处理吧。

IDA静态分析的重心

不少人谈到F5之后的伪代码都不怎么重视，认为简单参考就行。我以前试过不使用F5（因为确实不怎么准确）根据汇编指令手动还原一个简单的HEX算法，首先就是符号标记的问题，对于某个变量很容易就跟丢了，如果有多条件嵌套的会更痛苦；对比下来，F5就是最优的选择，但是也要清楚它是不正确的，有些时候还得必须去对着汇编进行还原才行。现在我会以F5后的代码为核心，它不需要完全准确，只需要不脱离对应函数的意思就足够了，而且我认为整个静态分析都应该以F5为重心。
第二就是汇编，如果F5不正确，就要回去分析汇编了。汇编指令比较原子化，这就为什么用F5，但终究还是要会分析汇编才行。我想这得会一目十行，也不是真的十行，只是汇编上往往需要好几个指令来对应一般编程语言的最简单的操作。
之所以说把重心放到F5上，那是为了标准化IDA静态分析，IDA的静态分析方法和技巧很多，如果我们把所有这些处理的目的就是为了得到更加准确的F5，那么我们就知道自己的静态分析的方向是什么了。例如花指令，如call analysis failed等，不过即使没有这些问题，按下F5也是不能解决问题的，还得继续进行处理，不得不说，这个工作比一般java的繁杂很多。

搭建IDA动态调试

具体步骤就不说了，可以参考这篇文章：https://bbs.kanxue.com/thread-259633.htm。
其中我想说的是IDA动态调试so的一些问题，首先是版本的问题，IDA版本<=7.0我试过无法在Android 10上调试，例如会出现jdb无法附加到目标VM。针对这个问题，建议使用高版本的IDA或者低版本的Android（后面这种没试过）。
我目前用的IDA 8.3会出现F5卡死，但是用低版本IDA F5又没问题，完蛋，目前不知道怎么解决，有遇到的朋友可以说下。

IDA动态调试如何下断点？

对于这个，我之前还花了几天研究，在我遇到的情况中，在原so位置下断点不一定有效。另外怎么更轻便处理断点也是个问题，有的时候既要patch、又要更改寄存器的值，加的断点多了——因为需要不断重复启动调试，F9按多了也是个痛苦的体力活，当然也需要配合python脚本进行处理，不过这个先不多说了。
在目前的样本中，需要给.init下断点，需要分析的函数就是init_proc。

分析so文件的ollvm混淆

首先启动IDA调试，一直按F9进入init函数中，该函数看起来是这样的：

这种嵌套的while循环就是ollvm混淆后的效果，但是在这之前，我先明确一个关键点。

对ollvm混淆的整体阅读

假设有一个C函数func，ollvm混淆是将func按顺序切分成n个块，然后打乱n个块的编写顺序，使用一个动态的整数标记（如上截图的v0）来调节乱序的块的执行顺序，也就是说这个整数标记使得func的乱序版本的执行顺序和原func的执行顺序是一样的。
例如上面的v0初始值是0xA0BA64CE，当进入while循环后，它一般就会到达v0==0xA0BA64CE的地方进行处理（一个块），处理完成后再更改v0的值（下一个块的标记），直至函数执行完毕，当然也会有一些变化，但是大体就是这样。
如果我们手动把这些块连起来，那就还原了该函数了。对于这个整数标记，简单的情形也可以静态分析的，但是如果while循环比较多，那就比较麻烦了，所以这里为什么使用IDA动态调试，其中一个作用就是真实的执行能直接知道具体的代码块的顺序。当然，这其实还是因为IDA F5预览不够完善，如果它能够近似一个编辑器就好了，例如VSCode，如能查找折叠等。
如上面的v0到v0 > (int)0xB945DFF9这个判断就头痛了，后面的else-if和else在哪里？如果有代码折叠，那就清晰方便很多。

手动还原每个代码块

当v0==0xA0BA64CE，执行的第一个代码块是：

StatusReg一般不需要分析，这不会影响当前函数的的主要逻辑。但是按X发现，v5在后面会使用到——可以判断它是一个函数栈内的变量。在IDA F5中，一个栈内的变量可能会直接被声明，甚至不赋值，如果是结构体可能会分散声明或赋值，这时就需要看汇编手动处理了。
v5后面是这样使用的：

那么我们可以判断v5是一个数组，char*类型的字节数组，用于保存一个字符串。
现在我们可以先命名一下v0为tick，然后将第一个代码块的代码复制到一个文本或编辑器中，最后再该代码旁边添加一个注释：tick 1
v5 = &StatusReg + -0xFA;
接下来按F8跟踪每一个代码就行，那么下一个是：

其中一个块出现了反调试，那就得先nop掉这行再进行调试。简单处理后的伪代码如下，其中右侧注解标记了代码块的执行顺序：

这里就不分析函数的具体作用了，就是跟踪标记一下代码块的序号，不算难。其实这里面有一些反调试的，目前忙，时间原因也不处理了。按照标记好的序号，将对应的代码块拼接起来就约等于原来的代码了。
不过，和阅读分析汇编代码一样，由于ollvm混淆比较常见，个人的目的主要是理清楚ollvm混淆后的代码和原代码的区别，这样我们看这种混淆代码的时候也能够一目十行，大概知道它的执行逻辑。
本来想把这部分写得更详细的，暂时没时间了，就先这样先。

总结

这严格来说都不算一个方法，甚至比较耗时，如果可以建议还是直接反混淆处理。但是熟悉它的结构可以让我们马上可以找到真实代码块，掌握整体的函数的逻辑，甚至不用反混淆就可以分析算法了，如果是还原算法，也不影响。至于F5恒常会出错的那一部分——即使完美反混淆也没用，那这部分我们还得自己阅读分析汇编进行处理。毕竟，要时刻记住，即使没有混淆，F5出错的概率也是恒常存在的。

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