从零实现hCaptcha视觉求解器：Gpt-Agreement-Payment三层决策架构揭秘-港品优选

从零实现hCaptcha视觉求解器：Gpt-Agreement-Payment三层决策架构揭秘

【免费下载链接】Gpt-Agreement-PaymentChatGPT Plus/Team/Pro 订阅协议端到端重放工具集 · hCaptcha 视觉求解器 · 反欺诈机制实证研究 / End-to-end protocol replay toolkit for ChatGPT Plus/Team/Pro subscription with from-scratch hCaptcha solver and empirical anti-fraud research项目地址: https://gitcode.com/gh_mirrors/gp/Gpt-Agreement-Payment

Gpt-Agreement-Payment 是一个 ChatGPT Plus / Team / Pro 订阅协议的端到端重放工具集，其中最硬核的组件，是它从零实现的 hCaptcha 视觉求解器——一个约 4200 行的独立 solver，不依赖任何打码平台，用"VLM 视觉大模型主路径 + CLIP/OpenCV 启发式回退 + Playwright 人类动作合成"三层决策架构，自动通过任意 hCaptcha 图形挑战题。本文带你完整拆解这套架构的设计思路与实现细节。

🧩 项目背景：为什么需要 hCaptcha 视觉求解器

Gpt-Agreement-Payment 覆盖Stripe Checkout → PayPal / GoPay / QRIS → ChatGPT 审批 → Codex OAuth + PKCE整条订阅链路。在 Stripe 结算环节，浏览器经常弹出 hCaptcha 图形挑战（点选、拖拽类），这是整条链路里最不稳定的一环。

求解器的核心文件是 CTF-pay/captcha/solver.py（旧路径 CTF-pay/hcaptcha_auto_solver.py 仍保留），配套一个轻量桥接服务 CTF-pay/captcha/bridge.py。它的定位很清晰：

通用性：对任意 hCaptcha bridge URL 生效，不绑定 Stripe 单场景；
独立性：ML 依赖（CLIP/torch）装在独立 venv，因此由card.py通过 subprocess 拉起而非 import，避免污染主环境；
可调试：每一轮决策都会落盘截图 + JSON 元数据，方便逐题复盘。

🗺️ 三层决策架构总览

整个求解流程是一个"逐层降级 + 视觉反馈重试"的状态机：

设计哲学一句话：能用 VLM 就不用规则，规则不匹配就交给执行器的重试环兜底。下面逐层拆解。

🎯 第 1 层：VLM 决策——首选主路径

VLM（视觉语言模型）层调用任何兼容 OpenAI/v1/chat/completions协议的端点，把 challenge 截图、候选区域 overlay 和结构化 JSON 指令一起发给模型。它有两种工作模式：

候选框模式

先用 OpenCV 提取候选点击/拖拽目标，给每个候选框标注G1、G2、S1、T1等 ID 画到 overlay 图上，VLM 只需从有限 ID 里选择，输出如{"action": "click", "selected_ids": ["G1", "G3"]}或{"action": "drag", "source_id": "S1", "target_id": "T2"}。把开放定位问题变成封闭选择题，显著降低模型出错率。

直出坐标模式

当候选框提取失败（图像布局非标准）时自动降级，VLM 直接返回归一化坐标，如{"action": "click", "coords": [[0.31, 0.42], [0.73, 0.41]]}。

VLM 配置

通过三个环境变量即可接入任意 OpenAI 兼容模型服务，源码见 CTF-pay/captcha/solver.py：

export CTF_VLM_BASE_URL="https://api.openai.com/v1" export CTF_VLM_API_KEY="sk-..." export CTF_VLM_MODEL="gpt-4o"

也支持--vlm-base-url/--vlm-api-key/--vlm-model命令行参数覆盖。VLM 超时或调用失败时，流程自动滑向第 2 层，不会卡死。

🔍 第 2 层：CLIP / OpenCV 启发式 dispatcher

VLM 不可用或失败时的回退路径：按 prompt 关键词匹配题型，路由到专用 solver。目前已覆盖12 种常见 hCaptcha 题型：

题型 prompt 关键词	Solver 函数	方法
`water travel`/`vehicle...water`	`solve_water_travel()`	CLIP 二分类，3×3 grid 或 object 候选
`drag`/`complete the pair`	`solve_pair_drag()`	颜色聚类定位 source + skeleton 匹配
`missing piece`/`complete the image`	`solve_missing_pieces_drag()`	HSV 槽位检测 + shape IoU
`float on water`	`solve_float_on_water()`	CLIP 二分类
`served hot`	`solve_hot_food()`	CLIP 二分类
`hop or jump`/`hopping`	`solve_hop_animals()`	CLIP 滑窗 + 聚类 + 两阶段评分
`produce heat to work`	`solve_heat_work()`	CLIP 二分类
`shiny thing`	`solve_shiny_thing()`	CLIP 二分类（单选）
`kept outside`	`solve_kept_outside()`	CLIP 二分类
`dissolve or melt`	`solve_dissolve_melt()`	CLIP 多标签分类
`hidden under the reference object`	`solve_hidden_under_reference()`	边缘检测 + 连通组件
`complete the road`+`finish line`	`solve_road_completion()`	边缘检测 + 连通组件

候选区域提取采用两种互补策略，按图像特征自动选择：

