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

[Андрей Жерносек]

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

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

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

[ScythLab]

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

[Андрей Жерносек]

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

Извиняюсь 127 байт :D
Так вот, в этом то и вся проблема, "127 байт(с размером в 2 байта)" это ответ на "ProtocolVersion - 265 байта" то-есть если поставить нули, или что-то другое подходящее по размеру, возвращает блок с размером в 127 байт
Вот изображение из первого сообщения
http://coderx.ru/attachment.php?attachmentid=2933&d=1424651432

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

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

http://www.la2kings.ru/la2bot/packets.html#ProtocolVersion
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

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

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

[Андрей Жерносек]

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

http://coderx.ru/attachment.php?attachmentid=2934&stc=1&d=1424685677

Залогинился на сервер 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]

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

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

[Андрей Жерносек]

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

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

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

[ScythLab]

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

[Андрей Жерносек]

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

Ух ты! а можно на функцию посмотреть? Желательно C# ;)
И где может храниться этот ключ, он передается в авторизации, или храниться в чем-то?

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

[ScythLab]

Ух ты! а можно на функцию посмотреть? Желательно C# ;)
И где может храниться этот ключ, он передается в авторизации, или храниться в чем-то?

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

[Андрей Жерносек]

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

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

[Breadfan]

Немного настойчивости, и мог бы сам найти ветку http://coderx.ru/forumdisplay.php?f=19 с необходимой тебе информацией.

[ScythLab]

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

PS. не исключено что нормальные программеры, специализирующиеся на исследованиях, могут сделать обход любого лейма (да и любой защиты) за считанные часы, только вот навряд ли они тебе расскажут как это сделать, потому что и знания/опыт нужен, и скорей всего они за счет этих "уникальных" знаний живут.

Добавлено через 12 минут
И ещё вопрос, то-есть ключ который приходит от сервера, как я понял назначается Админом, а что если создать Dll, внедрить её в процесс Линяги, и через свою Dll вытянуть или перехватить данные? :)
на сколько я знаю, для лейма статическая часть ключа хранится в файле Lineage2us.ini, но не факт. От сервера приходит динамическая часть (в криптоанализе т.н. "соль").
И расшифровка трафика это только 1 из частей, например в линяге есть т.н. DummyPacket (0x8D), защиты любят в этом пакете отправлять свои служебные данные, эти данные формируются особым образом, и сервер проверяет их корректность, в итоге дополнительно к защите нужно разбираться что же отправляется в этом пакете :)

[Андрей Жерносек]

Немного настойчивости, и мог бы сам найти ветку http://coderx.ru/forumdisplay.php?f=19 с необходимой тебе информацией.
Больше всего что пугает, так это то что этой информации нету, есть вопросы на которые нету ответом... тему пуста. :cray:

Добавлено через 33 минуты
Видят, но каждый ее решает по своемому, если ты хочешь сделать OOG бота, то тебе необходимо разобраться с защитой, написать свой алгоритм, эмулирующий защиту, и все будет хорошо. Косяк этого метода, что такой обход нужно писать под каждый сервер, и если на сервере что-то изменилось, то вновь лопатить клиент и вносить изменения в обход. Ну и плюс не забываем, что уровень знаний для этого нужно очень и очень приличный.
Можно пойти путем создания IG бота, здесь дело обстоит чуть проще, потому что ты можешь работать уже с расшифрованными данными, получается несколько проще и универсальней, хотя свои заморочки тоже имеются.
Можно вообще начать с простеньких кликеров, имхо это самые простые разновидности ботов, но у них и наименьший функционал.
Например, мой бот изначально был OOG, мне тогда повезло и я наткнулся на достаточно крупный сервер без защиты, потом спустя некоторое время на этом сервере поставили защиту, и я понял, что поддерживать универсальный OOG не смогу, поэтому перевел его в IG режим, поддерживать такого бота гораздо легче, определенные знания тоже должны быть, но все же их нужно меньше, чем для OOG.

PS. не исключено что нормальные программеры, специализирующиеся на исследованиях, могут сделать обход любого лейма (да и любой защиты) за считанные часы, только вот навряд ли они тебе расскажут как это сделать, потому что и знания/опыт нужен, и скорей всего они за счет этих "уникальных" знаний живут.

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

на сколько я знаю, для лейма статическая часть ключа хранится в файле Lineage2us.ini, но не факт. От сервера приходит динамическая часть (в криптоанализе т.н. "соль").
И расшифровка трафика это только 1 из частей, например в линяге есть т.н. DummyPacket (0x8D), защиты любят в этом пакете отправлять свои служебные данные, эти данные формируются особым образом, и сервер проверяет их корректность, в итоге дополнительно к защите нужно разбираться что же отправляется в этом пакете :)

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

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

[Андрей Жерносек]

Тема ещё актуальна Up!

[noklin]

Тоже пишу бота тока на java. Тоже дошел до GS и ломаю голову с lameGuard. Решил поделиться мыслями:
Это первый пакет который отправляет клиент на GS (epilogue) скорее всего это наш пакет ProtocolVersion.
Дальше пошла моя аналитика. Не факт, что написанное ниже, правда=)

