[Guide] How to sniff packets and parse it

03/15/2022 04:18 Z E T S U#1

currently, I know that I can fetch packets from edxLoader but I noticed that the edxLoader cannot fetch all the packets, especially when I had tried to log in to the server.so I want to know there is any other program can I use to read all the packets, and I wonder how I can parse the packets analyze them
such as this a packet chat

PHP Code:


			
[S -> C][3026]





07                                                ................





06 00                                             ................





61 00 73 00 64 00 61 00 73 00 64 00               a.s.d.a.s.d.....

how I can know what to use
ReadUint8() or ReadUint32() or ReadInt16() and so one
for an example i see smth like that

PHP Code:


			
06 02 03 04

in same line so I'm confused

03/15/2022 04:26 bimbum*#2

you can use packet parser by jellybitz.
the second question
07 > is 1 byte = 8 bits usually its a flag or a type (first byte of the packet) you can cosider it as readuint8
06 00 > is 2 bytes = 16 bits so you can cosider it as readuint16 (keep in mind at this case its the string size)
so if you have
06 02 03 04 = 4 bytes = 32 bits so you can read it as readuint32

theres a bot also called xbot by jellybitz too contains most packets parsed

--
uint = unsigned int making sure that the int you receive is greater or equal 0

03/15/2022 05:16 Z E T S U#3

first of all thanks for your hints, but why I see some packets containing smth like this bytes

Quote:

06 02 03 04

they don't use ReadUint32() and they distribute it into other bytes as 06 02 alone and 03 04 alone and it gives a diff result instead of using ReadUint32()

last question where can I find packet parser by JellyBitz I couldn't find it

03/15/2022 17:02 DaxterSoul#4

This is the [Only registered and activated users can see links. Click Here To Register...] that was talked about.

The reason edxAnalyzer is able to break up the packet data stream into segments is because it traces the individual read operations in the client when the packet is received. Some packets won't show because the way it's implemented (CMsg vs CMsgStreamBuffer and Buffering)

Figuring out the packet structure from the data stream alone is very hard. It can be done by comparing alot of edxAnalyzer logs and tracking where branches exist and I've parsed the majority of the SR_Client packets this way but a much easier approach is to reverse engineering the handler functions in the client. This will give you a structurally correct parse first and foremost as you won't always identify all ways the packet can change it's structure.

[Only registered and activated users can see links. Click Here To Register...]

Could you elaborate on this with concrete examples?

Quote:

Originally Posted by Z E T S U

first of all thanks for your hints, but why I see some packets containing smth like this bytes
06 02 03 04 they don't use ReadUint32() and they distribute it into other bytes as 06 02 alone and 03 04 alone and it gives a diff result instead of using ReadUint32()

03/15/2022 19:10 Z E T S U#5

Could you elaborate on this with concrete examples?

this is a recall user packet

PHP Code:


			

[C -> S][7010]
11 00                                             ................
09 00                                             ................
41 75 74 6F 45 76 65 6E 74                        AutoEvent.......

as Bimbum mentioned above
11 00 => WriteUint16() as it is a 2 bytes = 16 bits
09 00 => WriteUint16() as it is a 2 bytes = 16 bits (this is charname length i guess)

when i'm try to use this function nothing happened

PHP Code:


			
 Packet packet = new Packet(0x7010);
            packet.WriteUInt16((byte)0x11);
            packet.WriteAscii(Message);
            this.Send(packet);

but in another source , it is working like that

PHP Code:


			
 Packet packet = new Packet(0x7010);
                    packet.WriteUInt8((byte)0x11);
                    packet.WriteUInt8((byte)0);
                    packet.WriteAscii(Charname);
            this.Send(packet);

as you noticed that he split 11 00 into WriteUint8() and 00 into another WriteUint8()

and another question this 0x3013 packet at the same line has more than 4 bytes
how I can differentiate between them in this case how could I choose what to use

