GuardDo Pixel — это кастомная защищённая ОС для телефонов Pixel в лучших инженерных традициях безопасного софта: опенсорсная, защищённая ото всех, начиная с самих разработчиков, ориентированная на защиту пользователя, а не «национальной безопасности».

Из текущей линейки разработок для защиты и уничтожения данных GuardDo, GuardDo Pixel — самая актуального для индивидуального использования — частного или профессионального. Телефон всегда в кармане, всегда включён, первым попадает в руки при досмотре, при задержании, при «простой проверке документов», на границе итд. И именно в этом контексте проявляется преимущество специализации, в отличие от других защищённых решений как GrapheneOS, начиная с полной невидимой невидимости защищённого пространства: из белого нельзя обнаружить серое — ни через интерфейс, ни через системные системные запросы. А для остальных сценариев — есть запатентованные функции моментального и безвозвратного стирания устройства.

После статьи про «GuardDo Pixel против GrapheneOS» в комментариях на Хабре появились вопросы, которые звучали примерно так:

Что-то в статье много воды, а по факту 0. Какие у системы механики безопасности кроме panic button и защиты от прослушки?

— прочитав которые, разработчики GuardDo Pixel не выдержали, и попросили написать про их разработку ещё раз. Если первая статья была про философию GuardDo Pixel против GrapheneOS, то эта — про то, как оно работает внутри.

В первую очередь, стоит сказать, что у GuardDo есть открытый репозиторий — git.guarddo.net/opensource. Код открыт — можно смотреть, проверять, аудировать. И даже сборки обновлений полностью открыты в реальном времени — jenkins.guarddo.net (такого нет нигде, даже в grapheneOS). Поэтому разговор сегодня — технический и предметный.

Phones in both BFU and AFU states are safe from Cellebrite on updated builds, and as of late 2024, even a fully unlocked GrapheneOS device is immune from having its data copied.

Ссылка на статью Ars Technica от октября 2025 года. Хорошая статья, но там речь про конкретный сценарий: BFU (Before First Unlock) и AFU (After First Unlock) на обновлённых билдах. Да, GrapheneOS стал лучше с тех пор, как я писал про утёкшую таблицу Cellebrite 7.68.6 февраля 2024 года.

Но проблема, которую я описывал — видимость второго пространства — это не проблема Cellebrite. Это проблема момента, когда телефон уже разблокирован и в чужих руках. Cellebrite здесь вообще ни при чём: достаточно потянуть шторку и открыть меню переключения профилей. GrapheneOS это не скрывает — по дизайну. Это не баг, это особенность архитектуры. И именно её GuardDo решает иначе.

Часть первая: скрытые пространства — как это реализовано

Когда в прошлой статье я писал про «двойное пространство через пароль, не через меню» — это звучало как маркетинг. Объясняю, что за этим стоит технически.

Автопереключение с Keyguard

В стандартном Android смена пользователя — это: открыть настройки → выбрать профиль → ввести пароль от нужного профиля. Три шага, каждый из которых визуально демонстрирует, что профилей несколько.

В GuardDo Pixel это работает иначе. При вводе пароля на экране блокировки система верифицирует синтетический пароль через стандартный механизм Keyguard, но добавляет один шаг: проверяет, не принадлежит ли этот пароль другому скрытому пространству. Если принадлежит — запускается скрытый процесс переключения:

Текущий профиль помечается разблокированным, чтобы экран блокировки исчез без попытки запустить лаунчер текущего пользователя.
Keyguard уведомляется о предстоящем переходе — это блокирует повторный запрос пароля.
Выполняется переключение пользователя через кэшированную аутентификацию — без визуальных артефактов и дополнительных шагов.

Для человека, держащего телефон: он ввёл пароль и попал в нужное пространство. Никаких меню, никакого намёка на то, что пространств несколько.

В GrapheneOS — и в стандартном AOSP — такого механизма нет. Переключение там всегда явное и заметное.

Маскировка белого пространства и полная изоляция

