Page 5 of 5
Re: Packets: Reading and Understanding
Posted: Fri Apr 03, 2009 10:17 am
by 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?
Re: Packets: Reading and Understanding
Posted: Mon Apr 13, 2009 5:45 pm
by 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?
Re: Packets: Reading and Understanding
Posted: Mon Apr 13, 2009 6:17 pm
by Bion
the 5th byte in this case is the opcode... 2
Re: Packets: Reading and Understanding
Posted: Tue Apr 14, 2009 10:00 am
by DarkAlchemist
Bion wrote: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?
Re: Packets: Reading and Understanding
Posted: Tue Apr 14, 2009 4:45 pm
by LethalEncounter
DarkAlchemist wrote: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.
Re: Packets: Reading and Understanding
Posted: Tue Apr 14, 2009 7:10 pm
by 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.
Re: Packets: Reading and Understanding
Posted: Tue Apr 14, 2009 8:58 pm
by 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.
Re: Packets: Reading and Understanding
Posted: Tue Apr 14, 2009 10:06 pm
by 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
).
Re: Packets: Reading and Understanding
Posted: Tue Apr 14, 2009 10:21 pm
by 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
Re: Packets: Reading and Understanding
Posted: Wed Apr 15, 2009 3:30 pm
by LethalEncounter
Those packets did not come from the EQ2 packet collector and they are encrypted.
Re: Packets: Reading and Understanding
Posted: Wed Apr 15, 2009 4:25 pm
by DarkAlchemist
LethalEncounter wrote:Those packets did not come from the EQ2 packet collector and they are encrypted.
Thanks, that is all I needed to know.