本人菜鸟，初入逆向，前段时间把sig算法通过ida阅读伪代码和arm汇编进行了还原，花了4天时间，殊不知已有大神已经发有分析帖子了 

（link：https://bbs.pediy.com/thread-254328.htm）

目标APP的sig3算法前面已经做足了功夫，这里只陈述一下我是如何找到sig3算法的，并没有把算法还原，因为so层onload有大量ollvm，目前还处于学习阶段，还没有触及，日后学成在继续发帖分享下学习笔记。

本次目标APP版本是7.2.4.13202，这里使用Charles抓包知道了sig3的全称：

sig3全称是 _NS_sig3 ，这里将app拖入jadx-gui进行分析，使用字符串搜索大法进行初步查找：

通过框选区域发现，a3是来自a2.a方法，且str2通过上方代码得知是sig签名结果，b2是一个url，但是执行了b()可能进行了一些处理，这里暂时先不管b2数据是什么，先最终到最终a调用的地方。

String a3 = a2.a(b2 + str2);  跟进a方法的声明：

 通过查看a的方法声明，发现是一个interface，这里直接右键查看调用例：

发现只有一处地方使用了implements，进去查看具体代码实现：

继续跟进getSigWrapper方法实现：

继续跟进j.c(str)方法实现：

发现还在继续深入调用  String atlasSign = KSecurity.atlasSign(str);，继续跟进方法声明。

继续阅读下代码，我们可以直接双击str变量，查看他引用地方：

发现是执行 d().a(str) ，继续跟进查看实现方法：

这里传了个参数2，false，继续跟进。

这里我们看到，他new了一个i()，并且一直在里面赋值，通过简单的课文阅读理解，我们去掉无用的代码：

最终发现是调用了i.a(this.a).b().a(iVar, "0335") 实现，继续跟进查看：

发现是interface，继续右键查看用例。

找到引用的地方，双击找到具体实现 a(i,string)的方法：

我们继续进行简单的语文阅读理解。

我们是否还记得，他需要算法的参数都放在了iVar，这里他使用 iVar.i() 将要签名的信息拿出来，紧接着调用 this.a.getRouter().a 获得结果，发现a这里传了很多东西，估计是最终算法，我们先继续跟一下a方法。

好家伙，又是interface，继续右键，我们稳住。

继续跟进查看实现：

return JNICLibrary.doCommandNative(i, objArr);  我们发现，最终是传给了navite进行了计算。

那么我们继续hook下他都传了什么信息，这里我选择的hook点是：

因为最后面这2个传的东西太多，而且很多都是固定值，懒得码这么多代码。

编写好的frida代码，先将手机的frida运行起来，具体frida的搭建文章我们可以阅读： 

https://zhuanlan.kanxue.com/article-350.htm

https://www.jianshu.com/p/dadacd02fefd

我们看到传的参数是域名的路径和sig（我们第一次看到他是str+str2的合并，原来str是域名路径）

这里我们回到a方法，查看他最终传给navite的参数：

这里因为文章长度问题，就不具体展示细节。

参数八：就是一开始传的false 逻辑变量，这里我们可以回到一开始传的时候查看他的赋值就知道了，这里的b()只是获取当时赋值的结果：

参数全部找到了，由于so层看到了大量ollvm，我就没有进一步还原，只能通过hook方式主动调用了。

因为看到这个so的加载挺难找的，这里也记录下我的查找过程。我们进入JNICLibrary.doCommandNative(i, objArr);的定义发现并没有找到加载so文件。

这里我选择了右键查看b的调用例，发现有一处new的地方：

我们跟进去看看。

通过种种代码的文字提示，发现他是在这里调用  boolean a = f.a(context); 进行加载，貌似这个是在提示加载消耗的时间。继续跟进f.a()查看：

发现看到了一个名字叫：kwsgmain，加上底部提示的 retry load so ok，怀疑这个就是so文件名字，查看lib发现确实存在该文件。

通过后续的继续跟进这个字符串的调用，最终发现确实是这个文件：

但是拖进ida看到onload那一刻起，我目前先放弃了。先继续啃课本。