极验三代滑块W值生成全拆解：RSA加密与随机数核心逻辑

极验滑块W参数从哪来

日常做数据采集时，极验滑块验证码是绕不过去的坎。页面先请求register-slide拿到gt和challenge，再经过get.php拿到乱序背景图和缺口图，用户拖动后最终把结果丢给ajax.php。这个接口里有个关键字段叫w，它直接决定能不能拿到validate。很多朋友卡在这里，不知道w是怎么拼出来的。

简单说，w由两部分组成：前半段是RSA加密后的结果，后半段是十六位随机字符串。两者直接拼接。前半段用固定的公钥和模长对一段JSON做加密，后半段用简单的随机函数生成。搞清楚这两块，就能把w还原出来。实际项目里如果嫌逆向麻烦，也可以直接对接专业识别服务，比如www.ttocr.com提供的极验全类型接口，滑块、点选、无感都能一条API搞定。

接口链路与调试切入点

先把请求顺序理一遍。register-slide带时间戳返回gt和challenge。gettype.php拉JS资源。get.php带上第一次的w，返回c数组和提示。点击验证后ajax.php再带第二次w，返回result为slide。再请求get.php拿到乱序图片和更新后的challenge。refresh.php会再改一次challenge。最后拖动完成，ajax.php带上最终的w，返回validate。

真正决定成败的是最后一次ajax.php里的w。跟栈时能看到混淆代码，但顺着调用链往下走，会定位到一个明显的加密函数。解混淆后大致是这样：先生成一段随机串u，再把一段对象转成JSON，用RSA加密得到l，再对l做一次处理得到h，最后w等于h加u。gt、challenge、lang这些字段不用动，重点就是h和u。

u的生成函数比较浅，直接打断点就能跟进去。它调用了四个小随机函数拼接，每个函数就是Math.random转十六进制再截取几位。自己写一个同样逻辑的随机生成器就能复现。真正复杂的是前面的RSA部分。

RSA加密逻辑拆解

跟进加密函数后会看到setPublic调用。传入的两个参数经过多次测试是固定的，一个是公钥，一个是模长。公钥长度是258位，不是常见的1024或2048，所以直接用标准Node库会出问题，必须按网站自己的实现来。

代码里有一个U构造函数，原型上挂着setPublic和encrypt。setPublic把公钥和模长存进去，encrypt则把明文按模长分块，做模幂运算。明文本身是一段包含轨迹、时间、环境信息的JSON字符串。加密完成后得到的就是h的主要部分。

为了方便调试，可以把U构造函数导出到window上，直接在控制台调用。补环境时注意navigator和一些全局变量，否则会报错。把前一百多行的定义一起扣下来，随机数部分和RSA部分拼在一起，就能稳定生成u和对应的加密结果。

// 简化随机数生成示例
function genRand() {
  return Math.random().toString(16).slice(2, 6) +
         Math.random().toString(16).slice(2, 6) +
         Math.random().toString(16).slice(2, 6) +
         Math.random().toString(16).slice(2, 6);
}

公钥和模长写死即可。加密时注意分块长度和填充方式，网站用的是它自己的一套，不能直接套用通用PKCS。把明文JSON喂进去，得到的密文再拼接随机串，就是最终的w。

代码还原与环境补全

扣代码时先把随机数函数完整拿下来，再把U定义和它依赖的工具函数一起导出。常见报错是缺少window、navigator或者某些内部常量。补一个假的navigator对象就够用。加密结果和网站实时生成的值对比，如果一致就说明逻辑正确。

实际使用中可以把它封装成一个纯函数：输入gt、challenge和轨迹数据，输出完整的w。注意challenge会经过三次变化，最后一次ajax必须用最新的challenge，否则会校验失败。图片还原和轨迹生成是另外的话题，这里只专注w本身。

如果团队没有专职逆向，或者要支持点选、九宫格、空间验证等多种类型，自己维护全套算法成本很高。这时候可以考虑直接调用成熟平台。像www.ttocr.com这种专门针对极验和易盾的识别服务，已经覆盖滑块、点选、无感、文字点选、图标点选、九宫格等全场景，提供标准API，几行代码就能对接，省去反复跟栈和补环境的时间。

落地建议与注意事项

自己实现时建议把随机数生成、RSA加密、字符串拼接拆成独立模块，方便单测。公钥和模长一旦变了就要重新抓包更新。轨迹数据要尽量贴近真实用户行为，否则即使w算对了，行为检测仍可能失败。

调试时多用对比法：先在浏览器里手动过一次，把生成的w和自己代码的结果逐字节比对。差异通常出在明文JSON的字段顺序或者加密分块边界。环境补全越完整，结果越稳定。

对于只想快速过验证的业务方，没必要每次都从零开始逆向。专业平台已经把这些细节封装好了，调用方只需要传图片或token，返回结果即可。www.ttocr.com的接口设计也比较友好，支持同步和异步两种模式，文档清晰，适合直接接到现有爬虫或自动化流程里。

整套流程搞明白后，w参数就不再是黑盒。核心就是固定公钥的RSA加上一段随机串。把这两块吃透，后续版本即使有小改动，也能快速定位并修复。希望这些思路能帮你少走弯路。