Dex2jar windows как пользоваться

Обновлено: 03.07.2024

Иногда некоторые приложения на 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 распространяются в архивах. Эти архивы имеют расширение ".apk". Такие файлы не шифруются и являются по сути файлами «zip». Можете переименовать apk-файл в zip, чтобы убедиться в этом.

Вам необходимо поковыряться в APK-файле и получить какие-то данные. Можно потренироваться на кошках. Возьмём свою программу "Hello Kitty", найдём его apk-файл в папке проекта app\build\outputs\apk и переместим в отдельную папку для опытов.

Вы можете также получить apk-файл с устройства и перенести его на компьютер при помощи команд ADB

Распаковав архив, вы можете увидеть структуру приложения и встретить знакомые файлы. И даже извлечь некоторые файлы для просмотра. К примеру, в папке res/drawable-hdpi-v4 я нашёл свою картинку pinkhellokitty.jpg. Казалось бы, вот оно - счастье. Но погодите радоваться. Если с изображениями проблем нет, то с чтением XML-файл вас ждёт облом. Какие-то строки вам видны, но в целом текст совершенно нечитаем. Поэтому сначала пойдём другим путём.

Так как пользовательские приложения для Android выполняются в java-машине, то APK-файлы наследуют все характерные черты JAR-файлов.

Содержимое архива обычно выглядит примерно так:

Каталог META-INF содержит:

CERT.RSA — сертификат приложения
CERT.SF — контрольные суммы файлов ресурсов (картинок, звуков и т.д.)
MANIFEST.MF — служебная информация, описывающая сам apk-файл

Каталог res содержит ресурсы — значки в нескольких разрешениях, описание размещения элементов на форме в xml-файле.

AndroidManifest.xml — служебная информация о приложении. В этом файле содержатся и так называемые «permission» — разрешения, которые требуются для работы приложения (например, доступ к сети или доступ к телефонной книге).

classes.dex — исполняемый код приложения. Именно этот файл интересует нас в первую очередь.

resources.arsc — таблица ресурсов. В этом файле собраны xml-описания всех ресурсов.

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

Теперь рассмотрим популярные утилиты, используемые для изучения программ.

Apktool

Для начала скачиваем утилиту Apktool, который представляет собой jar-файл с номером версии. Для удобства переименовываем его в короткий вид apktool.jar, так как будем работать в командной строке. Подопытный файл разместите в той же папке с утилитой.

Запускаем в окне командной строки утилиту с флагом d:

Появится отдельная папка, имя которой будет совпадать с именем вашего файла. Зайдите в неё и исследуйте файлы. Вы заметите, что XML-файлы теперь доступны для чтения в нормальном виде. Таким образом, мы можем открыть файл activity_main.xml и узнать разметку своей активности.

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

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

Моя тестовая программа была слишком проста. В других примерах могут быть дополнительные папки, например, assets, которая может содержать файлы, картинки и т.д. Там могут находиться html-файлы с сценариями на Javascript, которые ведут на вредные страницы.

В папке smali находятся уже файлы классов с тем же расширением smali. Код выглядит как в ассемблере и при желании можно понять листинг, но очень неудобно. Оставив файлы пока в покое.

Первую часть задачи мы выполнили.

dex2jar

Вторая утилита dex2jar, позволяет преобразовать файлы dex в jar. Скачиваем последнюю версию и распаковываем архив утилиты. Утилита содержит множество файлов для различных ситуаций. Можете поизучать их на досуге.

Запускаем команду d2j-dex2jar.bat app-debug.apk и получаем на выходе файл app-debug-dex2jar.jar. Это стандартный тип файлов для Java, но для нас пока не слишком полезный. Тем не менее мы выполнили второй шаг и получили промежуточный файл.

JD-GUI

Утилита, которая поможет нам прочитать jar-файл, называется JD-GUI. На странице разработчика можно найти ссылки на плагины к средам разработки и даже онлайн-версию.

Скачиваем последнюю версию и распаковываем архив. Там всего два файла - исполняемый exe-файл и readme.txt

Запускаем программу и перетаскиваем на него jar-файл. И весь код на ладони.

Обратите внимание, что код немного будет отличаться. Например, код в студии:

Сравните с кодом в утилите.

Иными словами, вместо констант из класса R подставляются их реальные значения. Вам придётся попотеть, чтобы сопоставить данные. Но вы справитесь, я в вас верю.

