Что такое Lineage ( Баги,Читы )

SkyShadow · 22.03.2010, 02:49

Оглавление

I. Введение

II. Login-сервер

III. Game-сервер.

IV. Проблемы и как можно их использовать

V. Баги нового поколения

VI. Пара слов о С4

VII. Послесловие

VIII. Ссылки

IX. Приложения к статье

Статьи

I. Введение.

II. Login-сервер.

Введение.
Начнём с того, что разработчики lineage2 отделили логин сервер от игрового, дабы более менее
разгрузить и без того забитый канал игрового сервера. Кроме того, логин сервер имеет свойство
повисать (причём, это началось с с3 версии lineage и продолжается по сей день) и не пускать
пользователей на сервер. Зато те, кто уже играют, не испытывают совершенно никакого дискомфорта =)
А вследствие отсутсвия всё тех же багоискателей, которые могли бы найти и внятно объяснить девелоперам,
где же всё-таки закрался баг, он остаётся до сих пор непофиксанным. Так вот, не смотря на всю прелесть
идеи с разгрузкой игрового канала, наши отечественные админы упорно лепят логин сервер на одну машину
вместе с игровым.
1. Шифрование пакетов.

Для шифрования пакетов, которыми login-сервер обменивается с клиентом, lineage использует blowfish.
Да, тот самый алгоритм, который был разработан Брюсом Шнейером в 1993 году. Про blowfish важно знать,
что это симметричный блочный шифр. Симметричный - означает, что алгоритм использует 1 секретный
ключ, которым и шифруются/дешифруются данные. А если говорить конкретно о blowfish, то на основе
этого ключа генерируются 18 32-битных подключей и 4 матрицы размером 256 32-битовых слов каждая.
Которыми, в свою очередь, шифруются/дешифруются данные.
Блочный шифр - означает, что blowfish обрабатывает данные блоками (по 8 байт). А ещё это означает,
что если целостность шифротекста была нарушена, то часть мы по-любому сможем восстановить.
Применительно к lineage, нужно сказать, что ключ, на основе которого генерируются подключи,
является константой и чётко прописан в исходниках l2j (вот на чём сыпались 99% исследователей
lineage, которые предполагали, что ключ должен передаваться в одном из пакетов - см. ссылки в
конце). Ещё важно отметить то, что первые 2 байта данных пакета _не_шифруются_.
Чтож, с шифрованием, я думаю, мы разобрались. Идём дальше.

2. Структура пакетов.

Первые два байта пакета (те, которые не шифруются) содержат длину данных пакета (как и в halflife).
Следующий байт несёт в себе информацию о типе пакета. Логин-сервер обрабатывает пакеты:
0x00 - RequestAuthLogin (запрос на авторизацию - содержит логин и пароль)
0x02 - RequestServerLogin (запрос на заход на сервер)
0x05 - RequestServerList (запрос на список серверов)
На остальные он попросту не отвечает, оставляя лишь запись в логах. Клиентом же обрабатываются
пакеты следующих типов:
0x01 - авторизация не прошла
0x03 - вы успешно авторизованы
0x04 - ответ на RequestServerLogin
0x06 - ответ на RequestServerList
А также несколько дополнительные пакетов о бане аккаунта, проверки версии и тд - они представлены ниже.
Следующий байт является дополнительным к вышеописанным запросам. Например, если сервер ответил
нам на запрос авторизации пакетом типа 0x01, то следующий байт будет содержать причину, по
которой авторизация не прошла (для нас важны: 0x03 - неверный логин или пароль, 0x07 - кто-то уже
юзает аккаунт, 0x11 - установлен временный пароль). Но на самом деле этот байт уже не совсем служебный.
Например, в RequestAuthLogin пакетах с этого байта начинается логин.
Далее идёт Н-ное число байт, которые уже не являются управляющими, а несут информацию, определяемую
типом пакета. Ну, например, для "RequestAuthLogin" это поле содержит логин и пароль.
Важное предназначение имеют последние 8 байт пакета. Они содержат чексуму всего того, что идёт до
них, за исключением опять же первых двух байт пакета. Каким же образом вычисляется эта самая чексумма?
Из данных поочерёдно отделяются 32-битные слова. Первое XOR'ится со вторым. Результат этой операции
XOR'ится со следующим словом и так далее. Пример вычисления чексуммы будет продемонстрирован ниже.

3. Конструктор пакетов на Си Чтож, со структурой пакетов мы разобрались, теперь можно реализовать программно всё, что было описанно выше.

III. Game-сервер

1. Процесс авторизации на login-сервере и заход на game-сервер. Авторизация на логин сервере происходит в несколько этапов.

1) логин сервер посылает нам приветствие в виде пакета длиной 11 байт (вообще он содержит информацию о версии).
2) мы отвечаем ему RequestAuthLogin запросом
3) если пароль верный, посылает нам пакет с 32-ух битным номером нашего аккаунта (он всегда постоянный) - будем
звать его SessionKey #1.
4) мы отсылаем RequestServerList, на что сервер нам отвечает списком серверов, содержащим ипы,
порты, число играющих пользователей, максимальное число пользователей.
5) мы отсылаем RequestServerLogin, на что сервер проверяет наш AccessLevel (если он равен -1, значит мы забанены)
и в зависимости от нашего логина, пароля, уровня доступа и сокета, генерирует уникальный
32-битный SessionKey #2, по которому в последствие нас авторизует game-сервер.
Если же игровой сервер в дауне, имитирует это состояние (админы делают это для проведения работ на сервере)
или просто-напросто полон, отказывается нас принять.
6) если всё хорошо, лезем на игровой сервер. Отсылаем ему некий пакет (для каждого С3 сервера он свой,
но константный), на что он отвечает 12-ти байтным пакетом, содержащим первые 4 байта ключа, которые
скрепляем с другими 4-мя байтами (которые постоянны) и получаем 64-ёх битный ключ. В дальнейшем будем
использовать его для расшифровки и зашифровки игровых пакетов. Важно отметить, что с каждым
рас(за)шифрованным пакетом, его длина прибавляется к первой части ключа.
7) отсылаем ему логин и два идентификатора (уже в зашифрованном виде), которые мы получили в сеансе
с login-сервером. В ответ получаем список персонажей.
Вот так, в 7 этапов мы авторизуемся на сервере =) Сложно, зато безопасно.
Возможно, у кого-то из вас возник вопрос: а возможно ли зайти на игровой сервер напрямую? Без участия
логин сервера. Об этом я напишу ниже.

2. Шифрование пакетов

Как я уже писал выше, для шифрования игровых пакетов lineage использует 64-битный ключ. Первые
его 4 байта берутся из самого первого пакета game-сервера, вторые же-константы. Далее берётся N-ный символ
из открытого текста, XOR'ится с N-ным байтом ключа. Параллельно с этим XOR'ится (N-1)-ный символ
из открытого текста по 0xFF. Над результатами обоих вычислений проводится операция "поразрядное И".
И по такому алгоритму шифруется каждый символ начиная с первого. Как видите, как будет зашифрован
каждый последующий символ, зависит от предыдущего. А это значит, что если у нас по тем или иным
причинам повреждена первая часть пакета, либо её попросту нет, расшифровать вторую часть мы не
сможем. Ну это так, к слову. На самом деле это для нас не важно.
Ещё важно отметить то, что первая часть ключа переменна. С каждым новым расшифрованным пакетом,
к первым 4-ём байтам прибавляется длина этих данным. То есть, имея первоначальный ключ (на момент
соединения с логин сервером) и, выдернув пакет в определённый момент из сеанса с game-сервером,
расшифровать его мы не сможем. Для этого нам нужно восстановить все пакеты, которые были до него.
В принципе, количество возможных комбинаций ключа равно ~423 миллиона. С учётом простоты
алгоритма, современные компьютеры смогут произвести где-то 10 000 итераций в секунду (может даже
и больше) и найти ключ максимум за 12 часов. Но для этого нам понадобится знать хотя бы примерно
содержание пакета.
Для чего авторы сделали ключ переменным? Думаю, всем понятно, в целях безопасности. Хотя, речь идёт
о TCP (а не о UDP как в том же самом halflife), в котором кому-то постороннему "вклиниться" в сеанс
крайне затруднительно.

3. Протокол.

4. XID и ObjectID

Каждая вещь (предмет, NPC) в игре имеет свой 16/32-битный идентификатор (профессии - 8-ми битный).
Его смысл в том, что, согласитесь, удобнее передавать по сети 2/4-х байтное число, чем фразу Н-ной длины вроде:
"Crystal Scroll: Enchant Weapon (Grade B)" или ник NPC вроде "Magister MacTePqpJlOMaCTeP". Как вы понимаете, он
служит для идентификации того или иного объекта. Список этих идентификаторов и соответствующих им NPC/предметов
храниться и на сервере и клиенте, и между собой они никак не синхронизируется. То есть, если сменить эту таблицу
на сервере, то нужно патчить и клиент - это одна из причин, почему у каждого сервера свой патч.

Помимо этого идентификатора есть ещё 32-ух битный Object ID. После захода в игровой мир, сервер присваивает
каждому из предметов, которые есть у перса, свой уникальный OID. Причём OID каждого последующего предмета есть
OID текущего -1. То есть OID генерируется отнюдь не рандомно, а по порядку. После присвоения, OID
резервируется, так чтобы никто больше не умудрился получить аналогичный. Эта информация, кстати, не
подтверждена исходниками, то есть является моим собственным умозаключением. Если же это не так, то по
прошествию полного круга (от 0xFFFFFFFF до 0x00000000) может получится так, что уже занятый OID будет присвоен
новой шмотке, что приведят к неизвестным последствиям (возможности клонирования или простому падению сервера).
Но проблема в том, что диапазон OID довольно таки велик

А если быть более точным, нужно присвоить OID
~4.3 млрду вещей, чтобы пройти полный круг, что даже на сервере с мега-онлайном займёт Н-ное число дней
(а может и недель). Ещё раз повторюсь, это всего-лишь предположение. Но дело в том, что я, например, не
видил ниодного la2 сервера (даже офф) с аптаймом более недели. Может проблема как раз в этом?
А в целом, OID нужен для борьбы с клонированием. А точнее с выявлением оного.
Что касается NPC, OID у них выдаётся по такому же закону, но при появлении NPC в мире. С OID персонажей то же самое.

5. Примеры пакетов.

a) покупка предметов
b) приватные сообщения
c) пример пакета в котором сервер передаёт нам список всех предметов, которые есть на чаре. Причём, именно этот пакет закрепляет за каждым Item ID уникальный Object ID.

d) говорим с NPC на примере разучивания скиллов Для начала, нам нужно выделить NPC и завести с ним диалог:

IV. Проблемы и как можно их использовать

SkyShadow · 22.03.2010, 02:51

Всё предельно просто.
Кстати говоря, наряду с многочисленными способами заточки, существовала такая теория, что вероятность точки
просчитывается на клиенте и как бы мы говорим серверу, сломался предмет или нет. И будто бы простым artmoney
можно 100% точить. Это не правда, вы только что в этом убедились.
Действительно, на пакетном уровне точка выглядить предельно просто. Как можно обмануть эту систему?
Я могу предложить вам вот такие варианты:
1. активировать одну и ту же заточку несколько раз
2. послать RequestEnchantItem-пакет несколько раз
3. drop'нуть заточку после активации (позволит точить одной заточкой сколько угодно), либо позволит делать ложную (fake)
Заточку.
4. дропнуть шмотку сразу же после RequestEnchantItem-пакета. Если успеете, шмотка может не сломаться. Но заточется ли?
Все эти способы я опробовал на antaras.ru, к сожалению на нём они не сработали, но, уверяю, один из них 100%
работает на некоторых крупнейших Российских серверах. По просьбе того человека, кто мне с этим помогал, я не могу
назвать эти серверы и описать способ подробнее.

