Мессенджер MAX: что реально небезопасно и почему

Разбор статьи о мессенджере MAX. Что доказано, что нет - и почему это важно.

Как это получилось

Дал языковой модели Claude почитать сегодняшнюю статью Komandirpetuhov о мессенджере MAX на Пикабу. Попросил оценить.

Первый ответ - структурированная каша с буллетами и заголовками, ничего по делу. Попросил говорить серьёзно - снова декларации и выводы без объяснений. Попросил объяснять, а не декларировать - стало чуть лучше, но всё равно вода.

Когда спросил что реально небезопасно и как это работает на практике - машина решила что я прошу инструкцию для атаки и начала отказывать. Пришлось несколько раз объяснять что мне нужен технический разбор уязвимостей, а не руководство по взлому. Claude не понимал разницы и продолжал отказывать, прячась за этику.

В итоге всё-таки добился внятного ответа. Оказалось что в статье реально доказаны только три вещи: токен авторизации в plaintext, переписка в незашифрованной SQLite-базе, и cleartext HTTP к конкретным доменам прямо в конфиге APK. Всё остальное в статье - либо не проверено, либо раздуто.

Вывод: Claude по умолчанию принимает технические вопросы за злой умысел и отказывает там где не надо. Чтобы получить нормальный ответ, нужно продавливать. Это утомительно и неэффективно.

О чём статья

Автор взял APK мессенджера MAX, разобрал его стандартными инструментами - jadx, apktool, mitmproxy, Frida - и опубликовал результаты. Главный вывод: MAX позиционируется как безопасный мессенджер, но при техническом анализе обнаруживаются три реальные проблемы. Всё остальное в статье либо не доказано, либо раздуто для эффекта.

Попутно выясняется, что MAX - это технически переименованный TamTam из экосистемы VK Group. В декомпилированном коде повсюду пакеты ru.ok.tamtam, база данных называется OneMeRoomDatabase, артефакт сборки - tamtam-app_release. Никакого нового мессенджера нет.

Что доказано - с объяснением почему

1. Токен авторизации хранится в открытом виде

Android SharedPreferences по умолчанию сохраняет данные в обычный XML-файл. Шифрование добавляется отдельно - через Android Keystore API или EncryptedSharedPreferences. Автор нашёл токен okToken в файле auth.prefs, записанный через обычный putString без какого-либо Keystore. Это не интерпретация - это архитектура Android: если Keystore не используется, файл читается как текст без каких-либо инструментов.

Практическое следствие: токен даёт полный доступ к аккаунту - читать переписку, писать от чужого имени, видеть контакты. Без пароля, без SMS. И без привязки к устройству - токен работает откуда угодно.

2. Вся переписка хранится на устройстве незашифрованной

SQLite не шифрует данные по умолчанию. Шифрование добавляется через отдельную библиотеку SQLCipher - она либо есть в зависимостях проекта, либо нет. Автор проверил зависимости и не нашёл net.zetetic:android-database-sqlcipher. Нет библиотеки - нет шифрования. Это не мнение, это проверяемый факт.

Переписка лежит в cache.db, таблица messages, колонка text - как есть, открытым текстом. Любой процесс с достаточными правами читает её обычным SQL-запросом. Никакого взлома, никакой расшифровки.

3. Часть трафика идёт без HTTPS

Файл network_security_config.xml лежит в APK в открытом виде - его разархивирует apktool, после чего он читается как обычный XML. В нём явно прописано cleartextTrafficPermitted="true" для доменов .voskhod.ru и .gov.ru. Это значит, что часть трафика приложения идёт без шифрования - в публичной Wi-Fi сети она читается пассивно, без атаки.

Что в статье не доказано

Часть утверждений автора не подкреплена наблюдениями - и это важно понимать, потому что они написаны с той же уверенностью, что и доказанные факты.

• Контакты отправляются без хеширования - автор сам пишет, что certificate pinning не дал проверить трафик. Он видел код без классов хеширования, но это не означает, что хеширование не происходит на стороне сервера или на другом уровне.
• Геолокация управляется удалённо через SDK - взято из публичной документации MyTracker, а не из реального трафика MAX.
• 32 сервера за 2 минуты - без разбивки по категориям цифра ничего не доказывает. Любое современное приложение при запуске обращается к CDN, проверяет сертификаты через OCSP, загружает конфиги. Это нормально и не связано со слежкой.

Главная проблема статьи

Автор берёт реальные наблюдения и делает из них выводы, которые из этих наблюдений не всегда следуют. Это не подтасовка - скорее всего, он сам не замечает разрыва. Но проблема в том, что доказанное и предполагаемое написаны одинаково уверенно. Читатель не может понять, где факт, а где вывод.

Для широкой аудитории статья полезна: она честно объясняет, что MAX - не безопасный мессенджер в том смысле, в каком люди это понимают. Но как техническое исследование она не проходит минимальную планку строгости - нет версии APK, нет описания методики обхода certificate pinning, часть ключевых утверждений не верифицирована.

Что не указал автор статьи, но следует знать:

Четыре вещи.

Версия APK не указана. Без этого непонятно, актуальны ли результаты прямо сейчас или уже исправлены в следующем обновлении. Исследование без версии артефакта - это рассказ, а не исследование.

Certificate pinning не был обойдён. Автор не видел реальный трафик. Всё что он говорит про передачу контактов, геолокацию и аналитику - это выводы из кода и документации SDK, а не из перехваченных запросов. Код показывает что приложение умеет делать. Трафик показывает что оно делает в реальности. Это разные вещи.

Серверная сторона не анализировалась вообще. Автор говорит что VK видит все сообщения в открытом виде - это верно в смысле отсутствия E2E. Но как именно данные хранятся на серверах VK, зашифрованы ли они там и какими ключами - он не знает и не проверял. Это не снимает проблему, но картина неполная.

Нет ни слова про coordinated disclosure. В security-сообществе стандартная практика - сначала сообщить разработчику, дать время исправить, потом публиковать. Автор пишет "я знаю но не скажу" - но не пишет, уведомлял ли он VK Group. Если уведомлял - это важная информация. Если нет - это безответственно, особенно с учётом пункта 7 где он намекает на критические уязвимости.

Итог

Три вещи в MAX доказаны структурой кода, а не домыслами:

• Токен авторизации хранится незашифрованным и даёт полный доступ к аккаунту без пароля.
• Вся переписка лежит на устройстве открытым текстом.
• Часть трафика идёт без HTTPS - это прямо прописано в конфиге APK.

Плюс к этому: поскольку сквозного шифрования нет, VK Group видит все сообщения всех пользователей на своих серверах. По закону Яровой компания обязана хранить содержимое переписки шесть месяцев и предоставлять по запросу.

Для бытового общения MAX работает нормально. Но считать его защищённым мессенджером - не стоит.

И, вообще, есть и другие риски, неотмеченные автором:

Экосистемный риск. Токен okToken - это не просто токен MAX. Это токен Одноклассников. Если его угнать, открывается доступ не только к переписке в MAX, но потенциально ко всему аккаунту VK Group - ОК, почта Mail.ru, облако. Автор это упомянул вскользь, но не объяснил масштаб.

Резервные копии. Android по умолчанию бэкапит данные приложений в Google Drive, если разработчик не запретил это явно. Если MAX не отключил бэкап - cache.db с перепиской и auth.prefs с токеном уходят в облако Google. Автор об этом вообще не написал.

Invite-ссылки. Автор упомянул в самом конце одной строкой и не объяснил. В ссылке-приглашении зашит твой персональный трекинг-токен. Если ты публикуешь её публично - любой кто перейдёт по ней связывается с твоим аккаунтом, и аналитика VK знает что именно ты привёл этого человека. Это не просто реферальная система - это граф твоих социальных связей.

Метаданные. Даже если сообщения зашифровать - чего здесь нет - VK видит кто, кому, когда и как часто пишет. Это называется метаданные, и они зачастую информативнее содержания. Автор про это не написал вообще.

Удаление данных. Нет ни слова о том, что происходит с данными при удалении аккаунта или приложения. Удаляются ли сообщения с серверов VK, в какие сроки, и удаляются ли вообще - открытый вопрос.

Токен без ротации и отзыва. Автор нашёл plaintext-токен, но не задал следующий вопрос: сбрасывается ли он при выходе из аккаунта? Если logout не инвалидирует токен на сервере украденный токен работает вечно. Если нет ротации он работает годами. Это уже не "плохо сохранили", это архитектурный дефект.

Бэкап. Если в манифесте не выставлен android:allowBackup=false, Android автоматически копирует данные приложения в Google Drive. Включая cache.db и auth.prefs. Ключ шифрования этого бэкапа у Google. Компрометация Google-аккаунта означает компрометацию всей переписки.

Root detection и Frida. Не упомянуто вообще. Если приложение не определяет рутованное окружение и не блокирует Frida/Xposed барьер для атаки снижается с "нужен эксплойт" до "нужен инструмент". Это разница между сложной атакой и тривиальной.

Логирование. Типичный тихий канал утечки. Если токены, ID или эндпоинты пишутся в logcat или crash-репорты они доступны любому приложению с разрешением READ_LOGS. Автор не проверял.

Экспортируемые компоненты. Android позволяет другим приложениям обращаться к activity и сервисам через intent если разработчик не закрыл это явно. Многие утечки происходят не через сеть, а через межпроцессное взаимодействие. Не проверялось.

SDK как независимый канал. MyTracker имеет собственные сетевые каналы и может менять поведение через серверный конфиг без обновления приложения. Это значит что поверхность атаки шире чем то, что видно в APK.

Инвайт-ссылка как устойчивый идентификатор. Автор упомянул что в ней зашит трекинг-токен, но не сказал главного: это устойчивый пользовательский идентификатор, который не требует аутентификации и позволяет коррелировать действия человека вне приложения. Большинство людей не думают что ссылка которую они шарят друзьям это идентификатор который работает и после того как друг зарегистрировался. На самом деле, это уже не просто реферальная система это инструмент слежки за социальным графом.

Что из всего этого следует понимать обычному пользователю без технического бэкграунда:

Первое. Это не защищённый мессенджер в строгом смысле.
В системах с end-to-end шифрованием (как в Signal или WhatsApp) сообщения зашифрованы так, что даже сервер их не читает. В MAX такой модели нет. Это означает простую вещь: содержимое переписки технически доступно на стороне сервиса.

Второе. Данные на вашем устройстве не защищены сами по себе.
Если телефон попадёт в чужие руки (кража, ремонт, вредоносное приложение с правами) - переписка и токены могут быть считаны напрямую. Здесь не требуется взлом в киношном смысле, достаточно доступа к файлам приложения.

Третье. Токен важнее пароля.
В нормальной модели пароль - главный секрет. Здесь фактически главный ключ - это токен, который уже выдан приложению. Если он утёк, пароль может не понадобиться вообще. Поэтому:

• выход из аккаунта не всегда гарантирует мгновенное обнуление сессий
• смена пароля может не закрыть уже выданные токены

Четвёртое. Открытые сети - зона риска.
Если часть трафика идёт без HTTPS, то в публичном Wi-Fi (кафе, транспорт, отели) этот трафик потенциально читается. Это не означает, что всё видно всегда, но риск перехвата выше, чем у приложений, где весь трафик строго зашифрован.

Пятое. Облака и бэкапы - это отдельная точка утечки.
Даже если вы никому не даёте телефон, данные могут оказаться в резервной копии (например, в Google-аккаунте). Тогда доступ к облаку = доступ к переписке.

Шестое. Метаданные не менее важны, чем текст.
Даже без чтения сообщений сервис видит:

• с кем вы общаетесь
• когда и как часто
• с каких устройств
  Это позволяет восстановить социальные связи и поведенческий профиль.

Седьмое. Это тот же старый продукт - не просто деталь.
Если приложение фактически является переработкой другого (в данном случае TamTam из экосистемы VK Group), то:

• наследуются старые архитектурные решения
• новые заявления о безопасности не обязательно означают новую модель защиты

Восьмое. Риски зависят от сценария использования.
Для бытового общения (мемы, бытовые разговоры) - это приемлемо.
Для чувствительной информации (финансы, документы, личные данные, политика) - уже нет.

Девятое. Главный практический вывод.
Не вопрос плохой мессенджер или хороший, а вопрос соответствия задаче:

• если нужна приватность - выбирать решения с end-to-end
• если важна только удобная коммуникация - можно использовать, понимая ограничения

Коротко: MAX - это обычный централизованный мессенджер с рядом слабых мест в реализации. Он не даёт той степени защиты, которую многие по умолчанию ожидают от слова "безопасный".