Централизованый формат снифов

[Konctantin]

Редакция от 31 июля 2011, 13:13, версия 3.1

• 1. RAW.
  • 1.1. заголовок снифа.
    

    struct MainHeader
    {
      char signature[3]; // 'RAW'.
      byte version[2]; // 0x01, 0x03
      byte snifferID; 
      uint build; 
      char language[4]; // Язык клиента: 'ruRU', 'enGB' и т.д.
      byte sessionKey[40]; 
      uint unixTime;
      uint tickCount;
      uint optionalHeaderLength; 
    };
    byte[optionalHeaderLength] optionalData;

  • 1.2. чанк
    

    struct ChunkHeader
    {
      char direction[4]; // 'SMSG', 'CMSG'
      uint sessionID;
      uint tickCount;
      uint optionalDataLength;
      uint dataLength;
    };
    byte[optionalDataLength] optionalData;
    byte[dataLength] data;

• 2. PKT.
  • 2.1. заголовок снифа.
    

    struct MainHeader
    {
      char signature[3]; // 'PKT'
      byte version[2]; // 0x01, 0x03
      byte snifferID; 
      uint build; 
      char language[4]; // Язык клиента: 'ruRU', 'enGB' и т.д.
      byte sessionKey[40]; // может быть заполнено нулями
      uint unixTime;
      uint tickCount;
      uint optionalHeaderLength; 
    };
    byte[optionalHeaderLength] optionalData;

  • 2.2. чанк
    

    struct ChunkHeader
    {
      char direction[4]; // 'SMSG', 'CMSG'
      uint sessionID;
      uint tickCount;
      uint optionalDataLength;
      uint dataLength;
    };
    byte[optionalDataLength] optionalData;
    byte[dataLength] data;

    , где
    - data включает в себя Opcode, выравненный до uint
    - dataLength равен размеру data
  
  
• 3. Имя файла.
  • 3.1. имя файла
    имя может быть произвольным и удобным каждому из разработчиков.
    
  • 3.2. расширение файла
    обязательно .raw или .pkt

Редакция от 25 июля 2010, 21:00, версия 3.0

• 1. RAW.
  • 1.1. заголовок снифа.
    

    struct MainHeader
    {
      char signature[3]; // 'RAW'.
      byte version[2]; // 0x00, 0x03
      byte snifferID; 
      uint build; 
      char language[4]; // Язык клиента: 'ruRU', 'enGB' и т.д.
      byte sessionKey[40]; 
      uint optionalHeaderLength; 
    };
    byte[optionalHeaderLength] optionalData;

  • 1.2. чанк
    

    struct ChunkHeader
    {
      char direction[4]; // 'SMSG', 'CMSG'
      uint unixTime;
      uint tickCount;
      uint optionalDataLength;
      uint dataLength;
    };
    byte[optionalDataLength] optionalData;
    byte[dataLength] data;

• 2. PKT.
  • 2.1. заголовок снифа.
    

    struct MainHeader
    {
      char signature[3]; // 'PKT'
      byte version[2]; // 0x00, 0x03
      byte snifferID; 
      uint build; 
      char language[4]; // Язык клиента: 'ruRU', 'enGB' и т.д.
      byte sessionKey[40]; // может быть заполнено нулями
      uint optionalHeaderLength; 
    };
    byte[optionalHeaderLength] optionalData;

  • 2.2. чанк
    

    struct ChunkHeader
    {
      char direction[4]; // 'SMSG', 'CMSG'
      uint unixTime;
      uint tickCount;
      uint optionalDataLength;
      uint dataLength;
    };
    byte[optionalDataLength] optionalData;
    byte[dataLength] data;

    , где
    - data включает в себя Opcode, выравненный до uint
    - dataLength равен размеру data

Предложения
SnifferID:

0 - Wad // 2005 и ранее
1 - Nomad // 2005 и ранее
2 - WoWCore // 2006
3 - Mangos (TOM_RUS) // 2006
4 - User456 // 2007
5 - Delfin // 2007
6 - Burlex // 2007
7 - WCell // 2008
8 - Kobold // 2009
9 - abdula123 // 2010
10 - Konctantin/LordJZ // 2010
11 - Йоха // 2010

[TOM_RUS]

Я только сегодня добавил поддержку PKT 3.0 в свой WoWPacketViewer

[HuntsMan]

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

у кого нить есть готовый конвертор PKT 2.1 -> PKT 3.0?

А описание формата 2.1 где-нибудь глянуть можно?)

[Йоха]

на wowcore.ru

[RomanRom2]

не, ну если так сходу нет, то сам напишу лень просто...
я все свои снифы от классика сейчас перевел (почти) в PKT 2.1, да у меня в те времена было много разных форматов. вот думаю разом их в 3.0 конвертнуть и работать уже с ними. вот в бекграунде и пописываю...

кстати, собираю снифы в данный момент от классика. ни у кого не завалялось?

[HuntsMan]

Да я какбэ просто хочет к себе в парсер добавить поддержку этого формата, авось попадется

PS: Кому не жалко покажите структуру optionalData хидера и чанка, хочется в свой парсер добавить поддержку как можно большего количества форматов

[Йоха]

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

PS: Кому не жалко покажите структуру optionalData хидера и чанка, хочется в свой парсер добавить поддержку как можно большего количества форматов

Формат этого поля не определен, каждый пишет туда что захочет. У меня там для хидера пусто, а для чанков строка - адрес соединения и порт, например :

195.12.246.213:3724

[HuntsMan]

Спасибо Просто я у себя в хидере пишу описание, и количество пакетов в снифе. Естественно парсер использует эти данные. А то вдруг чей-нить сниф подвернется, и читатся не будет

[RomanRom2]

очень плохо. эти поля были сделаны не для хранения данных и последующего парсинга, а для как поля "для заметок". это не по феншую.

[Lordronn]

Не у кого не завалялось сниффа версии 2.1 и ранее. Хочу проверить как парсер будет их кушать

[RomanRom2]

http://wowcore.ru/downloads/HUMAN_priest[3.3.5]_PKT_v2.1.rar

там же и RAW и там же лог декодера, ну... какие опкоды там есть.

[Lordronn]

хедер:
ushort build
byte[40] sessionKey

чанк:
byte direction
uint unixTime
uint tickCount
uint size
uint opcode (direction == Direction.Client) ? uint : ushort;
byte[] data (size - (direction == Direction.Client) ? 4 : 2;

[LordJZ]

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

у кого нить есть готовый конвертор PKT 2.1 -> PKT 3.0?

У меня в сниффере есть встроенный конвертор из любого в любой (почти) формат, если кому-то сильно надо, могу вырезать и выложить как отдельный .ехе.

[RomanRom2]

а конвертните мне примерчик плиз, что я выложил, что б было с чем сравнивать?

[LordJZ]

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

а конвертните мне примерчик плиз, что я выложил, что б было с чем сравнивать?

Не понял, но все равно конвертнул в PKT 3.0 http://dl.dropbox.com/u/9241118/romanrompkt.rar

[RomanRom2]

все правильно сделал (с)
спасибо
я свой конвертор дописываю. когда есть пример - оно проще мне. я вообще люблю, знаете ли, по примерам обучаться.

[Йоха]

Вот и возник косячок, как я понял снифер или конвертер от LordJZ в поле версия пишет байты в другом порядке: 03 00
А в описании формата вроде как написано что надо писать 00 03.
Мой вьювер проверяет заголовок снифа и если что-то не совпадает, то файл не обрабатывается.
В частности проверяется сигнатура и версия.

[RomanRom2]

сначала должен быть записан младший байт, потом старший. в "3.0" 3 это старший, 0 - младший. при чтении word или (ushort или как там в си?) дожно быть число $0300 (0x0300).

[LordJZ]

Сообщение от Йоха

Вот и возник косячок, как я понял снифер или конвертер от LordJZ в поле версия пишет байты в другом порядке: 03 00
А в описании формата вроде как написано что надо писать 00 03.
Мой вьювер проверяет заголовок снифа и если что-то не совпадает, то файл не обрабатывается.
В частности проверяется сигнатура и версия.

Где это у меня такое? В выложенном выше архиве всё верно.

[RomanRom2]

http://ru-mangos.ru/showpost.php?p=11523&postcount=84

[Йоха]

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

сначала должен быть записан младший байт, потом старший. в "3.0" 3 это старший, 0 - младший. при чтении word или (ushort или как там в си?) дожно быть число $0300 (0x0300).

значит надо исправить тему, там явно написано:

// 0x00, 0x03

как это можно по другому понимать ? Для чего вообще это поле сделали byte[2], надо было сделать ushort и вопросов бы не возникало

[RomanRom2]

в теме все правильно написано. сначала младший, потом старший байты. соответственно 00, затем 03.

[Йоха]

ну так а почему в файле lich.pkt порядок байт другой

0000000000: 50 4B 54 03 00 0D 37 35 │ 00 00 72 75 52 55 00 00  PKT♥ ♪75  ruRU

Если это не конвертер от LordJZ, то сори, я лично обвинить тебя не хотел, просто подумал что это твоим конвертером сделан файл. Там в коментариях что-то мелькает насчет конвертера из izi в pkt.
Тогда претензии к автору этого снифа

http://ru-mangos.ru/showpost.php?p=21601&postcount=6

Вроде это Lordronn выкладывал, исправляй свой снифер или конвертер.

[RomanRom2]

не знаю почему Lordronn запутался в двух байтах в спецификации четко написано каков должен быть порядок байт.

[Lordronn]

Эм, я вообще не LordJZ-им конвертором конвертил. Я конвертировал с помощью IZI2PKT, только он у меня изменен.
С байтами не я запутался, а автор тулзы, а я проглядел)

