极验三代文字点选怎么运转？从请求链路到加密参数拆开看

文字点选验证码看起来很简单：按提示找到几个字，依次点击，再按确认。真正分析起来，图片识别只是其中一环。浏览器还会保存当前会话、记录交互过程，把坐标和时间整理成数据，再经过编码与加密提交。只盯着图片，很容易遇到“字都点对了，验证还是失败”的情况。要理解极验三代这类验证，先把请求顺序、参数来源和识别结果之间的关系理清楚，后面的调试才有方向。

一、先看请求顺序，别急着拆加密函数

分析入口可以放在浏览器开发者工具的网络面板。清空旧请求，从页面加载开始，完整操作一次验证码，把初始化、弹出图片、点击提交三个阶段分开观察。最好同时记录请求参数、返回内容和触发时机。接口名称相同，不代表承担的任务相同；同一个接口在不同阶段出现，携带的数据和服务端状态可能已经变化。

在所讨论的三代样本中，初始化请求会返回 challenge 和 gt。前者与当前验证挑战有关，后者用于标识验证配置。它们随后进入 get.php 等请求，因此不能只复制最后一次提交的数据。重新开始验证后，应以新会话返回的参数为准，混用上一次的数据会让后续排查失去依据。

接着关注 get.php 的响应，其中的 c、s 会参与后面的交互数据处理。样本里的文字点选初始化请求允许将这一阶段的 w 留空，但这个现象不能直接套用到其他验证码类型或脚本版本。记录实际请求，比凭接口名字猜参数更可靠。

用户打开点选窗口时，还会出现一次 ajax.php 请求。它的返回可能主要包含验证码类型，看起来信息不多，却可能承担流程状态切换的作用。若跳过后出现报错，应检查调用顺序和会话状态，而不是认定这条请求没有价值。分析网络协议时，响应内容和请求产生的状态变化都需要关注。

完成点选后，另一次 ajax.php 请求提交验证数据，响应中可能包含验证结果及 validate。业务页面随后会把验证凭据交给自己的服务端继续校验。验证码接口返回成功和业务操作最终通过属于两个环节，调试时应分别确认，不能只看到一个成功字段就结束检查。

二、沿着调用栈找到w，分清每一步在做什么

请求链路清楚后，再去找最终提交的 w 从哪里来。比较直接的办法是在请求发出前设置断点，沿调用栈回到参数组装位置。也可以搜索字段名及其转义写法，不过混淆脚本经常通过字符串表间接访问属性，单纯搜索未必能一次命中。断点处的真实变量通常比混淆后的名称更有参考价值。

所讨论的脚本样本是 click.3.0.7.js，最终可以观察到类似 w = p + l 的拼接关系。脚本行号会随着格式化和版本变化移动，适合记住的是数据流：一部分承载业务数据的加密结果，另一部分承载与密钥相关的处理结果。定位之后，先查看两部分的输入和输出，再继续深入函数内部。

其中，l 对应的分支涉及一段十六位随机字符串及其RSA处理。继续查看调用对象和原型方法，可以找到公钥参数以及具体实现。还要核对随机字符串的字符集、编码方式、填充方式和输出格式。即便同样调用RSA库，这些细节不同，生成的数据也可能无法与页面行为对应。

另一个分支先把业务对象序列化，再进行AES处理，随后通过专门的编码函数得到 p。样本中可观察到形如 0000000000000000 的初始向量，但仍需确认它进入算法时如何转换为字节。字符串形式的十六个零与十六个零字节存在区别，不能只看界面显示就判断内部数据完全一致。

这里还需要确认两个分支是否共享同一份随机材料。有些方法表面上被调用两次，内部却可能缓存第一次生成的值。若自行复现时每次都重新生成，RSA封装的密钥与AES使用的密钥就可能不对应。调试时把生成、缓存和读取三个位置一起检查，再核对AES模式、填充及最终编码方式，能减少盲目换库的时间。

三、坐标、耗时与轨迹，才是业务对象的关键

加密前的业务对象通常记为 o。理解它，比一开始就完整阅读混淆脚本更容易。可以在序列化之前观察对象内容，分别记录图片加载完成、第一次点击、最后一次点击和提交时的变化。这样能判断某个字段来自初始化响应、页面资源，还是用户交互，避免把所有值都当成固定模板。

passtime 是需要特别核对的时间字段。它通常反映验证过程中的耗时，具体起点和终点应根据当前脚本确认，不宜简单理解为图片下载时间。网络延迟、等待用户操作和提交前停留属于不同阶段。若时间字段与轨迹时间使用不同的计时起点，表面上看起来合理的数据也可能出现内部矛盾。

