Шифрация пакетов фростом

[Yukio]

Копаюсь с пакетами ГС руоффа. Все бы хорошо, да вот фрост, походу, шифрует пакеты.
Что имеем?
- Первый пакет от сервера приходит нешифрованным. Это информация со списком персонажей на аккаунте (0x09);
- Второй пакет, обычно, также приходит нешифрованным (это может быть 0x0d, не суть важно);
- Третий пакет приходит в зашифрованном виде

Прим.: все пакеты приводятся уже расшифрованными по дефолтному xor-алгоритму L2.
Пример первого нешифрованного пакета (длина 349 + 2):

9 1 0 0 0 7 0 0 0 0 44 0 65 0 66 0 74 0 0 0 fd 94 0 0 64 0 65 0 66 0 74 0 31 0 39 0 38 0 0 0 df ae 25 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 19 0 0 0 d 0 0 0 fe 1a ff ff ec 25 1 0 a0 f3 ff ff 6 f0 16 48 50 68 7d 40 9e 5e 29 cb 10 7 7c 40 36 b1 0 0 3b a8 e 0 0 0 0 0 ea ec 57 9 9 12 db 3f 15 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2c 0 0 0 d1 2d 0 0 0 0 0 0 0 0 0 0 4d 4 0 0 50 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 3 0 0 0 1 0 0 0 6 f0 16 48 50 68 7d 40 9e 5e 29 cb 10 7 7c 40 0 0 0 0 1d 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 e0 22 2 0

Тут все нормально, 0x09 - список персонажей на аккаунте.

Дальше, к примеру, жмем кнопку "Создать" (создать персонажа). Получаем пакет (длина 885 + 2):

