Дешифруем трафик _L/2/s/e/r/v/...

[nezabudkin]

Надеюсь, по заголовку темы всем понятно о каком сервере идет речь.

И так начнем...
Немного истории:
Где-то в начале 2008 года все игровые сервера этого проекта были обновлены до 6-х хроник, одновременно с этим было введено нестандартное шифрование на игровых серверах. Алгоритм был не очень сложным, и его довольно быстро ломанули. После чего администрация сервера пошла на отчаянный шаг, и похоже, что купила алгоритм защиты у одного из дружественных ей фришардов. Тому есть несколько свидетельств. Вот эта крипто-защита была действительно маниакальной! Достаточно сказать что длинна ключа была 64КБайт!!! Алгоритм той защиты представлен тут:
http://coderx.ru/showpost.php?p=16313&postcount=233
В середине декабря 2008 на серверах опять вводят новую защиту, обсуждение алгоритма которой я и хочу организовать в этом топике.

Добавлено через 4 минуты
Все начальные выкладки по этой теме выложу чуть позже...

Добавлено через 1 час 48 минут
Что касается трафика S->C, некаких изменений в алгоритме я не нашел, ключ задается и изменяется абсолютно так же, как и раньше.

Про подключение к серверу.
Если пользоваться последними версиями пакетхаков 3.4.1.х, то при входе на гейм сервер, через пару секунд клиент вылетает с критом (внутренней ошибкой). Причем комбинация галочек в настройках пакетхака совершенно не важна. Может у кого-нибудь иначе работает? По этому использую проксификатор и последнюю версию пакетхака. Стоит заметить, что версия 3.2.0 при скрытном способе инжекта подключается без проблем, и некаких ошибок не вылезает!!!

Параметры пакетхака:
Установлена галочка: не дешифровывать трафик
снята галочка: обход смены ксор ключа
т.е. дешифрация отключена полностью!

Так выглядит пакет KeyInit S->C
00 01 02 D8 A3 1E 01 00 00 00 01 00 00 00 - эта часть пакета совершенно стандартная, в ней четко виден начальный ключ, пока не понятно используется ли он вообще, а вот потом в этом пакете следует длинный хвост из 256 байт:
71 10 98 40 F8 26 9F 7E 44 1A C2 33 A2 15 4F D5 0F FB 21 1B B1 76 FE 32 CE BB EC 93 17 F7 96 1C F0 A3 83 04 0B B0 6E E7 AF 48 74 84 80 E6 24 6A 55 DA E8 FD 49 12 B3 13 5E 46 8E 6C 35 03 7C 95 C3 43 70 73 C1 0E 52 4D 72 6B 22 08 F1 C5 89 5B A1 8F 68 9A AC 59 A9 0D FA B8 E1 4E 53 39 5F F9 BA 87 D8 D9 E4 DC C9 28 F3 82 01 4C 99 D7 C4 85 DE CD 8B 6F 27 38 18 0A 91 7D F5 51 4A AB 3C A4 6D 3F 20 4B D2 88 0C DB AA 30 31 F6 60 9E 9C 57 7F F2 E2 8A E5 DF E9 FF 2E 50 23 09 86 25 07 BF 16 A6 BC B6 56 D6 EE 94 69 5C AE EF 11 CB 00 9D 42 EB A5 B5 C6 3A 9B 06 BD FC E3 A8 05 3B 7B 54 B9 65 E0 7A CA 81 34 47 2D 3D C0 D4 63 CC 2F 67 45 75 B4 3E 14 B2 97 C7 1D 90 5A 36 62 5D ED F4 02 2C 58 1E 78 64 2B AD A0 37 8D 92 BE 29 CF 1F 79 41 D3 2A 8C 61 66 EA 19 A7 D1 B7 D0 77 C8 DD
к чему он, пока тоже не выяснено.

Исследуем трафик С->S
Перейдем к примерам пакетов.

Так выглядит пакет sit/stand
3B 3B 3B 3B 3B 3B 3B 3B 3B 3B - в оригинале - 45 00 00 00 00 00 00 00 00 00
Так выглядит пакет sit/stand с нажатым Ctrl:
3B 3B 3B 3B 3B 67 3B 3B 3B 3B - в оригинале - 45 00 00 00 00 01 00 00 00 00
Так выглядит пакет sit/stand с нажатым Shift:
3B 3B 3B 3B 3B 3B 3B 3B 3B 67 - в оригинале - 45 00 00 00 00 00 00 00 00 01

Теперь пакет say2.
Отправляем в общий чат - "1"
6B B7 6B 6B 6B 6B 6B 6B 6B - в оригинале - 38 31 00 00 00 00 00 00 00
Отправляем в общий чат - "11"
6B B7 6B B7 6B 6B 6B 6B 6B 6B 6B - в оригинале 38 31 00 31 00 00 00 00 00 00 00
Отправляем в общий чат - "111"
6B B7 6B B7 6B B7 6B 6B 6B 6B 6B 6B 6B - в оригинале 38 31 00 31 00 31 00 и т.д.

На основании этих данных можно сделать вывод, что:
1. от пакета к пакету ключ не меняется
2. ключ не зависит от длинны пакета
3. на поверхности просматривается алгоритм:
for k:=1 to size-1 do
pck[k]:=pck[k] xor pck[k-1];
который снимает лишний "муар" с кода

Так как от пакета к пакету ключ не меняется, нету смысла выкладывать длинные дампы пакетов.
Складывается впечатление что длинна ключа 1 байт. Возможно, ключ зависит от id-номера пакета.
При релогине, начальный ключ меняется.

Что надо выяснить:
1. Алгоритм формирования начального ключа
2. Алгоритм шифрования

Жду Ваших мыслей!

Добавлено через 3 часа 9 минут
Поправка:
алгоритм
for k:=1 to size-1 do
pck[k]:=pck[k] xor pck[k-1]
помогает дешифровке S->C,
но мешает C->S.

[kostya_onishenko]

Пользуюсь WPF658 от Саурона. Прекрасно перехватывает траф и никаких критов.

[nezabudkin]

kostya_onishenko, тебе удалось дешифровать исходящий трафик?

[kostya_onishenko]

nezabudkin, к сожалению пока нет. Я писал, что ключ от клиента в процессе всей сессии не меняется, я копирую пакет сдачи манора и потом его отправляю несколько раз - таким образом сдаю манор. А вот от серевера к клиенту вообще непонятно что тварится, админы точно непонятно что курили, когда делали шифрацию. А если быть точным, то они шифрацию взяли с меганета, там тоже поменяли защиту и она такаяже.

[nezabudkin]

Значит предыдущая и нынешняя защиты разработаны одним и тем же человеком. А судя по тому что было накручено в предыдущей версии, ломать будем месяцев 5 не меньше.

Добавлено через 5 минут

Сообщение от kostya_onishenko

А вот от серевера к клиенту вообще непонятно что тварится

Алгоритм шифрования такой же, как и в предыдущей версии защиты. А вот алгоритм изменения ключа (счетчики) другой.

[QaK]

отсюда вывод: нужен лог, большой лог, длинный лог одинаковых пакетов, где есть последовательность из 8ми нулевых байт, т.е. 00 00 00 00 00 00 00 00.

[kostya_onishenko]

Сообщение от QaK

отсюда вывод: нужен лог, большой лог, длинный лог одинаковых пакетов, где есть последовательность из 8ми нулевых байт, т.е. 00 00 00 00 00 00 00 00.

скажи какие пакеты выложить, я сделаю

[Aniks]

Можно ещё попробывать тот же пакет выложить типа sit/stand тока с разных сесий, так как как я понял там меняется начальный ключ при рестарте.

[kolosOK]

скачал клиент интерлюдии, буду тоже смотреть. А есть у кого то старый патч на л2серв ?

[nezabudkin]

у меня нету