Сергей Попов
06.03.2026, 15:16
https://forum.antichat.xyz/attachments/4951102/1772795716687.png
Пользователь 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 и персональным данным отношения не имеет.
Вопросы, на которые ответ не закрывает:
Зачем для WebRTC-звонков пинговать
gosuslugi.ru
?
Почему ICMP, а не только STUN/TURN как у всех нормальных реализаций WebRTC?
Зачем "безобидные" данные передавать в закрытом бинарном протоколе, смешанном с основным трафиком?
Зачем модуль управляется удалённо с возможностью включения для отдельных аккаунтов?
Два лагеря, которые уже сформировались в обсуждении:
"Это слежка" — намеренно разработанный модуль мониторинга эффективности блокировок. Официальные пояснения не объясняют ни ICMP, ни gosuslugi, ни бинарный протокол.
"Паранойя без понимания" — WebRTC действительно требует внешний IP, Android VPN API стучит системно, а паттерны видят там, где их нет. Телеграм реверсните — удивитесь не меньше.
Исходное обсуждение с разбором от практиков — в нашем Telegram-канале по ИБ: античат (там же ссылка на оригинальное исследование на Хабре).
Ваша позиция?
Пользователь 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 и персональным данным отношения не имеет.
Вопросы, на которые ответ не закрывает:
Зачем для WebRTC-звонков пинговать
gosuslugi.ru
?
Почему ICMP, а не только STUN/TURN как у всех нормальных реализаций WebRTC?
Зачем "безобидные" данные передавать в закрытом бинарном протоколе, смешанном с основным трафиком?
Зачем модуль управляется удалённо с возможностью включения для отдельных аккаунтов?
Два лагеря, которые уже сформировались в обсуждении:
"Это слежка" — намеренно разработанный модуль мониторинга эффективности блокировок. Официальные пояснения не объясняют ни ICMP, ни gosuslugi, ни бинарный протокол.
"Паранойя без понимания" — WebRTC действительно требует внешний IP, Android VPN API стучит системно, а паттерны видят там, где их нет. Телеграм реверсните — удивитесь не меньше.
Исходное обсуждение с разбором от практиков — в нашем Telegram-канале по ИБ: античат (там же ссылка на оригинальное исследование на Хабре).
Ваша позиция?