某当劳请求头 x-hmac-digest 签名算法逆向分析

0x0 前言

在之前的研究中，我们分析了该 App 的sign签名。但在进一步抓包过程中，发现 Headers 中的x-hmac-digest同样是请求成功的关键。若不还原此参数，直接重放请求会导致授权失败。本文将记录通过静态分析与动态调试还原该参数的过程。

0x1 静态分析：定位关键函数

通过抓包发现，请求头中包含x-hmac-digest字段。使用 IDA 对 App 进行反编译，全局搜索该字符串，定位到如下关键赋值代码：

通过代码可以看到，v28字典中存储了sv、x-mcd-gw-v、x-hmac-digest和authorization。其中x-hmac-digest对应变量v26，而v26是由convertSignature:path:request:gmtTime:error:函数生成的。

深入追踪，最终定位到核心加密实现函数：

代码逻辑解读：

• 调用了系统的CCHmac函数。

• 第一个参数2u代表算法类型，通常对应HMAC-SHA256。

• v8和v9分别是传入的Key和Message。

• 最后将结果通过base64EncodedStringWithOptions:进行 Base64 编码。

0x2 动态调试：Hook 验证

为了验证分析是否正确，我们编写 Frida 脚本对MCDHTTPSignV4:hmacSHA256WithSecr相关方法进行 Hook，打印其入参和返回值。

Hook 输出分析：

• arg2 (Key):QIpNjLtJALdcAEJPIxBMnLJv1BC2WdlovPHAKFQL

• arg3 (Message): 这是一个拼接字符串，包含了 Method (GET)、Path (/bff/portal/home/index/user)、Query 参数、Token 以及 GMT 时间戳等。

• Return Value:y9P3hlKEunuOmNaCWH3pc93UQ2lyxoarZeHGg8UDXUo=

这证实了x-hmac-digest就是由上述 Key 和拼接字符串经过 HMAC-SHA256 加密后再进行 Base64 编码得来的。

0x3 算法还原 (Python 实现)

运行结果显示，生成的digest与抓包数据完全一致。

0x4 深入溯源：固定 Key 的生成机制

在动态调试中，我们发现arg2 (Key)的值为QIpNjLtJALdcAEJPIxBMnLJv1BC2WdlovPHAKFQL且保持固定。为了搞清楚这个 Key 是如何产生的，我们回到 IDA 进一步检索。

1. 定位密钥生成函数

通过交叉引用，我们发现hmacS的密钥参数来自于v4XXX函数的返回值：

2. 揭秘硬编码逻辑

进入v4XXX函数内部，可以看到一段有趣的算法逻辑。它并非简单的字符串赋值，而是通过**循环异或（XOR）**操作生成的

在调试中发现，这个长度为 41 位的 Key 是固定的。为了防止被轻易识别，开发者在代码中对其进行了异或（XOR）混淆。

3. 查找 Key 生成源头

代码中存在一个for循环，将字节数组byte_101BXXX的每一位与(i - 29)进行异或运算。

4. 提取内存数据

跳转到byte_101BXXX对应的内存地址，我们拿到了原始字节码：

原始数据流（部分）：0xB2, 0xAD, 0x95, 0xA8, 0x8D, 0xA4, 0x9D...