быдло.jazz
Защищенные смартфоны, комплексное обучение, направленное на анонимность и безопасность пользователя. Android only. Прайс/услуги @jazzphone Отзывы @spasibojazz @onejazz - автор @jazzsupport - саппорт Не имеем чатов и групп, не делаем рекламу.
Ko'proq ko'rsatish📈 Telegram kanali быдло.jazz analitikasi
быдло.jazz (@tvoijazz) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 11 788 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 10 196-o'rinni va Rossiya mintaqasida 54 183-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 11 788 obunachiga ega bo‘ldi.
29 Sentabr, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni 29 ga, so‘nggi 24 soatda esa -1 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 46.62% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 14.28% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 5 495 marta ko‘riladi; birinchi sutkada odatda 1 683 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 0 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent шифрование, идентификатор, девайс, отключение, разберем kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Защищенные смартфоны, комплексное обучение, направленное на анонимность и безопасность пользователя. Android only.
Прайс/услуги @jazzphone
Отзывы @spasibojazz
@onejazz - автор
@jazzsupport - саппорт
Не имеем чатов и групп, не делаем рекламу.”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 30 Sentabr, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
«If you forget your PIN or password, unlock your device using your linked Google account.»Если это не повод отказаться от Google, то я не знаю, что тогда повод. https://www.androidauthority.com/android-unlock-with-google-account-apk-teardown-3713919/ Функция заявлена как опция, но само её наличие, даже в выключенном виде, создаёт штатный путь, серверную инфраструктуру и юридическую точку давления на Google. Строго говоря, модель доверия и раньше была такой же: производитель прошивки контролирует код фреймворка и может встроить в него что угодно. Но в AOSP escrow-токены на неуправляемых телефонах отключены криптографически. addWeakEscrowToken работает только на automotive, а escrow-данные пользователя уничтожаются после настройки устройства. Чтобы обойти это, пришлось бы менять системный код и тайно поставлять изменение в прошивке. Новая функция по своей сути требует обратного: секрет, из которого восстанавливается ключ пользовательских данных, должен быть доступен через фактор, который контролирует Google. Проще говоря, теоретическая возможность превращается в штатный процесс. Вопрос на миллион долларов: может ли Google отказаться выполнить судебный приказ о техническом содействии в разблокировке конкретного устройства, если его привязка к аккаунту установлена, а разблокировка признана необходимым процессуальным действием? Приказ можно оспаривать, но для этого нужно чтобы Google хотел этого, что сильно вряд ли. Юрисдикция обязывает ко многому. Инструмент для исполнения приказа есть. Принципиальная техническая возможность имеется. Если пользователь включит функцию. Если, конечно, она вообще появится в прошивках. Но если реально появится, что скорее всего, то изъятый (в том числе BFU) аппарат, где функция была включена, открывается по аккаунту в любой момент, без владельца, минуя перебор. То что функция должна быть непременно включена - не факт. Вживую финальный код можно будет изучить только когда он будет на устройствах.
Это самая невероятная уязвимость, которую я когда-либо видели
Удивительно, что даже инженер Google может совершить такую большую ошибку в эпоху искусственного интеллектаХотел рассказать про другое, но как тут про другое, когда такие цитаты. В общем, вот вам очередной наброс от команды LSPosed и, соответственно, очередной проеб от Google. Это действительно интересно, и это нужно знать, если вы хоть немного хотите понимать что за железку держите в руках. Постараюсь максимально просто. Цепочка эксплойтов состоит из двух CVE - брешь в стеке телефонии 17-го Андроида и пробоина в ядре. Работает это в три шага: 1. Для начала, нужно оказаться внутри процесса, которому система доверяет. Если установленное приложение заявляет "я могу обрабатывать звонки", но на самом деле не может, то система лезет к несуществующему классу и падает. В Android 17 добавили проверку: перед обращением убедиться, что класс реально есть. Чтобы узнать, есть ли класс в чужом приложении, нужно взять загрузчик кода этого приложения. Приложение телефонии так и делает, но... Проверяя заодно и исполняет загруженный код. Это тот самый "гугловский инженер" упорол косяк. Приложение подсовывает свой код, который нужно выполнить для побега из песочницы в процесс которому система доверяет. Обычно чужой код в чужом приложении не смертелен. Но приложение телефонии объявлено как часть системы: оно живёт не отдельно, а прямо в system_server, главном процессе Android, с системным идентификатором. Всё, чужой код внутри. 2. Из системного процесса запустить обычный машинный код нельзя, политики запрещают. Но там же, в этом процессе, лежит список связей со всеми остальными процессами. По этому списку атакующий дотягивается до сетевого процесса и заставляет его загрузить свой код. Сетевой процесс нужен потому, что ему разрешено работать с шифрованными соединениями IPsec, а именно там третья дыра. Самая основная. 3. Телефон держит содержимое открытых файлов в оперативной памяти, чтобы не читать с диска по десять раз. Влез в этот фрагмент памяти - можешь контролировать то что исполняется в текущий момент. Права на файл, разумеется, проверяются, иначе у всего на устройстве был бы root. Но проверяются они только к файлу на диске. К файлу, который открыт в памяти - нет. Поскольку подразумевается что писать туда будет только ядро. А раз только ядро, то на тебе, ядро, дополнительные плюшки. Например отправка без копирования в отдельный буфер и расшифровка на месте. Атакующий делает так, чтобы эти два фактора встретились. Он собирает пакет, один из кусков которого - это ссылка на память с системным файлом, и скармливает этот пакет ядру как входящий зашифрованный. Ядро его расшифровывает и пишет в файл, на который указывает ссылка. После этого бесполезны все проверки и тд. Устройство скомпроментировано. Переписанный кусок файла срабатывает, когда его вызывает системный процесс, и дальше по цепочке: исполнение уходит в init, оттуда в ядро грузится чужой модуль, SELinux переводится в разрешающий режим, пиздец вашему устройству и ядерный апокалипсис. Самый главный момент здесь - не косяки "гугловских инженеров". Они взяли и тупо убрали проверку с которой я начал описание. Просто взяли, откатили то что накосячили, и - ура, мы закрыли уязвимость! Самое главное - это то, что завтра найдут новую дыру, где-нибудь в стеке bluetooth, и она точно так же по цепочке приведет к эскалации в ядре. Ядро на апстриме первый раз пофиксили от DirtyFrag еще в 2017-ом, но фикс тут же обошли. Последняя заплатка на его разновидность Fragnesia показала что сам класс уязвимостей будут юзать всегда, находить новые дыры, составлять новые цепочки. Нужно помнить главное: ваша безопасность - ваша забота. То что там где-то что-то пофиксили в апстриме, совершенно не означает что устройство в ваших руках безопасно. Уязвимость оставалась не закрытой три месяца с момента публикации. Флагманский смартфон от Google уязвим спустя три месяца после исправления ядра. Что там на каких-нибудь китайфонах - вообще представить страшно. Фикс ядра доедет до вас спустя еще месяцы или никогда.