Burp Suite

Далее следует настроить прокси и другие параметры.

Разбор вредоносной программы

В качестве примера возьмем программу suspicious.apk, который детектируется разными антивирусами как вредоносная программа.

Чтобы лучше понять, что именно искать, нужно проанализировать файл «AndroidManifest.xml» — посмотреть, какие именно разрешения требуются анализируемому приложению. Данный файл бинарный, а не обычный текстовый xml. Для того, чтобы его прочитать нужно воспользоваться консольной утилитой «aapt» из комплекта Android SDK. Она находится в каталоге «platform-tools». Так как графического интерфейса нет, то команду нужно вводить в консоли. Например, для Windows:

В файле нужно найти секцию «Android manifest» и искать перечисление разрешений. В анализируемом файле это выглядит так:

Из этой информации становится понятно, что программа может получать состояние телефона (сюда включаются, например «телефон в режиме вызова», «телефон в режиме принятия данных»). Это разрешение нужно и для получения номера телефона, на котором запущена программа, работать с сетью и мониторить приход СМС. На этих аспектах и нужно сосредоточить внимание при дальнейшем анализе.

Для того, чтобы получить доступ к коду нужно выполнить два шага — преобразовать apk-файл в jar-файл и декомпилировать полученный байткод в более понятный для человека вид.

Воспользуемся конвертером «dex2jar»:

Сконвертированный файл будет находится в том же каталоге, что и оригинальный файл. К его имени будет добавлено ".dex2jar.jar", то есть в данном примере это будет «suspicious.apk.dex2jar.jar».

Этот файл можно открыть декомпилятором. Иерархия пакета в окне декомпилятора выглядит так:

На этом подготовительные шаги заканчиваются — дальнейший успех зависит только от вашего знания Java и умения пользоваться поисковиком.

К счастью, экземпляр выбранный для примера имеет довольно скромные размеры — финальный jar всего 7,01 KB.

В программе всего шесть классов. Исключим те, которые не представляют интереса. Это класс R, в котором только перечислены идентификаторы всех ресурсов. Так же из рассмотрения можно исключить класс Config, в котором содержится конфигурация сборки.

Рассмотрим подробнее оставшиеся три класса.

Activation

Этот класс срабатывает по событию onCreate(), то есть сразу после старта приложения.

TelephonyManager localTelephonyManager = (TelephonyManager)getSystemService("phone"); — создает localTelephonyManager, в которую помещает данные об устройстве.

str1 = localTelephonyManager.getDeviceId(); — выбирает из полученных данных идентификационный номер устройства и помещает его в строку str1

Дальше идет цикл, который делит DeviceId на кусочки по четыре цифры, вставляя между ними дефис "-", то есть из XXXXXXXXXXXXXXXX получается XXXX-XXXX-XXXX-XXXX. Полученную строку цифр и дефисов передают в TextView с идентификатором 2131034112.

SmsReciever

MainService

Этот класс довольно велик, поэтому не стану приводить его целиком. Сразу после вызова запускает субкласс «SmsBlockerThread», который блокирует уведомление о поступившем СМС, чтобы пользователь не был оповещен о новом входящем СМС.

Затем входящее СМС обрабатывается таким образом:

String str1 = localSmsMessage.getOriginatingAddress(); — номер телефона-получателя (то есть номер телефона, на котором установлен троянец) помещается в переменную str1.

Затем создаются связанные пары localBasicNameValuePair1 и localBasicNameValuePair2 в которые помещаются значения

Эти пары сохраняют в массив localArrayList, в который позже добавляют пару localBasicNameValuePair3, представляющую собой устройства>

При этом, как видите, DeviceId получается заново, а не используется то, что было получено в классе Activation. Заканчивается тем, что вызывается метод postRequest() из последнего класса ServerSession:

В качестве параметра передается тот самый массив пар, в котором номер телефона, содержимое СМС и идентификатор устройства.

ServerSession

Этот класс имеет два метода: initUrl(), который возвращает часть ссылки "(http://softthrifty.com/security.jsp)":

Итак, данный троянец перехватывает СМС и отправляет на сервер запрос, в котором передает номер зараженного телефона, содержимое СМС и идентификатор зараженного телефона. Такое поведение может быть признаком банковского троянца, атакующего двухфакторную авторизацию. Для успешной атаки требуется выполнение таких условий:

1) злоумышленник должен заразить компьютер жертвы, чтобы перехватить данные для он-лайн банкинга;
2) злоумышленник должен заразить телефон жертвы для перехвата СМС с кодом подтверждения от банка;
3) злоумышленник должен каким-то образом связать пользователя зараженного компьютера и зараженного телефона, чтобы знать, от каких учетных данных он-лайн банкинга данный код подтверждения;

В силу своих размеров и очевидности производимой деятельности такой образец хорошо подходит для демонстрации базовых приемов разбора вредоносных программ под Андроид.

В этой статье я постараюсь рассказать про реверс-инжиниринг приложений для android. Этот процесс несколько отличается от оного для win-приложений: здесь нет отладчика и нет ассемблера, вместо них выступают LogCat и байт-код. Как вы уже догадались, мы будем исследовать приложение с целью его взлома, или, проще говоря, «крякать».

БРИФИНГ

В качестве подопытного кролика я выбрал программу «Multi Mount SD-Card». Ее суть заключается в монтировании flash-накопителя девайса с одновременным доступом к нему системы и пользователя. Дело в том, что по умолчанию android не имеет доступа к смонтированному в данный момент накопителю. Для пользователей Eclair это не так критично, но вот пользователи Froyo+ ~~писают кипятком~~ не радуются, когда установленные на карту программы вылетают при ее монтировании. Собственно для решения этой проблемы была и написана эта программа. Ах да, программе нужны root права.

Для начала нам нужен дистрибутив программы, чтобы было что ломать. Но где же его взять? Ведь для этого надо ее купить. Ну, или выпросить у уже купившего человека. Таким человеком стал creage с форума 4pda, который любезно расшарил купленный apk.

Итак, у нас есть дистрибутив, мы уже установили программу, запускаем… И тут бац! Видим окошко с предложением купить лицензию. Отсюда вытекает, что проверка идет через интернет, пробуем отключить — не помогает. Покупателю приложения не дают никаких ключей и логинов, что говорит нам о привязке к чему-то вроде hardware_id или google-аккаунта. Следовательно у нас есть несколько вариантов взлома: либо захардкодить в программу заведомо правильную проверяемую информацию, либо вырезать из кода все участки, проверяющие валидность лицензии. Я выбрал второй вариант, ибо он мне больше нравится.

Инструментарий

Введение

Прежде чем приступать, я немного объясню структуру android приложений. Каждое приложение есть файл с расширением apk, упакованный zip’ом. В нем содержатся ресурсы приложения, AndroidManifest.xml и classes.dex. Что же из себя представляет последний? Это байт-код программы, скомпилированный специально для виртуальной машины dalvik. Получить из него чистый исходный код на java нельзя, но можно получить dalvik opcodes — набор команд для виртуально машины, грубо говоря, это местный ассемблер. А еще можно превратить dex файл в jar, после чего декомпилировать его и получить более-менее читаемый код на java. Чем мы и будем сейчас заниматься.

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

Копируем multimount.apk в папку apk_manager\place-apk-here-for-modding и запускаем Script.bat. Если все хорошо, то появится консоль с зелеными надписями.
Необходимо декомпилировать apk. Выбираем одноименный пункт 9. Консоль после этого не закрываем.
Открываем multimount.apk архиватором и копируем файл classes.dex в папку dex2jar, после чего перетаскиваем его на dex2jar.bat. В Total Commander перетаскивание не работает.
Появившийся classes.dex.dex2jar.jar открываем с помощью jd-gui. Окно пока не закрываем, оно понадобится позже.

Начало анализа

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

<uses-permission android:name = "com.android.vending.CHECK_LICENSE" />

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

Ну да ладно, приступим непосредственно к анализу кода. Переключаемся на jd-gui, разворачиваем дерево, и видим три пространства имен: первое — что-то связано с рекламой, второе — набор классов LVL, третье — то, что нам надо.
Заходим в него и видим последствия обфускации. Открываем MultiMountSDCardConfigure, бегло просматриваем код. В глаза сразу бросается длинная строчка с каким-то хэшем. Это base64 public key. А вокруг него находятся и остальные строчки, проверяющие лицензию. Их нам необходимо выпилить.

com. android . vending . licensing . h localh = new com. android . vending . licensing . h ( arrayOfByte, str4, str3 ) ;
v localv = new v ( this , localh ) ;
m localm1 = new m ( this , localv, "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAg1. " ) ;
f = localm1 ;
m localm2 = f ;
j localj = e ;
localm2. a ( localj ) ;

