Пользователь 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:
Вопросы, на которые ответ не закрывает:

1. Зачем для WebRTC-звонков пинговать
   
   Код:

   gosuslugi.ru

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

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

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

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

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

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