之前的帖子清理了jumpout，本文尝试静态分析和利用frida来分析mtgsig参数。

定位算法的步骤这里就省略了，直接从一个hook结果开始分析：

从上面结果可以看出一些很长的猜测很关键的字段base64字符串，所以直接利用ida的插件搜索算法特征。

利用上面特征可以定位到函数sub_4cf88, 利用frida hook验证参数中的字段是否出现在此函数中：

通过验证分析看到a5参数调用了此函数，所以分析a5：

利用堆栈轻松找到调用base64的位置0xfe538:

从上图可以看出确实调用了base64函数，但是此位置无法使用f5生成伪C代码，从这里向前翻查找最近的函数序言或者可能函数，查看为什么后面无法被f5，找到函数0xfdaa4如下图所示：


是一个BR X8的跳转，ida无法计算x8的值所以没有办法继续向下分析。

仔细分析跳转位置的汇编指令，分析跳转的逻辑：

简单阅读上面的指令，这个br逻辑可以利用现有的信息计算，看着很像是基于跳转表的跳转。用unicron模拟测试一下：

利用上面模拟可以看出，是从so文件中获取跳转表，并根据不同的条件计算出不同的地址。所以这部分可以恢复，起码可以部分恢复。接下来则是需要分析这种跳转模式在当前函数中有多少，然后识别出来手动计算分支清理出跳转地址。首先需要确定当前0xfdaa4函数的范围，可以利用函数的特征或者是其他手段确认，这里可以尝试利用跳转表x22的特性确认，x22的值一般在同一个函数内是不会变化的，所以直接从函数开始搜索和x22修改读取相关的汇编指令：

结果就不展示了，利用上面函数的搜索脚本可以分析出相邻函数0x100cac, elf
文件一般函数和函数之间不会出现交叉，除非有内联函数或者是其他编译优化策略共用代码块，这里就当一般情况处理。函数范围已经确定，并且通过观察ldr读取跳转表指令可以分析出都是通过x22 + 偏移量的方式寻址，这里只有偏移量计算方式的不同：
1. 立即数
2. 寄存器
3. 寄存器移位操作，这里很单一，只有LSL#3

同时按照上面的寻址方式静态分析，可以看到还有一种其他跳转方式：

这种方式比较简单，直接读取基地址，然后加减偏移量，没有条件选择。
接下来则是通过搜索匹配这些跳转位置收集信息计算地址然后patch。
首先搜索BR Xd语句：

通过上面函数收集到跳转地址之后，需要利用特征收集关键信息，将之前的两种跳转分类成条件跳转case1和无条件跳转case2.case1关键信息特征为：

case2关键信息特征为：

通过上面总结的特征完成信息收集：

通过上面函数收集到关键信息计算条件跳转地址和无条件跳转地址，并且给出patch位置。所以case1的patch思路是：

case2的patch思路：

利用前面的信息计算跳转地址

上面的寄存器值从之前的unicorn模拟执行中可以找到，至此差不多就完全将逻辑替换完成了，只剩最后一步将语句patch进去

清理之后的结果

清理完成之后这个函数大致就可以静态分析。回到最初调用base64函数的部分：

直接hook函数sub_4cf88和函数sub_68968因为两个函数都有统一个参数v154：

hook结果对比：

可以看出sub_68968的结果和base64函数的输入一致。进入函数sub_68968看到如下：

进入函数sub_10f0f8:

看着好像是rc4加密，搜索一份c语言rc4加密函数对比：


对比起来看真的很像，如果是rc4，那么result应该是sbox，接着看函数sub_68958，hook验证

那么sub_68958极有可能是rc4 init函数：

网上搜索rc4 init函数：

好像在rc4 init 过程中多加了一个下标i。先看看key是啥，然后写代码验证魔改位置, 从网上抄个python版本的rc4 init：

将上面的key带入到修改的rc4 init中：得到如下结果：

验证通过的确是修改了rc4 init函数中的部分。接着看rc4的输入数据然后统一验证。继续向上查看sub_34844函数是和输入相关的


从上面可以看出是一个json字符串应该是一些设备信息相关的压缩后得到的，开头两个字节zlib的默认压缩方式。接着需要看rc4的key是什么，因为每次hook输入的key都是变化的。

所以函数sub_683ec应该是计算rc4 key的，hook验证：


两个函数的数据对比没有问题确实如此。至此算法流程还是比较清晰的，下面用python简单验证一下hook日志中的数据。首先是rc4 算法key的生成：

从上图看着是和v13异或得到，那么将输入和结果异或即可得到v13:

取多次hook结果验证这个在同一个机器上起码是不变的。

a5 第一版

[注意]APP应用上架合规检测服务，协助应用顺利上架！