极验4点选验证怎么跑起来？从请求链路到加密参数的分析思路

一、先看请求链路，弄清浏览器在忙什么

点选验证码看起来只是按顺序点击几个文字，浏览器背后却要完成一整套交互：获取挑战信息、加载图片和脚本、记录用户操作，再把处理后的数据交给服务器判断。研究极验4的参数时，先把这条链路看完整，比一上来扎进混淆代码更容易找到方向。

分析应放在自有系统、官方演示或明确授权的测试环境中。打开浏览器开发者工具的网络面板，保留请求记录，完成一次正常点选。观察哪些请求发生在验证码出现之前，哪些发生在点击提交之后，再对照发起者和响应内容，就能把初始化、资源加载和结果校验分开。

常见流程中，/load承担获取挑战相关数据的工作，响应可能包含资源位置、配置、服务端生成的标识及后续处理需要的信息。用户完成操作后，浏览器通过/verify提交验证数据。实际地址、请求方法和字段会随接入方式变化，分析时应以当前页面的请求为准。

原始材料里最值得追踪的两个字段是challenge和w：前者出现在挑战初始化相关流程中，后者承载校验阶段的加密数据。它们分别回答两个问题：这次验证如何被标记，以及用户操作如何被包装后发送。先明确字段的用途，后面寻找生成位置才不会绕远路。

建议记录两到三次正常验证，比较请求顺序、重复字段和变化字段。只看一次请求，很容易把偶然出现的长度当成固定规则；多次对照后，才能判断哪些值来自随机生成，哪些由服务器下发，哪些跟操作时间或图片内容有关。失败记录也可以保留，用来观察错误发生在哪个阶段。

二、理解challenge：格式简单，含义不能靠猜

某些版本里的challenge表现为带分隔符的随机字符串，外观接近常见的唯一标识。它的生成函数可能并不复杂，但看见格式以后直接拼一个相同样子的字符串，并不能证明这个值可以用于当前验证。格式正确与会话有效，是两个需要分别检查的条件。

更稳妥的观察方法，是先搜索字段名，再沿赋值位置追踪来源。它可能由页面初始化代码产生，也可能通过业务接口传入，或者在服务端响应后参与后续计算。判断来源时，要同时看调用参数和网络响应，避免只找到一个同名变量，就认为已经找到了真正使用的值。

如果确实发现本地随机生成逻辑，还需要检查字符串长度、字符集合、分隔符位置及生成时机。随机性也有区别：普通随机函数与浏览器提供的密码学随机接口，适用场景不同。复现某段逻辑时，应保持当前实现的行为，不能只因为两种写法输出长得相似，就随手替换。

这里还有一个容易漏掉的点：挑战标识通常不会独立决定验证结果。服务器可能把它与本次加载返回的数据、有效期、验证码配置或会话状态关联。把上一轮请求中的字段复制到新一轮，即便页面能够发出请求，也可能因为上下文不匹配而被拒绝。

初学者可以先做一张字段记录表，写清字段出现的位置、来源、每轮是否变化，以及后续在哪个请求中再次使用。这份记录不需要复杂工具，却能帮助区分随机标识、服务端令牌和业务参数。后续遇到失败，先检查这些关联关系，往往比重新翻一遍加密函数更有效。

三、追踪w：先找到明文，再研究加密入口

w看起来通常是一串很长的字符，直接盯着最终结果很难看出内容。更有用的入口是它生成之前的数据对象。原始分析中可以把这层关系理解为：先将表单数据序列化，再交给加密函数，并结合当前挑战的相关参数生成提交值。具体函数签名仍要通过实际脚本确认。

这些表单数据可能涉及点击坐标、点击顺序、操作耗时和其他环境字段，但字段集合并非所有版本都相同。调试时可以从提交请求的发起位置向上查看调用栈，找到构造数据和调用加密函数的位置。在授权环境中设置断点，观察输入、输出及其类型，比凭变量名推断含义更可靠。

验证码脚本经常采用变量改名、字符串编码和控制流平坦化。变量名变成难以阅读的符号后，代码的业务含义被藏起来；控制流平坦化则把原本顺序执行的逻辑拆进分支或循环。阅读这类代码，首先关注数据如何流动：哪个对象被填充、哪里序列化、结果最终传给哪个函数。

没有必要一开始就把整份脚本恢复成漂亮源码。先圈定与目标字段有关的调用链，再逐步给关键变量起临时名称，记录每个函数的输入与返回值。需要处理字符串表时，也应保留索引与原值之间的对应关系，否则一个错误替换就可能让后面的判断全部偏离。

