Retour a la page d'accueil
Switch to english
CCTT(1)
NAME
CCTT - Covert Channel Tunneling Tool
VERSION
Cette version 0.1.7 est une version alpha.
DISPOSITIONS LEGALES
CCTT a ete developpe dans l'objectif d'offrir aux responsables securite un moyen de verifier par la pratique l'etat de securite des reseaux dont ils ont LEGALEMENT la charge.
Toute utilisation de CCTT est subornee a l'acceptation de sa licence (voir COPYING) ainsi qu'au respect des dispositions legales propres au pays d'utilisation (voir le fichier LISEZMOI).
SYNOPSIS
cctt -s listen_address [-p listen_port] [-f config_file] [-t channel_type] [-l] [-L] [-v] [-T]
cctt -c connect_address [-d connect_port] [-f config_file] [-t channel_type] [-r | -a | -i | -z] [-v] [-T]
cctt [ -V | -h ]
DESCRIPTION
Ce manuel documente succinctement l'utilisation de Cctt.
Cctt est un outil permettant d'etablir des canaux subliminaux dans les flux autorises par les systemes de controle d'acces reseau mis en place.
PARAMETRES
Cctt utilise la syntaxe courante des lignes de commande GNU, avec des options en toute lettre precedees du double tiret ('-') ou leur equivalent raccourci.
Les parametres qui peuvent etre passes en ligne de commande sont :
-v, --version
Affiche la version de Cctt.
-h, --help
Affiche l'aide.
-d, --debug
Affiche les messages de debug (pour les developpeurs).
Serveur :
-s, --listen_address
Positionne l'adresse IP d'ecoute du serveur.
-p, --listen_port
Positionne le port d'ecoute du serveur (Tcp 4242 par defaut).
-l, --logging
Enregistre les sessions reverse-shell dans un fichier de log (rshells.log par defaut).
-L, --logging-syslog
Envoie les messages verbeux vers Syslogd (daemon.notice par defaut).
Tous les messages verbeux (si le flag -V a ete passe en ligne de commande) sont envoyes vers le demon syslogd local.
Si le flag -V n'a pas ete passe en parametre, seule l'initialisation et l'arret du serveur sont consignes.
Client :
-c, --connect_address
Positionne l'adresse IP de destination.
-d, --connect_port
Positionne le port de destination (Tcp 4242 par defaut).
-r, --rshell
Le client doit executer un shell inverse.
-i, --list_proxy_mode
Le client demande la liste de proxy autorise par le serveur.
-a, --proxy_mode
Le client doit fonctionner en mode proxy.
-z, --reverse_proxy_mode
Le client doit fonctionner en mode proxy inverse.
General :
-t, --channel_type
Positionne le type de canal (socket par defaut).
-f, --config_file
Positionne le fichier de configuration (cctt_srv.cf et cctt_cl.cf par defaut).
-v, --verbose
Execute Cctt en mode verbeux.
-T, --check_conf_file
Verifie la syntaxe du fichier de configuration et quitte.
TYPES DE CANAUX :
Les types de canaux sont positionnes via la ligne de commande mais font appel a des directives qui doivent etre positionnees dans les fichiers de configuration :
socket
Le canal consiste dans l'etablissement d'une socket PF_INET (basee sur le protocole TCP ou UDP : voir FICHIERS DE CONFIGURATION) standard entre client et serveur.
Aucun codage n'est realise et si la connexion tombe, les applications (shell, shell inverse et applications fonctionnant en mode proxy) sont tuees.
socket_encode
Ce type de canal est identique au canal socket mais le flot de donnees est code.
Une distance est calculee a partir d'une cle. Puis, on parcoure octet par octet un alphabet et la chaine a coder, on ajoute la distance au caractere courant de l'alphabet, on ajoute le resultat au caractere a coder, on fait quelques modulos pour demeurer dans une fourchette sizeof(unsigned char) et on cree la chaine codee. Si on parvient a la fin de l'alphabet, on boucle.
La chaine resultat est ensuite convertie en une suite de valeur hexadecimale (entre 00 et FF).
socket_http_proxy
Ce type de canal est identique au canal socket, mais utilise la methode CONNECT sur un serveur mandataire HTTP.
Le client ouvre une connexion avec un serveur mandataire HTTP, puis envoie la requete CONNECT @IP_serveur_Cctt:Port_serveur_Cctt HTTP/1.0. Si la connexion est acceptee par le serveur mandataire (reception de HTTP/1.0 200 Connection established), alors le canal est considere comme etabli.
socket_http_proxy_encode
Ce type de canal est identique au canal socket_http_proxy, mais les donnees sont codees comme pour le type de canal socket_encode.
client_only_with_http_proxy
Ce type de canal est identique au canal socket_http_proxy et n'est utilisable que par le client.
Il permet de beneficier des fonctionnalites de Cctt, tant du point de vue des services (shell, reverse-shell et mode proxy) que du point de vue de l'utilisation de la chaine de proxy sans etre oblige d'installer un serveur CCTT (le demon peut donc etre un service standard : ssh, netcat, etc...). Aucun paquet supplementaire n'est ajoute au flux (pas d'identification, pas de demande de service).
http_post
Ce type de canal permet une simulation du protocole HTTP basee sur l'envoi de requetes POST. Consultez les parties Directives HTTP POST serveur et Directives HTTP POST client pour plus d'informations.
http_post_proxy
Ce type de canal permet une simulation du protocole HTTP basee sur l'envoi de requetes POST. Consultez les parties Directives HTTP POST serveur et Directives HTTP POST client pour plus d'informations.
La gestion du proxy intermediaire est realisee comme suit :
Si la fonctionnalite chaine de proxy n'est pas activee, une connexion TCP est ouverte vers le serveur proxy et une requete HTTP POST specialement construite est envoyee.
Si la fonctionnalite chaine de proxy est activee, la methode CONNECT est employee jusqu'au dernier proxy sur lequel est envoyee une requete HTTP POST specialement construire.
http_post_proxy2
Ce type de canal est identique au type http_post_proxy sauf que la gestion du proxy intermediaire est realisee par la methode CONNECT.
test
Ce type de canal est utilise pour le developement de nouvelles fonctionnalites.
FICHIER DE CONFIGURATION SERVEUR
Les fichiers de configuration permettent de positionner plusieurs directives relatives au fonctionnement de Cctt.
Directives du fichier de configuration Serveur :
PROTOCOL=tcp|udp
C'est le protocole qui est utilise pour l'etablissement de la socket entre le client et le serveur ou entre le client et le serveur mandataire. Dans le cas d'une utilisation d'un serveur mandataire, ce protocole est obligatoirement tcp.
Cette directive est obligatoire.
FAKE_WEBSERVER=file
Si un client ne parvient pas a passer le stage de l'identification, le contenu du fichier lui est envoye et la connexion est fermee.
KILL_QUIET_DEL=x
Indique au serveur qu'il doit fermer les connexions quiet depuis x msecs. Si cette directive n'est pas positionnee, une valeur par defaut est definie dans includes/configuration.h.
KILL_QUIET_DEL_CF=x
Indique au serveur qu'il doit fermer les connexions ayant le flag close_flag positionne si elles sont quiet depuis x msecs. Si cette directive n'est pas positionnee, une valeur par defaut est definie dans includes/configuration.h.
Directives d'identification :
Ces directives permettent de specifier la methode d'identification utilisee entre client et serveur.
IDENT=xxx_ident
C'est le type d'identification parametre entre serveur et client. Il doit etre identique dans les deux fichiers de configuration et peut contenir les valeurs: clear_ident, basic_ident.
clear_ident ne contient aucun codage, la cle est envoyee telle quelle.
basic_ident contient un codage base sur le meme principe que le type de canal socket_encode.
Cette directive est obligatoire et est forcemment accompagnee de la directive IDENT_KEY.
IDENT_KEY=xxx
C'est la cle qui est utilisee pour identifier le client aupres du serveur. C'est une chaine ASCII.
Cette directive est obligatoire et est forcemment accompagnee de la directive IDENT.
Directives Mode Proxy :
Voir l'explication dans la partie relative au client.
PROXY_MODE_LIST=label:@IP:Port
Cette directive peut etre employee plusieurs fois si label est unique pour chaque ligne. C'est la liste d'autorisation de transfert pour les clients qui desirent fonctionner en mode proxy.
Le serveur recoit une requete, verifie si la demande est parametree dans sa liste et le cas echeant fonctionne en mode proxy pour le service label entre le client et l'application presente derriere @IP:Port.
PROXY_ONLY=ON|OFF
Indique au serveur de se positionner en mode proxy_only ou non. Ce mode configure le serveur de telle sorte qu'il refuse les demandes de shell ou de reverse-shell et de telle sorte que l'entree standard (voir MODE INTERACTIF) ne soit pas disponible.
Le serveur peut ainsi etre lance sans etat d'ame en background et utiliser les fonctionnalites de suppression des privileges (voir Directives de securisation du serveur).
Directives de configuration du shell :
SRV_SHELL_LOC=/path/to/shell
C'est le chemin absolu (attention au nom lors de l'utilisation de liens symboliques) menant a un interpreteur de commande (shell). Il est utilise dans le cas ou le client demande un shell au serveur.
Si le serveur ne veut pas offrir de shell au client, cette directive peut etre positionnee /path/to/false ou /path/to/nologin.
Cette directive est forcemment accompagnee de la directive SRV_SHELL_CMD.
SRV_SHELL_CMD=shell
C'est le nom de l'interpreteur de commande (shell) qui est configure dans la directive SRV_SHELL_LOC dont cette directive est forcemment accompagnee.
Directives de securisation du serveur :
Ces directives ne sont applicables que si le serveur est lance sous l'identite du super utilisateur.
PERM_USER_GROUP=user
Apres initialisation, le serveur prend l'identite (gid,uid) indiquee par l'utilisateur user.
Si la directive PERM_CHROOT est positionnee, celle-ci est d'abord appliquee.
PERM_CHROOT=path/to/chroot/directory
Apres initialisation, le serveur se bloque avec un chroot dans le repertoire indique.
Note: Ce repertoire doit etre un repertoire regulier et non un lien et doit permettre l'ecriture a l'identite sous laquelle tourne le serveur.
Directives HTTP POST serveur :
Quand le mode http_post est actionne, le serveur s'attend a recevoir des requetes HTTP POST et repond par des reponses HTTP. Comme le client peut couper la connexion TCP a intervalle regulier, le serveur maintient les applications en service et se sert pour se faire d'un numero aleatoire que le client lui envoie pour identifier si une nouvelle connexion est relative a une communication anterieure ou non.
Si une connexion TCP est ouverte et que la requete cliente ne contient pas d'URI predefinie, le serveur renvoie une page d'erreur avant de couper la connexion.
Il est possible de preciser au serveur qu'il doit repondre a certaines requetes en envoyant des fichiers preconfigures quand leurs URIs sont presentes dans la requete HTTP.
Les donnees utiles emises par le client peuvent etre masques en ajoutant des donnees avant et apres. Quand c'est le cas, le serveur ne tient pas compte de ces donnees superflues.
Les directives suivantes sont obligatoires pour le serveur en mode http_post.
HTTP_MOD_URI=/cgi-bin/cctt.cgi
L'URI specifiee dans cette directive indique au serveur que des donnees peuvent etre presentes dans le corps de la requete HTTP.
HTTP_MOD_SRV_ERROR_PAGE=error_page.txt
Le fichier specifie sera envoye par le serveur si l'URI definie dans HTTP_MOD_URI n'est pas presente dans la requete POST ou si l'URL de cette meme requete ne contient pas de fichier defini avec une directive HTTP_MOD_SRV_FAKE_URLS.
Les directives suivantes sont facultatives pour le serveur en mode http_post.
HTTP_MOD_SRV_TOP_PAD=octets
Indique au serveur qu'il y a octets de donnees superflues qui precedent les donnees utiles dans le corps de la requete HTTP.
HTTP_MOD_SRV_BOT_PAD=octets
Indique au serveur qu'il y a octets de donnees superflues qui suivent les donnees utiles dans le corps de la requete HTTP.
HTTP_MOD_CL_TOP_PAD=path/to/file
Indique au serveur de preceder les donnees utiles dans une reponse HTTP par les donnees presentes dans le fichier path/to/file.
HTTP_MOD_CL_BOT_PAD=path/to/file
Indique au serveur d'ajouter les donnees presentes dans le fichier path/to/file apres les donnees utiles d'une reponse HTTP.
HTTP_MOD_SRV_FAKE_URLS=path/to/file
Indique au serveur qu'il doit envoyer le fichier localise dans path/to/file quand il recoit une requete HTTP dont l'URI correspond a ce fichier.
Cette directive peut etre employee plusieurs fois.
FICHIER DE CONFIGURATION CLIENT
Les fichiers de configuration permettent de positionner plusieurs directives relatives au fonctionnement de Cctt.
Directives du fichier de configuration Client :
PROTOCOL=tcp|udp
C'est le protocole qui est utilise pour l'etablissement de la socket entre le client et le serveur ou entre le client et le serveur mandataire. Dans le cas d'une utilisation d'un serveur mandataire, ce protocole est obligatoirement tcp.
Cette directive est obligatoire.
Directives d'identification :
Ces directives permettent de specifier la methode d'identification utilisee entre client et serveur.
IDENT=xxx_ident
C'est le type d'identification parametre entre serveur et client. Il doit etre identique dans les deux fichiers de configuration et peut contenir les valeurs: clear_ident, basic_ident.
clear_ident ne contient aucun codage, la cle est envoyee telle quelle.
basic_ident contient un codage base sur le meme principe que le type de canal socket_encode.
Cette directive est obligatoire et est forcemment accompagnee de la directive IDENT_KEY.
IDENT_KEY=xxx
C'est la cle qui est utilisee pour identifier le client aupres du serveur. C'est une chaine ASCII.
Cette directive est obligatoire et est forcemment accompagnee de la directive IDENT.
Directives Mode Proxy :
L'utilisation de l'une de ces directives entraine l'obligation d'utilisation des autres.
Le client se positionne en ecoute sur un couple @IP:Port. Quand une application se connecte, le client se connecte au serveur, s'identifie et envoie la demande de transfert au serveur. Si cette demande est acceptee, le client recupere les donnees envoyees par l'application, leur ajoute les divers codages demandes et envoie le resultat au serveur. Il procede inversement quand il recoit des donnees du serveur.
Si le serveur accepte la demande du client, il ouvre une connexion vers l'application qui est configuree dans sa liste et transmet les donnees du client a l'application apres suppression des divers codage realises sur le flot de donnees recu. Il procede inversement en recevant des donnees de l'application avant de les renvoyer vers le client.
PROXY_MODE_PROT=tcp
En mode proxy, c'est le protocole utilise entre l'application locale et le client ainsi qu'entre le serveur et le service distant. Pour l'instant, seul le protocole tcp est supporte.
PROXY_MODE_LOCAL_IP=@IP
En mode proxy, c'est l'adresse IP avec laquelle le client se positionne en ecoute.
PROXY_MODE_LOCAL_PORT=Port
En mode proxy, c'est le port sur lequel le client se positionne en ecoute.
PROXY_MODE_REMOTE_IP=@IP
En mode proxy, c'est l'adresse IP qui est envoyee dans la demande de transfert. Cette adresse IP est comparee par le serveur avec les adresses se situant dans ses directives PROXY_MODE_LIST.
PROXY_MODE_REMOTE_PORT=port
En mode proxy, c'est le port qui est envoye dans la demande de transfert. Ce port est compare par le serveur avec les ports situes dans ses directives PROXY_MODE_LIST.
Directives Mode Proxy Inverse:
L'utilisation de l'une de ces directives entraine l'obligation d'utilisation des autres.
Le client se connecte au serveur et s'enregistre comme relais pour le serveur defini grace aux directives de son fichier de configuration. Une fois l'enregistrement effectue, le client se met en attente de donnees.
Quand le serveur recoit une demande pour ce service, il envoie les donnees au client via la connexion existante en lui indiquant de quel client applicatif il les a recues.
Le client recoit les donnees et : soit il n'a recu aucune donnees de ce client applicatif, auquel cas il ouvre une connexion vers le service parametre et fait office de proxy - soit il a deja recu des donnees de ce client applicatif auquel cas il fait office de proxy pour une connexion qu'il a ouverte precedemment.
En d'autres termes, la connexion etablie entre le client et le serveur permet un multiplexage rudimentaire.
PROXY_MODE_PROT=tcp
En mode proxy inverse, c'est le protocole utilise entre le client et le service auquel il sert de relais. Pour l'instant, seul le protocole tcp est supporte.
PROXY_MODE_REMOTE_IP=@IP
En mode proxy inverse, c'est l'adresse IP du service auquel le client sert de relais. Cette adresse IP est ajoutee dynamiquement par le serveur dans une directive PROXY_MODE_LIST et retiree lorsque le client en mode inverse coupe la connexion.
PROXY_MODE_REMOTE_PORT=port
En mode proxy inverse, c'est le port du service auquel le client sert de relais. Ce port est ajoute dynamiquement dans une directive PROXY_MODE_LIST.
Directives utilisees pour un serveur mandataire :
L'utilisation de l'une de ces directives entraine l'obligation d'utilisation des autres.
Dans le cas d'une utilisation d'un serveur mandataire faisant l'intermediaire entre le client et le serveur (types de canaux *_http_proxy_*), ces directives permettent de configurer la liaison vers le serveur mandataire.
CHANNEL_PROXY_PROT=tcp
C'est le protocole utilise entre le client et le serveur mandataire. Pour l'instant, seul le protocole tcp est supporte.
CHANNEL_PROXY_IP=@IP
C'est l'adresse IP du serveur mandataire.
CHANNEL_PROXY_PORT=Port
C'est le port utilise par le serveur mandataire pour effectuer le proxying HTTP.
CHANNEL_PROXY_DEL=Delai
C'est le temps d'attente d'une reponse du serveur mandataire avant de considerer qu'on abandonne la connexion. Il s'exprime en micro-secondes.
HTTP_PROXY_CHAINE=@Ip2:Port2:Delai;...;@Ipx:Portx:Delai
Permet d'utiliser la methode CONNECT sur une chaine de serveurs mandataires HTTP.
La premiere connexion a lieu avec le proxy defini avec CHANNEL_PROXY_IP. Sur celui-ci est envoyee la requete CONNECT vers la premiere adresse IP de la chaine HTTP_PROXY_CHAINE. Quand cette chaine est vide, on envoie la requete CONNECT pour l'adresse IP du serveur que l'on veut atteindre.
Le delai d'attente est configurable pour chaque proxy.
Directives HTTP POST client :
Quand le mode http_post est actionne, le client ouvre une connexion TCP, envoie un certain nombre de requete HTTP POST et receptionne les reponses correspondantes. Quand le nombre de requete configure est atteint, la connexion est coupee mais les applications demeurent actives. Une nouvelle connexion est alors ouverte et le meme schema se reproduit.
Le client peut envoyer un certain nombre de requetes superflues dans l'objectif de cacher les requetes legitimes. Si ces requetes superflues sont configurees au niveau du serveur, celui-ci enverra le contenu des fichiers demandes.
Il est egalement possible de cacher les donnees applicative d'une requete legitime en ajoutant des donnees avant et/ou apres dans le corps du message HTTP. Ceci permet par exemple de faire transiter pour un observateur les donnees applicatives dans des pages HTML ou dans des images.
Les directives suivantes sont obligatoires pour le client en mode http_post.
HTTP_MOD_CL_REQ_PER_CON=x
Specifie le nombre de requetes HTTP qui peuvent etre emises sur une connexion TCP avant que la connexion ne soit ferme puis re-ouverte.
HTTP_MOD_CL_DELAY_BET_CON=x
Specifie un delai minimal d'attente en msecs entre chaque emission de requete HTTP sur une connexion TCP.
HTTP_MOD_CL_HOSTNAME=hostname
Specifie que hostname doit etre ajoute dans le champ approprie du header HTTP de la requete POST.
HTTP_MOD_CL_CONTENTTYPE=content-type
Specifie que content-type doit etre utilise dans le champ approprie du header HTTP de la requete POST.
HTTP_MOD_CL_DATASIZE=x
Specifie que le client ne doit pas transmettre plus de x octets de donnees utiles dans une requete HTTP POST.
HTTP_MOD_URI=/cgi-bin/cctt.cgi
Envoie l'URI /cgi/bin/cctt.cgi dans la requete HTTP. C'est cette URI qui permettra au serveur de savoir si des donnees utiles sont presentes dans le corps de la requete HTTP.
Les directives suivantes sont facultatives pour le client en mode http_post.
HTTP_MOD_SRV_TOP_PAD=octets
Indique au client qu'il y a octets de donnees superflues qui precedent les donnees utiles dans le corps de la reponse HTTP.
HTTP_MOD_SRV_BOT_PAD=octets
Indique au client qu'il y a octets de donnees superflues qui suivent les donnees utiles dans le corps de la reponse HTTP.
HTTP_MOD_CL_TOP_PAD=path/to/file
Indique au client de preceder les donnees utiles dans une requete HTTP POST par les donnees presentes dans le fichier path/to/file.
HTTP_MOD_CL_BOT_PAD=path/to/file
Indique au client d'ajouter les donnees presentes dans le fichier path/to/file apres les donnees utiles d'une requete HTTP POST.
HTTP_MOD_CL_FAKE_URLS=GET /index.html HTTP/1.0
Indique au client qu'il doit envoyer la requete GET /index.html HTTP/1.0 au serveur. Cette requete est superflue : Si le serveur est configure pour envoyer le fichier present dans l'URI, il enverra le fichier et le client se contentera de le lire sans l'utiliser dans son fonctionnement applicatif.
Cette directive peut etre employee plusieurs fois.
L'utilisation de cette directive entraine obligatoirement l'utilisation de la directive HTTP_MOD_CL_FAKE_URLS_FREQ.
HTTP_MOD_CL_FAKE_URLS_FREQ=x
Cette directive indique au client la frequence d'envoi des requetes precisees avec la directive HTTP_MOD_CL_FAKE_URLS.
Si x est egal a -1, les requetes superflues seront envoyees toutes les y requetes legitimes (avec y aleatoire), si x est egal a 1, les requetes superflues seront envoyees pour chaque requete legitime et si x est egal a y>1, les requetes superflues seront envoyees toutes les y requetes legitimes.
L'utilisation de cette directive entraine obligatoirement l'utilisation d'au moins une directive HTTP_MOD_CL_FAKE_URLS.
MODE INTERACTIF
L'execution du serveur permet d'entrer quelques commandes en mode interactif. Ces commandes sont :
help
Affiche les commandes disponibles.
show connections
Affiche les connexions en cours.
show params
Affiche les informations d'initialisation du serveur.
kill connection X
Ferme la connexion allouee sur le socket descriptor X.
kill manager X
Tue le manager gerant la connexion allouee sur le socket descriptor X.
tell client X 'something'
Envoie la commande something au client de la connexion allouee sur le socket descriptor X.
quit
Stoppe le serveur.
SECURITE
Cctt est un outil de test. Je ne recommande donc pas son utilisation dans un environnement de production.
Aucun audit du code n'a eu lieu. Il serait preferable, si vous utilisez Cctt sur une plate-forme connectee a Internet, que vous l'executiez avec une identite possedant des droits restreints et qu'il soit bloque dans un cage.
Pour ce faire, soit vous creez votre environnement personel, soit vous utilisez les fonctionnalites presentees dans Directives de securisation du serveur.
AUTEUR
Simon Castro <scastro [at] entreelibre.com>
CONTRIBUTIONS
Olivier Dembour <odembour [at] entreelibre.com>, Hadi El-Khoury <helkhoury [at] entreelibre.com> et Alex Dyatlov <alex [at] gray-world.net>
DISTRIBUTION
La derniere version de Cctt peut etre obtenue sur http://www.entreelibre.com/cctt
LICENCE
CCTT - Covert Channel Tunneling Tool - v0.1.7, Copyright (C) 2002,2003 Simon Castro (scastro@entreelibre.com)
Cctt 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.
Cctt 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 Cctt; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA02111-1307 USA
Cctt v0.1.7 CCTT(1)
Licence :
This website and its content is part of the online documentation of CCTT - Covert Channel Tunneling Tool v0.1.7 - Copyright (C) 2002,2003 Simon Castro.
Cctt 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.
Cctt 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 Cctt; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA02111-1307 USA
Simon Castro Maj le 9 Juin 2003
|