夜雨聆风大家有没有刷到过闲*鱼、Tele*gram上的GPT Plus代充？20-50元就能开通一个月，比官方定价145元便宜一半还多，甚至还有人宣称能“白嫖”永久会员。
很多人以为是捡漏，实则是利用OpenAI的技术漏洞套利。前几日，X平台用户K*发布长推文，把这套代充背后的完整技术链路扒得底朝天；同日，博主阿*也爆料，Telegram上已出现能白嫖ChatGPT Plus/Pro的机器人。
今天就用通俗的语言拆解这个漏洞没有复杂术语，不管你是普通用户还是开发者，都能看懂灰*产是怎么“空手套白狼”的，以及背后的风险到底有多大。
一、漏洞核心：OpenAI犯了个“低级错误”
一句话点破关键：
OpenAI校验收据时，只看收据真假，不看这张收据是谁买的。
用大白话解释就是：你用Apple ID花85元买了一张ChatGPT Plus的内购收据，只要这张收据是真的，再拿到B、C、D任意一个ChatGPT账号的auth token（相当于账号临时凭证），就能给这些账号全部开通Plus会员。
这就像你拿着别人的购物小票去柜台领东西，柜员只核对小票真伪，根本不查你是不是小票上的购买人——漏洞的核心，就是缺失了“收据归属”的校验环节。
技术层面更直白：合法收据 + 有效auth token = 任意账号开通Plus，Apple ID与ChatGPT账号的绑定关系、对应关系，OpenAI全不校验。
二、正常内购vs漏洞利用：差了关键一步先看iOS上ChatGPT Plus的正常订阅流程，一共5步，环环相扣：
1.用户在iPhone上点击ChatGPT Plus订阅并付款；
2.App Store扣钱后，生成一张“购买收据”（receipt），写入手机本地沙盒；
3.ChatGPT App自动拾取这张收据，连同当前登录账号的auth token一起，发给OpenAI服务器；
4.OpenAI服务器向Apple验证收据真伪；
5.校验通过，给这张auth token对应的账号开通Plus权益。
而漏洞，就出在第4步到第5步之间。
正常情况下，OpenAI除了验收据真假，还应该校验“这张收据对应的Apple ID，和提交请求的ChatGPT账号是否有关联”；但实际操作中，他们直接跳过了这一步——只要收据是真的、token是有效的，不管两者有没有关系，直接开通权益。正常“三端订阅管理都交给第三方API处理，这本是正常开发逻辑，但OpenAI在这条链路上偷了懒，压根没想过有人会卡这个环节。”
三、完整操作链路：四步拆解
第一步：获取低价区Apple ID（成本85元）
ChatGPT Plus的定价是分地区的，土耳其区标价499里拉/月，折合人民币约85元；而国内iOS定价高达145元，这差价本身就是第一层套利空间。
操作很简单：注册或购买一个土耳其区Apple ID，充入足够的礼品卡余额，用于购买Plus订阅、获取收据。
第二步：拦截收据，阻止自动提交
在iPhone上打开ChatGPT App，不登录目标代充账号（可以登临时号，也可以不登录）。
关键操作来了：在内购付款前，配置网络拦截（比如代理），阻止ChatGPT App把收据自动发送给OpenAI服务器。
此时，App Store会正常扣款，Apple也会把收据写入手机本地沙盒（appStoreReceiptURL），但因为被拦截，这张收据不会被自动提交，而是留在手机里，等待手动提取。
第三步：导出收据（3种方法，无需越狱也能操作）
K*列出了3种主流导出方法，其中方法A门槛最低，无需越狱，普通人也能操作：
方法 A：端点本地映射（无需越狱）
用 DNS 劫持或本地代理，将 ChatGPT App 发往 OpenAI 的请求重定向到本地服务器。请求体中本身就携带 Base64 编码的收据，到本地后直接保存。
工具链：mitmproxy、Charles Proxy、自建 HTTPS 代理 + 自签证书。
Kai 原话：“不用越狱，门槛低得令人发指。”
方法 B：越狱设备 + Hook（iOS）
在越狱设备上使用 Frida 或 Flex，直接 hook StoreKit 框架，截取 SKPaymentTransaction 的 transactionReceipt，或读取 appStoreReceiptURL 对应的收据文件。
方法 C：Android + Xposed Hook
Android 路径使用 Xposed 框架 hook 对应支付回调，逻辑与 iOS 类似。
第四步：API补单，把收据打到任意账号
收据到手后，直接向 OpenAI 的订阅接口发送请求
请求示例（简化版，便于理解）：
POST https://ios.chat.openai.com/backend-api/mobile/apple/post_receiptContent-Type: application/jsonAuthorization: Bearer <目标账号的 auth token>{"receipt": "<Base64 编码的 iOS 收据>","platform": "ios","product_id": "com.openai.chatgptplus","device_info": {"model": "iPhone14,2","os_version": "17.0","timezone": "Asia/Shanghai"}}
Authorization 头使用的是目标用户的 auth token，而不是购买者的。这就是漏洞的核心利用方式——用 A 的收据给 B 开通 Plus。四、套利逻辑：重放攻击的经济模型
为什么闲鱼上的代充能卖到20-50元/月？核心就是“一票多充”的重放攻击，经济模型简单又暴利：
操作闭环也很简单：买家提供自己的ChatGPT auth token，卖家用提前准备好的收据调用API，给买家开通Plus；买家收到权益后，立刻修改密码，使token失效；而卖家则拿着同一张收据，继续给下一个买家代充，循环往复，一本万利。
更极端的是，Kai还提到，有灰产用日本、英国地区节点+抓包拦截，能0元获取收据，相当于彻底无成本套利——推测是利用了这些地区的免费试用政策或支付流程差异。
五、OpenAI到底偷了哪3个懒？
这个漏洞能被利用，本质是OpenAI的服务端设计存在3个致命缺失，说“偷懒”一点不为过：
1.缺失1：不校验收据与账号的归属关系。
Apple 的 Server-to-Server 验票接口（verifyReceipt 或 App Store Server API v2）返回的数据中包含 original_transaction_id，可以唯一标识一笔购买。正常做法是：
收据验证通过后：IF original_transaction_id 已绑定其他平台账号 → 拒绝ELSE → 绑定当前请求账号，发放权益
OpenAI 的实现显然跳过了这一步。
2.缺失2：没有重放拦截。
同一个original_transaction_id（同一张收据），被多个不同的auth token提交时，OpenAI没有去重逻辑，允许反复开通权益，这就是典型的“收据重放漏洞”。
3.缺失3：没有请求特征风控。
批量代充有明显的异常特征：
短时间内大量不同token用同一个交易ID、IP/设备指纹高度集中、设备信息千篇一律（比如全是iPhone14,2）——这些异常，OpenAI的风控系统完全没识别到。
总结：
正常设计： 验真伪 → 验归属 → 验重放 → 风控拦截 → 发放权益OpenAI 实际：验真伪 → （跳过）→ （跳过）→ （跳过）→ 发放权益六、同类漏洞的行业对比
这类 iOS 内购收据校验缺陷并非 OpenAI 独有。在移动支付生态中，类似问题有过多次先例：
transaction_id 去重 | ||
Restore Purchases | ||
| OpenAI (本案) | 收据重放 + 跨账号补单 | 未校验 Apple ID 归属 + 未做 transaction_id 去重 |
Apple 自身的 StoreKit 2 和 App Store Server API v2 已经提供了 JWSTransaction 签名验证、original_transaction_id 绑定、Server Notification V2 等完善的校验基础设施。问题不在 Apple 侧，而在 OpenAI 的服务端没有用好这些能力。
1. 收据 → 账号强绑定
# 伪代码defprocess_receipt(auth_token, receipt_data): verification = verify_with_apple(receipt_data) txn_id = verification.original_transaction_id existing_binding = db.query(txn_id)if existing_binding and existing_binding.account_id != auth_token.account_id:raise Error("此收据已绑定其他账号") db.bind(txn_id, auth_token.account_id) grant_plus(auth_token.account_id)2. transaction_id 全局去重
维护一张 (original_transaction_id, account_id) 的映射表，写入即锁定，拒绝同一 transaction_id 的二次绑定。
3. 请求级风控
同一 receipt 被不同 auth token 提交 → 立即拒绝并告警 同一 IP/设备指纹短时间内大量补单 → 触发人工审计 device_info字段与实际请求环境不符 → 标记风险
4. 迁移到 App Store Server API v2
使用 Apple 的 JWS 签名事务替代传统的 verifyReceipt，获得更细粒度的事务状态和撤销通知。
最后想说
这个漏洞，本质是“信息差”催生的灰产套利——技术不难，但大多数人不知道，少数人靠着这个赚得盆满钵满，甚至有人包装成“付费教程”收割智商税。
对普通人来说，最稳妥的方式还是通过官方渠道开通ChatGPT Plus，不要为了几十块的便宜，冒着账号泄露、权益被撤销的风险找代充；对开发者来说，这也是一个警示——iOS内购校验，少一步都可能酿成大错。
目前，OpenAI大概率已经在紧急修复这个漏洞，那些低价代充渠道，或许，“没几天就和谐掉”。与其投机取巧，不如踏实使用官方服务，才是最省心、最安全的选择。
免责声明：仅供学习交流！
参考来源：K*原帖、阿*相关推文
