Amazing Holes on Earth

Amazing Scary Holes on Earth!!
7 amazing holes

Apparently the largest ever hand-dug excavation in the world, this 1097 metre deep mine yielded over 3 tonnes of diamonds before being closed in 1914.
the amount of earth removed by workers is estimated to total 22.5 million tonnes.




Glory hole - Monticello dam
a glory hole is used when a dam is at full capacity and water needs to be drained from the resevoir.




This is the glory hole belonging to monticello dam in california and it ??s the largest in the world, its size enabling it to consume 14 ??400 cubic feet of water every second.



The hole can be seen at the top left of the photo above. if you were to jump in for some reason your slightly damp body would shoot out near the bottom of the dam .




Bingham canyon mine, utah
This is supposedly the largest man-made excavation on earth. extraction began in 1863 and still continues today, the pit increasing in size constantly. in its current state the hole is 3/4 mile deep and 2.5 miles wide.



Great blue hole, Belize
situated 60 miles off the mainland of belize is this incredible ??geographical phenomenon ?? known as a blue hole. there are numerous blue holes around the world but none as stunning as this one.



At surface level the near perfectly circular hole is 1/4 mile wide, the depth in the middle reaching 145 metres. obviously the hole is a huge hit with divers.

Beauty of Paintings - Feature paintings

CIFS Packet Structure

Packet Header:
Every CIFS request and response uses the packet header below as a template. The various fields are described after the template.



Header: The beginning of every CIFS packet contains a 4-byte header. The first byte is 0xFF, followed by the ASCII representation of the letters ‘S’, ‘M’, and ‘B’.
Command: The command field contains a one-byte code indicating the CIFS packet type. Examples from the CIFS1.0 draft for this field are SMB_COM_READ_ANDX7 (0x2E), SMB_COM_TREE_CONNECT (0x70), and SMB_COM_NEGOTIATE (0x72).

Error class: A server indicates whether or not a given request was successful with the error class field. Typically, the field is zero, indicating success. If non-zero, the field indicates what class the error code is from. When set, the error class field takes one of the following values:
• ERRDOS (0x01) – Error is from the core DOS operating system set
• ERRSRV (0x02) – Error is generated by the server network file manager
• ERRHRD (0x03) – Hardware error
• ERRCMD (0xFF) – Command was not in the “SMB” format

Error code: This 16-bit field indicates the type of error that has occurred. It is typically set to zero, indicating no error. If set, this number in conjunction with the error class above can be looked up in the CIFS1.0 draft to give full error descriptions,such as “bad password” or “file does not exist”. As with the error class, this field is set only by servers in response to a previous request.
Flags: Most of the 8 bits in the flags field specify particular options. The only one of note in this field is bit 3. When bit 3 is set to ‘1’, all pathnames in this particular packet must be treated as caseless. When bit 3 is set to ‘0’, all pathnames are case sensitive.

Flags2: This 16-bit field specifies more options. Bits that are useful:
• Bit 0, if set, indicates that the server may return long file names in the response.
• Bit 6, if set, indicates that any pathname in the request is a long file name.
• Bit 16, if set, indicates strings in the packet are encoded as UNICODE.
Pad/security signature: This field is typically set to zero.
Tree ID (TID): The TID is a 16-bit number that identifies which resource (disk share or printer, typically) this particular CIFS packet is referring to. When packets are exchanged which do not have anything to do with a resource, this number is meaningless and ignored.

If a client wishes to gain access to a resource, the client sends a CIFS packet with the command field set to SMB_COM_TREE_CONNECT_ANDX. In this packet, the share or printer name is specified (i.e. \\SERVER\DIR). The server then verifies that the resource exists and the client has access, then sends back a response indicating success. In this response packet, the server will set the TID to any number that it pleases. From then on, if the client wishes to make requests specific to that resource, it will set the TID to the number it was given.

Process ID (PID): The PID is a 16-bit number that identifies which process is issuing the CIFS request on the client. The server uses this number to check for concurrency issues (typically to guarantee that files will not be corrupted by competing client processes).

User ID (UID): The UID is 16-bit number that identifies the user who is issuing CIFS requests on the client side. The client must obtain the UID from the server by sending a CIFS session setup request containing a username and a password. Upon verifying the username/password, the server responds to the session setup and includes a generated UID. The client then uses the assigned UID in all future CIFS requests. If any of these client requests require file/printer permissions to be checked, the server will verify that the UID in the request has the necessary permissions to perform the operation.

