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

IMA4 2017/2018 P17

2017-10-09T17:01:41Z

Onaanaa : /* Liste des tâches à effectuer */

__TOC__
 

=Présentation générale=

* Titre du projet : SafeWatch

* Description : Montre connectée simple d'utilisation permettant de réorienter les personnes en difficulté.

==Objectifs==
De plus en plus de personnes se retrouvent seules en vieillissant, aussi bien chez elles qu’à l’extérieur. Nous sommes là pour faire le lien entre les deux. Notre montre, simple d’utilisation, vous permettra de rentrer chez vous au plus vite et d’appeler vos proches ou même les urgences en cas de nécessité. Cette montre dispose de trois boutons. Le premier permet de retrouver son chemin, le deuxième d’appeler ses proches et les urgences en cas de non-réponse et le troisième de revenir à la fonction horloge. Cette montre est reliée à une application installée sur le téléphone de la personne référente, application qui reçoit les appels et affiche la position de la montre.

==Positionnement par rapport à l'existant==
Notre montre permet, en plus de la géolocalisation et de l’appel des proches, de rediriger les personnes jusqu’à leur logement.

=Analyse du projet=

==Analyse du premier concurrent==

Arkea assistance :
*Montre connectée qui permet de déclencher à tout moment et en tous lieux une alerte en cas de besoin.
*Principe d’utilisation : Vous appuyez, vous êtes géolocalisé, nous vous écoutons
*Abonnement à une téléassistance
*Prix montre + abonnement = 13,45+24,90 par mois
*Inconvénients : montre tactile (peu pratique pour les personnes âgées), ne permet pas d’appeler les proches, pas d'orientation via GPS, prix de l’abonnement élevé.

==Analyse du second concurrent==

Libr’Alert :
*Une montre avec bouton SOS, très légère au design élégant
*Système de géolocalisation intégré
*Un dispositif que vous avez toujours à portée de main
*La réception et gestion des appels 24h/24 et 7j/7 par notre centrale d’écoute.
*La géolocalisation de l’appel d’urgence afin de pouvoir orienter les secours vers le bon endroit.
*Prix : 34,90€ par mois
*Inconvénients : pas de GPS, pas de possibilité de contacter les proches

==Scénario d'usage du produit ou du concept envisagé==

Fait divers : Une personne agée a été retrouvée, dix jours après sa disparition, en état de décomposition, dans un buisson non loin de chez elle. Cette femme d’un certain âge s’était perdue. Cause simple malheureusement trop fréquente. C’est dans ce cadre que la SafeWatch devient indispensable.

En effet, avec notre montre, la vieille dame aurait pu, dans un moment de lucidité, appuyer sur le bouton « appel d’un référent » afin d'envoyer un message automatique joignant sa position à un proche référent. Elle aurait pu aussi appuyer sur « retour maison » lui indiquant avec des flèches de direction le chemin pour revenir à son domicile. Sa vie tenant sur une simple pression d’un bouton de notre montre.

Mari esseulé, en état de peur face à la possibilité de perdre sa femme, aurait pu avec notre montre, la retrouver. En effet, grâce à notre option GPS dans la montre, sa femme aurait été localisée plus facilement et plus rapidement, et ainsi être encore en vie lors de sa découverte. Aujourd’hui, nous en sommes sûr il aurait aimé investir dans notre SafeWatch.

==Réponse à la question difficile==
Comment la montre se recharge-t-elle ?

Grace à un chargeur par induction (on pose sa montre à plat sur une plaque qui va recharger la batterie)

Comment éviter l'abus d'appel au référent ?

Cette montre reste réservée aux personnes pas encore totalement séniles qui sont conscientes que cet appareil va les aider. De plus, si le référent se rend compte que la personne abuse de l'option appel c'est de sa responsabilité de lui retirer la montre.
Un son sera émis lorsqu'une touche sera activée

=Réalisation du projet=

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

Afin de pouvoir réaliser les fonctions citées ci-dessus , nous utiliserons le matériel suivant : 

- Arduino UNO et 3 boutons poussoirs. 
- Géolocalisation : GPS Adafruit v3. 
- Appeler des proches ou les urgences : bouclier GSM Arduino 
- Affichage d'horloge et de l'orientation GPS vers domicile : 2.8" TFT LCD shield w/Touchscreen . 

==Calendrier prévisionnel==
==Liste des tâches à effectuer==

Tâche 1 : Réalisation du prototype : 

+ Montage sur plaque d'essai et test de l'ensemble 
+ Conception de la carte électronique rassemblant le matériel 
+ Réalisation de la carte et son boîtier en s'assurant que cela ressemblera à une montre vu le volume des boucliers 

Tache 2 : Géolocalisation : 
+ configuration du bouclier GPS 
+ Envoi de la position en appuyant sur le bouton poussoir 1 
+ Affichage de la position déjà envoyée , à l'aide d'une application mobile 
+ Afficher un message d'envoi de la position sur LCD

Tache 3 : Appeler un ou plusieurs numéros 
+ configuration du bouclier GSM 
+ Envoi des appels en appuyant sur bouton poussoir 2 
+ Envoi SMS personnalisé (Optionnel) 
+ Afficher un message d'envoi d'appel sur LCD 

Tache 4 : Horloge 
+ Afficher l'horloge sur LCD en appuyant sur le bouton poussoir 3 

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Analyse du projet
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

=Avancement du Projet=

==Prologue==
==Semaine 1==

=Fichiers Rendus=

IMA4 2017/2018 P17

2017-10-09T16:01:19Z

Onaanaa : /* Choix techniques : matériel et logiciel */

__TOC__
 

=Présentation générale=

* Titre du projet : SafeWatch

* Description : Montre connectée simple d'utilisation permettant de réorienter les personnes en difficulté.

==Objectifs==
De plus en plus de personnes se retrouvent seules en vieillissant, aussi bien chez elles qu’à l’extérieur. Nous sommes là pour faire le lien entre les deux. Notre montre, simple d’utilisation, vous permettra de rentrer chez vous au plus vite et d’appeler vos proches ou même les urgences en cas de nécessité. Cette montre dispose de trois boutons. Le premier permet de retrouver son chemin, le deuxième d’appeler ses proches et les urgences en cas de non-réponse et le troisième de revenir à la fonction horloge. Cette montre est reliée à une application installée sur le téléphone de la personne référente, application qui reçoit les appels et affiche la position de la montre.

==Positionnement par rapport à l'existant==
Notre montre permet, en plus de la géolocalisation et de l’appel des proches, de rediriger les personnes jusqu’à leur logement.

=Analyse du projet=

==Analyse du premier concurrent==

Arkea assistance :
*Montre connectée qui permet de déclencher à tout moment et en tous lieux une alerte en cas de besoin.
*Principe d’utilisation : Vous appuyez, vous êtes géolocalisé, nous vous écoutons
*Abonnement à une téléassistance
*Prix montre + abonnement = 13,45+24,90 par mois
*Inconvénients : montre tactile (peu pratique pour les personnes âgées), ne permet pas d’appeler les proches, pas d'orientation via GPS, prix de l’abonnement élevé.

==Analyse du second concurrent==

Libr’Alert :
*Une montre avec bouton SOS, très légère au design élégant
*Système de géolocalisation intégré
*Un dispositif que vous avez toujours à portée de main
*La réception et gestion des appels 24h/24 et 7j/7 par notre centrale d’écoute.
*La géolocalisation de l’appel d’urgence afin de pouvoir orienter les secours vers le bon endroit.
*Prix : 34,90€ par mois
*Inconvénients : pas de GPS, pas de possibilité de contacter les proches

==Scénario d'usage du produit ou du concept envisagé==

Fait divers : Une personne agée a été retrouvée, dix jours après sa disparition, en état de décomposition, dans un buisson non loin de chez elle. Cette femme d’un certain âge s’était perdue. Cause simple malheureusement trop fréquente. C’est dans ce cadre que la SafeWatch devient indispensable.

En effet, avec notre montre, la vieille dame aurait pu, dans un moment de lucidité, appuyer sur le bouton « appel d’un référent » afin d'envoyer un message automatique joignant sa position à un proche référent. Elle aurait pu aussi appuyer sur « retour maison » lui indiquant avec des flèches de direction le chemin pour revenir à son domicile. Sa vie tenant sur une simple pression d’un bouton de notre montre.

Mari esseulé, en état de peur face à la possibilité de perdre sa femme, aurait pu avec notre montre, la retrouver. En effet, grâce à notre option GPS dans la montre, sa femme aurait été localisée plus facilement et plus rapidement, et ainsi être encore en vie lors de sa découverte. Aujourd’hui, nous en sommes sûr il aurait aimé investir dans notre SafeWatch.

==Réponse à la question difficile==
Comment la montre se recharge-t-elle ?

Grace à un chargeur par induction (on pose sa montre à plat sur une plaque qui va recharger la batterie)

Comment éviter l'abus d'appel au référent ?

Cette montre reste réservée aux personnes pas encore totalement séniles qui sont conscientes que cet appareil va les aider. De plus, si le référent se rend compte que la personne abuse de l'option appel c'est de sa responsabilité de lui retirer la montre.
Un son sera émis lorsqu'une touche sera activée

=Réalisation du projet=

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

Afin de pouvoir réaliser les fonctions citées ci-dessus , nous utiliserons le matériel suivant : 

- Arduino UNO et 3 boutons poussoirs. 
- Géolocalisation : GPS Adafruit v3. 
- Appeler des proches ou les urgences : bouclier GSM Arduino 
- Affichage d'horloge et de l'orientation GPS vers domicile : 2.8" TFT LCD shield w/Touchscreen . 

==Calendrier prévisionnel==
==Liste des tâches à effectuer==
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Analyse du projet
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

=Avancement du Projet=

==Prologue==
==Semaine 1==

=Fichiers Rendus=

IMA4 2017/2018 P17

2017-10-09T16:00:56Z

Onaanaa : /* Choix techniques : matériel et logiciel */

__TOC__
 

=Présentation générale=

* Titre du projet : SafeWatch

* Description : Montre connectée simple d'utilisation permettant de réorienter les personnes en difficulté.

==Objectifs==
De plus en plus de personnes se retrouvent seules en vieillissant, aussi bien chez elles qu’à l’extérieur. Nous sommes là pour faire le lien entre les deux. Notre montre, simple d’utilisation, vous permettra de rentrer chez vous au plus vite et d’appeler vos proches ou même les urgences en cas de nécessité. Cette montre dispose de trois boutons. Le premier permet de retrouver son chemin, le deuxième d’appeler ses proches et les urgences en cas de non-réponse et le troisième de revenir à la fonction horloge. Cette montre est reliée à une application installée sur le téléphone de la personne référente, application qui reçoit les appels et affiche la position de la montre.

==Positionnement par rapport à l'existant==
Notre montre permet, en plus de la géolocalisation et de l’appel des proches, de rediriger les personnes jusqu’à leur logement.

=Analyse du projet=

==Analyse du premier concurrent==

Arkea assistance :
*Montre connectée qui permet de déclencher à tout moment et en tous lieux une alerte en cas de besoin.
*Principe d’utilisation : Vous appuyez, vous êtes géolocalisé, nous vous écoutons
*Abonnement à une téléassistance
*Prix montre + abonnement = 13,45+24,90 par mois
*Inconvénients : montre tactile (peu pratique pour les personnes âgées), ne permet pas d’appeler les proches, pas d'orientation via GPS, prix de l’abonnement élevé.

==Analyse du second concurrent==

Libr’Alert :
*Une montre avec bouton SOS, très légère au design élégant
*Système de géolocalisation intégré
*Un dispositif que vous avez toujours à portée de main
*La réception et gestion des appels 24h/24 et 7j/7 par notre centrale d’écoute.
*La géolocalisation de l’appel d’urgence afin de pouvoir orienter les secours vers le bon endroit.
*Prix : 34,90€ par mois
*Inconvénients : pas de GPS, pas de possibilité de contacter les proches

==Scénario d'usage du produit ou du concept envisagé==

Fait divers : Une personne agée a été retrouvée, dix jours après sa disparition, en état de décomposition, dans un buisson non loin de chez elle. Cette femme d’un certain âge s’était perdue. Cause simple malheureusement trop fréquente. C’est dans ce cadre que la SafeWatch devient indispensable.

En effet, avec notre montre, la vieille dame aurait pu, dans un moment de lucidité, appuyer sur le bouton « appel d’un référent » afin d'envoyer un message automatique joignant sa position à un proche référent. Elle aurait pu aussi appuyer sur « retour maison » lui indiquant avec des flèches de direction le chemin pour revenir à son domicile. Sa vie tenant sur une simple pression d’un bouton de notre montre.

Mari esseulé, en état de peur face à la possibilité de perdre sa femme, aurait pu avec notre montre, la retrouver. En effet, grâce à notre option GPS dans la montre, sa femme aurait été localisée plus facilement et plus rapidement, et ainsi être encore en vie lors de sa découverte. Aujourd’hui, nous en sommes sûr il aurait aimé investir dans notre SafeWatch.

==Réponse à la question difficile==
Comment la montre se recharge-t-elle ?

Grace à un chargeur par induction (on pose sa montre à plat sur une plaque qui va recharger la batterie)

Comment éviter l'abus d'appel au référent ?

Cette montre reste réservée aux personnes pas encore totalement séniles qui sont conscientes que cet appareil va les aider. De plus, si le référent se rend compte que la personne abuse de l'option appel c'est de sa responsabilité de lui retirer la montre.
Un son sera émis lorsqu'une touche sera activée

=Réalisation du projet=

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

Afin de pouvoir les fonctions citées ci-dessus , nous utiliserons le matériel suivant : 

- Arduino UNO et 3 boutons poussoirs. 
- Géolocalisation : GPS Adafruit v3. 
- Appeler des proches ou les urgences : bouclier GSM Arduino 
- Affichage d'horloge et de l'orientation GPS vers domicile : 2.8" TFT LCD shield w/Touchscreen . 

==Calendrier prévisionnel==
==Liste des tâches à effectuer==
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Analyse du projet
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

=Avancement du Projet=

==Prologue==
==Semaine 1==

=Fichiers Rendus=

IMA4 2017/2018 P17

2017-10-09T15:22:25Z

Onaanaa : /* Analyse du premier concurrent */

__TOC__
 

=Présentation générale=

* Titre du projet : SafeWatch

* Description : Montre connectée simple d'utilisation permettant de réorienter les personnes en difficulté.

==Objectifs==
De plus en plus de personnes se retrouvent seules en vieillissant, aussi bien chez elles qu’à l’extérieur. Nous sommes là pour faire le lien entre les deux. Notre montre, simple d’utilisation, vous permettra de rentrer chez vous au plus vite et d’appeler vos proches ou même les urgences en cas de nécessité. Cette montre dispose de trois boutons. Le premier permet de retrouver son chemin, le deuxième d’appeler ses proches et les urgences en cas de non-réponse et le troisième de revenir à la fonction horloge. Cette montre est reliée à une application installée sur le téléphone de la personne référente, application qui reçoit les appels et affiche la position de la montre.

==Positionnement par rapport à l'existant==
Notre montre permet, en plus de la géolocalisation et de l’appel des proches, de rediriger les personnes jusqu’à leur logement.

=Analyse du projet=

==Analyse du premier concurrent==

Arkea assistance :
*Montre connectée qui permet de déclencher à tout moment et en tous lieux une alerte en cas de besoin.
*Principe d’utilisation : Vous appuyez, vous êtes géolocalisé, nous vous écoutons
*Abonnement à une téléassistance
*Prix montre + abonnement = 13,45+24,90 par mois
*Inconvénients : montre tactile (peu pratique pour les personnes âgées), ne permet pas d’appeler les proches, pas d'orientation via GPS, prix de l’abonnement élevé.

==Analyse du second concurrent==

Libr’Alert :
*Une montre avec bouton SOS, très légère au design élégant
*Système de géolocalisation intégré
*Un dispositif que vous avez toujours à portée de main
*La réception et gestion des appels 24h/24 et 7j/7 par notre centrale d’écoute.
*La géolocalisation de l’appel d’urgence afin de pouvoir orienter les secours vers le bon endroit.
*Prix : 34,90€ par mois
*Inconvénients : pas de GPS, pas de possibilité de contacter les proches

==Scénario d'usage du produit ou du concept envisagé==

Fait divers : Une personne agée a été retrouvée, dix jours après sa disparition, en état de décomposition, dans un buisson non loin de chez elle. Cette femme d’un certain âge s’était perdue. Cause simple malheureusement trop fréquente. C’est dans ce cadre que la SafeWatch devient indispensable.

En effet, avec notre montre, la vieille dame aurait pu, dans un moment de lucidité, appuyer sur le bouton « appel d’un référent » afin d'envoyer un message automatique joignant sa position à un proche référent. Elle aurait pu aussi appuyer sur « retour maison » lui indiquant avec des flèches de direction le chemin pour revenir à son domicile. Sa vie tenant sur une simple pression d’un bouton de notre montre.

Mari esseulé, en état de peur face à la possibilité de perdre sa femme, aurait pu avec notre montre, la retrouver. En effet, grâce à notre option GPS dans la montre, sa femme aurait été localisée plus facilement et plus rapidement, et ainsi être encore en vie lors de sa découverte. Aujourd’hui, nous en sommes sûr il aurait aimé investir dans notre SafeWatch.

==Réponse à la question difficile==
Comment la montre se recharge-t-elle ?

Grace à un chargeur par induction (on pose sa montre à plat sur une plaque qui va recharger la batterie)

Comment éviter l'abus d'appel au référent ?

Cette montre reste réservée aux personnes pas encore totalement séniles qui sont conscientes que cet appareil va les aider. De plus, si le référent se rend compte que la personne abuse de l'option appel c'est de sa responsabilité de lui retirer la montre.
Un son sera émis lorsqu'une touche sera activée

=Réalisation du projet=

==Choix techniques : matériel et logiciel==
==Calendrier prévisionnel==
==Liste des tâches à effectuer==
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Analyse du projet
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

=Avancement du Projet=

==Prologue==
==Semaine 1==

=Fichiers Rendus=

IMA4 2017/2018 P17

2017-10-09T15:14:02Z

Onaanaa : /* Analyse du premier concurrent */

__TOC__
 

=Présentation générale=

* Titre du projet : SafeWatch

* Description : Montre connectée simple d'utilisation permettant de réorienter les personnes en difficulté.

