iOS ChatGPT Pro 20x 强开订阅全解析(若宇优化版)

若宇的 AI 学习日记深度安全拆解

前端入口关了 = 商品买不到了？

iOS ChatGPT Pro 20x

强开订阅全解析

Apple IAP 协议 · buyProduct · 鉴权抓包 · 订阅转移 · 跨平台对比

技术研究与协议防御参考

IAP协议安全分析

OpenAI 在 2026 年下半年把 Pro 20x（每月 200 美元）的新订阅入口关了。网页端撤了按钮，App 里删了选项，checkout 接口也开始拒绝新的 Pro 20x 请求。

但入口关了，不代表商品下架了。前阵子有人把一套绕过办法开源了出来，思路特别直白：不碰 OpenAI 的界面，直接对 Apple 的购买接口下单。OpenAI 关的是自家前端，App Store 后台那个 IAP 商品还挂着，只要能凑出一个合法的购买请求，Apple 照样扣款出收据，OpenAI 收到回执照样得开。

那份教程的完整版我拿到手了，一共六章，从前置条件、网络配置、越狱设置，一路讲到拦截原理和字段含义。下面在它的基础上加上我自己的分析，顺便跟之前拆过的 Stripe 协议支付 、 Google Play 订阅转移 摆在一起对照，把这条链路讲透。

1.1 OpenAI 关了什么

关的其实是几个面向用户的入口：网页端的订阅按钮和定价页没了，iOS/Android app 里不再列出 Pro 20x 这个选项， /payments/checkout 接口也开始拒绝 plan_type=chatgptpro 的新建请求。三条路都是"用户点得到的地方"，全被掐掉了。

1.2 OpenAI 没关什么

App Store Connect 里的 IAP 商品没有下架。

在 Apple 的体系里，一个 IAP 商品有自己独立的生命周期，跟 app 界面上展不展示是两码事。app 可以决定不把某个商品摆出来，但只要它在 App Store Connect 后台还挂着 “Approved”，Apple 的购买 API 就照单全收。

类比一下：超市把某个货撤下了货架，可收银系统里那个条码还在。你拿条码去自助机一扫，照样结账走人。

1.3 Apple 的购买 API 不管 App UI 的事

Apple 的内部购买端点是：

它收到请求后做三件事：先看鉴权字段（buyParams、guid、ams、cookie、afdsv2）合不合法，再看 salableAdamId 指向的商品在不在、能不能买，最后扣款、生成 receipt，通过 App Store Server Notifications 把交易推给开发者。

它唯独不看一件事：app 当前有没有在界面上展示这个商品。Apple 的支付系统跟 app 的 UI 是两套东西，互不干涉。

1.4 OpenAI 为什么一般会认这张收据

根据 Apple 的 App Store Review Guidelines（特别是 3.1.1 In-App Purchase 条款），通过 App 内购买解锁的功能必须由 Apple 的 IAP 体系交付，开发者不能在收到合法交易后拒不发放对应权益（否则可能被 Apple 判定违规、影响上架）。因此在正常设计下，OpenAI 收到一张合法且能对应到某个账号的 Pro 20x App Store 交易通知， 预期会 为该账号开通 Pro 20x。

不过要说明：这不代表 OpenAI 毫无裁量权——它仍可以基于自身风控（异常购买、退款、账号信誉等）拒绝或事后撤销开通，也可以要求交易能正确关联到一个 OpenAI 账号（见后文"交付"一节）才发放权益。“必开"是理想模型，不是绝对保证。

所以整条链路是：

UI 层的限制，在协议层面毫无意义。

— 超市货架与收银系统类比：UI层下架不等于商品下架

2.1 硬件

2.2 软件

2.3 账号

2.4 为什么必须越狱

简单说： Apple 的 App Store 和 iTunes Store 有 SSL Certificate Pinning（证书锁定）。

正常情况下，即使你在 iOS 系统里安装并信任了 MITM 代理的 CA 证书，App Store 的流量仍然无法被代理拦截——因为 App Store 只信任 Apple 自己的证书，不走系统信任链。

