wiki-se.plil.fr - Contributions [fr]

SE5 ECEAI 2024/2025/elhasnaoui-chaouni

2025-01-30T15:32:34Z

Achaouni : /* Conclusion */

=<div class="mcwiki-header" style="padding: 10px; font-family: 'Times New Roman' ; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 100%; background: #808080; vertical-align: top; height:70%; width: 98%;"> Introduction </div>=
==Objectifs du projet==
Séance 1 (03/09) : Lors de la première séance, nous avons entamé une réflexion sur les différentes idées de projets que nous pourrions développer en utilisant notre carte STM32, pour explorer les possibilités offertes par la carte, en considérant des applications potentielles dans divers domaines, tels que l'automatisation, la reconnaissance de formes ou le contrôle intelligent de systèmes. Ces premières discussions nous ont permis de poser les bases de projets innovants, alignés sur nos objectifs d'apprentissage et les capacités techniques de la STM32.

Par ailleurs, nous avons également configuré notre environnement de travail en installant les logiciels nécessaires, à savoir NanoEdge AI et STM32, afin de pouvoir commencer le développement de nos projets de manière efficace.

=<div class="mcwiki-header" style="padding: 10px; font-family: 'Times New Roman' ; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 100%; background: #808080; vertical-align: top; height:70%; width: 98%;"> Configuration Réseau </div>=
==Configuration serveur Cloud==

Nous allons créer une machine virtuelle sur Capbreton avec un accès internet IPv6. <br>
Cette machine virtuelle sera déployée grâce à Xen (Hyperviseur) et portera le nom "SE5-elhaschaouni".<br>
La commande lancée pour créer cette machine est la suivante :
<syntaxhighlight lang="bash">
xen-create-image --hostname SE5-elhaschaouni --force --dist bookworm --size 10G --memory 1G --dir /usr/local/xen --dhcp --bridge bridgeStudents
</syntaxhighlight>

===Configuration Réseau===

Nous devrons ensuite configurer son réseau, sa résolution DNS, et ses sources de paquets Debian.<br>
Pour configurer le réseau de notre machine, nous allons modifier le fichier ''/etc/network/interfaces'' qui est un fichier de configuration réseau où sont spécifiés les paramètres de l'interface.
<syntaxhighlight lang="bash">
auto eth0
iface eth0 inet6 auto
</syntaxhighlight>

===Configuration DNS===

Pour configurer la résolution DNS de notre machine, nous allons modifier le fichier ''/etc/resolv.conf''. Ce fichier permet de spécifier la configuration des serveurs de nom (DNS) afin de résoudre les noms de domaine en adresses IP. Voici la configuration DNS à appliquer :
<syntaxhighlight lang="bash">
domain plil.info
search plil.info
nameserver 2a01:c916:2047:c800:216:3eff:fe82:8a5c
</syntaxhighlight>

==Configuration Microcontrôleur SMT32==

=<div class="mcwiki-header" style="padding: 10px; font-family: 'Times New Roman' ; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 100%; background: #808080; vertical-align: top; height:70%; width: 98%;"> Communication des objets </div>=
==Communication RaspberryPi & Serveur Cloud ==

La communication entre la Raspberry Pi et le serveur Cloud se fait en utilisant le protocole '''MQTT'''. Le serveur Cloud est une machine virtuelle (VM) dans le même sous-réseau que la Raspberry Pi. Nous avons configuré le serveur '''MQTT''' en utilisant un '''Dockerfile''' pour créer et déployer le '''conteneur Docker''' sur le serveur Cloud. Nous avons également développé deux scripts Python pour gérer la communication : '''subscriber.py''' pour le serveur Cloud et '''publisher.py''' pour la Raspberry Pi.

===Déploiement du Serveur MQTT===
Nous avons créé un Dockerfile pour configurer Mosquitto.<syntaxhighlight lang="bash">
# Utiliser l'image de base de Mosquitto
FROM eclipse-mosquitto:latest
# Fichier de configuration
COPY mosquitto.conf /mosquitto/config/mosquitto.conf
# Exposer le port 1883 pour MQTT
EXPOSE 1883
EXPOSE 9001
</syntaxhighlight>

Nous avons construit l'image Docker à partir du Dockerfile avec la commande suivante :<syntaxhighlight lang="bash">
docker build -t mosquitto-mqtt .
</syntaxhighlight>Puis, nous avons lancé le conteneur Mosquitto avec la commande :<syntaxhighlight lang="bash">
docker run -d --name mosquitto -p 1883:1883 -p 9001:9001 mosquitto-mqtt
</syntaxhighlight>Cette commande démarre Mosquitto en arrière-plan (-d) et mappe le port '''1883''' du conteneur au port '''1883''' de l'hôte (RasberryPI), qui est le port par défaut utilisé par '''MQTT'''.

=== REST-API Flask ===
Nous avons développé un serveur HTTP avec Flask pour récupérer et afficher les données reçues via MQTT. Ce serveur permet à la Raspberry Pi de communiquer avec le serveur Cloud en temps réel, affichant les messages publiés sous une forme interactive. L'interface utilisateur de Flask permet de visualiser facilement les informations, facilitant ainsi la surveillance et l'analyse des données.<syntaxhighlight lang="python3">
from flask import Flask, render_template
from flask_socketio import SocketIO
import paho.mqtt.client as mqtt

app = Flask(__name__)
socketio = SocketIO(app)

# MQTT configuration, BROKER : Serveur MQTT (RaspberryPi)
mqtt_broker = 'IP_ADDRESS_RASPBERRYPI'
# TOPIC : Messages queue
mqtt_topic = 'default/topic'

# Callback when a message is received from MQTT
def on_message(client, userdata, message):
msg = message.payload.decode()
print(f'Received message: {msg} on topic {message.topic}')
socketio.emit('mqtt_message', {'message': msg, 'topic': message.topic})

mqtt_client = mqtt.Client()
mqtt_client.on_message = on_message
mqtt_client.connect(mqtt_broker)
mqtt_client.subscribe(mqtt_topic)
mqtt_client.loop_start()

# The index.html file contains the page HTML to show the data received over MQTT
# We have only one ENDPOIT (Route) GET / : Returns the html page
# To access the page go to : https://VM_IP:5000
@app.route('/')
def index():
return render_template('index.html')

if __name__ == '__main__':
socketio.run(app, debug=True)

</syntaxhighlight>

==Communication STM32 & RaspberryPi==
La Raspberry Pi recevra les données envoyées par le STM32 via le port série. Ensuite, la Raspberry Pi servira de broker MQTT, transmettant ces données au serveur Cloud pour un traitement et affichage. Cette configuration permet de centraliser les données collectées par le STM32 et de les envoyer de manière sécurisée et efficace vers le Cloud (Machine virtuelle) via MQTT.

= <div class="mcwiki-header" style="padding: 10px; font-family: 'Times New Roman' ; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 100%; background: #808080; vertical-align: top; height:70%; width: 98%;"> Entraînement du modèle d’apprentissage </div>Entraînement sur Microcontrôleur NUCLEO =
L'idée sera de développer un système capable de détecter et de reconnaître les chiffres de 0 à 5, représentés par les positions des doigts de la main.

Pour cela, nous utilisons la carte '''NUCLEO-F401RE''' associée au capteur de distance '''X-NUCLEO-53L5A1''', ainsi que '''NanoEdge AI Studio''' pour l'entraînement et le déploiement d'un modèle d'apprentissage automatique.

Les étapes principales du projet sont :

=== '''Collect Dataset''' ===
[[Fichier:WhatsApp Image 2025-01-09 at 15.22.17.jpg|vignette|388x388px|Collecte des donnés pour la classe "1"]]
Les chiffres de 0 à 5 ont été associés à des configurations spécifiques des doigts :
{| class="wikitable sortable"
|+
!Number
!Position des doigts
!'''Class'''
|-
|0
|Poing fermé.
|'''Class-0'''
|-
|1
|Seul l'index levé.
|'''Class-1'''
|-
|2
|Index et majeur levés.
|'''Class-2'''
|-
|3
|Index, majeur et annulaire levés.
|'''Class-3'''
|-
|4
|Tous les doigts sauf le pouce levés.
|'''Class-4'''
|-
|5
|Main entièrement ouverte.
|'''Class-5'''
|}

Pour améliorer la précision et la robustesse du modèle, nous avons adopté une stratégie consistant à capturer plusieurs positions de la main pour chaque chiffre.

On a collecté 15 lignes de données pour chaque signal (Chiffre) de '''0''' à '''5'''.

=== Réalisation de Benchmark ===
[[Fichier:WhatsApp Image 2025-01-09 at 15.46.45.jpg|vignette|393x393px|Score Benchmarks réalisés]]
Nous avons réalisé plusieurs séries de benchmarks en utilisant différents datasets afin de maximiser les performances et la fiabilité de notre modèle. Chaque test a permis d'évaluer l'impact des variations de données sur l'accuracy, la consommation de ressources (RAM et Flash), et le temps d'exécution.

Après plusieurs itérations, nous avons obtenu un score final de '''82,84 %''', avec une précision équilibrée de '''86,94 %''' (variation minimale de 83,33 % et maximale de 90,28 %, avec un écart-type de 2,87 %).

Ce résultat indique que le modèle est bien optimisé pour reconnaître les différentes configurations de doigts tout en restant adapté aux contraintes matérielles, avec une utilisation de '''29,9 KB de RAM''' et '''62 KB de Flash''', et un temps d'exécution de seulement '''11,4 ms''' sur un microcontrôleur STM32F411 cadencé à '''84 MHz'''.

=== Validation du Modèle ===
Pour valider le modèle, une phase de test en temps réel a été mise en place. Les données étaient collectées en continu à partir du capteur '''X-NUCLEO-53L5A1''', et chaque configuration de main (chiffres de 0 à 5) était analysée par le modèle embarqué sur la carte '''NUCLEO-F401RE'''. Les prédictions générées par le modèle étaient affichées instantanément sur un terminal série, permettant de visualiser en temps réel le chiffre détecté.

Cette étape a permis de vérifier la robustesse du modèle dans des conditions réelles. Nous avons évalué sa capacité à prédire avec précision les chiffres malgré des variations d'angles, de distances ou d’éclairage. Les résultats ont confirmé que le modèle pouvait maintenir une précision élevée et une réactivité satisfaisante, validant ainsi son utilisation pour l’application embarquée.
[[Fichier:WhatsApp Video 2025-01-09 at 16.22.02.mp4|vignette|Démonstration validation du modèle|centré|0x0px]]
=== Déploiement du modèle ===
Après la phase de validation, le modèle a été déployé sur la carte NUCLEO-F401RE.

Le modèle entraîné dans NanoEdge AI Studio a été exporté sous forme de bibliothèque C optimisée pour l'embarqué. Ensuite, il a été intégré dans un projet STM32 en utilisant <code>STM32CubeIDE</code>, qui permet de convertir et d'optimiser le modèle pour une exécution efficace sur le microcontrôleur.

Une fois le modèle converti, il a été inclus dans le firmware de la carte NUCLEO-F401RE. L’architecture globale du code est la suivante : <syntaxhighlight lang="c" line="1">
#include "stm32f4xx_hal.h"
#include "vl53l5cx_api.h"
#include "NanoEdgeAI.h"

VL53L5CX_Configuration sensor_config;

int main(void) {
HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
MX_I2C1_Init();

// Initialize the VL53L5CX sensor
if (vl53l5cx_init(&sensor_config) != 0) {
Error_Handler();
}
printf("VL53L5CX Initialized.\n");

// Initialize NanoEdge AI
int error = nanoEdgeAI_initialize();
if (error != 0) {
printf("NanoEdge AI Initialization failed: %d\n", error);
Error_Handler();
}
printf("NanoEdge AI Initialized.\n");

// Measurement loop
VL53L5CX_ResultsData results;
while (1) {
if (vl53l5cx_get_ranging_data(&sensor_config, &results) == 0) {
float input_features[] = { "Class-0", "Class-1", "Class-2", "Class-3", "Class-4", "Class-5" };

// Run inference
int gesture_id = nanoEdgeAI_classification(input_features);
printf("Value predicted: %d\n", gesture_id);
}
HAL_Delay(100);
}
}

</syntaxhighlight>[[Fichier:Capture d’écran 2025-01-10 à 22.56.28.png|alt=Visualisation du modèle|vignette|408x408px|Visualisation du modèle]]Enfin, une communication '''MQTT''' a été mise en place afin de transmettre les résultats de détection à un serveur distant. Une fois le chiffre prédit par le modèle embarqué, il est envoyé vers

un module de communication réseau, qui publie les données sur un broker '''MQTT.'''

=== Visualisation ===
Nous visualisons les résultats du modèle d'IA en temps réel grâce à la communication '''MQTT'''. Cette visualisation permet de suivre l’efficacité du modèle, d’évaluer les performances et de détecter d’éventuelles anomalies dans les configurations de main, garantissant ainsi une interface utilisateur claire et dynamique.

Les données sont envoyées dans le topic '''default/topic.'''
[[Fichier:Enregistrement de l’écran 2025-01-10 à 22.59.22.mov|alt=Visualisation du Modèle - Video Démonstration|vignette|Visualisation du Modèle - Video Démonstration|centré]]

= Conclusion =
Ce projet a démontré la faisabilité de la reconnaissance des chiffres '''0 à 5''' via un système embarqué combinant la carte '''NUCLEO-F401RE''', le capteur '''X-NUCLEO-53L5A1''' et un modèle avec '''NanoEdge AI Studio'''.

Au cours de cette réalisation, nous avons acquis des compétences clés en '''traitement des données capteurs''', '''entraînement et optimisation de modèles embarqués''', ainsi qu'en '''déploiement sur microcontrôleur''' avec '''STM32Cube'''.

L'intégration de la communication '''MQTT''' nous a également permis d’approfondir la transmission des données dans un environnement '''IoT''', renforçant ainsi notre expertise en systèmes intelligents embarqués.

SE5 ECEAI 2024/2025/elhasnaoui-chaouni

2025-01-30T15:31:27Z

Achaouni : /* Conclusion */

SE5 ECEAI 2024/2025/elhasnaoui-chaouni

2025-01-30T15:31:11Z

Achaouni : /* Déploiement du modèle */

SE5 ECEAI 2024/2025/elhasnaoui-chaouni

2025-01-30T15:27:57Z

Achaouni : /* Déploiement du modèle */

SE5 ECEAI 2024/2025/elhasnaoui-chaouni

2025-01-30T15:25:46Z

Achaouni : /* Déploiement du modèle */

=<div class="mcwiki-header" style="padding: 10px; font-family: 'Times New Roman' ; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 100%; background: #808080; vertical-align: top; height:70%; width: 98%;"> Introduction </div>=
==Objectifs du projet==
Séance 1 (03/09) : Lors de la première séance, nous avons entamé une réflexion sur les différentes idées de projets que nous pourrions développer en utilisant notre carte STM32, pour explorer les possibilités offertes par la carte, en considérant des applications potentielles dans divers domaines, tels que l'automatisation, la reconnaissance de formes ou le contrôle intelligent de systèmes. Ces premières discussions nous ont permis de poser les bases de projets innovants, alignés sur nos objectifs d'apprentissage et les capacités techniques de la STM32.

Par ailleurs, nous avons également configuré notre environnement de travail en installant les logiciels nécessaires, à savoir NanoEdge AI et STM32, afin de pouvoir commencer le développement de nos projets de manière efficace.

=<div class="mcwiki-header" style="padding: 10px; font-family: 'Times New Roman' ; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 100%; background: #808080; vertical-align: top; height:70%; width: 98%;"> Configuration Réseau </div>=
==Configuration serveur Cloud==

Nous allons créer une machine virtuelle sur Capbreton avec un accès internet IPv6. <br>
Cette machine virtuelle sera déployée grâce à Xen (Hyperviseur) et portera le nom "SE5-elhaschaouni".<br>
La commande lancée pour créer cette machine est la suivante :
<syntaxhighlight lang="bash">
xen-create-image --hostname SE5-elhaschaouni --force --dist bookworm --size 10G --memory 1G --dir /usr/local/xen --dhcp --bridge bridgeStudents
</syntaxhighlight>

===Configuration Réseau===

Nous devrons ensuite configurer son réseau, sa résolution DNS, et ses sources de paquets Debian.<br>
Pour configurer le réseau de notre machine, nous allons modifier le fichier ''/etc/network/interfaces'' qui est un fichier de configuration réseau où sont spécifiés les paramètres de l'interface.
<syntaxhighlight lang="bash">
auto eth0
iface eth0 inet6 auto
</syntaxhighlight>

===Configuration DNS===

Pour configurer la résolution DNS de notre machine, nous allons modifier le fichier ''/etc/resolv.conf''. Ce fichier permet de spécifier la configuration des serveurs de nom (DNS) afin de résoudre les noms de domaine en adresses IP. Voici la configuration DNS à appliquer :
<syntaxhighlight lang="bash">
domain plil.info
search plil.info
nameserver 2a01:c916:2047:c800:216:3eff:fe82:8a5c
</syntaxhighlight>

==Configuration Microcontrôleur SMT32==

=<div class="mcwiki-header" style="padding: 10px; font-family: 'Times New Roman' ; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 100%; background: #808080; vertical-align: top; height:70%; width: 98%;"> Communication des objets </div>=
==Communication RaspberryPi & Serveur Cloud ==

La communication entre la Raspberry Pi et le serveur Cloud se fait en utilisant le protocole '''MQTT'''. Le serveur Cloud est une machine virtuelle (VM) dans le même sous-réseau que la Raspberry Pi. Nous avons configuré le serveur '''MQTT''' en utilisant un '''Dockerfile''' pour créer et déployer le '''conteneur Docker''' sur le serveur Cloud. Nous avons également développé deux scripts Python pour gérer la communication : '''subscriber.py''' pour le serveur Cloud et '''publisher.py''' pour la Raspberry Pi.

===Déploiement du Serveur MQTT===
Nous avons créé un Dockerfile pour configurer Mosquitto.<syntaxhighlight lang="bash">
# Utiliser l'image de base de Mosquitto
FROM eclipse-mosquitto:latest
# Fichier de configuration
COPY mosquitto.conf /mosquitto/config/mosquitto.conf
# Exposer le port 1883 pour MQTT
EXPOSE 1883
EXPOSE 9001
</syntaxhighlight>

Nous avons construit l'image Docker à partir du Dockerfile avec la commande suivante :<syntaxhighlight lang="bash">
docker build -t mosquitto-mqtt .
</syntaxhighlight>Puis, nous avons lancé le conteneur Mosquitto avec la commande :<syntaxhighlight lang="bash">
docker run -d --name mosquitto -p 1883:1883 -p 9001:9001 mosquitto-mqtt
</syntaxhighlight>Cette commande démarre Mosquitto en arrière-plan (-d) et mappe le port '''1883''' du conteneur au port '''1883''' de l'hôte (RasberryPI), qui est le port par défaut utilisé par '''MQTT'''.

=== REST-API Flask ===
Nous avons développé un serveur HTTP avec Flask pour récupérer et afficher les données reçues via MQTT. Ce serveur permet à la Raspberry Pi de communiquer avec le serveur Cloud en temps réel, affichant les messages publiés sous une forme interactive. L'interface utilisateur de Flask permet de visualiser facilement les informations, facilitant ainsi la surveillance et l'analyse des données.<syntaxhighlight lang="python3">
from flask import Flask, render_template
from flask_socketio import SocketIO
import paho.mqtt.client as mqtt

app = Flask(__name__)
socketio = SocketIO(app)

# MQTT configuration, BROKER : Serveur MQTT (RaspberryPi)
mqtt_broker = 'IP_ADDRESS_RASPBERRYPI'
# TOPIC : Messages queue
mqtt_topic = 'default/topic'

# Callback when a message is received from MQTT
def on_message(client, userdata, message):
msg = message.payload.decode()
print(f'Received message: {msg} on topic {message.topic}')
socketio.emit('mqtt_message', {'message': msg, 'topic': message.topic})

mqtt_client = mqtt.Client()
mqtt_client.on_message = on_message
mqtt_client.connect(mqtt_broker)
mqtt_client.subscribe(mqtt_topic)
mqtt_client.loop_start()

# The index.html file contains the page HTML to show the data received over MQTT
# We have only one ENDPOIT (Route) GET / : Returns the html page
# To access the page go to : https://VM_IP:5000
@app.route('/')
def index():
return render_template('index.html')

if __name__ == '__main__':
socketio.run(app, debug=True)

</syntaxhighlight>

==Communication STM32 & RaspberryPi==
La Raspberry Pi recevra les données envoyées par le STM32 via le port série. Ensuite, la Raspberry Pi servira de broker MQTT, transmettant ces données au serveur Cloud pour un traitement et affichage. Cette configuration permet de centraliser les données collectées par le STM32 et de les envoyer de manière sécurisée et efficace vers le Cloud (Machine virtuelle) via MQTT.

= <div class="mcwiki-header" style="padding: 10px; font-family: 'Times New Roman' ; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 100%; background: #808080; vertical-align: top; height:70%; width: 98%;"> Entraînement du modèle d’apprentissage </div>Entraînement sur Microcontrôleur NUCLEO =
L'idée sera de développer un système capable de détecter et de reconnaître les chiffres de 0 à 5, représentés par les positions des doigts de la main.

Pour cela, nous utilisons la carte '''NUCLEO-F401RE''' associée au capteur de distance '''X-NUCLEO-53L5A1''', ainsi que '''NanoEdge AI Studio''' pour l'entraînement et le déploiement d'un modèle d'apprentissage automatique.

Les étapes principales du projet sont :

=== '''Collect Dataset''' ===
[[Fichier:WhatsApp Image 2025-01-09 at 15.22.17.jpg|vignette|388x388px|Collecte des donnés pour la classe "1"]]
Les chiffres de 0 à 5 ont été associés à des configurations spécifiques des doigts :
{| class="wikitable sortable"
|+
!Number
!Position des doigts
!'''Class'''
|-
|0
|Poing fermé.
|'''Class-0'''
|-
|1
|Seul l'index levé.
|'''Class-1'''
|-
|2
|Index et majeur levés.
|'''Class-2'''
|-
|3
|Index, majeur et annulaire levés.
|'''Class-3'''
|-
|4
|Tous les doigts sauf le pouce levés.
|'''Class-4'''
|-
|5
|Main entièrement ouverte.
|'''Class-5'''
|}

Pour améliorer la précision et la robustesse du modèle, nous avons adopté une stratégie consistant à capturer plusieurs positions de la main pour chaque chiffre.

On a collecté 15 lignes de données pour chaque signal (Chiffre) de '''0''' à '''5'''.

=== Réalisation de Benchmark ===
[[Fichier:WhatsApp Image 2025-01-09 at 15.46.45.jpg|vignette|393x393px|Score Benchmarks réalisés]]
Nous avons réalisé plusieurs séries de benchmarks en utilisant différents datasets afin de maximiser les performances et la fiabilité de notre modèle. Chaque test a permis d'évaluer l'impact des variations de données sur l'accuracy, la consommation de ressources (RAM et Flash), et le temps d'exécution.

Après plusieurs itérations, nous avons obtenu un score final de '''82,84 %''', avec une précision équilibrée de '''86,94 %''' (variation minimale de 83,33 % et maximale de 90,28 %, avec un écart-type de 2,87 %).

Ce résultat indique que le modèle est bien optimisé pour reconnaître les différentes configurations de doigts tout en restant adapté aux contraintes matérielles, avec une utilisation de '''29,9 KB de RAM''' et '''62 KB de Flash''', et un temps d'exécution de seulement '''11,4 ms''' sur un microcontrôleur STM32F411 cadencé à '''84 MHz'''.

=== Validation du Modèle ===
Pour valider le modèle, une phase de test en temps réel a été mise en place. Les données étaient collectées en continu à partir du capteur '''X-NUCLEO-53L5A1''', et chaque configuration de main (chiffres de 0 à 5) était analysée par le modèle embarqué sur la carte '''NUCLEO-F401RE'''. Les prédictions générées par le modèle étaient affichées instantanément sur un terminal série, permettant de visualiser en temps réel le chiffre détecté.

Cette étape a permis de vérifier la robustesse du modèle dans des conditions réelles. Nous avons évalué sa capacité à prédire avec précision les chiffres malgré des variations d'angles, de distances ou d’éclairage. Les résultats ont confirmé que le modèle pouvait maintenir une précision élevée et une réactivité satisfaisante, validant ainsi son utilisation pour l’application embarquée.
[[Fichier:WhatsApp Video 2025-01-09 at 16.22.02.mp4|vignette|Démonstration validation du modèle|centré|0x0px]]
=== Déploiement du modèle ===
Après la phase de validation, le modèle a été déployé sur la carte NUCLEO-F401RE.

Le modèle entraîné dans NanoEdge AI Studio a été exporté sous forme de bibliothèque C optimisée pour l'embarqué. Ensuite, il a été intégré dans un projet STM32 en utilisant <code>STM32CubeIDE</code>, qui permet de convertir et d'optimiser le modèle pour une exécution efficace sur le microcontrôleur.

Une fois le modèle converti, il a été inclus dans le firmware de la carte NUCLEO-F401RE. L’architecture globale du code est la suivante : <syntaxhighlight lang="c" line="1">
#include "stm32f4xx_hal.h"
#include "vl53l5cx_api.h"
#include "NanoEdgeAI.h"

VL53L5CX_Configuration sensor_config;

int main(void) {
HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
MX_I2C1_Init();

// Initialize the VL53L5CX sensor
if (vl53l5cx_init(&sensor_config) != 0) {
Error_Handler();
}
printf("VL53L5CX Initialized.\n");

// Initialize NanoEdge AI
int error = nanoEdgeAI_initialize();
if (error != 0) {
printf("NanoEdge AI Initialization failed: %d\n", error);
Error_Handler();
}
printf("NanoEdge AI Initialized.\n");

// Measurement loop
VL53L5CX_ResultsData results;
while (1) {
if (vl53l5cx_get_ranging_data(&sensor_config, &results) == 0) {
float input_features[] = { 0, 1, 2, 3, 4, 5 };

// Run inference
int gesture_id = nanoEdgeAI_classification(input_features);
printf("Value predicted: %d\n", gesture_id);
}
HAL_Delay(100);
}
}

</syntaxhighlight>[[Fichier:Capture d’écran 2025-01-10 à 22.56.28.png|alt=Visualisation du modèle|vignette|408x408px|Visualisation du modèle]]Enfin, une communication '''MQTT''' a été mise en place afin de transmettre les résultats de détection à un serveur distant. Une fois le chiffre prédit par le modèle embarqué, il est envoyé vers

un module de communication réseau, qui publie les données sur un broker '''MQTT.'''

=== Visualisation ===
Nous visualisons les résultats du modèle d'IA en temps réel grâce à la communication '''MQTT'''. Cette visualisation permet de suivre l’efficacité du modèle, d’évaluer les performances et de détecter d’éventuelles anomalies dans les configurations de main, garantissant ainsi une interface utilisateur claire et dynamique.

Les données sont envoyées dans le topic '''default/topic.'''
[[Fichier:Enregistrement de l’écran 2025-01-10 à 22.59.22.mov|alt=Visualisation du Modèle - Video Démonstration|vignette|Visualisation du Modèle - Video Démonstration|centré]]

SE5 IdO sécurité des objets 2024/2025 b3

2025-01-08T13:07:37Z

Achaouni : /* Craquage TempTale Ultra Temperature Sensor */

== Sécurisation WiFi par WPA2-EAP ==
'''''<u>Séance (25/09) :</u>'''''

* '''<u>Serveur virtuel</u>'''

Nous avons créé une MV sous le nom de '''SE5-elhaschaouni''' sur Capbreton en utilisant l'hyperviseur <code>xen</code>. (voir mdp : <code>cat /var/log/xen-tools/SE5-elhaschaouni.log</code>)

Cette dernière a 2 interfaces, avec l'adresse IP <code>172.26.145.103</code> sous eth0 et <code>172.26.3.103</code> sous eth1 dans le <code>VLAN 403</code>.

Pour cela, les interfaces <code>VLAN403</code> et <code>br403</code> ont été configurées sur capbreton (''voir /etc/network/interfaces.d'')

* '''<u>Point d'accés WiFi</u>'''

Nous avons fait la première configuration via console du point d'accès Cisco, notamment la configuration du SSH pour que les autres binômes puissent se connecter à la borne via SSH.

Par la suite, on a configuré notre SSID '''VM_binome_3''' pour qu'il utilise le <code>VLAN403</code> puis on l'a sécurisé avec '''WPA2-EAP'''.

Mascarade : Implementée avec succés (''Problème du chain "DROP" corrigé le 21/09'').

FreeRadius : Fonctionnel en '''PEAP-MSCHAPv2''' (2 utilisateurs disponibles).

DNS : Configuré avec bind9.

Serveur DHCP : Configuré. Le "range" des adresses IP allant de <code>172.16.3.100</code> à <code>172.16.3.200</code>

Accès Internet : OUI (On peut regarder des vidéos sur youtube)

''<u>Utilisateurs existants (user : mdp):</u>''

bilal : glopglop

ayoub : glopglop

== Craquage TempTale Ultra Temperature Sensor ==
L'appareil TempTale Ultra est un enregistreur d'humidité et de température élégamment conçu avec USB intégré qui peut mesurer les températures ambiantes de -30°C à +70°C et l'humidité de 0% RH à 100% Rh (Rh). Cet appareil compact, simple ou polyvalent, crée automatiquement un fichier PDF sécurisé et un fichier de données cryptés sans avoir besoin de logiciels supplémentaires.

Il est simple d'accéder aux fichiers générés par TempTale Ultra :<syntaxhighlight lang="bash">
sudo mount /dev/sdb TempTaleUltra/
</syntaxhighlight>
[[Fichier:Carte TempTale.jpg|vignette|Carte TempTale après soudage|302x302px]]
Comme une première tentative, on a essayé de modifier directement les données dans les fichiers mais ces dernières sont protégées en lecture seule. Et le fichier TTV est crypté. La seule solution pour modifier les données est de retirer cette protection dans le firmware.

Après démontage de TempTale Ultra, on trouve que le MCU utilisé est : STM32L152RCT6.

D'après le Datasheet, on trouve les PINs SWDIO, SWDCLK, NRST et VDD qui nous permettent de reprogrammer le MCU à l'aide d'un ST-LINK et STM32CubeIDE.

