A packet forensics challenge - Page 4
Page 4 of 4 FirstFirst ... 234
Results 31 to 38 of 38

Thread: A packet forensics challenge

  1. #31
    Senior Member
    Join Date
    Dec 2002
    Posts
    110
    Str43m3r, the r@p means nothing. It is empty ascii. It alludes to nothing vis a vis an ip addy.

  2. #32
    Senior Member
    Join Date
    Mar 2002
    Posts
    425
    The characters r@J are tcpdumps attempt to turn the corresponding bytes into ascii characters. It only displays characters that are displayable ascii, everything else gets a '.' So in other words, by leaving the r@J to the right, we can still figure out what the bytes on the left were (the one's you changed to x's). So unless you changed the r@J to throw us off, the source IP address was ??.114.64.74. Am I right?

  3. #33
    Senior Member
    Join Date
    Dec 2002
    Posts
    110
    Hmmm, crap I did not know that! Thanks for the tip. The ip addy you have is wrong though.
    The first two octets are correct, the last two are not however :-)

  4. #34
    Junior Member
    Join Date
    Feb 2003
    Posts
    2

    If I recall...

    If I recall my system was set at 4096. It has a gigabit enabled motherboard. That would maybe show that the computer is a windows based computer. Sorry if this doesn't help, just thought I would throw that out there.


    - Symbolic

  5. #35
    Member
    Join Date
    Dec 2001
    Posts
    35
    Str34m3r,
    Let me see if I understand your post correctly. The r@j in the fields on the right hand side are tcpdumps attempt to correlate the hex information to a readable format. By converting those characters to thier ascii numbers, then to hex it gives you the ip address. Im not quite sure that I understand how you accomplished this. And thanks for the detailed breakdown of the packet. I am currently pouring over it repeatedly to make sure I understand everything.

    10Ded
    [glowpurple]www.networksynapse.net[/glowpurple]

  6. #36
    Member
    Join Date
    Dec 2001
    Posts
    32
    This is by far one of the most informative posts I have seen anywhere. Rock on dudes.
    Bolt actions speak louder than words.

  7. #37
    Senior Member
    Join Date
    Dec 2002
    Posts
    110
    02:07:15.196281 xxx.xxx.xxx.xxx.50464 > xxx.xxx.xxx.xxx.929: S [tcp sum ok] 878999699:878999699(0) win 4096 (ttl 41, id 20442, len 40)
    0x0000 4500 0028 4fda 0000 2906 6ba6 xxxx xxxx E..(O...).k..r@J
    0x0010 xxxx xxxx c520 03a1 3464 7893 0000 0000 ........4dx.....
    0x0020 5002 1000 53d9 0000 0233 3503 3xxx P...S....35.11

    02:07:15:196281 This is the time the packet was sent right down to the microsecond
    xxx.xxx.xxx.xxx This is the source ip address
    50464 This is the source port (this is an ephemeral port ie: a port above 1024)
    > This is a director showing who is talking to who
    xxx.xxx.xxx.xxx This is the destination ip address
    929 This is the destination port, this is not an ephemeral port ie: it is under 1025
    S This denotes it is a syn packet ie: the first step of a tcp/ip 3 way handshake
    [tcp sum ok] This means the tcp sequence number is okay
    878999699:878999699 This is the tcp sequence #, used to identify the tcp datagram
    (0) This show how much data was sent in bytes ie: none cause this is only a syn packet
    win 4096 This shows the amount of buffered information the machine has to send
    ttl 41 This is the time to live before the packet is dropped
    id 20442 This is the ip datagram number, it is used to reassemble fragmented packets
    len 40 This is the length of the packet itself ie: 40 is right 20 for tcp 20 for ip

    You can infer a few things from some of the metrics above;
    win 4096 is normally associated with a windows box

    ttl 41 is normally associated with a *nix box as they are coded with a ttl of 64
    and windows is 128

    Beyond that the packet is showing normal behaviour in as much as there are illegal
    flag combinations ie: syn/fin/psh
    The tcp and ip headers are both 20 bytes which is normal.
    Remember a *lot* of information can be gleaned by the packet metrics. Whether or
    not a packet is spoofed and so on. Look to the packet before you all the answers
    are there.

    Hope this helps
    Don

  8. #38
    Senior Member
    Join Date
    Dec 2002
    Posts
    110
    Yo! 10ded did you read my post in this thread. The one that precedes this one. It breaks down all the fields. Take a look.

Posting Permissions

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

 Security News

     Patches

       Security Trends

         How-To

           Buying Guides