VKernel.co.uk – Your interface to the world

Packet Capture – Size manipulation

Splitting a very large packet capture

If a packet capture is over a certain file size, i.e. 300Mb+, it may be beneficial for processing / distribution purposes to split it into smaller chunks. You can do this using the “editcap” Wireshark command.

(For Windows) – Firstly, copy the packet capture to your “C:\Program files\Wireshark” folder. Then use the “capinfos -c” command on the packet capture to find out how many packets it contains, as below:

C:\Program Files\Wireshark>capinfos -c samplepacketcapture.cap
File name: samplepacketcapture.cap
Number of packets: 1070031

As we have 1,070,031 packets, it may be beneficial to split them into pcaps of 50,000 each:

C:\Program Files\Wireshark>editcap -c 50000 samplepacketcapture.cap

When the command has completed succesfully, there will be an amount of small .cap files in the same directory of 50,000 packets each.

Merging lots of packet captures into a single Pcap

Sometimes we may wish to merge multiple packet captures i.e. 4-5 100Mb Packet Captures into a single one for analysis and to remove errors such as “Ack received for unknown packet” etc. To do this, (For Windows) – Firstly, copy the packet capture to your “C:\Program files\Wireshark” folder. Then, we can use the “mergecap.exe” program, similar to how editcap works.

C:\Program Files\Wireshark\mergecap.exe -w master-cap.cap subcap1.cap
subcap2.cap subcap3.cap

In this command, we are merging subcap1 – subcap3 into a few file, called master-cap.cap.

Thats all there is to it. For references, some useful operators are:

Usage: mergecap [options] -w <outfile>|- <infile> ...
Output:
 -a                concatenate rather than merge files.
                   default is to merge based on frame timestamps.
 -s <snaplen>      truncate packets to <snaplen> bytes of data.
 -w <outfile>|-    set the output filename to <outfile> or '-' for stdout.
 -F <capture type> set the output file type; default is libpcap.
                   an empty "-F" option will list the file types.
 -T <encap type>   set the output file encapsulation type;
                   default is the same as the first input file.
                   an empty "-T" option will list the encapsulation types.
 -h                display this help and exit.
 -v                verbose output.

TCP: Establishing A Connection

Now, In my previous post I talked about TCP’s “three way handshake” while realising i hadnt actually written a basic introductory blog about it for people who arent as in-tune with the way of the packet yet

Basically, to establish a TCP connection, you will need 4 things:
1. A Destination IP Address
2. A port on that Destination IP Address
3. A Source IP Address
4. A port on that Source IP Address

As you may be aware, an IP Address with a port listening on it is referred to as a “Socket”; for example 192.168.1.1:80 is a socket, listening on port 80 typically means this is a HTTP Server.

To establish a TCP connection, you need 2 sockets to be able to talk to each other in order to initiate what is known as a “flow”; think of it as a 100m running track, its a straight line with 2 points, a start and a finish. If you dont have a start you cant send anything, if you dont have a finish it’ll never get there.

This “flow” between the 2 sockets is why TCP is typically referred to as a connection oriented protocol, as opposed to UDP which is referred to as connection less.

Anyway, before I digress too far from the crux of the matter: In order to establish a connection to transmit “data” over, you must first complete the three way handshake between the 2 sockets. This 3 way handshake consists of two vital flags used in a TCP conversation:

1. SYN (Synchronise)
2. ACK (Acknowledgement)

In the first stage, the Client (Establisher) sends a TCP SYN control segment to the Server (Recipient). This is the first stage of the handshake.

The Server receives this SYN, and in turn sends a SYN-ACK to the client. This ACK confirms Server has recieved the SYN, and in turn he has sent out his own SYN to synchronise with the client. This is the second stage of the three way handshake.

Finally, the client receives the SYN-ACK, and knows that Server got his SYN so he is good to receive communications. Client responds with an ACK to the Servers SYN, saying that he confirms the SYN packet sent by Server. This is the third and final stage of the handshake. Once this is done, it is said that a TCP Connection is “Established”.

To give this a metaphorical twist; Joe wants to communicate with Harry over a two-way radio. To ensure that Harry is listening on his send frequency, Joe shouts “Hello can you hear me?” down the radio (Stage 1, SYN).
On hearing this, Harry answers with “Yes, Can you hear me?” (ACKnowledges Joes original transmission, and sends a SYN of his own).
Finally, Joe knows Harry is listening as he has confirmed his question (ACK’d), so Joe answers Harrys question (SYN) with a “Yes” (ACK). It can now be said that Joe and Harry in an established communication.

Now, you may ask – what is being done in this SYN stage? Well, technically they are allocating buffer sizes, synchronising sequence numbers and various other variables. You can think of it using the metaphor as they are tweaking the frequency in which they are going to communicate on.

For further background information, there is a very good introductory page here:

http://www.inetdaemon.com/tutorials/internet/tcp/3-way_handshake.shtml

It has some good graphics, etc which help convey the concept.

Hope this helps!
Sam

Tags: Connection, Flow, Socket, TCP

Newsrip: Windows Vista/Windows 7 SMB 2.0 Remote BSOD

Found this article via Matts twitter. Basically, by modifiying code in the SMB 2.0 to have a “&” char in the “Process Id High” SMB header field, the remote client you are “attacking” if you will dies with :

“# PAGE_FAULT_IN_NONPAGED_AREA from socket import socket”.

This is very worrying for all you going out buying Windows 7 at the moment! Read the whole article here. Great work by whoever found it.

http://seclists.org/fulldisclosure/2009/Sep/0039.html