Хорошие инструменты для понимания / обратного проектирования сетевого протокола верхнего уровня

Question

Здесь есть интересная проблема. У меня есть ролевая MMOG, запускаемая через клиентское приложение (не браузер), которое отправляет действия моего проигрывателя на сервер, который синхронизирует всех игроков, отправляя пакеты обратно.

Теперь игра использует протокол верхнего уровня по TCP / IP для отправки данных. Однако wireshark не знает, какой протокол используется, и отображает все, кроме заголовка TCP, в виде дампа.

Кроме того, в этом дампе нет строк простого текста. Хотя в игре есть функция чата, отправляемая строка чата нигде не отображается в этом дампе как обычный текст.

Моя задача - немного переработать протокол, чтобы найти некоторые базовые сведения о данных, содержащихся в пакетах.

Кто-нибудь знает, почему строка чата не отображается в виде обычного текста и существует ли вероятность использования стандартного протокола верхнего уровня?

Кроме того, есть ли инструменты, которые могут помочь получить данные из дампа?

Answer 1

Если он зашифрован, у вас есть шанс (на самом деле, у вас есть 100% шанс, что вы правильно его используете): ключ должен находиться где-то на вашем компьютере. Просто откройте ваш любимый отладчик, понаблюдайте, как немного (ошибается, сто байтов или около того, я надеюсь) данных, поступающих из сокета, установите точку наблюдения для этих данных и посмотрите на следы стека вещей, которые получают доступ Это. Если вам действительно повезет, вы можете даже увидеть, как это расшифровывается на месте. Если нет, вы, вероятно, поймете тот факт, что они используют стандартный алгоритм шифрования (с теоретической точки зрения безопасности они были бы дураками), либо взглянув на следы стека (если вам повезет), либо используя один из профилировщиков IV / S-box (избегайте академических, большинство из них не работают без особых проблем). Многие алгоритмы шифрования используют блоки «стандартных данных». которые могут быть обнаружены (это IV / S-блоки), это то, что вы ищете в отсутствие другой информации. Что бы вы ни нашли, поищите в Google и попробуйте переопределить их библиотеку шифрования, чтобы сбросить данные, которые зашифрованы / расшифрованы. Из этих дампов должно быть относительно легко увидеть, что происходит.

Работа с зашифрованным сеансом может быть очень увлекательной, но требует навыков работы с отладчиком и большого чтения. Это может быть неприятно, но вы не пожалеете, если потратите время на то, чтобы узнать, как это сделать:)

Answer 2

Лучшее предположение: шифрование или сжатие.

Даже telnet поддерживает сжатие по проводам, хотя весь протокол полностью текстовый (ну, почти).

Вы можете попробовать запустить поток данных с помощью некоторых распространенных утилит сжатия, но я сомневаюсь, что это принесет вам большую пользу, поскольку, по всей вероятности, они не передают заголовки сжатия, просто применяются некоторые предварительно определенные значения.

Если это фактическое шифрование, то вы в значительной степени облажаны (без особых, гораздо больших усилий, которые я даже не собираюсь начинать изучать).

Answer 3

Скорее всего, он сжат или зашифрован.

Если он зашифрован, у вас не будет шансов.

Если он сжат, вам нужно каким-то образом выяснить, какие части данных сжимаются, где начинаются сжатые части и каков алгоритм сжатия. Если вам повезет, будут стандартные заголовки, которые вы можете идентифицировать, хотя они, вероятно, будут удалены, чтобы сэкономить место.

Ничего из этого не просто. Обратное проектирование сложно. Нет никаких стандартных инструментов, которые могли бы вам помочь, вам просто нужно исследовать и пробовать что-то, пока не разберетесь. Мой совет - спросить у разработчиков спецификации протокола и посмотреть, готовы ли они помочь поддержать то, что вы пытаетесь сделать.