часть этой статьи являеться другая статья, статья о пакетном уровне, автора, к сожалению не помню, но думаю он мне простит
i. введение

ii. login-сервер

1. шифрование пакетов
2. структура пакетов
3. конструктор requestauthlogin-пакетов на си

iii. game-сервер.

1. процесс авторизации на сервере
2. шифрование пакетов
3. протокол
4. xid и objectid
5. примеры пакетов:
a) скупка/продажа
b) личка
c) oid и iid
d) говорим с npc на примере разучивания скиллов

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

1. отсутствие лимита на кол-во попыток авторизации
2. шифрование пакетов
3. удалённое определение версии lineage2 сервера
4. удалённое "подвешивание" login-сервера
5. клонирование
6. создание "мутантов" и смешение скиллов
7. бессмертие
8. 'remote dos' и что это даёт
9. integer overflow в сетевом движке l2j
10. sql-injection
11. заточка (или сказка о 100%-ом enchant'е)
12. геодата (хождение сквозь стены)
13. прикол с socialaction (0x1b)
14. баг в ride (0x6a)
15. выкидываем из игры чаров
16. баг с requestrestartpoint (оживление и побег из тюрьмы)
17. раздеть чужого персонажа не зная ни логина, ни пароля - разве это реально?
18. итог

v. баги нового поколения

vi. пара слов о с4

vii. послесловие

viii. ссылки

ix. приложения к статье

i. введение.

что же такое lineage? это представитель новомодного жанра (класса?) игрушек - mmorpg
(massively multiplayer online role-playing game). я бы даже сказал один из самых
удачных и популярных, если не самый =). конечно, трудно говорить о популярности этой
игры, т.к. посчитать точное количество "втянувшихся" в lineage, наверное, невозможно,
но такие серверы как  (с максимально зарегистрированным онлайном в
10 000 человек) и оффициальный  (со всеми 100 000, при том, что он платный)
дают понять, что цифра должна быть внушительной.
суть игры заключается в том, что (как и в любой другой rpg) у вас есть свой персонаж и
огромный мир, в котором нужно добывать деньги, одежду, оружие, опыт. для того, чтобы в конечном
итоге драться с такими же как ты игроками и тешить своё самолюбие победами. некоторым людям,
у которых ну никак не ладится реальная жизнь, она позволяет самореализоваться в виртуальном мире -
стать известным воином и даже найти невесту (да, девушек в lineage играет тоже немало).
среди всех остальных online (да и не только online) игр, lineage подкупает своей
графикой. мне лично поначалу казалось невероятным, что кто-то смог создать такие
чудесные трёхмерные красоты для простой игры.
но есть у игры и тёмные стороны. во-первых, она имеет свойство затягивать. причём не
просто затягивать, а вызывать зависимость, с которой крайне сложно бороться. во-вторых,
сами понимаете, в индустрии, в которой крутятся сотни тысяч игроманов из практически
всех слоёв общества, дело без денег не обойдётся (как и всё в нашей жизни). ведь у
некоторых людей, имеющих семью, работу, просто нет времени на то, чтобы месяцами
прокачивать своего персонажа до нужного уровня. такая геймерская прослойка породила
на свет личностей, которые начали продавать игровые уровни и вещи за реальные деньги,
создав тем самым новую нишу в мире lineage. на данный момент, в зависимости от величины
сервера (и рейтов), стоимость хорошо одетого персонажа высокого уровня может варьироваться
от 300$ на умирающем  до 5 000$ на официальном сервере. самое смешное-
это покупка вещей у администрации того или иного сервера. вдумайтесь, геймер платит
n-ное количество убитых енотов за то, чтобы админ добавил 1 запись в базу данных игры.
вот как делают деньги из воздуха.
что же, я что-то увлёкся описанием игры ) сказывается год ,на неё потраченный.
безусловно, в подобной индустрии (где закручены деньги и тучи наивных и, порой глупых
геймеров) дело без нас - пытливых умов - обойтись не может. кто-то покупает персонажей,
кто-то создаёт и прокачивает сам, мы же выбираем третий, непроторённый путь.
дело в том, что за несколько лет существования этой игры, в ней не было найдено не одной
уязвимости (за исключением сугубо игровых багов), для неё не было написано не одной программы,
которая могла бы открыть злоумышленникам доступ в чужие аккаунты. а знаете почему?
мне кажется, молодых, неопытных багоискателей (постами которых пестрит bugtraq) отталкивало злое
шифрование пакетов в lineage. причём, даже в расшифрованном виде, они представляют собой
беспорядочный набор символов.
может быть, старички помнят мою статью про протокол клиент-серверного взаимодействия и
уязвимости half-life . целью той статьи было
описать игру и предоставить на блюдечке почти всё, чего я достиг в её изучении. в этой же статье
я поведаю как же расшифровывать траффик lineage2, расскажу немного об особенностях
протокола, ну и предоставлю несколько наработок (как своих так и чужих), все остальное
публиковать не буду, так как повальное использование оного может привести к хаосу в этом
прекрасном, сбалансированном и вполне сформировавшемся виртуальном мире =)

