Question on using packet sniffers

[ratman3]

hey Guys,
I just used Google and got myself a nice packet sniffer for free but I've always had problems decoding the packets themselves. Even in text mode the packets look like garbage and not something I can use. How do I fix this?

[|The|Specialist]

Well as you probably already know... The code is converted when it comes out of one PC then goes through a connection and is caught on the other end. I really don't see anything that you can do except complain to the peaple who made the program or try and cypher it yourself.

Maybe if you stumble around google for awhile you can find the answers your looking for or maybe even find a update for your sniffer.

[ratman3]

Originally posted here by |The|Specialist
Well as you probably already know... The code is converted when it comes out of one PC then goes through a connection and is caught on the other end. I really don't see anything that you can do except complain to the peaple who made the program or try and cypher it yourself.

Maybe if you stumble around google for awhile you can find the answers your looking for or maybe even find a update for your sniffer.

Correction: some of the code you can see in English but not all here is a screenshot of one packet that didn't get translated

[nebulus200]

Ok, this is a little hard for me to tell exactly what is going on, but, the line you have highlighted there I would suspect is not the beginning of the actual trace (the packet flags are Syn-Ack, which means that it is either the continuation of a conversation or an acknowledgement to a connection request (syn)). There may or may not have been useful information in that packet.

I am also not very familiar with the ports in use there so it is a little difficult for me to determine which direction the traffic is actually flowing (aside from trusting the sniffer, which sometimes is a bad thing). A quick google search turned up 7779 is oracle http web listener and 3099 is something to do with core, would guess 7779 is probably the destination port, which would fit nicely with the syn-ack response packet.

Now, on to the actual contents of the packets (the contents are actually quite small, so kinda makes me wonder why the packets are so small). The garbly gook means that the data is binary, this could be because it is encrypted or because the data is actually binary. In the case of the data being binary (or even if you have the proper encryption keys), the only way you would be able to decode it (aside from being pretty damn talented) would be to have a more capable decoding program (I know NAI sniffer pro can decode alot of protocols, and I am wanting to say ethereal can even do some as well).

You have also not really said what you are trying to do with the packet trace, so I will leave the discussion at that. Get a sniffer that understands the protocol on top (perhaps if the protocol isn't proprietary you could even decode it yourself), application layer is at layer 7 network/transport at 3/4 hence 'on top', and you will have your answer.

Hope that is at least helpful,

nebulus

EDIT: protocol is proprietary --> protocol isn't proprietary

EDIT 2: Also, in future when you post packet traces, it is a really really really good idea to completely obscure all addresses in question, aside from distinguishing that they are different address.

EDIT 3: Binary Data. When your sniffer tries to display contents of a packet, it takes the hex byte code and tries to print whatever the ascii equivelent is (it has been a really long time since I thought aobut this, having weird flashbacks to BASIC). So lets say you get a hex byte value of 41, it would print out in the decode side as 'A' and the byte code of 7a woudl print out as 'z'. Since binary code would just appear as a random sequence of byte codes, the output in ASCII will likewise look foreign or unclear. A good reference for converting ASCII from decimal/hex/oct/bin is at : http://claymore.engineer.gvsu.edu/~j...refer-143.html

[ratman3]

Originally posted here by nebulus200
Ok, this is a little hard for me to tell exactly what is going on, but, the line you have highlighted there I would suspect is not the beginning of the actual trace (the packet flags are Syn-Ack, which means that it is either the continuation of a conversation or an acknowledgement to a connection request (syn)). There may or may not have been useful information in that packet.

I am also not very familiar with the ports in use there so it is a little difficult for me to determine which direction the traffic is actually flowing (aside from trusting the sniffer, which sometimes is a bad thing). A quick google search turned up 7779 is oracle http web listener and 3099 is something to do with core, would guess 7779 is probably the destination port, which would fit nicely with the syn-ack response packet.

Now, on to the actual contents of the packets (the contents are actually quite small, so kinda makes me wonder why the packets are so small). The garbly gook means that the data is binary, this could be because it is encrypted or because the data is actually binary. In the case of the data being binary (or even if you have the proper encryption keys), the only way you would be able to decode it (aside from being pretty damn talented) would be to have a more capable decoding program (I know NAI sniffer pro can decode alot of protocols, and I am wanting to say ethereal can even do some as well).

You have also not really said what you are trying to do with the packet trace, so I will leave the discussion at that. Get a sniffer that understands the protocol on top (perhaps if the protocol isn't proprietary you could even decode it yourself), application layer is at layer 7 network/transport at 3/4 hence 'on top', and you will have your answer.

Hope that is at least helpful,

nebulus

EDIT: protocol is proprietary --> protocol isn't proprietary

EDIT 2: Also, in future when you post packet traces, it is a really really really good idea to completely obscure all addresses in question, aside from distinguishing that they are different address.

EDIT 3: Binary Data. When your sniffer tries to display contents of a packet, it takes the hex byte code and tries to print whatever the ascii equivelent is (it has been a really long time since I thought aobut this, having weird flashbacks to BASIC). So lets say you get a hex byte value of 41, it would print out in the decode side as 'A' and the byte code of 7a woudl print out as 'z'. Since binary code would just appear as a random sequence of byte codes, the output in ASCII will likewise look foreign or unclear. A good reference for converting ASCII from decimal/hex/oct/bin is at : http://claymore.engineer.gvsu.edu/~j...refer-143.html

I was going to use Ethereal but it will not run on dual processor boxes

[nebulus200]

As far as I know (which by far isn't everything), that leaves you with

a) fork over major $$$ on NAI Sniffer Pro

b) get a box, install linux. The problem with ethereal on two processor systems is a windows one (actually a limitation in winpcap). This would get around that problem, plus open up doors to many other sniffer and packet analyser programs.

IMHO, b is the easiest choice.


good luck whichever path you take, including the unseen one

/nebulus

[(V)/\><]

greetings,

you said that this software is new to you, so has it previously not decoded the packets, or is this portion some how special? perhaps the program has no decoder, none for this protocol or it is a raw socket connection. packets of this size are best viewed in hex.

however, E = 4500 hex so it is an ip version 4 with an internet header length of 5. pretty normal. it is using protocol 6, the '0' or 30 hex, or TCP in the transport layer, like the sniffer picks up. so perhaps not raw.

post the hex because there is no point in guessing the rest, check out the internet protocol rfc and the assigned numbers rfc might be useful also, so you can d.i.y. if you want.

[don]

Some words of advice. You are on a windows box so go and d/l either Ethereal if you are unfamiliar with tcp/ip which you say you are, and or go d/l windump and libpcap as well. Now
once you have done that paste a chunk here and I will break it "all" down for you. If you want
an intro go see my post on "Packet Crafting via Hping" in the tutorials section. I break a packet
down a little bit there.

[ratman3]

Originally posted here by (V)/\&gt;&lt;
greetings,

you said that this software is new to you, so has it previously not decoded the packets, or is this portion some how special? perhaps the program has no decoder, none for this protocol or it is a raw socket connection. packets of this size are best viewed in hex.

however, E = 4500 hex so it is an ip version 4 with an internet header length of 5. pretty normal. it is using protocol 6, the '0' or 30 hex, or TCP in the transport layer, like the sniffer picks up. so perhaps not raw.

post the hex because there is no point in guessing the rest, check out the internet protocol rfc and the assigned numbers rfc might be useful also, so you can d.i.y. if you want.

I should explain what I'm trying to do here:

I'm trying to use a sniffer to map a protocol so I can write code so I can make my own clients and/or use telnet to connect to a particular type of server. The particular protocol I'm trying to map out right now is the Parachat chatroom protocol but I can't translate it. Correct me if i'm wrong but aren't most client/server communications sent in plaintext unless encrypted (as in the SSH protocol)?

Here are some Parachat packets (in Hex):

Packet 1:

45 00 00 30 00 00 40 00 31 06 F4 E0 CF 2C C4 10
C0 A8 01 02 1E 63 0D 85 5B FE 4B CA 9F 71 F4 EF
70 12 16 D0 AF 45 00 00 02 04 05 B4 01 01 04 02

Packet 2:

45 00 00 28 53 96 40 00 31 06 A1 52 CF 2C C4 10
C0 A8 01 02 1E 63 0D 85 5B FE 4B CB 9F 71 F4 FF
50 10 16 D0 DB F9 00 00

Packet 3:

45 00 00 28 53 97 40 00 31 06 A1 51 CF 2C C4 10
C0 A8 01 02 1E 63 0D 85 5B FE 4B CB 9F 71 F5 DA
50 10 19 20 D8 CE 00 00

Packet 4:

45 00 00 5F 53 98 40 00 31 06 A1 19 CF 2C C4 10
C0 A8 01 02 1E 63 0D 85 5B FE 4B CB 9F 71 F5 DA
50 18 19 20 7F 10 00 00 3A 6C 6F 63 61 6C 68 6F
73 74 20 30 30 31 20 72 61 74 6D 61 6E 20 3A 20
57 65 6C 63 6F 6D 65 20 74 6F 20 74 68 65 20 50
61 72 61 43 68 61 74 20 53 65 72 76 65 72 0A

Packet 5:

45 00 02 D4 53 99 40 00 31 06 9E A3 CF 2C C4 10
C0 A8 01 02 1E 63 0D 85 5B FE 4C 02 9F 71 F5 DA
50 18 19 20 C1 70 00 00 3A 6C 6F 63 61 6C 68 6F
73 74 20 30 30 32 20 72 61 74 6D 61 6E 20 3A 20
53 65 72 76 65 72 20 69 73 20 72 75 6E 6E 69 6E
67 20 76 34 2E 30 31 0A 3A 6C 6F 63 61 6C 68 6F
73 74 20 30 30 34 20 72 61 74 6D 61 6E 20 6C 6F
63 61 6C 68 6F 73 74 20 50 61 72 61 43 68 61 74
2D 34 2E 30 31 20 62 20 6F 0A 4E 4F 54 49 43 45
20 72 61 74 6D 61 6E 20 3A 2A 2A 2A 20 76 34 2E
30 31 0A 4E 4F 54 49 43 45 20 72 61 74 6D 61 6E
20 3A 2A 2A 2A 20 4E 6F 74 69 63 65 20 2D 2D 20
28 63 29 20 31 39 39 36 2C 20 31 39 39 37 2C 20
31 39 39 38 20 31 39 39 39 20 4D 20 53 71 75 61
72 65 20 49 6E 63 2E 20 68 74 74 70 3A 2F 2F 77
77 77 2E 70 61 72 61 6C 6F 67 69 63 2E 63 6F 6D
2F 0A 3A 6C 6F 63 61 6C 68 6F 73 74 20 33 37 35
20 72 61 74 6D 61 6E 20 3A 20 4D 65 73 73 61 67
65 20 6F 66 20 74 68 65 20 64 61 79 0A 3A 6C 6F
63 61 6C 68 6F 73 74 20 33 37 32 20 72 61 74 6D
61 6E 20 3A 20 28 63 29 31 39 39 36 2D 32 30 30
32 20 4D 20 53 71 75 61 72 65 20 49 6E 63 2E 20
5B 20 68 74 74 70 3A 2F 2F 77 77 77 2E 50 61 72
61 43 68 61 74 2E 63 6F 6D 20 5D 20 76 34 2E 30
31 0A 3A 6C 6F 63 61 6C 68 6F 73 74 20 33 37 32
20 72 61 74 6D 61 6E 20 3A 20 20 0A 3A 6C 6F 63
61 6C 68 6F 73 74 20 33 37 36 20 72 61 74 6D 61
6E 20 3A 20 45 6E 64 20 6F 66 20 4D 65 73 73 61
67 65 20 6F 66 20 74 68 65 20 64 61 79 0A 50 61
72 61 43 68 61 74 20 63 68 61 74 0A 3A 72 61 74
6D 61 6E 20 20 4A 4F 49 4E 20 23 42 53 42 5F 50
48 45 4E 4F 4D 45 4E 4F 4E 5F 43 48 41 54 0A 3A
6C 6F 63 61 6C 68 6F 73 74 20 33 33 32 20 72 61
74 6D 61 6E 20 23 42 53 42 5F 50 48 45 4E 4F 4D
45 4E 4F 4E 5F 43 48 41 54 20 3A 57 65 6C 63 6F
6D 65 20 74 6F 20 6F 75 72 20 46 72 65 65 20 50
61 72 61 43 68 61 74 20 52 6F 6F 6D 21 0A 3A 6C
6F 63 61 6C 68 6F 73 74 20 33 35 33 20 72 61 74
6D 61 6E 20 3D 20 23 42 53 42 5F 50 48 45 4E 4F
4D 45 4E 4F 4E 5F 43 48 41 54 20 3A 20 72 61 74
6D 61 6E 20 0A 3A 6C 6F 63 61 6C 68 6F 73 74 20
33 36 36 20 72 61 74 6D 61 6E 20 23 42 53 42 5F
50 48 45 4E 4F 4D 45 4E 4F 4E 5F 43 48 41 54 20
3A 45 6E 64 20 6F 66 20 2F 4E 41 4D 45 53 20 6C
69 73 74 0A 52 4F 4F 4D 20 73 69 74 65 72 6F 6F
6D 73 20 0A

Now guys, am I missing something here or should this not tell me what is sent back and forth between the client and sever and allow me to login via telnet or my own program? The Parachat protocol is supposed to be based off or IRC and is definately not encrypted.

[don]

The only thing that is sent plaintext is the ascii breakout. That is there so we humans can interpret the machine language. That is the only reason. Think tcpdump usage here --->
tcpdump -nXvs 0 ip and host

tcpdump ---> the program of course
n ---> don't resolve to canonical names (keep it in numerica format)
X ---> dump it in ascii format as well
v ---> verbose mode (show ip header info as well)
s ---> snap length (ethernet is default of 1500)