Реверс-инжиниринг
Вы потеряли исходник своей программы и вам нужно восстановить код. Вы скачали программу с вирусом и хотите узнать, что он делает.
Программы под 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) злоумышленник должен каким-то образом связать пользователя зараженного компьютера и зараженного телефона, чтобы знать, от каких учетных данных он-лайн банкинга данный код подтверждения;
В силу своих размеров и очевидности производимой деятельности такой образец хорошо подходит для демонстрации базовых приемов разбора вредоносных программ под Андроид.
Источник
Инструменты для взлома и реверсинга приложений Android
За многие года существования Андроид разработчики приложений и те, кто эти приложения взламывает, обзавелись массой инструментов, направленных друг против друга. О том, какими способами можно защитить свое приложение, мы уже рассказывали, а сегодня у нас обзор инструментов для взлома и реверсинга Андроид приложений.
Все инструменты для анализа и реверсинга программ (не только для Android) можно разделить на две группы:
- Статический анализ — дизассемблеры, декомпиляторы, деобфускаторы и любые другие утилиты, которые работают с кодом, не запуская его.
- Динамический анализ — инструменты, с помощью которых приложение можно запустить на виртуальном или реальном устройстве и проанализировать его поведение.
В обеих группах есть утилиты, как для начинающих (запустил — получил список уязвимостей), так и для опытных пентестеров. В этой статье мы расскажем про все популярные программы для реверс инжиниринг apk, которые подойдут для новичков и для профи.
Статический анализ
Итак, для начала речь пойдет об инструментах статического анализа. Каждый кто пытается взломать приложение должен иметь в своем арсенале хотя бы два из них. Это декомпилятор и дизассемблер.
- Декомпилятор нужен, чтобы перегнать байт-код Dalvik обратно в код Java и с его помощью разобраться, как работает приложение.
- Дизассемблер транслирует байт-код в гораздо более низкоуровневый код Smali (местный ассемблер), в котором труднее разобраться, но зато он всегда корректен настолько, что его можно собрать обратно в приложение. Этой особенностью можно воспользоваться, например, чтобы внедрить в приложение собственный код.
Также вам пригодится деобфускатор. Он сделает декомпилированный код немного более читаемым.
Первая софтина в нашем списке инструментов для взлома программ — декомпилятор Jadx. Это активно развиваемый открытый декомпилятор, который выдает достаточно неплохой код Java на выходе и даже имеет функцию деобфускации кода. Работать с ним просто: запускаете Jadx-gui, с его помощью выбираете APK-файл приложений и видите иерархию пакетов и файлы с исходниками на Java.
Jadx может работать и в режиме командной строки. Например, следующая команда декомпилирует приложение example.apk и поместит полученный код Java в каталог out:
Более того, Jadx может дополнительно сгенерировать файлы build.gradle, чтобы исходники можно было импортировать в Android Studio:
Собрать приложение из них не получится, зато анализировать код будет гораздо удобнее.
Jadx в черном
Apktool
Второй инструмент, который должен обязательно быть в списке инструментов для реверс инжиниринга Android приложений, — это Apktool. Его назначение — разборка и сборка приложений. При этом термин «разборка» подразумевает дизассемблирование кода приложения в файлы формата Smali, а также декомпрессию ресурсов и файла AndroidManifest.xml.
С помощью Apktool можно разобрать приложение, проанализировать дизассемблерный код, внести в него правки и собрать обратно.
Разбираем приложение с помощью Apktool
APKiD
Эта небольшая утилита понадобится вам, когда вы заметите, что Jadx не в состоянии декомпилировать приложение. В большинстве случаев это значит, что приложение было обфусцировано или упаковано с помощью специальных инструментов. APKiD позволяет узнать, какие конкретно инструменты были использованы, выяснить, было ли приложение пересобрано с помощью Apktool и используются ли в нем какие-то другие техники для защиты от дизассемблирования/декомпиляции и запуска в виртуальной машине.
APKiD далеко не всегда работает корректно, а в некоторых случаях вообще не выводит никакой информации на экран. Но он может помочь, если вы в тупике — вывод утилиты понятный. Например:
- anti_debug : Debug.isDebuggerConnected() check — проверка, подключен ли дебаггер с помощью метода isDebuggerConnected;
- anti_vm : Build.MANUFACTURER check — проверка производителя смартфона, чтобы понять, что находитесь в виртуальной машине.
Но есть одно неочевидное поле: compiler. Оно обычно содержит dx или dexlib. Dx — стандартный компилятор Android SDK, а dexlib — это библиотека сборки файлов DEX из Apktool. Проще говоря, если в поле compiler находится dexlib, значит, приложение было пересобрано с помощью Apktool или аналогичного инструмента.
Результат работы APKiD для нескольких образцов малвари
Simplify
Что, если APKiD сообщает о применении обфускатора, а при попытке изучить код вы сталкиваетесь с зашифрованными строками? В этом случае вам нужен деобфускатор, который сможет сделать код более читаемым. Абсолютное большинство деобфускаторов, которые вы найдете в интернете, умеют бороться только с одним или несколькими обфускаторами, зачастую устаревших версий.
Simplify — универсальный деобфускатор. Вместо того чтобы искать в коде знакомые паттерны, он запускает код в виртуальной среде и дает ему возможность сделать все самому. В процессе исполнения код сам расшифрует зашифрованные строки, укажет на места, которые никогда не будут исполнены (обфускация с помощью мертвого кода), и укажет на реальный тип объектов, полученных с помощью рефлексии (а это позволит выполнить дерефлексию).
Из-за особенностей реализации виртуальной машины Simplify редко способен проанализировать все приложение целиком. Поэтому его стоит использовать для деобфускации отдельных методов и классов (это можно сделать с помощью флага -it):
[/crayon] До и после обработки Simplify
DeGuard
Simplify поможет, если приложение было пропущено через мощный обфускатор. Однако большинство программистов не обременяют себя применением чего-то более сложного, чем входящий в состав Android Studio ProGuard. А ProGuard — это оптимизатор, в котором функция обфускации появилась как побочный эффект. Единственное, чем он запутывает реверсера Андроид приложений, — это измененные на бессмысленный набор букв имена классов, методов и полей.
Разобраться в обфусцированном с помощью ProGuard коде не так уж и сложно, но сложнее, чем в совсем не обфусцированном (в два раза сложнее, если верить исследованиям). Поэтому даже для ProGuard существуют деобфускаторы.
DeGuard — наиболее интересный из них. Это веб-сервис, созданный в Высшей технической школе Цюриха. С помощью нейросетей он способен восстановить (а точнее, предсказать) оригинальные имена пакетов, классов, методов и полей. Одна проблема: нередко деобфусцированный код запутывает еще больше, чем оригинал.
Пример деобфускации с помощью DeGuard
Bytecode Viewer
А это решение класса «все в одном». Bytecode Viewer сочетает в себе функции Jadx, Apktool и еще нескольких инструментов. Он умеет дизассемблировать приложения, декомпилировать их с помощью пяти различных движков декомпиляции (JD-Core, Procyon, CFR, Fernflower, Krakatau), расшифровывать строки с помощью трех движков дешифрования, компилировать приложение обратно из декомпилированного кода (с помощью Ranino Compiler) и даже искать зловредный код!
Многие реверсеры APK рекомендуют использовать именно этот инструмент для анализа приложений. Их аргумент в том, что любой другой декомпилятор (тот же Jadx или популярный JD-GUI) может сломаться об обфусцированный или специальным образом написанный код и просто не покажет его. В то же время Bytecode Viewer, благодаря наличию сразу пяти движков декомпиляции, имеет больше шансов декомпилировать такое приложение.
На самом же деле не все так радужно. Bytecode Viewer — это кое-как работающая сборная солянка из различных открытых инструментов. Да, в нем множество движков декомпиляции, но, похоже, автор перестал следить за своим произведением. Текущая версия Bytecode Viewer уже не может открыть большинство APK.
Скриншота не будет по причине неработоспособности инструмента.
Закончим рассказ о статическом анализе на инструменте QARK. Это утилита для автоматического поиска уязвимостей в приложениях. Достаточно натравить ее на нужный APK или каталог с исходниками, и QARK проанализирует манифест, декомпилирует и проанализирует исходники и даже попробует создать эксплоит для взлома приложения с помощью найденных уязвимостей.
Пользоваться QARK очень просто: запускаете QarkMain.py, отвечаете на несколько вопросов и получаете отчет в формате HTML в каталоге quark/report.
Как и другие автоматизированные инструменты, QARK не может точно предсказать наличие уязвимости, он лишь высказывает предположение о ее существовании и дает реверсеру приложения намек, в какую сторону следует копать. Поэтому не стоит надеяться, что вы просто установите QARK и сразу начнете стричь купоны на пентесте приложений. Без матчасти никуда.
Отчет QARK
Динамический анализ
Статический анализ приложения не всегда позволяет раскрыть все подробности его поведения. Код может быть зашифрован упаковщиком, приложение может докачивать свои компоненты из интернета, расшифровывать строки только во время исполнения и делать другие вещи, которые нельзя увидеть, читая код.
Обнаружить такие вещи можно с помощью динамического анализа, то есть запустив приложение на реальном устройстве или в эмуляторе и изучив его поведение с помощью специальных инструментов. Именно это, кстати, происходит в Google Play, когда разработчик заливает новую версию приложения. Серверы Google запускают его в виртуальной среде и, если приложение делает какие-то неправомерные действия, запрещает его публикацию.
Frida
Начнем с короля всех инструментов динамического анализа, трассировки и модификации приложений — с Frida. Это так называемый Dynamic Instrumentation Toolkit, набор инструментов, позволяющих на лету внедрять собственный код в другие приложения. Внедрив код, можно выполнить полную трассировку приложения, перехватить функции шифрования, записи файлов на диск и вообще сделать с приложением все что угодно.
У нас уже была подробная статья о Frida, поэтому не будем повторяться. Скажем только, что у Frida есть репозиторий с готовыми скриптами, которые могут тебе пригодиться:
-
- fridantiroot — комплексный скрипт, позволяющий отключить проверки на root;
- Universal Android SSL Pinning Bypass — обход SSL Pinning;
- dereflector — скрипт Frida для дерефлексии Java-кода (превращения непрямых вызовов методов в прямые).
frida —codeshare pcipolloni/universal-android-ssl-pinning-bypass-with-frida -f com.example.app
Трассировка Telegram с помощью Frida
Objection
Frida — очень популярный инструмент. На его основе было создано множество более высокоуровневых утилит. Objection — одна из них. Она позволяет внедриться в приложение iOS или Android и провести анализ его приватного каталога, памяти, классов, методов, извлечь содержимое базы SQLite, обойти SSL-пиннинг.
Главное преимущество Objection в том, что она дает возможность «войти» в приватный каталог приложения точно так же, как это позволяет сделать устройство с root-доступом. Но в этом же ее недостаток: большинство задач, для которых предназначена Objection, легко решаются с помощью adb, команды sqlite (при наличии root) и общедоступных скриптов Frida.
Консоль Objection
Inspeckage
Inspeckage — еще один высокоуровневый инструмент динамического анализа приложений. У него огромное количество возможностей: он может получать информацию о полномочиях, активностях, контент-провайдерах и сервисах, умеет перехватывать обращения к SQLite, HTTP-серверам, файловой системе, буферу обмена, криптографическим функциям, запускать активности, подключаться к ContentProvider’aм и выполнять спуфинг местоположения.
Все это можно сделать, используя удобный веб-интерфейс. Но перед этим на смартфоне необходимо получить права root, а затем установить Xposed Framework (который как раз и позволяет Inspeckage выполнять перехват управления).
Главный экран Inspeckage
Drozer
На закуску у нас drozer — мощный инструмент для выполнения типичных задач пентеста приложений. Drozer позволяет получить информацию о приложении, запустить его активности, подключиться к ContentProvider’у, отправить сообщения сервису — в общем, сделать все, чтобы вытащить из приложения информацию или заставить его сделать то, что нам нужно.
Типичный воркфлоу drozer выглядит так. Сначала получаем информацию о приложении:
Источник