本文章仅做学习交流，请勿商业用途！如有侵权，请及时联系处理！感谢理解

Y29tLnNoaXpodWFuZy5kdWFwcA==

最频繁的是请求体和响应体的加密解密:libdusanwa.so的achilles和heracles方法

核心的ltk/ltn/rtk/lf...等参数：libszstone.so

核心的VMP中llibGameVMP.so中的IL等方法

还有像newSign/edk/sck等一系列的参数加密

此外还有libducloudpix.so中的一些列算法

...

xxx/call 注册sdk/sm

xxx/cold 注册androidId

xxx/getVisitorUserId 获取X_Auth_Token

...

ltk/skc 又分长和段：两者又有什么关联

sks代表算法类型：是否可以绕过加密

app中还会涉及到js的滑块问题：so中也有加解密

...

本次目的，通过最直接的方法还原请求中的加密和解密算法（unidbg模拟构造/trace日志结合ida综合分析还原算法）。其次是网上关于此app的一些研究比较多，但是相对核心的例如VMP/风控等的一些分析比较少，希望提高各位大佬的积极性，一起分析学习进步！

可以发现是在IL方法(vmp)反射调用到achilles加密的

参数1是请求体明文

参数2是skc

参数3是请求次数（个人理解，未认证）

参数4是时间戳

返回值的格式可以分析其中包括了两部分：长skc和加密请求体

打开so文件，发现achilles方法无法直接识别，so文件加密，这就不深入研究如何解密的，直接dump so，可使用frida 或者 unidbg进行，无非就是当改so运行时，若实现了so解密，直接dump下内存中的so的数据

分析dump下来的文件，找到方法入口，发现ollvm混淆，直接使用D-810工具进行反混淆。

构造好unidbg运行获取trace日志，这个基本没什么难度

第一部分是长的skc+校验，第二部分则是base64存储了重要的uuid(和加密的key息息相关，当然后续最新版本应该是存在变动)，第三部分则是数据加密内容

未分析过该算法，肯定是不知道每部分的内容，但是明显的三部分划分还是比较容易的

接下来就围绕这三部分如何产生的进行倒推法分析，当然该方法更适合初学者，有经验的大佬们会结合ida整体过一遍代码，然后挑选可疑方法或者代码，切入分析。我在有些so的算法分析中也遇到过，直接trace分析，可能误入一些简单魔改或者重写的算法中，圈子会绕的更大，但是ida上可能会更明了

本文不对skc进行深入分析，该参数特别敏感，感兴趣的大佬可以深入探讨

所以直接从第一部分的校验开始分析：unidbg写入日志搜索定位那里赋值

定位到下图方法，一看就非常熟悉，并且结合32位长度和固定常量值，可以知道这里就是MD5(算法)

根据MD5算法源码可知道，通常在MD5算法前有个方法是做MD5加密数据初始化的(加密数据放置指定位置)

根据unidbg调试查看参数发现前部分和第三部分数据加密内容一致，而后跟着0x20字节的内容（其实是uuid的md5和uuid的计算后的值进行拼接后的值）

根据0x20字节内容，通过写入trace查找，定位到q0赋值，找到x10寄存器值，查看哪里赋值

定位到如下图，用两个0x10长度的数据进行交叉写入

需要注意的点是交叉插入的顺序，那么两个数的长度都是0x10，如果假设都是MD5的产物，上面我们已经知道MD5算法，跟一下结果，看有没有用

正好可以发现uuid的md5是其中的一部分，而剩下0x10和uuid对比一下，发现就是uuid

通过地址赋值，定位到在memcpy处进行复制，在定位到主体的方法调用

unidbg验证，en_fun方法就是数据加密算法，参数1就是明文body，参数3则作为加密结果返回

会发现，到了这一步，思路就很明确了。我最开始猜测是魔改的des算法，是因为8字节进行计算，第一反应联想的就是DES，然后进入到en加密方法看也不算复杂就直接扣了。

这里在对key和iv做一个分析，或者说我当时理解的"表"进行来源分析（我最开始将此算法定位成key和iv融入某表的类似查表法算法），上面截图中也就是v18的来源

如下图，跟踪到en中的v18很简单，算法就几行代码，继续查看en_init的参数1的来源

根据unidbg的trace日志，可以定位到如下的方法，去混淆好代码一目了然。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课