Classes dex что это

Обновлено: 04.07.2024

Какое приложение мы будем препарировать? Я выбрал для своих целей VK Admin — программу для управления сообществами «ВКонтакте» со смартфона. В нем не предусмотрена темная тема, поэтому мы с тобой попробуем эту тему добавить.

Собираем и разбираем

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

Чтобы получить установочный пакет, можно воспользоваться Android Debugging Bridge — системой для отладки программ на устройстве. В *nix-подобных системах ADB ставится стандартно, с помощью пакетного менеджера, а в Windows — идет в составе Android Studio или Android SDK Platform Tools.

В первую очередь установим приложение из Google Play Store на смартфон, подключим его к компьютеру с помощью USB, затем воспользуемся ADB для переноса пакета приложения на компьютер и извлечем его содержимое.

$ adb shell pm path com.vk.admin
package:/data/app/com.vk.admin-Ka5KVtTbnGgxoRqnObb-pQ==/base.apk

$ adb pull /data/app/com.vk.admin-Ka5KVtTbnGgxoRqnObb-pQ==/base.apk com.vk.admin.apk
3881 KB/s (13414132 bytes in 3.374s)

$ apktool d com.vk.admin.apk
I: Using Apktool 2.4.0 on base.apk
I: Loading resource table.
I: Decoding AndroidManifest.xml with resources.
I: Regular manifest package.
I: Decoding file-resources.
I: Decoding values / XMLs.
I: Baksmaling classes.dex.
I: Copying assets and libs.
I: Copying unknown files.
I: Copying original files.

После этого мы получим папку com.vk.admin/ , внутри которой хранится все содержимое исходного .apk, только в декодированном виде. Чтобы применить изменения, необходимо будет снова воспользоваться рядом утилит.

Сначала собери приложение обратно в пакет .apk .

$ apktool b com.vk.admin/
I: Using Apktool 2.4.0
I: Checking whether resources has changed.
I: Checking whether sources has changed.
I: Smaling classes folder into classes.dex.
I: Building apk file.
I: Copying unknown files/dir.
I: Built apk.

Затем необходимо подписать приложение. Это нужно, чтобы и Google Play Store, и устройство не обновляли приложение, если подписи не совпадают. Поэтому не забудь удалить приложение с телефона, прежде чем установить свое, подписанное своим ключом. Для создания подписи в первый раз нужно воспользоваться утилитой keytool (входит в Java Development Kit):

$ keytool -genkey -keyalg RSA -alias xakep -keystore ks.keystore -validity 10000 -keysize 2048
Enter keystore password:
Re-enter new password:
What is your first and last name?
[Unknown]: Xakep User
What is the two-letter country code for this unit?
[Unknown]: RU
Is CN=Xakep User, C=RU correct?
[no]: yes

Enter key password for
(RETURN if same as keystore password):
Re-enter new password:

Когда ты уже создал ключ, подпиши приложение.

После этого установи приложение на телефон.

$ adb install com.vk.admin.apk
3881 KB/s (13414132 bytes in 3.374s)
Success

Продолжение доступно только участникам

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Взлом одного Android приложения

Недавно я усиленно разрабатывал свое приложение под Android, и в процессе защиты платной версии понял, что довольно сложно обезопасить приложение от взлома. Ради спортивного интереса решил попробовать убрать рекламу из одного бесплатного приложения, в котором баннер предлагается скрыть, если заплатить денежку через In-App Purchase.

В этой статье я опишу, как мне удалось убрать рекламу бесплатно и в конце — несколько слов о том, как усложнить задачу взломщикам.

Шаг 1. Получаем «читаемый» код приложения.
Чтобы добыть APK приложения из телефона, нужны root права. Вытягиваем приложение из телефона с помощью adb (пусть, для конспирации, у нас будет приложение greatapp.apk):
adb pull /data/app/greatapp.apk
Хабраюзер overmove подсказал мне, что root необязателен, можно с помощью Astro сделать бэкап любого приложения, и оно будет скопировано в /mnt/sdcard.
Хабраюзер MegaDiablo подсказал мне, что и Astro необязателен. Список установленных приложений и их файлы apk можно узнать через утилиту pm в шелле, а когда уже известно имя файла, его можно стянуть через adb pull /data/app/app.filename.apk .

APK — это ZIP архив, достаем оттуда интересующий нас файл classes.dex со скомпилированным кодом.
Будем использовать ассемблер/дизассемблер smali/baksmali для наших грязных дел.
java -jar baksmali-1.3.2.jar classes.dex

На выходе получаем директорию out с кучей файлов *.smali . Каждый из них соответствует файлу .class . Естественно, все обфусцированно по самое не хочу, выглядит эта директория вот так:

