Tip of the day 🌚

Если надо что-то быстро посчитать не выходя из Android Studio, то по double shift можно запустить встроенный калькулятор

Умение обходить фильтры - очень важный навык. Обычно он складывается из двух компонентов: развитого аналитического мышления и знания трюков. Сегодня будут трюки. Представим себе такой синтетический фильтр:

val input = "http://evil.com"

val filter = """^(https?)://.*@?evil\..+""".toRegex()

if (filter.matches(input)) {
  throw MalformedURLException("Banned URL!")
}

val okhttp = OkHttpClient()
val req = Request.Builder().url(URL(input)).build()

Есть мысли как его обойти? Подумайте 30 секунд.

Один из способов - модифицировать input любым из этих способов:
- url:http://evil.com
- http://evil.com (первый символ - пробел)

Но проверка по черному списку встречается все реже. Кажется, что разработчики начинают что-то подозревать 😰
#aht

Как работают текстовые кодировки

Записали топовый выпуск Подлодки про разные неочевидные аспекты устройства текстовых кодировок и работы с ними. Больше всего, конечно, про Unicode. Если хотите узнать, почему в любом приложении, работающем с текстом, есть баги – обязательно слушайте!

По мотивам подкаста Никита Прокопов написал еще и шикарную статью, в которой подбил основные тезисы.

Один аккаунт на два приложения

Авторизовался в приложении А, а потом открыл приложение Б

А там окошко "Хотите войти под тем же аккаунтом?"

Как?

Ответ: через посредника == системный сервис == AccountManager

Что произошло под капотом:

1. Приложение А получило ваш логин и пароль

2, Приложение А проверило через бекенд, что вы существуете

3, Приложение А обратилось к системному AccoutManager, создало в нем Account и положило в него ваш логин и пароль

4. Приложение Б в момент запуска тоже обратилось к AccountManager, вязало Account и увидела ваш логин и пароль

Готово, приложение Б может авторизовать вас под тем же аккаунтом, не заставляя вспоминать пароль


Схема начинает выглядеть более безопасно, если учесть два факта:

• Account можно передавать только между приложениями, имеющими одну подпись

• прихранивать логин и пароль в сыром виде не стоит. вместо этого можно передавать обезличенный токен, зашифрованный на бекенде


Почему вам это надо:

• пользователю не нужно вспоминать пароль == увеличивается шанс, что он авторизуется

• компании не надо тратить деньги на СМС с кодом авторизации

Well explained blog on how to find and exploit XSS in Android apps in WebViews and Deep Links
https://securityboulevard.com/2023/10/execution-of-arbitrary-javanoscript-in-android-application/

Раздельная компиляция, min, compile, target

В целом Java-технологии привычные к раздельной компиляции. Серверные приложения компилируются с Java Class Library, которая подкладывается в compile classpath при сборке, а запускаются с другим экземпляром JCL, которая лежит на сервере.

Однако, эта раздельность почти не чувствуется. Она незримо присутствует и заключается в том, что в итоговом jar у нас не лежит весь java.lang, java.util и что мы там ещё любим. Мы запускаем приложение с той же версией JDK, с которой собирали, и всё просто работает.

Таким образом, приложение разрабатывается под одну версию платформы, без оглядки на более старые и с надеждой на совместимость с новыми.

В desktop-приложениях (кто-то их ещё пишет?) всё ещё проще: зачастую JVM приносят с собой, и раздельной компиляции как не бывало.

В Android же, как известно, зоопарк: на конечных устройствах много разных версий. И вот тут система сборки спроектирована очень удачно:
• compile SDK — последняя версия, известная разработчику приложения на момент сборки. Она подкладывается в compile classpath, за счёт чего разработчик видит все новые фичи платформы;
• min SDK — минимальная поддерживаемая версия. Старой платформе, которую разработчик не хочет поддерживать, позволяет отклонять установку приложений. Инструментарию позволяет подсказать программисту, что те или иные declarations недоступны в min и могут отсутствовать в runtime classpath, поэтому нужно обернуть их использование в if;
• target SDK — версия, на поведение которой рассчитывает приложение. Позволяет более новой версии платформы сохранить поведение старой в старом приложении.

Таким образом, в быстро меняющемся мире Android-приложение компилируется для свежей версии платформы (compile SDK), ифами поддерживает более старые версии (вплоть до min SDK), а платформа, если она новее, чем ожидаемая (target SDK), сохраняет старое совместимое поведение (тоже ифами).

Это прекрасно. Это шедевр.

Для сравнения, ситуация в мире плагинов для IntelliJ: выбираешь одну версию, которая и будет твоим compile и min. Хочешь поддержать постарше — опускаешь версию, перестаёшь видеть новые declarations. Если в новых версиях что-то deprecated — ты об этом узнаешь на этапе валидации плагина, где-то после компиляции и упаковки.

Именно поэтому при обновлении IDE плагины часто либо отключаются (разработчик указал максимальную поддерживаемую версию), либо разваливаются (мой вариант:).

Зависишь от других плагинов? Вообще страдай. Там может быть установлена любая версия. Например, если зависишь от Android-плагина для IDE, то при компиляции видишь версию, которой полгода, а в бетах Android Studio уже много раз переименовали классы, поменяли на интерфейсы, переместили в другой пакет. (И сделали это в стенах той же компании, где придумали min, compile, target.) Удачи!

Итак, ребята, взгляните на статью. Ничего не смущает? А вот эта? Дело в не в оформлении или стиле повествования дело в самой теме. Что первая статья, что вторая по своей сути просто пересказ книги Мартина с щепоткой заезженных истин вроде: важна золотая середина, выбирайте что лучше для вашего приложения отталкивайтесь от бизнеса требований и бла, бла, бла.

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

Вот знаете же миф о том, чтобы разработчику оставаться на одном месте ему нужно постоянно учиться. Я вот уже давно не читаю статьи по мобильной разработке и все жду того момента, когда ничего не буду понимать. За последние 5 лет самым значимым изменением было внедрение compose. Но это всего лишь один UI слой, не говоря уже о том, что большие проекты только-только начинают на него переезжать и то с большим скрипом.

Архитектуры в мобилке до жути простые и они везде одинаковые в 90% случаев. Оставшиеся 10% это какие-нибудь рибс, и то по сути те же яйца, только в профиль. Я даже не уверен, что имеет смысл говорить об архитектуре модулей когда речь идет о мобильном приложение. У бэкендеров другое дело, у них реально миллион способов связать сервисы друг с другом и там имеет место обсуждение архитектур. Потому как проеб в архитектуре у бэкендеров это реальная потеря бабок.

Больше всего забавляет архитектурная секция, где тебя просят сделать архитектору обычного мобильного приложения, у нас в компании такая есть. Хотите я за пару абзацев научу вас ее проходить?

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

Затем вы собираете требования по фичам проекта и тупо отдельные фичи располагаете в разных модулях. Делаете модуль app, показываете что там есть di, затем добавим модуль навигации, ну а че бы и нет. Дальше у вас только два варианта как располагать модули. Либо всю бизнес логику делать внутри feature и если нужно шарить делаете api модуль с интерфейсами, либо делаете отдельные domain модули в которых уже будут всякие repository и interactor.

Дальше желательно сказать что проксирующие интеракторы это херня из под коня и если интервьюер адекватный, ему это понравится. Дальше вам лишь нужно выбрать уже готовую архитектору для Presentation слоя: MVVM или MVI. MVP уже никто не воспринимает всерьез. Расклад такой: с MVVM проще онбординг новых сотрудников, и она лучше по памяти когда дохера событий на экране, но она хуже когда много асинхронщины. MVI сложнее в онбординге, и создается новый State на любой чих, зато один единый State и вы забываете что такое Race Condition. Бум, все, идите к начальству и просите зарплату архитектора.

BLE Spam allows now to send unwanted notifications to iOS, Android and Windows at once using Flipper Zero.
If you don't have Flipper Zero, in the blog I explained how to trigger popups using any Android smartphone even with custom messages
https://www.mobile-hacker.com/2023/10/17/spam-ios-android-and-windows-with-bluetooth-pairing-messages-using-flipper-zero-or-android-smartphone/

Слухи ходили давно, но вот официальное подтверждение: Xiaomi отменили разрабатываемую ей в течении 13 лет оболочку MIUI. Вместо нее будет новое решение, HyperOS. Главная заявленная цель — интегрировать в единую экосистему основные девайсы Xiaomi, т.е. выйти за пределы телефонов.

Мне немного жаль, MIUI мне казалась неплохой. Ну, посмотрим на замену, она появится на телефонах Xiaomi 14-й серии.

https://www.androidauthority.com/xiaomi-hyperos-3376622/

Подборка историй о взломах мобильных приложений

Всем привет!

Недавно пришла в голову идея составить небольшую подборку из громких в свое время историй про взлом мобильных приложений. То есть о тех историях, которые получили публичную известность благодаря СМИ и немного пошумели.

Мне кажется, что получилось достаточно неплохо, по крайней мере мне самому было интересно ее перечитать после публикации.

Так что приятного и легкого чтения =)

#news #vulns

#Article #Medium #Fun

Building the Flappy Musk.eteer Arcade Game with Jetpack Compose

Не бизнес-приложениями едиными. Тут вам история как собрать с нуля свою версию Flappy Bird на Jetpack Compose без смс и регистрации.

Зеркало статьи 👉 тут

Android предоставляет весьма широки возможности по логированию различных событий. Одним из наиболее полезных, на мой взгляд, является логирование SQL запросов, которые делают приложения. Не важно, напрямую или через ORM. В логах будут те запросы, которые непосредственно выполняет БД. Включить эту возможность можно командой: adb shell setprop log.tag.SQLiteStatements VERBOSE. После чего в logcat должны появиться логи запросов. А если поискать в исходниках Android ссылки на метод isLoggable, то можно найти другие подобные теги и включить логирование для них аналогичным способом.
#aht