东航逆向实录:refer__1036、req/res、ssxmod_itna/itna2 一锅端
文章目录
- 声明
- 0. 前言
- 1. 先从现场下手:网络面到底长什么样
- 2. 协议入口定位:别追业务页面,先追统一封装器
- 3. req到底怎么生成:公式已经可以写死
- 3.1 transactionId 生成公式
- 3.2 明文业务包并不是页面原始参数
- 3.3 IV 也已经不是谜语
- 4. res怎么解:其实和 req 是同一把钥匙
- 5. 第一轮本地落地:先把前端加解密在本地复活
- 5.1 先做一层本地 helper
- 5.2 验证结果:`req` 回放可逐字节对齐
- 6. `refer__1036`:这个参数确实可疑,但别把它当唯一真神
- 6.1 它是什么
- 6.2 这次已经确认了什么
- 6.3 这次还没有确认什么
- 7. shoppingv2 卡住已经不是 AES 的锅
- 7.1 证据链已经闭环
- 7.2 我连真实浏览器值都原样重放了
- 7.3 同一套协议对首页接口是成功的
- 8. 既然协议层没锅,那就去看 cookie:`ssxmod_itna` / `ssxmod_itna2`
- 9. 第一步拆 cookie:先别猜算法,先抓现行
- 9.1 直接拦 `document.cookie`
- 10. 第二步拆 cookie:先确认它不是普通 base64
- 11. 第三步拆 cookie:先把编码器单独复现
- 12. `ssxmod_itna` 原始拼串:环境全家桶
- 12.1 `A8` 是动态项,别把它当常量
- 13. `ssxmod_itna2` 原始拼串:行为快照版
- 14. `dM / dK / dh / dL / A7`:这套东西到底都在采什么
- 14.1 `dM`:浏览器体检表
- 14.2 `dK`:自动化 / 运行环境补刀组
- 14.3 `dh`:宿主结构补充项
- 14.4 `dL`:最阴的一组异步 probe
- 14.5 `A7()`:用户行为速写
- 15. `GE(dl)` 这个坑,值得单独点名批评
- 16.这次最容易踩的几个坑
- 16.1 一看到 405 就回头怀疑 AES
- 16.2 看到 `refer__1036` 就把它当成宇宙真理
- 16.3 一看到 `ssxmod_itna` 就试图一口气复刻整套风控
- 16.4 把“能生成密文”误认为“能通过风控”
- 17. 最值钱的方法论是什么
- 17.1 先抓现场,再看源码
- 17.2 先找统一协议封装器
- 17.3 把问题分层
- 17.4 编码器和原料分开打
- 17.5 最终一定要落脚本
- 18. 这次关于 `refer__1036` 的最诚实结论
- 19. 一句话总结整件事
声明
本文章中所有内容仅供学习交流,严禁用于商业用途和非法用途,否则由此产生的一切后果均与作者无关,若有侵权,请私信我立即删除!
日期:2026-05-14
0. 前言
这次逆向一开始的目标,其实非常朴素:
- 把东航 H5 的请求体
req怎么生成搞明白 - 把响应里的
res怎么解密搞明白 - 把 URL 上那个看起来就很可疑的
refer__1036盯住 - 如果接口还不通,再继续拆风控 cookie:
ssxmod_itna/ssxmod_itna2 - 最后尽量用纯 Python 落地,让
requests能自己把流程走完
说得文明一点,这叫“协议分析 + 风控逆向”。
说得不文明一点,这叫:
前面先拆保险箱,后面再去拆门口保安的对讲机。
这篇文章不是单讲 AES,也不是单讲 cookie,而是把这两条线完整串起来,讲清楚我是怎么一步步从“这个站怎么 405 了”走到“哦,原来它有两层门禁”的。
1. 先从现场下手:网络面到底长什么样
逆向第一原则不是“
