Projet d'Initiation à la Recherche (PIR) | 4A-IR-SI | INSA Toulouse

NOM DU PIR

Membres : (Noms ecrit de mémoire, check orthographe) - Léonie Gallois - Elies Tali - Yohan Simard - Paul Faure - Nahom Bellay - Jean Remi Hok

Tuteurs : - Didier LeBotlan - Eric AlataS

WARNING : TO USE THE MAKEFILE YOU MAY NEED "gcc-multilib" (sudo apt-get install gcc-multilib)

Programmes SERVEUR et CLIENT, principe général :

- Le serveur : Gere un entier (init 0) En écoute sur un port passé en paramètre, des qu'une connexion arrive, il fork, traite la connexion dans le fils, le père se remet en attente
- Gestion de la connexion : Attends une chaine de caractère du client, et, en fonction de son contenu effectue les actions adéquates
- Chaine attendues : 
		* ADD/SUB/MUL/DIV      : Le serveur additionne, soustrait, multiplie, divise la valeur actuelle par l'argument passé
		* RESET								 : Le serveur remet l'entier a 0
		* GET 								 : Le serveur envoi la valeur de l'entier
		* PRINT                : Le serveur affiche la valeur de l'entier

- Le client : Demande a l'utilisateur de saisir une chaine, puis, affiche la réponse du serveur (si elle a lieu d'être)

- Failles : 
		* Le serveur copie la chaine reçue avec le read mal fait -> risque de buffer Overflow
		* Le serveur fork, l'attaquant peut accumuler de la connaissance

Etapes de dévellopement :

- Step 1 : FAIT
		* Le serveur  : Gere le nombre de connexions, à chaque connexions, il l'affiche juste.
		* Le client   : Se connecte et ferme la connexion aussitôt.
		* Utilité     : Test de l'établissement des connexions. 
		* Retour test : OK.
- Step 2 : FAIT
		* Le serveur  : Gere le nombre de connexions, à chaque connexions, dans le fils, il appelle une fonction d'affichage.
		* La fonction : Reçoit la nombre de connexion, l'affiche, ainsi que son adresse mémoire.
		* Le client   : Se connecte et ferme la connexion aussitôt.
		* Utilité     : Verification que les adresses ne changent pas dans la pile d'un fork à l'autre. 
		* Retour test : Adresses identiques a chaque connexions.
- Step 3 : FAIT
		* Le serveur  : Gere l'entier, à chaque connexions, dans le fils, on appelle une fonction de lecture de la requette (read avec BOF possible) puis traite la requete.
		* La fonction : Lit la chaine et renvoi une structure correspondant a l'action a faire.
		* Le client   : Se connecte, demande a l'utilisateur de saisir la chaine, affiche la réponse, et ferme la connexion.
		* Utilité     : Test du serveur dans son fonctionnement normal. Test BOF possible
		* Retour test : Serveur OK, BOF OK (detecté par le canary).
- Step 4 : TESTER LES PREMIERES EXPLOITATIONS