==Objectifs==
De plus en plus de personnes se retrouvent seules en vieillissant, aussi bien chez elles qu’à l’extérieur. Nous sommes là pour faire le lien entre les deux. Notre montre, simple d’utilisation, vous permettra de rentrer chez vous au plus vite et d’appeler vos proches ou même les urgences en cas de nécessité. Cette montre dispose de trois boutons. Le premier permet de retrouver son chemin, le deuxième d’appeler ses proches et les urgences en cas de non-réponse et le troisième de revenir à la fonction horloge. Cette montre est reliée à une application installée sur le téléphone de la personne référente, application qui reçoit les appels et affiche la position de la montre.

==Positionnement par rapport à l'existant==
Notre montre permet, en plus de la géolocalisation et de l’appel des proches, de rediriger les personnes jusqu’à leur logement.

=Analyse du projet=

==Analyse du premier concurrent==

Arkea assistance :
*Montre connectée qui permet de déclencher à tout moment et en tous lieux une alerte en cas de besoin.
*Principe d’utilisation : Vous appuyez, vous êtes géolocalisé, nous vous écoutons
*Abonnement à une téléassistance
*Prix montre + abonnement = 13,45+24,90 par mois
*Inconvénients : montre tactile (peu pratique pour les personnes âgées), ne permet pas d’appeler les proches, prix de l’abonnement élevé.

==Analyse du second concurrent==

Libr’Alert :
*Une montre avec bouton SOS, très légère au design élégant
*Système de géolocalisation intégré
*Un dispositif que vous avez toujours à portée de main
*La réception et gestion des appels 24h/24 et 7j/7 par notre centrale d’écoute.
*La géolocalisation de l’appel d’urgence afin de pouvoir orienter les secours vers le bon endroit.
*Prix : 34,90€ par mois
*Inconvénients : pas de GPS, pas de possibilité de contacter les proches

==Scénario d'usage du produit ou du concept envisagé==

Fait divers : Une personne agée a été retrouvée, dix jours après sa disparition, en état de décomposition, dans un buisson non loin de chez elle. Cette femme d’un certain âge s’était perdue. Cause simple malheureusement trop fréquente. C’est dans ce cadre que la SafeWatch devient indispensable.

En effet, avec notre montre, la vieille dame aurait pu, dans un moment de lucidité, appuyer sur le bouton « appel d’un référent » afin d'envoyer un message automatique joignant sa position à un proche référent. Elle aurait pu aussi appuyer sur « retour maison » lui indiquant avec des flèches de direction le chemin pour revenir à son domicile. Sa vie tenant sur une simple pression d’un bouton de notre montre.

Mari esseulé, en état de peur face à la possibilité de perdre sa femme, aurait pu avec notre montre, la retrouver. En effet, grâce à notre option GPS dans la montre, sa femme aurait été localisée plus facilement et plus rapidement, et ainsi être encore en vie lors de sa découverte. Aujourd’hui, nous en sommes sûr il aurait aimé investir dans notre SafeWatch.

==Réponse à la question difficile==
Comment la montre se recharge-t-elle ?

Grace à un chargeur par induction (on pose sa montre à plat sur une plaque qui va recharger la batterie)

Comment éviter l'abus d'appel au référent ?

Cette montre reste réservée aux personnes pas encore totalement séniles qui sont conscientes que cet appareil va les aider. De plus, si le référent se rend compte que la personne abuse de l'option appel c'est de sa responsabilité de lui retirer la montre.
Un son sera émis lorsqu'une touche sera activée

=Réalisation du projet=

==Choix techniques : matériel et logiciel==
==Calendrier prévisionnel==
==Liste des tâches à effectuer==
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Analyse du projet
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

=Avancement du Projet=

==Prologue==
==Semaine 1==

=Fichiers Rendus=

IMA4 2016/2017 P33

2017-05-18T12:34:36Z

Onaanaa : /* Feuille d'heures */

=Présentation du projet=
===Contexte===
Les objets connectés se font une place dans le quotidien et se déploient de plus en plus mais en ce qui concerne leur sécurité, il apparaît que les fabricants ont souvent négligé la sécurité des technologies et de les protéger contre les cyberattaques.
Afin de tester la sécurité des réseaux utilisés dans les objets connectés, nous étudierons le fonctionnement de ces protocoles. Dans le cadre de ce projet nous nous intéresserons aux protocoles LoRa et SigFox.

===Objectif===
L'objectif est donc de réaliser l'écoute de trame d'un réseau sans-fil (LoRa et SigFox) en capturant des trames afin de comprendre le fonctionnement de ces protocoles, et déterminer le format des trames ainsi que des méthodes d'attaque du réseau. C'est ce qu'on appelle l'ingénierie inverse.

===Description du projet===

Pour comprendre le fonctionnement du protocole, nous mettrons en place une maquette contenant des émetteurs et récepteurs afin d'écouter les trames dans le réseau. Une fois la maquette prête, nous mettrons en place une méthode d'écoute des trames et des captures de trames par un analyseur de spectre pour ensuite décoder ces trames.
Pour tester les attaques de type man in the middle, ie introduire des trames dans le réseau, nous allons créer des trames et les faire accepter par le réseau.

===Choix techniques : matériel et logiciel===
'''Fonction principale:'''

Ingénierie inverse : Pouvoir injecter des trames “écrites à la main” entre l'émetteur/récepteur LoRa.

'''Sous-fonction 1:'''

'''Sous-fonction 1:'''
Effectuer la communication entre les modules LoRa:

Pour etablir la communication on utilisera deux Arduino qui serviront à controler l’emission et la reception des données ainsi que les messages à transmettre.

[[Fichier:pt1.png]]

Sous-fonction 2:
on récupère le signal avec un analyseur de spectre pour pouvoir “décoder” le paquet LoRa.

[[Fichier:pt2.png]]

'''
Sous-fonction 3:'''

A partir du paquet “décodé” , écrire un autre paquet pour l’envoyer à un récepteur LoRa .
Pour l’interception , en fonction de la trame que recoit les modules LoRa , on décidera la méthode avec laquelle on intercepte la communication afin d’envoyer des trames “ecrites à la main”.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

'''Tâche 1''': Etablir la communication entre deux modules LoRa. 
'''Tâche 2''' :Visualiser sur l'analyseur de spectre le signal émis . 
'''Tâche 3''': .Prise en main du format du protocole LoRa 
'''Tâche 4''' : Ecrire un paquet LoRa et le faire accepter par un module LoRa . 

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
|4h
|6h
|6h
|
|
|
|
|
|
|
|
|16h
|-
|Découverte Feather + documentation LoRa
|
|
|
|4h
|
|
|
|
|
|
|
|4h
|-
|Tache1 : 1ere communication 2 feather
|
|
|
|
|6h
|
|
|
|
|
|
|6h
|-
|Test RSSI + mesures sur le spectre visualisé
|
|
|
|
|
|8h
|
|
|
|
|
|8h
|-
|Modification code émission+ réception
|
|
|
|
|
|
|8h
|
|
|
|
|8h
|-
|Plan de mesures
|
|
|
|
|
|
|
|8h
|8h
|
|
|16h
|-
|Mesures
|
|
|
|
|
|
|
|
|
|8h
|8h
|16h
|-
|
|
|
|
|
|
|
|
|
|
|
|
|74h
|}
 

==Avancement du Projet==

===Semaine 1===
Définition du cahier des charges et prise en main du protocole LoRa

===Semaine 2===

Suite du cahier des charges

===Semaine 3===

-Découverte du Feather 
-Etude sur le protocole LoRa et distinction entre Réseau (LoRaWAN) et le protocole LoRa. 

===Semaine 4===

Tache 1 réalisée: 
#Installation des librairies Adafruit (Sur deux machines pour emission/Reception) 
#Test des codes Emission/Réception proposés par la datasheet. 
#Communication réalisée entre deux modules LoRa . 

====Emission====
[[Fichier:femission.png]]

====Réception====

[[Fichier:freception.png]]

===Semaine 5===

Après avoir effectué la communication entre deux modules LoRa , on ajoute un troisième module comme étant récepteur pour voir les changement dus à la présence d'un ou d'autres récepteurs.

[[Fichier:mont3.jpg|500px|down|Montage 3 module LoRa : 1 émetteur & 2 récepteurs]]

On remarque que le RSSI (Received Signal Strength Indication) ne change quasiment pas (entre |21| et |19|) . On peut conclure que la présence de plusieurs récepteurs n'affecte pas la puissance du signal transmis .

[[Fichier:rssi1.png]]

[[Fichier:rssi2.png]]

1ere séance de mesures :

On réalise la communication LoRa entre les modules et on visualise le signal transmis avec une antenne PATCH connectée à un analyseur de spectre . 

[[Fichier:fr434.jpg|500px|down]]

On mesure pour la fréquence '''434MHz''':

'''le rapport signal sur bruit SNR '''

le rapport SNR donne une valeur de : 13 dBm
[[Fichier:cn.jpg|500px|down|]]

La puissance du signal est égale à 13 dBm . Ce résulat est identique à la puissance définit par défaut .

===Semaine 6 ===

Modification des codes d'émission et de réception : Envoyer des 1 ou des 0 au lieu du message "Hello word" ; Répondre par ce qu'on reçoit (Ping-pong)

(voir codes : fichier rendus).

===Semaine 7 et 8 ===

Plan de mesures (voir fichiers rendus en bas de la page).

===Semaine 9 et 10 ===

Mesures :

Pour visualiser le signal dans l'air , j'ai utilisé une antenne patch , en mettant tantot le module d'emission tantot le module de reception sur cette dernière .

Sur un oscilloscope 1GHz , j'ai pu visualisé les signaux suivants :

'''Emission :''' [[Fichier:Emission_patch.jpg|500px|down|]]

'''Reception: ''' [[Fichier:Reception_patch.jpg|500px|down|]]

Commentaires : Le signal d'émission visualisé en haut (c1) est la trame qu'on reçoit ; celui d'en-bas (F1) n'est qu'un zoom qui nous permet de voir la forme de ce signal.
On remarque qu'on a signal modulé en QPSK d'où le saut de phase . Cette forme ne correspond pas à la modulation LoRa qui est en chirp Spread Spectrum (CSS) (Cf. datasheet AN1200.22 LoRa™ Modulation) . 

Le cas était aussi pour le signal de reception , mais qui est modulé en AM .

Cette "déformation" des signaux est due à l'utilisation de l'antenne patch (800MHz) qui n'est pas adapté à notre antenne (434MHz). 

''''''Solution'''''' 

En évitant de passer par l’antenne patch , et en connectant directement l’antenne du module d'émission ( fil + GND) à l’oscilloscope via un câble coaxial , j’ai pu visualiser le signal prévu : 

[[Fichier:Lora_frame.jpg|500px|down|]] 
On peut remarquer la présence de deux trames , une correspond à la première émission et l’autre au retour amis par le module récepteur . 

Le signal d’en bas qui est un zoom de la trame , nous montre les chirps qu’on devrait avoir . En se basant sur la méthode suivant , on pourra décoder ce signal . 

Le but est d’avoir la taille minimale possible pour rendre plus facile le parcours de la trame .
Il faut d’abord penser à changer la bande passante et passer de 125 KHz à 8 KHz. 

'''Preamble : '''
Comme la taille du préambule n’affecte pas la transmission , on peut donc la réduire au minimum configurable qui est 6 avec la fonction setPreambleLength . Ce qui nous fera 10 symboles pour le preambule . Il faudra donc trouver 10 sauts de phases. 

'''Header : '''
En choisissant le mode SF=6 on force l’utilisation du mode implicit tout en réduisant également le nombre de chips par symbole:65 chips/symbol au lieu de 128 . 

'''Payload :'''

En utilisant maintenant SF= 6 , on envoie donc 6 char ( 111111 par exemple) et on s’attend à avoir 8 sauts de phase et 8*65 chirps ce qui donne 520 chirps pour le payload qui reste quand même beaucoup à compter pour s’en assurer . On se basera donc uniquement sur le comptage de sauts pour compter 8 symboles. Il faut noter que la taille max du payload est de 251 bits , même si on envoie que 6 bits de 1 le reste est mis à 0 . Cette taille peut être réduite en utilisant une bande passante plus petite 

'''CRC : '''
Comme on utilise le mode implicite , on n’est donc pas sur d’avoir un CRC , on vérifiera la présence de ce dernier sachant qu’il a une taille de 16 bits ce qui vaut 3 symboles à peu près . 

== Fichiers Rendus ==

[[Fichier:Plandemesures.pdf]]

[[Fichier:Rapportprojet33.pdf]]

IMA4 2016/2017 P33

2017-05-18T12:32:51Z

Onaanaa : /* Présentation du projet */

=Présentation du projet=
===Contexte===
Les objets connectés se font une place dans le quotidien et se déploient de plus en plus mais en ce qui concerne leur sécurité, il apparaît que les fabricants ont souvent négligé la sécurité des technologies et de les protéger contre les cyberattaques.
Afin de tester la sécurité des réseaux utilisés dans les objets connectés, nous étudierons le fonctionnement de ces protocoles. Dans le cadre de ce projet nous nous intéresserons aux protocoles LoRa et SigFox.

===Objectif===
L'objectif est donc de réaliser l'écoute de trame d'un réseau sans-fil (LoRa et SigFox) en capturant des trames afin de comprendre le fonctionnement de ces protocoles, et déterminer le format des trames ainsi que des méthodes d'attaque du réseau. C'est ce qu'on appelle l'ingénierie inverse.

===Description du projet===

Pour comprendre le fonctionnement du protocole, nous mettrons en place une maquette contenant des émetteurs et récepteurs afin d'écouter les trames dans le réseau. Une fois la maquette prête, nous mettrons en place une méthode d'écoute des trames et des captures de trames par un analyseur de spectre pour ensuite décoder ces trames.
Pour tester les attaques de type man in the middle, ie introduire des trames dans le réseau, nous allons créer des trames et les faire accepter par le réseau.

===Choix techniques : matériel et logiciel===
'''Fonction principale:'''

Ingénierie inverse : Pouvoir injecter des trames “écrites à la main” entre l'émetteur/récepteur LoRa.

'''Sous-fonction 1:'''

'''Sous-fonction 1:'''
Effectuer la communication entre les modules LoRa:

Pour etablir la communication on utilisera deux Arduino qui serviront à controler l’emission et la reception des données ainsi que les messages à transmettre.

[[Fichier:pt1.png]]

Sous-fonction 2:
on récupère le signal avec un analyseur de spectre pour pouvoir “décoder” le paquet LoRa.

[[Fichier:pt2.png]]

'''
Sous-fonction 3:'''

A partir du paquet “décodé” , écrire un autre paquet pour l’envoyer à un récepteur LoRa .
Pour l’interception , en fonction de la trame que recoit les modules LoRa , on décidera la méthode avec laquelle on intercepte la communication afin d’envoyer des trames “ecrites à la main”.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

'''Tâche 1''': Etablir la communication entre deux modules LoRa. 
'''Tâche 2''' :Visualiser sur l'analyseur de spectre le signal émis . 
'''Tâche 3''': .Prise en main du format du protocole LoRa 
'''Tâche 4''' : Ecrire un paquet LoRa et le faire accepter par un module LoRa . 

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
|4h
|6h
|6h
|
|
|
|
|
|
|
|
|16h
|-
|Découverte Feather + documentation LoRa
|
|
|
|4h
|
|
|
|
|
|
|
|4h
|-
|Tache1 : 1ere communication 2 feather
|
|
|
|
|6h
|
|
|
|
|
|
|6h
|-
|Test RSSI + mesures sur le spectre visualisé
|
|
|
|
|
|8h
|
|
|
|
|
|8h
|-
|Modification code émission+ réception
|
|
|
|
|
|
|8h
|
|
|
|
|8h
|-
|Plan de mesures
|
|
|
|
|
|
|
|8h
|8h
|
|
|16h
|-
|Mesures
|
|
|
|
|
|
|
|
|
|8h
|8h
|16h
|-
|
|
|
|
|
|
|
|
|
|
|
|
|74h
}
 
==Avancement du Projet==

===Semaine 1===
Définition du cahier des charges et prise en main du protocole LoRa

===Semaine 2===

Suite du cahier des charges

===Semaine 3===

-Découverte du Feather 
-Etude sur le protocole LoRa et distinction entre Réseau (LoRaWAN) et le protocole LoRa. 

===Semaine 4===

Tache 1 réalisée: 
#Installation des librairies Adafruit (Sur deux machines pour emission/Reception) 
#Test des codes Emission/Réception proposés par la datasheet. 
#Communication réalisée entre deux modules LoRa . 

====Emission====
[[Fichier:femission.png]]

====Réception====

[[Fichier:freception.png]]

===Semaine 5===

Après avoir effectué la communication entre deux modules LoRa , on ajoute un troisième module comme étant récepteur pour voir les changement dus à la présence d'un ou d'autres récepteurs.

[[Fichier:mont3.jpg|500px|down|Montage 3 module LoRa : 1 émetteur & 2 récepteurs]]

On remarque que le RSSI (Received Signal Strength Indication) ne change quasiment pas (entre |21| et |19|) . On peut conclure que la présence de plusieurs récepteurs n'affecte pas la puissance du signal transmis .

[[Fichier:rssi1.png]]

[[Fichier:rssi2.png]]

1ere séance de mesures :

On réalise la communication LoRa entre les modules et on visualise le signal transmis avec une antenne PATCH connectée à un analyseur de spectre . 

[[Fichier:fr434.jpg|500px|down]]

On mesure pour la fréquence '''434MHz''':

'''le rapport signal sur bruit SNR '''

le rapport SNR donne une valeur de : 13 dBm
[[Fichier:cn.jpg|500px|down|]]

La puissance du signal est égale à 13 dBm . Ce résulat est identique à la puissance définit par défaut .

===Semaine 6 ===

Modification des codes d'émission et de réception : Envoyer des 1 ou des 0 au lieu du message "Hello word" ; Répondre par ce qu'on reçoit (Ping-pong)

(voir codes : fichier rendus).

===Semaine 7 et 8 ===

Plan de mesures (voir fichiers rendus en bas de la page).

===Semaine 9 et 10 ===

Mesures :

Pour visualiser le signal dans l'air , j'ai utilisé une antenne patch , en mettant tantot le module d'emission tantot le module de reception sur cette dernière .