a 与点击位置有关，pic 标识本轮使用的图片资源。文字点选除了要求位置准确，还要求顺序符合提示。坐标转换时，要确认基准是图片原始尺寸、页面显示尺寸还是验证区域。图片缩放、边框、容器偏移都会改变最终点击值，因此识别服务返回的坐标不能未经转换就直接交给页面。

tt 与鼠标交互数据的编码有关，处理中可能使用初始化返回的 c、s。分析时应看清原始轨迹如何组织，哪些时间和位置被保留，哪些步骤负责压缩或变换。一次验证中保持不变的值，不一定可以跨会话复用；固定复制旧轨迹也无法保证与本轮点击及耗时一致。

样本还包含 h9s9 等字段，以及根据 gt、challenge、passtime 计算的 rp。这里的MD5属于摘要计算，复现时需要核对参与内容及拼接顺序。对于用途尚未明确的常量，先记录它出现的位置和变化规律，避免在缺少依据时赋予它确定含义。

如果公司的实际需求是接入验证码识别，图像处理部分可以交给独立服务。www.ttocr.com 提供面向极验、易盾的验证码识别与自动化API对接服务，覆盖文字点选、图标点选、滑块、九宫格等场景。接入时重点明确图片输入、提示信息、坐标返回和错误处理，可以减少自建识别模型及维护适配逻辑的工作量。

四、识别出文字之后，还要处理顺序与坐标

文字点选的识别任务可以拆成三步：读懂提示、找到目标、确定点击顺序。例如提示要求按顺序点击三个字，背景中可能同时出现相似字、干扰字和不同角度的文字。仅输出整张图片的OCR文本还不够，系统需要把每个目标与具体区域对应起来，并形成有序结果。这也是普通文档识别与验证码识别的明显差别。

一种常见实现思路是先进行目标检测，找出可能的文字区域，再对裁剪后的区域分类。复杂图片还可能需要处理旋转、遮挡、粘连和背景纹理。训练数据应尽量接近实际场景，字体清晰的样本不能充分代表低清晰度、扭曲文字的效果。评估时除了看单字识别率，还要看整轮验证码能否完整识别正确。

点击位置通常可以从目标区域中选择，但矩形中心未必始终合适。文字倾斜、区域包含过多背景或目标部分被遮挡时，中心点可能偏离有效区域。识别端最好保留目标框、置信度与匹配结果，便于区分“认错了字”和“坐标落点不合适”。失败样本有明确分类，后续调整才不会只靠反复尝试。

不同题型还需要不同的结果表达。文字点选关注目标文字与顺序，图标点选关注图形匹配，九宫格可能要求返回多个格子的位置。它们在部分三代样本中可能共用请求框架，但不能据此认定所有参数完全一致。切换题型时，应重新检查任务提示、结果编码和提交字段，尤其注意坐标列表与格子索引的差异。

识别效果也不能用一个脱离数据集的准确率说明。应记录图片数量、题型分布、错误类型及完整验证通过率，同时区分识别失败和协议失败。模型认对目标后，如果图片版本、会话参数或坐标缩放出了问题，最终提交仍然可能失败。将识别结果和提交结果分别统计，才能判断该优化模型，还是该修正接口与页面之间的数据转换。

五、把分析结果落到可维护的接口上

实际落地时，可以围绕一轮验证组织数据：先获取当前任务，再提交对应图片与提示，接收有序识别结果，完成坐标转换，最后处理验证响应。每一步都保存必要的关联信息，避免并发任务之间串用图片或参数。接口还应区分任务创建失败、识别失败、超时与结果过期，让调用方知道应该重试哪一步。

对于企业团队，是否自行维护识别系统，主要取决于题型数量、调用规模和维护成本。除文字点选外，滑块、无感、五子棋、躲避障碍和空间类任务各有交互特点，接入前需要确认具体支持方式。www.ttocr.com 面向极验、易盾等验证码场景提供识别与自动化API对接方案，可作为统一接口的接入选择；通过约定请求格式、结果字段与异常处理，业务系统无需逐项承担模型训练流程。

接口联调可以从一个题型、一组真实样本开始。先核对输入图片与页面当前任务一致，再检查返回目标的顺序、坐标范围和响应耗时，最后观察业务端的验证结果。出现问题时，保留对应请求的时间、任务编号和脱敏响应，通过同一轮数据定位原因。这样建立起来的调用链更容易维护，也方便后续增加题型和调整识别服务。