Pull to refresh

Разбор протокола World Of Tanks

Reading time 8 min
Views 115K
Часть первая: инструментарий мелкосерийного изобретения велосипедов

Почему и зачем: длинная и необязательная преамбула

Хорошо, что опыта игрового модостроительства у меня было немного — так, пару кастомных прицелов для Deer Hunter 2005 и «нелицензионный» недоклиент VATSIM/FSD с сопутствущим «взломом» протокола последнего. Ещё лучше, что ни разу не приходилось с головой погружаться в сколь-нибудь трудоёмкую и длительную отладку и дизассемблирование. То есть, с IDA и OllyDBG я поверхностно знаком, но не как с ежедневными рабочими инструментами.

В WOT играю с начала 2011 года. Не запоем, а, скорее, набегами — по 5-6 боёв вечером. Было время 2 года назад, наш клан состоял в Красном Альянсе, ходил на глобалку по ночам, выполнял какие-то тактические задачи на европейском ТВД, устраивал тренировки и спарринги, вовсю бурлили внутриигровые политические страсти, отпочковывались учебные кланы. Сейчас всего этого уже нет, и наш золотой ёжик превратился в табличку над «Домом Ветеранов».

Впадать в ересь сравнения танков с другими MMO не буду, так как хорошо знаком только с танками. Тем более не знаком ни с одним другим проектом, использующим BigWorld, поэтому искренне верю WarGaming'у на слово, что существуют и (не)тривиально (не)преодолеваются различные техномагические ограничения движка — на размер карты, на максимальную скорость юнита, на численность команд и прочее. Оставаясь в рамках внутренней критики, я также понимаю, что, с точки зрения целевой аудитории танков вообще, и их активного игрового коммьюнити в частности, каждое нововведение из очередного патча, безусловно, гораздо более востребовано и обосновано, сколь бы малым оно ни было. И что оптимизировать Motion Blur на несколько процентов это, безусловно, важнее, чем отменить принципиальную неизменяемость привязки действий на кнопки мыши для тех, кто привык на них ставить движение вперёд-назад (DOOM-стайл, да).

Итак, я уверен, что в обозримом будущем никаких планов по введению полноценного режима спектатора в WOT нет и не будет. Под полноценным режимом спектатора я понимаю множественные подключения игроков в сеанс боя изначально как невзаимодействующих на игру «привидений»-наблюдателей, а не на технике. Это тот самый режим, из-за отсутствия которого комментаторы на чемпионатах WOT вынуждены заходить в бой 15-м танком, убиваемым своими на базе. Это тот самый режим, из-за которого появились моды «командирского zoom» и «кинематографической камеры» — по сути, просто костыли. А нужен такой режим затем, чтобы командир роты занимался командованием, а не скакал впереди на лихом танке по-чапаевски, чтобы он видел ситуацию на карте в целом непрерывно, а не отвлекался на неё в пылу нападения из засады. В идеале, командиру даже не нужны красоты трёхмерного мира — достаточно одной большой карты на весь монитор с игровой ситуацией в реальном времени — HP, повреждениями модулей, членов экипажа, направлениями стволов и прицелов союзной техники, засвеченных в каждый момент вражеских юнитов и прочей вспомогательной информации.

WOT предоставляет широкие возможности модостроительства, но такая идея выходит за рамки классического «заменить пару swf-файлов на свои». Потребуется перехват и разбор самого игрового протокола для того, чтобы иметь возможность передать на командирский планшет своё видение игровой ситуации.

Обход шифрования 0x0A-й дорогой

Первые робкие попытки пролезть в протокол танков я предпринял ещё в 2011 году. Начинать это, как и везде в подобных задачах, стоит с хорошего сниффера (кстати, в случае с VATSIM/FSD на этом можно и остановиться — внезапно оказалось, что протокол там текстовый), и я, вооружившись Microsoft Network Monitor'ом, ринулся в бой. За отчётные 3 года в схеме входа ничего кардинально не поменялось, кроме количества игровых кластеров. Сервис авторизации у каждого кластера живёт на одном IP, к нему уходит один пакет с логином-паролем, и от него приходит один пакет — как минимум, с идентификатором конкретного игрового сервера из этого же кластера, на который клиенту надо переключиться, и с чьим IP происходит весь дальнейший обмен. Выглядит это всё приблизительно так

image

Помеченные октеты, судя по тому, что изменяются они мало и более-менее предсказуемо — заголовок пакета. После них идёт равномерный битовый шум, то есть там уже включается шифрование. Тут можно было вспомнить, что записи боёв в WOT шифруются BlowFish'ем, и что ключ шифрования не изменялся с того момента, как стал известен широкой публике, и покопаться глубже — но смысла в этом особого не вижу. Для задуманного гораздо важнее то, что ходит между клиентом и сервером в процессе игры, чем то, как он авторизуется при входе.

Итак, если трафик проходит потоковое шифрование, логично предположить, что где-то в глубинах программы есть функция наподобие SendToServer(), в которой есть вызов вроде EncryptBuffer() и в которой, в конечном счёте, выполнение доходит до конкретного sendto(). Наша задача, для начала — найти, где это происходит. Загружаем танки в OllyDbg и перед нажатием на кнопку «Войти» ставим логирующий брейкпоинт на sendto().

image

Через несколько десятков срабатываний, уже в ангаре, вызовы sendto() становятся более монотонными, в том плане, что адрес буфера для отправки данных не меняется:

77062E14  Call to WS2_32.sendto from WorldOfTanks.00BA5B97
            000004D8  Arg1 = 4D8
            04436A75  Arg2 = 4436A75
            00000010  Arg3 = 10
            00000000  Arg4 = 0
            0018E2DC  Arg5 = 18E2DC
            00000010  Arg6 = 10

Чтобы узнать, где шифруется этот буфер, я сначала пошёл по неправильному пути — начал изучать графы вызовов в IDA и отслеживать вручную возвраты из функций. Где-то на 15-й такой функции мне это надоело, я полностью заблудился в коде и поставил брейк на запись по адресу буфера.

image

Брейк сработал внутри вот такой чудесной функции по адресу 0x00BAF76F, чудесность которой состоит в том, что в неё передаются 3 параметра — два адреса буфера и ещё один — их одинаковая длина. Тот самый EncryptBuffer(ptr_src,ptr_dest,len), который нам нужен. Что там лежит в незашифрованном виде, мы пока смотреть не будем, об этом позже.

image

Это что касается отправки данных. Как быть с приёмом? Немного сложнее, но, в целом, так же, поэтому не буду утомлять вас большими и страшными скриншотами отладчика. Схема такая — ставим брейк на recvfrom(), смотрим адрес буфера, куда складывается принятый зашифрованный пакет. Ставим брейкпоинт на чтение с адреса буфера и тут нам в очередной раз повезло — брейк срабатывает на вызове функции по адресу 0x00BAFB79, которая занимается расшифровкой блоков по 8 байт и находится, в свою очередь, в теле функции по адресу 0x00BAFB30. А уже эта функция почти такая же чудесная, как и та, что мы нашли выше: она принимает 4 параметра — два адреса буфера, их длину и какой-то флаг.

image

Назовём её DecryptBuffer(ptr_src,ptr_dest,len,flag). Адреса буферов, как видно, совпадают. Что полностью логично, так как при потоковом шифровании стоит ожидать одинаковой длины блоков исходного и шифротекста.

Осталась одна тонкость. Если функцию EncryptBuffer() достаточно перехватывать непосредственно перед её вызовом (т.е. ставим INT3-брейкпоинт вместо CALL) вытаскивая память по адресу ptr_src длиной len, то в момент вызова DecryptBuffer() оба указателя покажут на один и тот же блок, который ещё пока зашифрован. Поэтому перехватывать эту функцию надо перед самым возвратом, который у неё происходит командой RETN 10 по адресу 0x00BAFBA8. В этот момент на стэке лежат те же параметры, за исключением того, что ptr_src равен нулю (это нововведение версии 0.8.11, в предыдущей указатели как-то оставались равны) и адрес возврата. И ptr_dest, конечно, показывает на расшифрованный буфер. Теперь, когда мы знаем, где в клиенте WOT сообщения ещё не зашифрованы и где уже расшифрованы, нужно их оттуда автоматически вытаскивать для дальнейшего анализа.

Что же там внутри?

Здесь матёрые гуру реверс-инжиниринга, в духе «There's an emacs command to do that» подумают: «ага, ну теперь можно написать на питоне\эзотерическом языке вот такой скрипт\плагин для ольки\иды, который будет делать с этими данными всё что хочешь и даже за пивом сбегает». Но мы пойдём другим путём. Я хочу сразу ориентироваться на то, что ещё до того, как дело дойдёт до разработки командирского планшета, то есть даже для самого полноценного разбора протокола WOT мне понадобятся помощники и тестировщики, далёкие от мира программирования. Им нужен будет простой инструмент с понятным интерфейсом, выдающий легко читаемые данные.

Так что предвидя скептические ухмылки, я засел за Lazarus и набросал в нём специализированный win32-отладчик, основной функцией которого является поставить два INT3-брекпоинта в нужных местах и по их срабатыванию вытаскивать данные по адресу и длине буфера, лежащим на стеке по известным смещениям. Ещё он умеет вести txt.gz лог с hexdump'ами пакетов и записывать все прошедшие пакеты так, что их потом можно заново «проиграть» через парсер. Вот что получилось. Так WOT клиент только начинает входить в ангар.

image

А вот так он себя ведёт уже находясь в ангаре.

image

Какие выводы можно сделать, даже не смотря на пояснения к пакетам, которые я поленился убрать для этих скриншотов? Сразу несколько.

