Содержание статьи

• Frida
• Пишем код
• Frida CodeShare
• Выводы

Немного словоблудия

Представь, что тебе в руки попал семпл малвари. Ты запускаешь его в эмуляторе и пытаешься проанализировать поведение. Но оказывается, что в эмуляторе он работает совсем не?так, как на реальном устройстве, и никакой подозрительной активности не проявляет: малварь умеет определять, что находится в эмулируемой среде.

Ты об этом догадываешься и поэтому решаешь запустить малварь под дебаггером (предварительно распаковав зловред и?добавив строчку android:debuggable="true" в AndroidManifest.xml), чтобы определить, как именно малварь производит проверку на эмулятор. И снова проблема: она умеет определять, что работает под отладчиком, и просто падает при запуске. Следующий шаг: статический анализ кода с помощью декомпилятора и дизассемблера, правка с целью вырезать куски, проверяющие наличие отладчика?и эмулируемой среды, снова правка кода по причине ошибки и все в таком духе.

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

Frida

Frida — это так называемый Dinamic Instrumentation Toolkit, то есть набор инструментов, позволяющих на лету внедрять собственный код в?другие приложения. Ближайшие аналоги Frida — это знаменитый Cydia Substrate для iOS и Xposed Framework для Android, те самые фреймворки, благодаря которым появились твики. Frida отличается от них тем, что нацелена на быструю правку кода в режиме реального времени. Отсюда и язык jаvascript вместо Objective-C или Java, и отсутствие необходимости упаковывать «твики»?в настоящие приложения. Ты просто подключаешься к процессу и меняешь его поведение, используя интерактивную JS-консоль (ну или отдаешь команду на загрузку ранее написанного скрипта).

Frida умеет работать с приложениями, написанными для всех популярных ОС, включая Windows, Linux, macOS, iOS и даже QNX. Мы же будем использовать ее для модификации приложений?под Android.

Итак, что тебе нужно:

1. Машина под управлением Linux. Можно и Windows, но, когда занимаешься пентестом приложений для Android, лучше использовать Linux.


2. Установленный adb. В Ubuntu/Debian/Mint устанавливается командой sudo apt-get install adb.


3. Рутованный смартфон или эмулятор на базе Android 4.2 и выше. Frida умеет работать и на нерутованном, но для этого?тебе придется модифицировать APK подопытного приложения. Это просто неудобно.

Для начала установим Frida:

$ sudo pip install frida

Далее скачаем сервер Frida, который необходимо установить на смартфон. Сервер можно найти на GitHub, его версия должна точно совпадать с версией Frida, которую мы установили на комп. На?момент написания статьи это была 10.6.55. Скачиваем:

$ cd ~/Downloads
$ wget https://github.com/frida/frida/releases/download/10.6.55/frida-server-10.6.55-android-arm.xz
$ unxz frida-server-10.6.55-android-arm.xz

Подключаем смартфон к компу, включаем отладку по USB (Настройки ? Для разработчиков ? Отладка по USB) и закидываем сервер на смартфон:

$ adb push frida-server-10.6.55-android-arm /data/local/tmp/frida-server

Теперь заходим на смартфон с помощью adb shell, выставляем нужные права на сервер и запускаем его:

$ adb shell
> su
> cd /data/local/tmp
> chmod 755 frida-server
> ./frida-server

Первые шаги

Ок, Frida установлена на комп, сервер запущен на смартфоне (не закрывай терминал с запущенным сервером). Теперь надо проверить, все ли работает как надо. Для этого воспользуемся командой frida-ps:

$ frida-ps -U

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

Для начала попробуем выполнить трассировку системных вызовов. Frida позволяет отследить обращения к любым?нативным функциям, в том числе системные вызовы ядра Linux. Для примера возьмем системный вызов open(), который используется для открытия файлов на чтение и/или запись. Запустим трассировку Телеграма:

$ frida-trace -i "open" -U org.telegram.messenger

Возьми телефон и?немного потыкай интерфейс Телеграма. На экран должны посыпаться сообщения примерно следующего содержания:

open(pathname="/data/user/0/org.telegram.messenger/shared_prefs/userconfing.xml", flags=0x241)

Эта строка означает, что Телеграм открыл файл userconfig.xml внутри каталога shared_prefs в своем приватном каталоге. Каталог shared_prefs в Android используется для хранения настроек, поэтому нетрудно?догадаться, что файл userconfig.xml содержит настройки приложения. Еще одна строка:

open(pathname="/storage/emulated/0/Android/data/org.telegram.messenger/cache/223023676_121163.jpg", flags=0x0)

Здесь все еще проще. Телеграм агрессивно кеширует загруженные данные, поэтому для отображения картинки он взял ее из кеша.

open(pathname="/data/user/0/org.telegram.messenger/shared_prefs/stats.xml", flags=0x241)

Еще один файл в каталоге shared_prefs. Судя по?всему, какая-то статистика использования.

open(pathname="/dev/ashmem", flags=0x2)

Выглядит странно, не так ли? На самом деле все просто. Файл /dev/ashmem виртуальный, он используется для обмена данными между процессами и системой с помощью IPC-механизма Binder. Проще говоря, эта строка означает, что Телеграм?обратился к Android, чтобы выполнить какую-то системную функцию или получить информацию. Такие строки можно смело пропускать.