某医保服务平台X-Tingyun、x-tif-signature、x-tif-nonce及encData、signData参数逆向实战
文章目录
- 声明
- 一、为什么这篇文章值得写
- 二、目标与交付标准
- 三、起手式：先看样本，再做第一轮分层
- 1. 业务加密类型几乎是明牌
- 2. `x-tif-signature` 看起来不是 SM2
- 3. `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