Во-первых, видно, что все пакеты начинаются либо с 0x48, либо с 0x58, либо с 0x78; какой-нибудь закономерности на этот счёт я ещё не уловил, кроме того, что пакеты с уже известной функцией свой значащий байт не меняют.

Во-вторых, почти в каждом пакете есть один или несколько счётчиков сообщений; например, в keep-alive и ответах на них этим занимается третий и четвёртый байт в заголовке, кроме того сам пакет содержит ещё счётчик сообщений общий (включая keep-alive) и какой-то специфический (считающий пакеты без учёта количества keep-alive); всё это имеет отношение к контролю доставки пакетов, который пришлось прикрутить к UDP, вероятно, для оценки потерь и пересылки BLOBов (об этом позже).

Размеры всех пакетов выравнены по границам 8 байт, что ненавязчиво указывает нам на размер блока всё того же BlowFish; пока я до этого догадался, прошло немало времени в попытках обьяснить странную «контрольную сумму» в конце, да ещё и переменной длины. В конце концов, получив в этом паддинге вместо простого мусора слово «Flags» я, наконец, прозрел.

Ну и в лучших хакерских традициях, в конце каждого пакета находится сигнатура мёртвой говядины; кто бы мог подумать где мы её найдём :)

После получения Session ID от сервера приезжает пакет, содержащий номер игрока в неожиданно текстовом формате (792067). А вот пакет, который начинается на 0x78 0x00 на первом скриншоте — особо интересен. Сочетание сигнатуры 0x80 0x20 вкупе с тем, что перед каждым строковым литералом в нём стоит 0x55 и байт длины строки, а после каждого 0x71 находится возрастающий номер, должно насторожить опытных питонщиков — это же, чёрт побери, Python Pickle со своим запихиванием всего подряд в мемо! Вот он такой:

Pickle
Dct[15]:(xmpp_host = wot-ru.loc
captchaKey = 6Lc8GcASAAAAAKffZdxeZZvOvmSTNXbZvsy6CgBR
voipDomain = www.wotp.vivox.com
file_server = Dct[6]:(clan_emblems_small = Dct[1]:(url_template = http://ce.worldoftanks.ru/dcont/clans/emblems/%d/emblem_32x32.png)
clan_emblems_big = Dct[1]:(url_template = http://ce.worldoftanks.ru/dcont/clans/emblems/%d/emblem_64x64.png)
rare_achievements_images_big = Dct[1]:(url_template = http://ce.worldoftanks.ru/dcont/achievements/medals/180x180/%d.png)
clan_emblems = Dct[1]:(url_template = http://ce.worldoftanks.ru/dcont/clans/emblems/%d/emblem_64x64_tank.png)
rare_achievements_images = Dct[1]:(url_template = http://ce.worldoftanks.ru/dcont/achievements/medals/67x71/%d.png)
rare_achievements_texts = Dct[1]:(url_template = http://ce.worldoftanks.ru/dcont/achievements/medals/medals_%s.xml))
newbieBattlesCount = 100
roaming = Lst[4]:(1,1,Lst[3]:(Lst[4]:(1,1,499999999,RU),Lst[4]:(2,500000000,999999999,EU),Lst[4]:(3,1000000000,1499999999,NA)),Lst[0]:())
xmpp_enabled = True
jdCutouts = 0
xmpp_port = 5222
isTutorialEnabled = True
wallet = Lst[2]:(True,True)
xmpp_connections = Lst[1]:(Lst[2]:(xmppcs.worldoftanks.net,5222))
xmpp_resource = wot
regional_settings = Dct[2]:(starting_day_of_a_new_week = 0
starting_time_of_a_new_day = 0)
reCaptchaParser = )



В следующей части, если она заинтересует уважаемых обитателей Хабра, я расскажу о том, как в протоколе WOT передаются файлы, размеры которых намного больше реалистичного размера UDP пакета и MTU. И о том, что эти файлы оказывается сжатыми zlib'ом а внутри у них всё тот же Python Pickle с разными неожиданными вещами.

Спасибо за внимание!

UPD. Свежие новости! По агентурным данным из самого сердца КВГ, мой лёгкий намёк на потенциал коммерческого использования командирского планшета поднял «небольшой бугурт» (дословно), в результате чего кровавые модераторы в полнейшей панике наконец заметили и слили в мусорник тему проекта на официальном форуме танков, а мне было доверительным шёпотом посоветовано замылить данные своего аккаунта на скриншотах.

Я, имярек, находясь в здравом уме и трезвой памяти, торжественно клянусь, что разработка эта имеет исключительно академический характер, клянусь никогда в жизни не покупать компанию WarGaming.net за несметные миллиарды, вырученные от продажи ещё даже не существующей разработки либо иным способом покушаться на финансовое благополучие любимой фирмы! Аминь.

UPD2.
«Видеопрезентация» из ныне убиенной темы на форуме танков
Tags:
Hubs:
+161
Comments 90
Comments Comments 90

Articles