Question on using packet sniffers
Page 1 of 2 12 LastLast
Results 1 to 10 of 18

Thread: Question on using packet sniffers

  1. #1
    Member
    Join Date
    Dec 2002
    Posts
    86

    Question on using packet sniffers

    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?

  2. #2
    Banned
    Join Date
    Jul 2002
    Posts
    877
    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.

  3. #3
    Member
    Join Date
    Dec 2002
    Posts
    86
    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

  4. #4
    Jaded Network Admin nebulus200's Avatar
    Join Date
    Jun 2002
    Posts
    1,356
    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

    There is only one constant, one universal, it is the only real truth: causality. Action. Reaction. Cause and effect...There is no escape from it, we are forever slaves to it. Our only hope, our only peace is to understand it, to understand the 'why'. 'Why' is what separates us from them, you from me. 'Why' is the only real social power, without it you are powerless.

    (Merovingian - Matrix Reloaded)

  5. #5
    Member
    Join Date
    Dec 2002
    Posts
    86
    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

  6. #6
    Jaded Network Admin nebulus200's Avatar
    Join Date
    Jun 2002
    Posts
    1,356
    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
    There is only one constant, one universal, it is the only real truth: causality. Action. Reaction. Cause and effect...There is no escape from it, we are forever slaves to it. Our only hope, our only peace is to understand it, to understand the 'why'. 'Why' is what separates us from them, you from me. 'Why' is the only real social power, without it you are powerless.

    (Merovingian - Matrix Reloaded)

  7. #7
    Senior Member
    Join Date
    Jun 2002
    Posts
    394

    meh

    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.
    Hmm...theres something a little peculiar here. Oh i see what it is! the sentence is talking about itself! do you see that? what do you mean? sentences can\'t talk! No, but they REFER to things, and this one refers directly-unambigeously-unmistakably-to the very sentence which it is!

  8. #8
    Senior Member
    Join Date
    Dec 2002
    Posts
    110
    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.

  9. #9
    Member
    Join Date
    Dec 2002
    Posts
    86

    Re: meh

    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 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.

  10. #10
    Senior Member
    Join Date
    Dec 2002
    Posts
    110
    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)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •