Как подписать ваше гибридное мобильное приложение для размещения в Google Play

Хакер #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-файл:

$ cd /tmp $ wget http://bit.ly/WC3OCz $ tar -xjf apktool1.5.1.tar.bz2 

Далее нам понадобится скрипт-обвязка для запуска apktool (он, кстати, доступен и для Windows), включающий в себя еще и утилиту aapt, которая понадобится для запаковки пакета:

$ wget http://bit.ly/WRjEc7 $ tar -xjf apktool-install-linux-r05-ibot.tar.bz2 

Далее просто сваливаем содержимое обоих архивов в каталог ~/bin и добавляем его в $PATH:

$ mv apktool.jar ~/bin $ mv apktool-install-linux-r05-ibot/* ~/bin $ export PATH=~/bin:$PATH 

Если же ты работаешь в Windows, то для нее есть превосходный инструмент под названиемVirtuous Ten Studio, который также аккумулирует в себе все эти инструменты (включая сам apktool), но вместо CLI-интерфейса предоставляет пользователю интуитивно понятный графический интерфейс, с помощью которого можно выполнять операции по распаковке, дизассемблированию и декомпиляции в несколько кликов. Инструмент этот Donation-ware, то есть иногда появляются окошки с предложением получить лицензию, но это, в конце концов, можно и потерпеть. Описывать его не имеет никакого смысла, потому что разобраться в интерфейсе можно за несколько минут. А вот apktool, вследствие его консольной природы, следует обсудить подробнее.

Рассмотрим опции 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, например:

$ apktool d mail.apk 

После этого в каталоге mail появятся все извлеченные и дизассемблированные файлы пакета.

Препарирование. Отключаем рекламу

Теория — это, конечно, хорошо, но зачем она нужна, если мы не знаем, что делать с распакованным пакетом? Попробуем применить теорию с пользой для себя, а именно модифицируем какую-нибудь софтину так, чтобы она не показывала нам рекламу. Для примера пусть это будет Virtual Torch — виртуальный факел. Для нас эта софтина подойдет идеально, потому что она под завязку набита раздражающей рекламой и к тому же достаточно проста, чтобы не потеряться в дебрях кода.

Итак, с помощью одного из приведенных способов скачай приложение из маркета. Если ты решил использовать Virtuous Ten Studio, просто открой APK-файл в приложении и распакуй его, для чего создай проект (File -> New project), затем в контекстном меню проекта выбери Import File. Если же твой выбор пал на apktool, то достаточно выполнить одну команду:

$ apktool d com.kauf.particle.virtualtorch.apk 

После этого в каталоге com.kauf.particle.virtualtorch появится файловое дерево, похожее на описанное в предыдущем разделе, но с дополнительным каталогом smali вместо dex-файлов и файлом apktool.yml. Первый содержит дизассемблированный код исполняемого dex-файла приложения, второй — служебную информацию, необходимую apktool для сборки пакета обратно.

Первое место, куда мы должны заглянуть, — это, конечно же, AndroidManifest.xml. И здесь мы сразу встречаем следующую строку:

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

$ apktool b com.kauf.particle.virtualtorch 

В каталоге com.kauf.particle.virtualtorch/build/ появится результирующий APK-файл. Однако установить его не получится, так как он не имеет цифровой подписи и контрольных сумм файлов (в нем просто нет каталога META-INF/). Мы должны подписать пакет с помощью утилиты apk-signer. Запустили. Интерфейс состоит из двух вкладок — на первой (Key Generator) создаем ключи, на второй (APK Signer) подписываем. Чтобы создать наш приватный ключ, заполняем следующие поля:

• Target File — выходной файл хранилища ключей; в нем обычно хранится одна пара ключей;
• Password и Confirm — пароль для хранилища;
• Alias — имя ключа в хранилище;
• Alias password и Confirm — пароль секретного ключа;
• Validity — срок действия (в годах). Значение по умолчанию оптимально.

Остальные поля, в общем-то, необязательны — но необходимо заполнить хотя бы одно.

WARNING

Чтобы подписать приложение с помощью apk-signer, ты должен установить Android SDK и указать полный путь до него в настройках приложения.

Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.

Теперь этим ключом можно подписать APK. На вкладке APK Signer выбираем только что сгенерированный файл, вводим пароль, алиас ключа и пароль к нему, затем находим файл APK и смело жмем кнопку «Sign». Если все пройдет нормально, пакет будет подписан.

INFO

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

Цифровая подпись необходима только стороннему софту, поэтому если ты занимаешься модификацией системных приложений, которые устанавливаются копированием в каталог /system/app/, то подписывать их не нужно.

После этого скидываем пакет на смартфон, устанавливаем и запускаем. Вуаля, реклама пропала! Вместо нее, однако, появилось сообщение, что у нас нет интернета или отсутствуют соответствующие разрешения. По идее, этого могло бы и хватить, но сообщение выглядит раздражающе, да и, если честно, нам просто повезло с тупым приложением. Нормально написанная софтина, скорее всего, уточнит свои полномочия или проверит наличие интернет-соединения и в противном случае просто откажется запускаться. Как быть в этом случае? Конечно, править код.

Обычно авторы приложений создают специальные классы для вывода рекламы и вызывают методы этих классов во время запуска приложения или одной из его «активностей» (упрощенно говоря, экранов приложения). Попробуем найти эти классы. Идем в каталог smali, далее com (в org лежит только открытая графическая библиотека cocos2d), далее kauf (именно туда, потому что это имя разработчика и там лежит весь его код) — и вот он, каталог marketing. Внутри находим кучу файлов с расширением smali. Это классы, и наиболее примечателен из них класс Ad.smali, по названию которого нетрудно догадаться, что именно он выводит рекламу.

Мы могли бы изменить логику его работы, но гораздо проще будет тупо убрать вызовы любых его методов из самого приложения. Поэтому выходим из каталога marketing и идем в соседний каталог particle, а затем в virtualtorch. Особого внимания здесь заслуживает файл MainActivity.smali. Это стандартный для Android класс, который создается Android SDK и устанавливается в качестве точки входа в приложение (аналог функции main в Си). Открываем файл на редактирование.

Внутри находится код smali (местный ассемблер). Он довольно запутанный и трудный для чтения в силу своей низкоуровневой природы, поэтому мы не будем его изучать, а просто найдем все упоминания класса Ad в коде и закомментируем их. Вбиваем строку «Ad» в поиске и попадаем на строку 25:

.field private ad:Lcom/kauf/marketing/Ad; 

Здесь создается поле ad для хранения объекта класса Ad. Комментируем с помощью установки знака ### перед строкой. Продолжаем поиск. Строка 423:

new-instance v3, Lcom/kauf/marketing/Ad; 

Здесь происходит создание объекта. Комментируем. Продолжаем поиск и находим в строках 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, условный переход на которую осуществляется аккурат перед созданием экземпляра класса:

if-ne p1, v0, :cond_10 .line 74 new-instance v0, Landroid/content/Intent; ... :cond_10 

Скорее всего, программа каким-то случайном образом вычисляет, нужно ли показывать рекламу на главном экране, и, если нет, перескакивает сразу на cond_10. Ок, упростим ей задачу и заменим условный переход на безусловный:

#if-ne p1, v0, :cond_10 goto :cond_10 

Больше упоминаний FirstAd в коде нет, поэтому закрываем файл и вновь собираем наш виртуальный факел с помощью apktool. Копируем на смартфон, устанавливаем, запускаем. Вуаля, вся реклама исчезла, с чем нас всех и поздравляем.

WWW

• Перевод приложений Android;
• пример снятия триала с приложения.

Итоги

Эта статья лишь краткое введение в методы вскрытия и модификации Android-приложений. За кадром остались многие вопросы, такие как снятие защиты, разбор обфусцированного кода, перевод и замена ресурсов приложения, а также модификация приложений, написанных с использованием Android NDK. Однако, имея базовые знания, разобраться во всем этом — лишь вопрос времени.

Тут вам покажем несколько способов инструментов, при помощи которых можно подписывать приложения Android перед публикацией их в Google App Play.

Подписка APK средствами IDE Android Studio

Вы можете использовать Android Studio для ручного создания подписанных APK, по одному за раз, или для нескольких вариантов сборки сразу. Вместо того, чтобы вручную подписывать APK, вы также можете настроить свои настройки сборки Gradle для автоматической обработки подписей во время процесса сборки. В этом разделе описывается процесс ручной подписи. Подробнее о подписании приложений как части процесса сборки см. В разделе Настройка процесса сборки для автоматической подписки APK.

Чтобы вручную подписать APK для выпуска в Android Studio, выполните следующие действия:

1. Жмем Build > Generate Signed APK и откроется окно Generate Signed APK . (Как создать ключи подписи в Android Studio мы писали в прошлой статье)
2. В окне Generate Signed APK Wizard выберите хранилище ключей, закрытый ключ и введите пароли для обоих. (Если вы только что создали хранилище ключей в предыдущем разделе, эти поля уже будут заполнены) Затем нажмите «Next» 
3. В следующем окне выберите пункт назначения для подписанных APK, выберите тип сборки (если применимо), выберите продукт (ы) и нажмите «Finish»

Когда процесс завершится, вы найдете свой подписанный APK в выбранной вами папке назначения. Теперь вы можете распространять подписанный APK через торговую площадку приложения, например, в Google Play Store, или использовать выбранный вами механизм распространения подписанного приложения конечным пользователям.

Чтобы пользователи могли успешно устанавливать обновления для вашего приложения, вам нужно будет подписать APK с тем же сертификатом на протяжении всего срока действия вашего приложения.

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

Есть сгенерированные ключи подписи или создаем?

Мы уже разбирали тут, как генерировать хранилище ключей с ключом подписи. Если кратко, то вы можете подписать свое приложение из командной строки с помощью инструмента apksigner или настроить Gradle для его подписки во время сборки. В любом случае вам нужно сначала сгенерировать закрытый ключ с помощью keytool. Например командой

Примечание: keytool находится в каталоге bin/ вашего JDK. Чтобы найти ваш JDK из Android Studio, выберите «File»> «Project Structure», а затем «SDK Location», и вы увидите местоположение JDK

В этом примере команды консоль еще запросит ввести пароли для хранилища ключей и ключа подписи и запросит заполнить поля Distinguished Name для вашего ключа. Затем он генерирует хранилище ключей в виде файла с именем my-release-key.jks, сохраняя его в текущем каталоге (вы можете перемещать его по своему усмотрению). Хранилище ключей содержит один ключ, действительный в течение 10 000 дней.

Теперь вы можете создать unsigned APK, т.е. построить конфигурацию release и подписать его вручную или вместо этого настроить Gradle для автоматического подписания APK.

Подписка APK средствами командной строки Android SDK

Инструмент apksigner, доступный в версии 24.0.3 и выше для Android SDK Build Tools, позволяет вам подписывать APK и подтверждать, что подпись APK будет проверена успешно на всех версиях платформы Android, поддерживаемых этими APK. В этом подразделе представлено краткое руководство по использованию инструмента и служит ссылкой для различных параметров командной строки, которые поддерживает инструмент

Примечание 1. если вы подписываете APK с помощью apksigner и вносите дальнейшие изменения в APK, подпись APK становится недействительной. Поэтому перед подписанием APK вы должны использовать такие инструменты, как zipalign.

Примечание 2. Чтобы использовать инструмент apksigner, вы должны иметь версию 24.0.3 или выше установленных инструментов Android SDK Build Tools. Вы можете обновить этот пакет с помощью диспетчера SDK.

1). Открываем командную строку и перемещаемся в корневую директорию —из Android Studio, выбираем View > Tool Windows > Terminal. Затем вызываем команду assembleRelease:

Это создает APK под именем module_name-unsigned.apk в папке project_name/module_name/build/outputs/apk/. APK будет неподписанным(unsigned) и невыровненным(unaligned), который на данный момент — он не может быть установлен до тех пор, пока не будет подписан вашим секретным ключом.

2). Align the unsigned APK using zipalign:

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

3). Подписываем APK своим личным ключом с помощью apksigner:

В этом примере выводится подписанный APK на my-app-release.apk после его подписания с закрытым ключом и сертификатом, который хранится в одном файле хранилища ключей: my-release-key.jks.

Инструмент apksigner поддерживает другие параметры подписки, включая подписание файла APK с использованием отдельного закрытого ключа и файлов сертификатов и подписку APK с использованием нескольких подписчиков. Для получения дополнительной информации см. ссылку apksigner.

4). Убеждаемся, что ваш APK подписан:

Пример подписки средствами Android SDK

Если вышеописанное вызывает трудности, то давайте сделаем некоторый простой пример генерации ключа командой keytool, выполнения операции zipalign и подписи командой apksigner.

Сначала строим релиз средствами Cordova и Android SDK

Команда keytool генерации ключа в консоли:

Операция zipalign в консоли:

Обратите внимание, что zipalign мы выполняем по прямому пути версии приложения, которая соответствует версии нашего разрабатываемого приложения.

Операция подписи apksigner:

Обратите внимание, что apksigner мы выполняем по прямому пути версии приложения и указываем путь к сгенерированному ключу, которая соответствует версии нашего разрабатываемого приложения. Далее, после нажатия Enter, консоль запросит поочередно запросить пароль от хранилища ключей и от самого ключа.

Подписка APK средствами командной строки JDK

Выше мы уже знакомились с инструментом keytool для создания хранилища ключей и самих ключей подписи в составе JDK, а в данной секции описано то, как средствами JDK подписывать этим ключом приложение и для этого есть специальный инструмент в составе JDK в той же папке, что и keytool — jarsigner.

Команда подписи с ее параметрами записывается так

Имена параметров нам знакомы по keytool:

• хранилище (keystore),
• пароль (storepass) к нему
• пароль (keypass) к ключу.
• А последние два параметра – это имя APK-файла, который вы хотите подписать и алиас ключа из указанного хранилища, который вы хотите использовать для подписи.

После данной команды приложение будет подписано и будет готово к установке на устройства или можно распространять через Google App Play.

Другие инструменты подписи

Пожалуй, сюда можно добавить такие инструменты, как:

• apk-signer — простой инструмент командной строки для подписи apk
• APK Signing Tool — этот инструмент с оконным интерфейсом позволяет вам подписать APK с вашим хранилищем ключей. Вы можете переопределить хранилище демо-версий и использовать свое собственное хранилище ключей перед загрузкой приложения в Google Play.
• APK Signer — инструмент с оконным интерфейсом упрощает создание файла хранилища ключей.

Android Studio предоставляет широкие возможности как для разработки приложений, так и для повышения автоматизации и комфортности при программировании.

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

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

Перед тем, как начать подписание приложения, вам необходимо в файле gradle.properties создать новое свойство. Назовём его Keys.repo и, в качестве значения, укажем путь до папки, где впоследствии будут находиться хранилище ключей и файл со свойствами (например, C:/Users/UserName/.signing).

Keys.repo=C:/Users/UserName/.signing

Затем нужно создать эту папку или, если вы указали существующую, открыть её. В ней необходимо создать файл YourProjectName.properties, внутри которого будут прописаны в качестве свойств путь до хранилища ключей, псевдоним ключа и пароль в следующем виде.

RELEASE_STORE_FILE=/YourProjectName/KeyStoreName.jks  RELEASE_STORE_PASS=******  RELEASE_ALIAS=KeyAlias  RELEASE_KEY_PASS=******

Как создать хранилище ключей?

Если у вас нет хранилища ключей, его можно легко создать с помощью Android Studio. Для этого нужно выбрать в меню пункт Build -> Generate Signed APK.

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

Затем нужно создать папку YourProjectName и перенести туда нужный файл хранилища ключей.

Теперь можно приступить непосредственно к процессу подписания. Для этого в вашем проекте нужно открыть файл build.gradle (расположенный в папке app). Внутри него в блоке android нужно добавить следующий код.

signingConfigs {    debug { /* здесь никаких изменений нет */ }    release {      if (project.hasProperty("Keys.repo")) {        def projectPropsFile = file(project.property("Keys.repo") + "/YourProjectName.properties")        if (projectPropsFile.exists()) {          Properties props = new Properties()          props.load(new FileInputStream(projectPropsFile))          storeFile file(file(project.property("Keys.repo") + props['RELEASE_STORE_FILE']))          storePassword props['RELEASE_STORE_PASS']          keyAlias props['RELEASE_ALIAS']          keyPassword props['RELEASE_KEY_PASS']        }      } else {          println "======================================================="          println "[ERROR] - Please configure release-compilation environment - e.g. in ~/.signing directory"          println "======================================================="      }    }  }

Какие бывают схемы получения подписи?

Существуют две схемы получения подписи APK: v1 JAR и v2 Full APK.

В первом случае подписывается JAR-файл, что является традиционным способом подписания. Подпись v1 не защищает некоторые части APK, такие как метаданные ZIP. Верификатор APK должен обрабатывать множество ненадёжных (ещё не проверенных) структур данных, а затем отбрасывать данные, которые не подписаны, что предоставляет большой простор для атаки. Кроме того, верификатор APK должен распаковать все сжатые записи, что тратит много времени и памяти. Чтобы решить эти проблемы, была разработана вторая схема v2 Full APK.

Схема v2 была представлена в Android 7.0 Nougat (API 25) и работает, начиная с версии Android Studio 2.2 и Android Gradle plugin 2.2. Эта схема обеспечивает более быструю установку приложения и хорошую защиту от несанкционированных изменений в APK. Содержимое APK хешируется и подписывается, затем полученный блок подписи APK вставляется в APK.

Во время проверки схема v2 рассматривает APK как blob и выполняет проверку подписи по всему файлу. Любая модификация APK, включая модификации метаданных ZIP, делает подпись недействительной. Эта форма проверки значительно быстрее и позволяет обнаружить больше несанкционированных модификаций.

Новый формат обратно совместим, поэтому APK, подписанные новой схемой, могут быть установлены на более ранних устройствах (которые будут просто игнорировать новую подпись), если эти APK также подписаны схемой v1.

По умолчанию при подписании используются обе схемы, чтобы приложения могли быть установлены на любых устройствах. Однако если есть такая необходимость, можно отключить подпись v1 или v2. Для этого в вышеприведённом коде в блоке release достаточно дописать следующие строки.

v1SigningEnabled false

или

v2SigningEnabled false

Важно также учитывать, что подписывать схемой v1 нужно до подписания схемой v2, поскольку APK не пройдёт проверку по схеме v2, если он будет подписан дополнительными сертификатами после подписания схемой v2.

После того, как код добавлен, укажите этот код в блоке buildTypes внутри release. Например:

buildTypes {    release {      minifyEnabled true      shrinkResources true      proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'      signingConfig signingConfigs.release    }  }

Теперь можно смело в пункте меню Build выбирать Build APK, предварительно сменив тип сборки с debug на release. Как видно, данный способ удобен тем, что он автоматический, его достаточно настроить лишь раз и ваши хранилища ключей могут быть в безопасности.