Мне стало интересно, почему это происходит. Так что самое время сделать кратку выжимку и разобраться, насколько все плохо на самом деле

Для желающих прочитать оригинал или узнать больше технических моментов - очень советую прочитать оригинальную статью с Хабра

Первым делом рассмотрим систему загрузки плагинов и тот самый RCE.

В exteraGram зашит механизм динамического обновления и работы с плагинами -PythonPluginsEngine. Сам по себе функционал плагинов - штука удобная. Но то, как это реализовано под капотом, мягко говоря, пугает

Схема работы выглядит так:

Telegram-канал со скриптами
      ↓
Скачивание кода / .so / Python прямо из Telegram
      ↓
Проверка подписи (ЭЦП)? НЕТ
      ↓
Запуск прямо в процессе Telegram (с его UID)

Клиент качает исполняемые модули прямо из постов Telegram-канала и выполняет их в едином адресном пространстве приложения. При этом в цепочке загрузки вообще нет проверки цифровой подписи (ЭЦП). Вдобавок прописаны флаги вроде can_not_skip, чтобы обойти окно установки

Что это значит на практике? Если кто-то угнать Telegram-канал разработчиков или подменит файл, он получает возможность скрытно запустить свой код на вашем телефоне. И у него будут ровно те же права, что и у самого Telegram

И вот это - самый настоящий Remote Code Execution (RCE), без всяких оговорок.

Теперь заглянем в «Безопасный режим» (Safe Mode)

В официальном патчноуте версии 12.9.0 авторы гордо заявили, что добавили безопасный режим для работы с плагинами

Открываем декомпилятор, находим PythonPluginsEngine.java и ищем реализацию. И что мы там видим? Ровно одну строчку:

Java

if (safeMode) {
    return;
}

Все. Это не изоляция, не песочница на уровне ОС и не ограничение прав через SecurityManager. Это банальный тумблер: либо загрузка выключена полностью, либо, если она включена, код выполняется с полным доступом ко всему процессу

Разберем «запредельную» защиту: LSParanoid, OLLVM и забытый strip.

В чатах авторы очень любили рассказывать про свои крутые защиты. И накручено там реально немало:

1. Python-модули плагинов скомпилированы через Cython в нативные библиотеки .so.
2. Библиотеки прогнаны через кастомный OLLVM с запутыванием потока управления (Control Flow Flattening).
3. Весь Java-код наглухо зашифрован обфускатором LSParanoid (математика на базе SplitMix64, битовые сдвиги rotl на 9, 10, 13 и XOR-ы с массивами).

Казалось бы, глухая оборона. Но разработчики совершили детскую ошибку: они забыли сделать strip для нативных .so библиотек

Утилита strip вычищает отладочную информацию. Забыв ее выполнить, авторы подарили реверсерам все внутренние пути сборки SDK, точную версию Cython и имена функций прямо на блюдечке. Вся сложная OLLVM-обфускация обнулилась одной незапущенной командой. А для Java-части с LSParanoid автор исследования просто написал декриптор на Python, который за секунды расшифровал все строки

Что вредоносный код сможет спереть?

Вредоносной либе вообще не нужно ломать Android или получать root. Ей уже дали место прямо внутри процесса Telegram, с его UID и правами

Что получает атакующий при запуске своего кода:

• Данные авторизации: Прямой доступ к auth_key, сессиям и токенам.
• Переписку и файлы: Доступ к локальным базам со всеми чатами, медиа и кэшем.
• Telegram API: Возможность от вашего лица отправлять сообщения, читать диалоги и совершать любые действия в сети.
• Ресурсы устройства: Камеру и микрофон, если разрешения для Telegram уже были выданы.

В каком случае сессиям реально настанет пизда и каковы шансы?

Файлы качаются напрямую с серверов Telegram по зашифрованному протоколу MTProto, поэтому перехватить трафик (классический MitM) тут физически невозможно

Когда аккаунтам реально пизда:

1. Угнали Telegram-канал разработчиков. Кто-то ломает аккаунт админа канала, откуда клиент качает плагины, и редактирует пост, заливая туда зловредный .so или Python-модуль.
2. Злой умысел или инсайдер. Владелец канала сам выкладывает модуль со стилером.

Поскольку никакой проверки ЭЦП нет, exteraGram молча схавает поддельный файл, завантажит его в память и отдаст ключи от вашего аккаунта

Каковы шансы такого исхода?

• В обычный день: Относительно низкие. Пока админов не взломали, прямо сейчас ничего не утечет.
• Системный риск: Огромный. Безопасность вашей сессии теперь буквально равна безопасности аккаунта админа канала exteraGram. Один успешный фишинг админа - и тысячи пользователей в ту же секунду теряют свои аккаунты.

Итоги

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

Моя личная рекомендация

На фоне данной ситуации очень хочу посоветовать отказаться от использования exteraGram/AyuGram. Учитывая ситуацию и то, как разработчик exteraGram относится к своему же продукту (его отношение к своему же продукту можете прочитать в оригинальной статье) - отказ от данного клиента будет лучшим вариантом

Мне стало интересно, почему это происходит. Так что самое время сделать кратку выжимку и разобраться, насколько все плохо на самом деле

Для желающих прочитать оригинал или узнать больше технических моментов - очень советую прочитать статью с Хабра

Первым делом рассмотрим систему загрузки плагинов и тот самый RCE.

В exteraGram зашит механизм динамического обновления и работы с плагинами -PythonPluginsEngine. Сам по себе функционал плагинов - штука удобная. Но то, как это реализовано под капотом, мягко говоря, пугает

Схема работы выглядит так:

Telegram-канал со скриптами
      ↓
Скачивание кода / .so / Python прямо из Telegram
      ↓
Проверка подписи (ЭЦП)? НЕТ
      ↓
Запуск прямо в процессе Telegram (с его UID)

Клиент качает исполняемые модули прямо из постов Telegram-канала и выполняет их в едином адресном пространстве приложения. При этом в цепочке загрузки вообще нет проверки цифровой подписи (ЭЦП). Вдобавок прописаны флаги вроде can_not_skip, чтобы обойти окно установки

Что это значит на практике? Если кто-то угнать Telegram-канал разработчиков или подменит файл, он получает возможность скрытно запустить свой код на вашем телефоне. И у него будут ровно те же права, что и у самого Telegram

И вот это - самый настоящий Remote Code Execution (RCE), без всяких оговорок.

Теперь заглянем в «Безопасный режим» (Safe Mode)

В официальном патчноуте версии 12.9.0 авторы гордо заявили, что добавили безопасный режим для работы с плагинами

Открываем декомпилятор, находим PythonPluginsEngine.java и ищем реализацию. И что мы там видим? Ровно одну строчку:

Java

if (safeMode) {
    return;
}

Все. Это не изоляция, не песочница на уровне ОС и не ограничение прав через SecurityManager. Это банальный тумблер: либо загрузка выключена полностью, либо, если она включена, код выполняется с полным доступом ко всему процессу

Разберем «запредельную» защиту: LSParanoid, OLLVM и забытый strip.

В чатах авторы очень любили рассказывать про свои крутые защиты. И накручено там реально немало:

1. Python-модули плагинов скомпилированы через Cython в нативные библиотеки .so.
2. Библиотеки прогнаны через кастомный OLLVM с запутыванием потока управления (Control Flow Flattening).
3. Весь Java-код наглухо зашифрован обфускатором LSParanoid (математика на базе SplitMix64, битовые сдвиги rotl на 9, 10, 13 и XOR-ы с массивами).

Казалось бы, глухая оборона. Но разработчики совершили детскую ошибку: они забыли сделать strip для нативных .so библиотек

Утилита strip вычищает отладочную информацию. Забыв ее выполнить, авторы подарили реверсерам все внутренние пути сборки SDK, точную версию Cython и имена функций прямо на блюдечке. Вся сложная OLLVM-обфускация обнулилась одной незапущенной командой. А для Java-части с LSParanoid автор исследования просто написал декриптор на Python, который за секунды расшифровал все строки

Что вредоносный код сможет спереть?

Вредоносной либе вообще не нужно ломать Android или получать root. Ей уже дали место прямо внутри процесса Telegram, с его UID и правами

Что получает атакующий при запуске своего кода:

• Данные авторизации: Прямой доступ к auth_key, сессиям и токенам.
• Переписку и файлы: Доступ к локальным базам со всеми чатами, медиа и кэшем.
• Telegram API: Возможность от вашего лица отправлять сообщения, читать диалоги и совершать любые действия в сети.
• Ресурсы устройства: Камеру и микрофон, если разрешения для Telegram уже были выданы.

В каком случае сессиям реально настанет пизда и каковы шансы?

Файлы качаются напрямую с серверов Telegram по зашифрованному протоколу MTProto, поэтому перехватить трафик (классический MitM) тут физически невозможно

Когда аккаунтам реально пизда:

1. Угнали Telegram-канал разработчиков. Кто-то ломает аккаунт админа канала, откуда клиент качает плагины, и редактирует пост, заливая туда зловредный .so или Python-модуль.
2. Злой умысел или инсайдер. Владелец канала сам выкладывает модуль со стилером.

