样本：aHR0cHM6Ly93d3cuYWxpeXVuZHJpdmUuY29tL3MvbkFBcUhtcGFBczg=
观前提示：
本文章仅供学习交流,切勿用于非法通途,如有侵犯贵司请及时联系删除
0x1 抓包
打开抓包软件， 发现app显示服务器连接失败，关闭抓包又正常了
基本可以考虑是证书验证了。
绕过方法网上很多，这里就不详细介绍。
绕过证书验证后就能正常抓包了
本文只分析signature这个字段的加密
0x2 加密位置分析
根据抓包信息搜索关键字很快就能找到关键点。
双击进来并找用例
跳转过来后就能看到signature的加密处了
进入LoginRequest.a方法
再继续进入b方法
可以看到这里就是加密处
进入a2.a方法后可以看到读取了map的内容拼接成字符串放进OvhrqNJCPF方法进行加密
进入OvhrqNJCPF方法
能看到是一个native方法，加载的是liblogin_encrypt.so
0x3 So分析
打开IDA，打开so文件。
搜Java可以看到出现了几个方法，其中也包含了本次分析的OvhrqNJCPF。
双击进来
发现需要等待挺久的，这是因为代码被混淆过了，体积膨胀了很多，加载需要点时间。
加载后能看到一堆框框，看到这个真是令人悲伤，又要爆肝了。
Tab看看伪代码发现字符串也被混淆了，并且可以使用Frida 一个一个dump数据。
只需要取so的地址再加上偏移地址就可以获取到正常的字符串了。
但是，字符串这么多需要挺大耐心的。
如下我曾经的分析记录
当然，还原字符串的方法不止这一个。
后面，我使用IDA动态调试dump出数据并配合010 Editor来替换数据，同样达成字符串还原的效果。(这里我比较懒,我就不详细说明流程了)
参考文章： https://blog.csdn.net/wang_624/article/details/115066838 https://www.bilibili.com/video/BV1pa411w7Gz?from=search&seid=925396145472135392&spm_id_from=333.337.0.0
dump脚本
static main(void){ auto fp,dexAddress,end,size; dexAddress=0xC5919000; end=0xC591B000; fp=fopen("I:\\liblogin_encrypt.so","wb"); for(;dexAddress<end;dexAddress++) fputc(Byte(dexAddress),fp); }
以下附上替换过程以及效果
已经基本能够帮助分析了。
回到代码 继续分析这个native方法干了啥。
还是老规矩，先改改JNIENV，改改变量名，辅助分析。
改完看到一堆控制流 在虚假块和真实块中间反复横跳，要咋搞呢？
我这里用一个比较讨巧的方法，找变量的调用，但这个就要你对整个流程的走向有一个把握了。
选中str变量，按X键，找调用
就一个跳过去 接着再找v128的调用
这里看到有好几个调用处，那就需要分析一下哪个才是要看的了。
例如上图有取长度进行计算的 有字符串拼接的 那优先选择字符串拼接的看看
如果错误了再反回来继续看别处调用。
过来之后可以看到这里还是在拼接内容，然后给了v113
还是同样找调用
比较符合下一步操作的就上面的CallObjectMethod那个方法了
照着这个方法看下来 就可以比较好的分析整个流程了，但是并不是所有情况都适合这个偷鸡的方法，是因为我选的这个样本比较简单。
从上图中能看到这个so方法还是最终会调回去Java层的方法的。
例如从中间就看到了
toUpperCase
java/lang/StringBuilder
append
java/security/MessageDigest（熟悉的朋友应该知道这是什么东西吧）
再往下看
还看到了SHA-1 update digest 这几个关键字眼。
基本可以判断这个so方法走的就是
- 拼接字符串
- 字符串转大写
- 调java/security/MessageDigest的SHA-1方法
那大概流程就分析清楚了啦
大家只需要去网上下载一个MessageDigest的hook脚本就行了
感谢各位大佬观看
如有错误 还请海涵
共同进步
[完]
