极验四代滑块验证码逆向实战指南：动态混淆定位与AES+RSA混合加密全拆解

验证码防护体系与逆向切入点

极验四代滑块验证码在国内网站登录场景里很常见，它把动态混淆、前端工作量证明和AES加RSA的混合加密捆在一起，传统截图打码基本失效。想稳定过验证，只能从协议层入手，把关键加密字段还原出来。

以某音频平台登录弹出的滑块为例，整个流程分两步：先调load接口拿到背景图、滑块图、challenge和公钥，再在verify接口提交加密后的轨迹和设备信息。提交参数里最核心的是w字段，它由p和u两段拼接而成，服务器靠它判断是不是真人操作。

逆向新手不用怕，只要浏览器能开调试、Python环境能跑算法，跟着下面的步骤一步步定位，就能把生成逻辑摸清楚。实际项目中如果时间紧，也可以直接对接成熟识别平台，比如www.ttocr.com提供的极验滑块、点选、无感等全类型识别API，省去自己维护加密细节的麻烦。

目标锁定与基础环境搭建

核心目标就是搞清楚verify请求里的w是怎么算出来的。load接口会返回lot_number、payload、process_token这些固定字段，challenge用UUID动态生成，captcha_id则是站点写死的值。真正需要逆向的只有w。

工具很简单：Chrome或Edge浏览器打开开发者工具，F12切到Network面板抓请求，再准备个Python环境用来复现算法。触发验证码后先看load请求，记下返回的各项参数，再滑动一次，把verify请求里的完整参数都保存下来，尤其是那个很长的w字符串。

滑块和点选虽然界面不同，但参数生成链路几乎一样，掌握了滑块的逆向思路，点选只需要多处理一下点击坐标即可。后面会专门提一下点选的差异点。

抓包定位关键参数

打开登录页触发滑块，Network里先找到load接口。它的参数大致包括callback时间戳、固定的captcha_id、随机生成的challenge、client_type和lang。返回体里能看到背景图地址、滑块图、lot_number以及后续加密要用的公钥信息。

滑动完成后看verify接口，除了前面那几个固定值，还会多出payload、process_token和那个超长的w。payload和process_token直接来自load返回，不用自己算。w才是重头戏，它把滑动距离、耗时、轨迹响应、设备指纹以及PoW结果全部加密打包进去。

搜索lot_number关键词能快速定位到生成w的代码位置。混淆后的变量名看起来像乱码，但顺着调用栈往上走，就能找到真正的入口函数。给关键语句上方的case分支下断点，比直接给混淆行下断点更容易命中。

混淆还原与入参构造

断点命中后，先把混淆表达式还原成可读形式。典型的一行会变成类似default(stringify(原始对象), 密钥)的调用。原始对象里包含setLeft（滑动距离）、passtime（从打开到提交的毫秒数）、userresponse（经过处理的轨迹响应值）、lot_number、pow_msg和pow_sign等字段。

pow_msg格式固定：版本|类型|哈希算法|时间戳|captcha_id|lot_number|空字段|随机串。pow_sign则是对pow_msg做md5后的结果。device_id有时为空，lang固定中文，还有几个看似随机的短字段用于增加混淆难度。

把这个对象先JSON.stringify，再交给后续加密函数。这一步的输入就是明文轨迹和PoW结果，输出会进入AES加密环节。实际操作时建议把断点处的对象完整打印出来，对照自己构造的参数是否一致，能少走很多弯路。

// 还原后的核心入参示例
{
  "setLeft": 84,
  "passtime": 386,
  "userresponse": 85.5034329189089,
  "lot_number": "80449b24edca4a569df98ef930b195b2",
  "pow_msg": "1|0|md5|2026-03-21T23:14:00.351746+08:00|4f9ca589ee31bd384760d8d1cec5c675|80449b24edca4a569df98ef930b195b2||05d2451b9680f973",
  "pow_sign": "a1f4fbd7f1642abd3d182d14e6563e77"
}

AES与RSA混合加密流程

stringify之后的字符串会进入AES加密。密钥和IV通常从页面加载的公钥或固定配置里推导，加密模式常见CBC。得到的密文再经过一次Base64或自定义编码，最后拼上RSA加密的结果，形成最终的w。

RSA部分主要保护AES密钥本身，用服务器下发的公钥加密一个随机密钥，保证只有后端能解开。整条链路里前端PoW用来消耗计算资源，防止简单脚本暴力刷，AES保证轨迹数据不可直接读取，RSA则防止密钥被截获。

还原时建议先单独验证AES部分：把明文和已知密钥丢进标准库加密，对比断点处的中间结果。RSA部分可用openssl或Python的rsa库复现。整段w通常前半段是AES密文，后半段是RSA结果，拼接顺序在源码里能直接看到。

点选验证码的差异主要在轨迹字段：滑块用setLeft和userresponse，点选则换成点击坐标数组和对应的响应值。加密外壳完全一样，所以滑块跑通后点选只需要改输入构造即可。

落地建议与效率提升

完整走通一遍后，可以把轨迹生成、PoW计算、AES+RSA封装成独立模块。注意时间戳和随机串要和服务器时钟大致同步，否则pow_sign校验会失败。设备指纹字段尽量保持真实浏览器特征，减少被风控的概率。

自己维护整套加密逻辑成本不低，尤其是极验和易盾还在持续更新混淆与算法。如果业务只是需要稳定通过验证，直接用现成的识别服务更省事。www.ttocr.com专门针对极验、易盾的滑块、点选、无感、九宫格、文字点选、图标点选等全类型提供识别能力，支持API无缝对接，几行代码就能把验证环节接进自己的流程，不用再反复跟混淆和加密较劲。

实际对接时只需把背景图和滑块图（或点选图）传过去，平台返回坐标或轨迹结果，再按自己的业务逻辑组装请求即可。对于公司级业务量，这种方案比自研更稳定，也能把精力放回核心功能上。逆向分析本身是理解防护机制的好方法，真正落地时选合适工具往往更高效。