[RomanRom2]

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

Не понял, но все равно конвертнул в PKT 3.0 http://dl.dropbox.com/u/9241118/romanrompkt.rar

наконец то написал свои конверторы pkt2-to-pkt3 и обратно, проверьте.
http://filebeam.com/dae73f8446073dada011b4120249b374

в приведенном выше LordJZ сниффе к каждому чанку добавлена optData длиной в два байта и содержащая два нуля. можно поинтересоваться зачем?

[LordJZ]

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

...
в приведенном выше LordJZ сниффе к каждому чанку добавлена optData длиной в два байта и содержащая два нуля. можно поинтересоваться зачем?

Это «мои» данные, забыл поставить проверку на их запись при неправильном SnifferId. А данных в исходном дампе не было, поэтому писал нули. Поправлю у себя.

[RomanRom2]

прошу любить и жаловать, версия 3.1 - поддержка нескольких соединений в одном файле.

Редакция от 19 мая 2011, 14:00

• 1. RAW.
  • 1.1. заголовок снифа.
    

    struct MainHeader
    {
      char signature[3]; // 'RAW'.
      byte version[2]; // 0x01, 0x03
      byte snifferID; 
      uint build; 
      char language[4]; // Язык клиента: 'ruRU', 'enGB' и т.д.
      byte sessionKey[40]; 
      uint unixTime;
      uint tickCount;
      uint optionalHeaderLength; 
    };
    byte[optionalHeaderLength] optionalData;

  • 1.2. чанк
    

    struct ChunkHeader
    {
      char direction[4]; // 'SMSG', 'CMSG'
      uint connectionID;
      uint tickCount;
      uint optionalDataLength;
      uint dataLength;
    };
    byte[optionalDataLength] optionalData;
    byte[dataLength] data;

• 2. PKT.
  • 2.1. заголовок снифа.
    

    struct MainHeader
    {
      char signature[3]; // 'PKT'
      byte version[2]; // 0x01, 0x03
      byte snifferID; 
      uint build; 
      char language[4]; // Язык клиента: 'ruRU', 'enGB' и т.д.
      byte sessionKey[40]; // может быть заполнено нулями
      uint unixTime;
      uint tickCount;
      uint optionalHeaderLength; 
    };
    byte[optionalHeaderLength] optionalData;

  • 2.2. чанк
    

    struct ChunkHeader
    {
      char direction[4]; // 'SMSG', 'CMSG'
      uint connectionID;
      uint tickCount;
      uint optionalDataLength;
      uint dataLength;
    };
    byte[optionalDataLength] optionalData;
    byte[dataLength] data;

    , где
    - data включает в себя Opcode, выравненный до uint
    - dataLength равен размеру data
    - connectionID - любые числа на усмотрение разработчика, можно использовать socketID, можно автоинкремент. Важно что бы пакеты одной сессии можно было отличить от пакетов другой.
• 3. Имя файла.
  • 3.1. имя файла
    имя может быть произвольным и удобным каждому из разработчиков.
    
  • 3.2. расширение файла
    обязательно .raw или .pkt