Помимо выше-описанных способов точки, есть ещё метод fake-заточки. Он как раз основан на том, что после активации
заточки, мы куда-нибудь её прячем. Сервер просчитывает заточился предмет или нет и выводит результат, который из-за
спрятанной заточки не вводится в силу. То есть предмет и не ломается и не точится, но мы видим результат.
На основе этого метода, народ пытался искать какие-то закономерности в точке и просчитывать её вероятность.
Что касается закономерностей, как это не удивительно, они их находили. Но наличие закономерности ставит под
вопрос само существование рандома в точке. По крайней мере степень его "рандомности".
Вот наработки взятые с форума cheaters.net.ua, а точнее из поста F4llen'a (прямую ссылку ищите в конце):
+1 100%
+2 100%
+3 100%
+4 -+-+-+ (+-+-+-) или же (----++++----+++)
+5 ++---++-++----+++---
+6 +++++----+--++--
+7 +++++++++------
+8 +++-+-+++----+++
+9 ++-++--++---++--
+10 ++--+--++--+
"+" означает успешную заточку, "-" соответственно кристаллы.
Исходя из этой "таблицы" он выдвинул теорию, что на каждом этапе заточки есть свой "тип рандомайзера":
а) много плюсов подряд в начале +++++--+----+
б) 2 плюса и минусы ++--++-----++-++---
в) плюс-минус +-+-+-+ 4 ложные заточки должны дать ответ.
Соответственно, определив какой вы имеете тип на данном этапе, можно было предсказывать успех/неудачу точки.
С одной стороны, мне кажется бредом разделение рандомайза на типы, с другой же я знаю людей, которые смогли заточить
таким способом аж до +15-ти.
Давайте попробуем с точки зрения тер/вера рассмотреть эту статистику:
Заточка Всего/Успех Вер. успеха
+4 15/7 0.466
+5 20/9 0.45
+6 16/8 0.50
+7 15/9 0.60
+8 16/10 0.625
+9 16/8 0.50
+10 12/6 0.50
Получившиеся данные верны ровно на столько, на сколько верна таблица F4llen'а. Посчитав среднее значение вероятностей
успешной заточки, получим число 0.52, что означает, что успешная и ложная заточка в целом равновероятны. Для каждого
же конкретного этапа заточки, можно сказать то же самое и сейчас объясню почему.
Напишем маленькую программу, которая будет генерировать равновероятно цифру 1 или 0. Делать она это будет 240 раз,
для каждых 60-ти чисел (можно считать их этапами заточки) будет счетать вероятность выпадения единицы (в дальнейшем
"успех") и в итоге счетать общую вероятность успеха для всех 240 чисел (за вероятность успеха принимаем процентное
соотношение единиц и нулей к 240):

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main () {
int O = 0, I = 0, Ot = 0, It = 0, total = 241, r = 0;
srand(time(0));
for(int i = 0;i < total;i++) {
r = rand()%2;
printf("%i ",r);
if(r) I++; else O++;
if(!(i%60)) {
printf("\n%i/%i\nВероятность успеха: %.2f\n",I,O,I/0.60);
Ot+=O; It+=I;
I = 0; O = 0;
}

}
printf("Вероятность успеха в целом: %.2f\n",It/2.40);
return 0;
}

Вот, что программа вывела на экран:
-----------------------
0 1 1 0 1 1 0 1 1 0 0 0 0 0 0 1 0 1 0 1 1 0 0 1 1 1 0 1 1 1 0 0 0 1 0 0 0 1 0 1
1 0 0 0 0 0 0 1 1 1 1 1 0 1 1 0 1 0 0 1
29/31
Вероятность успеха: 48.33
0 0 0 1 1 0 0 0 0 1 0 1 1 1 0 0 0 1 1 0 1 0 1 0 1 0 0 1 1 1 1 0 1 1 0 1 0 0 0 1
0 1 0 0 1 1 0 1 1 0 1 0 1 1 0 1 1 1 1 1
32/28
Вероятность успеха: 53.33
1 0 1 1 0 1 0 1 1 1 0 1 1 1 0 1 1 0 0 1 1 0 1 1 1 1 0 1 1 1 0 0 0 1 0 0 1 1 0 0
0 1 0 1 1 0 0 1 0 1 0 0 1 0 0 0 0 1 0 0
31/29
Вероятность успеха: 51.67
1 0 0 1 1 1 1 0 0 0 0 0 0 0 1 1 0 0 1 1 1 0 1 0 0 1 0 0 0 1 0 0 0 1 0 1 0 1 1 0
1 0 1 0 0 0 1 0 1 1 0 0 1 0 0 1 0 1 1 1
27/33
Вероятность успеха: 45.00
Вероятность успеха в целом: 50.00
-----------------------
Как видите, тут прослеживаются те "типы рандома" о которых писал f4llen при том, что выпадение 0 и 1 равновероятно и
никакой закономерности тут нет. Плюс ко всему при промежуточных измерениях вероятностей (для каждых 60-ти чисел),
вероятность успеха несколько отклонялась от 50%, но общая всё равно была максимально близка к действительной
вероятности выпадения 0 или 1.
Таким образом, статистика f4llen'а ни что иное, как попытка систематизировать обычный рандом.
Ну и последний камень в сторону тех, кто считает, что на вероятность заточки влияет даже погода за окном:
В L2j нет своего генератора случайных чисел, в нём такой же библиотечный рандомайзер, что был использован выше. С той
лишь разницей, что на вероятность заточки влияет одно единственное число, которое выставляется администрацией.
Будте уверены, в lineage2 off то же самое.

