[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
Быть может там есть ключик, но как расшифровать не знаю. Еще надо найти функцию которая собирает токен.