Список ревьюверов тот же:
- Konctantin:
- LordJZ: accepted
- TOM_RUS:
- RomanRom2: accepted
- VDm:
- Deamon:
- Nomad:
- abdula123:
- user456:
- Aven:
- йоха:

ревью до 19 июня 2011г.

[Йоха]

я бы поле uint unixTime; перенес из хидера чанка в мейн хидер. Начальное время берется из хидера, а потом есть тиккаунт

И еще предлагаю opcode вынести из data в чанк хидер, а в data хранить чистые данные пакета

[Lordronn]

1.Я бы использовал 1 байт для connectionId, ибо ну не верю я, что будет более 255 соеденений, с которых можно будет получить интересное нам
2.tickCount - не понимаю зачем он вообще.
3.
Я бы изменил порядок на такой:

uint optionalDataLength;
uint dataLength;
byte[dataLength] data;
uint optionalDataLength;
byte[optionalDataLength] optionalData;

[LordJZ]

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

1.Я бы использовал 1 байт для connectionId, ибо ну не верю я, что будет более 255 соеденений, с которых можно будет получить интересное нам
...

Это не индекс, это уникальный номер. Нулевое (которое закрывается сразу после открытия), первое (Home сервер), второе (World сервер 1 при входе в мир), третье (World сервер 2 при смене карты). Возможно, 4 байта под это много. Но где-то здесь проскакивала мысль про Socket Handle, в теории он может быть > 0xFFFF.

Я бы изменил порядок на такой:

Против.

я бы поле uint unixTime; перенес из хидера чанка в мейн хидер. Начальное время берется из хидера, а потом есть тиккаунт

У меня тоже были мысли на эту тему, но в таком случае получается нелегким (точнее, небыстрым) вычисление времени для какого-то отдельного взятого пакета.[/quote]

И еще предлагаю opcode вынести из data в чанк хидер, а в data хранить чистые данные пакета

Вот здесь я «за». Еще можно сделать размер в 2 байта. ) Но не много ли изменений для 3.1 ?

[RomanRom2]

возможно вы правы, время для чанка может и не нужно, сейчас вспоминаю, когда и зачем оно было нужно... и не припоминаю. тем более в прошлый раз мы это тоже обсуждали. время чанка вычисляется одним сложением времени снифа и тиккаунта чанка. тиккаунт чанка - очень нужный параметр. можно сказать фундаментальная основа снифа. есть такие, кто этого не понимает?

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

против вынесения опкода из данных. опкод - это часть данных, это заголовок пакета. хидер чанка - это протольные поля, никакого отношения к данным не имеющие. не нужно их мешать, как например tcp с эзернетом. делать их 2 или 4 байта - без разницы, т.к. либо тот либо тот все равно придется выравнивать до выбранной размерности. на прошлом ревью если помните выбрали 4 потому что это компиляторы выравнивают поля до 4 байт (если не принять мер специально) и вроде как легче процессору. фигня конечно все это , но выбрали уж.

1 байт для идентификатора соединения я думаю мало. смотря как делать... если для каждого нового соединения просто инкрементировать это значение, то возможно в большинстве случаев этого будет достаточно. но это такое скользкое ограничение, что потенциально возможны случаи, когда инкремент достигнет 255 и пойдет далее. например когда снифер долго запущен и плеер-задрот играет все выходные безвылазно. ну может же быть такое? поэтому что бы ну совсем исключить даже потенциальные проблемы был предложен int, что бы даже не думалось нахрен об этом

в связи с вышесказанным есть предложение заменить unixDateTime на ConnectionID. вот и все изменения для 3.1

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

[Йоха]

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

против вынесения опкода из данных. опкод - это часть данных, это заголовок пакета. хидер чанка - это протольные поля, никакого отношения к данным не имеющие. не нужно их мешать, как например tcp с эзернетом. делать их 2 или 4 байта - без разницы, т.к. либо тот либо тот все равно придется выравнивать до выбранной размерности.

ну неудобно просто за опкодом лезть в данные ... Какой смысл хранить его там? кроме религиозных мотивов

меня бесит вот такое уродство в коде:

int opcode = *(int *)(m_Index[nIndex] + sizeof(PKT_CHUNK) + chunk->optionalDataLength);

