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 <palmers@team-teso.net> ]=-----------------=|


	|=------=[ 5 courtes histoires au sujet de execve ]=-----=|
	|=-------------------------------------------------------=|
	|=-----=[ Traduit par z33w <z33w@kernel-land.org> ]=-----=|


--[ 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