# C2PA相机经不起现实的考验：Android端可被root攻击伪造签名

- 来源：Hacker News 热门（buzzing.cc 中文翻译）
- 作者：Retr0id
- 发布时间：2026-08-26 22:05
- AIHOT 分数：77
- AIHOT 标记：精选
- AIHOT 链接：https://aihot.virxact.com/items/cmta6v56y03ytroj25ggn7rlo
- 原文链接：https://www.da.vidbuchanan.co.uk/blog/android-c2pa.html

## 精选理由

文章用可复现的 root 攻击展示 C2PA 签名可被伪造，说明把真实性押注在 Android 硬件证明上的方案存在系统性缺陷，信任模型需要重新设计。

## AI 摘要

安全研究员David Buchanan指出，C2PA相机认证在Android平台上可被攻破。通过root权限提升漏洞（如CVE-2026-43499），攻击者可利用StrongBox硬件签名任意数据，伪造C2PA签名图像和视频，且无需硬件攻击。该问题无法通过常规补丁修复，已提前90天向相关方报告。

## 正文

C2PA 相机经不起现实的检验

作者：David Buchanan（又名 retr0id），2026 年 8 月 25 日

你可能听说过，C2PA 是一项能奇迹般拯救我们于猖獗 AI 伪造的技术，它让相机对拍摄的图像进行密码学签名。密码学万岁！

抱歉。这行不通。这里涉及的问题很多，我会尽量快速切入正题：

Android 平台上的 C2PA 相机应用依赖密钥证明（Key Attestation）和/或 Google Play Integrity，以防止用户篡改应用来签署任意文件（而非仅限设备图像传感器输出的数据）。

能够签署任意文件会破坏 C2PA 的信任模型。

提权漏洞利用会攻破 Android 的密钥证明安全模型，Play Integrity 同样如此。

Android 设备可以通过低成本的硬件故障注入攻击获得 root 权限。

现有设备中的硬件漏洞无法通过补丁修复（这里有一些细微差别，稍后讨论）。

因此，Android 平台上的 C2PA 已被攻破，而且是以一种无法通过补丁实际修复的方式。

以上内容没有一个是“0day”，且已在至少 90 天前报告给相关方（但任何头脑清醒的人都应该预见到这一点，事实上很多人也确实预见到了）。

但等等，还有更多！部分得益于大语言模型，root 级本地提权漏洞的出现速度已经超过 Google 发布补丁的速度。撰写本文时，针对已完全打补丁的 Google Pixel 设备，野外已存在一键 root 利用（通过 CVE-2026-43499）。借助这些漏洞，任何人都可以制造 C2PA 伪造品，而无需硬件攻击。在本文后面，我会提供具体操作说明。

如你所见，我在这里聚焦 Android。让 Google 来解释原因：

Pixel 相机应用达到了保证级别 2（Assurance Level 2），这是 C2PA 一致性计划目前定义的最高安全评级。移动应用要达到保证级别 2，目前只有在 Android 平台上才有可能。

也就是说，我攻击的是“最强”的实现，只是为了说明问题。下面这张 AI 生成的垃圾图片，C2PA 却声称是 Pixel 相机应用直接输出的真实未编辑照片：（悬停可取消模糊，点击可“验证”）

而且，这里有一段 YouTube 视频，信息框里写着它是“用相机拍摄的”（剧透警告：其实不是）。

编辑于 2026-08-25T19:12:16Z：谷歌似乎已从视频描述中删除了“用相机拍摄”这一栏，大概是手动删除的。但这没什么用——继续往下读，了解如何为自己的媒体内容签名。另外，我把链接换成了另一个。伪造行为会一直持续，直到士气好转为止。

顺便说一句，有传闻称苹果正在开发自己的媒体来源验证方案，但目前还不存在。等它推出后，我会告诉你我的看法。我怀疑他们的垂直整合会带来显著优势，这可能会把最容易得手的攻击转移到光学领域（比如拍摄屏幕画面等）。

总之，让我们进入正题。

根权限本地提权（root LPE）是如何攻破“硬件背书”的密钥认证的？

认证机制只认证特定事项，包括：

引导加载程序是否已锁定。

AVB 密钥是否为厂商自己的密钥。

设备是否运行最新的安全更新。

“常规”的 Android 设备获取 root 权限的方法是解锁引导加载程序并刷入修改过的固件镜像，这个过程会强制恢复设备出厂设置。认证机制会标记引导加载程序已解锁，谷歌将拒绝向你的设备签发 C2PA 密钥（Netflix 也不会向你提供高清内容，银行应用也无法使用，等等等等）。

到目前为止，一切还算顺利（如果你喜欢这种机制的话）。

然而，如果你通过漏洞利用获取 root 权限，认证机制就没有可靠的方法来“察觉”。引导加载程序仍然锁定，AVB 密钥未被修改，设备仍然运行着最初启动时的安全更新。现在，谷歌的服务器会欣然向一台已被入侵的设备签发密钥。

C2PA 密钥仍然受到硬件安全的保护，位于 StrongBox 内部（在较新的 Pixel 设备上是 Titan M2）。这确实能阻止攻击者提取密钥，即使拥有 root 权限也不行。然而，攻击者并不需要原始密钥材料！作为 root 用户，他们可以要求 StrongBox 使用这些密钥签署他们想要的任何数据，并生成 C2PA 伪造内容（或者解密你的 Signal 收件箱，以及其他各种坏事）。

认证机制设计背后的理论是：已知的软件本地提权漏洞应当被修补，然后依赖方（即验证认证报告的一方）可以要求用户安装更新，这样更新后的设备就不再能被本地提权攻击了。

CVE-2026-43499 证明了及时修补并不总是可行的，但让我们先假定所有人都是善意的，假装针对未修补漏洞的公开利用代码从来不存在。那么还剩两个问题：

任何资金还算充裕的实体，从政府到手机取证公司，都能囤积一批私有漏洞利用代码（而且它们确实这么做了）。而这些恰恰是你最不希望它们伪造 C2PA 签名的群体。

无论补丁级别如何，低成本硬件漏洞利用始终存在。

我是如何给演示图片和视频签名的？

最初，我使用了硬件攻击。这是我之前研究的延续：只用一只打火机就能拿到 root 权限吗？

我本来想在这里详细写一写，但坦率地说，纯软件漏洞利用路径抢了我的风头。软件漏洞利用在存在时方便得多，所以硬件细节我留到以后再完整写。不用着急，因为硬件漏洞利用在大多数情况下是无法通过补丁修复的。

如果你想今天就复现我的发现，我推荐 Root My Pixel 工具。（注意：虽然它目前支持大多数 Pixel 设备最新的 8 月安全更新，但你需要从 main 分支自行构建才能启用该支持。我个人在 Pixel 8a 和 9a 上测试过。）

拿到 root 权限后，攻击的其余部分就只是管道工程了。我做了一个工具来简化这个过程：keystork。Keystork 采用客户端/服务器架构，允许客户端代码在冒充任何已安装应用的同时，对 KeyStore API 执行任意操作。“服务器”（keystorkd）运行在已 root 的设备上，客户端则是任何能说通我自创的线上协议的东西（默认通过 ADB 转发的 Unix 域套接字传输）。参考客户端是一个带对应 CLI 接口的 Python 库，但理论上 Android 应用也能以 Shizuku 风格与它通信（不过你得先构建一个认证/权限层）。

这里有一个针对 Pixel 相机应用的“签署任意图像”概念验证脚本：https://gist.github.com/DavidBuchanan314/fa0ffdaaaa31594e6a511118c1cea1e0

软件漏洞可以而且将会（最终）被修补，但硬件漏洞却是永久性的。真的是这样吗？

硬件攻击能否被缓解？

理论上可以，实际上不太行。

我最初的策略（翻转 PTE 中的比特位）至今在 Pixel 设备上仍然有效。但在三星设备上却行不通！

我最初的一些测试是在三星 A07 设备上进行的（因为它们便宜）。当时漏洞利用是有效的，但一次安全更新后就不再起作用了（我觉得时间上只是巧合）。这次更新启用了三星的“RKP”缓解措施（实时内核保护，不要与远程密钥配置混淆……）

除其他措施外，三星的缓解方案使用 EL2 虚拟机监控器对某些内存区域施加额外保护（有点像微软的 HVCI）。我仍然可以利用硬件漏洞翻转 PTE 中的比特位，但即使我通过故障注入将 PTE 映射到用户空间，EL2 也不会允许我覆盖它（这在我最初设计的漏洞利用中是必不可少的一步）。

我有几个替代策略的计划来绕过三星的缓解措施，但还没有时间去实现它们。我的一个替代策略即使在硬件内存加密存在的情况下也应该有效。一旦我把它弄通了，我想把这个策略打包成一个“通用 Android 硬件 root 工具”——敬请期待？（我还想攻破 HVCI 来干扰反作弊系统，也敬请期待。）

