Подделка подписи Android-приложения и её проверка
2026-03-10 02:56 Diff

Теги: android, signature, андроид, подпись, ndk, native

Несколько лет назад обнаружил, что в интернете появляются свежие версии моих, слегка изменённых (была убрана монетизация), apk буквально спустя пару часов после публикации версии. Был очень заинтересован этим, т. к. в моём приложении были проверки подписи в разных местах, что-то вроде:

PackageInfo info = null; try { info = getPackageManager() .getPackageInfo(getPackageName(), PackageManager.GET_SIGNATURES); } catch (PackageManager.NameNotFoundException e) { e.printStackTrace(); } if (null != info && info.signatures.length > 0) { byte[] rawCertJava = info.signatures[0].toByteArray(); }

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

В гугле обнаружил исходники инструмента, который вносил все эти изменения автоматически.

Этот инструмент может быть использован пользователями, обладающими минимальными техническими знаниями путём запуска файлов скриптов 'run.bat' or 'run.sh'.

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

На рисунке ниже изображен результат работы скрипта:

На рисунке ниже часть манифеста до изменения инструментом обхода проверок подписи:

На рисунке ниже часть манифеста после изменения инструментом обхода проверок подписи (видно указание на внедрённый класс PmsHookApplication):

Сам класс PmsHookApplication, как он выглядит в dex:

Пример того, как выглядит набор байт подписи в этом классе:

Решил реализовать проверку подписи с помощью NDK используя чистый си, т. к. реверс-инженеров, которые могут декомпилировать нативные исполняемые файлы, значительно меньше. Игра в кошки-мышки :)

Сама проверка состоит из нескольких стадий: ● получаем путь апк файла; ● извлекаем 'META-INF/CERT.RSA' из apk с помощью zlib; ● парсим 'META-INF/CERT.RSA'; ● проверям набор байт из подписи либо в нативном слое, либо передаем его в Java-слой приложения.

Результат работы проверки можно увидеть ниже:

1) до применения nsktool (инструмент подделки подписи):

2) после применения nsktool (инструмент подделки подписи):

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

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

Для предотвращения этого: — скрывайте чувствительные строковые константы в коде; — используйте при компиляции флаг -fvisibility=hidden.