внимание.
1. сразу предупреждаю, я иногда буду возвращаться к статье про half-life, ибо аналогии помогут
вам легче понять написанное. да и мне писать проще.
2. статья писалась на основе анализа расшифрованных пакетов и изучения исходного
кода "самопального" lineage2 сервера l2j, написанного на яве. соответственно, статья 100%
действительна для l2j, а для официального настолько, насколько l2j действителен для него =)
3. все исходники написаны под linux. для компиляции нужна либла blowfish. либлы из openssl
package подойдут при маленькой модификации кода.
4. кстати о модификации кода. в исходниках, предоставленных в статье, есть небольшие ошибки
в логике, дабы исключить их бездумное использование. если вы вникнете в статью, то и пофиксить
их не будет проблемой.
5. и последнее. полная версия статьи была доступна долгое время (пол года) только ограниченному
числу людей и с выходом с4 версии lineage2 и фиксами большинства багов резко устарела.
про с4 я расскажу немного в конце.

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. конструктор пакетов на си
чтож, со структурой пакетов мы разобрались, теперь можно реализовать программно всё, что было
описанно выше.

/*

la2-example.c ~ lineage2 c3 requestauthlogin packet constructor

helps to understand lineage2 authentification.

darkgrey / m00.blackhat.ru

~broken
*/

#include "/usr/local/include/blowfish.h"

// длина ключа
#define key_len 20
// длина requestauthlogin пакета постоянна и равна auth_pkt_len + 2
#define auth_pkt_len 0x30

// ключ, на основе которого генерируются sub-keys (подключи)
char key[] = "[;'.]94-31==-&%@!^+]";

// структура bfkey, которая после генерации подключей будет содержать
// 18 p подключей и 4 s матрицы
bf_key bfkey;

// функция, которая вычисляет чексумму и вставляет её в пакет
int add_ckecksum(char *raw, int count) {
long chksum = 0l;
int i = 0;
long ecx;
for(i = 0; i < count; i += 4) {
ecx = raw[i];
ecx |= raw[i + 1];
ecx |= raw[i + 2];
ecx |= raw[i + 3];
chksum ^= ecx;
}

printf("checksum: 0x%x\n",chksum);
memcpy(raw+count, (char *)&chksum, 4);
}

// добавляет логин и пароль в пакет (отделено от основной функции
// из соображений читабельности)
int add_lp(char *raw, char *l, char *p) {
l[15] = '\0';
p[17] = '\0';

memcpy(raw+3,l,strlen(l));
memcpy(raw+17,p,strlen(p));
}

// выводит на экран пакет в читабельном виде (для отладки)
int print_packet(char *raw, int len) {
int i, c = 0;

for(i=0;i<54;i++) printf("_");

for(i=0;i<len+2;i++) {
if((c % 0x10)==0) printf("\n0x%.2x | ", c);
printf("%.2x ",raw[i] & 0xff);
c++;

}
printf("\n\n");
}

