ProtocolVersion - массив-константа

Андрей Жерносек · 23.02.2015, 04:33

Здравствуйте Ув. Форумчане!
в общем пишу бота на C#, тут дошел до соединения с GM (Гейм сервером)
И тут такая проблема, в общем сервер Интерлюди, когда соединяюсь, отправляю пакет, ProtocolVersion, длина тип верные, а вот что дальше, остальные байты откуда их брать?
Если со снифнуть, и после первой отправки этого массива который был взят из WPE PRO, отправляет в ответ непонятные байты... с размером в 127 байтов(С размером).
А после первого раза, совсем другие байты, более похожи на те которые мне надо, и размер пакета 1037 Байт...

Вопрос откуда брать этот массив с байтами? подскажите пожалуйста а то уже

Делаю по принципу
http://www.la2kings.ru/la2bot/packet...rotocolVersion
Но там с GM сервером, как-то иначе...

ScythLab · 23.02.2015, 10:41

Многа нипонятных букавак.
Что значит "длина и тип верные"? Какие остальные байты? Что за размер 137 байт или 1037? нужно бы определиться.
Стандартная длина пакета ProtocolVersion - 265 байта (c:id, d:версия протокола, блок данных 256 байт, d:некая контрольная сумма).
Как правило этот пакет сильно не меняется, но, например, lameguard подменят блок данных (256 байт) на свой, причем не помню можно ли его соснифать или он каждый раз разный. Видел защиту в которой после блока данных шел еще небольшой массив на 16-32 байт.
Так что тут 2 варианта: 1) все-таки разобраться что конкретно отсылается, и попробовать соснифать пакет, и тупо отправлять полученные данные (но вариант крайне сомнительный), 2) разбирать алгоритм формирования данных.
И еще не забывай, что многие защиты шифруют GS-трафик.

Андрей Жерносек · 23.02.2015, 12:17

Цитата:

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

Многа нипонятных букавак.
Что значит "длина и тип верные"? Какие остальные байты? Что за размер 137 байт или 1037? нужно бы определиться.
Стандартная длина пакета ProtocolVersion - 265 байта (c:id, d:версия протокола, блок данных 256 байт, d:некая контрольная сумма).
Как правило этот пакет сильно не меняется, но, например, lameguard подменят блок данных (256 байт) на свой, причем не помню можно ли его соснифать или он каждый раз разный. Видел защиту в которой после блока данных шел еще небольшой массив на 16-32 байт.
Так что тут 2 варианта: 1) все-таки разобраться что конкретно отсылается, и попробовать соснифать пакет, и тупо отправлять полученные данные (но вариант крайне сомнительный), 2) разбирать алгоритм формирования данных.
И еще не забывай, что многие защиты шифруют GS-трафик.

Извиняюсь 127 байт

Так вот, в этом то и вся проблема, "127 байт(с размером в 2 байта)" это ответ на "ProtocolVersion - 265 байта" то-есть если поставить нули, или что-то другое подходящее по размеру, возвращает блок с размером в 127 байт
Вот изображение из первого сообщения

Но, массив-константа просто взят из клиента, и он разный,в первое использование, оно возвращает массив, в 1035 байт(без 2-х байтов размера) И как я понимаю это пакет "FirstKey", а после повторной отправки ProtocolVersion с теми-же байтами который был отправлен первый пакет, получаю ответ в 125 байт(без размера в 2 байта) который показан в скрине...

В этом вся и проблема как сгенерировать правильный массив-константа?

http://www.la2kings.ru/la2bot/packet...rotocolVersion

Код HTML:

ProtocolVersion

Формат:
07 01           // Длина
00              // Тип
XX XX XX XX     // ProtocolVersion
[далее идет массив-константа, который хз от чего зависит, у меня он такой:]
09 07 54 56 03 09 0B 01 07 02 54 54 56 07 00 02
55 56 00 51 00 53 57 04 07 55 08 54 01 07 01 53
00 56 55 56 01 06 05 04 51 03 08 51 08 51 56 04
54 06 55 08 02 09 51 56 01 53 06 55 04 53 00 56
56 53 01 09 02 09 01 51 54 51 09 55 56 09 03 04
07 05 55 04 06 55 04 06 09 04 51 01 08 08 06 05
52 06 04 01 07 54 03 06 52 55 06 55 55 51 01 02
04 54 03 55 54 01 57 51 55 05 52 05 54 07 51 51
55 07 02 53 53 00 52 05 52 07 01 54 00 03 05 05
08 06 05 05 06 03 00 0D 08 01 07 09 03 51 03 07
53 09 51 06 07 54 0A 50 56 02 52 04 05 55 51 02
53 00 08 54 04 52 56 06 02 09 00 08 03 53 56 01
05 00 55 06 08 56 04 0D 06 07 52 06 07 04 0A 06
01 04 54 04 00 05 02 04 54 00 09 52 53 05 04 01
04 05 05 01 52 51 52 0D 06 51 08 09 54 53 00 0D
01 02 03 54 53 01 05 03 08 56 54 07 02 54 0B 06

Откуда у него эти данные, из сниффера, или из его там генерации...

И можно чутка поподробнее, про контрольную сумму, куда ещё дописывать нужно, с какова байта?)

Андрей Жерносек · 23.02.2015, 14:02

Вот перехватил пакеты, на старте подключения гейм сервера

Залогинился на сервер 2 раза, с одного и того же аккаунта (Зашел к выбору персов и вышел)

Из 2-х пакетов ProtocolVersion выявил одинаковые байты

