Контрольные суммы APK и IPA (MD5, SHA-1, SHA-256): зачем их запрашивают и как получить

При сдаче мобильного приложения на экспертизу по кибербезопасности вместе с APK или IPA запрашивают и его контрольные суммы — MD5, SHA-1 и SHA-256. Команда, впервые столкнувшаяся с этим требованием, часто спрашивает: «где их взять?». На деле это работа на одну минуту. Но есть одно тонкое правило, и его нарушение приводит к лишней переписке и потере времени.

Что такое контрольная сумма

Контрольная сумма (hash, checksum) — короткий «отпечаток», вычисленный из содержимого файла. Один и тот же файл всегда даёт одно и то же значение. Если в файле изменится хотя бы один байт, значение станет совсем другим.

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

• Какой именно файл проверялся? Находки в отчёте относятся к конкретной сборке. Хеш однозначно её определяет.
• Не изменился ли файл по пути? Можно проверить, что при загрузке или передаче файл не повредили и не подменили.
• Совпадает ли проверенный файл с распространяемым? Это основа для последующего сравнения.

MD5 и SHA-1 сегодня считаются криптографически слабыми — для них известны атаки на коллизии. Поэтому основное надёжное значение — SHA-256. MD5 и SHA-1 обычно запрашивают как дополнительные идентификаторы для совместимости и удобства.

Как получить

Linux

md5sum app-release.apk
sha1sum app-release.apk
sha256sum app-release.apk

macOS

md5 app-release.ipa
shasum -a 1 app-release.ipa
shasum -a 256 app-release.ipa

Windows (PowerShell)

Get-FileHash .\app-release.apk -Algorithm MD5
Get-FileHash .\app-release.apk -Algorithm SHA1
Get-FileHash .\app-release.apk -Algorithm SHA256

Если PowerShell нет, в обычной командной строке работает certutil:

certutil -hashfile app-release.apk SHA256

Удобно записать результаты в один текстовый файл и сдать вместе с именем файла, номером версии и датой сборки. Например: app-release.apk, версия 2.3.1 (build 45), SHA-256: ....

Главное правило: именно сдаваемый файл

Контрольная сумма верна только для того самого файла. Поэтому:

1. Сначала соберите финальный файл, затем снимите хеш, затем сдайте именно этот файл.
2. Не пересобирайте после снятия хеша. Даже сборка из того же кода с теми же настройками часто даёт другой хеш: отличаются метки времени сборки, подпись и другие факторы.
3. Не переподписывайте файл и не меняйте его, распаковывая и запаковывая заново. Изменится подпись — изменится и хеш.
4. Если файлов несколько — хеш для каждого. APK и IPA или отдельные APK для разных архитектур — у каждого своё значение.
5. Если кладёте файл в zip, уточните, для чего экспертиза ждёт хеш: для самого архива или для APK/IPA внутри.

Если в ходе экспертизы вы вносите исправления и сдаёте новую сборку, снимите хеши и для нового файла. Отправка старых значений с новым файлом — частая ошибка.

Как сверить значение

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

sha256sum app-release.apk > app-release.apk.sha256
sha256sum -c app-release.apk.sha256

Если выводится app-release.apk: OK, файл не изменился. В PowerShell достаточно простого сравнения: (Get-FileHash .\app-release.apk).Hash -eq "ОЖИДАЕМОЕ_ЗНАЧЕНИЕ" должно вернуть True. Если сверяете глазами, смотрите на всю строку, а не только на начало и конец.

Файл в магазине может отличаться

Это часто вызывает вопросы, поэтому лучше знать заранее:

• Google Play. При использовании Play App Signing вы загружаете AAB, а Google сам собирает из него APK и подписывает своим ключом. APK, который получает пользователь, имеет другой хеш, чем сданный вами файл.
• App Store. Apple дополнительно обрабатывает и шифрует приложение в магазине, поэтому скачанное из магазина приложение тоже не даёт тот же хеш, что ваш IPA.

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

Порядок подготовки файла

При сдаче нашего собственного продукта мы придерживались такого порядка и рекомендуем его клиентам:

1. Собирается финальная сборка со всеми исправлениями и включёнными release-настройками (обфускация, R8, RASP).
2. Файл устанавливается на тестовое устройство, кратко проверяются основные сценарии и защитные меры (root/jailbreak, tamper).
3. Только после этого снимаются MD5, SHA-1, SHA-256.
4. Файл, хеши, версия и номер сборки сдаются одним пакетом.
5. Копия файла и хеши сохраняются и у вас — для последующих вопросов и повторной проверки.

Этот простой порядок предотвращает ситуации вроде «мы проверяли другой файл» или «значения не совпадают».

Сканирование

Хотите подготовить приложение перед сдачей на экспертизу? Оставьте заявку на сканирование. ИИ-агент Claude и наш специалист проверят ваш APK или IPA и покажут, что нужно закрыть до сдачи.