2Captcha等验证码求解服务如何复现reCAPTCHA及解析payload原理

1. 2Captcha类服务复现reCAPTCHA内容的核心逻辑 #

这类服务根本不需要复刻特定用户本地收到的专属reCAPTCHA挑战，核心是利用reCAPTCHA本身的校验规则设计实现的：

• 你提交的reCAPTCHA密钥（即sitekey）、目标站点URL本身就是完全公开的参数：普通用户打开目标站时，前端加载reCAPTCHA脚本的请求会明文携带这两个值，reCAPTCHA官方服务端就是靠这两个参数识别当前请求来自哪个接入站点。
• 2Captcha拿到这两个参数后，会直接在工人侧的正常浏览器环境里，用完全一致的参数向reCAPTCHA官方发起验证加载请求，匹配正常的请求头、浏览器指纹后打开reCAPTCHA的验证iframe，此时拿到的验证挑战（不管是点图任务还是无感校验的风险判定），和普通用户在目标站点打开的reCAPTCHA挑战属于同sitekey、同域名下的合法验证会话。
• reCAPTCHA生成的校验token仅和sitekey、绑定域名做强校验，不会和发起验证的用户本地会话、IP做不可绕过的绑定：只要工人侧的浏览器指纹、IP质量满足风控要求，答完题生成的合法token，完全可以带回原用户的访问会话提交给目标站点校验，目标站调用reCAPTCHA接口验签时会判定为有效。
• 所谓的“复现”本质不是还原用户本地看到的那一组特定验证图片，而是直接生成同验证维度下的合法有效token，毕竟最终站点只认token的合法性，不会追溯这个token是在哪个浏览器环境下答出来的。

2. reCAPTCHA payload的工作机制 #

你参考的截图里的payload，就是浏览器和reCAPTCHA服务端交互全流程的请求体，覆盖初始加载、风险上报、答案提交三个核心阶段，具体逻辑如下：
reCAPTCHA payload示例截图

• 初始加载阶段payload：携带固定的基础参数，包括v（当前reCAPTCHA脚本版本号）、k（即sitekey）、p（当前页面的完整URL）、co（域名匹配规则相关配置），服务端收到这部分参数后会生成全局验证会话ID，做第一轮风险判定，决定是直接返回通过的token（无感验证场景），还是弹出图片/交互挑战。
• 风险上报阶段payload：这部分就是你截图里占比最大、看起来没有明确语义的键值对，全是前端脚本自动采集的浏览器指纹、用户行为特征，包括鼠标移动轨迹、页面停留时长、点击坐标、浏览器webdriver标记、插件数量、时区、屏幕分辨率、WebAPI调用特征等，所有值都经过了自定义编码，是reCAPTCHA做风控打分的核心依据，每次reCAPTCHA脚本版本更新，这部分的字段名、编码逻辑都会同步调整，没有公开的固定解析规则。
• 答案提交阶段payload：携带前面生成的会话ID、用户完成挑战的答案内容（比如选中的图片坐标、交互顺序）、实时采集的最新行为特征，服务端收到后会同时校验答案正确性、累计风控分，满足阈值就返回最终的合法g-recaptcha-response token，供用户提交给目标站点完成校验。
• 这类payload自带参数自校验逻辑，如果手动篡改核心指纹参数、或者强制缺失必填字段，reCAPTCHA会直接判定为高风险，要么弹出难度更高的挑战，要么直接拒绝返回有效token。

内容的提问来源于stack exchange，提问作者FieryKing93