Quote:

[S -> C][3013]
D6 3C 8A 91 74 07 00 00 32 6E 6E 00 00 00 00 00 .<..t...2nn.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 C3 06 00 00 C3 06 ................
00 00 01 00 00 00 00 00 00 00 00 00 2D 08 01 00 ............-...
00 00 00 3B 0E 00 00 00 00 00 00 00 00 00 00 00 ...;............
27 00 00 00 00 01 00 02 00 04 00 00 00 00 3C 0E '.............<.
00 00 00 00 00 00 00 00 00 00 00 27 00 00 00 00 ...........'....
01 00 02 00 05 00 00 00 00 3D 0E 00 00 00 00 00 .........=......
00 00 00 00 00 00 27 00 00 00 00 01 00 02 00 06 ......'.........
00 00 00 00 30 0E 00 00 00 00 00 00 00 00 00 00 ....0...........
00 3E 00 00 00 00 01 00 02 00 07 00 00 00 00 86 .>..............
2A 00 00 00 00 00 00 00 00 00 00 00 2E 00 00 00 *...............
00 01 00 02 00 0D 00 00 00 00 42 1D 00 00 01 00 ..........B.....
0E 00 00 00 00 43 1D 00 00 01 00 0F 00 00 00 00 .....C..........
8E 28 00 00 14 00 05 00 00 01 01 01 00 00 00 01 .(..............
02 01 00 00 00 01 03 01 00 00 00 01 11 01 00 00 ................
00 01 12 01 00 00 00 01 13 01 00 00 00 01 14 01 ................
00 00 00 02 00 02 01 00 01 00 00 00 01 8D 01 00 ................
00 10 00 18 08 01 01 00 16 00 53 4E 5F 43 4F 4E ..........SN_CON
5F 51 45 56 5F 41 4C 4C 5F 42 41 53 49 43 5F 30 _QEV_ALL_BASIC_0
01 00 00 00 00 00 00 00 00 00 4C 53 01 00 A8 61 ..........LS...a
D9 98 73 44 7E 6F 02 C2 9B 8B AA 44 F6 E6 00 01 ..sD~o.....D....
00 F6 E6 00 00 00 00 00 00 80 41 00 00 48 42 00 ..........A..HB.
00 C8 42 00 03 00 47 41 4D 00 00 00 01 00 00 00 ..B...GAM.......
00 00 00 00 00 00 00 00 00 00 00 00 FF 53 00 20 .............S..
00 00 00 00 00 03 00 00 00 01 07 04 01 4A EA 03 .............J..
00 64 02 4A F0 03 00 64 03 4A EE 03 00 64 04 4A .d.J...d.J...d.J
F8 03 00 64 00 00 00 00 00 00 00 00 01 00 01 00 ...d............
00 ................

03/15/2022 19:48 bimbum*#6

Quote:

Originally Posted by Z E T S U

Could you elaborate on this with concrete examples?

this is a recall user packet

PHP Code:

[C -> S][7010] 11 00 ................ 09 00 ................ 41 75 74 6F 45 76 65 6E 74 AutoEvent.......

as Bimbum mentioned above
11 00 => WriteUint16() as it is a 2 bytes = 16 bits
09 00 => WriteUint16() as it is a 2 bytes = 16 bits (this is charname length i guess)

i mentioned that at the chat case its the string size so

Code:

09 00                                             ................
41 75 74 6F 45 76 65 6E 74                        AutoEvent.......

can be read as readascii
origin >

Code:

                UInt16 length = m_reader.ReadUInt16();
                byte[] bytes = m_reader.ReadBytes(length);

then you encode it. i dont think that would be something you would go through.
the second one you sent seems like some array if iam not wrong.
but as i told you if you just looking for parsed packets you can use any of released sources....
if you want to know what every byte represents and why sometimes this be character level for example and sometimes be hwanlevel then you would use x64debug and follow the packet

03/15/2022 19:52 Z E T S U#7

Quote:
Originally Posted by bimbum*
i mentioned that at the chat case its the string size so
Code:
09 00                                             ................
41 75 74 6F 45 76 65 6E 74                        AutoEvent.......
can be read as readascii

Yes I know that this case can read or write as Ascii but about
11 00 why the packet split into 11 writeuint8 and 00 writeuint8 not
WriteUint16

03/15/2022 20:02 bimbum*#8

Quote:

Originally Posted by Z E T S U

Yes I know that this case can read or write as Ascii but about
11 00 why the packet split into 11 writeuint8 and 00 writeuint8 not
WriteUint32

read the rest of the comment.
11 00 is 2 bytes = 16 bits
so it can be read as 8 8 or 16 at once
would recommend reading abit about binary and hexadecimal number systems

03/15/2022 21:04 DaxterSoul#9

Quote:

Originally Posted by Z E T S U

when i'm try to use this function nothing happened

PHP Code:

Packet packet = new Packet(0x7010); packet.WriteUInt16((byte)0x11); packet.WriteAscii(Message); this.Send(packet);

but in another source , it is working like that

PHP Code:

Packet packet = new Packet(0x7010); packet.WriteUInt8((byte)0x11); packet.WriteUInt8((byte)0); packet.WriteAscii(Charname); this.Send(packet);

as you noticed that he split 11 00 into WriteUint8() and 00 into another WriteUint8()

Both of your examples produce the same bytes "11 00 04 00 54 65 73 74" which works as intended.

However I see what you're trying to say.
Some people write the individual bytes to ensure byte ordering as seen in parsing. This is because they've tried directly turning the hex output into C# hexadecimal literal like this:

Code:

            Packet packet = new Packet(0x7010);
            packet.WriteUInt16(0x1100);
            packet.WriteAscii("Test");

The code above however will produce the following byte stream "00 11 04 00 54 65 73 74".
Why this happens is a little complicated to explain here but if you're interested you can read about it here.

Quote:

Originally Posted by Z E T S U

and another question this 0x3013 packet at the same line has more than 4 bytes
how I can differentiate between them in this case how could I choose what to use

I assume this is coming from edxAnalyzer. If not then it's simply because there is no auto parsing that tracks the read operations.

0x3013 belongs to what I call "[Only registered and activated users can see links. Click Here To Register...]".
The BEGIN and END packet's are usually swallowed by edxAnalyzer however you'll see a packet with the opcode "0000" after it.
This fake temporary packet is created by the client on _BEGIN and contains all data (if any) from the _BEGIN and all (possibly multiple) _DATA packets. It's handled upon receiving _END packet.

03/16/2022 01:26 Z E T S U#10

Quote:
Originally Posted by DaxterSoul
Both of your examples produce the same bytes "11 00 04 00 54 65 73 74" which works as intended.

However I see what you're trying to say.
Some people write the individual bytes to ensure byte ordering as seen in parsing. This is because they've tried directly turning the hex output into C# hexadecimal literal like this:
Code:
            Packet packet = new Packet(0x7010);
            packet.WriteUInt16(0x1100);
            packet.WriteAscii("Test");
The code above however will produce the following byte stream "00 11 04 00 54 65 73 74".
Why this happens is a little complicated to explain here but if you're interested you can read about it here.

I assume this is coming from edxAnalyzer. If not then it's simply because there is no auto parsing that tracks the read operations.

0x3013 belongs to what I call "[Only registered and activated users can see links. Click Here To Register...]".
The BEGIN and END packet's are usually swallowed by edxAnalyzer however you'll see a packet with the opcode "0000" after it.
This fake temporary packet is created by the client on _BEGIN and contains all data (if any) from the _BEGIN and all (possibly multiple) _DATA packets. It's handled upon receiving _END packet.

Thank you so much , I got the idea