d b 0 0 0 0 0 0 0 0 0 0 0 63 0 0 0 58 0 0 0 1 0 0 0 63 0 0 0 37 0 0 0 1 0 0 0 63 0 0 0 52 0 0 0 1 0 0 0 63 0 0 0 27 0 0 0 1 0 0 0 63 0 0 0 27 0 0 0 1 0 0 0 63 0 0 0 26 0 0 0 1 0 0 0 0 0 0 0 a 0 0 0 63 0 0 0 26 0 0 0 1 0 0 0 63 0 0 0 1b 0 0 0 1 0 0 0 63 0 0 0 29 0 0 0 1 0 0 0 63 0 0 0 4f 0 0 0 1 0 0 0 63 0 0 0 4e 0 0 0 1 0 0 0 63 0 0 0 4e 0 0 0 1 0 0 0 1 0 0 0 12 0 0 0 63 0 0 0 52 0 0 0 1 0 0 0 63 0 0 0 3d 0 0 0 1 0 0 0 63 0 0 0 52 0 0 0 1 0 0 0 63 0 0 0 29 0 0 0 1 0 0 0 63 0 0 0 26 0 0 0 1 0 0 0 63 0 0 0 25 0 0 0 1 0 0 0 1 0 0 0 19 0 0 0 63 0 0 0 24 0 0 0 1 0 0 0 63 0 0 0 20 0 0 0 1 0 0 0 63 0 0 0 26 0 0 0 1 0 0 0 63 0 0 0 4a 0 0 0 1 0 0 0 63 0 0 0 54 0 0 0 1 0 0 0 63 0 0 0 4d 0 0 0 1 0 0 0 2 0 0 0 1f 0 0 0 63 0 0 0 5c 0 0 0 1 0 0 0 63 0 0 0 38 0 0 0 1 0 0 0 63 0 0 0 4d 0 0 0 1 0 0 0 63 0 0 0 2a 0 0 0 1 0 0 0 63 0 0 0 27 0 0 0 1 0 0 0 63 0 0 0 23 0 0 0 1 0 0 0 2 0 0 0 26 0 0 0 63 0 0 0 27 0 0 0 1 0 0 0 63 0 0 0 1e 0 0 0 1 0 0 0 63 0 0 0 25 0 0 0 1 0 0 0 63 0 0 0 55 0 0 0 1 0 0 0 63 0 0 0 4d 0 0 0 1 0 0 0 63 0 0 0 49 0 0 0 1 0 0 0 3 0 0 0 2c 0 0 0 63 0 0 0 58 0 0 0 1 0 0 0 63 0 0 0 32 0 0 0 1 0 0 0 63 0 0 0 57 0 0 0 1 0 0 0 63 0 0 0 25 0 0 0 1 0 0 0 63 0 0 0 26 0 0 0 1 0 0 0 63 0 0 0 29 0 0 0 1 0 0 0 3 0 0 0 31 0 0 0 63 0 0 0 28 0 0 0 1 0 0 0 63 0 0 0 17 0 0 0 1 0 0 0 63 0 0 0 2b 0 0 0 1 0 0 0 65 8b 1a ce 12 8b 1a ce 4f 10 e8 3d a6 10 e8 3d ba 68 ba df c 68 ba df f0 34 1 54 35 34 1 54 40 81 a1 86 a2 81 a1 86 c5 c4 b3 58 4c c4 b3 58 b1 ff 47 f7 4e ff 47 f7 40 a 2c b6 a5 a 2c b6 25 bf 4d 70 e1 bf 4d 70 b6 1 e5 ec 9 1 e5 ec e9 15 d2 e2 2 15 d2 e2 ea b9 83 7e 27 b9 83 7e d7 d1 e8 27 1f d1 e8 27 e3 c3 95 3b 45 c3 95 3b e1 5a 4c 68 7b 5a 4c 68 a1 69 b0 f8 42 69 b0 f8 35 d5 8e ea b0 d5 8e ea 7a 74 c3 a 84 74 c3 a cb 80 dc 29 16 80 dc 29 25 de fb ec c8 de fb ec 92 e 50 1 74 e 50 1 8a 39 5f 51 54 39 5f 51 d3 b4 50 d6 33 b4 50 d6 a4 a4 c6 4a d a4 c6 4a 7e 59 e9 2f 9a 59 e9 2f 29 94 9d ba d0 94 9d ba af b 31 c 37 b 31 c bc 25 b7 f9 77 25 b7 f9 d8 b0 a2 58 29 b0 a2 58 a8 b6 a6 2e 3f b6 a6 2e c3 bc 25 81 4a bc 25 81 55 9e b5 d2 9a 9e b5 d2 48 e8 3a 5c 8f e8 3a 5c fe 6 ed b7 17 6 ed b7 19 3e e3 3a

Тут тоже нормально - 0x0d, NewCharacterSuccessPacket.

Теперь нажимаем кнопку "Назад". Должен (!) прийти пакет 0x09 (т.е. пакет, абсолютно идентичный первому пакету от ГС). Но вот, каким приходит третий пакет:

25 3b 5 41 55 f5 e6 41 55 f2 aa d3 be 3c 52 d3 af 3c db 51 46 0 7e 51 df 94 15 d5 9b f4 a8 d5 cc f4 bb b d0 c4 27 b 37 6a 4d b 5b cf 9f b 5b cf 3b 5b 90 53 98 5b 91 53 bc ed bd 5f 16 ed a9 5f f2 58 35 92 e4 a7 27 ad ba d 91 95 a5 f2 37 96 a7 43 74 97 ad 4b ba a1 bf 9e 4c 63 11 15 6a d5 b b3 37 bf a6 b3 c 17 2e de 5c 2 d1 d7 bf fc cc 63 27 c3 ad 5c 32 c3 d7 f9 aa 3c 6f f9 ab 3c 75 18 67 a9 d6 18 67 a9 5c ee 7c 6e fc ee 7c 6e da c 64 74 1c c 64 74 cb 36 6f 62 3b 36 6f 62 46 5f 75 80 aa 5f 75 80 8e cc cf 6e 6d cc cf 6e 3f 36 55 e9 8a 36 79 e9 49 83 b8 37 f0 83 69 1a 10 e5 c3 99 bf e5 8e 9d 85 e 91 fd 36 e c1 f9 8e a2 c9 5d 36 a2 c9 5d 58 34 f1 3 c6 34 f1 3 d3 b0 93 7c 5f b0 93 7c 22 b9 46 19 e6 b9 46 19 84 30 41 7 76 30 41 7 8e b6 82 45 71 b6 82 45 7b 57 f5 7 a5 57 f4 7 94 8b e8 56 36 8b ea 56 1e db 6f e3 b7 93 39 7b 60 c7 8a 71 95 4c 4 28 e5 3a 2e 3f 6b 7a 33 3f e1 8d 7b b9 4e 8d 7a b9 4c 4 5f c0 9b 4 5f c0 15 4c 99 2d f8 4c 99 2d 8a 4b 95 b2 6c 4b 95 b2 b9 61 1a 50 2b 61 1a 50 8b 79 5c 51 74 79 5c b1 52 4e 2b

Более того, реальная физическая длина пакета, которая вычисляется исходя из знаний структуры TCP-пакетов и сдвигов = 349 (как и в первом пакете). А вот длина пакета, которую передает сервер равна 52910 (0xce 0xae). Т.е. получается, что шифруется и длина пакета? о_О Еще один пакет 0x09 придет уже с другой информацией (т.е. каждый раз приходит что-то новое).
Ну и, соответственно, данные совершенно не те, что должны быть. Если смотреть на шифрованное значение длины пакета, то навязывается мысль, что это может быть RSA. Но т.к. каждый раз данные пакета разные, то, либо открытый RSA-ключ должен передаваться каждый раз (что навряд ли, т.к. физическая длина пакета не меняется), либо это вовсе не RSA.
Если это другой xor, то в любом случае, либо ключ каждый раз должен передаваться новый (опять же, не может быть из-за физической длины пакета), либо есть другой алгоритм изменения этого ключа?

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

[ANZO]

Советую почитать по фросту тут http://exelab.ru/f/index.php?action=...c=17771&page=0

Дешифровывать траффик у Вас врядли нормально и практически применимо получится, а вот работать с ним на ring-0 и цеплять методы "frostRecv" , "frostSendto" и т.п. и получать траффик чистым вполне ворзможно думаю.

[Yukio]

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

[ALF.]

оО тоже интересно...
Пойду ка распакую GameShield посмотрю что в нем

[ANZO]

Сообщение от [Santyaga]

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

Именно так.

[ALF.]

Кому надо держите распакованный GameShield

l2-wt.ru/gameShieldDll_dumped.7z

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

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

Именно так.

в ring0 можно будет хукать функции клиента типа UNetHandler::Recv и оттуда получать уже расшифрованный трафик? или надо будет frostrecv?

[Hint]

Зачем обсуждать это на форумах? Кто умеет обходить, пусть обходит. Зачем пилить сук? Чтобы потешить самолюбие и немного поднять репутацию? Глупо.

[hex1r0]

offtop:

Свернуть ↑

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

Зачем обсуждать это на форумах? Кто умеет обходить, пусть обходит. Зачем пилить сук? Чтобы потешить самолюбие и немного поднять репутацию? Глупо.

сразу видно, кто уже обошел

Свернуть ↑Развернуть ↓

[Hint]

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

offtop:

Свернуть ↑


сразу видно, кто уже обошел

Свернуть ↑Развернуть ↓

offtop:

Свернуть ↑ В первые же дни... да я и не скрываю (имя проекта в подписи).

Свернуть ↑Развернуть ↓

[ANZO]

Вы учтите что и фрост работает и на r0\r3 и так же палит все что происходит на нулях, так что просто слайсингом тут не обойдешься. Без приличного опыта в этом деле туда вообще лучше не лезть.
ЗЫ: Илья зайди в асю плз, пару вопросов есть