Программа для переделки игр на андроид
Вот и у меня появилась задача модифицировать приложение имея всего лишь его apk. И те, кто занимался декомпиляцией приложений знают насколько тяжело его потом скомпилировать.
Декомпиляция
-
для декомпиляции ресурсов. для преобразования dex в jar. для получения исходников из jar.
- еще рекомендую JAD, некоторые места лучше декомпилирует чем JD-GUI.
Если попробовать собрать приложение после декомпиляции, то скорее всего оно не скомпилируется из-за ошибок, особо тяжело декомпилируются циклы и условия. Некоторые ошибки легко исправляются, но опять же разобраться во множестве условных переходов будет не просто, а когда их количество более ста или даже несколько тысяч, то такой способ восстановить приложение теряет эффективность, быстрее написать все заново.
На этом можно было и закончить эксперименты с декомпиляцией, но лень двигатель прогресса и родился новый способ.
Переопределение классов
Итак, jar это библиотека, так почему бы просто не подключить ее к новому проекту? Кидаем ее в папку libs, наследуемся от главной активити и компилируем. Все работает, главное чтоб не совпадали имена классов, поэтому названия пакетов должно отличаться иначе как минимум совпадут сгенерированные BuildConfig и R.
Таким способом можно отнаследоваться от Activity, Service, BroadcastReceiver и, возможно, некоторых других классов объявляемых в манифесте, так же в манифесте нужно будет указать новые имена классов, иначе они не будут использоваться.
Теперь можно переопределить виртуальные функции, но и только, тем более ключевое слово final не позволит это сделать и отнаследоваться тоже, поэтому идем дальше.
Замена классов
Разархивировав jar библиотеку получим class файлы, это скомпилированные классы, заметим, что при сборке проекта в папке bin/classes лежат те же class файлы, а что если подсунуть туда файлы из библиотеки…
Не все так просто, для начала нужно скомпилировать проект. Чтобы использовать классы исходного приложения нужно его как-то присоединить к проекту, но при этом не экспортировать. Делается это просто: из папки libs Эклипс сам экспортирует библиотеки, поэтому перемещаем jar библиотеку в папку lib и подключаем к проекту, в Эклипсе это Project->Preferences->Java Build Path->Libraries->Add Jars… далее во вкладке Order and Export нужно убедиться, что не установлен чекбокс, потому что экспортировать библиотеку нам не нужно, все будет в class файлах.
Теперь берем какой-нибудь класс из декомпилированных исходников приложения, исправляем в нем ошибки компиляции, добавляем, например, показ диалога, чтоб убедиться, что используется именно новый класс. Далее очищаем проект, в Эклипсе это Project->Clean, копируем class файлы в папку bin/classes, собираем проект и все работает!
При следующих сборках проекта нет необходимости его очищать, так что использовать такой способ достаточно удобно. Для облегчения исправления ошибок после декомпиляции я использовал исходники полученные из JD-GUI и JAD, обычно этого было достаточно.
Но вот пришло время собрать релизную версию, а для нее, конечно же, используется обфускатор и выдаст он сотни ошибок на совпадения имен классов и неразрешенные ссылки. Вот теперь пора убрать из скомпилированных class файлов классы, которые были заменены, после этого ошибок не должно быть. Еще одна неприятная особенность сборки релиза — нужно каждый раз очищать проект и копировать class файлы, а то они куда-то пропадают.
Заключение
Таким способом декомпилируются только модифицируемые файлы, что избавляет от исправления ошибок во всех исходниках и улучшает надежность, так как всего часть кода подвергнется процессу декомпиляции — исправления — компиляции.
С большой вероятностью не получится скрыть все следы от оригинального приложения, названия необфусцированных классов таких как Activity и Service, а так же названия их пакетов сохранятся и будут доступны после декомпиляции модифицированного приложения, но для пиратских версий это не проблема, из-за чего стоит защищать приложение, способы защиты аналогичны другим способам защиты от изменения кода.
Обновление классов в jar — идея замены классов пришла из этой возможности для jar библиотеки.
Создание игры процесс захватывающий и познавательный. Особенно это заметно, когда ремейк «классики» делаешь сам, руководствуясь идеями оригинала и десятками часов, потраченных на прохождение кампании. У меня не было сколь-нибудь значимого опыта разработки для Android'a, поэтому создание работающего «как надо» приложения для планшета поначалу выглядело довольно туманно, но от этого не менее притягательно. При наличии времени и возможностей, можно стряхнуть пыль со старых игр, подмазать и подклеить, добавив поддержку «больших» разрешений и окажется, что они выглядят не хуже современных продуктов, выложенных на маркете, даже с палитрой RGB565 без альфа-канала. Я предполагал, что будут подводные камни и заботливо спрятанные грабли, которые лежат тихонько во время разработки, но больно лупят по голове, стоит запустить игру на реальном железе. Чего сильно не хватало, так это отладчика, а возникающие проблемы лишь укрепили желание достичь поставленной цели. Под катом будет рассказ о том, как это все заработало.
Стоит сразу предупредить, что это возможно будет рассказ о велосипедах, я не придумал ничего такого, что не гуглится на просторах «интернетов». Также Читатель вряд ли увидит новые решения или мега технологии, но найдет опробованные инструкции по сборке приложения, использующего SDL1/2, для Android.
Здравствуйте!
Ремейк игры Caesar III© начинался совсем не как отдельный проект, а скорее набор фиксов для количества жителей, поддержки «больших» разрешений и исследования декомпилированного кода оригинальной игры в поисках пасхалок и недокументированных режимов работы. А когда количество восстановленного кода перевалило за половину от общего, стало понятно, что можно попытаться восстановить игру. В качестве библиотеки отрисовки была выбрана SDL1.2, которая хорошо зарекомендовала себя в других проектах, а ещё проста в освоении и использовании. Ремейк поначалу был Linux-only, в начале этого года перебрался на другие платформы (Mac, Windows и Haiku), а потом у меня завелся вот такой планшет, а голове периодически возникали мысли «работает на одном линуксе, должно работать и на другом».
Попытка номер раз, удачная
У SDL версии 1.2 «из коробки» нет возможности работы под андроидом, зато есть замечательный проект libsdl-android, который позволяет, используя свое окружение и скрипты собирать код, использующий эту библиотеку в приложении для андроида. Собранное приложение может загрузить ресурсы как из интернета, так и распаковать из установщика. Сам libsdl-android содержит большое количество библиотек, которые могут вам понадобиться, начиная от bzip2 и разных кодеков, до самой SDL и его окружения SDL_image, SDL_mixer, ttf и другие. Если у игры нет платформозависимого кода, то портирование занимает несколько шагов:
Если все удачно скомпилилось, то в папке commandergenius/project/bin появится файла MainActivity-[release|debug]-unsigned.apk, который нужно подписать и установить на устройство.
$ keytool -genkey -v -keystore rs.keystore -alias caesaria -keyalg RSA -keysize 2048 -validity 10000
$ jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore rs.keystore ~/projects/commandergenius/project/bin/MainActivity-release-unsigned.apk caesaria
$ mv ~/projects/commandergenius/project/bin/MainActivity-release-unsigned.apk ~/projects/caesaria.apk
$ adb uninstall net.dalerank.caesaria
$ adb install ~/projects/caesaria.apk
Подводные камни
0. Определение окружения: для начала надо определиться в каком окружении будет работать Windows, Linux или Linux Android.
Решение: Проверяем наличие дефайнов ANDROID/__ANDROID__.
2. Использование OpenGL: если кому понадобится OpenGL, то на мобильных плафтормах обитает его близкий родственник GLES.
Решение: подключаем вместо стандартных заголовояных файлов и , есть небольшие отличия в использовани текстур и отрисовке, но в основном код(простой код, который я использовал) работает практически без изменений.
3. Обработка событий: пропадает событие SDL_MOUSEBUTTONUP при движении пальцем по экрану, это могла быть недоработка в самой библиотеке libsdl-android или я где-то его терял. Проявлялось иногда в отсутствии реакции элементов интерфейса на действия пользоватся, например после движения остановились на кнопкой, которая по идее должна перейти в состояние если над ней находится курсор мыши.
Решение: Специфично для моего приложения — при сборке под андроид было добавлено принудительное обновление состояния элементов под курсором при движении последнего.
4. Мелкий интерфейс: разрешение экрана современных мобильных устройств сопоставимо или превышает разрешение монитора, используемого 10-15 лет назад, но физические размеры заметно меньше, оттого и сам элементы пользовательского интерфейса выглядят мелко и пользоваться ими будет не всегда удобно.
Решение: Переделка интерфейса, что достаточно хлопотное занятие и не всегда удается сохранить первоначальный вид.
Один переезд равен двум пожарам(народная мудрость)
Все началось с того, что один из коммитеров прислал ссылку на ветку разработки, где успешно запустил игру с использованием относительно свежей библиотеки SDL2, а до этого использовалась версия SDL1.2 — 2008 года выпуска. Надо сказать, что я и сам рассматривал возможность перехода на новую версию, особенно после просмотра списка изменений, который сулил нормальную поддержку Mac и Android, что называется «из коробки». А тут еще и миниотпуск на работе получился, взяв кувалду побольше гайд потолще и большую чашку кофе, я начал переводить ремейк на новый «движок».
Не хочу утомлять читателя техническими подбробностями переезда, просто у самой библиотеки с приходом аппаратной поддержки изменилась идеология работы, что поначалу доставляло определенные трудности, пока я к ней не привык. Переезд растянулся на неделю вечеров и под конец представлял собой исправление оставшихся недочетов и графических артефактов. Переделки были закончены и подготовлены сборки для «больших» ОС, и опять появилась необходимость повторного чтения мануалов по сборке приложения под Андроид, потому как libsdl-android нормально адаптирован для работы с SDL1.2, а поддержка SDL2 похоже заброшена (о чем сами авторы и пишут в ридми)
Осознал я правдивость этого текста, когда было потрачено несколько часов в попытке запустить порт в старой конфигурации через libsdl-android. Ну что ж, отрицательный опыт — тоже опыт: буду использовать доступные инструмены.
Попытка номер два, не совсем удачная
SDL2 уже содержит все необходимые конфиги для сборки приложения под андроид, почитав статью, рекомендованную на официальном сайте, можно пробовать собрать чтонибудь. Опять же будут несколько шагов, за исключением установки и настройки adt.
Для чего все эти копирования сделаны. чтобы проще было считать относительные пути для библиотек. В папке android/libs будет лежать SDL и компания, в папке android/data — будет иконка приложения.
В папке android/android-project/jni создаем символьные ссылки на компоненты приложения
$ln -s ../../libs/SDL SDL
$ln -s ../../libs/SDL_mixer SDL_mixer
$ln -s ../../libs/SDL_net SDL_net
$ln -s ../../src/dep/aes aes
$ln -s ../../src/source application
$ln -s ../../src/dep/bzip2 bzip2
$ln -s ../../src/dep/freetype freetype
$ln -s ../../src/dep/libpng libpng
$ln -s ../../src/dep/lzma lzma
$ln -s ../../src/dep/smk smk
$ln -s ../../src/dep/src src
$ln -s ../../src/dep/ttf ttf
$ln -s ../../src/dep/zlib zlib
Немного о том, что же я тут написал:
zlib нужен для сборки freetype, который в свою очередь нужен для SDL_ttf и будет отвечать за рендеринг шрифтов.
Библиотека smk нужна для воспроизведения видео в формате smack, в этом формате выполнены ролики оригинальной игры.
Bzip, lzma и aes нужны для работы с zip-архивами.
libpng требуется для загрузки текстур для игры.
SDL, SDL_mixer, SDL_net отвечают соответсвенно за рисования, работы со звуком и сетью.
application содержит исходники самой игры, которые будут собраны в библиотеку libapplication.so
в папке src располагаются исходники библиотеки libmain.so, а вот для неё уже написано кружево java-вызовов над с-кодом, которое позволит нам успешно стартовать и порадовать пользователя яркой картинкой.
Настройки проекта и конфиги для ndk уже любезно предоставлены авторами SDL2
Чтобы система сборки увидела, какие нам необходимы библиотеки для работы и собрала их, нужно написать для них конфиги, наподобие Makеfile. С большой вероятностью Android.mk уже будет присутствовать в репозитории библиотеки, или их можно найти на просторах интернета. Мне пришлось дописать конфиги сборки для для игры и библиотеки libsmk.
LOCAL_MODULE := smk
LOCAL_SRC_FILES := $(subst $(LOCAL_PATH)/,, \
$(wildcard $(LOCAL_PATH)/*.c))
Конфиг содержит указание скомпилировать все файлы с расширением .с, найденные в текущей папке (для libsmk это будет jni/smk)
Аналогично пишется и конфиг для сборки библиотеки, которая будет представлять саму игру.
SDL_PATH := ../../libs/SDL
SDL_MIXER_PATH := ../../libs/SDL_mixer
SDL_NET_PATH := ../../libs/SDL_net
GAME_PATH := $(LOCAL_PATH)
DEP_PATH := ../dep
LOCAL_C_INCLUDES := \
$(LOCAL_PATH)/$(SDL_PATH)/include \
$(LOCAL_PATH)/$(SDL_MIXER_PATH) \
$(LOCAL_PATH)/$(SDL_NET_PATH)/include \
$(LOCAL_PATH)/$(FREETYPE_PATH)/include \
$(LOCAL_PATH)/$(GAME_PATH) \
$(LOCAL_PATH)/$(DEP_PATH) \
$(LOCAL_PATH)/$(DEP_PATH)/libpng
LOCAL_SHARED_LIBRARIES := SDL2 SDL2_mixer SDL2_net sdl_ttf pnggo lzma bzip2 aes smk
LOCAL_CPP_FEATURES += exceptions
LOCAL_CPP_FEATURES += rtti
LOCAL_LDLIBS := -lGLESv1_CM -llog
Тоже должно быть понятно, в LOCAL_C_INCLUDES добавляет пути где нужно искать заголовочные файлы, в LOCAL_SRC_FILES добавляем файлы с исходным кодом,
в LOCAL_SHARED_LIBRARIES прописываем зависимости приложения.
флаги rtti, exceptions отвечают за использование RTTI и исключений.
$cd android-project
$android update project -p. -t android-15
$ndk-build V=1
$ant [release|debug]
$ant install[r|d]
Теоретически, после выполнения описанных шагов на подключенном девайсе или эмуляторе вы увидите установленное приложение.
Грабли
1. Где искать ресурсы.
Место размещения ресурсов зависит от конкретной реализации ОС, но в большинстве случаев приложению будет доступна папка /sdcard/Android/data/имя_пакета/files, при использовании непосредственно пути может быть ошибка доступа или ошибка поиска файла.
Получить полный путь к директории приложения можно через функцию SDL_AndroidGetExternalStoragePath(), определенную в файле SDL_system.h
2. Использование флагов создания окна.
Комбинация SDL_WINDOW_OPENGL | SDL_WINDOW_SHOWN | SDL_WINDOW_BORDERLESS работает не на всех девайсах, убираем SDL_WINDOW_OPENGL или SDL_WINDOW_BORDERLESS и смотрим какой из флагов крашит программу. Не могу объяснить с чем связано такое поведение. С флагом SDL_WINDOW_SHOWN запукается по логам один в один, как и со всеми флагами, но при этом вероятность вылета намного меньше.
3. Слишком много звуковых каналов.
Наблюдаются вылеты при вызове функции SDL_mixer::Mix_AllocateChannels(N>16) c ошибкой, что невозможно иниализировать звук. Обходится снижением запрошенного числа каналов, насколько корректно решать эту проблему таким способом я не знаю.
4. stlport vs gnustl
Вылет при использовании stlport, нарвался на этот баг при обходе вектора с использованием итераторов на эмуляторе Nexus 7 (Android 4.0.3). Опять же не могу объяснить факт сей ошибки, решилось использованием gnustl при сборке приложения.
5. Мое кунгфу сильнее твоего.
Использование библиотеки с именем, похожим на имя той, что уже есть в системе приводит к загрузке чужой библиотеки, в которой возможно нет необходимых функций. Ошибка появилась из-за того, что я собираю свою версию libpng.so, решение было найдено на stackoverflow, исправилось заменой имени библиотеки libpng.so на libpnggo.so
В заключении.
Работает! Почти не отличается от ББ! Доволен ли я? Не очень!
Дело в том, что толи я криворукий, толи лыжи не едут, но на планшете приложение получилось крайне медленным (10-12 fps для крайне простой картинки результат унылый), думаю, вина тут в руках и незнании матчасти. SDL — отличная библиотека в обеих реинкарнациях, и много действительно хороших игр использует её, а также портировано на андроид.
Потраченного времени на создание порта не жаль точно, получен определенный опыт и много положительных эмоций, когда игра взлетела. Тем, кто ещё раздумывает пробовать или нет, однозначно пробовать, не откладывайте на потом!
Иногда некоторые приложения на Android чем-то не устраивают пользователя. В качестве примера можно привести назойливую рекламу. А то бывает и так — всем хороша программа, да только перевод в ней или кривой, или вовсе отсутствует. Или, например, программа триальная, а получить полную версию возможности нет. Как же изменить ситуацию?
Введение
В этой статье мы поговорим о том, как разобрать пакет APK с приложением, рассмотрим его внутреннюю структуру, дизассемблируем и декомпилируем байт-код, а также попробуем внести в приложения несколько изменений, которые могут принести нам ту или иную выгоду.
Чтобы сделать все это самостоятельно, потребуются хотя бы начальные знания языка Java, на котором пишутся приложения для Android, и языка XML, который используется в Android повсеместно — от описания самого приложения и его прав доступа до хранения строк, которые будут выведены на экран. Также понадобится умение обращаться со специализированным консольным софтом.
Итак, что же представляет собой пакет APK, в котором распространяется абсолютно весь софт для Android?
Декомпиляция приложений
В статье мы работали только с дизассемблированным кодом приложения, однако если в большие приложения вносить более серьезные изменения, разобраться в коде smali будет гораздо сложнее. К счастью, мы можем декомпилировать код dex в Java-код, который будет хоть и не оригинальным и не компилируемым обратно, но гораздо более легким для чтения и понимания логики работы приложения. Чтобы сделать это, нам понадобятся два инструмента:
Использовать их следует так. Сначала запускаем 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 и, соответственно, работать будет хоть в винде, хоть в никсах.
Настройка 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 появятся все извлеченные и дизассемблированные файлы пакета.
Препарирование. Отключаем рекламу
Теория — это, конечно, хорошо, но зачем она нужна, если мы не знаем, что делать с распакованным пакетом? Попробуем применить теорию с пользой для себя, а именно модифицируем какую-нибудь софтину так, чтобы она не показывала нам рекламу. Для примера пусть это будет 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:
Здесь происходит создание объекта. Комментируем. Продолжаем поиск и находим в строках 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. Однако, имея базовые знания, разобраться во всем этом — лишь вопрос времени.
Так уж получилось, что приложение для чтения комиксов и манги, которое я использую на своем android-смартфоне, после обновления стало показывать рекламу в конце каждой главы комикса. Данное приложение пару лет назад было доступно на Google Play (платная версия которого и была мной куплена), но было удалено в силу «нарушения авторских прав», после чего ушло в подполье и стало распространятся через сайт разработчика. Увы, достойных альтернатив этому приложению на android и iOS я не нашел, но и смотреть рекламу особо не было желания, тем более я уже покупал версию без рекламы. Сам разработчик почему-то не сделал возможности отключить ее, а на просьбы добавить такую возможность не отозвался. Поэтому пришлось искать альтернативные методы ее отключения. Первое, что пришло в голову, это то, что android-приложения пишутся на java, а значит есть вероятность, что автор не обфусцировал свое приложение и его можно попытаться декомпилировать. Немного подумав, я приступил к работе.
Код метода placeAdViewIfNeeded:
Самое простое, что пришло на ум после чтения кода, это убрать все лишнее, и оставить лишь вызов return;
Но, как уже было сказано, даже если бы я изменил в java-классе что-либо, я бы не смог в итоге скомпилировать приложение в IDE. Поэтому пришлось искать альтернативу. Оказалось, что smali-файлы, которые создаются в процессе декомпиляции, позволяют также после внесения нужных изменений, вновь собрать модифицированное приложение. Увы, сайт, что был приведен выше, позволял лишь получать исходники, но не собирать новые. Поэтому пришлось искать способы сделать это самостоятельно.
Была найдена утилита ApkTools, которая позволяла декомпилировать и компилировать apk-файлы. Кроме того, потребовалась утилита aapt.exe, которая была взята мной из стандартного SDK под андроид в папке android-sdk\build-tools\20.0.0.
Для удобства вызова утилиты из под windows был создан скрипт apktool.bat:
Для декомпиляции приложения были выполнены команды:
После чего, в полученных исходниках был найден файл BaseReaderFragment.smali и нужные нам методы были изменены следующим образом:
Далее пришла очередь сборки apk-файла из исходников.
Сделать это можно cледующей командой:
Но это еще не все. Чтобы приложение можно было установить, его нужно было подписать цифровой подписью. Самый простой способ сделать это – это скачать архив в котором находится утилита для подписи приложений и цифровые сертификаты к ней.
Распаковываем архив, выполняем команду:
Полученный apk-файл можно загружать на телефон, чтобы проверить наше модифицированное приложение. Однако в процессе тестирования изменений оказалось, что объявления больше не показываются, однако сама страница для их показа создается, что не очень приятно. Снова был проанализирован код приложения, найден класс BaseSeamlessReaderFragment, а в нем метод appendPages.
В нем было видно, что строчка:
создает дополнительную страницу, помимо тех, что есть в главе манги, с параметром, отвечающим за показ объявлений. Было решено удалить эту строчку и посмотреть результат. Снова заглядываем в аналогичный smali-файл(BaseSeamlessReaderFragment$4) и удаляем строчку:
Снова проводим сборку apk-файла из исходников и подписываем наше приложение. После установки и тестирования приложения экран с рекламой окончательно исчез, что и было конечной целью.
Данный пример показывает, что в случае необходимости можно довольно просто и быстро модифицировать уже существующие android-приложения, чтобы добавить в них недостающий функционал или наоборот удалить некоторые нежелательные возможности в тех ситуациях, когда доступа к исходникам нет. Надеюсь он поможет людям, которые попали в похожую ситуацию и не хотят мирится с ней, найти решение проблемы.
Делаем видео на своем андроид устройстве в стиле Harlem Shake.
Создавайте собственные книги на своем устройстве с помощью простой программы от разработчика Red Jumper.
Создавайте новые игры с помощью данной программы от SilentWorks .
Станьте конструктором и постройте свой фантастический LEGO остров.
v3.0.0 + Мод: бесплатные покупки
Отличное приложение, для создания 3D FPS игр, на android, с кучей возможностей.
Отличное приложение как для начинающих так и для продвинутых блогеров видео сервиса YouTube.
Изменяйте планировку своего дома, не передвигая мебель в реальной жизни.
v3.4.1 build 314 Unlocked
официальная игра по мотивам культового Британского сериала.
Создавайте коллажи, и изменяйте ваши фотографии используя всевозможные инструменты.
Создавайте свои лучшие видео клипы.
Создавайте новых персонажей, улучшайте их и делитесь с друзьями своим фетишем.
Уникальный сканер для считывания текста с любых документов.
Создавай собственные уникальные карты и раскрой творческий потенциал.
Стройте американские горки своей мечты и проверяйте их на деле пуская по ним вагончики.
Создавайте свои собственные мемы.
Профессиональное создание логотипа.
Создание креативного логотипа для бизнеса
Удобное приложение для создания ярлыков
Отличное приложение для извлечение apk файлов с андроид девайса.
Приложение где вы сможете создать своего уникального пони!
Полезные программы для Андроид
Популярные теги Андроид
Все права защищены.
Функционал в разработке!
Пока эти кнопки заработают, пройдут года, может даже века, но вы не отчаивайтесь, ждите и вам воздастся! Хочешь ускорить процесс разработки? Делай репосты страниц сайта в соцсети и рассказывай о нас друзьям!
Читайте также: