做爬虫和自动化测试的早晚都会撞上hcaptcha这堵墙。它和传统验证码完全不是一路玩法前端铺了大量埋点后端拆成配置下发、任务下发、校验提交三段式异步链路任何一步缺了关键参数返回的就是一句冷冰冰的error或fail。我刚开始接触时也犯过傻以为就是简单的图片点选后来把API链路拆开才明白真正的难点全在参数构造。这篇文章想把hcaptcha逆向的完整链路讲清楚从API解析入手到关键参数怎么构造再到反复踩坑后沉淀下来的排错清单。适合三类人一是做授权安全测试的朋友二是想搞懂验证码协议的前后端同学三是在自动化测试里被hcaptcha卡住的工程师。先说好所有内容都只围绕受控环境和个人学习展开别拿去做未授权站点的批量注册。1. 项目背景与整体思路1.1 hcaptcha为什么难缠hcaptcha 是 Intuition Machines 推出的验证码服务大量被 Cloudflare 生态和各类高防站点引用。它和旧式图形验证码最大的区别在于你看到的图片点选只是表面交互服务端真正校验的是一整套环境信号和请求时序。拆开看难缠在三点。第一点是触发机制复杂。hcaptcha 会根据访问者的 IP 信誉、浏览器指纹、操作轨迹决定出题难度。有时候放一个勾选框就算过有时候连续出三四张图这背后是服务端对信任度的实时打分。所以你在本地一秒钟生成请求和真人正常访问的行为模式明显不同评分一低题目立刻变难。第二点是参数链路长。从页面加载到最终拿到 token中间至少要经过配置下发、任务下发、校验提交三段请求每一段都携带大量前端采集的数据。这些数据有的明文有的加密。只有把整条链路理顺才知道哪一步该带什么。第三点是更新频繁。hcaptcha 的前端 JS 打包产物和参数结构经常微调。今天能跑通的字段拼法可能下周就 400。这也是视频教程类的逆向分享往往活不过一个月的原因。真正能沉淀下来的不是某段具体代码而是分析链路的方法。1.2 逆向项目的技术选型与总体拆解接到一个 hcaptcha 相关的逆向需求我习惯先问自己三个问题目标是协议复现还是要稳定拿到 token周围环境是否完全可控允许引入多少自动化组件这三个问题的答案决定了技术路线。如果是纯学习协议思路应该聚焦在 API 解析上。用浏览器 DevTools 或抓包工具记录完整请求逐条理解字段含义再用 Python 脚本逐段复现请求。这种方式不追求全程无人干预但能最快速度理清链路。如果是自动化测试场景我的建议是半自动方案用 Playwright 驱动真实浏览器完成交互同时拦截关键请求、观察参数构成再在必要时用脚本补充心跳和会话维持。这种做法对参数构造的压力小很多稳定性也更高。如果是安全评估类项目那就必须拿到授权并且在隔离环境中做。重点分析的是请求中哪些参数可以被伪造、哪些参数和会话绑定、服务端校验的强弱在哪而不是去批量生成 token。总体拆解下来hcaptcha 逆向可以分成四个阶段链路解析、字段理解、参数构造、回放验证。下面的内容就是按这四个阶段展开的实战记录。2. API通信流程解析2.1 从页面加载到token生成的请求链我习惯先用 DevTools 里的 Network 面板过一遍完整流程按时间顺序把请求记录下来。hcaptcha 的通信链路大致是这样跑的页面加载 hcaptcha 的 api.js通常是https://hcaptcha.com/1/api.js?renderexplicit这类地址。api.js 在当前页面插入一个 iframeiframe 指向https://hcaptcha.com/captcha?sitekeyxxxhostxxx等参数拼接的地址。这个 iframe 里跑的是真正的验证码交互页面。iframe 加载完成后会请求checksiteconfig接口用来向服务端确认当前 sitekey 和 host 组合是否合法顺便拿一些前端配置。用户点击勾选框或者自动触发后前端请求getcaptcha接口获取具体的验证任务。这里会带上 sitekey、host、motionData 等参数。如果是图片任务用户完成点选后前端把答案和一堆行为数据整理好请求checkcaptcha接口进行校验。校验通过后hcaptcha 会返回一个 token通常以P1_开头。失败则返回E0_开头或类似标识。这个 token 交回目标网站的前端再由目标网站后端调用siteverify接口二次校验确认 token 有效且未被使用过。第 7 步非常重要。也就是说就算你逆向拿到了 hcaptcha token也只能交给目标网站的后端由它去 hcaptcha 那边验真。单纯在本地生成一个 token 是绕不过服务端最终验证的这也是 hcaptcha 比普通前端验证码硬核的根本原因。整个链路里getcaptcha和checkcaptcha是两个核心接口也是参数构造的大头。前端绝大部分埋点数据都集中在这两个请求里。2.2 关键端点的请求与响应字段以我最近一次在测试环境抓到的请求为例getcaptcha的请求体大概是这个结构{ sitekey: b3a8d8b8-..., host: test.example.com, hl: zh, motionData: eyJ0eXBlIjoidjIiLCJzdGFydCI6MTY5OT..., v0: 1, c: checkcaptcha所需的关联数据 }注意不同版本字段略有差别有的会多出stoken有的把c放在 query string 里。字段名必须以你当次抓包为准别硬套别人的模板。getcaptcha的响应同样有版本差异。我遇到过的典型响应包含{ c: hsw或任务相关的key, expiration: 120, generated_pass_uuid: false, job: 任务标识, pass: false, request_type: image, requested_for: ..., timestamp: ... }如果request_type是image响应里还会带tasklist里面有图片地址和切割信息。这个job和c后续在checkcaptcha阶段要原样带回可以理解成服务端发给你的一张“任务凭证”。checkcaptcha请求体大致长这样{ sitekey: b3a8d8b8-..., host: test.example.com, hl: zh, job: 任务标识, c: 从getcaptcha响应里提取的关联数据, v0: 1, motionData: ..., answers: { task_key_1: [3, 1] } }answers是图片点选任务的选择坐标或区块编号具体格式取决于任务类型。校验通过后响应里会出现pass: true和一把 token。这个 token 就是整个验证码流程的最终产出。理解这张请求链后我在表格里做了一层整理方便自己后续复盘时快速回忆。阶段端点作用关键参数配置下发checksiteconfig确认 sitekey/host 合法性sitekey, host任务下发getcaptcha获取验证任务sitekey, host, motionData, c校验提交checkcaptcha提交答案与行为数据job, c, answers, motionData后端验真siteverify服务端二次校验 tokensecret, response token3. 核心参数构造细节3.1 站点标识类参数sitekey是网站公开的验证码标识直接写在目标页面的 HTML 里随便一搜就能看到。host是当前域名它必须与 sitekey 的绑定域名一致否则接口直接报错。这两个参数本身不算复杂真正的坑在于hcaptcha 服务端会把sitekey host 用户IP 浏览器指纹组合成一个信任模型。同样的参数组合在不同 IP 和环境下的难度天差地别。因此在实际构造请求时不建议只用静态参数硬刷。更好的做法是让参数和真实环境保持“同源”。简单说就是从哪个页面拿到的 sitekey就尽量用对应域名的 host环境信息也保持一致。千万不要在本地起一个服务去请求生产环境的 sitekey然后指望它给你一个 pass。hl是语言标识v0是版本标识这两个字段相对固定。我一般保持和正常浏览器抓包一致不做特殊构造。3.2 行为数据与motionDatamotionData是 hcaptcha 前端采集的用户行为数据通常是鼠标移动轨迹、点击坐标、停留时间、事件时间戳等信息的编码结果。新版里 data 类型在不同任务下可能不同。从排查经验看hcaptcha 对行为数据的最低要求是“合理”。所谓合理包括轨迹点与点之间的时间间隔符合人类操作习惯鼠标移动路径不是两端点之间的直线匀速按下、抬起、点击事件顺序正确整体耗时在几秒到几十秒范围内而不是毫秒级完成。如果你用脚本伪造 motionData最容易翻车的就是时间戳和坐标逻辑。我见过一个案例伪造的数据里鼠标从屏幕左下角到右下角只花了 200 毫秒还是一条直线服务端检测到这种轨迹后直接判决为机器人。后来把轨迹改成带噪声的贝塞尔曲线并加入停顿和微小回退才勉强通过基础检测。需要说明的是我建议优先用 Playwright 这类工具驱动真实浏览器生成 motionData而不是手工伪造。真实交互产生的数据有内在随机性比任何模仿算法都自然。手工伪造只能作为协议理解的学习手段很难应对生产级别校验。3.3 加密参数c与整体签名思路c参数是 hcaptcha 逆向里最劝退的一环。它是个加密串看起来像随机字符实际内部封装了任务状态、前端环境信息、部分行为指纹等数据。在不同阶段c的来源和含义不一样在getcaptcha阶段c可能携带一些前置的会话数据如果为空也可能不传。在checkcaptcha阶段c通常来自getcaptcha响应的c字段需要回传。也就是说c本质上是一个由服务端发出、前端加工后再返回的状态凭证。服务端通过解密c来核对任务的合法性、时效性和来源一致性。想完全逆出c的加密算法需要做前端 JS 的断点调试和算法还原工作量非常大而且 hcaptcha 更新频繁今天还原的算法明天可能就失效。从工程角度我更推荐把c视为“不可手工构造参数”采用黑盒方式处理从真实环境拿到什么c原样保存、原样回传只在字段级别做拼接。这种方式听起来不够炫但实战中稳定性最高。逆向的目标是让链路可解释、可复现不是非要手写加密算法不可。很多宣称能破解 hcaptcha 的收费服务底层也大量依赖真实浏览器环境来获取关键参数。4. 实操过程与核心环节实现4.1 环境准备与抓包定位先说环境。我用的工具组合是Python 3.10 httpx Playwright抓包用 Chrome DevTools 和 mitmproxy 配合。如果只观察 hcaptcha 自身的请求DevTools 就够用了过滤域名hcaptcha.com即可。具体抓包步骤打开目标测试页面提前清空所有缓存和 Cookie。打开 DevTools 的 Network 面板勾选 Preserve log。触发验证码交互最好等到 iframe 加载完成后再操作避免漏掉早期请求。点击验证码完成后把 Network 面板里所有hcaptcha.com请求导出成 HAR 文件。用文本编辑器或者在线工具打开 HAR按照时间顺序逐条核对请求和响应。这里有个小技巧搜索框输入getcaptcha可以直接定位到任务下发请求。点开左侧的请求记录右侧能看到 payload 和 response。别嫌麻烦把所有字段都整理到本地笔记里标注来源后面构造请求时就是一本字典。4.2 用脚本复现getcaptcha请求链路理解透之后第一步就是脚本化复现getcaptcha请求。这一步风险低、反馈快非常适合作为起点。下面是一个基础的请求示例目的是观察返回结构不涉及最终 token 生成import httpx url https://hcaptcha.com/getcaptcha payload { sitekey: b3a8d8b8-0000-0000-0000-000000000000, host: test.example.com, hl: zh, motionData: e30, # base64编码的{}仅用于观察响应 } headers { User-Agent: ( Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36 ), Content-Type: application/json, Accept: application/json, Origin: https://newassets.hcaptcha.com, Referer: https://newassets.hcaptcha.com/, } with httpx.Client(http2True, timeout15) as client: resp client.post(url, jsonpayload, headersheaders) print(resp.status_code) print(resp.text)跑完之后把输出和抓包响应做一个 diff。正常情况下字段结构应该一致只是timestamp、job这类动态值不同。如果出现 400 或 error优先检查是不是缺少了 Cookie 相关参数或者motionData格式不对。这一步的意义是验证你抓包时看到的请求体不是前端临时拼的而是一个可以被外部客户端复现的标准 HTTP 接口调用。能复现这个请求后面的checkcaptcha才有进行下去的基础。4.3 从请求复现到token校验的半自动方案要拿到最终 token纯手工构造所有参数很不现实。我个人在项目里最常用的方案是“半自动 参数回填”。思路是这样的用 Playwright 打开目标页面正常触发 hcaptcha。在页面上下文里注入一段脚本用PerformanceObserver或重写XMLHttpRequest/fetch捕获checkcaptcha的请求参数。把捕获到的c、job、motionData等参数保存下来转交给外部脚本做后续处理。外部脚本复现请求拿到 token 后返回给测试流程。这段捕获逻辑可以简写成from playwright.sync_api import sync_playwright captured {} def handle_request(request): if checkcaptcha in request.url and request.method POST: post_data request.post_data_json captured[payload] post_data captured[url] request.url with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page() page.on(request, handle_request) page.goto(https://test.example.com/protected-page) # 手动或自动完成验证码交互 page.wait_for_timeout(30000) browser.close() print(captured)拿到真实的checkcaptcha请求后再回到 Python 脚本里做回放。这一套流程最大的好处是不需要理解c的加密细节也不需要手工构造行为数据所有复杂参数都由浏览器环境原生生成脚本只负责记录和重放。对学习协议和做授权测试来说这个精度完全够用。5. 常见问题与排查技巧实录5.1 高频报错对照表下面这些错误是我在实际调试里高频遇到的整理成表格方便直接对照。报错现象可能原因排查方向400 missing inputJSON 字段缺失对比抓包 payload逐字段补齐400 invalid sitekeysitekey 不存在或 host 不匹配检查参数是否从页面动态读取403 forbiddenIP 信誉低或环境标记明显更换纯净测试环境清理指纹timeout任务已过期检查expiration字段控制回放间隔fail / E0 token行为数据异常或答案错误检查 motionData 合理性确认 answers 对应关系cannot verifytoken 被重复使用或过期siteverify 失败和逆向请求无关需重新走流程最坑的不是 400而是看起来 200、其实返回 fail。这种情况说明网络链路没问题是参数里的行为特征被服务端判了死刑。优先检查 motionData 和 c 是否来自同一个浏览器会话不要从 A 页面拿 c、从 B 页面拿 motionData混搭必挂。5.2 工程中容易翻车的四个细节先说 TLS 指纹。hcaptcha 的服务端对客户端指纹的感知非常敏感。用纯 requests 库发起请求即使 headers 伪装得再像浏览器TLS 握手特征也会暴露。我实测下来httpx 开启 HTTP/2 的支持会好很多或者直接用curl_cffi这类自带浏览器 TLS 指纹的客户端。如果你的请求返回的报错和正常浏览器完全不一致先怀疑这一层。再一个细节是 Cookie 管理。hcaptcha 会在前后端请求之间种下若干hc_开头的 Cookie比如hc_session、hc_ak等。这些 Cookie 参与会话状态管理如果复现请求时没有正确携带服务端会认为这不是同一个会话。解决办法是用真实浏览器环境预置 Cookie并把 Cookie 保存下来后续每次请求都带上。第三个细节是任务过期。getcaptcha返回的数据里有expiration通常只有几十到一百多秒。很多人先把请求参数保存到数据库过一会儿再回放结果一梭子全部 timeout。正确做法是拿到参数后立即提交或者设计自动重试机制在任务过期前重新拉取。第四个细节是版本差异。hcaptcha 的c结构和motionData格式在不同版本之间有差异甚至同一时间段的不同站点都可能拿到不同结构。网上教程里的参数模板只能作为参考必须从自己当前环境的抓包结果出发。我的习惯是每轮调试前先重新抓包把字段结构和最新代码对齐避免拿旧模板硬套新接口。5.3 合规边界与最后的提醒这节我必须多说几句。hcaptcha 逆向分析和绕过的边界其实很清晰授权测试、个人学习、漏洞研究、自动化回归测试都是合理的场景。但在未授权站点上批量生成 token、绕过验证码做注册或爬取轻则违反服务条款重则涉及法律风险。文章里所有示例我都刻意保持在协议解析和受控环境复现的范围内没有提供可用于批量生成 token 的完整工具。从技术角度看我强烈建议把重点放在理解协议和提升调试能力上而不是追求一个“全自动破解”脚本。hcaptcha 的防护体系是动态的今天跑通的脚本明天就可能失效唯一保值的能力是你对链路的理解、对字段的敏感度、对排错的熟练度。我个人在实际操作中的体会是逆向这类验证码耐心比技巧重要。别想着一步到位先把抓包数据整理成自己的字典再逐段复现最后再考虑自动化。这个过程虽然慢但每走一步你对这套防护体系的理解都会深一层。等链路全部跑通回头再看你收获的绝不仅仅是一个能过验证码的脚本而是一套通用的协议分析能力这套能力放到任何别的前端风控体系上照样能用。 
长河君 · 2026/9/17 12:49:27 · 阅读 1.2k hcaptcha逆向实战：从API链路解析到参数构造与排错清单
做爬虫和自动化测试的早晚都会撞上hcaptcha这堵墙。它和传统验证码完全不是一路玩法前端铺了大量埋点后端拆成配置下发、任务下发、校验提交三段式异步链路任何一步缺了关键参数返回的就是一句冷冰冰的error或fail。我刚开始接触时也犯过傻以为就是简单的图片点选后来把API链路拆开才明白真正的难点全在参数构造。这篇文章想把hcaptcha逆向的完整链路讲清楚从API解析入手到关键参数怎么构造再到反复踩坑后沉淀下来的排错清单。适合三类人一是做授权安全测试的朋友二是想搞懂验证码协议的前后端同学三是在自动化测试里被hcaptcha卡住的工程师。先说好所有内容都只围绕受控环境和个人学习展开别拿去做未授权站点的批量注册。1. 项目背景与整体思路1.1 hcaptcha为什么难缠hcaptcha 是 Intuition Machines 推出的验证码服务大量被 Cloudflare 生态和各类高防站点引用。它和旧式图形验证码最大的区别在于你看到的图片点选只是表面交互服务端真正校验的是一整套环境信号和请求时序。拆开看难缠在三点。第一点是触发机制复杂。hcaptcha 会根据访问者的 IP 信誉、浏览器指纹、操作轨迹决定出题难度。有时候放一个勾选框就算过有时候连续出三四张图这背后是服务端对信任度的实时打分。所以你在本地一秒钟生成请求和真人正常访问的行为模式明显不同评分一低题目立刻变难。第二点是参数链路长。从页面加载到最终拿到 token中间至少要经过配置下发、任务下发、校验提交三段请求每一段都携带大量前端采集的数据。这些数据有的明文有的加密。只有把整条链路理顺才知道哪一步该带什么。第三点是更新频繁。hcaptcha 的前端 JS 打包产物和参数结构经常微调。今天能跑通的字段拼法可能下周就 400。这也是视频教程类的逆向分享往往活不过一个月的原因。真正能沉淀下来的不是某段具体代码而是分析链路的方法。1.2 逆向项目的技术选型与总体拆解接到一个 hcaptcha 相关的逆向需求我习惯先问自己三个问题目标是协议复现还是要稳定拿到 token周围环境是否完全可控允许引入多少自动化组件这三个问题的答案决定了技术路线。如果是纯学习协议思路应该聚焦在 API 解析上。用浏览器 DevTools 或抓包工具记录完整请求逐条理解字段含义再用 Python 脚本逐段复现请求。这种方式不追求全程无人干预但能最快速度理清链路。如果是自动化测试场景我的建议是半自动方案用 Playwright 驱动真实浏览器完成交互同时拦截关键请求、观察参数构成再在必要时用脚本补充心跳和会话维持。这种做法对参数构造的压力小很多稳定性也更高。如果是安全评估类项目那就必须拿到授权并且在隔离环境中做。重点分析的是请求中哪些参数可以被伪造、哪些参数和会话绑定、服务端校验的强弱在哪而不是去批量生成 token。总体拆解下来hcaptcha 逆向可以分成四个阶段链路解析、字段理解、参数构造、回放验证。下面的内容就是按这四个阶段展开的实战记录。2. API通信流程解析2.1 从页面加载到token生成的请求链我习惯先用 DevTools 里的 Network 面板过一遍完整流程按时间顺序把请求记录下来。hcaptcha 的通信链路大致是这样跑的页面加载 hcaptcha 的 api.js通常是https://hcaptcha.com/1/api.js?renderexplicit这类地址。api.js 在当前页面插入一个 iframeiframe 指向https://hcaptcha.com/captcha?sitekeyxxxhostxxx等参数拼接的地址。这个 iframe 里跑的是真正的验证码交互页面。iframe 加载完成后会请求checksiteconfig接口用来向服务端确认当前 sitekey 和 host 组合是否合法顺便拿一些前端配置。用户点击勾选框或者自动触发后前端请求getcaptcha接口获取具体的验证任务。这里会带上 sitekey、host、motionData 等参数。如果是图片任务用户完成点选后前端把答案和一堆行为数据整理好请求checkcaptcha接口进行校验。校验通过后hcaptcha 会返回一个 token通常以P1_开头。失败则返回E0_开头或类似标识。这个 token 交回目标网站的前端再由目标网站后端调用siteverify接口二次校验确认 token 有效且未被使用过。第 7 步非常重要。也就是说就算你逆向拿到了 hcaptcha token也只能交给目标网站的后端由它去 hcaptcha 那边验真。单纯在本地生成一个 token 是绕不过服务端最终验证的这也是 hcaptcha 比普通前端验证码硬核的根本原因。整个链路里getcaptcha和checkcaptcha是两个核心接口也是参数构造的大头。前端绝大部分埋点数据都集中在这两个请求里。2.2 关键端点的请求与响应字段以我最近一次在测试环境抓到的请求为例getcaptcha的请求体大概是这个结构{ sitekey: b3a8d8b8-..., host: test.example.com, hl: zh, motionData: eyJ0eXBlIjoidjIiLCJzdGFydCI6MTY5OT..., v0: 1, c: checkcaptcha所需的关联数据 }注意不同版本字段略有差别有的会多出stoken有的把c放在 query string 里。字段名必须以你当次抓包为准别硬套别人的模板。getcaptcha的响应同样有版本差异。我遇到过的典型响应包含{ c: hsw或任务相关的key, expiration: 120, generated_pass_uuid: false, job: 任务标识, pass: false, request_type: image, requested_for: ..., timestamp: ... }如果request_type是image响应里还会带tasklist里面有图片地址和切割信息。这个job和c后续在checkcaptcha阶段要原样带回可以理解成服务端发给你的一张“任务凭证”。checkcaptcha请求体大致长这样{ sitekey: b3a8d8b8-..., host: test.example.com, hl: zh, job: 任务标识, c: 从getcaptcha响应里提取的关联数据, v0: 1, motionData: ..., answers: { task_key_1: [3, 1] } }answers是图片点选任务的选择坐标或区块编号具体格式取决于任务类型。校验通过后响应里会出现pass: true和一把 token。这个 token 就是整个验证码流程的最终产出。理解这张请求链后我在表格里做了一层整理方便自己后续复盘时快速回忆。阶段端点作用关键参数配置下发checksiteconfig确认 sitekey/host 合法性sitekey, host任务下发getcaptcha获取验证任务sitekey, host, motionData, c校验提交checkcaptcha提交答案与行为数据job, c, answers, motionData后端验真siteverify服务端二次校验 tokensecret, response token3. 核心参数构造细节3.1 站点标识类参数sitekey是网站公开的验证码标识直接写在目标页面的 HTML 里随便一搜就能看到。host是当前域名它必须与 sitekey 的绑定域名一致否则接口直接报错。这两个参数本身不算复杂真正的坑在于hcaptcha 服务端会把sitekey host 用户IP 浏览器指纹组合成一个信任模型。同样的参数组合在不同 IP 和环境下的难度天差地别。因此在实际构造请求时不建议只用静态参数硬刷。更好的做法是让参数和真实环境保持“同源”。简单说就是从哪个页面拿到的 sitekey就尽量用对应域名的 host环境信息也保持一致。千万不要在本地起一个服务去请求生产环境的 sitekey然后指望它给你一个 pass。hl是语言标识v0是版本标识这两个字段相对固定。我一般保持和正常浏览器抓包一致不做特殊构造。3.2 行为数据与motionDatamotionData是 hcaptcha 前端采集的用户行为数据通常是鼠标移动轨迹、点击坐标、停留时间、事件时间戳等信息的编码结果。新版里 data 类型在不同任务下可能不同。从排查经验看hcaptcha 对行为数据的最低要求是“合理”。所谓合理包括轨迹点与点之间的时间间隔符合人类操作习惯鼠标移动路径不是两端点之间的直线匀速按下、抬起、点击事件顺序正确整体耗时在几秒到几十秒范围内而不是毫秒级完成。如果你用脚本伪造 motionData最容易翻车的就是时间戳和坐标逻辑。我见过一个案例伪造的数据里鼠标从屏幕左下角到右下角只花了 200 毫秒还是一条直线服务端检测到这种轨迹后直接判决为机器人。后来把轨迹改成带噪声的贝塞尔曲线并加入停顿和微小回退才勉强通过基础检测。需要说明的是我建议优先用 Playwright 这类工具驱动真实浏览器生成 motionData而不是手工伪造。真实交互产生的数据有内在随机性比任何模仿算法都自然。手工伪造只能作为协议理解的学习手段很难应对生产级别校验。3.3 加密参数c与整体签名思路c参数是 hcaptcha 逆向里最劝退的一环。它是个加密串看起来像随机字符实际内部封装了任务状态、前端环境信息、部分行为指纹等数据。在不同阶段c的来源和含义不一样在getcaptcha阶段c可能携带一些前置的会话数据如果为空也可能不传。在checkcaptcha阶段c通常来自getcaptcha响应的c字段需要回传。也就是说c本质上是一个由服务端发出、前端加工后再返回的状态凭证。服务端通过解密c来核对任务的合法性、时效性和来源一致性。想完全逆出c的加密算法需要做前端 JS 的断点调试和算法还原工作量非常大而且 hcaptcha 更新频繁今天还原的算法明天可能就失效。从工程角度我更推荐把c视为“不可手工构造参数”采用黑盒方式处理从真实环境拿到什么c原样保存、原样回传只在字段级别做拼接。这种方式听起来不够炫但实战中稳定性最高。逆向的目标是让链路可解释、可复现不是非要手写加密算法不可。很多宣称能破解 hcaptcha 的收费服务底层也大量依赖真实浏览器环境来获取关键参数。4. 实操过程与核心环节实现4.1 环境准备与抓包定位先说环境。我用的工具组合是Python 3.10 httpx Playwright抓包用 Chrome DevTools 和 mitmproxy 配合。如果只观察 hcaptcha 自身的请求DevTools 就够用了过滤域名hcaptcha.com即可。具体抓包步骤打开目标测试页面提前清空所有缓存和 Cookie。打开 DevTools 的 Network 面板勾选 Preserve log。触发验证码交互最好等到 iframe 加载完成后再操作避免漏掉早期请求。点击验证码完成后把 Network 面板里所有hcaptcha.com请求导出成 HAR 文件。用文本编辑器或者在线工具打开 HAR按照时间顺序逐条核对请求和响应。这里有个小技巧搜索框输入getcaptcha可以直接定位到任务下发请求。点开左侧的请求记录右侧能看到 payload 和 response。别嫌麻烦把所有字段都整理到本地笔记里标注来源后面构造请求时就是一本字典。4.2 用脚本复现getcaptcha请求链路理解透之后第一步就是脚本化复现getcaptcha请求。这一步风险低、反馈快非常适合作为起点。下面是一个基础的请求示例目的是观察返回结构不涉及最终 token 生成import httpx url https://hcaptcha.com/getcaptcha payload { sitekey: b3a8d8b8-0000-0000-0000-000000000000, host: test.example.com, hl: zh, motionData: e30, # base64编码的{}仅用于观察响应 } headers { User-Agent: ( Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36 ), Content-Type: application/json, Accept: application/json, Origin: https://newassets.hcaptcha.com, Referer: https://newassets.hcaptcha.com/, } with httpx.Client(http2True, timeout15) as client: resp client.post(url, jsonpayload, headersheaders) print(resp.status_code) print(resp.text)跑完之后把输出和抓包响应做一个 diff。正常情况下字段结构应该一致只是timestamp、job这类动态值不同。如果出现 400 或 error优先检查是不是缺少了 Cookie 相关参数或者motionData格式不对。这一步的意义是验证你抓包时看到的请求体不是前端临时拼的而是一个可以被外部客户端复现的标准 HTTP 接口调用。能复现这个请求后面的checkcaptcha才有进行下去的基础。4.3 从请求复现到token校验的半自动方案要拿到最终 token纯手工构造所有参数很不现实。我个人在项目里最常用的方案是“半自动 参数回填”。思路是这样的用 Playwright 打开目标页面正常触发 hcaptcha。在页面上下文里注入一段脚本用PerformanceObserver或重写XMLHttpRequest/fetch捕获checkcaptcha的请求参数。把捕获到的c、job、motionData等参数保存下来转交给外部脚本做后续处理。外部脚本复现请求拿到 token 后返回给测试流程。这段捕获逻辑可以简写成from playwright.sync_api import sync_playwright captured {} def handle_request(request): if checkcaptcha in request.url and request.method POST: post_data request.post_data_json captured[payload] post_data captured[url] request.url with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page() page.on(request, handle_request) page.goto(https://test.example.com/protected-page) # 手动或自动完成验证码交互 page.wait_for_timeout(30000) browser.close() print(captured)拿到真实的checkcaptcha请求后再回到 Python 脚本里做回放。这一套流程最大的好处是不需要理解c的加密细节也不需要手工构造行为数据所有复杂参数都由浏览器环境原生生成脚本只负责记录和重放。对学习协议和做授权测试来说这个精度完全够用。5. 常见问题与排查技巧实录5.1 高频报错对照表下面这些错误是我在实际调试里高频遇到的整理成表格方便直接对照。报错现象可能原因排查方向400 missing inputJSON 字段缺失对比抓包 payload逐字段补齐400 invalid sitekeysitekey 不存在或 host 不匹配检查参数是否从页面动态读取403 forbiddenIP 信誉低或环境标记明显更换纯净测试环境清理指纹timeout任务已过期检查expiration字段控制回放间隔fail / E0 token行为数据异常或答案错误检查 motionData 合理性确认 answers 对应关系cannot verifytoken 被重复使用或过期siteverify 失败和逆向请求无关需重新走流程最坑的不是 400而是看起来 200、其实返回 fail。这种情况说明网络链路没问题是参数里的行为特征被服务端判了死刑。优先检查 motionData 和 c 是否来自同一个浏览器会话不要从 A 页面拿 c、从 B 页面拿 motionData混搭必挂。5.2 工程中容易翻车的四个细节先说 TLS 指纹。hcaptcha 的服务端对客户端指纹的感知非常敏感。用纯 requests 库发起请求即使 headers 伪装得再像浏览器TLS 握手特征也会暴露。我实测下来httpx 开启 HTTP/2 的支持会好很多或者直接用curl_cffi这类自带浏览器 TLS 指纹的客户端。如果你的请求返回的报错和正常浏览器完全不一致先怀疑这一层。再一个细节是 Cookie 管理。hcaptcha 会在前后端请求之间种下若干hc_开头的 Cookie比如hc_session、hc_ak等。这些 Cookie 参与会话状态管理如果复现请求时没有正确携带服务端会认为这不是同一个会话。解决办法是用真实浏览器环境预置 Cookie并把 Cookie 保存下来后续每次请求都带上。第三个细节是任务过期。getcaptcha返回的数据里有expiration通常只有几十到一百多秒。很多人先把请求参数保存到数据库过一会儿再回放结果一梭子全部 timeout。正确做法是拿到参数后立即提交或者设计自动重试机制在任务过期前重新拉取。第四个细节是版本差异。hcaptcha 的c结构和motionData格式在不同版本之间有差异甚至同一时间段的不同站点都可能拿到不同结构。网上教程里的参数模板只能作为参考必须从自己当前环境的抓包结果出发。我的习惯是每轮调试前先重新抓包把字段结构和最新代码对齐避免拿旧模板硬套新接口。5.3 合规边界与最后的提醒这节我必须多说几句。hcaptcha 逆向分析和绕过的边界其实很清晰授权测试、个人学习、漏洞研究、自动化回归测试都是合理的场景。但在未授权站点上批量生成 token、绕过验证码做注册或爬取轻则违反服务条款重则涉及法律风险。文章里所有示例我都刻意保持在协议解析和受控环境复现的范围内没有提供可用于批量生成 token 的完整工具。从技术角度看我强烈建议把重点放在理解协议和提升调试能力上而不是追求一个“全自动破解”脚本。hcaptcha 的防护体系是动态的今天跑通的脚本明天就可能失效唯一保值的能力是你对链路的理解、对字段的敏感度、对排错的熟练度。我个人在实际操作中的体会是逆向这类验证码耐心比技巧重要。别想着一步到位先把抓包数据整理成自己的字典再逐段复现最后再考虑自动化。这个过程虽然慢但每走一步你对这套防护体系的理解都会深一层。等链路全部跑通回头再看你收获的绝不仅仅是一个能过验证码的脚本而是一套通用的协议分析能力这套能力放到任何别的前端风控体系上照样能用。