быдло.jazz
Защищенные смартфоны, комплексное обучение, направленное на анонимность и безопасность пользователя. Android only. Прайс/услуги @jazzphone Отзывы @spasibojazz @onejazz - автор @jazzsupport - саппорт Не имеем чатов и групп, не делаем рекламу.
显示更多📈 Telegram 频道 быдло.jazz 的分析概览
频道 быдло.jazz (@tvoijazz) 俄语 语言赛道中的 是活跃参与者。目前社区聚集了 11 789 名订阅者,在 技术与应用 类别中位列第 10 196,并在 俄罗斯 地区排名第 54 183 位。
📊 受众指标与增长动态
自 невідомо 创建以来,项目保持高速增长,吸引了 11 789 名订阅者。
根据 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 уязвим спустя три месяца после исправления ядра. Что там на каких-нибудь китайфонах - вообще представить страшно. Фикс ядра доедет до вас спустя еще месяцы или никогда.