В итоге, хочу сказать, что не стоит пытаться обмануть rand(), скорее он обманет вас =) Стоит искать баги в самом
процессе точки, но опять же, как было продемонстрировано выше, это слишком простой процесс, чтобы быть бажным.

А вообще, "случайностей не бывает, а бывают только неизвестные нам закономерности" (c) Кто-то.

12. Геодата (хождение сквозь стены).
Сегодня постучался человек в асю и начал спорить, что l2j ничем не отличается от оффа. В связи с этим я решил
добавить в статью пару слов про геодату в l2j и off.
Процесс передвижения по миру в la2 реализован довольно интересно. Оказывается, за тем, куда идти следит и сервер и
клиент параллельно. Точнее, вы кликаете в ту точку, куда хотите попасть, клиент в соответствии с имеющейся у него
геодатой смотрит можно ли туда пройти, если да, то посылает запрос на сервер. Тот уже в соответствии со своей
геодатой разрешает или возвращает вас в исходное положение. Этим как раз и объясняется феномен под названием
"нивидимые стены", который, кстати, присущь нашим фришардным проджектам с кривыми локациями.
В l2j же нет геодаты, она прикручевается к нему дополнительно. Что это значит? А то, что за передвижением чара
следит только клиент по имеющейся у него геодате. Поэтому, воспользовавшись ботом (в котором понятное дело также
нет геодаты), вы можете ходить сквозь стены, потому что ни сервер, ни клиент (в лице бота) просто не знают про них.
Эта проблема кстати не только l2j. На С1ОФФ как правило С3/C4 локации также без геодаты, то есть там точно также
ответственность за передвижение возлагается только на клиента.

Если разбирать передвижение более подробно, то оно реализуется пакетом "0x01 MoveBackwardToLocation". В нём
присутствует два набора координат - где стоим и куда хотим попасть. После этого пакета сервер начинает нас
шаг за шагом двигать в желаемую нами точку. Причём, с каждым шагом он не посылает нам новые координаты! Для
того, чтобы клиенту узнать в какой точке в данный момент он находится, посылается пакет "0x48 ValidatePosition".
То есть, в целом, мы посылаем пакет с координатами куда хотим попасть, а потом просто периодически проверяем,
грубо говоря, на сколько мы продвинулись.
Но это так, для общего развития, так сказать =)

13. Прикол с SocialAction (0x1b)
Что такое SocialAction, думаю, объяснять не надо. Оказалось, что помимо смеха, приветствия, победы и тд, анимация
при LVL UP'е является таким же SocialAction'ом. А, насколько вам известно, запрос на произведение SocialAction
отправляет клиент, то есть мы сами можем в любой момент сделать себе lvlup =) Только анимацию, разумеется.
Вот формат SocialAction-пакета:

1b // Тип пакета (SocialAction)
0f 00 00 00 // номер action'а (0f - lvlup)

14. Баг c Ride (0x6a)
Запрос "Ride" посылает клиент, когда хочет забраться на страйдера или виверена.
Формат:

6a // тип пакета
00 00 00 00 // 0/1 слезть/залезть
00 00 00 00 // номер питомца: 1 - страйдер, 2 вивирен

Когда у вас вызван страйдер и вы посылаете запрос "Ride", на самом деле, страйдер исчезает (то есть выходит из игры
и теряет свой OID - этим как раз объясняется то, что когда вы с него слезаете, он пропадает), а садитесь вы уже не
конкретно на своего страйдера, а на некий эталон страйдеров

Немного некорректно выразился, ну да ладно.
Оказалось, что на некоторых ла2-серверах отсутствует проверка на то, а вызывали ли вы вообще страйдера, перед тем
как на него сесть. То есть ни с того, ни с сего, послав пакет:
6a 01 00 00 00 01 00 00 00
Вы сядете на страйдера, хоть и не вызывали его. Причём, даже если у вас нет дудки. Таким же образом можно садится и
на виверен.
Этот баг, также как и прикол с SocialAction был найден человеком под ником Maddaemon. Гратз ему.

15. Выкидываем из игры чаров
Этот баг я открыл случайно, изучая всё тех же мутантов. Меня мучал вопрос, почему когда при создании чара указываешь
несуществующую рассу (число больше 4-ёх), всегда создаётся чар с текстурами human'а? Причём, этот human не может учить
скиллы у NPC human'ов, то есть ничего кроме текстур его с людьми не объединяло. Так вот, оказалось, что в виде human'а
таких чаров воспринимает _только_ С1/C3 клиенты. С4 же для таких чаров текстуры просто не находит и вылетает с ошибкой.
То есть, как только в зону видимости la2 C4 клиента попадает такой чар, он падает. Под зоной видимости я подразумеваю
не то, что вы видите на экране, а приблизительно зону видимости команды "/target".
Так, например, поставив такого персонажа рядом с замком на время осады, у нападающих не будет шанса, т.к. ботами
захватывать замок крайне проблематично, а клиентом зайти в игру они просто не смогут.

Я испытал это на трёх крупных отечественных С4 серверах (не l2j), везде работало.
Такими чарами, кстати, можно проверять персонажей на ботов ) Если не упал, значит бот. Но это способ для ГМов-садистов
имхо.

[Ссылки могут видеть только зарегистрированные пользователи. ] - видео запись с одного из Российских С4 серверов. На ней показано, какой эффект оказывают
такие чары на других игроков.

16. Баг с RequestRestartPoint (оживление и побег из тюрьмы)
Этот баг был найден нашим соотечественником из подполья [Ссылки могут видеть только зарегистрированные пользователи. ] под ником sshd.
Когда вы умираете, у вас появляется окно с выбором места, где как бы вас оживить. При обычных условиях там всего одна
кнопка: "return to the nearest village". После нажатия на которую игра посылает пакет:

6d // тип пакета (RequestRestartPoint)
00 00 00 00 // аргумент, который собственно говорит серверу о том, куда нас вернуть

Баг заключается в том, что как раз клиент говорит серверу куда вернуть чара после смерти. То есть, не клиент, а мы.
LA2 С3/C4 серверы поддерживают следующие значения аргумента (места возврата):

0 – return to town (в город)
1 – hide PK (если вы ПК, возвращает в город ПК или в окрестности того города, где вас убили)
2 – to castle (в замок)
3 – to siege HQ (к флагу во время осады)
4 – fixed, festival (во время фестиваля тьмы оживляет вас на месте).

Таким образом, послав вместе "00 00 00 00", "04 00 00 00" наш чар оживится на том месте, где собственно был убит.
В связи с этим багом, у меня возникла мысль о том, как можно вызволить из тюрьмы персонажа.
Для этого чар, находящийся в тюрьме, должен быть в клане. Этот клан записывается на осаду и ставит флаг, при этом
чара, который в тюрьме надо каким-нибудь образом убить. На antaras.ru, к примеру, это не сложно, там вокруг тюрьмы
аггры, бьющие через стену. Далее вы просто посылаете "RequestRestartPoint" пакет с аргументом "03 00 00 00" и чар
появляется (должен появится

) живой у флага.

