Dex to jar android

Содержание

Реверс-инжиниринг
Apktool
dex2jar
JD-GUI
Burp Suite
Разбор вредоносной программы
Activation
SmsReciever
MainService
ServerSession
Dex to jar android
Реверс-инжиниринг android приложений
БРИФИНГ
Инструментарий
Введение
Декомпиляция
Начало анализа
Компиляция и установка
Опять анализ
Примечания

Реверс-инжиниринг

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

Программы под Android распространяются в архивах. Эти архивы имеют расширение «.apk». Такие файлы не шифруются и являются по сути файлами «zip». Можете переименовать apk-файл в zip, чтобы убедиться в этом.

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

Распаковав архив, вы можете увидеть структуру приложения и встретить знакомые файлы. И даже извлечь некоторые файлы для просмотра. К примеру, в папке res/drawable-hdpi-v4 я нашёл свою картинку pinkhellokitty.png. Казалось бы, вот оно — счастье. Но погодите радоваться. Если с изображениями проблем нет, то с чтением 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

Burp Suite позволит вам просматривать HTTP-траффик на эмуляторе. Скачайте последнюю версию.

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

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

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

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

Разумеется, вы должны подставить свои пути. В Linux команда будет такой же с очевидными отличиями (не будет букв дисков и расширения «exe» у утилиты). Для большего удобства вывод можно перенаправить в файл:

В файле нужно найти секцию «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

Этот класс срабатывает при приходе СМС-сообщения, событие onReceive().

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

MainService

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

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

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

String str2 = localSmsMessage.getMessageBody(); — тело сообщения помещается в переменную str2

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

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

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

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

ServerSession

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

и большой метод postRequest(), который вызывался из класса MainService. Несмотря на размер, задача postRequest() проста — отправить на сервер по ссылке, возвращаемой методом initUrl(), данные, добавив пары из массива, собранного в MainService. То есть всего лишь обратиться по ссылке:

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

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

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

Источник

Dex to jar android

Project move to GitHub

_	Mirror	Wiki	Downloads	Issues
gh	https://github.com/pxb1988/dex2jar	Wiki	Releases	Issues
sf	https://sourceforge.net/p/dex2jar	old	old	old
bb	https://bitbucket.org/pxb1988/dex2jar	old	old	old
gc	https://code.google.com/p/dex2jar	old	old	old

Tools to work with android .dex and java .class files

dex-reader/writer: Read/write the Dalvik Executable (.dex) file. It has a light weight API similar with ASM.
d2j-dex2jar: Convert .dex file to .class files (zipped as jar)
smali/baksmali: disassemble dex to smali files and assemble dex from smali files. different implementation to smali/baksmali, same syntax, but we support escape in type desc «Lcom/dex2jar\t\u1234;»
other tools: d2j-decrypt-string

Источник

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

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

БРИФИНГ

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

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

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

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

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

Apk Manager
dex2jar
jd-gui

Введение

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

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

Все манипуляции с apk мы будем проводить с помощтю утилиты Apk Manger. Это эдакий единый фронт-енд для набора библиотек, работающих с apk. Напомню, у вас должны быть установлены драйвера для девайса и включен режим USB-debugging. Приступим.

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

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

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

.

#iput-object v1, p0, Lcom/rafoid/multimountsdcard/widget/MultiMountSDCardConfigure;->e:Lcom/android/vending/licensing/j;

#new-instance v1, Lcom/android/vending/licensing/m;

#new-instance v2, Lcom/android/vending/licensing/v;

#new-instance v3, Lcom/android/vending/licensing/h;

#sget-object v4, Lcom/rafoid/multimountsdcard/widget/MultiMountSDCardConfigure;->d:[B

#invoke-virtual , Lcom/rafoid/multimountsdcard/widget/MultiMountSDCardConfigure;->getPackageName()Ljava/lang/String;

#move-result-object v5

#invoke-direct , Lcom/android/vending/licensing/h;-> ([BLjava/lang/String;Ljava/lang/String;)V

#invoke-direct , Lcom/android/vending/licensing/v;-> (Landroid/content/Context;Lcom/android/vending/licensing/n;)V

#const-string v0, «MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCg. «

#invoke-direct , Lcom/android/vending/licensing/m;-> (Landroid/content/Context;Lcom/android/vending/licensing/k;Ljava/lang/String;)V

#iput-object v1, p0, Lcom/rafoid/multimountsdcard/widget/MultiMountSDCardConfigure;->f:Lcom/android/vending/licensing/m;

#iget-object v0, p0, Lcom/rafoid/multimountsdcard/widget/MultiMountSDCardConfigure;->f:Lcom/android/vending/licensing/m;

#iget-object v1, p0, Lcom/rafoid/multimountsdcard/widget/MultiMountSDCardConfigure;->e:Lcom/android/vending/licensing/j;

#invoke-virtual , Lcom/android/vending/licensing/m;->a(Lcom/android/vending/licensing/j;)V

.

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

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

Для этого будем использовать уже знакомый нам Apk Manager.

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

Опять анализ

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

b = localProgressDialog;

.

#invoke-static , Landroid/app/ProgressDialog;->show(Landroid/content/Context;Ljava/lang/CharSequence;Ljava/lang/CharSequence;ZZ)Landroid/app/ProgressDialog;

#move-result-object v0

#iput-object v0, p0, Lcom/rafoid/multimountsdcard/widget/MultiMountSDCardConfigure;->b:Landroid/app/ProgressDialog;

.

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;

>

.

.method public onStart(Landroid/content/Intent;I)V

.locals 3

#sget-object v0, Lcom/rafoid/multimountsdcard/widget/MultiMountSDCardWidget;->b:Ljava/lang/Boolean;

#invoke-virtual , Ljava/lang/Boolean;->booleanValue()Z

#move-result v0

#if-eqz v0, :cond_0

const/4 v0, 0x0

:goto_0

invoke-static , Ljava/lang/Boolean;->valueOf(Z)Ljava/lang/Boolean;

move-result-object v0

invoke-static , Lcom/rafoid/multimountsdcard/widget/MultiMountSDCardWidget;->a(Landroid/content/Context;Ljava/lang/Boolean;)Landroid/widget/RemoteViews;

move-result-object v0

new-instance v1, Landroid/content/ComponentName;

sget-object v2, Lcom/rafoid/multimountsdcard/widget/MultiMountSDCardWidget;->a:Ljava/lang/Class;

invoke-direct , Landroid/content/ComponentName;-> (Landroid/content/Context;Ljava/lang/Class;)V

invoke-static , Landroid/appwidget/AppWidgetManager;->getInstance(Landroid/content/Context;)Landroid/appwidget/AppWidgetManager;

move-result-object v2

invoke-virtual , Landroid/appwidget/AppWidgetManager;->updateAppWidget(Landroid/content/ComponentName;Landroid/widget/RemoteViews;)V

return-void

#:cond_0

const/4 v0, 0x1

goto :goto_0

.end method

.

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

Примечания

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

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

Источник