C2PA Android Cameras Broken: Pixel Assurance Level 2 Forged Anyway

C2PA on Android just failed its strongest test. On August 25, 2026, security researcher David Buchanan (retr0id) published C2PA Cameras Do Not Survive Contact with Reality — a working break of Pixel Camera, the only mobile app certified at C2PA Assurance Level 2, the highest rating in the conformance program. His demo: an AI-generated slop image that C2PA verification accepts as a real, unedited photograph from Pixel Camera, plus a YouTube video whose infobox claimed it was "captured with a camera" when it was not.

The thread hit ~75 points on Hacker News under the same title — unusually practitioner-heavy for a cryptography post. explainx.ai's read: this is not a niche Android bug. It is a trust-model failure for anyone treating Content Credentials as forensic proof rather than a compliance and workflow signal — the same distinction we draw in what C2PA actually is and what changed after EU AI Act enforcement.

TL;DR — what people are asking

What Buchanan demonstrated

Google's own marketing set up the target. At Made by Google 2025, the company announced Pixel 10 would attach Content Credentials to every Pixel Camera JPEG — achieving Assurance Level 2 through Tensor G5, Titan M2, and Android's hardware-backed security APIs. Buchanan's opening move: attack the strongest implementation to make the point general.

His published results:

1. AI-generated image — blurred in the blog post; hover reveals slop; click runs C2PA verification that reports a genuine Pixel Camera capture.
2. YouTube video — provenance infobox showed "Captured with a camera" until Google manually removed that section (~19:12 UTC same day). Buchanan swapped the embed URL; the underlying forgery technique unchanged.
3. Tools released — keystork (client/server KeyStore impersonation over ADB) and a sign-any-image PoC gist targeting Pixel Camera.

Buchanan credits Dr. Neal Krawetz (Hacker Factor) for years of prior C2PA critique — including Pixel 10 forgery demonstrations and a 2026 formal analysis with UMBC showing validators agree on assertions but not always on trusted timestamps. Buchanan's contribution is the full Android root chain on the current AL2 product, with reproducible tooling.

The attack chain, step by step

Why bootloader unlock is not the only path

The "clean" root path — unlock bootloader, flash modified firmware, factory reset — does break attestation. Key Attestation reports an unlocked bootloader; Google refuses to provision C2PA keys (and Netflix drops HD, banking apps complain).

Exploit-based root is different. CVE-2026-43499 and similar LPEs leave the bootloader locked, AVB keys untouched, and the security patch level whatever it was at boot. Attestation has no reliable way to notice the compromise. Google's servers provision keys to a rooted device.

StrongBox protects keys, not intent

C2PA keys live in StrongBox (Titan M2 on newer Pixels). Root cannot extract raw key material. Root can ask StrongBox to sign arbitrary data — producing valid C2PA manifests for files that never touched the image sensor. Same KeyStore access that would decrypt a Signal inbox, Buchanan notes, if an attacker wanted worse outcomes than photo forgery.

The design assumption: patch LPEs quickly, require attestation reports above a minimum patch level, and compromised devices eventually age out. Buchanan's counter-evidence:

• CVE-2026-43499 — one-click root on fully patched Pixel devices at time of writing; Meta patched the same LPE on Quest headsets early August while Pixel flagships still had not.
• Private exploit stockpiles — governments and mobile forensics vendors are exactly the actors you least want forging C2PA.
• LLM-accelerated LPE discovery — root bugs shipping faster than patch cycles; Buchanan explicitly credits LLMs for speeding exploit research.

keystork: impersonate any app, sign anything

After root, Buchanan's keystork handles plumbing:

• keystorkd runs on the rooted device as a KeyStore proxy server.
• Client (Python library + CLI) speaks a wire protocol over a Unix domain socket forwarded via ADB.
• Client code performs arbitrary KeyStore operations while impersonating any installed app — e.g. Pixel Camera.

The PoC gist signs any image file as if Pixel Camera had captured it. In theory, Android apps could talk to keystork Shizuku-style; Buchanan notes you'd want an auth layer first.

Reproduction today: Root My Pixel — build from main for August 2026 patch support; Buchanan tested on Pixel 8a and 9a.

Hardware fault injection: the unpatchable branch

Before software LPEs stole the spotlight, Buchanan used DRAM bus fault injection (continuing earlier lighter research). Hardware glitches flip page-table entries to map kernel memory into userspace — root without unlocking the bootloader.

Samsung RKP (Real-time Kernel Protection) blocks one variant: an EL2 hypervisor prevents overwriting protected PTEs even if glitching maps them. Buchanan's PTE strategy still works on Pixel devices today; Samsung mitigations stopped his initial A07 exploit after an update (timing possibly coincidental). He plans alternate hardware strategies, including paths that work with memory encryption — a potential "universal Android hardware root" tool.

Intel MEE and Apple's SEP Memory Protection Engine treat external DRAM as untrusted, but running the full Android Linux kernel inside such protection is not performance-viable — which is why Apple uses MPE for SEP, not the main AP. Fixing C2PA on Android properly, Buchanan argues, would require rearchitecting the entire image pipeline including AI processing inside a secure enclave with strong memory protection. Google apparently agrees — that's the infeasible part.

