Learning tcpdump

[Amadeus]

Ok, I thought that today I would finally take a shot at learning how packet sniffing was accomplished, and how you guys figured out offsets and packet structures.

So, I downloaded tcpdump, and after browsing through the documentation, tried this command:

tcpdump -i eth1 -N -vvv -X udp

Surprisingly enough, this made more sense than I thought it would when reading it. (Of course, I am assuming that EQ uses udp from my first couple attempts at packet sniffing, so let me know if that's wrong). Anyway, I wanted to ask a couple questions. Hopefully someone has time to answer a couple..and I hope they're not TOO stupid

-----------------------
1. Here was a typical packet:

16:48:08.192205 192.168.0.2.1119 > eqzone-63-24.3035:  [udp sum ok] udp 10 (ttl 128, id 12853, len 38)
0x0000   4500 0026 3235 0000 8011 7137 c0a8 0002        E..&25....q7....
0x0010   4025 968b 045f 0bdb 0012 4b5c 0004 d42b        @%..._....K\...+
0x0020   f94b fd1c 4240 4240 4240 4240 4240             .K..B@B@B@B@B@

Now...what the hell am I looking at? ..hehe. What does the '10' mean? (I notice that each packet has 'udp #' on it....this one happened to be 10).

2. Is each packet a 'structure' in everquest.h? In other words, was that packet I posted earlier a single structure, or can they be combined?

3. I've heard of taking 'packet dumps' and then comparing them with future packet dumps. What is the command syntax for this?

4. Are opcodes somewhere in this too?

....Anyway, I feel like a blind man roaming around in a room full of rocking chairs, but you have to start somewhere I guess and I can't find anyone willing to write a guide...so, here goes nothing.

Please don't laugh

[Amadeus]

hehe...wow, 118 views and no responses


I went to "The Arena" and did some more putzing around, and I'm fairly sure I know which packets are sending the "consider" message. However, the data (as posted above) never looks the same for comparison..so obviously I'm still doing something wrong

wtb howto with example...even a really simple one.

[tamasine]

snooped packets these days are almost totally (as far as i'm aware) opaque. ie they need decoding before they make sense. many are compressed, some are encrypted. some are fragmented. (snooped a shop-open a while back. saw no big packets, seq spat out a 20k 'packet' containing shop data)

there is however some structure to them. there's something that says how it's put together/where in the packet stream it is/how to decode it. if you work that bit out then you might start getting somewhere ;)

good luck!

(i would be very interested to know whether the big breaks in seq history were packet-disassembly, or code-disassembly.)

[e@tme]

I am also trying to work some bits and pieces out here...


My question is:

What is the best way to start decoding packets?

[showeqfan]

I always liked this one

http://www.ethereal.com/

[casey]

packet:

16:48:08.192205 192.168.0.2.1119 > eqzone-63-24.3035:  [udp sum ok] udp 10 (ttl 128, id 12853, len 38)
0x0000   4500 0026 3235 0000 8011 7137 c0a8 0002        E..&25....q7....
0x0010   4025 968b 045f 0bdb 0012 4b5c 0004 d42b        @%..._....K\...+
0x0020   f94b fd1c 4240 4240 4240 4240 4240             .K..B@B@B@B@B@

ipv4 header: (20 bytes long, as indicated by the low nibble of the first byte which is multiplied by 4, 5*4 = 20 bytes). Protocol is 11 (byte 0x9), so the data will be a udp packet. For other info about the header, look up its struct, and remember that network byte order is big endian.

16:48:08.192205 192.168.0.2.1119 > eqzone-63-24.3035:  [udp sum ok] udp 10 (ttl 128, id 12853, len 38)
0x0000   4500 0026 3235 0000 8011 7137 c0a8 0002        E..&25....q7....
0x0010   4025 968b xxxx xxxx xxxx xxxx xxxx xxxx        @%..._....K\...+
0x0020   xxxx xxxx xxxx xxxx xxxx xxxx xxxx             .K..B@B@B@B@B@

udp header, 8 bytes. just src and dest ports, length and a checksum.

16:48:08.192205 192.168.0.2.1119 > eqzone-63-24.3035:  [udp sum ok] udp 10 (ttl 128, id 12853, len 38)
0x0000   xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx        E..&25....q7....
0x0010   xxxx xxxx 045f 0bdb 0012 4b5c xxxx xxxx        @%..._....K\...+
0x0020   xxxx xxxx xxxx xxxx xxxx xxxx xxxx             .K..B@B@B@B@B@

udp data, this is the everquest data.

16:48:08.192205 192.168.0.2.1119 > eqzone-63-24.3035:  [udp sum ok] udp 10 (ttl 128, id 12853, len 38)
0x0000   xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx        E..&25....q7....
0x0010   xxxx xxxx xxxx xxxx xxxx xxxx 0004 d42b        @%..._....K\...+
0x0020   f94b fd1c 4240 4240 4240 4240 4240             .K..B@B@B@B@B@

[e@tme]

I am clear on the structure of the packet (ipv4, UDP header & data)

Do i need to uncompress / un-encrypt the payload (Everquest data) in order to understand what it is? If so, what is the method for doing the de-crypt/compress of that data?

My main sticking point is working out how the payload works out to be some meaningful struct placed into everquest.h etc.

[Thom_Merrilin]

Well, I'm not sure on how valid this info is, due to SEQ decode issues...

But if SEQ is still spitting out data the way it should, then I have a few opcodes to toss out. Keep in mind tho, without a proper decode... this has no effect on making SEQ work.(Yeah, I tried)

#define StartCastCode               0x0042
#define cSenseHeadingCode           0x0047
#define RemDropCode                 0x00bc
#define WearChangeCode              0x0103
#define cCursorItemCode             0x0148
#define MakeDropCode                0x08bd

My only hope is that this can somehow help those who work on the decode.

-Thom

[runner]

Greate thread

I also wanted to look around a little on the packets and this thread got me started.

Just hope someone culd confirm if i'm on the right way here or if im still clueless.

I went to an empty zone and started to fool around with casting spells and looked at the packets that came from the server.
this is what i found:

casting a spell , these three packets are comming from the server to my client , the last is comming when the spell ends.
I have markt under the bytes:
(m) for what seems to be some kind of message type
(c) for some kind of counter
(s) for bytes that seem to be static or the same in the packets
(z) for the bytes that have changed when i zoned and recast the spell
(?) for bytes that seem to constanly change.

On the second packet i have markt 4 bytes with in [] that seems to be the id of the spell.

02:12:20.677175 server.3375 > client.1762:  [udp sum ok] udp 10 (ttl 108, id 48776, len 38)
0x0000   4500 0026 be88 0000 6c11 be6e c76c 0357 E..&....l..n.l.W
0x0010   c0a8 4664 0d2f 06e2 0012 162f 0004 017a ..Fd./...../...z
                                       mmmm cccc
0x0020   4dc2 9525 1f54 0000 0000 0000 0000      M..%.T........
         cccc ???? ???? ???? ssss ssss ssss

02:12:20.870203 server.3375 > client.1762:  [udp sum ok] udp 22 (ttl 108, id 54664, len 50)
0x0000   4500 0032 d588 0000 6c11 a762 c76c 0357 E..2....l..b.l.W
0x0010   c0a8 4664 0d2f 06e2 001e b68f 1200 017b ..Fd./.........{
                                       mmmm cccc
0x0020   2dfc 014a 1901 c401 5a00 b80b 0000 8289 -..J....Z.......
         cccc cccc ssss zzss[ssss]ssss ssss ????
0x0030   aee7                                    ..
         ????

02:12:23.609050 server.3375 > client.1762:  udp 107 (ttl 108, id 24458, len 135)
0x0000   4500 0087 5f8a 0000 6c11 1d0c c76c 0357 E..._...l....l.W
0x0010   c0a8 4664 0d2f 06e2 0073 49e4 1200 017c ..Fd./...sI....|
                                       mmmm cccc
0x0020   2dfd 014b 46a8 785e c518 3c5e 2342 77c4 -..KF.x^..<^#Bw.
         cccc cccc ssss ssss ???? ???? ???? ????
0x0030   6620 3edf 7084 f108 a32d 0317 900d 0607 f.>.p....-......
         ??cc ssss sszz sszz ssss ssss ssss sssz
0x0040   989c 41d4 7310 0154 c4b2 14ac e039 483d ..A.s..T.....9H=
zz       ssss ssss ssss ssss ssss ssss ssss ssss
0x0050   aa8a                                    ..
zz       ssss

Thanks for any answer.
/Runner