И вот что я узнал
23 192.168.100.2:3356 190.115.22.69:7777 267 Send
0000 0B 01 00 EA 02 00 00 03 7B 6C C3 A9 3A EE 88 FE
0010 8A 6F D3 FB F0 2F 13 12 A2 55 23 10 BC 11 00 8C
0020 26 3E D0 47 E8 7B 8C 04 0D BF 15 E6 8F FF FC FA
0030 85 35 31 B3 16 C0 50 90 B3 BD EA 34 3F 3F 5A A1
0040 79 15 FF 3A 84 9E 9E 2C 93 EF 5E 67 B5 7F 9B 51
0050 70 1B 56 84 3C 23 00 43 C4 70 93 6B EB 0A 30 7D
0060 42 BA 6B C5 D9 0D E0 E9 F3 91 54 CA 94 E5 E1 B8
0070 97 48 70 14 DF 7E 15 2C 7A B1 32 E2 EC 86 08 51
0080 4F E9 60 7B EC 04 73 F7 63 3A CB 93 44 7A 47 54
0090 30 19 80 6D DB CE B0 49 DC 8F BD 07 AA 6D BA 39
00A0 8A B5 C3 7F 19 16 28 0D C0 C9 CE 8A CA 4D D9 86
00B0 FB 68 9C 02 80 2A D8 C6 6B 3A 7B C5 8D 30 92 8B
00C0 4C 7D 2E C6 28 D2 01 EA 20 0A FA 6C E2 60 47 22
00D0 D1 B4 E3 89 96 1C C2 99 83 0C 42 06 48 F1 C4 80
00E0 E4 44 DC 8B 00 89 2E 42 39 ED 28 8D BA 29 0C 9B
00F0 16 87 98 FC 47 04 48 43 BC 5D 93 75 A4 3A D6 34
0100 76 0F 69 7A 43 D7 7B 85 03 2C 17

после версии протокола 30 байт до 7B,
после байта 7B, 26 байт до 79,
20 байтов до байта 23,
26 байт, до байта 97
30 байт, до байта 54
1 байт, до байта 19
2 байт, до байта DB

А байты, 85, 2C повторяются в каждом пакете ProtocolVersion, а те меняются но остаються в таком положении...
Скажите что это могут быть за байты, и как они шифруються...

ScythLab · 23.02.2015, 20:14

имхо там стоит защита, в пакете ProtocolVersion блок данных из 256 байт подменяется на свой, в котором содержится некоторая служебная информация (например, Hwid компа и прочие полезные мелочи).
Ответ у тебя вообще странный, на сколько помню на запрос ProtocolVersion сервер должен отправлять ответ InitKey, размер этого пакета в случае неудачи 2 байта, а если все хорошо, то не более 20.
У тебя же какие-то сотни и тысячи байт, к тому же в ответе на 125 байт у тебя там какие-то странные строчки "0,510,77758,6506" и "02:40:43".

Поищи какой-нить сервер без защиты, либо вообще поставь свой, потому что задача и так не самая примитивная, а если ее решать на "проблемном" сервере, то становится невыполнимой.

Андрей Жерносек · 23.02.2015, 21:42

Цитата:

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

имхо там стоит защита, в пакете ProtocolVersion блок данных из 256 байт подменяется на свой, в котором содержится некоторая служебная информация (например, Hwid компа и прочие полезные мелочи).
Ответ у тебя вообще странный, на сколько помню на запрос ProtocolVersion сервер должен отправлять ответ InitKey, размер этого пакета в случае неудачи 2 байта, а если все хорошо, то не более 20.
У тебя же какие-то сотни и тысячи байт, к тому же в ответе на 125 байт у тебя там какие-то странные строчки "0,510,77758,6506" и "02:40:43".

Поищи какой-нить сервер без защиты, либо вообще поставь свой, потому что задача и так не самая примитивная, а если ее решать на "проблемном" сервере, то становится невыполнимой.

На сервере стоит защита Lameguard

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

ScythLab · 23.02.2015, 23:05

Цитата:

Сообщение от Андрей Жерносек

На сервере стоит защита Lameguard

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

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

Андрей Жерносек · 24.02.2015, 01:02

Цитата:

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

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

Ух ты! а можно на функцию посмотреть? Желательно C#

И где может храниться этот ключ, он передается в авторизации, или храниться в чем-то?

Это получается каждый пакет который будет приходить, будет шифроваться, его надо будет расшифровать по VMPC, а потом уже это будет как чистый пакет, который расшифровывать уже XOR-ом...?

ScythLab · 24.02.2015, 14:33

Цитата:

Сообщение от Андрей Жерносек

Ух ты! а можно на функцию посмотреть? Желательно C#

И где может храниться этот ключ, он передается в авторизации, или храниться в чем-то?

Это получается каждый пакет который будет приходить, будет шифроваться, его надо будет расшифровать по VMPC, а потом уже это будет как чистый пакет, который расшифровывать уже XOR-ом...?

Метнуться по быстрому и перевести тебе яву на c#?

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

Андрей Жерносек · 24.02.2015, 15:05

ScythLab, ведь серверов с чистым трафиком все меньше и меньше...
Неужели люди которые занимаются ботоводством, не видят эту проблему? и способы обхода...

Спасибо за информацию, буду копаться в исходниках...
И ещё вопрос, то-есть ключ который приходит от сервера, как я понял назначается Админом, а что если создать Dll, внедрить её в процесс Линяги, и через свою Dll вытянуть или перехватить данные?