17. Раздеть чужого персонажа не зная ни логина, ни пароля - разве это реально?
Да, к сожалению это реально. Я решил убрать этот параграф из статьи, так как это очень серьёзная брешь в lineage2,
которая наделает ещё не мало шуму. Не хочу, чтобы это было на моей совести

Скажу лишь, что существует возможность входить под рандомными персонажами (то есть сами мы конкретного персонажа
выбрать не можем, это делает сервер). Пока что это было опробовано только на известном сервере [Ссылки могут видеть только зарегистрированные пользователи. ],
но я уверен, что это работает и на других.
Так что не удивляйтесь, если вашего чара с паролем аля "6IlZk9qR[!]" вдруг разденут.

18. Итог
Чтож, я описал достаточное кол-во багов. К сожалению, к моменту публикации статьи большинство из них стали уже не
так актуальны. То, что актульно сейчас или находится в данный момент в разработке, возможно будет выложено позднее
на форуме la2brute.5bb.ru.

V. Баги нового поколения
[вырезано]
Могу лишь сказать, что их будет использовать мой новый ингейм бот LA2Monster.

VI. Пара слов о C4
Вообще С4 всё ещё никак не может устаканиться. Точнее пошло некое разветвление в реализации авторизации.
L2J C4 серверы стали применять для шифрования авторизационного пакета RSA (впрочем как и ОФФ от NCSoft).
Причём, пара private/public-ключей генерируется для каждого соединения. Клиенту в первом пакете сервер
передаёт 1024-битный публичный ключ, которым клиент _поверх_ blowfish шифрует пакет с логином/паролем.
Этот способ гарантирует то, что никто извне не сможет получить клиентский логин и пароль. Хотя, если
вспомнить взлом Rc5-64, то раскрытие 128-байтного ключа не кажется таким уж заоблочным.
Хочется отметить, что генерация key-pair в RSA достаточно трудоёмкое занятие. У меня на генерацию пары ключей
с помощью библиотек openssl уходило ~1.5-2 секунды, что для сервера с онлайном, скажем, в 1000 человек -
непозволительная роскошь. Хотя опять же, login-сервер по задумкам NCSoft должен быть на другой машине нежели
game-сервер, но, как я уже писал выше, это не всегда выполняется у нас в России.
Что же касается С1ОФФ переделанных в С4, RSA в них не используется. Хотя изменена работа с внутренними
идентификаторами, которые используются для авторизации на game-сервере. При этом и для l2j и для с1офф-с4
используется один и тот же С4 клиент.

VII. Послесловие.
Конечно, по этой статье нельзя создать RFC по lineage, ибо, естественно, некоторые моменты
я пропускал, так как они были не важны или я до конца не понимал их сам. Так или иначе, я считаю, что
дал вам уйму пищи для размышлений.
Если вы с чем-то не согласны или знаете (думаете, что знаете

) чего я не знаю, пишите на d4rk@securitylab.ru,
либо в ЛС на [Ссылки могут видеть только зарегистрированные пользователи. ] на ник "nop".
Буду рад пообщаться.

VIII. Ссылки.

[Ссылки могут видеть только зарегистрированные пользователи. ]
index.php%3Fshowtopic%3D5041+blowfish+lineage2&hl= ru&gl=ru&ct=clnk&cd=1 -
сохранённая в кэшэ гугла bbs'ка, на которой обсуждалось клиент-серверное взаимодействие lineage.
Судя по постам, народ упорно не хочет смотреть исходники l2j и пытается методом тыка найти способ
авторизоваться на сервере.
[Ссылки могут видеть только зарегистрированные пользователи. ] - То же самое
[Ссылки могут видеть только зарегистрированные пользователи. ] - то же самое, только наши Русские. В отличие от
америкосов, далеко продвинулись.
[Ссылки могут видеть только зарегистрированные пользователи. ] -
статья F4llen'а про fake-энчант и про типы рандома (она упоминалась в этой статье в параграфе про заточки).
[Ссылки могут видеть только зарегистрированные пользователи. ] - отличный раздел про blowfish.
[Ссылки могут видеть только зарегистрированные пользователи. ] - интересная статья про расчёт числа Пи исходя из теории вероятности. Так, для расширения
кругозора.
[Ссылки могут видеть только зарегистрированные пользователи. ] - моя предыдущая статья подобной тематики. Она
более простая за счёт интуитивно-понятного протокола HalfLife, рекомендую новичкам начать с неё.
[Ссылки могут видеть только зарегистрированные пользователи. ] - коммерческий проект.
[Ссылки могут видеть только зарегистрированные пользователи. ] - видео запись - приложение к параграфу 13 (Выкидываем из игры чаров)
[Ссылки могут видеть только зарегистрированные пользователи. ] - показано, как с помощью LA2Fun учить скиллы любого уровня на проджектах
и смешивать проффессии на l2j.
[Ссылки могут видеть только зарегистрированные пользователи. ] - показано, как создавать мутантов (на примере бессмертных) на проджектах
с помощью LA2Fun.

IX. Приложения к статье.
Приложение к статье находится по адресу: m00.blackhat.ru/la2shit.rar
Содержимое:
game-serv-encryption.txt - исходник на асме шифрования пакетов game-сервером (выкладывал sauron на allcheats.ru).
grabber.c - старый пример скачивания ников с сайта на примере [Ссылки могут видеть только зарегистрированные пользователи. ]. Кстати, на antaras.ru уже давно
ввели cookie, так что этот пример уже на нём не работает. Этот код упоминался в разделе про перебор паролей.
ID.rar - список предметов и соответствующих им ID
la2brute_1.1.OLD.rar - старая тестовая версия la2brute. Была написана в феврале-марте этого года. Виснет, падает, так
что считайте это PoC'ом =)
la2reklamer.rar - программа для массовой рассылки сообщений. Сама скачивает ники игроков, которые онлайн и в течение
минуты каждому из них персонально пишет приватное сообщение.
raid.jpg - пример того, как можно использовать бессмертных мутантов =) автор Hint
screenshot1.jpg - скрин генератора auth-пакетов
screenshot2.jpg - скрин совместной работы моего патча для sniffit и переборщика паролей к ла2 серверам.
shot1.JPG, shot2.JPG, shot3.JPG - скрины мутантов, созданных с помощью la2fun
sniff.exe - эх от сердца отрываю.. сниффер, который перехватывать и расшифровывает входящий/исходящий la2-траффик.
Причём и login-сервера и game-сервера. Настроен на мой сетевой интерфейс, так что для использования вам придётся
покопаться в бинарном коде =)
mass.nuke.avi - запись того, как из-за моего чара с сервера падают сотни человек.
la2-example.c - пример конструирования RequestAuthLogin-пакета
Sniffit.LA2C3.plug.rar - плагин для sniffit, который позволяет перехватывать чужие RequestAuthLogin-пакеты и
вытаскивать из них логин/пароль
l2.crash.ini - Зашифрованный файл с настройками для L2C3 клиента от которого он падает. При удачной эксплуатации
может позволить получить полный доступ к компьютеру, на котором этот l2.ini был использован.
la2fun_1.2.demo.rar - урезанный LA2Fun 1.2. Может создавать мутантов, бессмертных чаров, чаров без головы, учить скиллы любых уровней.
Последние версии LA2Fun и LA2Bute 1.5 (С3/C4) я решил не выкладывать из уважения к тем, кто их покупал за деньги..
Также хотел выложить linux-версию la2brute, но что-то не смог найти :\

**ExxtanzO** · 22.03.2010, 08:42

Ужасный, неоформленый копипаст + боян!
Автору: Оформи, поставь откуда скопированно.
Для оформления используется выделение цветом важной информации, заголовков и т.п., добавление картинок и т.п.
Чтобы было хоть небольшое желание ЭТО читать.
а так автору минус пока что

~~pr0m0~~ · 22.03.2010, 11:39

Ниасилил..
Не нашел где что важное, автор сам читал ?? Мог бы сделать что типа конспекта или не?

FirstBIT · 24.03.2010, 17:42

актуально для времен С4

fuzzion · 30.03.2010, 13:24

на нормальных С4 не актуально.

Что такое Lineage ( Баги,Читы )

Статьи и описания по Lineage 2