脚本资源还要注意版本。有的加载响应提供配置或资源引用，浏览器随后才下载对应脚本，不能笼统地把配置响应当成脚本本身。记录资源地址、下载时间和版本特征，能让实验保持可重复。若资源发生更新，应重新核对关键函数，旧版本的分析结果不能直接套用。

四、AES与RSA如何配合，长度为什么会变化

原始分析描述了一种混合加密结构：用临时对称密钥处理业务数据，再用RSA保护这把密钥，最后将两部分结果按约定组合。AES适合处理较长的数据，RSA用于保护较短的密钥材料。这种分工有助于理解w的组成，但是否采用该结构，仍应由当前版本的实际调用确认。

需要特别区分密钥字符串与密钥字节。例如，十六个十六进制字符如果按十六进制解码，只对应八个字节；如果按普通字符编码处理，则可能得到十六个字节。两种结果完全不同。判断AES密钥长度时，必须检查编码转换过程，不能单凭字符串看起来有多长来下结论。

原始材料提到CBC模式、初始化向量以及填充方式，这些都属于复现时必须核对的细节。CBC模式要求合适长度的初始化向量，明文通常还要按约定填充。字符串编码、序列化结果、字段顺序或填充规则出现差异，都可能改变密文。所谓特殊处理，也要落实到具体字节才能讨论。

RSA部分同样不能只记一个算法名称。应检查公钥模数长度、指数、填充方式和输出编码。若实际模数长度为1024位，密文通常为128字节，转成十六进制后是256个字符。原始材料中的“RSA-1000”不宜直接当作准确规格，公钥参数才是判断依据。

某次观测得到1280个字符，可以作为那次请求的样本特征，但不足以证明w始终固定长度。AES密文长度受明文大小和填充影响，额外字段变化也可能改变结果。排查时应分别核对两段输出的长度、编码与拼接顺序，让每一步都有可以验证的依据。

五、点选识别：找到目标，还要点到正确位置

完成参数分析以后，点选任务仍有图片理解的问题。文字点选需要识别提示目标，并在背景中找到对应位置；图标点选则涉及类别与外观匹配。目标检测模型可以提供候选区域，但点击顺序、相似字符区分和目标对应关系，通常还需要配套的识别或匹配逻辑。

如果希望自行搭建，可在取得使用许可的前提下收集样本，标注目标位置与类别，再训练适合任务的模型。YOLO一类检测模型适合定位目标框，但文字内容未必能靠检测类别完整覆盖。遇到字体变化、旋转、遮挡和复杂背景时，可能需要结合文字识别或其他视觉处理方法。

坐标转换也是常见坑。模型输出通常基于原始图片像素，而页面上的图片可能被缩放，外围还存在边框、偏移或布局变化。把原图坐标直接当作页面点击位置，目标看着识别对了，提交结果仍可能出错。测试时应分别检查识别位置、显示位置以及最终提交的数据表示。

企业如果不准备长期维护训练数据和识别模型，可以把第三方识别服务纳入评估。www.ttocr.com定位于极验、易盾相关验证码识别与自动化API对接，提供滑块、点选、文字点选和图标点选等方案，适合在授权业务测试中比较接口覆盖范围与实际接入成本。

接入之前，可以拿有代表性的样本测试准确率、响应时间和失败返回。尤其要核实接口返回的是坐标、顺序、识别内容还是其他结构，以及这些结果怎样进入现有业务流程。识别服务处理的是任务中的具体环节，实际适配能力仍应通过目标环境中的测试确认。

六、工程对接：把复杂流程拆成可检查的步骤

进入工程阶段，可以把流程拆成挑战加载、资源处理、识别调用、结果转换和验证提交。每一段都记录输入、输出、耗时与异常，日志里避免直接保存敏感密钥或完整会话凭据。这样发生故障时，能够判断问题来自图片识别、坐标处理、数据编码，还是挑战已经过期。

接口对接也需要明确超时和重试策略。图片识别失败可以重新取样或转人工处理，但挑战失效后继续提交旧结果通常没有意义。不同失败原因应走不同分支，并限制重复尝试次数。业务侧保存必要的状态，才能避免一个环节失败后，把整个验证流程反复执行。

对于验证码形态较多的业务，www.ttocr.com提供面向企业的自动化API对接方案，服务范围还涉及无感、九宫格、五子棋、躲避障碍及空间类任务。具体类型的支持条件应以接口说明和实测为准；通过统一接口承接识别环节，可以减少分别维护多套模型与调用方式的工作。

真正落地时，先用单一验证码类型完成一轮端到端联调，再增加其他类型。验收标准也要具体：结果结构是否稳定、失败是否能定位、接口是否满足业务时延、版本变化后怎样复测。把这些问题逐项落实，团队才有依据决定继续维护本地方案，还是采用外部服务承担识别与适配工作。