lisezmoi.developpeurs

Cctt, "Covert Channel Tunneling Tool" - 顾名思义

CCTT - Covert Channel Tunneling Tool v0.1.8 - LISEZMOI.developpeurs
Copyright (C) 2002,2003 Simon Castro - [e-mail]
$Id: LISEZMOI.developpeurs,v 1.9 2003/08/29 10:11:51 simsim Exp $


================================================================================
This file is part of CCTT - Covert  Channel  Tunneling  Tool  v0.1.8  (C)  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, MA  02111-1307  USA
================================================================================

Ce fichier documente (succinctement) le code de CCTT de facon a ce que quiconque
puisse parvenir le plus  facilement  possible  a  debugger  l'application  ou  a
ajouter de nouvelles fonctionnalites.

Toutes les contributions, qu'elles  soient  un  exemple  de  code,  une  version
modifiee ou simplement une idee, sont les bienvenues.

La seule obligation que je pose est que le code soit documente.

Note : Meme si je ne le fais pas moi meme (:>), je  prefererais  que  toutes les
variables soient positionnees dans la structure S_OPTIONS *options, plutot qu'en
globales dans le code.

Pour m'envoyer un patch, vous pouvez utiliser la commande :
diff -urbBaN cctt-ma_version cctt-votre_version > votre_version.patch

Note Finale : Les explications de ce fichier ont ete ecrites pour la  v0.1.5  et
ne sont pas a jour.

================================================================================

A) Description du code general
B) Description du code serveur
   B1) Description d'une connexion TCP
   B2) Description d'une connexion UDP
   B3) Execution d'un type de canal
   B4) Identification du client
   B5) Autorisation de service
       B5A) Shell serveur
       B5B) Demande de la liste Proxy
       B5C) ReverseShell
       B5D) Demande de proxy.
   B6) Mode interactif 
C) Description du code client
   C1) Etablissement de la connexion reseau
   C2) Identification du client
   C3) Shell demande au serveur ou demande de liste d'autorisation Proxy
   C4) Envoi d'un ReverseShell au serveur

  I) Activation du mode DEBUG
 II) Comment ajouter un type de canal ?
III) Comment ajouter un type d'identification ?
 IV) Comment ajouter un parametre dans un fichier de configuration ?

================================================================================

A) Description du code general

  Un seul binaire effectue les taches du serveur et du client.
    L'execution initiale est commune au serveur et au client et est composee des
  actions suivantes :
    * Verification des parametres passes en ligne de commande et initialisation.
      Si une erreur est detectee, Cctt quitte.
    * Verification des parametres du fichier de configuration et initialisation.
      Si une erreur est detectee, Cctt quitte.
    * Verification finale de l'initialisation. Si une erreur est detectee,  Cctt
      quitte.
  Le binaire lance ensuite le serveur ou le client.

  => Tous ces appels sont effectues a partir de la fonction main (main.c) ou des
     fonctions qui lui sont rattachees.

    Les 4 fonctions qui suivent sont appellees lors des read/write relatifs a la
  communication des parties (voir do_server_deencode.c et do_client_deencode.c):
    * do_server_has_something_to_encode et do_client_has_something_to_encode
    * do_server_has_something_to_decode et do_client_has_something_to_decode
  => Elles permettent d'encoder/decoder/riendutout_er les buffers et  d'ajouter/
     retirer/riendutout_er les headers avant emission/reception.

================================================================================

B) Description du code serveur

    Une fois initialise, le serveur execute une  boucle principale : do_server()
  (do_server.c) qui attend qu'un appel systeme select retourne.
    Quand le select retourne, plusieurs fonctions sont appellees les unes  apres
  les autres :
    * check_sd_and_exec() : Permet de verifier  quel  socket  descriptor  a  ete
      active et en fonction du protocole serveur (TCP ou UDP) d'enregistrer  les
      clients, de traiter leurs demandes et de les desenregistrer.
    * check_managers() : Verifie si un manager (processus permettant  de  lancer
      un shell au niveau du serveur) est termine ou pas. Si c'est le cas,  cette
      fonction s'occupe de fermer les canaux associes.
    * check_proxy_connections() : Verifie si les applications cote  serveur  ont
      quelque chose a envoyer aux clients (mode proxy).
    * check_if_client_waits() : Verifie (TCP) si  les  clients  ont  depasse  le
      seuil d'attente avant l'envoi de leur buffer a l'application concernee  et
      met a jour certaines informations sur les clients.

  B1) Description d'une connexion TCP

    Quand un client se connecte, le socket descriptor serveur est active  et  un
  contexte client est initialise avec  un  index  base  sur  le  nouveau  socket
  descriptor attribue par l'appel systeme accept() (check_sd_and_exec()).

    Quand des donnees se presentent sur le nouveau sd, le client  est  considere
  comme enregistre au niveau reseau (check_sd_and_exec() et il est fait appel  a
  la fonction srv_manage_client(). Cette fonction lit les donnees presentent sur
  la socket, les stocke dans un buffer temporaire et met a jour une structure de
  temps. S'il n'y a pas de place dans le buffer  temporaire,  les  donnees  sont
  immediatement soumises pour traitement (do_channel() : channels.c).

    La  fonction  check_if_client_waits()  executee  apres  retour   du   select
  principal verifie  (meme  si  aucun  socket  descriptor  n'a  ete  active)  la
  structure   de   temps   precedente   a   intervalle   regulier   defini   par
  WAITIME_BEFORE_ACTION (includes/definitions.h)  et  si  le  temps  est  ecoule
  appelle la fonction do_channel() (channels.c) egalement.

  B2) Description d'une connexion UDP

    Quand un client se connecte (ie : un datagramme UDP parvient au serveur), la
  fonction srv_manage_client_udp() (do_server.c) est  executee.  Cette  fonction
  est chargee d'identifier si le client est  enregistre  au  niveau  reseau,  de
  l'enregistrer si tel n'est pas  le  cas  et  de  soumettre  les  donnees  pour
  traitement.

    Contrairement, a l'enregistrement reseau d'une connexion TCP  (dont  l'index
  est  base  sur  un  numero  de  socket  descriptor  fixe),  les  clients  sont
  enregistres en UDP avec  un  index  relatif  a  la  struct  sockaddr  qui  les
  caracterise.

    Comme pour la gestion TCP, le traitement des donnees s'effectue par  l'appel
  de la fonction do_channel() (channels.c).

  B3) Execution d'un type de canal

    La fonction do_channel()  lance  a  partir  d'un  tableau  de  pointeur  sur
  fonction la fonction de gestion de canal requise. C'est  l'une  des  fonctions
  server_do_xxx (server_do_xxx.c).
    Ces fonctions ont pour but de :
      * identifier/autoriser le client.
      * identifier/autoriser la demande de service du client.
      * soumettre les donnees pour  traitement  une  fois  les  deux  conditions
        precedentes approuvees.

    Ces fonctions recuperent en parametre le buffer qui a ete lu sur  la  socket
  et, en fonction du type de canal, elles desencodent/desencapsule  les  donnees
  qui les interesse.

  B4) Identification du client

    L'identification du client est realisee apres  l'enregistrement  reseau.  Si
  cette identification est incorrecte, la connexion est fermee  et  le  contexte
  client reinitialise.

    La fonction  d'identification  srv_ident_client()  (srv_ident_client.c)  est
  relative au type de  canal  utilise  (voir B3)  et  se  charge  d'executer  la
  fonction convenable qui peut etre :
      * srv_ident_client_clear  : La requete d'identification est en clair.
      * srv_ident_client_basic  : La requete d'identification est codee selon le
        principe du canal socket_encode.

    Ces  fonctions,  apres  desencapsulations/decodages  eventuels,  verifie  la
  pertinence des donnees emises par le client :
      * La cle envoyee par le client est elle valide ?
      * La demande de service envoyee par le client est elle valide ?

  B5) Autorisation de service

    L'autorisation         de         service         srv_check_client_request()
  (srv_check_client_request.c) verifie la demande de service et si celle-ci  est
  convenable prepare le service demande :
      * Shell serveur demande par le client   : server_was_asked_a_shell()  dans
        le .c du meme nom.
      * ReverseShell client envoye au serveur : Enregistrement    du   type   de
        service.
      * Demande de la liste Proxy             : send_proxy_list_and_close() dans
        le .c du meme nom.
      * Demande de proxy                      : Enregistrement    du   type   de
        service.

    Deux types de services apparaissent donc. Le premier est charge de gerer  la
  connexion immediatement, le second est  charge  d'enregistrer  la  demande  de