Всем привет! Сегодня я хочу поделиться историей одного странного и затянувшегося расследования, главным героем которого стал мой компьютер, а антагонистом — веб-версия Telegram. Эта история не только о поиске прожорливого процесса, но и о глубоких аномалиях в поведении современных веб-приложений, которые вызывают серьезные вопросы.
Пролог: Внезапный враг внутри Chrome
Я не системщик и не шарю особо в безопасности и в том как бы схватить за хвост призрака, даже если он майнер, думаю в комментариях умные люди раскроют ситуацию и дадут рекомендации как действовать.
Все началось буднично. Я заметил, что дома слишком жарко, а кулеры процессора вышли на взлетный режим. Беглый взгляд на диспетчер задач Windows показал, что один из процессов chrome.exe стабильно отъедает около 30% моего 16-ядерного процессора, работающего на частотах 5+ ГГц. Для понимания масштаба: это нагрузка, сопоставимая с рендерингом видео в After Effects, но сейчас я просто сидел в браузере и ни одна из моих вкладок не содержала анимаций или вычислений для такой нагрузки.
Первая мысль — найти виновную вкладку. Я обратился за помощью к ChatGPT, который любезно подсказал стандартный путь: встроенный диспетчер задач Chrome по Shift + Esc.
Проблема была идентифицирована практически сразу. Процесс с PID 7136, ответственный за львиную долю нагрузки, оказался Dedicated Worker: https://web.telegram.org/k/rlottie.worker-DkltbnkR.js. То есть, виновником была вкладка с Telegram Web (которую я закрыл дня 4 тому назад), т е среди активных вкладок виновников не было.
Казалось бы, инцидент исчерпан. Закрыть вкладку — и дело с концом. Но тут-то и началось самое интересное.
Акт I: Неубиваемый процесс и белый экран
Я попытался зайти в Telegram Web снова, но вместо привычного интерфейса меня встретил абсолютно белый экран. Вкладка была пуста. Но процесс-воркер никуда не делся и продолжал молотить на 30% CPU.
Что я только не делал:
Несколько раз перезагружал вкладку через
Ctrl + Shift + R(жесткая перезагрузка с очисткой кэша).Закрывал и открывал вкладку заново.
Пытался зайти по прямым ссылкам на чаты.
Результат был один — белый экран и не стихающий гул кулеров. Самое странное, что процесс пережил несколько дней, две перезагрузки компьютера и два сбоя электричества. Он просто запускался вместе с Chrome и продолжал свою разрушительную деятельность.
Это первая и главная аномалия. Поведение, абсолютно нетипичное для обычного веб-скрипта. Мои подозрения переросли в паранойю: а не майнер ли это, который так хитро маскируется под системный воркер Telegram?
Акт II: Расследование. Подозрительные улики
Я снова обратился к AI-помощнику с просьбой провести более глубокое исследование и помочь собрать доказательства. В ходе нашего диалога вскрылся целый пласт странностей в архитектуре Telegram Web.
Странность №1: Феноменальная персистентность Service Worker
В чем аномалия: Service Worker (SW) — это скрипт, который браузер запускает в фоновом режиме, отдельно от веб-страниц. Он нужен для пуш-уведомлений, фоновой синхронизации и работы в офлайне. По спецификации, SW должен выгружаться из памяти после короткого периода бездействия, чтобы не расходовать ресурсы. В моем случае воркер не просто жил, а активно работал несколько суток, переживая перезагрузки ОС, несколько сбоев электричества, полное отключение от сети два раза и один раз на 8 часов!
Техническое объяснение: Такое поведение может быть вызвано либо багом в самом воркере, который входит в бесконечный цикл, либо некорректной регистрацией, из-за которой Chrome не может его "усыпить". Когда вы запускаете Chrome, он проверяет зарегистрированные SW, и если SW подписан на события (например, fetch), он может активироваться даже без открытой вкладки, перехватывая сетевые запросы. Именно поэтому процесс возрождался снова и снова.
Странность №2: Белый экран при активных воркерах
В чем аномалия: Пользовательский интерфейс (UI) не отрисовывался во время попыток входа на сайт, но когда в хроме не было открыто вкладок Telegram - в фоне работали десятки процессов, связанных с Telegram: rlottie.worker (анимации), crypto.worker (шифрование), mtproto.worker (сетевой протокол).
Техническое объяснение: Это указывает на то, что жизненный цикл SW и UI полностью рассинхронизирован. SW успешно регистрируется и запускает свои дочерние воркеры, но основной скрипт, отвечающий за отрисовку интерфейса, по какой-то причине падает или не может выполниться. В итоге мы получаем "зомби-приложение": фронтенд мертв, а бэкенд в браузере жив и потребляет ресурсы.
Странность №3: Использование blob: URL для загрузки воркеров
В чем аномалия: Многие воркеры (кроме rlottie и tinyld) загружались не с прямого URL вида https://web.telegram.org/worker.js, а через blob: ссылки.
Техническое объяснение: blob: URL — это ссылка на данные, которые сгенерированы динамически прямо в браузере из строки или массива байт. С одной стороны, это позволяет гибко управлять кодом. С другой — это усложняет аудит безопасности. Вы не можете просто посмотреть исходный код скрипта по ссылке. Он создается "на лету", и его содержимое может меняться, что является идеальной средой для маскировки вредоносного кода.
Странность №4: Активный крипто-воркер без секретных чатов
В чем аномалия: В диспетчере задач был замечен crypto.worker-BTYwgy7.js. Но ведь веб-версия Telegram не поддерживает сквозное шифрование (E2EE) и секретные чаты! Зачем ей крипто-воркер?
Техническое объяснение: Это подозрение оказалось ложным, но показательным. Как пояснил AI, протокол MTProto, на котором работает Telegram, использует шифрование не только для секретных чатов. Оно нужно для защиты канала между клиентом и сервером (шифрование Cloud Chats), для генерации ключей авторизации (обмен Диффи-Хеллмана), для шифрования медиафайлов при передаче и для проверки паролей двухфакторной аутентификации. Все эти операции ускоряются за счет выноса в WebAssembly-воркер. Так что его наличие оправдано, но для неискушенного пользователя выглядит подозрительно.
Странность №5: Неэффективность официальных каналов поддержки
В чем аномалия: Как правило техподдержка молчит. Жду их ответы на некоторые обращения уже лет 6, смысл обращаться если пользователь не из ФСБ (Французской Службы Безопасности)?
Техническое объяснение: Это, к сожалению, распространенная проблема крупных сервисов. Но когда речь идет о критическом баге, потребляющем огромное количество ресурсов и вызывающем подозрения в безопасности у обычного пользователя, такая неотзывчивость создает токсичную атмосферу недоверия. Надеюсь кто-то из команды ТГ это прочитает, Аминь!
Акт III: Вердикт — майнинг или чудовищный баг?
После глубокого анализа мы с ГПТ пришли к выводу, что это, скорее всего, не майнинг. Вот аргументы "против":
Отсутствие сторонних подключений. Анализ сетевой активности не показал соединений с известными майнинг-пулами. Все запросы шли на поддомены
telegram.org.Отсутствие кода майнера. Поиск по ключевым словам (
mine,hash,nonce,coinhive,cryptonight) в коде самогоrlottie.worker.jsничего не дал.Природа
rlottie. Это библиотека от Samsung для рендеринга сложных векторных анимаций (Lottie). Они действительно очень ресурсоемкие, и при определенных условиях (отключенное аппаратное ускорение в браузере, баг в версии) могут вызывать колоссальную нагрузку на CPU.
Скорее всего, мы столкнулись с катастрофическим багом, усугубленным несколькими факторами:
"A"-версия Telegram Web, которая использует более тяжелый рендерер анимаций (в отличие от более легкой "K"-версии).
Баг в жизненном цикле Service Worker, который не позволял ему выгрузиться и приводил к зацикливанию.
Эпилог: Как победить монстра и что делать, если вы столкнулись с подобным
Вот пошаговый план, который помог окончательно решить проблему и который я рекомендую всем, кто столкнется с подобным поведением любого веб-приложения.
Принудительно удалить Service Worker. Это самый важный шаг.
Откройте инструменты разработчика (
F12илиCtrl + Shift + I).Перейдите на вкладку
Application->Service Workers.Найдите в списке воркеры, связанные с
web.telegram.org, и нажмитеUnregisterдля каждого из них.Как альтернатива, можно выполнить в консоли скрипт, который убьет всех воркеров на странице:
navigator.serviceWorker.getRegistrations() .then(regs => regs.forEach(reg => reg.unregister())) .then(() => console.log('All service workers unregistered'));
Полностью очистить данные сайта.
На той же вкладке
Applicationперейдите вClear storage.Поставьте все галочки и нажмите
Clear site data.
Включить аппаратное ускорение (в моем случае было включено, что тоже странно).
Зайдите в
Настройки Chrome->Система.Убедитесь, что включен параметр «Использовать аппаратное ускорение, если доступно».
Перейти на K-версию Telegram.
Используйте адрес
https://web.telegram.org/k/. Она значительно легче и оптимизированнее.
Заключение
Хотя прямых доказательств майнинга найдено не было (в силу моей слабой компетентности в этом деле), подозрение есть и эта история — яркий пример того, как совокупность багов, непрозрачной архитектуры (blob: URL) и неотзывчивой поддержки может породить обоснованные подозрения и доставить массу головной боли. Поведение Telegram Web было аномальным, неинтуитивным и враждебным по отношению к пользователю и его ресурсам. Дамп памяти процессора я снял, но разбираться в нем - надо найти время и в принципе большинству пользователей врядли это захочется делать. А от ТГ хотелось бы исправления багов, вместо пукающих и какающих эмоджи.
Надеюсь, мое расследование будет полезно тем, кто столкнется с необъяснимой нагрузкой от браузера. Будьте бдительны и не бойтесь копать глубоко!