某蜂窝 zzzghostsigh 补环境+纯算

安卓逆向

jadx

首先找到定位点。

这里直接搜索 zzzghostsigh

然后找他引用的位置

继续往下找一下位置。

这里发现是一个接口的实现。

那没关系。我们继续找下实现的位置。

这里可以挨个去看。

这里发现是gh.b()

继续点两下 就找到了 引用的位置。找到so层 是 libmfw.so

然后我们hook一下 看看传餐以及结果值。

unidbg

这里直接unidbg补环境

封装好请求

直接运行 报错如下

这里看到 直接就运行了没报错 缺少什么环境

1
2
[10:49:23 460]  WARN [com.github.unidbg.linux.ARM64SyscallHandler] (ARM64SyscallHandler:410) - handleInterrupt intno=2, NR=-128336, svcNumber=0x1a2, PC=unidbg@0xfffe0ab4, LR=RX@0x1203cbac[libmfw.so]0x3cbac, syscall=null
java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0

直接去看报错的这部分基址。跳过这部分校验

ida找一下 3cbac

然后分析下 。这个方法中都是校验。补起来相对还是比较麻烦的。

所以这里我们往上看。这个方法

按x 看下调用的地方。这里就是调用环境的地方。

所以这里我们直接跳过这个判断。

这里直接unibdg 去跳过 这个环境

1
2
3
4
5
6
7
8
9
 emulator.attach().addBreakPoint(module.base + 0x3970C, new BreakPointCallback() {
            @Override
            public boolean onHit(Emulator<?> emulator, long address) {
//                emulator.getBackend().reg_write(Arm64Const.UC_ARM64_REG_PC,0x3970C+4);
                emulator.getBackend().reg_write(Arm64Const.UC_ARM64_REG_PC,address+4);
                emulator.getBackend().reg_write(Arm64Const.UC_ARM64_REG_X0,1);
                return true;
            }
        });

这里返回true 即断点不会断住，返回false 即代表断点断住。

然后直接运行。发现可以出值。

结果也正如一开始我们frida的值一样。

接下来就是trace了

纯算分析

这里直接搜索 0x4a55

搜索到了 0x4a55d456 拆成了 8个字节。

那我们再搜下 0x9606ba47 果然也有 13个。实际不算结果12个。

那总计下

4a55d456 9606ba47 87057a46 2b4f926c f9739142

拆成了 五组。 40位。其实已经可以猜出来是sha256了。

先找下 0x4a55d456的基址 0x1203f360

搜索 一下

这里先回去看看 ida

这里把代码丢给gpt。gpt直接告诉我们这是个sha1

但是我们实际上去运算。发现好像对不上啊

所以肯定是魔改了一些参数。这里继续回去看010里的trace。

这里就相对简单了。我们对这源码去看实现就好。

这里找着入口对着看。

这里直接找sha1的特征值。

找一段源码（最好找python的。或者Go的 只要不是JS的,因为我就是js改的。千奇百怪）

这里我们找下sha1 的轮常数： 1518500249，1859775393，1894007588（-1894007588）

然后把它转成16进制去trace搜索。

这里分别为 0x5A827999，0x6ED9EBA1，0x8F1BBCDC

这里去搜搜

这里可以发现trace的地方有703个很明显不合理

找到 w29=0x5A827999 做下切割。

只拿一段。

这里找到 movk的地方。

发现一共4轮。

但是这这里movk直接就是就是加载常量了 所以得往前看一点。看看谁那些值。

具体看看trace中的值。

这里可以推断出SHA1的魔值

1
2
3
4
5
v18 = 0x67452301
v19 = 0xEFCDAB89
V20 = 0x98BADCFE
v21 = 0x5E4A1F7C
v22 = 0x10325476

但是好像和标准值有差别

标准的 “v21”与“v22”为 “0x10325476” 以及 “0xC3D2E1F0”

这里虽然改了。但是结果仍然不一致。

继续往下看吧。

分析下具体的代码

如下

以上依次为

movk、rev、and、add、eor、add、ror、add、ror、add、

_、字节反转、与、加、异或、右移、加、右移、加

这里可以看到这里基本和算法都差不多没有魔改。这一段对这去扣。

剩余是否一致也是一样的。往下看。

这里只讲差异点吧。

在开头搜过 0x5a827999 这个值。但是正常这个值。其实标准中应该只参与过16轮。而稳重有36轮。

所以还有20轮肯定是改了轮数。

所以下文开始就是16轮之后的改的论数

对应的伪c如下

继续问下ai

所以代码应该如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
if (i < 16) {
    f = (b & c) | ((~b) & d);
    k = 0x5A827999;
} else if (i < 20) {
    f = b ^ c ^ d;
    k = 0x6ED9EBA1;
} else if (i < 40) {
    f = (b & c) | (b & d) | (c & d);
    k = 0x8F1BBCDC;
} else if(i < 60){
    f = (b & c) | ((~b) & d);
    k = 0x5A827999;
}else{
    f = b ^ c ^ d;
    k = 0xCA62C1D6;
}

这里既是改了 这些值还是对不上。

走到最后

这里对源码看看

那正常 应该是

4 3 2 1 0

而我们的 是

4 2 3 1 0

所以这样调转下位置。 然后运行

发现终于一模一样了。

结语

也算搞了好几天。还原了一个比较简单的算法。