1. Протокол.
Как и в пакетах login-сервера, первые два байта отводятся под длину. Далее байт означает тип пакета.
Вот типы пакетов, которые должен обрабатывать С3 клиент lineage2 (некоторые буду комментировать):
// отсылает login-сервер
0x01 loginfail2
0x02 accountKicked1
0x03 loginok
0x04 serverlist
0x05 serverfail
0x06 playfail
0x07 playok
0x08 accountKicked
0x09 blockedAccMsg // бан
0x20 protocol version different
0x00 VersionCheck

// отсылает game-сервер
0x01 MoveToLocation
0x02 NpcSay
0x03 CharInfo // имеется в виду окружающие персы
0x04 UserInfo
0x06 Attack
0x07 Attack
0x08 Attacked
0x09 Attacked
0x0a AttackCanceld
0x0b Die
0x0c Revive
0x0d AttackOutOfRange
0x0e AttackInCoolTime
0x0f AttackDeadTarget
0x10 LeaveWorld
0x11 AuthLoginSuccess
0x12 AuthLoginFail
0x13 CharList // список чаров
0x15 SpawnItem // на некоторых С3 ответ на выбор чара
0x16 DropItem // на некоторых С3 передаёт инфо о мобе
0x17 GetItem
0x18 EquipItem
0x19 UnequipItem
0x1a StatusUpdate
0x1b NpcHtmlMessage // на некоторых С3 передаёт список шмота с ItemID и их ObjectID
0x1c SellList
0x1d BuyList
0x1e DeleteObject
0x1f CharSelectInfo
0x20 LoginFail
0x21 CharSelected
0x22 NpcInfo
0x23 NewCharacterSuccessPacket
0x24 NewCharacterFailPacket
0x25 CharCreateOk
0x26 CharCreateFail
0x27 ItemList
0x28 SunRise
0x29 SunSet
0x2a EquipItemSuccess // устарел
0x2b EquipItemFail // устарел
0x2c UnEquipItemSuccess // устарел
0x2d UnEquipItemFail // устарел
0x2e TradeStart
0x2f TradeStartOk // устарел
0x30 TradeOwnAdd
0x31 TradeOtherAdd
0x32 TradeDone
0x33 CharDeleteSuccess
0x34 CharDeleteFail
0x35 ActionFail
0x36 ServerClose
0x37 InventoryUpdate
0x38 TeleportToLocation
0x39 TargetSelected
0x3a TargetUnselected
0x3b AutoAttackStart
0x3c AutoAttackStop
0x3d SocialAction
0x3e ChangeMoveType
0x3f ChangeWaitType
0x40 NetworkFail // устарел
0x43 CreatePledge
0x44 AskJoinPledge
0x45 JoinPledge
0x46 WithdrawalPledge
0x47 OustPledgeMember
0x48 SetOutPledgeMember
0x49 DismissPledge
0x4a SetDismissPledge
0x4b AskJoinParty
0x4c JoinParty
0x4d WithdrawalParty
0x4e OustPartyMember
0x4f SetOustPartyMember
0x50 DismissParty
0x51 SetDismissParty
0x52 MagicAndSkillList
0x53 WarehouseDepositList
0x54 WarehouseWithdrawalList
0x55 WarehouseDone
0x56 ShortCutRegister
0x57 ShortCutInit
0x58 ShortCutDelete
0x59 StopMove
0x5a MagicSkillUser
0x5b MagicSkillCanceld

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

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

a) покупка предметов
Для того, чтобы поставить на скупку предмет, нам нужно воспользоваться 3-мя пакетами.
Первый 0x94 (SetPrivateBuyMsg). Как видно из названия он устанавливает то сообщение, которое будет
выводится над головой у перса в момент торговли (то, которое на жёлтом фоне). Вот пример:

// SetPrivateStoreBuyMsg пакет
XX XX // Размер данных
94 // тип пакета
41 00 41 00 41 00 42 00 42 00 42 00 // текст. Символы должны быть разделены между собой null-байтом.
00 00 // конец пакета

Далее используем пакет типа 0x91 (SetPrivateBuyList). В нём как раз передаём количество предметов,Item ID
и цену. Например:

// SetPrivateStoreList пакет
XX XX // Размер данных
91 // тип пакета
01 00 00 00 // количество вещей
// начало блока
e1 02 00 00 // Item ID
00 00
01 00 00 00 // сколько предметов данного типа скупить
e8 03 00 00 // цена
// конец блока

XX XX // размер данных
1d // тип
01 00 00 00 // кол-во

Что касается продажи, то там практически всё то же самое. Только вместо 'SetPrivateBuyMsg' юзаем
'SetPrivateStoreMsg', а вместо 'SetPrivateBuyList' - 'SetPrivateStoreList' соответственно.
А, чуть не забыл, вместо Item ID юзаем Object ID, потому что мы продаём какой-то конкретный предмет.

b) приватные сообщения
Тут всё очень просто.

XX XX // размер данных
38 // тип пакета (Say2)
42 00 42 00 42 00 42 // сообщение (BBBB)
00 00 00 02 00 00 00 // пробел =)
41 00 41 00 41 00 41 // ник (АААА)
00 00 00 // конец

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

XX XX // длина пакета

1b // тип пакета (0x1b на antaras.ru)
00 00

05 00 // количество предметов

04 00 // тип шмотки
1e 26 14 40 // Object ID
d4 15 00 00 // Item ID (0x15d4 - Tutorial Guide)
01 00 00 00 // Количество
05 00 00 00 00 00 00 00 00 00 00 00 00 00 // Заточка, квестовый итем, дропается или нет и ещё что-то

01 00 // тип шмотки
1d 26 14 40 // Object ID
7b 04 00 00 // Item ID (0x47b - Squire's pants)
01 00 00 00 // Количество
01 00 00 00 00 00 00 08 00 00 00 00 00 00

01 00 // тип шмотки
1c 26 14 40 // Object ID
7a 04 00 00 // Item ID (0x47a - Squire's Shirt)
01 00 00 00 // Количество
01 00 00 00 00 00 00 04 00 00 00 00 00 00

00 00 // тип шмотки
1b 26 14 40 // Object ID
0a 00 00 00 // Item ID (0x0a - dagger)
01 00 00 00 // Количество
00 00 00 00 00 00 80 00 00 00 00 00 00 00

00 00 // тип шмотки
1a 26 14 40 // Object ID
42 09 00 00 // Item ID (0x942 - Guild Member's Club)
01 00 00 00 // Количество
00 00 00 00 00 00 80 00 00 00 00 00 00 00

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

04 // тип пакета (Action)
51 14 10 48 // OID NPC
// далее идут координаты _нашего_ персонажа
c6 51 01 00 // X
52 45 02 00 // Y
b8 f2 ff ff // Z
00 // конец

Причём однократная посылка этого пакета - выделение NPC. Чтобы завести с ним диалог, нужно послать этот пакет
ещё раз.
Далее, когда открывается окно с выбором диалогов и вы выбираете пункт "Learn skills", клиент серверу отсылает вот
такой пакет:

21 // тип пакета (RequestBypassToServer)
6c 00 65 00 61 00 72 00 6e 00 5f 00 73 00 6b 00 69 00 6c 00 6c 00 00 // learn_skill
00 // конец

После вызова диалога со скиллами, вы можете либо посмотреть информацию о любом скилле с помощью:

6b // тип пакета (RequestAcquireSkillInfo)
10 00 00 00 // номер скилла
09 00 00 00 // уровень

Чтобы выучить этот скилл, посылается точно такой же пакет, но с типом 0x63 (RequestAcquireSkill)

