February 19th, 2003, 08:35 PM
Str43m3r, the r@p means nothing. It is empty ascii. It alludes to nothing vis a vis an ip addy.
February 20th, 2003, 01:56 AM
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?
February 20th, 2003, 02:06 AM
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 :-)
February 20th, 2003, 04:30 AM
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.
February 20th, 2003, 01:27 PM
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.
February 20th, 2003, 02:08 PM
This is by far one of the most informative posts I have seen anywhere. Rock on dudes.
Bolt actions speak louder than words.
February 20th, 2003, 03:19 PM
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
Hope this helps
February 20th, 2003, 09:02 PM
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.