Дэвид Бьюкенен (aka retr0.id), 25 августа 2026

Возможно, вы слышали, что C2PA — это технология, которая должна чудесным образом спасти всех от повального распространения AI-подделок за счёт того, что камеры криптографически подписывают снятые ими изображения. Ура криптографии!

К сожалению, это не сработает. Здесь много деталей, поэтому стоит сразу перейти к сути:

  • Приложения-камеры с C2PA на Android полагаются на Key Attestation и/или Google Play Integrity, чтобы не дать пользователям модифицировать приложение для подписи произвольных файлов (а не только данных с сенсора устройства).

  • Возможность подписывать произвольные файлы ломает модель доверия C2PA.

  • Эксплойты повышения привилегий до root ломают модель безопасности Key Attestation в Android, и Play Integrity — тоже.

  • Устройства Android можно получить root через недорогие атаки внедрения аппаратных сбоев.

  • Аппаратные уязвимости в уже выпущенных устройствах невозможно исправить патчем (об этом подробнее ниже).

  • Следовательно, C2PA на платформе Android сломан способом, который нельзя реально устранить патчем.

  • Ничего из перечисленного не является «0day» — обо всём было сообщено соответствующим сторонам минимум 90 дней назад (хотя любой внимательный человек мог предвидеть это заранее, как многие и предвидели).

Но это ещё не всё! Отчасти благодаря LLM, эксплойты повышения привилегий до root появляются быстрее, чем Google успевает выпускать патчи. На момент написания текста в открытом доступе существуют one-click root-эксплойты для полностью пропатченных устройств Google Pixel (через CVE-2026-43499). С их помощью любой человек может создавать поддельные C2PA-подписи без необходимости в аппаратных атаках. Далее в тексте приводятся инструкции, как это сделать.

Фокус сделан на Android — и вот почему, в объяснении самой Google:

Приложение Pixel Camera достигло уровня надёжности Assurance Level 2 — наивысшего рейтинга безопасности, определённого на данный момент программой соответствия C2PA. Assurance Level 2 для мобильного приложения сейчас возможен только на платформе Android.

Иными словами, атаке подверглась «сильнейшая» реализация — специально, чтобы показать масштаб проблемы. Вот AI-сгенерированное «мусорное» изображение, которое C2PA считает настоящей неотредактированной фотографией прямо из приложения Pixel Camera (наведите курсор, чтобы снять размытие, кликните, чтобы «проверить»):

А вот видео на YouTube, в описании которого указано, что оно «снято на камеру» (спойлер: это не так).

Правка, 2026-08-25T19:12:16Z: похоже, Google убрал раздел «Снято на камеру» из описания видео, предположительно вручную. Это мало что меняет — далее в тексте объясняется, как подписать собственные медиафайлы. Также была заменена ссылка на другую. Подделки будут продолжаться, пока не улучшится моральный дух.

Кстати, по слухам, Apple работает над собственным решением по подтверждению происхождения медиа, но пока оно не существует. Когда оно появится, отношение к нему можно будет высказать отдельно. Вертикальная интеграция Apple, вероятно, даст им значительное преимущество, что может сместить самые доступные векторы атак в оптическую область (фотографирование экранов и тому подобное).

Теперь подробнее.

Как эксплойт повышения привилегий до root ломает «аппаратно защищённую» аттестацию ключей?

Аттестация подтверждает лишь определённые вещи, включая:

  • Заблокирован ли загрузчик.
  • Принадлежат ли ключи AVB самому производителю.
  • Установлено ли на устройстве последнее обновление безопасности.

«Обычный» способ получить root на устройстве Android — разблокировать загрузчик и прошить модифицированный образ прошивки, что при этом принудительно сбрасывает устройство до заводских настроек. Аттестация зафиксирует разблокированный загрузчик, и Google откажется выдавать устройству ключи C2PA (а заодно Netflix не предоставит контент в высоком разрешении, банковское приложение не будет работать и так далее).

Пока всё логично (если вам вообще нравится такая логика).

Однако если получить root через эксплойт, у механизма аттестации нет надёжного способа это «заметить». Загрузчик по-прежнему заблокирован, ключи AVB не изменены, а устройство всё ещё работает на том обновлении безопасности, с которым загрузилось изначально. В результате серверы Google охотно выдадут ключи скомпрометированному устройству.

