Aller au contenu

Bilan du Projet de Thomas TRESGOTS

Analyse complète, résultats techniques et évaluation de mon projet.

Preuves Techniques

État avant l'attaque
Zoom

État Initial

Avant le lancement, le réseau est stable. Les clients sont connectés et aucune anomalie n'est visible dans les logs.

État pendant l'attaque
Zoom

Perturbation

Dès l'activation, les logs s'affolent. On constate des déconnexions massives et répétées ("Deauthenticated", "Disassociated") indiquant que l'attaque est effective.

État après l'attaque
Zoom

Stabilisation

Une fois l'attaque stoppée, le calme revient instantanément. Les clients négocient à nouveau leur connexion et le service reprend son cours normal.

Capture & Analyse

Pour analyser le comportement du réseau lors de l'attaque, j'ai effectué une capture de trafic avec Wireshark sur un PC connecté au même réseau. L'analyse des trames a permis de mettre en évidence les mécanismes de reconnexion déclenchés par la désauthentification.

Capture DHCP
Zoom

1. Boucles DHCP

J'ai immédiatement remarqué une série anormale de requêtes DHCP. Le client, forcé à la déconnexion, perd son bail IP et tente frénétiquement de le renouveler. On observe clairement la séquence Discover -> Offer -> Request -> ACK qui se répète en boucle tant que l'attaque persiste.

Capture ARP
Zoom

2. "Tempêtes" ARP

Parallèlement aux requêtes DHCP, j'ai constaté un grand nombre de trames ARP ("Who has..."). À chaque tentative de reconnexion, la victime cherche à ré-identifier la passerelle par défaut (Gateway) pour rétablir sa route vers Internet. C'est un indicateur fiable d'une perte de connectivité récente.

Capture Multicast
Zoom

3. Trafic Multicast

Enfin, on note l'apparition de trafic Multicast (IGMP, mDNS) par rafales. Cela correspond aux services de découverte du client (comme Apple Bonjour ou UPnP) qui se rannoncent sur le réseau après chaque reconnexion réussie.

Problèmes Rencontrés & Solutions

Principaux obstacles rencontrés et solutions techniques apportées.

Configuration de l'AP

Le Défi La désauthentification en elle-même n'est pas très compliquée, mais le vrai besoin était un point d'accès dédié et correctement configuré pour mener des tests propres et obtenir des preuves exploitables (stabilité, accès aux logs).

La Solution J’ai configuré un AP Wi-Fi spécifiquement pour les tests en réutilisant les notions de première année. Cela m’a permis d’avoir un environnement stable et de récupérer des traces (logs) pour appuyer les résultats.

Passage de UIFlow à Arduino

Le Défi J'ai initialement tenté de développer la communication LoRa via UIFlow 2. Même si le module LoRa était détecté, le programme ne se lançait jamais. Le passage à UIFlow 1 n'a rien changé : impossible de pousser un code fonctionnel.

La Solution J'ai choisi de basculer définitivement vers Arduino. Le flash a immédiatement fonctionné, la librairie LoRa s'est révélée stable, et la communication radio a enfin pu être exploitée.

Bilan Global : Satisfaction du Cahier des Charges

Analyse critique des résultats obtenus face aux attentes initiales.

Objectifs Atteints ?

Concernant la désauthentification, l’objectif a été atteint : j’ai étudié le fonctionnement du Wi-Fi et documenté un scénario de désauthentification avec un M5StickC Plus2 et un Flipper Zero. Cela m’a permis d’observer l’impact réel, d’en identifier les limites et de proposer des pistes de protection.

Concernant les communications LoRa sécurisées et non sécurisées, l’objectif est également atteint. Pour aller plus loin, il aurait été intéressant de pouvoir altérer les messages interceptés afin de simuler un véritable scénario de Man-in-the-Middle, mais ce n’était pas dans le périmètre ni directement supporté par notre configuration matérielle.

Moyens Adaptés ?

Oui et non. Au départ, nous disposions uniquement du M5StickC Plus2 pour explorer ses fonctionnalités Wi-Fi. Un simple partage de connexion via téléphone suffisait pour les premiers tests, mais cela devenait vite limité pour produire des preuves. J’ai donc pris l’initiative d’emprunter un point d’accès Wi-Fi de l’IUT, avec l’accord de M. Val et M. Martin, afin d’obtenir des logs et des traces exploitables.

