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?
Printable View
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?
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 translatedQuote:
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.
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 :(Quote:
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
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
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.
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.
I should explain what I'm trying to do here:Quote:
Originally posted here by (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.
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.
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)
so in other words tcpdump tranlates the hex into text I can use?Quote:
Originally posted here by 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)
in other words, it will give you the same "text" that you have in the text section of the sniffer program that you are using. any binary that can be grouped into 7, but normally 8 bits can be viewed as ascii. tcpdump does not do any translating. it captures in binary and can group the binary digits together into bytes (8bits) words (16bits) or long words (32bits).
each single digit takes up four binary bits
45 00 00 30 00 00 40 00 31 06 F4 E0 CF 2C C4 10 (bytes)
4500 0030 0000 4000 3106 F4E0 CF2C C410 (words)
45000030 00004000 3106F4E0 CF2CC410 (long words)
http://www.asciitable.com to see how this is simple mapped onto ascii characters. the disadvantage of viewing this "text" is that alot of characters will not be displayed, or will be displayed like ¡ö or ▐ or ¨€ because they might be special characters, null, ack, line feed. viewing the packet data in hex allows you to see everything.
by text you can use, you mean what?Quote:
so in other words tcpdump tranlates the hex into text I can use?
You got it baby! Well the payload portion of it. You will still have to xlate the hex if ya wanna
the other info ie: ip hdr stuff.
has anyone checked out www.ngsec.com and looked for their tool section, their ngsniff seems to do a decent job... decodes the headers, then give you the hex and ascii payload..
only got it like 5 minutes ago, but looks pretty usable..
In other words I want to be able to sniff protocol x and then be be able to use protocol x via telnetQuote:
Originally posted here by (V)/\><
in other words, it will give you the same "text" that you have in the text section of the sniffer program that you are using. any binary that can be grouped into 7, but normally 8 bits can be viewed as ascii. tcpdump does not do any translating. it captures in binary and can group the binary digits together into bytes (8bits) words (16bits) or long words (32bits).
each single digit takes up four binary bits
45 00 00 30 00 00 40 00 31 06 F4 E0 CF 2C C4 10 (bytes)
4500 0030 0000 4000 3106 F4E0 CF2C C410 (words)
45000030 00004000 3106F4E0 CF2CC410 (long words)
http://www.asciitable.com to see how this is simple mapped onto ascii characters. the disadvantage of viewing this "text" is that alot of characters will not be displayed, or will be displayed like ¡ö or ▐ or ¨€ because they might be special characters, null, ack, line feed. viewing the packet data in hex allows you to see everything.
by text you can use, you mean what?
I don't know if this will help too much, i like to visualize things...
http://www.erg.abdn.ac.uk/users/gorr.../ip-header.gif
http://www.erg.abdn.ac.uk/users/gorr...ip-packet.html
The easiest thing for you is probably to load up Ethereal. It does a nice job of simplifying
things.
I'll play with Etherreal on the laptop later