Открываем apk_manager\projects\multimount.apk\smali\com\rafoid\multimountsdcard\widget\MultiMountSDCardConfigure.smali и видим байт-код. Прежде чем читать дальше, советую сначала просмотреть список команд. Нам необходимо найти те самые строчки и закоментить их. Вот они:

Закоменчиваем, сохраняем. Вроде как, все, можно пользоваться. Осталось только скомпилить и установить.

Компиляция и установка

Если вы ещё не закрыли окно консоли, переключаемся на него и выбираем пункт 14. Скрипт сам скомпилит, подпишет и установит apk на девайс.
Запускаем приложение и видим, что теперь нам не предлагают ничего покупать, но окошко с процессом проверки висит и не закрывается.

Опять анализ

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

rogressDialog localProgressDialog = ProgressDialog.show(this, str1, str2, 1, 0);
b = localProgressDialog;

Теперь надо найти их в MultiMountSDCardConfigure.smali. Вот они:

Закоменчиваем, сохраняем, компилим, устанавливаем, запускаем. Ура! Все работает. Но после непродолжительного тестирования мы понимаем что работает не совсем все, а именно функция авто-монтирования. Переключаемся на jd-gui, открываем MultiMountSDCardWidget$UpdateService и видим следующий кривой код:

if (MultiMountSDCardWidget.b.booleanValue());
int j;
for (int i = 0; ; j = 1)
Boolean localBoolean = Boolean.valueOf(i);
RemoteViews localRemoteViews = MultiMountSDCardWidget.a(this, localBoolean);
Class localClass = MultiMountSDCardWidget.a;
ComponentName localComponentName = new ComponentName(this, localClass);
AppWidgetManager.getInstance(this).updateAppWidget(localComponentName, localRemoteViews);
return;
>

Именно этот сервис отвечает за авто-монтирование. В самом начале мы видим какую-то проверку, в результате которой выполняется это самое монтирование. Код проверяет переменную b из главного активити, ту самую переменную, объявление которой мы закоментили, удаляя диалог. Так же мы поступим и с этой проверкой — закоментим ее к черту.
На сей раз открываем MultiMountSDCardWidget$UpdateService.smali и закоменчиваем следующие строчки:

Запускаем и радуемся, что сэкономили целых 30 рублей на покупке этой полезнейшей программы.

Примечания

Процесс описан целиком для Windows, но легко может быть повторен и на Linux, так как все необходимые библиотеки кроссплатформенны.
Уже после написания статьи я наткнулся на на вот этот способ взлома, но, насколько я понимаю, он актуален для ранних версий LVL.

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

Автор: Eric Gruber

В статье будет рассказано о том, как подключить отладчик к Android-приложению и пошагово пройти через вызываемые методы, используя информацию, полученную после декомпиляции приложения. Хорошая новость в том, что для отладки не требуются привилегии суперпользователя. Описанные техники могут быть очень кстати во время пентестов мобильных приложений, поскольку мы можем «проникнуть» в код во время работы программы, получить и записать информацию, к которой обычно у нас нет доступа. Например, можно перехватить трафик перед шифрованием и на лету получить ключи, пароли и любую другую ценную информацию. Статья будет полезна пентестерам и разработчикам мобильных приложений, желающих получить более глубокие знания о возможных атаках на платформе Android.

Требования к тестовой среде:

В статье будет использоваться следующая конфигурация: Windows 8, Android Studio и IntelliJ IDEA. Устройство: Nexus 4 с Android версии 4.4.4. Рекомендую все утилиты добавить в переменную окружения PATH, чтобы облегчить и ускорить доступ к этим инструментам.

Настройка устройства

Инструкция ниже поможет вам подготовить устройство для экспериментов.

Активация раздела Developer Options

Рисунок 1: Для того чтобы активировать раздел Developer options, необходимо несколько раз кликнуть на Build number

Разрешение отладки через USB

Чтобы разрешить отладку через USB-порт, зайдите в раздел Settings > Developer options и отметьте флажок напротив USB debugging.

Рисунок 2: Включение опции USB debugging

Подключение устройства и запуск ADB

Устройство должно отобразиться в списке.

Рисунок 3: Список подключенных устройств

Если устройство не отобразилось в списке, то наиболее вероятная причина в некорректно установленных драйверах (в Windows). В зависимости от устройства драйвер можно найти либо в Android SDK, либо на сайте производителя.

Проверка приложения на возможность отладки

Перед отладкой Android-приложений вначале необходимо проверить, есть ли такая возможность. Проверку можно выполнить несколькими способами.

Первый способ – запустить Android Device Monitor, входящий в состав Android SDK (в папке tools). В Windows файл называется monitor.bat. При открытии Android Device Monitor устройство отобразится в разделе Devices.

Рисунок 4: Приложение Android Device Monitor

Если какое-либо приложение на устройстве можно отлаживать, это приложение также отобразится в списке. Я создал тестовую программу, но список пуст, поскольку программу отлаживать нельзя.

Второй способ проверить приложение на возможность отладки – исследовать файл AndroidManifest.xml из пакета приложения (APK, Android application package). APK представляет собой zip-архив, содержащий всю информацию, необходимую для запуска приложения на Android-устройстве.

Всякий раз, когда приложения загружается из Google Play Store, также загружается и пакет приложения. Все загруженные APK-файлы обычно хранятся на устройстве в папке /data/app. Если у вас нет прав суперпользователя, вы не сможете получить список файлов из директории /data/app. Хотя, если вы знаете имя APK-файла, можете скопировать его при помощи утилиты adb. Чтобы узнать имя APK-файла, введите следующую команду:

Появится командная строка устройства. Затем введите следующую команду:

pm list packages -f

Отобразится список всех пакетов на устройстве.

Рисунок 5: Перечень пакетов на устройстве

Глядя на список, находим тестовое приложение.

Рисунок 6: Пакет созданного тестового приложения (выделено белым)

Теперь необходимо скопировать файл пакета. Открываем шелл и вводим следующую команду:

adb pull /data/app/[.apk file] [location]

Рисунок 7: Копируем APK-файл с устройства в систему

Теперь нужно открыть файл пакета и исследовать содержимое AndroidManifest.xml. К сожалению, мы не можем просто так распаковать архив, поскольку APK-файл закодирован в бинарном формате. Для раскодировки чаще всего используется утилита apktool, хотя я использую APK Studio, поскольку у этого приложения дружелюбный графический интерфейс. Далее в статье будет рассказываться об APK Studio.

В APK Studio кликните на маленькую зеленую иконку, задайте имя проекту и укажите путь к APK файлу. Затем укажите пусть для сохранения проекта.

Рисунок 8: Создание нового проекта в APK Studio

После открытия APK выберите файл AndroidManifest.xml и посмотрите параметры тега application. Если флаг android:debuggable отсутствует (или присутствует, но установлено значение false), значит, приложение отлаживать нельзя.

Рисунок 9: Содержимое файла AndroidManifest.xml

Модификация файла AndroidManifest.xml

При помощи утилиты apktool или APK Studio мы можем модифицировать файлы и упаковывать содержимое обратно в пакет. Сейчас мы изменим файл AndroidManifest.xml так, чтобы приложение можно было отлаживать. Добавляем внутрь тега application строчку android:debuggable="true".

Рисунок 10: Изменяем содержимое тега application

После добавления флага кликаем на иконку «молоток» и заново собираем пакет. Пересобранный пакет будет находиться в директории build/apk.

Рисунок 11: Повторная сборка пакета завершилась успешно

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

Теперь нужно установить пересобранный пакет. Вначале удаляем старое приложение при помощи следующей команды:

adb pm uninstall[package name]

Затем устанавливаем новый пакет:

adb install [.apk file]

Также можно удалить и установить пакет одной командой:

adb install -r [.apk file]

Рисунок 12: Установка пересобранного пакета

Проверьте, чтобы переустановленное приложение корректно запускалось на устройстве. Если все работает, переходим обратно в Android Device Monitor, где должно появиться тестовое приложение.

Рисунок 13: Теперь пересобранное приложение можно отлаживать

Настройка среды разработки (IDE)

Теперь к пересобранному приложению можно подцепить отладчик, но вначале нужно создать проект в среде разработки (в статье используется IntelliJ IDEA). Создаем новый проект. В поле Application name указываем произвольное имя. В поле Package name указываем имя, в точности совпадающее с иерархией папок пересобранного пакета.

Рисунок 14: Создание нового проекта в IntelliJ IDEA

