Подделка подписи Android-приложения и её проверка

Несколько лет назад обнаружил, что в интернете появляются свежие версии моих, слегка изменённых (была убрана монетизация), 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.