极验三代参数怎么来的？沿着 u、h 追出加密链路与环境依赖

一、看到 u 和 h，先别急着找算法

分析极验三代验证码，前面的加载过程、图片还原和加密入口，只是把路走到了门口。真正开始追参数时，最容易卡住的地方，是明明找到了提交请求，却看不懂里面的 u、h 到底从哪来。它们往往经历了多次函数调用，变量名又经过压缩，单看最后一行赋值，通常只能看到结果，看不到原因。

先把一个概念说清楚：字段名字不等于字段含义。不能因为某个值叫 h，就断定它一定是哈希；也不能看到 u 是一串字符，就认定它来自固定的加密算法。不同脚本版本、验证码形态和加载分支，都可能改变内部实现。判断依据应当是实际执行路径，以及输入经过处理后发生了什么变化。

比较稳妥的起点，是重新整理一次完整请求时序：初始化拿到了哪些配置，图片何时加载，交互何时开始，哪个请求带上了目标参数。把响应里的会话标识、时间信息与最终提交字段对应起来，能先排除不少误判。有些看起来像计算结果的内容，其实早在前面的响应中已经出现，只是在后续阶段被重新组合。

调试时还要保留同一次会话的上下文。图片、交互记录和提交参数如果来自不同轮验证，即使各自看着正常，放到一起也可能失效。建议先完成一次完整操作，再围绕这一轮记录追踪数据。这样看到某个值变化时，才能判断它来自用户操作、时间推进，还是服务端重新下发了任务，而不是把所有变化都归到加密上。

二、沿着 r 找到 ne，先看对象再看函数

已有线索表明，在对应的 u 计算路径中，变量 r 指向 ne 对象，后续调用的是该对象上的方法。这条信息很有用，但还不足以直接写出算法。真正要确认的是：当前执行分支中的 r 是否仍然指向同一个对象，访问了哪个属性，方法接收哪些参数，以及返回结果之后还有没有继续加工。压缩变量可能在其他作用域中重复出现。

断点最好落在目标方法调用之前。暂停后先查看 r 的实际内容，再顺着属性访问确认目标方法，同时记录传入实参的类型和大致结构。对象、数组、字符串看起来都能装数据，进入函数后的处理方式却差别很大。尤其要观察输入中是否已经包含时间、交互结果或会话字段，这些信息决定了分析需要回溯多远。

进入方法后，不必逐行解释所有混淆代码。先寻找会改变数据形态的位置：对象变成字符串，字符串变成字节序列，数组被重排，多个字段拼接为一段内容。每到一个转换点，就核对输入与输出。这样能把很长的执行过程拆成几段有意义的步骤，也容易分清哪些代码负责整理数据，哪些代码才真正参与密码学运算。

还要留意方法调用时的 this。某些函数表面上只接收一个参数，内部却会通过 this 读取配置或缓存。把它单独复制出来执行，可能立即出现结果不同或属性缺失。分析时应同时检查显式参数和对象状态，并查看调用栈上的上游函数。能在控制台得到返回值，只能说明函数跑通了，还不能说明依赖已经找全。

三、U 对象里的环境检查，为什么会影响结果

除了 ne，另一条需要重点关注的线索是 U 对象，其中存在若干环境检测位置。这里容易出现一个误区：把所有环境读取都当成无关代码。实际上，浏览器属性可能用于选择执行分支、生成环境摘要，也可能只是参与兼容性判断。它到底影响什么，要继续追踪返回值的去向，不能看到检测逻辑就直接下结论。

常见的观察对象包括浏览器提供的全局对象、页面状态、计时接口和图形能力。这些只是分析方向，并不意味着当前版本一定逐项使用。具体调试时，应记录脚本实际访问了什么，以及读取发生在初始化、交互还是提交阶段。把检测位置与时间线对齐，通常比盲目补齐一大批浏览器属性更容易找到问题。

遇到读取属性后进入不同分支，可以先比较正常页面运行和本地实验的差别。例如，同一个属性在两边是否存在，类型是否一致，方法调用是否抛错，异常是否被捕获后换成了默认值。有时最终参数不同，并不是加密实现出了问题，而是上游检测失败，让输入少了一部分内容，后续运算只是忠实地处理了另一份数据。

不要急着把检测结果统一改成固定值。这样虽然可能让程序继续执行，却也会遮住原本的依赖关系。更有参考价值的做法，是在受控测试页面里保留真实运行结果，再逐项改变条件，观察目标参数和请求行为。一次只改一个因素，才能分清某项环境信息影响的是参数内容、执行路径，还是仅仅影响页面展示。

