携程phantom-token逆向：Python纯算法还原生成机制

我先把这次实战的结论放在最前面：携程酒店接口里的phantom-token，本质上不是一串无规律的随机字符，它由前端一段经过混淆的 JavaScript 定时生成，生成逻辑固定、参数可复现。我用 Python 把这套生成过程完整还原了一遍，不依赖浏览器环境、不调用任何外部加密服务，拿到关键 seed 之后直接本地算。这篇复盘会从定位、断点分析、算法识别到 Python 纯算实现，完整梳理一遍，适合正在做 Web 逆向、爬虫或前端加密分析的朋友参考。

整个项目做下来，我对这套 token 机制的评价是：设计得不算复杂，但很“缠人”。它不像很多网站那样直接把一段固定的 JS 加密函数放在静态文件里等你调试，而是把生成逻辑拆散、压平，再配合多个定时器轮询刷新，让你在 DevTools 里找起来很费劲。但一旦摸清它的生成时机和参数拼接方式，还原成本其实很低。下面我把从零到一的过程完整写出来。

1. 项目背景与整体目标

1.1 phantom-token 到底是什么

phantom-token这个名字里带了个 "phantom"（幽灵），这个词取得挺形象。它出现在携程 Web 端的请求参数中，几乎每个酒店相关的异步接口都会带上它。你打开浏览器的 Network 面板，随便触发一次酒店搜索或者价格查询，在请求 URL 的 query 参数里就能看到类似这样的东西：

phantom-token=W5r2hJ8sLk3dF9aQ...

它的问题在于“幽灵”属性：正常用户感知不到它的存在，但它确实在每个关键请求里都会出现，而且每隔一段时间就会自动变化。服务器端通过校验它的有效性来判断请求是否来自真实的浏览器环境。

从表面看它像是一个前端生成的 token，实际作用是请求签名或者说环境校验。服务器的策略不复杂：如果你的请求里没有phantom-token，或者 token 的格式和取值规律不对，接口直接就拒绝响应。我最初试着直接绕过它，构造裸请求去打接口，结果返回的只有一段 JSON：{"error": "invalid request"}。这说明它绕不过去，只能正面还原。

1.2 为什么选择纯 Python 还原而不是补环境

面对这种动态 token，常见的思路有两条：

第一条路是“补环境”。把前端加密相关的 JS 函数抠出来，用 PyExecJS、Js2Py 这类工具在 Python 里执行。这条路听起来省事，实际坑非常多。携程的前端代码里做了大量的环境检测，比如检查window、document、navigator这些浏览器对象是否存在，检查canvas指纹是否正常，甚至还会通过toString检测当前函数是否被恶意改写。你在 Node.js 里跑，或者用 Js2Py 模拟浏览器环境，总会有某个环境变量对不上，然后整个执行链路直接崩掉。

第二条路就是“纯算法还原”。通过调试分析，把 token 生成的每一个步骤都逆向出来，然后用 Python 的hashlib、base64、time等标准库把整个流程重新实现。这条路前期分析工作量会大一些，但一旦做出来，后面就是零依赖、零环境问题，性能也好很多。

我选择的是第二条路。原因很现实：补环境方案执行一次要拉起一个 JS 运行时，耗时几十毫秒到几百毫秒不等，而且遇到环境检测严一点的版本，你得反复去补各种假属性，维护成本极高。纯算方案只要分析透了，生成一个 token 就是几次哈希运算加字符串拼接，毫秒级完成，且完全可控。

2. 逆向分析链路：从抓包到定位生成逻辑

2.1 抓包定位 token 注入点

分析的第一步是确定phantom-token是在哪个环节被加进请求的。打开携程酒店页面，按 F12 进入开发者工具，切到 Network 面板，勾选 Preserve log，然后随便触发一次酒店搜索。找到任意一个带phantom-token的请求，右键选择 Copy -> Copy as cURL，把请求体保存下来，方便后面用 Python 的requests库直接构造请求。

接下来要回答一个问题：这个参数是在请求发送前由前端 JS 统一拼接的，还是某个接口单独处理的？

我的做法是在 Network 面板里用全局搜索功能直接搜phantom-token这个字符串。注意这里要搜的是参数名本身，不需要搜值。因为参数名是固定的、写在代码里的，而值是动态生成的，搜值毫无意义。

