Обнаружение взлома кода в Apk

Question

Я особенно новичок в разработке приложений и недавно узнал обо всем процессе подписания apk, почему он является обязательным и важно предотвращать несанкционированное и фальсификацию приложения. Одна из известных проверок Signature относится к использованию класса PackageManager для проверки подписи. Есть ли какой-либо другой метод, который проверяет каталог META-INF в самом apk на предмет фальсификации или других оскорбительных действий, чтобы убедиться, что приложение не подделано и не повреждено своей оригинальной подписью?

Answer 1

Лучшей практикой является обнаружение взлома на стороне сервера, которое не может быть исправлено.

Вот как:

Используйте Android SafetyNet. Так проверяет себя Android Pay.

Основной поток:

• Ваш сервер генерирует одноразовый номер, который отправляет клиентскому приложению.
• Приложение отправляет запрос проверки с одноразовым номером через Сервисы Google Play.
• SafetyNet проверяет, что локальное устройство не было изменено и прошло CTS.
• Ответ, подписанный Google ("аттестация"), возвращается вашему приложению с результатом "прошел / не прошел" и информацией об APK-файле вашего приложения (хэш-код и сертификат подписи).
• Ваше приложение отправляет подтверждение на ваш сервер.
• Ваш сервер проверяет одноразовый номер и подпись APK, а затем отправляет подтверждение на сервер Google для проверки. Google проверяет аттестационную подпись и сообщает вам, подлинная ли она.

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

Учтите, однако, что это означает:

• Пользователи, рутировавшие свой телефон, не пройдут эти проверки. Пользователи, которые установили пользовательское или стороннее ПЗУ / прошивку / ОС (например, Cyanogen), не пройдут эти проверки.

• Пользователи, у которых нет доступа к сервисам Google Play (например, устройства Amazon, люди в Китае), не пройдут эти проверки.

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

Наконец, поймите, что это не совсем герметичное решение. Имея root-доступ и, возможно, Xposed, можно изменить библиотеку SafetyNet, чтобы она лгала серверам Google, сообщая им "правильные" ответы, чтобы получить результат проверки, подписанный Google. В действительности SafetyNet просто перемещает цели и усложняет задачу злоумышленникам. Поскольку эти проверки в конечном итоге должны выполняться на неподконтрольном вам устройстве, действительно невозможно создать полностью безопасную систему.

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

Answer 2

Этот код Получите контрольную сумму CRC файла Classes.dex и сравните ее с предоставленной.

private void crcTest() throws IOException {
 boolean modified = false;
 // required dex crc value stored as a text string.
 // it could be any invisible layout element
 long dexCrc = Long.parseLong(Main.MyContext.getString(R.string.dex_crc));

 ZipFile zf = new ZipFile(Main.MyContext.getPackageCodePath());
 ZipEntry ze = zf.getEntry("classes.dex");

 if ( ze.getCrc() != dexCrc ) {
  // dex has been modified
  modified = true;
 }
 else {
  // dex not tampered with
  modified = false;
 }
}