越狱后装 SSL Kill Switch 2（或类似 tweak），可以在 runtime hook 掉证书校验函数，让 App Store 的流量走系统信任链 → 被 MITM 代理截获。

这跟 Android 上的操作一个道理：Android 的 ChatGPT App 也有证书锁定，需要 Frida/Xposed 来绕过。 平台不同，原理一模一样。

3.1 代理配置

Apple 的购买 API 会检查请求的源 IP 是否与 Apple ID 的注册区域匹配。美区 Apple ID 必须用美国 IP。

推荐架构：

Charles 配置上游代理： Proxy → External Proxy Settings → SOCKS Proxy → 填入美国代理地址

— 网络架构：iOS 越狱设备 → MITM 代理 → 上游美国住宅 IP → Apple 服务器

3.2 MITM 证书安装

1打开 Charles → Help → SSL Proxying → Install Charles Root Certificate on a Mobile Device

2iPhone 浏览器访问 chls.pro/ssl 下载证书

3设置 → 通用 → VPN 与设备管理 → 安装描述文件

4设置 → 通用 → 关于本机 → 证书信任设置 → 启用完全信任

关键步骤 ：第 4 步很多人漏掉。iOS 安装证书和信任证书是两个独立操作，只安装不信任 = 白装。

3.3 SSL Proxying 规则

在 Charles 中配置 SSL Proxying：

如果用 mitmproxy：

配置完成后，访问 App Store 应该能在代理工具中看到明文 HTTPS 请求。如果还是显示 CONNECT 隧道而不是解密内容，说明 SSL Kill Switch 没生效——检查越狱工具和 tweak 的兼容性。

4.1 越狱工具选择

这一台只用来 抓鉴权 ，不需要跑 ChatGPT app，所以选一个越狱成熟、稳定的老系统即可：

4.2 安装必要 Tweak

越狱完成后，通过 Cydia/Sileo 安装：

SSL Kill Switch 2 设置：

注意 ：不要全局开启证书绕过——那样会影响所有 App 的安全性。只针对 App Store / iTunes Store 开启就够了。

4.3 验证 MITM 生效

打开 App Store → 随便搜个 App → 查看代理工具：

成功 ：看到 GET https://p70-buy.itunes.apple.com/... 的解密请求

失败 ：只看到 CONNECT p70-buy.itunes.apple.com:443 且无解密内容

如果失败，排查：

1SSL Kill Switch 是否选中了正确的进程（ com.apple.AppStore ）

2越狱环境是否完整（ uicache / ldrestart 后重试）

3代理证书是否已经被 完全信任 （不只是安装）

这一节是整个方法的核心。

5.1 Apple 购买请求的鉴权体系

在 App Store 里点一下"购买”，iOS 会往 Apple 的购买服务器发一个 HTTP POST 请求，里头带着五个关键的鉴权字段：

这五个字段凑齐，等于拿到了你 Apple ID 的完整付款授权——谁手里有它们，谁就能以你的身份向 Apple 下单。

5.2 各字段深度解析

这是一个 Base64 编码的二进制数据包，由 App Store 客户端在发起购买时生成。内部包含：

当前 Apple ID 的 session 信息

购买请求的签名数据

设备上下文信息

重要特性 ：根据原始教程的描述和实际操作验证，buyParams 与 当前购买会话 绑定，但据称不与 特定商品 ID 绑定——这意味着触发任意 IAP 时抓到的 buyParams，可以配合不同的商品参数（如 salableAdamId）使用。这是整个方法成立的关键前提。

设备的唯一标识。在 iTunes/App Store 这套协议里，guid 通常由设备网络接口的 MAC 地址等硬件标识生成，表现为一串十六进制字符（桌面客户端上常见是 12 位，真机上的取值方式可能不同）。

它跟设备硬件绑定，不会随便变。同一台机器反复操作，guid 一直是那一个——风控要盯的话，这是个很明显的锚点。

