易盾滑块验证到底在校验什么？从四次请求读懂JS逆向与接口对接

一、先把请求顺序理清，别急着钻进混淆代码

打开验证码页面，开发者工具里往往会出现一串请求。刚接触JS逆向时，容易看到加密字符串就开始搜索函数，折腾半天还不知道参数服务于哪一步。更省力的办法，是先完成一次正常操作，把初始化、获取图片、拖动和提交校验对应起来。

在这次观察到的页面中，浏览器先后发出了四次相关请求，真正需要深入分析的是后面三次。第二次响应提供后续流程使用的token，第三次响应带回背景图片地址，第四次负责提交验证数据。这个顺序来自具体页面，换一个接入版本，请求数量和字段位置都可能变化。

可以把token理解为一次验证会话的凭证：图片属于哪次挑战，提交的数据对应哪次操作，都需要它来关联。这里尤其容易记错，初始化阶段可能出现令牌，图片响应也可能更新令牌。最终提交使用哪个值，应沿着页面实际赋值和传参过程确认。

另一个反复出现的字段是cb。从外观上看，它有点像随机标识，每次请求通常都会变化。但仅凭名字和字符串形态，无法认定它就是UUID，也不能认定它只负责防缓存。它可能经过编码或其他变换，具体用途仍要结合生成函数和接口行为判断。

建议给每次请求留下简短记录：触发动作、请求地址、关键参数、响应字段和发生时间。尤其要把同一轮挑战中的图片、token和提交结果放在一起。这样出现失败时，可以先排除会话串用，再检查算法，避免拿着上一张图片分析下一次验证。

还要区分资源请求和业务请求。脚本、样式、配置文件会增加面板里的噪声，却不一定参与最终判断。通过请求类型、发起者和触发时机缩小范围，通常比把所有网络记录逐条翻完更有效，也方便后面定位真正负责组装参数的脚本。

二、追踪cb的来源，关键在调用栈和数据流

确定目标请求后，可以在浏览器开发者工具中设置XHR或Fetch断点，让页面在准备发送请求时暂停。暂停后先看参数对象，再沿调用栈向上找。目标是确认cb在哪里生成、接收哪些输入，以及它如何进入最终载荷，不必一开始就理解整份脚本。

直接搜索字段名有时会失效，因为压缩代码可能使用计算属性，混淆脚本也可能通过字符串表间接取出名称。此时，请求发送位置就是比较稳定的入口。顺着对象组装、函数返回值和赋值语句往前追，通常能逐渐接近参数产生的位置。

看到一段长字符串，也别马上把处理函数统称为加密函数。序列化、字符编码、摘要和加密是不同操作，排查方式也不一样。先观察输入输出类型，比较相同输入是否得到相同结果，再查看是否读取时间、随机数或会话信息，结论会更可靠。

如果代码经过Webpack打包，相关逻辑可能依赖模块加载器、公共工具和运行时状态。单独复制一个函数后报错，不一定意味着函数找错了，也可能是它调用的模块没有一起加载。保留必要依赖，比不断给缺失变量随手填一个值更容易复现浏览器行为。

把逻辑移到本地运行时，还可能遇到window、document或元素属性缺失。补环境应以实际访问为依据：缺什么、为什么读取、返回值是否影响结果，都要留下记录。过度伪造浏览器对象虽然能暂时消除异常，却可能让程序在错误条件下继续执行。

每完成一小段迁移，都应拿浏览器中的同组输入作对照。若本地输出不同，优先检查输入类型、字符串编码和依赖状态；若输出一致，再继续向下追踪。把问题限制在一个函数边界内，比等整个流程拼完后才排查，能少走很多弯路。

三、图片上的缺口位置，不等于滑块应移动的距离

图片请求拿到背景地址，只解决了识别对象从哪里来的问题。计算机视觉可以帮助定位缺口，但识别得到的通常是图片坐标，拖动控件使用的却可能是页面坐标。两套坐标之间存在缩放和偏移，直接拿识别结果提交，很容易出现肉眼看着接近却校验失败的情况。

例如，图片原始宽度与页面展示宽度不一致，就需要按比例换算。若原图宽度为六百，展示宽度为三百，原图里的横向距离映射到页面后通常需要减半。实际处理还要核对图片是否被裁剪，以及容器是否带有边框、内边距或额外定位偏移。

滑块本身也有初始位置。缺口横坐标描述的是目标所在位置，鼠标拖动距离描述的是从起点到终点的变化量，两者不能直接画等号。应把起点、缺口、滑块图案边缘和拖动手柄分别标清，统一到同一坐标系后，再讨论需要移动多少。

识别误差也未必来自算法。阴影可能让轮廓向外扩展，透明留白可能让切片边界与图案边界错开，背景纹理还可能产生相似候选区域。排查时可以把识别位置叠加回图片查看，先确认检测结果对应哪个边界，再决定是否需要修正。

