Практический тест MAX Desktop в Windows: Keenetic → OpenConnect → VPS, с фиксацией Procmon, Wireshark и tcpdump
Эксперимент проведён 8 сентября 2026 года. Материал описывает наблюдение за поведением программы и собственной сетевой инфраструктурой. Это не инструкция по обходу ограничений доступа и не попытка доказать заранее выбранный вывод. |
Я решил провести эксперимент и проверить, видит ли мессенджер MAX Desktop под ОС Windows и пытается ли он его увидеть или найти в моей системе целенаправленно.
Самый интересный вопрос о desktop-клиенте MAX для меня был не в том, выходит ли он в интернет. Конечно, выходит — это мессенджер. Вопрос другой: может ли приложение понять, что часть трафика компьютера проходит через VPN, если никакого VPN-клиента в самой Windows вообще нет?
Моя схема следующая : компьютер подключён по интерфейсу LAN Ethernet к Keenetic. На Windows нет никакого VPN-клиента, нет отдельного VPN-адаптера и нет VPN-маршрутов. Разделение трафика выполняет маршрутизатор в режиме Split Routing: основной РФ-трафик идёт напрямую, а другая часть трафика роутером Keenetic отправляется через OpenConnect-туннель на удалённый VPS в Европе. Это типичный Split Routing режим маршрутизации трафика, который реализован не на конечном локальном ПК, а на сетевом шлюзе, в качестве которого выступает Ethernet-роутер.
Такой сценарий интереснее обычного теста с VPN-клиентом в Windows. Если программа MAX просто «шерстит» сетевые адаптеры или читает таблицу маршрутов ОС, она здесь ничего очевидного не увидит. Чтобы определить обходной маршрут, MAX пришлось бы действовать иначе: проверять внешний IP, тестировать доступность сторонних узлов, сравнивать маршруты либо получать соответствующую информацию от сетевого стека другим способом.
Что именно я проверял
Я поставил ряд следующих вопросов, на которые я хочу получить ответ:
Какие процессы запускает MAX Desktop и какие внешние соединения инициируют именно процессы MAX-а?
Какие системные идентификаторы и параметры Windows читает программа MAX на ОС Windows?
Читает ли MAX сетевые настройки Windows — в том числе proxy/PAC и параметры TCP/IP?
Пытается ли MAX самостоятельно определить внешний IP-адрес или обращаться к сторонним ресурсам, чтобы проверить доступность сети?
Проходит ли трафик MAX через VPN-сервер, если VPN настроен на Keenetic, а не в Windows?
Экспериментальный стенд
Windows-ПК (обычный Ethernet)
│
▼
Keenetic — шлюз и Split Routing
├──────────────► прямой выход в Интернет
│
└── OpenConnect-туннель ──► VPS ──► Интернет
На Windows во время эксперимента работали Wireshark, Process Monitor и TCPView. На VPS — tcpdump. Перед установкой я сохранил исходные сетевые параметры Windows, маршруты, список адаптеров, а у MSI — SHA-256 и Authenticode-подпись. Это нужно не столько для статьи, сколько для того, чтобы потом можно было отличить состояние и конфигурацию системы до установки мессенджера MAX от состояния и конфигурации после его установки.
Как фиксировал события
Используемый инструмент | Что фиксировалось | Цель |
Process Monitor | Доступ к файлам и реестру, запуск процессов (Process Create), сетевые подключения (TCP Connect) | Понять, какое действие выполнил именно MAX.exe или MAX-service.exe |
Wireshark | DNS-запросы, TCP/TLS-пакеты, имя сервера в SNI, последовательность сетевого обмена | Увидеть, к каким серверам устанавливаются TLS-соединения |
TCPView | Открытые сетевые соединения, порты и PID процессов | Быстро проверить активные соединения MAX |
tcpdump на VPS | Пакеты на VPN-интерфейсе vpns0 | Проверить, прошёл ли конкретный поток через OpenConnect-туннель |
Первый запуск: два процесса и отдельный локальный сервис
После установки клиент запускает основной MAX.exe и отдельный MAX-service.exe. TCPView сразу показал внешний HTTPS-сеанс основного процесса и локальное взаимодействие с сервисом через loopback. В одном из захватов MAX-service.exe слушал локальный порт 61415, а MAX.exe подключался к нему через ::1.
Важное уточнение: порт 61415 в данном случае используется как локальный RPC-канал между MAX.exe и MAX-service.exe. Соединение происходит только через loopback-интерфейс Windows (127.0.0.1 / ::1), поэтому это не внешний порт, доступный из сети. Наличие параметра --rpc-port 61415 в командной строке MAX-service.exe дополнительно подтверждает, что порт используется для внутреннего взаимодействия компонентов MAX. Конкретное назначение этого RPC-канала в рамках эксперимента я отдельно не исследовал.
TCPView после первого запуска MAX: внешний HTTPS-сеанс MAX.exe и локальная связь с MAX-service.exe.
Procmon подтвердил архитектуру точнее. Основной процесс запускает MAX-service.exe, crashpad_handler.exe и taskkill.exe. В командной строке MAX-service.exe присутствуют --rpc-port 61415, каталог настроек и параметр --device-id. Значение device-id на опубликованном скриншоте я скрыл.
Procmon, событие Process Create: MAX запускает локальный сервис и обработчик сбоев (crash-handler). Значение --device-id скрыто.
Отдельно я проверял гипотезу о скрытом запуске браузера для сетевых проверок. В отфильтрованных событиях запуска процессов (Process Create) Chrome, Edge и Firefox не появились. Это не доказывает, что MAX «никогда» не может использовать браузер, но в проведённых запусках такого поведения не было.
Куда MAX подключается
Wireshark на первом запуске показал TLS Client Hello к инфраструктуре ONEME/MAX. Для соединения с 155.212.204.150 SNI был api2.oneme.ru. Отдельно MAX-service.exe устанавливал соединение TLS к sdk-api-rf.apptracer.ru — это видно непосредственно в Client Hello.
Wireshark: в начале TLS-соединения (Client Hello) видно имя сервера в поле SNI — api2.oneme.ru.
Wireshark: в начале TLS-соединения (Client Hello) видно имя сервера в поле SNI — sdk-api-rf.apptracer.ru.
После авторизации и в последующих запусках появлялись соединения с инфраструктурой MAX/ONEME и сервисами звонков. Здесь особенно полезен Procmon: он показывает, какой именно процесс открыл TCP-соединение (событие TCP Connect). В Wireshark видны сами сетевые пакеты, но на рабочем компьютере без привязки к PID их легко перепутать с трафиком браузера или другой программы.
Procmon, фильтр TCP Connect: исходящие соединения MAX.exe/MAX-service.exe. Локальное имя компьютера скрыто.
MachineGuid: MAX читает стабильный идентификатор установки Windows
Одна из наиболее явных находок — обращения к HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid. И MAX.exe, и MAX-service.exe многократно выполняли RegQueryValue для этого значения.
Procmon: MAX многократно читает MachineGuid. Само значение намеренно скрыто.
MachineGuid — это идентификатор конкретной установки Windows, который хранится в реестре. Это не «досье»: сам по себе MachineGuid не содержит ФИО, IP-адрес, координаты или модель компьютера. Его значение достаточно стабильно, поэтому программы могут использовать его как один из признаков конкретной установки системы — например, для диагностики, лицензирования, защиты от мошенничества (антифрода) или формирования цифрового отпечатка устройства (device fingerprint).
Важно: Procmon показывает, что локальный процесс прочитал MachineGuid. Это НЕ доказывает, что значение MachineGuid было отправлено на сервер. Основной обмен MAX идёт через TLS, то есть в зашифрованном виде, а расшифровку трафика в этом эксперименте я не выполнял. |
Здесь есть ещё один важный момент. MAX использует Crashpad — компонент для сбора информации о сбоях программы. Подобные системы используют постоянные локальные идентификаторы, чтобы различать установки программы и не создавать дубликаты одних и тех же отчётов о сбоях. Поэтому само чтение MachineGuid может иметь вполне обычное диагностическое назначение и само по себе не является доказательством слежения. При этом по данным Procmon нельзя однозначно установить, что именно Crashpad инициировал чтение MachineGuid, для какой конкретно цели оно использовалось и передавалось ли это значение на сервер.
У MAX есть и собственные идентификаторы устройства (device ID)
Помимо системного MachineGuid, программный клиент MAX на ОС Windows читает собственные файлы deviceid. В захвате MAX.exe открывает и читает файл .crash_dumps\deviceid, а MAX-service.exe — отдельный tracer\deviceid. В обоих случаях Procmon фиксирует ReadFile длиной 36 байт. Плюс отдельный --device-id передаётся сервису в командной строке.
Procmon: компоненты MAX/Tracer читают собственные файлы deviceid.
Из этого можно сделать только один вывод: MAX использует несколько разных идентификаторов, связанных с программой или устройством. При этом по имеющимся данным нельзя утверждать, что это один и тот же идентификатор в разных местах или что все эти значения отправляются на сервер.
Имя компьютера: ComputerName и Hostname
MAX-service.exe читает ActiveComputerName и параметры TCP/IP Hostname. Это значит, что клиент получает имя Windows-компьютера. Само значение на скриншотах скрыто — для доказательства достаточно Path, RegQueryValue и SUCCESS.
Procmon: MAX читает ActiveComputerName — системное имя компьютера. Само значение скрыто.
Системные настройки proxy/PAC: сначала выглядит страшно, но важен контекст
В моей Windows оказался сохранён AutoConfigURL — адрес файла автоматической настройки прокси (PAC): http://127.0.0.1:19823/proxy.pac. Ручной прокси при этом был выключен (ProxyEnable = 0), ProxyServer отсутствовал, а в момент проверки ни одна программа не слушала TCP-порт 19823.
Проверка Windows: AutoConfigURL присутствует, ручной прокси выключен, на TCP-порту 19823 нет слушающего процесса.
Procmon показывает, что MAX действительно читает раздел реестра Internet Settings, в том числе параметр AutoConfigURL. То есть доказано, что программа получает системные настройки прокси.
Procmon: MAX читает Internet Settings, включая AutoConfigURL.
Но в этом нет ничего сверхестестенного, так как вполне логично что программный клиент MAX может смотреть параметры интернет подключения, чтобы подключаться к глобальной сети. Обычному настольному приложению, которому нужен интернет, читать системные настройки прокси и PAC в Windows это не криминал. Иначе в корпоративной сети или у пользователя с настроенным системным прокси приложение может просто не подключиться. Поэтому сам по себе этот факт я не считаю доказательством «слежения за VPN». Мы видим чтение сетевой конфигурации, а зачем она используется, можно понять только по дальнейшим действиям программы.
Что ещё читает MAX-service.exe: микрофоны и камера
В финальном Procmon-захвате MAX-service.exe перечисляет MMDevices\Audio\Capture и читает свойства устройств. В логах видны названия аудиоустройств и модель веб-камеры. Для мессенджера с аудио- и видеозвонками это ожидаемое поведение: приложению нужно знать, какие устройства доступны для звонка.
В этом эпизоде тоже нет никакой сенсации. Техническое исследование полезно именно тогда, когда отделяет необычное поведение от того, что нормально для функциональности программы. |
Главный тест: видит ли MAX VPN, которого нет в Windows?
Теперь к исходному вопросу. В моей схеме Windows видит только обычное Ethernet-подключение и Keenetic в качестве шлюза. OpenConnect-туннель создан на самом роутере и до Windows не доходит. Поэтому MAX не может просто найти в системе «VPN-адаптер OpenConnect» — такого адаптера в Windows физически нет.
Сначала я отдельно доказал, что split routing действительно работает и что на VPS именно vpns0 относится к моему роутеру Keenetic. Для этого был сделан контрольный HTTPS-запрос к заранее выбранному внешнему адресу, который правилами маршрутизации Keenetic направлялся через туннель. Конкретное имя контрольного домена на скриншоте скрыто: для проверки маршрута оно не имеет значения.
Windows: контрольный HTTPS-запрос успешно выполнен; имя тестового домена скрыто.
VPS: тот же поток одновременно виден на VPN-интерфейсе vpns0 как входящее соединение (In) от стороны Keenetic — peer 10.10.10.194 — к тому же внешнему IP.
После этого на vpns0 был записан отдельный tcpdump во время запуска/авторизации/бездействия MAX. Параллельно на Windows Procmon фиксировал только MAX.exe и MAX-service.exe. Это позволило сравнить два набора данных: какие внешние TCP Connect соединения осуществил программный мессенджер MAX и какие из этих адресов реально появились на выходе из VPN-туннеля.
Результат: обнаруженные соединения MAX с его API, AppTracer и сервисами звонков на VPN-интерфейсе vpns0 не появились. То есть в этой конфигурации Keenetic отправлял обычные соединения самого MAX напрямую, а не через мой OpenConnect-туннель.
Пытался ли MAX определить VPN другим способом?
Остаётся провести эксперимент с более сложным вариантом моей гипотезы: программа МАХ могла бы не направлять собственные обычные соединения через VPN, а выполнить отдельную проверку. Например, обратиться к сервису определения внешнего IP, проверить доступность сторонних зарубежных серверов или сравнить результаты нескольких соединений.
Я наблюдал за MAX на нескольких этапах: первый запуск без входа в аккаунт, авторизация, перезапуск и период бездействия (idle). За это время я не обнаружил у процессов MAX соединений с типичными сервисами проверки внешнего IP (IP-check), а также самостоятельных обращений к Telegram или WhatsApp. В Procmon среди событий запуска процессов (Process Create) не было запуска браузера самим MAX. На VPN-интерфейсе VPS также не появился отдельный поток, который можно было бы уверенно связать с такой проверкой.
Это отрицательный результат, а не доказательство того, что MAX в принципе не умеет определять VPN при Split Routing. Поведение программы может зависеть от версии клиента, серверной конфигурации, аккаунта и условий запуска. Поэтому корректнее говорить так: «в проведённом эксперименте механизм определения VPN-туннеля при Split Routing через роутер Keenetic не воспроизвёлся». |
Что в итоге доказано, а что — нет
Наблюдение | Статус | Что можно утверждать |
Чтение MachineGuid | Доказано | MAX.exe/MAX-service.exe читают MachineGuid через операцию RegQueryValue в реестре |
Чтение имени ПК / Hostname | Доказано | Клиент читает системное имя компьютера |
Чтение настроек proxy/PAC | Доказано | MAX читает системные настройки Internet Settings, включая адрес PAC-файла AutoConfigURL |
Собственные deviceid | Доказано | Компоненты читают локальные файлы deviceid; сервис запускается с параметром --device-id |
Перечисление аудио- и видеоустройств | Доказано | MAX-service.exe получает свойства устройств записи звука и видео (capture-устройств) |
Передача MachineGuid на сервер | Не доказано | Содержимое TLS-соединений не расшифровывалось |
Определение внешнего IP через VPN | Не обнаружено | В тесте не найдено обращений процессов MAX к типичным сервисам определения внешнего IP |
Проверка Telegram/WhatsApp для определения маршрута | Не обнаружено | В наблюдавшихся запусках таких соединений не было |
Определение Split Routing на Keenetic | Признаков не обнаружено | Соединения MAX не появились на VPN-интерфейсе vpns0; отдельной проверки доступности (reachability) не найдено |
Ограничения эксперимента
Я не перехватывал и не расшифровывал TLS-трафик методом MITM (man-in-the-middle). Поэтому я не видел содержимое HTTPS-запросов MAX и не могу по этому исследованию сказать, какие именно поля передавались внутри них.
Я не выполнял статический или динамический reverse engineering — то есть не разбирал исполняемые файлы MAX и их внутреннюю логику. Исследование основано на том, что было видно со стороны Windows и сети.
Результаты вида «не обнаружено» относятся только к конкретной версии Windows-клиента, аккаунту, дате и серверной конфигурации на момент эксперимента.
Во время части эксперимента я не делал сетевые выводы только по Wireshark: какой именно процесс создавал соединение, дополнительно проверялось в Procmon и TCPView.
VPN находился не в Windows, а на Keenetic. Это принципиальная особенность теста: результат нельзя автоматически переносить на ситуацию, когда VPN-клиент установлен непосредственно на компьютере
Вывод
MAX Desktop действительно считывает некоторые технические параметры и идентификаторы Windows. Он читает MachineGuid, имя компьютера, системные сетевые настройки Internet Settings, собственные device ID и свойства мультимедийных устройств. Все эти действия можно увидеть в Procmon и повторить.
Но главный вопрос статьи дал другой результат: в моей схеме Split Routing через Keenetic → OpenConnect → VPS я не смог выявить и подтвердить, что MAX Desktop определяет наличие VPN-маршрута. Более того, в ходе эксперимента я не обнаружил признаков того, что программа пыталась целенаправленно определить наличие VPN при такой схеме Split Routing. Обычные соединения MAX не проходили через VPN-интерфейс vpns0 на VPS, а отдельной активной проверки внешнего IP или сторонних сервисов, которая могла бы показать наличие обходного маршрута, в наблюдавшихся запусках обнаружено не было.
Для меня это оказался скорее неожиданный итог: заранее ожидаемой сенсации не случилось. Одна строка в Procmon — например, чтение proxy.pac — ещё не означает слежение. И наоборот: наличие TLS не означает, что приложение ничего не собирает. Важно разделять четыре разных факта: программа «прочитала данные локально», «использовала их для своей работы», «отправила их на сервер» и «использовала их для идентификации или контроля». В этом эксперименте доказаны в основном первые два уровня. Чтобы доказать передачу на сервер, нужна расшифровка трафика или наблюдение за внутренней работой клиента специальными инструментами. Для четвёртого уровня нужен отдельный воспроизводимый механизм.
Итоговый ответ на главный вопрос эксперимента: в исследованной конфигурации я не обнаружил признаков того, что MAX Desktop пытался определить наличие VPN или распознал VPN при Split Routing, реализованном на уровне сетевого оборудования, а не на уровне операционной системы Windows.
Проще говоря, цель эксперимента была такой: понять, пытается ли MAX обнаружить наличие VPN при сложной схеме маршрутизации, когда VPN-клиента в Windows нет, а весь Split Routing выполняет роутер Keenetic.
Уважаемый читатель! Поставь, пожалуйста, плюс за труды, буду признателен!
