Давным-давно я нечто подобное показывал, но в более олдскульном гиковом варианте.

Отличная прога для тех кому это нужно:
https://github.com/rhythmcache/Dioxamine

Подключение: USB OTG-кабель.
Wireless ADB.

Штука многофункциональная, работает как полноценный adb/fastboot и не только:

- файловый менеджер: /sdcard и корень ФС, push/pull пачками, переименование, удаление.

- пакетный менеджер: установка APK и сплитов (.apks, .xapk), удаление, enable/disable, вытягивание установленных APK.

- sideload OTA-пакетов, Rescue mode с wipe userdata.

- трансляция экрана.

- стрим камеры цели: выбор объектива.

- прошивка образов (boot, recovery, system, vendor_boot, init_boot, etc).

- временный запуск ядра/recovery без записи в раздел (fastboot boot).

- lock/unlock бутлоадера.

- инспектор переменных (getvar).

- прямой fastboot-терминал.

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

Для самых маленьких: Google там вводит отлежку в 24ч для устанавливаемых из сторонних источников АПК. Этому софту все это похрен, он вам поставит что угодно, также как обычный ПК. И сделает это буквально на ходу.

Софт в стадии альфа, есть мелкие баги.

Android-приложение-отправитель самоуничтожающихся зашифрованных заметок.

От создателя PGPony и других полезных лошадок. Сервис одноразовых записок с возможностью использования собственного сервера (по умолчанию используется сервер разраба).

Что это такое, для тех кто не застал эпоху одноразовых записок:

Ты пишешь заметку, задаёшь правила её уничтожения и приложение формирует ссылку. Ссылку отправляешь любым способом получателю. Получатель открывает её в обычном браузере. После прочтения (или по таймеру) заметка исчезает с сервера.

Можно настроить:

Количество просмотров - от 1 до 100. После достижения лимита текст на сервере обнуляется.

Срок жизни - от 5 минут до 30 суток. Заметка умирает даже если её вообще не открыли.

Пароль - и так понятно.

Автоскрытие - через сколько секунд текст пропадёт с экрана получателя после показа.

Уведомление о прочтении - уведомление, что заметку открыли.

Еще можно сжечь принудительно, поставить метку, просмотреть статус и тд.

Работает примерно так. На устройстве генерируется ключ, которым шифруется послание. Послание запечатывается в конверт и отправляется на сервер, а ключ, вместе с указанием конверта отправляется получателю. Сервер физически не может получить ключ, потому что ключ находится в той части адреса, которую браузер серверу не отправляет. Не отправляет он ее не почему-то там, а потому что это базовый принцип работы HTTP. Часть после # называется фрагментом. Он придуман для навигации внутри уже загруженной страницы. Странице он нужен, серверу нет. Поэтому браузер, формируя HTTP-запрос, фрагмент в него не кладёт: в запрос попадает только путь.

В общем, вполне честный и грамотный подход при открытой реализации.

https://github.com/norsehorse-dev/BurnPonyAndroid

Это очень интересно. Особенно тем кто считает root на своем устройстве чем-то опасным. Правильно считаете. Только не тот root.

Это видео от команды LSPosed, их представлять не нужно. На видео они эксплуатируют DirtyFrag и еще одну дыру, которую не озвучивают. И правильно делают. У них там с Google терки по поводу нее, но не суть.. В результате они получают полный root на Pixel 10 с Android 17. Это абсолютно стоковый смартфон из коробки, с заблокированным загрузчиком. И они получают на нем полный доступ просто запустив приложение.

Заметили, я нарочно написал это максимально простым языком? Это чтобы самый тупой и закоренелый рутофоб проникся: страшен не root. Страшен root который вы не контролируете. О котором вы даже не подозреваете.

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

https://github.com/BuSung-dev/Root-My-Galaxy

Это ссылка на софт, который позволяет получит практически то же самое, что описано выше, но через уязвимость CVE-2026-43499, известную как GhostLock. Принцип у уязвимости другой, суть та же: получение root на устройстве с заблокированным загрузчиком и, следовательно, полный контроль над устройством. Без изменений системы, без разблокировки загрузчика и прочих сопутствующих действий. Подвержены не только Samsung, но и OnePlus, Pixel - аналогичные софты там же на GitHub.

Обе озвученные уязвимости известны, имеют описание и живут в ядре системы. Им не нужны никакие разрешения или сложные действия со стороны пользователя. Вы можете сколько угодно думать себе что раз вы не рутовали свое устройство, то и защищены по самые гланды по сравнению с рутованными. Но root, чужой и вами не управляемый, придет и обоснует вам ваши заблуждения.

Тут ссылка на софт, который чекает вас на уязвимость GhostLock
https://github.com/CakesTwix/Android-CVE-2026-43499

Внимание! На многих устройствах присутствует только один из двух необходимых патчей ядра, которые закрывают уязвимость. При запуске чекера вы можете вызвать панику ядра, со всеми последствиями: от перезагрузки до зависания. Чекайте на свой страх и риск!. Собственно, результат получите в любом случае: уязвим, не уязвим, или паника, которая означает что рутануть вас таким способом нельзя, но вызвать отказ в обслуживании как нефиг делать. Лечится все это только патчами/обновлением ядра.

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

Суть кратко: мутный тип был на карандаше, и при попытке досмотра его смартфона не придумал ничего лучше чем сбросить его к херам заводу, используя функцию "пароль под принуждением" во всем известной GrapheneOS. Ну, епта! Сброс до завода! Гении секьюрности!

- Внимание, дети! Посмотрите налево! Тут вы можете видеть канонического лошару, чья фотография должна украсить соответствующий раздел Википедии. Кто ответит, почему?

- Правдоподобное отрицание?

- Молодцы, дети. Всем пятерка. В дневник. А лошаре пятерка срока на американских нарах.

Это происшествие - наглядный пример того, что людям нужна защита. Но они не хотят в нее погружаться. Вместо этого они берут и используют распиаренное говно решения, которые также далеки от реальной жизни, как американский суд (да и любой суд) от желания что-то там выяснять и доказывать. Достали пыльный закон с прецедентом, развернули, применили. А че нет-то? Факт демонстративного удаления данных можно рассматривать как умышленное действие? Несомненно. Есть статья на этот случай? Статья всегда найдется. Всё - бедолага пять лет отхватит там, где можно было поулыбаться и идти в Starbucks пить американо.

Если вы что-то экстренно удаляете, то это должно происходить незаметно, без следа в системе, или сводиться к действию, которое вам не смогут вменить как умышленное.. Для этого заранее определяется круг критически важных объектов, к которым большинство ваших данных не относятся. Решается вопрос с логированием самого действия системой, подбирается оптимальный способ и тд. Это - сложная наука, по другому не скажешь. Но никто не задумывается об этом всерьёз, пока не окажется в ситуации, которую назад уже не откатить.

А Графин - ну он и есть Графин. Школьники его подружкам показывают. Серьезные люди его не используют. А к чему может привести не серьёзное использование не серьёзного инструмента лучше читать в таких постах, чем в личном деле.

Представьте два смартфона в одном. Представили? А теперь представьте три, четыре...

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

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

- каждая дополнительная система является отдельным "слотом", который живёт в userdata. Каждый слот имеет свои ключи шифрования.

- количество систем ограничено только объемом памяти устройства. При желании вы сможете установить сразу несколько различных систем, например AOSP+GAPPS, crDroid и форк GrapheneOS, и перезагружаться между ними по своему выбору

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

- все дополнительные системы имеют собственные изолированные и зашифрованные разделы пользовательских данных, которые не пересекаются с основной хостовой системой

- дополнительные системы "живут" столько, сколько необходимо владельцу, устанавливаются и удаляются без необходимости дополнительной прошивки устройства и тд.

- все, чему вы научились на основном курсе, вы сможете применить в любой из установленных систем

Нужно использовать браузер Яндекс с "национальным сертификатом" без каких-либо рисков для чувствительных данных?

Нужно изолировать и скрыть криптокошельки?

Есть необходимость использовать VK и Rustore?

Часто пересекаете границу и хотите гарантированно скрыть чувствительные данные?

Дополнительные системы - это оптимальный баланс между виртуалкой и реальным устройством. С их помощью можно решить большинство задач как в контексте безопасности данных, так и закрыть повседневные гражданские задачи. Госуслуги из допсистемы никогда не увидят ваш прокси на хосте, Сбер не узнает что у вас крипты больше чем у Маска, а Макс не увидит ваши аккаунты в Телеге. В общем, мастхэв для продвинутых пользователей Android.

Требования: устройство должно иметь динамические разделы и поддержку Treble

Урок доступен только тем, кто прошел основной курс!

Старт: 6 августа (1 день)

Стоимость участия: 20к

Для участия обращаться к саппорту: @JazzSupport

Саппорт имеет право отказать в записи без объяснения причин.

Кто там спрашивал про актуальный hosts?

https://github.com/hagezi/dns-blocklists#ultimate

Линейка Multi в пяти уровнях агрессивности: Light (166k), Normal (341k), Pro (479k), Pro++ (564k), Ultimate (673k). Каждый следующий уровень включает предыдущий.
На сегодня это самый поддерживаемый и лучше всего структурированный публичный набор. Чтобы не перегружать систему, особенно если оперативка небольшая, и нужно в базовую безопасность, а не просто порезать рекламу, достаточно прошки. Если в паранойку и комплексную безопасность - то плюс полный TIF. Но это еще 1.1M записей, на телефоне может жрать RAM.

Главное отличие от склеек типа StevenBlack в том, что каждый уровень компилируется и валидируется отдельно. В репо есть слои разрешений типа allow_light-ultimate.txt - домены, вычищаемые из всех уровней включая Fake и TIF, allow_light-normal.txt - разблокировка только для мягких уровней, чтобы Light/Normal не ломали ничего, и тд. Именно поэтому Light - это не тупо урезанный Normal. Списки прогоняются по 10000 сайтов из Cisco Umbrella Top 1M, проверяется загрузка страниц, корректность отображения, работа навигации, картинок, видео. Мёртвые хосты регулярно удаляются, чтобы держать размер минимальным.

Для тех кто не понимает о чем речь. Это набор DNS-блоклистов от одного мейнтейнера (hagezi), собранный не "склейкой чужих списков", а с чисткой, дедупом и собственными дополнениями поверх десятков источников. Обновляется автоматически, де-факто сейчас это эталон в нише блокировки рекламы, фишинга, малвари и тд.

В общем, читайте, разбирайтесь, выбирайте.

Эта новость вовсе не новость, просто удобный повод объяснить почему Android - это не Google.

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

Давным-давно в 2005-м, когда многих из вас не было на свете, в Google решили что Android Inc., основаная в 2003 году, может стать нехилой конкуренцией Symbian и Windows Mobile, уже довольно распространенным на тот момент. Через три года после покупки, в 2008-м выкатили первое устройство на AndroidOS. Тогда же появился AOSP как открытая часть платформы под Apache 2.0. И это ключевой момент всей истории с сертификацией и заебавшими перлами типа "Google запрещает установку сторонних приложений на Android".

AOSP - это открытый исходный код, который может собрать кто угодно (на нём и построены LineageOS, GrapheneOS и т.д.). Google-серверов не требует.

AOSP=Android. Даже если вот прямо сейчас закрыть проект, Android никуда не денется. Это открытый код в свободном доступе, который лежит на тысячах серверов и частных накопителей, его можно использовать, развивать, им можно делиться. Китай со своей HarmonyOS тому пример. Если волшебным способом изъять этот код со всех носителей - только тогда Android исчезнет. Появится Googloid, Hrenoid - что-то другое.

GMS (Google Mobile Services) - это проприетарный набор поверх AOSP: Play Store, Play services, Play Protect, FCM, геолокация Google и т.д. По сути - это паразитарный закрытый софт, который распространяется только по лицензии Google и не имеет к AOSP никакого отношения.

Сертифицированное устройство - это устройство, чей производитель прошёл три условия Google: собрал прошивку, проходящую CTS (Compatibility Test Suite - проверка совместимости с Android-спецификацией), подписал с Google дистрибьюторское соглашение (MADA), получил лицензию на предустановку GMS, и чей build fingerprint зарегистрирован в базе Google. С Android 8+ на такие устройства заводятся аппаратные ключи атестации, подписанные корневым сертификатом Google (attestation root), зашитые в TEE/StrongBox.

Несертифицированное устройство — кастомный ROM, de-Googled-сборка или устройство без GMS-лицензии. Я его держу сейчас в руках.

Google в тексте условий говорит про "системные сервисы на сертифицированных устройствах". Читается это как "наш софт на наших доверенных телефонах". Но за этой фразой скрыто одно уравнение: системные сервисы = GMS, а "сертифицированное устройство" - это единственное место, где Google этому GMS полностью доверяет.

Возвращаясь к скрину, Google фактически говорит: "на устройствах, где стоит наш GMS с полным доверием, он будет делать что хочет, жить своей фоновой жизнью и тратить твой трафик - и платишь за это ты, долбоебина, потому что повязан лицензией и пользовательским соглашением". По сути, это единственный внешний субъект, принимаюший решения на устройстве удалённо.

Используя Android без GMS вы возвращаете себе суверенитет, который GMS, как привилегированный слой на устройстве, вертел на колу. Но это не бесплатная свобода, а осознанный размен, ибо Google вяжет вас не только обязательствами, но и конфетками, перечислять которые не буду. Потому что независимо от них я свой выбор сделал давно.

Надеюсь, главное вы почерпнули: Google живет и паразитирует поверх Android, он собирает ваши данные и отправляет их на свои сервера. Держит с этими серверами фоновый канал с абсолютно разными целями. Как для пушей, чтобы вы вовремя получили это сообщение, так и для отправки cell-tower данных для геолокационной базы Google и вашего отслеживания. И делает он это с вашего разрешения. В обмен на конфетку.

Олдскул или модерн? v4 vs. v6?
Годы доверия к классике или активная разработка современного инструмента?

Не скринах PGPony, софт и криптоядро идут отдельными репо. Под iOS тоже есть вариант, но мне не интересно.

Собственно, знакомьтесь - современная альтернатива всеми любимому OpenKeychain, а если не знаете что это, то, скорее всего, вы лютый терминальный красноглаз или, что более вероятно, не используете OpenPGP на Android и "шифрование" для вас - это просто какое-то слово на букву "ша". Для вас распишу подробнее.

Шифрование/подпись/расшифровка - три базовые операции PGP:

шифрование - превращает текст/файл в нечитаемый блок, открыть который сможет только получатель своим приватным ключом

подпись - к сообщению прикрепляется криптографическую "печать", получатель убеждается, что писал именно Jazz и текст не подменили

расшифровка - обратная операция, вашим приватным ключом открывается то, что зашифровали конкретно для вас, и заодно проверяется чужая подпись.

В чем отличия, плюсы и минусы по сравнению с OpenKeychain?

Лошадка поддерживает v4 и v6 - два поколения формата OpenPGP. OK - только v4.

Лошадка может в HW-ключи по NFC (YubiKey 5, Token2) - вместо того чтобы держать приватный ключ в памяти телефона, он хранится на физической железке (смарткарта/токен). Чтобы что-то подписать или расшифровать, достаточно приложить её к телефону через NFC и ввести PIN. Ключ никогда не покидает карту, даже если телефон скомпрометирован, вытащить ключ нельзя. Генерация ключа прямо на карте, новый приватный ключ рождается внутри токена и физически никогда не существует на телефоне. На телефоне только софт для управления (удалить, сменить пин и тд.).

Чего нет в PGPony? Системный OpenPGP API. То есть нативный бэкенд для почты типа K-9/Thunderbird, связка с XMPP-клиентом и все за что сообщество ценит OpenKeychain - хрен вам. Но, возможно и хотелось бы - добавится.

Вывод: PGPony даёт более современный формат (v6) с лучшей целостностью и защитой  паролем, но реализуется это преимущество только когда обе стороны на v6. Базовая криптография одинаковая.

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

https://x.com/nebusecurity/status/2069707520160227688

Сразу определимся, что пост от Nebula Security абсолютно коммерческий, типа "VEGA, алга", "Mythos - шляпа", и все такое. Но суть совершенно не в этом. Это наглядная демонстрация современной атаки на пользователя, после которой все ваши секреты уже не ваши, а тезеры уехали на чужой кош.

Суть демонстрации: юзер тапает на ссылку в Firefox на Android 17 - все, телефон заражен и рутован. Без установки приложений, без дополнительных действий. Рутован не в смысле что пользователь получил root-доступ на своем устройстве, а в том смысле что его получил атакующий, применив браузерный эксплойт. Кривой компилятор, побег из песочницы и вот, атакующий уже в вашем ядре.

Еще раз. Это не обычный KernelSU/Magisk root. Это компрометация ядра из контекста браузерного процесса. Атакующий работает с привилегиями ядра, без ограничений, без проблем с SELinux - круче него только Бэтмен. Что он теперь может сделать конкретно? Да все: читать /data/data/*, все приложения, включая мессенджеры, кошельки, читать ключи в памяти, вытаскивать CE-зашифрованные данные пока устройство в AFU и тд. И при этом спрятать следы всего этого.

Есть такой термин - "компрессия квалификации". Если раньше цепочка "найти баг - написать рабочий эксплойт - доставить" требовала редкой коммандной экспертизы и месяцев работы, то сейчас способность моделей решать реальные инженерные задачи выросла примерно с 33% решённых реальных GitHub-issue в 2024 до почти 81% в 2025, и это мне еще лень искать статистику за последние месяцы.

Есть еще один термин - "коллапс окна защиты". Время от раскрытия уязвимости до её эксплуатации в дикой природе упало с более чем 700 дней в 2020-м до 44 дней в 2025-м, а некоторые эксплойты в 2026-м выстреливают через 24 часа (!) после раскрытия. Че ты там моргаешь, бро? Это - реалия.

И в ней ролмодел "я не таргет" - это неприлично инфантильный долбоебизм. Непозволительный никому. Это раньше дорогущий Pegasus таргетировали на конкретного персонажа за хулиард денег. А сейчас AI убирает главный ограничитель массовых атак - стоимость подготовки каждого эксплойта. Когда эта стоимость падает, исчезает сама необходимость выбирать жертв: дешевле бить по всем. Это уже не "работа снайпера", это "рыбак закинул сеть и тянет". Потому что так дешевле. Потому что эксплойт становится расходником, а не драгоценным инструментом, потому что атака на его основе, вот конкретно эта из демо-видео - она ничего не стоит.

Все кто хоть немного в безопасность прекрасно понимают что стратегия "обновлюсь, когда узнаю об угрозе" мертва. Это уже не работает. Тупо не успевает защищать. Единственная состоятельная защита - защита активная, опережающая. Когда нельзя предсказать и нельзя опередить точку входа, рационально защищать точку выхода - узкое горло, через которое проходит любая успешная атака независимо от CVE. Потому что дохуя себе широченная поверхность подобных атак, в случае успеха, почти всегда обязана сойтись к маленькому набору целей. В конкретном описанном случае - получить root в ядре. Пофиг как это будет сделано. Суть защиты не патчи ждать от лисьих браузеров, а отлавливать такие события и пресекать. Безжалостно. Кто хочет поковырять самостоятельно и самостоятельно понять, на чём вообще держится защита от эскалации привилегий (вот этот самый нисхуя root в ядре) копайте в сторону commit_creds и BPF kprobe. Это та точка ядра, через которую проходит любой переход к root.

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

Делал чисто для себя, но, уверен, многим пригодится.

Модуль задуман как альтернатива AFWall+ или Netswitch, проще говоря - рутовый файервол на iptables. Но с акцентом на мультипрофильность и удобство, а также на работу с системными приложениями, ибо пользовательские можно резать чем угодно. Внимательно читаем алармы относящиеся к Shared UID при выставлении правил. Приложения разделены не только на "Пользовательские" и "Системные", но и разбиты отдельно по пользователям: u0, u10, u11 и тд.

Работает с Magisk/KernelSU. Управление через WebUI. Если ваш менеджер для управления root-доступом не алё в WebUI, используйте стороннее решение, в KSU/KSUN все встроено в менеджеры, вы это и так знаете.

Делюсь lite-версией, полную версию раздам на следующем потоке курса. В полной присутствуют дополнительные функции типа killswitch и тд. Возможно, если нечем будет заняться, в полную версию встрою раздельное управление мобильным трафиком, wifi, etc. Но, если честно, не вижу в этом особого смысла. Приложению или можно ходить в сеть, или нельзя. Чуть-чуть нельзя - это извращения.