Grid 模式（detect_label_grid）：针对标准 3×3 网格，用行列像素方差/非白统计检测三个等分 band，判定门槛是覆盖率 ≥ 72% 且均衡度 ≥ 55%；
Object 模式（_build_object_candidates_generic）：非标准布局时回退，用 Canny 边缘 + 连通组件 + 形态学去噪提取独立物体。

🖱️ 第 3 层：Playwright 执行器

答案只是坐标，真正难的是"像人一样点上去"且不被检测到。执行层做了四件事：

1. 反检测：通过init_script覆盖navigator.webdriver、navigator.platform、navigator.hardwareConcurrency等十余个指纹属性。

2. 人类动作合成：

点击：4 点 Bézier 曲线逼近鼠标轨迹 + 200–400ms 随机延迟；
拖拽：3 段插值路径，起/中/终点各加 jitter；
操作间停顿：均值 800ms ± 300ms 的正态分布。

3. 视觉反馈重试环：每次交互后抓前后两帧，计算changed_pixels与mean_diff两个指标判断点击是否"落地"。没落地就自动偏移重试——点击类按±10px / ±16px八方向 + 原点共 9 次，拖拽类按5 starts × 5 ends = 25种 jitter 组合。

4. 多 raster 源 + 网络监听：优先从 canvastoDataURL()拿原始位图，canvas 空白（图绘在 SVG 里）时回退整页截图；同时拦截hcaptcha.com域的/getcaptcha（提取 prompt）与/checkcaptcha（提取 pass 状态）响应，元数据写入round_XX.json。

🔄 Variation 重试体系：不赌单次答案

solver 从不返回单一答案，而是有序候选序列：

Click 类：candidate_click_sets按 CLIP 置信度排序——先试"强集"（全部置信度 ≥ 0.5），再试"中集"（≥ 0.3），最后逐个单选提交；
Drag 类：source jitter 五点 × target jitter 五点，生成 25 种组合依次尝试；
图像哈希去重：以(prompt, sha1(image_bytes))为 key 记录已耗尽的 variation，同题重复出现时直接跳过失败方案。

所有 variation 用尽后抛出drag_variations_exhausted/click_set_variations_exhausted异常（见 CTF-pay/captcha/solver.py 的错误上报分支），上层 daemon 接住后触发"重跑当前轮"，而不是 solver 内无限重试——把重试责任按层级切分是这个架构的一大亮点。

⚙️ 快速上手：运行与调试 hCaptcha 求解器

求解器可完全独立运行，传入任意 bridge URL：

# 有头模式（看着它干活） ~/.venvs/ctfml/bin/python CTF-pay/captcha/solver.py \ http://127.0.0.1:PORT/index.html --headed --timeout 300 # 关闭 VLM，只跑启发式 ~/.venvs/ctfml/bin/python CTF-pay/captcha/solver.py \ http://127.0.0.1:PORT/index.html --no-vlm

在完整 pipeline 中，CTF-pay/card.py（shim）背后的 card/_monolith.py 里的solve_stripe_hcaptcha_in_browser()会自动检测：遇到非 invisible challenge 且未显式配置external_solver时，自动补齐 solver 的 python 解释器、脚本路径、输出目录与 VLM 配置，再通过 subprocess 拉起并自动抬高browser_challenge.timeout_ms防止外层超时误杀。solver 结果经本地 bridge 的/resultHTTP 端点回传。

项目还附带一个本地 mock 网关 CTF-pay/relays/mock_gateway.py，配合 CTF-pay/config.local-mock.json 可在无真实支付环境下演练整套流程。如果使用 Web UI，配置向导的 Step 08/09（打码 / VLM）会把 VLM 端点写入CTF-pay/config.auto.json：

调试产物速查

--out-dir（默认/tmp/hcaptcha_auto_solver）下每轮都会落盘：

文件	含义
`round_XX.png`	每轮截图
`round_XX.json`	完整决策元数据（prompt、候选框、VLM 响应、视觉反馈值）
`checkcaptcha_pass_*.json`	通过那次的网络监听快照
`checkcaptcha_fail_*.json`	失败那次的快照
`session_meta_*.json`	整个会话元信息

调试一道失败的题，cat round_05.json | jq .就能看到 VLM 到底选了什么、坐标落在哪。

🧩 扩展新题型：只需三步

架构的开放性在于新增题型是纯增量开发：

写一个 prompt 匹配函数（如is_carry_things_prompt）；
写求解函数，返回带candidate_click_sets的SolverResult；
在solve_bridge()的 dispatcher（CTF-pay/captcha/solver.py）加一个elif分支。

官方建议每新增一种题型，先攒 100–500 张该题型的round_XX.png截图找模式，详见 docs/hcaptcha-solver.md 与 CONTRIBUTING.md。

📚 总结

Gpt-Agreement-Payment 的 hCaptcha 视觉求解器给出了一个可复用的解题系统范本：

VLM 优先：把定位问题转成选择题/坐标题，覆盖未知题型；
规则兜底：12 种已知题型走专用 CLIP/OpenCV solver，零 API 成本；
执行层拟人：Bézier 轨迹 + 帧差视觉反馈 + 偏移重试环，让坐标"真的点中"；
责任分层：solver 耗尽 variation 就交棒给 daemon 重跑轮次，任何一层失败都有出口。

完整实现约 4200 行，全部源码在 CTF-pay/captcha/ 目录下，值得逐函数精读。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析