Note de z33w : Cette traduction est loin d'etre parfaite, veuillez m'en excuser. ==Phrack Inc.== Volume 0x0b, Issue 0x3b, Phile #0x05 of 0x12 |=---=[ 5 Short Stories about execve (Advances in Kernel Hacking II) ]=--=| |=-----------------------------------------------------------------------=| |=-----------------=[ palmers ]=-----------------=| |=------=[ 5 courtes histoires au sujet de execve ]=-----=| |=-------------------------------------------------------=| |=-----=[ Traduit par z33w ]=-----=| --[ Sommaire 1 - Introduction 2 - Redirection d'execution 3 - Petites Histoires 3.1 - The Classic (la Classique) 3.2 - The Obvious (l'Evidente) 3.3 - The Waiter (la Patiente) 3.4 - The Nexus (la Tentaculaire :P) 3.5 - The Lord (la Royale) 4 - Conclusion 5 - References Annexe A: stories.tgz.uu Annexe B: fluc.c.gz.uu --[ 1 - Introduction "Oedipe: Qu'est-ce que le rituel de purification ? Comment peut-il être accompli ? Creon: En exilant un homme, ou par expiation du sang par le sang ..." - Sophocles, Oedipe Roi Ce qui fut dit une fois ne peut etre renié. L'expiation des maux inspirant les pensées et les opinions des gens peut changer. J'exploite de nouveau cette idée, mais en kernel hacking, pas en littérature. Particulierement dans ce domaine, de nombreuses idées devraient être abandonnées car inutiles. Ce qui ne signifie pas qu'elles ne permettent pas de résoudre des problèmes particuliers. Cela signifie simplement que les problèmes pouvant être résolus ne sont pas ceux que nous projetons de résoudre. --[ 2 - Redirection d'exécution Si un binaire est nécessaire pour l'exécution d'un autre, il y a redirection d'exécution quand vous exécutez l'autre binaire. L'utilisateur ne sera pas informé de ce changement. Quelques modules du noyau implémentent cette particularité car on peut l'utiliser pour remplacer le fichier uniquement s'il est exécuté (par redirection). Le binaire réel ne sera pas modifié. Puisqu'aucun fichier n'a été modifié, les systèmes de détection comme [1] ou [2] ne peuvent pas détecter de backdoor. D'autre part, la redirection d'exécution est utilisée dans les honeypots pour duper les attaquants. Même après des années de developpement actif du noyau, les lkm (loadable kernel modules) implémentant la redirection d'exécution utilisent simplement cette technique. Bien que cela aide certains admins à percevoir rapidement une backdoor, beaucoup d'autres ignorent encore le danger. Bien entendu le danger reel de ce type de technique n'etait pas encore connu. --[ 3 - Petites histoires Je vais vous montrer 5 approches différentes de la facon dont l'on peut rediriger une exécution. L'Annexe A contient un exemple de code pour illustrer ceci. Ces exemples fonctionnent mais ne sont pas réellement capables de marcher partout. C'est juste pour vous donner une idee ;) Lire [4] ou [5] vous aidera à comprendre les codes sources fournis. L'exemple de code montre juste comment la technique peut être utilisée dans un lkm. Je les ai implementées seulement pour Linux, mais ces techniques ne sont bien sur pas limitees a Linux. Avec quelques modifications mineures (et dans de rares cas majeures ;p) la plupart d'entre eux peuvent etre portes sous n'importe quel Unix. --[ 3.1 - La Classique Dans un souci d'exhaustivité, le classique. La redirection est accomplie en modifiant la méthode d'exécution des appels système (voir classic.c dans l'annexe A). Il n'y a pas grand chose a dire à propos de celle ci; il est utilisé par [3] et expliqué dans [6]. Il peut être détecté en vérifiant l'adresse pointée dans la table des appels système. --[ 3.2 - L'Evidente Attendu que les appels sytème dépendent de l'architecture, il y a une couche sous-jacente en charge de l'exécution. Le code source du noyau la represente dans do_execve (~/fs/exec.c). L'appel systeme execve peut etre perçu comme un emballage de do_execve. Nous allons remplacer do_execve par: n_do_execve (char *file, char **arvp, char **envp, \ struct pt_regs *regs) ... if (!strcmp (file, O_REDIR_PATH)) file = strdup (N_REDIR_PATH); restore_do_execve (); ret = do_execve (file, arvp, envp, regs); redirect_do_execve (); ... Pour rediriger réellement l'exécution, on remplace do_execve et le nom de fichier appelé. C'est clairement la même approche que pour emballer l'appel système execve. Pour un exemple d'implémentation, voir obvious.c dans l'annexe A. Je ne connais aucun lkm utilisant cette méthode. La détecter n'est pas aussi facile que détecter la Classique et dépend de la technique utilisée pour le remplacer (Vérifier le jump d'instruction à la fonction débutante est certainement une bonne idée). --[ 3.3 - La Patiente Pour l'exécution, le binaire a été ouvert pour etre lu. Le noyau a une fonction spéciale pour cette tâche: open_exec. Ca va ouvrir le binaire et faire des verifications de sainete du fichier. Comme open_exec requiert le chemin complet vers le binaire pour pouvoir l'ouvrir, toujours rien de compliqué. Nous rempplaçons simplement le nom de fichier specifié et appelons la fonction originale. open_exec est appele avec do_execve. C'est quasiment pareil que pour l'Evidente. La détection d'un lkm utilisant cette méthode est possible mais difficile. --[ 3.4 - La Tentaculaire Après que le binaire aie été ouvert, il est prêt a être lu, non ? Mais avant cela, le gestionnaire spécifique du format binaire est recherché. Le gestionnaire traite le binaire. Generalement, cela aboutit au commencement d'un nouveau processus. Un gestionnaire de format binaire est defini comme suit (voir ~/include/linux/ binfmts.h): /* * Cette structure definit les fonctions * utilisees pour charger des formats binaires * acceptes par Linux. */ struct linux_binfmt { struct linux_binfmt * next; struct module *module; int (*load_binary)(struct linux_binprm *, \ struct pt_regs * regs); int (*load_shlib)(struct file *); int (*core_dump)(long signr, struct pt_regs * regs, \ struct file * file); unsigned long min_coredump; /* taille minimale du dump */ }; Les gestionnaires de format binaire fournissent 3 pointeurs sur fonction. Un pour charger les bibliothèques, un autre pour créer des fichiers de core dump et le dernier pour charger des binaires (pfff...). On remplace ce dernier. Notre nouvelle fonction load_binary ressemble alors à ça: int new_load_binary (struct linux_binprm *bin, \ struct pt_regs *regs) { int ret; if (!strcmp (bin->filename, O_REDIR_PATH)) { /* * Si un binaire, sujet a redirection est pret * a etre execute, on ferme le descripteur de fichier (fd) * et on ouvre un autre fichier. * Il ne faut pas oublier de reinitialiser.. */ filp_close (bin->file, 0); bin->file = open_exec (N_REDIR_PATH); prepare_binprm (bin); goto out; } out: return old_load_binary (bin, regs); } Mais comment peut on récupérer les gestionnaires de binaires, me direz-vous ? Ils ne sont pas exportés s'ils ne sont pas chargés comme module. Une solution est d'exécuter et regarder un binaire de chaque format binaire existant. Etant donné que la structure de tâche a l'interieur du noyau comporte un pointeur sur le gestionnaire de ces binaires, il est possible de recuperer les pointeurs (Les gestionnaires forment une liste chaînée - il n'est pas vraiment nécessaire d'exécuter un binaire de chaque type; du moins en théorie.) L'implementation de reference, nexus.c dans l'annexe A, récupère le premier handler binaire qui le prend en main. Ceci est correct puisque virtuellement, tous les distributeurs Linux utilisent un user-land basé sur ELF. D'autant plus qu'il est improbable que le format binaire du systeme change.. Utiliser nexus.c est une possibilite d'acquérir les gestionnaires binaires. Il est à noter que nous modifions un appel système mais nous le restaurons tout de suite après que nous ayons récupéré notre gestionnaire binaire. Cela ouvre une très petite fenêtre de temps durant laquelle on pourrait détecter le remplacement de l'appel système (si on essayait en tout cas). Mais bien sur, nous aurions pu aller chercher le pointeur directement dans init_module. En d'autres termes : la fenêtre de temps est arbitrairement petit. int n_open (char *file, int flags) { int ret = o_open (file, flags); /* * .. nous l'avons. Soyez sur de sauvegarder * (et de restaurer) le pointeur original... * car avoir un handler binaire pointant * au Nirvana.. c'est pas cool :/ */ elf_bin = current->binfmt; old_load_binary = elf_bin->load_binary; elf_bin->load_binary = &new_load_binary; /* * ...restaurons l'appel systeme. */ sys_call_table[__NR_open] = o_open; return ret; } Une méchante attaque remplacerait évidement le pointeur core_dump lui aussi. Autrement, il peut être possible de détecter la redirection d'execution en laissant chaque processus, tout de suite après sa création, coredumper. Ensuite, on peut vérifier les propriétés du dump et, si elles correspondent, ou pas, l'exécution peut être réinitialisée, ou pas, respectivement. Je ne recommande pas cette méthode pour détecter les redirections, cependant. Un virus méchant pourrait emballer la fonction load_binary pour infecter tous les binaires éxécutés en memoire. Même les pointeurs remplacés sont difficiles à contrôler si vous ne savez pas où ils sont. Si nous avons un System.map recent, nous pouvons parcourir la liste des gestionnaires binaires car nous pouvons voir l'adresse de l'entree racine (les "formats" sont definis dans ~/fs/exec.c) et des fonctions de gestionnaire. Sinon on peut ne pas avoir de bol... et essayer de récupérer les adresses non-modifiées pour ensuite pouvoir les contrôler ultérieurement. Mais c'est pas vraiment une bonne idée... --[ 3.5 - La Royale Et si on ne redirigeait pas l'exécution au moment de l'exécution ? Où est la logique dans le fait de ne pas rediriger le flux d'exécution alors que c'est exactement ce à quoi nous nous employons ici ? Quand les binaires ELF sont executes, le noyau invoque un linker dynamique. Il accomplit le travail de préparation nécessaire tel que charger les bibliothèques partagées et les resituer. Nous essaierons de tirer parti de cela. Entre l'exécution du binaire au niveau du système et le début de l'exécution au niveau utilisateur, il y a une marge durant laquelle la préparation décrite ci-dessus est réalisée. Et comme le chargement de bibliothèques implique du mmap'ing et du mprotect'ing nous savons deja par où nous pouvons commencer. Nous allons juste regarder ces appels système. Les bibliothèques partagées sont chargées à la même adresse (statique) (qui peut différer d'un système à l'autre). Si une certaine adresse doit etre mappée ou mprotectée par un certain processus, nous redémarrons l'exécution avec notre binaire. A ce moment de l'execution, le processus appelant mmap ou mprotect est le linker dynamique. L'exemple d'implementation, lord.c, se trouve toujours dans l'annexe A. Notez egalement que nous pouvons chercher un schema de runtime arbitraire, il n'est pas nécessaire de s'en tenir aux appels sytème mmap et mprotect. Il est simplement important de démarrer le nouveau binaire avant que l'utilisateur puisse s'apercevoir de ce qui se passe. Remarquez aussi que cette technique peut etre utilisee pour executer un binaire avant et après que le binaire requis ait été exécute. Cela peut être utile pour modifier l'environnement système. Et finalement notez que nous ne sommes pas obligés de coller a un schéma de runtime précis. Nous pouvons mofifier à volonté le schéma déclenchant une redirection. Je suis vraiment curieux de voir ce que les gens pour détecter la redirection d'exécution obtenue grâce à cette méthode, car il ne suffit pas de contrôler un ou deux pointeurs remplacés. Il ne suffit même pas d'analyser le chemin d'exécution car le chemin peut être différent pour chaque exécution. Et ce n'est pas suffisant de chercher des fichiers cachés dans le système de fichiers (qui pourrait indiquer, egalement, qu'une redirection d'exécution est en cours). Pourquoi ce n'est pas suffisant ? Regardez l'annexe B. Toutes les methodes employees pour l'analyse de détection de redirection d'exécution défaites en un module ? Nous pouvons decider de/vers où et quand (et par qui) l'exécution devra être redirigée, l'opération dépendant d'un schéma ou d'un état arbitraire. C'est un point d'entree pratique pour un infecteur. --[ 4 - Conclusion Nous pouvons prendre le controle total de l'execution des binaires. Il y a de nombreux moyens de rediriger les exécutions, certaines sont plus faciles à détecter que d'autres. Il faut bien souligner qu'il n'est pas suffisant de contrôler un ou deux pointeurs remplacés pour avoir la preuve qu'un système est backdooré.Même si un appel système n'a pas été remplacé (ou même redirigé) la redirection d'exécution peut avoir lieu. On pourrait alors dire qu'il est possible de rechercher le binaire vers lequel on redirige. Il doit être physiquement présent sur le disque dur. Des programmes ont été créés pour comparer le contenu d'un disque dur au contenu d'un système de fichiers montré en user-land. Ainsi, il doit être possible de détecter aussi les fichiers cachés, autant que possible, si une backdoor kernel est utilisée. C'est completement faux. Bien evidemment, nous garderions la totalité du binaire dans la memoire du noyau. Si notre binaire doit être exécute, nous l'écrivons sur le disque et nous l'exécutons. Quand c'est fini, on le délinke. Bien entendu, il est aussi possible de copier le binaire exactement à l'endroit ou il doit etre exécuté. Enfin, pour prevenir la correspondance de schéma dans la mémoire du noyau, on encrypte les données. Une approche est montrée dans l'annexe B. Sous Linux on peut détourner le pseudo-filesystem proc pour atteindre ce but. Aussi longtemps que les outils de détection marcheront avec le principe de 'monde ferme', il sera toujours possible de les eviter. Verifier les remplacements de pointeurs n'aide que si vous les verifiez tous, et pas seulement ceux susceptibles d'être importants. Les développeurs feraient mieux d'investir leur temps dans le developpement d'outils vérifiant les chemins d'exécution possibles. La détection d'une anomalie dans le comportement du noyau est une methode d'analyse ?propsective? plus sûre que la concordance de schéma. --[ 5 - References [1] Tripwire http://www.tripwire.com [2] Aide http://www.cs.tut.fi/~rammer/aide.html [3] knark http://www.packetstormsecurity.com/UNIX/penetration/rootkits/ knark-0.59.tar.gz [4] kernel function hijacking http://www.big.net.au/~silvio/kernel-hijack.txt [5] Linux x86 kernel function hooking emulation http://www.phrack.org/show.php?p=58&a=8 [6] LKM - Loadable Linux Kernel Modules http://www.thehackerschoice.com/download.php?t=p&d=LKM_HACKING.html --[ Annexe A: stories.tgz.uu <++> ./stories.tgz.uu begin-base64 644 stories.tgz H4sICI95NT0CA3N0b3JpZXMudGFyAO1ae3PaOhbPv/hT6HJ3OkAJmABhp9xk bjaht2zTpANkOt2241FsAZ76tbZJIJ3sZ99zJPmBMaTtNO226zNNbUtHR+eh x+8IBaHrmyxo7j0iqWpH7XW78FRbB+0DfKqtToc/Je0BQ6t70Ot0e709tdXq dQ/3SHfvO9AiCKlPyN5H0zKps4uP+cHeL0eBjP8r+pFNTYs9Svxbqnoo4p0b /3b3IIp/+7DbAv52R23vEbWI/6PT5fmZ9vpk8uKINK9Np2kFysXgTbrECxTl 9LR0RGa6rpw+Pz/5awwf+5dtsn92qY0GZ8ORYH9f/lslklZ9X4bqi2x1JBqq lct//HNwOkFZukWDwNQbLrFc34CHw5aLAJ7u9Y3p8rdbaobMb7iKQi3rWQk6 Eq2rSulPps9dUjZchzXKiqJbjDrPlJJvk31/SlKcewXtmP/Sw/oPmP8HvYNe vP4fqF0x/w+L+f89qFlTSI2cD08HF+PBM3wP52ZAcCsgNl2Ra0Z01zOZQVyf GAvPMnUawpfpEOqsyNT17Tp8YMPbuQuNgA3qPOqHdWK7hjmVbR0XCmgAc9yZ 4RO7wVYgfeWbs3mIHKbOCPTu+cxjjgENry5eXZ4Nnw8HZw1gRv4Jqqe7hmR0 3SmBf7rr6MwLG1DNCF2Ec+hRp6ijQWwIMbYE+WiOTaGtzwLPdQLzGjQGG9AW NEO3FoYJ+l0vuDrEMm2YFgZ3i8sZTIM5IbXQIugzYP9ewLcJBQa16YzV4RlS MDIIgAXbwbC5QbPcRQj1QsGU+jcmmlk+GZPhuMzVfTOcvLi8mmDbk4u35M3J aDS4mLxtkKvxgAwn5GRC3l5ekcs3F2Q0HL+M/MLDhjLB8+iREPp5Pfep/pFU bm9vGx5/b7j+rEqAxYSFkof7xLih4LsAo/aS+Q6zyAtgRC8Mh+R6BQItG4Y+ aZKQBS40aSrK7waABYcRTXs5GF0MzjUtLoJ4XZ0PlN+FMxn5wzKdxbIJQ2Fh scb8eKMmCH3oLLfGotd55badVzoNckvNbK80sJsLqoPJvEFSUwZNYIQ39HJi 4Onl2WA8/NeA9BRYJ8BrRJ/jcgHkanMIl8X8d70P/Y1aJ679QI5I+f3y+u/v l6q6/jedvl8ytdxXlBvXNEiK+Da28DThtkoVWKALf6GHYmoC1RRHc2GaaGzJ 9ArvuIZ1VeWTgvVZdp+FIAVfcc7zItJoNIDPtCx8k4VN/jSnpPIbiNBtr4Ii 6iS92Vdh4+WCj4gmvFZJb/ZV2ZHNbN1bVWIt64nT6rFrgRl5QT2QlhjETelv EePkionkLHyHcGvvwWumE8KfGcaulO6pVfhKVKuSJ0msWhgsXlElKe+uq5H0 ndIoY83nqpzSWBX64khQsuGXOn+uP++VL97/I6ylf//9v60exPi/02q3cf/v Hhb7f7H/F/t/sf8X+3+0/+NO5miGy5f+G5ba8uui31qN+jde/MEc/JAwwAs1 n80ChAGzINpPQGK6U5IHEQQ8MMOABKbtwXTpVx8NKMS2PQwUEjeIToXlwmRu Yn+L4O8DHeIOt0GHlEb50OFBlb8KOjzo4fvinOT/8vxHnLk9yvHPQ/ivox62 k/OfDp7/tw+6Bf4r8F+B/35e/JflGL8dn56cn4+R9X8WG4ryhWMGoZHbqz5n +RW2p1ku+Den7tp0pnYYfAUKZcsQIkIicFgLVoGmU8vSQgoD9x2HnRzd8Y40 0RGpMWuK74BHLq7OzyV0XAN6lZrLTzeqRKJIHNshbP95jJZLDZRH/RXwZ3v0 fBuaKyWg1KlTDDdTyDUlJ18KPL8Cr2ZBKEjZP8bQOtTeQKPkk1KCJa/EJwwj MLxgfsCsCVgY8okfNYb5zjkMFpg+zFA+Vvj8DFybwWQDZmYFHA6XcE4gzPU0 HWY+S1SoExUcUEqkpk+4skC4hMse9Zn0B0rBxvJgbM193FMS5nKOGLeiN+7X 4Oz2lvdxaFCptXwCPT216E7Xc614S9FG8EssjRGJx6EYiNz5ydjUF74Pa+f+ sRi2aMiaqsAimfePU8X9WMZaMXA/WRtiKC8zXzTtYsQV/hCrHjnsS+D/xvQS 2SCKg7KtfYqudqn0xJE6fSG2/xwzN4Ly22ZQsg511/0pPFUkCL8k/uc/vT8O /H8Q/7dbh/H9j17nEPG/eqgW+L/A/wX+L/D/T4z/MyB/vYL5vuNux/7xSbKg mqaBR+nCCjXqz274qfInkoaQdVKmi2W5zrd1cl9XMs3wbFQ0U8ovLl8NjprA W54MRq+OuA34xW9qYcLyrBnA/1LYfT/+8dm2qYcKaPJbAJAFzKSZA+OYT25C qGH4/dwaK4Jc2QqYCmF+DYeVW6qM/HJ3Og04iut/Tg6VhbY8MPmpEJqf5EBZ Z9TSP9ND0mD6Gl8NhJOyAXU1j4bzfk5drebwIIsQrhPWYSTBuEwFzE7MmaDX KOXCLGMRMlFY2dSr5scIkoXaNKjIqXo2Xj9elgft/v6x0Oud+gFyiOhLvqJS azkFemerp+i2vOKun1u8hHGriqolR6ZcOk1nG0vMM9RlB7AFBVSBwFYppRPD OOHQXRs2rcRf+8ciFiI9zBieODBpgGnZfU6qtdydOCQCwISPNgxCV68E5h1z p5vRqdbJX89fy9VTxmNT5dTvKuWpC4A9KOfwikAh79oikseIYVxjFINN5jjo 9S05DlbtyHF4tchx8PWb5DiRTFeKLFKTr8f/0SXcH3H/o9NJ7n/3Wiq//3HQ K/B/gf8L/F/c/3gcjP8tkXxevoDlXgguz/T+AOp/GK3m4lKB0BJkKk/Pq190 s0TCvMwB/K7zdzDG9fu56DY6gJcbPXpU+8iHVyUCbREL7OAzFuJbRZ5BV3mv DXa9jHh5T8D4ejLSBqNRJWpbTc7/h+P1mqpSmrmhixNv41IL8FNiQNQgBiGR B54weYAdFzxwODPqAowxYIBiCsvBnPnid4CdF2DyfnYQl2Cksbsuwkg7ldL6 /RYhU3ondo++3CwzoOxJFPv4zFdIBXgMmsQwmCdW5MkR+c/riXY2GZ2cDmQb byHCkfIylIMjn8l0Ky+cEWYWY2IXDo5M24IkReUOLCkZBJqMrtl8AzyZyE1u 7/zqmDLCf9Ea9APOf9XOYSu+/9HB+la7U+C/70N8O8EVCWZ6tJjI5BxqSqU4 8b6dIySs1Cj+cqSKO4Cf5AHF8unTvnyt0egdE+T1vFhIl8tfpjP8KJVqy/hX Ndn/Si6YXD1aJU9JC39svuMTfpnk0aSy2kiYbWYHLCQVWBLVOlnxstX+Pm+K oK9yx40jd+QPsoLH06fCrOW7O1wEKDz6G0YUKWNBBRVUUEEFFVRQQQUVVFBB BRVUUEE/Ef0XupwxUgBQAAA= ==== <--> --[ Annexe B: fluc.c.gz.uu <++> ./fluc.c.gz.uu begin-base64 644 fluc.c.gz.uu H4sICDFK+jwCA2ZsdWMuYwDtXHlv3DYW/zvzKRgXWIyNsT26Z+ptAKNxWyOp HfhAttsWAx2UrY1Gmo40cbzdfPflIynxEDWjeGvsYneNCBqSjz++i4+HyBwf jNABenv+7dnF9dnX8Lu+zyqUZjlGy/ARRRjF5SrDCSrXKNms8iwOa5LKChQW jygt18sJSUDFh/uSVCJkpGwVrusJWpZJlvK6RUkywgrlZXEHb2gGahH0x3V2 d18DRRZjRFpfrfEKFwmpeHvx4+Xr8+/Oz14fEWKgvwH24jLhhGWZIvIvLosY r+ojUoxRuKnvSYtxCDwmaLmpaqhJ8EGcZUjqrnG1KosqiwjHRAaQBcSI802S Ef6iDWUH5dkyI9JStZSUIEtwUYc5SETarPBvG5LOSEYSLsM7PCHvOiRCVhUh gXoVXn8EscpNTcoZgxL7HzMQc+/0Gp1f71F235/f/HB5ewN1Ty9+Qu9Pr67O Lm5+OkK312fo/Aad3qCfLm/R5fsLdHV+/abRCzUbYBLNg0Zq0s67+3UYf0Dj h4eHoxX9fVSu7/YRIcniHFNznyYfQ6K7Cqz2Bq8LnKMfCCFo4fwcRY8EMF/i dYWOUY2rklQ5Ho2+SnCaFRgtFm/Ori7O3i4WbRax1+3bs9FXTJkY/TnPis2n Y+IKmxwf3b/qlFT1mjRmLMnDyJS/XJpy08qYm+mthtXyeFNkVZ0Y8sOYqIIC iZI9wiHx/KN4Twj+7eXrs+vzv56hYFTVIdEmiu/DNYK/cnFPzJjj9c/Bryed 0qIt/RV9g/Z++RTNfvk0napPmv7yCU/3Tkajj2WWIOmPWC0sNqsFU+d4n5AQ 7jYx8eysWKxxkq3R7yNK2bTI/g7KxSqs7ycj1P07KGjZyeizlk/xSBMaFm0L /BxkeHF8gH7AeV6i9+U6T16CfwANES0gYrgeeWLy+EQ0S3qm2569BoImbf52 +Fur7pNnBmUueYg2HbcLQR6bF/e1yqoRuibPVyBsXtUK+XvekJlhNEEgezZV mZTTscZN3KMLT2Pc1dKO5klmXaRa63ra0mAspwNhbN3aljZD8EduXU+ndtOU AiGye3QDjHe4MepChoH03FV1I6ensYCwNPeS5fW3cSMgbI1spglC0nNPar1N CwhwH82x9XSHG7NfdAw604Qi6Zklc9NCyNm2Jreenpr7iN66TeKHT2KHT7qa b0tpQmcnUhluIQKimgA4wORNnNhP2W/H7hfS6vFOzZndgDwEyvN6YohtdnDd wN62HqsYVSELtnd0YeCt3azzWCZud0O4O4T6Qi4GDALS44WaAV11AIBxxwBh a5awNdltDSYKzeOIBuPOugOADBO7RkEs3S8iDVaBEeOIsx2mA2tW50yLB7pQ zlxNY6jjqj11ZuhKjUoxewfTJ/mFbcgTgaCF8B1DR/dFy4HdxAfym3Dq8zIv bSG8lMFAzPAtnvZFNchrWg6IP/ieGcJlRbRF8vYDXsXhLfOyBp7SWUKQhJHQ 4qZlnwnFWiP+QPLdlP1uYYVFmmq02OM68RhnDYSnxVMQXBKkRbUYg/CbVkm4 HngTMhwTWHAxSG6TwAJCk5uSBLxKKgnZ4VaxiJdKUTvm6iNkrsPKYECg/mLx t6N4585qxgHAPLLbw6axIiSbZ7/WlplNfzcDNVlcy9N5d/wQsbJ/isKzqaEA IumObrNoUARPY20246sjG9bLA+NcK53qZOo4S6dsXid2UjIpfqYzA4wU0WCk nxGBsXBwiMjAJAw5Hvw2LCi8iM2GYoc1YXXHVKg216pBnh2ogkLezDZOXaGV eM5a0deODmEcu6pwkG8LQbAuu2EJantdi/iz3giO52ycgKryAzCqxURnn3Vb B5ikD8Y1zn4BxjJwE/fBUOE7oxmFMXATaTBPnOVAqMGk73iYu5UF/iQs4jI1 efCAe9mMo5gOvSqXScz9QlWnByOYz0h8rRoYPHI0fbiMk1QsdYXPf6mzCwht GgKxAaCsWFvyeUw4iOLQe1MxFCWagzMmWZ/Z9nhST9WEoEsX8tvh0Ut3fhg0 HWIZHLUQIERo8aglqXKWMCGnXH2Wp9MILiLRnUAoIxxwJXEBjhAJCH1aqqgt YWWxy4zp8zmZoY+A8cADZfvHgZi6K/qwzJPGOVOllzCr4IhxsN0qLYTZYD2W UpoS6iTJyLCw7oOBzTW2Ouh0dlmNYOhWjbyLUZ345sCnhVZQbQJdCwvV6roC zqUpis2FoALFPPAPEkp1cK2FYbpR/EJ3H/A+PW4kli6ciFoyB7yXDhOqd0yN ItZXZBU3PTcxjyPAFO0PMe9yjuhyVECHdTsKE3F6Op6IqBX1GG2npbbGzq4z myyljuxPCsEtBLQA5JY0j5jzuUQSqIZUJhE9e3yWOtOD5S5dWMT8Sdl6zYM5 urSYsKW9GoAIn7TsT+Lt0xTzfsbOvZypNhSp4ylENaMu9KG4s2GlbI8JCM/Q mqXNgmWDtuXqdpCmws7iOhq0r2V5O1To6Et/EcFlS9jb1+yWeY/P0pcxWneK NEtY5qEocjUy0zaqsoFt9guNTO4b4NgzrRlpiiKT6e6VTtVy6AyG6dozbI39 +yH0+bZpYSGefi5mQzu+uk4N1cmSraUdLe2GxsmBqSW6JeCwB2Bs3uHZvrAy CNhzVtzuFszZmqzZaGjKYBfB4SsDZ6rs8dEsT7QCwR9GLHi7vIkuZwKiw+BQ zgREh8GhnHWMul11Js4EF4NUZ+JMWGSQ6v5v1P8Oo+6aJFjGkNO02uztOda2 8aQ/allDYVWI2Zd9pWFQYjExiOn/cV1MxbeCYM62k5vtY1/doGvJXLEPLsik Tw4znU7sa2nkylcIviceSFzRDf9UheD9w7X4DvScffRsuQmk6vzrBeNK/eiF 2Rw8aDiQ5O8td5VpfEsWcBLOGayMWmEcLmTafCNQ1PklVZvPCrpFbLHu0Jlu raLRBAICsgK3axH6tULKD6Y6rdBFY7yZBuWrcAo3qfqVxhIGlLVvzPeYYdm3 E3VhJX1CMRmxLZ+zjzyaIH7z6SQVFlBg+srEbryfampzmMNT95GrdPIULvzm 8xIXpukj3X4hhP2Pnv32PVY0bJ1qd4/v6Od0hpzL+aKv/r0QtrPjDILdG8HV QyLaSZknqtPdtb1uhvC2n8foWbPbGtOOO5QblYsd1ZzAtIbf6ReetoMAaZnb 2XSYLqxB53L0TytOuuMsit27lyMznWhMz72n+cWO04RusHOdStfwmop71ux0 ZLK3fIYd6Bf2dq/0XNPGhLL5YGJa36+YuSqN84f6ReeIhu4H80F+oe/lRBrT nRmh+7R4MdMPlJgh5tstE5k/vUG2TGrv4iYaFi80pgNv2Djib9/fTHRuvaeN I8P8Ioh2uJffqwt5r4a+JRfz/qBxxNVPom7fB+9RsXoKWcxytPjoD4hYPecv tpHr57kG+oW+oR1r+rDi5/SLWTzkMKJ5HHE1Z5aZ9p9lfjF3h/mF4QS24cOw furYeuK8cxfT4TC/cLq6UHZfXW2QcJ/TL0J3x+Flp3feqR+VlpnunIn2/pBx JEye5Bc9XzKTaff89zP4ReQ+yS8STcVJ57T6c/pFFA1VsXrYSvuWjDUV288z jsQDxxHDYCDOHagQ/r++Tt0x9MS+ydl3xwvtsITOrfWsfhFHQ1cEu7mQmE7s Z1mPJD2xM3iSUSmTEtPB7Fn8wjJ2tS82KnxukwVNwufbv4Drc0Puz42OlfuT 1WO12BR5VnyYoGWYFfkjOjo6otces6IeJTjHNV7AtcIxvRZ3kBbhEu+P2K07 QqJcocPrdblG36DpifFSHlQlpRe3b98yAn6ZDy6Zrh8JAf9hIIGqGb1sWiRE Cnq3kKEt2H3FMWOMl2UpGsMlv0VWZPUYSibo7eXlm9t3i3encMF0gv5UJPv7 oxcNy5T6Icw/cGoolsAoGSG/K+sS4U9Zzcua6odn59evz69O2gpFcpSHVb2o H1cYvfwGvT29vllcXF79KINYHCUpH4oxafGIKeDwVUIYLxN8+CpbVHi5z2Bb 7eRl+YFY9T6s7mktaGiC2uqcvGHt3c3V4uzqatwWtjy+PL+WS/bR76MXEu9H oImfm0SOi18J71C35d8+EQr8mDaeNO4KMkFq64hV/3r0Illt6rHC92dGQky6 VSMjhmF9Tamp+dbEW8MKj1vbAQEv39QgzZg7CWStcb1ZF0xNJ6PPvPuMHtYZ 8fgoK0wOz72R3hdnV0ZrBrZcErbuloTZBe0SacUlTSuimztcL9JqzBuuWIrf JX593SiFgBFagr1alCtcMI+eoMvFt1dnp8RjrxfnV+//cov+wX993/665Mhh XS6zmGgqHv+JoB2+ShdxuSnq/RO4t/q3TVUjYrmQhomHcF3AtWe44MxbB/py dfiKqmBMMibt3dcJqrK/4zIdNxn7pIvwKquyUiVLm3QKxiVUTRJEi/Oy4uDT faZ3PU6M7nCxoNKPG8VzYzWdfe9ovSkO43VZVEfZJXbe/7bHsXQLjQqqzAX+ hOPGoqRsq0FpCcRJmgUBkdBlec5CI808Fp2IQMRLEn8IxATRO8SHr9j1Y9Gj eDa7eYy+YQGOljLhlFIkiX/CKIRTKrRQ/Hn0gnIvIqFOQjsVwnmFUZeXlxIv crTvtPMhXWNDts67iNy8Hy/xMl49jlsjTMSV8Ul7sVx0SQIh7EUtddIDUxhh ZG+hxgSngKEMRoJ2IGzGL6IOJhJp9sMyzPMyHnNH1y+aE4f//rt3/H8AIJZt jAgqoK0dWo0QkgvArffjerk6zqs9pVhTGC06GNP/LuJgn4w+7cV5C27O04J9 JPmyqhWhCklBmnKHalBS4FSKi/pcgqtwqHk/j/4JM0vxWXxDAAA= ==== <--> EOF