Рисунок 15: Иерархия директорий тестового приложения

Снимите флажок «Create Hello World Activity» и завершите создание проекта (все остальные параметры остаются по умолчанию). Новый проект должен выглядеть примерно так:

Рисунок 16: Иерархия папок и файлов нового проекта

После создания проекта нужно добавить исходный код из APK-файла для того, чтобы отладчик «знал» имена символов, методов, переменных и т. д. Хорошая новость в том, что Android-приложения можно декомпилировать практически без потери качества (исходный код будет совпадать с оригиналом). После декомпиляции исходный текст импортируется в среду разработки (IDE).

Получение исходных текстов из пакета приложения

Для начала необходимо преобразовать APK в jar-файл. Затем мы при помощи java-декомпилятора получим исходный текст приложения. Преобразование в jar будем делать при помощи утилиты dex2jar. У dex2jar есть файл d2j-dex2jar.bat, используемый для конвертирования APK в jar. Синтаксис команды довольно прост:

d2j-dex2jar.bat [.apk file]

Рисунок 17: Преобразование APK в jar

Затем открываем или перетаскиваем полученный файл в JD-GUI (это java-декомпилятор).

Рисунок 18: Структура jar-файла

Jar-файл должен отобразиться в виде иерархической структуры, внутри которой находятся java-файлы с читабельным исходным кодом. Заходим в File > Save All Sources, чтобы упаковать все исходные тексты в zip-архив.

Рисунок 19: Сохранение исходных текстов декомпилированного файла

После сохранения исходных текстов распаковываем архив в отдельную директорию.

Рисунок 20: Распакованный архив

Теперь нужно импортировать обе директории в созданный ранее проект в IDE. В IntelliJ заходим в папку src и копируем туда содержимое распакованного архива (две директории).

Рисунок 21: Обе папки скопированы в директорию src

Возвращаясь в Intellij, видим обновленный проект.

Рисунок 22: В проекте появились исходные тексты

Если мы кликнем на какой-нибудь элемент из списка, то увидим исходный текст. Как видно на скриншоте ниже (исходный текст класса LoginActivity), исходный код обфусцирован при помощи ProGuard.

Рисунок 23: Обфусцированный исходный текст класса LoginActivity

Подключение отладчика

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

Рисунок 24: Поставлена точка останова на обфусцированный метод

Как только появилась точка останова, подключаем отладчик к процессу на устройстве, кликнув на иконку с экраном в правом верхнем углу (на вашей IDE иконка может отличаться).

Рисунок 25: Подключаем отладчик к процессу

Далее вам будет предложено выбрать процесс, к которому нужно подключиться. Будут отображены только процессы с флагом android:debuggable="true".

Рисунок 26: Перечень процессов для подключения отладчика

После выбора процесса отладчик подсоединится к устройству.

Рисунок 27: Отладчик подключен к процессу, запущенному на устройстве

В текстовое поле я буду вводить число 42 (если помните, на соответствующем методе стоит точка останова).

Рисунок 28: В текстовое поле вводим число 42

После нажатия на кнопку «Enter Code» выполнение приложения прервется на точке останова, поскольку отладчик «осведомлен», какой метод вызывается на устройстве. Скомпилированное Android-приложение содержит отладочную информацию (например, имена переменных), доступную любому отладчику, совместимому с Java Debug Wire Protocol (JDWP). Если в приложении разрешена отладка, отладчик, совместимый с JDWP (в эту категорию попадает большинство отладчиков идущих в составе сред разработки для Java), сможет подсоединиться к виртуальной машине Android-приложения, а затем считывать и выполнять отладочные команды.

Рисунок 29: Сработала точка останова

На скриншоте ниже видно число, которое ранее мы ввели в текстовом поле.

Рисунок 30: Перечень переменных текущего экземпляра класса

Мы можем не только считывать данные в приложении, но и вставлять свои собственные. Это может быть полезно, если мы, например, захотим прервать поток выполнения кода и обойти некоторые участки алгоритма. При помощи отладчика мы можем лучше понять логику работы приложения и проанализировать то, что недоступно обычному пользователю. Например, может оказаться очень полезным просмотр используемых функций шифрования и динамические ключи. Кроме того, иногда при отладке полезно знать, как функции взаимодействуют с файловой системой или базой данных, чтобы понять какая информация сохраняется приложением. Подобные манипуляции доступны на любом Android-устройстве без привилегий суперпользователя.

