быдло.jazz

быдло.jazz pinned «Анонс предстоящего курса! Старт: 25 сентября Что в программе: - Android 16 - работа с кастомными прошивками, получение Root - поговорим о самых современных и передовых решениях для рутирования на основе ядра и сравним их с классикой - разберем понятие…»

Это самая невероятная уязвимость, которую я когда-либо видел

и

Удивительно, что даже инженер Google может совершить такую большую ошибку в эпоху искусственного интеллекта

Хотел рассказать про другое, но как тут про другое, когда такие цитаты. В общем, вот вам очередной наброс от команды LSPosed и, соответственно, очередной проеб от Google. Это действительно интересно, и это нужно знать, если вы хоть немного хотите понимать что за железку держите в руках. Постараюсь максимально просто.

Цепочка эксплойтов состоит из двух CVE - брешь в стеке телефонии 17-го Андроида и пробоина в ядре.

Работает это в три шага:

1. Для начала, нужно оказаться внутри процесса, которому система доверяет.

Если установленное приложение заявляет "я могу обрабатывать звонки", но на самом деле не может, то система лезет к несуществующему классу и падает. В Android 17 добавили проверку: перед обращением убедиться, что класс реально есть. Чтобы узнать, есть ли класс в чужом приложении, нужно взять загрузчик кода этого приложения. Приложение телефонии так и делает, но... Проверяя заодно и исполняет загруженный код. Это тот самый "гугловский инженер" упорол косяк.

Приложение подсовывает свой код, который нужно выполнить для побега из песочницы в процесс которому система доверяет. Обычно чужой код в чужом приложении не смертелен. Но приложение телефонии объявлено как часть системы: оно живёт не отдельно, а прямо в system_server, главном процессе Android, с системным идентификатором. Всё, чужой код внутри.

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

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

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

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

Самый главный момент здесь - не косяки "гугловских инженеров". Они взяли и тупо убрали проверку с которой я начал описание. Просто взяли, откатили то что накосячили, и - ура, мы закрыли уязвимость! Самое главное - это то, что завтра найдут новую дыру, где-нибудь в стеке bluetooth, и она точно так же по цепочке приведет к эскалации в ядре. Ядро на апстриме первый раз пофиксили от DirtyFrag еще в 2017-ом, но фикс тут же обошли. Последняя заплатка на его разновидность Fragnesia показала что сам класс уязвимостей будут юзать всегда, находить новые дыры, составлять новые цепочки.

Нужно помнить главное: ваша безопасность - ваша забота.

То что там где-то что-то пофиксили в апстриме, совершенно не означает что устройство в ваших руках безопасно. Уязвимость оставалась не закрытой три месяца с момента публикации. Флагманский смартфон от Google уязвим спустя три месяца после исправления ядра. Что там на каких-нибудь китайфонах - вообще представить страшно. Фикс ядра доедет до вас спустя еще месяцы или никогда.

ВАЖНАЯ ИНФОРМАЦИЯ:

Курс и дополнительные уроки посвящены защите данных, финансов и конфиденциальности пользователя. Вопросы прохождения антифрод систем МЕНЯ НЕ ИНТЕРЕСУЮТ!!!

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

Но! Если вы понятия не имеете о своей персональной модели угроз, проще говоря "нахрена мне это нужно" - курс не для вас.

FAQ - t.me/jazzphone/56

Список подходящих устройств:
https://t.me/jazzphone/100

Дополнительные уроки:

2. FCKRKN или как использовать средства обхода и избежать детекта.

Подробнее:
https://t.me/tvoijazz/2632
Стоимость 10к

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

Подробнее:
https://t.me/tvoijazz/2645
Стоимость 20к

Данные уроки уже записаны и выложены.

Дополнительный урок:

1. Защита от криминалистической экспертизы и несанкционированного доступа к данным на смартфоне. Экстренное автоматизированное и ручное удаление данных и ключей шифрования. Основные моменты:

- автоматизированное удаление выбранных данных и приложений при попытке перебора пароля блокировки

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

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

- автоматизированный запуск удаления выбранных файлов с последующей перезаписью свободного пространства на накопителе (возможность восстановления исключается) при подключении к ПК или комплексам по извлечению данных

- поговорим о методике взлома смартфона при помощи комплекса типа UFED в контексте несанкционированного запуска отладки в обход блокировки экрана для последующего снятия данных и защите от этого

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

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

- Dead Switch. Если устройство не разблокировалось владельцем в течение заданного времени, происходит удаление всех/выбранных данных

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

Пример 1: тапнули только вам известным способом по экрану блокировки - открывается реальный рабочий стол с нужными приложениями. Не тапнули - откроется фейковый "бытовой", все критически важные приложения и данные останутся скрыты в системе, доступ к настройкам устройства заблокирован.
Пример 2: нажали на определенную область на экране - удалились все/выбранные данные. На управление жестами возможна привязка любых действий и запуск любых скриптов и команд.

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