Одно из пространств (белое) выглядит как совершенно обычный сток Android. За это отвечает модуль внутри лаунчера, который для заданного списка пакетов подменяет иконки и названия на стоковые ресурсы через системный набор иконок и строк. Данные кэшируются для быстродействия.

Дополнительно: в белом пространстве полностью отсутствуют все нестандартные элементы интерфейса — QS-тайлы «Уничтожение» и «Паника», любые настройки, которых нет в AOSP. Переключатели многопользовательского режима скрыты. Обои — стандартные.

С точки зрения форензики, белое пространство никак не сигнализирует о наличии защищённого. В GrapheneOS — сигнализирует всем, кто знает, как выглядит GrapheneOS. А знают все, кому нужно знать.

Полная изоляция: пространства не видят друг друга никак — ни через интерфейс, ни через системные запросы. Из белого нельзя обнаружить серое. Каждое работает как отдельное устройство.

Часть вторая: функция уничтожения — три независимых барьера

В прошлой статье я описал сценарии уничтожения. Сегодня — что происходит внутри при нажатии тайла.

Вызов WipeData с флагом destroy_device = true. Это не заводской сброс. Разница критическая.

Барьер первый: криптографическое стирание ключей

На Android 11+ метаданные файловой системы шифруются через dm-default-key, а ключ для этого слоя хранится в разделе /metadata в виде KeyMint-блоба. Titan M2 защищает этот ключ на аппаратном уровне и участвует в derivation-цепочке.

Это форматирует /metadata и безвозвратно уничтожает KeyMint-блобы. Блоки данных на /data физически остаются — но без ключей это криптографический шум. Cryptographic erase — стандартный метод из NIST SP 800-88.

Барьер второй: снятие блокировки записи и физическая очистка

Системные разделы по умолчанию смонтированы только для чтения — и на уровне ФС, и на уровне блочного устройства. Перед переформатированием блокировка снимается принудительно.

После этого форматирование делегируется make_ext4fs или mkfs.f2fs, которые при создании новой ФС отправляют накопителю команду BLKSECDISCARD — secure discard, физическое затирание ячеек.

Барьер третий: AVB и заблокированный загрузчик

ОС подписана собственными приватными ключами AVB GuardDo. Загрузчик заблокирован, а возможность его разблокировки программно отключена.

Это означает: даже если кто-то разберёт телефон и попытается залить сторонний образ через fastboot — верификация AVB провалится. Зарегистрировать кастомный ключ можно только при разблокированном загрузчике. Разблокировать загрузчик нельзя. Titan M2 не выдаст ключи шифрования. На накопителе — шум.

Триггеры уничтожения

Все хранятся в Settings.Secure и недоступны без системных привилегий:

Специальный пароль — отдельный PIN на экране блокировки, ввод которого немедленно вызывает initiateDeviceSelfDestruct()
5 неверных попыток — флаг ERASE_ERROR_PIN_LAYOUT, после пятой ошибки уничтожение, а не просто задержка
Отпечаток пальца — флаг ERASE_ON_FINGERPRINT; полезен при принуждении, когда заставляют приложить палец
Авиарежим — переход в режим полёта может быть настроен как триггер
QS-тайл — прямое нажатие в шторке
Удалённый сигнал — SMS или звонок с заданного номера (доп. Опция)
Таймер неактивности — автоуничтожение, если телефон не использовался заданное время

Часть третья: функция «Паника» — мягкое обнуление

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

По долгому нажатию тайла запускается panicPressed(). Последовательность:

Перебираются все установленные пакеты через getInstalledPackages(0). Системные приложения определяются по флагу FLAG_SYSTEM и не трогаются. Остальные удаляются через deletePackageAsUser() с флагом DELETE_ALL_USERS — удаление для всех профилей, а не только текущего.
packageManager.deletePackageAsUser(
packageInfo.packageName,
observer,
PackageManager.DELETE_ALL_USERS,
UserHandle.USER_SYSTEM,
)
Браузеры обрабатываются отдельно через clearApplicationUserData() — история, куки, кэш, сохранённые пароли.
Очистка для каждого профиля через UserManager.aliveUsers. Внешнее хранилище — по путям /storage/emulated/{userId}. Удаляются: DCIM, Pictures, Movies, Music, Downloads, Documents, папки мессенджеров — WhatsApp, Telegram, Signal, Recordings, ScreenRecorder.
Внутренние данные — по /data/user/{userId} для каждого профиля. Рекурсивно: cache, code_cache, files, databases, shared_prefs.
Сброс индексов MediaStore. Вызывается resolver.delete() для всех четырёх URI: Images, Video, Audio, Downloads. Без этого галерея продолжала бы «видеть» удалённые файлы.

