Реверсинг приложений под Android. Разбираемся с функционалом
Сегодня мы продолжим изучение реверсинга приложений под Android. В предыдущей статье мы рассмотрели основы устройства приложений, установили необходимые инструменты и разобрали небольшой пример. В этой статье мы продолжим разбирать практические примеры.
Байт-код DEX
В предыдущей статье мы начали рассматривать пример ~/samples/ThaiCamera.apk. Теперь, когда у нас есть отправные точки, с которых, можно было бы начать поиск подозрительного кода, давайте продолжим разбирать этот артефакт и поговорим о формате DEX.
DEX означает исполняемые файлы байт-кода Android (APK) в виде файлов Dalvik Executable (DEX), которые содержат скомпилированный код, используемый для запуска вашего приложения.
Спецификация исполняемого файла Dalvik ограничивает общее количество методов, на которые можно ссылаться в одном файле DEX, до 65 536 (64 КБ), включая методы каркаса Android, библиотечные методы и методы в вашем собственном коде. Для того, чтобы преодолеть этот предел, необходимо настроить процесс сборки приложений для создания более одного файла DEX, известного как Multidex.
Dex — это имя формата файла и кодировки, с которой компилируется код Java Java. Ранние версии Android загружали и исполняли двоичные файлы dex непосредственно на виртуальной машине Dalvik. В более поздних версиях Android используется Android Runtime (ART), которая обрабатывает файлы dex как промежуточное представление и выполняет дальнейшие компиляции на нем до запуска приложения.
Таким образом, Dex — очень старый формат файла с точки зрения продолжительности жизни смартфонов и предназначен для устройств, основная память которых измерена в десятках мегабайт. Но, к сожалению, эти дизайнерские ограничения тех дней остались с нами по сей день.
Обратный инжиниринг байт-кода DEX
Продолжим реинжиниринг приложения ~/samples/ThaiCamera.apk, чтобы определить, не занимается ли оно мошенничеством с SMS-сообщениями премиум-класса.
Чтобы мошенничать с SMS-сообщениями премиум-класса, приложение должно отправить SMS-сообщение премиум-класса (номера телефонов премиум-класса обычно являются короткими кодами) без указания номера телефона, на который отправляется SMS-сообщение, стоимости SMS-сообщения и согласия пользователя.
Чтобы отметить приложение как вредоносное, вам необходимо определить, оно:
Отправляет SMS-сообщения;
Это SMS-сообщение отправляется на премиум-номер;
И при этом, SMS-сообщение отправляется на премиум-номер только после согласия пользователя.
Очевидно, что это не исчерпывающий список признаков вредоноса, использующего премиум номера, но для начала нам будет достаточно этого.
Перейдем к практике. Если jadx еще не запущен, запустите jadx, открыв терминал в виртуальной машине и выполнив команду jadx-gui в терминале, и откройте ThaiCamera.apk в графическом интерфейсе jadx.
Помните, что манифест доступен в разделе «Resources», нажав на AndroidManifest.xml. Чтобы проанализировать байт-код DEX, вы можете щелкнуть по классам на вкладке Source Code, чтобы открыть каждый класс. jadx — это скорее декомпилятор, чем дизассемблер, поэтому он декомпилирует байт-код DEX обратно в Java. Декомпилированная Java не будет выглядеть точно так же, как при ее написании разработчиком, однако часто она довольно близка к функционально корректной.
Отправка сообщений
Начнем анализировать классы, которые мы определили в качестве отправных точек в предыдущей статье. Если вы имеете опыт разработки на Java, относитесь к обратному проектированию как к отладке. Те, кто хорошо знаком с разработкой под Android, наверняка знают, какие элементы кода отвечают за отправку SMS. Ну, а все остальные могут прибегнуть к помощи поиска по SendMessage.
Интересным является SendMessage. Собственно, на обнаружении этой функции мы и остановились в предыдущей статье. Теперь нам необходимо разобраться с тем, как собственно все это работает.
Итак, представленная выше процедура SendMessage производит непосредственную отправку SMS сообщения, но для того, чтобы отправить сообщение необходимо наличие прав, которых строго говоря, по умолчанию быть не должно.
Здесь обратим внимание на onCreate, находящийся рядом. Здесь мы пытаемся получить информацию о SIM карте, в частности о номере, IMEI и т.д.
Здесь же мы видим интересную процедуру loginByPost. В ней осуществляется обращение к некоторому ресурсу 139.59.107.168. В качестве аргумента этому узлу передается номер телефона жертвы.
Обычный поиск по данному адресу ничего особо интересного не выдает, разве что, то что этот IP сингапурского провайдера.
Поиск по этому адресу на Virustotal дает более интересные результаты, подтверждающие, что наш Thai_camera является вредоносным файлом. Из соображений безопасности не рекомендуется на Virustotal отправлять целиком файлы для проверки, во избежание утечки их содержимого. Вместо этого лучше отправить контрольную сумму или какой-то известный факт из жизни подозрительного файла. В данном случае этим фактом является найденный IP.
Таким образом наш вредонос сообщает своему хозяину телефон зараженного устройства для последующего учета.
Запрос прав
Вернемся к отправке SMS. Выполнить запросы на отправку сообщения в отсутствии нужных прав не получится, но специально для такого случая мы можем запросить эти права у пользователя. Для этого имеется специальная процедура onRequestPermissionsResult.
Собственно, на этом изучение нашего артефакта можно считать завершенным. Желающие могут проверить работу этого семпла на реальном устройстве.
Заключение
В этой небольшой статье мы завершили рассмотрение первого артефакта. Нашей основной задачей было посмотреть, как взаимодействуют между собой элементы кода, реализующие вредоносную функциональность. В следующей статье мы продолжим тему реверсинга и поговорим о том, как можно выявить уязвимости в приложении под Android.
Больше практических навыков, методик и инструментов для обеспечения информационной безопасности вы можете получить в рамках практических онлайн-курсов от экспертов отрасли.
