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 验证工具并不会检查吊销状态。我相信他们很快也会修复这个问题。
C2PA Cameras Do Not Survive Contact With Reality
By David Buchanan (aka retr0id), 25 th August 2026
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!
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).
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.
As you can see, I'm focusing on Android here. I'll let Google explain why:
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.
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)
And, here's a Youtube video that the infobox says was "captured with a camera" (spoiler alert: it wasn't).
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.
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?
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.
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.)
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.
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).
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:
Any moderately-well-funded entity, from governments to mobile forensics companies, can build a stockpile of private exploits (and so they do). These are exactly the groups you don't want to be forging C2PA signatures.
Low-cost hardware exploits exist, regardless of patch level.
How did I sign the demo image and video?
Initially, I used a hardware attack. It was a continuation of my earlier research: Can You Get Root With Only a Cigarette Lighter?
I was going to write about it in-depth here, but frankly the software-only exploitpaths stole my thunder. Software exploits are much more convenient when they exist, so I'll save the full hardware details for another time. There's no rush, since the hardware exploits can't be patched, for the most part.
If you'd like to reproduce my findings today, I recommend the Root My Pixel tool. (Note: while it supports the latest August security updates of most Pixel devices today, you'll need to build from main to enable that support. I've personally tested on Pixel 8a and 9a.)
After getting root, the rest of the attack is just plumbing. I made a tool to facilitate this: keystork. Keystork has a client/server architecture, allowing client code to perform arbitrary operations against the KeyStore API, while impersonating any installed app. The "server" (keystorkd) runs on a rooted device, and the client is anything that can speak the wire protocol I made up (transported by default via a unix domain socket forwarded over ADB). The reference client is a python library with a corresponding CLI interface, but in theory Android apps could talk to it, Shizuku-style (although you'd want to build an auth/permissions layer first).
Here's a "sign any image" PoC script, against the Pixel Camera app: https://gist.github.com/DavidBuchanan314/fa0ffdaaaa31594e6a511118c1cea1e0
While software exploits can and will be patched (eventually), the hardware exploits are forever. Or are they?
Can the hardware attacks be mitigated?
In theory yes, in practice not really.
My initial strategy (flipping bits in PTEs) still works on Pixel devices today. However, it does not work on Samsung devices!
I did some of my initial tests on a Samsung A07 device (because they're cheap). The exploit worked at the time, but after a security update it stopped working (I think the timing was a coincidence). The update enabled Samsung's "RKP" mitigation (Real-time Kernel Protection, not to be confused with Remote Key Provisioning...)
Among other things, Samsung's mitigations use an EL2 hypervisor to apply additional protections to certain memory regions (a bit like Microsoft's HVCI). I can still use hardware exploits to flip bits in PTEs, but even if I map a PTE into userspace via glitching, EL2 won't let me overwrite it (which was an essential part of my exploit, as initially designed).
I have several plans for alternate strategies to work around Samsung's mitigations, but I haven't gotten around to implementing them yet. One of my alternate strategies should work even in the presence of hardware memory encryption. Once I get it working, I'd like to package this strategy up into a "universal Android hardware root" tool—watch this space? (I would also like to pop HVCI to mess with anti-cheat, watch that space, too.)
At the hardware level, several solutions exist that treat external DRAM as completely untrusted, thus mitigating any kind of bus faulting attack, in theory at least. Examples include Intel MEE, and Apple's SEP Memory Protection Engine. However, these solutions are not performant enough to realistically run the whole Android linux kernel within (which is why Apple only uses it to protect SEP and not the main AP, and Intel dropped the feature entirely in newer SGX revisions, leading to attacks like Battering RAM).
Even with the best hardware-level mitigations, fixing C2PA on Android is going to involve completely rearchitecting the software stack. The entire image processing pipeline, including all the fancy AI stuff, would need to run inside a secure enclave with strong hardware memory protection.
I don't think Google is going to do all that, which is probably why they closed my report with status "Won't fix (infeasible)". It just doesn't make sense to do all that rearchitecting, when you still can't stop "picture of screen" style attacks.
By the way, despite the WONTFIX resolution, Google chose to award me a $7500 bounty for the submission:
Thank you for submitting your report. While hardware glitching and side channel attacks are out of scope for our bug bounty program, our security team found your findings valuable, and the data you provided will help us improve future iterations of the product.
I wasn't expecting a bounty (I knew it was formally out-of-scope), so it was a nice surprise. It'll cover all the devices I bricked during my research. But it's worth noting:
The most obvious (to me) C2PA attack vector is out of scope for Google's VRP. Thus, the VRP does not meaningfully protect Android C2PA implementations.
How broad is the impact?
I've been focusing on the Pixel Camera app here, but there are several other "C2PA Camera" apps on Android. All those I've investigated rely on either Key Attestation or Play Integrity for their security. They are all broken in the same way, except they're not exclusive to Google Pixel devices. This means you don't need to root a Pixel device, you can pick the cheapest and most vulnerable device in the whole Android ecosystem to run your exploit on.
They are all victims of Google's misleading marketing claims regarding the effectiveness of their platform's security. You can find a full list of "Conformant" C2PA implementations here (All that include Android_KeyAttestation or Google_PlayIntegrity in their attestationMethods list are likely vulnerable)
Outside of C2PA, I've been having fun using my hardware glitching strategy to root a wide variety of Android devices, including an Amazon Fire TV stick and a Meta Quest 3s VR headset (again, I will probably write more about this later!)
Aside: Meta already patched the CVE-2026-43499 LPE on Quest headsets, near the start of the month, to stop people from cheating in VR video games. It's absolutely bonkers to me that Google has not issued a patch for even their flagship Pixel devices yet.
Thanks
While I've taken a recent foray into the C2PA ecosystem, Dr. Neal Krawetz of Hacker Factor has been sounding the alarm about it for years. His writing was my introduction to the topic, and he's been very helpful in discussing things with me, as well as helping coordinate vulnerability disclosures.
You can read his takes on these vulnerabilities here.
Thank you also to the Provenance and Authenticity Standards Assessment Working Group (PASAWG), who are likewise researching the effectiveness of C2PA.
Oh, and one more thing...
While preparing my PoC for publication, I had a fun "but what if?" thought. Pulling on that thread led me to a private key disclosure vulnerability. I reported it to Google two days ago, and they seem to have patched it yesterday (this is why I prefer hardware attacks, patches ruin the fun). I'll probably write more about it in the future.
This is where I would paste in a Pixel Camera C2PA private key and corresponding certificate chain, if I wasn't a coward. But I decided not to. If you're a journalist who'd like a peek, let me know.
I assume Google has revoked this particular key by now (I included it in my report to them). However most C2PA verification tools do not check for revocation. I'm sure they'll fix that soon, too.