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

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

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

引导加载程序是否已锁定。
AVB 密钥是否为厂商自己的密钥。
设备是否运行最新的安全更新。

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

任何资金还算充裕的实体，从政府到手机取证公司，都能囤积一批私有漏洞利用代码（而且它们确实这么做了）。而这些恰恰是你最不希望它们伪造 C2PA 签名的群体。
无论补丁级别如何，低成本硬件漏洞利用始终存在。

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

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

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

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

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

哦，还有一件事……

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

总之，让我们进入正题。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

影响范围有多广？

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

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

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

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

Android 平台上的 C2PA 相机应用依赖密钥证明（Key Attestation）和/或 Google Play Integrity，以防止用户篡改应用来签署任意文件（而非仅限设备图像传感器输出的数据）。
能够签署任意文件会破坏 C2PA 的信任模型。
提权漏洞利用会攻破 Android 的密钥证明安全模型，Play Integrity 同样如此。
Android 设备可以通过低成本的硬件故障注入攻击获得 root 权限。
现有设备中的硬件漏洞无法通过补丁修复（这里有一些细微差别，稍后讨论）。
因此，Android 平台上的 C2PA 已被攻破，而且是以一种无法通过补丁实际修复的方式。
以上内容没有一个是“0day”，且已在至少 90 天前报告给相关方（但任何头脑清醒的人都应该预见到这一点，事实上很多人也确实预见到了）。

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

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

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

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

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

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

C2PA 相机经不起现实的检验

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