Sur un oscilloscope 1GHz , j'ai pu visualisé les signaux suivants :

'''Emission :''' [[Fichier:Emission_patch.jpg|500px|down|]]

'''Reception: ''' [[Fichier:Reception_patch.jpg|500px|down|]]

Commentaires : Le signal d'émission visualisé en haut (c1) est la trame qu'on reçoit ; celui d'en-bas (F1) n'est qu'un zoom qui nous permet de voir la forme de ce signal.
On remarque qu'on a signal modulé en QPSK d'où le saut de phase . Cette forme ne correspond pas à la modulation LoRa qui est en chirp Spread Spectrum (CSS) (Cf. datasheet AN1200.22 LoRa™ Modulation) . 

Le cas était aussi pour le signal de reception , mais qui est modulé en AM .

Cette "déformation" des signaux est due à l'utilisation de l'antenne patch (800MHz) qui n'est pas adapté à notre antenne (434MHz). 

''''''Solution'''''' 

En évitant de passer par l’antenne patch , et en connectant directement l’antenne du module d'émission ( fil + GND) à l’oscilloscope via un câble coaxial , j’ai pu visualiser le signal prévu : 

[[Fichier:Lora_frame.jpg|500px|down|]] 
On peut remarquer la présence de deux trames , une correspond à la première émission et l’autre au retour amis par le module récepteur . 

Le signal d’en bas qui est un zoom de la trame , nous montre les chirps qu’on devrait avoir . En se basant sur la méthode suivant , on pourra décoder ce signal . 

Le but est d’avoir la taille minimale possible pour rendre plus facile le parcours de la trame .
Il faut d’abord penser à changer la bande passante et passer de 125 KHz à 8 KHz. 

'''Preamble : '''
Comme la taille du préambule n’affecte pas la transmission , on peut donc la réduire au minimum configurable qui est 6 avec la fonction setPreambleLength . Ce qui nous fera 10 symboles pour le preambule . Il faudra donc trouver 10 sauts de phases. 

'''Header : '''
En choisissant le mode SF=6 on force l’utilisation du mode implicit tout en réduisant également le nombre de chips par symbole:65 chips/symbol au lieu de 128 . 

'''Payload :'''

En utilisant maintenant SF= 6 , on envoie donc 6 char ( 111111 par exemple) et on s’attend à avoir 8 sauts de phase et 8*65 chirps ce qui donne 520 chirps pour le payload qui reste quand même beaucoup à compter pour s’en assurer . On se basera donc uniquement sur le comptage de sauts pour compter 8 symboles. Il faut noter que la taille max du payload est de 251 bits , même si on envoie que 6 bits de 1 le reste est mis à 0 . Cette taille peut être réduite en utilisant une bande passante plus petite 

'''CRC : '''
Comme on utilise le mode implicite , on n’est donc pas sur d’avoir un CRC , on vérifiera la présence de ce dernier sachant qu’il a une taille de 16 bits ce qui vaut 3 symboles à peu près . 

== Fichiers Rendus ==

[[Fichier:Plandemesures.pdf]]

[[Fichier:Rapportprojet33.pdf]]

IMA4 2016/2017 P33

2017-05-18T12:32:19Z

Onaanaa : /* Présentation du projet */

=Présentation du projet=
===Contexte===
Les objets connectés se font une place dans le quotidien et se déploient de plus en plus mais en ce qui concerne leur sécurité, il apparaît que les fabricants ont souvent négligé la sécurité des technologies et de les protéger contre les cyberattaques.
Afin de tester la sécurité des réseaux utilisés dans les objets connectés, nous étudierons le fonctionnement de ces protocoles. Dans le cadre de ce projet nous nous intéresserons aux protocoles LoRa et SigFox.

===Objectif===
L'objectif est donc de réaliser l'écoute de trame d'un réseau sans-fil (LoRa et SigFox) en capturant des trames afin de comprendre le fonctionnement de ces protocoles, et déterminer le format des trames ainsi que des méthodes d'attaque du réseau. C'est ce qu'on appelle l'ingénierie inverse.

===Description du projet===

Pour comprendre le fonctionnement du protocole, nous mettrons en place une maquette contenant des émetteurs et récepteurs afin d'écouter les trames dans le réseau. Une fois la maquette prête, nous mettrons en place une méthode d'écoute des trames et des captures de trames par un analyseur de spectre pour ensuite décoder ces trames.
Pour tester les attaques de type man in the middle, ie introduire des trames dans le réseau, nous allons créer des trames et les faire accepter par le réseau.

===Choix techniques : matériel et logiciel===
'''Fonction principale:'''

Ingénierie inverse : Pouvoir injecter des trames “écrites à la main” entre l'émetteur/récepteur LoRa.

'''Sous-fonction 1:'''

'''Sous-fonction 1:'''
Effectuer la communication entre les modules LoRa:

Pour etablir la communication on utilisera deux Arduino qui serviront à controler l’emission et la reception des données ainsi que les messages à transmettre.

[[Fichier:pt1.png]]

Sous-fonction 2:
on récupère le signal avec un analyseur de spectre pour pouvoir “décoder” le paquet LoRa.

[[Fichier:pt2.png]]

'''
Sous-fonction 3:'''

A partir du paquet “décodé” , écrire un autre paquet pour l’envoyer à un récepteur LoRa .
Pour l’interception , en fonction de la trame que recoit les modules LoRa , on décidera la méthode avec laquelle on intercepte la communication afin d’envoyer des trames “ecrites à la main”.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

'''Tâche 1''': Etablir la communication entre deux modules LoRa. 
'''Tâche 2''' :Visualiser sur l'analyseur de spectre le signal émis . 
'''Tâche 3''': .Prise en main du format du protocole LoRa 
'''Tâche 4''' : Ecrire un paquet LoRa et le faire accepter par un module LoRa . 

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
|4h
|6h
|6h
|
|
|
|
|
|
|
|
|16h
|-
|Découverte Feather + documentation LoRa
|
|
|
|4h
|
|
|
|
|
|
|
|4h
|-
|Tache1 : 1ere communication 2 feather
|
|
|
|
|6h
|
|
|
|
|
|
|6h
|-
|Test RSSI + mesures sur le spectre visualisé
|
|
|
|
|
|8h
|
|
|
|
|
|8h
|-
|Modification code émission+ réception
|
|
|
|
|
|
|8h
|
|
|
|
|8h
|-
|Plan de mesures
|
|
|
|
|
|
|
|8h
|8h
|
|
|16h
|-
|Mesures
|
|
|
|
|
|
|
|
|
|8h
|8h
|16h
|-
|
|
|
|
|
|
|
|
|
|
|
|
|74h
|
}
==Avancement du Projet==

===Semaine 1===
Définition du cahier des charges et prise en main du protocole LoRa

===Semaine 2===

Suite du cahier des charges

===Semaine 3===

-Découverte du Feather 
-Etude sur le protocole LoRa et distinction entre Réseau (LoRaWAN) et le protocole LoRa. 

===Semaine 4===

Tache 1 réalisée: 
#Installation des librairies Adafruit (Sur deux machines pour emission/Reception) 
#Test des codes Emission/Réception proposés par la datasheet. 
#Communication réalisée entre deux modules LoRa . 

====Emission====
[[Fichier:femission.png]]

====Réception====

[[Fichier:freception.png]]

===Semaine 5===

Après avoir effectué la communication entre deux modules LoRa , on ajoute un troisième module comme étant récepteur pour voir les changement dus à la présence d'un ou d'autres récepteurs.

[[Fichier:mont3.jpg|500px|down|Montage 3 module LoRa : 1 émetteur & 2 récepteurs]]

On remarque que le RSSI (Received Signal Strength Indication) ne change quasiment pas (entre |21| et |19|) . On peut conclure que la présence de plusieurs récepteurs n'affecte pas la puissance du signal transmis .

[[Fichier:rssi1.png]]

[[Fichier:rssi2.png]]

1ere séance de mesures :

On réalise la communication LoRa entre les modules et on visualise le signal transmis avec une antenne PATCH connectée à un analyseur de spectre . 

[[Fichier:fr434.jpg|500px|down]]

On mesure pour la fréquence '''434MHz''':

'''le rapport signal sur bruit SNR '''

le rapport SNR donne une valeur de : 13 dBm
[[Fichier:cn.jpg|500px|down|]]

La puissance du signal est égale à 13 dBm . Ce résulat est identique à la puissance définit par défaut .

===Semaine 6 ===

Modification des codes d'émission et de réception : Envoyer des 1 ou des 0 au lieu du message "Hello word" ; Répondre par ce qu'on reçoit (Ping-pong)

(voir codes : fichier rendus).

===Semaine 7 et 8 ===

Plan de mesures (voir fichiers rendus en bas de la page).

===Semaine 9 et 10 ===

Mesures :

Pour visualiser le signal dans l'air , j'ai utilisé une antenne patch , en mettant tantot le module d'emission tantot le module de reception sur cette dernière .

Sur un oscilloscope 1GHz , j'ai pu visualisé les signaux suivants :

'''Emission :''' [[Fichier:Emission_patch.jpg|500px|down|]]

'''Reception: ''' [[Fichier:Reception_patch.jpg|500px|down|]]

Commentaires : Le signal d'émission visualisé en haut (c1) est la trame qu'on reçoit ; celui d'en-bas (F1) n'est qu'un zoom qui nous permet de voir la forme de ce signal.
On remarque qu'on a signal modulé en QPSK d'où le saut de phase . Cette forme ne correspond pas à la modulation LoRa qui est en chirp Spread Spectrum (CSS) (Cf. datasheet AN1200.22 LoRa™ Modulation) . 

Le cas était aussi pour le signal de reception , mais qui est modulé en AM .

Cette "déformation" des signaux est due à l'utilisation de l'antenne patch (800MHz) qui n'est pas adapté à notre antenne (434MHz). 

''''''Solution'''''' 

En évitant de passer par l’antenne patch , et en connectant directement l’antenne du module d'émission ( fil + GND) à l’oscilloscope via un câble coaxial , j’ai pu visualiser le signal prévu : 

[[Fichier:Lora_frame.jpg|500px|down|]] 
On peut remarquer la présence de deux trames , une correspond à la première émission et l’autre au retour amis par le module récepteur . 

Le signal d’en bas qui est un zoom de la trame , nous montre les chirps qu’on devrait avoir . En se basant sur la méthode suivant , on pourra décoder ce signal . 

Le but est d’avoir la taille minimale possible pour rendre plus facile le parcours de la trame .
Il faut d’abord penser à changer la bande passante et passer de 125 KHz à 8 KHz. 

'''Preamble : '''
Comme la taille du préambule n’affecte pas la transmission , on peut donc la réduire au minimum configurable qui est 6 avec la fonction setPreambleLength . Ce qui nous fera 10 symboles pour le preambule . Il faudra donc trouver 10 sauts de phases. 

'''Header : '''
En choisissant le mode SF=6 on force l’utilisation du mode implicit tout en réduisant également le nombre de chips par symbole:65 chips/symbol au lieu de 128 . 

'''Payload :'''

En utilisant maintenant SF= 6 , on envoie donc 6 char ( 111111 par exemple) et on s’attend à avoir 8 sauts de phase et 8*65 chirps ce qui donne 520 chirps pour le payload qui reste quand même beaucoup à compter pour s’en assurer . On se basera donc uniquement sur le comptage de sauts pour compter 8 symboles. Il faut noter que la taille max du payload est de 251 bits , même si on envoie que 6 bits de 1 le reste est mis à 0 . Cette taille peut être réduite en utilisant une bande passante plus petite 

'''CRC : '''
Comme on utilise le mode implicite , on n’est donc pas sur d’avoir un CRC , on vérifiera la présence de ce dernier sachant qu’il a une taille de 16 bits ce qui vaut 3 symboles à peu près . 

== Fichiers Rendus ==

[[Fichier:Plandemesures.pdf]]

[[Fichier:Rapportprojet33.pdf]]

IMA4 2016/2017 P33

2017-05-18T12:31:39Z

Onaanaa : /* Feuille d'heures */

=Présentation du projet=
===Contexte===
Les objets connectés se font une place dans le quotidien et se déploient de plus en plus mais en ce qui concerne leur sécurité, il apparaît que les fabricants ont souvent négligé la sécurité des technologies et de les protéger contre les cyberattaques.
Afin de tester la sécurité des réseaux utilisés dans les objets connectés, nous étudierons le fonctionnement de ces protocoles. Dans le cadre de ce projet nous nous intéresserons aux protocoles LoRa et SigFox.

===Objectif===
L'objectif est donc de réaliser l'écoute de trame d'un réseau sans-fil (LoRa et SigFox) en capturant des trames afin de comprendre le fonctionnement de ces protocoles, et déterminer le format des trames ainsi que des méthodes d'attaque du réseau. C'est ce qu'on appelle l'ingénierie inverse.

===Description du projet===

Pour comprendre le fonctionnement du protocole, nous mettrons en place une maquette contenant des émetteurs et récepteurs afin d'écouter les trames dans le réseau. Une fois la maquette prête, nous mettrons en place une méthode d'écoute des trames et des captures de trames par un analyseur de spectre pour ensuite décoder ces trames.
Pour tester les attaques de type man in the middle, ie introduire des trames dans le réseau, nous allons créer des trames et les faire accepter par le réseau.

===Choix techniques : matériel et logiciel===
'''Fonction principale:'''

Ingénierie inverse : Pouvoir injecter des trames “écrites à la main” entre l'émetteur/récepteur LoRa.

'''Sous-fonction 1:'''

'''Sous-fonction 1:'''
Effectuer la communication entre les modules LoRa:

Pour etablir la communication on utilisera deux Arduino qui serviront à controler l’emission et la reception des données ainsi que les messages à transmettre.

[[Fichier:pt1.png]]

Sous-fonction 2:
on récupère le signal avec un analyseur de spectre pour pouvoir “décoder” le paquet LoRa.

[[Fichier:pt2.png]]

'''
Sous-fonction 3:'''

A partir du paquet “décodé” , écrire un autre paquet pour l’envoyer à un récepteur LoRa .
Pour l’interception , en fonction de la trame que recoit les modules LoRa , on décidera la méthode avec laquelle on intercepte la communication afin d’envoyer des trames “ecrites à la main”.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

'''Tâche 1''': Etablir la communication entre deux modules LoRa. 
'''Tâche 2''' :Visualiser sur l'analyseur de spectre le signal émis . 
'''Tâche 3''': .Prise en main du format du protocole LoRa 
'''Tâche 4''' : Ecrire un paquet LoRa et le faire accepter par un module LoRa . 

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
|4h
|6h
|6h
|
|
|
|
|
|
|
|
|16h
|-
|Découverte Feather + documentation LoRa
|
|
|
|4h
|
|
|
|
|
|
|
|4h
|-
|Tache1 : 1ere communication 2 feather
|
|
|
|
|6h
|
|
|
|
|
|
|6h
|-
|Test RSSI + mesures sur le spectre visualisé
|
|
|
|
|
|8h
|
|
|
|
|
|8h
|-
|Modification code émission+ réception
|
|
|
|
|
|
|8h
|
|
|
|
|8h
|-
|Plan de mesures
|
|
|
|
|
|
|
|8h
|8h
|
|
|16h
|-
|Mesures
|
|
|
|
|
|
|
|
|
|8h
|8h
|16h
|-
|
|
|
|
|
|
|
|
|
|
|
|
|74h

==Avancement du Projet==

===Semaine 1===
Définition du cahier des charges et prise en main du protocole LoRa

===Semaine 2===

Suite du cahier des charges

===Semaine 3===

-Découverte du Feather 
-Etude sur le protocole LoRa et distinction entre Réseau (LoRaWAN) et le protocole LoRa. 

===Semaine 4===

Tache 1 réalisée: 
#Installation des librairies Adafruit (Sur deux machines pour emission/Reception) 
#Test des codes Emission/Réception proposés par la datasheet. 
#Communication réalisée entre deux modules LoRa . 

====Emission====
[[Fichier:femission.png]]

====Réception====

[[Fichier:freception.png]]

===Semaine 5===

Après avoir effectué la communication entre deux modules LoRa , on ajoute un troisième module comme étant récepteur pour voir les changement dus à la présence d'un ou d'autres récepteurs.

[[Fichier:mont3.jpg|500px|down|Montage 3 module LoRa : 1 émetteur & 2 récepteurs]]

On remarque que le RSSI (Received Signal Strength Indication) ne change quasiment pas (entre |21| et |19|) . On peut conclure que la présence de plusieurs récepteurs n'affecte pas la puissance du signal transmis .

[[Fichier:rssi1.png]]

[[Fichier:rssi2.png]]

1ere séance de mesures :

On réalise la communication LoRa entre les modules et on visualise le signal transmis avec une antenne PATCH connectée à un analyseur de spectre . 

[[Fichier:fr434.jpg|500px|down]]

On mesure pour la fréquence '''434MHz''':

'''le rapport signal sur bruit SNR '''

le rapport SNR donne une valeur de : 13 dBm
[[Fichier:cn.jpg|500px|down|]]

La puissance du signal est égale à 13 dBm . Ce résulat est identique à la puissance définit par défaut .

===Semaine 6 ===

Modification des codes d'émission et de réception : Envoyer des 1 ou des 0 au lieu du message "Hello word" ; Répondre par ce qu'on reçoit (Ping-pong)

(voir codes : fichier rendus).

===Semaine 7 et 8 ===

Plan de mesures (voir fichiers rendus en bas de la page).

===Semaine 9 et 10 ===

Mesures :

Pour visualiser le signal dans l'air , j'ai utilisé une antenne patch , en mettant tantot le module d'emission tantot le module de reception sur cette dernière .

Sur un oscilloscope 1GHz , j'ai pu visualisé les signaux suivants :

'''Emission :''' [[Fichier:Emission_patch.jpg|500px|down|]]

'''Reception: ''' [[Fichier:Reception_patch.jpg|500px|down|]]

Commentaires : Le signal d'émission visualisé en haut (c1) est la trame qu'on reçoit ; celui d'en-bas (F1) n'est qu'un zoom qui nous permet de voir la forme de ce signal.
On remarque qu'on a signal modulé en QPSK d'où le saut de phase . Cette forme ne correspond pas à la modulation LoRa qui est en chirp Spread Spectrum (CSS) (Cf. datasheet AN1200.22 LoRa™ Modulation) . 

Le cas était aussi pour le signal de reception , mais qui est modulé en AM .

Cette "déformation" des signaux est due à l'utilisation de l'antenne patch (800MHz) qui n'est pas adapté à notre antenne (434MHz). 

''''''Solution'''''' 

En évitant de passer par l’antenne patch , et en connectant directement l’antenne du module d'émission ( fil + GND) à l’oscilloscope via un câble coaxial , j’ai pu visualiser le signal prévu : 

[[Fichier:Lora_frame.jpg|500px|down|]] 
On peut remarquer la présence de deux trames , une correspond à la première émission et l’autre au retour amis par le module récepteur . 

Le signal d’en bas qui est un zoom de la trame , nous montre les chirps qu’on devrait avoir . En se basant sur la méthode suivant , on pourra décoder ce signal . 

Le but est d’avoir la taille minimale possible pour rendre plus facile le parcours de la trame .
Il faut d’abord penser à changer la bande passante et passer de 125 KHz à 8 KHz. 

'''Preamble : '''
Comme la taille du préambule n’affecte pas la transmission , on peut donc la réduire au minimum configurable qui est 6 avec la fonction setPreambleLength . Ce qui nous fera 10 symboles pour le preambule . Il faudra donc trouver 10 sauts de phases. 

'''Header : '''
En choisissant le mode SF=6 on force l’utilisation du mode implicit tout en réduisant également le nombre de chips par symbole:65 chips/symbol au lieu de 128 . 

'''Payload :'''

En utilisant maintenant SF= 6 , on envoie donc 6 char ( 111111 par exemple) et on s’attend à avoir 8 sauts de phase et 8*65 chirps ce qui donne 520 chirps pour le payload qui reste quand même beaucoup à compter pour s’en assurer . On se basera donc uniquement sur le comptage de sauts pour compter 8 symboles. Il faut noter que la taille max du payload est de 251 bits , même si on envoie que 6 bits de 1 le reste est mis à 0 . Cette taille peut être réduite en utilisant une bande passante plus petite 

'''CRC : '''
Comme on utilise le mode implicite , on n’est donc pas sur d’avoir un CRC , on vérifiera la présence de ce dernier sachant qu’il a une taille de 16 bits ce qui vaut 3 symboles à peu près . 

== Fichiers Rendus ==

[[Fichier:Plandemesures.pdf]]

[[Fichier:Rapportprojet33.pdf]]

IMA4 2016/2017 P33

2017-05-18T11:56:11Z

Onaanaa : /* Semaine 9 et 10 */

=Présentation du projet=
===Contexte===
Les objets connectés se font une place dans le quotidien et se déploient de plus en plus mais en ce qui concerne leur sécurité, il apparaît que les fabricants ont souvent négligé la sécurité des technologies et de les protéger contre les cyberattaques.
Afin de tester la sécurité des réseaux utilisés dans les objets connectés, nous étudierons le fonctionnement de ces protocoles. Dans le cadre de ce projet nous nous intéresserons aux protocoles LoRa et SigFox.

===Objectif===
L'objectif est donc de réaliser l'écoute de trame d'un réseau sans-fil (LoRa et SigFox) en capturant des trames afin de comprendre le fonctionnement de ces protocoles, et déterminer le format des trames ainsi que des méthodes d'attaque du réseau. C'est ce qu'on appelle l'ingénierie inverse.

===Description du projet===

Pour comprendre le fonctionnement du protocole, nous mettrons en place une maquette contenant des émetteurs et récepteurs afin d'écouter les trames dans le réseau. Une fois la maquette prête, nous mettrons en place une méthode d'écoute des trames et des captures de trames par un analyseur de spectre pour ensuite décoder ces trames.
Pour tester les attaques de type man in the middle, ie introduire des trames dans le réseau, nous allons créer des trames et les faire accepter par le réseau.

===Choix techniques : matériel et logiciel===
'''Fonction principale:'''

Ingénierie inverse : Pouvoir injecter des trames “écrites à la main” entre l'émetteur/récepteur LoRa.

'''Sous-fonction 1:'''

'''Sous-fonction 1:'''
Effectuer la communication entre les modules LoRa:

Pour etablir la communication on utilisera deux Arduino qui serviront à controler l’emission et la reception des données ainsi que les messages à transmettre.

[[Fichier:pt1.png]]

Sous-fonction 2:
on récupère le signal avec un analyseur de spectre pour pouvoir “décoder” le paquet LoRa.

[[Fichier:pt2.png]]

'''
Sous-fonction 3:'''

A partir du paquet “décodé” , écrire un autre paquet pour l’envoyer à un récepteur LoRa .
Pour l’interception , en fonction de la trame que recoit les modules LoRa , on décidera la méthode avec laquelle on intercepte la communication afin d’envoyer des trames “ecrites à la main”.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

'''Tâche 1''': Etablir la communication entre deux modules LoRa. 
'''Tâche 2''' :Visualiser sur l'analyseur de spectre le signal émis . 
'''Tâche 3''': .Prise en main du format du protocole LoRa 
'''Tâche 4''' : Ecrire un paquet LoRa et le faire accepter par un module LoRa . 

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 4h
| 6h
| 6h
|4h
|6h
|8h
|8h
|8h
|8h
|8h
|8h
|
|}

==Avancement du Projet==

===Semaine 1===
Définition du cahier des charges et prise en main du protocole LoRa

===Semaine 2===

Suite du cahier des charges

===Semaine 3===

-Découverte du Feather 
-Etude sur le protocole LoRa et distinction entre Réseau (LoRaWAN) et le protocole LoRa. 

===Semaine 4===

Tache 1 réalisée: 
#Installation des librairies Adafruit (Sur deux machines pour emission/Reception) 
#Test des codes Emission/Réception proposés par la datasheet. 
#Communication réalisée entre deux modules LoRa . 

====Emission====
[[Fichier:femission.png]]

====Réception====

[[Fichier:freception.png]]

===Semaine 5===

Après avoir effectué la communication entre deux modules LoRa , on ajoute un troisième module comme étant récepteur pour voir les changement dus à la présence d'un ou d'autres récepteurs.

[[Fichier:mont3.jpg|500px|down|Montage 3 module LoRa : 1 émetteur & 2 récepteurs]]

On remarque que le RSSI (Received Signal Strength Indication) ne change quasiment pas (entre |21| et |19|) . On peut conclure que la présence de plusieurs récepteurs n'affecte pas la puissance du signal transmis .

[[Fichier:rssi1.png]]

[[Fichier:rssi2.png]]

1ere séance de mesures :

On réalise la communication LoRa entre les modules et on visualise le signal transmis avec une antenne PATCH connectée à un analyseur de spectre . 

[[Fichier:fr434.jpg|500px|down]]

On mesure pour la fréquence '''434MHz''':

'''le rapport signal sur bruit SNR '''

le rapport SNR donne une valeur de : 13 dBm
[[Fichier:cn.jpg|500px|down|]]

La puissance du signal est égale à 13 dBm . Ce résulat est identique à la puissance définit par défaut .

===Semaine 6 ===

Modification des codes d'émission et de réception : Envoyer des 1 ou des 0 au lieu du message "Hello word" ; Répondre par ce qu'on reçoit (Ping-pong)

(voir codes : fichier rendus).

===Semaine 7 et 8 ===

Plan de mesures (voir fichiers rendus en bas de la page).

===Semaine 9 et 10 ===

Mesures :

Pour visualiser le signal dans l'air , j'ai utilisé une antenne patch , en mettant tantot le module d'emission tantot le module de reception sur cette dernière .

Sur un oscilloscope 1GHz , j'ai pu visualisé les signaux suivants :

'''Emission :''' [[Fichier:Emission_patch.jpg|500px|down|]]

'''Reception: ''' [[Fichier:Reception_patch.jpg|500px|down|]]

Commentaires : Le signal d'émission visualisé en haut (c1) est la trame qu'on reçoit ; celui d'en-bas (F1) n'est qu'un zoom qui nous permet de voir la forme de ce signal.
On remarque qu'on a signal modulé en QPSK d'où le saut de phase . Cette forme ne correspond pas à la modulation LoRa qui est en chirp Spread Spectrum (CSS) (Cf. datasheet AN1200.22 LoRa™ Modulation) . 

Le cas était aussi pour le signal de reception , mais qui est modulé en AM .

Cette "déformation" des signaux est due à l'utilisation de l'antenne patch (800MHz) qui n'est pas adapté à notre antenne (434MHz). 

''''''Solution'''''' 

En évitant de passer par l’antenne patch , et en connectant directement l’antenne du module d'émission ( fil + GND) à l’oscilloscope via un câble coaxial , j’ai pu visualiser le signal prévu : 

[[Fichier:Lora_frame.jpg|500px|down|]] 
On peut remarquer la présence de deux trames , une correspond à la première émission et l’autre au retour amis par le module récepteur . 

Le signal d’en bas qui est un zoom de la trame , nous montre les chirps qu’on devrait avoir . En se basant sur la méthode suivant , on pourra décoder ce signal . 

Le but est d’avoir la taille minimale possible pour rendre plus facile le parcours de la trame .
Il faut d’abord penser à changer la bande passante et passer de 125 KHz à 8 KHz. 

'''Preamble : '''
Comme la taille du préambule n’affecte pas la transmission , on peut donc la réduire au minimum configurable qui est 6 avec la fonction setPreambleLength . Ce qui nous fera 10 symboles pour le preambule . Il faudra donc trouver 10 sauts de phases. 

'''Header : '''
En choisissant le mode SF=6 on force l’utilisation du mode implicit tout en réduisant également le nombre de chips par symbole:65 chips/symbol au lieu de 128 . 

'''Payload :'''

En utilisant maintenant SF= 6 , on envoie donc 6 char ( 111111 par exemple) et on s’attend à avoir 8 sauts de phase et 8*65 chirps ce qui donne 520 chirps pour le payload qui reste quand même beaucoup à compter pour s’en assurer . On se basera donc uniquement sur le comptage de sauts pour compter 8 symboles. Il faut noter que la taille max du payload est de 251 bits , même si on envoie que 6 bits de 1 le reste est mis à 0 . Cette taille peut être réduite en utilisant une bande passante plus petite 

'''CRC : '''
Comme on utilise le mode implicite , on n’est donc pas sur d’avoir un CRC , on vérifiera la présence de ce dernier sachant qu’il a une taille de 16 bits ce qui vaut 3 symboles à peu près . 

== Fichiers Rendus ==

[[Fichier:Plandemesures.pdf]]

[[Fichier:Rapportprojet33.pdf]]

IMA4 2016/2017 P33

2017-05-18T11:52:20Z

Onaanaa : /* Semaine 9 et 10 */

=Présentation du projet=
===Contexte===
Les objets connectés se font une place dans le quotidien et se déploient de plus en plus mais en ce qui concerne leur sécurité, il apparaît que les fabricants ont souvent négligé la sécurité des technologies et de les protéger contre les cyberattaques.
Afin de tester la sécurité des réseaux utilisés dans les objets connectés, nous étudierons le fonctionnement de ces protocoles. Dans le cadre de ce projet nous nous intéresserons aux protocoles LoRa et SigFox.

===Objectif===
L'objectif est donc de réaliser l'écoute de trame d'un réseau sans-fil (LoRa et SigFox) en capturant des trames afin de comprendre le fonctionnement de ces protocoles, et déterminer le format des trames ainsi que des méthodes d'attaque du réseau. C'est ce qu'on appelle l'ingénierie inverse.

===Description du projet===

Pour comprendre le fonctionnement du protocole, nous mettrons en place une maquette contenant des émetteurs et récepteurs afin d'écouter les trames dans le réseau. Une fois la maquette prête, nous mettrons en place une méthode d'écoute des trames et des captures de trames par un analyseur de spectre pour ensuite décoder ces trames.
Pour tester les attaques de type man in the middle, ie introduire des trames dans le réseau, nous allons créer des trames et les faire accepter par le réseau.

===Choix techniques : matériel et logiciel===
'''Fonction principale:'''

Ingénierie inverse : Pouvoir injecter des trames “écrites à la main” entre l'émetteur/récepteur LoRa.

'''Sous-fonction 1:'''

'''Sous-fonction 1:'''
Effectuer la communication entre les modules LoRa:

Pour etablir la communication on utilisera deux Arduino qui serviront à controler l’emission et la reception des données ainsi que les messages à transmettre.

[[Fichier:pt1.png]]

Sous-fonction 2:
on récupère le signal avec un analyseur de spectre pour pouvoir “décoder” le paquet LoRa.

[[Fichier:pt2.png]]

'''
Sous-fonction 3:'''

A partir du paquet “décodé” , écrire un autre paquet pour l’envoyer à un récepteur LoRa .
Pour l’interception , en fonction de la trame que recoit les modules LoRa , on décidera la méthode avec laquelle on intercepte la communication afin d’envoyer des trames “ecrites à la main”.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

'''Tâche 1''': Etablir la communication entre deux modules LoRa. 
'''Tâche 2''' :Visualiser sur l'analyseur de spectre le signal émis . 
'''Tâche 3''': .Prise en main du format du protocole LoRa 
'''Tâche 4''' : Ecrire un paquet LoRa et le faire accepter par un module LoRa . 

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 4h
| 6h
| 6h
|4h
|6h
|8h
|8h
|8h
|8h
|8h
|8h
|
|}

==Avancement du Projet==

===Semaine 1===
Définition du cahier des charges et prise en main du protocole LoRa

===Semaine 2===

Suite du cahier des charges

===Semaine 3===

-Découverte du Feather 
-Etude sur le protocole LoRa et distinction entre Réseau (LoRaWAN) et le protocole LoRa. 

===Semaine 4===

Tache 1 réalisée: 
#Installation des librairies Adafruit (Sur deux machines pour emission/Reception) 
#Test des codes Emission/Réception proposés par la datasheet. 
#Communication réalisée entre deux modules LoRa . 

====Emission====
[[Fichier:femission.png]]

====Réception====

[[Fichier:freception.png]]

===Semaine 5===

Après avoir effectué la communication entre deux modules LoRa , on ajoute un troisième module comme étant récepteur pour voir les changement dus à la présence d'un ou d'autres récepteurs.

[[Fichier:mont3.jpg|500px|down|Montage 3 module LoRa : 1 émetteur & 2 récepteurs]]

On remarque que le RSSI (Received Signal Strength Indication) ne change quasiment pas (entre |21| et |19|) . On peut conclure que la présence de plusieurs récepteurs n'affecte pas la puissance du signal transmis .

[[Fichier:rssi1.png]]

[[Fichier:rssi2.png]]

1ere séance de mesures :

On réalise la communication LoRa entre les modules et on visualise le signal transmis avec une antenne PATCH connectée à un analyseur de spectre . 

[[Fichier:fr434.jpg|500px|down]]

On mesure pour la fréquence '''434MHz''':

'''le rapport signal sur bruit SNR '''

le rapport SNR donne une valeur de : 13 dBm
[[Fichier:cn.jpg|500px|down|]]

La puissance du signal est égale à 13 dBm . Ce résulat est identique à la puissance définit par défaut .

===Semaine 6 ===

Modification des codes d'émission et de réception : Envoyer des 1 ou des 0 au lieu du message "Hello word" ; Répondre par ce qu'on reçoit (Ping-pong)

(voir codes : fichier rendus).

===Semaine 7 et 8 ===

Plan de mesures (voir fichiers rendus en bas de la page).

===Semaine 9 et 10 ===

Mesures :

Pour visualiser le signal dans l'air , j'ai utilisé une antenne patch , en mettant tantot le module d'emission tantot le module de reception sur cette dernière .

Sur un oscilloscope 1GHz , j'ai pu visualisé les signaux suivants :

'''Emission :''' [[Fichier:Emission_patch.jpg|500px|down|]]

'''Reception: ''' [[Fichier:Reception_patch.jpg|500px|down|]]

Commentaires : Le signal d'émission visualisé en haut (c1) est la trame qu'on reçoit ; celui d'en-bas (F1) n'est qu'un zoom qui nous permet de voir la forme de ce signal.
On remarque qu'on a signal modulé en QPSK d'où le saut de phase . Cette forme ne correspond pas à la modulation LoRa qui est en chirp Spread Spectrum (CSS) (Cf. datasheet AN1200.22 LoRa™ Modulation) . 

Le cas était aussi pour le signal de reception , mais qui est modulé en AM .

Cette "déformation" des signaux est due à l'utilisation de l'antenne patch (800MHz) qui n'est pas adapté à notre antenne (434MHz). 

''''''Solution'''''' 

En évitant de passer par l’antenne patch , et en connectant directement l’antenne du module d'émission ( fil + GND) à l’oscilloscope via un câble coaxial , j’ai pu visualiser le signal prévu : 

[[Fichier:Lora_frame.jpg|500px|down|]]

== Fichiers Rendus ==

[[Fichier:Plandemesures.pdf]]

[[Fichier:Rapportprojet33.pdf]]

Fichier:Lora frame.jpg

2017-05-18T11:40:50Z

Onaanaa :

IMA4 2016/2017 P33

2017-05-18T11:23:01Z

Onaanaa : /* Semaine 9 et 10 */

=Présentation du projet=
===Contexte===
Les objets connectés se font une place dans le quotidien et se déploient de plus en plus mais en ce qui concerne leur sécurité, il apparaît que les fabricants ont souvent négligé la sécurité des technologies et de les protéger contre les cyberattaques.
Afin de tester la sécurité des réseaux utilisés dans les objets connectés, nous étudierons le fonctionnement de ces protocoles. Dans le cadre de ce projet nous nous intéresserons aux protocoles LoRa et SigFox.

===Objectif===
L'objectif est donc de réaliser l'écoute de trame d'un réseau sans-fil (LoRa et SigFox) en capturant des trames afin de comprendre le fonctionnement de ces protocoles, et déterminer le format des trames ainsi que des méthodes d'attaque du réseau. C'est ce qu'on appelle l'ingénierie inverse.

===Description du projet===

Pour comprendre le fonctionnement du protocole, nous mettrons en place une maquette contenant des émetteurs et récepteurs afin d'écouter les trames dans le réseau. Une fois la maquette prête, nous mettrons en place une méthode d'écoute des trames et des captures de trames par un analyseur de spectre pour ensuite décoder ces trames.
Pour tester les attaques de type man in the middle, ie introduire des trames dans le réseau, nous allons créer des trames et les faire accepter par le réseau.