// главная функция, которая конструирует пакет
int build_auth_packet(char *login, char *pwd) {
int count = auth_pkt_len / 8;
int i;
char packet_skeleton[] =
// каркас пакета requestauthlogin
"\x32\x00" // длина пакета постоянна и равна 0x30 + 0x02
"\x00" // тип пакета (0x00 - requestauthlogin)
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\ x00\x00" // login
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\ x00\x00\x00\x00" // password
"\x08" // означает конец секции login/password
"\x00\x00\x00\x00\x00\x00\x00\x00" // в c3 не применяется (зарезервированно?)
"\x00\x00\x00\x00" // чексумма
"\x00\x00\x00\x00";

// добавляем логин и пароль в пакет
add_lp(packet_skeleton, login, pwd);

// считаем и добавляем чексумму
add_ckecksum(packet_skeleton + 2, auth_pkt_len - 8);

printf("auth packet dump (non-crypted):\n");
print_packet(packet_skeleton, auth_pkt_len);

// шифруем блоками по 8 байт
for(i = 0; i < count; i++)
bf_encrypt((bf_long *)((short*)&packet_skeleton+1+i*4), &bfkey, bf_encrypt);

printf("auth packet dump (encrypted):\n");
print_packet(packet_skeleton,auth_pkt_len);
}

int main() {
char login[] = "m00", // тестовый логин
pwd[] = "ownzu"; // пароль

printf("\nla2-example.c ~ lineage2 c3 requestauthlogin packet constructor\n\n");

// генерируем sub-keys
bf_set_key(&bfkey, key_len, key);

// собираем пакет
build_auth_packet(login, pwd);
}
/* eof */

вот что на моём боксе программа вывела на экран:

bash-2.05b$ ./a.out

la2-example.c ~ lineage2 c3 requestauthlogin packet constructor

checksum: 0x224a0377
auth packet dump (non-crypted):
__________________________________________________ ____
0x00 | 32 00 00 6d 30 30 00 00 00 00 00 00 00 00 00 00
0x10 | 00 6f 77 6e 7a 75 00 00 00 00 00 00 00 00 00 00
0x20 | 00 08 00 00 00 00 00 00 00 00 77 03 4a 22 00 00
0x30 | 00 00

auth packet dump (encrypted):
__________________________________________________ ____
0x00 | 32 00 09 d9 97 e2 29 89 8c b5 1a a0 1a 83 74 43
0x10 | 39 fc 2f 03 c3 26 9c 65 b0 c4 20 28 11 c1 6a 95
0x20 | 3e 44 45 46 2a ae b9 18 91 2e 75 56 d0 dc 40 b5
0x30 | 77 2a

