MAX следит за VPN? Реверс-инжиниринг против официальных пояснений — кто врёт?

[Сергей Попов]

Пользователь runetfreedom на Хабре разобрал APK мессенджера MAX (v26.4.3) через mitmproxy + декомпиляцию и заявил: приложение содержит модуль слежки за VPN и доступностью заблокированных ресурсов.

Что нашли в трафике:

• При сворачивании/разворачивании приложения на api.oneme.ru уходит пакет с пингами до main.telegram.org, mmg.whatsapp.net, gosuslugi.ru, gstatic.com, mtalk.google.com
• Проверяется доступность по ICMP + TCP:443 — классический метод тестирования блокировок через ТСПУ
• Собирается внешний IP через микс российских и зарубежных сервисов (помогает поймать тех, кто не заворачивает весь трафик в VPN)
• Флаг host-reachability управляется сервером удалённо — можно включить точечно для конкретного аккаунта
• Весь шпионский трафик замешан с основным в бинарном протоколе (10-байтный заголовок + MessagePack) — отфильтровать без отключения мессенджера невозможно

Официальный ответ MAX:

Всё это нужно для WebRTC-звонков и проверки push-уведомлений. К VPN и персональным данным отношения не имеет.

Вопросы, на которые ответ не закрывает:

1. Зачем для WebRTC-звонков пинговать gosuslugi.ru?
2. Почему ICMP, а не только STUN/TURN как у всех нормальных реализаций WebRTC?
3. Зачем "безобидные" данные передавать в закрытом бинарном протоколе, смешанном с основным трафиком?
4. Зачем модуль управляется удалённо с возможностью включения для отдельных аккаунтов?

Два лагеря, которые уже сформировались в обсуждении:

"Это слежка" — намеренно разработанный модуль мониторинга эффективности блокировок. Официальные пояснения не объясняют ни ICMP, ни gosuslugi, ни бинарный протокол.

"Паранойя без понимания" — WebRTC действительно требует внешний IP, Android VPN API стучит системно, а паттерны видят там, где их нет. Телеграм реверсните — удивитесь не меньше.

Исходное обсуждение с разбором от практиков — в нашем Telegram-канале по ИБ: Codeby (там же ссылка на оригинальное исследование на Хабре).

Ваша позиция?