===Choix techniques : matériel et logiciel===
'''Fonction principale:'''

Ingénierie inverse : Pouvoir injecter des trames “écrites à la main” entre l'émetteur/récepteur LoRa.

'''Sous-fonction 1:'''

'''Sous-fonction 1:'''
Effectuer la communication entre les modules LoRa:

Pour etablir la communication on utilisera deux Arduino qui serviront à controler l’emission et la reception des données ainsi que les messages à transmettre.

[[Fichier:pt1.png]]

Sous-fonction 2:
on récupère le signal avec un analyseur de spectre pour pouvoir “décoder” le paquet LoRa.

[[Fichier:pt2.png]]

'''
Sous-fonction 3:'''

A partir du paquet “décodé” , écrire un autre paquet pour l’envoyer à un récepteur LoRa .
Pour l’interception , en fonction de la trame que recoit les modules LoRa , on décidera la méthode avec laquelle on intercepte la communication afin d’envoyer des trames “ecrites à la main”.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

'''Tâche 1''': Etablir la communication entre deux modules LoRa. 
'''Tâche 2''' :Visualiser sur l'analyseur de spectre le signal émis . 
'''Tâche 3''': .Prise en main du format du protocole LoRa 
'''Tâche 4''' : Ecrire un paquet LoRa et le faire accepter par un module LoRa . 

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 4h
| 6h
| 6h
|4h
|6h
|8h
|8h
|8h
|8h
|8h
|8h
|
|}

==Avancement du Projet==

===Semaine 1===
Définition du cahier des charges et prise en main du protocole LoRa

===Semaine 2===

Suite du cahier des charges

===Semaine 3===

-Découverte du Feather 
-Etude sur le protocole LoRa et distinction entre Réseau (LoRaWAN) et le protocole LoRa. 

===Semaine 4===

Tache 1 réalisée: 
#Installation des librairies Adafruit (Sur deux machines pour emission/Reception) 
#Test des codes Emission/Réception proposés par la datasheet. 
#Communication réalisée entre deux modules LoRa . 

====Emission====
[[Fichier:femission.png]]

====Réception====

[[Fichier:freception.png]]

===Semaine 5===

Après avoir effectué la communication entre deux modules LoRa , on ajoute un troisième module comme étant récepteur pour voir les changement dus à la présence d'un ou d'autres récepteurs.

[[Fichier:mont3.jpg|500px|down|Montage 3 module LoRa : 1 émetteur & 2 récepteurs]]

On remarque que le RSSI (Received Signal Strength Indication) ne change quasiment pas (entre |21| et |19|) . On peut conclure que la présence de plusieurs récepteurs n'affecte pas la puissance du signal transmis .

[[Fichier:rssi1.png]]

[[Fichier:rssi2.png]]

1ere séance de mesures :

On réalise la communication LoRa entre les modules et on visualise le signal transmis avec une antenne PATCH connectée à un analyseur de spectre . 

[[Fichier:fr434.jpg|500px|down]]

On mesure pour la fréquence '''434MHz''':

'''le rapport signal sur bruit SNR '''

le rapport SNR donne une valeur de : 13 dBm
[[Fichier:cn.jpg|500px|down|]]

La puissance du signal est égale à 13 dBm . Ce résulat est identique à la puissance définit par défaut .

===Semaine 6 ===

Modification des codes d'émission et de réception : Envoyer des 1 ou des 0 au lieu du message "Hello word" ; Répondre par ce qu'on reçoit (Ping-pong)

(voir codes : fichier rendus).

===Semaine 7 et 8 ===

Plan de mesures (voir fichiers rendus en bas de la page).

===Semaine 9 et 10 ===

Mesures :

Pour visualiser le signal dans l'air , j'ai utilisé une antenne patch , en mettant tantot le module d'emission tantot le module de reception sur cette dernière .

Sur un oscilloscope 1GHz , j'ai pu visualisé les signaux suivants :

'''Emission :''' [[Fichier:Emission_patch.jpg|500px|down|]]

'''Reception: ''' [[Fichier:Reception_patch.jpg|500px|down|]]

Commentaires : Le signal d'émission visualisé en haut (c1) est la trame qu'on reçoit ; celui d'en-bas (F1) n'est qu'un zoom qui nous permet de voir la forme de ce signal.
On remarque qu'on a signal modulé en QPSK d'où le saut de phase . Cette forme ne correspond pas à la modulation LoRa qui est en chirp Spread Spectrum (CSS) (Cf. datasheet AN1200.22 LoRa™ Modulation) . 

Le cas était aussi pour le signal de reception , mais qui est modulé en AM .

Cette "déformation" des signaux est due à l'utilisation de l'antenne patch (800MHz) qui n'est pas adapté à notre antenne (434MHz). 

''''''Solution'''''' 
En évitant de passer par l’antenne patch , et en connectant directement l’antenne du module d'émission ( fil + GND) à l’oscilloscope via un câble coaxial , j’ai pu visualiser le signal prévu : 

== Fichiers Rendus ==

[[Fichier:Plandemesures.pdf]]

[[Fichier:Rapportprojet33.pdf]]

Fichier:Rapportprojet33.pdf

2017-05-12T06:25:03Z

Onaanaa :

IMA4 2016/2017 P33

2017-05-12T06:24:52Z

Onaanaa : /* Fichiers Rendus */

=Présentation du projet=
===Contexte===
Les objets connectés se font une place dans le quotidien et se déploient de plus en plus mais en ce qui concerne leur sécurité, il apparaît que les fabricants ont souvent négligé la sécurité des technologies et de les protéger contre les cyberattaques.
Afin de tester la sécurité des réseaux utilisés dans les objets connectés, nous étudierons le fonctionnement de ces protocoles. Dans le cadre de ce projet nous nous intéresserons aux protocoles LoRa et SigFox.

===Objectif===
L'objectif est donc de réaliser l'écoute de trame d'un réseau sans-fil (LoRa et SigFox) en capturant des trames afin de comprendre le fonctionnement de ces protocoles, et déterminer le format des trames ainsi que des méthodes d'attaque du réseau. C'est ce qu'on appelle l'ingénierie inverse.

===Description du projet===

Pour comprendre le fonctionnement du protocole, nous mettrons en place une maquette contenant des émetteurs et récepteurs afin d'écouter les trames dans le réseau. Une fois la maquette prête, nous mettrons en place une méthode d'écoute des trames et des captures de trames par un analyseur de spectre pour ensuite décoder ces trames.
Pour tester les attaques de type man in the middle, ie introduire des trames dans le réseau, nous allons créer des trames et les faire accepter par le réseau.

===Choix techniques : matériel et logiciel===
'''Fonction principale:'''

Ingénierie inverse : Pouvoir injecter des trames “écrites à la main” entre l'émetteur/récepteur LoRa.

'''Sous-fonction 1:'''

'''Sous-fonction 1:'''
Effectuer la communication entre les modules LoRa:

Pour etablir la communication on utilisera deux Arduino qui serviront à controler l’emission et la reception des données ainsi que les messages à transmettre.

[[Fichier:pt1.png]]

Sous-fonction 2:
on récupère le signal avec un analyseur de spectre pour pouvoir “décoder” le paquet LoRa.

[[Fichier:pt2.png]]

'''
Sous-fonction 3:'''

A partir du paquet “décodé” , écrire un autre paquet pour l’envoyer à un récepteur LoRa .
Pour l’interception , en fonction de la trame que recoit les modules LoRa , on décidera la méthode avec laquelle on intercepte la communication afin d’envoyer des trames “ecrites à la main”.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

'''Tâche 1''': Etablir la communication entre deux modules LoRa. 
'''Tâche 2''' :Visualiser sur l'analyseur de spectre le signal émis . 
'''Tâche 3''': .Prise en main du format du protocole LoRa 
'''Tâche 4''' : Ecrire un paquet LoRa et le faire accepter par un module LoRa . 

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 4h
| 6h
| 6h
|4h
|6h
|8h
|8h
|8h
|8h
|8h
|8h
|
|}

==Avancement du Projet==

===Semaine 1===
Définition du cahier des charges et prise en main du protocole LoRa

===Semaine 2===

Suite du cahier des charges

===Semaine 3===

-Découverte du Feather 
-Etude sur le protocole LoRa et distinction entre Réseau (LoRaWAN) et le protocole LoRa. 

===Semaine 4===

Tache 1 réalisée: 
#Installation des librairies Adafruit (Sur deux machines pour emission/Reception) 
#Test des codes Emission/Réception proposés par la datasheet. 
#Communication réalisée entre deux modules LoRa . 

====Emission====
[[Fichier:femission.png]]

====Réception====

[[Fichier:freception.png]]

===Semaine 5===

Après avoir effectué la communication entre deux modules LoRa , on ajoute un troisième module comme étant récepteur pour voir les changement dus à la présence d'un ou d'autres récepteurs.

[[Fichier:mont3.jpg|500px|down|Montage 3 module LoRa : 1 émetteur & 2 récepteurs]]

On remarque que le RSSI (Received Signal Strength Indication) ne change quasiment pas (entre |21| et |19|) . On peut conclure que la présence de plusieurs récepteurs n'affecte pas la puissance du signal transmis .

[[Fichier:rssi1.png]]

[[Fichier:rssi2.png]]

1ere séance de mesures :

On réalise la communication LoRa entre les modules et on visualise le signal transmis avec une antenne PATCH connectée à un analyseur de spectre . 

[[Fichier:fr434.jpg|500px|down]]

On mesure pour la fréquence '''434MHz''':

'''le rapport signal sur bruit SNR '''

le rapport SNR donne une valeur de : 13 dBm
[[Fichier:cn.jpg|500px|down|]]

La puissance du signal est égale à 13 dBm . Ce résulat est identique à la puissance définit par défaut .

===Semaine 6 ===

Modification des codes d'émission et de réception : Envoyer des 1 ou des 0 au lieu du message "Hello word" ; Répondre par ce qu'on reçoit (Ping-pong)

(voir codes : fichier rendus).

===Semaine 7 et 8 ===

Plan de mesures (voir fichiers rendus en bas de la page).

===Semaine 9 et 10 ===

Mesures :

Pour visualiser le signal dans l'air , j'ai utilisé une antenne patch , en mettant tantot le module d'emission tantot le module de reception sur cette dernière .

Sur un oscilloscope 1GHz , j'ai pu visualisé les signaux suivants :

'''Emission :''' [[Fichier:Emission_patch.jpg|500px|down|]]

'''Reception: ''' [[Fichier:Reception_patch.jpg|500px|down|]]

Commentaires : Le signal d'émission visualisé en haut (c1) est la trame qu'on reçoit ; celui d'en-bas (F1) n'est qu'un zoom qui nous permet de voir la forme de ce signal.
On remarque qu'on a signal modulé en QPSK d'où le saut de phase . Cette forme ne correspond pas à la modulation LoRa qui est en chirp Spread Spectrum (CSS) (Cf. datasheet AN1200.22 LoRa™ Modulation) . 

Le cas était aussi pour le signal de reception , mais qui est modulé en AM .

Cette "déformation" des signaux est due à l'utilisation de l'antenne patch (800MHz) qui n'est pas adapté à notre antenne (434MHz). 
:

== Fichiers Rendus ==

[[Fichier:Plandemesures.pdf]]

[[Fichier:Rapportprojet33.pdf]]

IMA4 2016/2017 P33

2017-05-11T20:23:01Z

Onaanaa : /* Fichiers Rendus */

=Présentation du projet=
===Contexte===
Les objets connectés se font une place dans le quotidien et se déploient de plus en plus mais en ce qui concerne leur sécurité, il apparaît que les fabricants ont souvent négligé la sécurité des technologies et de les protéger contre les cyberattaques.
Afin de tester la sécurité des réseaux utilisés dans les objets connectés, nous étudierons le fonctionnement de ces protocoles. Dans le cadre de ce projet nous nous intéresserons aux protocoles LoRa et SigFox.

===Objectif===
L'objectif est donc de réaliser l'écoute de trame d'un réseau sans-fil (LoRa et SigFox) en capturant des trames afin de comprendre le fonctionnement de ces protocoles, et déterminer le format des trames ainsi que des méthodes d'attaque du réseau. C'est ce qu'on appelle l'ingénierie inverse.

===Description du projet===

Pour comprendre le fonctionnement du protocole, nous mettrons en place une maquette contenant des émetteurs et récepteurs afin d'écouter les trames dans le réseau. Une fois la maquette prête, nous mettrons en place une méthode d'écoute des trames et des captures de trames par un analyseur de spectre pour ensuite décoder ces trames.
Pour tester les attaques de type man in the middle, ie introduire des trames dans le réseau, nous allons créer des trames et les faire accepter par le réseau.

===Choix techniques : matériel et logiciel===
'''Fonction principale:'''

Ingénierie inverse : Pouvoir injecter des trames “écrites à la main” entre l'émetteur/récepteur LoRa.

'''Sous-fonction 1:'''

'''Sous-fonction 1:'''
Effectuer la communication entre les modules LoRa:

Pour etablir la communication on utilisera deux Arduino qui serviront à controler l’emission et la reception des données ainsi que les messages à transmettre.

[[Fichier:pt1.png]]

Sous-fonction 2:
on récupère le signal avec un analyseur de spectre pour pouvoir “décoder” le paquet LoRa.

[[Fichier:pt2.png]]

'''
Sous-fonction 3:'''

A partir du paquet “décodé” , écrire un autre paquet pour l’envoyer à un récepteur LoRa .
Pour l’interception , en fonction de la trame que recoit les modules LoRa , on décidera la méthode avec laquelle on intercepte la communication afin d’envoyer des trames “ecrites à la main”.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

'''Tâche 1''': Etablir la communication entre deux modules LoRa. 
'''Tâche 2''' :Visualiser sur l'analyseur de spectre le signal émis . 
'''Tâche 3''': .Prise en main du format du protocole LoRa 
'''Tâche 4''' : Ecrire un paquet LoRa et le faire accepter par un module LoRa . 

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 4h
| 6h
| 6h
|4h
|6h
|8h
|8h
|8h
|8h
|8h
|8h
|
|}

==Avancement du Projet==

===Semaine 1===
Définition du cahier des charges et prise en main du protocole LoRa

===Semaine 2===

Suite du cahier des charges

===Semaine 3===

-Découverte du Feather 
-Etude sur le protocole LoRa et distinction entre Réseau (LoRaWAN) et le protocole LoRa. 

===Semaine 4===

Tache 1 réalisée: 
#Installation des librairies Adafruit (Sur deux machines pour emission/Reception) 
#Test des codes Emission/Réception proposés par la datasheet. 
#Communication réalisée entre deux modules LoRa . 

====Emission====
[[Fichier:femission.png]]

====Réception====

[[Fichier:freception.png]]

===Semaine 5===

Après avoir effectué la communication entre deux modules LoRa , on ajoute un troisième module comme étant récepteur pour voir les changement dus à la présence d'un ou d'autres récepteurs.

[[Fichier:mont3.jpg|500px|down|Montage 3 module LoRa : 1 émetteur & 2 récepteurs]]

On remarque que le RSSI (Received Signal Strength Indication) ne change quasiment pas (entre |21| et |19|) . On peut conclure que la présence de plusieurs récepteurs n'affecte pas la puissance du signal transmis .

[[Fichier:rssi1.png]]

[[Fichier:rssi2.png]]

1ere séance de mesures :

On réalise la communication LoRa entre les modules et on visualise le signal transmis avec une antenne PATCH connectée à un analyseur de spectre . 

[[Fichier:fr434.jpg|500px|down]]

On mesure pour la fréquence '''434MHz''':

'''le rapport signal sur bruit SNR '''

le rapport SNR donne une valeur de : 13 dBm
[[Fichier:cn.jpg|500px|down|]]

La puissance du signal est égale à 13 dBm . Ce résulat est identique à la puissance définit par défaut .

===Semaine 6 ===

Modification des codes d'émission et de réception : Envoyer des 1 ou des 0 au lieu du message "Hello word" ; Répondre par ce qu'on reçoit (Ping-pong)

(voir codes : fichier rendus).

===Semaine 7 et 8 ===

Plan de mesures (voir fichiers rendus en bas de la page).

===Semaine 9 et 10 ===

Mesures :

Pour visualiser le signal dans l'air , j'ai utilisé une antenne patch , en mettant tantot le module d'emission tantot le module de reception sur cette dernière .

Sur un oscilloscope 1GHz , j'ai pu visualisé les signaux suivants :

'''Emission :''' [[Fichier:Emission_patch.jpg|500px|down|]]

'''Reception: ''' [[Fichier:Reception_patch.jpg|500px|down|]]

Commentaires : Le signal d'émission visualisé en haut (c1) est la trame qu'on reçoit ; celui d'en-bas (F1) n'est qu'un zoom qui nous permet de voir la forme de ce signal.
On remarque qu'on a signal modulé en QPSK d'où le saut de phase . Cette forme ne correspond pas à la modulation LoRa qui est en chirp Spread Spectrum (CSS) (Cf. datasheet AN1200.22 LoRa™ Modulation) . 

Le cas était aussi pour le signal de reception , mais qui est modulé en AM .

Cette "déformation" des signaux est due à l'utilisation de l'antenne patch (800MHz) qui n'est pas adapté à notre antenne (434MHz). 
:

== Fichiers Rendus ==

[[Fichier:Plandemesures.pdf]]

[[Fichier:Rapport_projet33.pdf]]

Fichier:Rapport projet33.pdf

2017-05-11T20:22:21Z

Onaanaa : a téléversé une nouvelle version de « Fichier:Rapport projet33.pdf »

IMA4 2016/2017 P33

2017-05-11T20:19:34Z

Onaanaa : /* Fichiers Rendus */

=Présentation du projet=
===Contexte===
Les objets connectés se font une place dans le quotidien et se déploient de plus en plus mais en ce qui concerne leur sécurité, il apparaît que les fabricants ont souvent négligé la sécurité des technologies et de les protéger contre les cyberattaques.
Afin de tester la sécurité des réseaux utilisés dans les objets connectés, nous étudierons le fonctionnement de ces protocoles. Dans le cadre de ce projet nous nous intéresserons aux protocoles LoRa et SigFox.