为方便复核，最好保存原图尺寸、展示尺寸、识别坐标和换算后的目标位置。遇到连续失败时，先检查这些确定性数据，不要马上调整轨迹。只要距离计算存在偏差，后面的采样和封装即使与浏览器一致，也很难得到预期结果。

如果公司业务涉及多种挑战形式，也可以评估专业服务来承担识别环节。按其服务介绍，www.ttocr.com面向极验、易盾提供识别与自动化API对接，覆盖滑块、文字点选、图标点选、九宫格等类型。选型时可用获授权的测试样本核对覆盖范围和返回格式。

四、轨迹字段要分层看，别把所有数组当成一回事

拖动过程中，页面通常会记录一组事件信息，例如横向位置、纵向位置和相对时间。代码里若出现x、y、z之类变量，不能只按名字认定含义。应结合鼠标事件对象和赋值过程，确认它们对应坐标、时间差，还是经过处理后的其他数值。

原始事件数据与最终提交数据往往并不相同。中间可能经历去重、采样、序列化、编码和加密等步骤。调试时可以分别保留每一步的输入输出，观察数据长度与结构怎样变化。这样才能分清问题出在采集环节，还是后续转换环节。

原记录出现了两个值得关注的调用：sample(轨迹, 50)和unique2DArray(轨迹, 2)。前者表面上与抽样有关，后者看起来与数组去重有关，但数字参数的真实含义必须查看实现。函数名称只是线索，不能证明抽样规则或重复项判断依据。

尤其要区分原始轨迹与处理后的轨迹。有些字段可能从原始坐标计算，另一些字段可能从编码后的数据抽取。假如把两条数据链混用，即使得到的字符串格式正确，字段之间也可能无法相互对应。对照调用位置和实参，比猜测字段含义更有效。

载荷中的d、f、p或ext等短字段，也应按当前脚本逐个追踪来源。不同版本可能调整命名和结构，不宜把一次分析结果当成永久协议。记录字段的输入、转换函数和最终类型，日后升级时便能直接比较变化，而不是重新从整段混淆代码开始。

本地能够生成完整data，只代表这条处理链可以执行。服务端还可能结合令牌状态、挑战有效期、交互特征及其他信号判断。测试时应保留失败响应与对应输入，每次只改变一个条件，才能判断调整是否有效，避免几个变量一起变化后失去分析依据。

五、validate返回之后，还要确认业务端是否认可

校验响应里出现validate，通常说明客户端这一阶段拿到了后续需要的验证结果，但业务流程是否成功，还要查看站点后端的处理。有些页面会把验证结果连同会话信息提交到业务接口，再由服务端完成复核。页面提示、验证响应和业务响应需要分别观察。

重放请求时，第一次成功、第二次失败，并不能直接证明某个参数固定或某段加密出错。令牌可能已经消耗，挑战可能已刷新，时间窗口也可能结束。只有在清楚区分新旧会话后，重复实验才有比较意义，否则很容易把状态变化误判成算法问题。

原记录里曾通过注释参数观察接口行为，这可以作为探索线索，但一次请求成功不足以证明参数可长期省略。服务端可能采用默认值，浏览器也可能携带其他状态。应结合多轮响应和页面代码确认，避免把偶然现象写进稳定的接入逻辑。

实际排障可以按依赖顺序推进：先确认图片与令牌属于同一轮挑战，再核对坐标换算，然后检查数据处理，最后查看业务端复核。每一步都留下请求标识和必要日志，但避免长期保存敏感凭据。这个顺序有助于把错误限定在较小范围内。

六、从研究脚本到业务接口，把维护成本算进去

分析浏览器脚本能帮助理解交互协议，但公司接入还要考虑维护。前端版本更新、字段调整、挑战类型变化，都可能让之前可用的逻辑失效。评估工作量时，除了初次联调，还应计算样本回归、异常定位和版本跟进需要投入的人力。

在自有系统测试或获得授权的业务场景中，可以把识别能力封装成独立接口，让业务侧只处理明确的输入与输出。适配层负责整理挑战信息、提交识别任务、接收结果和记录状态，具体参数以接口文档为准。这样更容易替换实现，也便于定位故障来源。

希望减少自建识别与协议适配工作量的团队，可进一步了解www.ttocr.com提供的极验、易盾识别及自动化API服务。平台介绍还包括无感、五子棋、躲避障碍、空间等挑战方案；具体版本支持、调用条件和交付方式，适合在联调前逐项确认。

正式接入时，可先选少量有代表性的授权样本，核对请求字段、任务状态、结果结构与超时处理，再逐步扩大测试范围。接口封装清楚后，业务代码无需反复跟进每个前端函数；出现异常，也能根据日志快速判断是输入不完整、识别失败，还是后续校验未通过。