Почему переподписанные APK-файлы всё ещё устанавливаются и где кроются риски

Различайте проверку установки, идентичность подписи и бизнес-авторизацию

Android требует подписи APK. Система проверяет, подтверждают ли структура пакета установщика и данные подписи, что текущее содержимое было подписано соответствующим закрытым ключом. Если злоумышленник модифицирует DEX-файлы, ресурсы или Manifest, а затем полностью переподписывает результат своим ключом, новый пакет становится криптографически самосогласованным и может удовлетворять условиям для чистой установки.

Этот результат отвечает лишь на вопрос, имеет ли текущий пакет проверяемую подпись; он не отвечает на вопрос, является ли подписант официальным издателем. Авторизация бренда, легитимные каналы распространения, права входа в учётную запись и доступ к интерфейсам повышенного риска - это бизнес-задачи, которые приложение и сервер должны оценивать отдельно.

Следовательно, отчёты о тестировании не должны приравнивать «возможность установки после переподписи» к «сбою защиты подписи», а «неудачу установки» - к «полному устранению рисков переупаковки». Правильные вопросы таковы: Может ли модифицированный пакет попасть на устройства пользователей? Может ли он выдать себя за официальную версию при обновлении? Может ли он подключиться к реальным сервисам? И как сервер идентифицирует и обрабатывает такие случаи?

Почему переподписанные пакеты часто допускают только чистую установку

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

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

Ротация подписей и Play App Signing усложняют цепочку выпуска. Команды должны сохранять текущие и исторически допустимые идентификаторы сертификатов, правила ротации, а также разграничивать ответственность ключей загрузки и ключей подписи приложений. Серверные политики должны использовать данные, соответствующие методу дистрибуции. Сертификаты разработки, загрузки и финальной дистрибуции никогда не должны смешиваться в одном поле.

• Выполнить обновление поверх текущей рабочей версии
• Выполнить чистую установку после удаления
• Проверить изменения имени пакета и влияние на каталог данных
• Верифицировать ротацию сертификатов согласно правилам платформы дистрибуции

Управление переупаковкой должно начинаться с идентификации финального артефакта

Команды часто сохраняют только номер сборки, игнорируя запись дайджеста файла финального APK и дайджеста подписывающего сертификата. Инъекция ресурсов канала, выравнивание, переподпись или оптимизация пакета могут изменить финальный файл. Если сканирование безопасности анализирует артефакты до канальной обработки, файлы, получаемые конечными пользователями, не покрываются теми же доказательствами.

Рекомендуем генерировать однозначные записи артефактов для каждого кандидата на выпуск: имя пакета, versionCode, versionName, SHA-256 файла, SHA-256 сертификата, результат верификации схемы подписи, источник сборки, канал, порядок обработки и временную метку генерации. Статические проверки, установка обновлений, функциональное регрессионное тестирование и серверные правила допуска должны ссылаться на эту запись.

Дайджесты файлов сами по себе не являются мерами защиты; их ценность заключается в предотвращении незаметного изменения тестируемого объекта в ходе рабочего процесса. Любое изменение дайджеста, подписи или последовательности каналов указывает на новый кандидат на выпуск, требующий повторного выполнения затронутых контрольных точек.

artifact:
  package: com.example.redacted
  version_code: 240
  version_name: 2.4.0
  sha256: REDACTED
signing:
  certificate_sha256: REDACTED
  schemes: [v2, v3]
  distribution: managed-channel
pipeline:
  - build-release
  - harden-candidate
  - channel-resources
  - final-sign
acceptance:
  install_fresh: required
  upgrade_from_production: required
  server_policy_check: required

Серверы должны рассматривать аномальных клиентов как проблему политик безопасности

Клиенты могут передавать имена пакетов, версии, сертификаты или материалы целостности, однако модифицированные клиенты способны подделывать эти стандартные поля отчётности. Серверы должны отдавать приоритет верифицируемым сигналам, объединяя статус учётной записи, версию, поведение запросов, риски устройства и среду дистрибуции в единую политику, вместо того чтобы доверять одиночному булевому значению от клиента.

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

Сценарии дистрибуции вне Google Play не могут просто копировать сигналы, эксклюзивные для Play. Корпоративная дистрибуция, внутренние каналы и частная доставка требуют создания собственных списков разрешённых версий, сопоставлений сертификатов, механизмов обновлений и процедур обработки аномалий. Сигналы платформы являются частью доказательной базы, а не универсальным решением для всех каналов.

Некорректная последовательность релиза аннулирует предыдущие проверки

Изменение DEX, ресурсов или манифеста после финальной подписи нарушает целостность данных, покрытых подписью; пересборка или повторная подпись после сканирования разрывает связь между выводами сканера и итоговым файлом. Если инструменты обработки каналов требуют модификации тела пакета, это должно быть выполнено до финальной подписи, а последовательность зафиксирована в реестре артефактов.

Распространение через AAB дополнительно разделяет загруженные артефакты и сплит-APK, получаемые устройствами пользователей. Командам следует загружать или получать фактически доставленные артефакты с платформы распространения для выборочных проверок, подтверждая соответствие имен пакетов, версий, идентичности подписей и ключевых ресурсов записям релиза. Локально сгенерированные универсальные APK не могут автоматически представлять все конфигурации устройств.

Пакеты отката также должны проходить ту же проверку подписи и валидацию обновления. В случае инцидента временная повторная подпись старого файла может привести к сбою установки поверх существующей версии из-за несоответствия номеров версий, подписей или требований миграции данных.

Как определить, что риск переупаковки находится под контролируемым управлением публикации

Публикуемый вывод не означает, что модифицированные пакеты никогда не смогут установиться. Это означает, что идентичность официального артефакта поддаётся аудиту, аномальные артефакты не могут silently перезаписать официальные версии, сервер способен идентифицировать или ограничивать недоверенных клиентов, у пользователей есть пути получения подлинных версий и восстановления, а команды могут проводить аудит файлов финальной доставки.

Тесты должны сохранять доказательства как для успешных сценариев, так и для путей сбоя. Успешные сценарии включают нормальную установку и обновление официальных версий, вход в систему и ключевые бизнес-процессы. Сценарии аномалий включают обновление поверх версий с нерелевантными сертификатами, доступ неизвестных версий к высоко рискованным интерфейсам, работу с истекшими версиями, отсутствие сигналов целостности и восстановление после ложных срабатываний. Проверка только отказа без процесса восстановления загоняет реальных пользователей в неразрешимое состояние.

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

• Идентичность официального артефакта может быть независимо проверена
• Аномальные сертификаты не могут silently перезаписать официальные установки
• Сервер имеет градуированные политики для неизвестных клиентов
• Пользователи могут вернуться к доверенным каналам релиза
• Пакеты отката прошли предварительную проверку обновления