联系逍遥

扫码添加微信，或点击下方按钮复制联系方式。

微信 plus6566 点击复制 QQ 826215906 点击复制

进微信群请联系博主，各位觉得文章对你有帮助的话可否打赏一些呀~

⚠️ 免责声明：本文仅供安全研究与技术学习。文中分析的技术手段仅用于理解 Apple IAP 系统与订阅管理的工作原理。请勿将相关技术用于任何未授权的操作。

前言

OpenAI 在 2026 年下半年关闭了 Pro 20x（$200/月）的新订阅入口。Web 端没了按钮，App 端没了选项，API 也不再接受新的 Pro 20x checkout 请求。

但有人发现了一个思路：不走 OpenAI 的 UI，直接走 Apple 的支付 API。

原理说起来就一句话——OpenAI 关的是自家前端的入口，但 App Store 后台的 IAP 商品还活着。只要你能构造一个合法的 Apple 购买请求，Apple 照样扣款、出收据，OpenAI 的服务端收到合法的 App Store 回执就得开通。

最近有人把这个方法开源了，我拿到了完整教程（包含前置条件、网络配置、越狱设置、拦截原理、操作流程、字段说明六个章节）。今天在这个基础上加入我们自己的技术分析——特别是与 Stripe 协议支付 和 Google Play 订阅转移 的对比——把整个攻击面拆清楚。

一、核心原理：为什么 App Store 能绕过 OpenAI 的限制

1.1 OpenAI 关了什么

OpenAI 做了这些事：

1. Web 端：移除了 Pro 20x 的订阅按钮和定价页入口
2. App 端：ChatGPT iOS/Android App 内不再展示 Pro 20x 选项
3. API 端：/payments/checkout 接口拒绝 plan_type=chatgptpro 的新建请求

1.2 OpenAI 没关什么

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

这很关键。在 Apple 的体系里，一个 IAP 商品（In-App Purchase Product）有自己的生命周期，它不受 App UI 层的控制。App 可以选择不在界面上展示某个 IAP 商品，但只要商品在 App Store Connect 后台还是 “Approved” 状态，Apple 的购买 API 就接受对它的购买请求。

打个比方：超市把某个商品从货架上撤了，但收银系统的数据库里还有这个商品的条码。你拿着条码去自助结账机一扫——滴，正常结账。

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

Apple 的内部购买端点是：

POST https://p70-buy.itunes.apple.com/WebObjects/MZBuy.woa/wa/buyProduct

这个 API 做三件事：

1. 验证鉴权：buyParams / guid / ams / cookie / afdsv2 这些字段是否合法
2. 验证商品：salableAdamId 对应的 IAP 商品是否存在且处于可购买状态
3. 处理支付：扣款 → 生成 receipt → 通过 App Store Server Notifications 推送给开发者

它不做的事：不检查 App 当前是否在 UI 上展示了这个商品。Apple 的支付系统和 App 的 UI 是完全解耦的。

1.4 OpenAI 必须 honor App Store 收据

根据 Apple 的 App Store Review Guidelines（特别是 3.1.1 In-App Purchase 条款），开发者必须为合法的 App Store 交易提供对应的服务。OpenAI 收到一张合法的 Pro 20x App Store 收据，就必须开通 Pro 20x——否则就是违反 Apple 的开发者协议。

所以整条链路是：

构造 buyProduct 请求
    ↓
Apple 验证鉴权 + 商品存在
    ↓
Apple 扣款 $200
    ↓
Apple 生成 receipt
    ↓
App Store Server Notification → OpenAI
    ↓
OpenAI 验证 receipt → 合法 → 开通 Pro 20x

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。

iOS 设备 → HTTP 代理（MITM） → 上游 SOCKS5 代理（美国住宅 IP） → Apple 服务器

推荐架构：

iPhone ──WiFi──▶ 电脑（Charles / mitmproxy）
                        │
                        ▼
               上游代理（US 住宅 IP）
                        │
                        ▼
             p70-buy.itunes.apple.com

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

3.2 MITM 证书安装

1. 打开 Charles → Help → SSL Proxying → Install Charles Root Certificate on a Mobile Device
2. iPhone 浏览器访问 chls.pro/ssl 下载证书
3. 设置 → 通用 → VPN 与设备管理 → 安装描述文件
4. 设置 → 通用 → 关于本机 → 证书信任设置 → 启用完全信任

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

3.3 SSL Proxying 规则

在 Charles 中配置 SSL Proxying：

Proxy → SSL Proxying Settings → Enable SSL Proxying
Add:
  Host: *.itunes.apple.com
  Port: 443
Add:
  Host: *.apple.com
  Port: 443

