Кто-нибудь пользуется jadx для повседневной работы? Смотреть код, ресурсы, искать строки и т.д. Мне кажется, что как декомпилятор он неплохой, но смотреть код в нем не удобно. Поэтому мой обычный флоу работы с jadx это File->Save as gradle project и дальше уже смотреть в студии. Но мне захотелось еще больше автоматизировать этот процесс и вообще не заходить в GUI. У jadx есть cli версия, но мне всегда было очень лениво сесть и сопоставить опции из GUI с cli. В какой-то момент, я заметил, что в настройках есть кнопка "Copy to clipboard", которая позволяет выгрузить все текущие настройки в виде json. При этом, проблема сопоставления никуда не делась и я задал автору утилиты вопрос о том как перекатить эти опции из GUI в cli. Оказалось, что такой возможности пока нет, но есть обходной путь. Чем я и воспользовался, написав конвертер json конфигов во флаги командной строки. Мою проблему он решает, но если вашу нет, то создавайте issue или засылайте PR-ы.
Но, строго говоря - это костыль и лучше бы иметь такую возможность в самом jadx, поэтому поставьте лайков под этой issue.

Если ваш вечер пятницы выглядит не так, то чем вы вообще там занимаетесь? 😁

Все подробности скоро на канале. Не переключайтесь.

Есть такая местами популярная в вебе штука - security.txt. Этот файл обычно располагают в корне сайта и он содержит контакты куда репортить уязвимости и иногда PGP ключи для шифрования отчетов. Но я ни разу не встречал этого или подобного ему файла в мобильных приложениях. Хотя это кажется полезным. Предлагаю всем разработчикам приложений, располагать такой файл в директории assets. Там его будет легко найти. Чтобы не составлять такой файл руками можно воспользоваться готовым генератором. Как вам такая инициатива?

Не буду разгонять телегу про "это был тяжелый год...". Был. И хватит об этом. Но в этом году удалось сделать много того, до чего долго не доходили руки. Одна из таких вещей - мое небольшое исследование о том, как ведут себя строки в памяти JVM и можно ли их гарантированно оттуда удалить. Как обычно я буду очень рад конструктивным дополнениям и уточнениям к изложенному материалу. Приятного чтения!

Начнем год с конференций. Вы же не хотите, чтобы на месте этого поста была статья про исследование приложения накрытого DexGuard-ом? Ну вот 🙃

Positive Hack Days 12, который пройдет 19-20 мая в Парке Горького - объявляет Call For Papers. Мне, традиционно, хотелось бы послушать много крутых докладов по уязвимостям в мобилках. Порадуйте меня пожалуйста 😉 Но вообще, там довольно широкий набор тем, и если мобилки вам не очень, то можно подать доклад про расследование действий кибергруппировок, безопасность BIOS, UEFI и другого firmware и даже про архитектурные проблемы современных вычислительных систем. Уж о чем, а об архитектуре тут все мастера потрындеть, да?

Рассматриваются разные варианты участия:
- доклад (50 минут),
- Fast Track (15 минут),
- Hands-on Lab (до 4 часов).

Лабу на 4 часа предлагаю сделать про снятие пиннинга 👨‍💻

Заявки от спикеров будут приниматься до 25 марта 2023 года. Программный комитет ответит на все заявки до 1 апреля.

Запускаю новую рубрику - Android Hacker Tips. Она будет выходить раз в неделю и содержать полезные советы, которые, теоретически, должны помогать в работе исследователям мобильных приложений. Эти советы будут выходить каждый понедельник под хештегом #aht. Чтобы не делать это сообщение бесполезным, прикрепляю к нему самый первый совет.
——————————————
При изучении сложных конструкций в декомпилированном коде или даже оригинальном исходном коде, полезно в динамике понимать как работает тот или иной алгоритм или его часть. Чтобы не переписывать это на какой-нибудь python или не создавать новый проект в Android Studio/Intellij IDEA - можно воспользоваться scratch-файлами. Кроме того, что они упрощают написание PoC-ов, они также являются кросс-проектными, а значит можно написать несколько базовых скретчей и они сразу будут доступны во всех новых исследуемых приложених. При условии, что вы используете Android Studio/Intellij IDEA конечно.