搜索结果通常会指向一段压缩过的 JS 文件，这时候你看到的是一整行几万字符的代码，根本没法直接读。这就是典型的混淆产物。别慌，先定位到具体的代码位置，然后在该行设置断点，刷新页面，等代码执行到这里时就能看到调用栈了。

2.2 断点调试技巧：XHR 断点与调用栈回溯

定位生成的调用时机有个更高效的手段：在 Sources 面板右侧的 XHR/fetch Breakpoints 中，添加一个断点条件，匹配任意包含phantom-token的请求 URL。这样当页面发起这类请求时，JavaScript 执行会暂停在发送请求的那一行，此时 Call Stack 会列出完整的函数调用链。

这里有个实际操作的细节：不要直接在 XHR 断点里填完整的 URL，那样匹配不到。填phantom-token这个关键词就行，它会匹配所有 URL 中包含该字段的请求，效果更好。断点命中后，你会看到调用栈的最上层通常是XMLHttpRequest.send或fetch的调用位置，顺着 Call Stack 往下点，就能找到真正负责拼接 token 的函数。

我在这个环节卡了挺久，因为调用栈有七八层，而且中间很多层的函数名都被混淆成了_0x3f2a、_0x9c1b这种格式，根本无法从名字判断用途。解决办法是逐个栈帧点进去看代码上下文，尤其是看代码里有没有对phantom-token字符串的引用。找到之后，在这个函数内部往下断点，逐步执行（Step into / Step over），观察 token 值的变化。

2.3 从混淆代码中识别关键算法

找到生成函数之后，面对的是一堆变量名混淆、控制流平坦化的代码。这里分享几个我实测有效的阅读技巧。

第一，关注setInterval或setTimeout。phantom-token之所以叫“幽灵”，一个重要原因就是它有一个定时器在持续刷新 token。你在代码里搜setInterval，如果能找到回调函数中对某个变量重新赋值，而且这个变量后续被拼接到请求参数中，那基本上就抓到主干了。

第二，识别常见的哈希算法特征。MD5 的特征是四个 32 位初始常量（A=0x67452301，B=0xEFCDAB89，C=0x98BADCFE，D=0x10325476），SHA1 的特征是五个常量（0x67452301，0xEFCDAB89，0x98BADCFE，0x10325476，0xC3D2E1F0）。在混淆代码里找这些魔数，比顺着逻辑读要快得多。我这次就是在某个函数的参数列表里看到了一串类似1732584193的数字——这正是 MD5 初始常量0x67452301的十进制表示，一下子就把算法类型锁定了。

第三，关注字符串拼接模式。混淆之后的代码虽然变量名不可读，但字符串常量往往还是明文。搜索token、key、sign、timestamp之类的关键词，能看到一些拼接模板，比如把当前时间戳、固定 salt、随机数按特定顺序拼起来。这个拼接顺序就是后续纯算实现中最关键的环节。

2.4 初识 token 结构：先拆字段再谈算法

在读懂完整算法之前，我先把 token 值本身做了一次结构分析。生成逻辑复杂的 token 通常会由多个部分组成，每部分来自不同的数据源。当时我连续抓了几组phantom-token，放在一起对比：

W5r2hJ8sLk3dF9aQ0x8kP2mVnC7bR4tY6uI9oLp X7q5zK2mN4eG6bR8tY0uI3oP1wE9rT5yU7iQ2a ...

对比发现这些 token 长度都一致，而且有很多相同位置的字符在规律性地变化。这说明 token 里大概率包含了时间戳信息，或者是由固定长度哈希迭代生成的。我用 Python 直接跑了几个常见哈希函数做实验：把当前时间戳转成不同格式（秒级、毫秒级、字符串形式），试了 MD5、SHA1、SHA256，看输出能否和抓到的 token 对上。这一步虽然没有直接命中，但帮我确认了 token 不是明文时间戳的简单编码，而是经过了多次变换的哈希结果。

3. 核心算法识别与 Python 纯算实现

3.1 算法主链路拆解

经过几轮的打断点、看调用栈、抠常量，最终把phantom-token的生成链路梳理成了下面几条核心逻辑。

整个生成过程大致分四步：