Apple Fraud Detection Service v2。这是 Apple 自研的反欺诈系统，类似于 Stripe 的 Radar。根据已知的设备指纹技术和逆向分析，它在设备端可能采集的信号包括（不限于）：

传感器数据（加速度计 / 陀螺仪等）

设备状态（电池、屏幕亮度等）

触控行为模式

网络环境信息

系统运行时信息

生成的 token 是一个很长的字符串（通常 1000+ 字符），每次购买请求都会重新生成。

越狱对 afdsv2 的影响 ：Apple 的 FDS 理论上可以检测到越狱状态。但根据社区反馈，只要不修改 afdsv2 的生成过程（即让系统正常收集并生成），越狱设备的 afdsv2 通常仍会被接受。风险是长期频繁操作可能积累风控分数被标记。

Apple Media Services token，用于标识当前登录的 Apple ID 在 Apple 媒体服务体系中的身份。这个 token 通常在 Apple ID 登录时颁发，有效期较长。

Apple ID 的会话凭据集合。这里的"cookie"是一个泛称，实际包含 HTTP Cookie 和自定义请求头两类：

Cookie：

自定义请求头（随 cookie 一起抓取）：

5.3 与 Stripe / Google Play 的鉴权对比

三个平台的支付协议我都拆过，正好放在一起做个对比：

三个平台的共同点： 都是在协议层绕过 UI 层的限制，核心逻辑完全相同。

差异在于"如何获取鉴权凭据"和"反欺诈系统有多强"。Stripe 最容易（浏览器 DevTools 导出 HAR 即可），Google Play 居中（需要 Root/Xposed 但不需要越狱），Apple 最难（必须越狱 + MITM）。

5.4 “订阅转移"的原理

文档标题里还有个关键词： 订阅转移 。

这跟之前拆过的 Google Play 订阅转移 是同一个思路：

1Apple ID A 在越狱设备上完成购买 → Pro 20x 订阅绑定到 Apple ID A

2ChatGPT App 收到 App Store 的购买回执，准备把权益绑定到当前登录的 OpenAI 账号

3在 App 处理回执之前 ，切换 ChatGPT 的登录账号到目标账号 B

4App 把 Pro 20x 权益绑到了账号 B

或者更直接的方式，类似之前分析过的 iOS 收据复用漏洞 ：

1在设备上完成购买，拦截 App 发给 OpenAI 的回执提交请求

2修改请求中的 auth token（换成目标账号的 token）

3重放请求 → 目标账号获得 Pro 20x

说到底，Apple 只负责收钱出票，OpenAI 只负责验票开权。中间这张票落到谁头上，取决于你怎么操作。

6.1 完整操作流程

6.2 Phase 1 详细步骤

Step 1 ：越狱设备连接 MITM 代理，确认代理工作正常。

Step 2 ：在 Charles 中设置 Breakpoint（断点拦截）：

Step 3 ：在越狱设备上打开 ChatGPT App → 进入订阅页面 → 触发任意一个 IAP 购买流程。

这一步你可以随便选哪个套餐——Plus、Pro Lite、随便一个。目的不是真的购买，而是触发 App Store 的支付流程，让系统生成鉴权数据。

Step 4 ：当 App Store 弹出支付确认面板时，确认支付（Face ID / Touch ID / 密码）。

Step 5 ：确认后，Charles 会在断点处拦截到 POST .../buyProduct 请求。此时请求 还没有发送到 Apple 服务器 。

Step 6 ：从请求体中提取 5 个关键字段并保存：

Step 7 ：在 Charles 中选择 Abort （中止请求），不让它到达 Apple 服务器。这样不会产生真实扣款。

6.3 Phase 2 详细步骤

拿到鉴权数据后，用脚本或者 HTTP 工具（如 Postman / curl / Python requests）构造 Pro 20x 的购买请求：

— 抓包拦截与重写：保留 Apple ID 鉴权凭据，替换为 Pro 20x 商品参数

注意事项 ：

