首先使用jadx对apk进行逆向

搜索关键字 QDSign，可以直接找到对应的类，可以看到参数经过加密得到

进一步跟踪，发现了c类中有如下三个so方法，还有3个loadlibrary,分别进行了hook，发现c-lib动态注册了sign,sos动态注册了s,没有发现crypto有动态注册，使用frida对3个so函数进行了hook，证实sign是QDSign的加密函数，s是AegisSign的加密函数，SignNew并没有调用，搜索java代码，也没有发现调用的地方，猜测可能该函数没有实现，暂时不管了。

先用frida进行hook看看返回结果

确认结果确实为QDSign的值

通过 jnitrace -l libsos.so 包名 -i RegisterNatives 可以看到是动态注册的函数

直接再执行 jnitrace -l libsos.so 包名 发现程序卡在了闪屏页，原因不明，这种方法在很多应用上都会这样，有大神知道原因吗？

换成程序启动后，进行attach的方式， jnitrace -l libc-lib.so 应用名 -m attach ，貌似没有结果，这个方法在自己的程序上可以正常获取trace，但是在最近逆向的应用上都没有任何输出，原因不明，有没有知道的大佬解答一下？

祭出unidbg大杀器试试，使用模拟23版本，会报错

报以上错误，猜想是不是用的applcationContext、看了下日志,替换为android/content/ContextWrapper后，继续执行，又报错

搜了一圈，没找到有用的信息。

最后想不到办法了，抱着侥幸心理、死马当活马医，换成19版本。。！！！居然成功了！！！

模拟执行sign方法，得到如下结果

观察在sign方法中获取了参数、版本号、签名，然后进行了两次md5,最后输出了一个128位的字节数组，经过测试，两个md5分别为对请求参加md5,对签名进行md5。

sign函数返回的是字节数组，看了下jadx解析出来的工具类的名字为Base64Util，遂想到先用android的Base64一下，看看结果如何。可以看出，应用的base64函数做过特殊处理，在中间插入了两个空格，看来需要直接使用它原来的方法比较好。

此时需要逆向 包名.core.util.e(这个类是Base64Util)下的public static String m39789a(byte[] bArr)函数，可以看出，该函数逻辑恢复不正确；

于是通过jadx的信息，定位该dex位于classes3.dex中，通过dex2jar，获得了对应的jar压缩包；

由于压缩包中其他的类，并不是本次关注对象，单独提取 包名.core.util.e.class，扔到在线反编译网站，选择Procyon引擎进行逆向后得到

通过该函数解析字节数组，得到了最终的加密参数。

下面该还原so中的具体加密细节了。

打开IDA查看函数，通过unidbg模拟可以看到动态注册函数位置位于0x25a9，查看伪代码，可以看到对参数进行了拼接

这些参数通过对比unidbg日志，除了src不知道是什么，其余都对应上了，那接下来，hook下strcat

可以得出src的值

再往下分析，得出2488函数是最终进行加密的函数，继续跟进，看到如下代码

可以看到DES_ede3_cbc_encrypt关键字，搜索google，发现有一个openssl库一模一样的函数，参数个数也对应上了，

得出v24是输入参数，v27、v26、v25分别为秘钥1、2、3，v21为初始化向量。懒得找一个openssl库来实验了，我先想办法得到秘钥，向量已经在代码中看到了，既是01234567。

hook函数DES_ede3_cbc_encrypt

结果如下

看这个日志输出,三个秘钥都不相同,看不出是个啥，往回看秘钥来源于0xb88函数，hook这个函数

得到了一个字符串，搜索google找到DES_ede3_cbc_encrypt对应的java方法实验一下

然后把两个字节比较之后发现一模一样，说明秘钥正确。

到此算法分析结束。