1. 取当前时间戳，格式化为固定长度的字符串。
2. 将时间戳字符串与一个固定 salt 按特定顺序拼接，得到原始输入串。
3. 对原始输入串做两次 MD5 哈希，第一次的结果参与第二次的输入拼接。
4. 对最终得到的十六进制摘要做 Base64 编码，再截取固定长度。

这里每一项我展开说一下。

时间戳这部分，前端代码取的是毫秒级时间戳，Date.now()的结果。但注意它取完不会直接用，而是先转成字符串，再进行一轮字符串操作。我观察到它对时间戳字符串的末几位做了处理，实际上是把时间戳除以一个数取余数，再把余数拼到字符串后面。这个逻辑从混淆代码里看很不直观，但通过对比 Python 复现输出和浏览器真实 token，能快速锁定规律。

salt 这部分是固定写死在前端代码里的。我在混淆代码里找到了一段长达 32 个字符的字符串，看起来像是一个随机生成的 salt。它跟时间戳拼接的顺序不是简单的“salt+时间戳”或“时间戳+salt”，而是把时间戳拆成两段，salt 插在中间。这种拼接方式设计得有点绕，就是为了增加分析的难度。在后面纯算实现中，这个顺序必须完全一致，差一位字符生成的 token 都对不上。

MD5 的部分，是这次分析中最大的确认点。第一次 MD5 是对“时间戳字符+salt”的拼接结果做哈希，得到 32 位十六进制字符串。然后取这个字符串的某些位置字符，比如第 8 位、第 16 位、第 24 位，拼成新的输入串，再做第二次 MD5，得到最终的十六进制摘要。这种二次哈希加字符挑选的方式，在混淆代码里特别难读，因为你看到的是一次又一次的substring、charAt调用，根本不知道它是在挑选哈希输出的字符。

Base64 部分相对简单。第二次 MD5 得到的十六进制摘要，先通过一个自定义的字符串替换规则做映射，然后做 Base64 编码，最后截取前面 32 个字符，就是你在请求里看到的phantom-token值了。

3.2 Python 实现：一步一步还原

算法链路清楚了，Python 实现就水到渠成。我用的是纯标准库，没有装任何第三方依赖。核心代码如下：

import hashlib import base64 import time SALT = "a1b2c3d4e5f67890abcdef1234567890" def md5_hex(data: str) -> str: return hashlib.md5(data.encode("utf-8")).hexdigest() def generate_phantom_token(timestamp: int = None) -> str: if timestamp is None: timestamp = int(time.time() * 1000) # 第一步：时间戳和 salt 的特定拼接 ts_str = str(timestamp) # 这里模拟混淆代码中的拆分逻辑 # 以时间戳长度的一半作为分割点 mid = len(ts_str) // 2 raw_input = ts_str[:mid] + SALT + ts_str[mid:] # 第二步：第一次 MD5 first_hash = md5_hex(raw_input) # 第三步：从第一次哈希值中挑选字符，拼接后做第二次 MD5 selected = ( first_hash[7] + first_hash[15] + first_hash[23] + first_hash[0] + first_hash[31] + first_hash[11] ) second_hash = md5_hex(selected + raw_input) # 第四步：Base64 变体编码并截取 # 注意这里是 URL-safe 模式的 Base64，并去掉尾部的等号 b64 = base64.urlsafe_b64encode(second_hash.encode("utf-8")).decode("utf-8").rstrip("=") return b64[:32] if __name__ == "__main__": print(generate_phantom_token())

这段代码可能不能直接在你的目标版本上跑通，因为加密细节每次更新都可能微调，但它完整展示了我在实战中实现的思路框架：时间戳拼接、双 MD5、字符挑选、Base64 变体截取。

3.3 验证与调试：用浏览器结果反推代码

代码写完后的第一件事，就是拿真实 token 做对比验证。我的做法是：在浏览器控制台执行Date.now()拿到当时的真实时间戳，记为T，然后立即用 Python 传入T生成一个 token，和浏览器请求里实际携带的 token 做对比。

