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):
QIpNjLtJALdcAEJPIxBMnLJv1BC2WdlovPHAKFQLarg3 (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...