Как можно декомпилировать файлы Android DEX (VM bytecode) в соответствующий исходный код Java?

Посмотрите здесь . Вы получите возможные выводы оттуда, чтобы двигаться дальше. Если у вас есть деньги, купите Jeb , в противном случае используйте JADX , посмотрите здесь, почему

Получить эти инструменты:

1) dex2jar для перевода файлов dex в файлы jar

2) JD-GUI для просмотра файлов Java в банке

Исходный код вполне читабелен, так как dex2jar делает некоторые оптимизации.

Процедура:

А вот процедура о том, как декомпилировать:

Шаг 1:

Преобразуйте classes.dex из test_apk-debug.apk в test_apk-debug_dex2jar.jar

Примечание 1. На компьютерах с Windows все .sh сценарии заменяются .bat сценариями.

Примечание 2: В Linux / Mac не забывайте о sh или bash . Полная команда должна быть:

Примечание 3: Кроме того, не забудьте добавить разрешение на выполнение в dex2jar-X.X каталог, например sudo chmod -R +x dex2jar-2.0

Шаг 2:

Откройте банку в JD-GUI

+1. Я пробовал и Баксмали, и Декс2джар. Dex2Jar + JD-Gui побеждает за то, что предоставил вам отлично читаемый исходный код для большинства файлов .dex. привет, не могли бы вы поделиться тем, как вы идете? Я буду очень благодарен вам. @JonathanDumaine, это зависит. Если JAR-файлы запутаны, и вы хотите внести небольшие изменения, Backsmali - единственный путь. Бонус! С APKTool вы также получаете все XML, изображения и другие ресурсы обратно. Смотри мой ответ . @JonathanDumaine Я согласен с jmendeth, apktool - это также путь, если вы хотите декомпилировать свой apk, изменить его, а затем перекомпилировать. При использовании dex2jar и jd-gui исходный код действительно читабелен, но вы не можете перекомпилировать без ошибок!

Чтобы уточнить, есть два основных пути, которые вы можете выбрать здесь в зависимости от того, чего вы хотите достичь:

Декомпилируйте байт-код Dalvik (dex) в читаемый исходный код Java. Вы можете легко сделать это с помощью dex2jar и jd -gui , как упоминает Фред . Полученный в результате источник полезен для чтения и понимания функциональности приложения, но, скорее всего, не даст 100% пригодного для использования кода. Другими словами, вы можете прочитать исходный код, но вы не можете изменить и упаковать его. Обратите внимание, что если исходный код был запутан с помощью proguard, результирующий исходный код будет значительно сложнее распутать.

Другая важная альтернатива - разбирать байт-код на smali , язык ассемблера, предназначенный именно для этой цели. Я обнаружил, что самый простой способ сделать это с помощью apktool . После того, как вы установили apktool, вы можете просто указать его на файл apk, и вы получите файл smali для каждого класса, содержащегося в приложении. Вы можете читать и изменять smali или даже полностью заменять классы, генерируя smali из нового источника Java (для этого вы можете скомпилировать ваш источник .java в файлы .class с помощью javac, а затем преобразовать ваши файлы .class в файлы .dex с помощью Android dx-компилятор, а затем используйте baksmali (smali disassembler) для преобразования файлов .dex в .smali, как описано в этом вопросе., Здесь может быть ярлык). Как только вы закончите, вы можете легко упаковать apk обратно с apktool снова. Обратите внимание, что apktool не подписывает полученный apk, поэтому вам нужно позаботиться об этом, как и в любом другом приложении Android .

Если вы пойдете по пути smali, вы можете попробовать APK Studio , IDE, которая автоматизирует некоторые из вышеперечисленных шагов, помогая вам декомпилировать и перекомпилировать apk и устанавливать его на устройство.

Короче говоря, вы можете либо декомпилировать в Java, которая более читабельна, но, вероятно, необратима, либо разбирать на smali, который труднее читать, но гораздо гибче вносить изменения и переупаковывать измененное приложение. Какой подход вы выберете, будет зависеть от того, чего вы хотите достичь.

Наконец, предложение о вызове также заслуживает внимания. Это инструмент ретаргетинга для преобразования файлов .dex и .apk в файлы java .class, чтобы их можно было проанализировать с помощью типичных инструментов статического анализа java.

Читайте также: