Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Примитивный метод модификации Android приложения

Anna | 2.06.2014 | нет комментариев
Бывает позже релиза приложения его исходники куда-то деваются. Правда чай, такое непрерывно случается? И ничего не остается помимо как декомпилировать его и подправить несколько сотен строк кода и все это необходимо сделать максимально стремительно.

Вот и у меня возникла задача модифицировать приложение имея каждого лишь его apk. И те, кто занимался декомпиляцией приложений знают насколько трудно его потом скомпилировать.

Декомпиляция

Для Android’а существуют следующие утилиты:

  • ApkTool для декомпиляции источников.
  • Dex2Jar для реформирования dex в jar.
  • JD-GUI для приобретения исходников из 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 библиотеки.

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB