быдло.jazz
Защищенные смартфоны, комплексное обучение, направленное на анонимность и безопасность пользователя. Android only. Прайс/услуги @jazzphone Отзывы @spasibojazz @onejazz - автор @jazzsupport - саппорт Не имеем чатов и групп, не делаем рекламу.
إظهار المزيد📈 نظرة تحليلية على قناة تيليجرام быдло.jazz
تُعد قناة быдло.jazz (@tvoijazz) في القطاع اللغوي الروسية لاعباً نشطاً. يضم المجتمع حالياً 11 788 مشتركاً، محتلاً المرتبة 10 196 في فئة التكنولوجيات والتطبيقات والمرتبة 54 183 في منطقة روسيا.
📊 مؤشرات الجمهور والحراك
منذ تأسيسه في невідомо، حقق المشروع نمواً سريعاً وجمع 11 788 مشتركاً.
بحسب آخر البيانات بتاريخ 29 سبتمبر, 2026، تحافظ القناة على نشاط مستقر. خلال آخر 30 يوماً تغيّر عدد الأعضاء بمقدار 29، وفي آخر 24 ساعة بمقدار -1، مع بقاء الوصول العام مرتفعاً.
- حالة التحقق: غير موثّقة
- معدل التفاعل (ER): يبلغ متوسط تفاعل الجمهور 46.62%. وخلال أول 24 ساعة من النشر يحصد المحتوى عادةً 14.28% من ردود الفعل نسبةً إلى إجمالي المشتركين.
- وصول المنشورات: يحصل كل منشور على متوسط 5 495 مشاهدة. وخلال اليوم الأول يجمع عادةً 1 683 مشاهدة.
- التفاعلات والاستجابة: يتفاعل الجمهور بانتظام؛ متوسط التفاعلات لكل منشور يبلغ 0.
- الاهتمامات الموضوعية: يركز المحتوى على مواضيع رئيسية مثل шифрование, идентификатор, девайс, отключение, разберем.
📝 الوصف وسياسة المحتوى
يصف المؤلف القناة بأنها مساحة للتعبير عن الآراء الذاتية:
“Защищенные смартфоны, комплексное обучение, направленное на анонимность и безопасность пользователя. Android only.
Прайс/услуги @jazzphone
Отзывы @spasibojazz
@onejazz - автор
@jazzsupport - саппорт
Не имеем чатов и групп, не делаем рекламу.”
بفضل وتيرة التحديث المرتفعة (أحدث البيانات بتاريخ 30 سبتمبر, 2026) تحافظ القناة على حداثتها ومستوى وصول مرتفع. وتُظهر التحليلات تفاعلاً نشطاً من الجمهور، ما يجعلها نقطة تأثير مهمة ضمن فئة التكنولوجيات والتطبيقات.
«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 уязвим спустя три месяца после исправления ядра. Что там на каких-нибудь китайфонах - вообще представить страшно. Фикс ядра доедет до вас спустя еще месяцы или никогда.
