Чтобы загружать контент для продажи через приложения добавьте в apk файл разрешение billing
Иногда некоторые приложения на Android чем-то не устраивают пользователя. В качестве примера можно привести назойливую рекламу. А то бывает и так — всем хороша программа, да только перевод в ней или кривой, или вовсе отсутствует. Или, например, программа триальная, а получить полную версию возможности нет. Как же изменить ситуацию?
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:
Здесь происходит создание объекта. Комментируем. Продолжаем поиск и находим в строках 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;
- пример снятия триала с приложения.
Препарирование. Отключаем рекламу
Теория — это, конечно, хорошо, но зачем она нужна, если мы не знаем, что делать с распакованным пакетом? Попробуем применить теорию с пользой для себя, а именно модифицируем какую-нибудь софтину так, чтобы она не показывала нам рекламу. Для примера пусть это будет 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
Вскрываем подопытного
Теперь нам нужно найти приложение, которое, во-первых, нетрудно расковырять, а во-вторых, которое несет какую-то пользу и достаточно известно. То есть брать простейшую софтину только для того, чтобы было не очень сложно разобраться в ее коде, мы не будем, а вместо этого устремим свой взор на топ Play Store. Практически идеальный кандидат на эту роль — выпущенный два месяца назад ASAP Launcher, удобнейший домашний экран с массой полезных и неординарных функций.
Другие статьи в выпуске:
Для удобства переименуем пакет в asap.apk:
Разархивируем с помощью unzip:
Да, APK — это обычный архив ZIP, но тем не менее он имеет четкую структуру:
- META-INF — каталог, содержащий файлы MANIFEST.MF, CERT.MF и CERT.RSA. Первые два — список всех файлов пакета и их контрольных сумм, последний содержит открытый ключ разработчика и созданную с помощью закрытого ключа цифровую подпись файла CERT.MF. Эти данные нужны, чтобы при установке пакета система смогла выяснить, что пакет не был модифицирован и действительно создан его автором. Это важно, так как, поскольку нет возможности подделать цифровую подпись пакета (для этого нужен закрытый ключ), модифицированный пакет придется подписывать другим ключом;
- res — ресурсы приложения. Здесь находятся иконка (mipmap), переводы строк (values), изображения (drawable), а также описания интерфейса приложения (layout). Все их можно модифицировать, чтобы изменить внешний вид приложения. Правда, файлы XML придется сначала «разжать» — для улучшения производительности они хранятся в бинарном формате;
- classes.dex — код приложения в форме байт-кода виртуальной машины Dalvik. Обычно приложения содержат только один такой файл, но, используя директиву multiDex, разработчик может заставить среду разработки разбить его на множество более мелких для улучшения производительности или преодоления ограничения на 65 536 методов в одном dex-файле;
- AndroidManifest.xml — манифест приложения, описывающий его структуру, включая активности, сервисы, обработчики интентов и так далее. Опять же в формате бинарного XML.
Также пакет может содержать другие каталоги, например assets (любые файлы, включенные разработчиком, в данном случае — шрифты и база данных) и lib (нативные библиотеки, созданные с использованием Android NDK).
Изучаем код
Само собой разумеется, просто разархивировать пакет недостаточно. Чтобы разобраться в работе приложения, необходимо декомпилировать файл classes.dex.
Для этого мы воспользуемся jadx-gui. Запускаем, выбираем asap.apk и видим слева список пакетов Java, включенных в APK. В данном случае это пакеты android.support — официальная библиотека Google, реализующая поддержку функций новых версий Android в старых (например, чтобы получить Material Design в Android 4.1), com.google.android.gms — Google Mobile Services, com.nispok.snakbar — реализация GUI-элемента snakbar, а также несколько других.
Основной код приложения содержится в пакете com.citc.asap, именно такое имя носит и само приложение в Google Store и на устройстве. Открываем его и видим больше десятка каталогов и множество исходников Java. Наша задача — сделать приложение «оплаченным», не платя за него. Но как найти нужный файл, реализующий проверку на оплату? Скорее всего, он будет содержать в имени слово billing. Пробегаемся по исходникам в поисках нужного нам файла и натыкаемся на исходник BaseBillingFragment в подкаталоге (пакете) fragments:
Это очень простой класс Java, в котором есть интересный метод:
Все, что он делает, — просто возвращает значение поля mHasPrime, однако интересен он не этим, а своим именем. Дело в том, что платная (точнее, оплаченная) версия ASAP называется Prime, и очевидно, что метод hasPrime как раз и нужен для проверки оплаты приложения. Чтобы подтвердить свою догадку, сохраним декомпилированные исходники (File -> Save all) в каталог и попробуем найти в них вызовы hasPrime():
Совпадений немного, основной «пользователь» hasPrime() — это SettingsFragment, то есть исходник, отвечающий за формирование окна настроек. Учитывая, что Prime-версия отличается от бесплатной именно тем, что в ней разблокированы дополнительные поля настроек, уже сейчас мы можем быть на 90% уверены, что hasPrime() — нужный нам метод. Скорее всего, именно с его помощью приложение выясняет, куплена ли Prime-версия. Осталось только убедиться в этом окончательно, подменив код метода на свой.
Итоги
Эта статья лишь краткое введение в методы вскрытия и модификации Android-приложений. За кадром остались многие вопросы, такие как снятие защиты, разбор обфусцированного кода, перевод и замена ресурсов приложения, а также модификация приложений, написанных с использованием Android NDK. Однако, имея базовые знания, разобраться во всем этом — лишь вопрос времени.
Checkout («касса», «кассовый аппарат») — это библиотека для совершения покупок внутри приложений на базе Android In-App Billing v.3. Основная цель — уменьшить время разработчика, затрачиваемое на внедрение платежей в Андроид приложения. Проект был вдохновлён библиотекой Volley, и проектировался для того, чтобы быть максимально простым в использовании, быстрым и гибким.
- Загрузить исходный код из github репозитория и скопировать его в свой проект
- Для пользователей Maven использовать следующую зависимость:
- Для пользователей Gradle использовать следующую зависимость:
- Загрузить нужный архив из репозитория
Библиотека требует com.android.vending.BILLING разрешение (permission).
Если вы подключили библиотеку как зависимость (например, в Maven или Gradle), то дополнительно делать ничего не надо. В противном случае, нужно добавить следующую строчку в AndroidManifest.xml:
Библиотека содержит 3 основных класса: Billing, Checkout и Inventory.
Класс Billing обрабатывает запросы на покупку (см. методы IInAppBillingService.aidl) и управляет подкючением к сервису Google Play. Этот класс лучше всего использовать как синглтон, для того чтобы все запросы выстраивались в одну очередь и использовали один кеш. Например, класс приложения может выглядеть следующим образом:
Исходный код доступен в моём репозитории на github. Там же вы найдёте исходный код тестового приложения (само приложение может быть установлено из Google Play). Всё под лицензией Apache License, Version 2.0.
В библиотеке есть над чем работать (например, не хватает покрытия тестами, и было бы неплохо иметь процедуру миграции из одной популярной библиотеки). Но в целом, ей уже можно пользоваться в продакшене, что я и делаю в своём приложении Say it right!.
Вопросы и пожелания приветствуются в комментариях к статье, а также в багтрекере на гитхабе.
UPD Для библиотеки есть тестовое приложение в Google Play. Для того чтобы совершать тестовые платежи нужно вступить в эту Google+ группу.
На недавно прошедшей Google I/O 2018, среди множества нововведений, объявили также о добавлении нового формата приложений.
Этот формат получил название Android App Bundle и представляет собой улучшенный способ сборки вашего приложения. С его помощью можно легко оптимизировать размер приложения, при этом не нужно будет вносить какие-либо изменения в код. Android App Bundle включает весь скомпилированный код и ресурсы, отсеивая затем то, что не нужно конкретному устройству.
Важно! На данный момент Android App Bundle работает только в preview-версии Android Studio. Последняя версия Android Studio 3.2 Canary доступна здесь.
Android App Bundle представляет собой файл (с расширением .aab), который загружается в Google. Каждый бандл включает скомпилированный код и ресурсы для всех модулей приложения и поддерживаемых конфигураций устройств.
Проще говоря, бандлы это подписанные ZIP-файлы, которые упорядочивают код и ресурсы приложения в модули.
Из этих модулей Google Play генерирует различные APK, которые предоставляются пользователям, такие как: базовые APK, dynamic feature APK, конфигурационные APK и (для устройств, которые не поддерживают разделённые APK) мульти-APK. Каталоги, окрашенные в синий цвет, представляют собой код и ресурсы, которые Google Play использует для создания конфигурационного APK для каждого модуля.
Примечание: бандл нужно создавать для каждого уникального приложения или applicationID. То есть, если вы используете несколько product flavor в своём приложении для создания различных APK, и каждая из этих веток использует уникальный applicationID, то вам нужно будет создать отдельный бандл для каждой ветки.
Код и ресурсы для каждого модуля организованы аналогично стандартным APK, и это логично, поскольку каждый из этих модулей может быть сгенерирован как отдельный APK. Ниже можно увидеть более подробное описание некоторых файлов и каталогов Android App Bundle:
- base/, feature1/, feature2/. Каждый из этих каталогов представляет собой модуль приложения. Базовый модуль приложения всегда содержится в базовом каталоге бандла. Директории же с дополнительными особенностями, каждой из которых присваивается специальное имя, находятся отдельно.
- файлы Protocol Buffer (.pb). Эти файлы содержат метаданные, которые помогают описать содержимое бандла в магазинах приложений. Например, BundleConfig.pb, находящийся в корневом каталоге бандла, предоставляет информацию о самом бандле, например, какая версия build tools используется для сборки. Другие файлы, такие как recourse.pb и native.pb, описывают, как определённый код и ресурсы должны использоваться для различных конфигураций устройств. Google Play использует эту информацию для генерации APK, оптимизированного для устройства пользователя.
- manifest/. В отличие от APK, бандлы хранят файл AndroidManifest.xml каждого модуля в отдельном каталоге.
- dex/. В отличие от APK, бандлы хранят DEX-файлы каждого модуля в отдельном каталоге.
- root/. Этот каталог хранит файлы, которые позже перемещаются в директорию root любого APK, который включает в себя модуль, в котором находится этот каталог. Например, каталог base/root/ бандла может включать ресурсы Java, которые загружаются приложением с помощью использования Class.getResources(). Эти файлы позже перемещаются в директорию root APK приложения и каждого мульти-APK, которые генерирует Google Play. Пути в этом каталоге также сохраняются, то есть, подкаталоги тоже перемещаются вместе с root.
Примечание: если содержимое этого каталога конфликтует с другими файлами и каталогами в корне APK, Play Console отклонит загрузку бандла. Например, вы не сможете включить каталог root/lib/, поскольку он будет конфликтовать с каталогом lib, уже находящимся в APK. - res/, lib/, assets/. Эти каталоги идентичны тем, что используются в стандартном APK. При загрузке приложения, Google Play проверяет в этих каталогах и пакетах только те файлы, которые соответствуют конфигурации целевого устройства.
Создание бандла с помощью Android Studio очень похоже на создание APK. Для сборки достаточно выбрать в меню Build — Build Bundle(s)/APK(s) > Build Bundle(s) и IDE создаст бандл для выбранного варианта сборки и разместит его в каталоге //build/outputs/bundle/.
Если создаётся бандл для debug-версии приложения, Android Studio автоматически подпишет бандл с помощью отладочного ключа подписи. Для загрузки бандла в Google Play он должен быть подписан.
После того, как Android Studio завершит создание подписанного бандла, его можно будет открыть и проанализировать. Анализ бандла позволяет проверить содержимое и работает аналогично APK Analyzer.
Для создания App Bundle IDE использует тот же инструмент с открытыми исходным кодом, называемый bundletool, который Google Play использует для последующего преобразования бандла в подписанные APK.
Прежде чем загрузить бандл в консоль Google Play, его нужно подписать. Чтобы создать подписанный App Bundle, нужно выполнить следующие действия:
- Выбрать в меню Build — Generate Signed Bundle/APK.
- В появившемся диалоге выбрать Android App Bundle и нажать Next.
- В выпадающем списке выбрать модуль, для которого требуется создать бандл, после чего нажать Next.
- Предоставить информацию о созданном ключе подписи либо создание нового ключа подписи. Вы можете использовать те же ключи, которые используете для генерации подписи APK.
- Если вы хотите, чтобы Android Studio также сохранила ключ подписи в виде зашифрованного файла, то нужно поставить флажок Export encrypted key. Чтобы иметь возможность загружать бандл, необходимо также загрузить этот зашифрованный файл в консоль Google Play и зарегистрировать подписку приложения с помощью Google Play.
- Нажать Next.
- Выбрать папку назначения для бандла, тип сборки и product flavor проекта.
- Нажать Finish.
После того, как Android Studio завершит создание подписанного бандла, его можно будет найти и проанализировать, выбрав соответствующую опцию во всплывающем уведомлении. Если был выбран экспорт ключа подписи, то к нему можно будет быстро перейти, щёлкнув по стрелке вниз в правом нижнем углу всплывающего уведомления, чтобы развернуть его, и затем выбрав Show Exported Key File.
После того, как бандл создан, его можно загрузить в Google Play для проверки, тестирования или публикации приложения. Прежде чем приступить к работе, следует соблюсти следующие условия:
- Зарегистрироваться в программе Google Play App Signing.
- Если приложение включает dynamic feature modules, то его можно загружать и тестировать через внутренний тестовый трек консоли Google Play. Однако чтобы опубликовать приложение, нужно принять программу Dynamic Feature, которая на данный момент находится в стадии бета-версии.
- Google Play поддерживает загрузку приложений размером не более 100 МБ.
Снаряжаемся
Для выполнения описанных в статье действий понадобится ряд инструментов, и главный инструмент — это Linux. Да, многие из названных далее программ могут работать и в Windows, но в любых операциях, связанных с Android и его приложениями, лучше не полагаться на детище Билли. В Linux практически все сделать проще, командная строка здесь в разы удобнее (она нам ох как понадобится), а некоторые инструменты просто недоступны для других ОС.
После установки Linux в виртуалку или второй системой сразу устанавливаем средства разработки на Java и виртуальную машину. В Ubuntu это можно сделать с помощью одной команды:
Также нам нужны четыре инструмента для распаковки и декомпиляции приложений:
-
— швейцарский армейский нож для распаковки и запаковки приложений; — декомпилятор байт-кода Dalvik в код на Java; — дизассемблер кода Dalvik (не пугайся, с настоящим ассемблером он имеет мало общего); — утилита для подписи пакетов.
Для удобства создадим в домашнем каталоге подкаталог Android и скачаем эти инструменты в него:
Добавим в конец файла ~/.bashrc следующие строки:
Они нужны для того, чтобы вместо длинных и неудобных команд вроде java -jar ~/Android/sign.jar можно было набрать просто sign.
Выводы
Взломать приложение для Android очень и очень просто. Да, я не спорю, нам попался удобный и простой пример для модификации, но опять же повторюсь — это весьма популярное приложение, о котором рассказывали на большинстве сайтов, посвященных Android.
Большинство других приложений вскрыть так же просто, однако есть достаточное количество экземпляров, пропущенных через обфускаторы и различные системы защиты. С ними все несколько сложнее, и таким приложениям будет посвящена третья статья цикла. Во второй статье мы рассмотрим, как тот же самый метод модификации использовать для внедрения собственного кода.
Устройство 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 и, соответственно, работать будет хоть в винде, хоть в никсах.
Настройка Real APK Leecher
Другие статьи в выпуске:
Просмотр и модификация
Допустим, ты нашел интересующий тебя пакет, скачал, распаковал… и при попытке просмотра какого-нибудь XML-файла с удивлением обнаружил, что файл не текстовый. Чем же его декомпилировать и как вообще работать с пакетами? Неужели необходимо ставить SDK? Нет, SDK ставить вовсе не обязательно. На самом деле для всех шагов по распаковке, модификации и упаковке пакетов APK нужны следующие инструменты:
Использовать все эти инструменты можно и по отдельности, но это неудобно, поэтому лучше воспользоваться более высокоуровневым софтом, построенным на их основе. Если ты работаешь в 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 появятся все извлеченные и дизассемблированные файлы пакета.
Как добавить In-app Billing в приложение : 6 комментариев
А физ. лицо может зарегистрировать Google Wallet? Или нужно ИП открывать?
Может, в этом плене Google очень демократичная компания. Выплаты начнутся по достижении порога в 100$
А как тестировать покупки? Я прописал в play console тестового пользователя и через него покупаю например рекламу. Деньги не списываются но покупка числиться у него в google play.
Но в классе InventoryCallback mPurchases = 0.
Как правильно тестировать?
Здравствуйте! К сожалению, насчёт тестирования не получится что-либо подсказать, попробуйте написать автору библиотеки на гитхабе.
Ни один разговор о взломе и модификации приложений не обходится без упоминания дизассемблера, дебаггера, формата исполняемых файлов и вездесущей IDA Pro. Однако в случае с Android все намного проще, и здесь для вскрытия и даже внедрения кода в приложение совсем не обязательно использовать все эти инструменты. Код можно легко декомпилировать обратно в Java и модифицировать, используя пару простых инструментов и текстовый редактор.
Этой статьей мы начинаем цикл, посвященный вскрытию и модификации приложений для Android. Первая часть — вводная, поэтому никакого хардкора: мы разберемся в устройстве пакетов APK, научимся разбирать APK на части, декомпилировать его код, вносить правки и собирать обратно, и в качестве примера взломаем одно популярное приложение из маркета. Вторая статья будет целиком посвящена внедрению бэкдора/вируса в чужое приложение. Это уже не просто правка нескольких строк, а глубокая модификация. Третья статья — методы обфускации и их обхода. Все больше разработчиков используют нетривиальную обфускацию, чтобы осложнить жизнь реверсерам. Мы распутаем их код и опять же внесем правки в приложение.
Обновление приложения
После загрузки приложения в Play Console, для обновления приложения достаточно повысить код версии, а также создать и загрузить новый бандл. Затем Google Play сгенерирует обновлённые APK с новым кодом версии и будет предоставлять их по мере необходимости.
Использование Android App Bundle даёт большие преимущества для оптимизации APK приложений. С помощью этого способа мы обновили одно из наших приложений, «Менеджер паролей от Wi-Fi сетей«, заменив в нём стандартный APK на App Bundle. Таким образом, размер APK файлов уменьшился на целый мегабайт, что является очень хорошим результатом.
Кроме того, Google на данный момент тестирует дополнение к App Bundle, Dynamic feature modules, с помощью которого можно разбивать базовый APK на части, которые будут докачиваться при необходимости, пока что эта технология находится в бета-версии.
Возможно, единственным недостатком банлдов на данный момент назвать необходимость использовать preview-версию Android Studio, однако эта проблема временная.
Рано или поздно наступает момент, когда разработчику нужно задуматься о том, как монетизировать своё приложение, чтобы оно приносило доход. Есть различные бизнес-модели, с помощью которых можно этого достичь, однако наиболее популярной является использование рекламы в приложении. Одним из плюсов использования рекламы является то, что она хорошо сочетается с другой бизнес-моделью — покупками внутри приложения. Например, пользователь может заплатить некоторую сумму денег для того, чтобы отключить показ рекламы в приложении.
В этой статье мы рассмотрим, как можно реализовать встроенные покупки на примере своего приложения Менеджер паролей от Wi-Fi сетей.
Возможность покупок в приложениях реализована благодаря In-app Billing. In-app Billing — это сервис Google Play, который позволяет продавать цифровой контент внутри приложений. Этот сервис можно использовать для продажи широкого спектра контента, включая загружаемый контент, такой как мультимедийные файлы и фотографии, виртуальный контент, такой как уровни игры или различные вспомогательные предметы, премиальные услуги и многое другое.
Встроенные покупки можно подключить для любого приложения, опубликованного в Google Play. Ничего особенного для этого не требуется, только аккаунт разработчика Google Play Console и аккаунт продавца Google Wallet. Android SDK также содержит пример приложения с реализованными встроенными покупками.
Ваше приложение обращается к сервису In-app Billing с помощью API, который предоставляется приложением Google Play, установленным на устройстве. Затем Google Play передает платежные запросы и ответы на запросы между вашим приложением и сервером Google Play. Таким образом, ваше приложение никогда напрямую не связывается с сервером Google Play. Вместо этого ваше приложение отправляет запросы в приложение Google Play через межпроцессную связь (IPC) и получает от него ответы, нет необходимости поддерживать какие-либо соединения между вашим приложением и сервером Google Play.
In-app Billing поддерживает широкую совместимость, он работает на устройствах под управлением Android 2.2 (API 8) или выше, на которых установлена последняя версия приложения Google Play.
API In-app Billing предоставляет следующие возможности:
- Ваше приложение отправляет запросы с помощью модернизированного API, который позволяет пользователям легко запрашивать информацию о продукте из Google Play и заказывать продукты в приложении. API быстро восстанавливает продукты на основе прав пользователя.
- API синхронно передает информацию о заказе на устройство при завершении покупки.
- Все покупки регулируемы, т.е. Google Play отслеживает права пользователя на продукты. Пользователь не может владеть несколькими экземплярами одного продукта в приложении; только один экземпляр может принадлежать пользователю в любой момент времени.
- Приобретённые продукты могут быть использованы. В таком случае они возвращаются в бесхозное состояние и могут быть куплены снова.
- API обеспечивает поддержку подписки.
Есть разные способы, как встроить в своё приложение In-app Billing: можно это делать как вручную, так и используя сторонние библиотеки. Одной из таких библиотек является Checkout, которая уже содержит в себе готовую к применению реализацию сервиса. Ею и воспользуемся.
Checkout — это реализация In-app Billing API. Большим плюсом здесь является, что с помощью этой библиотеки можно сделать интеграцию встроенных покупок в приложение намного проще, чем если бы это делалось вручную с нуля.
Checkout решает общие проблемы, с которыми могут столкнуться разработчики при работе с покупками, например:
- Как отменить все запросы, когда активность уничтожена?
- Как запросить информацию о покупках в фоновом потоке?
- Как проверить покупку?
- Как загрузить все покупки с использованием данных continuationToken или SKU (уникальный идентификатор продукта)?
- Как добавить покупки с минимумом шаблонного кода?
Checkout может быть использован с любым фреймворком или без него. Он имеет четкое разграничение функциональности, доступной в разных контекстах: покупки могут быть сделаны только в активности, тогда как SKU может быть загружен в сервис или класс Application.
Перед началом работы библиотеку нужно добавить в проект. Для этого в файле build.gradle модуля приложения добавить зависимость в блок dependencies.
Для работы с покупками требуется специальное разрешение com.android.vending.BILLING, которое будет добавлено в AndroidManifest.xml автоматически с помощью Gradle. Вы также можете добавить его вручную, добавив в файл манифеста следующую строчку перед элементом :
Создадим экземпляр класса Billing в Application, откуда затем будем брать его при необходимости. Если у вас нет класса Application в проекте, вы можете легко создать его. Для этого нужно добавить в файле AndroidManifest.xml в элемент атрибут android:name=».Имя класса», например:
После этого нужно поставить курсор на имя класса, нажать Alt + Enter и выбрать опцию «Create class», после чего Android Studio создаст его.
В этом классе нам нужно добавить следующий код:
BASE64_PUBLIC_KEY это ключ, который используется для установления безопасного подключения между вашим приложением и сервером Google Play. Получить этот ключ вы можете в Google Play Console, перейдя в раздел «Инструменты разработки» — «Службы и API». Там в «Лицензирование и продажа контента» вы увидите сгенерированный для вашего приложения ключ, который нужно будет добавить в приложение, например, объявить как строковую константу в классе Application.
Класс Billing это основной класс для работы с библиотекой, он отвечает за:
- подключение и отключение услуг биллинга;
- выполнение платежных запросов;
- кеширование результатов запросов;
- создание объектов Checkout;
- логирование;
Для того, чтобы избежать множественных подключений к службе In-app Billing, следует использовать только один экземпляр класса Billing, именно по этой причине мы и создаём его в классе Application.
Теперь в классе активности при её создании инициализируем экземпляр класса ActivityCheckout, который наследует от базового класса Checkout.
Класс Checkout это средний уровень библиотеки, он использует класс Billing в определённом контексте (в Application, активности или сервисе), проверяет, поддерживаются ли покупки на устройстве и выполняет запросы. ActivityCheckout это подкласс, который способен покупать различные предметы, для создания его экземпляра нужно вызвать метод Checkout.forActivity() и передать в параметры активность и экземпляр Billing.
Метод start() запускает созданный экземпляр и отправляет запрос, который проверяет, поддерживается ли биллинг на этом устройстве.
Метод createPurchaseFlow() создаёт постоянный поток для покупок со слушателем, который будет получать обновления данных о покупках. Код слушателя выглядит следующим образом:
Класс PurchaseListener наследует от EmptyRequestLisneter , который имеет методы onSuccess() и onError(). В данном случае, если пользователь купит отключение рекламы или сделает пожертвование, то слушатель получит данные о покупке и выполнит нужные операции.
Теперь нужно создать экземпляр класса Invertory.
Класс Invertory загружает данные о продуктах, SKU и покупках. Его жизненный цикл связан с жизненным циклом Checkout, в котором он был создан.
Метод makeInvertory() создаёт экземпляр Invertory и привязывает его к нужному объекту Checkout.
Метод load() отправляет запрос на получение данных о продуктах и асинхронно загружает результат в callback. В параметрах формируется запрос, какие именно продукты нужно получить (в данном случае, все имеющиеся, а именно донаты и отключение рекламы). Код коллбека, который принимает результат запроса, представлен ниже:
Метод onLoaded() вызывается, когда все данные загружены. В нём проверяются различные данные о продуктах. Например, можно проверить с помощью поля supported можно проверить, поддерживается ли продукт, а метод getSku() возвращает идентификатор продукта. Если нужно узнать стоимость продукта на основе локали устройства, то следует вызывать getSku(TYPE).price.
Метод isPurchased() проверяет, был ли продукт куплен пользователем. В случае с рекламой это будет означать, что её следует отключать.
Теперь нужно отправлять платёжные запросы сервису. Для этого в настройках приложения есть две кнопки «Удалить рекламу» и «Поддержать проект материально».
Обработка кнопки отключения рекламы выглядит следующим образом:
С помощью данного метода формируется запрос на покупку продукта, результат которого будет получен коллбеком.
Аналогичным образом формируется запрос на донат.
Таким образом, с помощью библиотеки мы реализовали встроенные покупки в приложении без использования шаблонного кода.
Анализ APK с помощью проводника
Когда бандл загружен, Google Play автоматически генерирует разделённые APK и мульти-APK для всех конфигураций устройств, поддерживаемых приложением. В Play Console можно можно использовать App Bundle Explorer для просмотра всех вариантов APK, сгенерированных Google Play; анализа данных, таких как поддерживаемые устройства и экономия размера APK; загрузки созданных APK для тестирования.
WARNING
Это ознакомительная статья, призванная всего лишь показать процесс взлома приложений. Она не призывает тебя заниматься варезом и лишать доходов людей, потративших многие недели на создание приложений. ASAP Launcher — великолепное приложение без навязчивой рекламы, почти вся полезная функциональность доступна бесплатно. Поэтому вместо того, чтобы использовать крякнутую версию, лучше купи полное приложение и поддержи разработчика. Оно обойдется тебе всего в 100 рублей.
Введение
В этой статье мы поговорим о том, как разобрать пакет APK с приложением, рассмотрим его внутреннюю структуру, дизассемблируем и декомпилируем байт-код, а также попробуем внести в приложения несколько изменений, которые могут принести нам ту или иную выгоду.
Чтобы сделать все это самостоятельно, потребуются хотя бы начальные знания языка Java, на котором пишутся приложения для Android, и языка XML, который используется в Android повсеместно — от описания самого приложения и его прав доступа до хранения строк, которые будут выведены на экран. Также понадобится умение обращаться со специализированным консольным софтом.
Итак, что же представляет собой пакет APK, в котором распространяется абсолютно весь софт для Android?
Вносим правки
Метод hasPrime() очень прост: он возвращает значение поля mHasPrime, которое имеет тип boolean. Нетрудно предположить, что в случае, если приложение оплачено, hasPrime() вернет true, иначе вернет false. Наша задача — сделать так, чтобы метод всегда возвращал true и остальная часть приложения думала, что приложение оплачено, и разблокировала дополнительные опции в окне настроек.
К сожалению, сделать это с помощью прямой правки исходного кода не получится: приложение нельзя скомпилировать обратно. Однако никто не запрещает дизассемблировать код, внести правки и собрать его вновь. И как раз здесь нам понадобится apktool. Дизассемблируем APK:
В текущем каталоге появится подкаталог asap. Открываем файл asap/smali/com/citc/asap/fragments/BaseBillingFragment.smali и находим hasPrime() . Декларация метода будет выглядеть так:
Это и есть дизассемблированный листинг, и, как ты видишь, он на порядок проще, чем дизассемблированный код нативных приложений. В целом здесь все тривиально:
- .method protected hasPrime()Z — объявляет protected-метод, который возвращает значение типа boolean (Z);
- .locals 1 — говорит виртуальной машине, что метод использует в своей работе один регистр (в данном случае он будет содержать возвращаемое значение);
- .prologue и .line 167 — директивы, необходимые для отладки, на ход исполнения не влияют;
- iget-boolean v0, p0 . — получает значение поля типа boolean и записывает в регистр v0, регистр p0 — это нулевой параметр, он всегда равен имени класса (this);
- return v0 — возвращает значение регистра v0;
- .end method — закрывает тело метода.
Теперь мы должны изменить данный метод так, чтобы он возвращал true независимо от значения поля mHasPrime . Мы могли бы сделать это вручную, но проще написать новый метод на Java:
И пропустить его через компилятор и дизассемблер:
На выходе получаем следующий ассемблерный код:
Ты уже должен сам догадаться, что он объявляет константу v0 со значением 1 и возвращает ее (в Dalvik тип boolean — это int, который может иметь значение 1 — true или 0 — false). Осталось только вставить этот код вместо оригинального и собрать пакет обратно:
Пакет появится в каталоге asap/dist . Переименуем его, чтобы не запутаться:
И подпишем с помощью тестового ключа:
В результате в текущем каталоге появится файл asap-fake-hasPrime.s.apk. Остается только закинуть его на карту памяти и установить, удалив перед этим оригинальное приложение.
Евгений Зобнин
Редактор рубрики X-Mobile. По совместительству сисадмин. Большой фанат Linux, Plan 9, гаджетов и древних видеоигр.
Декомпиляция приложений
В статье мы работали только с дизассемблированным кодом приложения, однако если в большие приложения вносить более серьезные изменения, разобраться в коде smali будет гораздо сложнее. К счастью, мы можем декомпилировать код dex в Java-код, который будет хоть и не оригинальным и не компилируемым обратно, но гораздо более легким для чтения и понимания логики работы приложения. Чтобы сделать это, нам понадобятся два инструмента:
Использовать их следует так. Сначала запускаем dex2jar, указывая в качестве аргумента путь до apk-пакета:
В результате в текущем каталоге появится Java-пакет mail.jar, который уже можно открыть в jd-gui для просмотра Java-кода.
Читайте также: