Вопрос или проблема
Я пытаюсь написать прокси-приложение VNC, которое, среди прочего, записывает RFB трафик, проходящий между VNC сервером и клиентом, в FBS файл. Когда сервер и клиент оба являются UltraVNC версии 1.4.3.6, отправляются четыре сообщения, которые не перечислены в спецификации RFB https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst с идентификаторами 173, 13 и 7.
Трассировка Wireshark, показывающая неизвестный тип серверного сообщения
Первый случай появления сообщения 173
Я ищу информацию о содержании этих сообщений и о том, как их анализировать.
Ответ или решение
Вопрос о неизвестных типах сообщений, отправляемых UltraVNC сервером и клиентом версии 1.4.3.6, поднимает интересную техническую проблему, с которой сталкиваются разработчики, работающие с протоколом RFB (Remote Framebuffer Protocol). RFB — это основа для протоколов, используемых разными VNC-решениями, и он определяет формат данных и команды, передаваемые между VNC клиентом и сервером. Однако, как показывает практика, некоторые реализации, включая UltraVNC, могут иметь собственные расширения и нестандартные команды.
Теория: Протокол RFB и его ограничения
Протокол RFB разрабатывался для обеспечения кросс-платформенного обмена удаленной графической информацией. Спецификация RFB определяет стандартные команды, такие как FramebufferUpdate, SetColorMapEntries, и другие, которые позволяют управлять отображением экрана клиента. Тем не менее, спецификации протокола не всегда покрывают особенности индивидуальных реализаций, таких как UltraVNC или TightVNC, которые могут внедрять дополнительные функции.
Месседжи с ID 173, 13 и 7, не описанные в официальной спецификации, потенциально являются частью таких расширений или оптимизаций UltraVNC. Обычно они не документированы в официальных источниках, поэтому изучение сетевого трафика и логирование сообщений могут дать ключи к их расшифровке.
Пример: Анализ UltraVNC
В UltraVNC могут использоваться собственные расширения для улучшения производительности, безопасности или добавления дополнительных функций. Как правило, такие сообщения передаются в виде бинарных данных и могут содержать как команды, так и данные.
Для исследования подобного трафика может использоваться Wireshark — мощный инструмент для анализа сетевого трафика. Wireshark позволяет исследовать пакеты, анализировать их содержимое и пытаться понять структуру на основании бинарных данных. Примеры Wireshark-пакетов, предоставленных вами, указывают на повторяющиеся структуры и заголовки, которые можно проанализировать для построения гипотез о назначении этих сообщений.
Применение: Интерпретация и использование неизвестных сообщений
1. Анализ данных: С помощью Wireshark можно идентифицировать шаблоны в данных сообщений. Начните с поиска повторяющихся последовательностей байтов, которые могут представлять заголовки или структуру данных. Например, 173 может быть идентификатором заголовка, за которым следует структура данных, описывающая определенную команду или параметр.
2. Инженерия обратного проекта: Используйте моделирование и тестирование с различными версиями UltraVNC, чтобы понять, как система реагирует на изменения в этих сообщениях. Попробуйте создать собственные промежуточные серверы, которые могут перехватывать и повторять сообщения, имитируя ответы, чтобы выяснить поведение клиента и сервера.
3. Связь с сообществом разработчиков: Поиск в форумах и обсуждениях, посвященных UltraVNC и RFB, может дать дополнительную информацию о нестандартных расширениях. Часто разработчики делятся подобными находками, и может быть получена исходная информация о назначении данных сообщений.
4. Обходные решения: Если прямое понимание и использование этих специфичных сообщений невозможно, попробуйте искать обходные решения или эмуляцию нужного функционала через стандартные команды RFB.
Этот комплексный подход позволяет не только исследовать неизвестные сообщения UltraVNC, но и создавать более гибкие и умные VNC-прокси приложения, которые могут эффективно взаимодействовать с разными версиями VNC-серверов и клиентов. Такая гибкость особенно важна в корпоративных и образовательных средах, где разнообразие используемого ПО может быть значительным.
Отметим также, что в случае отправки сообщений неизвестного типа всегда следует учитывать безопасность и надежность, избегать потенциальных рисков неправильной интерпретации данных.