Эта статья — оригинальная, а не Copy/Paste и не машинный перевод. При копировании прошу ссылаться.

Иллюстрации оригинальные и являются интеллектуальной собственностью @themegaera. Спасибо ей, что нашла время в плотном графике учебы.

Предисловие.

Анализ приложений исключительно в позновательных целях - это очень творческое дело. И, хотя 90% времени уходит на вообщем то рутинную работу, но вот остальные 10% - это наверное то, что заставляет людей делать ставки или играть в рулетку - азарт и бесконечная вера в удачу. Не всегда срабатывает - да. Но уж если срабатывает, то понимаешь, что такое настоящее удовольствие.
Теперь, уже на третий год моей работы на этом направлении, складывается определенная общая картина. И скажу так - соревнование защита-нападение в мире приложений Android - это всегда дуэль. Причем противники здесь могут использовать всю свою фантазию практически без ограничений. Да, возможно набор средств и ограничен, но их комбинации бесконечны.
Иногда случается и такое, как на экзамене - готовишься к чему-то сложному, пишешь шпаргалки, а все оказывается легко и просто. Вот один такой случай.

Исходные данные. Добыча.

Приложение очень крупной, с точки зрения прохождение через нее денежных потоков, компании. Суть приложения в том, чтобы обеспечивать верификацию пользователя при выполнении важных действий со своим счетом. Основное приложение работает на десктопе в браузере. Но, когда необходимо выполнить важную операцию, в браузере появляется запрос на верификацию. Пользователь должен открыть приложение на телефоне, после чего приложением будет собран определенный набор данных и отправлен на сервер. Сервер и решит - настоящий это пользователь или нет. Если нет - то транзакция не пройдет. Я не описываю все тонкости, но основная суть такая.
Приложение защищено и не работает на эмуляторе, на устройствах с root, и вообще, при любом отклонении, выдает сообщение о наличии угрозы и закрывается.
Цель исследования - выяснить возможность автоматического запуска приложения и верификации с заранее заданными параметрами.

Исходные данные. Защита.

Как обычно то, что у нас есть в начале пути - это файл apk, полученный либо с ресурсов типа apkmirror, либо непосредственно вытянутый из телефона через adb и собранный из частей в один. Теперь уж не разделенные apk - большая редкость.
Первое, что я, как правило, использую для анализа - это утилита apkid. Очень полезный инструмент. Практически это магический шар-предсказатель. Позволяет без вскрытия получить общее представление о том, что ждет исследователя в будущем.
В данном случае, мне было предсказано, что впереди меня ждет Appdome.

Если кто не в курсе, то Appdome - это еще одна разновидность "не имеющей аналогов" системы защиты мобильных приложений. В том числе и приложений для ОС Android, которая изначально была создана корпорацией Google так, чтобы эту самую защиту максимально усложнить.
По сути Appdome зарабатывает огромные деньги на том, что предлагает разработчикам ПО такой амулет, который, если его наложить на продукт, способен защитить этот продукт от разнообразных форм нечисти. При этом, отдельным текстом, утверждается, что изменений в код исходного продукта не вносится. В общем - Чудо из Чудес. Но при этом разработчик, зачем-то должен передать в Appdome свое хранилище Keystore с паролями к ключам.
В общем - шаманство 80-го уровня. Но, судя по финансовым результатам деятельности Appdome, многие, как это и свойственно любому человеку - верят.
Если отвлечься от маркетинга, то Appdome - это еще один вариант попытки создать комплексную защиту приложений, на основании всего имеющегося в наличии мирового опыта. То же самое, что и Dexprotector, о котором я писал раньше, только - вид сбоку.
Очевидно, что от продукта, в который вложено много денег потребитель вправе ожидать исполнения своих ожиданий. Но всегда ли так бывает?
На сайте Appdome Заказчик может выбрать от каких типов угроз он хочет защитить свое приложение. В соответствии с правилами современного маркетинга все угрозы разбиты на составляющие, защита от каждой из которых продается отдельно. Таким образом заказчик может натыкать галок в соответствии со своим бюджетом.

Вот примерный список угроз, которые обещает поймать Appdome:

• целостность файлов приложения. Сравниваются контрольные суммы dex файлов и библиотек со значениями из базы данных.

• проверка на наличие root на телефоне

• проверка на эмулятор

• проверка на подключение с использованием adb

• проверка на включение опции "для разработчика" в настройках телефона

• проверка на Exposed

• проверка на Frida

Некоторые приемы, применяемые в Appdome для защиты данных приложения:

• шифрование библиотек

• кодирование строковых констант

• шифрование Shared Preferences и другого содержимого приватной папки приложения

Вся информация о выбранных Заказчиком угрозах помещается в базу данных SQLite и конечно тоже шифруется.
Основа защитного механизма Appdome - это библиотека libloader.so. Ниже показан принципиальный алгоритм работы исследуемого приложения на которое наложена защита Appdome:

Если словами, то работает так: При инициализации приложения (класс Application) загружается библиотека libloader.so ( то есть уже изменяется исходный код )) ). Эта библиотека подцепляет базу данных, в которой хранится вся информация, связанная с Appdome. После этого libloader.so проверяет себя на целостность, сравнивая контрольную сумму из базы данных с контрольной суммой непосредственно файла. Если они не совпадают, то происходит мгновенный Segmentation Fault (на схеме - exit()) и приложение закрывается.
Если с CRC все хорошо, то libloader.so начинает проверки тех угроз, которые купил Заказчик ( список их есть в базе данных) По окончанию проверок формируется некий вердикт. Если угроз не обнаружено запускается штатный алгоритм основной бизнес-логики приложения ( в нашем случае обобщенно - метод getAndSendInfo()). Appdome больше не вмешивается в работу приложения до тех пор, пока не появится угроза. Для этой цели в приложении инициализируются Service и Broadcat Receiver, которые соответственно отправляет и получает уведомления в случае, если вы например, включите отладку во время работы приложения. Если угрозы обнаружены, то libloader отправляет описание угрозы в интегрированный Event Tracker Mixpanel и показывает Toast с сообщением об угрозе. После этого ( примерно через 10 секунд после запуска приложения) libloader убивает процесс приложения.

И что с этим всем делать?

Вариантов много, и каждый из них ведет к цели. Разница только во времени и инструментах.
ВРЕМЯ !!!
Вот оно - Решение в данном конкретном случае.
А давайте сделаем так:

Мы просто запустим бизнес-логику сами. Не дожидаясь вердикта от Appdome. Прямо из метода onCreate нашей MainActivity и запустим. В конце метода onCreate вызовем метод getAndSendInfo(). А что нам мешает это сделать то? Ничего не мешает.
И, опа! - верификация пройдена.

Разбор полетов.

Как так то?
А суть, как вы уже поняли во времени. Время, черт его побери!
Время, через которое Appdome убьет процесс - примерно 10 секунд от запуска приложения. А время, за которое приложение собирает и отправляет данные при штатно работающей сети - 5 секунд.
А то, что приложение закроется на 10-й секунде даже и хорошо - нам не нужно его закрывать. Пусть Appdome работает за нас.
Вообще когда я это сделал, то у меня возникло странное ощущение раздвоения алгоритмов - получется, что в данном случае приложение работает отдельно от защиты, а защита - отдельно от приложения. Как в параллельных мирах - одно на другое не влияет.

Задачи выполнены:

• Нужно было автоматизировать запуск приложения. Мы его и запускаем с десктопа через adb. Appdome adb видит, но сделать ничего не успевает.

• Нужно подставлять свои параметры в запрос верификации. Дак ведь теперь у нас теперь root права на телефоне. Сохраняем файл json с необходимыми параметрами на телефон, а в приложении при запуске эти параметры считываем и подставляем в запрос. Appdome видит root, но опять таки сделать ничего не может.

Заключение.

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

Суть статьи в том, чтобы сказать начинающим аналитикам, да и вообще всем, кто сталкивается с нерешаемой, на первый взгляд, задачей: Не верьте глазам своим - "глаза боятся, а руки делают" - Народная мудрость. А Народ, тем более на Руси, всегда смекалистый был и есть. Смело беритесь за самые сложные задачи, не оглядываясь на громкие названия компаний.

Чем крупнее компания - тем больше в ней бардака. И разработчики, и и тестировщики, и специалисты по защите информации в крупных компаниях сидят на окладах и постепенно расслабляются и начинают лениться и халтурить. А иногда неграмотный "эффективный" менеджер просто берет и покупает защиту, совершенно не зная как ее правильно применить. Таких продуктов даже мне, за столь небольшой период времени попалось не мало.
Что до Appdome - я устал оправдывать для себя эти компании. Мол они делают хороший продукт, просто пользователи его плохо применяют. Нет. Все не так.
Просто в Appdome какой-то менеджер принял решение, что для того чтобы Заказчик видел, что Appdome работает нужно непременно вывести на экран сообщение с описанием найденной угрозы. А разработчик, которому дали задание это реализовать, просто заложил временнУю задержку для этого сообщения.
Ну вот скажите - зачем пользователю знать какая именно угроза привела к остановке приложения? Вот мне, как аналитику это действительно может быть интересно. А Заказчику вообще важнее чтобы приложение просто не запускалось.

Кстати, взять тот же Dexprotector - там то приложение просто закрывается без всяких сообщений. Видимо у них решение принимал все таки технарь, а не маркетолог.

Технаря - в Президенты! )))

P.S.: Я за чистоту Русского Языка, и стараюсь использовать русские аналоги англоязычных терминов. Где это невозможно или неудобно, я пишу в оригинале - по-английски.

С уважением к тем, кто работает.
R_VolAnd