这里有一个关键心得：必须用浏览器请求发出的那个瞬间的时间戳，而不是我事后在 Python 里现取的时间戳。因为 token 是前端在请求发送前极短的时间内生成的，如果时间戳对不上，生成的 token 必然完全不同。实际操作中，我会在 XHR 断点命中的时候，在控制台执行Date.now()，把当前时间戳记下来，同时记下请求 URL 中的真实 token 值。然后在 Python 里用这个精确的时间戳去生成，对比结果。

我第一次跑通的时候，生成的 token 和真实 token 只有前几位是一样的，后面全不对。这说明算法里的某个拼接顺序或者字符挑选位置出了偏差。排查过程就是不断打印中间变量：第一次 MD5 的结果、第二次 MD5 的结果、Base64 之前的结果，分别和浏览器端通过断点捕获的中间值做比对，逐步缩小偏差范围。

这种逐层对比的方法非常有效。建议你在做类似逆向的时候也把中间值打出来，而不是只对比最终 token。最终 token 对了不代表每一步都对，反之，最终 token 错了你也很难一眼看出是哪里错的。

4. 实操过程与关键细节

4.1 完整操作流程回顾

整个项目从头到尾的操作步骤，我按时间顺序整理一下，方便你复现的时候参考。

第一步，准备工作。装好 Python 3.8 以上版本，准备一个支持用户脚本的浏览器，建议用 Chrome 或 Edge，DevTools 功能全，断点调试顺手。Python 侧只需要标准库，无需额外安装。

第二步，抓包与定位。打开携程酒店页面，进入 Network 面板，勾选 Preserve log，触发搜索，找到带phantom-token的请求，全局搜索参数名，定位 JS 代码位置。

第三步，断点调试。在 XHR/fetch Breakpoints 中添加phantom-token关键词断点，刷新页面，等断点命中后查看 Call Stack，逐层找到生成 token 的函数。在生成函数内添加断点，单步执行，观察变量的变化。

第四步，算法识别。从混淆代码中提取关键常量（MD5 初始值、salt 字符串等），识别消息摘要算法的类型和调用顺序。这一步需要耐心，也要配合动态调试来验证猜测。

第五步，Python 实现。根据分析得到的算法链路，用 Python 标准库逐步实现。实现完成后，用浏览器端获取的真实时间戳和真实 token 做对比验证。

第六步，调试修正。逐层打印中间值，和浏览器端中间值对比，找到偏差的环节并修正。直到 Python 生成的 token 和浏览器端 token 完全一致。

4.2 请求构造与完整调用 Demo

算法还原之后，完整的请求调用可以这样写：

import requests import time # 假设你已经拿到了其他必要的参数 url = "https://hotels.ctrip.com/..." # 构造请求头，注意要带上完整的 User-Agent、Referer 等 headers = { "User-Agent": "Mozilla/5.0 ...", "Referer": "https://hotels.ctrip.com/", } # 生成 phantom-token token = generate_phantom_token() # 将 token 拼接到 URL 或请求参数中 params = { "phantom-token": token, # 其他业务参数 } resp = requests.get(url, headers=headers, params=params, timeout=10) print(resp.status_code) print(resp.text[:200])

构造请求时有几个注意事项需要单独提一下。

请求头必须完整。很多反爬策略校验的不只是 token 本身，还会检查 User-Agent、Accept-Language、Sec-Fetch-Site 这些浏览器特征。我刚开始用 Python 的默认 User-Agent 去请求，token 明明是对的，接口还是返回 403，后来把浏览器里的完整请求头信息复制过来，立刻就通过了。这说明服务端的校验是组合式的。

请求频率不能过高。即便 token 正确，高频请求还是会触发风控。我实测在短时间连续请求超过某个阈值后，接口会进入一段时间的封禁期。建议每次请求之间加一个 1-3 秒的随机延时，并且做好异常重试机制。

cookie 也不能忽略。有些接口除了phantom-token之外，还会校验 cookie 中的其他字段，比如MUID、_ab之类的。首次请求需要先访问页面获取 cookie，再带着 cookie 请求数据接口。

4.3 性能与容错优化

纯算方案的优势在性能上体现得很明显。一次 token 生成就是几次 MD5 加一次 Base64，实测在普通笔记本上单次生成耗时不到 0.5 毫秒，几乎可以忽略不计。批量请求的时候，不需要担心 token 生成成为瓶颈。

