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

[Breadfan]

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

[ScythLab]

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

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

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

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

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

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

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

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

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

Больше всего что пугает, так это то что этой информации нету, есть вопросы на которые нету ответом... тему пуста.

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

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

Видят, но каждый ее решает по своемому, если ты хочешь сделать 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

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

[noklin]

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

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

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