Ключи C2PA всё ещё защищены аппаратной безопасностью, внутри StrongBox (в чипе Titan M2 на новых устройствах Pixel). Это действительно не даёт злоумышленнику извлечь сам ключевой материал даже при наличии root. Однако для атаки не требуется сырой ключевой материал! Получив root, злоумышленник может попросить StrongBox подписать этими ключами любые данные по своему выбору и создать поддельную C2PA-подпись (или, среди прочего, расшифровать входящие сообщения Signal).

Теория, лежащая в основе механизма аттестации, состоит в том, что известные программные уязвимости повышения привилегий должны патчиться, а сторона, проверяющая аттестацию (relying party), может требовать от пользователей установки обновлений — после чего обновлённое устройство больше нельзя эксплуатировать через эту уязвимость.

CVE-2026-43499 доказывает, что своевременные патчи доступны не всегда, но даже если предположить (в качестве уступки), что публичных эксплойтов для непропатченных багов никогда не существует, остаются две проблемы:

  1. Любая достаточно обеспеченная организация — от правительств до компаний мобильной криминалистики — может собрать запас приватных эксплойтов (и они это делают). Это как раз те группы, от которых меньше всего хотелось бы получать поддельные C2PA-подписи.

  2. Существуют недорогие аппаратные эксплойты, независимо от уровня патчей.

Как были подписаны демонстрационное изображение и видео?

Изначально использовалась аппаратная атака — продолжение более раннего исследования: Can You Get Root With Only a Cigarette Lighter?

Планировалось описать её подробно здесь, но, честно говоря, чисто программные эксплойты для разных путей перетянули внимание на себя. Программные эксплойты гораздо удобнее, когда они существуют, поэтому подробности об аппаратной атаке — тема для другого раза. Спешить некуда: аппаратные эксплойты по большей части патчами не устраняются.

Для тех, кто хочет воспроизвести результаты сегодня, рекомендуется инструмент Root My Pixel (примечание: хотя он поддерживает августовские обновления безопасности для большинства устройств Pixel, для этого нужно собрать его из ветки main. Лично протестировано на Pixel 8a и 9a.)

После получения root остальная часть атаки — это уже «сантехника». Для упрощения этого процесса был создан инструмент keystork. У keystork клиент-серверная архитектура: клиентский код может выполнять произвольные операции с KeyStore API, имитируя любое установленное приложение. «Сервер» (keystorkd) работает на устройстве с root, а клиентом может быть что угодно, способное общаться по придуманному протоколу (по умолчанию — через unix domain socket, проброшенный по ADB). Референсный клиент написан на Python с соответствующим CLI-интерфейсом, но в теории с сервером могли бы общаться и Android-приложения, в стиле Shizuku (хотя для этого сначала стоило бы построить слой авторизации и разрешений).

Вот PoC-скрипт «подписать любое изображение» для приложения Pixel Camera: https://gist.github.com/DavidBuchanan314/fa0ffdaaaa31594e6a511118c1cea1e0

Программные эксплойты рано или поздно будут пропатчены, а вот аппаратные — навсегда. Или всё же нет?

Можно ли смягчить аппаратные атаки?

В теории — да, на практике — почти нет.

Изначальная стратегия (переключение битов в PTE) до сих пор работает на устройствах Pixel. Однако на устройствах Samsung она не работает!

Часть первоначальных тестов проводилась на Samsung A07 (потому что они дешёвые). Эксплойт на тот момент срабатывал, но после обновления безопасности перестал работать (совпадение по времени, скорее всего, случайное). Обновление включило механизм защиты Samsung «RKP» (Real-time Kernel Protection, не путать с Remote Key Provisioning...)

Среди прочего, защитные механизмы Samsung используют гипервизор уровня EL2 для дополнительной защиты определённых областей памяти (что-то вроде HVCI от Microsoft). Аппаратный эксплойт по-прежнему позволяет переключать биты в PTE, но даже если через сбой отобразить PTE в пользовательское пространство, EL2 не позволяет перезаписать его — а это была ключевая часть исходного дизайна эксплойта.

Есть несколько идей альтернативных стратегий обхода защиты Samsung, но пока руки до их реализации не дошли. Одна из альтернативных стратегий должна работать даже при наличии аппаратного шифрования памяти. После её реализации планируется упаковать всё это в инструмент «универсальный аппаратный root для Android» — стоит следить за обновлениями. (Также хотелось бы обойти HVCI, чтобы вмешаться в работу анти-читов — за этим тоже стоит понаблюдать.)

На аппаратном уровне существует несколько решений, которые считают внешнюю DRAM полностью недоверенной, тем самым смягчая любые атаки через сбои на шине — по крайней мере в теории. Примеры включают Intel MEE и Memory Protection Engine из Apple SEP. Однако эти решения недостаточно производительны, чтобы реально запускать внутри них весь линуксовый ядро Android (поэтому Apple использует такую защиту только для SEP, а не для основного процессора, а Intel вовсе убрала эту функцию из новых версий SGX, что привело к атакам вроде Battering RAM).

Даже с лучшими аппаратными средствами защиты, исправление C2PA на Android потребует полной перестройки программного стека. Весь конвейер обработки изображений, включая всю продвинутую AI-составляющую, должен будет работать внутри защищённого анклава с сильной аппаратной защитой памяти.

Едва ли Google пойдёт на такую перестройку — вероятно, именно поэтому отчёт был закрыт со статусом «Won't fix (infeasible)». Действительно, не имеет большого смысла проводить такую масштабную работу, если всё равно нельзя остановить атаки в духе «фотография экрана».

Кстати, несмотря на статус WONTFIX, Google всё же выплатил вознаграждение в размере $7500 за отчёт:

Спасибо за отправленный отчёт. Хотя аппаратные атаки методом сбоев и атаки по побочным каналам не входят в область действия нашей программы bug bounty, наша команда безопасности сочла ваши находки ценными, и предоставленные данные помогут нам улучшить будущие версии продукта.

Выплата стала приятной неожиданностью (было заранее известно, что формально она вне области действия программы). Этого хватит, чтобы покрыть все устройства, «убитые» в процессе исследования. Но стоит отметить главное:

Наиболее очевидный вектор атаки на C2PA не входит в область действия программы вознаграждений Google (VRP). Таким образом, VRP не обеспечивает сколько-нибудь значимой защиты реализаций C2PA на Android.

Насколько широко распространена проблема?

Основное внимание уделялось приложению Pixel Camera, но на Android существует ещё несколько «C2PA-камер». Все исследованные приложения полагаются либо на Key Attestation, либо на Play Integrity в качестве основы своей защиты. Они все сломаны одинаковым образом, с той разницей, что не привязаны исключительно к устройствам Google Pixel. Это означает, что для атаки не обязательно получать root на Pixel — можно выбрать самое дешёвое и уязвимое устройство во всей экосистеме Android.

Все они стали жертвами вводящих в заблуждение маркетинговых заявлений Google об эффективности безопасности их платформы. Полный список «соответствующих» реализаций C2PA можно найти здесь (все, у кого в списке attestationMethods указаны Android_KeyAttestation или Google_PlayIntegrity, вероятно, уязвимы).

Помимо C2PA, стратегия аппаратных сбоев была с успехом опробована на самых разных устройствах Android, включая Amazon Fire TV Stick и VR-гарнитуру Meta Quest 3s (об этом тоже, вероятно, будет отдельный текст позже!)

Кстати, Meta уже пропатчила уязвимость CVE-2026-43499 на гарнитурах Quest — в начале месяца, чтобы предотвратить читерство в VR-играх. Удивительно, что Google до сих пор не выпустила патч даже для своих флагманских устройств Pixel.

Благодарности

Хотя интерес к экосистеме C2PA возник относительно недавно, доктор Нил Кравец (Neal Krawetz) из Hacker Factor уже много лет бьёт тревогу на эту тему. Его материалы стали отправной точкой для знакомства с проблемой, и он оказал большую помощь в обсуждении деталей, а также в координации раскрытия уязвимостей.

Его взгляд на эти уязвимости можно прочитать здесь.

Отдельная благодарность Provenance and Authenticity Standards Assessment Working Group (PASAWG), которая также исследует эффективность C2PA.

И ещё кое-что...

При подготовке PoC к публикации возникла шальная мысль «а что, если?». Она привела к обнаружению уязвимости, связанной с раскрытием приватного ключа. Отчёт был отправлен в Google два дня назад, и, судя по всему, вчера уязвимость уже пропатчили (именно поэтому аппаратные атаки предпочтительнее — патчи портят всё веселье). Подробности, вероятно, появятся позже отдельным материалом.

Здесь можно было бы вставить приватный ключ C2PA приложения Pixel Camera и соответствующую цепочку сертификатов — если бы не осторожность. Было решено этого не делать. Журналистам, которым интересно взглянуть, стоит связаться напрямую.

Есть основания полагать, что Google уже отозвал этот конкретный ключ (он был включён в отчёт). Однако большинство инструментов верификации C2PA не проверяют отзыв ключей. Возможно, это тоже скоро исправят.