Нужно всегда обращать внимание на блок <query> в манифесте приложении. Там можно найти имена пакетов, с которыми исследуемое приложение как-то взаимодействует. Это взаимодействие может быть очень тесным и доверительным. А отсутствие проверки подписи при таком взаимодействии может дать поистине безграничные возможности. При исследовании этих взаимодействий также помогает поиск по ключевым словам queryIntentActivities, getPackageInfo, resolveActivity и getInstalledPackages.
#aht

Если приложение использует биометрию, то нужно сразу искать флаги setUserAuthenticationRequired и setInvalidatedByBiometricEnrollment. Если они установлены в false, то это может позволить обойти биометрическую аутентификацию при наличии физического доступа к устройству.
Первый флаг устанавливается когда нужно ограничить использовать ключа шифрования биометрическими данными. Без правильной биометрии - ключ не будет доступен для использования. Соответственно, если он false, то биометрический диалог можно просто скипнуть с помощью Frida.
Второй флаг, установленный в false позволяет злоумышленнику добавить в систему свой палец/лицо и получить доступ к приложению используя уже свои биометрические данные.
#aht

После декомпиляции приложения нужно поискать секреты в коде. Для этого можно использовать trufflehog или любую другую подобную утилиту. Пример запуска trufflehog: trufflehog filesystem --directory=`pwd` --only-verified
Но иногда, отсутствие флага only-verified дает интересные результаты. Поэтому обязательно попробуйте. А как быть с найденными секретами дальше, подскажет keyhacks
#aht

Четверг, как известно - рыбный день. Почему это важно? Да ни почему. Просто забавный факт. А кроме этого факта я хотел поделиться с вами первой частью моего цикла статей про деобфускацию (и в какой-то степени обратную компиляцию) кода android приложений. Все это, как обычно - лютый эксперимент, который неизвестно куда зайдет и сколько продлится. Но, у самурая нет цели, есть только путь. Приятного чтения.

Когда исследуешь сильно обфусцированное приложение, то приходится заниматься восстановлением оригинальных имен переменных и функций вручную. Или придумывать такие имена самостоятельно исходя из контекста использования. Кроме этого, иногда приходится удалять целые куски мусорного кода и совершать прочие рефакторинги. Чтобы проще было контролировать происходящее, откатываться или проверять гипотезы без вреда для кодовой базы - можно добавить декомпилированный код в локальный git репозиторий и пользоваться всеми прелестями этого инструмента.
#aht

Попалась мне тут совершенно замечательная ссылка, которой не имею сил не поделиться - https://github.com/krizzsk/HackersCave4StaticAndroidSec.

Там куча ссылок на туториалы, утилиты и исследования по уязвимостями в Android. Звучит скучно да? Верно. Это был бы еще один всратый "awesome list" если бы не одно "но" - там много ссылок на нативные китайские блоги и статьи. И там действительно полезная инфа, которую просто так не загулишь, если не ищешь специально на китайском. Я давно хотел найти что-то подобное и вот оно пришло. Из полезного лично для себя, я нашел там разбор форматов различных файлов (AndroidManifest.xml, resources.arsc и т.п.) и материалы по статическому анализу. Всем 你好 ;)

Перепаковка приложения может быть довольно болезненной процедурой. Чтобы избежать возможных глюков после пересборки, можно воспользоваться специальными флагами apktool: -s распакует приложение, но не будет декомпилировать код, а -r распакует без декодирования ресурсов. Если нужно только убрать ssl pinning через network_security_config.xml, то нет нужды декомпилировать код. А если требуется убрать проверку на root, то ресурсы можно не декодировать.
#aht

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

PHDAYS12 близко (19-20 мая)🌞 И чтобы он получился действительно крутым - нужны крутые доклады. Моя личная установка в этом плане не изменилась - хороших докладов про мобильный инфобез должно быть больше. Особенно хотелось бы послушать что-то междисциплинарное а-ля "Угон аккаунта из Google Calendar через подключенную по BT умную колонку" ;) Тема, кстати, не под копирайтом - забирайте =) К чему я это все? 25 марта заканчивается прием заявок на доклады и у вас есть шанс запрыгнуть с вашим исследованием в этот поезд!

