版本：5.9.6

加固类型：梆梆企业版

抓包

部分接口 无法抓包。使用rocapture去获取数据

得到的CURL如下。

这里只做部分Demo演示：

tip：最近重新抓包了 发现很多接口有了 seal-v3 和 sign-v3 。

估计是我下载当天接口没迭代 所有部分接口没有v3

本文只对v2进行分析。

Java

首先这是加固。所以要先去脱壳。

使用脱壳机或者脱壳网站 或者使用dump都可以。

搜索sign-v2

最后发现调用的是Gears.drift

同理另一个 seal-v2的入口函数如下：

这里frida一下 得到的值和结果如下：

这里再去hook下So层的地址。使用 [RegisterNatives.js]

可以看到虽然是做了一层检测。但是地址依然被hook出来了。

unidbg

走到这里 我们可以先去看SO

可以看到 这个SO也是加固的。

这里使用分两步。

首先拿着so去脱壳。

其次 给自己的ida装上去混淆插件。

这里脱完的so，我们用刚刚的registerNavitve脱出来的地址，

直接放到unidbg中补就行了。

补完会报一个错。

com/pupumall/customer/tinystack/S->q()Ljava/lang/String;

这里去Java层看下这个实现逻辑。

发现实现逻辑也在So里

这里hook下。

这里发现如果是没登陆的应用大概率是空。应该是注册。具体逻辑在So层 。可以暂时先写死。

我是主动调用hook到了。但具体实现仍需要去看。

补全之后就能出值了。

这里往上翻一翻可以看到。再调用blurr函数的时候。drift也会调用。并且sign-v2 的值也会出现。

所以这里应该我们分析seal-v2 就行。

算法

这里由于每次的值都不一样。所以首先我们需要去固定下Unidbg的随机值。

本文随机值只需固定RandomFileIO即可。

可以观察到。

一共 a、b、c、d、e、f

六个值

其中

a： 16位 有点像md5 + 后四位拼接

b、d、e： 三个值一样 疑似是随机值。

c、f ：暂时不知道 需要具体分析

a & sign-v2

这里直接分析下trace 日志吧

如下图所示

可知 第一个加密点在 74efc函数中。

这里可以看到 最后一位数字C6 但是整体加密是40位

可见 后面8位和前面32位并非一套算法。

那32位。最让人联想到的就是md5。

这里字节去hook下这个方法的入参和结果。

结果如下。发现他是调用Json里的值。

这里我们再来看看日志和So。

其实这里找到这里 对着去看日志 就知道魔改了啥值。

这里经过分析。

得知MD5方法走了两次

再去看下unidbg 可知。seal-v2中也调用了 sign-v2。

sign-v2的长度也是32 由此推断是一套算法。

然后我们找到一份MD5 源码对着改。然后丢进去看看。

最后对比结果。和sign-v2的结果对比一致。

b & d & e

seal-v2的a 还有尾巴 ps19ztv3

这里基于unidbg修改了几次随机值

发现每次值都随机。所以应该是一个Seed随机数

C

RC4 算法。

算法函数如下： key为打码。

F

其实有个很秒杀的方法。这个有兴趣的可以加我私聊。

其实我们看到最后的这个== 我们可以盲猜一下他是base64。

首先搜下 base64 特征点

定位可知 在 sub_79238 这个函数中

然后丢给AI

ai帮我吗还原去除掉伪代码

如下：

intencrypt_and_pack(constchar* input, int flag, Out* out){constchar* key =        (flag & 1) ? "abQjOosSOMLBfRg05fAm"                   : "AbQjOosSOMLBfRg05fAm";size_t len = strlen(input);size_t out_len;uint8_t* buf = encrypt(input, len, key, &out_len);if (need_extra_process())        process_A(buf, out_len, out, flag & 1);else        process_B(buf, out_len, out);free(buf);memset(out->pad, 0, sizeof(out->pad));return0;}

其实这里就能得知 sub_1B1E30是算法来源

但是这里的算法 是xxtea啊

这里我们来找找 xxtea的算法来看看。

其实可以看到所谓的xxtea魔改 其实也就是改了下delta的值。

这里我们借助AI + SO+trace

得知 密钥藏在这段Trace中

0x4271724C -> “LrqB” 0x35757664 -> “dvu5” 0x474B4F6D -> “mOKG” 0x6D356A33 -> “3j5m”

这里delta的话。我在trace中找了几个值问AI 然后对比出是某个值。

那其实 F的算法比较清楚了

即 base64魔改+ XXtea魔改

结语

最后算法… 没场景。整合再说吧。另外还出了v3 估计光弄v2 也没用。

鸣谢一波：我🐑哥 以及我七神