Урок 123. Как подписать приложение. Утилиты keytool и jarsigner
Тема этого урока не относится непосредственно к программированию. И вполне себе можно кодить без этих знаний. Но для общего развития, думаю, об этом все-таки стоит поговорить. Данные знания пригодятся вам, например, когда будете делать приложение с гугл-картой, или когда будете выкладывать свое творение на маркет.
Подпись приложения
Вообще, в процессе подписи и верификации участвуют закрытый/открытый ключи и сертификат. Если кому интересно, то можете погуглить эти понятия и почитать подробнее. Я же, чтобы не усложнять урок, буду просто называть все это ключом. Для понимания темы урока этого будет достаточно.
Вы создали приложение и хотите его протестировать на реальном устройстве или эмуляторе. Для того, чтобы установить и запустить приложение, оно должно быть подписано. Если вы еще не публиковали на маркете свои приложения, то, скорее всего, про то, что приложение надо подписывать, вы слышите первый раз. И точно помните, что ни с какими подписями не возились. Создавали проект, кодили все, что нужно, сохраняли и запускали и все прекрасно работало. Так происходило, потому что Eclipse сам создавал ключ и сам подписывал приложение этим ключом, чтобы вам на первых порах не приходилось думать об этом. И когда ваше приложение устанавливалось, оно было уже подписанным. А если попытаться установить неподписанное приложение, то получим ошибку.
Итак, приложение обязательно должно быть подписанным, и Eclipse любезно берет это на себя. Он подписывает их debug-ключом. Раньше срок его действия был всего один год. Android проверяет срок действия ключа только при установке. Т.е. если вы установили приложение и срок действия ключа истек, вы все равно сможете использовать установленное приложение. А вот установить или обновить приложение, подписанное истекшим ключом, не получится. Система выдаст ошибку.
Сейчас срок debug-ключа равен 30 лет. Но приложение, подписанное debug-ключом, не получится опубликовать на маркете. А значит, нам надо будет создавать свой ключ и подписывать им приложение.
keytool
Для создания ключа нам понадобится утилита keytool. Ее можно найти по адресу <папка с Java>\bin. Она умеет создавать новые ключи и показывать информацию о уже существующих. Давайте сначала попробуем посмотреть информацию о существующем ключе. Для этого возьмем тот самый debug-ключ, который используется для подписи приложений по умолчанию. Узнать где он находится можно в настройках Eclipse: Window > Preferences >Android > Build.
Файл debug.keystore имеет расширение keystore. Это можно перевести как хранилище ключей. Это действительно так, один такой файл может содержать в себе несколько ключей. Для того чтобы обратится к конкретному ключу внутри хранилища используется alias (алиас, можно рассматривать его как имя ключа).
Посмотрим, какие ключи есть в хранилище debug.keystore. Используем команду list. С помощью параметров keystore и storepass укажем имя файла хранилища и пароль к хранилищу:
keytool -list -keystore debug.keystore -storepass android
Мы видим, что здесь хранится один ключ с алиасом androiddebugkey, и создан он был 26.08.2012. Этот ключ и используется Eclipse-ом для подписи вашего приложения по умолчанию. Хранилище и ключ имеют одинаковый пароль — android.
Давайте создадим свой ключ. Для этого используем команду genkey и к ней идет куча параметров.
keytool -genkey -keystore mykeys.keystore -storepass spassword -alias mykey1 -keypass kpassword1 -dname “CN=Dmitry Vinogradov O=StartAndroid C=RU” -validity 10000
Выглядит страшно, но на самом деле все несложно. Просто надо понимать следующее:
хранилище — это файл и оно защищено паролем
ключ в хранилище имеет алиас и свой пароль
также ключ содержит информацию о владельце и имеет ограниченный срок действия
Именно эти вышеперечисленные параметры мы и задали в скрипте.
keystore — имя файла хранилища
storepass — пароль к хранилищу
alias — алиас создаваемого ключа
keypass — пароль к ключу
dname — информация о владельце ключа
validity — срок действия ключа (в днях)
dname задается в определенном формате. Я указал только имя, организацию и страну.
После выполнения этой команды в хранилище mykeys.keystore создался ключ с вышеуказанными параметрами. Если указанное хранилище не существует, то оно будет создано.
Теперь давайте снова используем команду list и поглядим на только что созданный ключ
keytool -list -keystore mykeys.keystore -storepass spassword
Видим, что внутри все так, как мы и создавали — один ключ с алиасом mykey1.
Туда же можно поместить второй ключ. Но теперь запишем скрипт создания ключа в несколько урезанном виде. Мы не будем указывать пароли к хранилищу и ключу, и информацию о владельце.
keytool -genkey -keystore mykeys.keystore -alias mykey2 -validity 10000
и программа спросит нас о недостающих данных. Сначала пароль к хранилищу, затем данные о владельце ключа (я заполнял не все требуемые значения), затем пароль для создаваемого ключа и подтверждение пароля.
Функционально разницы нет, но при таком способе вам не надо знать формат ввода параметра dname (утилита все спросит сама), и посторонним не видны пароли, которые вы вводили.
Теперь в хранилище два ключа. Выполним list и убедимся.
keytool -list -keystore mykeys.keystore
Обратите внимание, что я не ввел пароль от хранилища (например, чтобы не «светить» его). Утилита спросит меня:
Видно, что был запрошен пароль и в хранилище сейчас два ключа.
Команду list можно еще выполнить с параметром v. Этот параметр добавляет информативности.
Теперь для каждого ключа виден не только алиас и дата создания, но и инфа о владельце, срок действия и пр.
Параметр v также можно использовать и с командой genkey. После создания ключа будет выведено немного информации о нем в консоль.
jarsigner
Итак, разобрались с keytool. Знаем, как создавать хранилище с ключами и как посмотреть инфу о существующих. Осталось узнать, как подписать приложение ключом. Для этого используется другая утилита — jarsigner.
Скрипт подписи выглядит так:
jarsigner -keystore mykeys.keystore -storepass spassword -keypass kpassword1 Package1.apk mykey1
Имена параметров нам знакомы по keytool: хранилище (keystore), пароль (storepass) к нему и пароль (keypass) к ключу. А последние два параметра – это имя APK-файла, который вы хотите подписать и алиас ключа из указанного хранилища, который вы хотите использовать для подписи.
После этого приложение будет подписано и система примет его к установке.
Ради интереса давайте попробуем установить неподписанный APK. Чтобы создать его надо щелкнуть правой кнопкой мыши на проекте в Eclipse и выбрать Android tools > Export Unsigned Application Package. Далее указываем путь, куда сохранить APK-файл. Eclipse создает приложение из проекта и сохраняет его в указанный каталог. После этого он выводит сообщение, что перед публикацией приложения необходимо его подписать и сжать (утилитой zipalign).
Попробуем установить приложение на эмулятор с помощью adb. Получаем ошибку Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES]:
Система обнаружила, что приложение не подписано.
Если же сначала закинуть APK на эмулятор и там запустить файловым менеджером, получим такое сообщение при установке:
Визард
Eclipse предоставляет визард, который позволяет реализовать все вышеописанные шаги по подготовке приложения к установке. Для этого надо на проекте в Eclipse щелкнуть правой кнопкой и выбрать Android tools > Export Signed Application Package.
Визард на всякий случай уточнит проект
Затем надо выбрать: использовать существующее хранилище или создавать новое. Если используем существующее, то выбираем его и вводим пароль к этому хранилищу.
Жмем Next, и визард спрашивает, какой из существующих ключей использовать, либо дает возможность создать новый.
Выбираем существующий ключ, вводим пароль к нему
Осталось указать путь и имя файла, куда Eclipse сохранит готовое, подписанное и сжатое приложение. Заодно он сразу показывает срок действия сертификата.
Жмем Finish и получаем готовое приложение, которое можно публиковать на маркете.
Если же у вас пока нет ключа, то визард поможет вам его создать, чтобы не надо было возиться с консолью и keytool.
В этом случае вы указываете, что хотите создать хранилище
Далее надо создать ключ
Здесь вы указываете алиас, пароль, срок действия (в годах) и инфу о владельце.
Ну и остается указать путь к создаваемому файлу
По идее, я мог бы сразу показать вам этот визард, который за вас все сделает, но я думаю, что вы не понимали бы значение всех его экранов и полей. А это не очень хорошая практика – пользоваться тем, чего не понимаешь. Поэтому я подробно расписал механизм ключей и подписи приложений, чтобы вы представляли себе, как устроен этот процесс и что делает визард.
По поводу срока действия ключа, в хелпе пишут, что рекомендуется ставить 25 лет. И что при публикации приложения на маркете, проверяется, что срок действия закончится позднее, чем 22 октября 2033. Думаю, эта дата будет периодически сдвигаться.
На следующем уроке:
— разбираемся, что такое Package для приложения
Присоединяйтесь к нам в Telegram:
— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.
— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование
— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня
— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме
Опасности вторичной упаковки
Проблема вторичной упаковки является лишь частью угрозы безопасности приложений Android. Как правило, инструменты декомпиляции используются для вставки рекламного кода и связанных с ним конфигураций в приложения, а затем выпускаются на сторонних рынках приложений и форумах для ожидания «фишинга». Вред, наносимый упаковщиком мобильным приложениям, заключается в следующем:
- Вставьте свое собственное объявление или удалите оригинальное объявление;
- Вредоносный код, вредоносные отчисления, троянские кони и т.д .;
- Изменить оригинальную логику оплаты;
Вышеуказанное злонамеренное поведение наносит серьезный ущерб интересам мобильных продуктов и пользователей, а также влияет на корпоративную репутацию.
Механизм подписи APK
Механизм подписи APK, разработанный Google, призван предотвратить две проблемы:
- Не позволяйте другим изменять пакет APK, чтобы предотвратить вторичную упаковку после декомпиляции;
Как запретить другим упаковывать его снова? При установке APK в систему Android, он сначала проверит, есть ли подпись и может ли подпись совпадать; - Система Android не может устанавливать APK с тем же именем пакета, но разными сигнатурами при установке пакетов APK;
Следующее начинает анализировать процесс подписи APK:
Нужно знать фон
Пойди в Baidu самостоятельно, чтобы понять концепцию;
- Сводка данных (отпечаток данных), алгоритм симметричного шифрования MD5 \ SHA-1
- Алгоритм асимметричного шифрования
- Цифровая подпись, цифровой сертификат
- Подпишите пакеты APK вручную
1. Просмотр файла META-INF
Измените суффикс пакета .apk на .zip, откройте папку после распаковки и найдите каталог META-INF.
Подпись начинается вокруг этих трех документов.
2. Сначала посмотрите на первый файл MANIFEST.MF
Этот файл содержит сводные значения данных всех файлов в файле APK. Это эквивалентно дактилоскопии каждого отдельного (кроме этих трех) файлов.
3. Глядя на второй файл CERT.SF
Подобно файлу MANIFEST.MF, единственное отличие состоит в том, что есть еще одна строка SHA1-Digest-Manifest: KDerPmANkkB5mxceo/t5oXRGApg= , Эта строка является сводкой данных MANIFEST.MF.
4. Наконец, посмотрите на третий файл CERT.SF
Рассчитайте зашифрованное значение предыдущего файла CERT.SF с закрытым ключом, которое называется подписью, поэтому этот файл содержит подпись и открытый ключ;
Если это в системе Windows, рекомендуется использовать программное обеспечение cmder.exe, чтобы использовать следующую команду.
Обзор содержания сертификата:
Команда, используемая для управления хранилищем закрытого ключа:
резюме
После создания APK подпись не может быть изменена, так как нет закрытого ключа. Но он может заменить подпись, потому что система Android проверяет правильность подписи только при установке APK. (Это всего лишь мое личное предположение, и позже я углублюсь в проверку исходного кода системы, и настоящий молоток — это правда или ложь)
Процесс подписания можно представить как поток обработки отправителя и получателя, и это также двустороннее действие, которое можно грубо понимать как следующий поток:
Вы можете заменить клиента 1 на изображении выше процессом упаковки APK и заменить сервер процессом установки APK на телефонах Android.Если система хранит открытый ключ в CERT.RSA, а значение хеш-функции расшифровывается в исходном apk и файле CERT.SF. Если значение Hash не соответствует, оно не будет установлено.
Проверьте, можно ли заменить подпись
Необходимым условием для успешной вторичной упаковки является то, что подпись может быть заменена, и APK не выполняет проверку подписи. Есть три способа проверить подпись:
Пакет APK не делает проверку подписи
Просто замените подпись. Шаги по замене подписи будут описаны ниже;
- проверка кода Java
Сложность состоит в том, чтобы найти проверенный код JAVA, просто закомментируйте его; - Проверка .so файла
Сложность состоит в том, чтобы найти проверенный код C, просто закомментируйте его; - пак
Трудность заключается в том, чтобы сначала распаковать;
Заменить шаги подписи
шаги:
Используя инструмент AndroidKiller_v1.3.1, который имеет функцию компиляции, вы можете выполнить вторичную упаковку, принцип состоит в том, чтобы заменить значение подписи.
Вскрываем, модифицируем и запаковываем Android-приложения
Иногда некоторые приложения на Android чем-то не устраивают пользователя. В качестве примера можно привести назойливую рекламу. А то бывает и так — всем хороша программа, да только перевод в ней или кривой, или вовсе отсутствует. Или, например, программа триальная, а получить полную версию возможности нет. Как же изменить ситуацию?
Введение
В этой статье мы поговорим о том, как разобрать пакет APK с приложением, рассмотрим его внутреннюю структуру, дизассемблируем и декомпилируем байт-код, а также попробуем внести в приложения несколько изменений, которые могут принести нам ту или иную выгоду.
Чтобы сделать все это самостоятельно, потребуются хотя бы начальные знания языка Java, на котором пишутся приложения для Android, и языка XML, который используется в Android повсеместно — от описания самого приложения и его прав доступа до хранения строк, которые будут выведены на экран. Также понадобится умение обращаться со специализированным консольным софтом.
Итак, что же представляет собой пакет APK, в котором распространяется абсолютно весь софт для Android?
Декомпиляция приложений
В статье мы работали только с дизассемблированным кодом приложения, однако если в большие приложения вносить более серьезные изменения, разобраться в коде smali будет гораздо сложнее. К счастью, мы можем декомпилировать код dex в Java-код, который будет хоть и не оригинальным и не компилируемым обратно, но гораздо более легким для чтения и понимания логики работы приложения. Чтобы сделать это, нам понадобятся два инструмента:
- dex2jar — транслятор байт-кода Dalvik в байт-код JVM, на основе которого мы сможем получить код на языке Java;
- jd-gui — сам декомпилятор, позволяющий получить из байт-кода JVM читаемый код Java. В качестве альтернативы можно использовать Jad (www.varaneckas.com/jad); хоть он и довольно старый, но в некоторых случаях генерирует более читаемый код, нежели Jd-gui.
Использовать их следует так. Сначала запускаем dex2jar, указывая в качестве аргумента путь до apk-пакета:
В результате в текущем каталоге появится Java-пакет mail.jar, который уже можно открыть в jd-gui для просмотра Java-кода.
Устройство APK-пакетов и их получение
Пакет приложения Android, по сути, является обычным ZIP-файлом, для просмотра содержимого и распаковки которого никаких специальных инструментов не требуется. Достаточно иметь архиватор — 7zip для Windows или консольный unzip в Linux. Но это что касается обертки. А что внутри? Внутри же у нас в общем случае такая структура:
- META-INF/ — содержит цифровой сертификат приложения, удостоверяющий его создателя, и контрольные суммы файлов пакета;
- res/ — различные ресурсы, которые приложение использует в своей работе, например изображения, декларативное описание интерфейса, а также другие данные;
- AndroidManifest.xml — описание приложения. Сюда входит, например, список требуемых разрешений, требуемая версия Android и необходимое разрешение экрана;
- classes.dex — компилированный байт-код приложения для виртуальной машины Dalvik;
- resources.arsc — тоже ресурсы, но другого рода — в частности, строки (да-да, этот файл можно использовать для русификации!).
Перечисленные файлы и каталоги есть если не во всех, то, пожалуй, в абсолютном большинстве APK. Однако стоит упомянуть еще несколько не столь распространенных файлов/каталогов:
- assets — аналог ресурсов. Основное отличие — для доступа к ресурсу необходимо знать его идентификатор, список asset’ов же можно получать динамически, используя метод AssetManager.list() в коде приложения;
- lib — нативные Linux-библиотеки, написанные с помощью NDK (Native Development Kit).
Этот каталог используют производители игр, помещая туда движок игры, написанный на C/C++, а также создатели высокопроизводительных приложений (например, Google Chrome). С устройством разобрались. Но как же получить сам файл пакета интересующего приложения? Поскольку без рута с устройства забрать файлы APK не представляется возможным (они лежат в каталоге /data/app), а рутить не всегда целесообразно, имеется как минимум три способа получить файл приложения на компьютер:
- расширение APK Downloader для Chrome;
- приложение Real APK Leecher;
- различные файлообменники и варезники.
Какой из них использовать — дело вкуса; мы предпочитаем использовать отдельные приложения, поэтому опишем использование Real APK Leecher, тем более что написан он на Java и, соответственно, работать будет хоть в винде, хоть в никсах.
После запуска программы необходимо заполнить три поля: Email, Password и Device ID — и выбрать язык. Первые два — e-mail и пароль твоего гуглоаккаунта, который ты используешь на устройстве. Третий же является идентификатором устройства, и его можно получить, набрав на номеронабирателе код ##8255## и затем найдя строку Device ID. При заполнении надо ввести только ID без префикса android-.
Настройка Real APK Leecher
Другие статьи в выпуске: 
Хакер #170. Малварь для OS X
После заполнения и сохранения нередко выскакивает сообщение «Error while connecting to server». Оно не имеет отношения к Google Play, поэтому смело его игнорируй и ищи интересующие тебя пакеты.
Просмотр и модификация
Допустим, ты нашел интересующий тебя пакет, скачал, распаковал… и при попытке просмотра какого-нибудь XML-файла с удивлением обнаружил, что файл не текстовый. Чем же его декомпилировать и как вообще работать с пакетами? Неужели необходимо ставить SDK? Нет, SDK ставить вовсе не обязательно. На самом деле для всех шагов по распаковке, модификации и упаковке пакетов APK нужны следующие инструменты:
- архиватор ZIP для распаковки и запаковки;
- smali — ассемблер/дизассемблер байт-кода виртуальной машины Dalvik (code.google.com/p/smali);
- aapt — инструмент для запаковки ресурсов (по умолчанию ресурсы хранятся в бинарном виде для оптимизации производительности приложения). Входит в состав Android SDK, но может быть получен и отдельно;
- signer — инструмент для цифровой подписи модифицированного пакета (bit.ly/Rmrv4M).
Использовать все эти инструменты можно и по отдельности, но это неудобно, поэтому лучше воспользоваться более высокоуровневым софтом, построенным на их основе. Если ты работаешь в Linux или Mac OS X, то тут есть инструмент под названием apktool. Он позволяет распаковывать ресурсы в оригинальный вид (в том числе бинарные XML- и arsc-файлы), пересобирать пакет с измененными ресурсами, но не умеет подписывать пакеты, так что запускать утилиту signer придется вручную. Несмотря на то что утилита написана на Java, ее установка достаточно нестандартна. Сначала следует получить сам jar-файл:
Далее нам понадобится скрипт-обвязка для запуска apktool (он, кстати, доступен и для Windows), включающий в себя еще и утилиту aapt, которая понадобится для запаковки пакета:
Далее просто сваливаем содержимое обоих архивов в каталог
/bin и добавляем его в $PATH:
Если же ты работаешь в Windows, то для нее есть превосходный инструмент под названиемVirtuous Ten Studio, который также аккумулирует в себе все эти инструменты (включая сам apktool), но вместо CLI-интерфейса предоставляет пользователю интуитивно понятный графический интерфейс, с помощью которого можно выполнять операции по распаковке, дизассемблированию и декомпиляции в несколько кликов. Инструмент этот Donation-ware, то есть иногда появляются окошки с предложением получить лицензию, но это, в конце концов, можно и потерпеть. Описывать его не имеет никакого смысла, потому что разобраться в интерфейсе можно за несколько минут. А вот apktool, вследствие его консольной природы, следует обсудить подробнее.
Импорт APK в Virtuous Ten Studio
Рассмотрим опции apktool. Если вкратце, то имеются три основные команды: d (decode), b (build) и if (install framework). Если с первыми двумя командами все понятно, то что делает третья, условный оператор? Она распаковывает указанный UI-фреймворк, который необходим в тех случаях, когда ты препарируешь какой-либо системный пакет.
Рассмотрим наиболее интересные опции первой команды:
- -s — не дизассемблировать файлы dex;
- -r — не распаковывать ресурсы;
- -b — не вставлять отладочную информацию в результаты дизассемблирования файла dex;
- —frame-path — использовать указанный UI-фреймворк вместо встроенного в apktool. Теперь рассмотрим пару опций для команды b:
- -f — форсированная сборка без проверки изменений;
- -a — указываем путь к aapt (средство для сборки APK-архива), если ты по какой-то причине хочешь использовать его из другого источника.
Пользоваться apktool очень просто, для этого достаточно указать одну из команд и путь до APK, например:
После этого в каталоге mail появятся все извлеченные и дизассемблированные файлы пакета.
Препарирование. Отключаем рекламу
Теория — это, конечно, хорошо, но зачем она нужна, если мы не знаем, что делать с распакованным пакетом? Попробуем применить теорию с пользой для себя, а именно модифицируем какую-нибудь софтину так, чтобы она не показывала нам рекламу. Для примера пусть это будет Virtual Torch — виртуальный факел. Для нас эта софтина подойдет идеально, потому что она под завязку набита раздражающей рекламой и к тому же достаточно проста, чтобы не потеряться в дебрях кода.
Поиск кода рекламы в jd-gui
Итак, с помощью одного из приведенных способов скачай приложение из маркета. Если ты решил использовать Virtuous Ten Studio, просто открой APK-файл в приложении и распакуй его, для чего создай проект (File -> New project), затем в контекстном меню проекта выбери Import File. Если же твой выбор пал на apktool, то достаточно выполнить одну команду:
После этого в каталоге com.kauf.particle.virtualtorch появится файловое дерево, похожее на описанное в предыдущем разделе, но с дополнительным каталогом smali вместо dex-файлов и файлом apktool.yml. Первый содержит дизассемблированный код исполняемого dex-файла приложения, второй — служебную информацию, необходимую apktool для сборки пакета обратно.
Первое место, куда мы должны заглянуть, — это, конечно же, AndroidManifest.xml. И здесь мы сразу встречаем следующую строку:
Нетрудно догадаться, что она отвечает за предоставление приложению полномочий на использование интернет-соединения. По сути, если мы хотим просто избавиться от рекламы, нам, скорее всего, достаточно будет запретить приложению интернет. Попытаемся это сделать. Удаляем указанную строку и пробуем собрать софтину с помощью apktool:
В каталоге com.kauf.particle.virtualtorch/build/ появится результирующий APK-файл. Однако установить его не получится, так как он не имеет цифровой подписи и контрольных сумм файлов (в нем просто нет каталога META-INF/). Мы должны подписать пакет с помощью утилиты apk-signer. Запустили. Интерфейс состоит из двух вкладок — на первой (Key Generator) создаем ключи, на второй (APK Signer) подписываем. Чтобы создать наш приватный ключ, заполняем следующие поля:
- Target File — выходной файл хранилища ключей; в нем обычно хранится одна пара ключей;
- Password и Confirm — пароль для хранилища;
- Alias — имя ключа в хранилище;
- Alias password и Confirm — пароль секретного ключа;
- Validity — срок действия (в годах). Значение по умолчанию оптимально.
Остальные поля, в общем-то, необязательны — но необходимо заполнить хотя бы одно.
Создание ключа в apk-signer
WARNING
Чтобы подписать приложение с помощью apk-signer, ты должен установить Android SDK и указать полный путь до него в настройках приложения.
Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.
Теперь этим ключом можно подписать APK. На вкладке APK Signer выбираем только что сгенерированный файл, вводим пароль, алиас ключа и пароль к нему, затем находим файл APK и смело жмем кнопку «Sign». Если все пройдет нормально, пакет будет подписан.
Так как мы подписали пакет нашим собственным ключом, он будет конфликтовать с оригинальным приложением, а это значит, что при попытке обновить софтину через маркет мы получим ошибку.
Цифровая подпись необходима только стороннему софту, поэтому если ты занимаешься модификацией системных приложений, которые устанавливаются копированием в каталог /system/app/, то подписывать их не нужно.
После этого скидываем пакет на смартфон, устанавливаем и запускаем. Вуаля, реклама пропала! Вместо нее, однако, появилось сообщение, что у нас нет интернета или отсутствуют соответствующие разрешения. По идее, этого могло бы и хватить, но сообщение выглядит раздражающе, да и, если честно, нам просто повезло с тупым приложением. Нормально написанная софтина, скорее всего, уточнит свои полномочия или проверит наличие интернет-соединения и в противном случае просто откажется запускаться. Как быть в этом случае? Конечно, править код.
Обычно авторы приложений создают специальные классы для вывода рекламы и вызывают методы этих классов во время запуска приложения или одной из его «активностей» (упрощенно говоря, экранов приложения). Попробуем найти эти классы. Идем в каталог smali, далее com (в org лежит только открытая графическая библиотека cocos2d), далее kauf (именно туда, потому что это имя разработчика и там лежит весь его код) — и вот он, каталог marketing. Внутри находим кучу файлов с расширением smali. Это классы, и наиболее примечателен из них класс Ad.smali, по названию которого нетрудно догадаться, что именно он выводит рекламу.
Мы могли бы изменить логику его работы, но гораздо проще будет тупо убрать вызовы любых его методов из самого приложения. Поэтому выходим из каталога marketing и идем в соседний каталог particle, а затем в virtualtorch. Особого внимания здесь заслуживает файл MainActivity.smali. Это стандартный для Android класс, который создается Android SDK и устанавливается в качестве точки входа в приложение (аналог функции main в Си). Открываем файл на редактирование.
Внутри находится код smali (местный ассемблер). Он довольно запутанный и трудный для чтения в силу своей низкоуровневой природы, поэтому мы не будем его изучать, а просто найдем все упоминания класса Ad в коде и закомментируем их. Вбиваем строку «Ad» в поиске и попадаем на строку 25:
Здесь создается поле ad для хранения объекта класса Ad. Комментируем с помощью установки знака ### перед строкой. Продолжаем поиск. Строка 423:
Здесь происходит создание объекта. Комментируем. Продолжаем поиск и находим в строках 433, 435, 466, 468, 738, 740, 800 и 802 обращения к методам класса Ad. Комментируем. Вроде все. Сохраняем. Теперь пакет необходимо собрать обратно и проверить его работоспособность и наличие рекламы. Для чистоты эксперимента возвращаем удаленную из AndroidManifest.xml строку, собираем пакет, подписываем и устанавливаем.
Наш подопытный кролик. Видна реклама 
Он же, но уже без рекламы
Оп-па! Реклама пропала только во время работы приложения, но осталась в главном меню, которое мы видим, когда запускаем софтину. Так, подождите, но ведь точка входа — это класс MainActivity, а реклама пропала во время работы приложения, но осталась в главном меню, значит, точка входа другая? Чтобы выявить истинную точку входа, вновь открываем файл AndroidManifest.xml. И да, в нем есть следующие строки:
Они говорят нам (и, что важнее, андроиду) о том, что активность с именем Start должна быть запущена в ответ на генерацию интента (события) android.intent.action.MAIN из категории android.intent.category.LAUNCHER. Это событие генерируется при тапе на иконку приложения в ланчере, поэтому оно и определяет точку входа, а именно класс Start. Скорее всего, программист сначала написал приложение без главного меню, точкой входа в которое был стандартный класс MainActivity, а затем добавил новое окно (активность), содержащее меню и описанное в классе Start, и вручную сделал его точкой входа.
Открываем файл Start.smali и вновь ищем строку «Ad», находим в строках 153 и 155 упоминание класса FirstAd. Он тоже есть в исходниках и, судя по названию, как раз и отвечает за показ объявлений на главном экране. Смотрим дальше, идет создание экземпляра класса FirstAd и интента, по контексту имеющего отношение к этому экземпляру, а дальше метка cond_10, условный переход на которую осуществляется аккурат перед созданием экземпляра класса:
Скорее всего, программа каким-то случайном образом вычисляет, нужно ли показывать рекламу на главном экране, и, если нет, перескакивает сразу на cond_10. Ок, упростим ей задачу и заменим условный переход на безусловный:
Больше упоминаний FirstAd в коде нет, поэтому закрываем файл и вновь собираем наш виртуальный факел с помощью apktool. Копируем на смартфон, устанавливаем, запускаем. Вуаля, вся реклама исчезла, с чем нас всех и поздравляем.
- Перевод приложений Android;
- пример снятия триала с приложения.
Итоги
Эта статья лишь краткое введение в методы вскрытия и модификации Android-приложений. За кадром остались многие вопросы, такие как снятие защиты, разбор обфусцированного кода, перевод и замена ресурсов приложения, а также модификация приложений, написанных с использованием Android NDK. Однако, имея базовые знания, разобраться во всем этом — лишь вопрос времени.
Ответы на распространенные вопросы о подписании приложений в Google Play
Приложения для Android имеют криптографическую подпись разработчика. С ее помощью менеджер пакетов на устройстве пользователя может проверить, что каждое обновление приложения происходит из одного и того же источника, и что оно не было подделано. Google Play также применяет эту проверку подписи, когда вы загружаете свой APK-файл на консоль Google Play, так что даже если бы у кого-то были ваши учетные данные для входа, было бы невозможно отправить вредоносное обновление, не имея также доступа к вашему закрытому ключу.
Исторически сложилось так, что разработчики отвечали за создание своих собственных закрытых ключей и сохраняли их в безопасности на протяжении всего срока службы приложения. И хотя такой подход предлагал большую гибкость, он также приводил к ошибкам: генерация слабых ключей, случайная проверка вашего закрытого ключа в публичном репозитории или даже полная его потеря — это всего лишь несколько распространенных ошибок, которые регулярно происходят даже с опытными разработчиками.
В настоящее время у разработчиков есть привлекательная альтернатива для управления ключами самостоятельно: подписание приложения на Google Play, где ключ загрузки (тот, который вы используете, чтобы загрузить свои артефакты в Google Play) и ключ для подписи приложения (который используется для подписи APK-файлов, распространяющихся на устройства) могут быть разными, и второй ключ хранится на Google инфраструктуре.
Несмотря на то, что многие другие популярные платформы используют такой способ распределения ключей, для многих разработчиков это отход от предыдущей модели подписи Android, и некоторые из них могут подумать, что они теряют контроль над своими приложениями.
Вот почему я хочу развеять некоторые распространенные заблуждения относительно подписи приложений в Google Play, а также дать рекомендации по конкретным сценариям, с которыми вы можете столкнуться.
Этот совет основан на вопросах, которые наша команда по связям с разработчиками слышала на конференциях, в онлайн-форумах и наших чатах 1:1.
Давайте начнем с самой убедительной причины для перехода на подписание приложений с помощью Google Play:
Без подписи приложения в Google Play: благодаря защите безопасности, встроенной в Android, без ключа вы или Google ничего не можете сделать для продолжения обновления вашего приложения. Ваш единственный вариант — это создать новый список с новым именем пакета и начать с нуля.
С подписью приложения в Google Play: вы можете запросить новый ключ загрузки. Play сможет продолжать подписывать обновления вашего приложения с помощью ключа подписи приложения, который надежно хранится в Google.
Если бы я назвал одну причину, которая говорит за принятие подписи приложения, то это была бы та, что выше. Но прежде чем мы пойдем дальше и поговорим о конкретных сценариях, которые этот метод может помочь исправить (есть и другие!), давайте сначала сделаем паузу, чтобы ответить на мета-вопрос:
Первым приоритетом Google Play является создание безопасной и надежной платформы для миллиардов пользователей и миллионов разработчиков.
От этого зависит устойчивость и успех экосистемы. Большинство разработчиков не могут обеспечить тот уровень безопасности, который может предложить Google.
Новая модель приложения, где Play поглощает артефакты публикации и генерирует подписанные, предназначена для минимизации шанса того, что ключи подписи будут раскрыты. Она не только безопасна, но и более эффективна, а также ориентирована на будущее с выгодой как для конечных пользователей, так и для разработчиков.
Например, ряд приложений, находящихся в настоящее время в Play Store, до сих пор не приняли более безопасную схему подписи v2. После регистрации в приложении подписи от Google Play приложения автоматически получают преимущества новых механизмов защиты и будущих улучшений, без необходимости работы разработчика.
И наконец, разделение формата публикации (с использованием пакетов приложений для Android) и формата обслуживания (разделенные APK) открывает преимущества как для разработчиков, так и для пользователей: от повышения безопасности до оптимизации, снижения сложности и фрагментации. Однако для этого Play должен иметь возможность подписывать обслуживающие артефакты.
Некоторые примеры функций, доступных прямо сейчас, — это автоматическая оптимизация размера для доставки приложений, а также новые настраиваемые параметры доставки модулей в вашем приложении.
Что еще более важно, такой подход дает нам возможность развивать и совершенствовать механизмы доставки в будущем, обеспечивая при этом доверие и безопасность распределяемых артефактов.
Несмотря на то, что мы продолжаем совершенствовать наш стек обслуживания, мы не изменяем и не распространяем код вашего приложения без вашего ведома и одобрения, и новые оптимизации, которые выполняет Play, доступны для вашего контроля в bundletool с открытым исходным кодом. Далее в этом часто FAQ мы обсудим некоторые метаданные (те, которые не влияют на работу вашего приложения), которые вы можете увидеть между артефактами, загруженными из Play и созданными локально.
Без подписи приложения в Google Play: как уже упоминалось ранее, вы не можете просто переключиться на новый ключ, так как это будет означать, что ваши существующие пользователи не смогут получать обновления приложений. Вы должны либо продолжать использовать существующий ключ и рисковать безопасностью данных ваших пользователей, либо начать новую запись приложения с нуля.
С подписью приложения в Google Play: если вы используете слабый ключ или ваш ключ был скомпрометирован, вы можете обновить его для новых установок.
Это осуществляется путем доставки APK, подписанных вашим устаревшим ключом, существующим пользователям, когда они обновляют приложение, в то время как новые установки приложений получают APK, подписанные обновленным безопасным ключом.
Рассмотрите включение подписи приложения сейчас и как можно скорее переключитесь на использование отдельного ключа загрузки, что снизит вероятность компрометирования ключа подписи приложения.
Текущий процесс обновления до нового ключа не является мгновенным, и если ключ подписи приложения утечет, ваши существующие пользователи будут подвергаться риску до тех пор, пока они не переустановят приложение или не перейдут на новое устройство.
Обратите внимание, что текущий процесс обновления ключа не использует преимущества функции ротации ключа, введенной в Android 9 (Pie) и выше. В настоящее время мы изучаем поддержку ротации ключей с помощью подписи приложения версии 3 для устройств на этих версиях ОС и сообщим об этом сообществу разработчиков, как только оно будет готово, в отдельном объявлении.
Без подписи приложения в Google Play: нет никакой концепции отдельного “ключа загрузки”, поэтому, если ваш ключ подписи выпуска утечет, вы можете оказаться в большой беде: кто-то может создать вредоносные или несанкционированные версии вашего приложения, которые будут неразличимы (и обновляемы!) от вашего оригинального APK.
Конечно, защита учетной записи Google применяется к доступу к консоли Google Play (и мы рекомендуем разработчикам включить 2-ступенчатую проверку), поэтому злоумышленнику все равно придется найти способ обмануть пользователя, чтобы он загрузил такой измененный APK. Тем не менее безопасность вашего приложения ослаблена.
Обратитесь к вопросу 3 о скомпрометированном ключе подписи приложения, чтобы узнать, какие исправления доступны, а также как обновить ключ для новых установок.
С подписью приложения в Google Play: если ваш ключ загрузки отделен от ключа подписи приложения (рекомендованный вариант), и просочился только первый, то данные ваших пользователей будут в безопасности — одного ключа загрузки недостаточно, чтобы подменить APK, подписанные ключом подписи приложения. Просто запросите новый ключ загрузки.
Если вы продолжили использовать ключ подписи приложения для загрузки в Play, когда вы впервые включили подпись приложения, и он просочился, вы находитесь в немного худшей ситуации, но подпись приложения все еще может исправить эту проблему. Следуйте советам о том, как обновить свой ключ для новых установок.
Вы или кто-либо другой в вашей учетной записи разработчика не может загрузить и сохранить закрытый ключ для вашего приложения, хранящегося в защищенной инфраструктуре Google. Это делается для обеспечения защиты ключа подписи вашего приложения.
Если вы предвидите ситуацию, в которой вам потребуется постоянный доступ к ключу подписи вашего приложения, вам следует сделать следующее при включении подписи приложения:
· Не выбирайте опцию, в которой Google Play создает ключ подписи приложения за вас. Вместо этого создайте свой ключ подписи локально на вашем компьютере.
· Надежно перенесите свой ключ в Google Play и не удаляйте его с вашего компьютера.
· Храните ключ в надежном месте, чтобы он не просочился к третьим лицам.
· Убедитесь, что вы регулярно создаете и тестируете резервные копии своего ключа, так как в случае его потери вы не сможете загрузить его из Google.
Эти шаги описаны в документации. В инструкции о том, как ”выбрать существующее приложение”, показано, как зашифровать свой ключ подписи, чтобы загрузить его на консоль Google Play из Android Studio или командной строки.
Если вы абсолютно уверены, что вам не понадобится постоянный доступ к ключу подписи вашего личного приложения, мы рекомендуем вам либо разрешить Play генерировать ваш ключ (для новых приложений), либо удалить свою копию после передачи ее в Play и переключиться на использование ключа загрузки.
Ключ загрузки может быть сброшен, и это не ставит под угрозу безопасность ваших пользователей в случае утечки информации.
Если вы включаете подпись приложения для нового приложения и выбираете опцию создания нового ключа в консоли Google Play, ключ никогда не передается и генерируется непосредственно на защищенном сервере Google.
Если вам нужно передать существующий ключ подписи (необязательно для новых приложений и обязательно для существующих приложений), вы всегда делаете это в зашифрованном виде. Независимо от того, экспортируете ли вы ключ из Android Studio или из командной строки, вы будете использовать инструмент шифрования закрытого ключа Play (PEPK) локально на вашем компьютере перед передачей ключа.
В случае, если вам нужно знать детали используемого шифрования, PEPK использует асимметричное шифрование эллиптической кривой P256 с симметричным шифрованием AES. Если вам нужно получить более подробную информацию, вы можете загрузить инструмент PEPK и его исходный код во время процесса регистрации подписи приложения.
Не стесняйтесь просматривать или компилировать его самостоятельно, чтобы он мог быть запущен в вашей собственной безопасной среде, гарантируя, что незашифрованный ключ никогда не будет раскрыт.
Используйте только версии PEPK, загруженные с консоли Google Play, никогда не загружайте его или его источник с непроверенных сторонних веб-сайтов.
Когда вы используете подпись приложения в Google Play, ваши ключи хранятся в той же инфраструктуре, где и Google хранит свои собственные.
Доступ к ключам регулируется строгими ACL и аудиторскими следами с защитой от несанкционированного доступа для всех операций.
Все артефакты, созданные и подписанные ключом разработчика, становятся доступными в консоли Google Play для проверки/аттестации.
Кроме того, чтобы предотвратить потерю ключей, мы очень часто делаем резервные копии нашего основного хранилища. Эти резервные копии строго зашифрованы, и мы регулярно тестируем восстановление из этих резервных копий.
Если вы хотите узнать о технической инфраструктуре Google, ознакомьтесь с информационными документами Google Cloud Security.
Если вы хотите использовать сервисы или API, которые требуют регистрации с хэшем публичного сертификата вашего приложения, вы можете просмотреть или загрузить “отпечатки пальцев” публичного сертификата из раздела “App signing“ консоли Google Play:
Не забывайте всегда использовать эти отпечатки пальцев при включении сервисов для выпускных версий вашего приложения, а не для тех, которые получены из вашего ключа загрузки.
Большинство сервисов позволяют включить несколько сертификатов для приложения, поэтому вы можете продолжить тестирование с локально построенными APK, а также APK, генерируемыми Google Play.
Как уже говорилось ранее, Play не будет изменять функциональность вашего приложения без вашего ведома и одобрения. Однако он вставляет небольшое количество метаданных, которые помогают проверить источник и целостность распространения. Эти метаданные бывают двух видов:
• Для всех приложений, загруженных в Google Play, Play добавлял метаданные безопасности после блока подписи, чтобы включить такие функции, как авторизованный обмен приложениями P2P. Мы объявили об этом первоначально в своем блоге в 2017 году.
• Для приложений, загруженных в виде пакетов приложений, мы улучшим безопасность, введя так называемый штамп источника. Эти исходные метаданные вставляются в манифест приложения с помощью bundletool. Когда APK генерируется на сервере Play, он также подписывается с помощью ключа Google в дополнение к вашему ключу подписи приложения.
Это означает, что метаданные безопасности не могут быть удалены или изменены без аннулирования подписи Google. Такой подход дает сигнал высокой уверенности в том, что немодифицированные АПК, содержащие исходный штамп, пришли из Google Play.
Вы можете локально использовать bundletool с открытым исходным кодом для генерации APK из пакетов точно так же, как это делает Play на сервере. Метаданные исходного штампа, добавленные bundletool, не будут подписаны ключом Google. Другие исходные подписи будут возможны, когда ApkSigner будет обновлен со следующим выпуском Android.
Есть несколько вариантов, доступных для вас:
• В целях тестирования вы можете использовать внутреннюю ссылку на общий доступ к приложению для любой исторической версии вашего приложения из проводника пакетов приложений консоли Google Play. Нажатие на ссылку на устройстве приведет к установке APK, которые Play Store установит в prod для этого устройства.
• Вы также можете загрузить подписанные APK-файлы для конкретных устройств из проводника пакетов приложений консоли Google Play.
Приложения можно распространять несколькими способами и по разным каналам. Есть несколько соображений, которые вы должны иметь в виду, в зависимости от того, является ли это приложение новым или существующим.
Для новых приложений вы можете использовать отдельные ключи подписи для каждого канала распространения, а Google будет генерировать ключ, используемый Google Play для вас. Это самый безопасный способ для приложений, распространяемых в Play, так как ключ никогда не покидает серверы Google, что сводит вероятность того, что кто-то перехватит ключ, почти к нулю.
Кроме того, для тех, кто не хочет управлять несколькими ключами, но все еще использует преимущества безопасности подписи приложений в Google Play, мы скоро предоставим возможность загружать подписанные универсальные APK из проводника пакетов приложений и распространять их в других магазинах.
Для существующих приложений: если вы уже используете один ключ для разных магазинов, при желании вы можете продолжать это делать. При включении входа в приложение в Google Play вам будет предложено загрузить существующий ключ.
При необходимости вы можете рассмотреть функцию обновления ключа, упомянутую ранее, чтобы со временем отказаться от совместного использования ключа, используемого Google Play, с другими каналами распространения.
Есть одно предостережение, которое приходит вместе с вышеприведенным советом: пожалуйста, обратите внимание, что если вы решите использовать отдельные ключи подписи для разных магазинов, ваши пользователи не смогут перекрестно обновлять приложение между различными каналами распространения. Например, когда кто-то изначально установил приложение через другой магазин, а затем пытается обновить его через Play. Они должны будут удалить и установить приложение снова.
Нет, вы не должны делать все сразу.
Вы можете выбрать подписание приложений от Google Play и продолжить публикацию APK. Когда вы будете готовы, вы можете начать публиковать пакеты приложений для Android.
Публикация с помощью пакета приложений проста для систем сборки, которые поддерживают его, и автоматически предоставляет такие преимущества, как уменьшение размера, для большинства приложений.
Со временем вы можете воспользоваться преимуществами расширенных функций, таких как динамическая доставка. Вы также можете модулировать свое приложение с помощью динамических функциональных модулей, чтобы улучшить время сборки и воспользоваться преимуществами настраиваемой доставки. Play может использовать динамическую доставку для предоставления высококачественных активов во время или после установки с настраиваемыми режимами и интеллектуальными опциями таргетинга.
Если вы хотите начать использовать подпись приложений, но ваши менеджеры или команды по безопасности нуждаются в объяснении преимуществ и предостережений касательно подписи приложений, то покажите им эту статью.
Перевод: Лебедев Даниил.
Еще больше полезной и нужной информации вы найдете в нашем Телеграм-канале по ссылке: