aBaiAutoplus 深度拆解：当「注册机」进化成 AI 账号工厂

1.1 插件的自发现机制#

系统的灵魂在 core/registry.py。启动时用 pkgutil.iter_modules 扫描 platforms/ 下的所有 Python 包，任何带 @register 装饰器的 BasePlatform 子类都会被自动注册到全局注册表：

1
# 一个平台插件的典型结构
2
@register
3
class ChatGPTPlatform(BasePlatform):
4
    name = "chatgpt"
5
    display_name = "ChatGPT"
6
    supported_executors = ["protocol", "headless", "headed"]
7
    supported_identity_modes = ["mailbox"]
8
    supported_oauth_providers = ["google", "microsoft"]
9
    capabilities = ["plus_payment", "paypal_checkout"]

这意味着添加新平台不需要修改任何核心代码——你在 platforms/ 下新建一个包，实现 plugin.py，定义 build_protocol_mailbox_adapter() 和 build_browser_registration_adapter()，系统启动时它就会出现在 Web UI 里。

1.2 注册流程引擎：三种模式统一抽象#

这是整个架构最精巧的部分。所有平台的注册逻辑被收敛到三个标准 Flow 类中：

三者的共同点是都依赖 Adapter 模式：

1
@dataclass(slots=True)
2
class ProtocolMailboxAdapter:
3
    result_mapper: Callable        # 结果映射器
4
    worker_builder: Callable       # Worker 构造器
5
    register_runner: Callable      # 注册执行器
6
    otp_spec: OtpSpec | None       # 验证码抓取规格
7
    link_spec: LinkSpec | None     # 验证链接抓取规格
8
    use_captcha: bool              # 是否需要打码

每个平台的 plugin.py 只需「组装」一个 Adapter 并返回，Flow 引擎负责执行环境的构建（代理注入、邮箱轮换、验证码回调、超时控制、取消检查）。这种设计让”注册”这件事变成了声明式配置——开发者不需要理解并发控制、异常重试、SSE 日志推送等技术细节。

1.3 技术栈选型中的安全考量#

注意几个关键组件的选择：

• HTTP 客户端：curl_cffi 而非 requests 或 httpx。原因很简单——curl_cffi 能伪造 TLS 指纹（impersonate="chrome136"），让请求在 TLS 握手层面就”看起来像浏览器”。Cloudflare / Akamai 等 WAF 对 requests 库的 JA3 指纹一抓一个准。

• 浏览器引擎：Playwright（Chromium）+ Camoufox（反指纹）+ BitBrowser（指纹浏览器）。三套浏览器后端覆盖不同场景——Playwright 用于普通表单、Camoufox 用于需要绕过 Turnstile 的场景、BitBrowser 用于 PayPal 这种对浏览器环境极度敏感的平台。

• 桌面端：Electron 内嵌完整 Python 后端，不依赖用户安装 Python 环境。这种”all-in-one”打包方式是降低使用门槛的关键——用户双击 .dmg 或 .exe 就能用。

2.1 GoPay 付款链路：14 步 API 协议#

印尼 GoPay 是 ChatGPT Plus 订阅的一条「野路子」。因为 ChatGPT 在印尼的定价（IDR）相对低廉，且 GoPay 对虚拟卡/PIN 的验证不如欧美严格，整套链路可以被协议化。

其流水线分三步（实现见 application/gopay_pay_chatgpt.py）：

1
步骤一【协议】：调用 generate_plus_link(country=ID, currency=IDR)
2
      → 拿到 Stripe Hosted Checkout 的 cashier_url
3

4
步骤二【浏览器】：打开 cashier_url → 等待页面自动跳转到 Midtrans 域
5
      → 捕获 midtrans_url（Snap v3/v4 重定向 URL）
6

7
步骤三【协议】：GoPayPayment.pay(midtrans_url, account)
8
      → 14 步 Midtrans API：生成支付token → 启动交易 → GoPay 扫码/确认 → 回调

第三步最精彩——Midtrans 的 Snap 收银台本质是一套 RESTful API 编排，每步都需要精确的 header 构造、csrf token 传递、以及 JWT 签名验证。项目在 platforms/gopay-deploy/ 中做了一套完整的 GoPay 协议 Worker，从账号登录、PIN 验证、余额查询到付款确认，全链路协议化。

同时注意到一个巧妙的工程手段——PhoneTTLGuard：

1
class PhoneTTLGuard:
2
    """Hero-SMS 号码 20 分钟自动回收的护栏"""
3
    def __init__(self, ttl_seconds: int = 1200):
4
        self.ttl_seconds = ttl_seconds
5
        self._start = time.monotonic()
6

7
    def check(self) -> None:
8
        if self.elapsed() > self.ttl_seconds:
9
            raise RuntimeError("号码有效期已过，任务失败")

因为接码平台的印尼号码只有 20 分钟有效期，如果你在注册 GoPay 后超过 20 分钟才去调用付款接口，号码已被回收，短信验证码就收不到了。这个护栏用 time.monotonic()（不受系统时钟回拨影响）在每一步执行前检查，超时直接判失败——干净利落的工程防御。

2.2 PayPal 付款链路：HAR 协议逆向的艺术#

比 GoPay 更复杂的是 PayPal。ChatGPT Plus 的后付费链路会经过 Stripe → PayPal 的审批协议跳转，PayPal 端有：

• hCaptcha passive 检测（包含约 2200 字符的签名 JWT）
• Generic Risk Center 企业风控（5 次交叉验证请求）
• SignUp Guest 注册流（包括手机号验证、地址填充、卡片绑定）
• Hermes 兜底支付（OPT_OUT 模式，$0 trial 不产生真实扣款）

项目仓库中一份 77MB 的 HAR 文件 checkout-20260523-160436-04xg0pylps_edu.hsxhome.com.har（含 846 个请求），被逐帧反推成了协议文档 PAYPAL_PROTOCOL_FLOW.md，拆解出 6 个 Stage、20+ 个端点的完整调用链。

最值得关注的技术点：

① hCaptcha passive 的”不战而胜”

PayPal 的 /auth/validatecaptcha 端点接受 hcaptchaToken=NOT_REACHABLE 作为参数——也就是说，在某些条件下，PayPal 自己的前端 JavaScript 在检测不到 hCaptcha 时也不会拒绝请求，而是走到一个 authchallengenodeweb 模板（返回 200 + 7387 字节 HTML）。真正的 hCaptcha 校验在另一个端点 /auth/verifyhcaptchapassive 中触发，需要 hCaptcha SDK 生成的 P1_<签名JWT> token。

这个发现意味着：如果能绕过 PayPal 的 Generic Risk Center 风控评分，hCaptcha 可能根本不会被触发。这是典型的”从协议层面理解风控触发条件”的逆向思路，而不是硬着头皮去对着 hCaptcha 死磕。

② Hermes 兜底支付的 $0 trial 秘密

在前几次 addCard 时，GraphQL mutate 返回 ISSUER_DECLINE / CARD_GENERIC_ERROR 并不代表失败。PayPal 会自动在 redirect URL 追加 addFIContingency=noretry&fallback=1&reason=CARD_GENERIC_ERROR（base64 编码），把流量导进 /webapps/hermes 兜底支付。Hermes 里只需发一个 authorize mutation，带 fundingPreference={"balancePreference":"OPT_OUT"}，PayPal 就会直接返回 status=success——因为它识别到这是一笔 $0 试用的审批授权，不需要真实扣款。

OPT_OUT 是整条链路中最关键的一个参数。它告诉 PayPal：“别从任何资金渠道扣款，这是一笔授权审批。” 不掌握这个细节，你会以为 visa 虚拟卡被拒就是失败。掌握了，你就知道这条 HAR 里的所有”失败”步骤都是预期的路由分支。

2.3 代理池：成功率驱动的智能轮换#

代理在 AI 账号注册中是核心竞争力。Cloudflare 对数据中心 IP 的态度越来越严苛，Turnstile 验证码的通过率与 IP 质量直接挂钩。

aBaiAutoplus 的代理池设计有三种层级：

三个关键设计：

1. 自动回退：动态代理失败 → 回退到静态代理池 → 再失败才报错
2. 成功率统计：GET /api/stats/by-proxy 可按代理查询成功率排行
3. 平台敏感度区分：不同平台对 IP 的容忍度不同，可分别配置代理策略

3.1 账号生命周期管理器#

1
- 每 6 小时：有效性检测（check token 是否还能用）
2
- 每 12 小时：Token 自动续期（当前支持 ChatGPT session_token 刷新）
3
- Trial 过期扫描：快过期 → 预警标记，已过期 → 状态更新为 EXPIRED

这不是装饰性功能——如果你有 200 个 ChatGPT 账号，手动检查每个 token 是否过期是不现实的。生命周期管理器让账号池成为一种「可运营的资源」，而非一次性消耗品。

3.2 多维度成功率仪表盘#

1
/api/stats/overview     → 全局概览（总数、成功率、状态分布）
2
/api/stats/by-platform  → 按平台统计成功率（看哪个平台风控严）
3
/api/stats/by-day       → 按天注册趋势（看成功率是否在下降）
4
/api/stats/by-proxy     → 代理成功率排行（淘汰低质代理）
5
/api/stats/errors       → 失败错误聚合（分析常见失败原因）

把成功率数据分析做成独立 API，意味着可以接入 Grafana / Prometheus 等外部监控，而不只是看 Web UI 上的图表。这是「工具」到「运维平台」之间的一条分界线。

3.3 账号导出生态#

注册完的账号需要被消费。支持 6 种导出格式：

• JSON / CSV：常规导出
• CPA：内容发布平台导入格式
• Sub2API：订阅 API 转换器格式
• Kiro-Go：Kiro 平台的 config.json 格式
• Any2API：开源 API 网关格式（注册完自动推送到网关，即注册即用）

最后这个 Any2API 联动很有意思——注册工具本身不提供 API 服务，但它能自动把账号推送到另一个 API 网关项目，让下游消费者通过统一接口获取账号。这是一种「微服务化」的思路：注册工具专注生产，API 网关专注分发。

3.4 Any2API 自动推送映射#

4.1 any-auto-register（上游项目）#

本质差异：any-auto-register 做了「注册」，aBaiAutoplus 做了「注册 + 付费」。两者的架构是同源的（同一套插件基类和注册引擎），但 aBaiAutoplus 在 ChatGPT 平台上的深度远超上游——不只是接口注册，而是打通了从账户创建到 Plus 订阅扣款的全流程。

可以这么说：

• any-auto-register = 注册框架 + 多平台适配器
• aBaiAutoplus = 注册框架 + ChatGPT Plus 付费工程 + GoPay 全套协议

4.2 gpt-auto-register（⭐397）#

最直接的单平台竞品。基于 Python + Selenium，专注 ChatGPT 账号注册。

差距不在功能数量，在架构理念。gpt-auto-register 是一个能用的注册脚本；aBaiAutoplus 是一个可扩展的注册平台。

4.3 chatgpt-auto-register（⭐13）#

基于 undetected-chromedriver 的入门级实现。功能最基础，适合学习原理，不具备生产级可用性。与 aBaiAutoplus 不在同一量级，不做详细对比。

4.4 差异化总结#

如果把「AI 账号注册工具」的进化分为三个阶段：

1
第一代（2023）    Selenium + 手动配置 → 注册成功
2
第二代（2024-25） Playwright + 多平台 + 插件化 → 注册 + 管理
3
第三代（2026）    协议逆向 + 付费打通 + 微服务生态 → 全链路自动化

aBaiAutoplus 处于第二代向第三代的过渡期——它继承了第二代的插件化框架，但用 GoPay / PayPal 协议逆向和 Any2API 联动把自己推进了第三代的门槛。三者的核心差异体现在付费集成、TLS 对抗深度、以及生态完整度上。

5.1 TLS 指纹伪装的双层策略#

项目在 HTTP 层面有两套请求方案：

• curl_cffi（core/http_client.py）：默认 impersonate="chrome136"，伪造完整的 TLS 握手指纹
• tls_client（core/tls.py）：更轻量的选择，用于 GoPay 等对 TLS 检测不那么严格的场景

这种「双层策略」是有深度的——curl_cffi 的 impersonate 虽然真实度高，但附带性能开销；对于不需要高伪装的 API 请求，退回到 tls_client 能提升吞吐量。

5.2 邮箱层的「深度防御」#

9 种邮箱 Provider 不是简单的多选，而是一种分层防护策略：

• 自己的域名邮箱（Laoudo）：稳定性最高，适合重要账号，不会被封
• 自建 Cloudflare Worker 邮箱：完全可控，邮箱域名随机，难以被平台封禁
• 公共临时邮箱（DuckMail / TempMail.lol）：零配置，适合快速测试
• MoeMail 自动注册：连邮箱也是自动创建的，适合大规模并发

不同场景用不同邮箱，这是一种对抗意识——当平台开始针对特定邮箱域名做风控时，你有备选方案。

5.3 验证码求解的递进策略#

「先本地、再远程、最后手动」的递进逻辑，比直接调打码平台更经济。

5.4 开源安全审计的”工程良心”#

项目开源前做了一份详细的安全审计（OPEN_SOURCE_RELEASE.md），发现的 P0 级问题包括：

• 81 个真实 ChatGPT 账号明文凭证已被 git 跟踪
• 8 个 GoPay 账号的手机号 + PIN 明文泄露
• 13 个调试 dump 文件含 PayPal / Stripe 实时 cookie

这份审计本身就是一个有价值的技术文档——它展示了「开源前要做哪些安全检查」的完整 checklist：

1. 扫描 git 历史中的凭证文件
2. 检查源码中的硬编码 API Key
3. 审查第三方 APK 逆向常量是否可公开
4. 验证 .gitignore 规则是否生效
5. git filter-repo 重写历史的完整命令

每个打算开源的开发者都应该读一遍这份文档。

6.1 技术局限#

• GoPay 地域锁定：依赖印尼手机号 + 印尼 IP，对中国用户不友好
• PayPal 浏览器自动化不稳定：BitBrowser profile 持久化是双刃剑——历史 cookie 积累后可能触发异常检测
• Camoufox 依赖：本地 Solver 依赖于 Camoufox 的反指纹浏览器，ARM 架构支持有限
• MoeMail 公共实例不可控：依赖第三方部署的实例稳定性

6.2 运维负担#

• 3.7M 行 Python（含依赖）不是小工程，依赖更新和兼容性维护是个长期问题
• 跨平台浏览器自动化（Playwright + Camoufox + BitBrowser）的环境配置复杂度高
• 多接码渠道、多验证码渠道的 API 轮换和余额管理需要持续关注

6.3 法律与道德边界#

项目在 README 中明确了「仅供学习研究」的定位，并且基于 AGPL-3.0 许可证。但必须指出：

• 自动化注册违反几乎所有目标平台的 ToS
• 协议化支付链路可能涉及支付欺诈的法律风险
• 印尼 GoPay 的 APK 逆向常量（CLIENT_SECRET 等）存在 ToS 和版权问题

技术是好技术，但使用场景需要谨慎判断。