===Objectif===
L'objectif est donc de réaliser l'écoute de trame d'un réseau sans-fil (LoRa et SigFox) en capturant des trames afin de comprendre le fonctionnement de ces protocoles, et déterminer le format des trames ainsi que des méthodes d'attaque du réseau. C'est ce qu'on appelle l'ingénierie inverse.

===Description du projet===

Pour comprendre le fonctionnement du protocole, nous mettrons en place une maquette contenant des émetteurs et récepteurs afin d'écouter les trames dans le réseau. Une fois la maquette prête, nous mettrons en place une méthode d'écoute des trames et des captures de trames par un analyseur de spectre pour ensuite décoder ces trames.
Pour tester les attaques de type man in the middle, ie introduire des trames dans le réseau, nous allons créer des trames et les faire accepter par le réseau.

===Choix techniques : matériel et logiciel===
'''Fonction principale:'''

Ingénierie inverse : Pouvoir injecter des trames “écrites à la main” entre l'émetteur/récepteur LoRa.

'''Sous-fonction 1:'''

'''Sous-fonction 1:'''
Effectuer la communication entre les modules LoRa:

Pour etablir la communication on utilisera deux Arduino qui serviront à controler l’emission et la reception des données ainsi que les messages à transmettre.

[[Fichier:pt1.png]]

Sous-fonction 2:
on récupère le signal avec un analyseur de spectre pour pouvoir “décoder” le paquet LoRa.

[[Fichier:pt2.png]]

'''
Sous-fonction 3:'''

A partir du paquet “décodé” , écrire un autre paquet pour l’envoyer à un récepteur LoRa .
Pour l’interception , en fonction de la trame que recoit les modules LoRa , on décidera la méthode avec laquelle on intercepte la communication afin d’envoyer des trames “ecrites à la main”.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

'''Tâche 1''': Etablir la communication entre deux modules LoRa. 
'''Tâche 2''' :Visualiser sur l'analyseur de spectre le signal émis . 
'''Tâche 3''': .Prise en main du format du protocole LoRa 
'''Tâche 4''' : Ecrire un paquet LoRa et le faire accepter par un module LoRa . 

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 4h
| 6h
| 6h
|4h
|6h
|8h
|8h
|8h
|8h
|8h
|8h
|
|}

==Avancement du Projet==

===Semaine 1===
Définition du cahier des charges et prise en main du protocole LoRa

===Semaine 2===

Suite du cahier des charges

===Semaine 3===

-Découverte du Feather 
-Etude sur le protocole LoRa et distinction entre Réseau (LoRaWAN) et le protocole LoRa. 

===Semaine 4===

Tache 1 réalisée: 
#Installation des librairies Adafruit (Sur deux machines pour emission/Reception) 
#Test des codes Emission/Réception proposés par la datasheet. 
#Communication réalisée entre deux modules LoRa . 

====Emission====
[[Fichier:femission.png]]

====Réception====

[[Fichier:freception.png]]

===Semaine 5===

Après avoir effectué la communication entre deux modules LoRa , on ajoute un troisième module comme étant récepteur pour voir les changement dus à la présence d'un ou d'autres récepteurs.

[[Fichier:mont3.jpg|500px|down|Montage 3 module LoRa : 1 émetteur & 2 récepteurs]]

On remarque que le RSSI (Received Signal Strength Indication) ne change quasiment pas (entre |21| et |19|) . On peut conclure que la présence de plusieurs récepteurs n'affecte pas la puissance du signal transmis .

[[Fichier:rssi1.png]]

[[Fichier:rssi2.png]]

1ere séance de mesures :

On réalise la communication LoRa entre les modules et on visualise le signal transmis avec une antenne PATCH connectée à un analyseur de spectre . 

[[Fichier:fr434.jpg|500px|down]]

On mesure pour la fréquence '''434MHz''':

'''le rapport signal sur bruit SNR '''

le rapport SNR donne une valeur de : 13 dBm
[[Fichier:cn.jpg|500px|down|]]

La puissance du signal est égale à 13 dBm . Ce résulat est identique à la puissance définit par défaut .

===Semaine 6 ===

Modification des codes d'émission et de réception : Envoyer des 1 ou des 0 au lieu du message "Hello word" ; Répondre par ce qu'on reçoit (Ping-pong)

(voir codes : fichier rendus).

===Semaine 7 et 8 ===

Plan de mesures (voir fichiers rendus en bas de la page).

===Semaine 9 et 10 ===

Mesures :

Pour visualiser le signal dans l'air , j'ai utilisé une antenne patch , en mettant tantot le module d'emission tantot le module de reception sur cette dernière .

Sur un oscilloscope 1GHz , j'ai pu visualisé les signaux suivants :

'''Emission :''' [[Fichier:Emission_patch.jpg|500px|down|]]

'''Reception: ''' [[Fichier:Reception_patch.jpg|500px|down|]]

Commentaires : Le signal d'émission visualisé en haut (c1) est la trame qu'on reçoit ; celui d'en-bas (F1) n'est qu'un zoom qui nous permet de voir la forme de ce signal.
On remarque qu'on a signal modulé en QPSK d'où le saut de phase . Cette forme ne correspond pas à la modulation LoRa qui est en chirp Spread Spectrum (CSS) (Cf. datasheet AN1200.22 LoRa™ Modulation) . 

Le cas était aussi pour le signal de reception , mais qui est modulé en AM .

Cette "déformation" des signaux est due à l'utilisation de l'antenne patch (800MHz) qui n'est pas adapté à notre antenne (434MHz). 
:

== Fichiers Rendus ==

[[Fichier:Plandemesures.pdf]]

[[Fichier:Rapport_Projet33.pdf]]

IMA4 2016/2017 P33

2017-05-11T20:18:27Z

Onaanaa : /* Fichiers Rendus */

=Présentation du projet=
===Contexte===
Les objets connectés se font une place dans le quotidien et se déploient de plus en plus mais en ce qui concerne leur sécurité, il apparaît que les fabricants ont souvent négligé la sécurité des technologies et de les protéger contre les cyberattaques.
Afin de tester la sécurité des réseaux utilisés dans les objets connectés, nous étudierons le fonctionnement de ces protocoles. Dans le cadre de ce projet nous nous intéresserons aux protocoles LoRa et SigFox.

===Objectif===
L'objectif est donc de réaliser l'écoute de trame d'un réseau sans-fil (LoRa et SigFox) en capturant des trames afin de comprendre le fonctionnement de ces protocoles, et déterminer le format des trames ainsi que des méthodes d'attaque du réseau. C'est ce qu'on appelle l'ingénierie inverse.

===Description du projet===

Pour comprendre le fonctionnement du protocole, nous mettrons en place une maquette contenant des émetteurs et récepteurs afin d'écouter les trames dans le réseau. Une fois la maquette prête, nous mettrons en place une méthode d'écoute des trames et des captures de trames par un analyseur de spectre pour ensuite décoder ces trames.
Pour tester les attaques de type man in the middle, ie introduire des trames dans le réseau, nous allons créer des trames et les faire accepter par le réseau.

===Choix techniques : matériel et logiciel===
'''Fonction principale:'''

Ingénierie inverse : Pouvoir injecter des trames “écrites à la main” entre l'émetteur/récepteur LoRa.

'''Sous-fonction 1:'''

'''Sous-fonction 1:'''
Effectuer la communication entre les modules LoRa:

Pour etablir la communication on utilisera deux Arduino qui serviront à controler l’emission et la reception des données ainsi que les messages à transmettre.

[[Fichier:pt1.png]]

Sous-fonction 2:
on récupère le signal avec un analyseur de spectre pour pouvoir “décoder” le paquet LoRa.

[[Fichier:pt2.png]]

'''
Sous-fonction 3:'''

A partir du paquet “décodé” , écrire un autre paquet pour l’envoyer à un récepteur LoRa .
Pour l’interception , en fonction de la trame que recoit les modules LoRa , on décidera la méthode avec laquelle on intercepte la communication afin d’envoyer des trames “ecrites à la main”.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

'''Tâche 1''': Etablir la communication entre deux modules LoRa. 
'''Tâche 2''' :Visualiser sur l'analyseur de spectre le signal émis . 
'''Tâche 3''': .Prise en main du format du protocole LoRa 
'''Tâche 4''' : Ecrire un paquet LoRa et le faire accepter par un module LoRa . 

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 4h
| 6h
| 6h
|4h
|6h
|8h
|8h
|8h
|8h
|8h
|8h
|
|}

==Avancement du Projet==

===Semaine 1===
Définition du cahier des charges et prise en main du protocole LoRa

===Semaine 2===

Suite du cahier des charges

===Semaine 3===

-Découverte du Feather 
-Etude sur le protocole LoRa et distinction entre Réseau (LoRaWAN) et le protocole LoRa. 

===Semaine 4===

Tache 1 réalisée: 
#Installation des librairies Adafruit (Sur deux machines pour emission/Reception) 
#Test des codes Emission/Réception proposés par la datasheet. 
#Communication réalisée entre deux modules LoRa . 

====Emission====
[[Fichier:femission.png]]

====Réception====

[[Fichier:freception.png]]

===Semaine 5===

Après avoir effectué la communication entre deux modules LoRa , on ajoute un troisième module comme étant récepteur pour voir les changement dus à la présence d'un ou d'autres récepteurs.

[[Fichier:mont3.jpg|500px|down|Montage 3 module LoRa : 1 émetteur & 2 récepteurs]]

On remarque que le RSSI (Received Signal Strength Indication) ne change quasiment pas (entre |21| et |19|) . On peut conclure que la présence de plusieurs récepteurs n'affecte pas la puissance du signal transmis .

[[Fichier:rssi1.png]]

[[Fichier:rssi2.png]]

1ere séance de mesures :

On réalise la communication LoRa entre les modules et on visualise le signal transmis avec une antenne PATCH connectée à un analyseur de spectre . 

[[Fichier:fr434.jpg|500px|down]]

On mesure pour la fréquence '''434MHz''':

'''le rapport signal sur bruit SNR '''

le rapport SNR donne une valeur de : 13 dBm
[[Fichier:cn.jpg|500px|down|]]

La puissance du signal est égale à 13 dBm . Ce résulat est identique à la puissance définit par défaut .

===Semaine 6 ===

Modification des codes d'émission et de réception : Envoyer des 1 ou des 0 au lieu du message "Hello word" ; Répondre par ce qu'on reçoit (Ping-pong)

(voir codes : fichier rendus).

===Semaine 7 et 8 ===

Plan de mesures (voir fichiers rendus en bas de la page).

===Semaine 9 et 10 ===

Mesures :

Pour visualiser le signal dans l'air , j'ai utilisé une antenne patch , en mettant tantot le module d'emission tantot le module de reception sur cette dernière .

Sur un oscilloscope 1GHz , j'ai pu visualisé les signaux suivants :

'''Emission :''' [[Fichier:Emission_patch.jpg|500px|down|]]

'''Reception: ''' [[Fichier:Reception_patch.jpg|500px|down|]]

Commentaires : Le signal d'émission visualisé en haut (c1) est la trame qu'on reçoit ; celui d'en-bas (F1) n'est qu'un zoom qui nous permet de voir la forme de ce signal.
On remarque qu'on a signal modulé en QPSK d'où le saut de phase . Cette forme ne correspond pas à la modulation LoRa qui est en chirp Spread Spectrum (CSS) (Cf. datasheet AN1200.22 LoRa™ Modulation) . 

Le cas était aussi pour le signal de reception , mais qui est modulé en AM .

Cette "déformation" des signaux est due à l'utilisation de l'antenne patch (800MHz) qui n'est pas adapté à notre antenne (434MHz). 
:

== Fichiers Rendus ==

[[Fichier:Plandemesures.pdf]]

[[Fichier:Rapport_Projet33.jpg]]

Fichier:Rapport projet33.pdf

2017-05-11T20:17:19Z

Onaanaa :

IMA4 2016/2017 P33

2017-05-07T12:05:49Z

Onaanaa : /* Présentation du projet */

=Présentation du projet=
===Contexte===
Les objets connectés se font une place dans le quotidien et se déploient de plus en plus mais en ce qui concerne leur sécurité, il apparaît que les fabricants ont souvent négligé la sécurité des technologies et de les protéger contre les cyberattaques.
Afin de tester la sécurité des réseaux utilisés dans les objets connectés, nous étudierons le fonctionnement de ces protocoles. Dans le cadre de ce projet nous nous intéresserons aux protocoles LoRa et SigFox.

===Objectif===
L'objectif est donc de réaliser l'écoute de trame d'un réseau sans-fil (LoRa et SigFox) en capturant des trames afin de comprendre le fonctionnement de ces protocoles, et déterminer le format des trames ainsi que des méthodes d'attaque du réseau. C'est ce qu'on appelle l'ingénierie inverse.

===Description du projet===

Pour comprendre le fonctionnement du protocole, nous mettrons en place une maquette contenant des émetteurs et récepteurs afin d'écouter les trames dans le réseau. Une fois la maquette prête, nous mettrons en place une méthode d'écoute des trames et des captures de trames par un analyseur de spectre pour ensuite décoder ces trames.
Pour tester les attaques de type man in the middle, ie introduire des trames dans le réseau, nous allons créer des trames et les faire accepter par le réseau.

===Choix techniques : matériel et logiciel===
'''Fonction principale:'''

Ingénierie inverse : Pouvoir injecter des trames “écrites à la main” entre l'émetteur/récepteur LoRa.

'''Sous-fonction 1:'''

'''Sous-fonction 1:'''
Effectuer la communication entre les modules LoRa:

Pour etablir la communication on utilisera deux Arduino qui serviront à controler l’emission et la reception des données ainsi que les messages à transmettre.

[[Fichier:pt1.png]]

Sous-fonction 2:
on récupère le signal avec un analyseur de spectre pour pouvoir “décoder” le paquet LoRa.

[[Fichier:pt2.png]]

'''
Sous-fonction 3:'''

A partir du paquet “décodé” , écrire un autre paquet pour l’envoyer à un récepteur LoRa .
Pour l’interception , en fonction de la trame que recoit les modules LoRa , on décidera la méthode avec laquelle on intercepte la communication afin d’envoyer des trames “ecrites à la main”.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

'''Tâche 1''': Etablir la communication entre deux modules LoRa. 
'''Tâche 2''' :Visualiser sur l'analyseur de spectre le signal émis . 
'''Tâche 3''': .Prise en main du format du protocole LoRa 
'''Tâche 4''' : Ecrire un paquet LoRa et le faire accepter par un module LoRa . 

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 4h
| 6h
| 6h
|4h
|6h
|8h
|8h
|8h
|8h
|8h
|8h
|
|}

==Avancement du Projet==

===Semaine 1===
Définition du cahier des charges et prise en main du protocole LoRa

===Semaine 2===

Suite du cahier des charges

===Semaine 3===

-Découverte du Feather 
-Etude sur le protocole LoRa et distinction entre Réseau (LoRaWAN) et le protocole LoRa. 

===Semaine 4===

Tache 1 réalisée: 
#Installation des librairies Adafruit (Sur deux machines pour emission/Reception) 
#Test des codes Emission/Réception proposés par la datasheet. 
#Communication réalisée entre deux modules LoRa . 

====Emission====
[[Fichier:femission.png]]

====Réception====

[[Fichier:freception.png]]

===Semaine 5===

Après avoir effectué la communication entre deux modules LoRa , on ajoute un troisième module comme étant récepteur pour voir les changement dus à la présence d'un ou d'autres récepteurs.

[[Fichier:mont3.jpg|500px|down|Montage 3 module LoRa : 1 émetteur & 2 récepteurs]]

On remarque que le RSSI (Received Signal Strength Indication) ne change quasiment pas (entre |21| et |19|) . On peut conclure que la présence de plusieurs récepteurs n'affecte pas la puissance du signal transmis .

[[Fichier:rssi1.png]]

[[Fichier:rssi2.png]]

1ere séance de mesures :

On réalise la communication LoRa entre les modules et on visualise le signal transmis avec une antenne PATCH connectée à un analyseur de spectre . 

[[Fichier:fr434.jpg|500px|down]]

On mesure pour la fréquence '''434MHz''':

'''le rapport signal sur bruit SNR '''

le rapport SNR donne une valeur de : 13 dBm
[[Fichier:cn.jpg|500px|down|]]

La puissance du signal est égale à 13 dBm . Ce résulat est identique à la puissance définit par défaut .

===Semaine 6 ===

Modification des codes d'émission et de réception : Envoyer des 1 ou des 0 au lieu du message "Hello word" ; Répondre par ce qu'on reçoit (Ping-pong)

(voir codes : fichier rendus).

===Semaine 7 et 8 ===

Plan de mesures (voir fichiers rendus en bas de la page).

===Semaine 9 et 10 ===

Mesures :

Pour visualiser le signal dans l'air , j'ai utilisé une antenne patch , en mettant tantot le module d'emission tantot le module de reception sur cette dernière .

Sur un oscilloscope 1GHz , j'ai pu visualisé les signaux suivants :

'''Emission :''' [[Fichier:Emission_patch.jpg|500px|down|]]

'''Reception: ''' [[Fichier:Reception_patch.jpg|500px|down|]]

Commentaires : Le signal d'émission visualisé en haut (c1) est la trame qu'on reçoit ; celui d'en-bas (F1) n'est qu'un zoom qui nous permet de voir la forme de ce signal.
On remarque qu'on a signal modulé en QPSK d'où le saut de phase . Cette forme ne correspond pas à la modulation LoRa qui est en chirp Spread Spectrum (CSS) (Cf. datasheet AN1200.22 LoRa™ Modulation) . 

Le cas était aussi pour le signal de reception , mais qui est modulé en AM .

Cette "déformation" des signaux est due à l'utilisation de l'antenne patch (800MHz) qui n'est pas adapté à notre antenne (434MHz). 
:

== Fichiers Rendus ==

[[Fichier:Plandemesures.pdf]]

IMA4 2016/2017 P33

2017-05-07T11:52:48Z

Onaanaa : /* Feuille d'heures */

=Présentation du projet=
===Contexte===
Les objets connectés se font une place dans le quotidien et se déploient de plus en plus mais en ce qui concerne leur sécurité, il apparaît que les fabricants ont souvent négligé la sécurité des technologies et de les protéger contre les cyberattaques.
Afin de tester la sécurité des réseaux utilisés dans les objets connectés, nous étudierons le fonctionnement de ces protocoles. Dans le cadre de ce projet nous nous intéresserons aux protocoles LoRa et SigFox.