- настраиваем "Пароль под принуждением". Внимание! Метод не имеет отношения к общеизвестным способам (Wasted, Duress, Xposed Hooks, etc). Один и тот же пароль, в зависимости от ситуации разблокирует устройство обычным способом или разблокирует устройство и, одновременно, удаляет критически важные данные и запускает перезапись освободившегося пространства незаметно для атакующего

- покажу один из авторских вариантов Duress-пароля (new)*

- разберем понятие "правдоподобного отрицания" и при чем здесь логи (new)

- мастер-класс по поднятию своих сервисов в системе для отслеживания нужных событий. Покажу как я делаю "тревожную кнопку" в своих сборках, без использования стороннего софта создадим собственные демоны на отслеживание физических кнопок, попытки подключения к ПК и тд и встроим их в систему*
———————————————
Продолжительность: 2 дня.
Стоимость участия: 30k

~ Доп.уроки доступны для приобретения только ученикам прошедшим основной курс.

Запись/вопросы @JazzSupport

- защита любого выбранного приложения от открытия посторонним, работаем с activity приложений вместо сторонних блокировщиков

- подмена изображения для системной камеры и камер, встроенных в приложения. Покажу альтернативный софт (new)

- разбираем способ передачи информации с использованием стеганографии без ограничений при работе с PGP-ключами

- подробный разбор защиты от ARP-атаки с простейшим примером такой атаки

- актуальный способ замены системного WebView на альтернативный (Cromite, Vanadium) с возможностью переключения

- делаем свой модуль для подмены/скрытия отпечатков системы. Разбираем, чем работа с props отличается от работы с hooks, нативные методы доступа к идентификаторам и тд.*

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

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

- изменение прав на файлы, замена компонентов прошивки в системах Read-Only через командную строку

- скрытие аккаунтов в настройках системы при досмотре устройства (new)*

- обновление DeviceSpoofer (new)*

- скрытие критически важных настроек от постороннего доступа (new)*

- защита содержимого уведомлений выбранных приложений (смс, мессенджеры, etc) от перехвата (new)*

- блокировка установки/удаления приложений в обход пользователя (как при физическом доступе, например при прохождении контроля, так и при удаленной компроментации) (new)*

- KGuard, защита от локального повышения привилегий на eBPF. Отслеживаем и блокируем несанкционированный root-доступ при удаленных атаках и заражении, отбиваем атаки через эскалацию из непривилегированного процесса, браузерный побег из песочницы, etc (new)*
———————————————
Внимание! Присутствует обновление софта до актуальных версий и замена некоторых решений на альтернативные.

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

Длительность курса: 6 дней.
Стоимость участия: 50k
Начало уроков в 17.00 (Mск)

🔗Требования для участия в курсе: разблокированный загрузчик + ПК с выходом в сеть. Крайне рекомендуется наличие флэшки и USB OTG-адаптера под ваш девайс.

Для самых маленьких - словарик нуба.

Запись/вопросы: @JazzSupport

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

Анонс предстоящего курса!

Старт: 25 сентября

Что в программе:

- Android 16

- работа с кастомными прошивками, получение Root

- поговорим о самых современных и передовых решениях для рутирования на основе ядра и сравним их с классикой

- разберем понятие metamodule, выберем нужный

- используем Google "на минималках" (MicroG)

- подмена/скрытие цифрового отпечатка смартфона и необходимых идентификаторов.
Разберем понятие уникальных и не уникальных идентификаторов
Разберем "необходимое" и "бесполезное"*

- разберёмся с Predator

- защита данных и трафика от контроля со стороны провайдера и оператора

- защита от перехвата мобильного сигнала ложными базовыми станциями (мониторинг)

- защита DNS-запросов, DNSCrypt, DoH и тд.

- разберем варианты и особенности шифрования данных в памяти смартфона

- подмена/скрытие геолокации для приложений, основанная на координатах gps в привязке к базовым станциям операторов мобильных сетей*

- подмена/скрытие данных оператора связи для приложений (код и страна сетевого оператора, страна провайдера sim)*

- подмена окружающих точек доступа для выбранных приложений

- покажу авторский софт для скрытия отпечатков и идентификаторов, запрета чтения сетевого окружения, списка приложений и тд.*

- защита камеры и микрофона от доступа в обход пользователя на современных версиях Android

- подмена установщика приложений в системе, расскажу зачем это может понадобиться

- настройка скрытого зашифрованного "сейфа", с возможностью делать фото прямо внутри защищенного пространства (файлы тут же шифруются). Здесь же можно хранить текстовые заметки и любые документы, создание и скрытие зашифрованных томов с критически важными данными

- реализация утилиты secure delete, для безвозвратного удаления данных на смартфоне (для участников отдельного урока по антикриминалистике - автоматическое удаление с перезаписью полными циклами)

- блокировка доступа к вредоносным хостам и доменам

- современные методы отключения трекеров в приложениях, как системных так и установленных пользователем. Таких как Google Firebase и проч. (рассмотрим несколько вариантов)

- генератор "мусорного трафика", с акцентом на случаи когда он может понадобиться (new)*

- расширенная защита от U-print

- отключение возможной утечки данных через snapshots (миниатюры скриншотов "недавних" приложений)

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

- одновременное использование неограниченного количества рабочих профилей*

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

- отключение утечки трафика при загрузке системы и отключении файервола*

- защита от zero-click атак при открытии ссылок в браузерах (FF)

- шифрование переписки и обмена файлами по любым каналам*

- защита содержимого экрана от скриншотов в любом приложении*

- выборочное скрытие установленных приложений друг от друга

- скрытие любых приложений в системе. Разберем вариант скрытия в отдельном Privacy Space. Приложения скрываются от обнаружения как при проверке устройства, так и друг от друга

- скрываем выбранные файлы и директории на общем накопителе

- маршрутизация трафика (весь/выбранные приложения) смартфона через сеть Tor по схеме Tor-Over-VPN

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

- внесение изменений в манифест приложения, работа с целевым SDK приложения, работа с разрешениями в манифесте, создание собственной подписи

- debloating, разберем альтернативный способ с использованием своего персонального модуля, более безопасный способ

Видимо, это уже можно считать официальным "разводом" звездной пары GrapheneOS и Google Pixel? Или нет? Как трактовать "unable to complete the port"?

Чтобы понимали суть, немного пройдемся по хронологии, а чтобы понимать реально сложный технический контекст, я раскидаю по тексту нужные ссылки :

Август 2025 (после выхода Pixel 10). На фоне того, что Google перестал публиковать device trees, проект успокаивал: изменения приемлемы, все преодолеем. Штаны, полные оптимизма.

Август 2026, заявление о планируемой поддержке Motorola, но Pixel 11 также в планах, все хорошо.

Буквально на следующий день: все хорошо, но не очень: порт под 11-й Pixel может занять месяцы.

Через неделю: все плохо, мы не можем завершить порт на Pixel 11-й серии. Собственно, все.

Graphene уходит к новой возлюбленной - Moto? Google продолжит планомерно переориентировать Pixel с гиковских девайсов на основу для развития Gemini? Про это как-нибудь отдельно расскажу, это тоже интересно, и тоже не лежит на поверхности.

Но в чем причина развода?

Сделать порт нельзя из-за отсутствия поддержки аппаратного memory tagging в софте, в прошивке и хайли лайкли (дословно near certainly hardware) в железе. Вывод графенщиков: Google вырезал важную защитную функцию ради экономии.

Насколько это правдоподобно? Довольно таки да. Tensor G6 это Cortex C1-Ultra + шесть C1-Pro, GPU Imagination PowerVR вместо Mali, TSMC 3 нм вместо ожидавшихся 2 нм, плюс смена модема на MediaTek. По железу - это однозначный регресс после 10-ки. За тот же, или больше, прайс в рознице.

Но! Отсутствие MTE, который появился на Pixel 8 - это не причина отказаться от поддержки Pixel 11, это тупо поза, в которую встает проект GrapheneOS. Без поддержки MTE в железе графеновские сборки были и есть и на Pixel 7, и на Pixel 6, хоть там и держится все на одном hardened_malloc (это я упростил, конечно). Просто сборка не была завязана на ARM Memory Tagging Extension (MTE), что не мешало им позиционироваться как секьюр. Но поза вполне понятная: принять в 2026 году новый флагман, который по защите слабее трёхлетнего Pixel 8, означает создать ситуацию, где "самый новый" становится "самым слабым". И самым дорогим в линейке. Отсутствие MTE бьет конкретно по сопротивлению к AFU-экстракции и целевым цепочкам, то есть ровно по тому чем славится GrapheneOS. Плюс цена сопровождения: целое семейство устройств с урезанными защитами и вечные костыли в коде. Но проблема не только и не столько в этом. Проблема тут в том, что Google не дает исходники под Pixel, как делал это раньше. И графенщикам нужно брать и вручную реверсить девайс, на ходу придумывая решения чтобы не уронить свою же планку, которую они задрали понадеявшись на то что Google их не подставит. А это требует таких ресурсов, что проще уйти на Motorola, которая рассматривает это как коммерческий актив и (если) реально намерена партнерить.

Ну и, справедливости ради - near certainly hardware означает, что они не доказали отсутствие MTE в кремнии. Если окажется, что блок есть, но не инициализируется прошивкой, Google может это включить обновлением, и порт возобновится. Только ему это нахрен не нужно. Кроме того, с 2027 года все флагманские Snapdragon получат зрелый MTE и значительно улучшенный secure element. А это уже серьезное отличие от актуальных Moto, которые, мягко говоря, не тянут планку. Ну и, стоит понимать, что текущий расклад вполне может вывести Moto на роль гиковского устройства с лояльной политикой к разного рода кастомам, а Pixel - к обвязке вокруг Gemini с намертво закрытым загрузчиком.

Пошли за попкорном.

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

Отличная прога для тех кому это нужно:
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), собранный не "склейкой чужих списков", а с чисткой, дедупом и собственными дополнениями поверх десятков источников. Обновляется автоматически, де-факто сейчас это эталон в нише блокировки рекламы, фишинга, малвари и тд.

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