文章目录声明一、为什么这篇文章值得写二、目标与交付标准三、起手式：先看样本，再做第一轮分层1. 业务加密类型几乎是明牌2. `x-tif-signature` 看起来不是 SM23. `X-Tingyun` 更像监控头，而不是业务头四、为什么这次先走静态，不先走动态五、资源定位：先找到该下哪几个文件1. 主入口脚本存在2. 页面级 chunk 单独存在3. 监控脚本单独下发六、第一轮搜索：不要一开始就搜算法，先搜接口名结果一：接口定义落到了统一请求实例结果二：请求、响应都经过统一拦截器七、加密模块定位：命中 Webpack 模块 `7d92`八、先拆外围链路：`x-tif-*` 比想象中更简单九、`X-Tingyun`：先别把它当业务签名十、`encData` 不是“直接拿 appSecret 当 SM4 key”真实 key 还有一层派生明文也不是普通 JSON 字符串最终 `encData` 的生成链十一、`signData`：真正的难点不在 SM2，而在签名前字符串这次的签名前序列化规则一个抽象化后的签名串示例为什么这一步一定要从源码读，而不是盲猜十二、响应解密：请求通了不算完，响应还得拿回来十三、响应 `signData` 验签十四、为什么最后能脱离浏览器1. 密钥材料就在 bundle 里2. 加密入口是纯 JS 逻辑3. 外围头没有强环境绑定十五、工程化落地：我最后做了三套版本1. Node.js 版2. 纯 Python 版3. `gmssl + requests` 版声明本文章中所有内容仅供学习交流，严禁用于商业用途和非法用途，否则由此产生的一切后果均与作者无关，若有侵权，请私信我立即删除！一、为什么这篇文章值得写很多人做 Web 逆向时，一上来就会掉进两个坑：只盯着抓包结果，试图靠猜测把参数拼出来一看到浏览器调试不顺，就以为这题做不下去了这次目标站点给了我一个很典型、也很有代表性的案例：页面是公开查询页请求参数里有业务加密请求头里还有网关头和埋点头响应也做了加密封装前端是标准的 Webpack 打包站点，不是完全黑盒这类站如果方法对，效率其实很高。真正难的往往不是算法本身，而是你能不能在前 30 分钟内把问题拆对。所以这篇文章想讲清楚的不是“最后代码是什么”，而是下面这几个更重要的问题：我是怎么判断应该先看什么、后看什么的哪些参数属于业务加密，哪些只是外围噪音如何从一堆 bundle 里快速缩小范围为什么最后能脱离浏览器复现哪些点已经闭环，哪些点仍然没有完全闭环二、目标与交付标准本次分析目标页面：主页aHR0c