Поскольку никакой проверки ЭЦП нет, exteraGram молча схавает поддельный файл, завантажит его в память и отдаст ключи от вашего аккаунта

Каковы шансы такого исхода?

• В обычный день: Относительно низкие. Пока админов не взломали, прямо сейчас ничего не утечет.
• Системный риск: Огромный. Безопасность вашей сессии теперь буквально равна безопасности аккаунта админа канала exteraGram. Один успешный фишинг админа — и тысячи пользователей в ту же секунду теряют свои аккаунты.

Итоги

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

Моя личная рекомендация

На фоне данной ситуации очень хочу посоветовать отказаться от исползования плагинов как таковых (в целом их удалить), либо же вовсе отказаться от использования exteraGram/AyuGram. Учитывая ситуацию и то, как разработчик exteraGram относится к своему же продукту (его отношение к своему же продукту можете прочитать в оригинальной статье) - отказ от данного клиента будет лучшим вариантом

Я решил поискать информацию на счет этого везде — гуглил, искал по форумам, дорыл даже до китайских. Самое время сделать выжимку всей информации, что я нашел.

Первым делом рассмотрим NOS production: error (-7).

Данная ошибка сигнализирует о том, что процессор не может связаться с чипом безопасности Titan. Ошибка -7 — тайм-аут. Говоря просто — процессор не получил ответ от чипа, сколько бы не ждал этого самого ответа.

Сам по себе чип предназначен для защиты Google Pixel. Он имеет свою ОЗУ, свою ПЗУ и криптографический сопроцессор (это будет важно в дальнейшем).

Что делает чип на самом деле? Хранит в себе криптографические ключи, сверяет подписи загрузчики и подписи ядра ОС. Также он пытаетсся обезопасить смартфон от подмены прошивки, путем этих самых сравнений цифровых подписей. При несовпадении подписей он блокирует запуск системы и выдает предупреждение. На самом деле чип делает куда больше, но объяснять все это займет слишком много текста, вернемся к изначальной теме статьи.

Конкретно в этом случаем мы видим Device state: error!
Что это значит? Телефон буквально не понимает на месте ли чип в принципе. Он пытается связаться с ним по шине SPI/I2C для получения криптографического ключа, но от чипа нет ответа от слова совсем. Последствия данной ошибки: ПОЛНАЯ блокировка обращений к UFS. Телефон видит данную ситуацию как попытку обойти защиту чипа. Без доступа к чипу телефон не может расшифровать ни одного байта памяти, вместо них он видит абсолютно случайный набор байтов, фактически белый шум. Как бонус — загрузчик теряет доступ к разделам.

Как это работает? В процессорах Google Tensor присутствует аппаратный блок ICE (Inline Crypto Engine), располежен он на шине между процессором и памятью, занимается он дешифровкой и шифровкой данных по алгоритму AES. Для дешифровки ему необходим ключ шифрования, который хранится в изолированной зоне чипа Titan. При состоянии error! процессор не может получить данный ключ.

Как оживить телефон в данной ситуации? Никак. Буквально. Единственное, что ты можешь сделать — заменить материнскую плату, либо пытаться перепаять чип Titan (что вряд-ли поможет, куда проще и надежнее заменить плату). Прошив тут невозможен физически.

Почему тут невозможно просто отформатировать UFS и залить новую прошивку?

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

Зона RPMB (Replay Protected Memory Block) — сверхзащищенная зона в UFS-накопителе, записать туда что-либо возможно только если запрос подписан ключом, который (ой как неожиданно) хранится в чипе Titan. Что в этой зоне находится? Счетчик попыток ввода пароля, состояние блокирвки загрузчика и хэши системных разделов.

В дополнении к ней существует Write Protection — загрузчик при старте проверяет статус RPMB. Поскольку связи с чипом безопасности нет загрузчик никак не может верифицировать подписи и авторизовать запись в системные разделы UFS. Фактически контроллер памяти в такой ситуации попросту отклоняет любые команды записи на аппаратном уровне.

Теперь рассмотрим Device state: error (-1).

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

В первом случае — процессор отправляет запрос на чтение, по шине связь идет, но в ответ процессор получает только ошибку передачи данных. Это может быть как сбоем шины, то и сбоем чипа, либо вовсе отсутствием на нем питания. Если после обновления вылезла такая ошибка — вероятнее всего либо произошел скачок питания, либо перегрев чипа. Результат — чип остался с поврежденным загрузочным сектором. По итогу он остается в вечном аппаратном ступоре и не может ничего сделать. Телефон в данной ситуации считает, что чипа безопасности нет в принципе.

Единственный вариант ремонта — замена материнской платы.

Что еще в теории может помочь?

Буду честен — не питай надежды, что все будет легко, просто и тем более дешево.

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

Второй вариант — попробовать даунгрейд прошивки.

Результат? Отказано. Anti-rollback существует и активно работает.

Итоги

На самом деле такая ошибка ОГРОМНАЯ редкость, но от нее не застрахован никто. Единственная надежда — сдавать телефон по гарантии (актуально только для тех, у кого гарантия все еще активна и кто находится в любой стране, в которой Google официально предоставляет свои телефоны и сервисные центры). Если же ты в России или у тебя попросту закончилась гарантия — покупай донора, меняй плату.

Важная помарка

Всю информацию я беру из открытых источников, в том числе форумов. В некоторых пунктах могут быть ошибки, поскольку документации от Google у меня нет, я не гарантирую абсолютную точность статьи, но хотя бы попытался разобраться в ситуации и предостеречь от бесполезных потугов "починить на авось"

Давайте вспомним кто же начал этот тренд в рамках вообще всего бренда. 2018 год. Huawei начали подозревать в шпионаже, после чего они закрыли возможность разблокировки загрузчика. Затем начали подтягиваться LG, Asus, Vivo и так далее. Некоторые начали заметно усложнять разблокировку, например Xiaomi.

Тем временем Google ввели Anti-Rollback на Pixel 6 и 8 серии. Возможно со временем это доберется и до остальных серий. Вместе с этим Google планируют усложнить установку APK, требуя для их установки сертификаты.

У Apple тоже с этим не все в порядке. Хотя бы поставить версию iOS ниже можно, только если ее подпись от самих же Apple все еще активна. Те же приколы с сертификатами для установки приложений.

А теперь давайте посмотрим что же находится под капотом Android/iOS. Android в качестве ядра имеет при себе Linux. Ядро, задуманное как позволяющее ПОЛНОСТЬЮ контроллировать устройство. Абсолютная свобода, абсолютный энтузиазм и открытый код. Что делают Google вместе с остальными производителями смартфонов? Кастрирует ядро в хлам. Настолько, что оно теряет весь свой смысл. И еще сильнее кастрируют его возможности блокируя возможно разблокировки загрузчик, тем самым отбирая у пользователей root-права*. Что же находится под капотом iOS? Darwin, который в свою очередь основан на XNU, а уже тот на BSD + Mach. Абсолютный франкештейн. Закрытый код, стабильность, но все еще контроль над системой. И Apple в iOS это... Просто отобрали.

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

И отдельно хотелось бы выделить Vivo. Это абсолютный апофеоз ограничений. Мало того, что у тебя нет возможности разблокировать загрузчик и активен Anti-Rollback, так тебе еще и искусственно накидывают невозможность использовать приложения от ColorOS/OxygenOS/RealmeUI — прошивок, которые принадлежат ровно тому же холдингу. Да, многие из них ставятся. Только вот исхода у тебя два. 1 — Тебе на китайском языке выдается предупреждение о том, что требуешь слишком много свободы. Дословно "{Название приложения} является кастомизированным приложением и несовместимо с текущим устройством", после чего вылетает. 2 — Оно просто вылетает и может положить тебе лаунчер. Окончательно добила невозможность смены лаунчера на китайской версии OriginOS. То есть невозможно ни выкинуть часть приложений, ни почистить систему от мусора, банально невозможно откатить систему, невозможно получить root-права, невозможно использовать приложения, созданные буквально тем же холдингом и моментами буквально идентичные, так еще и банально невозможно кастомизировать систему.

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

Раньше Android-смартфоны ценили именно за свободу — кастомные прошивки, ядра, root, модификации интерфейса. Сейчас же индустрия постепенно двигается к модели «телефон как сервис», где пользователь превращается не во владельца устройства, а в арендатора с ограниченным набором разрешенных действий.

И самое тревожное здесь даже не сами ограничения, а то, насколько быстро люди начинают считать их нормой. Новое поколение пользователей уже воспринимает невозможность разблокировки загрузчика, запрет на установку стороннего ПО или жесткую привязку к экосистеме как что-то естественное. Производители годами приучали аудиторию к мысли, что свобода — это неудобно, root — зло, а открытая система обязательно приведет к вирусам и поломкам. В итоге рынок постепенно приходит к тому, что Android теряет собственную идентичность и всё сильнее копирует философию iOS — только без той оптимизации и целостности, ради которых Apple изначально строила свою закрытую экосистему.

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

*root-права — учетная запись главного администратора в операционных системах на базе Linux, открывающая неограниченный доступ ко всем системным файлам и настройкам, позволяя получить абсолютный контроль над системой.