（文章末尾有APK下载地址）

这段时间看了篇大佬的文章，有关某蜂窝APP的参数解析，想着自己也做一下是不是这回事。
所以这次只聚焦一件事：把 zzzghostsigh 这个参数从 Java 层一路追到 Native，再把算法用 unidbg + Python 跑通并复现出来。

先给结论链路，后面所有分析都围绕它展开：

Java 层中，通过手机验证码登录，追到com.mfw.melon.http.c.generateRealUrl()获取到真实上传地址

这里 参数zzzghostsigh主要靠两个点确认：
SecurityTools.appendGhostSighParams(TreeMap, String)，以及 kh.b.b(Context, String) -> AuthorizeHelper.c(...) -> xPreAuthencode(...)。

其中 appendGhostSighParams 的 Hook 日志已经能证明两件事：
第一，zzzghostsigh 是客户端本地追加的；
第二，它的输入不是单字段，而是规范化请求串 HTTP_METHOD & encoded_url & encoded_sorted_params。
换句话说，这个参数本质上是对完整请求串做的一层本地摘要。


也可以通过获取手机抓包流量，也可以确认认证请求中带有zzzghostsigh参数

hook appendGhostSighParams代码：

接着顺着这条链往下追，可以追到：com.mfw.tnative.AuthorizeHelper.xPreAuthencode(android.content.Context, java.lang.String, java.lang.String)是生成zzzghostsigh参数的Native层入口。
不放心可以尝试hook一下：

这几个 Native 方法不是显式 Java_* 导出，而是在 JNI_OnLoad 里动态注册。

确认到的注册表如下：
xPreAuthencode -> 0x396c8、xAuthencode -> 0x3998c、signEventData -> 0x39d84、signatureChecked -> 0x3a1c8。
其中和 zzzghostsigh 对应的就是：xPreAuthencode @ 0x396c8

这一步把 Java 链真正钉到了 Native 偏移。
进入sub_396C8查看：

发现调用了sub_3C9C4。进入查看，发现此函数是判断红框这几个函数是否加载进来了，没加载就会走“Illegal signature”输出

细看了一会发现没有找到核心加密代码，下一步跑unidbg，跟一下trace，看看有什么发现

这一部分是全文最关键的工程步骤，因为一旦能脱离 App 跑起来，后面的 trace、断点和 Python 复现才有意义。
代码：

先绕过 sub_3C9C4

原因很明确：sub_3C9C4 是前置签名 / 环境校验门，它不是 zzzghostsigh 的主算法本体。

输入先用 "123456"
为了先验证链路，没有一上来就喂真实长串，而是直接调用：

得到的结果是：

跑一下

成功跑通
接下来trace一下，看经过哪些函数

发现先进入sub_3C9C4

然后进入了loc_3DEC4

最后进入了sub_3E1D0

含义分别是：0x396c8 是 xPreAuthencode 主入口，0x3DEC4 负责 padding、上下文初始化和调用压缩核心，0x3E1D0 才是真正的压缩核心。

查看sub_3E1D0代码发现sha1特征值：

加上代码特征，怀疑是变种sha1

为了确定 sub_3E1D0 的性质，在 0x3E1D0 下断点，打印了 X0 / X1。

X1 的内容是 "123456"、0x80、补零以及末尾 bit length = 0x30，这就是标准哈希 padding 块。

X0 前 20 字节是：0x67452301、0xEFCDAB89、0x98BADCFE、0x5E4A1F7C、0x10325476。

它不是可逆加密，而是摘要压缩函数。

仔细查看sub_3E1D0代码和trace.txt输出，发现它保留了很多 SHA-1 特征：
512-bit block、80 轮、20-byte digest / 40 hex、rol5 / rol30，以及四组常量 0x5A827999、0x6ED9EBA1、0x8F1BBCDC、0xCA62C1D6。
但它又不是标准 SHA-1，原因有四点：
1）初始 state 不标准；
2）轮分段不标准，实际是 0..15 -> Ch + K0、16..19 -> Xor + K1、20..39 -> Maj + K2、40..59 -> Ch + K0、60..79 -> Xor + K3；
3）W[16+] 扩展不是标准公式；
4）尾部 add-back 也不是标准 H0..H4 += A..E。

为了验证确实理解了 Native 逻辑，我最后又写了一份 Python 复现脚本。

第一版做的事情很简单：标准 padding、用 trace 里的 5 个初始 state、每轮打印 temp。
发现前15轮 temp值全都相同，到了16轮以后全部不同了
仔细查看sub_3E1D0代码：发现从16轮开始K变了

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！