文章目录
-
- 声明
- 前言
- 一、为什么想写这篇文章
- 二、这次逆向的真实目标到底是什么
- 三、第一阶段：先别急着抠算法，先确认问题到底是不是 token
- 四、第二阶段：先恢复请求体，再谈恢复签名
-
- 1. 为什么我喜欢先恢复 body
- 2. 列表页 body 是怎么来的
- 3. 一个非常隐蔽但常见的坑：日期
- 五、第三阶段：静态分析 phantom-token，但不要陷进“全量还原前端”幻觉
-
- 1. 面对混淆脚本时，最容易犯的错误
- 2. 更实用的做法：只围绕目标参数建立证据链
- 3. 这次实际采用的拆解思路
- 六、第四阶段：不要只靠“看代码”，一定要做对照实验
- 七、第五阶段：用脚本批量验证“强校验”是否存在
-
- 这次实际测过的接口
- 实测结论是什么
- 八、第六阶段：继续往详情页走，服务码和 body 构造比 token 更关键
-
- 1. 先搞清服务码
- 2. 评论接口为什么很值得测
- 3. 房型弹层为什么更适合检验“token 强弱”
- 九、第七阶段：为什么 一开始“看起来像 token 失效”，其实不是
-
- 1. 当时的现象
- 2. 真正的问题
- 3. 为什么这种脚本最容易误导人
- 十、这次逆向最重要的几个方法论
-
- 方法论 1：先分离“协议问题”和“算法问题”
- 方法论 2：尽量从页面已有数据中提请求模板
- 方法论 3：不要被“看起来很重要”的字段吓住
- 方法论 4：静态分析负责“找线索”，动态实验负责“定结论”
- 方法论 5：逆向不是“全理解”，而是“够用且可证”
- 十一、这次 phantom-token逆向的最终结论
-
- 已确认的事实
- 已通过实验验证的事实
- 更合理的判断
- 十二、给初学者的一个实用建议
-
- 不要追求“第一步就把算法全抠出来”
- 十三、python完整实现
-
- python 无phantom_token版
- python带phantom_token纯算版
声明
本文章中所有内容仅供学习交流，严禁用于商业用途和非法用途，否则由此产生的一切后果均与作者无关，若有侵权，请私信我立即删除！
前言
目标站点
https://hotels.ctrip.com/hotels/list?countryId=1&city=17&provinceId