===Objectif===
L'objectif est donc de réaliser l'écoute de trame d'un réseau sans-fil (LoRa et SigFox) en capturant des trames afin de comprendre le fonctionnement de ces protocoles, et déterminer le format des trames ainsi que des méthodes d'attaque du réseau. C'est ce qu'on appelle l'ingénierie inverse.

===Description du projet===

Pour comprendre le fonctionnement du protocole, nous mettrons en place une maquette contenant des émetteurs et récepteurs afin d'écouter les trames dans le réseau. Une fois la maquette prête, nous mettrons en place une méthode d'écoute des trames et des captures de trames par un analyseur de spectre pour ensuite décoder ces trames.
Pour tester les attaques de type man in the middle, ie introduire des trames dans le réseau, nous allons créer des trames et les faire accepter par le réseau.

===Choix techniques : matériel et logiciel===
'''Fonction principale:'''

Ingénierie inverse : Pouvoir injecter des trames “écrites à la main” entre l'émetteur/récepteur LoRa.

'''Sous-fonction 1:'''

'''Sous-fonction 1:'''
Effectuer la communication entre les modules LoRa:

Pour etablir la communication on utilisera deux Arduino qui serviront à controler l’emission et la reception des données ainsi que les messages à transmettre.

[[Fichier:pt1.png]]

Sous-fonction 2:
on récupère le signal avec un analyseur de spectre pour pouvoir “décoder” le paquet LoRa.

[[Fichier:pt2.png]]

'''
Sous-fonction 3:'''

A partir du paquet “décodé” , écrire un autre paquet pour l’envoyer à un récepteur LoRa .
Pour l’interception , en fonction de la trame que recoit les modules LoRa , on décidera la méthode avec laquelle on intercepte la communication afin d’envoyer des trames “ecrites à la main”.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

'''Tâche 1''': Etablir la communication entre deux modules LoRa. 
'''Tâche 2''' :Visualiser sur l'analyseur de spectre le signal émis . 
'''Tâche 3''': .Prise en main du format du protocole LoRa 
'''Tâche 4''' : Ecrire un paquet LoRa et le faire accepter par un module LoRa . 

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 4h
| 6h
| 6h
|4h
|6h
|8h
|8h
|8h
|8h
|8h
|8h
|
|}

==Avancement du Projet==

===Semaine 1===
Définition du cahier des charges et prise en main du protocole LoRa

===Semaine 2===

Suite du cahier des charges

===Semaine 3===

-Découverte du Feather 
-Etude sur le protocole LoRa et distinction entre Réseau (LoRaWAN) et le protocole LoRa. 

===Semaine 4===

Tache 1 réalisée: 
#Installation des librairies Adafruit (Sur deux machines pour emission/Reception) 
#Test des codes Emission/Réception proposés par la datasheet. 
#Communication réalisée entre deux modules LoRa . 

====Emission====
[[Fichier:femission.png]]

====Réception====

[[Fichier:freception.png]]

===Semaine 5===

Après avoir effectué la communication entre deux modules LoRa , on ajoute un troisième module comme étant récepteur pour voir les changement dus à la présence d'un ou d'autres récepteurs.

[[Fichier:mont3.jpg|500px|down|Montage 3 module LoRa : 1 émetteur & 2 récepteurs]]

On remarque que le RSSI (Received Signal Strength Indication) ne change quasiment pas (entre |21| et |19|) . On peut conclure que la présence de plusieurs récepteurs n'affecte pas la puissance du signal transmis .

[[Fichier:rssi1.png]]

[[Fichier:rssi2.png]]

1ere séance de mesures :

On réalise la communication LoRa entre les modules et on visualise le signal transmis avec une antenne PATCH connectée à un analyseur de spectre . 

[[Fichier:fr434.jpg|500px|down]]

On mesure pour la fréquence '''434MHz''':

== le rapport signal sur bruit SNR ==

le rapport SNR donne une valeur de : 13 dBm
[[Fichier:cn.jpg|500px|down|]]

La puissance du signal est égale à 13 dBm . Ce résulat est identique à la puissance définit par défaut .

===Semaine 6 ===

Modification des codes d'émission et de réception : Envoyer des 1 ou des 0 au lieu du message "Hello word" ; Répondre par ce qu'on reçoit (Ping-pong)

(voir codes : fichier rendus).

===Semaine 7 et 8 ===

Plan de mesures (voir fichiers rendus en bas de la page).

===Semaine 9 et 10 ===

Mesures :

Pour visualiser le signal dans l'air , j'ai utilisé une antenne patch , en mettant tantot le module d'emission tantot le module de reception sur cette dernière .

Sur un oscilloscope 1GHz , j'ai pu visualisé les signaux suivants :

'''Emission :''' [[Fichier:Emission_patch.jpg|500px|down|]]

'''Reception: ''' [[Fichier:Reception_patch.jpg|500px|down|]]

Commentaires : Le signal d'émission visualisé en haut (c1) est la trame qu'on reçoit ; celui d'en-bas (F1) n'est qu'un zoom qui nous permet de voir la forme de ce signal.
On remarque qu'on a signal modulé en QPSK d'où le saut de phase . Cette forme ne correspond pas à la modulation LoRa qui est en chirp Spread Spectrum (CSS) (Cf. datasheet AN1200.22 LoRa™ Modulation) . 

Le cas était aussi pour le signal de reception , mais qui est modulé en AM .

Cette "déformation" des signaux est due à l'utilisation de l'antenne patch (800MHz) qui n'est pas adapté à notre antenne (434MHz). 
:

== Fichiers Rendus ==

[[Fichier:Plandemesures.pdf]]

IMA4 2016/2017 P33

2017-05-07T11:48:29Z

Onaanaa : /* Semaine 9 et 10 */

=Présentation du projet=
===Contexte===
Les objets connectés se font une place dans le quotidien et se déploient de plus en plus mais en ce qui concerne leur sécurité, il apparaît que les fabricants ont souvent négligé la sécurité des technologies et de les protéger contre les cyberattaques.
Afin de tester la sécurité des réseaux utilisés dans les objets connectés, nous étudierons le fonctionnement de ces protocoles. Dans le cadre de ce projet nous nous intéresserons aux protocoles LoRa et SigFox.

===Objectif===
L'objectif est donc de réaliser l'écoute de trame d'un réseau sans-fil (LoRa et SigFox) en capturant des trames afin de comprendre le fonctionnement de ces protocoles, et déterminer le format des trames ainsi que des méthodes d'attaque du réseau. C'est ce qu'on appelle l'ingénierie inverse.

===Description du projet===

Pour comprendre le fonctionnement du protocole, nous mettrons en place une maquette contenant des émetteurs et récepteurs afin d'écouter les trames dans le réseau. Une fois la maquette prête, nous mettrons en place une méthode d'écoute des trames et des captures de trames par un analyseur de spectre pour ensuite décoder ces trames.
Pour tester les attaques de type man in the middle, ie introduire des trames dans le réseau, nous allons créer des trames et les faire accepter par le réseau.

===Choix techniques : matériel et logiciel===
'''Fonction principale:'''

Ingénierie inverse : Pouvoir injecter des trames “écrites à la main” entre l'émetteur/récepteur LoRa.

'''Sous-fonction 1:'''

'''Sous-fonction 1:'''
Effectuer la communication entre les modules LoRa:

Pour etablir la communication on utilisera deux Arduino qui serviront à controler l’emission et la reception des données ainsi que les messages à transmettre.

[[Fichier:pt1.png]]

Sous-fonction 2:
on récupère le signal avec un analyseur de spectre pour pouvoir “décoder” le paquet LoRa.

[[Fichier:pt2.png]]

'''
Sous-fonction 3:'''

A partir du paquet “décodé” , écrire un autre paquet pour l’envoyer à un récepteur LoRa .
Pour l’interception , en fonction de la trame que recoit les modules LoRa , on décidera la méthode avec laquelle on intercepte la communication afin d’envoyer des trames “ecrites à la main”.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

'''Tâche 1''': Etablir la communication entre deux modules LoRa. 
'''Tâche 2''' :Visualiser sur l'analyseur de spectre le signal émis . 
'''Tâche 3''': .Prise en main du format du protocole LoRa 
'''Tâche 4''' : Ecrire un paquet LoRa et le faire accepter par un module LoRa . 

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 4h
| 6h
| 6h
|4h
|6h
|8h
|
|
|
|
|
|
|}

==Avancement du Projet==

===Semaine 1===
Définition du cahier des charges et prise en main du protocole LoRa

===Semaine 2===

Suite du cahier des charges

===Semaine 3===

-Découverte du Feather 
-Etude sur le protocole LoRa et distinction entre Réseau (LoRaWAN) et le protocole LoRa. 

===Semaine 4===

Tache 1 réalisée: 
#Installation des librairies Adafruit (Sur deux machines pour emission/Reception) 
#Test des codes Emission/Réception proposés par la datasheet. 
#Communication réalisée entre deux modules LoRa . 

====Emission====
[[Fichier:femission.png]]

====Réception====

[[Fichier:freception.png]]

===Semaine 5===

Après avoir effectué la communication entre deux modules LoRa , on ajoute un troisième module comme étant récepteur pour voir les changement dus à la présence d'un ou d'autres récepteurs.

[[Fichier:mont3.jpg|500px|down|Montage 3 module LoRa : 1 émetteur & 2 récepteurs]]

On remarque que le RSSI (Received Signal Strength Indication) ne change quasiment pas (entre |21| et |19|) . On peut conclure que la présence de plusieurs récepteurs n'affecte pas la puissance du signal transmis .

[[Fichier:rssi1.png]]

[[Fichier:rssi2.png]]

1ere séance de mesures :

On réalise la communication LoRa entre les modules et on visualise le signal transmis avec une antenne PATCH connectée à un analyseur de spectre . 

[[Fichier:fr434.jpg|500px|down]]

On mesure pour la fréquence '''434MHz''':

== le rapport signal sur bruit SNR ==

le rapport SNR donne une valeur de : 13 dBm
[[Fichier:cn.jpg|500px|down|]]

La puissance du signal est égale à 13 dBm . Ce résulat est identique à la puissance définit par défaut .

===Semaine 6 ===

Modification des codes d'émission et de réception : Envoyer des 1 ou des 0 au lieu du message "Hello word" ; Répondre par ce qu'on reçoit (Ping-pong)

(voir codes : fichier rendus).

===Semaine 7 et 8 ===

Plan de mesures (voir fichiers rendus en bas de la page).

===Semaine 9 et 10 ===

Mesures :

Pour visualiser le signal dans l'air , j'ai utilisé une antenne patch , en mettant tantot le module d'emission tantot le module de reception sur cette dernière .

Sur un oscilloscope 1GHz , j'ai pu visualisé les signaux suivants :

'''Emission :''' [[Fichier:Emission_patch.jpg|500px|down|]]

'''Reception: ''' [[Fichier:Reception_patch.jpg|500px|down|]]

Commentaires : Le signal d'émission visualisé en haut (c1) est la trame qu'on reçoit ; celui d'en-bas (F1) n'est qu'un zoom qui nous permet de voir la forme de ce signal.
On remarque qu'on a signal modulé en QPSK d'où le saut de phase . Cette forme ne correspond pas à la modulation LoRa qui est en chirp Spread Spectrum (CSS) (Cf. datasheet AN1200.22 LoRa™ Modulation) . 

Le cas était aussi pour le signal de reception , mais qui est modulé en AM .

Cette "déformation" des signaux est due à l'utilisation de l'antenne patch (800MHz) qui n'est pas adapté à notre antenne (434MHz). 
:

== Fichiers Rendus ==

[[Fichier:Plandemesures.pdf]]

Fichier:Reception patch.jpg

2017-05-07T11:47:52Z

Onaanaa : signal visualisé en captant un signal recu par un module lora avec une antenne patch

signal visualisé en captant un signal recu par un module lora avec une antenne patch

IMA4 2016/2017 P33

2017-05-07T11:37:22Z

Onaanaa : /* Semaine 9 et 10 */

=Présentation du projet=
===Contexte===
Les objets connectés se font une place dans le quotidien et se déploient de plus en plus mais en ce qui concerne leur sécurité, il apparaît que les fabricants ont souvent négligé la sécurité des technologies et de les protéger contre les cyberattaques.
Afin de tester la sécurité des réseaux utilisés dans les objets connectés, nous étudierons le fonctionnement de ces protocoles. Dans le cadre de ce projet nous nous intéresserons aux protocoles LoRa et SigFox.

===Objectif===
L'objectif est donc de réaliser l'écoute de trame d'un réseau sans-fil (LoRa et SigFox) en capturant des trames afin de comprendre le fonctionnement de ces protocoles, et déterminer le format des trames ainsi que des méthodes d'attaque du réseau. C'est ce qu'on appelle l'ingénierie inverse.

===Description du projet===

Pour comprendre le fonctionnement du protocole, nous mettrons en place une maquette contenant des émetteurs et récepteurs afin d'écouter les trames dans le réseau. Une fois la maquette prête, nous mettrons en place une méthode d'écoute des trames et des captures de trames par un analyseur de spectre pour ensuite décoder ces trames.
Pour tester les attaques de type man in the middle, ie introduire des trames dans le réseau, nous allons créer des trames et les faire accepter par le réseau.

===Choix techniques : matériel et logiciel===
'''Fonction principale:'''

Ingénierie inverse : Pouvoir injecter des trames “écrites à la main” entre l'émetteur/récepteur LoRa.

'''Sous-fonction 1:'''

'''Sous-fonction 1:'''
Effectuer la communication entre les modules LoRa:

Pour etablir la communication on utilisera deux Arduino qui serviront à controler l’emission et la reception des données ainsi que les messages à transmettre.

[[Fichier:pt1.png]]

Sous-fonction 2:
on récupère le signal avec un analyseur de spectre pour pouvoir “décoder” le paquet LoRa.

[[Fichier:pt2.png]]

'''
Sous-fonction 3:'''

A partir du paquet “décodé” , écrire un autre paquet pour l’envoyer à un récepteur LoRa .
Pour l’interception , en fonction de la trame que recoit les modules LoRa , on décidera la méthode avec laquelle on intercepte la communication afin d’envoyer des trames “ecrites à la main”.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

'''Tâche 1''': Etablir la communication entre deux modules LoRa. 
'''Tâche 2''' :Visualiser sur l'analyseur de spectre le signal émis . 
'''Tâche 3''': .Prise en main du format du protocole LoRa 
'''Tâche 4''' : Ecrire un paquet LoRa et le faire accepter par un module LoRa . 

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 4h
| 6h
| 6h
|4h
|6h
|8h
|
|
|
|
|
|
|}

==Avancement du Projet==

===Semaine 1===
Définition du cahier des charges et prise en main du protocole LoRa

===Semaine 2===

Suite du cahier des charges

===Semaine 3===

-Découverte du Feather 
-Etude sur le protocole LoRa et distinction entre Réseau (LoRaWAN) et le protocole LoRa. 

===Semaine 4===

Tache 1 réalisée: 
#Installation des librairies Adafruit (Sur deux machines pour emission/Reception) 
#Test des codes Emission/Réception proposés par la datasheet. 
#Communication réalisée entre deux modules LoRa . 

====Emission====
[[Fichier:femission.png]]

====Réception====

[[Fichier:freception.png]]

===Semaine 5===

Après avoir effectué la communication entre deux modules LoRa , on ajoute un troisième module comme étant récepteur pour voir les changement dus à la présence d'un ou d'autres récepteurs.

[[Fichier:mont3.jpg|500px|down|Montage 3 module LoRa : 1 émetteur & 2 récepteurs]]

On remarque que le RSSI (Received Signal Strength Indication) ne change quasiment pas (entre |21| et |19|) . On peut conclure que la présence de plusieurs récepteurs n'affecte pas la puissance du signal transmis .

[[Fichier:rssi1.png]]

[[Fichier:rssi2.png]]

1ere séance de mesures :

On réalise la communication LoRa entre les modules et on visualise le signal transmis avec une antenne PATCH connectée à un analyseur de spectre . 

[[Fichier:fr434.jpg|500px|down]]

On mesure pour la fréquence '''434MHz''':

== le rapport signal sur bruit SNR ==

le rapport SNR donne une valeur de : 13 dBm
[[Fichier:cn.jpg|500px|down|]]

La puissance du signal est égale à 13 dBm . Ce résulat est identique à la puissance définit par défaut .

===Semaine 6 ===

Modification des codes d'émission et de réception : Envoyer des 1 ou des 0 au lieu du message "Hello word" ; Répondre par ce qu'on reçoit (Ping-pong)

(voir codes : fichier rendus).

===Semaine 7 et 8 ===

Plan de mesures (voir fichiers rendus en bas de la page).

===Semaine 9 et 10 ===

Mesures :

Pour visualiser le signal dans l'air , j'ai utilisé une antenne patch , en mettant tantot le module d'emission tantot le module de reception sur cette dernière .

Sur un oscilloscope 1GHz , j'ai pu visualisé les signaux suivants :

'''Emission :''' [[Fichier:Emission_patch.jpg|500px|down|]]

'''Reception '''

Commentaires : Le signal d'émission visualisé en haut (c1) est la trame qu'on reçoit ; celui d'en-bas (F1) n'est qu'un zoom qui nous permet de voir la forme de ce signal.
On remarque qu'on a signal modulé en QPSK d'où le saut de phase . Cette forme ne correspond pas à la modulation LoRa qui est en chirp Spread Spectrum (CSS) (Cf. datasheet AN1200.22 LoRa™ Modulation) . 

Le cas était aussi pour le signal de reception , mais qui est modulé en AM .

Cette "déformation" des signaux est due à l'utilisation de l'antenne patch (800MHz) qui n'est pas adapté à notre antenne (434MHz). 

== Fichiers Rendus ==

[[Fichier:Plandemesures.pdf]]

Fichier:Emission patch.jpg

2017-05-07T11:22:45Z

Onaanaa : Signal visualisé en captant le signal emis par un module LoRa par une antenne patch

Signal visualisé en captant le signal emis par un module LoRa par une antenne patch

IMA4 2016/2017 P33

2017-05-07T11:15:15Z

Onaanaa : /* Présentation du projet */

IMA4 2016/2017 P33

2017-05-07T11:02:31Z

