Binder Trace: Tool for intercepting and parsing Android Binder messages Think of it as "Wireshark for Binder"
https://github.com/foundryzero/binder-trace

Брутфорс сканера отпечатка пальца в смартфоне. Как страшно жить!

#cybersec #hack #research

Platform Samples - коллекция примеров применения различных API платформы Android.

Целью этих примеров является демонстрация определенной функциональности в изоляции, и они могут использовать упрощенный код. Для лучших практик в реальных условиях разработчики рекомендуют следовать документации и Now In Android.

Среди рассмотренных тем - доступность, камера, подключение, графика, геолокация, приватность, пользовательский интерфейс.

Platform Samples на GitHub: https://github.com/android/platform-samples
Платформа: Android
⭐️: 234

Разрешения в Android

Вдохновлённые одной из статей Oversecured про типичные ошибки в разрешениях, которые присутствуют при разработке приложений мы решили собрать чек-лист чуть побольше и дать немного больше описания и теории всем, кто хотел бы узнать что-то новое или освежить воспоминания об этом инструменте.

По итогу родилась статья на Хабр.
Прошу вашего внимания и, надеюсь, что информация окажется полезной!

Всем приятного чтения и хорошего настроения!

#habr #android #permissions

Существует отличный вариант украсить заголовки страниц в приложении при перелистывании. Предлагаем вам туториал — изучайте 😎

Читать статью

#новостиproglib

Если для эксплуатации уязвимости нужно передать Parcelable класс в intent-е, то есть пара способов это сделать. Представим, что activity ожидает модель User, которая лежит в пакете com.myapp.xxx. Можно создать в эксплойте такую же структуру пакетов, и класс с таким же названием и необходимыми полями. Чтобы не писать реализацию сериализации руками, то можно воспользоваться плагином и добавить к созданному классу аннотацию @Parcelize. Но иногда классы бывают сложными или их требуется несколько сразу. В этом случае проще взять из целевого приложения .dex файлы с этими классами, положить их в assets и работать с ними через DexClassLoader. Пример здесь.
#aht

Clock of Clocks - анимированные часы, сделанные с помощью Jetpack Compose.

Clock of Clocks на GitHub: https://github.com/khoa-omega/clock-of-clocks
Платформа: Android
⭐️: 22

Хочу оформить главные, можно назвать их заповедями тестирования или постулатами, называйте как хотите. Я уже в разработке почти 6 лет и вот весь мой опыт, который есть на данный момент можно оформить так:

Зачем тесты?

👉 Тесты не избавляют от багов, не делают программу надежнее и не заставляют тебя писать чистый код. Тесты нужны лишь убедится, что ты новым кодом не сломал предыдущий, позволяют не оглядываться назад на каждом шагу
👉 Тесты имеют смысл только в том случае, если они постоянно запускаются на CI и блокируют МРы, иначе это бессмысленная трата времени, плавали знаем
👉 Тест плох, если он падает постоянно, на него перестают обращать внимания и забивают
👉 Тест плох если всегда проходит, значит он нихрена не тестирует
👉 Тест пишем только тогда, когда уверены, что нет другого механизма обеспечить качество (см. прошлые посты)
👉 Флакающие/мигающие тесты, от таких тестов нужно избавляться также быстро как гугл отказывается от проектов. Мигающие тесты приносят целый ворох проблем: не дают никакой информации, нагружают систему т.к приходится их перезапускать, и увеличивают вероятность оказаться вне поля зрения.

Как не нужно тестировать?

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

Как лучше тестировать?

👉 Тесты не должны ломаться при рефакторинге, и быть обузой. Иначе разрабы просто будут боятся рефакторить код, а это приведет к протуханию кода
👉 Тесты должны писаться также легко как и основной код
👉 В тестах может быть дублирование, так как избавление от дублирование это уже абстракция, абстракция это сложно, а сложность ведет к багам. Вам нужны баги еще и в тестах?
👉 Ассинхронность. Как показывает практика лучше ничего не подменять и тестировать в условиях реальной работы. Иначе в тестах на одном потоке все прекрасно, а в проде гонка и плавающие баги (см. подход из предыдущего поста).
👉 Тесты могут потребовать изменения в архитектуре или инфраструктуре, это ок так и должно быть. Однако внутри кода проекта не должно быть упоминаний о тестах: @visiblefortesting или idling в коде проекта это сигнал о том, что вы профакапились с архитектурой

Android Data Repository — A simple pattern that we often misunderstand

Статья про паттерн репозиторий, как он должен выглядеть и чего там делать не стоит.

👉 Don’t use JSON/SQL model in the Repository methods
👉 Repository is not a group of backend endpoints
👉 Repository is not a database table
👉 Not every Repository needs a Data Source

Читать (En)

Вау, просто вау. В комментарии в сорцах SQLite обнаружилась потрясающая история: для временных файлов пришлось по умолчанию использовать префикс "etilqs_" (SQLite наоборот), потому что McAfee засирали юзерам temp папку, а юзеры находили контакты разработчиков SQLite и названивали им с жалобами.

#sqlite #db #humor

Опубликовали мое выступление на Mobius. Теперь оно доступно на Ютубе всем желающим:

https://youtu.be/htWzdvht0Qg

И ещё выступление где я был приглашенным экспертом - про Lobzik: https://youtu.be/8BB5Qa1O5TM

Вероятно Twitter заDDOSил сам себя

Последние два дня Илон Маск утверждал, что Twitter подвергается атаке со стороны "нескольких сотен организаций", которые осуществляют "ЭКСТРЕМАЛЬНЫЙ уровень извлечения данных". Это вынудило компанию экстренно включить "большое количество серверов" и принять чрезвычайные меры.

1. В выходные Twitter начал блокировать доступ к Twitter всем вышедшим из системы, требуя входа в систему для просмотра любого твита или профиля. Маск назвал это "временной чрезвычайной мерой".

2. Очевидно, это не остановило наплыв трафика, и Twitter ограничил количество твитов, которые вы можете просматривать.

3. Сразу же пользователи Twitter начали видеть сообщения "Rate Limit Exceeded".

4. Неужели компании, занимающиеся разработкой искусственного интеллекта, обрушили соцсеть? Возможно, да. А возможно и нет.

5. Само веб-приложении Twitter постоянно отправляет запросы в Twitter в бесконечном цикле. "Это уморительно. Похоже, что Твиттер сам себя заDDOSил". Twitter отправляет около 10 запросов в секунду, пытаясь получить контент, который никогда не приходит. Вероятно, это создало адские условия, которые инженеры даже не предполагали, и поэтому мы получаем эту комедию ошибок, приводящую к самой эпической самоликвидации - само-DDOS.

6. С другой стороны в настоящее время неизвестно, когда этот баг появился и насколько сильно он влияет на трафик, поэтому трудно определить, этот баг вдохновил Twitter заблокировать незарегистрированный доступ и добавить ограничения скорости, или же баг был спровоцирован развертыванием этих изменений.

И что: было бы забавно, если бы эта "чрезвычайная ситуация" от начала и до конца была вызвана ошибкой, в результате которой Twitter сам себе устроил DDOS, породив все эти "интересные" решения 🤡