目标
找出请求中sign值的来源
准备
1.修改后的专用分析机
2.准备抓包环境
3.准备Frida、ida、jadx等分析环境
简单说一下分析过程中遇到的问题
1.首先是定位native在so中的位置，这个很简单，方法也很多
2.使用frida配置主动调用环境，让测试变的更简单一些
3.对算法核心代码进行定位，定位核心算法的方法很多，各有各的优劣，多尝试，合适的地方使用合适的方法
(1)Ida的trace功能，这种方法本身是非常好的一种方法，因为大部分的情况下这种方法更有效也更简单，但目前这种方式已知存在一些问题导致这种方式的使用受限
①慢，ida trace的方式会很慢，所以一般都是在缩小范围后再使用这种trace的方式来操作
②容易跑偏，跑到系统库里面，这种问题一般配合ida的脚本的DBG_Hooks进行主动对指令范围进行控制，通过ida_dbg.enable_insn_trace(True)来控制是否开启指令跟踪，不过这种方式没有具体用过所以这里不作评价，我常用的还是缩小范围后再开启trace，或通过trace来找一些异常代码，比如退出指令等，因为这样操作比较简单，可以绕开大部分问题，让日志也更简洁一些
③ida的trace功能貌似开启后就无法关闭，所谓的关闭只是不再打印日志，实际上trace的功能代码还是在跑，手动操作的时候貌似存在这个问题，没有用脚本试过，所以不清楚脚本的接口关闭会不存在同样的问题
④碰到特殊指令会导致功能异常，比如这里碰到的问题就是在trace功能开启的状态下STXR/STXRH指令会操作失败，包括在这行指令上F8也会失败，原因在于单步会导致读和写同时存在时写就会失败，目前这个算法里面没有看到被用在反调试功能上，只是在系统库里面大量看到了这种指令。从反调试的角度来说，这个指令其实存在好几个反调试点，对熟悉它的人来说影响不大，但对不熟悉它的人来说可以让人给整懵逼了，比如，算法中穿插着用这个指令进行赋值，根据指令执行结果改变算法流程（这个指令的第一个操作寄存器会被写入执行成功与否的状态），系统库中就是用这个指令配合CBNZ一起使用的，将指令执行结果带入算法中进行计算等等，都是骚操作
⑤算法中穿插反调试手段的情况，这种比较普遍，这个Sign算法里面就有，这种方式也好解决，碰到了改掉就行，无非就是麻烦一点罢了
(2)Unidbg，这种方法很强大，它的强大主要体现在无感知hook这块，但这种也不够完善，存在很多问题，主要是在环境这一块，毕竟是一个脱机的环境，补环境这块让人很头疼，不过在指令级追踪这块非常强大，可以对任意指令地址进行日志打印以分析流程，虽然这个也支持调试，但是那种调试还是不太习惯，所以整体来说这个我用的比较少，一般用它大致看看JNI_OnLoad还不错
(3)Frida，frida一般配合ida一起使用，这也是我最常用的手段，这种方式也基本上算是一种万能的方法，复杂环境使用这种方式可以让分析变得更轻松一些，基本流程就是ida静态分析一下可疑的关键代码，然后通过Frida进行确认定位以缩小关键代码的范围，之后再对关键代码进行trace日志分析，或进行单步调试分析均可以，同样的，这种方法通用是通用，但是同时也要面对frida和ida存在的共同的问题

问题
说说过程中碰到的问题吧
1.STXR/STXRH指令的问题以及ida的指令跟踪总是跑到库函数里面等，这些问题直接导致了我trace整个函数的计划失败，后面缩小范围的时候还是会碰到，这时候我使用的方法就是在碰到这种指令时在保证单线程的情况下将这种指令替换为了等价的STR之类的指令进行绕过了，trace也就自然而然的可以了
2.frida对指令hook的问题，在Hook函数时没有碰到问题，只有在一个函数频繁打印时frida才会异常挂掉，但是在对指令进行hook时，基本上90%的情况下都会异常，比如hook bl x8这样的指令，拿取x8的值时，基本上一hook就挂掉了庆幸的是第一次到来时基本可以拿到地址，不过也有例外情况，有一些就碰到了x8==0x20的情况，跳转到0x20的地址进行执行，汗，然后大致看了下frida对函数头部hook和指令间Hook的差异：
frida在hook函数头部的时候会将头部改写为

而在对中间指令进行hook时，确替换了4条指令，比如在hook blr x8指令时将就bl及接下来的三条指令一起替换成了下面的这种指令

对于函数头部的代码来说还好，没什么问题，但是对于指令间Hook的代码来说就存在两种情况：
1).指令占用空间过大，如果其占用了跳转指令的目标地址的指令导致在执行前有指令跳转到了这4条指令上，那基本上也就异常无疑了。
2)X16虽然做为保留寄存器存在，正常编译器一般不尽量不用它，但如果刻意使用呢，就会导致环境异常，比如将blr x8这种指令用x16替代
3.混淆，主要碰到了3种混淆，强度都不算太大，解决起来也很简单，这三种混淆主要还是对静态分析造成干扰，对动态分析没感觉到有太大的阻碍，无非就是注意不要跑偏就好
(1)第一种混淆，在函数头部,解决方法也很简单，分析一下函数特征，脚本里面根据特征直接替换就行了，比如上面的混淆整个nop掉，然后直接b sub_68314即可

(2)第二种混淆，存在偏移表的这种，观察代码逻辑，直接以w0的值代入表达式算出表中的偏移量，然后取出偏移表中的值算出跳转的最终地址直接跳转过去即可

(3)第三种，也有规律可寻，这种我没有处理，直接单步调的，看起来str ldr一大片一大片的，实际上都是一些保存环境和恢复环境的代码，调试的时候基本可以忽略，碰到逻辑上不符合预期的再回头看看就好。而要pass掉这种代码其实也不难，比如下面的这段代码

分为三个部分，一是赋值部分一大片的mov常量，然后一个B跳转，第二部分可以算是干扰部分，将前面的赋值部分代入后实际上也是一个赋值代码，可以替换第一部分的相关赋值指令，不过需要注意位置会不会有影响，第三部分就是一个跳转表，大致意思就是jmp table + (table + index 4)
最终结果就是：

如果只是追求逻辑修复能F5的话这样就可以了

最后附上字符串解密还原的代码，代码量比较少，比较简单，示例代码还原后与代码中的一致，调试的时候忘截图了，只记录了参数和结果，所以这里没有ida里面的截图，结果为字符串“sec.umeng.com”：

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！