【文章标题】：C2PA Cameras Do Not Survive Contact with Reality
【文章标题】：C2PA相机经不起现实的考验
【文章正文】：
C2PA Cameras Do Not Survive Contact With Reality
C2PA相机经不起现实的考验
By David Buchanan (aka retr0id), 25th August 2026
作者：David Buchanan（又名 retr0id），2026年8月25日
You might have heard that C2PA is a technology that will miraculously save us from rampant AI forgeries, by having cameras cryptographically sign the images they capture. Hooray for cryptography!
你可能听说过，C2PA是一项将通过让相机对其拍摄的图像进行加密签名，从而奇迹般地将我们从猖獗的AI伪造中拯救出来的技术。密码学万岁！
Sorry. That’s not going to work. There’s a lot going on here, so I’ll try to get to the point as quickly as possible:
抱歉。这行不通。这里涉及很多问题，所以我将尽可能快地切入正题：
-
C2PA camera apps on the Android platform rely on Key Attestation and/or Google Play Integrity, to prevent users from tampering with the app to sign arbitrary files (as opposed to data from the device’s image sensor).
-
Being able to sign arbitrary files breaks C2PA’s trust model.
-
Root privilege escalation exploits break Android’s Key Attestation security model, and Play Integrity likewise.
-
Android devices can be rooted via low-cost hardware fault injection attacks.
-
Hardware vulnerabilities in existing devices cannot be patched (there’s nuance here, discussed later).
-
Therefore, C2PA on the Android platform is broken, in a way that cannot be realistically patched.
-
None of the above is “0day”, and has been reported to the relevant parties at least 90 days ago (but anyone with their head screwed on should have seen it coming, as many have).
-
Android平台上的C2PA相机应用依赖密钥认证和/或Google Play完整性，以防止用户篡改应用以签署任意文件（而不是来自设备图像传感器的数据）。
-
能够签署任意文件破坏了C2PA的信任模型。
-
Root提权漏洞利用破坏了Android的密钥认证安全模型，Play Integrity同样如此。
-
Android设备可以通过低成本硬件故障注入攻击被root。
-
现有设备中的硬件漏洞无法修补（这里有细微差别，稍后讨论）。
-
因此，Android平台上的C2PA被破坏了，而且这种破坏无法现实地修补。
-
以上没有一个是“0day”，并且至少在90天前就已报告给相关方（但任何头脑清醒的人都应该早就预见到了，许多人确实如此）。
But wait, there’s more! Thanks in part to LLMs, root LPEs are coming out faster than Google can ship patches. At time of writing, one-click root exploits exist in-the-wild for fully-patched Google Pixel devices (via CVE-2026-43499). With these, anyone can produce C2PA forgeries without requiring hardware attacks. Later in this article, I’ll provide instructions for doing so.
但是等等，还有更多！部分由于LLM，root本地提权漏洞的出现速度比谷歌发布补丁的速度还快。在撰写本文时，针对已完全打补丁的Google Pixel设备，野外已存在一键root漏洞利用（通过CVE-2026-43499）。有了这些，任何人都可以在不需要硬件攻击的情况下制造C2PA伪造。在本文后面，我将提供操作说明。
As you can see, I’m focusing on Android here. I’ll let Google explain why:
如你所见，我在这里专注于Android。我让谷歌来解释原因：
The Pixel Camera app achieved Assurance Level 2, the highest security rating currently defined by the C2PA Conformance Program. Assurance Level 2 for a mobile app is currently only possible on the Android platform.
Pixel相机应用达到了保证等级2，这是C2PA一致性计划目前定义的最高安全等级。移动应用达到保证等级2目前仅在Android平台上可能。
i.e. I’m attacking the “strongest” implementation, just to make a point. Here’s an AI-generated slop image, which C2PA says is a real unedited photograph straight out of the Pixel Camera app: (Hover to un-blur, click to “verify” it)
也就是说，我攻击的是“最强”的实现，只是为了说明问题。这是一张AI生成的劣质图像，C2PA声称它是直接来自Pixel相机应用的真实未编辑照片：（悬停以取消模糊，点击“验证”）
And, here’s a Youtube video that the infobox says was “captured with a camera” (spoiler alert: it wasn’t).
还有，这是一个YouTube视频，信息框显示它“用相机拍摄”（剧透警告：并非如此）。
Edit, 2026-08-25T19:12:16Z: Google appears to have removed the “Captured with a camera” section from the video description, presumably manually. That doesn’t achieve muchâread on to learn how to sign your own media. Also I swapped out the URL for another one. The forgeries will continue until morale improves.
编辑，2026-08-25T19:12:16Z：谷歌似乎已从视频描述中删除了“用相机拍摄”部分，大概是手动删除的。这并没有多大作用——继续阅读以了解如何签署你自己的媒体。另外，我把URL换成了另一个。伪造将继续，直到士气提高。
By the way, Apple is rumoured to be working on their own media provenance solution, but it doesn’t exist yet. I’ll let you know what I think of it, when it does. I suspect their vertical integration will give them a significant advantage, which might shift the lowest-hanging-fruit attacks into the optical domain (taking pictures of screens, etc.)
顺便说一句，据传苹果正在开发他们自己的媒体溯源解决方案，但它尚不存在。等它出现时，我会告诉你我的看法。我怀疑他们的垂直整合将给他们带来显著优势，这可能会将最容易得手的攻击转移到光学领域（拍摄屏幕照片等）。
Anyway, let’s get into the details.
无论如何，让我们进入细节。
How does root LPE break “hardware-backed” key attestation?
Root本地提权如何破坏“硬件支持”的密钥认证？
Attestation only attests certain things, including:
认证只证明某些事项，包括：
-
Whether the bootloader is locked.
-
Whether the AVB keys are the vendor’s own.
-
Whether the device is running the latest security update.
-
引导加载程序是否已锁定。
-
AVB密钥是否是供应商自己的。
-
设备是否运行最新的安全更新。
The “normal” way to root an Android device is to unlock the bootloader and flash a modified firmware image, which forces a factory reset of the device in the process. Attestation will flag that the bootloader is unlocked, and Google will refuse to provision C2PA keys to your device (and Netflix won’t serve you high-res content, your banking app won’t work, etc. etc.)
root Android设备的“正常”方法是解锁引导加载程序并刷入修改过的固件镜像，这个过程会强制设备恢复出厂设置。认证会标记引导加载程序已解锁，谷歌将拒绝为你的设备配置C2PA密钥（而且Netflix不会为你提供高清内容，你的银行应用将无法工作，等等等等）。
So far, so good (if you’re into that kind of thing.)
到目前为止，一切顺利（如果你喜欢那种事情的话。）
However, if you root a device via an exploit, the attestation mechanism has no reliable way to “notice”. The bootloader is still locked, the AVB keys are unmodified, and the device is still running whatever security update it booted with initially. Now Google’s servers will happily provision keys to a compromised device.
然而，如果你通过漏洞利用root设备，认证机制没有可靠的方法来“察觉”。引导加载程序仍然锁定，AVB密钥未被修改，设备仍然运行着它最初启动时的任何安全更新。现在谷歌的服务器将很乐意为被攻破的设备配置密钥。
The C2PA keys are still protected by hardware security, inside StrongBox (in Titan M2, on newer Pixel devices). This does stop an attacker from pulling out the keys, even with root. However, an attacker does not need the raw key material! As root, they can ask StrongBox to use these keys to sign whatever data they like, and produce C2PA forgeries (or decrypt your Signal inbox, among other bad things).
C2PA密钥仍然受到硬件安全保护，位于StrongBox内部（在较新的Pixel设备上的Titan M2中）。这确实阻止了攻击者提取密钥，即使拥有root权限。然而，攻击者并不需要原始密钥材料！作为root，他们可以要求StrongBox使用这些密钥签署任何他们想要的数据，并制造C2PA伪造（或者解密你的Signal收件箱，以及其他坏事）。
The theory behind the design of the attestation mechanism is that known software LPEs should be patched, and then the Relying Party (the entity verifying the attestation report) can require that users install the updates, and then the updated device can no longer be LPE’d.
认证机制设计背后的理论是，已知的软件本地提权漏洞应该被修补，然后依赖方（验证认证报告的实体）可以要求用户安装更新，然后更新后的设备就不能再被本地提权了。
CVE-2026-43499 is proof that timely patches are not always available, but let’s give everyone the benefit of the doubt and pretend that public exploits for unpatched bugs never exist. There are two remaining problems:
CVE-2026-43499证明及时的补丁并不总是可用，但让我们假定每个人都是善意的，并假装针对未修补漏洞的公开利用从未存在。还有两个问题：
-
Any moderately-well-funded entity, from governments to mobil
-
任何资金中等充裕的实体，从政府到移动