Android安全-记一次对vm保护的算法的快速定位

在找sgmain相关资料时看到了这个贴子：
https://bbs.pediy.com/thread-267741.htm
之后对大佬使用的trace工具很感兴趣，对反编译引擎也很感兴趣，不过底蕴不够，反编译引擎之类的也就将就用第三方，只能常试用frida的Stalker改了个类似的trace工具试了下效果也就有了这篇文章
用到的工具：ida/Ghidra/frida
看的是手淘6.5.82版本的sgmain，因为本身只是对trace工具的一次验证，所以不包含实际的算法分析过程，只谈测试过程中的感受
快速定位主要依赖的是Stalker，ida和Ghidra主要是用于静态分析
在静态分析上，我这种小菜鸡就不讨论两个反编译引擎的本质哪个优劣，就谈使用的感受。
先上对比，对于sgmain的doCommand方法
ida的效果：

ghidra的效果:

源码大概是这样子的：

可以很明显看出ida对除法的优化更好一些，ghidra在除法这块就没有ida好，但是我个人更喜欢Ghidra的效果
这里说句题外话，关于除法，编译器对一个整数进行除法运算时往往会转换成乘一个魔数然后除2的多少次方这种，这个推导过程很复杂，本质上就是把除任意整数变成除2的N次方的数，但过程中存在很多边界问题导致比较复杂，不过如果当ida之类的返编译器在复杂需要手动推导时，网上有种方法可以算出大概的值，不过涉及到符号问题及取模问题，记得好像是有Sub类指令参与的可能就是取模，但没有细究，有兴趣的可以自己编译后对比看看。
一般像这种同时存在
乘法、位移0x3F/0x1f取符号位、ASR之类指令时，基本八九不离十就可能是除法

如上面的这种代码，就可以尝试用(1 << XX) / (magicNum - 1)这种方式来算出大概的除数，比如就上面的指令来说：

而且在patch后的及时效果上面感觉更好一些，特别是那些br reg,adrp ret之类的跳转识别效果会比ida好，用ida的时候那个JMPOUT很尴尬，即使你使用跳转patch了也不一定能有效f5，可能还得去除中间的一些混淆的乱码才可以
其次Ghidra也存在一个比较尴尬的问题，就像上面这个代码里面框起来的代码，那个0x2bb3c这个函数（ghidra会自动添加基址，默认是0x100000），在初次打开时，这个函数被识别为了空函数，而且无反回，这也就直接导致下面的那个0xe78c0所在的代码块被直接隐藏了，因为lStack76 != 0被直接视为了不可达分支，修改函数定义后代码也就立刻重新生成了上面的这个效果，修改是及时生效的，效果不错。
现在的一些间接跳转的混淆，不管他怎么变形，实际上很多时候都是常量表达式，而对于常量表达式的这种间接跳有很多种方式处理
比如0x2bb3c头部的这段代码：

代码看起来有点复杂，各种运算，还有间接地址访问，而且每个函数头部都有这种间接跳，且貌似每个表达式都不一样，但实际上这种处理起来也相当简单，分静态和动态两种情况。
动态的情况不用说，单步或trace来获取对应的跳转地址即可，对于Ghidra，也不需要特别处理，它会自动帮你把这些常量表达式计算出来，在进行反编译时会自动使用它计算出的结果进行代入。
比如下面的是Ghidra的汇编显示：

而如果你要说就用ida，不开启动态调试的情况下也简单，用ida的脚本使用unicorn进行模拟执行一下结果就跑出来了：

对于那种代码之间被各种跳转包围的间接跳，例如:
ida中那种函数中间的间接跳

ghidra函数中部的间接跳：

处理方式其实差不多，不管是ida还是Ghidra它们即便是能算出来跳转地址，也会给你提示，比如上面的ida就提示地址是loc_2BD68，但是他们为了确宝流程尽可能准确，所以一般不会在返汇编窗口中进行常量化，这时候就需要进行手动patch。
如果是硬是要ida配合Unicorn，这时候也不是不可以，但是因为部分常量在其它代码块中，再加上里面经常混杂一些地址中常量的访问，在通用性上面可能会不太好，所以这种时候一般建议是用trace的数据，或依赖现有工具返汇编引擎的结果来参考进行Patch。
比如，在Ghidra中与上面的类似的代码块在反汇编引擎中一般会给你提示出来：

在汇编页面就是如下的这种：

常见的混淆基本都是差不多的处理方式，再复杂的基本也离不开Trace了。

Stalker与ida的trace各有优缺点吧，ida的trace是依托于调试器的，所以调试器有的缺点他都有,一般配合DBG_Hooks脚本处理效果更好，我一般喜欢在定位范围缩小到一定程度后才会用它，再则是用它来追踪程序的退出流程返向推检测的代码，不过这里主要说Stalker使用的问题就不聊它了。
Stalker很早之前就存在了，不过貌似这个东西在arm64之后才用的比较多一些，在arm32里面需要处理跳转地址的问题，而我实际使用过程中发现，如果开启了call事件，基本必崩，所以所有事件都是false的情况下做的处理，简而言之就是只用了transform回调。
在使用过程中发现几点问题：
1.Stalker的模式给我的感觉是将每一个以b/ret之类的流程跳转指令作为块的分离点来处理的，transform入口处iterator.next()返回的是块的地址，所以在这里直接使用某一地址来判断是否为Trace跟踪的代码区间可能会存在问题，比如，我在尝试任意指令hook时不遍历整个iterator块而用addr.compare == 0作为判断就会永远无法到达，因为transform每次来时iterator.next()返回的只会是代码块的首地址
2.由于前面的原因，所以iterator.putCallout中的指令是没有b/ret之类跳转指令的，在arm32里面常见的adrp pc, #imm这类指令在这里没有看到，所以暂时不清楚这种情况会不会有其它变化。
3.instruction的regsRead和regsWritern里面是空的，碰到跳转或条件指令里里面会有值，但不包含常规寄存器，猜测可能是在性能优化上的有意为之，不过问题不大，无非就是在处理ldr x0,[x0]这类指令时打印寄存器值时需要注意一些。
除了这些外貌似也没什么太大的问题，整体执行速度还不错，就是代码量大时偶尔会挂掉，特别是在跟踪步入bl指令时。
然后依拖于Stalker封装了几个函数：

因为是随手测试的，所以没有专门去看sign的计算是哪一个，就随手测试了几个值，不需要的屏蔽掉了，也就有了下面的这个结果：

sign计算的中间call都应该算是比较清析吧
中间的流程大概就是在0xbc708处bl 0xbe1ac，之后就是0xbc8e0处调用0xc709c，参数是1PaJH2i4Bu60DMq4zUogvFil9Bs=字符串，之后一连串的bl 0xc792c,之后会使用新的函数调用bl 0x2bb3c进行执行，之后还有

流程貌似还算比较清晰
然后在ghidra里面看了一下，不忍直视，来点片段享受一下吧
0xbc560

0xc709c

0xc792C