windows internet programming part 3.html

黑客培训教程

    			  SYN:  Synchronize sequence numbers.
    			  FIN:  No more data from sender.

8.  Window		- Specifies the maximum size of a segment that you can
			  accept, if the segment is larger than this then it
			  must be fragmented.

9.  Checksum		- The TCP checksum just like we explained with the IP
			  header, is to ensure that there is no loss of Data
			  during transport, it gets the size of the packet and
			  when it gets to the host the host compares the size
			  of the packet with the value of the checksum and if
			  they dont match you can see the packet was mangled
			  during transport.

			  The TCP Checksum is calculated using a psuedo header
			  which is prefixed to the TCP Header. The purpose of
			  this Psuedo Header is to protect the TCP packet from
			  misrouted segments. The Psuedo Header contains 4
			  main pieces of information, the Source IP, the
			  Destination IP numbers, the protocol and the TCP
			  length.


   			  +-----------------------------------+
   			  |           Source Address          |
   			  +-----------------------------------+
   			  |         Destination Address       |
   			  +--------+--------+--------+--------+
   			  |  zero  |  PTCL  |    TCP Length   |
   			  +--------+--------+--------+--------+

			  FIG 1.3  - The structure of a Psuedo Header


			  The TCP Length field is the length of the TCP Header
			  + length of the Data and does not count the length of
			  the Psuedo Header (12 Bytes).

10. Urgent Pointer	- This field is only to be set when the URG control bit
			  is set. It points to a Data area.

11. Options		- The TCP options field is very similiar to the IP Options
			  field except it has fewer interesting parts that need
			  to be mentioned here...  none.

12. Padding		- The same as the IP Padding Field.




3.3 THE UDP HEADER
=======================================

   +---------------------------------+--------------------------------+
   |          Source Port            |       Destination Port         |
   |            16 bits              |           16 bits              |
   +---------------------------------+--------------------------------+
   |            Length               |           Checksum             |
   |            16 bits              |           16 bits              |
   +---------------------------------+--------------------------------+

   FIG 1.4  - The Structure of a UDP Header

The UDP Header is more basic than previous Headers, it has only 4 fields.

1. Source Port
2. Destination Port
3. Length
4. Checksum


1.  Source Port		- Same as in TCP.

2.  Destination Port	- Same as in TCP.

3.  Length		- The length of the Datagram, including UDP Header and
			  Data. Size must be at least 8.

4.  Checksum		- Same as TCP this field protects against misrouted packets
			  it also uses the same Psuedo Header as TCP.



3.4 THE ICMP HEADER
=======================================

   +----------------+----------------+--------------------------------+
   |      Type      |     Code       |           Checksum             |
   |     8 bits     |    8 bits      |           16 bits              |
   +----------------+----------------+--------------------------------+
   |                              Unused                              |
   |                              32 bits                             |
   +------------------------------------------------------------------+
   |            Internet Header + 64 bits of Original Data            |
   |                              32 bits                             |
   +------------------------------------------------------------------+

   FIG 1.5  - The Standard Structure of an ICMP Header

The ICMP Header changes depending on the message it is sending. Different
ICMP Messages are conveyed by combinations of different values and the
Unused Field can contain different values and become used depending upon
the different ICMP messages being sent. For example in some messages you
may need to specify the general Type of message and then its code, this
certain message may require additional information such as the IP Address
of a computer, this address would then be stored in the Unused Field.

The ICMP protocol is similiar to UDP in that it is used in messages of 1
Datagram in size, however, ICMP is more like an extension of IP and certain
fields must also be set for use with ICMP.


The Standard ICMP Header has 4 main fields.

1. Type
2. Code
3. Checksum
4. Unused


1.  Type		- Field declaring the type of ICMP Message.

2.  Code		- Field specifying the messages code to identify its
			  meaning.

3.  Checksum	- Calculated the same as other headers, the kernel may pad
			  this if the checksum is an odd number to respect 32 bit
			  boundaries in most ICMP messages but Checksum is not
			  calculated in some ICMP Messages.

4.  Unused	- The value of this field varies depending on the type of
			  ICMP message, if no value is to be entered in this field
			  it must be specified as 0.


There are several different ICMP messages but here we are only going to refer
to the 2 most interesting types Echo and Netmask request and reply's.

======================
Echo Request and Reply
======================

Description:

These two ICMP Messages are commonly used in conjunction to form
the ping program. First we send an Echo Request to a host and
that host then sends us an echo reply. By sending multiple requests
to a host and comparing the time they were sent with the time that
the Echo Reply was recieved we can calculate the mean time that
packets are sent between us and that host. This Message is also
useful to determine whether a host is reachable and connected to the
internet or not.