1. отсутствие лимита на кол-во попыток авторизации
Это даёт возможность к бесконечному перебору паролей к тому или иному аккаунту. Я не буду
описывать как и чего, брутфорсер он и в Африке брутфорсер. Расскажу лишь о своём личном опыте
в этой области.
Испытание проводилось на www.antaras.ru - старый, вымирающий отечественный lineage2 C1OFF сервер
(с добавками из с3). Используя только ту информацию (ну и non-blocking sockets), что я
предоставил выше, был написан брутфорсер (переборщик логинов и паролей) и программа, которая
выдирает список ников, играющих в данный момент на сервере с 'http://antharas.ru/?id=2'.
Составил от балды список паролей типа 123456789, 0987654321 (на antaras.ru минимальная длина
пароля 8 символов - на всех серверах по-разному), список с никами,в данный момент играющих на
сервере геймеров,составил ~1500 строк. Переборщик я запускал с постороннего сервера, дабы не
палить свой ип. Итого, за ночь было вскрыто порядка 50 аккаунтов. Но, к сожалению, большая половина
аккаунтов были либо пусты, либо с персонажами маленького уровня. Зато остальная малая часть...
Скажу лишь, что суммарный урон, нанесённый геймерам, составил чуть больше 1ккк игровых денег (шмотом)
или порядка 400$ ,если переводить в реальные - хотя как сторгуешься. Но, честно говоря, он не
"составил", а "составил бы". Я, на самом деле, абсолютно ничего не взял с этих аккаунтов, а нашёл
немного иное приминение всему этому wink Об этом ниже.

2. Удалённое определение версии lineage2 сервера
Помните я говорил, что последние 8 байт в пакетах логин-сервера отводятся под чексумму? Точнее, из них
предпоследние 4 :> А если вдруг оставить пакет без чексуммы, офф версия lineage сервера нас просто-
напросто дисконнектит. В l2j функция, которая проверяет чексумму возвращает true или false,
но почему-то возвращаемое значение не проверяется. То есть, фактически l2j не проверяет чексумму.
Соответственно, если дисконнект, то офф, если нет, то l2j.

3. Удалённое "подвешивание" login-сервера
Было замечено, что некоторые серверы на пакеты, не содержащие логина/пароля отвечают пакетом типа 0x03
(который означает, что вы успешно авторизованы). После чего начинают вести себя крайне нестабильно.
Я проверил это на 10-ти крупных С3 серверах, половина никак не отвечала на такой пакет, другая
отвечала пакетом 0x01 (авторизация не прошла), но только www.la2.ru посылал 0x03 и на время прекращал
принимать входящие соединения (видимо, у них установлена система "авто-подъёма").
Для реализации программы, которая бы подвешивала la2.ru, вам нужно всего-лишь смешать выше-предоставленный
генератор пакетов с простым tcp-клиентом.
Бесконечный цикл посыла подобных пакетов приведёт к невозможности зайти на игровой сервер.

Ещё тут вспомнился баг с "fake death". На некоторых кривых явах после FD чары как бы так и остаются мёртвыми и их нельзя
атаковать пока они не сделают рестарт. Ну это так, к слову.

7. 'remote DoS' и что это даёт
Обычно уязвимости подобного рода особо не ценятся, так как более чем просто "поприкалываться" из них ничего
получить нельзя. LA2 же постоянно сохраняет состояние мира (через каждые Н-секунд - этот вопрос ещё точно не
изучен, да он и не так важен), чтобы после внезапного падения сделать откат. То есть, умея прогнозировать
(или провоцировать) падение game-сервера, мы получаем "власть над откатами". Что это значит? А то, что,
вас убили? Откат! Вас раздели? Откат!! У вас не получилось заточить шмотку? Откат!!!
Кроме того, есть очень ценные монстры, которые имеют очень большое resp time (fairy queen timinel - респ
5 часов, например) и присутствуют в единичном экземпляре. Убили, повалили сервер, сервер поднялся, моб снова
появился. В итоге время респа сокращается с 5 часов до 3-ёх минут.
Как же перегружать сервер?
Для l2j 100% рабочий способ - это кристализация.
72 // RequestCrystallizeItem
00 00 00 00 // OID предмета
FF FF FF FF // количество
Подставляем в этот пакет реальный OID предмета и отсылаем. На что сервер моментально падает.
Для проджектов тут всё сложнее. При шифровании пакетов неправильным ключём, сервер иногда падает. ПОчему? Если
ключи не совпадают, значит сервер при расшифровке получает совершенно рандомные значения (то есть ни то, что мы
зашифровывали). И выследить как раз ту последовательность значений, при которой сервер падает, у меня пока что
не получилось.

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® 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(), скорее он обманет вас =) Стоит искать баги в самом
процессе точки, но опять же, как было продемонстрировано выше, это слишком простой процесс, чтобы быть бажным.

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

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

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

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

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

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

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

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

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