а то как бы было красиво:

int opcode = chunk->opcode

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

на прошлом ревью если помните выбрали 4 потому что это компиляторы выравнивают поля до 4 байт (если не принять мер специально) и вроде как легче процессору. фигня конечно все это , но выбрали уж.:

это все фигня, выравнивание данных замечательно управляется из кода
у меня это структуры объявлены так:

#pragma pack(push, 1)

struct PKT_HEADER
{
	BYTE signature[3]; // 'PKT'
	BYTE version[2]; // 0x00, 0x03
	BYTE snifferID; 
	DWORD build; 
	BYTE language[4]; // Язык клиента: 'ruRU', 'enGB' и т.д.
	BYTE sessionKey[40]; // может быть заполнено нулями
	DWORD optionalHeaderLength; 
};

struct PKT_CHUNK
{
	union
	{
		BYTE b[4]; // 'SMSG', 'CMSG'
		DWORD d;
	} direction;
	DWORD unixTime;
	DWORD tickCount;
	DWORD optionalDataLength;
	DWORD dataLength;
};

#pragma pack(pop)

[Lordronn]

Ну в разных языках\способах все выглядит по разному. У меня это вот так

                        byte[] optionalData = reader.ReadBytes(optionalDataLength);
                        byte[] data = reader.ReadBytes(dataLength);

                        using (BinaryReader binReader = new BinaryReader(new MemoryStream(data)))
                        {
                            uint opcode = binReader.ReadUInt32();
                            byte[] byteData = binReader.ReadBytes((int) (binReader.BaseStream.Length - 4));
                            packets.Add(new Packet(direction, (Opcode) opcode, byteData, unixTime, tickCount));
                        }

[HuntsMan]

Думаю для pkt все же удобнее было бы вынести опкод в отдельное поле, т.к. мы рассматриваем WoW Packet, а не TCP Packet. В остальном полностью согласен.

[alien]

это все фигня, выравнивание данных замечательно управляется из кода
у меня это структуры объявлены так:

Угу только #pragma pack не стандарт а пошло из MS Studio и поддерживается не всеми компиляторами )

[Йоха]

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

Угу только #pragma pack не стандарт а пошло из MS Studio и поддерживается не всеми компиляторами )

что в других компиляторах нет возможности задавать размер выравнивания структур ?

[alien]

Есть но не все поддерживают прагму)

[Йоха]

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

Я привел пример с прагмой потому что пишу на VC++, остальные могут почитать документацию к своему комплятору

[LordJZ]

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

возможно вы правы, время для чанка может и не нужно, сейчас вспоминаю, когда и зачем оно было нужно... и не припоминаю. тем более в прошлый раз мы это тоже обсуждали. время чанка вычисляется одним сложением времени снифа и тиккаунта чанка. тиккаунт чанка - очень нужный параметр. можно сказать фундаментальная основа снифа. есть такие, кто этого не понимает?

Ага, понял свою ошибку.

...
в связи с вышесказанным есть предложение заменить unixDateTime на ConnectionID. вот и все изменения для 3.1

Вот это уже совсем хорошо. )

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

Сообщение от Йоха

...
меня бесит вот такое уродство в коде:

int opcode = *(int *)(m_Index[nIndex] + sizeof(PKT_CHUNK) + chunk->optionalDataLength);

а то как бы было красиво:

int opcode = chunk->opcode

...

Дак создайте аксессор:

int getOpcode()
{
    return *(int *)(m_Index[nIndex] + sizeof(PKT_CHUNK) + this->optionalDataLength);
}

И тогда:

int opcode = chunk->getOpcode();

Добавлено:

Прошу прощения, не стерпел, сделал обработчик PKT 3.1, заодно переделал у себя алгоритм чтения.
PKT 3.1 превью номер 0, версия 19 мая, присутствуют Connection Id, Unix и Ticks в основном заголовке (файл был действительно создан 14 апреля), Opt Data во всех заголовках: http://dl.dropbox.com/u/9241118/PKT_3.1_Preview_0.pkt (файл «искусственный», т.е. конвертированный из PKT 3.0 в PKT 3.1)

[LordJZ]

Со времен 19 июня 2011 прошло уже почти 3 недели. Отзывов что-то не сильно видно. :/