bash-2.05b$

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. протокол.
как и в пакетах 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
0x5d creaturesay
0x5e equipupdate
0x5f stopmovewithlocation
0x60 doorinfo
0x61 doorstatusupdate
0x63 partysmallwindowall
0x64 partysmallwindowadd
0x65 partysmallwindowdeleteall
0x66 partysmallwindowdelete
0x67 partysmallwindowupdate
0x68 pledgeshowmemberlistall
0x69 pledgeshowmemberlistupdate
0x6a pledgeshowmemberlistadd
0x6b pledgeshowmemberlistdelete
0x6c magiclist // устарел
0x6d skilllist
0x6e vehicleinfo
0x6f vehicledeparture
0x70 vehiclechecklocation
0x71 getonvehicle
0x72 getoffvehicle
0x73 traderequest
0x74 restartresponse
0x75 movetopawn
0x76 setto
0x77 startrotating
0x78 finishrotating
0x79 movebackwardtolocation // имеется ввиду скилл или to_the_nearest_village после смерти
0x7a systemmessage
0x7d startpledgewar
0x7e replystartpledgewar
0x7f stoppledgewar
0x80 replystoppledgewar
0x81 surrenderpledgewar
0x82 replysurrenderpledgewar
0x83 setpledgecrest // устарел
0x84 pledgecrest
0x85 setupgauge
0x86 showboard
0x87 chooseinventoryitem
0x89 movetolocationinvehicle
0x8a stopmoveinvehicle
0x8b validatelocationinvehicle
0x8c tradeotheradd2
0x8d tradepressownok // устарел
0x8e magicskilllaunched
0x8f friendaddrequestresult
0x90 friendadd // устарел
0x91 friendremove // устарел
0x92 friendlist // устарел
0x93 friendstatus // устарел
0x94 tradepressotherok // устарел
0x95 friendaddrequestresult2
0x96 leaveworld2
0x97 abnormalstatusupdate
0x98 questlist
0x99 enchantresult
0x9a authserverlist // устарел
0x9b pledgeshowmemberlistdeleteall
0x9c pledgeinfo
0x9d pledgeextendedinfo
0x9e surrenderpersonally
0x9f ride
0xa1 pledgeshowinfoupdate
0xa2 clientaction
0xa3 aquireskilllist
0xa4 aquireskillinfo
0xa5 serverobjectinfo
0xa6 hidegm
0xa7 aquireskilldone
0xa8 gmviewcharacterinfo
0xa9 gmviewpledgeinfo
0xaa gmviewskillinfo
0xab gmviewmagicinfo
0xac gmviewquestinfo
0xad gmviewitemlist
0xae gmviewwarehousewithdrawlist
0xaf partymatchlist
0xb0 partymatchdetail
0xb1 playsound
0xb2 staticobject
0xb3 privateselllist2
0xb4 privatebuylist2
0xb5 privatestoremsg
0xb6 showminimappacket
0xb7 reviverequest // устарел
0xb8 abnormalvisualeffect
0xb9 tutorialshowhtml
0xba tutorialshowquestionmark
0xbb tutorialenableclientevent
0xbc tutorialclose
0xbd showradar
0xbe deleteradar
0xbf mytargetselected
0xc0 partymemberposition
0xc1 askjoinalliance
0xc2 joinalliance
0xc3 withdrawalliance
0xc4 oustalliancememberpledge
0xc5 dismissalliance
0xc6 setalliancecrest // устарел
0xc7 receiveallycrest
0xc8 serverclosesocket // устарел
0xc9 petstatusshow
0xca petinfo
0xcb petitemlist
0xcc petinventoryupdate
0xcd allianceinfo // устарел
0xce petstatusupdate
0xcf petdelete
0xd0 privateselllist
0xd1 privatebuylist
0xd2 privatestoremsg
0xd3 vehiclestart
0xd4 requesttimecheck
0xd5 startalliancewar
0xd6 replystartalliancewar // устарел
0xd7 stopalliancewar
0xd8 replystopalliancewar // устарел
0xd9 surrenderalliancewar // устарел
0xda skillcooltimepacket
0xdb packagetolistpacket
0xdc packagesendablelistpacket
0xdd earthquake
0xde flytolocation
0xdf blocklist // устарел
0xe0 specialcamera
0xe1 normalcamera
0xe2 castlesiegeinfopacket
0xe3 castlesiegeattackerlist
0xe4 castlesiegedefenderlist
0xe5 nicknamechanged
0xe6 pledgestatuschanged
0xe7 relationchanged
0xe8 oneventtrigger
0xe9 multiselllistpacket
0xea setsummonremaintime
0xeb onskillremainsec
0xec netpingpacket

