Packets: Reading and Understanding

[John Adams]

Thanks, paulgh. You seem to know more about this stuff than most. So why again are you not on one of our teams?

[DarkAlchemist]

Code: Select all

0000:	00 09 00 00 02 52 00 00 00 03 1E 0B CC 22 41 CA .....R......."A.
0010:	56 AE 40 AC F5 D4 0E 94 F9 16 7C 11 69 37 BC 46 V.@.......|.i7.F
0020:	92 BE D2 DB B9 AB 6F 8E 17 EA E4 8C E6 81 9A 76 ......o........v
0030:	EF 2F F1 B6 0C 99 1C 8C CD 14 6C 63 F3 A7 5C 50 ./........lc..\P
0040:	20 7C 9A 49 78 C6 14 00 1A F9 77 01 8F 4E 69 BC  |.Ix.....w..Ni.
0050:	C8 1C 3C DB 2A E0 7C F2 9A 26 FF 01 00 00 00 23 ..<.*.|..&.....#

I am seeing a ton of packets where the 5th byte is not a 0 or a 1 but could be anything. Has something changed with this byte?

[Bion]

the 5th byte in this case is the opcode... 2

[DarkAlchemist]

the 5th byte in this case is the opcode... 2

So, the 00 00 in the third and fourth bytes tells us to use

Code: Select all

EQProtocolPacket* newpacket = ProcessEncryptedData(p->pBuffer+3, p->size-3, OP_Packet);

or is there something I am missing?

[LethalEncounter]

Code: Select all

0000:	00 09 00 00 02 52 00 00 00 03 1E 0B CC 22 41 CA .....R......."A.
0010:	56 AE 40 AC F5 D4 0E 94 F9 16 7C 11 69 37 BC 46 V.@.......|.i7.F
0020:	92 BE D2 DB B9 AB 6F 8E 17 EA E4 8C E6 81 9A 76 ......o........v
0030:	EF 2F F1 B6 0C 99 1C 8C CD 14 6C 63 F3 A7 5C 50 ./........lc..\P
0040:	20 7C 9A 49 78 C6 14 00 1A F9 77 01 8F 4E 69 BC  |.Ix.....w..Ni.
0050:	C8 1C 3C DB 2A E0 7C F2 9A 26 FF 01 00 00 00 23 ..<.*.|..&.....#

I am seeing a ton of packets where the 5th byte is not a 0 or a 1 but could be anything. Has something changed with this byte?

This is part of the encryption process and is handled a little differently, do you have another example of a packet sent by the server where the 5th byte is not a 0 or 1? Client packets don't include this byte.

[DarkAlchemist]

I can go see but how do we know if it is correct or if it is encrypted or what?

Here is one with a d2 in the fifth byte position

Code: Select all