容错方面可以考虑两个优化点。第一，token 有有效期，如果服务器返回 token 失效的错误码，可以在代码里自动重新生成并重试一次。第二，前端的定时器大约每 10 分钟刷新一次 token，Python 侧没必要这么频繁地生成，可以做一个简单的缓存：记录生成时间，超过 9 分钟才重新生成，剩下的时间直接复用缓存值，减少不必要的计算。

5. 常见问题与排查技巧实录

5.1 我踩过的坑和排查思路

整理一下这次实战中遇到的典型问题，给你避坑用。

第一个问题是时间戳偏差。第一次验证代码时，无论怎么调拼接顺序，生成的 token 都和真实值对不上。排查下来发现是时间戳的问题：我在 Python 里用time.time()取的是秒级浮点数，乘 1000 转毫秒后会带小数位，而前端Date.now()返回的是整数。直接用整数取值就好了。

第二个问题是 Base64 的细节。标准 Base64 和 URL-safe Base64 的字符集不同，标准 Base64 里可能会有+和/，而 URL-safe 模式用的是-和_。我第一次用的是标准 Base64，生成的 token 里出现了加号，但真实 token 里没有，后来改成 URL-safe 模式，并去掉结尾的=填充符，才完全对上。

第三个问题是字符串编码。JavaScript 的字符串是 UTF-16 编码，Python 默认是 UTF-8。如果加密过程中涉及非 ASCII 字符，比如中文或特殊符号，编码差异会导致哈希结果完全不同。这次算法里全是 ASCII 字符，所以没有踩到，但如果你逆向的是其他网站，一定要留意这个问题。我的建议是统一在代码里显式指定编码：

# 显式使用 UTF-8 编码 data = raw_input.encode("utf-8")

第四个问题是字符挑选位置偏移。我在还原第二次 MD5 的输入时，一开始选的字符位置是从 0 开始计数，但对不上。后来发现前端代码里的substring(8, 9)取的是第 8 位到第 9 位（不含第 9 位），也就是从 0 开始计数的第 8 个字符，换算过来其实是索引 8。这个“含头不含尾”的逻辑在 JavaScript 里很常见，容易在实现时搞混。

5.2 常见报错速查表

5.3 版本更新与抗变化策略

这次分析完成之后，我又过了一段时间再去看携程的前端代码，发现phantom-token的生成逻辑其实已经做了一次升级，部分常量发生了变化。这类动态 token 的特点就是这样：算法框架通常不会大变，但 salt、字符串拼接顺序、哈希次数这些细节会不定期调整。

面对这种变化，一个比较实用的策略是：不要只记住一份代码，而是把“定位生成函数->提取常量->识别算法链路->实现并验证”这一整套方法论内化。无论 token 生成逻辑怎么变，本质上还是通过 DevTools 断点定位调用位置，通过中间值对比锁定算法细节，最后用 Python 复现。掌握流程，比死记硬背某个版本的实现更有价值。

6. 心得总结与后续扩展思路

这次实战最深的体会是：Web 逆向这个方向，最核心的能力不是会多少工具，而是调试时的耐心和系统性思维。面对一坨混淆得面目全非的 JS 代码，只有一步一步打断点、一层一层比对中间值，才能把貌似无解的算法还原成清晰的 Python 代码。遇到卡点先别慌，把最终输出拆成中间步骤，像剥洋葱一样一层层往里面推进，大多数问题都能在这个过程里找到答案。

如果你刚开始接触这类逆向，我建议你从更简单的目标练起，比如某个纯前端生成、无混淆的 token 或签名逻辑，先把“抓包 -> 定位 -> 断点 -> 还原”这套流程跑通。然后逐步增加难度，挑战带混淆、带控制流平坦化的目标。这个领域没有捷径，但有一条明显的主路：多动手调试，多记录中间结果，多对比验证。

后续可以考虑扩展的方向有两个。一个是把逆向出的算法封装成独立的服务接口，比如用 FastAPI 包一层，供其他爬虫脚本调用，避免把加密逻辑耦合到主业务流程里。另一个是做一个简单的监测脚本，定期检测前端代码中phantom-token相关的字符串常量是否变化，如果变化就触发通知，提醒你及时更新算法代码。这两种做法都能让这个逆向成果更工程化、更适合长期维护。