在硬件层面，存在几种将外部 DRAM 视为完全不可信的解决方案，从而至少在理论上缓解任何类型的总线故障注入攻击。例如 Intel MEE 和 Apple 的 SEP 内存保护引擎。然而，这些方案的性能不足以实际承载整个 Android Linux 内核运行（这就是为什么 Apple 只用它来保护 SEP 而不是主应用处理器，而 Intel 在较新的 SGX 修订版中完全放弃了该功能，导致了像 Battering RAM 这样的攻击）。

即便有了最好的硬件级缓解措施，要在 Android 上修复 C2PA，也必然涉及对整个软件技术栈的彻底重构。整个图像处理流水线，包括所有花哨的 AI 功能，都需要在具备强硬件内存保护的安全飞地内运行。

我不认为 Google 会去做所有这些工作，这大概就是他们以“无法修复（不可行）”的状态关闭我报告的原因。当你仍然无法阻止“拍屏幕”这类攻击时，做所有这些重构确实没什么意义。

顺便说一下，尽管结论是 WONTFIX（不予修复），Google 还是决定为这份提交奖励我 7500 美元：

感谢您提交报告。虽然硬件故障注入和侧信道攻击不在我们漏洞奖励计划的范围之内，但我们的安全团队认为您的发现很有价值，您提供的数据将帮助我们改进产品的未来迭代。

我本来没指望拿到奖金（我知道这在形式上超出了范围），所以这是个惊喜。这笔钱能覆盖我在研究过程中弄坏的所有设备。但值得注意的是：

在我看来最明显的 C2PA 攻击途径，却不在 Google VRP（漏洞奖励计划）的范围之内。因此，VRP 并不能切实保护 Android 上的 C2PA 实现。

影响范围有多广？

我在这里一直专注于 Pixel 相机应用，但 Android 上还有其他几个“C2PA 相机”应用。我调查过的所有应用，其安全性要么依赖密钥证明（Key Attestation），要么依赖 Play Integrity。它们都以同样的方式被攻破，只不过它们并非 Google Pixel 设备独有。这意味着你不需要 root 一台 Pixel 设备，你可以挑选整个 Android 生态系统中价格最低、最易受攻击的设备来运行你的漏洞利用程序。

它们都是 Google 关于其平台安全有效性误导性宣传的受害者。你可以在这里找到完整的“符合规范”的 C2PA 实现列表（所有在其 attestationMethods 列表中包含 Android_KeyAttestation 或 Google_PlayIntegrity 的实现，可能都容易受到攻击）。

除了 C2PA 之外，我还一直在用我的硬件故障注入策略来 root 各种 Android 设备，包括亚马逊 Fire TV 棒和 Meta Quest 3s VR 头显（再说一次，我可能稍后会写更多相关内容！）

顺便说一句：Meta 已经在月初修补了 Quest 头显上的 CVE-2026-43499 本地权限提升漏洞，以防止人们在 VR 游戏中作弊。让我完全无法理解的是，Google 甚至还没有为其旗舰 Pixel 设备发布补丁。

谢谢

虽然我最近才涉足 C2PA 生态系统，但 Hacker Factor 的 Neal Krawetz 博士多年来一直在就此事发出警告。他的文章是我了解这个主题的入门读物，而且他在与我讨论问题以及协助协调漏洞披露方面帮了很大的忙。

你可以在这里阅读他对这些漏洞的看法。

还要感谢来源与真实性标准评估工作组（PASAWG），他们同样在研究 C2PA 的有效性。

哦，还有一件事……

在准备公开发布我的概念验证（PoC）时，我产生了一个有趣的“但是万一呢？”的想法。顺着这个思路深挖下去，我发现了 一个私钥泄露漏洞。我两天前向 Google 报告了这个问题，他们似乎在昨天就修补了它（这就是为什么我更喜欢硬件攻击，补丁会毁掉乐趣）。我将来可能会写更多相关内容。

如果我不是个胆小鬼的话，这里本该粘贴一个 Pixel 相机 C2PA 私钥及对应的证书链。但我决定不这么做。如果你是记者，想看一眼，请告诉我。

我猜 Google 现在应该已经吊销了这个特定的密钥（我在给他们的报告中包含了它）。然而，大多数 C2PA 验证工具并不会检查吊销状态。我相信他们很快也会修复这个问题。