Попытаемся понять, где в этой обфусцированной куче «говорится» о рекламе. Сначала я просто сделал поиск с текстом " AdView " (View, отображающий рекламу из AdMob SDK) по всем файлам. Нашелся сам AdView.smali , R$id.smali и некий d.smali . AdView.smali смотреть не очень интересно, R.$id я как-то сначала проигнорировал, и пошел сразу в таинственный d.smali .

Шаг 2. Пойти по неверному пути.
Вот и метод a() в файле d.smali с первым упоминанием AdView (я решил, скриншотом лучше, а то без форматирования это очень уныло читать):

Метод ничего не возвращает, поэтому я, недолго думая, решил просто вставить поближе к началу return-void . Когда я все собрал и запустил, приложение радостно крэшнулось. Лог из adb logcat :

Понятно, что наш AdView в результате манипуляций должным образом не создался. Забудем пока про d.smali .

Похоже, это идентификатор View с рекламой. Поищем, где он используется, сделав поиск по значению 0x7f080006 . Получаем всего два результата: тот же R$id и GreatApp.smali . В GreatApp.smali текст уже гораздо интереснее (комментарии мои):

Видно, что этот идентификатор используется для поиска View (строка 588) и буквально сразу же AdView удаляется с экрана (строка 595). Видимо, удаляется, если пользователь заплатил за отсутствие рекламы? Если посмотреть немного выше, то взгляд цепляется за строчку 558 с «ключевыми словами»:
invoke-static , Lnet/robotmedia/billing/BillingController;->isPurchased(Landroid/content/Context;Ljava/lang/String;)Z

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

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

Как устроен билд APK файла внутри

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

У андроида много удивительных характеристик и одна из них разные архитектуры процессоров такие как ARM64 и x86

Невозможно скомпилировать код, который поддерживает каждую архитектуру. Вот именно поэтому используется Java виртуальная машина.

Понимание Java виртуальной машины

JVM это виртуальная машина, позволяющая устройству запускать код, который скомпилирован в Java байткод

Используя JVM, вы избавляетесь от проблемы с разной архитектурой процессоров.

JVM предоставляет переносимость и она позволяет запускать Java код в виртуальной среде, вместо того, чтобы запускать его сразу «на железе»

Но JVM была создана для систем с большими мощностями по ресурсам, а наш андроид имеет сравнительно мало памяти и заряда батареи.

По этой причине Google создал адаптированную под андроид виртуальную машину, которая называется Dalvik.

Компилируем исходный код

Наш исходный Java код для андроида компилируется в класс файл .class с байткодом с помощью javac компилятора и запускается на JVM

Для котлина есть kotlinc компилятор, который делает совместимый с Java байткод.

Байткод — это набор инструкций, который выполняется на целевом устройстве.

Java байткод — это набор инструкций для Java виртуальной машины.

Андроид виртуальная машина

Каждое андроид приложение работает на своей виртуальной машине. С версий 1.0 до 4.4, это был Dalvik. В андроид 4.4, вместе с Dalvik, Google представил в качестве эксперимента новый андроид runtime, который назывался ART

Сгенерированный класс файл .class содержит JVM Java байткод.

Но у андроида есть свой собственный оптимизированный формат байткода, который называется Dalvik bytecode — это просто инструкции машинного кода для процессора также как и JVM байткод.

Комплияция в .dex файл

Во время компиляции происходит конвертация .class класс файл и .jar библиотеки в один classes.dex файл, который содержит Dalvik байткод.

Команда dx превращает все .class и .jar файлы в один classes.dex файл, который написан с форматом Dalvik байткода.

Dex — это аббревиатура с английского — Dalvik Executable.

ART против Dalvik

C версии 4.4 андроид мигрировал на ART. ART также работает с .dex файлом.

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

ART и Dalvik совместимы, так что приложения разработанные для Dalvik должны работать и на ART.

Компиляция Dalvik (JIT- just in time) имела такие минусы как — быстрая трата батареи, лаги в приложениях и плохой перформанс. В Dalvik трансляция происходит только когда это нужно. Мы открываем новый экран и только в этот момент происходит трансляция, за счет этого установка происходит быстрее, но при этом проседает перформанс.

Это причина по которой Google сделал Android Runtime (ART).

ART — основан на AOT (ahead of time) компиляции, она происходит до того как приложение запустится.

В ART компиляция происходит во время установки приложения. Это ведет к более долгому времени установки, но уменьшает трату батареи и избавляет от лагов, которые были на Dalvik.

Несмотря на то, что Dalvik был заменен на ART, .dex формат файлов еще используется

В андроид 7.0 JIT вернулся. Гибридная среда сочетает фичи как от JIT компиляции так и
от ART

Среда запуска байткода это очень важная часть андроида и она вовлечена в процесс запуска и установки приложения

Каждый этап описанного процесса

Source Code (Исходный код)

