# C2PA Cameras Do Not Survive Contact With Reality > Source: > Published: 2026-08-25 15:51:24+00:00 [C2PA Cameras Do Not Survive Contact With Reality](#c2pa-cameras-do-not-survive-contact-with-reality) *By David Buchanan (aka retr0id), 25 th August 2026* You might have heard that [C2PA](https://c2pa.org/) is a technology that will miraculously save us from rampant AI forgeries, by having cameras cryptographically sign the images they capture. Hooray for [cryptography](https://www.aumasson.jp/murphy.html)! 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](https://developer.android.com/privacy-and-security/security-key-attestation)and/or[Google Play Integrity](https://developer.android.com/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](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#_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](https://www.da.vidbuchanan.co.uk/blog/dram-emfi.html).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**. 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](https://blog.google/security/pixel-android-trusted-images-c2pa-content-credentials/): The Pixel Camera app [, the highest security rating]achieved Assurance Level 2[currently defined]by the C2PA Conformance Program. Assurance Level 2 for a mobile app is currentlyonly 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](https://www.youtube.com/watch?v=o6SPloDkUy0) that the infobox says was "captured with a camera" (spoiler alert: it wasn't). By the way, Apple is [rumoured](https://www.macrumors.com/2026/08/10/ios-27-apple-reference-image/) 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?](#how-does-root-lpe-break-quothardwarebackedquot-key-attestation) Attestation only attests certain things, including: - Whether the bootloader is locked. - Whether the [AVB](https://source.android.com/docs/security/features/verifiedboot/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](https://nvd.nist.gov/vuln/detail/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?](#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?](https://www.da.vidbuchanan.co.uk/blog/dram-emfi.html) I *was* going to write about it in-depth here, but frankly the software-only [exploit](https://github.com/alex193a/Root-My-Pixel) [paths](https://github.com/BuSung-dev/Root-My-Galaxy) 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](https://github.com/alex193a/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](https://github.com/DavidBuchanan314/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 (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](https://github.com/rikkaapps/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](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?](#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](https://docs.samsungknox.com/admin/fundamentals/whitepaper/samsung-knox-mobile-security/system-security/real-time-kernel-protection/)" 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](https://connormcgarr.github.io/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](https://eprint.iacr.org/2016/204.pdf), and Apple's SEP [Memory Protection Engine](https://support.apple.com/en-gb/guide/security/sec59b0b31ff/web#secb8d5e5708). 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](https://batteringram.eu/)). 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?](#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](https://github.com/c2pa-org/conformance-public/blob/main/conforming-products/conforming-products-list.json) (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!) [Thanks](#thanks) While I've taken a recent foray into the C2PA ecosystem, Dr. Neal Krawetz of [Hacker Factor](https://www.hackerfactor.com/blog/) 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](https://www.hackerfactor.com/blog/index.php?/archives/1102-C2PA-and-Pixel-Glitter-Milk.html). Thank you also to the [Provenance and Authenticity Standards Assessment Working Group](https://cisa.umbc.edu/pasawg/) (PASAWG), who are likewise researching the effectiveness of C2PA. [Oh, and one more thing...](#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.