Datasheet MCU [https://www.st.com/content/ccc/resource/technical/document/datasheet/2a/6e/97/91/cd/c0/43/8b/DM00048356.pdf/files/DM00048356.pdf/jcr:content/translations/en.DM00048356.pdf STM32L152RCT6].

'''''<u>Séances (21/10 + 22/10) :</u>'''''

On s'attaque au soudage des pins JTAG, pour cela il fallait bien identifier les 5 pins dont nous avons besoin, à savoir :

- 3.3V (câble bleu)

- GND (câble noir)

- SWDIO (câble blanc)

- SWCLK (câble gris)

- RESET (câble orange)

Nous avons revérifier ces connexions entre les sorties du MCU et les pins JTAG à l'aide d'un multimètre (continuité).

[[Fichier:Connexion L152-Nucleo.jpg|vignette|229x229px|Connexion L152-Nucleo]]
Ensuite, comme une deuxième tentative, nous avons essayé de la connecter en utilisant la carte <code>NUCLEO-FR401RE</code> comme intermédiaire via le canal CN4.
{| class="wikitable"
|+ST-Link Pins
!'''VDD'''
!'''CN4-1'''
|-
|'''GND'''
|'''CN4-3'''
|-
|'''SWDIO'''
|'''CN4-4'''
|-
|'''SWCLK'''
|'''CN4-2'''
|-
|'''RST'''
|'''CN4-5'''
|}

En alimentant que la carte <code>NUCLEO-FR401RE</code>, notre carte TempTale se trouve sans alimentation. Du coup, nous l'avons alimenté séparement via USB.

Par la suite, nous avons essayé de se connecter à la carte via le logiciel '''STM32 ST-LINK Utility.''' Cette fois-ci, on arrive à accéder à notre carte !
[[Fichier:Wiki-3.png|vignette|288x288px|Détection de la carte STM32L152]]
[[Fichier:Wiki-2.png|centré|vignette|420x420px|Successful connection to the target]]

== Craquage nedis WIFIDS20WT (Détecteur de fumée) ==

=== Connexion du dispositif au réseau via WIFI ===
[[Fichier:Connexion nedis via app.jpg|vignette|191x191px|Connexion nedis via app]]
Nous avons connecté notre détecteur de fumée <code>Nedis WIFIDS20WT</code> à l'application mobile Nedis en suivant les étapes simples de configuration. Après avoir installé l'application sur notre smartphone, nous avons activé le Wi-Fi et ajouté le détecteur au réseau. L'application permet également de surveiller l'état du détecteur et d'effectuer des tests à distance.

=== Analyse du trafic réseau ===
Dans un premier temps, nous avons tenté d'analyser le trafic réseau via <code>Wireshark</code> afin d’identifier des échanges spécifiques liés au protocole WPA2, notamment les trames EAPOL (Extensible Authentication Protocol Over LAN) échangées lors du 4-Way Handshake. En capturant ces trames, notre objectif était de surveiller les retransmissions qui pourraient indiquer une tentative de réinstallation de clé, point central de l’exploitation de la faille KRACK.

Nous avons essayé d'identifier l'adresse IP que le dispositif Nedis utilise sur le réseau (connexion partagée depuis notre smartphone). Pour ce faire, nous avons appliqué un filtre spécifique dans Wireshark, en utilisant l'adresse IP de notre smartphone personnel comme référence <code>172.20.10.2</code>[[Fichier:Analyse Wireshark.jpg|vignette|338x338px|1ère analyse Wireshark]]Ce filtre nous a permis de capturer uniquement les paquets ayant pour source notre smartphone, ce qui nous a aidés à repérer les échanges réseau dirigés vers le dispositif Nedis. En isolant ces paquets, nous avons pu mieux analyser les interactions spécifiques entre notre smartphone et le dispositif, et tenter de déterminer l'adresse IP assignée à ce dernier sur le réseau pour poursuivre les analyses liées à la vulnérabilité KRACK.

L'adresse IP la plus "suspecte" pour l'instant est <code>172.20.10.15</code> qu'on pense être celle du dispositif.

[[Fichier:IP+MAC.jpg|vignette|151x151px|Adresse IP + MAC du dispositif]]
---

Après plusieurs tentatives avec le réseau du téléphone, on arrive à obtenir la "bonne adresse IP" avec l'adresse MAC du dispositif mais ce dernier n'arrive pas à maintenir une connexion stable (comme affiché sur la capture d'écran ci-dessous).
[[Fichier:Tentatives de ping.png|centré|vignette|480x480px|Tentatives de ping]]

Nous avons alors décidé de changer de réseau et se connecter avec le Wifi <code>WIFI_IA_SE5</code>

On réalise un premier scan du réseau avec l'utilitaire <code>nmap</code> pour voir tous les appareils connectés avec leur adresse MAC correspondante, en espérant trouver notre dispositif connecté à ce réseau.

==== <u><big>Deuxième tentative</big></u> ====
[[Fichier:Capture d’écran 2024-12-11 à 14.59.01.png|vignette|345x345px|2ème analyse Wireshark]]
On réessaye de connecter le dispositif en utilisant le réseau de notre smartphone.

192.168.89.183 : Adresse IP du dispositif

192.168.89.186 : Adresse IP du PC effectuant l'analyse

On peut voir des paquets entre le PC et le dispositif, mais pas grand chose du côté serveur.

Étant donné que le smartphone joue le rôle d'un MITM, on arrive pas à capturer des paquets pertinents.

On retrouve en grande partie des paquets de communication entre le PC et le dispositif (comme affiché sur l'image ci-joint).

==== <u><big>Troisième tentative</big></u> ====
Cette fois-ci, on utilisera le réseau <code>PLIL</code> pour ne pas avoir notre smartphone comme étant MITM.
[[Fichier:3ème analyse Wireshark.jpg|vignette|3ème analyse Wireshark]]
D'après une analyse approfondie sur Wireshark, on arrive déjà à voir les paquets lors de la première connexion (requêtes <code>SYNC</code>) et d'autres paquets intéressants dès le démarrage du dispositif. Ceci n'était pas possible avant car il y avait le téléphone qui n'affichait pas en quelque sorte les paquets destinés directement au dispositif.

Pour cette manipulation, nous avons utilisé le réseau '''PLIL''' et tenté une attaque de type '''MITM'''. Plusieurs simulations de fumée ont été réalisées afin d’observer le comportement du système ainsi que les paquets échangés entre le capteur, l’application '''NEDIS''' et d’autres adresses IP publiques.

Après plusieurs tentatives de simulation, nous avons pu identifier deux adresses IP publiques apparaissant systématiquement dans les communications :

Adresse IP : '''3.124.85.154''' ''':''' Cette adresse appartient à la plage des IP réservées pour AWS (Amazon Web Services).

Adresse IP : '''18.197.183.192 :''' Cette adresse appartient également à la plage des IP réservées pour AWS.

Nous avons vérifié ces deux adresses IP, et elles sont bien incluses dans les plages d’IP réservées pour AWS dans la région '''eu-central-1''' ( Francfort ).

Les deux IP adresses sont des Machines virtuelles EC2 hebergees dans la region '''eu-central-1''' ( Francfort ).
[[Fichier:Analyse @IP1.jpg|alt=Analyse @IP1|vignette|Analyse de l'adresse 3.124.85.154|364x364px]]

===== Analyse Des serveurs CLOUD =====

Adresse IP : '''3.124.85.154 :''' Contient 3 ports ('''80''', '''443''' et '''7010''') qui sont ouverts et utilise principalement comme services HTTP/HTTPS. (Comme affiché sur les captures d'écran).

Adresse IP : '''18.197.183.192 :''' Contient également 3 ports ouverts, dont 1 qui utilise du '''MQTT''' sur le port '''1883''' et un autre en '''MQTT-S''' sur le port '''8883'''.
[[Fichier:Capture d’écran 2025-01-07 à 22.03.48.png|vignette|360x360px|Vérification IP adresses AWS]][[Fichier:Screenip18.jpg|vignette|Analyse de l'adresse 18.194.10.142|352x352px]]
===== Workflow Potentiel =====
'''Capteur ---> 18.197.183.192 :''' Le capteur envoie des données via MQTT/MQTTS. Cette instance EC2 pourrait également acheminer les messages vers d'autres services pour traitement ou visualisation.

'''Capteur ---> 3.124.85.154 :''' L'application mobile/Capteur communique avec le (API Gateway) serveur pour des opérations destinées à l'utilisateur, telles que la récupération de données stockées, l'envoi de commandes de contrôle au capteur ou la gestion des comptes d'utilisateurs.

===== Mock du serveur MQTT =====
L'idée sera de créer un '''<code>mock server</code>''' avec la même adresse IP, sur notre machine, et essayer de faire passer une communication de paquets via notre machine plutôt que passer par le serveur d'origine. Une fois ceci sera réalisé, nous pourrons commencer à craquer et manipuler le dispositif comme souhaité.

En analysant les paquets à destination de ce serveur, nous avons remarqué que la communication passe par le port 8883 qui nécessite le protocole MQTTS (ceci va nous poser un blocage car un certificat sera nécessaire par la suite).

On va essayer de falsifier la connection en configurant un nouveau serveur '''MQTT-S''' sur la zabeth17. On a généré un certificat en utilisant les commandes suivantes :<syntaxhighlight lang="bash">
openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -sha256 -days 365 -out ca.crt -subj "/C=US/ST=Newyork/L=Newyork/O=Nedis/CN=18.197.183.192"

openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr -subj "/C=US/ST=Newyork/L=Newyork/O=Nedis/CN=18.197.183.192"
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 365 -sha256

</syntaxhighlight>
[[Fichier:Mock certificats.png|vignette|352x352px|Mock certificats NEDIS|gauche]]
[[Fichier:Certs Config.png|vignette|353x353px|Configuration serveur MQTT/MQTT-S]]

SE5 IdO sécurité des objets 2024/2025 b3

2025-01-08T13:06:21Z

Achaouni : /* Mock du serveur MQTT */

== Sécurisation WiFi par WPA2-EAP ==
'''''<u>Séance (25/09) :</u>'''''

* '''<u>Serveur virtuel</u>'''

Nous avons créé une MV sous le nom de '''SE5-elhaschaouni''' sur Capbreton en utilisant l'hyperviseur <code>xen</code>. (voir mdp : <code>cat /var/log/xen-tools/SE5-elhaschaouni.log</code>)

Cette dernière a 2 interfaces, avec l'adresse IP <code>172.26.145.103</code> sous eth0 et <code>172.26.3.103</code> sous eth1 dans le <code>VLAN 403</code>.

Pour cela, les interfaces <code>VLAN403</code> et <code>br403</code> ont été configurées sur capbreton (''voir /etc/network/interfaces.d'')

* '''<u>Point d'accés WiFi</u>'''

Nous avons fait la première configuration via console du point d'accès Cisco, notamment la configuration du SSH pour que les autres binômes puissent se connecter à la borne via SSH.

Par la suite, on a configuré notre SSID '''VM_binome_3''' pour qu'il utilise le <code>VLAN403</code> puis on l'a sécurisé avec '''WPA2-EAP'''.

Mascarade : Implementée avec succés (''Problème du chain "DROP" corrigé le 21/09'').

FreeRadius : Fonctionnel en '''PEAP-MSCHAPv2''' (2 utilisateurs disponibles).

DNS : Configuré avec bind9.

Serveur DHCP : Configuré. Le "range" des adresses IP allant de <code>172.16.3.100</code> à <code>172.16.3.200</code>

Accès Internet : OUI (On peut regarder des vidéos sur youtube)

''<u>Utilisateurs existants (user : mdp):</u>''

bilal : glopglop

ayoub : glopglop

== Craquage TempTale Ultra Temperature Sensor ==
L'appareil TempTale Ultra est un enregistreur d'humidité et de température élégamment conçu avec USB intégré qui peut mesurer les températures ambiantes de -30°C à +70°C et l'humidité de 0% RH à 100% Rh (Rh). Cet appareil compact, simple ou polyvalent, crée automatiquement un fichier PDF sécurisé et un fichier de données cryptés sans avoir besoin de logiciels supplémentaires.

Il est simple d'accéder aux fichiers générés par TempTale Ultra :<syntaxhighlight lang="bash">
sudo mount /dev/sdb TempTaleUltra/
</syntaxhighlight>
[[Fichier:Carte TempTale.jpg|vignette|Carte TempTale après soudage|302x302px]]
Comme une première tentative, on a essayé de modifier directement les données dans les fichiers mais ces dernières sont protégées en lecture seule. Et le fichier TTV est crypté. La seule solution pour modifier les données est de retirer cette protection dans le firmware.

Après démontage de TempTale Ultra, on trouve que le MCU utilisé est : STM32L152RCT6.

D'après le Datasheet, on trouve les PINs SWDIO, SWDCLK, NRST et VDD qui nous permettent de reprogrammer le MCU à l'aide d'un ST-LINK et STM32CubeIDE.

Datasheet MCU [https://www.st.com/content/ccc/resource/technical/document/datasheet/2a/6e/97/91/cd/c0/43/8b/DM00048356.pdf/files/DM00048356.pdf/jcr:content/translations/en.DM00048356.pdf STM32L152RCT6].

'''''<u>Séances (21/10 + 22/10) :</u>'''''

On s'attaque au soudage des pins JTAG, pour cela il fallait bien identifier les 5 pins dont nous avons besoin, à savoir :

- 3.3V (câble bleu)

- GND (câble noir)

- SWDIO (câble blanc)

- SWCLK (câble gris)

- RESET (câble orange)

Nous avons revérifier ces connexions entre les sorties du MCU et les pins JTAG à l'aide d'un multimètre (continuité).

[[Fichier:Connexion L152-Nucleo.jpg|vignette|229x229px|Connexion L152-Nucleo]]
Ensuite, comme une deuxième tentative, nous avons essayé de la connecter en utilisant la carte <code>NUCLEO-FR401RE</code> comme intermédiaire via le canal CN4.
{| class="wikitable"
|+ST-Link Pins
!'''VDD'''
!'''CN4-1'''
|-
|'''GND'''
|'''CN4-3'''
|-
|'''SWDIO'''
|'''CN4-4'''
|-
|'''SWCLK'''
|'''CN4-2'''
|-
|'''RST'''
|'''CN4-5'''
|}

En alimentant que la carte <code>NUCLEO-FR401RE</code>, notre carte TempTale se trouve sans alimentation. Du coup, nous l'avons alimenté séparement via USB.

Par la suite, nous avons essayé de se connecter à la carte via le logiciel '''STM32 ST-LINK Utility.''' Cette fois-ci, on arrive à accéder à notre carte !
[[Fichier:Wiki-3.png|vignette|288x288px|Détection de la carte STM32L152]]
[[Fichier:Wiki-2.png|centré|vignette|420x420px|Successful connection to the target]]

[...]

== Craquage nedis WIFIDS20WT (Détecteur de fumée) ==

=== Connexion du dispositif au réseau via WIFI ===
[[Fichier:Connexion nedis via app.jpg|vignette|191x191px|Connexion nedis via app]]
Nous avons connecté notre détecteur de fumée <code>Nedis WIFIDS20WT</code> à l'application mobile Nedis en suivant les étapes simples de configuration. Après avoir installé l'application sur notre smartphone, nous avons activé le Wi-Fi et ajouté le détecteur au réseau. L'application permet également de surveiller l'état du détecteur et d'effectuer des tests à distance.

=== Analyse du trafic réseau ===
Dans un premier temps, nous avons tenté d'analyser le trafic réseau via <code>Wireshark</code> afin d’identifier des échanges spécifiques liés au protocole WPA2, notamment les trames EAPOL (Extensible Authentication Protocol Over LAN) échangées lors du 4-Way Handshake. En capturant ces trames, notre objectif était de surveiller les retransmissions qui pourraient indiquer une tentative de réinstallation de clé, point central de l’exploitation de la faille KRACK.

Nous avons essayé d'identifier l'adresse IP que le dispositif Nedis utilise sur le réseau (connexion partagée depuis notre smartphone). Pour ce faire, nous avons appliqué un filtre spécifique dans Wireshark, en utilisant l'adresse IP de notre smartphone personnel comme référence <code>172.20.10.2</code>[[Fichier:Analyse Wireshark.jpg|vignette|338x338px|1ère analyse Wireshark]]Ce filtre nous a permis de capturer uniquement les paquets ayant pour source notre smartphone, ce qui nous a aidés à repérer les échanges réseau dirigés vers le dispositif Nedis. En isolant ces paquets, nous avons pu mieux analyser les interactions spécifiques entre notre smartphone et le dispositif, et tenter de déterminer l'adresse IP assignée à ce dernier sur le réseau pour poursuivre les analyses liées à la vulnérabilité KRACK.

L'adresse IP la plus "suspecte" pour l'instant est <code>172.20.10.15</code> qu'on pense être celle du dispositif.

[[Fichier:IP+MAC.jpg|vignette|151x151px|Adresse IP + MAC du dispositif]]
---

Après plusieurs tentatives avec le réseau du téléphone, on arrive à obtenir la "bonne adresse IP" avec l'adresse MAC du dispositif mais ce dernier n'arrive pas à maintenir une connexion stable (comme affiché sur la capture d'écran ci-dessous).
[[Fichier:Tentatives de ping.png|centré|vignette|480x480px|Tentatives de ping]]

Nous avons alors décidé de changer de réseau et se connecter avec le Wifi <code>WIFI_IA_SE5</code>

On réalise un premier scan du réseau avec l'utilitaire <code>nmap</code> pour voir tous les appareils connectés avec leur adresse MAC correspondante, en espérant trouver notre dispositif connecté à ce réseau.

==== <u><big>Deuxième tentative</big></u> ====
[[Fichier:Capture d’écran 2024-12-11 à 14.59.01.png|vignette|345x345px|2ème analyse Wireshark]]
On réessaye de connecter le dispositif en utilisant le réseau de notre smartphone.

192.168.89.183 : Adresse IP du dispositif

192.168.89.186 : Adresse IP du PC effectuant l'analyse

On peut voir des paquets entre le PC et le dispositif, mais pas grand chose du côté serveur.

Étant donné que le smartphone joue le rôle d'un MITM, on arrive pas à capturer des paquets pertinents.

On retrouve en grande partie des paquets de communication entre le PC et le dispositif (comme affiché sur l'image ci-joint).

==== <u><big>Troisième tentative</big></u> ====
Cette fois-ci, on utilisera le réseau <code>PLIL</code> pour ne pas avoir notre smartphone comme étant MITM.
[[Fichier:3ème analyse Wireshark.jpg|vignette|3ème analyse Wireshark]]
D'après une analyse approfondie sur Wireshark, on arrive déjà à voir les paquets lors de la première connexion (requêtes <code>SYNC</code>) et d'autres paquets intéressants dès le démarrage du dispositif. Ceci n'était pas possible avant car il y avait le téléphone qui n'affichait pas en quelque sorte les paquets destinés directement au dispositif.

Pour cette manipulation, nous avons utilisé le réseau '''PLIL''' et tenté une attaque de type '''MITM'''. Plusieurs simulations de fumée ont été réalisées afin d’observer le comportement du système ainsi que les paquets échangés entre le capteur, l’application '''NEDIS''' et d’autres adresses IP publiques.

Après plusieurs tentatives de simulation, nous avons pu identifier deux adresses IP publiques apparaissant systématiquement dans les communications :

Adresse IP : '''3.124.85.154''' ''':''' Cette adresse appartient à la plage des IP réservées pour AWS (Amazon Web Services).

Adresse IP : '''18.197.183.192 :''' Cette adresse appartient également à la plage des IP réservées pour AWS.

Nous avons vérifié ces deux adresses IP, et elles sont bien incluses dans les plages d’IP réservées pour AWS dans la région '''eu-central-1''' ( Francfort ).

Les deux IP adresses sont des Machines virtuelles EC2 hebergees dans la region '''eu-central-1''' ( Francfort ).
[[Fichier:Analyse @IP1.jpg|alt=Analyse @IP1|vignette|Analyse de l'adresse 3.124.85.154|364x364px]]

===== Analyse Des serveurs CLOUD =====

Adresse IP : '''3.124.85.154 :''' Contient 3 ports ('''80''', '''443''' et '''7010''') qui sont ouverts et utilise principalement comme services HTTP/HTTPS. (Comme affiché sur les captures d'écran).

Adresse IP : '''18.197.183.192 :''' Contient également 3 ports ouverts, dont 1 qui utilise du '''MQTT''' sur le port '''1883''' et un autre en '''MQTT-S''' sur le port '''8883'''.
[[Fichier:Capture d’écran 2025-01-07 à 22.03.48.png|vignette|360x360px|Vérification IP adresses AWS]][[Fichier:Screenip18.jpg|vignette|Analyse de l'adresse 18.194.10.142|352x352px]]
===== Workflow Potentiel =====
'''Capteur ---> 18.197.183.192 :''' Le capteur envoie des données via MQTT/MQTTS. Cette instance EC2 pourrait également acheminer les messages vers d'autres services pour traitement ou visualisation.

'''Capteur ---> 3.124.85.154 :''' L'application mobile/Capteur communique avec le (API Gateway) serveur pour des opérations destinées à l'utilisateur, telles que la récupération de données stockées, l'envoi de commandes de contrôle au capteur ou la gestion des comptes d'utilisateurs.

===== Mock du serveur MQTT =====
L'idée sera de créer un '''<code>mock server</code>''' avec la même adresse IP, sur notre machine, et essayer de faire passer une communication de paquets via notre machine plutôt que passer par le serveur d'origine. Une fois ceci sera réalisé, nous pourrons commencer à craquer et manipuler le dispositif comme souhaité.

En analysant les paquets à destination de ce serveur, nous avons remarqué que la communication passe par le port 8883 qui nécessite le protocole MQTTS (ceci va nous poser un blocage car un certificat sera nécessaire par la suite).

On va essayer de falsifier la connection en configurant un nouveau serveur '''MQTT-S''' sur la zabeth17. On a généré un certificat en utilisant les commandes suivantes :<syntaxhighlight lang="bash">
openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -sha256 -days 365 -out ca.crt -subj "/C=US/ST=Newyork/L=Newyork/O=Nedis/CN=18.197.183.192"

openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr -subj "/C=US/ST=Newyork/L=Newyork/O=Nedis/CN=18.197.183.192"
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 365 -sha256

</syntaxhighlight>
[[Fichier:Mock certificats.png|vignette|352x352px|Mock certificats NEDIS|gauche]]
[[Fichier:Certs Config.png|vignette|353x353px|Configuration serveur MQTT/MQTT-S]]

SE5 IdO sécurité des objets 2024/2025 b3

2025-01-08T10:33:41Z

Achaouni : /* Mock du serveur MQTT */

== Sécurisation WiFi par WPA2-EAP ==
'''''<u>Séance (25/09) :</u>'''''

* '''<u>Serveur virtuel</u>'''

Nous avons créé une MV sous le nom de '''SE5-elhaschaouni''' sur Capbreton en utilisant l'hyperviseur <code>xen</code>. (voir mdp : <code>cat /var/log/xen-tools/SE5-elhaschaouni.log</code>)

Cette dernière a 2 interfaces, avec l'adresse IP <code>172.26.145.103</code> sous eth0 et <code>172.26.3.103</code> sous eth1 dans le <code>VLAN 403</code>.

Pour cela, les interfaces <code>VLAN403</code> et <code>br403</code> ont été configurées sur capbreton (''voir /etc/network/interfaces.d'')

* '''<u>Point d'accés WiFi</u>'''

Nous avons fait la première configuration via console du point d'accès Cisco, notamment la configuration du SSH pour que les autres binômes puissent se connecter à la borne via SSH.

Par la suite, on a configuré notre SSID '''VM_binome_3''' pour qu'il utilise le <code>VLAN403</code> puis on l'a sécurisé avec '''WPA2-EAP'''.

Mascarade : Implementée avec succés (''Problème du chain "DROP" corrigé le 21/09'').

FreeRadius : Fonctionnel en '''PEAP-MSCHAPv2''' (2 utilisateurs disponibles).

DNS : Configuré avec bind9.

Serveur DHCP : Configuré. Le "range" des adresses IP allant de <code>172.16.3.100</code> à <code>172.16.3.200</code>

Accès Internet : OUI (On peut regarder des vidéos sur youtube)

''<u>Utilisateurs existants (user : mdp):</u>''

bilal : glopglop

ayoub : glopglop

== Craquage TempTale Ultra Temperature Sensor ==
L'appareil TempTale Ultra est un enregistreur d'humidité et de température élégamment conçu avec USB intégré qui peut mesurer les températures ambiantes de -30°C à +70°C et l'humidité de 0% RH à 100% Rh (Rh). Cet appareil compact, simple ou polyvalent, crée automatiquement un fichier PDF sécurisé et un fichier de données cryptés sans avoir besoin de logiciels supplémentaires.

Il est simple d'accéder aux fichiers générés par TempTale Ultra :<syntaxhighlight lang="bash">
sudo mount /dev/sdb TempTaleUltra/
</syntaxhighlight>
[[Fichier:Carte TempTale.jpg|vignette|Carte TempTale après soudage|302x302px]]
Comme une première tentative, on a essayé de modifier directement les données dans les fichiers mais ces dernières sont protégées en lecture seule. Et le fichier TTV est crypté. La seule solution pour modifier les données est de retirer cette protection dans le firmware.

Après démontage de TempTale Ultra, on trouve que le MCU utilisé est : STM32L152RCT6.

D'après le Datasheet, on trouve les PINs SWDIO, SWDCLK, NRST et VDD qui nous permettent de reprogrammer le MCU à l'aide d'un ST-LINK et STM32CubeIDE.

Datasheet MCU [https://www.st.com/content/ccc/resource/technical/document/datasheet/2a/6e/97/91/cd/c0/43/8b/DM00048356.pdf/files/DM00048356.pdf/jcr:content/translations/en.DM00048356.pdf STM32L152RCT6].

'''''<u>Séances (21/10 + 22/10) :</u>'''''

On s'attaque au soudage des pins JTAG, pour cela il fallait bien identifier les 5 pins dont nous avons besoin, à savoir :

- 3.3V (câble bleu)

- GND (câble noir)

- SWDIO (câble blanc)

- SWCLK (câble gris)

- RESET (câble orange)

Nous avons revérifier ces connexions entre les sorties du MCU et les pins JTAG à l'aide d'un multimètre (continuité).

[[Fichier:Connexion L152-Nucleo.jpg|vignette|229x229px|Connexion L152-Nucleo]]
Ensuite, comme une deuxième tentative, nous avons essayé de la connecter en utilisant la carte <code>NUCLEO-FR401RE</code> comme intermédiaire via le canal CN4.
{| class="wikitable"
|+ST-Link Pins
!'''VDD'''
!'''CN4-1'''
|-
|'''GND'''
|'''CN4-3'''
|-
|'''SWDIO'''
|'''CN4-4'''
|-
|'''SWCLK'''
|'''CN4-2'''
|-
|'''RST'''
|'''CN4-5'''
|}

En alimentant que la carte <code>NUCLEO-FR401RE</code>, notre carte TempTale se trouve sans alimentation. Du coup, nous l'avons alimenté séparement via USB.

Par la suite, nous avons essayé de se connecter à la carte via le logiciel '''STM32 ST-LINK Utility.''' Cette fois-ci, on arrive à accéder à notre carte !
[[Fichier:Wiki-3.png|vignette|288x288px|Détection de la carte STM32L152]]
[[Fichier:Wiki-2.png|centré|vignette|420x420px|Successful connection to the target]]

[...]

== Craquage nedis WIFIDS20WT (Détecteur de fumée) ==

=== Connexion du dispositif au réseau via WIFI ===
[[Fichier:Connexion nedis via app.jpg|vignette|191x191px|Connexion nedis via app]]
Nous avons connecté notre détecteur de fumée <code>Nedis WIFIDS20WT</code> à l'application mobile Nedis en suivant les étapes simples de configuration. Après avoir installé l'application sur notre smartphone, nous avons activé le Wi-Fi et ajouté le détecteur au réseau. L'application permet également de surveiller l'état du détecteur et d'effectuer des tests à distance.

=== Analyse du trafic réseau ===
Dans un premier temps, nous avons tenté d'analyser le trafic réseau via <code>Wireshark</code> afin d’identifier des échanges spécifiques liés au protocole WPA2, notamment les trames EAPOL (Extensible Authentication Protocol Over LAN) échangées lors du 4-Way Handshake. En capturant ces trames, notre objectif était de surveiller les retransmissions qui pourraient indiquer une tentative de réinstallation de clé, point central de l’exploitation de la faille KRACK.

Nous avons essayé d'identifier l'adresse IP que le dispositif Nedis utilise sur le réseau (connexion partagée depuis notre smartphone). Pour ce faire, nous avons appliqué un filtre spécifique dans Wireshark, en utilisant l'adresse IP de notre smartphone personnel comme référence <code>172.20.10.2</code>[[Fichier:Analyse Wireshark.jpg|vignette|338x338px|1ère analyse Wireshark]]Ce filtre nous a permis de capturer uniquement les paquets ayant pour source notre smartphone, ce qui nous a aidés à repérer les échanges réseau dirigés vers le dispositif Nedis. En isolant ces paquets, nous avons pu mieux analyser les interactions spécifiques entre notre smartphone et le dispositif, et tenter de déterminer l'adresse IP assignée à ce dernier sur le réseau pour poursuivre les analyses liées à la vulnérabilité KRACK.

L'adresse IP la plus "suspecte" pour l'instant est <code>172.20.10.15</code> qu'on pense être celle du dispositif.

[[Fichier:IP+MAC.jpg|vignette|151x151px|Adresse IP + MAC du dispositif]]
---

Après plusieurs tentatives avec le réseau du téléphone, on arrive à obtenir la "bonne adresse IP" avec l'adresse MAC du dispositif mais ce dernier n'arrive pas à maintenir une connexion stable (comme affiché sur la capture d'écran ci-dessous).
[[Fichier:Tentatives de ping.png|centré|vignette|480x480px|Tentatives de ping]]

Nous avons alors décidé de changer de réseau et se connecter avec le Wifi <code>WIFI_IA_SE5</code>

On réalise un premier scan du réseau avec l'utilitaire <code>nmap</code> pour voir tous les appareils connectés avec leur adresse MAC correspondante, en espérant trouver notre dispositif connecté à ce réseau.

==== <u><big>Deuxième tentative</big></u> ====
[[Fichier:Capture d’écran 2024-12-11 à 14.59.01.png|vignette|345x345px|2ème analyse Wireshark]]
On réessaye de connecter le dispositif en utilisant le réseau de notre smartphone.

192.168.89.183 : Adresse IP du dispositif

192.168.89.186 : Adresse IP du PC effectuant l'analyse

On peut voir des paquets entre le PC et le dispositif, mais pas grand chose du côté serveur.

Étant donné que le smartphone joue le rôle d'un MITM, on arrive pas à capturer des paquets pertinents.

On retrouve en grande partie des paquets de communication entre le PC et le dispositif (comme affiché sur l'image ci-joint).

==== <u><big>Troisième tentative</big></u> ====
Cette fois-ci, on utilisera le réseau <code>PLIL</code> pour ne pas avoir notre smartphone comme étant MITM.
[[Fichier:3ème analyse Wireshark.jpg|vignette|3ème analyse Wireshark]]
D'après une analyse approfondie sur Wireshark, on arrive déjà à voir les paquets lors de la première connexion (requêtes <code>SYNC</code>) et d'autres paquets intéressants dès le démarrage du dispositif. Ceci n'était pas possible avant car il y avait le téléphone qui n'affichait pas en quelque sorte les paquets destinés directement au dispositif.

Pour cette manipulation, nous avons utilisé le réseau '''PLIL''' et tenté une attaque de type '''MITM'''. Plusieurs simulations de fumée ont été réalisées afin d’observer le comportement du système ainsi que les paquets échangés entre le capteur, l’application '''NEDIS''' et d’autres adresses IP publiques.

Après plusieurs tentatives de simulation, nous avons pu identifier deux adresses IP publiques apparaissant systématiquement dans les communications :

Adresse IP : '''3.124.85.154''' ''':''' Cette adresse appartient à la plage des IP réservées pour AWS (Amazon Web Services).

Adresse IP : '''18.197.183.192 :''' Cette adresse appartient également à la plage des IP réservées pour AWS.

Nous avons vérifié ces deux adresses IP, et elles sont bien incluses dans les plages d’IP réservées pour AWS dans la région '''eu-central-1''' ( Francfort ).

Les deux IP adresses sont des Machines virtuelles EC2 hebergees dans la region '''eu-central-1''' ( Francfort ).
[[Fichier:Analyse @IP1.jpg|alt=Analyse @IP1|vignette|Analyse de l'adresse 3.124.85.154|364x364px]]

===== Analyse Des serveurs CLOUD =====

Adresse IP : '''3.124.85.154 :''' Contient 3 ports ('''80''', '''443''' et '''7010''') qui sont ouverts et utilise principalement comme services HTTP/HTTPS. (Comme affiché sur les captures d'écran).

Adresse IP : '''18.197.183.192 :''' Contient également 3 ports ouverts, dont 1 qui utilise du '''MQTT''' sur le port '''1883''' et un autre en '''MQTT-S''' sur le port '''8883'''.
[[Fichier:Capture d’écran 2025-01-07 à 22.03.48.png|vignette|360x360px|Vérification IP adresses AWS]][[Fichier:Screenip18.jpg|vignette|Analyse de l'adresse 18.194.10.142|352x352px]]
===== Workflow Potentiel =====
'''Capteur ---> 18.197.183.192 :''' Le capteur envoie des données via MQTT/MQTTS. Cette instance EC2 pourrait également acheminer les messages vers d'autres services pour traitement ou visualisation.

'''Capteur ---> 3.124.85.154 :''' L'application mobile/Capteur communique avec le (API Gateway) serveur pour des opérations destinées à l'utilisateur, telles que la récupération de données stockées, l'envoi de commandes de contrôle au capteur ou la gestion des comptes d'utilisateurs.

===== Mock du serveur MQTT =====
L'idée sera de créer un '''<code>mock server</code>''' avec la même adresse IP, sur notre machine, et essayer de faire passer une communication de paquets via notre machine plutôt que passer par le serveur d'origine. Une fois ceci sera réalisé, nous pourrons commencer à craquer et manipuler le dispositif comme souhaité.

En analysant les paquets à destination de ce serveur, nous avons remarqué que la communication passe par le port 8883 qui nécessite le protocole MQTTS (ceci va nous poser un blocage car un certificat sera nécessaire par la suite).

Pour contourner ce problème, nous allons configurer une '''redirection de ports''' (Port forwarding) vers 1883 pour avoir accès au protocole MQTT qui, quant à lui, n'utilise aucun certificat de sécurité.

---

Membres : '''BILAL EL HASNAOUI''' et '''AYOUB CHAOUNI'''

SE5 IdO sécurité des objets 2024/2025 b3

2025-01-08T10:13:30Z

Achaouni : /* Mock du serveur MQTT */

== Sécurisation WiFi par WPA2-EAP ==
'''''<u>Séance (25/09) :</u>'''''

* '''<u>Serveur virtuel</u>'''

Nous avons créé une MV sous le nom de '''SE5-elhaschaouni''' sur Capbreton en utilisant l'hyperviseur <code>xen</code>. (voir mdp : <code>cat /var/log/xen-tools/SE5-elhaschaouni.log</code>)

Cette dernière a 2 interfaces, avec l'adresse IP <code>172.26.145.103</code> sous eth0 et <code>172.26.3.103</code> sous eth1 dans le <code>VLAN 403</code>.

Pour cela, les interfaces <code>VLAN403</code> et <code>br403</code> ont été configurées sur capbreton (''voir /etc/network/interfaces.d'')

* '''<u>Point d'accés WiFi</u>'''

Nous avons fait la première configuration via console du point d'accès Cisco, notamment la configuration du SSH pour que les autres binômes puissent se connecter à la borne via SSH.

Par la suite, on a configuré notre SSID '''VM_binome_3''' pour qu'il utilise le <code>VLAN403</code> puis on l'a sécurisé avec '''WPA2-EAP'''.

Mascarade : Implementée avec succés (''Problème du chain "DROP" corrigé le 21/09'').

FreeRadius : Fonctionnel en '''PEAP-MSCHAPv2''' (2 utilisateurs disponibles).

DNS : Configuré avec bind9.

Serveur DHCP : Configuré. Le "range" des adresses IP allant de <code>172.16.3.100</code> à <code>172.16.3.200</code>

Accès Internet : OUI (On peut regarder des vidéos sur youtube)

''<u>Utilisateurs existants (user : mdp):</u>''

bilal : glopglop

ayoub : glopglop

== Craquage TempTale Ultra Temperature Sensor ==
L'appareil TempTale Ultra est un enregistreur d'humidité et de température élégamment conçu avec USB intégré qui peut mesurer les températures ambiantes de -30°C à +70°C et l'humidité de 0% RH à 100% Rh (Rh). Cet appareil compact, simple ou polyvalent, crée automatiquement un fichier PDF sécurisé et un fichier de données cryptés sans avoir besoin de logiciels supplémentaires.

Il est simple d'accéder aux fichiers générés par TempTale Ultra :<syntaxhighlight lang="bash">
sudo mount /dev/sdb TempTaleUltra/
</syntaxhighlight>
[[Fichier:Carte TempTale.jpg|vignette|Carte TempTale après soudage|302x302px]]
Comme une première tentative, on a essayé de modifier directement les données dans les fichiers mais ces dernières sont protégées en lecture seule. Et le fichier TTV est crypté. La seule solution pour modifier les données est de retirer cette protection dans le firmware.

Après démontage de TempTale Ultra, on trouve que le MCU utilisé est : STM32L152RCT6.

D'après le Datasheet, on trouve les PINs SWDIO, SWDCLK, NRST et VDD qui nous permettent de reprogrammer le MCU à l'aide d'un ST-LINK et STM32CubeIDE.

Datasheet MCU [https://www.st.com/content/ccc/resource/technical/document/datasheet/2a/6e/97/91/cd/c0/43/8b/DM00048356.pdf/files/DM00048356.pdf/jcr:content/translations/en.DM00048356.pdf STM32L152RCT6].

'''''<u>Séances (21/10 + 22/10) :</u>'''''

On s'attaque au soudage des pins JTAG, pour cela il fallait bien identifier les 5 pins dont nous avons besoin, à savoir :

- 3.3V (câble bleu)

- GND (câble noir)

- SWDIO (câble blanc)

- SWCLK (câble gris)

- RESET (câble orange)

Nous avons revérifier ces connexions entre les sorties du MCU et les pins JTAG à l'aide d'un multimètre (continuité).

[[Fichier:Connexion L152-Nucleo.jpg|vignette|229x229px|Connexion L152-Nucleo]]
Ensuite, comme une deuxième tentative, nous avons essayé de la connecter en utilisant la carte <code>NUCLEO-FR401RE</code> comme intermédiaire via le canal CN4.
{| class="wikitable"
|+ST-Link Pins
!'''VDD'''
!'''CN4-1'''
|-
|'''GND'''
|'''CN4-3'''
|-
|'''SWDIO'''
|'''CN4-4'''
|-
|'''SWCLK'''
|'''CN4-2'''
|-
|'''RST'''
|'''CN4-5'''
|}

En alimentant que la carte <code>NUCLEO-FR401RE</code>, notre carte TempTale se trouve sans alimentation. Du coup, nous l'avons alimenté séparement via USB.

Par la suite, nous avons essayé de se connecter à la carte via le logiciel '''STM32 ST-LINK Utility.''' Cette fois-ci, on arrive à accéder à notre carte !
[[Fichier:Wiki-3.png|vignette|288x288px|Détection de la carte STM32L152]]
[[Fichier:Wiki-2.png|centré|vignette|420x420px|Successful connection to the target]]

[...]

== Craquage nedis WIFIDS20WT (Détecteur de fumée) ==

=== Connexion du dispositif au réseau via WIFI ===
[[Fichier:Connexion nedis via app.jpg|vignette|191x191px|Connexion nedis via app]]
Nous avons connecté notre détecteur de fumée <code>Nedis WIFIDS20WT</code> à l'application mobile Nedis en suivant les étapes simples de configuration. Après avoir installé l'application sur notre smartphone, nous avons activé le Wi-Fi et ajouté le détecteur au réseau. L'application permet également de surveiller l'état du détecteur et d'effectuer des tests à distance.

=== Analyse du trafic réseau ===
Dans un premier temps, nous avons tenté d'analyser le trafic réseau via <code>Wireshark</code> afin d’identifier des échanges spécifiques liés au protocole WPA2, notamment les trames EAPOL (Extensible Authentication Protocol Over LAN) échangées lors du 4-Way Handshake. En capturant ces trames, notre objectif était de surveiller les retransmissions qui pourraient indiquer une tentative de réinstallation de clé, point central de l’exploitation de la faille KRACK.

Nous avons essayé d'identifier l'adresse IP que le dispositif Nedis utilise sur le réseau (connexion partagée depuis notre smartphone). Pour ce faire, nous avons appliqué un filtre spécifique dans Wireshark, en utilisant l'adresse IP de notre smartphone personnel comme référence <code>172.20.10.2</code>[[Fichier:Analyse Wireshark.jpg|vignette|338x338px|1ère analyse Wireshark]]Ce filtre nous a permis de capturer uniquement les paquets ayant pour source notre smartphone, ce qui nous a aidés à repérer les échanges réseau dirigés vers le dispositif Nedis. En isolant ces paquets, nous avons pu mieux analyser les interactions spécifiques entre notre smartphone et le dispositif, et tenter de déterminer l'adresse IP assignée à ce dernier sur le réseau pour poursuivre les analyses liées à la vulnérabilité KRACK.

L'adresse IP la plus "suspecte" pour l'instant est <code>172.20.10.15</code> qu'on pense être celle du dispositif.

[[Fichier:IP+MAC.jpg|vignette|151x151px|Adresse IP + MAC du dispositif]]
---

Après plusieurs tentatives avec le réseau du téléphone, on arrive à obtenir la "bonne adresse IP" avec l'adresse MAC du dispositif mais ce dernier n'arrive pas à maintenir une connexion stable (comme affiché sur la capture d'écran ci-dessous).
[[Fichier:Tentatives de ping.png|centré|vignette|480x480px|Tentatives de ping]]

Nous avons alors décidé de changer de réseau et se connecter avec le Wifi <code>WIFI_IA_SE5</code>

On réalise un premier scan du réseau avec l'utilitaire <code>nmap</code> pour voir tous les appareils connectés avec leur adresse MAC correspondante, en espérant trouver notre dispositif connecté à ce réseau.

==== <u><big>Deuxième tentative</big></u> ====
[[Fichier:Capture d’écran 2024-12-11 à 14.59.01.png|vignette|345x345px|2ème analyse Wireshark]]
On réessaye de connecter le dispositif en utilisant le réseau de notre smartphone.

192.168.89.183 : Adresse IP du dispositif

192.168.89.186 : Adresse IP du PC effectuant l'analyse

On peut voir des paquets entre le PC et le dispositif, mais pas grand chose du côté serveur.

Étant donné que le smartphone joue le rôle d'un MITM, on arrive pas à capturer des paquets pertinents.

On retrouve en grande partie des paquets de communication entre le PC et le dispositif (comme affiché sur l'image ci-joint).

==== <u><big>Troisième tentative</big></u> ====
Cette fois-ci, on utilisera le réseau <code>PLIL</code> pour ne pas avoir notre smartphone comme étant MITM.
[[Fichier:3ème analyse Wireshark.jpg|vignette|3ème analyse Wireshark]]
D'après une analyse approfondie sur Wireshark, on arrive déjà à voir les paquets lors de la première connexion (requêtes <code>SYNC</code>) et d'autres paquets intéressants dès le démarrage du dispositif. Ceci n'était pas possible avant car il y avait le téléphone qui n'affichait pas en quelque sorte les paquets destinés directement au dispositif.

Pour cette manipulation, nous avons utilisé le réseau '''PLIL''' et tenté une attaque de type '''MITM'''. Plusieurs simulations de fumée ont été réalisées afin d’observer le comportement du système ainsi que les paquets échangés entre le capteur, l’application '''NEDIS''' et d’autres adresses IP publiques.

Après plusieurs tentatives de simulation, nous avons pu identifier deux adresses IP publiques apparaissant systématiquement dans les communications :

Adresse IP : '''3.124.85.154''' ''':''' Cette adresse appartient à la plage des IP réservées pour AWS (Amazon Web Services).

Adresse IP : '''18.197.183.192 :''' Cette adresse appartient également à la plage des IP réservées pour AWS.

Nous avons vérifié ces deux adresses IP, et elles sont bien incluses dans les plages d’IP réservées pour AWS dans la région '''eu-central-1''' ( Francfort ).

Les deux IP adresses sont des Machines virtuelles EC2 hebergees dans la region '''eu-central-1''' ( Francfort ).
[[Fichier:Analyse @IP1.jpg|alt=Analyse @IP1|vignette|Analyse de l'adresse 3.124.85.154|364x364px]]

===== Analyse Des serveurs CLOUD =====

Adresse IP : '''3.124.85.154 :''' Contient 3 ports ('''80''', '''443''' et '''7010''') qui sont ouverts et utilise principalement comme services HTTP/HTTPS. (Comme affiché sur les captures d'écran).

Adresse IP : '''18.197.183.192 :''' Contient également 3 ports ouverts, dont 1 qui utilise du '''MQTT''' sur le port '''1883''' et un autre en '''MQTT-S''' sur le port '''8883'''.
[[Fichier:Capture d’écran 2025-01-07 à 22.03.48.png|vignette|360x360px|Vérification IP adresses AWS]][[Fichier:Screenip18.jpg|vignette|Analyse de l'adresse 18.194.10.142|352x352px]]
===== Workflow Potentiel =====
'''Capteur ---> 18.197.183.192 :''' Le capteur envoie des données via MQTT/MQTTS. Cette instance EC2 pourrait également acheminer les messages vers d'autres services pour traitement ou visualisation.

'''Capteur ---> 3.124.85.154 :''' L'application mobile/Capteur communique avec le (API Gateway) serveur pour des opérations destinées à l'utilisateur, telles que la récupération de données stockées, l'envoi de commandes de contrôle au capteur ou la gestion des comptes d'utilisateurs.

===== Mock du serveur MQTT =====
L'idée sera de créer un '''<code>mock server</code>''' avec la même adresse IP, sur notre machine, et essayer de faire passer une communication de paquets via notre machine plutôt que passer par le serveur d'origine. Une fois ceci sera réalisé, nous pourrons commencer à craquer et manipuler le dispositif comme souhaité.

En analysant les paquets à destination de ce serveur, nous avons remarqué que la communication passe par le port 8883 qui nécessite le protocole MQTTS (ceci va nous poser un blocage car un certificat sera nécessaire par la suite).

Pour contourner ce problème, nous allons configuré une '''redirection de ports''' (Port forwarding) vers 1883 pour avoir accès au protocole MQTT qui, quant à lui, n'utilise aucun certificat de sécurité.

---

Membres : '''BILAL EL HASNAOUI''' et '''AYOUB CHAOUNI'''

SE5 IdO sécurité des objets 2024/2025 b3

2025-01-07T21:13:43Z

Achaouni :

== Sécurisation WiFi par WPA2-EAP ==
'''''<u>Séance (25/09) :</u>'''''

* '''<u>Serveur virtuel</u>'''

Nous avons créé une MV sous le nom de '''SE5-elhaschaouni''' sur Capbreton en utilisant l'hyperviseur <code>xen</code>. (voir mdp : <code>cat /var/log/xen-tools/SE5-elhaschaouni.log</code>)

Cette dernière a 2 interfaces, avec l'adresse IP <code>172.26.145.103</code> sous eth0 et <code>172.26.3.103</code> sous eth1 dans le <code>VLAN 403</code>.

Pour cela, les interfaces <code>VLAN403</code> et <code>br403</code> ont été configurées sur capbreton (''voir /etc/network/interfaces.d'')

* '''<u>Point d'accés WiFi</u>'''

Nous avons fait la première configuration via console du point d'accès Cisco, notamment la configuration du SSH pour que les autres binômes puissent se connecter à la borne via SSH.

Par la suite, on a configuré notre SSID '''VM_binome_3''' pour qu'il utilise le <code>VLAN403</code> puis on l'a sécurisé avec '''WPA2-EAP'''.

Mascarade : Implementée avec succés (''Problème du chain "DROP" corrigé le 21/09'').

FreeRadius : Fonctionnel en '''PEAP-MSCHAPv2''' (2 utilisateurs disponibles).

DNS : Configuré avec bind9.

Serveur DHCP : Configuré. Le "range" des adresses IP allant de <code>172.16.3.100</code> à <code>172.16.3.200</code>

Accès Internet : OUI (On peut regarder des vidéos sur youtube)

''<u>Utilisateurs existants (user : mdp):</u>''

bilal : glopglop

ayoub : glopglop

== Craquage TempTale Ultra Temperature Sensor ==
L'appareil TempTale Ultra est un enregistreur d'humidité et de température élégamment conçu avec USB intégré qui peut mesurer les températures ambiantes de -30°C à +70°C et l'humidité de 0% RH à 100% Rh (Rh). Cet appareil compact, simple ou polyvalent, crée automatiquement un fichier PDF sécurisé et un fichier de données cryptés sans avoir besoin de logiciels supplémentaires.

Il est simple d'accéder aux fichiers générés par TempTale Ultra :<syntaxhighlight lang="bash">
sudo mount /dev/sdb TempTaleUltra/
</syntaxhighlight>
[[Fichier:Carte TempTale.jpg|vignette|Carte TempTale après soudage|302x302px]]
Comme une première tentative, on a essayé de modifier directement les données dans les fichiers mais ces dernières sont protégées en lecture seule. Et le fichier TTV est crypté. La seule solution pour modifier les données est de retirer cette protection dans le firmware.

Après démontage de TempTale Ultra, on trouve que le MCU utilisé est : STM32L152RCT6.

D'après le Datasheet, on trouve les PINs SWDIO, SWDCLK, NRST et VDD qui nous permettent de reprogrammer le MCU à l'aide d'un ST-LINK et STM32CubeIDE.

Datasheet MCU [https://www.st.com/content/ccc/resource/technical/document/datasheet/2a/6e/97/91/cd/c0/43/8b/DM00048356.pdf/files/DM00048356.pdf/jcr:content/translations/en.DM00048356.pdf STM32L152RCT6].

'''''<u>Séances (21/10 + 22/10) :</u>'''''

On s'attaque au soudage des pins JTAG, pour cela il fallait bien identifier les 5 pins dont nous avons besoin, à savoir :

- 3.3V (câble bleu)

- GND (câble noir)

- SWDIO (câble blanc)

- SWCLK (câble gris)

- RESET (câble orange)

Nous avons revérifier ces connexions entre les sorties du MCU et les pins JTAG à l'aide d'un multimètre (continuité).

[[Fichier:Connexion L152-Nucleo.jpg|vignette|229x229px|Connexion L152-Nucleo]]
Ensuite, comme une deuxième tentative, nous avons essayé de la connecter en utilisant la carte <code>NUCLEO-FR401RE</code> comme intermédiaire via le canal CN4.
{| class="wikitable"
|+ST-Link Pins
!'''VDD'''
!'''CN4-1'''
|-
|'''GND'''
|'''CN4-3'''
|-
|'''SWDIO'''
|'''CN4-4'''
|-
|'''SWCLK'''
|'''CN4-2'''
|-
|'''RST'''
|'''CN4-5'''
|}

En alimentant que la carte <code>NUCLEO-FR401RE</code>, notre carte TempTale se trouve sans alimentation. Du coup, nous l'avons alimenté séparement via USB.

Par la suite, nous avons essayé de se connecter à la carte via le logiciel '''STM32 ST-LINK Utility.''' Cette fois-ci, on arrive à accéder à notre carte !
[[Fichier:Wiki-3.png|vignette|288x288px|Détection de la carte STM32L152]]
[[Fichier:Wiki-2.png|centré|vignette|420x420px|Successful connection to the target]]

[...]

== Craquage nedis WIFIDS20WT (Détecteur de fumée) ==

=== Connexion du dispositif au réseau via WIFI ===
[[Fichier:Connexion nedis via app.jpg|vignette|191x191px|Connexion nedis via app]]
Nous avons connecté notre détecteur de fumée <code>Nedis WIFIDS20WT</code> à l'application mobile Nedis en suivant les étapes simples de configuration. Après avoir installé l'application sur notre smartphone, nous avons activé le Wi-Fi et ajouté le détecteur au réseau. L'application permet également de surveiller l'état du détecteur et d'effectuer des tests à distance.

=== Analyse du trafic réseau ===
Dans un premier temps, nous avons tenté d'analyser le trafic réseau via <code>Wireshark</code> afin d’identifier des échanges spécifiques liés au protocole WPA2, notamment les trames EAPOL (Extensible Authentication Protocol Over LAN) échangées lors du 4-Way Handshake. En capturant ces trames, notre objectif était de surveiller les retransmissions qui pourraient indiquer une tentative de réinstallation de clé, point central de l’exploitation de la faille KRACK.

Nous avons essayé d'identifier l'adresse IP que le dispositif Nedis utilise sur le réseau (connexion partagée depuis notre smartphone). Pour ce faire, nous avons appliqué un filtre spécifique dans Wireshark, en utilisant l'adresse IP de notre smartphone personnel comme référence <code>172.20.10.2</code>[[Fichier:Analyse Wireshark.jpg|vignette|338x338px|1ère analyse Wireshark]]Ce filtre nous a permis de capturer uniquement les paquets ayant pour source notre smartphone, ce qui nous a aidés à repérer les échanges réseau dirigés vers le dispositif Nedis. En isolant ces paquets, nous avons pu mieux analyser les interactions spécifiques entre notre smartphone et le dispositif, et tenter de déterminer l'adresse IP assignée à ce dernier sur le réseau pour poursuivre les analyses liées à la vulnérabilité KRACK.

L'adresse IP la plus "suspecte" pour l'instant est <code>172.20.10.15</code> qu'on pense être celle du dispositif.

[[Fichier:IP+MAC.jpg|vignette|151x151px|Adresse IP + MAC du dispositif]]
---

Après plusieurs tentatives avec le réseau du téléphone, on arrive à obtenir la "bonne adresse IP" avec l'adresse MAC du dispositif mais ce dernier n'arrive pas à maintenir une connexion stable (comme affiché sur la capture d'écran ci-dessous).
[[Fichier:Tentatives de ping.png|centré|vignette|480x480px|Tentatives de ping]]

Nous avons alors décidé de changer de réseau et se connecter avec le Wifi <code>WIFI_IA_SE5</code>

On réalise un premier scan du réseau avec l'utilitaire <code>nmap</code> pour voir tous les appareils connectés avec leur adresse MAC correspondante, en espérant trouver notre dispositif connecté à ce réseau.

==== Deuxième tentative ====
[[Fichier:Capture d’écran 2024-12-11 à 14.59.01.png|vignette|345x345px|2ème analyse Wireshark]]
On réessaye de connecter le dispositif en utilisant le réseau de notre smartphone.

192.168.89.183 : Adresse IP du dispositif

192.168.89.186 : Adresse IP du PC effectuant l'analyse

On peut voir des paquets entre le PC et le dispositif, mais pas grand chose du côté serveur.

Étant donné que le smartphone joue le rôle d'un MITM, on arrive pas à capturer des paquets pertinents.

On retrouve en grande partie des paquets de communication entre le PC et le dispositif (comme affiché sur l'image ci-joint).

==== Troisième tentative ====
Cette fois-ci, on utilisera le réseau <code>PLIL</code> pour ne pas avoir notre smartphone comme étant MITM.
[[Fichier:3ème analyse Wireshark.jpg|vignette|3ème analyse Wireshark]]
D'après une analyse approfondie sur Wireshark, on arrive déjà à voir les paquets lors de la première connexion (requêtes <code>SYNC</code>) et d'autres paquets intéressants dès le démarrage du dispositif. Ceci n'était pas possible avant car il y avait le téléphone qui n'affichait pas en quelque sorte les paquets destinés directement au dispositif.

[[Fichier:Analyse @IP1.jpg|alt=Analyse @IP1|vignette|Analyse de l'adresse 3.124.85.154]]
Nous avons pu identifier 2 adresses IP pertinentes (3.124.85.154 et 18.194.10.142) qui sont des serveurs virtuels '''EC2''' appartenant à AWS.

Le premier (3.124.85.154) contient 3 ports (80, 443 et 7010) qui sont ouverts et utilise comme principalement service http/https. (comme affiché sur les captures d'écran).

Le deuxième (18.194.10.142) contient également 3 ports ouverts, dont 1 qui utilise du '''mqtt''' sur le port 1883.

[[Fichier:Screenip18.jpg|vignette|Analyse de l'adresse 18.194.10.142]]
L'idée sera de créer un '''<code>mock server</code>''' avec la même adresse IP, sur notre machine, et essayer de faire passer une communication de paquets via notre machine plutôt que passer par le serveur d'origine. Une fois ceci sera réalisé, nous pourrons commencer à craquer et manipuler le dispositif comme souhaité.

---

Membres : '''BILAL EL HASNAOUI''' et '''AYOUB CHAOUNI'''

SE5 IdO sécurité des objets 2024/2025 b3

2025-01-07T21:12:50Z

Achaouni : /* Craquage nedis WIFIDS20WT (Détecteur de fumée) */

== Sécurisation WiFi par WPA2-EAP ==
'''''<u>Séance (25/09) :</u>'''''

* '''<u>Serveur virtuel</u>'''

Nous avons créé une MV sous le nom de '''SE5-elhaschaouni''' sur Capbreton en utilisant l'hyperviseur <code>xen</code>. (voir mdp : <code>cat /var/log/xen-tools/SE5-elhaschaouni.log</code>)

Cette dernière a 2 interfaces, avec l'adresse IP <code>172.26.145.103</code> sous eth0 et <code>172.26.3.103</code> sous eth1 dans le <code>VLAN 403</code>.

Pour cela, les interfaces <code>VLAN403</code> et <code>br403</code> ont été configurées sur capbreton (''voir /etc/network/interfaces.d'')

* '''<u>Point d'accés WiFi</u>'''

Nous avons fait la première configuration via console du point d'accès Cisco, notamment la configuration du SSH pour que les autres binômes puissent se connecter à la borne via SSH.

Par la suite, on a configuré notre SSID '''VM_binome_3''' pour qu'il utilise le <code>VLAN403</code> puis on l'a sécurisé avec '''WPA2-EAP'''.

Mascarade : Implementée avec succés (''Problème du chain "DROP" corrigé le 21/09'').

FreeRadius : Fonctionnel en '''PEAP-MSCHAPv2''' (2 utilisateurs disponibles).

DNS : Configuré avec bind9.

Serveur DHCP : Configuré. Le "range" des adresses IP allant de <code>172.16.3.100</code> à <code>172.16.3.200</code>

Accès Internet : OUI (On peut regarder des vidéos sur youtube)

''<u>Utilisateurs existants (user : mdp):</u>''

bilal : glopglop

ayoub : glopglop

== Craquage TempTale Ultra Temperature Sensor ==
L'appareil TempTale Ultra est un enregistreur d'humidité et de température élégamment conçu avec USB intégré qui peut mesurer les températures ambiantes de -30°C à +70°C et l'humidité de 0% RH à 100% Rh (Rh). Cet appareil compact, simple ou polyvalent, crée automatiquement un fichier PDF sécurisé et un fichier de données cryptés sans avoir besoin de logiciels supplémentaires.

Il est simple d'accéder aux fichiers générés par TempTale Ultra :<syntaxhighlight lang="bash">
sudo mount /dev/sdb TempTaleUltra/
</syntaxhighlight>
[[Fichier:Carte TempTale.jpg|vignette|Carte TempTale après soudage|302x302px]]
Comme une première tentative, on a essayé de modifier directement les données dans les fichiers mais ces dernières sont protégées en lecture seule. Et le fichier TTV est crypté. La seule solution pour modifier les données est de retirer cette protection dans le firmware.

Après démontage de TempTale Ultra, on trouve que le MCU utilisé est : STM32L152RCT6.

D'après le Datasheet, on trouve les PINs SWDIO, SWDCLK, NRST et VDD qui nous permettent de reprogrammer le MCU à l'aide d'un ST-LINK et STM32CubeIDE.

Datasheet MCU [https://www.st.com/content/ccc/resource/technical/document/datasheet/2a/6e/97/91/cd/c0/43/8b/DM00048356.pdf/files/DM00048356.pdf/jcr:content/translations/en.DM00048356.pdf STM32L152RCT6].

'''''<u>Séances (21/10 + 22/10) :</u>'''''

On s'attaque au soudage des pins JTAG, pour cela il fallait bien identifier les 5 pins dont nous avons besoin, à savoir :

- 3.3V (câble bleu)

- GND (câble noir)

- SWDIO (câble blanc)

- SWCLK (câble gris)

- RESET (câble orange)

Nous avons revérifier ces connexions entre les sorties du MCU et les pins JTAG à l'aide d'un multimètre (continuité).

[[Fichier:Connexion L152-Nucleo.jpg|vignette|229x229px|Connexion L152-Nucleo]]
Ensuite, comme une deuxième tentative, nous avons essayé de la connecter en utilisant la carte <code>NUCLEO-FR401RE</code> comme intermédiaire via le canal CN4.
{| class="wikitable"
|+ST-Link Pins
!'''VDD'''
!'''CN4-1'''
|-
|'''GND'''
|'''CN4-3'''
|-
|'''SWDIO'''
|'''CN4-4'''
|-
|'''SWCLK'''
|'''CN4-2'''
|-
|'''RST'''
|'''CN4-5'''
|}

En alimentant que la carte <code>NUCLEO-FR401RE</code>, notre carte TempTale se trouve sans alimentation. Du coup, nous l'avons alimenté séparement via USB.

Par la suite, nous avons essayé de se connecter à la carte via le logiciel '''STM32 ST-LINK Utility.''' Cette fois-ci, on arrive à accéder à notre carte !
[[Fichier:Wiki-3.png|vignette|288x288px|Détection de la carte STM32L152]]
[[Fichier:Wiki-2.png|centré|vignette|420x420px|Successful connection to the target]]

[...]

== Craquage nedis WIFIDS20WT (Détecteur de fumée) ==

=== Connexion du dispositif au réseau via WIFI ===
[[Fichier:Connexion nedis via app.jpg|vignette|191x191px|Connexion nedis via app]]
Nous avons connecté notre détecteur de fumée <code>Nedis WIFIDS20WT</code> à l'application mobile Nedis en suivant les étapes simples de configuration. Après avoir installé l'application sur notre smartphone, nous avons activé le Wi-Fi et ajouté le détecteur au réseau. L'application permet également de surveiller l'état du détecteur et d'effectuer des tests à distance.

=== Analyse du trafic réseau ===
Dans un premier temps, nous avons tenté d'analyser le trafic réseau via <code>Wireshark</code> afin d’identifier des échanges spécifiques liés au protocole WPA2, notamment les trames EAPOL (Extensible Authentication Protocol Over LAN) échangées lors du 4-Way Handshake. En capturant ces trames, notre objectif était de surveiller les retransmissions qui pourraient indiquer une tentative de réinstallation de clé, point central de l’exploitation de la faille KRACK.

Nous avons essayé d'identifier l'adresse IP que le dispositif Nedis utilise sur le réseau (connexion partagée depuis notre smartphone). Pour ce faire, nous avons appliqué un filtre spécifique dans Wireshark, en utilisant l'adresse IP de notre smartphone personnel comme référence <code>172.20.10.2</code>[[Fichier:Analyse Wireshark.jpg|vignette|338x338px|1ère analyse Wireshark]]Ce filtre nous a permis de capturer uniquement les paquets ayant pour source notre smartphone, ce qui nous a aidés à repérer les échanges réseau dirigés vers le dispositif Nedis. En isolant ces paquets, nous avons pu mieux analyser les interactions spécifiques entre notre smartphone et le dispositif, et tenter de déterminer l'adresse IP assignée à ce dernier sur le réseau pour poursuivre les analyses liées à la vulnérabilité KRACK.

L'adresse IP la plus "suspecte" pour l'instant est <code>172.20.10.15</code> qu'on pense être celle du dispositif.

[[Fichier:IP+MAC.jpg|vignette|151x151px|Adresse IP + MAC du dispositif]]
---

Après plusieurs tentatives avec le réseau du téléphone, on arrive à obtenir la "bonne adresse IP" avec l'adresse MAC du dispositif mais ce dernier n'arrive pas à maintenir une connexion stable (comme affiché sur la capture d'écran ci-dessous).
[[Fichier:Tentatives de ping.png|centré|vignette|480x480px|Tentatives de ping]]

Nous avons alors décidé de changer de réseau et se connecter avec le Wifi <code>WIFI_IA_SE5</code>

On réalise un premier scan du réseau avec l'utilitaire <code>nmap</code> pour voir tous les appareils connectés avec leur adresse MAC correspondante, en espérant trouver notre dispositif connecté à ce réseau.

==== Deuxième tentative ====
[[Fichier:Capture d’écran 2024-12-11 à 14.59.01.png|vignette|345x345px|2ème analyse Wireshark]]
On réessaye de connecter le dispositif en utilisant le réseau de notre smartphone.

192.168.89.183 : Adresse IP du dispositif

192.168.89.186 : Adresse IP du PC effectuant l'analyse

On peut voir des paquets entre le PC et le dispositif, mais pas grand chose du côté serveur.

Étant donné que le smartphone joue le rôle d'un MITM, on arrive pas à capturer des paquets pertinents.

On retrouve en grande partie des paquets de communication entre le PC et le dispositif (comme affiché sur l'image ci-joint).

==== Troisième tentative ====
Cette fois-ci, on utilisera le réseau <code>PLIL</code> pour ne pas avoir notre smartphone comme étant MITM.
[[Fichier:3ème analyse Wireshark.jpg|vignette|3ème analyse Wireshark]]
D'après une analyse approfondie sur Wireshark, on arrive déjà à voir les paquets lors de la première connexion (requêtes <code>SYNC</code>) et d'autres paquets intéressants dès le démarrage du dispositif. Ceci n'était pas possible avant car il y avait le téléphone qui n'affichait pas en quelque sorte les paquets destinés directement au dispositif.

[[Fichier:Analyse @IP1.jpg|alt=Analyse @IP1|vignette|Analyse de l'adresse 3.124.85.154]]
Nous avons pu identifier 2 adresses IP pertinentes (3.124.85.154 et 18.194.10.142) qui sont des serveurs virtuels '''EC2''' appartenant à AWS.

Le premier (3.124.85.154) contient 3 ports (80, 443 et 7010) qui sont ouverts et utilise comme principalement service http/https. (comme affiché sur les captures d'écran).

Le deuxième (18.194.10.142) contient également 3 ports ouverts, dont 1 qui utilise du '''mqtt''' sur le port 1883.

[[Fichier:Screenip18.jpg|vignette|Analyse de l'adresse 18.194.10.142]]
L'idée sera de créer un '''<code>mock server</code>''' avec la même adresse IP, sur notre machine, et essayer de faire passer une communication de paquets via notre machine plutôt que passer par le serveur d'origine. Une fois ceci sera réalisé, nous pourrons commencer à craquer et manipuler le dispositif comme souhaité. --

---

Membres : '''BILAL EL HASNAOUI''' et '''AYOUB CHAOUNI'''

SE5 IdO sécurité des objets 2024/2025 b3

2025-01-07T21:12:31Z

Achaouni : /* Troisième tentative */

== Sécurisation WiFi par WPA2-EAP ==
'''''<u>Séance (25/09) :</u>'''''

* '''<u>Serveur virtuel</u>'''

Nous avons créé une MV sous le nom de '''SE5-elhaschaouni''' sur Capbreton en utilisant l'hyperviseur <code>xen</code>. (voir mdp : <code>cat /var/log/xen-tools/SE5-elhaschaouni.log</code>)

Cette dernière a 2 interfaces, avec l'adresse IP <code>172.26.145.103</code> sous eth0 et <code>172.26.3.103</code> sous eth1 dans le <code>VLAN 403</code>.

Pour cela, les interfaces <code>VLAN403</code> et <code>br403</code> ont été configurées sur capbreton (''voir /etc/network/interfaces.d'')

* '''<u>Point d'accés WiFi</u>'''

Nous avons fait la première configuration via console du point d'accès Cisco, notamment la configuration du SSH pour que les autres binômes puissent se connecter à la borne via SSH.

Par la suite, on a configuré notre SSID '''VM_binome_3''' pour qu'il utilise le <code>VLAN403</code> puis on l'a sécurisé avec '''WPA2-EAP'''.

Mascarade : Implementée avec succés (''Problème du chain "DROP" corrigé le 21/09'').

FreeRadius : Fonctionnel en '''PEAP-MSCHAPv2''' (2 utilisateurs disponibles).

DNS : Configuré avec bind9.

Serveur DHCP : Configuré. Le "range" des adresses IP allant de <code>172.16.3.100</code> à <code>172.16.3.200</code>

Accès Internet : OUI (On peut regarder des vidéos sur youtube)

''<u>Utilisateurs existants (user : mdp):</u>''

bilal : glopglop

ayoub : glopglop

== Craquage TempTale Ultra Temperature Sensor ==
L'appareil TempTale Ultra est un enregistreur d'humidité et de température élégamment conçu avec USB intégré qui peut mesurer les températures ambiantes de -30°C à +70°C et l'humidité de 0% RH à 100% Rh (Rh). Cet appareil compact, simple ou polyvalent, crée automatiquement un fichier PDF sécurisé et un fichier de données cryptés sans avoir besoin de logiciels supplémentaires.

Il est simple d'accéder aux fichiers générés par TempTale Ultra :<syntaxhighlight lang="bash">
sudo mount /dev/sdb TempTaleUltra/
</syntaxhighlight>
[[Fichier:Carte TempTale.jpg|vignette|Carte TempTale après soudage|302x302px]]
Comme une première tentative, on a essayé de modifier directement les données dans les fichiers mais ces dernières sont protégées en lecture seule. Et le fichier TTV est crypté. La seule solution pour modifier les données est de retirer cette protection dans le firmware.

Après démontage de TempTale Ultra, on trouve que le MCU utilisé est : STM32L152RCT6.

D'après le Datasheet, on trouve les PINs SWDIO, SWDCLK, NRST et VDD qui nous permettent de reprogrammer le MCU à l'aide d'un ST-LINK et STM32CubeIDE.

Datasheet MCU [https://www.st.com/content/ccc/resource/technical/document/datasheet/2a/6e/97/91/cd/c0/43/8b/DM00048356.pdf/files/DM00048356.pdf/jcr:content/translations/en.DM00048356.pdf STM32L152RCT6].

'''''<u>Séances (21/10 + 22/10) :</u>'''''

On s'attaque au soudage des pins JTAG, pour cela il fallait bien identifier les 5 pins dont nous avons besoin, à savoir :

- 3.3V (câble bleu)

- GND (câble noir)

- SWDIO (câble blanc)

- SWCLK (câble gris)

- RESET (câble orange)

Nous avons revérifier ces connexions entre les sorties du MCU et les pins JTAG à l'aide d'un multimètre (continuité).

[[Fichier:Connexion L152-Nucleo.jpg|vignette|229x229px|Connexion L152-Nucleo]]
Ensuite, comme une deuxième tentative, nous avons essayé de la connecter en utilisant la carte <code>NUCLEO-FR401RE</code> comme intermédiaire via le canal CN4.
{| class="wikitable"
|+ST-Link Pins
!'''VDD'''
!'''CN4-1'''
|-
|'''GND'''
|'''CN4-3'''
|-
|'''SWDIO'''
|'''CN4-4'''
|-
|'''SWCLK'''
|'''CN4-2'''
|-
|'''RST'''
|'''CN4-5'''
|}

En alimentant que la carte <code>NUCLEO-FR401RE</code>, notre carte TempTale se trouve sans alimentation. Du coup, nous l'avons alimenté séparement via USB.

Par la suite, nous avons essayé de se connecter à la carte via le logiciel '''STM32 ST-LINK Utility.''' Cette fois-ci, on arrive à accéder à notre carte !
[[Fichier:Wiki-3.png|vignette|288x288px|Détection de la carte STM32L152]]
[[Fichier:Wiki-2.png|centré|vignette|420x420px|Successful connection to the target]]

[...]

== Craquage nedis WIFIDS20WT (Détecteur de fumée) ==

=== Connexion du dispositif au réseau via WIFI ===
[[Fichier:Connexion nedis via app.jpg|vignette|191x191px|Connexion nedis via app]]
Nous avons connecté notre détecteur de fumée <code>Nedis WIFIDS20WT</code> à l'application mobile Nedis en suivant les étapes simples de configuration. Après avoir installé l'application sur notre smartphone, nous avons activé le Wi-Fi et ajouté le détecteur au réseau. L'application permet également de surveiller l'état du détecteur et d'effectuer des tests à distance.

=== Analyse du trafic réseau ===
Dans un premier temps, nous avons tenté d'analyser le trafic réseau via <code>Wireshark</code> afin d’identifier des échanges spécifiques liés au protocole WPA2, notamment les trames EAPOL (Extensible Authentication Protocol Over LAN) échangées lors du 4-Way Handshake. En capturant ces trames, notre objectif était de surveiller les retransmissions qui pourraient indiquer une tentative de réinstallation de clé, point central de l’exploitation de la faille KRACK.

Nous avons essayé d'identifier l'adresse IP que le dispositif Nedis utilise sur le réseau (connexion partagée depuis notre smartphone). Pour ce faire, nous avons appliqué un filtre spécifique dans Wireshark, en utilisant l'adresse IP de notre smartphone personnel comme référence <code>172.20.10.2</code>[[Fichier:Analyse Wireshark.jpg|vignette|338x338px|1ère analyse Wireshark]]Ce filtre nous a permis de capturer uniquement les paquets ayant pour source notre smartphone, ce qui nous a aidés à repérer les échanges réseau dirigés vers le dispositif Nedis. En isolant ces paquets, nous avons pu mieux analyser les interactions spécifiques entre notre smartphone et le dispositif, et tenter de déterminer l'adresse IP assignée à ce dernier sur le réseau pour poursuivre les analyses liées à la vulnérabilité KRACK.

L'adresse IP la plus "suspecte" pour l'instant est <code>172.20.10.15</code> qu'on pense être celle du dispositif.

[[Fichier:IP+MAC.jpg|vignette|151x151px|Adresse IP + MAC du dispositif]]
---

Après plusieurs tentatives avec le réseau du téléphone, on arrive à obtenir la "bonne adresse IP" avec l'adresse MAC du dispositif mais ce dernier n'arrive pas à maintenir une connexion stable (comme affiché sur la capture d'écran ci-dessous).
[[Fichier:Tentatives de ping.png|centré|vignette|480x480px|Tentatives de ping]]

Nous avons alors décidé de changer de réseau et se connecter avec le Wifi <code>WIFI_IA_SE5</code>

On réalise un premier scan du réseau avec l'utilitaire <code>nmap</code> pour voir tous les appareils connectés avec leur adresse MAC correspondante, en espérant trouver notre dispositif connecté à ce réseau.

==== Deuxième tentative ====
[[Fichier:Capture d’écran 2024-12-11 à 14.59.01.png|vignette|345x345px|2ème analyse Wireshark]]
On réessaye de connecter le dispositif en utilisant le réseau de notre smartphone.

192.168.89.183 : Adresse IP du dispositif

192.168.89.186 : Adresse IP du PC effectuant l'analyse

On peut voir des paquets entre le PC et le dispositif, mais pas grand chose du côté serveur.

Étant donné que le smartphone joue le rôle d'un MITM, on arrive pas à capturer des paquets pertinents.

On retrouve en grande partie des paquets de communication entre le PC et le dispositif (comme affiché sur l'image ci-joint).

==== Troisième tentative ====
Cette fois-ci, on utilisera le réseau <code>PLIL</code> pour ne pas avoir notre smartphone comme étant MITM.
[[Fichier:3ème analyse Wireshark.jpg|vignette|3ème analyse Wireshark]]
D'après une analyse approfondie sur Wireshark, on arrive déjà à voir les paquets lors de la première connexion (requêtes <code>SYNC</code>) et d'autres paquets intéressants dès le démarrage du dispositif. Ceci n'était pas possible avant car il y avait le téléphone qui n'affichait pas en quelque sorte les paquets destinés directement au dispositif.

[[Fichier:Analyse @IP1.jpg|alt=Analyse @IP1|vignette|Analyse de l'adresse 3.124.85.154]]
Nous avons pu identifier 2 adresses IP pertinentes (3.124.85.154 et 18.194.10.142) qui sont des serveurs virtuels '''EC2''' appartenant à AWS.

Le premier (3.124.85.154) contient 3 ports (80, 443 et 7010) qui sont ouverts et utilise comme principalement service http/https. (comme affiché sur les captures d'écran).

Le deuxième (18.194.10.142) contient également 3 ports ouverts, dont 1 qui utilise du '''mqtt''' sur le port 1883.

[[Fichier:Screenip18.jpg|vignette|Analyse de l'adresse 18.194.10.142]]
L'idée sera de créer un '''<code>mock server</code>''' avec la même adresse IP, sur notre machine, et essayer de faire passer une communication de paquets via notre machine plutôt que passer par le serveur d'origine. Une fois ceci sera réalisé, nous pourrons commencer à craquer et manipuler le dispositif comme souhaité. --

Membres : '''BILAL EL HASNAOUI''' et '''AYOUB CHAOUNI'''

Fichier:Screenip18.jpg

2025-01-07T21:03:26Z

Achaouni :

Screenip18

Fichier:Analyse @IP1.jpg

2025-01-07T21:02:37Z

Achaouni :

Analyse @IP1

Fichier:3ème analyse Wireshark.jpg

2025-01-07T20:49:46Z

Achaouni :

3ème analyse Wireshark

SE5 ECEAI 2024/2025/elhasnaoui-chaouni

2024-12-28T19:48:27Z

Achaouni : /* Entraînement du modèle d’apprentissage */

=<div class="mcwiki-header" style="padding: 10px; font-family: 'Times New Roman' ; font-weight: bold; color: #0000FF; text-align: center; font-size: 100%; background: #808080; vertical-align: top; height:70%; width: 98%;"> Introduction </div>=
==Objectifs du projet==
Séance 1 (03/09) : Lors de la première séance, nous avons entamé une réflexion sur les différentes idées de projets que nous pourrions développer en utilisant notre carte STM32, pour explorer les possibilités offertes par la carte, en considérant des applications potentielles dans divers domaines, tels que l'automatisation, la reconnaissance de formes ou le contrôle intelligent de systèmes. Ces premières discussions nous ont permis de poser les bases de projets innovants, alignés sur nos objectifs d'apprentissage et les capacités techniques de la STM32.

Par ailleurs, nous avons également configuré notre environnement de travail en installant les logiciels nécessaires, à savoir NanoEdge AI et STM32, afin de pouvoir commencer le développement de nos projets de manière efficace.

=<div class="mcwiki-header" style="padding: 10px; font-family: 'Times New Roman' ; font-weight: bold; color: #0000FF; text-align: center; font-size: 100%; background: #808080; vertical-align: top; height:70%; width: 98%;"> Configuration Réseau </div>=
==Configuration serveur Cloud==

Nous allons créer une machine virtuelle sur Capbreton avec un accès internet IPv6. <br>
Cette machine virtuelle sera déployée grâce à Xen (Hyperviseur) et portera le nom "SE5-elhaschaouni".<br>
La commande lancée pour créer cette machine est la suivante :
<syntaxhighlight lang="bash">
xen-create-image --hostname SE5-elhaschaouni --force --dist bookworm --size 10G --memory 1G --dir /usr/local/xen --dhcp --bridge bridgeStudents
</syntaxhighlight>

===Configuration Réseau===

Nous devrons ensuite configurer son réseau, sa résolution DNS, et ses sources de paquets Debian.<br>
Pour configurer le réseau de notre machine, nous allons modifier le fichier ''/etc/network/interfaces'' qui est un fichier de configuration réseau où sont spécifiés les paramètres de l'interface.
<syntaxhighlight lang="bash">
auto eth0
iface eth0 inet6 auto
</syntaxhighlight>

===Configuration DNS===

Pour configurer la résolution DNS de notre machine, nous allons modifier le fichier ''/etc/resolv.conf''. Ce fichier permet de spécifier la configuration des serveurs de nom (DNS) afin de résoudre les noms de domaine en adresses IP. Voici la configuration DNS à appliquer :
<syntaxhighlight lang="bash">
domain plil.info
search plil.info
nameserver 2a01:c916:2047:c800:216:3eff:fe82:8a5c
</syntaxhighlight>

==Configuration Gateway Raspberry Pi==
==Configuration Microcontrôleur SMT32==

=<div class="mcwiki-header" style="padding: 10px; font-family: 'Times New Roman' ; font-weight: bold; color: #0000FF; text-align: center; font-size: 100%; background: #808080; vertical-align: top; height:70%; width: 98%;"> Communication des objets </div>=
==Communication RaspberryPi & Serveur Cloud ==

La communication entre la Raspberry Pi et le serveur Cloud se fait en utilisant le protocole MQTT. Le serveur Cloud est une machine virtuelle (VM) dans le même sous-réseau que la Raspberry Pi. Nous avons configuré le serveur MQTT Mosquitto en utilisant un Dockerfile pour créer et déployer le conteneur Docker sur le serveur Cloud. Nous avons également développé deux scripts Python pour gérer la communication : '''subscriber.py''' pour le serveur Cloud et '''publisher.py''' pour la Raspberry Pi.

===Déploiement du Serveur MQTT Mosquitto :===
Nous avons créé un Dockerfile pour configurer Mosquitto.<syntaxhighlight lang="bash">
# Utiliser l'image de base de Mosquitto
FROM eclipse-mosquitto:latest
# Fichier de configuration
COPY mosquitto.conf /mosquitto/config/mosquitto.conf
# Exposer le port 1883 pour MQTT
EXPOSE 1883
EXPOSE 9001
</syntaxhighlight>

Nous avons construit l'image Docker à partir du Dockerfile avec la commande suivante :<syntaxhighlight lang="bash">
docker build -t mosquitto-mqtt .
</syntaxhighlight>Puis, nous avons lancé le conteneur Mosquitto avec la commande :<syntaxhighlight lang="bash">
docker run -d --name mosquitto -p 1883:1883 -p 9001:9001 mosquitto-mqtt
</syntaxhighlight>Cette commande démarre Mosquitto en arrière-plan (-d) et mappe le port '''1883''' du conteneur au port '''1883''' de l'hôte (RasberryPI), qui est le port par défaut utilisé par '''MQTT'''.

==Communication STM32 & RaspberryPi==

= <div class="mcwiki-header" style="padding: 10px; font-family: 'Times New Roman' ; font-weight: bold; color: #0000FF; text-align: center; font-size: 100%; background: #808080; vertical-align: top; height:70%; width: 98%;"> Entraînement du modèle d’apprentissage </div> =
L'idée sera de développer un système capable de détecter et de reconnaître les chiffres de 0 à 5, représentés par les positions des doigts de la main.
Pour cela, nous utilisons la carte <code>NUCLEO-F401RE</code> associée au capteur de distance <code>X-NUCLEO-53L5A1</code>, ainsi que '''NanoEdge AI Studio''' pour l'entraînement et le déploiement d'un modèle d'apprentissage automatique.

Les étapes principales du projet sont :

# '''Acquisition des données''' : Nous avons configuré le capteur X-NUCLEO-53L5A1 pour collecter des données sur les distances des doigts, selon différentes configurations de la main correspondant aux chiffres de 0 à 5.
# '''Prétraitement des données''' : Pour nettoyer et formater les données collectées afin de les rendre compatibles avec NanoEdge AI Studio (en utilisant '''Data Logger''') puis les stocker dans un fichier .bin.
# '''Entraînement du modèle''' : Nous avons utilisé NanoEdge AI Studio pour créer et entraîner un modèle basé sur les données collectées, capable de reconnaître les positions des doigts.
# '''Déploiement''' : Intégration du modèle entraîné dans la carte NUCLEO-F401RE et le combiner avec le capteur pour effectuer une détection en temps réel.
# '''Tests et validation''' : Pour évaluer les performances du système (précision, stabilité...) et ajuster le modèle ou les paramètres du capteur si nécessaire.

==Entraînement sur serveur Cloud==

SE5 IdO sécurité des objets 2024/2025 b3

2024-12-11T17:04:34Z

Achaouni : /* Analyse du trafic réseau */

Fichier:Capture d’écran 2024-12-11 à 14.59.01.png

2024-12-11T14:17:11Z

Achaouni :

2ème analyse Wireshark

SE5 IdO sécurité des objets 2024/2025 b3

2024-11-27T16:08:35Z

Achaouni : /* Craquage TempTale Ultra Temperature Sensor */

SE5 IdO sécurité des objets 2024/2025 b3

2024-11-27T16:07:25Z

Achaouni : /* Analyse du trafic réseau */

Fichier:Tentatives de ping.png

2024-11-27T16:05:54Z

Achaouni :

Tentatives de ping

Fichier:IP+MAC.jpg

2024-11-27T15:56:29Z

Achaouni :

IP+MAC

SE5 IdO sécurité des objets 2024/2025 b3

2024-11-27T10:26:44Z

Achaouni : /* Craquage TempTale Ultra Temperature Sensor */

SE5 IdO sécurité des objets 2024/2025 b3

2024-11-13T15:21:02Z

Achaouni : /* Craquage nedis WIFIDS20WT (Détecteur de fumée) */

Fichier:Analyse Wireshark.jpg

2024-11-13T15:16:11Z

Achaouni :

Analyse Wireshark

SE5 IdO sécurité des objets 2024/2025 b3

2024-10-22T15:11:41Z

Achaouni :

SE5 IdO sécurité des objets 2024/2025 b3

2024-10-22T15:10:32Z

Achaouni :

Fichier:Connexion nedis via app.jpg

2024-10-22T15:09:07Z

Achaouni :

Connexion nedis via app

SE5 IdO sécurité des objets 2024/2025 b3

2024-10-22T15:00:25Z

Achaouni :

Fichier:Wiki-3.png

2024-10-22T14:56:57Z

Achaouni :

Successful connection to the target

Fichier:Wiki-2.png

2024-10-22T14:55:32Z

Achaouni :

Connection to target

SE5 IdO sécurité des objets 2024/2025 b3

2024-10-22T13:48:47Z

Achaouni :

Fichier:Connexion L152-Nucleo.jpg

2024-10-22T13:44:02Z

Achaouni :

Connexion L152-Nucleo

SE5 IdO sécurité des objets 2024/2025 b3

2024-10-21T15:59:47Z

Achaouni :

Fichier:Carte TempTale.jpg

2024-10-21T15:57:59Z

Achaouni :

Carte TempTale

SE5 IdO sécurité des objets 2024/2025 b3

2024-10-21T14:53:39Z

Achaouni :

SE5 IdO sécurité des objets 2024/2025 b3

2024-10-21T13:26:19Z

Achaouni :

SE5 IdO sécurité des objets 2024/2025 b3

2024-10-21T13:23:55Z

Achaouni : /* Sécurisation WiFi par WPA2-EAP */

SE5 ECEAI 2024/2025/elhasnaoui-chaouni

2024-09-03T10:15:10Z

Achaouni :

Séance 1 (03/09) : Lors de la première séance, nous avons entamé une réflexion sur les différentes idées de projets que nous pourrions développer en utilisant notre carte STM32, pour explorer les possibilités offertes par la carte, en considérant des applications potentielles dans divers domaines, tels que l'automatisation, la reconnaissance de formes ou le contrôle intelligent de systèmes. Ces premières discussions nous ont permis de poser les bases de projets innovants, alignés sur nos objectifs d'apprentissage et les capacités techniques de la STM32.

Par ailleurs, nous avons également configuré notre environnement de travail en installant les logiciels nécessaires, à savoir NanoEdge AI et STM32, afin de pouvoir commencer le développement de nos projets de manière efficace.

SE5 ECEAI 2024/2025/elhasnaoui-chaouni

2024-09-03T10:06:22Z

Achaouni :

[[Read more ...]]

SE5 ECEAI 2024/2025/elhasnaoui-chaouni

2024-09-03T10:00:58Z

Achaouni :

[...]

SE5 ECEAI 2023/2024

2024-09-03T10:00:16Z

Achaouni :

SE5 ECEAI 2023/2024

Groupe Delannoy - Lemaire : [[SE5 ECEAI/eceai 2023/2024/jcie]]

Groupe Rodenburg - Thomas → [[Gabidann|SE5 ECEAI/eceai 2023/2024/gabidann]]

Groupe Halaoui - Farault : [[SE5 ECEAI/eceai 2023/2024/FaraultHalaoui]]

Groupe Godard - Delcourt : [[SE5 ECEAI/eceai 2023/2024/GodardDelcourt]]

Groupe Naudot - Riffaut : [[SE5 ECEAI/eceai_2023/2024/NaudotRiffaut]]

Groupe Amoros - Delaby : [[SE5 ECEAI/eceai 2023/2024/AmorosDelaby]]

Groupe Charleux - Habre : [[SE5 ECEAI/eceai 2023/2024/CharleuxHabre]]

Groupe Balbastre - Simon : [[SE5 ECEAI/eceai 2023/2024/BalbastreSimon]]

Groupe Patrikeev - Mouton : [[SE5 ECEAI/eceai 2023/2024/Patrikeev-Mouton]]

Groupe Brenier - Nguyen : [[SE5 ECEAI/eceai 2023/2024/Brenier-Nguyen]]

Groupe Vallée - Sellali : [[SE5 ECEAI/eceai 2023/2024/ValleeSellali]]

Groupe Black - Blgrim: [[SE5 ECEAI/eceai 2023/2024/black-blgrim]]

SE5 ECEAI 2024/2025

Groupe Cruchet - Deryckère : [[SE5 ECEAI/eceai 2024/2025/cruchet-deryckere]]

Groupe Wijsman - Lefranc : [[SE5 ECEAI/eceai 2024/2025/wijsman-lefranc]]

Groupe Duhr - Becquet : [[SE5 ECEAI/eceai 2024/2025/duhr-becquet]]

Groupe Ling : [https://wiki-se.plil.fr/mediawiki/index.php/SE5_ECEAI/eceai_2024/2025/ling SE5 ECEAI/eceai 2024/2025/ling]

Groupe Benmbarek - El Qastalani : [[SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani]]

Groupe Elhasnaoui - Chaouni : [[SE5 ECEAI 2024/2025/elhasnaoui-chaouni]]

SE5 ECEAI 2024/2025/elhasnaoui-chaouni

2024-09-03T10:00:01Z

Achaouni : Page créée avec « [...) »

[...)

SE5 ECEAI 2023/2024

2024-09-03T08:54:55Z

Achaouni :

SE5 ECEAI 2023/2024

Groupe Delannoy - Lemaire : [[SE5 ECEAI/eceai 2023/2024/jcie]]

Groupe Rodenburg - Thomas → [[Gabidann|SE5 ECEAI/eceai 2023/2024/gabidann]]

Groupe Halaoui - Farault : [[SE5 ECEAI/eceai 2023/2024/FaraultHalaoui]]

Groupe Godard - Delcourt : [[SE5 ECEAI/eceai 2023/2024/GodardDelcourt]]

Groupe Naudot - Riffaut : [[SE5 ECEAI/eceai_2023/2024/NaudotRiffaut]]

Groupe Amoros - Delaby : [[SE5 ECEAI/eceai 2023/2024/AmorosDelaby]]

Groupe Charleux - Habre : [[SE5 ECEAI/eceai 2023/2024/CharleuxHabre]]

Groupe Balbastre - Simon : [[SE5 ECEAI/eceai 2023/2024/BalbastreSimon]]

Groupe Patrikeev - Mouton : [[SE5 ECEAI/eceai 2023/2024/Patrikeev-Mouton]]

Groupe Brenier - Nguyen : [[SE5 ECEAI/eceai 2023/2024/Brenier-Nguyen]]

Groupe Vallée - Sellali : [[SE5 ECEAI/eceai 2023/2024/ValleeSellali]]

Groupe Black - Blgrim: [[SE5 ECEAI/eceai 2023/2024/black-blgrim]]

SE5 ECEAI 2024/2025

Groupe Cruchet - Deryckère : [[SE5 ECEAI/eceai 2024/2025/cruchet-deryckere]]

Groupe Wijsman - Lefranc : [[SE5 ECEAI/eceai 2023/2024/wijsman-lefranc]]

Groupe Duhr - Becquet : [[SE5 ECEAI/eceai 2024/2025/duhr-becquet]]

Groupe Ling : [https://wiki-se.plil.fr/mediawiki/index.php/SE5_ECEAI/eceai_2024/2025/ling SE5 ECEAI/eceai 2024/2025/ling]

Groupe Benmbarek - El Qastalani : [[SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani]]

Groupe Elhasnaoui - Chaouni : [[SE5 ECEAI/eceai 2024/2025/elhasnaoui-chaouni]]

SE5 ECEAI/eceai 2024/2025/elhasnaoui-chaouni

2024-09-03T08:53:25Z

Achaouni : Page créée avec « [...] »

[...]

SE5 ECEAI/eceai 2024/2025/

2024-09-03T08:51:55Z

Achaouni : Page créée avec « = SE5 ECEAI/eceai 2024/2025/elhasnaoui-chaouni = [...] »

= SE5 ECEAI/eceai 2024/2025/elhasnaoui-chaouni =
[...]

Atelier SysRes SE4 2023/2024 E12

2024-04-16T16:22:47Z

Achaouni : /* Cassage de mot de passe WPA-PSK par force brute */

== Effraction WiFi ==

=== Cassage de clef WEP d’un point d’accès WiFi ===

=== Cassage de mot de passe WPA-PSK par force brute ===
Binôme 7 : AYOUB CHAOUNI & BILAL EL HASNAOUI

- Nous avons réussi à craquer <code>krakotte07</code>, le mot de passe est le suivant : <code>66683666</code>
[[Fichier:Flag.png|alt=Mdp kracotte|centré|vignette|482x482px|[[Mdp kracotte]]]]

- Les étapes de résolution étaient les suivants :

1- On a d'abord lancé la capture des dialogues d'identification avec <code>airodump-ng</code> .

2-

3-
== Sécurisations ==

=== Chiffrement de données ===

=== Sécurisation WiFi par WPA2-EAP ===

Atelier SysRes SE4 2023/2024 E12

2024-04-16T16:20:02Z

Achaouni : /* Cassage de mot de passe WPA-PSK par force brute */

== Effraction WiFi ==

=== Cassage de clef WEP d’un point d’accès WiFi ===

=== Cassage de mot de passe WPA-PSK par force brute ===
Binôme 7 : AYOUB CHAOUNI & BILAL EL HASNAOUI

- Nous avons réussi à craquer <code>krakotte07</code>, le mot de passe est le suivant : <code>66683666</code>
[[Fichier:Flag.png|alt=Mdp kracotte|centré|vignette|482x482px|[[Mdp kracotte]]]]

- Les étapes de résolution étaient les suivants :

1-

2-

3-
== Sécurisations ==

=== Chiffrement de données ===

=== Sécurisation WiFi par WPA2-EAP ===

Atelier SysRes SE4 2023/2024 E12

2024-04-16T16:19:41Z

Achaouni : /* Cassage de mot de passe WPA-PSK par force brute */

== Effraction WiFi ==

=== Cassage de clef WEP d’un point d’accès WiFi ===

=== Cassage de mot de passe WPA-PSK par force brute ===
Binôme 7 : AYOUB CHAOUNI & BILAL EL HASNAOUI

- Nous avons réussi à craquer krakotte07, le mot de passe est le suivant : 66683666
[[Fichier:Flag.png|alt=Mdp kracotte|centré|vignette|482x482px|[[Mdp kracotte]]]]

- Les étapes de résolution étaient les suivants :

1-

2-

3-
== Sécurisations ==

=== Chiffrement de données ===

=== Sécurisation WiFi par WPA2-EAP ===

Atelier SysRes SE4 2023/2024 E12

2024-04-16T16:18:14Z

Achaouni : /* Cassage de mot de passe WPA-PSK par force brute */

== Effraction WiFi ==

=== Cassage de clef WEP d’un point d’accès WiFi ===

=== Cassage de mot de passe WPA-PSK par force brute ===
Binôme 7 : AYOUB CHAOUNI & BILAL EL HASNAOUI

- Nous avons réussi à craquer krakotte07, le mot de passe est le suivant : 66683666
[[Fichier:Flag.png|alt=Mdp kracotte|centré|vignette|482x482px|[[Mdp kracotte]]]]

== Sécurisations ==

=== Chiffrement de données ===

=== Sécurisation WiFi par WPA2-EAP ===