Когда мы говорим о взломе и модификации чужих приложений, то чаще всего подразумеваем использование декомпилятора, дизассемблера и отладчика. Но есть инструмент, который работает совершенно иначе. Это Frida, тулкит, позволяющий внедриться в процесс и переписать его части на языке JavaScript.
Представь, что тебе в руки попал семпл малвари. Ты запускаешь его в эмуляторе и пытаешься проанализировать поведение. Но оказывается, что в эмуляторе он работает совсем не так, как на реальном устройстве, и никакой подозрительной активности не проявляет: малварь умеет определять, что находится в эмулируемой среде.
Ты об этом догадываешься и поэтому решаешь запустить малварь под дебаггером (предварительно распаковав зловред и добавив строчку android:debuggable="true"
в AndroidManifest.xml
), чтобы определить, как именно малварь производит проверку на эмулятор. И снова проблема: она умеет определять, что работает под отладчиком, и просто падает при запуске. Следующий шаг: статический анализ кода с помощью декомпилятора и дизассемблера, правка с целью вырезать куски, проверяющие наличие отладчика и эмулируемой среды, снова правка кода по причине ошибки и все в таком духе.
А теперь представь, что у тебя есть инструмент, позволяющий прямо во время работы приложения отключить все эти проверки, просто переписав проверочные функции на JavaScript. Никаких дизассемблерных листингов smali, никаких правок низкоуровневого кода, никаких пересборок приложения; ты просто подключаешься к работающему приложению, находишь нужную функцию и переписываешь ее тело. Недурно, не так ли?
Frida — это так называемый Dinamic Instrumentation Toolkit, то есть набор инструментов, позволяющих на лету внедрять собственный код в другие приложения. Ближайшие аналоги Frida — это знаменитый Cydia Substrate для iOS и Xposed Framework для Android, те самые фреймворки, благодаря которым появились твики. Frida отличается от них тем, что нацелена на быструю правку кода в режиме реального времени. Отсюда и язык JavaScript вместо Objective-C или Java, и отсутствие необходимости упаковывать «твики» в настоящие приложения. Ты просто подключаешься к процессу и меняешь его поведение, используя интерактивную JS-консоль (ну или отдаешь команду на загрузку ранее написанного скрипта).
Frida умеет работать с приложениями, написанными для всех популярных ОС, включая Windows, Linux, macOS, iOS и даже QNX. Мы же будем использовать ее для модификации приложений под Android.
Итак, что тебе нужно:
sudo apt-get install adb
.Для начала установим 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, чтобы выполнить какую-то системную функцию или получить информацию. Такие строки можно смело пропускать.
Материалы из последних выпусков можно покупать отдельно только через два месяца после публикации. Чтобы продолжить чтение, необходимо купить подписку.
Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке
1 год6490 р. Экономия 1400 рублей! |
1 месяц720 р. 25-30 статей в месяц |
Уже подписан?
Читайте также
Последние новости