En parallèle, j’ai contribué à la partie LoRa menée par Ludovic. Le M5StickC Plus2 ne supportant pas la couche LoRa, il n’a pas pu servir de sniffer/MITM. Nous avons contourné cette limite en utilisant un troisième M5Stack dédié pour l’observation du trafic LoRa.

Leçons et Améliorations

Ce qui a été bien fait : La documentation rigoureuse et la présentation via ce site web permettent de valoriser le travail technique.
À améliorer : Pour aller plus loin, on pourrait mettre en place le principe de PMF (Protected Management Frames) pour empêcher techniquement la désauthentification et vérifier l'efficacité de cette protection.

Coopération

La répartition des tâches a été efficace. J'ai pu me concentrer sur le volet Wi-Fi tout en participant activement à l'interception et l'analyse des communications LoRa. Les points de synchronisation réguliers ont permis d'assurer la cohérence globale du projet et l'intégration fluide de nos travaux respectifs.

Synthèse Personnelle & Autoévaluation

Retour individuel sur l'expérience et justification de la note.

Implication & Sérieux

Coef. 2

Assiduité, respect strict des délais et motivation constante.

Qualité Technique

Coef. 1

Pertinence des solutions proposées, propreté du code et capacité d'innovation.

Travail d'Équipe

Coef. 1

Communication fluide, aide spontanée apportée aux autres et partage de connaissances.

TT
Thomas TRESGOTS

Thomas TRESGOTS

Pack 1
Implication & Sérieux 16/20
Qualité Technique 16/20
Travail d'Équipe 15/20
Note Calculée
15.75 /20

Justification de la note

  • Aspect Technique

    Réalisation d’un scénario de désauthentification Wi-Fi dans un environnement autorisé, avec preuves d'impact (déconnexion/logs AP). Contribution à la partie LoRa : bases d'un échange fiable, ACK, réémissions.

  • Résolution de Problèmes

    La mise en place d'un environnement de test robuste (AP dédié, logs) a été chronophage mais indispensable pour dépasser la simple "observation visuelle" et fournir des preuves techniques solides.

  • Coopération

    J’ai assuré une communication régulière avec l’équipe et apporté mon aide sur différents aspects du projet, notamment en accompagnant Ludovic dans la mise en place des communications LoRa.

Évaluation par les Pairs

Notes attribuées aux autres membres du groupe.

Implication & Sérieux

Coef. 2

Assiduité, respect strict des délais et motivation constante.

Qualité Technique

Coef. 1

Pertinence des solutions proposées, propreté du code et capacité d'innovation.

Travail d'Équipe

Coef. 1

Communication fluide, aide spontanée apportée aux autres et partage de connaissances.

Mattéo Pack 3

Implication & Sérieux 19/20
Qualité Technique 18/20
Travail d'Équipe 17/20
Note Finale
18.25 /20
Justification
Points Forts

Organisation : En pilotant la gestion de projet, Mattéo a su répartir les tâches efficacement et optimiser notre temps. Le découpage en “PACK” a été une excellente idée pour structurer le travail.

Disponibilité : Grâce à sa maîtrise du Secure Element développée sur sa partie MQTT, Mattéo a pu aider pour la partie chiffrement des communications LoRa.

Axe d'Amélioration

Collaboration : Pour aller encore plus loin, il pourrait déléguer davantage certaines tâches (ex. site web) afin d’impliquer plus largement l’équipe.

Ludovic Pack 2

Implication & Sérieux 16/20
Qualité Technique 15/20
Travail d'Équipe 14/20
Note Finale
15.25 /20
Justification
Points Forts

Vidéo : Ludovic a réalisé une vidéo claire et efficace qui synthétise très bien notre SAE en peu de temps.

Recherches : Ses recherches sur le Secure Element, menées en collaboration avec M. Martin, ont apporté une base solide pour l’intégration dans nos communications Lora.

Axe d'Amélioration

Base LoRa : Une implication plus poussée sur la mise en place de la base de communication LoRa (échanges/fiabilisation) aurait facilité l’intégration de la partie chiffrée avec Secure Element.