0000: 00 09 00 03 d2 b4 6a df b8 d7 d3 6d 5b d9 29 72   ......j....m[.)r
0010: 58 f2 cb 5d db 87 bb fc cc 05 40 cf 83 bd e0 a1   X..]......@.....
0020: a0 b3 36 3e 99 f6 e7 f7 84 c3 b9 37 43 a9 d0 96   ..6>.......7C...
0030: 38 8e a3 46 13 8f cd 37 48 84 c5 38 1d 44 52 1c   8..F...7H..8.DR.
0040: 11 d8 27 a8 82 99 86 d4 52 d4 7c 0c e0 ad dd 5c   ..'.....R.|....\
0050: 13 16 9e ad 8e 9f 8b 09 19 9f 9e 37 21 89 3c 41   ...........7!.<A
0060: 97 86 46 d3 14 c3 46 12 8b 1d 36 1d b2 3a e7 0e   ..F...F...6..:..
0070: cb 58 b8 ef 40 b5 26 e8 f2 20 bb 82 0b a4 99 a0   .X..@.&.. ......
0080: ce 6a 73 6c 98 d6 fc 0d 07 0d 0e 74 f2 70 30 46   .jsl.......t.p0F
0090: 90 b9 67 d1 5d 75 c7 cc 49 72 df e7 e9 91 9f a3   ..g.]u..Ir......
00a0: 5c 4e 56 04 7d 9d 65 45 26 e4 1a 88 f2 4c 9e 5b   \NV.}.eE&....L.[
00b0: 0c a9 e5 38 65 95 75 ea 2c 39 a4 82 f2 e1 39 44   ...8e.u.,9....9D
00c0: 0c 3c 69 ea fd f8 1d 13 e2 85 1a d0 6f 8c c7 7f   .<i.........o...
00d0: db d7 95 b0 8d fb 39 6d d2 14 39 89 55 fc ae ff   ......9m..9.U...
00e0: 2e 19 e3 92 58 15 1c 11 ce a9 a5 94 55 71 c1 e6   ....X.......Uq..
00f0: dd a3 6c a9 a0 f8 8a 7c fa a1 76 fe 2f 51 5d 32   ..l....|..v./Q]2
0100: b5 3a 85 4e 0e 43 5e 25 08 1f bf 97 44 08 9b de   .:.N.C^%....D...
0110: 16 34 ea bb 0c ec 66 54 d6 9a 74 23 82 64 cc 30   .4....fT..t#.d.0
0120: 35 d4 2c 3f 3c e3 70 0d 28 65 89 d4 8e a4 cf 8f   5.,?<.p.(e......
0130: 8a 8b 1f 59 1f 0c d1 5f 5e b8 76 de 07 25 e1 d7   ...Y..._^.v..%..
0140: 80 f6 96 22 47 66 97 e7 8e 50 4c aa f7 33 14 fd   ..."Gf...PL..3..
0150: c9 9e 3b dd 6b 70                                 ..;.kp

Here is one with a 65 in the fifth position

Code: Select all

0000: 00 09 00 31 65 62 49 62 34 d7 d8 67 00 27 11 19   ...1ebIb4..g.'..
0010: f4 67 4f fe 3b c0 5f f1 4b 40 34 87 14 78 2d 3d   .gO.;._.K@4..x-=
0020: ab d9 bf be 40 b6 b3 04 37 15 04 cf b6 f2 3c 3c   ....@...7.....<<
0030: c8 f0 9b 87 9f 19 c1 aa 7e b9 6a bd 75 60 65 31   ........~.j.u`e1
0040: fc 15 68 ce d6 ed e0 d7 70 50 90 47 ba a6 f2 3d   ..h.....pP.G...=
0050: 6d 9a fe 63 15 37 7f 36 a5 9b f7 b0 e1 8e ee cd   m..c.7.6........
0060: 35 0c f8 96 1f b3 bc e0 ca b6 5f 7f fc 69 7f 99   5........._..i..
0070: a8 97 b6 42 0c 8b 46 6e f6 90 c3 df 8d b6 8a 49   ...B..Fn.......I
0080: 1c ef 96 99 b3 db fe 62 2e dd a4 a1 81 6e d2 20   .......b.....n. 
0090: 05 cc ba 07 d6 9f 49 17 e9 14 e6 4d e2 7f 8a a6   ......I....M....
00a0: 55 5c a8 71 17 cf 97 34 44 62 1c 6d a6 c4 bf 87   U\.q...4Db.m....
00b0: 12 03 9f ab 97 db 35 e8 67 e1 c0 01 ed e0         ......5.g.....

So, this rule of the fifth byte being a 0 or a 1 meaning not compressed or compressed is not set in stone as I hardly ever see a 1 or a 0 in that fifth byte.

[Zcoretri]

DarkAlchemist
I reposted a section of the packet explanation and bolded parts in red. The compression byte will not always be in the same spot, depends on whether the collecter stripped some info.

Hope thats helps to explain what you are seeing.


1. The only type we are interested in is OP_Packet (09). This is the type that you need to look for inside of the packet log. However, Packet Collector will sometimes strip the 00 09 off depending on how the packet was sent.
2. The next 2 bytes in the packet is usually the sequence. The server and client use this to determine if a packet was lost and needs to be resent. Only again, depending on how the packet was sent, Packet Collector might strip this off.
3. The next byte is a 1 if it is compressed using zlib or a 0, if not.
4. Now we get to the opcode of the packet. This is what determines what type of packet we are looking at. There are a few rules for opcodes:
A. If the opcode is less than 255, it will be a single byte, however if the opcode is greater than 254, a 0xFF will be the first byte here, followed by the opcode which is now two bytes.
B. Once you have the opcode determined from the rules above it gets even more complicated. If the opcode is a OP_ClientCmdMsg (depending on the version number this value changes), then the next 4 bytes are the size of the packet, and finally the real opcode is listed just like in rule A.

[DarkAlchemist]

I am 100% sure the collector did not strip anything off of those packets I listed. I was never more sure in my life about something as this so I am grateful for that info but in this instance it doesn't apply (though I did not remember some of that info so thanks for the refresher ).

[Bion]

tbh those packets look to me like they are encrypted. i am not real sure but i can not pick out the opcode in them

[LethalEncounter]

Those packets did not come from the EQ2 packet collector and they are encrypted.

[DarkAlchemist]

Those packets did not come from the EQ2 packet collector and they are encrypted.

Thanks, that is all I needed to know.