Onaanaa : /* Présentation du projet */

IMA4 2016/2017 P33

2017-05-07T10:34:53Z

Onaanaa : /* Semaine 8 */

IMA4 2016/2017 P33

2017-05-07T10:34:41Z

Onaanaa : /* Semaine 8 et 9 */

IMA4 2016/2017 P33

2017-05-07T10:28:37Z

Onaanaa : /* Fichiers Rendus */

IMA4 2016/2017 P33

2017-05-07T10:26:30Z

Onaanaa : /* Fichiers Rendus */

IMA4 2016/2017 P33

2017-05-07T10:26:12Z

Onaanaa : /* le rapport signal sur bruit SNR */

IMA4 2016/2017 P33

2017-05-07T10:24:28Z

Onaanaa : /* le bruit */

IMA4 2016/2017 P33

2017-05-07T10:14:31Z

Onaanaa : /* le bruit */

IMA4 2016/2017 P33

2017-03-27T13:46:29Z

Onaanaa : /* Fichiers Rendus */

Fichier:Plandemesures.pdf

2017-03-27T13:45:42Z

Onaanaa :

IMA4 2016/2017 P33

2017-03-27T13:43:28Z

Onaanaa : /* Avancement du Projet */

Fichier:Channelpower.jpg

2017-03-27T13:32:58Z

Onaanaa :

Fichier:Fr434.jpg

2017-03-27T13:32:20Z

Onaanaa :

Fichier:Cn.jpg

2017-03-27T13:31:55Z

Onaanaa :

Fichier:Bruit.jpg

2017-03-27T13:31:05Z

Onaanaa :

Discussion:Projets IMA4 SC & SA 2016/2017

2017-03-22T15:12:07Z

Onaanaa : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Mini-cahier des charges || Mi-parcours || Fin de parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Cahier des charges conforme à la discussion avec l'encadrant. Présentation propre avec un effort d'illustration. Pas de liste des tâches ou de calendrier prévisionnel. Quelques coquilles corrigées.
| Abandon constaté
| 
| 
| 
| 
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Cahier des charges succinct. Attention à la rédaction en français. Un effort d'illustration avec un schéma global. Une liste des tâches, sans chiffrage pour l'instant.
| Mauvaise utilisation de la feuille d'heures.De gros problèmes de rédaction en français bien compréhensibles.Un Wiki très bien tenu et très bien illustré, une avancée du travail parfaitement expliquée, continuez ainsi !
| 
| 
| 
| 
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Cahier des charges assez précis. Pas trop de coquilles. Une liste des tâches un peu succincte. Réfléchissez bien à la structure du programme pour la mise à jour simplifiée des fiches sur l'application.
| Feuille d'heures non utilisée, Wiki non mis à jour.Pour les 4 premières semaine, des paragraphes correctement rédigés et bien illustré, il était possible de se faire une idée de l'avancée du projet.
| 
| 
| 
| 
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Cahier des charges précis. Forme très correcte. Une liste des tâches réfléchie. Il y a même un calendrier prévisionnel.
| Aucune utilisation de la feuille d'heures.Un excellent Wiki, très complet, très bien illustré, le travail est parfaitement décrit !
| 
| 
| 
| 
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Cahier des charges très précis. De même pour la liste des tâches. L'utilisation de bioloïds ne semble pas justifiée. Pourquoi ne parlez-vous de capteurs que dans le cadre d'un seul des deux appareils ?
| Feuille d'heures très bien exploitée.Wiki très bien rédigé mais absolument pas illustré, un peu court peut être.
| 
| 
| 
| 
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Pas mal de coquilles corrigées. Une certaine imprécision (confusion Arduino Mega et ATMEGA, flou dans la liste des tâches). Cela dit un cahier des charges et une liste des tâches sont présentés. Pensez aux problèmes de calibration du système et à la transmission des données vers un smartphone par exemple.
| Mauvaise utilisation de la feuille d'heures.Quelques coquilles, le Wiki est un peu vide, pas totalement à jour, dommage que le cahier des charges joint ne soit pas intégré directement au Wiki.
| 
| 
| 
| 
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Synthèse correcte de l'entretien avec l'encadrant. Le cahier des charges est correct mais moins précis que le sujet. Le découpage en tâche est un peu rapide : l'analyse des fichiers MIDI devrait être sous-découpée. Presque pas de coquilles.
| Très bonne utilisation de la feuille d'heures.Wiki très synthétique dans un français très correct, à jour, travail sur l'imprimante bien décrit, pas beaucoup d'information sur l'analyse du fichier MIDI.
| 
| 
| 
| 
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Très bonne prise en main du sujet. Cahier des charges très précis. Liste des tâches bien détaillée. Orthographe irréprochable.
| Feuille d'heures bien exploitée, Wiki très bien rédigé, illustré, l'avancé du travail est bien présenté.
| 
| 
| 
| 
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Une grande partie du cahier des charges est une copie du sujet. Définissez ce qu'est une Referee Box. D'un autre coté, le cahier des charges est précis. La liste des tâches est correcte. Cependant elle semble omettre la partie mécanique de la MPS ? Pas de coquilles.
| Pas d'utilisation de la feuille d'heures.Wiki bien rédigé et très bien illustré, le travail effectué est présenté. Il serait bien d'avoir une carte rapidement.
| 
| 
| 
| 
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Des imprécisions dans la transcription de la réunion avec l'encadrant. Voire des contre-sens. Le cahier des charges est assez complet. Pas de liste des tâches. Vous avez vraiment passé 3h sur la rédaction du cahier des charges ? (edit d'Alex : certainement pas)Une liste des tâches ajoutée.
| Pas d'utilisation de la feuille d'heures.Le Wiki est principalement constitué des schématiques et des PCB des différentes cartes. Après tout c'est un point important de votre travail mais le soin apporté à ces productions, s'il s'améliore était initialement assez faible. La rédaction est presque absente ou d'un niveau faible. Vous devriez déjà avoir des cartes en production.
| 
| 
| 
| 
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Le texte a été modifié pour être compréhensible mais le problème n'est pas là. Vous n'avez pas du tout transcrit les demandes de l'encadrant mais donné le sujet du projet de l'an passé. Cette année vous devez améliorer l'aspect esthétique des robots, construire le quatrième robot et améliorer la détection infra-rouge en utilisant le protocole utilisé par les télécommandes infra-rouges classiques. Vous n'avez pas, non plus, donné une liste précise des tâches à réaliser.Cahier des charges révisé avec l'encadrant. La listes des tâches à réaliser est à préciser.
| Pas d'utilisation de la feuille d'heures.Wiki assez vide, le seul élément probant est la présentation de la nouvelle version de la carte des robots suiveurs. Des coquilles, ce que l'on peut difficilement vous reprocher. Il faudrait maintenant avoir un code pour le protocole RC5, utilisez deux Arduinos pour avoir un prototype de démonstration.
| 
| 
| 
| 
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| La restitution de la discussion avec l'encadrant est très correcte et le cahier des charge est précisément décrit. Par contre la liste des tâches à effectuer n'est pas dressée en commençant par l'étude des conditions à respecter pour lancer un tel ballon.
| Pratiquement pas d'utilisation de la feuille d'heures.Wiki un peu rapide, illustré, quelques coquilles. Peu de résultats à ce jour, vous devriez avoir votre carte et avoir conduit un test de communication avec les capteurs et les modules LoRa.
| 
| 
| 
| 
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Assimilation très correcte des demandes faites par les encadrants. Un cahier des charges précis. De même pour la liste des tâches. Un effort de présentation sans trop de coquilles. Cependant quelques erreurs relevées par M. Dhaussy, merci de corriger le CdC au vu des remarques transmises.
| Pas d'utilisation de la feuille d'heures.Wiki à l'abandon, impossible de savoir où vous en êtes dans le travail. Réagissez immédiatement !
| 
| 
| 
| 
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| Le cahier des charges est une recopie du sujet, avec des passages soulignés, certes. Une liste des tâches très précise mais uniquement orientée développement Web. Il manque toute la partie étude et utilisation des éco-systèmes d'isolation.Cahier des charges plus précis, vous pouvez vous lancer.
| Pas d'utilisation de la feuille d'heures.Partie travail du Wiki presque vide, pas d'illustration, il est à craindre que le travail ne soit pas plus avancé que le Wiki.
| 
| 
| 
| 
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Cahier des charges très précis avec déjà des idées pour la réalisation. Liste des tâches à effectuer très détaillée.
| Pas d'utilisation de la feuille d'heures.Très bon Wiki, bien illustré, travail bien décrit.
| 
| 
| 
| 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Très peu d'apport par rapport au sujet qui est lui même assez bref. Il ne semble pas y avoir eu de rencontre avec l'encadrant dans les temps impartis ? Pas de liste des tâches. Cahier des charges révisés sous la direction de deux encadrants.
| Mauvaise utilisation de la feuille d'heures.Wiki vide, rien de concret semble avoir été réalisé, aucune illustration. Il va falloir mettre les bouchées quadruples ...
| 
| 
| 
| 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Le cahier des charges est une paraphrase du sujet. Dans la liste des tâches il semble curieux de ne pas commencer par l'étude des brouilleurs. Avez-vous échangé avec vos encadrants ?Cahier des charges plus précis.
| Tentative d'utilisation de la feuille d'heures, definissez au préalable les lignes dans ce tableau.Un Wiki trop rapidement rédigé en style télégraphique avec des coquilles, à la lecture du Wiki il est difficile de croire que vous avez passé le nombre d'heures annoncées pour si peu de résultats.
| 
| 
| 
| 
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Une simple paraphrase du sujet. Pas de liste des tâches à réaliser. Il semble que vous n'avez pas réussi à échanger avec vos encadrants dans les temps impartis. Des coquilles (corrigées).
| Mauvaise utilisation de la feuille d'heures.Wiki pratiquement vide, l'image n'apporte rien, le Wiki ne reflète que peu de travail.
| 
| 
| 
| 
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Une rencontre avec les encadrants. Un cahier des charges assez précis. Pas de section "tâches à réaliser" mais une section "notre travail" qui pourrait en tenir lieu avec un effort de structuration.
| Utilisation de la feuille d'heure.Un Wiki trop synthétique, des illustrations à venir ?
| 
| 
| 
| 
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Présentez les objectifs généraux pour commencer. Un cahier des charges très précis mais il manque la liste des tâches à effectuer. Débutez la par l'état de l'art sur les produits déjà commercialisés.
| Bonne utilisation de la fichier d'heures.Excellent Wiki mais non mis à jour ; il s'arrête à la semaine 4.
| 
| 
| 
| 
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Le sujet du projet à été recopié. Les deux sections personnelles sont assez mal rédigées. Un contre-sens sur le mode de connexion du prototype actuel : la veilleuse est configurée en point d'accès. Parlez plutôt de "Précisions sur le cahier des charges" plutôt que de "Problèmes rencontrés sur l'étude du projet". Renommez aussi "Nouveau cahier des charges" en "Tâches à réaliser" et ajouter les autres tâches demandées dans le sujet.Cahier des charges et listes des tâches finalement validés par deux encadrants.
| Bonne utilisation de la feuille d'heures.Bon Wiki, correctement illustré. Par contre faudrait arriver à présenter une réalisation, vous prenez du retard.
| 
| 
| 
| 
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Uniquement une recopie du sujet.Un cahier des charges et une liste de tâches corrects après discussion avec deux encadrants.
| Mauvaise utilisation de la feuille d'heures.Le Wiki n'est pas à jour, il s'arrête à la semaine 4. Bien illustré. Le travail se concentre sur la partie logicielle, en particulier avec un traitement d'image non demandé mais intéressant. Il faudrait se pencher très vite sur le contrôle des lasers.
| 
| 
| 
| 
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Un très bon cahier des charges. Le sujet semble être bien assimilé. Une liste des tâches correcte (il faudrait peut-être détailler la programmation du proxy).
| Un Wiki tout simplement parfait.
| 
| 
| 
| 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Un excellent cahier des charges. Liste des tâches très détaillée. Parfait.
| Pas d'utilisation de la feuille d'heures.Wiki très détaillé, correctement illustré, le travail effectué est présenté correctement.
| 
| 
| 
| 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Vous n'avez pas su vous adapter à la syntaxe mediawiki. Correction pour obtenir un CdC lisible. Une recopie intégrale du sujet. Un cahier des charges qui ressemble plus à une liste des tâches à effectuer.Vous utilisez bien la syntaxe mediawiki maintenant. Par contre il n'y a toujours pas de cahier des charges.
| Feuille d'heures utilisée. Un Wiki mis à jour. Il est très difficile de se faire une idée de votre travail. Il semble que vous soyez actuellement plutôt en TP qu'en projet ?
| 
| 
| 
| 
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Un cahier des charges en 4 lignes, c'est trop court. En particulier rien sur le contexte du projet à savoir le matériel ou le simulateur sur lequel les tests seront effectués. Une liste des tâches, cette liste est-elle avalisé par l'encadrant ?Toujours pas de cahier des charges.
| Feuille d'heures correctement remplie. Wiki plutôt vide. Il est difficile de se faire une idée du travail réalisé, vous semblez bloqué à l'étape bibliographie.
| 
| 
| 
| 
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (25/01) !! Séance 2 (01/02) !! Séance 3 (08/02) !! Séance 4 (15/02) !! Séance 5 (01/03) !! Séance 6 (08/03) !! Séance 7 !! Séance 8 !! Séance 9 !! Séance 10
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Haroun Abdelali
| 
| Absent
| Absent
| D317 
| D309 
| D309 
| 
| 
| 
| 
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Wenyu sun / Xinyue xu
| E304 Presentes
| C201 Présentes
| C201Présentes
| C201Présentes
| E304&C201
| E304
| 
| 
| 
| 
| 
| 
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Martin Rohmer / Kévin Godesence
| E306 
| E303 Présents
| E301 Présents
| E305
| E303
| E305
| E305
| 
| 
| 
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Robin Cavalieri / Edmur Lopes
| E305 
| E305 Présents
| E305Présents
| E305
| E305
| E305
| E305
| E305
| 
| 
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Cedric Roussel / Thomas Stievenard
| 
| E303 Présents
| Présents
| E305
| E303
| E305
| E305
| 
| 
| 
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Mame Arame Diop / Amina Fahem
| 
| E303 Présentes
| E304 Présents
| E304
| E304
| E304
| E306
| E304
| 
| 
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Antoine Arnaudet / Vivian Senaffe
| E304 
| E305 Arnaudet présent Senaffe absent
| E304
| E304Présents
| E304
| E304
| E304
| E304
| 
| 
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Butaye Marianne / François Duport
| E304 
| E304 Présents
| E303 Présents
| E305
| E305
| E305
| E305
| E306
| 
| 
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Samy Belhouachi / François Xavier Cockenpot
| 
| E305 Présents
| E301 Présents
| E305 
| E303 et E305
| E303 et E305
| E305
| E305
| 
| 
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Cheikh Said Ahmed / Khadija El Messnaoui
| 
| E305 Said-Ahmed présent El Messnaoui absente
| Présents
| E303 
| E305
| 
| 
| 
| 
| 
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Manlu Luo / Xinyi Wang
| E305 
| E304 Présentes
| E304 Présentes
| E304 
| E304 
| 
| 
| 
| 
| 
| 
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| Olivier Mahieux / Grillère Baptiste
| E306 
| E305 Présents
| Présents
| 
| 
| 
| 
| 
| 
| 
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Rodolphe Toin
| E305 
| E305 Présent
| E305/301 Présents
| E305 
| E305 
| E305 
| E305 
| E305 
| 
| 
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| | E304 
| Rattrapage DS
| Abs
| Malade
| Malade
| Malade
| E303
| E303
| E303
| 
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Thomas Gosse / Bacem Hagui
| 
| E304 Gosse présent Hagui absent
| Présents
| 
| 
| 
| 
| 
| 
| 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Tristan Hart / Etienne Profit
| 
| E304 Présents
| E304Présents
| E304
| E304
| E304
| E304
| 
| 
| 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Nicky Ung / Alexis Macherez
| E304 
| E304 Présents
| E304/301 Présents
| E305
| E304
| E304
| E304/C205
| 
| 
| 
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Oumaima Naanaa
| 
| Absente
| E301Présente
| E301
| E301
| E306
| E306 C205
| E306 C205
| 
| 
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Alice Coffin / Diana Marrucho
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Lutecia Damiens / Alexis Dorian
| E306 
| E303 Présents
| E303 Présents
| Fabricarium
| E303
| E306
| E306
| E306
| 
| 
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Hugo Delatte
| 
| E304 Présents
| E304 
| E304 Présents
| 
| 
| 
| 
| 
| 
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Loïc Tombazzi / Marius Trimbur
| E304 
| E303 Présents
| E303 Présents
| E304 
| E303 
| E304 
| E304 
| E303 
| 
| 
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Marouan Mcharfi / Tristan lopez
| E304 
| E304 Présents
| E304 Présents
| E304 
| E304 
| E304 
| E304 
| 
| 
| 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Alexandre Huet / François Lefevre
| E306
| E306 Présents
| E304 Présents
| E304
| E304
| E304
| E304
| E304
| 
| 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Djamil Mohamed / Hamza Kerroum
| C305/D306A 
| C305/D306A Présents
| C305/D306A Présents
| C305/D306A 
| C305/D306A 
| C305/D306A 
| C305/D306A 
| C305/D306A 
| 
| 
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Jean-Baptiste Saison
| C305/D306A 
| C305/D306A Présent
| D306A Présent
| D306A/C305 
| D306A/D322 
| D306A/D322 
| D306A 
| D306A 
| 
| 
|}

IMA4 2016/2017 P33

2017-03-13T14:12:47Z

Onaanaa : /* Semaine 5 */

IMA4 2016/2017 P33

2017-03-13T14:07:11Z

Onaanaa : /* Semaine 5 */

Fichier:Mont3.jpg

2017-03-13T14:06:43Z

Onaanaa :

IMA4 2016/2017 P33

2017-03-13T14:02:05Z

Onaanaa : /* Semaine 5 */

IMA4 2016/2017 P33

2017-03-13T14:00:48Z

Onaanaa : /* Semaine 5 */

IMA4 2016/2017 P33

2017-03-13T13:59:39Z

Onaanaa : /* Semaine 5 */

Fichier:Mntg3.jpg

2017-03-13T13:57:28Z

Onaanaa :