如果用 mitmproxy：

mitmproxy --mode regular --set upstream_cert=false -p 8888

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

四、iOS 越狱设备配置

4.1 越狱工具选择

提示：如果没有越狱设备，也可以用老款 iPhone（如 iPhone 8/X，A11 芯片）专门做这件事。闲鱼几百块收一台就行。

4.2 安装必要 Tweak

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

SSL Kill Switch 2    — 绕过证书锁定
PreferenceLoader     — Tweak 设置面板
AppList              — 应用列表（SSL Kill Switch 依赖）

SSL Kill Switch 2 设置：

Settings → SSL Kill Switch 2
  ├── Disable Certificate Validation: ON
  └── 选择目标 App → 勾选 App Store / iTunes Store

注意：不要全局开启证书绕过——那样会影响所有 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 且无解密内容

如果失败，排查：

1. SSL Kill Switch 是否选中了正确的进程（com.apple.AppStore）
2. 越狱环境是否完整（uicache / ldrestart 后重试）
3. 代理证书是否已经被完全信任（不只是安装）

五、订阅拦截与转移原理

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

5.1 Apple 购买请求的鉴权体系

当你在 App Store 里点击"购买"按钮时，iOS 系统会向 Apple 的购买服务器发送一个 HTTP POST 请求。这个请求携带 5 个关键鉴权字段：

这 5 个字段加在一起 = 你 Apple ID 的完整付款授权。 拿到它们，就等于拿到了以你的 Apple ID 身份向 Apple 发起购买请求的能力。

5.2 各字段深度解析

buyParams

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

• 当前 Apple ID 的 session 信息
• 购买请求的签名数据
• 设备上下文信息

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

guid

设备的硬件唯一标识符。在 iOS 上由设备的硬件信息（如 UDID 或网络接口地址等）经过哈希计算得出。格式为十六进制字符串，具体长度因 iOS 版本和设备型号而异。

这个值在设备恢复出厂之前是固定的。如果你用同一台设备多次操作，guid 始终相同——Apple 的风控系统会注意到这一点。

afdsv2

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

• 传感器数据（加速度计 / 陀螺仪等）
• 设备状态（电池、屏幕亮度等）
• 触控行为模式
• 网络环境信息
• 系统运行时信息

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

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

ams

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

cookie

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 订阅转移 是一个思路：

1. Apple ID A 在越狱设备上完成购买 → Pro 20x 订阅绑定到 Apple ID A
2. ChatGPT App 收到 App Store 的购买回执，准备把权益绑定到当前登录的 OpenAI 账号
3. 在 App 处理回执之前，切换 ChatGPT 的登录账号到目标账号 B
4. App 把 Pro 20x 权益绑到了账号 B

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

1. 在设备上完成购买，拦截 App 发给 OpenAI 的回执提交请求
2. 修改请求中的 auth token（换成目标账号的 token）
3. 重放请求 → 目标账号获得 Pro 20x

大白话：Apple 只管"收钱出票”，OpenAI 只管"验票开权"。中间把票给谁——全看你怎么操作。

六、订阅流程详解

6.1 完整操作流程

┌─────────────────────────────────────────────────────────┐
│               Phase 1: 鉴权数据捕获                      │
│                                                         │
│  越狱 iOS 设备 + MITM 代理 + SSL Kill Switch            │
│  打开 App Store → 触发任意 IAP 购买（如 Plus）           │
│  代理中拦截 POST .../buyProduct 请求                     │
│  提取: buyParams, guid, afdsv2, ams, cookie             │
│  阻断请求（不让它真正完成支付）                           │
└───────────────────────┬─────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────┐
│               Phase 2: 构造 Pro 20x 购买请求              │
│                                                         │
│  保留 Phase 1 的鉴权字段                                 │
│  替换商品参数为 Pro 20x 的值:                             │
│    productType = A                                      │
│    salableAdamId = 6657954405                            │
│    offerName = oai_chatgpt_pro_20000_1m                 │
│    price = 200000                                       │
│    appAdamId = 6448311069                               │
│  发送到: p70-buy.itunes.apple.com/.../buyProduct        │
└───────────────────────┬─────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────┐
│               Phase 3: Apple 处理 + OpenAI 开通           │
│                                                         │
│  Apple 验证鉴权 → 扣款 $200 → 生成 transaction           │
│  App Store Server Notification → OpenAI 后端             │
│  OpenAI 验证 receipt → 合法 → 开通 Pro 20x              │
│  或: 在 ChatGPT App 中 "Restore Purchases" 触发同步     │
└─────────────────────────────────────────────────────────┘

6.2 Phase 1 详细步骤

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

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

Proxy → Breakpoints → Add:
  Protocol: HTTPS
  Host: p70-buy.itunes.apple.com
  Path: */buyProduct*
  方向: Request（拦截请求，不拦截响应）

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 个关键字段并保存：

buyParams = <Base64 长字符串>
guid = <16位十六进制>
afdsv2 = <1000+ 字符的长字符串>
ams = <Apple Media Services token>
cookie = <完整的 Cookie 字符串>

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

6.3 Phase 2 详细步骤

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

POST https://p70-buy.itunes.apple.com/WebObjects/MZBuy.woa/wa/buyProduct
Content-Type: application/x-www-form-urlencoded
Cookie: <Phase 1 保存的完整 cookie>
X-Apple-I-MD: <Machine Data>
X-Apple-I-MD-M: <Machine Data Metadata>
X-Dsid: <Directory Services ID>

productType=A
&price=200000
&salableAdamId=6657954405
&pricingParameters=STDQ
&pg=default
&offerName=oai_chatgpt_pro_20000_1m
&appAdamId=6448311069
&guid=<Phase 1 的 guid>
&buyParams=<Phase 1 的 buyParams>
&afdsv2=<Phase 1 的 afdsv2>
&ams=<Phase 1 的 ams>

注意事项：

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 扣了钱，OpenAI 收到 Apple 的通知说"这个用户买了 Pro 20x"，OpenAI 就得开。或者用户在 App 里点一下"恢复购买"，效果一样。

七、关键请求与字段说明

7.1 商品参数逐字段拆解

productType=A&price=200000&salableAdamId=6657954405&pricingParameters=STDQ&pg=default&offerName=oai_chatgpt_pro_20000_1m&appAdamId=6448311069

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

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

7.3 端点地址解析

https://p70-buy.itunes.apple.com/WebObjects/MZBuy.woa/wa/buyProduct

题外话：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 三条路径

┌──────────────────────────────────────────────────────────────────┐
│                    ChatGPT Pro 20x 开通                          │
│                                                                  │
│  路径 1: Stripe 协议支付                                          │
│  ┌─────────┐   ┌────────────┐   ┌────────────┐   ┌──────────┐  │
│  │ HAR 抓包 │→ │ 构造 ctoken │→ │ PI confirm  │→ │ Stripe   │  │
│  │ (浏览器) │   │ + 税务优化  │   │ + 3DS 处理  │   │ webhook  │  │
│  └─────────┘   └────────────┘   └────────────┘   └──────────┘  │
│                                                                  │
│  路径 2: Google Play 订阅转移                                     │
│  ┌─────────┐   ┌────────────┐   ┌────────────┐   ┌──────────┐  │
│  │ MITM 或  │→ │ 提取 fetch │→ │ RC /receipts│→ │ RC 通知  │  │
│  │ ADB 提取 │   │ _token     │   │ + account  │   │ OpenAI   │  │
│  └─────────┘   └────────────┘   └────────────┘   └──────────┘  │
│                                                                  │
│  路径 3: Apple IAP 强开（本文）                                    │
│  ┌─────────┐   ┌────────────┐   ┌────────────┐   ┌──────────┐  │
│  │ 越狱    │→ │ 抓取 5 个   │→ │ buyProduct  │→ │ ASSN V2  │  │
│  │ + MITM  │   │ 鉴权字段   │   │ API 调用    │   │ 通知     │  │
│  └─────────┘   └────────────┘   └────────────┘   └──────────┘  │
└──────────────────────────────────────────────────────────────────┘

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”（恢复购买）
4. StoreKit 查询 Apple ID A 的有效订阅 → 找到 Pro 20x
5. ChatGPT 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 的服务条款都禁止此类操作
• 计算机欺诈：通过技术手段获取未被授权的服务访问权

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

十一、技术总结

完整攻击链路

越狱 iOS + MITM → 抓取 buyParams/guid/afdsv2/ams/cookie
                    ↓
            构造 Pro 20x buyProduct 请求
                    ↓
  p70-buy.itunes.apple.com/WebObjects/MZBuy.woa/wa/buyProduct
                    ↓
         Apple 验证鉴权 → 扣款 $200 → 生成 receipt
                    ↓
    App Store Server Notification V2 → OpenAI 后端
                    ↓
        OpenAI 验证 receipt → 合法 → 开通 Pro 20x

漏洞本质

平台方（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 官方文档
• Stripe 协议支付深度拆解（本站）
• GPT Plus 订阅转移全解析（本站）
• iOS 收据复用漏洞（本站）

标签: #ChatGPT #Pro20x #iOS #Apple #IAP #越狱 #AppStore #支付安全 #订阅 #逆向工程 #Stripe #GooglePlay