A UID is valid only for the given NetBIOS session. Other sessions could potentially be using an identical UID that the server correlates with a different user. Note: if a
server is operating in share level security mode (see above), the UID is meaningless and ignored.

Multiplex ID (MID): The MID is a 16-bit value that is used to allow multiple outstanding client requests to exist without confusion. Whenever a client sends a CIFS packet, it checks to see if it has any other unanswered requests pending. If it does, it insures that the new request will have a different MID then the previously outstanding requests. Whenever a server replies to a CIFS request, it insures that the response it sends matches the request MID that it received. In following this procedure, the client can always know exactly which outstanding request an incoming reply is correlated to.

WordCount and parameter words: CIFS packets use these two fields to hold command-specific data. The CIFS packet header template above cannot hold every possible data type for every possible CIFS packet. To remedy this, the parameter words field was created with a variable length. The wordcount specifies how many 16-bit words the parameter words field will actually contain. In this way, each CIFS packet can adjust to the size needed to carry its own command-specific data.

The wordcount for each packet type is typically constant and defined in the CIFS1.0 draft. There are two wordcounts defined for every single command; one wordcount for the client request and another for the server response. Two counts are needed because the amount of data necessary to make a request is not necessarily the same amount needed to issue a reply.

ByteCount and buffer: These fields are very similar to the wordcount and parameter words fields above; they hold a variable amount of data that is specified on a per packet basis. The bytecount indicates how many bytes of data will exist in the buffer field that follows.

The major difference between the parameter data section above and the buffer is what type of data they store. The parameter words data section typically holds a small number of packet options, while the buffer data section typically holds large amounts of raw data (e.g. file data).

Packet Sequence Walkthroughs:
Two common CIFS client/server packet exchanges are presented below. The first exchange shows what packets are sent when a client first initiates contact with a server: a NetBIOS session is established, a CIFS dialect is negotiated, a username and password are sent, and finally, a resource (such as a printer or directory share) is connected to. The second exchange examines the packets required to open a file and read from it.

For each exchange, an initial summary gives an overview of the entire process. In addition, each packet that is sent and received is detailed (by listing out the various packet header values) and also summarized.
Note that in all examples, the client always sends to TCP port 139, and the server always replies to the ephemeral port number that is chosen by the client. In addition, the following CIFS packet fields will not be described for each individual packet:

• Error class/code – always zeros when sent from client and assumed to be zeros when returned from server (the examples do not cover error scenarios).
• Flags – set to 0x00 for all packets (case sensitive pathnames)
• Flags2 – set to 0x0001 for all packets (long file name support)
• Pad/security signature – Set to zero in all packets

Initial contact, login, and tree connect:
When a CIFS client determines that it wishes to access resources on a CIFS server, the following packet sequence is exchanged. First, a NetBIOS session is established in order to provide a reliable message sequence transport service. Then, the client and server negotiate the CIFS dialect in which they will be communicating. The client then logs into the server, sending a username and password (for this example, the server will be operating in user level security). Finally, the client connects to the desired resource.
Packet #1 request, client –► server
Purpose: Establish NetBIOS session
Summary:
The client, wishing to exchange CIFS packets with the server, initiates a NetBIOS session between itself and the server (referred to as “calling the server” in the previous NetBIOS section). This provides for sequenced, reliable message delivery between the two endpoints. Note that the client must know the server’s NetBIOS name in order to call it and also must indicate its own NetBIOS name.

The events to establish the NetBIOS session are as follows. First, the client establishes a full duplex TCP connection with the server on port 139. Once this is accomplished, the client builds and sends a NetBIOS session request packet (not diagrammed in the NetBIOS section above, but described in RFC1002) over the TCP connection. In summary, the session request packet contains the client’s NetBIOS name, the server’s NetBIOS name, and an integer constant which indicates the packet’s purpose is to establish a NetBIOS session. Please see RFC1002 for more details.
Packet #2 response, server –► client
Purpose: Positive NetBIOS session acknowledgement
Summary:
If the above session request packet contained the server’s NetBIOS name, and the packet was formatted correctly, the server replies with a simple session established acknowledgement. This 4-byte packet is also described in RFC1002. In summary, it indicates either a successful session establishment or an error code.
Packet #3 request, client –► server
Purpose: Negotiate CIFS dialect
Summary:
Now that the NetBIOS session is established, the client is ready to send the first real CIFS request. The client sends the SMB_COM_NEGOTIATE command and includes a list of CIFS dialects that it understands.
Packet:
Command: SMB_COM_NEGOTIATE (0x72)
TID: Ignored in this packet.
PID: Set to process ID of client process.
UID: Ignored in this packet.
MID: Any unique number.
WordCount: 0
ParameterWords: There are none because wordcount is 0.
Bytecount: Set to 119 (variable depending on how many CIFS dialects the client understands).
Buffer: Contains 119 bytes worth of dialect descriptions, examples would be as follows: “PC NETWORK PROGRAM 1.0”, “MICROSOFT NETWORKS 3.0”, “DOS LM1.2X002”, “DOS LANMAN2.1”, “Windows for Workgroups 3.1a”, “NT LM 0.12”.
Packet #4 response, server –► client
Purpose: Choose CIFS dialect from request list
Summary:
The server is now responding to the negotiate protocol request by selecting the dialect that it wishes to communicate in.
Packet:
Command: SMB_COM_NEGOTIATE (0x72)
TID: Ignored in this packet.
PID: Ignored when packet is from server.
UID: Ignored in this packet.
MID: matches unique number chose above.
WordCount: This number depends on the dialect that is chosen. For this example, we will assume that the server chose “NT LM 0.12”8. In this case, the wordcount is 17.
ParameterWords: The 17 words contained here indicate the chosen dialect and many server properties. Of note is the MaxMpxCount (which states the max number of pending requests the client can initiate) and the 32-bit capabilities flags (which indicate if UNICODE is supported, if large files are supported, if NT commands are supported, and more).
Bytecount: Variable, usually greater than 8.
Buffer: Typically contains an 8-byte random string that the client uses in the next packet for encryption purposes.
Packet #5 request, client –► server
Purpose: User login
Summary:
Now that the CIFS dialect has been agreed upon, the client sends a packet containing a username and password to gain a user ID (UID). This packet also relays client capabilities to the server, so the packet must be sent even if the server is using share level security.
Packet:
Command: SMB_COM_SESSION_SETUP_ANDX (0x73)
TID: Ignored in this packet.
PID: Set to process ID of client process.
UID: Ignored in this packet.
MID: Any unique number.
WordCount: 12
ParameterWords: This section is very similar to the server’s negotiate protocol parameter words response. However, instead of listing the server’s capabilities, it lists the client’s. It also contains the size of the passwords to be supplied in the buffer section below.
Bytecount: Variable, the buffer below contains the encrypted password, the username, the name of the operating system and the native LAN manger. Therefore, the size listed here depends on the string sizes of all these entities.
Buffer: As mentioned above, this field actually contains the password, username, and other strings that identify the operating system involved.
Packet #6 response, server –► client
Purpose: Indicates User ID (UID) or returns error if bad password
Summary:
Once the server receives the encrypted password and username, it checks if the combination is valid. If the password is invalid, this response packet will be returned with the error class and code set to the appropriate error value. If the username/password is correct, then this packet contains the UID that the client will begin to send with every packet from here on.
Packet:
Command: SMB_COM_SESSION_SETUP_ANDX (0x73)
TID: Ignored in this packet.
PID: Ignored when packet is from server.
UID: The 16-bit number that the server has assigned to represent client user identity.
MID: Matches unique number chose above.
WordCount: 3
ParameterWords: Nothing relevant to normal operation.
Bytecount: Variable, the buffer below contains strings stating the server OS and native LAN manager type.
Buffer: Contains strings indicating the server OS and LAN manager type.
Packet #7 request, client –► server
Purpose: Connect to particular resource
Summary:
At this point, the client has authenticated itself to the server and may proceed to connect to the actual share. In this packet, the client specifies the share that it wishes to access. Share names are specified in UNC format (i.e. \\SERVER\SHARE).
Packet:
Command: SMB_COM_TREE_CONNECT_ANDX (0x75)
TID: Ignored in this packet.
PID: Set to process ID of client process.
UID: Set to the server returned UID from the above session setup response.
MID: Any unique number.
WordCount: 4
ParameterWords: Nothing relevant to normal operation.
Bytecount: Variable, depends on the size of the UNC string that is requested below.
Buffer: Contains the share name that the client wishes to access.
Packet #8 response, server –► client
Purpose: Indicates Tree ID (TID) or error if share name does not exist
Summary:
If the share specified above exists and the user has access permission, then the server returns a successful response with the TID set to the number it wishes to refer to the resource as. If the share does not exist or the user does not have access permission, the server will return the appropriate error class and error code here. Assuming that this packet indicates success, the client now has everything it needs to access files from the specified share. This is the final packet in this client/server exchange.
Packet:
Command: SMB_COM_SESSION_SETUP_ANDX (0x73)
TID: 16-bit number which server has assigned to represent the requested resource.
PID: Ignored when packet is from server.
UID: 16-bit number representing the user.
MID: Matches unique number chosen above.
WordCount: 3
ParameterWords: Nothing relevant to normal operation.
Bytecount: Variable, the buffer below contains strings stating the native file system and device type of the requested resource.
Buffer: Contains strings that state the native file system and device type.
File open and read:
Once a client has completed the initial packet exchange sequence described above, it may open and read files from the share that was requested. The file open consists of one CIFS request and one CIFS response. The read request also consists of one request and one response packet.
Packet #1 request, client –► server
Purpose: Open a file
Summary:
In order to read or write to a file, it first must be opened. This CIFS packet does exactly that.
Packet:
Command: SMB_COM_OPEN_ANDX (0x2D)
TID: Set to the server returned TID from the tree connect response above.
PID: Set to process ID of client process.
UID: Set to the server returned UID from the session setup response above.
MID: Any unique number.
WordCount: 15
ParameterWords: Specifies many open options such as mode (read, write, or readwrite) and sharing mode (none, read, write).
Bytecount: Variable, depends on the size of the string that contains the filename.
Buffer: Contains the name of the file to be opened.
Packet #2 response, server –► client
Purpose: Indicate File ID, or error code if problem
Summary:
The server checks to see if the filename above exists and if the user specified in the UID has permission to access the file. If these conditions are not met, the server will return the appropriate error class and error code indicating what that problem is. If there are no errors, the server returns a response packet that includes a File ID (FID) that can be used in subsequent packets for accessing the file. Note that the FID is returned to the client in the parameter words field of the response. There is no FID field in the standard CIFS header.
Packet:
Command: SMB_COM_OPEN_ANDX (0x2D)
TID: 16-bit number which the server assigned to represent the requested resource.
PID: Ignored when packet is from the server.
UID: 16-bit number representing the user.
MID: Matches unique number chosen above.
WordCount: 15
ParameterWords: Many flags indicating what type of actions occurred and the very important 16-bit FID.
Bytecount: 0
Buffer: No data in buffer.
Packet #3 request, client –► server
Purpose: Read from a file
Summary:
Assuming that the above response indicated a FID for the client to use, an actual read request for file data can now be issued.
Packet:
Command: SMB_COM_READ_ANDX (0x2E)
TID: Set to the server-returned TID from the tree connect response above.
PID: Set to process ID of client process.
UID: Set to the server-returned UID from the session setup response above.
MID: Any unique number.
WordCount: 10
ParameterWords: Here, the FID is stated so the server knows which opened file the client is referring to. Also indicated here are a 32-bit file offset and a 16-bit count value. These two numbers dictate where and how much data to return from the file.
Bytecount: 0
Buffer: No data in buffer.
Packet #4 response, server –► client
Purpose: Returns file data requested
Summary:
This packet contains the requested file data. Assuming the UID, TID, and FID were all valid numbers in the request, an error here should be unlikely.
Packet:
Command: SMB_COM_READ_ANDX (0x2E)
TID: 16-bit number which server has assigned to represent the requested resource.
PID: Ignored when packet is from the server.
UID: 16-bit number representing the user.
MID: Matches unique number chosen above.
WordCount: 12
ParameterWords: Here, the number of bytes that were actually read is indicated. This does not necessarily match the number requested (in case the request exceeded the file boundary).
Bytecount: Variable, the buffer holds the file data, so this number is also the number of bytes that were actually read.
Buffer: The file data requested.

CIFS Internals

In a nutshell, the Common Internet File System (CIFS) is a network protocol that allows file sharing between network nodes. The protocol is based around a client server design where the client sends request packets to the server, and the server responds back to the client with response packets. Each packet that is sent contains a standard header, plus two variable length fields that are used for packet specific information. Each packet also contains a command field that indicates the general purpose the packet is trying to accomplish. Common command fields indicate that the packet’s purpose is to login, open a file, read from a file, or write to a file.
To gain a more in-depth understanding of the protocol, there are three detailed sections on CIFS below. The first section covers major protocol properties. The second section introduces the CIFS standard packet header by diagramming the various fields and defining their purpose. The final section has two typical packet sequence walkthroughs: logging into a server and a file open/read.

Protocol Properties:
Client/server + request/response: As mentioned above, the CIFS architecture is based upon a client sending requests and a server replying to each request sent5. The protocol is capable of having multiple simultaneous requests outstanding. This is accomplished through the use of a multiplex id (MID). The client insures that every request that is sent to the server has a unique MID. When the server replies to a given request, the response contains the same MID. In this way, multiple requests can be sent to the server, and the client can simply match the response MID with the MID it generated to know which request has just been replied to.

Command based: Each CIFS packet contains a 1-byte command field. There are currently 100+ commands available and the core functionality of each packet revolves around the specified command. Responses to the client always have the same command code as the request. A list of common command codes is available within the CIFS1.0 draft specification.

Protocol dialects/negotiation: There have been many versions of the CIFS protocol since its inception in the 1980’s. Each protocol version is referred to as a dialect and is assigned a unique string to identify the dialect such as “PC NETWORK PROGRAM 1.0” or “NT LM 0.12”. When a client wishes to access files on a remote server, the first CIFS packet that is sent is a negotiate protocol packet. In this CIFS packet, the client lists all of the dialect strings that it is capable of understanding. In the response packet, the server indicates which dialect it wishes to communicate in, or indicates that the server understood no dialects. In this way, the client and server can negotiate which dialect to use for a particular CIFS session.
User/share level security: A share is a server entity (typically a file folder or printer) that is tagged as available to CIFS clients for network sharing. Restricted access to the share is brought about in one of two ways:
1. User level security: Indicates that a client wishing to access the share must provide a username and a password for access. This provides the server administrator fine grain control over who has access to the share. This type of security is used in Windows NT and Windows 2000.
2. Share level security: Indicates that the share itself requires a password to access, but no username is required and no user identity is established. For example, a password X could be assigned to a certain share. Any user knowing password X can then gain access to the share. There is no fine grain control because there is no concept of individual users and their rights. This type of security is used in Windows 95 and 98.
Encryption: For either of the two security methods above, the actual password is sent in an encrypted format to the server6. There are two encryption methods that are commonly used: the newer NT style and the older LAN Manager style. Both encryption methods use challenge-response authentication, where the server sends the client a random string and expects a response that proves the client knows both the random string and the user password.
Command batching: Many CIFS packets are capable of piggybacking other CIFS packets in order to reduce response latency and better utilize network bandwidth. This technique is referred to as ANDX batching.
Opportunistic locking: When a CIFS packet specifies to open a file, an opportunistic lock (oplock) can be requested. If granted by the server, the oplock indicates to the client that no other entities are accessing the file. This allows the client to make any modifications to the file that it wants and not have to write them all to the server immediately. There are multiple types of oplocks and many nuances to them. See the CIFS1.0 draft specification for more information.

Common Internet File System - CIFS

What is CIFS?
The Common Internet File System (CIFS), also known as Server Message Block (SMB), is a network protocol whose most common use is sharing files on a Local Area Network (LAN). The protocol allows a client to manipulate files just as if they were on the local computer. Operations such as read, write, create, delete, and rename are all supported – the only difference being that the files are not on the local computer and are actually on a remote server.
The CIFS protocol works by sending packets from the client to the server. Each packet is typically a basic request of some kind, such as open file, close file, or read file. The server then receives the packet, checks to see if the request is legal, verifies the client has the appropriate file permissions, and finally executes the request and returns a response packet to the client. The client then parses the response packet and can determine whether or not the initial request was successful.
CIFS is a fairly high-level network protocol. In the OSI model, it is probably best described at the Application/Presentation layer. This means CIFS relies on other protocols for transport. The most common protocol used for reliable transport is NetBIOS over TCP (NBT), which will be described in the NetBIOS chapter below. Other protocols have been used for the transport layer, however with the enormous popularity of the Internet, NBT has become the de-facto standard.
Although file sharing is CIFS’s primary purpose, there are other functions that CIFS is commonly associated with. Most CIFS implementations are also capable of determining other CIFS servers on the network (browsing), printing, and even complicated authentication techniques. None of these subjects will be discussed in this document however, only the basics of CIFS file operations.

Where is CIFS?
The CIFS protocol is most commonly used with Microsoft operating systems. Windows For Workgroups was the first Microsoft operating system to use CIFS, and each Microsoft operating system since then has been able to function as both a CIFS server and client. Microsoft operating systems use CIFS for remote file operations (typically mapping network drives), browsing (via the Network Neighborhood icon), authentication (NT and Windows 2000), and remote printer services. It would be fair to say the core of native Microsoft networking is built around its CIFS services.
Because of Microsoft’s large corporate and home user base, the CIFS protocol is found virtually everywhere. Flavors of the Unix operating system also implement a CIFS client/server via the Samba program. Apple computers also have CIFS clients and servers available, which might make CIFS the most common protocol for file sharing available.