от клиента серверу:
0x01 movebackwardtolocation
0x02 say
0x03 enterworld
0x04 action
0x08 requestauthlogin
0x09 logout
0x0a attack
0x0b charactercreate
0x0c characterdelete
0x0d characterselect
0x0e newcharacter
0x0f itemlist
0x10 requestequipitem
0x11 requestunequipitem
0x12 requestdropitem
0x12 requestdropitemfrompet
0x14 useitem
0x15 traderequest
0x16 addtradeitem
0x17 tradedone
0x1a requestteleport
0x1b socialaction
0x1c changemovetype // устарел. теперь юзается 'requestactionuse'
0x1d changewaittype // устарел. теперь юзается 'requestactionuse'
0x1e requestsellitem
0x1f requestbuyitem
0x20 requestlinkhtml
0x21 requestbypasstoserver
0x22 requestbbswrite
0x23 requestcreatepledge
0x24 requestjoinpledge
0x25 requestanswerjoinpledge
0x26 requestwithdrawalpledge
0x27 requestoustpledgemember
0x28 requestdismisspledge
0x29 requestjoinparty
0x2a requestanswerjoinparty
0x2b requestwithdrawalparty
0x2c requestoustpartymember
0x2d requestdismissparty
0x2e requestmagicskilllist
0x2f requestmagicskilluse
0x30 appearing
0x31 sendwarehousedepositlist
0x32 sendwarehousewithdrawlist
0x33 requestshortcutreg
0x34 requestshortcutuse
0x35 requestshortcutdel
0x37 requesttargetcancel
0x38 say2 // приват (на некоторых серверах - la2.ru - юзается 0x39)
0x3c requestpledgememberlist
0x3e requestmagiclist
0x3f requestskilllist
0x41 movewithdelta
0x42 getonvehicle
0x43 getoffvehicle
0x44 answertraderequest
0x45 requestactionuse
0x46 requestrestart
0x47 requestsiegeinfo
0x48 validateposition
0x49 requestsekcustom
0x4a startrotating
0x4b finishrotating
0x4d requeststartpledgewar
0x4e requestreplystartpledgewar
0x4f requeststoppledgewar
0x50 requestreplystoppledgewar
0x51 requestsurrenderpledgewar
0x52 requestreplysurrenderpledgewar
0x53 requestsetpledgecrest
0x55 requestgivenickname // вообще юзается для установки тайтла cl'ами. может для чего ещё..
0x57 requestshowboard
0x58 requestenchantitem
0x59 requestdestroyitem
0x5b sendbypassbuildcmd
0x5e requestfriendinvite
0x5f requestfriendaddreply
0x60 requestfriendlist
0x61 requestfrienddel
0x62 characterrestore
0x63 requestquestlist
0x64 requestdestroyquest
0x66 requestpledgeinfo
0x67 requestpledgeextendedinfo
0x68 requestpledgecrest
0x69 requestsurrenderpersonally
0x6a ride
0x6b requestacquireskillinfo
0x6c requestacquireskill
0x6d requestrestartpoint
0x6e requestgmcommand
0x6f requestpartymatchconfig
0x70 requestpartymatchlist
0x71 requestpartymatchdetail
0x72 requestcrystallizeitem
0x73 requestprivatestoremanage
0x74 setprivatestorelist
0x75 requestprivatestoremanagecancel
0x76 requestprivatestorequit
0x77 setprivatestoremsg
0x78 requestprivatestorelist
0x79 sendprivatestorebuylist
0x7a revivereply
0x7b requesttutoriallinkhtml
0x7c requesttutorialpasscmdtoserver
0x7d requesttutorialquestionmark
0x7e requesttutorialclientevent
0x7f requestpetition
0x80 requestpetitioncancel
0x81 requestgmlist
0x82 requestjoinally
0x83 requestanswerjoinally
0x84 requestwithdrawally
0x85 requestoustally
0x86 requestdismissally
0x87 requestsetallycrest
0x88 requestallycrest
0x89 requestchangepetname
0x8a requestpetuseitem
0x8b requestgiveitemtopet
0x8c requestgetitemfrompet
0x8e requestallyinfo
0x8f requestpetgetitem
0x90 requestprivatestorebuymanage
0x91 setprivatebuylist
0x92 requestprivatestorebuymanagecancel
0x93 requestprivatestorebuyquit
0x94 setprivatebuymsg
0x95 requestprivatestorebuylist
0x96 sendprivatestorebuybuylist
0x97 sendtimecheckpacket
0x98 requeststartalliancewar
0x99 replystartalliancewar
0x9a requeststopalliancewar
0x9b replystopalliancewar
0x9c requestsurrenderalliancewar
0x9d requestskillcooltime
0x9e requestpackagesendableitemlist
0x9f requestpackagesend
0xa0 requestblock
0xa1 requestcastlesiegeinfo
0xa2 requestcastlesiegeattackerlist
0xa3 requestcastlesiegeinfo
0xa4 requestjoincastlesiege
0xa5 requestconfirmcastlesiegewaitinglist
0xa6 requestsetcastlesiegetime
0xa7 requestmultisellchoose
0xa8 netping

как видите, большинство клиентских пакетов начинается со слова request, что переводится как "запрос".
да, действительно, весь процесс игры выглядит примерно так: сервер постоянно передаёт нам состояние мира,
положение мобов/игроков/npc и тд. мы же, когда что-то надо (пойти, атаковать и тд) передаём "запрос". всё
очень просто.
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) покупка предметов
для того, чтобы поставить на скупку предмет, нам нужно воспользоваться 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 // цена
// конец блока

немного поясню этот пакет. им мы поставили на скупку 1 вещь с iid 0x2e1 (scroll of resurrection) за 1000 аден.
и последний пакет типа 0x1d. он непосредственно запускает торговлю:

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)