![..[ Phrack Magazine ]..](../../images/phrack-logo.jpg){kind=logo}
.:: Big Loop Integer Protection ::.
Issues:
[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ] [ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ] [ 51 ] [ 52 ] [ 53 ] [ 54 ] [ 55 ] [ 56 ] [ 57 ] [ 58 ] [ 59 ] [ 60 ] [ 61 ] [ 62 ] [ 63 ] [ 64 ] [ 65 ] [ 66 ] [ 67 ] [ 68 ] [ 69 ] [ 70 ] [ 71 ]
Current issue : #60 | Release date : 2002-12-28 | Editor : Phrack Staff
| Introduction | Phrack Staff |
| Loopback | Phrack Staff |
| Linenoise | Phrack Staff |
| Toolz Armory | Packet Storm |
| Phrack Prophile on horizon | Phrack Staff |
| Smashing The Kernel Stack For Fun And Profit | noir |
| Burning the bridge: Cisco IOS exploits | FX |
| Static Kernel Patching | jbtzhm |
| Big Loop Integer Protection | Oded Horovitz |
| Basic Integer Overflows | blexim |
| SMB/CIFS By The Root | ledin |
| Firewall Spotting with broken CRC | Ed3f |
| Low Cost and Portable GPS Jammer | anonymous author |
| Traffic Lights | plunkett |
| Phrack World News | Phrack Staff |
| Phrack magazine extraction utility | Phrack Staff |
Title : Big Loop Integer Protection
Author : Oded Horovitz
==Phrack Inc.==
Volume 0x0b, Issue 0x3c, Phile #0x09 of 0x10
|=-------------------=[ Big Loop Integer Protection]=------------------=|
|=---------------------------------------------------------------------=|
|=--------------=[ Oded Horovitz ohorovitz@entercept.com ]=------------=|
--[ Contents
1 - Introduction
2 - Part I - Integer problems
2.1 - Introduction
2.2 - Basic code samples
3 - Part II - Exploitation pattern
3.1 - One input, two interpretations
3.2 - What is the nature of the input?
3.3 - Suggested detection
4 - Part III - Implementation
4.1 - Introduction
4.2 - Why gcc?
4.3 - A bit about gcc
4.3.1 - Compilation flow
4.3.2 - The AST
4.3.3 - Getting started
4.4 - Patch Goals
4.5 - Patch overview
4.5.1 - Tactics
4.5.2 - Modifying the AST
4.6 - Limitations
5 - References
6 - Thanks
7 - Appendix A - Real life examples
7.1 - Apache Chunked encoding
7.2 - OpenSSH auth
8 - Appendix B - Using blip
--[ 1 - Introduction
Integer overflow and integer sign vulnerabilities are now common
knowledge. This has led to increased exploitation of integer-related
vulnerabilities. The article will attempt to suggest a way to detect
these vulnerabilities by adding compiler support that detects and flags
integer vulnerabilities exploitations. Specifically a gcc patch is
presented to demonstrate the feasibility of this technique.
The article is divided into three parts. Part one contains a brief
introduction to some of the common integer related vulnerabilities. We
list some of the recent public vulnerabilities. Part two of the article
tries to explain the root cause of the problem with integer
vulnerabilities. Using real examples, the article explains why
exploitation is possible in the first place, and how it may be possible
to detect exploitation of integer vulnerabilities, even when the
vulnerability is not known in advance. Part three goes through the
implementation of the suggested detection scheme. Since the
implementation of this detection scheme is in the form of a gcc patch,
introduction information about gcc internals is provided as well. We
summarize the paper by demonstrating the protection at work against
OpenSSH and the Apache httpd packages.
--[ 2 - Part I - Integer problems
----[ 2.1 - Introduction
In the last year the attention seems to have shifted to a new bad
programming practice. This practice is related to the possibility to
integer overflows that cause buffer overflows. It turns out the many
popular and (assumed to be) secure software packages (OpenSSH, Apache,
*BSD kernel) share this vulnerability. The root cause for this bad
practice is insufficient input validation for integer type input. Integer
input looks so naive, only a few bits long. What can go wrong here? Well,
it seems that quite a lot can go wrong. The following is a table of
integer related vulnerabilities taken from the OpenBSD and FreeBSD
security lists. All vulnerabilities have been reported during year 2002.
-------------------------------------------------------------------------
| Vulnerable package | Short description of vulnerability |
-------------------------------------------------------------------------
| OpenBSD select syscall | Positive limit checks against int value |
| (See reference [4]) | allowing stack overflow |
-------------------------------------------------------------------------
| RPC xdr_array | Int overflow cause small buffer allocation |
| | which later overflowed with input |
-------------------------------------------------------------------------
| OpenSSH Authentication | Int overflow cause small buffer allocation |
| | which later overflowed with input |
-------------------------------------------------------------------------
| Apache chunked-encoding| Positive condition is done on signed int |
| | allowing heap overflow |
-------------------------------------------------------------------------
| FreeBSD get_pallette | Positive condition is done on signed int |
| | allowing information leak from kernel to user|
-------------------------------------------------------------------------
| FreeBSD accept1,getsoc-| Positive condition is done on signed int |
| kname1,getpeername1 | allowing information leak from kernel to user|
-------------------------------------------------------------------------
Table 1 - Sample integer vulnerabilities in year 2002.
The common problem that exists in all of the above vulnerabilities is
that an input of integer type (signed and unsigned) was used to trigger
overflow (when writing) or info leak (when reading) to/from program
buffers. All of the above vulnerabilities would have been prevented if
proper limits had been enforced.
----[ 2.2 - Basic code samples
Integer vulnerabilities can be further illustrated by looking at the
following two simple code samples.
Example 1 (int overflow):
-------------------------
01 int main(int argc,char* argv[]){
02 unsigned int len,i;
03 char *buf;
04 if(argc != 3) return -1;
05 len=atoi(argv[1]);
06 buf = (char*)malloc(len+1);
07 if(!buf){
08 printf("Allocation faild\n");
09 return -1;
10 }
11 for(i=0; i < len; i++){
12 buf[i] = _toupper(argv[2][i]);
13 }
14 buf[i]=0;
15 printf("%s\n",buf);
16 }
The code above seems quite legit. The program converts a string to its
upper case representation. First it allocates enough space for the string
and the NULL termination character. Then it converts each character into
its upcase value. But when looking a bit closer, we can identify two
major problems in the code. First, the program trusts the user to have as
much characters as he specifies (which is obviously not the case)(line
5). Second, the program doesn't take into account that by calculating the
space to allocate, an integer overflow may occur (line 6). Trying to
generalize the problem, the first bug may allow the attacker to read
information, which he didn't provide (by trusting the user input and
reading *len* chars from argv[2]). The second bug allows the attack to
overflow the heap with its own data, and therefore to fully compromise
the program.
Example 2 (sign check-bypass):
------------------------------
01 #define BUF_SIZE 10
02 int max = BUF_SIZE;
03 int main(int argc,char* argv[]){
04 int len;
05 char buf[BUF_SIZE];
06 if(argc != 3) return -1;
07 len=atoi(argv[1]);
08 if(len < max){
09 memcpy(buf,argv[2],len);
10 printf("Data copied\n");
11 }
12 else
13 printf("Too much data\n");
14 }
The second example shows a program that had the intention to solve the
problem introduced in the first example, by attempting to enforce user
input length to a known and predefined maximum value. The problem in this
code is that len is defined as a signed int. In this case a very big
value (unsigned wise) is interpreted as a negative value (line 8), which
will bypass the limit check. Still, in line 9 the same value is
interpreted as an unsigned positive number causing a buffer overflow and
possibly allowing a full compromise.
--[ 3 - Part II - Exploitation pattern
----[ 3.1 - One input, two interpretations
So what is the real problem? How come such security-oriented packages
have these vulnerabilities? The answer is that integer inputs sometimes
have an ambiguous interpretation at different parts of the code (integer
may change their sign at different values, implicit type cast, integer
overflows). That ambiguous interpretation is hard to notice when
implementing input validation code.
To explain this ambiguity let us look at the first example. At the time
of allocation (line 6), the code believes that since the input is a
number, then adding another number will yield a bigger number (len+1).
But since typical C language programs ignore integer overflows the
particular number 0xffffffff do not apply to this assumption and yields
unexpected result (zero). Unfortunately the same error is *NOT* repeated
later in the code. Therefore the same input 0xffffffff this time
interpreted as an unsigned value (a huge positive number).
In the second example the ambiguity of the input is even more obvious.
Here the code includes a silent type casting generated by the compiler
when calling memcpy. The code therefore is checking the value of the
input as if it was a signed number (line 8) while using it to copy data
as if it was an unsigned (line 9).
This ambiguity is invisible for the coder eye, and may go undetected,
leaving the code vulnerable to this "stealthy" attack.
----[ 3.2 - What is the nature of the input?
Looking back at the above examples reveal a common meaning for the
attacker input. (Sorry if the next few lines will explain the obvious :>)
The above input is a number for a reason. It is a counter! It counts
items! It doesn't matter what those "items" are (bytes, chars, objects,
files, etc.). They are still countable amount of items. And what can you
do with such a counter? Well, you are most likely to do some processing
"count" amount of times. As a note I will say that not *every* number is
also a counter. There are many other reasons to have numbers around. But
the one that are related to integer vulnerabilities happend to be
"counters" most of the time.
For example, if the count is for challenge response you may want to read
"count" amount of responses (OpenSSH). Or if the count is buffer length
you may want to copy "count" amount of bytes from one memory location to
the other (Apache httpd).
The bottom line is that somewhere behind this number there is the proper
"loop" in the code that will do some processing, "count" number of times.
This "loop" may have multiple forms such as the for-loop in the first
example, or as an implicit loop in memcpy. Still all loop flavors will
end up looping around the "count".
----[ 3.3 - Suggested detection
Ok, what do we have so far about those vulnerabilities?
- The input was ambiguously used in the code.
- Somewhere in the code there is a loop that uses the input integer as an
iteration counter.
To make the interpretation of the number ambiguous, the attacker has to
send a huge number. Looking at the first example we can see that in order
to make the number ambiguous the attacker needed to send such a big
number that if doing (len+1) the number will overflow. For that to happen
the attacker will have to send the value 0xffffffff. Looking at the
second example, in order to make the interpretation of the number
ambiguous, the attacker needs to send such a number that will fall into
the negative range of an integer 0x80000000-0xffffffff.
The same huge number sent by the attacker to trigger the vulnerability is
later used in a loop as the iterations counter (As discussed in the
section "What is the nature of the input?")
Now lets analyze the exploit process:
1. Attacker wants to overflow buffer.
2. Attacker may use integer vulnerability
3. Attacker sends a huge integer to trigger the vulnerability.
4. Count loop executes (probably) using attacker input as the loop bound.
5. A Buffer is overflowed (On early iterations of the loop!)
Therefore detecting (and preventing) integer vulnerability exploitation
is possible by validating the loop bounds before its execution. The
validation of the loop will check that the loop limit is not above a
predefined threshold, and if the limit is higher that the threshold a
special handler will be triggered to handle the possible exploitation.
Since the value required to trigger most integer vulnerabilities is huge,
we can assume (hope) that most legitimate loops will not trigger this
protection.
To get a feeling for what values we expect to see in integer
Vulnerabilities, lets examine the following samples:
- Allocating buffer for user data + program data
Looks like: buf = malloc(len + sizeof(header));
In this case the value required for triggering int overflow is very close
to 0xffffffff since most program struct sizes are in the range of several
bytes to hundreds bytes at most.
- Allocating arrays
looks like: buf = malloc(len * sizeof(object));
In this case the value required for triggering the overflow may be much
smaller then in the first example but it is still a relatively huge
value. For example if sizeof(object) == 4 then the value should be bigger
then 0x40000000 (one Giga). Even if the sizeof(object)== 64 the value
should be bigger then 0x4000000 (64 Mega) in order to cause an overflow.
- Falling to negative range
In this case the value required to make a number negative is any number
bigger then 0x7fffffff.
Looking at the values required to trigger the integer vulnerability, we
can choose a threshold such as 0x40000000 (One Giga) that will handle
most cases. Or we can select smaller threshold for better protection,
which may trigger some false positives.
--[ 4 - Part III - Implementation
----[ 4.1 - Introduction
Once we have a suggested a way to detect integer attacks, it will be nice
to implement a system based on that idea. A possible candidate for
implementing this system is to extend an existing compiler. Since the
compiler knows about all loops in the application, it will be possible
for the compiler to add the appropriate security checks before any "count
loop". Doing so will secure the application without any knowledge of the
specific vulnerability.
Therefore I choose to implement this system as a gcc patch and name it
"Big Loop Integer Protection" a.k.a blip. Using the -fblip flag one may
now be able to protect his application from the next yet to be public
integer exploit.
----[ 4.2 - Why gcc?
Choosing gcc was not a tough decision. First this compiler is one of the
most common compilers in the Linux, *nix world. Therefore, patching gcc
will allow protecting all applications compiled with gcc. Second, the
gcc is open-source therefore it may be feasible to implement this patch
in the first place. Third, previous security patches were implemented as
gcc patches (StackGaurd, ProPolice).So why not follow their wisdom?
----[ 4.3 - A bit about gcc
Well.., all happy I set down knowing that I'm about to make a gcc patch
for preventing integer attacks. But, except of that, what do I really
know about gcc at all? I must admit that the answer for that question was
- "not much".
To overcome this little problem, I was looking for some documentation
about gcc internals. I also hoped to find something similar to what I
wanted to do, which already exists. Fast enough, it was clear that before
jumping to other examples, I must understand the gcc beast.
.. Two weeks later, I have read enough of the gcc internal documentation,
and I spent enough time in debugging sessions of the compiler, to be able
to start modifying the code. However before I start jumping into details
I would like to provide some background about how gcc works, which I hope
the reader will find useful.
------[ 4.3.1 - Compilation flow
The gcc compiler is really an amazing machine. The design goals of gcc
include the ability to support multiple programming languages, which
later can be compiled into multiple platforms and instruction sets. In
order to achieve such a goal, the compiler uses several abstraction
layers.
At first, a language file is processed (parsed) by a language "Front
End". Whenever you invoke the gcc compiler, the compiler will decide
which of the available "Front End"s is good for parsing the input files,
and will execute that "Front End". The "Front End" will parse the whole
input file and will convert it (using many global helper functions) to an
"Abstract Syntax Tree" (AST). By doing so the "Front End" makes the
original programming language transparent to the gcc "Back End". The AST
as its name suggests, is a data-structure, which resides in memory and
can represent all the features of all the programming languages gcc
supports.
Whenever the "Front End" finishes to parse a complete function, and
converts it to an AST representation, a gcc function called
rest_of_compilation is being called. This function takes down the AST
output from the parser and "expands" it into a "Register Transfer
Language" (RTL). The RTL, which is the "expanded" version of the AST, is
then processed again and again through the many different phases of
compilation.
To get a feeling for work that is done on the RTL tree, a subset
list of the different phases is:
- Jump Optimization
- CSE (Common sub-expression elimination)
- Data flow analysis
- Instruction combination
- Instruction scheduling
- Basic block reordering
- Branch shortening
- Final (code generation)
I've selected only a few phases out of the big list of phases to
demonstrate the work done on RTL. The full list is quite more extensive
and can be found in the gcc internal docs (see "Getting started" for link
to docs). The nice thing about RTL is that all those phases are performed
independent of the target machine.
The last phase which is performed on the RTL tree, will be the "final"
phase. At that point the RTL representation is ready to be substituted by
actual assembly instructions that deal with the specific architecture.
This phase is possible due to the fact that the gcc maintains an abstract
definition of "machine modes". A set of files that can describe each
supported machine hardware, and instruction set in a way that makes it
possible to translate RTL to the appropriate machine code.
------[ 4.3.2 - The AST
I will now focus on the AST, which I will refer to as the "TREE". This
TREE is the output of the front end parsing of a language file. The TREE
contains all the information existing in the source file which is
required for code generation (e.g. declaration, functions, types..). In
addition the TREE also includes some of the attributes and implicit
transformations that the compiler may choose to perform (e.g. type
conversion, auto variables..).
Understanding the TREE is critical for creating this patch. Fortunately
the TREE is well structured and even if its object-oriented-like-
programming-using-c is overwhelming at first, after a few debugging
sessions, every thing starts to fall in place.
The core data structure of the TREE is the tree_node (defined in tree.h).
This structure is actually one big union that can represent any piece of
information. The way it works is that any tree node has its code, which
is accessible using "TREE_CODE (tree node)". Using this code the compiler
may know which of the union fields are relevant for that node (e.g. A
constant number will have the TREE_CODE() == INTEGER_CST, therefore the
node->int_cst is going to be the union member that will have the valid
information.). As a note, I will say that there is no need to access any
of the tree node structure fields directly. For each and every field in
that structure there is a dedicated macro that uniforms the access to
that field. In most cases this macro will contain some additional checks
of the node, and maybe even some logic to execute whenever access to that
field is made (e.g. DECL_RTL which is responsible to retrieve the RTL
representation of a TREE node, will call make_decl() if no RTL expression
exists for that node).
So we know about the TREE and tree node, and we know that each node can
represent many different things, what else is important to know about the
tree nodes? Well, one thing is the way tree nodes are linked to each
other. I will try to give a few sample scenarios that represent most of
the cases where one tree node is related to another one.
Reference I - Chains:
A chain is a relation that can be best described as a list. When the
compiler needs to maintain a list of nodes *that don't have any link-
related information*, it will simply use the chain field of the tree node
(accessible using the TREE_CHAIN() macro). An example for such a case is
the list of statements nodes in a function body. For each statement in a
COMPOUND_STMT list there is a chained statement that represents the
following statement in the code.
Reference II - Lists:
Whenever simple chaining is not enough, the compiler will use a special
tree node code of TREE_LIST. TREE_LIST allows the compiler to save some
information attached to each item on the list. To do so each item in the
list is represented by three tree nodes. The first tree node will have
the code TREE_LIST. This tree node will have the TREE_CHAIN pointing to
the next node in the list. It will have the TREE_VALUE pointing to the
actual tree node item, and it will also have TREE_PURPOSE which may point
to another tree node that holds extra information about this item meaning
in the list. As an example the tree node of code CALL_EXPR, will have a
TREE_LIST as its second operand. This list will represent the parameters
sent to the called function.
Reference III - Direct reference:
Many of the tree node fields are tree nodes themselves. It may be
confusing at first glance, but it will be clear soon enough. A few common
examples are:
- TREE_TYPE this field represent the type of a tree node. For example
each tree node with expression code must have a type.
- DECL_NAME whenever some declaration tree nodes have a name, it will
not exist as a string pointed directly by the declaration tree node.
Instead using the DECL_NAME one can get access to another tree node of
code IDENTIFIER_NODE. The latter will have the requested name
information.
- TREE_OPERAND() One of the most commonly used references. Whenever
there is a tree node, which has a defined number of "child" tree nodes,
the TREE_OPERAND() array will be used (e.g. tree node of code IF_STMT
will have TREE_OPERAND(t,0) as a COND_EXPR node, TREE_OPERAND(t,1) as the
THEN_CLAUSE statement node, and TREE_OPERAND(t,2) as the ELSE_CLAUSE
statement tree node.)
Reference IV - Vectors:
Last and quite less common is the tree node vector. This container, which
is accessible using the TREE_VEC_XXX macros, is used to maintain varying
size vectors.
There is a lot more to know about AST tree nodes for which the gcc
internal documents may have better and more complete explanations. So I
will stop my AST overview here with a suggestion to read the docs.
In addition to storing the abstract code in the AST. There are several
global structures, which are being extensively used by the compiler. I
will try to name a few of those global structures that I found very
useful to checkout while doing some debugging sessions.
- current_stmt_tree : provides the last added stmt to the tree , last
expression type, and the expression file name.
- current/global_binding_level : provides binding information,
such as defined names in a particular binding level, and block pointers
- lineno : var containing the line number that is parsed at the moment
- input_filename: file name that is parsed at the moment
------[ 4.3.3 - Getting started
If you want to experience the AST tree yourself, or to dig into the patch
details, it is recommended to read this getting started section. You are
safe to continue to the next section if you do not wish to do that.
First thing first, get the compiler source code. The version I used as
base for this patch is gcc 3.2. For information about download and build
of the compiler please check http://gcc.gnu.org/install/
(Please remember to specify the compiler version you wish to download.
The default version may be the last-release, which was not checked
against this patch)
Next thing you may want to do is to sit down and carefully read the gcc
internal documents. ( For the sake of this patch, you should be familiar
with the first 9 sections of this document ) The document is located
http://gcc.gnu.org/onlinedocs/gccint/
Assuming you read the document and you want to go to the next level, I
recommend to have a set of simple programs to be used as compiler
language file, your debugger of choice, and start debugging the compiler.
Some good break points that you might find useful are:
- add_stmt : called whenever the parser decides to add a new statement
into the AST. This break point may be very handy when it is not so clear
how a specific tree node is being created. By breaking on add_stmt and
checking up the call stack, it is easy to find more interesting places to
dig into.
- rest_of_compiliation : called whenever a function was completely
converted into AST representation. If you are interested to check out how
the AST is turning into RTL this is a good place to start.
- expand_stmt: called each time a statement is about to be expanded
into RTL code. Setting a Break point here will allow you to easily
investigate the structure of an AST tree node without the need to go
through endless nesting levels.
<TIP> Since the gcc compiler will end up calling the cc1 compiler for *.c
files, you may want to debug cc1 in the first place, and save yourself
the trouble of making your debugger follow the child process of gcc
</TIP>
Soon enough you will need some reference for all the little macros used
while messing with the AST tree. For that I recommend getting familiar
with the following files:
gcc3.2/gcc/gcc/tree.h
gcc3.2/gcc/gcc/tree.def
----[ 4.4 - Patch Goals
Like every project in life, you have to define the project goals. First
you better know if you reached your goals. Second, which is not less
important, since resources are limited, it is much easier to protect
yourself from a never-ending project.
The goals of this patch were above all to be a proof of concept for the
suggested integer exploits prevention scheme. Its therefore *not* a goal
to solve all current and future problems in the security world, or even
not to solve all exploits that have integer input related to them.
The second goal of this implementation is to keep the patch simple. Since
the patch is only a proof of concept, we preferred to keep things simple
and avoid fancy solutions if they required more complex code.
Last but not least the third goal is to make this patch usable. That
means easy to use, intuitive, and able to protect real world packages
bigger then 30 lines of code :).
----[ 4.5 - Patch overview
The patch will introduce a new flag to the gcc compiler named "blip". By
compiling a file using the -fblip flag, the compiler generates code
that will check for the "blip" condition for every for/while loop and for
every call to a "loop like" function.
A "loop like" function is any function that is a synonym for a loop.
(e.g. memcpy, bcopy, memset, etc.).
The generated check, will evaluate if a loop is about to execute a "Huge"
number of times. (defined by LIBP_MAX). Each time a loop is about to
execute, the generated code verifies that the loop limit is smaller than
the threshold. If an attempt to execute a loop more than the threshold
value is identified, the __blip_violation() handler will be called
instead of the loop, leading to a controlled termination of the
processes.
The current version of the patch will support only the C language. This
decision was made in order to keep this first version of the patch small
and simple. Also, all the vulnerable packages that this patch was planned
to protect are written in C. So I thought that having only C is a good
start.
------[ 4.5.1 - Tactics
Having the above goals in mind, I had to take some decisions during the
development of the patch. One of the problems I had was to choose the
right place to hack the code. There are quite a lot of options available,
and I will try to give some pros and cons for each option, hoping it will
help others to make educated decisions once they encounter the same
dilemmas.
The first thing that I had to decide was the program representation I
want to modify. The process of compilation looks more or less like that:
Processing Program representation
------------ ------------
Programming => 1. Source code
Parsing => 2. AST
Expanding => 3. RTL
"final" => 4. Object file
So what is the right place to implement the checks?
The following table lists some of the pros and cons for modifying the
code at different stages during the compilation process.
+-------------+-----------------------------+---------------------------+
|Stage |Pros | Cons |
+-------------+-----------------------------+---------------------------+
| AST |- Target independent |- No access to hardware |
| |- Language independent | Registers, instructions |
| |- Optimization independent | |
| |- High level Access to | |
| | language "source" | |
| |- Intuitive to add code | |
+-------------+-----------------------------+---------------------------+
| RTL |- Target independent |- Low level "source" access|
| |- Language independent |- May interfere with |
| |- Full access to target | optimization |
| | hardware | |
+-------------+-----------------------------+---------------------------+
| Object file |- Language independent |- Hardware dependent |
| | |- Lack syntax information |
| | |- Modification of flow may |
| | | break compiler logic |
+-------------+-----------------------------+---------------------------+
After some thought I decided to modify the AST representation. It seems
to be the most natural place to do such a change. First, the patch
doesn't really need to access low-level information such as hardware
registers, or even virtual registers allocations. Second, the patch can
easily modify the AST to inject custom logic into it, while doing the
same at the RTL level will require major changes, which will hurt the
abstraction layers defined in gcc.
Solving my second dilemma was not as easy as the first one. Now that AST
patching was the plan I had in mind, I needed to find the best point in
time in which I will examine the existing AST tree, and emit my checks on
it. I had three possible options.
1) Add a call to my function from the parser code of some language (which
happened to be C). By doing so, I have the chance to evaluate and modify
the tree "on the fly" and therefore save an extra pass over the tree
later. A clear disadvantage is the patch becomes language dependent.
2) Wait until the whole function is parsed by the front-end. Then go
through the created tree, before converting it to RTL and find the
places, which require checks, and patch them. An advantage of this method
is that the patch is no longer language dependent. On the other hand,
implementing a "tree walk" that will scan a given tree, is quite complex
and error prone task, which will go against the goals we defined above
such as simple, and useful patch.
3) Patch the AST tree *while* it is being converted into RTL. Although
this option looks like the most advantageous (language independent, no
need for a tree walk) it still has a major disadvantage which is the
uncertainty of being able to *safely* modify the AST tree at that time.
Since the RTL "conversion machine" is already processed some parts of the
AST tree, it might be dangerous to patch the AST tree at that time.
Finally, I have decided that the goal of making this patch simple,
implies selecting the first option of calling my evolution functions from
the C parser.
I've placed the hook into my patch in three locations. Two calls inside
the c-parse.y (main parser file) code allowing me to examine the FOR and
WHILE loops and to modify them on the fly. The third call is located
outside the parser since catching all call locations was quite tricky to
do from within the parser. Basically since in many different situations a
CALL_EXPR is created hooking all of them seems to be non-natural. The
alternative that I found which seems to work just fine for me, was to add
a call to my function inside the build_function_call() within the c-
typeck.c file (C compiler type-checking expression builder).
The main entry into the patch is the blip_check_loop_limit() function
which will do all the work of checking if a loop seems to be relevant,
and to call the right function that will do the actual patching of the
AST tree.
In order for a loop to be considered it needs to look like a count loop.
The blip patch will therefore try to examine each loop and decide if the
loop seems to be a counter loop (exact criteria for examining loops will
follow). For each count loop an attempt is made to detect the "count"
variable and the "limit" variable.
Example of simple loops and their variables:
- for(i=0; i < j; i+=3}{;} ==> Increment loop, i = count j = limit.
- while(len--){;} ==> decrement loop, len = counter ; 0 = limit.
The current implementation considers a loop as count loop only if:
- 2 variables are detected in the loop condition
(sometimes one of them can be a constant)
- one of those variables is modified in the loop condition or in the
loop expr
- *only one* variable is modified
- the modification is of the increment / decrement style (++,--,+=,-=)
The code, which examines the loop, is executed in blip_find_loop_vars()
and it may be improved in the future to identify more loops as count
loops.
After detecting the loop direction, the loop count and the limit, the AST
tree is modified to include a check that verifies that a big loop is
reported as a blip violation.
In order to keep the patch simple and risk free, any time a loop seems
too complex to be understood as count loop, the loop will be ignored
(Using the blip warning flags its possible to list the ignored loops, and
the reason why they were ignored).
------[ 4.5.2 - Modifying the AST
When you start patching complex applications such as gcc, you want to
make sure you are not causing any "butterfly effect" while modifying
memory resident structures on the fly. To save yourself from a lot of
trouble I will suggest avoiding modification to any structure directly.
But instead use the existing functions that the language parser would
have used if the code you want to "inject" was found in the original
source code. Following this layer of encapsulation will save you from
making mistakes such as forgetting to initialize a structure member, or
not updating another global variable or flag.
I found it very helpful to simulate the code injection by actually
modifying the source code, and tracing the compiler as it builds the AST
tree, and later mimicking the code creation by using the same functions
used by the parser to build my new check code. This way I was able to
eliminate the need of "dirty" access to the AST tree, which I was quite
afraid of while starting the modification.
Knowing the right set of functions to use to inject any code I would
like, the question became what would I really like to inject? The answer
differs a bit between the different loop types. In the case of a for-loop
the blip patch will add the check expression as the last expression in
the FOR_INIT statement. In the case of the while loop the blip patch will
add the check expression as a new statement before the while loop. In the
case of a function call to a "loop like" function such as memcpy, the
blip patch will replace the whole call expression with a new condition
expression, having the __blip_violation on the "true" side, and the
original call expression on the "false" side.
Let's illustrate the last paragraph with some samples..
Before blip
-----------
1) for(i=0;i< len;i++){}
2) While(len--){}
3) p = memcpy(d,s,l)
After blip
----------
1) for(i=0,<blip_check>?__blip_violation:0;i<len;i++){}
2) <blip_check>?__blip_violation:0;
while(len--){}
3) p = <blip_check>?__blip_violation : memcpy(d,s,l)
The <blip_check> itself is quite simple. If the loop is incremental
(going up) then the check will look like: (limit > count && limit-count >
max). If the loop is going down the check will be (count > limit &&
count - limit > max). There is a need to check the delta between the
count and the limit and not only the limit since we don't want to trigger
false positive in a loop such as:
len = 0xffff0000;
for(i=len-20;i < len; i++){};
The above example may look at first like an integer exploit. But it may
also be a legitimate loop which simply happens to iterate over very high
values.
The function responsible for building the <blip_check> is
blip_build_check_exp(), and its the code is self-explanatory, so I will
not duplicate the function comments here.
One of the difficulties I had while injecting the blip code, was the
injection of the __blip_violation function into the target file. While
creating the <blip_check> I simply created expressions which reference
the same tree nodes I found in the loop condition or as parameter to the
loop like function call. But the __blip_violation function didn't exist
in the name space of the compiled file, and therefore trying to reference
it was a bit trickier, or so I thought. Usually when a CALL_EXPR is
created, a FUNCTION_DECL is identified (as one of the available function
visible to the caller) and an ADDR_EXPR is later created to express the
address of the declared function. Since __blip_violation was not
declared , attempts to execute lookup_name() for that name will yield
an empty declaration.
Fortunately gcc was kind / forgiving enough, and I was able to build a
FUNCTION_DECL and reference it leaving all the rest of the work for the
RTL to figure out. The code, which builds the function call, is located
in blip_build_violation_call(). The function body of __blip_violation is
located in the libgcc2.c (Thanks for ProPolice for giving an example..).
<DISCLAIMER> All the modification above is being done in the spirit of
proof of concept for the blip integer exploits detection. There is no
warranty that the patch will actually increase the protection of any
system, nor that it will keep the compiler stable and usable (while using
-fblip), nor that any of the coding / patching recommendation made in the
article will make any sense to the hardcore maintainer of the gcc project
:>.</DISCLAIMER>
----[ 4.6 - Limitations
This section summarizes the limitations known to me at the time of
writing this article. I will start from the high-level limitations going
to the low level technical limitations.
- The first limitation is the coverage of the patch. The patch is
designed to stop integer vulnerabilities that yield big loops. Other
vulnerabilities that are due to bad design or lack of integer validation
will not be protected.
For example the following code is vulnerable but cannot be protected by
the patch:
void foo(unsigned int len,char* buf){
char dst[10];
if(len < 10){
strcpy(dst,buf);
}
}
- Sometimes a generic integer overflow done "by the book" will not be
detected. An example for such a case will be the xdr_array vulnerability.
The problem is due to the fact that the malloc function was called with
the overflowed expression of *two* different integer input, while the
blip protection can handle only a single big count loop. When looking at
the xdr_array loop, we can see that it will be easy for the attacker to
supply such input integers, that will overflow the malloc expression, but
will still keep the loop count small.
- Some count loops will not be considered. One example is a complex
loop condition and it is non trivial to identify the count loop. Such
loops must be ignored, or otherwise false positives may occur which may
lead to undefined execution.
- [Technical limitation] The current version is designed to work only
with C language.
- [Technical limitation] The current version will not examine embedded
assembly code which may include "loop" instructions. Therefore allowing
integer overflow exploitation to go undetected.
--[ 5 - References
[1] StackGuard
Automatic Detection and Prevention of Stack Smashing Attacks
http://www.immunix.org/StackGuard/
[2] ProPolic
GCC extension for protecting applications from stack-smashing attacks
http://www.trl.ibm.com/projects/security/ssp/
[3] GCC
GNU Compiler Collection
http://gcc.gnu.org
[4] noir
Smashing The Kernel Stack For Fun And Profit
Phrack Issue #60, Phile 0x06 by noir
[5] Halvar Flake
Third Generation Exploits on NT/Win2k Platforms
http://www.blackhat.com/presentations/bh-europe-01/halvar-flake/bh-
europe-01-halvarflake.ppt
[6] MaXX
Vudo malloc tricks
Phrack Issue 0x39, Phile #0x08
[7] Once upon a free()..
Phrack Issue 0x39, Phile #0x09
[8] Aleph One
Smashing The Stack For Fun And Profit
Phrack Issue 0x31, Phile #0x0E
--[ 6 - Thanks
I want to thanks my team for helping me in the process of creating the
paper. Thank you Monty, sinan, yona, shok for your helpful comments and
ideas for improving the paper. If you think the English in this paper is
broken imagine what my team had to go through :>. Without you guys I
would never made it.
Thanks to anonymous :> for read proofing the paper, and providing helpful
technical feedback and reassurance.
--[ 7 - Appendix A - Real life examples
Having the patch ready, I wanted to give it a test drive on one of the
known and high profile vulnerabilities. The criteria used for checking
the patch was:
- The package should be compiled successfully with the patch
- The patch should be able to protect the package against exploitation
of the known bugs
I've selected to test the patch on Apache httpd and the OpenSSH packages.
Since both packages are: high profile, have vulnerabilities that the
patch should is expected to protect against (in vulnerable version), and
they are big enough to "qa" the patch a little bit.
The protection test was proven to be successful:), and the vulnerable
version compiled with -fblip proved to be non exploitable.
The following section explains how to compile the packages with the blip
patch. We will show the output assembly generated before / after the
patch for the code which was enabling the exploit to overflow the program
buffers.
----[ 7.1 - Apache Chunked encoding
--[ Vulnerability info
Just to make sure that all are in sync with the issue of the apache
chunked-encoding vulnerability I will list part of the vulnerable code
followed by some explanation.
Code: Apache src/main/http_protocol.c : ap_get_client_block()
01 len_to_read = get_chunk_size(buffer);
<some code here...>
02 r->remaining = len_to_read;
<some code here...>
03 len_to_read = (r->remaining > bufsiz) ? bufsiz : r->remaining;
04 len_read = ap_bread(r->connection->client, buffer , len_to_read);
The vulnerability in this case allows a remote attacker to send a
negative chunk length. Doing so will bypass the check at line 3, and will
end up with calling the ap_bread() with a huge positive number.
--[ Testing patch
To compile the apache httpd with the -fblip enabled, one may edit the
file src/apaci and add the following line at the EOF "echo '-fblip'".
Any attempt to send a negative chunk length after compiling apache httpd
with the blip patch will end up with the httpd executing the
__blip_violation.
According to the blip theory, the attack should trigger some kind of a
loop. We can see at line 4 of the listed code that a call is made to the
ap_bread() function. So if the theory is correct we are supposed to find
a loop inside that function.
/*
* Read up to nbyte bytes into buf.
* If fewer than byte bytes are currently available, then return those.
* Returns 0 for EOF, -1 for error.
* NOTE EBCDIC: The readahead buffer _always_ contains *unconverted*
data.
* Only when the caller retrieves data from the buffer (calls bread)
* is a conversion done, if the conversion flag is set at that time.
*/
API_EXPORT(int) ap_bread(BUFF *fb, void *buf, int nbyte)
{
int i, nrd;
if (fb->flags & B_RDERR)
return -1;
if (nbyte == 0)
return 0;
if (!(fb->flags & B_RD)) {
/* Unbuffered reading. First check if there was something in the
* buffer from before we went unbuffered. */
if (fb->incnt) {
i = (fb->incnt > nbyte) ? nbyte : fb->incnt;
#ifdef CHARSET_EBCDIC
if (fb->flags & B_ASCII2EBCDIC)
ascii2ebcdic(buf, fb->inptr, i);
else
#endif /*CHARSET_EBCDIC*/
memcpy(buf, fb->inptr, i);
fb->incnt -= i;
fb->inptr += i;
return i;
}
i = read_with_errors(fb, buf, nbyte);
#ifdef CHARSET_EBCDIC
if (i > 0 && ap_bgetflag(fb, B_ASCII2EBCDIC))
ascii2ebcdic(buf, buf, i);
#endif /*CHARSET_EBCDIC*/
return i;
}
nrd = fb->incnt;
/* can we fill the buffer */
if (nrd >= nbyte) {
#ifdef CHARSET_EBCDIC
if (fb->flags & B_ASCII2EBCDIC)
ascii2ebcdic(buf, fb->inptr, nbyte);
else
#endif /*CHARSET_EBCDIC*/
memcpy(buf, fb->inptr, nbyte);
fb->incnt = nrd - nbyte;
fb->inptr += nbyte;
return nbyte;
}
if (nrd > 0) {
#ifdef CHARSET_EBCDIC
if (fb->flags & B_ASCII2EBCDIC)
ascii2ebcdic(buf, fb->inptr, nrd);
else
#endif /*CHARSET_EBCDIC*/
memcpy(buf, fb->inptr, nrd);
nbyte -= nrd;
buf = nrd + (char *) buf;
fb->incnt = 0;
}
if (fb->flags & B_EOF)
return nrd;
/* do a single read */
if (nbyte >= fb->bufsiz) {
/* read directly into caller's buffer */
i = read_with_errors(fb, buf, nbyte);
#ifdef CHARSET_EBCDIC
if (i > 0 && ap_bgetflag(fb, B_ASCII2EBCDIC))
ascii2ebcdic(buf, buf, i);
#endif /*CHARSET_EBCDIC*/
if (i == -1) {
return nrd ? nrd : -1;
}
}
else {
/* read into hold buffer, then memcpy */
fb->inptr = fb->inbase;
i = read_with_errors(fb, fb->inptr, fb->bufsiz);
if (i == -1) {
return nrd ? nrd : -1;
}
fb->incnt = i;
if (i > nbyte)
i = nbyte;
#ifdef CHARSET_EBCDIC
if (fb->flags & B_ASCII2EBCDIC)
ascii2ebcdic(buf, fb->inptr, i);
else
#endif /*CHARSET_EBCDIC*/
memcpy(buf, fb->inptr, i);
fb->incnt -= i;
fb->inptr += i;
}
return nrd + i;
}
We can see in the code several possible execution flows. Each one of them
includes a "loop" that moves all the data into the buf parameter. If the
code supports CHARSET_EBCDIC then the ascii2ebdcdic function executes the
deadly loop. On other normal cases, the memcpy function implements the
deadly loop.
Following is the assembly code generated for the above function.
.type ap_bread,@function
ap_bread:
pushl %ebp
movl %esp, %ebp
subl $40, %esp
movl %ebx, -12(%ebp)
movl %esi, -8(%ebp)
movl %edi, -4(%ebp)
movl 8(%ebp), %edi
movl 16(%ebp), %ebx
testb $16, (%edi)
je .L68
movl $-1, %eax
jmp .L67
.L68:
movl $0, %eax
testl %ebx, %ebx
je .L67
testb $1, (%edi)
jne .L70
cmpl $0, 8(%edi)
je .L71
movl 8(%edi), %esi
cmpl %ebx, %esi
jle .L72
movl %ebx, %esi
.L72:
cmpl $268435456, %esi ------------------------
jbe .L73
movl %esi, (%esp) Blip Check (Using esi)
call __blip_violation
jmp .L74 ------------------------
.L73:
movl 4(%edi), %eax
movl 12(%ebp), %edx
movl %edx, (%esp)
movl %eax, 4(%esp)
movl %esi, 8(%esp)
call memcpy
.L74:
subl %esi, 8(%edi)
addl %esi, 4(%edi)
movl %esi, %eax
jmp .L67
.L71:
movl %edi, (%esp)
movl 12(%ebp), %eax
movl %eax, 4(%esp)
movl %ebx, 8(%esp)
call read_with_errors
jmp .L67
.L70:
movl 8(%edi), %edx
movl %edx, -16(%ebp)
cmpl %ebx, %edx
jl .L75
cmpl $268435456, %ebx ------------------------
jbe .L76
movl %ebx, (%esp) Blip check (using ebx)
call __blip_violation
jmp .L77 ------------------------
.L76:
movl 4(%edi), %eax
movl 12(%ebp), %edx
movl %edx, (%esp)
movl %eax, 4(%esp)
movl %ebx, 8(%esp)
call memcpy
.L77:
movl -16(%ebp), %eax
subl %ebx, %eax
movl %eax, 8(%edi)
addl %ebx, 4(%edi)
movl %ebx, %eax
jmp .L67
.L75:
cmpl $0, -16(%ebp)
jle .L78
cmpl $268435456, -16(%ebp) ------------------------
jbe .L79
movl -16(%ebp), %eax Blip check
movl %eax, (%esp) (using [ebp-16])
call __blip_violation
jmp .L80 ------------------------
.L79:
movl 4(%edi), %eax
movl 12(%ebp), %edx
movl %edx, (%esp)
movl %eax, 4(%esp)
movl -16(%ebp), %eax
movl %eax, 8(%esp)
call memcpy
.L80:
subl -16(%ebp), %ebx
movl -16(%ebp), %edx
addl %edx, 12(%ebp)
movl $0, 8(%edi)
.L78:
testb $4, (%edi)
je .L81
movl -16(%ebp), %eax
jmp .L67
.L81:
cmpl 28(%edi), %ebx
jl .L82
movl %edi, (%esp)
movl 12(%ebp), %eax
movl %eax, 4(%esp)
movl %ebx, 8(%esp)
call read_with_errors
movl %eax, %esi
cmpl $-1, %eax
jne .L85
jmp .L91
.L82:
movl 20(%edi), %eax
movl %eax, 4(%edi)
movl %edi, (%esp)
movl %eax, 4(%esp)
movl 28(%edi), %eax
movl %eax, 8(%esp)
call read_with_errors
movl %eax, %esi
cmpl $-1, %eax
jne .L86
.L91:
cmpl $0, -16(%ebp)
setne %al
movzbl %al, %eax
decl %eax
orl -16(%ebp), %eax
jmp .L67
.L86:
movl %eax, 8(%edi)
cmpl %ebx, %eax
jle .L88
movl %ebx, %esi
.L88:
cmpl $268435456, %esi ------------------------
jbe .L89
movl %esi, (%esp) Blip check (using esi)
call __blip_violation
jmp .L90 ------------------------
.L89:
movl 4(%edi), %eax
movl 12(%ebp), %edx
movl %edx, (%esp)
movl %eax, 4(%esp)
movl %esi, 8(%esp)
call memcpy
.L90:
subl %esi, 8(%edi)
addl %esi, 4(%edi)
.L85:
movl -16(%ebp), %eax
addl %esi, %eax
.L67:
movl -12(%ebp), %ebx
movl -8(%ebp), %esi
movl -4(%ebp), %edi
movl %ebp, %esp
popl %ebp
ret
One can notice that before any call to the memcpy function (which is one
of the "loop like" functions), a little code was added which calls
__blip_violation in the case the 3rd parameter of memcpy is bigger than
blip_max.
Another thing worth mentioning is the way the injected check is accessing
this 3rd parameter. In the first block of the injected code the parameter
is stored at the esi register, at the second block the parameter is
stored in the ebx register and in the third block the parameter is stored
on the stack at ebp-16. The reason for that is very simple. Since the
modification of the code was done at the AST tree, and since the patch
was using the exact same tree node that was used in the call expression
to memcpy, the RTL generated the same code for both the call expression
and the check expression.
Now lets go back to the ap_bread function. And lets assume that the
CHARSET_EBCDIC was indeed defined. In that case the ascii2ebcdic function
would have being the one to have the "vulnerable" loop. Therefore we hope
that the blip patch would check the loop in that function as well.
The following is the ascii2ebcdic code taken from src/ap/ap_ebcdic.c
API_EXPORT(void *)
ascii2ebcdic(void *dest, const void *srce, size_t count)
{
unsigned char *udest = dest;
const unsigned char *usrce = srce;
while (count-- != 0) {
*udest++ = os_toebcdic[*usrce++];
}
return dest;
}
Result of compiling the above function with the -fblip
.type ascii2ebcdic,@function
ascii2ebcdic:
pushl %ebp
movl %esp, %ebp
pushl %edi
pushl %esi
pushl %ebx
subl $12, %esp
movl 16(%ebp), %ebx
movl 8(%ebp), %edi
movl 12(%ebp), %esi
cmpl $0, %ebx -------------------
jbe .L12
cmpl $268435456, %ebx
jbe .L12 Blip check
movl %ebx, (%esp)
call __blip_violation
.L12: -------------------
decl %ebx
cmpl $-1, %ebx
je .L18
.L16:
movzbl (%esi), %eax
movzbl os_toebcdic(%eax), %eax
movb %al, (%edi)
incl %esi
incl %edi
decl %ebx
cmpl $-1, %ebx
jne .L16
.L18:
movl 8(%ebp), %eax
addl $12, %esp
popl %ebx
popl %esi
popl %edi
popl %ebp
ret
.Lfe2:
While processing the ascii2ebcdic function, the blip patch identified the
while loop as a count-loop. The loop condition supplies all the
information required to create a <blip_check>. First we identify the
variables of the loop. In this case "count" is one var and the constant
"0" is the second one. Looking for variable modification, we can see that
"count" is decremented in the expression "count--". Since "count" is the
only modified variable we can say that "count" is the count-variable and
the constant 0 is the limit-variable. We can also say that the loop is a
decrement-loop since the modification operation is "--". The check
therefore will be (count > limit && count - limit > MAX_BLIP). Looking at
the above assembly code, we can see that the loop count is stored in the
ebx register (Its easy to spot this by looking at the code below label 12
(L12). This code represent the while condition. It first decrements ebx
and later compares it with the loop constant). The <blip_check> therefore
will utilize the ebx register for the check.
----[ 7.2 - OpenSSH auth
--[ Vulnerability info
The OpenSSH Vulnerability is an example of an integer overflow bug, which
results in a miscalculated allocation size. The following is a snippet of
the vulnerable code:
OpenSSH auth2-chall.c : input_userauth_info_response()
01 nresp = packet_get_int();
<some code here ..>
02 response = xmalloc(nresp * sizeof(char*));
03 for(i = 0; i < nresp; i++)
04 response[i] = packet_get_string(NULL);
At line 01 the code reads an integer into an unsigned variable. Later the
code allocates an array with nresp entries. The problem is that nresp *
sizeof(char*) is an expression that may overflow. Therefore sending nresp
bigger than 0x40000000 allows allocation of a small buffer that can be
later overflowed by the assignment in line 04.
--[ Testing the patch
To compile the OpenSSH package with the -fblip enabled, one may add -
fblip to the CFLAGS definition at Makefile.in (i.e. CFLAGS=@CFLAGS@ -
fblip)
Any attempt to send a large number of responses after compiling OpenSSH
with the blip patch will end up with OpenSSH executing the
__blip_violation.
The following is snippet of the vulnerable function.
static void
input_userauth_info_response(int type, u_int32_t seq, void *ctxt)
{
Authctxt *authctxt = ctxt;
KbdintAuthctxt *kbdintctxt;
int i, authenticated = 0, res, len;
u_int nresp;
char **response = NULL, *method;
<omitted code>
nresp = packet_get_int();
if (nresp != kbdintctxt->nreq)
fatal("input_userauth_info_response: wrong number of
replies");
if (nresp > 0) {
-----------------------------------------
** Vulnerable code **
-----------------------------------------
response = xmalloc(nresp * sizeof(char*));
for (i = 0; i < nresp; i++)
response[i] = packet_get_string(NULL);
}
<omitted code>
}
The above function is translated to the following assembly code if
compiled with the -fblip protection.(In order to make blip modification
readable, the code was compiled using -O instead of using -O2, which will
reorder basic blocks)
.type input_userauth_info_response,@function
input_userauth_info_response:
movl -16(%ebp), %eax
movl $0, 4(%eax)
call packet_get_int
movl %eax, %esi
movl -20(%ebp), %edx
cmpl 12(%edx), %eax
je .L111
movl $.LC15, (%esp)
call fatal
.L112:
testl %esi, %esi
je .L113
leal 0(,%esi,4), %eax
movl %eax, (%esp)
call xmalloc
movl %eax, -32(%ebp)
movl $0, %ebx
cmpl $0, %esi
jbe .L115
cmpl $268435456, %esi ------------------------
jbe .L115
movl %esi, (%esp) Blip Check
call __blip_violation
.L115: ------------------------
cmpl %esi, %ebx
jae .L113
.L120:
movl $0, (%esp)
call packet_get_string
movl -32(%ebp), %ecx
movl %eax, (%ecx,%ebx,4)
incl %ebx
cmpl %esi, %ebx
jb .L120
The blip patch identified the for-loop as a count-loop and injected a
code to direct the flow to the _blip_violation handler in the case that
the limit (i.e. nresp) is bigger then the BLIP_MAX. Therefore if nresp
value will be high enough to trigger an overflow in the call to xmalloc,
it will also be high enough to get caught by the <blip_check>.
--[ 8 - Appendix B - Using blip
To enable the blip patch one should first add the -fblip flag when
executing the gcc compiler.
The blip patch will attempt to emit the <blip_check> whenever it seems
possible to do so. The patch will silently ignore all loops or calls,
which cannot be protected. In order to see the ignored loops one can use
one of the following warning flags, which will also provide a message
describing the reason for ignoring the specific loop.
Warning flags:
- blip_for_not_emit - report ignored for loops.
- blip_while_not_emit - report ignored while loops.
- blip_call_not_emit - report ignored calls to loop like function.
A reason for ignoring a loop will be one of the following:
- Loop variables are less then 4 bytes long
- for init is not an expression
- call to function is made using a pointer to function
- call parameters have side effects. Reusing the expression may cause
unexpected results
- loop condition is too complex in order to find the loop variables
- non of loop variables is modified (not enough info to make check)
- both loop var are modified
- condition is too complex
The blip patch is also capable of reporting check statistics. Using the
-fblip_stat one can make the blip patch to print out statistical
information about amount of loops processed and the amount of loops that
where successfully checked.
The following command line will compile the first sample code. The output
of the compilation will follow
$ gcc -o sample -fblip -fblip_stat -O sample.c
-=] Blip statistics (checks emits)
Total: 1/100% 1/100%
for: 1/100% 1/100%
while: 0/0% 0/0%
calls: 0/0% 0/0%
-=] End Blip Statistics
begin 640 blip.patch
M9&EF9B`M3G5R(&=C8RTS+C(O9V-C+TUA:V5F:6QE+FEN(&=C8RTS+C(M8FQI
M<"]G8V,O36%K969I;&4N:6X-"BTM+2!G8V,M,RXR+V=C8R]-86ME9FEL92YI
M;@E4:'4@36%Y(#(S(#$P.C4W.C(Q(#(P,#(-"BLK*R!G8V,M,RXR+6)L:7`O
M9V-C+TUA:V5F:6QE+FEN"4UO;B!$96,@(#(@,3DZ-#(Z,SD@,C`P,@T*0$`@
M+3<R-RPW("LW,C<L-R!`0`T*("!S:6)C86QL+F\@<VEM<&QI9GDM<G1X+F\@
M<W-A+F\@<W-A+6-C<"YO('-S82UD8V4N;R!S=&UT+F\)7`T*("!S=&]R+6QA
M>6]U="YO('-T<FEN9W!O;VPN;R!T:6UE=F%R+F\@=&]P;&5V+F\@=')E92YO
M('1R964M9'5M<"YO(`E<#0H@('1R964M:6YL:6YE+F\@=6YR;VQL+F\@=F%R
M87-M+F\@=F%R<F%Y+F\@=F5R<VEO;BYO('9M<V1B9V]U="YO('AC;V9F;W5T
M+F\@7`T*+2`D*$='0RD@)"AO=71?;V)J96-T7V9I;&4I("0H15A44D%?3T)*
M4RD-"BL@8FQI<"YO("0H1T=#*2`D*&]U=%]O8FIE8W1?9FEL92D@)"A%6%12
M05]/0DI3*0T*(`T*($)!0TM%3D0@/2!M86EN+F\@;&EB8F%C:V5N9"YA#0H@
M#0I`0"`M-S8X+#<@*S<V."PX($!`#0H@#0H@3$E",D953D-37S(@/2!?9FQO
M871D:7AF(%]F:7AU;G-X9G-I(%]F:7AT9F1I(%]F:7AU;G-T9F1I(%]F;&]A
M=&1I=&8@7`T*("`@("!?8VQE87)?8V%C:&4@7W1R86UP;VQI;F4@7U]M86EN
M(%]E>&ET(%]A8G-V<VDR(%]A8G-V9&DR(%]A9&1V<VDS(%P-"BT@("`@7V%D
M9'9D:3,@7W-U8G9S:3,@7W-U8G9D:3,@7VUU;'9S:3,@7VUU;'9D:3,@7VYE
M9W9S:3(@7VYE9W9D:3(@7V-T;W)S#0HK("`@(%]A9&1V9&DS(%]S=6)V<VDS
M(%]S=6)V9&DS(%]M=6QV<VDS(%]M=6QV9&DS(%]N96=V<VDR(%]N96=V9&DR
M(%]C=&]R<R!<#0HK"5]B;&EP7W9I;VQA=&EO;@T*(`T*(",@1&5F:6YE9"!I
M;B!L:6)G8V,R+F,L(&EN8VQU9&5D(&]N;'D@:6X@=&AE('-T871I8R!L:6)R
M87)Y+@T*($Q)0C)&54Y#4U]35"`](%]E<')I;G1F(%]B8B!?7V=C8U]B8VUP
M#0ID:69F("U.=7(@9V-C+3,N,B]G8V,O8FQI<"YC(&=C8RTS+C(M8FQI<"]G
M8V,O8FQI<"YC#0HM+2T@9V-C+3,N,B]G8V,O8FQI<"YC"5=E9"!$96,@,S$@
M,38Z,#`Z,#`@,3DV.0T**RLK(&=C8RTS+C(M8FQI<"]G8V,O8FQI<"YC"4UO
M;B!$96,@(#(@,3DZ-#(Z,SD@,C`P,@T*0$`@+3`L,"`K,2PX,S4@0$`-"BLO
M*@T-"BL@*B`@("!4:&ES(&9I;&4@:7,@<&%R="!O9B!'3E4@0T,N#0T**R`J
M#0T**R`J("`@($=.52!#0R!I<R!F<F5E('-O9G1W87)E.R!Y;W4@8V%N(')E
M9&ES=')I8G5T92!I="!A;F0O;W(@;6]D:69Y#0T**R`J("`@(&ET('5N9&5R
M('1H92!T97)M<R!O9B!T:&4@1TY5($=E;F5R86P@4'5B;&EC($QI8V5N<V4@
M87,@<'5B;&ES:&5D(&)Y#0T**R`J("`@('1H92!&<F5E(%-O9G1W87)E($9O
M=6YD871I;VX[(&5I=&AE<B!V97)S:6]N(#(L(&]R("AA="!Y;W5R(&]P=&EO
M;BD-#0HK("H@("`@86YY(&QA=&5R('9E<G-I;VXN#0T**R`J#0T**R`J("`@
M($=.52!#0R!I<R!D:7-T<FEB=71E9"!I;B!T:&4@:&]P92!T:&%T(&ET('=I
M;&P@8F4@=7-E9G5L+`T-"BL@*B`@("!B=70@5TE42$]55"!!3ED@5T%24D%.
M5%D[('=I=&AO=70@979E;B!T:&4@:6UP;&EE9"!W87)R86YT>2!O9@T-"BL@
M*B`@("!-15)#2$%.5$%"24Q)5%D@;W(@1DE43D534R!&3U(@02!005)424-5
M3$%2(%!54E!/4T4N("!3964@=&AE#0T**R`J("`@($=.52!'96YE<F%L(%!U
M8FQI8R!,:6-E;G-E(&9O<B!M;W)E(&1E=&%I;',N#0T**R`J#0T**R`J("`@
M(%EO=2!S:&]U;&0@:&%V92!R96-E:79E9"!A(&-O<'D@;V8@=&AE($=.52!'
M96YE<F%L(%!U8FQI8R!,:6-E;G-E#0T**R`J("`@(&%L;VYG('=I=&@@1TY5
M($-#.R!S964@=&AE(&9I;&4@0T]064E.1RX@($EF(&YO="P@=W)I=&4@=&\-
M#0HK("H@("`@=&AE($9R964@4V]F='=A<F4@1F]U;F1A=&EO;BP@-3D@5&5M
M<&QE(%!L86-E("T@4W5I=&4@,S,P+`T-"BL@*B`@("!";W-T;VXL($U!(#`R
M,3$Q+3$S,#<L(%5302X@("HO#0T**PT-"BLC:6YC;'5D92`B8V]N9FEG+F@B
M#0T**R-I;F-L=61E(")S>7-T96TN:"(-#0HK(VEN8VQU9&4@(FUA8VAM;V1E
M+F@B#0T**R-I;F-L=61E(")R=&PN:"(-#0HK(VEN8VQU9&4@(G1R964N:"(-
M#0HK(VEN8VQU9&4@(G1O<&QE=BYH(@T-"BLC:6YC;'5D92`B8FQI<"YH(@T-
M"BLC:6YC;'5D92`B9FQA9W,N:"(-#0HK(VEN8VQU9&4@(F,M8V]M;6]N+F@B
M#0T**PT-"BLO*B!T:&ES('-T<G5C="!W:6QL(&AE;'`@86QL(&-H96-K7VQO
M;W!?;&EM:70@9G5N8W1I;VYT:6]N#0T**R`J('1O(&-O;6UU;FET8V%T92X-
M#0HK("H@4VEN8V4@=&AE(&-O;7!I;&5R(&ES('-I;F=L92!T:')E860L(&%N
M9"!T:&4@8FQI<"!C:&5C:W,@87)E(&%L;'=A>7,@#0T**R`J('-T871L97-S
M+"!T:&%N(&ET<R!S869E('1O('5S92!T:&ES('-T<G5C="!A<R!G;&]B86P@
M:6YS=&5A9"!O9B!P87-S:6YG#0T**R`J(&ET(&%L;"!A<F]U;F0N("HO#0T*
M*PT-"BML;V]P7VQI;6ET7W,@;&]O<%]L:6UI=#L-#0HK#0T**R\J('-A=F4@
M9G5N8W1I;VX@=&\@8F4@8VAE8VME9"!A9V%I;G-T(&EN=&5G97(@97AP;&]I
M="`J+PT-"BML;V]P7VQI:V5?<R`);&]O<%]L:6ME<UM=/7L-#0HK"7LB;65M
M8W!Y(BPR?2P-#0HK"7LB;65M;6]V92(L,GTL#0T**PE[(FUE;7-E="(L,GTL
M#0T**PE[(FUE;6-C<'DB+#-]+`T-"BL)>R)B8V]P>2(L,GTL#0T**PE[(F)Z
M97)O(BPQ?2P-#0HK"7LB<W=A8B(L,GTL#0T**PE[(B(L,'T)#0T**WT[#0T*
M*PT-"BLO*B!G;&]B86P@9F]R(&)L:7`@<W1A=&ES=&EC<R`J+PT-"BMB;&EP
M7W-T871I<W1I8W-?<R`@(&)L:7!?<W1A=#U[,"PP+#`L,"PP+#`L,"PP?3L-
M#0HK#0T**R-D969I;F4@4$52*'@L>2D@"7D@/R`H>"`J(#$P,"DO>2`Z(#`-
M#0HK#0T**R\J('!R:6YT(&)L:7`@<W1A=&ES=&EC<R!T;R!T:&4@<W1D97)R
M("HO#0T**W9O:60@#0T**V)L:7!?<W1A=%]P<FEN="AF<"D-#0HK"49)3$4J
M"69P.PT-"BM[#0T**PT-"BL):68H(69L86=?8FQI<"!\?`T-"BL)"2%F;&%G
M7V)L:7!?<W1A="D@<F5T=7)N.PT-"BL)#0T**PEI9BAF<"`]/2`P*2`-#0HK
M"0EF<"`]('-T9&5R<CL-#0HK"0T-"BL-#0HK"69P<FEN=&8H9G`L(EQN+3U=
M($)L:7`@<W1A=&ES=&EC<R`H8VAE8VMS(&5M:71S*5QN(BD[#0T**PD-#0HK
M"69P<FEN=&8H9G`L(E1O=&%L.EQT)60O)60E)5QT7'0E9"\E9"4E7&XB+`T-
M"BL)"0EB;&EP7W-T870N=&]T86Q?8VAE8VMS+#$P,"P-#0HK"0D)8FQI<%]S
M=&%T+G1O=&%L7V5M:71S+`T-"BL)"0E015(H8FQI<%]S=&%T+G1O=&%L7V5M
M:71S+&)L:7!?<W1A="YT;W1A;%]C:&5C:W,I*3L)"0D-#0HK"0D)#0T**PEF
M<')I;G1F*&9P+")F;W(Z7'0E9"\E9"4E7'1<="5D+R5D)25<;B(L#0T**PD)
M"6)L:7!?<W1A="YF;W)?8VAE8VMS+`T-"BL)"0E015(H8FQI<%]S=&%T+F9O
M<E]C:&5C:W,L8FQI<%]S=&%T+G1O=&%L7V-H96-K<RDL#0T**PD)"6)L:7!?
M<W1A="YF;W)?96UI=',L#0T**PD)"5!%4BAB;&EP7W-T870N9F]R7V5M:71S
M+&)L:7!?<W1A="YF;W)?8VAE8VMS*2D["0D)#0T**PD)"0T-"BL)9G!R:6YT
M9BAF<"PB=VAI;&4Z7'0E9"\E9"4E7'1<="5D+R5D)25<;B(L#0T**PD)"6)L
M:7!?<W1A="YW:&EL95]C:&5C:W,L#0T**PD)"5!%4BAB;&EP7W-T870N=VAI
M;&5?8VAE8VMS+&)L:7!?<W1A="YT;W1A;%]C:&5C:W,I+`T-"BL)"0EB;&EP
M7W-T870N=VAI;&5?96UI=',L#0T**PD)"5!%4BAB;&EP7W-T870N=VAI;&5?
M96UI=',L8FQI<%]S=&%T+G=H:6QE7V-H96-K<RDI.PD)"0T-"BL)"0D-#0HK
M"69P<FEN=&8H9G`L(F-A;&QS.EQT)60O)60E)5QT7'0E9"\E9"4E7&XB+`T-
M"BL)"0EB;&EP7W-T870N8V%L;%]C:&5C:W,L#0T**PD)"5!%4BAB;&EP7W-T
M870N8V%L;%]C:&5C:W,L8FQI<%]S=&%T+G1O=&%L7V-H96-K<RDL#0T**PD)
M"6)L:7!?<W1A="YC86QL7V5M:71S+`T-"BL)"0E015(H8FQI<%]S=&%T+F-A
M;&Q?96UI=',L8FQI<%]S=&%T+F-A;&Q?8VAE8VMS*2D["0D)#0T**PT-"BL)
M9G!R:6YT9BAF<"PB+3U=($5N9"!";&EP(%-T871I<W1I8W-<;B(I.PT-"BM]
M#0T**PT-"BLO*B!P<FEN="!A('=A<FYI;F<@;65S<V%G92P@;VYL>2!D;R!S
M;R!I9B!T:&4@<FEG:'0@=V%R;FYI;F<@9FQA9R!I<R!T=7)N960@#0T**R`J
M(&]N+B`J+PT-"BL-#0HK=F]I9`T-"BMB;&EP7W=A<FYI;F<H=V%R;E]I9"QM
M97-S86=E*0T-"BL)96YU;2!B;&EP7W=A<FYI;F=S('=A<FY?:60[#0T**PEC
M;VYS="!C:&%R*@EM97-S86=E.PT-"BM[#0T**PT-"BL):68H=V%R;E]I9"`]
M/2!314Q&7T-(14-+*7L-#0HK"0ES=VET8V@H5%)%15]#3T1%("AL;V]P7VQI
M;6ET+G-T;70I*7L-#0HK"0D)8V%S92!&3U)?4U1-5#H-#0HK"0D)"7=A<FY?
M:60@/2!.15]&3U([#0T**PD)"0EB<F5A:SL-#0HK#0T**PD)"6-A<V4@5TA)
M3$5?4U1-5#H-#0HK"0D)"7=A<FY?:60@/2!.15]72$E,13L-#0HK"0D)"6)R
M96%K.PT-"BL-#0HK"0D)8V%S92!#04Q,7T584%(Z#0T**PD)"6-A<V4@041$
M4E]%6%!2.@T-"BL)"0D)=V%R;E]I9"`]($Y%7T-!3$P[#0T**PD)"0EB<F5A
M:SL-#0HK#0T**PD)"61E9F%U;'0Z<F5T=7)N.PT-"BL)"7T-#0HK"7T-#0HK
M#0T**PES=VET8V@H=V%R;E]I9"E[#0T**PD)8V%S92!.15]&3U(Z#0T**PD)
M"6EF*"%W87)N7V)L:7!?9F]R7VYO=%]E;6ET*2!R971U<FX[#0T**PD)"6)R
M96%K.PT-"BL)"6-A<V4@3D5?5TA)3$4Z#0T**PD)"6EF*"%W87)N7V)L:7!?
M=VAI;&5?;F]T7V5M:70I(')E='5R;CL-#0HK"0D)8G)E86L[#0T**PD)8V%S
M92!.15]#04Q,.@T-"BL)"0EI9B@A=V%R;E]B;&EP7V-A;&Q?;F]T7V5M:70I
M(')E='5R;CL-#0HK"0D)8G)E86L[#0T**PT-"BL)"61E9F%U;'0Z(')E='5R
M;CL-#0HK"7T-#0HK#0T**PT-"BL)=V%R;FEN9RAM97-S86=E*3L-#0HK?0T-
M"BL-#0HK#0T**R\J(&)U:6QD(&$@8V%L;"!T;R!T:&4@8FQI<%]V:6]L871I
M;VX@9G5N8W1I;VXN('5S:6YG('1H92!A<F<@97AP(&%S('1H92`-#0HK("H@
M<&%R86UE=&5R(&9O<B!T:&ES(&-A;&PN("HO#0T**PT-"BMT<F5E#0T**V)L
M:7!?8G5I;&1?=FEO;&%T:6]N7V-A;&PH87)G*0T-"BL)=')E92!A<F<[#0T*
M*WL-#0HK#0T**PET<F5E"7!A<F%M<SL-#0HK"71R964)97AP.PT-"BL)=')E
M90EB;&EP7V9U;F-?9&5C;#U.54Q,.PT-"BL-#0HK"71R964)8FQI<%]V:6]L
M871I;VY?9&5C;"`]($Y53$P[#0T**PD-#0HK"6)L:7!?=FEO;&%T:6]N7V1E
M8VP@/0T-"BL)"6)U:6QD7V1E8VP@*$953D-424].7T1%0TPL(&=E=%]I9&5N
M=&EF:65R*")?7V)L:7!?=FEO;&%T:6]N(BDL#0T**PD)"0EB=6EL9%]F=6YC
M=&EO;E]T>7!E("AI;G1E9V5R7W1Y<&5?;F]D92Q.54Q,7U12144I*3L-#0HK
M#0T**PE$14-,7T%25$E&24-)04P@*&)L:7!?=FEO;&%T:6]N7V1E8VPI(#T@
M,3L-#0HK"41%0TQ?15A415).04P@*&)L:7!?=FEO;&%T:6]N7V1E8VPI(#T@
M,3L-#0HK"41%0TQ?24Y,24Y%("AB;&EP7W9I;VQA=&EO;E]D96-L*2`](#`[
M#0T**PE44D5%7U!50DQ)0R`H8FQI<%]V:6]L871I;VY?9&5C;"D@/2`Q.PT-
M"BL)#0T**PEB;&EP7V9U;F-?9&5C;"`](&)L:7!?=FEO;&%T:6]N7V1E8VP[
M#0T**PT-"BL)<&%R86US("`]('1R965?8V]N<R`H3E5,3"QA<F<L3E5,3"D[
M#0T**PEI9B@A<&%R86US*2!R971U<FX@3E5,3#L-#0HK"0T-"BL)+RH@8VAE
M8VL@:68@9G5N8W1I;VX@9&5C;"XN*B\)#0T**PEI9BA44D5%7T-/1$4@*&)L
M:7!?9G5N8U]D96-L*2`A/2!&54Y#5$E/3E]$14-,*7L-#0HK"0ER971U<FX@
M3E5,3#L-#0HK"7T-#0HK"0D)#0T**PEE>'`@/2!B=6EL9%]F=6YC=&EO;E]C
M86QL*&)L:7!?9G5N8U]D96-L+'!A<F%M<RD[#0T**PD-#0HK"7)E='5R;B!E
M>'`[#0T**WT-#0HK#0T**R\J(`E#<F5A=&4@82!C:&5C:R!E>'`@9F]R('1H
M92!B;&EP(&-O;F1I=&EO;B!T:&4@97AP('=I;&P@8F4@;V8@0T].1%]%6%!2
M(`T-"BL@*B`)='EP92P@86YD('=I;&P@:&%V92!T:&4@9F]L;&]W:6YG(&9O
M<FUA=#H-#0HK("H@"2@H;W`Q(#X@;W`R*2`F)B`H*&]P,2UO<#(I(#X@;6%X
M7VQI;6ET*2D@(#\@8FQI<%]V:6]L871I;VXH*2`Z(&5X<#L@(`T-"BL@*@T-
M"BL@*B`)=VAE<F4@;W`Q+V]P,B!A<F4@8V]U;F0@86YD(&QI;6ET+"!A;F0@
M=&AE:7(@;W)D97(@:6X@=&AE(&5X<&5R<W-I;VX@:7,-#0HK("H@"2!D969I
M;F1E9"!B>2!T:&4@9&ER96-T:6]N(&]F('1H92!L;V]P(`T-"BL@*@T-"BL@
M*B`)($%S(&$@;F]T92P@:2!C;W5L9"!H879E(&%D9"!S;VUE(&5X=')A(&QO
M9VEC('1O(&5L:6UI;F%T92!T:&4@8V]M<&QE>"`-#0HK("H@"2!C:&5C:R!I
M9B!T:&4@;&EM:70O8V]U;G0@87)E(&-O;G-T86YT<RP@8G5T('-I;F-E('1H
M92!O<'1I;6EZ97(@8V%N(`T-"BL@*B`)('!I8VL@=&AA="!U<"!I="!W:6QL
M(&)E(')E9'5N9&%N="!A;F0@82!S;W5R8V4@;V8@;6ES=&%K97,N*B\-#0HK
M#0T**W1R964-#0HK8FQI<%]B=6EL9%]C:&5C:U]E>'`H97AP*0T-"BL)=')E
M90EE>'`[#0T**WL-#0HK#0T**PET<F5E"71T(#T@=F]I9%]T>7!E7VYO9&4[
M#0T**PET<F5E"6]P7W1T.PT-"BL)=')E90EB;&EP7W9I;VQA=&EO;E]C86QL
M+&)L:7!?;6%X.PT-"BL)#0T**PDO*B!A;&P@97AP<F5S<VEO;B!N965D960@
M9F]R('1H92!C;VYD=&EO;B!C<F5A=&EO;B`J+PT-"BL-#0HK"71R964@("`@
M;W!?9W1?;6%X.PD)+RH@;W`@/B!M87@@*B\)#0T**PET<F5E"6]P,5]G=%]O
M<#([(`DO*B`H;W`Q(#X@;W`R*2`J+PT-"BL)=')E90EM:6YU<SL@"0D)+RH@
M*&]P,2UO<#(I("HO#0T**PET<F5E"6UI;G5S7V=T7VUA>#L@"2\J("@H;W`Q
M+6]P,BD@/B!M87A?;&EM:70I("HO#0T**PET<F5E"71?86YD:68[(`D)+RH@
M=&AE("@I)B8H*2`J+PT-"BL-#0HK"71R964)8V]U;G0["0D)+RH@=&AE(&-A
M;&-U;&%T960@8V]U;G0@;&]O<"`J+PD-#0HK"71R964)8V]N9%]T97-T.PD)
M+RH@=&AE(&-O;F1I=&EO;B!T97-T("HO#0T**PET<F5E"6-O;F1?97AP.PD)
M+RH@5&AE('=H;VQE(&)L:7`@8V]N9&ET:6]N("HO#0T**PD-#0HK"6EF*&5X
M<"D)='0@/2!44D5%7U194$4@*&5X<"D[#0T**PD)#0T**PEO<%]T="`](&QO
M;F=?=6YS:6=N961?='EP95]N;V1E.PT-"BL-#0HK"6)L:7!?;6%X(#T@8G5I
M;&1?:6YT7S(@*$),25!?34%8+#`I.PT-"BL)5%)%15]465!%("AB;&EP7VUA
M>"D@/2!O<%]T=#L-#0HK#0T**PT-"BL)+RH@:68@;&]O<"!C;W5N=&5R(&]R
M(&QO;W`@;&EM:70@87)E('-M86QL97(@=&AE;B`T8GET92!I;G1S(`T-"BL)
M("H@9&]N="!E=F5N(&)O=&AE<B!T;R!C<F5A=&4@8VAE8VL@97AP<F5S<VEO
M;BX@*B\-#0HK"6EF*"%44D5%7U194$4H;&]O<%]L:6UI="YC;W5N=&5R*2!\
M?`T-"BL)"5194$5?4%)%0TE324].*%12145?5%E012AL;V]P7VQI;6ET+F-O
M=6YT97(I*2`\(#,R('Q\#0T**PD)(512145?5%E012AL;V]P7VQI;6ET+FQI
M;6ET*2!\?`T-"BL)"5194$5?4%)%0TE324].*%12145?5%E012AL;V]P7VQI
M;6ET+FQI;6ET*2D@/"`S,BE[#0T**PD)#0T**PD)8FQI<%]W87)N:6YG*%-%
M3$9?0TA%0TLL(F)L:7`Z('9A<B!S;6%L;&5R('1H96X@;&]N9R(I.PD-#0HK
M"0ER971U<FX@3E5,3#L-#0HK"7T-#0HK"0T-"BL)<W=I=&-H*%12145?0T]$
M12`H;&]O<%]L:6UI="YS=&UT*2E["0T-"BL-#0HK"6-A<V4@5TA)3$5?4U1-
M5#H-#0HK"6-A<V4@1D]27U-4350Z#0T**PT-"BL)"0T-"BL)"2\J(&EN(&QO
M;W`@;V8@='EP92!W:&EL92AL96XM+2D@9V-C(&9O<B!S;VUE(')E87-O;B!P
M<F5F97(@=&\@8V]M<&%R92`-#0HK"0D@*B!T:&4@<F5S=6QT(&]F(")L96XM
M+2(@=&\@82!V86QU92!I;G-T96%D(&]F(&-O;7!A<FEN9R`B;&5N(BX@#0T*
M*PD)("H@*'1O('-A=F4@<F5G:7-T97)S('=H:6-H(&]L9"!L96X_*2!T:&4@
M<F5S=6QT(&ES('1H870@9V-C(&%S<W5M92`-#0HK"0D@*B!T:&%T(#`@+2T@
M=VEL;"!B96-O;64@,'AF9F9F9F9F9B!E=F5N(&EF('1H92!L;V]P(&ES('5N
M<VEG;F5D("$A+@T-"BL)"2`J(%1O(')E<')E<V5N="!T:&4@<F5A;"!D:7-T
M86YC92!W92!W:6QL(&-H86YG92!T:&ES('9A;'5E('1O(#`N("HO#0T**PD)
M:68H;&]O<%]L:6UI="YD:7(@/3T@1$5#4D5-14Y4("8F#0T**PD)"512145?
M0T].4U1!3E0H;&]O<%]L:6UI="YL:6UI="D@)B8-#0HK"0D)5%)%15])3E1?
M0U-47TQ/5RAL;V]P7VQI;6ET+FQI;6ET*2`]/2`P>$9&1D9&1D9&*7L-#0HK
M"0D);&]O<%]L:6UI="YL:6UI="`](&EN=&5G97)?>F5R;U]N;V1E.PD)#0T*
M*PD)?0T-"BL)#0T**PD-#0HK"0DO*B!C;VYV97)T('1H92!L:6UI="!A;F0@
M8V]U;G0@:6YT;R!U;G-I9VYE9"!I;G0@:68@=&AE>2!A<F4@;F]T(`T-"BL)
M"2`J(&%L;')E861Y('-O+B!4:&ES(&-O;G9E<G1I;VX@:7,@;F]T('-U<'!O
M<V4@=&\@969F96-T('1H92!R96%L(`T-"BL)"2`J('9A<G,N+B`Z*2`J+PT-
M"BL)"6EF*"%44D5%7U5.4TE'3D5$*&QO;W!?;&EM:70N8V]U;G1E<BD@)B8-
M#0HK"0D)(512145?0T].4U1!3E0H;&]O<%]L:6UI="YC;W5N=&5R*2E[#0T*
M*PD)"6QO;W!?;&EM:70N8V]U;G1E<B`](&)U:6QD,2`H0T].5D525%]%6%!2
M+&QO;F=?=6YS:6=N961?='EP95]N;V1E+`T-"BL)"0D)"0D)"0D);&]O<%]L
M:6UI="YC;W5N=&5R*3L-#0HK"0E]#0T**PD)#0T**PD):68H(512145?54Y3
M24=.140H;&]O<%]L:6UI="YL:6UI="D@)B8-#0HK"0D)(512145?0T].4U1!
M3E0H;&]O<%]L:6UI="YL:6UI="DI>PT-"BL)"0EL;V]P7VQI;6ET+FQI;6ET
M(#T@8G5I;&0Q("A#3TY615)47T584%(L;&]N9U]U;G-I9VYE9%]T>7!E7VYO
M9&4L#0T**PD)"0D)"0D)"0EL;V]P7VQI;6ET+FQI;6ET*3L-#0HK"0E]#0T*
M*PD)#0T**PD)#0T**PD)+RH@8V]N<W1R=6-T('1H92!C:&5C:R!E>'!R97-S
M:6]N<R!D97!E;F1I;F<@;VX@;&]O<"!D:7)E8W1I;VX@*B\-#0HK"0EI9BAL
M;V]P7VQI;6ET+F1I<B`]/2!)3D-214U%3E0I>PT-"BL)"0EM:6YU<R`](&)U
M:6QD("A-24Y54U]%6%!2+&]P7W1T+`T-"BL)"0D)"0D);&]O<%]L:6UI="YL
M:6UI="QL;V]P7VQI;6ET+F-O=6YT97(I.PT-"BL)#0T**PD)"6]P,5]G=%]O
M<#(@/2!B=6EL9"`H1U1?15A04BQB;V]L96%N7W1Y<&5?;F]D92P-#0HK"0D)
M"0D)"0EL;V]P7VQI;6ET+FQI;6ET+&QO;W!?;&EM:70N8V]U;G1E<BD[#0T*
M*PD)?0T-"BL)"65L<V5[#0T**PD)"6UI;G5S(#T@8G5I;&0@*$U)3E537T58
M4%(L;W!?='0L#0T**PD)"0D)"0EL;V]P7VQI;6ET+F-O=6YT97(L;&]O<%]L
M:6UI="YL:6UI="D[#0T**PD)"0T-"BL)"0EO<#%?9W1?;W`R(#T@8G5I;&0@
M*$=47T584%(L8F]O;&5A;E]T>7!E7VYO9&4L#0T**PD)"0D)"0D);&]O<%]L
M:6UI="YC;W5N=&5R+&QO;W!?;&EM:70N;&EM:70I.PT-"BL)"7T)#0T**PD-
M#0HK"0DO*B!I9B!A;GD@;V8@=&AE(&5X<')E<W-I;VYS('=A<R!N;W0@8W)E
M871E9"P@9F%I;"`J+PT-"BL)"6EF*"%M:6YU<R!\?"`A;W`Q7V=T7V]P,BD@
M<F5T=7)N($Y53$P[#0T**PD-#0HK"0EM:6YU<U]G=%]M87@@/2!B=6EL9"`H
M1U1?15A04BQB;V]L96%N7W1Y<&5?;F]D92QM:6YU<RQB;&EP7VUA>"D[#0T*
M*PD):68H(6UI;G5S7V=T7VUA>"D@<F5T=7)N($Y53$P[#0T**PD)#0T**PD)
M=%]A;F1I9B`](&)U:6QD("A44E542%]!3D1)1E]%6%!2+&)O;VQE86Y?='EP
M95]N;V1E+`T-"BL)"0D)"0EO<#%?9W1?;W`R+&UI;G5S7V=T7VUA>"D[#0T*
M*PD-#0HK"0EI9B@A=%]A;F1I9BD@<F5T=7)N($Y53$P[#0T**PD)#0T**PD)
M8V]N9%]T97-T(#T@=%]A;F1I9CL-#0HK"0EC;W5N="`](&UI;G5S.PD-#0HK
M"0D-#0HK"0EB<F5A:SL-#0HK"0T-"BL)8V%S92!#04Q,7T584%(Z#0T**PT-
M"BL)"6EF*%12145?54Y324=.140H;&]O<%]L:6UI="YL:6UI="D@)B8-#0HK
M"0D)(512145?0T].4U1!3E0H;&]O<%]L:6UI="YL:6UI="DI>PT-"BL)"0EL
M;V]P7VQI;6ET+FQI;6ET(#T@8G5I;&0Q("A#3TY615)47T584%(L;&]N9U]U
M;G-I9VYE9%]T>7!E7VYO9&4L#0T**PD)"0D)"0D)"0EL;V]P7VQI;6ET+FQI
M;6ET*3L-#0HK"0E]#0T**PT-"BL)"6]P7V=T7VUA>"`](&)U:6QD("A'5%]%
M6%!2+&)O;VQE86Y?='EP95]N;V1E+&QO;W!?;&EM:70N;&EM:70L8FQI<%]M
M87@I.PT-"BL)"6EF*"%O<%]G=%]M87@I(')E='5R;B!.54Q,.PT-"BL-#0HK
M"0EC;VYD7W1E<W0@/2!O<%]G=%]M87@[#0T**PD)8V]U;G0@/2!L;V]P7VQI
M;6ET+FQI;6ET.PT-"BL)"0T-"BL)"6)R96%K.PT-"BL-#0HK"61E9F%U;'0Z
M<F5T=7)N($Y53$P["0T-"BL)?0T-"BL)"0T-"BL)8FQI<%]V:6]L871I;VY?
M8V%L;"`](&)L:7!?8G5I;&1?=FEO;&%T:6]N7V-A;&PH8V]U;G0I.PT-"BL)
M:68H(6)L:7!?=FEO;&%T:6]N7V-A;&PI(')E='5R;B!.54Q,.PT-"BL)#0T*
M*PDO*B!N;W<@=V4@=VEL;"!B=6EL9"!T:&4@0T].1%]%6%!2('5S:6YG('1H
M92!G="!A<R!T:&4@8V]N9&ET:6]N#0T**PD@*B!A(&-A;&P@=&\@;W5R(&)L
M:7!?=FEO;&%T:6]N(&9U;F-T:6]N(&EF(&-O;F1I=&EO;B!I<R!T<G5E+"!A
M;F0@#0T**PD@*B!T:&4@87)G(")E>'`B(&%S(&9A;'-E(&5X<"!O9B!T:&4@
M0T].1%]%6%!2("HO#0T**PEC;VYD7V5X<"`](&)U:6QD("A#3TY$7T584%(L
M='0L8V]N9%]T97-T+&)L:7!?=FEO;&%T:6]N7V-A;&PL#0T**PD)"0D@97AP
M(#\@97AP(#H@:6YT96=E<E]Z97)O7VYO9&4I.PT-"BL-#0HK"7)E='5R;B!C
M;VYD7V5X<#L-#0HK?0T-"BL-#0HK#0T**R\J($-R96%T92!A;B!%6%!27U-4
M350@=VET:"!A($-/3D1?15A04B!I;G-I9&4L('=H:6-H(&-H96-K(&9O<B!B
M;&EP(`T-"BL@*B!C;VYD:71I;VXN("HO#0T**PT-"BMT<F5E#0T**V)L:7!?
M8G5I;&1?8VAE8VM?<W1M="AE>'`I#0T**PET<F5E"65X<#L-#0HK>PT-"BL-
M#0HK"71R964)8VAE8VM?<W1M=#TP.PT-"BL)=')E90EC:&5C:U]E>'`],#L-
M#0HK#0T**PEC:&5C:U]E>'`@/2!B;&EP7V)U:6QD7V-H96-K7V5X<"AE>'`I
M.PT-"BL):68H(6-H96-K7V5X<"D@<F5T=7)N($Y53$P[#0T**PD-#0HK"6-H
M96-K7W-T;70@/2!B=6EL9%]S=&UT*$584%)?4U1-5"P@8VAE8VM?97AP*3L-
M#0HK#0T**PER971U<FX@8VAE8VM?<W1M=#L-#0HK?0T-"BL-#0HK#0T**R\J
M"6%D9"!A($-/3D1?15A04B!T;R!T:&4@9F]R(&EN:70@<W1M="X@5&AE(&%D
M9&ET:6]N(&-H96-K('=I;&P@8F4@:6X@80T-"BL@*@EF;W)M870@;V8@82!N
M97<@15A04E]35$U4(&)Y(&UA:VEN9R!T:&4@8W5R<F5N="!F;W(@:6YI="!S
M=&UT(&$@#0T**R`J"4-/35!/54Y$7U-4350@86YD(&-H86EN9R!T:&4@;F5W
M($584%)?4U1-5"!A="!T:&4@96YD(&]F('1H92!E>&ES=&EN9R!O;F4N(`T-
M"BL@*B\-#0HK(`T-"BMB;V]L("`-#0HK8FQI<%]E;6ET7V9O<E]L;V]P7V-H
M96-K<RAF;W)?<W1M="D-#0HK"71R964)9F]R7W-T;70[#0T**PD)#0T**WL-
M#0HK#0T**PET<F5E"69O<E]I;FET.PT-"BL)=')E90EC;VUP;W5N9%]E>'!R
M.PT-"BL)=')E90EB;&EP7V5X<#L-#0HK#0T**PEF;W)?:6YI="`]($9/4E])
M3DE47U-4350@*&9O<E]S=&UT*3L-#0HK#0T**PDO*B!(86YD;&4@;VYL>2!C
M87-E<R!W:&5R92!F;W(@:6YI="!I<R!E>'!R97-S:6]N+B`J+PT-"BL):68H
M5%)%15]#3T1%("AF;W)?:6YI="D@(3T@15A04E]35$U4*2![#0T**PD)8FQI
M<%]W87)N:6YG*$Y%7T9/4BP-#0HK"0D)(F)L:7`Z(&9O<B!I;FET(&ES(&YO
M="!%6%!27U-4350B*3L)#0T**PD)<F5T=7)N(&9A;'-E.PT-"BL)?0T-"BL)
M#0T**PDO*B!B=6EL9"!A(&)L:7`@8VAE8VL@=7-I;F<@=&AE(&=L;V)A;"!L
M;V]P7VQI;6ET("HO#0T**PEB;&EP7V5X<"`](&)L:7!?8G5I;&1?8VAE8VM?
M97AP*$Y53$Q?5%)%12D[#0T**PEI9B@A8FQI<%]E>'`I>PT-"BL)"6)L:7!?
M=V%R;FEN9RA.15]&3U(L#0T**PD)"2)B;&EP.B!I;G1E<FYA;"!F86EL=7)E
M('=H:6QE(&)U:6QD:6YG(&-H96-K(&5X<')E<W-I;VXB*3L)#0T**PD)<F5T
M=7)N(&9A;'-E.PT-"BL)?0T-"BL-#0HK"6EF*%12145?3U!%4D%.1"`H9F]R
M7VEN:70L,"D@/3T@3E5,3%]44D5%*7L-#0HK"0E44D5%7T]015)!3D0@*&9O
M<E]I;FET+#`I(#T@8FQI<%]E>'`[#0T**PE]#0T**PEE;'-E>PT-"BL)"2\J
M(&-O;G-T<F%C="!A(&YE=R!C;VUP;W5N9"!E>'!R97-S:6]N("HO#0T**PD)
M8V]M<&]U;F1?97AP<B`](&)U:6QD*$-/35!/54Y$7T584%(L=F]I9%]T>7!E
M7VYO9&4L#0T**PD)"0D)"0D)5%)%15]/4$5204Y$("AF;W)?:6YI="PP*2P-
M#0HK"0D)"0D)"0EB;&EP7V5X<"D[#0T**PD-#0HK"0EI9B@A8V]M<&]U;F1?
M97AP<BD@<F5T=7)N(&9A;'-E.PT-"BL)#0T**PD)+RH@<F5P;&%C92!C=7)R
M96YT(&9O<B!I;FET(&5X<')E<W-I;VX@=VET:"!T:&4@;F5W(&-O;7!O=6YD
M(`T-"BL)"2`J(&5X<')E<W-I;VX@*B\-#0HK"0D-#0HK"0E44D5%7T]015)!
M3D0@*&9O<E]I;FET+#`I(#T@8V]M<&]U;F1?97AP<CL-#0HK"7T-#0HK"0T-
M"BL)<F5T=7)N('1R=64[#0T**PD-#0HK?0T-"BL-#0HK+RH)861D(&$@0T].
M1%]%6%!2(&)E9F]R92!T:&4@5TA)3$5?4U1-5"X@5&AE(&%D9&ET:6]N(&-H
M96-K('=I;&P@8F4@:6X@80T-"BL@*@EF;W)M870@;V8@82!N97<@15A04E]3
M5$U4+B!3:6YC92!W92!A<F4@8V%L;&5D(&EN(&$@<W1A=&4@=VAE<F4@=&AE
M(`T-"BL@*@E72$E,15]35$U4('=A<R!N;W0@>65T(&%D9&5D('1O('1H92!T
M<F5E+B!W92!W:6QL('-I;7!L>2!A9&0@;W5R(&-O;F0N(`T-"BL@*B\-#0HK
M(`T-"BMB;V]L("`-#0HK8FQI<%]E;6ET7W=H:6QE7VQO;W!?8VAE8VMS*"D-
M#0HK>PT-"BL)=')E90EB;&EP7W-T;70[#0T**PD)#0T**PEB;&EP7W-T;70@
M/2!B;&EP7V)U:6QD7V-H96-K7W-T;70H3E5,3%]44D5%*3L-#0HK"6EF*"%B
M;&EP7W-T;70I(')E='5R;B!F86QS93L-#0HK"0T-"BL)861D7W-T;70H8FQI
M<%]S=&UT*3L-#0HK"0T-"BL)<F5T=7)N('1R=64[#0T**WT-#0HK#0T**PT-
M"BLO*B!C;VYV97)T(&$@0T%,3%]%6%!2('1O(&$@0T].1%]%6%!2(&AA=FEN
M9R!T:&4@8FQI<"!C:&5C:W,@87,@=&AE(&-O;F0N#0T**R`J(&%N9"!T:&4@
M;W)I9VEN86P@0T%,3%]%6%!2(&%S('1H92!F86QS92!S:61E(&]F('1H92!E
M>'!R97-S:6]N+B`J+R`-#0HK#0T**W1R964@(`T-"BMB;&EP7V5M:71?8V%L
M;%]C:&5C:W,H8V%L;"D-#0HK"71R964)8V%L;#L-#0HK"0D-#0HK>PT-"BL)
M=')E90EC:&5C:U]E>'`[#0T**PT-"BL)8VAE8VM?97AP(#T@8FQI<%]B=6EL
M9%]C:&5C:U]E>'`H8V%L;"D[(`T-"BL-#0HK"2\J(&EF('=E(&9A:6QE9"!T
M;R!C;VYV97)T('1H92!E>'`@:6YT;R!O=7(@8VAE8VLL(`T-"BL)("H@=&AE
M;B!R971U<FX@=&AE(&]R:6=I;F%L(&5X<'(@*B\-#0HK"6EF*"%C:&5C:U]E
M>'`I(')E='5R;B!C86QL.PT-"BL-#0HK"7)E='5R;B!C:&5C:U]E>'`[#0T*
M*WT-#0HK#0T**R\J(&-H96-K(&EF(&$@9&5C;"!I<R!P87)T(&]F(&$@<W1M
M="!O<B!A;B!E>'!R(&%S(&$@;'9A;'5E#0T**R`J(&EF(&ET(&ES('1H96X@
M8V]N<VED97(@:70@87,@;6]D:69I960@#0T**R`J#0T**R`J(%1H:7,@9G5N
M8W1I;VX@:7,@<F5C=7)S:79E(&%N9"!T:&4@<W1O<"!C;VYI=&EO;B!I<R!E
M:71H97(-#0HK("H@+2!A('-I;7!L92!E>'!R('=A<R!F;W5N9"!W:&EC:"!A
M;&QO=R!U<R!T;R!F:6=U<F4@;W5T('1H870@#0T**R`J(`D@=&AE(&1E8VP@
M:7,@;6]D:69I960N#0T**R`J("T@82!F=6YC=&EO;B!R96%C:"!A('-T;70@
M+R!E>'!R('1O(&-O;7!L97@@=&\@=F5R9FEY#0T**R`J(`D@*'=E(&-A;B!C
M:&5A="!I;B!F:7)S="!V97)S:6]N(&%N9"!C;&%I;2!T:&%T(&%L;6]S="!E
M=F5R>71H:6YG#0T**R`J(`D@:7,@=&]O(&AA<F0@=&\@:61E;G1I9GD@<V\@
M<F5C=7)S:79E(&5N9"!W:&EL92!S=7!P;W)T:6YG(&]N;'D@#0T**R`J(`D@
M8F%S:6,@<W1U9F8@*2HO#0T**PT-"BL-#0HK#0T**V)O;VP-#0HK8FQI<%]D
M96-L7VUO9&EF:65D("AD96-L+'0I#0T**PET<F5E(&1E8VP[#0T**PET<F5E
M('0[#0T**WL-#0HK"6EN="!I.PT-"BL)=')E90EE>'`[#0T**PD-#0HK"6EF
M*"%T*2!R971U<FX@9F%L<V4[#0T**PD-#0HK"7-W:71C:"A44D5%7T-/1$4@
M*'0I*7L-#0HK#0T**PDO*B!H86YD;&4@:VYO=VX@<VEM<&QE(&-A<V5S('=H
M:6-H(&ES('1Y<&EC86P@=&\@8V]U;G1E<B`-#0HK"2`J(&UO9&EF:6-A=&EO
M;G,@*B\-#0HK"0D-#0HK"0EC87-E($U/1$E&65]%6%!2.@T-"BL)"0DO*B!O
M;FQY('1A:V4@8V%R92!O9B!C87-E(&QI:V4@*ST@+3T@34]$24997T584%(@
M=VAE<F4@9&5C;"`-#0HK"0D)("H@:7,@;VX@;&5F="!S:61E(&%N9"!A;'-O
M(&]N(')I9VAT('-I9&4@=&]G871H97(@=VET:"!A(`T-"BL)"0D@*B!C;VYS
M=&%N="`J+PT-"BL)"0EE>'`@/2!44D5%7T]015)!3D0@*'0L,2D[#0T**PD)
M"6EF*`E44D5%7T]015)!3D0@*'0L,"D@/3T@9&5C;"`F)@T-"BL)"0D)97AP
M("8F#0T**PD)"0E44D5%7T]015)!3D0@*&5X<"PP*2`]/2!D96-L("8F#0T*
M*PD)"0E44D5%7T]015)!3D0@*&5X<"PQ*2`F)@T-"BL)"0D)5%)%15]#3TY3
M5$%.5"`H5%)%15]/4$5204Y$("AE>'`L,2DI*7L-#0HK#0T**PT-"BL)"0D)
M:68H5%)%15]#3T1%("AE>'`I(#T](%!,55-?15A04BE[#0T**PD)"0D);&]O
M<%]L:6UI="YD:7(@/2!)3D-214U%3E0[#0T**PD)"0D)<F5T=7)N('1R=64[
M#0T**PD)"0E]#0T**PD)"0D-#0HK"0D)"6EF*%12145?0T]$12`H97AP*2`]
M/2!-24Y54U]%6%!2*7L-#0HK"0D)"0EL;V]P7VQI;6ET+F1I<B`]($1%0U)%
M345.5#L-#0HK"0D)"0ER971U<FX@=')U93L-#0HK"0D)"7T-#0HK#0T**PD)
M"0ER971U<FX@=')U93L-#0HK"0D)?0T-"BL)"0EE;'-E#0T**PD)"0ER971U
M<FX@9F%L<V4[#0T**PT-"BL)"0D-#0HK"0EC87-E(%!214E.0U)%345.5%]%
M6%!2.@T-"BL)"6-A<V4@4$]35$E.0U)%345.5%]%6%!2.@T-"BL)"0T-"BL)
M"0EI9BAD96-L(#T](%12145?3U!%4D%.1"`H="PP*2E[#0T**PD)"0EL;V]P
M7VQI;6ET+F1I<B`]($E.0U)%345.5#L-#0HK"0D)"7)E='5R;B!T<G5E.PT-
M"BL)"0E]#0T**PD)"0T-"BL)"0EB<F5A:SL-#0HK#0T**PD)8V%S92!03U-4
M1$5#4D5-14Y47T584%(Z#0T**PD)8V%S92!04D5$14-214U%3E1?15A04CH-
M#0HK"0D)#0T**PD)"0T-"BL)"0EI9BAD96-L(#T](%12145?3U!%4D%.1"`H
M="PP*2E[#0T**PD)"0EL;V]P7VQI;6ET+F1I<B`]($1%0U)%345.5#L-#0HK
M"0D)"7)E='5R;B!T<G5E.PT-"BL)"0E]#0T**PD)"0T-"BL)"0EB<F5A:SL-
M#0HK#0T**PD)8V%S92!,5%]%6%!2.@T-"BL)"6-A<V4@3$5?15A04CH-#0HK
M"0EC87-E($=%7T584%(Z#0T**PD)8V%S92!'5%]%6%!2.@T-"BL)"6-A<V4@
M15%?15A04CH-#0HK"0EC87-E($Y%7T584%(Z#0T**PT-"BL)"0DO*B!I;B!T
M:&4@8V%S92!O9B!S:6UP;&4@8V]N9&ET:6]N+"!C:&5C:R!F;W(@;6]D:69I
M8V%T:6]N(&]F#0T**PD)"2`J(&]N92!O9B!T:&4@<VED97,N(%1H:7,@=VEL
M;"!H96QP('5S(&EN(&-A<V5S(&QI:V4@#0T**PD)"2`J('=H:6QE*&QE;BTM
M*2`J+PT-"BL-#0HK"0D)9F]R*&D],#MI(#P@,CL@:2LK*7L-#0HK#0T**PD)
M"0EI9BAB;&EP7V1E8VQ?;6]D:69I960H9&5C;"`L(%12145?3U!%4D%.1"AT
M+&DI*2D-#0HK"0D)"0ER971U<FX@=')U93L-#0HK"0D)?0T-"BL-#0HK"0D)
M<F5T=7)N(&9A;'-E.PT-"BL-#0HK"0D)#0T**PD)9&5F875L=#H-#0HK"0D)
M<F5T=7)N(&9A;'-E.PT-"BL)"0T-"BL)?0T-"BL-#0HK"7)E='5R;B!F86QS
M93L)#0T**WT-#0HK#0T**R\J(&9I;F0@82!D96-L(&]U="!O9B!P87)E;G0@
M97AP<B!O<&5R86YD+B!M;W-T('-I;7!L92!C87-E(&ES('=H96X-#0HK("H@
M;W`@:7,@=&AE(&1E8VP@:71S96QF+B!A;F]T:&5R('-U<'!O<G1E9"!C87-E
M(&ES('=H96X@=&AE(&]P(&ES(&$-#0HK("H@;6]D:69Y(&]R(&EN8W)E;65N
M="`O(&1E8W)E;65N="!E>'!R+"!I;B!T:&ES(&-A<V4@=&AE(&9I<G-T(&]P
M97)A;F0-#0HK("H@=VEL;"!B92!T:&4@;&]O:V5D(&9O<B!D96-L+B`-#0HK
M("H-#0HK("H@:6X@8V%S97,@;W1H97(@=&AE;B!T:&]S92P@=V4@=VEL;"!N
M;W0@9FEN9"!T:&4@9&5C;"X@*B\-#0HK#0T**W1R964-#0HK8FQI<%]F:6YD
M7V1E8VPH;W`I#0T**PET<F5E(&]P.PT-"BM[#0T**PT-"BL)<W=I=&-H*"!4
M4D5%7T-/1$4H;W`I*7L-#0HK"0EC87-E(%9!4E]$14-,.@T-"BL)"6-A<V4@
M4$%235]$14-,.@T-"BL)"6-A<V4@1DE%3$1?1$5#3#H-#0HK"0EC87-E($E.
M5$5'15)?0U-4.@T-"BL-#0HK"0D)<F5T=7)N(&]P.PT-"BL)"0D-#0HK"0DO
M*B!I9B!S:6UP;&4@97AP<B!L;V]K(&EN<VED92XJ+PT-"BL)"6-A<V4@4%)%
M1$5#4D5-14Y47T584%(Z#0T**PD)8V%S92!04D5)3D-214U%3E1?15A04CH-
M#0HK"0EC87-E(%!/4U1$14-214U%3E1?15A04CH-#0HK"0EC87-E(%!/4U1)
M3D-214U%3E1?15A04CH-#0HK#0T**PD)"7)E='5R;B!B;&EP7V9I;F1?9&5C
M;"A44D5%7T]015)!3D0@*&]P+#`I*3L-#0HK"0D)#0T**PD)+RH@:6X@8V%S
M92!L;V]P('9A<B!N965D(&-O;G9E<G1I;VXL('=E('=I;&P@9FEN9"!S;VUE
M(`T-"BL)"2`J(&YO<"!E>'!R97-S:6]N<R`J+PT-"BL)"6-A<V4@3D]07T58
M4%(Z#0T**PD)8V%S92!#3TY615)47T584%(Z#0T**PD)"0T-"BL)"0ER971U
M<FX@8FQI<%]F:6YD7V1E8VPH5%)%15]/4$5204Y$("AO<"PP*2D[#0T**PD)
M#0T**PD)9&5F875L=#H-#0HK"0D)<F5T=7)N($Y53$P[#0T**PE]#0T**WT-
M#0HK#0T**R\J(&QO;VL@:6YS:61E(&$@0T%,3%]%6%!2+"!A;F0@9FEN9"!T
M:&4@9G5N8W1I;VX@;F%M92X@=&AE;B!S96%R8V@@#0T**R`J(&9U;F-T:6]N
M(&YA;64@:6X@8FQI<"!L:7-T+"!A;F0@8W)E871E(&$@(FQO;W!?;&EM:70B
M('-T=7)C="!U<VEN9PT-"BL@*B!T:&4@3BUT:"!P87)A;2!A<R!L:6UI="P@
M8V]N<W1A;G0@,"!A<R!C;W5N=&5R+"!A;F0@<V5T(&1I<F5C=&EO;B`-#0HK
M("H@=&\@:6YC<F5M96YT+B`J+PT-"BMB;V]L#0T**V)L:7!?9FEN9%]C86QL
M7VQI;6ET<RAC86QL+'!A<F%M<RD-#0HK"71R964)8V%L;#L-#0HK"71R964)
M<&%R86US.PT-"BM[#0T**PT-"BL)=')E90EF=6YC7V1E8VPL<&%R86T[#0T*
M*PEI;G0)"6DL<&%R86U?:6YD97@]+3$[#0T**PT-"BL)+RH@=7!D871E('-T
M871I<W1I8W,@8V]U;G1E<G,@*B\-#0HK"6)L:7!?<W1A="YT;W1A;%]C:&5C
M:W,K*SL-#0HK"6)L:7!?<W1A="YC86QL7V-H96-K<RLK.PT-"BL)#0T**PEI
M9B@A8V%L;"!\?`T-"BL)"2%44D5%7T]015)!3D0H8V%L;"PP*7Q\#0T**PD)
M5%)%15]#3T1%("A44D5%7T]015)!3D0@*&-A;&PL,"DI("$]($%$1%)?15A0
M4B!\?`T-"BL)"2%44D5%7T]015)!3D0H5%)%15]/4$5204Y$("AC86QL+#`I
M+#`I*7L-#0HK"0D-#0HK"0EB;&EP7W=A<FYI;F<H3D5?0T%,3"PB8FQI<#H@
M8V%L;"!E>'!R(&1O;G0@:&%V92!A9&1R97-S(&5X<'(B*3L)#0T**PD)<F5T
M=7)N(&9A;'-E.PT-"BL)?0T-"BL-#0HK"69U;F-?9&5C;"`](%12145?3U!%
M4D%.1"`H5%)%15]/4$5204Y$("AC86QL+#`I+#`I.PT-"BL):68H(%12145?
M0T]$12`H9G5N8U]D96-L*2`A/2!&54Y#5$E/3E]$14-,('Q\#0T**PD)(41%
M0TQ?3D%-12`H9G5N8U]D96-L*2!\?`T-"BL)"2$@241%3E1)1DE%4E]03TE.
M5$52("@@1$5#3%].04U%*&9U;F-?9&5C;"DI*7L-#0HK#0T**PD)8FQI<%]W
M87)N:6YG*$Y%7T-!3$PL(F)L:7`Z(&-A;&P@8GD@<&]I;G1E<B!T;R!F=6YC
M=&EO;B!N;W0@<W5P<&]R=&5D(BD[#0T**PD@("`)<F5T=7)N(&9A;'-E.PT-
M"BL)?0T-"BL-#0HK#0T**PEF;W(H:3TP.R!S=')L96XH;&]O<%]L:6ME<UMI
M72YF=6YC7VYA;64I(#X@,#MI*RLI>PT-"BL)"6EF*'-T<F-M<"A)1$5.5$E&
M24527U!/24Y415(@*$1%0TQ?3D%-12`H9G5N8U]D96-L*2DL#0T**PD)"0D)
M;&]O<%]L:6ME<UMI72YF=6YC7VYA;64I/3TP*7L-#0HK"0D)#0T**PD)"7!A
M<F%M7VEN9&5X(#T@;&]O<%]L:6ME<UMI72YP87)A;5]I;F1E>#L-#0HK"0D)
M8G)E86L[#0T**PD)?0T-"BL)?0T-"BL)#0T**PDO*B!I9B!F=6YC=&EO;B!N
M;W0@9F]U;F0@:6X@;&]O<%]L:6ME<R!L:7-T('1H96X@9&]N="!C;W5N=`T-
M"BL)("H@:70@:6X@=&AE(&)L:7!?<W1A="`J+PT-"BL):68H<&%R86U?:6YD
M97@@/"`P*7L-#0HK"0EB;&EP7W-T870N=&]T86Q?8VAE8VMS+2T[#0T**PD)
M8FQI<%]S=&%T+F-A;&Q?8VAE8VMS+2T[#0T**PD)<F5T=7)N(&9A;'-E.PT-
M"BL)?0T-"BL)"0D-#0HK#0T**PEP87)A;2`]('!A<F%M<SL-#0HK"69O<BAI
M/3`[(&D@/"!P87)A;5]I;F1E>"`F)B!P87)A;3L@:2LK*7L-#0HK"0EP87)A
M;2`](%12145?0TA!24X@*'!A<F%M*3L-#0HK"7T-#0HK"0T-"BL):68H(7!A
M<F%M*2!R971U<FX@9F%L<V4[#0T**PD-#0HK"6QO;W!?;&EM:70N;&EM:70@
M/2!44D5%7U9!3%5%("AP87)A;2D[#0T**PT-"BL)+RH@:68@<&%R86T@:7,@
M8V%L8W5L871E9"!U<VEN9R!A(&9U;F-T:6]N+"!D;VYT(&EN8VQU9&4@=&AA
M=`T-"BL)("H@97AP<B!I;B!T:&4@8VAE8VLL(&ET<R!W87D@=&]O(')I<VMY
M+B`J+PT-"BL):68H5%)%15]3241%7T5&1D5#5%,@*&QO;W!?;&EM:70N;&EM
M:70I*7L-#0HK"0EB;&EP7W=A<FYI;F<H3D5?0T%,3"PB8FQI<#H@<&%R86T@
M<V5E;7,@=&\@:&%V92!S:61E(&5F9F5C=',B*3L-#0HK"0ER971U<FX@9F%L
M<V4["0D-#0HK"7T-#0HK"0T-"BL);&]O<%]L:6UI="YC;W5N=&5R(#T@:6YT
M96=E<E]Z97)O7VYO9&4[#0T**R`@"6QO;W!?;&EM:70N9&ER(#T@24Y#4D5-
M14Y4.PD-#0HK"0T-"BL)+RH@86QL('-E96US('1O(&)E(&]K+"!W92!F;W5N
M9"!T:&4@;&EM:71S+"!A;F0@=V4@8V%N(`T-"BL)("H@8V]N=&EN=64@=VET
M:"!E;6ET:6<@=&AE(&)L:7`@8VAE8VLN("HO#0T**PD-#0HK"7)E='5R;B!T
M<G5E.PT-"BM]#0T**PT-"BL-#0HK+RH@3&]O:R!I;G-I9&4@82!L;V]P(&-O
M;F1I=&EO;BX@9FER<W0@8VAE8VL@:68@8V]N9&ET:6]N(&ES('1O;R`-#0HK
M("H@8V]M<&QI8V%T960N(&EF(&ET(&ES+"!R971U<FX@3E5,3"`O+R!&25A-
M12!R961U8V4@(F-O;7!L:6-A=&5D(B!S970-#0HK("H-#0HK("H@9F]R(&5A
M8V@@9&5C;"!I;B!T:&4@8V]N9&ET:6]N+"!C:&5C:R!I9B!D96-L(&ES(&UO
M9&EF:65D(&5I=&AE<@T-"BL@*B!I;B!C;VYD(&]R(&5X<'(N(&EF(&ET)W,@
M;6]D:69I960@8V]N<VED97(@:70@87,@=&AE(&-O=6YT97(N#0T**R`J(&EF
M(&UO<F4@=&AE;B!O;F4@8V]U;G1E<B!F;W5N9"!R971U<FX@3E5,3"X@*B\-
M#0HK#0T**V)O;VP-#0HK8FQI<%]F:6YD7VQO;W!?=F%R<RAC;VYD+&5X<'(I
M#0T**PET<F5E"6-O;F0[#0T**PET<F5E"65X<'([#0T**WL-#0HK#0T**PET
M<F5E"61E8VP],#L-#0HK"6EN=`D):2QN=6U?;6]D:69I960],#L-#0HK#0T*
M*PEI9B@A8V]N9"D@<F5T=7)N(&9A;'-E.PT-"BL)#0T**PDO*B!F:7)S="!V
M97)S:6]N('=I;&P@<W5P<&]R="!O;FQY('9E<GD@<VEM<&QE(&-O;F1I=&EO
M;G,@*B\)#0T**PES=VET8V@H5%)%15]#3T1%("AC;VYD*2E[#0T**PD)8V%S
M92!,5%]%6%!2.@T-"BL)"6-A<V4@3$5?15A04CH-#0HK"0EC87-E($=%7T58
M4%(Z#0T**PD)8V%S92!'5%]%6%!2.@T-"BL)"6-A<V4@15%?15A04CH-#0HK
M"0EC87-E($Y%7T584%(Z#0T**PT-"BL)"0DO*B!F:6YD(&1E8VP@=VEL;"!G
M970@86X@;W!E<F%N9"!A;F0@<F5T=7)N('1H92`B;6%I;B(-#0HK"0D)("H@
M9&5C;"!T:&%T(')E<')E<W0@:70N(`T-"BL)"0D@*B`-#0HK"0D)("H@4VEN
M8V4@=&AI<R!O<&5R86YD(&ES('!A<G0@;V8@=VAA="!W92!H;W!E(&$@8V]U
M;G1E<@T-"BL)"0D@*B!C;VYD:71I;VXL(&ET<R!G;VEN9R!T;R!B92!E:71H
M97(@=F%R+W!A<F%M(&1E8VP@;W(@#0T**PD)"2`J(&%N(&5X<'(@=VAI8V@@
M;W5R(')E<75E<W1E9"!D96-L(&ES('!A<G0@;V8N("HO#0T**PD)#0T**PT-
M"BL)"0EF;W(H:3TP.R!I(#P@,CL@:2LK*7L-#0HK"0D-#0HK"0D)"61E8VP@
M/2!B;&EP7V9I;F1?9&5C;"A44D5%7T]015)!3D0@*&-O;F0L:2DI.PD)"0T-
M"BL)"0D):68H(61E8VPI>PT-"BL)"0D)"6)L:7!?=V%R;FEN9RA314Q&7T-(
M14-++`T-"BL)"0D)"0D)(F)L:7`Z(&-A;G0@9FEN9"!L;V]P(&1E8VP@:6X@
M8V]N9&ET:6]N(BD[#0T**PD)"0D)+RH@8V]N9&ET:6]N('1O;R!C;VUP;&5X
M+"!R971U<FX@*B\-#0HK"0D)"0ER971U<FX@9F%L<V4[#0T**PD)"0E]#0T*
M*PT-"BL)"0D)+RH@8VAE8VL@:68@9&5C;"!I<R!M;V1I9FEE9"X@=V4@:&]P
M92!T;R!G970@80T-"BL)"0D)("H@;6]D:69I8V%T:6]N('-U8V@@87,@:6YC
M<F5M96YT(&]R(&1E8W)E;65N=`T-"BL)"0D)("H@<VEN8V4@=V4@:&%V92!T
M;R!K;F]W('1H92!L;V]P(&1I<F5C=&EO;B`J+PT-"BL)"0D):68H*&)L:7!?
M9&5C;%]M;V1I9FEE9"AD96-L+&-O;F0I('Q\#0T**PD)"0D)(&)L:7!?9&5C
M;%]M;V1I9FEE9"AD96-L+&5X<'(I*2E[#0T**PD)"0D)#0T**PD)"0D);G5M
M7VUO9&EF:65D*RL[#0T**PD)"0D);&]O<%]L:6UI="YC;W5N=&5R(#T@9&5C
M;#L-#0HK"0D)#0T**PD)"0D)#0T**PD)"0E]#0T**PD)"0DO*B!I9B!N;W0@
M;6]D:69I960@;6%Y8F4@:71S('1H92!L:6UI="`N<V%V92!I="`-#0HK"0D)
M"2`J(&EN(&-A<V4@=&AA="!W92!W:6QL(&9I;F0@;W1H97(@87,@8V]U;G1E
M<B`J+PT-"BL)"0D)96QS97L-#0HK"0D)"0EL;V]P7VQI;6ET+FQI;6ET(#T@
M9&5C;#L-#0HK"0D)"7T-#0HK"0D)?0D-#0HK"0D)#0T**PD)"6EF*&YU;5]M
M;V1I9FEE9"`]/2`Q*7L-#0HK"0D)"7)E='5R;B!T<G5E.PT-"BL)"0E]#0T*
M*PD)"0T-"BL)"0DO*B!W92!D:61N="!F;W5N9"!O;F4@*&%N9"!O;FQY(&]N
M92D@;6]D:69I960@9&5C;"X@#0T**PD)"2`J('-O('=E(&1O;G0@:VYO=R!W
M:&EC:"!I<R!T:&4@;&EM:70@*&EF(&%T(&%L;"!E>&ES="D@*B\-#0HK"0D)
M:68H;G5M7VUO9&EF:65D(#T](#`I>PT-"BL)"0D)8FQI<%]W87)N:6YG*%-%
M3$9?0TA%0TLL#0T**PD)"0D)(F)L:7`Z('=H:6-H(&QO;W`@=F%R(&ES(&UO
M9&EF:65D/R`H8F]D>2!N;W0@<V5A<F-H960I(BD[#0T**PD)"7T-#0HK"0D)
M96QS97L-#0HK"0D)"6)L:7!?=V%R;FEN9RA314Q&7T-(14-++`T-"BL)"0D)
M"2)B;&EP.B!M;W)E('1H96X@;VYE('9A<B!I<R!M;V1I9FEE9"P@=VAO(&ES
M(&-O=6YT97(_(BD[#0T**PD)"0D-#0HK"0D)?0T-"BL)"0ER971U<FX@9F%L
M<V4[#0T**PD)"0T-"BL)"0T-"BL)"61E9F%U;'0Z#0T**PD)"6)L:7!?=V%R
M;FEN9RA314Q&7T-(14-++`T-"BL)"0D)"2)B;&EP.B!C;VYD:71I;VX@:7,@
M=&]O(&-O;7!L97@@9F]R('1H:7,@=F5R<VEO;B(I.PT-"BL)"0ER971U<FX@
M9F%L<V4[#0T**PE]#0T**PD-#0HK?0T-"BL-#0HK#0T**R\J(&-H96-K(&9O
M<B!L;V]P(&QI;6ET<RX@:68@;&]O<"!S965M<R!T;R!B92!A(&-O=6YT(&QO
M;W`L(`T-"BL@*B!E;6ET(&-O9&4@=&\@8VAE8VL@;&]O<"!C;W5N=&5R(&EN
M(')U;BUT:6UE+B!T:&%T(&-O9&4@=VEL;`T-"BL@*B!M86ME('-U<F4@=&AE
M(&-O=6YT97(@:7,@;F]T('1O;R!B:6<@*&%S(')E<W5L="!O9B!I;G0@;W9E
M<F9L;W<-#0HK("H@97AP;&]I=&%T:6]N*2`J+PT-"BL-#0HK("`@#0T**W1R
M964-#0HK8FQI<%]C:&5C:U]L;V]P7VQI;6ET("AT*0T-"BL@("`@('1R964@
M=#L-#0HK>PT-"BL)+RH@3&]O<"!P87)T<R`J+PT-"BL)=')E90ER97-U;'0]
M=#L-#0HK#0T**PDO*B!)9B!W92!A<F4@;F]T(&%S:V5D('1O(&)L:7`L(')E
M='5R;B!T:&4@=')E92!W92!G;W0@*B\-#0HK"6EF*"%F;&%G7V)L:7`I(')E
M='5R;B!R97-U;'0[#0T**PT-"BL)+RH@268@=&AE('1R964@=V4@9V]T(&ES
M(&YU;&P@=&AE;B!W92!C86YT(&1O(&UU8V@@*B\-#0HK"6EF*"%T*0ER971U
M<FX@<F5S=6QT.PT-"BL-#0HK"2\J(&EN:71I86QI>F4@;&]O<%]L:6UI="!G
M;&]B86P@*B\-#0HK"6QO;W!?;&EM:70N<W1M="`]('0[#0T**PEL;V]P7VQI
M;6ET+F-O=6YT97(@/2!.54Q,.PT-"BL);&]O<%]L:6UI="YL:6UI="`]($Y5
M3$P[#0T**PEL;V]P7VQI;6ET+F1I<B`](%5.2TY/5TX[#0T**PT-"BL-#0HK
M"0T-"BL)#0T**PES=VET8V@H5%)%15]#3T1%("AT*2E[#0T**PD-#0HK"2\J
M(&1E<&5N9&EN9R!O9B!L;V]P('1Y<&4L(&5X=')A8W0@=&AE(&QO;W`@<W1M
M=',@86YD(&5X<')S#0T**PD@*B!L;V]P(&-O;F1I=&EO;B!W:6QL(&AE;'`@
M=7,@:61E;G1I9GD@=&AE(&QO;W`@8V]U;G1E<B!V87(-#0HK"2`J('=E('=I
M;&P@;&%T97(@;&]O:R!I;B!C;VYD(&ET<V5L9B!A;F0@=&AE(&9O<E]E>'!R
M(&9O<B`-#0HK"2`J(&UO9&EF:6-A=&EO;B!O9B!V87)S(&]F(&-O;F1I=&EO
M;BX@#0T**PD@*@T-"BL)("H@:68@;6]D:69I8V%T:6]N(&9O=6YD(&%N9"!L
M;V]K(&QI:V4@82`B8V]U;G0B(&UO9&EF:6-A=&EO;B`-#0HK"2`J("AI+F4N
M("LK+"TM+"L]+"H]+BX@971C*2!W92!W:6QL(&MN;W<@:71S(&$@(F-O=6YT
M(B!L;V]P+@T-"BL)("H@"0T-"BL)("H@;F5X="!S=&5P+"!I<R!T;R!I9&5N
M=&EF>2!C;VYD:71I;VX@97AP<F5S:6]N+B!A;F0@=&\@96UI=`T-"BL)("H@
M8V]D92!T;R!C:&5C:R!L:6UI="!I;B!R=6YT:6UE+"!B969O<F4@;&]O<"!S
M=&%R="!E>&5U8W1I;VX@("HO#0T**PT-"BL)8V%S92!&3U)?4U1-5#H-#0HK
M"0EB;&EP7W-T870N9F]R7V-H96-K<RLK.PT-"BL)"6)L:7!?<W1A="YT;W1A
M;%]C:&5C:W,K*SL-#0HK"0D)#0T**PD):68H8FQI<%]F:6YD7VQO;W!?=F%R
M<RA&3U)?0T].1"`H="DL1D]27T584%(@*'0I*2D-#0HK"0D):68H8FQI<%]E
M;6ET7V9O<E]L;V]P7V-H96-K<RAT*2E[#0T**PD)"0EB;&EP7W-T870N=&]T
M86Q?96UI=',K*SL-#0HK"0D)"6)L:7!?<W1A="YF;W)?96UI=',K*SL-#0HK
M"0D)?0T-"BL-#0HK"0EB<F5A:SL-#0HK"6-A<V4@5TA)3$5?4U1-5#H-#0HK
M"0EB;&EP7W-T870N=VAI;&5?8VAE8VMS*RL[#0T**PD)8FQI<%]S=&%T+G1O
M=&%L7V-H96-K<RLK.PT-"BL-#0HK"0EI9BAB;&EP7V9I;F1?;&]O<%]V87)S
M*%=(24Q%7T-/3D0@*'0I+$Y53$Q?5%)%12DI#0T**PD)"6EF*&)L:7!?96UI
M=%]W:&EL95]L;V]P7V-H96-K<R@I*7L-#0HK"0D)"6)L:7!?<W1A="YT;W1A
M;%]E;6ET<RLK.PT-"BL)"0D)8FQI<%]S=&%T+G=H:6QE7V5M:71S*RL[#0T*
M*PD)"7T-#0HK"0T-"BL)"6)R96%K.PT-"BL)8V%S92!#04Q,7T584%(Z#0T*
M*PD)#0T**PD):68H8FQI<%]F:6YD7V-A;&Q?;&EM:71S*'0L5%)%15]/4$52
M04Y$("AT+#$I*2D-#0HK"0D)<F5S=6QT(#T@8FQI<%]E;6ET7V-A;&Q?8VAE
M8VMS*'0I.PD)#0T**PT-"BL)"6EF*')E<W5L="`A/2!T*7L-#0HK"0D)8FQI
M<%]S=&%T+G1O=&%L7V5M:71S*RL[#0T**PD)"6)L:7!?<W1A="YC86QL7V5M
M:71S*RL[#0T**PD)?0T-"BL)"0T-"BL)"6)R96%K.PD-#0HK"61E9F%U;'0Z
M#0T**PD)<F5T=7)N(')E<W5L=#L-#0HK"7T-#0HK#0T**PER971U<FX@<F5S
M=6QT.PT-"BL)#0T**WT-#0ID:69F("U.=7(@9V-C+3,N,B]G8V,O8FQI<"YH
M(&=C8RTS+C(M8FQI<"]G8V,O8FQI<"YH#0HM+2T@9V-C+3,N,B]G8V,O8FQI
M<"YH"5=E9"!$96,@,S$@,38Z,#`Z,#`@,3DV.0T**RLK(&=C8RTS+C(M8FQI
M<"]G8V,O8FQI<"YH"4UO;B!$96,@(#(@,3DZ-#(Z,SD@,C`P,@T*0$`@+3`L
M,"`K,2PY.2!`0`T**R\J#0HK#0HK"4)I9R!,;V]P($EN=&5G97(@4')O=&5C
M=&EO;B`M($$N2RY!(")B;&EP(@T**PT**PEB;&EP(&ES(&$@<&%T8V@@9F]R
M('1H92!G8V,@8V]M<&EL97(L('=H:6-H(&1E=&5C="!T:&4@97AP;&]I=&%T
M:6]N#0HK"6]F("AP=6)L:6-L>2D@=6YK;F]W;B!I;G1E9V5R(&]V97)F;&]W
M(&%N9"!S:6=N('9U;&YE<F%B:6QI=&EE<RX-"BL-"BL@("`-"BM4:&ES(&9I
M;&4@:7,@<&%R="!O9B!'3E4@0T,N#0HK#0HK1TY5($-#(&ES(&9R964@<V]F
M='=A<F4[('EO=2!C86X@<F5D:7-T<FEB=71E(&ET(&%N9"]O<B!M;V1I9GD-
M"BMI="!U;F1E<B!T:&4@=&5R;7,@;V8@=&AE($=.52!'96YE<F%L(%!U8FQI
M8R!,:6-E;G-E(&%S('!U8FQI<VAE9"!B>0T**W1H92!&<F5E(%-O9G1W87)E
M($9O=6YD871I;VX[(&5I=&AE<B!V97)S:6]N(#(L(&]R("AA="!Y;W5R(&]P
M=&EO;BD-"BMA;GD@;&%T97(@=F5R<VEO;BX-"BL-"BM'3E4@0T,@:7,@9&ES
M=')I8G5T960@:6X@=&AE(&AO<&4@=&AA="!I="!W:6QL(&)E('5S969U;"P-
M"BL)8G5T(%=)5$A/550@04Y9(%=!4E)!3E19.R!W:71H;W5T(&5V96X@=&AE
M(&EM<&QI960@=V%R<F%N='D@;V8-"BL)34520TA!3E1!0DE,2519(&]R($9)
M5$Y%4U,@1D]2($$@4$%25$E#54Q!4B!055)03U-%+B`@4V5E('1H90T**PE'
M3E4@1V5N97)A;"!0=6)L:6,@3&EC96YS92!F;W(@;6]R92!D971A:6QS+@T*
M*PT**PE9;W4@<VAO=6QD(&AA=F4@<F5C96EV960@82!C;W!Y(&]F('1H92!'
M3E4@1V5N97)A;"!0=6)L:6,@3&EC96YS90T**PEA;&]N9R!W:71H($=.52!#
M0SL@<V5E('1H92!F:6QE($-/4%E)3D<N("!)9B!N;W0L('=R:71E('1O#0HK
M"71H92!&<F5E(%-O9G1W87)E($9O=6YD871I;VXL(#4Y(%1E;7!L92!0;&%C
M92`M(%-U:71E(#,S,"P-"BL)0F]S=&]N+"!-02`P,C$Q,2TQ,S`W+"!54T$N
M("`J+PT**PT**R-D969I;F4@0DQ)4%]-05@),'@Q,#`P,#`P,"`O*B`R-38@
M34(@<V5E;7,@=V%Y('1O;R!M=6-H(&)I9R!L;V]P+BXN*B\-"BL-"BMT>7!E
M9&5F(&5N=6T@;&]O<%]D:7(-"BM[#0HK"55.2TY/5TY?1$E2+"\J('=E(&-A
M;FYO="!T96QL(&QO;W`@9&ER96-T:6]N("HO#0HK"4E.0U)%345.5"P)+RH@
M;&]O<"!I<R!G;VEN9R!U<"`J+PT**PE$14-214U%3E0)+RH@;&]O<"!I<R!G
M;VEN9R!D;W=N("HO#0HK?0T**VQO;W!?9&ER.PT**PT**W1Y<&5D968@96YU
M;2!B;&EP7W=A<FYI;F=S#0HK>PT**PE314Q&7T-(14-++`DO*B!U<VEN9R!T
M:&4@5%)%12!O8FIE8W0@9FEN9"!O=70@=&AE(')I9VAT#0HK"0D)"2`@('=A
M<FYI;F<@9FQA9R`J+PT**PE.15]&3U(L"0DO*B!W87)N(&YO="!E;6ET:6YG
M(&-H96-K(&9O<B!F;W(@;&]O<',@*B\-"BL)3D5?5TA)3$4L"2\J('=A<FX@
M;F]T(&5M:71I;F<@8VAE8VL@9F]R('=H:6QE(&QO;W!S("HO#0HK"4Y%7T-!
M3$P)"2\J('=A<FX@;F]T(&5M:71I;F<@8VAE8VL@9F]R(&-A;&QS("HO#0HK
M?0T**V)L:7!?=V%R;FEN9W,[#0HK#0HK='EP961E9B!S=')U8W0@7VQO;W!?
M;&EM:71?<WL-"BL)=')E92!S=&UT.PD-"BL)=')E92!C;W5N=&5R.PT**PET
M<F5E(&QI;6ET.PT**PEE;G5M(&QO;W!?9&ER(&1I<CL-"BL):6YT"2!L:6YE
M;F\[#0HK#0HK?6QO;W!?;&EM:71?<SL-"BL-"BLO*B!B;&EP('-T871I<W1I
M8W,@<W1R=6-T=7)E+"!W:6QL(&UA:6YT86EN('1H92!A;6]U;G0@;V8@96YC
M;W5T97)D(`T**R`J(&-O9&4@=&AA="!M:6=H="!H879E(&YE961E9"!A(&)L
M:7`@8VAE8VLL(&%N9"!T:&4@<F5A;"!A;6]U;G0@;V8@#0HK("H@=&EM97,@
M=&AA="!A(&)L:7`@8VAE8VL@=V%S(&5M:71E9"X@*B\-"BMT>7!E9&5F('-T
M<G5C="!?8FQI<%]S=&%T:7-T:6-S7W-[#0HK"75N<VEG;F5D(&EN=`ET;W1A
M;%]C:&5C:W,[#0HK"75N<VEG;F5D(&EN=`ET;W1A;%]E;6ET<SL-"BL)#0HK
M"75N<VEG;F5D(&EN=`EF;W)?8VAE8VMS.PT**PEU;G-I9VYE9"!I;G0)=VAI
M;&5?8VAE8VMS.PT**PEU;G-I9VYE9"!I;G0)8V%L;%]C:&5C:W,[#0HK"0T*
M*PEU;G-I9VYE9"!I;G0)9F]R7V5M:71S.PT**PEU;G-I9VYE9"!I;G0)=VAI
M;&5?96UI=',[#0HK"75N<VEG;F5D(&EN=`EC86QL7V5M:71S.PT**WUB;&EP
M7W-T871I<W1I8W-?<SL-"BL-"BLO*B!.54Q,('1E<FUI;F%T960@;&ES="!O
M9B!F=6YC=&EO;B!W:&EC:"!A<F4@86QM;W-T('1H92!S86UE(&%S(&$@#0HK
M("H@;&]O<"X@:2YE(&UE;6-P>2P@;65M;6]V92XN(&9O<B!E86-H(&9U;F-T
M:6]N('=E('=I;&P@<V%V92!T:&4@#0HK("H@;F%M92!O9B!T:&4@9G5N8W1I
M;VX@87,@=V5L;"!A<R!T:&4@,"!B87-E9"!I;F1E>"!T;R!T:&4@<&%R86T@
M#0HK("H@=VAI8V@@:7,@<W5P<&]S92!T;R!H879E('1H92!L96YG=&@@=F%R
M:6%B;&4@*B\-"BL-"BMT>7!E9&5F('-T<G5C="!?;&]O<%]L:6ME7W-[#0HK
M"6-H87()"0EF=6YC7VYA;65;,C4V73L-"BL)=6YS:6=N960@:6YT"7!A<F%M
M7VEN9&5X.PT**WUL;V]P7VQI:V5?<SL-"BL-"BL-"BL-"BMV;VED(&)L:7!?
M<W1A=%]P<FEN=`D)"5!!4D%-4R`H*$9)3$4J*2D[#0HK#0HK8F]O;"!B;&EP
M7V1E8VQ?;6]D:69I960@("`@("`@("!005)!35,@*"AT<F5E+'1R964I*3L-
M"BMT<F5E(&)L:7!?9FEN9%]D96-L("`@("`@("`@("`@(%!!4D%-4R`H*'1R
M964I*3L-"BMB;V]L(&)L:7!?9FEN9%]L;V]P7W9A<G,@("`@("`@(%!!4D%-
M4R`H*'1R964L=')E92DI.PT**V)O;VP@8FQI<%]F:6YD7V-A;&Q?;&EM:71S
M("`@("`@4$%204U3("@H=')E92QT<F5E*2D[#0HK#0HK8F]O;"!B;&EP7V5M
M:71?9F]R7VQO;W!?8VAE8VMS("`@("`@4$%204U3("@H=')E92DI.PT**V)O
M;VP@8FQI<%]E;6ET7W=H:6QE7VQO;W!?8VAE8VMS("`@(%!!4D%-4R`H*'9O
M:60I*3L-"BMT<F5E(&)L:7!?96UI=%]C86QL7V-H96-K<R`@("`@("`@("!0
M05)!35,@*"AT<F5E*2D[#0HK#0HK=')E92!B;&EP7V)U:6QD7V-H96-K7W-T
M;70@("`@("!005)!35,@*"AT<F5E*2D[#0HK=')E92!B;&EP7V)U:6QD7V-H
M96-K7V5X<"`@("`@("!005)!35,@*"AT<F5E*2D[#0HK=')E92!B;&EP7V)U
M:6QD7W9I;VQA=&EO;E]C86QL("!005)!35,@*"AT<F5E*2D[#0HK#0HK=')E
M92!B;&EP7V-H96-K7VQO;W!?;&EM:70)"5!!4D%-4R`H*'1R964I*3L-"BMV
M;VED(&)L:7!?=V%R;FEN9PD)"0E005)!35,@*"AE;G5M(&)L:7!?=V%R;FEN
M9W,L8V]N<W0@8VAA<BHI*3L-"F1I9F8@+4YU<B!G8V,M,RXR+V=C8R]C+6]B
M:F,M8V]M;6]N+F,@9V-C+3,N,BUB;&EP+V=C8R]C+6]B:F,M8V]M;6]N+F,-
M"BTM+2!G8V,M,RXR+V=C8R]C+6]B:F,M8V]M;6]N+F,)5&AU($UA<B`R."`Q
M,#HT.3HU."`R,#`R#0HK*RL@9V-C+3,N,BUB;&EP+V=C8R]C+6]B:F,M8V]M
M;6]N+F,)36]N($1E8R`@,B`Q.3HT,CHS.2`R,#`R#0I`0"`M-C(L-B`K-C(L
M.2!`0`T*("`@:68@*&QO;VMU<%]A='1R:6)U=&4@*")A;'=A>7-?:6YL:6YE
M(BP@1$5#3%]!5%1224)55$53("AF;BDI("$]($Y53$PI#0H@("`@(')E='5R
M;B`Q.PT*(`T**R`@:68H1$5#3%],04Y'7U-014-)1DE#("AF;BD@/3T@3E5,
M3"D@#0HK"2`@<F5T=7)N(#`[#0HK("`-"B`@(')E='5R;B!$14-,7T1%0TQ!
M4D5$7TE.3$E.15]0("AF;BD@)B8@1$5#3%]%6%1%4DY!3"`H9FXI.PT*('T-
M"B`-"F1I9F8@+4YU<B!G8V,M,RXR+V=C8R]C+7!A<G-E+GD@9V-C+3,N,BUB
M;&EP+V=C8R]C+7!A<G-E+GD-"BTM+2!G8V,M,RXR+V=C8R]C+7!A<G-E+GD)
M5V5D($%U9R`Q-"`P,CHS,CHS-2`R,#`R#0HK*RL@9V-C+3,N,BUB;&EP+V=C
M8R]C+7!A<G-E+GD)36]N($1E8R`@,B`Q.3HT,CHS.2`R,#`R#0I`0"`M-#8L
M-B`K-#8L-R!`0`T*("-I;F-L=61E(")O=71P=70N:"(-"B`C:6YC;'5D92`B
M=&]P;&5V+F@B#0H@(VEN8VQU9&4@(F=G8RYH(@T**R-I;F-L=61E(")B;&EP
M+F@B#0H@("`-"B`C:69D968@355,5$E"651%7T-(05)3#0H@(VEN8VQU9&4@
M/&QO8V%L92YH/@T*0$`@+3(Q.3$L.2`K,C$Y,BPQ,"!`0`T*("`@("`@("`@
M("`@("`@("![("0T(#T@=')U=&AV86QU95]C;VYV97)S:6]N("@D-"D[#0H@
M"0D@(&-?9FEN:7-H7W=H:6QE7W-T;71?8V]N9"`H=')U=&AV86QU95]C;VYV
M97)S:6]N("@D-"DL#0H@"0D)"0D@("`@)#QT='EP93XR*3L-"BL)"0EB;&EP
M7V-H96-K7VQO;W!?;&EM:70@*"0\='1Y<&4^,BD[#0H@"0D@("0\='1Y<&4^
M)"`](&%D9%]S=&UT("@D/'1T>7!E/C(I.R!]#0H@"2`@8SDY7V)L;V-K7VQI
M;F5N;U]L86)E;&5D7W-T;70-"BT)"7L@4D5#2$%)3E]35$U44R`H)#QT='EP
M93XV+"!72$E,15]"3T19("@D/'1T>7!E/C8I*3L@?0T**PD)>R!214-(04E.
M7U-43513("@D/'1T>7!E/C8L(%=(24Q%7T)/1%D@*"0\='1Y<&4^-BDI.WT-
M"B`)?"!D;U]S=&UT7W-T87)T#0H@"2`@)R@G(&5X<'(@)RDG("<[)PT*("`@
M("`@("`@("`@("`@("#,I.R!]#0I`0"`M,C(Q,BPW("LR,C$T+#@@0$`-"B`)("!X
M97AP<B`G*2<-"B`)"7L@1D]27T584%(@*"0\='1Y<&4^,BD@/2`D.3L@?0T*
M(`D@(&,Y.5]B;&]C:U]L:6YE;F]?;&%B96QE9%]S=&UT#0HM("`@("`@("`@
M("`@("`@('L@4D5#2$%)3E]35$U44R`H)#QT='EP93XR+"!&3U)?0D]$62`H
M)#QT='EP93XR*2D[('T-"BL@("`@("`@("`@("`@("`@>R!214-(04E.7U-4
M3513("@D/'1T>7!E/C(L($9/4E]"3T19("@D/'1T>7!E/C(I*3L-"BL)"0D)
M("!B;&EP7V-H96-K7VQO;W!?;&EM:70@*"0\='1Y<&4^,BD[('T-"B`)?"!3
M5TE40T@@)R@G(&5X<'(@)RDG#0H@"0E[('-T;71?8V]U;G0K*SL-"B`)"2`@
M)#QT='EP93XD(#T@8U]S=&%R=%]C87-E("@D,RD[('T-"F1I9F8@+4YU<B!G
M8V,M,RXR+V=C8R]C+71Y<&5C:RYC(&=C8RTS+C(M8FQI<"]G8V,O8RUT>7!E
M8VLN8PT*+2TM(&=C8RTS+C(O9V-C+V,M='EP96-K+F,)5&AU($UA<B`R,2`Q
M-SHU,SHS.2`R,#`R#0HK*RL@9V-C+3,N,BUB;&EP+V=C8R]C+71Y<&5C:RYC
M"4UO;B!$96,@(#(@,3DZ-#(Z,SD@,C`P,@T*0$`@+30R+#8@*S0R+#<@0$`-
M"B`C:6YC;'5D92`B:6YT;"YH(@T*("-I;F-L=61E(")G9V,N:"(-"B`C:6YC
M;'5D92`B=&%R9V5T+F@B#0HK(VEN8VQU9&4@(F)L:7`N:"(-"B`-"B`O*B!.
M;VYZ97)O(&EF('=E)W9E(&%L<F5A9'D@<')I;G1E9"!A(")M:7-S:6YG(&)R
M86-E<R!A<F]U;F0@:6YI=&EA;&EZ97(B#0H@("`@;65S<V%G92!W:71H:6X@
M=&AI<R!I;FET:6%L:7IE<BX@("HO#0I`0"`M,34X-RPV("LQ-3@X+#$Q($!`
M#0H@("!44D5%7U-)1$5?149&14-44R`H<F5S=6QT*2`](#$[#0H@("!R97-U
M;'0@/2!F;VQD("AR97-U;'0I.PT*(`T**R`@+RH@8VAE8VL@=&AE(&YE=R!C
M<F5A=&5D($-!3$Q?15A04B!F;W(@8FQI<"!C;VYD:71I;VXN(`T**R`@("H@
M:68@8VAE8VL@8V]D92!R97%U:7)E9"P@=&AE($-!3$Q?15A04B!W:6QL(&)E
M(')E<&QA8V5D('=I=&@@80T**R`@("H@0T].1%]%6%!2(&AA=FEN9R!T:&4@
M0T%,3%]%6%!2(&]N(&ET<R!F86QS92!S:61E+B`J+PT**R`@<F5S=6QT(#T@
M8FQI<%]C:&5C:U]L;V]P7VQI;6ET*')E<W5L="D[#0HK#0H@("!I9B`H5D])
M1%]465!%7U`@*%12145?5%E012`H<F5S=6QT*2DI#0H@("`@(')E='5R;B!R
M97-U;'0[#0H@("!R971U<FX@<F5Q=6ER95]C;VUP;&5T95]T>7!E("AR97-U
M;'0I.PT*9&EF9B`M3G5R(&=C8RTS+C(O9V-C+V9L86=S+F@@9V-C+3,N,BUB
M;&EP+V=C8R]F;&%G<RYH#0HM+2T@9V-C+3,N,B]G8V,O9FQA9W,N:`E4:'4@
M36%R(#(Q(#$U.C$R.C(Q(#(P,#(-"BLK*R!G8V,M,RXR+6)L:7`O9V-C+V9L
M86=S+F@)36]N($1E8R`@,B`Q.3HT,CHS.2`R,#`R#0I`0"`M-C0Q+#0@*S8T
M,2PQ.2!`0`T*("\J($YO;GIE<F\@;65A;G,@96YA8FQE('-Y;F-H<F]N;W5S
M(&5X8V5P=&EO;G,@9F]R(&YO;BUC86QL(&EN<W1R=6-T:6]N<RX@("HO#0H@
M97AT97)N(&EN="!F;&%G7VYO;E]C86QL7V5X8V5P=&EO;G,[#0H@#0HK+RH@
M3F]N>F5R;R!M96%N<R!P<FEN="!B;&EP('-T871I<W1I8W,@*&EF(&)L:7`@
M:7,@96YA8FQE9"D@*B\-"BME>'1E<FX@:6YT(&9L86=?8FQI<%]S=&%T.PT*
M*PT**R\J($YO;GIE<F\@;65A;G,@96YA8FQE(&)L:7`@8VAE8VMS(&9O<B!L
M;V]P<R!A;F0@;&]O<"UL:6ME(&-A;&QS("HO#0HK97AT97)N(&EN="!F;&%G
M7V)L:7`[#0HK#0HK+RH@5V%R;B!W:&5N(&9O<B!B;&EP(&-H96-K(&-O=6QD
M(&YO="!B92!E;6ET960N("`M5V)L:7!?9F]R7VYO=%]E;6ET+B`@*B\-"BME
M>'1E<FX@:6YT('=A<FY?8FQI<%]F;W)?;F]T7V5M:70[#0HK#0HK+RH@5V%R
M;B!W:&5N('=H:6QE(&)L:7`@8VAE8VL@8V]U;&0@;F]T(&)E(&5M:71E9"X@
M("U78FQI<%]W:&EL95]N;W1?96UI="X@("HO#0HK97AT97)N(&EN="!W87)N
M7V)L:7!?=VAI;&5?;F]T7V5M:70[#0HK#0HK+RH@5V%R;B!W:&5N(&1O(&)L
M:7`@8VAE8VL@8V]U;&0@;F]T(&)E(&5M:71E9"X@("U78FQI<%]C86QL7VYO
M=%]E;6ET+B`@*B\-"BME>'1E<FX@:6YT('=A<FY?8FQI<%]C86QL7VYO=%]E
M;6ET.PT**PT*("-E;F1I9B`O*B`A($=#0U]&3$%'4U](("HO#0ID:69F("U.
M=7(@9V-C+3,N,B]G8V,O;&EB9V-C+7-T9"YV97(@9V-C+3,N,BUB;&EP+V=C
M8R]L:6)G8V,M<W1D+G9E<@T*+2TM(&=C8RTS+C(O9V-C+VQI8F=C8RUS=&0N
M=F5R"5=E9"!*=6X@,3,@,#<Z,C8Z,#$@,C`P,0T**RLK(&=C8RTS+C(M8FQI
M<"]G8V,O;&EB9V-C+7-T9"YV97()36]N($1E8R`@,B`Q.3HT,CHS.2`R,#`R
M#0I`0"`M,3<T+#0@*S$W-"PW($!`#0H@("!?56YW:6YD7U-J3&I?4F%I<V5%
M>&-E<'1I;VX-"B`@(%]5;G=I;F1?4VI,:E]&;W)C9615;G=I;F0-"B`@(%]5
M;G=I;F1?4VI,:E]297-U;64-"BL-"BL@(",@0FEG($QO;W`@26YT96=E<B!0
M<F]T96-T:6]N("AB;&EP*2!H86YD;&5R#0HK("!?7V)L:7!?=FEO;&%T:6]N
M#0H@?0T*9&EF9B`M3G5R(&=C8RTS+C(O9V-C+VQI8F=C8S(N8R!G8V,M,RXR
M+6)L:7`O9V-C+VQI8F=C8S(N8PT*+2TM(&=C8RTS+C(O9V-C+VQI8F=C8S(N
M8PE4=64@36%Y(#(Q(#$V.C0T.C,X(#(P,#(-"BLK*R!G8V,M,RXR+6)L:7`O
M9V-C+VQI8F=C8S(N8PE-;VX@1&5C("`R(#$Y.C0R.C,Y(#(P,#(-"D!`("TR
M,#0Y+#,@*S(P-#DL,3$@0$`-"B`C96YD:68@+RH@3D5%1%]!5$58250@*B\-
M"B`-"B`C96YD:68@+RH@3%]E>&ET("HO#0HK#0HK(VEF9&5F($Q?8FQI<%]V
M:6]L871I;VX-"BMV;VED(%]?8FQI<%]V:6]L871I;VX@*'5N<VEG;F5D(&EN
M="!L:6UI="E[#0HK"0T**PEP<FEN=&8H(F)L:7`@=FEO;&%T:6]N("$A(2P@
M*'5N<VEG;F5D(&EN="DE;'4L("AI;G0I)61<;B(L;&EM:70L;&EM:70I.PT*
M*PEA8F]R="@I.PT**WT-"BLC96YD:68-"F1I9F8@+4YU<B!G8V,M,RXR+V=C
M8R]L:6)G8V,R+F@@9V-C+3,N,BUB;&EP+V=C8R]L:6)G8V,R+F@-"BTM+2!G
M8V,M,RXR+V=C8R]L:6)G8V,R+F@)5V5D($%U9R`R,B`P-SHS-3HR,B`R,#`Q
M#0HK*RL@9V-C+3,N,BUB;&EP+V=C8R]L:6)G8V,R+F@)36]N($1E8R`@,B`Q
M.3HT,CHS.2`R,#`R#0I`0"`M,C(L-B`K,C(L-R!`0`T*("-I9FYD968@1T-#
M7TQ)0D=#0S)?2`T*("-D969I;F4@1T-#7TQ)0D=#0S)?2`T*(`T**V5X=&5R
M;B!V;VED(%]?8FQI<%]V:6]L871I;VX@*'5N<VEG;F5D(&EN="!L:6UI="D[
M#0H@97AT97)N(&EN="!?7V=C8U]B8VUP("AC;VYS="!U;G-I9VYE9"!C:&%R
M("HL(&-O;G-T('5N<VEG;F5D(&-H87(@*BP@<VEZ95]T*3L-"B!E>'1E<FX@
M=F]I9"!?7V-L96%R7V-A8VAE("AC:&%R("HL(&-H87(@*BD[#0H@97AT97)N
M('9O:60@7U]E<')I;G1F("AC;VYS="!C:&%R("HL(&-O;G-T(&-H87(@*BP@
M=6YS:6=N960@:6YT+"!C;VYS="!C:&%R("HI#0ID:69F("U.=7(@9V-C+3,N
M,B]G8V,O=&]P;&5V+F,@9V-C+3,N,BUB;&EP+V=C8R]T;W!L978N8PT*+2TM
M(&=C8RTS+C(O9V-C+W1O<&QE=BYC"5-U;B!-87D@,C8@,C(Z-#@Z,34@,C`P
M,@T**RLK(&=C8RTS+C(M8FQI<"]G8V,O=&]P;&5V+F,)36]N($1E8R`@,B`Q
M.3HT,CHS.2`R,#`R#0I`0"`M-S`L-B`K-S`L-R!`0`T*("-I;F-L=61E(")D
M96)U9RYH(@T*("-I;F-L=61E(")T87)G970N:"(-"B`C:6YC;'5D92`B;&%N
M9VAO;VMS+F@B#0HK(VEN8VQU9&4@(F)L:7`N:"(-"B`-"B`C:68@9&5F:6YE
M9"`H1%=!4D8R7U5.5TE.1%])3D9/*2!\?"!D969I;F5D("A$5T%21C)?1$5"
M54='24Y'7TE.1D\I#0H@(VEN8VQU9&4@(F1W87)F,F]U="YH(@T*0$`@+3DR
M+#8@*SDS+#@@0$`-"B`C:6YC;'5D92`B:&%L9G!I8RYH(@T*("-E;F1I9@T*
M(`P-"BL-"BL-"B`O*B!#87)R>2!I;F9O<FUA=&EO;B!F<F]M($%335]$14-,
M05)%7T]"2D5#5%].04U%#0H@("`@=&\@05--7T9)3DE32%]$14-,05)%7T]"
M2D5#5"X@("HO#0H@#0I`0"`M.#8W+#8@*S@W,"PX($!`#0H@("`@1F]R(&5A
M8V@@=F%R:6%B;&4L('1H97)E(&ES(&%N(%]L;V<@=F%R:6%N="!W:&EC:"!I
M<R!T:&4@<&]W97(-"B`@("!O9B!T=V\@;F]T(&QE<W,@=&AA;B!T:&4@=F%R
M:6%B;&4L(&9O<B`N86QI9VX@;W5T<'5T+B`@*B\-"B`-"BL-"BL-"B!I;G0@
M86QI9VY?;&]O<',[#0H@:6YT(&%L:6=N7VQO;W!S7VQO9SL-"B!I;G0@86QI
M9VY?;&]O<'-?;6%X7W-K:7`[#0I`0"`M.#<Y+#8@*S@X-"PQ-B!`0`T*(&EN
M="!A;&EG;E]F=6YC=&EO;G,[#0H@:6YT(&%L:6=N7V9U;F-T:6]N<U]L;V<[
M#0H@#0HK+RH@268@;VYE(&5M:70@8FQI<"!C:&5C:W,@=&\@<')O=&5C="!F
M<F]M('-O;64@:6YT96=E<B!V=6QN97)A8FEL:71I97,-"BL@*B!E>'!L;VET
M871I;VYS+B`J+PT**PT**VEN="!F;&%G7V)L:7`@/2`P.PT**VEN="!F;&%G
M7V)L:7!?<W1A="`](#`[#0HK#0HK:6YT('=A<FY?8FQI<%]F;W)?;F]T7V5M
M:70@/2`P.PT**VEN="!W87)N7V)L:7!?=VAI;&5?;F]T7V5M:70@/2`P.PT*
M*VEN="!W87)N7V)L:7!?8V%L;%]N;W1?96UI="`](#`[#0HK#0H@+RH@5&%B
M;&4@;V8@<W5P<&]R=&5D(&1E8G5G9VEN9R!F;W)M871S+B`@*B\-"B!S=&%T
M:6,@8V]N<W0@<W1R=6-T#0H@>PT*0$`@+3$Q-3`L-B`K,3$V-2PQ,"!`0`T*
M("`@($Y?*")297!O<G0@;VX@<&5R;6%N96YT(&UE;6]R>2!A;&QO8V%T:6]N
M(&%T(&5N9"!O9B!R=6XB*2!]+`T*("`@>R`B=')A<'8B+"`F9FQA9U]T<F%P
M=BP@,2P-"B`@("!.7R@B5')A<"!F;W(@<VEG;F5D(&]V97)F;&]W(&EN(&%D
M9&ET:6]N("\@<W5B=')A8W1I;VX@+R!M=6QT:7!L:6-A=&EO;B(I('TL#0HK
M("![(")B;&EP(BP@)F9L86=?8FQI<"P@,2P-"BL@("!.7R@B16UI="!":6<@
M3&]O<"!);G1E9V5R(%!R;W1E8W1I;VX@*&)L:7`I(&-H96-K<R(I('TL#0HK
M("![(")B;&EP7W-T870B+"`F9FQA9U]B;&EP7W-T870L(#$L#0HK("`@3E\H
M(E)E<&]R="!B;&EP('-T871I<W1I8W,B*2!]+`T*('T[#0H@#0H@+RH@5&%B
M;&4@;V8@;&%N9W5A9V4M<W!E8VEF:6,@;W!T:6]N<RX@("HO#0I`0"`M,30Y
M,2PW("LQ-3$P+#$S($!`#0H@("![(F1E<')E8V%T960M9&5C;&%R871I;VYS
M(BP@)G=A<FY?9&5P<F5C871E9%]D96-L+"`Q+`T*("`@($Y?*")787)N(&%B
M;W5T('5S97,@;V8@7U]A='1R:6)U=&5?7R@H9&5P<F5C871E9"DI(&1E8VQA
M<F%T:6]N<R(I('TL#0H@("![(FUI<W-I;F<M;F]R971U<FXB+"`F=V%R;E]M
M:7-S:6YG7VYO<F5T=7)N+"`Q+`T*+2`@($Y?*")787)N(&%B;W5T(&9U;F-T
M:6]N<R!W:&EC:"!M:6=H="!B92!C86YD:61A=&5S(&9O<B!A='1R:6)U=&4@
M;F]R971U<FXB*2!]#0HK("`@3E\H(E=A<FX@86)O=70@9G5N8W1I;VYS('=H
M:6-H(&UI9VAT(&)E(&-A;F1I9&%T97,@9F]R(&%T=')I8G5T92!N;W)E='5R
M;B(I('TL#0HK("![(F)L:7!?9F]R7VYO=%]E;6ET(BP@)G=A<FY?8FQI<%]F
M;W)?;F]T7V5M:70L(#$L#0HK("`@3E\H(E=A<FX@=VAE;B!B;&EP(&-H96-K
M(&]F(&9O<B!L;V]P(&-O=6QD(&YO="!B92!E;6ET960B*2!]+`T**R`@>R)B
M;&EP7W=H:6QE7VYO=%]E;6ET(BP@)G=A<FY?8FQI<%]W:&EL95]N;W1?96UI
M="P@,2P-"BL@("!.7R@B5V%R;B!W:&5N(&)L:7`@8VAE8VL@;V8@=VAI;&4@
M;&]O<"!C;W5L9"!N;W0@8F4@96UI=&5D(BD@?2P-"BL@('LB8FQI<%]C86QL
M7VYO=%]E;6ET(BP@)G=A<FY?8FQI<%]C86QL7VYO=%]E;6ET+"`Q+`T**R`@
M($Y?*")787)N('=H96X@8FQI<"!C:&5C:R!O9B!C86QL<R!C;W5L9"!N;W0@
M8F4@96UI=&5D(BD@?0T*('T[#0H@#0H@=F]I9`T*0$`@+34R,34L-B`K-3(T
M,"PY($!`#0H@("`O*B!3=&]P('1I;6EN9R!A;F0@<')I;G0@=&AE('1I;65S
M+B`@*B\-"B`@('1I;65V87)?<W1O<"`H5%9?5$]404PI.PT*("`@=&EM979A
M<E]P<FEN="`H<W1D97)R*3L-"BL-"BL@("\J(%!R:6YT(&)L:7`@<W1A=&ES
M=&EC<R`J+PT**R`@8FQI<%]S=&%T7W!R:6YT*'-T9&5R<BD[#0H@?0T*(`P-
M"B`O*B!%;G1R>2!P;VEN="!O9B!C8S$L(&-C,7!L=7,L(&IC,2P@9C<W,2P@
&971C+@T*
`
end
|=[ EOF ]=---------------------------------------------------------------=|
© Copyleft 1985-2024, Phrack Magazine.