В результате, устройство включается, работает, выглядит чисто — но всех пользовательских данных нет.

Часть четвёртая: App Lock — системный сервис, которого нет в GrapheneOS

И GrapheneOS, и GuardDo реализуют многопользовательские профили и private spaces. Однако GuardDo добавляет к этому App Lock — глубоко интегрированный системный сервис в system_server, отсутствующий в AOSP. GrapheneOS для изоляции чувствительных приложений опирается прежде всего на отдельные профили, тогда как GuardDo даёт возможность точечно блокировать конкретные приложения прямо внутри одного пространства — с перехватом запуска, автоматической релокировкой и скрытием из лаунчера.

Перехват запуска приложений реализован через ActivityInterceptorCallback — каждая попытка открыть защищённое приложение перехватывается на системном уровне, до того как приложение успевает запуститься. Показывается экран аутентификации с IntentSender для возобновления после верификации.

Автоматическая релокировка работает через TaskStackListener. Как только защищённое приложение покидает передний план — запускается таймер. Два режима: по таймауту (минимум 5 мс) или мгновенно при выключении экрана.

Скрытие приложений из лаунчера: сервис ведёт список скрытых пакетов через getHiddenPackages. Приложения остаются установленными, но в интерфейсе их нет.

Пароль App Lock хэшируется через scrypt (N=2048, r=8, p=1) с 16-байтовой случайной солью. Прогрессивная задержка: 5 попыток → 30 сек, 10 → 1 мин, 15 → 5 мин.

Защита уведомлений: для заблокированных приложений содержимое уведомлений подавляется — виден только заголовок.

Конфигурация хранится в /data/system_de и требует системного разрешения MANAGE_APP_LOCK. Обычные приложения не могут получить доступ к конфигурационным файлам.

Часть пятая: блокировка QS и меню питания на локскрине

На заблокированном экране физический свайп для вызова панели быстрых настроек игнорируется полностью. Глобальное меню питания не вызывается. За это отвечает специализированный контроллер в SystemUI, который отслеживает состояние экрана через ScrimEventListener.

Если keyguardShowing или dozing — любая попытка открыть шторку не вызывает никакой реакции. Параллельно в showGlobalActionsInternal() при isKeyguardLocked() && isKeyguardSecure() диалог меню питания не отображается.

Почему это важно: Cellebrite и аналогичные инструменты используют разные векторы, в том числе через физические кнопки и быстрые настройки на локскрине. Здесь эта поверхность атаки закрыта.

Часть шестая: стабильность — то, о чём не говорят в маркетинге

Ещё один типичный вопрос из комментариев к кастомным прошивкам: «а оно вообще нормально работает?»

Подход GuardDo к базе — гибридный. Google ежедневно вносит правки в Android, часть из них интегрируется точечно. Если посмотреть на реальные коммиты — это сухой список того, что было сломано и исправлено:

Состояние гонки в уведомлениях (исправлено)
NPE в TextToSpeechManagerPerUserService (исправлено)
Краш QSAnimator (исправлено)
NPE в SettingsLib для фрагментов без разделителя (исправлено)
Краш при смене конфигурации через ConcurrentModificationException в SystemUI (исправлено)
Краш вторичного пользователя при заблокированном системном пользователе (исправлено)
NPE в ArtFastDataOutput.writeUTF() (исправлено)
Утечка памяти в car service — исправлено
Краш FlashlightControllerImpl при пустом списке ID камер — исправлено
Мерцание экрана при запуске горизонтальных приложений из вертикальных — исправлено
ConcurrentModificationException в LocaleStore — исправлено

И это — только небольшая часть. Плюс отключено отладочное логирование в десятках системных компонентов: SplashScreen, лаунчер, телефония, медиаплеер. Эти «невидимые» процессы незаметно нагружали процессор и расходовали батарею в любой кастомной прошивке, которая просто не занималась этим.

А что GrapheneOS?

GrapheneOS тоже не стоит на месте и переносит часть апстрим-патчей из AOSP. Но здесь важно понимать приоритеты: GrapheneOS сфокусирован на hardening — усилении ядра, изоляции процессов, sandboxed Google Play. Это их сильная сторона, и они делают это хорошо. Однако точечная работа по стабильности — перенос апстрим-фиксов в том объёме и с той скоростью, как это делает GuardDo — не является приоритетом GrapheneOS. Большинство патчей из списка выше — это апстрим-фиксы, которые Google вносит в основную ветку Android, но которые в кастомные прошивки не попадают автоматически: их нужно находить, оценивать и переносить вручную. GuardDo это делает системно.

Что касается отладочного логирования — GrapheneOS этим не занимается в сопоставимом объёме. Отключение debug-логов в десятках компонентов — SplashScreen, лаунчер, телефония, медиаплеер — это тихая работа, которая не попадает в анонсы, но ощутимо влияет на плавность и время работы от батареи.

Напомню: всё это — примерно 1% от реального объёма работы над прошивкой. И уже на этом 1% хорошо видно, чем системная разработка отличается от «взял AOSP, накрутил фичи».

7. Собственные серверы для мессенджеров

Отдельный момент, который не попал в прошлую статью. В GuardDo Pixel есть поддержка настройки собственных серверов для p2p-мессенджеров. Это означает: вы поднимаете свою инфраструктуру, прошивка умеет с ней работать. Никаких централизованных серверов третьих сторон в критически важных коммуникациях — если вы этого хотите. Для корпоративного сегмента, family-офисов это не опция, это требование.

Сравнение с другими кастомными ОС всё ещё актуально?

Оба проекта заслуживают уважения. GrapheneOS — технически сильная система с открытым кодом, hardened kernel, sandboxed Google Play. CalyxOS — удобнее для обычного пользователя, с microG вместо Google Play. Оба решают проблему слежки со стороны Google.

Но ни один из них не решает задачу, которую решает GuardDo Pixel: что происходит, когда телефон уже не в ваших руках.

GrapheneOS в этом сценарии даёт вам хорошо закрытую дверь с видимой вывеской «здесь что-то спрятано». CalyxOS — примерно то же самое, просто вывеска чуть более заметная. GuardDo строит другое: дверь, которую не видно, плюс кнопку, которая уничтожает всё за ней за секунды, плюс второй вход, который выглядит как обычная квартира.

Это разные задачи. GrapheneOS и CalyxOS отвечают на вопрос «как сделать Android приватным». GuardDo Pixel отвечает на вопрос «как сделать так, чтобы данные принадлежали только вам в любой момент времени — включая момент, когда телефон изымают». Таким образом, по совокупности защитных механик, ориентированных на сценарий изъятия разблокированного устройства, GuardDo предлагает уникальный набор инструментов, отсутствующий в GrapheneOS и CalyxOS.

Самое трудное в статье — как её закончить

Код открыт: git.guarddo.net/opensource. Сборки прозрачные — вы всегда можете видеть что собираться у вас в прошивке jenkins.guarddo.net Аудит возможен. Вопросы про «джентльменам верят на слово» — туда.

Архитектура, которую я описал выше, не существует ни в AOSP, ни в GrapheneOS, ни в CalyxOS.

GrapheneOS остаётся крепким стандартом противостояния Google и сетевой слежке. Но анонимных ОС — GuardDo Pixel на текущий момент на вершине: они предлагают инструменты, которых нет больше нигде, к тому же они улучшают детали, с которыми ни одна другая кастомная ОС не работает.

Если остаются технические вопросы — разработчики читают комментарии.

GuardDo Pixel: обзор телефона с секретом