00000000 0B 01 0E 98 00 00 00 CB 5E D5 C9 27 C2 B2 C3 7B
00000010 BB 9C FD 9D 58 B5 5C 08 22 E2 3A C9 0E DE 2E F2
00000020 FC 4D B0 DB 44 52 61 53 78 C3 08 E5 06 16 9B 5A
00000030 02 3B 05 BF 73 93 9B 7A 67 52 F6 AE 0A AC BE 17
00000040 C4 EE E4 E3 E9 6D 1B 81 8D 3C FC 32 39 A1 E2 C3
00000050 A8 FB DA BB 30 FC A5 70 58 2D 4E 52 C0 DF 66 7D
00000060 68 DE 64 43 4E 07 6C EE 95 A9 B9 C7 F2 B0 27 78
00000070 F7 4E 7C FB AD 3E 60 0C A2 29 83 2E AE D5 CB 76
00000080 74 B6 DC A5 F2 D6 85 2F 77 1D 0B AA AE A7 03 12
00000090 45 CA B7 0C B0 68 46 E8 0F 6D 40 B1 C4 86 09 BA
000000A0 43 2E 9B FB A4 5E 4D A6 FE 4A BC 54 3D 52 31 4B
000000B0 5B 87 0D 55 AA 7C 8E 3B 09 E6 36 BC 1F 7B CE 3D
000000C0 3B DB A3 9B 5E 27 EC 80 70 62 A6 25 38 B1 23 AC
000000D0 51 A0 8C 32 0F 67 D9 98 85 6E 41 DC CD 5C 17 2A
000000E0 8D 97 2B 78 73 82 BC 7B 69 38 BD 8E 55 57 62 38
000000F0 49 AF A0 DA AF 0C A8 34 FE 1C 02 48 0C C6 45 20
00000100 37 52 1D 1D BE 89 54 D1 CB 78 DF

с 00 по 01 - размер пакета
02 – тип пакета (0E) на епилоге он вреди такой
С 03 по 06 – версия протокола (в данном случае это 152)
С 07 по 106 – блок 256 байт с данными (шифруется только он). В этой каше где то зарыты:
1 – токен(4 байта)
2 – идентификатор железа (16 байт)
3 – логин (4 – 14 байт + байт 0x00) нольбайт служит для сообщения что байты логина закончились
4 – флаг (2 байта)
5 – версия (2 байта)
6 – патч (1 байт)
7 – счетчик (1 байт)
8 – болок из 16 байт который нужен для вычисления смещения(смещения надо знать чтобы проверить чек сумму)
9 – var38 (4 байта)
с 107 по 10A – чек(не шифруется)
Чек нужен для поверхностной проверки правильности пакета. Эти 4 байта получаются после анализа зашифрованных 256-ти байт блока данных. Блок с данными(256 байт) буду называть data[], а последние 4 байта то есть чек буду называть check[].

Первая проверка (checkData):
1. - check[0] должен быть равен ксору всех байт в data и байтом равным -1 (0xFF)
2. - check[1]^data[0] (^ это XOR) это у нас патч lameGuard. Во всех пакетах check[1]^data[0] равны одному и тому же а данном случае CB^CB = 0.
3. – получаем версию:
3.1 берем наш check инвертируем первые и вторые 2 байта переводя в int результаты ксорим
int z = (check[1] & 255) << 8 | (check[0] & 255);
int version = (check[3] & 255) << 8 | (check[2] & 255);
version ^= z;

Потом идет проверка версии и патча(то с чем идет сравнение забито в конфиге сервера)

Вторая проверка (checkClient):
1. Расшифровка блока данных получаем decData[] (расшифрованные 256 байт блока данных)
2. decData[255] должен быть равен ксору всех байт кроме decData[255] в decData и байтом равным -1 (0xFF)

Если все проверки пройдены начинается считывание полезных данных из decData.

Каждый новый первый пакет от клиента выглядит не так как из прошлого соединения это объясняется рандомным заполнением блока данных:

public static int writeB(byte[] raw, int offset, byte[] data, int size) {
for(int i = 0; i < size; ++i) {
raw[offset] = (byte)(data[i] ^ raw[0]);
raw[offset + 1] = (byte)(2 + rand.nextInt(2));
offset += raw[offset + 1] & 255;
}

return offset;
}
С чnением проблем нет так как есть offset:

public static int readB(byte[] raw, int offset, byte[] data, int size) {
for(int i = 0; i < size; ++i) {
data[i] = (byte)(raw[offset] ^ raw[0]);
offset += raw[offset + 1] & 255;
}

return offset;
}
То почему нельзя воспозоваться предыдущим первым пакетом из прошлого соединения
Скорее всего связанно с проверкой токена.

Итоги: Что писать и куда известно. Все уперается в нахождение lamekey где-то в в папке system =).Копать надо L2.bin, GameGuard.des. Не дает покоя Lineage2us.ini
Быть может там есть ключик, но как расшифровать не знаю. Еще надо найти функцию которая собирает токен.

[i_am_kisly]

Автор, Я думаю осилишь перевод с плюсов на шарп.
ProtocolVersion (http://coderx.ru/attachment.php?attachmentid=2943&stc=1&d=1429216091)

Парни, Как сеть организовывали? У меня прост какой-то многопоточный ахтунг получается.

[noklin]

Парни, Как сеть организовывали? У меня прост какой-то многопоточный ахтунг получается.

Есть поток который в цыкле читает из сокета пакеты и кидает их на склад. Другой поток их обрабатывает. Как то так. От ГС так и не дождался ответа:(