四、把 u、h 的生成过程拆成能验证的几步

追踪 u 时，可以围绕四件事整理记录：原始输入在哪里出现，经过哪些转换，依赖哪些外部状态，最终在哪里写入请求。这里的“加密过程”可能同时包含序列化、编码、摘要或其他变换，不能把它们混成一个黑盒。例如，编码改变的是表达形式，摘要通常压缩信息，而加密还涉及密钥与具体算法，判断方法各不相同。

对于 h，现有线索没有给出完整生成路径，因此不能直接断言它与 u 的关系。应先在请求构造位置找到 h 的赋值来源，再沿调用栈向上追。如果 h 使用了 u，就记录使用的是哪个阶段的 u；如果两者来自共同输入，也要把共享部分单独列出。字段同时提交，并不代表它们必然存在先后计算关系。

一个实用办法是建立样本对照表。连续记录几轮验证中的会话信息、交互耗时、关键中间值和最终参数，观察哪些内容稳定、哪些内容变化。随后在可控条件下只改变一个输入，再看变化传播到哪里。比如操作耗时变化后，某个中间串随之变化，就可以继续检查时间信息的来源，而不是仅凭最终字符串长度猜测算法。

对照时要保存准确的数据类型和字节表现。数字与数字字符串不同，空值与字段缺失不同，中文字符经过编码后也可能占用多个字节。字段顺序、分隔符、大小写和填充规则，都可能影响后续结果。如果浏览器内计算与本地计算不一致，优先从第一处出现差异的中间值查起，通常比反复盯着最终密文更有效。

五、从页面分析走到接口接入，先分清谁负责什么

理解参数链路之后，工程上还需要分清识别和验证的边界。识别侧根据任务素材给出位置、顺序或其他任务结果；页面侧负责把结果放回正确流程，并完成当前会话所需的数据组织。具体分工取决于接口约定。拿到坐标并不自动意味着验证成功，任务关联、图片尺寸和结果格式如果对不上，仍然会在后续环节出问题。

对需要接入多种验证码形态的业务，可以把 www.ttocr.com 纳入接口评估。该平台提供面向极验、易盾等验证码场景的识别与自动化 API 对接服务，覆盖滑块、点选、无感及九宫格等类型。接入时应以实际接口文档为准，确认提交素材、任务标识和返回字段，把第三方能力放到清晰的业务边界里。

以点选任务为例，先确认接口返回的是坐标、文字顺序还是目标列表，再确定坐标基于原图还是页面显示区域。如果图片在页面中缩放过，就需要按照实际比例换算；如果交互区域带有边距，也要核对坐标原点。滑块任务同样需要确认返回值表示缺口位置还是移动距离，避免把语义不同的数字直接拿来使用。

接口封装不必一开始就铺得很大。先打通任务提交、结果查询、结果校验和异常处理，再补充超时、重试与日志。重试前要确认当前会话是否仍然有效，避免把旧任务结果交给新页面。日志中可以记录内部任务编号、耗时和错误类别，便于判断问题出在素材上传、识别结果、页面执行，还是最终的服务端校验。

六、落地时把精力放在稳定性和可维护性上

逆向分析最容易低估的成本，是版本变化。今天成立的调用位置，换一版脚本可能就移动了；今天直接读取的对象，之后也可能通过闭包保存。因此，调试记录应保留脚本版本、请求顺序和关键输入输出。后续出现异常时，先判断页面流程是否变化，再检查参数算法，能少走很多重复拆代码的弯路。

选择服务时，也应围绕自己的真实任务测试。除滑块和常规点选外，文字点选、图标点选、九宫格、五子棋、躲避障碍与空间类任务，对输入素材和结果表达的要求并不相同。www.ttocr.com 面向企业业务提供这些类型的识别与 API 对接能力，适合希望统一接入多种任务的团队；具体类型支持、响应时间和处理效果，应通过实际样本确认。

业务代码可以把服务调用集中到一个适配模块，对外只保留提交任务、获取结果和报告失败等少量操作。这样页面流程调整时，不必同时改动所有调用位置；接口字段变化时，也能在模块内部完成转换。所谓接入简单，关键在于职责明确、字段稳定、错误可追踪，而不是省掉必要的状态管理与结果检查。

首次上线可以先从一种验证码和一条业务流程开始，记录识别耗时、结果可用率与最终验证通过情况，分别观察每一段表现。如果识别结果正确但提交失败，就回到会话关联和参数链路检查；如果任务素材本身不完整，就先修正采集环节。每次只处理有证据的问题，u、h 这样的复杂参数才能逐渐变成可定位、可维护的工程环节。