文章目录
-
- 声明
- 前言
- 一、问题现象：参数看起来都像，结果就是不对
- 二、先别怀疑世界，先怀疑自己还原的状态初始化
- 三、真正的坑：Python 用的是 raw tempkey，JS 用的是 final tempkey
- 四、这个 tempkey 不是“随机矩阵”那么简单
-
- 1. 初始化状态不是拍脑袋取，而是从矩阵自身导出
- 2. `jt_row` 先被打补丁，再参与后续计算
- 五、两个最阴的细节：都不是 raw row，而是 mutated row
-
- 结论 1：高区块写回依赖的是 mutated `jt_row`
- 结论 2：block2 写回同样依赖 mutated `jt_row`
- 六、这些公式不是猜出来的，是从 VM 字节码里抠出来的
- 七、为什么这次没有继续死盯 `WEBDFPID`、`status=2`、headers
-
- `WEBDFPID` 重要，但这次不是主因
- `status=2` 重要，但不是首刀
- headers 当然要像，但别什么都怪 headers
- 八、最终落地：把 final tempkey 接进默认 signer
-
- 1. 新增 tempkey 重建模块
- 2. 默认 signer 不再直接用 raw tempkey
- 九、验证方式：不要只看函数对不对，要看请求能不能活着回来
-
- 第一层：中间状态对比
- 第二层：真实请求回包
- 十、这次逆向里几个特别值得记的经验
-
- 经验 1：签名不对时，优先检查“状态构造”，不要只盯“签名函数”
- 经验 2：能逐字节对比，就不要只看最终字符串
- 经验 3：别把“环境参数”当万能借口
- 经验 4：服务端返回 `200` 才是最终裁判
- 结语
声明
本文章中所有内容仅供学习交流，严禁用于商业用途和非法用途，否则由此产生的一切后果均与作者无关，若有侵权，请私信我立即删除！
前言
这篇文章记录一次非常典型、也非常折磨人的前端签名逆向过程。
目标并不花哨：
- 不是“浏览器开着就算成功”
- 不是“把 JS 丢进 Node 里凑合跑”
- 更不是“抓一个现成 mtgsig 回去复用，祈祷它别过期”
真正目标只有一个：
把大众点评 H5Guard 的签名链路还原到纯 Python，可稳定发起请求并拿到 200。
如果要用一句话概括这次逆向的灵魂教训，那就是：
你以为自己把签名算法还原完了，实际上你还原的只是“签名算法的原材料生成器的前半段”。
这类坑，不阴间，但很恶心。因为它不会直接告诉你“你错了”，它只会让你觉得“我看起来哪都对，可服务端就是不爱我”。
一、问题现象：参数看起来都像，结果就是不对
目标网址：
https://www.di
