-
-
[原创]TikTok Shop 滑块验证码逆向分析与协议还原实践
-
发表于: 2026-8-6 18:59
-
本文记录一次针对 TikTok Shop 滑块验证码的逆向分析过程。从浏览器中的 JavaScript SDK 出发，逐步还原整个验证码协议，最终实现纯 HTTP 完成滑块校验，而无需驱动浏览器完成拖拽。
相比介绍某一个算法，本文更希望分享整个逆向思路：如何分析一个现代 Web 验证码，以及如何一步步完成协议化。
现代电商平台的滑块验证码，真正需要验证的并不是"鼠标有没有移动"。
浏览器完成的一次滑块，大致包含下面几个阶段：
页面上的拖动，仅仅只是其中的一小部分。
因此，与其不断模拟浏览器鼠标事件，不如直接分析：
浏览器最终向服务端提交了什么。
如果能够完全还原这一过程，那么浏览器便不再是必需组件。
整个分析过程可以抽象为下面这条流水线。
整个过程中，我们并不是直接研究加密，而是按照浏览器真正执行的顺序，一层层向前推。
任何验证码最终都会调用一次 Verify 接口。
因此第一件事不是研究加密，而是找到：
是谁生成的。
浏览器抓包后，可以看到 Verify 请求大致如下：
请求体只有一个核心字段：
说明：
整个滑块真正提交的数据，都已经被封装到了 captchaBody 中。
因此接下来需要继续逆向：
captchaBody 是如何生成的？
经过 JavaScript 插桩，可以定位到 SDK 加密之前的明文对象（plain）。
例如：
直到这里，整个验证码真正需要提交的数据才全部暴露出来。
这一步非常重要。
因为之后所有工作，都建立在：
先理解每个字段代表什么，再考虑如何生成。
而不是一开始就研究加密算法。
接下来开始逐个分析 plain 中的数据来源。
经过大量样本比对，可以发现字段主要分成几类。
例如：
来自 /captcha/get 接口。
无需计算。
例如：
需要下载：
然后通过 OpenCV 等算法识别缺口位置。
得到真正需要拖动的水平距离。
例如：
这些来自浏览器采集的环境数据。
协议实现时可以直接按照 SDK 格式生成。
真正花时间最多的是：
经过大量 Challenge 对比，可以发现：
真正影响 y 的，是 /captcha/get 中的参数计算出的偏移量。
当所有字段都能够独立获得以后，就可以生成完整轨迹。
整个 plain 就已经完整。
当 plain 已经完全一致以后，加密反而变成最简单的一步。
直接沿着 SDK 调用链即可定位：
只要执行与浏览器一致的加密流程，就能够得到完全一致的 captchaBody。
因此这里关注点已经不再是算法，而是：
如何保证输入完全一致。
TikTok Shop 在 Verify 请求之外，还存在额外的一层请求保护。
例如：
这些通常都由页面 SDK 自动生成。
协议化时需要同步完成签名计算，否则 Verify 请求仍然会失败。
因此最终 Verify 请求包含两部分：
二者缺一不可。
当所有步骤全部完成以后，整个流程可以收敛成：
整个运行过程中，仅依赖：
无需驱动浏览器完成拖动。
完成整个协议链路后，在真实挑战上即可获得 Verify 成功响应：
|
|
|
|
|
|
|
|
|
|
|
 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