1代理 IP 一致性 ：这个请求必须走和 Phase 1 相同的出口 IP。Apple 会比对购买请求的源 IP，如果和鉴权生成时的 IP 不同，可能被拒。这与 Stripe 协议支付 中的"出口 IP 一致性"规则完全相同。

2时效性 ：鉴权数据（特别是 buyParams 和 afdsv2）有时效性。抓到后应尽快使用，拖太久 token 会过期。

3请求头 ：除了 Cookie 外，还需要带上 Apple 的特征请求头（ X-Apple-I-MD 等）。这些也在 MITM 抓包中一并获取。

6.4 Phase 3：交付

Apple 处理购买后有两种通知机制：

机制一：App Store Server Notifications V2（服务端到服务端）

Apple 向 OpenAI 配置的 notification endpoint 发送 JSON Web Signature (JWS) 格式的通知，包含完整的交易信息。OpenAI 的后端验证 JWS 签名 → 确认交易合法 → 开通对应的订阅。

这是最可靠的通知路径，不需要客户端参与。

机制二：App 端 Restore Purchases

在 ChatGPT App 中执行"恢复购买"操作（StoreKit 的 restoreCompletedTransactions ），App 会向 Apple 服务器查询当前 Apple ID 的所有有效订阅，然后把新的 Pro 20x 订阅同步到当前登录的 OpenAI 账号。

换句话说，Apple 扣完钱，把"这个用户买了 Pro 20x"的通知发给 OpenAI，OpenAI 就得开权益；用户自己在 app 里点一下"恢复购买”，走的是另一条路，结果一样。

7.1 商品参数逐字段拆解

7.2 ChatGPT 的 IAP 商品体系（推测）

基于 offerName 的命名规则推导——仅 Pro 20x 的值来自已公开的教程，其余为合理推测：

7.3 端点地址解析

题外话 ：WebObjects 最初由 NeXT 公司在 1996 年推出（起初基于 Objective-C，2000 年 WebObjects 5 转向 Java），后随 NeXT 被 Apple 收购。Apple 的 iTunes Store / App Store 后端至今仍在使用这个已有 30 年历史的框架。 MZBuy.woa 这种 URL 结构在互联网上几乎只有 Apple 在用——看到 .woa 后缀就知道是 Apple 的后端。

7.4 buyParams 的结构特征

虽然 buyParams 的内部格式是加密的（Apple 的私有协议），但从外部特征可以观察到：

编码格式 ：Base64

解码后大小 ：通常 200-500 字节

包含信息 ：经过加密的购买会话上下文

生成时机 ：在设备端触发购买流程时由 StoreKit 框架生成

有效期 ：通常几分钟内有效

绑定关系 ：与当前 Apple ID session + 设备绑定，但不与特定商品绑定

7.5 afdsv2 的结构特征

Apple Fraud Detection Service v2 token：

长度 ：通常 1000-4000 字符

编码 ：Base64 或自定义编码

采集数据 ：加速度计、陀螺仪、电池状态、屏幕信息、网络环境、应用列表等

生成频率 ：每次购买请求都重新生成

对应平台 ：类似 Stripe Radar 的 device_data ，或 Google 的 SafetyNet attestation

与 Stripe 的对比：

这也是为什么 Apple IAP 路径的安全级别比 Stripe 协议支付更高—— 你很难在没有真实 iOS 设备的情况下伪造 afdsv2。 必须在真机上操作。

把三个支付平台的协议都拆过一遍之后，可以画一张完整的攻击面全景图：

— 跨平台支付协议与攻击面全景对比

8.1 三条路径

8.2 全维度对比

8.3 从攻击面看防御优先级

最容易修的是 Google Play 路径 ：RevenueCat 只要在 /v1/receipts 接口加上 app_user_id 与付款人的校验，就能堵住转移漏洞。

Stripe 路径本质上不是漏洞 ——它只是用 API 替代了浏览器操作，属于自动化而非绕过。OpenAI 关闭 checkout 入口就堵死了这条路（但目前 Stripe 路径仅用于已开放的订阅档位）。

Apple IAP 路径最难修 。要堵这个洞，OpenAI 有两个选择：