What Hacker News got right (and where practitioners split)

The HN thread (~75 points, August 2026) clustered around honest tradeoffs, not cheerleading.

False promise harm. Commenters like mistercow argued marketing that equates C2PA signatures with "real photograph" probative value is actively harmful — photos become ≈ drawings in court and newsrooms if signed slop carries the same weight as signed captures.

Compliance, not forensics. trentor and others reframed C2PA as EU AI Act / agency insurance audit-trail infrastructure — useful for demonstrating disclosure processes, useless as standalone proof of physical reality. That aligns with explainx.ai's EU AI Act builder guide: Article 50 marks output, not truth.

Attestation vs exploit-rooted devices. uqers, demibabs, and thread regulars noted the gap between "hardware-backed keys exist" and "the device running the signing code is trustworthy" — Buchanan's entire paper in one sentence.

Analog hole. wisty and randomblock1 restated the classic attack: high-DPI monitor, dark room, tripod — or print-and-hold — turns any unsigned forgery into a signed camera capture. Sensor-level signing does not help if the sensor faithfully records attacker-controlled photons.

Apple SEP debate. tashian vs gyomu argued whether Secure Enclave integration would shift attacks to optics-only. Legend2440 linked rumored iOS 27 "Reference mode" with PCC authentication — vertical integration as advantage, analog hole as remaining floor.

Camera OEM question. jazzyjackson asked whether Sony, Leica, and Olympus content-credentials programs face the same class of break — any implementation chaining through general-purpose OS signing inherits the same root problem.

explainx.ai synthesizes: HN's compliance camp and Buchanan's break camp are both correct. C2PA is worth deploying for LinkedIn and X labeling, Claude file metadata, and regulatory workflows. It is not worth treating as a substitute for out-of-band verification or human corroboration.

Google's response: bounty without a fix

Google closed the report "Won't fix (infeasible)" — rearchitecting the stack cannot defeat screen photography. They still paid $7,500, with VRP text noting hardware glitching is out of scope but findings would inform future iterations.

Buchanan's read:

• The most obvious C2PA attack vector is out of scope for Android VRP — so the program does not protect C2PA implementations meaningfully.
• Hardware attacks are largely unpatchable on deployed silicon.
• A separate private key disclosure bug found while preparing the PoC was patched within ~two days — patches "ruin the fun" of hardware research, he notes dryly.

Most C2PA verification tools do not check certificate revocation, he adds — even after Google revoked the disclosed key.

What this means if you build with provenance

For product and compliance teams

For engineers choosing trust layers

1. Layer signals — C2PA manifest + invisible watermark + platform policy, as Anthropic ships for Claude and we explain in how AI watermarking works. No single layer survives a motivated attacker.
2. Verify conformant product lists skeptically — Assurance Level describes intended hardware backing, not resistance to root on the general-purpose OS calling KeyStore.
3. Design for the analog hole explicitly — EXIF lens data, scene consistency, and witness corroboration matter; Krawetz has long shown metadata omissions and partial signing in Pixel manifests.
4. Open vs closed trust models — Open-weight models remove provider marking; they do not remove your deployer obligations or the need for process-level provenance.

For educators and policy readers

The case for provenance marking still holds — transparency beats blanket bans. Buchanan's work narrows what provenance promises: not "trust this pixel array," but "this file passed through a labeled pipeline at signing time on a device that met attestation claims." That is weaker than marketing slides suggest and stronger than nothing for teaching people to spot fakes.

What's next: Apple, revocation, and verification UX

Apple has no shipping C2PA camera product yet. Rumored iOS 27 Reference mode would run signing closer to SEP — raising software attack cost, not eliminating optics attacks.

Near-term fixes that might actually ship: revocation checking in verifiers, stricter conformant-product allowlists, and honest UX copy that separates "signed by Pixel Camera app" from "depicts physical reality."

Buchanan teases more hardware-root research (Fire TV stick, Quest 3s) and a future write-up on the patched private-key disclosure. Journalists can request key material through his contact flow — he chose not to publish keys in the post.

Related on explainx.ai

• What Is C2PA? Content Credentials, Explained — baseline standard before this break
• Anthropic's Claude invisible watermarks and C2PA — layered provenance in practice
• LinkedIn and X flag AI images via C2PA — platform read of manifests
• Deepfake fraud: the $25.6M video call scam — why out-of-band verification beats tech seals
• What changes after EU AI Act enforcement — compliance vs forensic proof
• Why AI watermarks are good: the case for provenance — what marking is still for
• How to detect Claude's watermark and C2PA — verification tooling limits
• Open-weight vs closed models: how to choose — deployer-side obligations

Primary sources: David Buchanan — C2PA Cameras Do Not Survive Contact with Reality · Hacker News discussion (~75 pts) · Neal Krawetz — Google Pixel 10 and Massive C2PA Failures · Google — Pixel C2PA announcement

Attack details, CVE status, and Google's response reflect David Buchanan's publication and thread discussion as of August 26, 2026. Pixel patch availability and YouTube provenance UI may change.