Data can be inserted into an Echo request, perhaps for checking
the integrity of a packet which it is returned?


Type:

Echo Request	= 8
Echo Reply 	= 0


Code:

Field Unused	= 0


Checksum:

As specified above.


Identifier:

Same as the IP Identifier, useful to determine which ICMP Echo Reply
belongs to which Echo Request.


Sequence Number:

Used in the same way as the Identifier is above, useful for matching
Echo Reply's with Requests.

====================================================================

=========================
Netmask Request and Reply
=========================

Description:

We can send a netmask request to a host and it will return a netmask
reply containing its subnetmask, getting subnetmasks is useful for
mapping out and gathering information on network topology.


Type:

Netmask Request	= 17
Netmask Reply	= 18


Code:

Field Unused	= 0


Checksum:

Same as above.


Identifier:

Same as the IP Identifier, useful to determine which ICMP Netmask
Reply belongs to which Netmask Request.


Sequence Number:

Used in the same way as the Identifier is above, useful for matching
Netmask Reply's with Requests.

====================================================================



4.0 CREATING A PACKET
=======================================

OK well thats enough Protocol Header theory, lets look at how we are
going to construct a raw socket in code and the differences between
coding raw sockets and normal windows sockets code.

Now with normal Sockets we give certain information to the stack in
the case of windows, the Winsock. This information comprises of things
like what transport layer were gonna use, TCP or UDP, the address of
the host we are going to send it to, the port for it to go to, the
Data to be contained within the Datagram, we name the socket call
the sendto() function and off it goes. What we should consider now
is what then happens to the information that we just provided, we know
how the IP protocol sends it off zooming across the internet and how
the host handles and sends this Data, but what happens inbetween the
time we called sendto() and the time that packet leaves our computer?

Well we passed this information to the winsock, the winsock then
takes information such as the Destination address and our own address
along with the protocol we specified and fills out the relevant
fields in the protocol header, it then sets the TTL with its own
default value of 35.

Then the winsock uses the other information we provided, the source
and destination port numbers, and fills the relevant TCP or UDP
Header fields, and constructs the header, wraps the headers around
the Data we specified and calculates things such as fragmentation
and fills in the fields. Once everything is filled out and wrapped
up the winsock calculates the size of the packet and specifies the
checksum value.

With all this done the winsock sends the packet off to whiz around
the internet.

So with normal sockets we dont have to specify all those nasty fields
in the Headers we leave it up to good ol' winsock and it handles that
but we want to create our own headers so how do we stop the winsock
from prefixing its headers onto our packet?


4.1 SETSOCKOPT()
=======================================

The setsockopt() function is very important in raw sockets, its here
that we tell the winsock that we want to use our own headers for this
packet and for it to not add its own to ours.

The setsockopt() function has 5 parameters:

1. Socket
2. Level
3. Option Name
4. Option value
5. Option Length


1. Socket		- Just like in normal sockets this is a Socket
		 	  that we made earlier in the program.

2. Level		- This is the protocol we are going to be using
		 	  in the program, it has values such as
		 	  IPPROTO_TCP and IPPROTO_IP.

3. Option Name		- The socket option we are going to set, we will
			  be setting this to IP_HDRINCL, this option is
			  what tells the winsock we want to include our
			  own headers for the packet.

4. Option Value		- Pointer to the buffer in which the value for
			  the requested option is supplied. We will be
			  using a boolean called bOpt set to true for
			  this, set to false would mean that we dont want
			  to use the IP_HDRINCL option.

5. Option Length	- The size of the buffer which supplies the
			  value. We will use sizeof(bOpt) for this.


The setsockopt() function well be looking at so will look like this:

setsockopt(myraw, IPPROTO_IP, IP_HDRINCL, (char *)&bOpt, sizeof(bOpt)


So now how do we tell the winsock that we want to use raw sockets
instead of normal sockets in the first place?


4.2 SOCKET()
=======================================

Of course weve already covered the socket() function in the past and
are familiar with its different parameters but what we have to be
concerned about two of its parameters, its type and protocol.

A normal socket looks like the following:

socket(AF_INET, SOCK_STREAM, 0)

Before we used to set its type as SOCK_STREAM or SOCK_DGRAM for TCP
and UDP respectively. In raw sockets however we will set the type
parameter to SOCK_RAW and the protocol to IPPROTO_RAW.

A Raw Socket looks like this:

socket(AF_INET, SOCK_RAW, IPPROTO_RAW);

So thats how we tell the winsock that its a raw socket that we will
be using which still leaves the question how do we build the actual
header?