Это Java и Kotlin файлы в src пакете.

Resource Files

Файлы находящиеся в директории с ресурсами

AIDL Files

AIDL — аббревиатура Android Interface Definition Language, позволяет вам описать интерфейс межпроцессорного взаимодействия.

AIDL — может использоваться между любыми процессами в андроиде.

Library Modules

Модули библиотек содержат Java или Kotlin классы, компоненты андроида и ресурсы.

Код и ресурсы бибилотеки компилируются и пакуются вместе с приложением.

Поэтому модуль библиотеки может считаться компайл тайм артефактом.

AAR Libraries

Андроид библиотеки компилируются в AAR — android archive файл, который вы можете использовать как зависимость для вашего android app модуля.

AAR файлы могут содержать андроид ресурсы и файл манифеста, что позволяет вам упаковать туда общие ресурсы такие как layouts и drawables в дополнение к Java или Kotlin классам и методам.

JAR Libraries

JAR это Java библиотека и в отличие от AAR она не может содержать андроид ресурсы и манифесты.

Android Asset Packaging Tool

AAPT2 — аббревиатура (Android Asset Packaging Tool) — компилирует манифест и файлы ресурсов в один APK.

Этот процесс разделен на два шага компиляцию и линковку Это улучшает производительность так как если вы поменяете один файл, вам нужно компилировать только его и прилинковать к остальным файлам командой 'link'

AAPT2 может компилировать все типы андроид ресурсов, таких как drawables и XML файлы.

При вызове AAPT2 для компиляции, туда передается по одному ресурсному файлу на каждый вызов

Затем APPT2 парсит файл и генерирует промежуточный бинарный файл с расширением .flat

Фаза линковки склеивает все промежуточные файлы сгенерированные в фазе компиляции и дает нам на выход один .apk файл. Вы также можете сгенерировать R.java файл и правила для proguard в это же время.

resources.arsc

Полученный на выходе .apk файл не включает в себя DEX файл, APK не подписан и не может быть запущен на устройстве.

APK содержит AndroidManifest, бинарные XML файлы и resources.arsc

resource.arsc содержит всю мета информацию о ресурсах, такую как индексы всех ресурсов в пакете

Это бинарный файл и APK который может быть запущен. APK который вы обычно создаете и запускаете не сжат и может быть использован просто посредством размещения в памяти.

R.java файл это выходной файл вместе с APK ему назначен уникальный id, который позволяет Java коду использовать ресурсы во время компиляции.

arsc это индекс ресурса который используется во время запуска приложения

D8 и R8

Начиная с андроид студии 3.1 и далее, D8 был сделан дефолтным компилятором.

D8 производит более маленькие dex файлы с лучшей производительностью, если сравнивать со старым dx.

R8 используется для компиляции кода. R8 это оптимизированная версия D8

D8 играет роль конвертера класс файлов в Dex файлы, а также производит дешугаринг функций из Java 8 в байткод, который может быть запущен на андроиде

R8 оптимизирует dex байткод. Он предоставляет такие фичи как оптимизация, обфускация, удаление ненужных классов.

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

Обфускация имеет и другие преимущества для предотвращения реверс инжиниринга, но основная цель уменьшить размер.

Оптимизация уменьшает размер Dex файла путем переписывания ненужных частей кода и инлайнинга.

С помощью дешугаринга мы можем использовать удобные фичи языка Java 8 на андроиде.

Dex and Multidex

R8 дает на выходе один DEX файл, который называется classes.dex

Если количество методов приложения переваливает за 65,536, включая подключенные библиотеки, то произойдет ошибка при билде</b

The method ID range is 0 to 0xFFFF.

Другими словами, вы можете ссылаться на 65,536, или от 0 до. 65,535, если говорить цифрами

Чтобы избежать этого, нужно внимательно следить за зависимостями своего проекта и использовать R8, чтобы удалять неиспользуемый код, или включать мультидекс (multidex)

Подписывание APK файла

Все Apk файлы требуют цифровую подпись до того как они могут быть установлены на ваш девайс

Для дебаг билдов, андроид студия автоматически подписывает приложение используя дебажный сертификат сгенерированный с помощью android sdk tools.

Дебажный кейстор и дебажный сертификат создаются автоматически

Для релиз билдов вам нужен кейстор, которым вы подпишете свой apk файл. Вы можете создать APK файл в андроид студии через «Generated Signed Apk» опцию.

Примечания

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

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

Введение

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

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

Реверс-инжиниринг android приложений

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

БРИФИНГ

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

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

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

Опять анализ

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

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

Копируем 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. Окно пока не закрываем, оно понадобится позже.

WARNING

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

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

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

<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 и видим байт-код. Прежде чем читать дальше, советую сначала просмотреть список команд. Нам необходимо найти те самые строчки и закоментить их. Вот они:

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

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