1在 App Store Connect 下架 Pro 20x 商品 → 但这会影响现有 iOS Pro 用户的续费

2在收据验证时拒绝新的 Pro 20x 购买 → 可行，但需要区分"新购买"和"续费"

Apple 自己也很难帮忙——因为从 Apple 的角度看，这是一笔完全合法的交易。用户有 Apple ID、有支付方式、有真实设备、商品也是 approved 状态。Apple 的系统设计初衷就是让开发者可以灵活管理 IAP 商品，而不是让 Apple 来决定哪些商品能卖。

9.1 收据转移（Receipt Transfer）

这个方法跟之前写的 iOS 收据复用漏洞 是可以结合用的。

流程：

1通过 buyProduct API 完成购买，Apple 向 ChatGPT App 推送 receipt

2拦截 ChatGPT App 提交给 OpenAI 的 receipt 请求

3将 receipt 绑定到不同的 OpenAI 账号

但需要注意：2026 年 7 月后 OpenAI 已经 部分修复 了 iOS 收据复用漏洞。具体表现为收据的 original_transaction_id 会被检查——同一个 original_transaction_id 不能同时绑定多个 OpenAI 账号。

但如果每次都是新购买（新的 transaction），收据都是新的 ，转移不受此限制。

9.2 Restore Purchases 路径

更简单的转移方式：

1在越狱设备上用 Apple ID A 完成 Pro 20x 购买

2在 ChatGPT App 中登录 OpenAI 账号 B

3在 App 内执行 “Restore Purchases”（恢复购买）

4StoreKit 查询 Apple ID A 的有效订阅 → 找到 Pro 20x

5ChatGPT App 将 Pro 20x 绑定到 OpenAI 账号 B

这要求 ：在步骤 3 时，设备登录的 Apple ID 必须是 A（即购买 Pro 20x 的那个 Apple ID）。这样 StoreKit 才能查到对应的订阅。

10.1 Apple 账号风险

10.2 越狱设备安全

越狱 = 放弃 iOS 的安全模型。需要注意：

1不要在越狱设备上存储敏感信息 （主力 Apple ID、银行 App 等）

2专机专用 ：用一台专门的老设备做这件事

3及时清理 ：操作完成后关闭 SSL Kill Switch，避免日常使用时被中间人攻击

10.3 合法性

不同司法管辖区对这类操作的定性不同。一些可能的法律风险：

绕过技术保护措施 ：越狱本身在某些国家/地区属于灰色地带

违反 TOS ：OpenAI 和 Apple 的服务条款都禁止此类操作

计算机欺诈 ：通过技术手段获取未被授权的服务访问权

本文仅供技术研究与学习。 实际操作的法律后果由读者自行承担。

完整攻击链路

漏洞本质

平台方（OpenAI）在 UI 层关闭了入口，但在支付平台（Apple）层面没有关闭商品。 只要 App Store Connect 里的 IAP 商品还处于 “Approved” 状态，Apple 的购买 API 就接受任何合法的购买请求，不管 App 的 UI 有没有展示这个商品。

这跟我之前发现的每一个支付漏洞，本质都一样：

0 PHP 跨区混淆 ： Stripe 创建 session 时的区域信号不一致

prorationMode Hook ： Google Play Billing 的 proration 参数可被客户端修改

RevenueCat 凭证转移 ： RevenueCat 不校验付款人与开通人的对应关系

₱982 Pro 20x TOCTOU ： Stripe PI 金额锁定与订阅计划变更不互斥

iOS 收据复用 ： OpenAI 不校验收据与 Apple ID 的绑定关系

iOS IAP 强开（本文） ： App Store 商品未下架，API 层可绕过 UI 层限制

说白了就一句话：几层状态得对齐。UI 关了，API 也得关；API 关了，支付平台后台的商品也得跟着下架。中间任何一层没关严，那层就是留给别人的入口。

Apple In-App Purchase 文档

App Store Server Notifications V2

StoreKit 2 文档

SSL Kill Switch 2

mitmproxy 官方文档