Если угон акканта вы нарисечить еще не успели, то другие темы тоже вполне себе приветствуются:
👨‍🔬 новые техники и векторы атак, эксплуатация уязвимостей;
👨‍🔧 разработка и защита приложений;
🤖 технологии и безопасность ML в ИБ.

Хватит смотреть трансляции, пора их создавать 🚀

Даже если на устройстве есть root доступ, команды adb push/pull все равно будут работать в пользовательском режиме. Это значит, что не выйдет скачать или отправить файлы в директории доступные только суперпользователю. Но выход есть. Вместо adb push будет cat file.txt | adb shell su -c "dd of=/data/file.txt", а для замены adb pull - adb shell su -c "dd if=/data/file.txt" >> file.txt. В целом, так можно выполнить любую команду с правами root - adb shell su -c "<command>".
#aht

Обфусцированный код, при более пристальном рассмотрении, порой оказывается не таким уж и обфусцированным. Например по методу toString() часто можно восстановить оригинальное имя класса и имена полей. Для этого можно поискать по коду все объявления этого метода с помощью ключевого слова toString() { и найти что-то вроде этого:

public final String toString() {
  StringBuilder m20399b = C0002b.m20399b("Insets(left=");
  m20399b.append(this.f39a);
  m20399b.append(", top=");
  m20399b.append(this.f40b);
  m20399b.append(", right=");
  m20399b.append(this.f41c);
  m20399b.append(", bottom=");
  return C0047d.m19892c(m20399b, this.f42d, ')');
}

Теперь можно переименовывать класс и поля, что сильно упростит дальнейшие исследования.
#aht

Тут недавно в чате искали работу реверсером. Я вам принес =) В соседнюю команду ребята ищут толкового реверс инженера. Основная задача: изучение механизмов защиты мобильных приложений от статического и динамического анализа. И конечно же поиск возможностей обхода этих механизмов. Все как вы любите ;)

Помимо умения нажимать F5 в IDAPro, горячо приветствуется навык чтения пейперов, и перекладывания полученных из них знаний в PoC-и. Также нужно понимать основы криптографии и модели безопасности мобильных ОС. В общем, если вы когда-нибудь заглядывали под капот очередному Dex<placeholder>, то и сами знаете что требуется для такой работы. Остальные подробности найдете здесь.

В качестве бонусов: красивая аниме аватарка (если у вас еще нет) и возможность удаленной работы. Ну и IDAPro дадут, наверное...

Если приложение закрыто пин-кодом и он реализован локально, то есть несколько типичных ошибок, которые допускают разработчики.
1. Приложение никак не ограничивает количество попыток ввода;
2. После перезпуска приложения - счетчик попыток сбрасывается;
3. Приложение некорректно проверяет метку времени и можно сбросить счетчик путем перевода времени в системе;
4. Окно с пин-кодом не является блокирующим и можно запустить основной экран напрямую через Intent.

Подбирать пин-код в автоматическом режиме можно например с помощью ui-automator. Для него также есть вполне рабочая библиотека на python.
#aht

Толковый доклад об особенностях реализации шифрования данных на android смартфонах (FDE) и способах расшифровки этих данных. В докладе рассматриваются Huawei P9 и Samsung A5 2016. Устройства довольно старые, но дело даже не в них, а в тех приемах работы, которые применяются. Думаю, что каждый посмотревший этот доклад найдет для себя что-то новое.

https://youtu.be/-OAc4UOuPEo

Иногда полезно понимать с какими флагами запускается Intent внутри приложения или какие флаги были установлены для PendingIntent. В декомпилированном коде это, как правило, выглядит так intent.setFlags(268435456) или так PendingIntent.getActivity(context, f11650a.incrementAndGet(), intent, 1073741824). Конечно же есть способ восстановления значений флагов. Базовый код для проверки значения флага выглядит так:

if ((flagsValue & Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {
    addToSet("Intent.FLAG_ACTIVITY_NEW_TASK")
}

Но встречаются также комбинации флагов, и для восстановления полной картины придется повторить эту операцию для каждого из возможных значений флагов. Но если вы пользуетесь AndroidStudio, то она умеет делать это сама. Для этого нужно поставить курсор на значение флага и нажать Alt/Option+Enter. Будут предложены возможные значения для замены. Или Alt/Option+Shift+Enter чтобы выполнить замену сразу. Но это не всегда работает как нужно.
#aht