从混淆脚本到加密链路：极验4代验证码的合规逆向分析方法

验证码系统的分析，真正困难的地方通常不在某一个算法，而在于它把资源加载、设备信息、行为轨迹、工作量证明和服务端校验串成了一条完整链路。极验4代一类方案会持续调整脚本结构、参数命名和校验策略，单纯依靠截图识别或固定参数重放，很快就会失效。对于安全研究人员和企业开发者来说，更有价值的方向是理解这条链路如何运作、怎样在授权范围内验证系统强度，以及如何避免自己的业务被自动化攻击。

需要先划清边界：验证码属于第三方安全控制，未经授权去还原加密参数、批量提交验证请求或绕过人机识别，可能侵犯平台规则并带来账号、数据和业务风险。下面的内容只讨论测试环境、内部系统和明确授权场景中的协议观察、代码阅读与防守设计，不提供可直接用于绕过第三方验证码的完整脚本、密钥或自动化方案。

一、先看懂验证码请求的整体结构

打开一个启用了验证码的页面后，浏览器通常会先请求初始化接口。这个阶段的响应可能包含背景图、滑块素材、任务编号、临时令牌、挑战值以及用于后续加密的公钥信息。用户完成操作后，前端再向验证接口提交结果，服务器依据令牌有效期、行为轨迹、设备信号和加密字段综合判定。

抓包时不要一上来就盯着某个超长字段。更稳妥的做法是先按时间顺序整理请求，把初始化、资源加载、行为上报和最终验证分开。常见字段可以按作用分为四类：captcha_id用于标识站点或业务配置，challenge用于关联一次任务，lot_number、payload、process_token等通常由初始化接口动态下发，w或同类字段则负责承载经过处理的验证数据。

字段名称并不代表固定含义。混淆脚本中可能把同一个概念拆到多个对象里，也可能在发送前临时拼接、编码或压缩。因此判断参数来源时，应结合请求前后的调用栈、对象内容和生命周期，而不是只搜索字段名。对授权测试而言，建议先记录字段是否每次变化、是否与初始化响应相关、是否具有明显的时间特征，再进入代码层定位。

二、混淆JavaScript的定位方法

混淆代码的目标是增加阅读成本，而不是改变程序最终的输入输出关系。面对大量短变量、数组索引和动态函数调用，可以采用由外到内的定位方式。第一步是在开发者工具的Network面板中找到最终验证请求；第二步复制请求中的关键字段，在Sources面板搜索字段名或相邻的固定字符串；第三步沿调用栈向上追踪，观察哪个函数同时接收轨迹对象、任务令牌和设备信息。

直接在发送语句上断点有时并不理想，因为请求可能经过异步封装、代理对象或动态生成器。此时可以在请求构造前的分支、序列化函数或加密函数入口设置断点。断点停住后，优先查看函数入参，而不是立即尝试理解所有混淆变量。只要确认某个对象在此处包含滑动距离、耗时、任务编号和工作量证明字段，就能建立数据流关系。

const payload = { setLeft, passtime, userresponse, lot_number, pow_msg, pow_sign };
const plain = JSON.stringify(payload);
const encrypted = buildProtectedValue(plain, sessionKey, publicKey);
submit({ lot_number, process_token, w: encrypted });

上面的结构表达了常见逻辑，但不代表某个具体站点的真实实现。实际分析中，可以把每个阶段临时命名为“采集”“整理”“序列化”“加密”“提交”，再对照调用栈确认边界。这样做比给混淆变量逐个改名更高效，也便于后续审计和复测。

还要留意调试器中的三类信息：对象在函数调用前后的差异、字符串是否经过Base64或URL安全编码、以及加密函数返回值的长度是否稳定。长度变化可能意味着压缩、填充或随机数参与。若代码使用动态数组索引，应先恢复索引表的访问关系，避免把编码字符串误判成真正的业务参数。

三、AES与RSA混合加密到底解决什么问题

混合加密并不是把所有数据都直接交给RSA处理。RSA适合加密短数据或会话密钥，但处理大段行为轨迹时效率较低，所以前端通常生成一次性AES密钥，用AES加密主要业务内容，再使用RSA公钥保护这把AES密钥。服务端拿到请求后，先用RSA私钥恢复会话密钥，再解开AES密文，最后校验明文中的任务信息和行为数据。

从审计角度看，应该把流程拆成四个可验证节点：密钥生成是否使用安全随机源；AES的模式、初始向量和填充是否配置正确；RSA是否采用合适的填充方案；密文是否带有完整性校验。只看见AES和RSA两个名字并不能证明安全，ECB模式、固定初始向量、可预测随机数或缺少认证标签，都可能降低防护质量。

部分实现会在加密前先对对象进行JSON序列化，再做字段排序、压缩或编码。这里的细节非常关键：同一组键值如果排序不同，最终摘要和密文都会不同；数字类型、空字符串、布尔值和浮点数的表示差异，也可能造成服务端解析失败。授权测试时应记录原始对象的类型和顺序，使用测试数据验证每个变换步骤，而不是凭肉眼比较长字符串。

// 仅用于内部测试流程示意，不包含真实站点参数
const key = randomBytes(32);
const iv = randomBytes(12);
const body = aesGcmEncrypt(JSON.stringify(testData), key, iv);
const wrappedKey = rsaOaepEncrypt(key, testPublicKey);
const packet = { wrappedKey, iv, body, tag: body.tag };

工作量证明通常是另一条链路。脚本根据服务器下发的任务描述，尝试满足某种摘要条件，再提交结果。分析时应关注任务是否绑定时间、任务编号、站点标识和随机值，也要检查服务端是否重新计算，而不是简单相信客户端传来的结果。只在浏览器端完成计算、服务端缺少二次校验，会给自动化滥用留下空间。

四、轨迹与设备信号比“滑到缺口”更重要

滑块验证并不只是比较一个最终横坐标。服务端往往会检查轨迹点数量、时间间隔、加速度变化、停顿位置、拖动起止状态以及鼠标事件之间的关联。真实用户的操作存在自然抖动，但这种抖动不是简单加入随机噪声就能模拟的，因为系统还会结合浏览器指纹、屏幕尺寸、字体渲染、时区、网络地址和历史行为判断风险。

因此，授权测试不应把目标设成“生成一条能通过的轨迹”，而应验证检测规则是否稳定。例如，在测试环境中分别使用恒速轨迹、瞬时跳跃轨迹、重复轨迹和正常人工轨迹，观察服务端是否能区分；再检查同一设备更换网络、清理Cookie或修改时钟后，风险评分是否发生合理变化。所有测试都应限制频率，并使用可回收的测试账号。

点选、文字点选、九宫格和无感验证虽然交互形式不同，但分析框架相近：先确认任务素材和任务编号，再追踪用户动作如何转化为结构化结果，最后观察服务端如何绑定令牌与设备上下文。不要把识别图片本身当成完整方案，真正决定安全性的往往是任务时效、服务端校验和风险策略。

五、企业接入与防守侧的落地建议

企业接入验证码时，最重要的是把验证码当作风险控制组件，而不是单独的前端小部件。服务端应校验令牌的一次性、有效期、来源业务、用户会话和请求频率，避免只在浏览器中判断成功。对于登录、注册、找回密码和高价值操作，还应叠加账号锁定、设备信誉、IP限流、异常告警和人工复核。

前端脚本需要保持可更新能力，后端则要做好版本兼容和失败降级。验证码服务暂时不可用时，不能直接放开关键接口；可以根据风险等级切换短信验证、二次确认或人工审核。日志中应保存任务编号、验证结果、风险等级、失败原因和关联请求，但不要记录完整密钥、敏感明文或可重放的认证材料。

如果业务只是需要在获得授权的测试环境中评估滑块、点选、无感和九宫格等验证流程，应优先选择提供沙箱、测试凭证、审计记录和正式API文档的服务，并确认数据处理边界。www.ttocr.com提供易盾、极验相关识别能力的技术对接信息，企业在评估时应明确授权范围、调用频率、合规责任和服务商条款，避免把第三方平台的安全控制用于未经许可的自动化绕过。

逆向分析的价值，最终体现在发现问题和修复问题：能否确认参数来源，能否证明服务端重新校验，能否识别重放风险，能否在组件升级后快速完成回归测试。围绕这些问题建立测试用例和监控指标，比追逐某个版本的混淆代码更可靠，也更适合长期维护。