L’équipe : A défaut d’avoir plusieurs personnalités comme on pourrait l’entendre dans la vidéo rétrospective du CTF 2024, je fus hélas le seul preux chevalier qui mena à bien ce projet et ce à mes dépens.

L’objectif : Créer une épreuve de désamorçage de bombe factice en utilisant une carte ESP32.

Les temporels : 3 jours pour concevoir, prototyper, tester et réaliser le produit fini.
Initialement prévu sur une période de 3 mois en parallèle de mon Erasmus en Finlande, les composants provisionnés sur les fiches d’achat et de budget d’avril 2024 ont été reçus 3 jours avant l’événement, faute de logistique rodée.

Cette épreuve s’inscrivait dans une continuité de toute une campagne d’épreuves suivant le fil conducteur d’une histoire fictive où une attaque réalisée par des hacktivistes pouvait potentiellement paralyser la cérémonie des JO de Paris.
Les participants devaient déceler tous les “flags” en réussissant les différents challenges afin d’accéder à l’ultime épreuve de désamorçage.

Un projet réalisé autour de 5 éléments:

• Un panneau de diodes électroluminescentes à couleur variable 8×8
• Un clavier 4×4 Touches Alphanumériques
• 5 paires de fiches “bananes” colorées
• Un écran LCD I²C 16×2
• Un microcontrôleur ESP32 Espressif S3 Devkit C, choisi pour son inclusion plus large des librairies C et C++ comme “Vector”

Librairies utilisées:

• Librairie Wi-Fi pour la mise en mode point d’accès de l’ESP-32.
• Librairie AsyncTCP afin d’autoriser plusieurs administrateurs du CTF à se connecter à l’interface de configuration et de suivi.
  Auteur : Me No Dev Références 
• Librairie Keypad afin de convertir le comportement résistif des touches du clavier en une lettre ASCII.
  Auteur : Mark Stanley, Alexander Brevig Références
• Librairie NeoPixel afin de gérer le panneau led RGB 8×8.
  Auteur : Adafruit Références
  
• Librairie Wire pour la gestion du protocole I²C.
• Librairie LiquidCrystal I²C afin de gérer l’afficheur LCD.
  Auteur : Frank de Brabander Références
  

Cette épreuve se déroulait en 3 parties :

1. La première consistait à résoudre un labyrinthe aux murs invisibles suivant un modèle prédéfini et donné lors de la résolution des défis de campagne.

2. La seconde consistait à saisir un code récupéré lors d’un autre challenge de la campagne d’influence sur le pavé numérique.

 

3. La troisième consistait à déconnecter les fiches bananes suivant un ordre bien précis divulgué sous forme de poème lors de la résolution d’un challenge de campagne.

Mieux que des mots, voici la vidéo explicative sous forme de “tutoriel” à destination de l’équipe CTF d’Angers.

——-

Allons découvrir l’envers du décor.

Dans un premier temps, j’ai effectué une simulation sur la plateforme Wokwi afin de simuler le système réel:
La simulation est composée des mêmes éléments que le système physique

– ESP 32 Espressif

– Keypad

-Buzzer

-Panneau LED 8×8

– Switchs

Grâce à wokwi premium, j’ai pu simuler l’interface web de contrôle pour les organisateurs stockée dans la mémoire du contrôleur ESP32. Son utilisation est simple:

– Les organisateurs sélectionnent un motif de labyrinthe que le participant devra résoudre lors de l’épreuve.

– Un temps de compte a rebours est défini en fonction de la difficulté choisie.

– Les organisateurs lancent ensuite le compte à rebours. L’épreuve débute !

J’ai codé le système sur un principe de machine à états évoluant en fonction des réussites des épreuves par l’utilisateur

Parmi ces états on retrouve

– Un état d’attente IDLE “ENATT” où la bombe rentre en mode configuration.

– Un état “MAZE” où les utilisateurs doivent résoudre la première épreuve

– Un état “CODE” exhaustif sur sa fonction.

– Un  état “CABLES” pour l’épreuve de déconnection des câbles en un instant précis.

– Un état “KABOOM” où la bombe fictivement rentre en mode explosion.

– Un mode “REUSSI” où la bombe délivre son flag de réussite.

Voici le squelette de la machine a état contrôlant le système:

Remarque : l’état “lock” me permet d’éviter de rafraîchir l’écran LCD durant chaque cycle d’horloge.

En termes de variables, les labyrinthes étaient codés “en dur” dans la mémoire non volatile :

Il en allait de même pour la page web auto-hébergée de manière asynchrone (utilisant la librairie ESPAsyncWebServer) par l’ESP-32 mise en mode point d’accès Wi-Fi.

La première épreuve de résolution d’un labyrinthe faisait appel à la librairie KeyPad : on convertissait l’appui sur une touche en caractère alphanumérique puis on mettait à jour la position réelle du joueur au sein du labyrinthe en vérifiant que sa saisie était correcte.
A chaque saisie correcte, on mettait à jour le panneau LED par simple balayage de pixel rgb suivant l’adressage ligne, colonne facilité par la librairie NeoPixel d’Adafruit : la couleur verte était attribuée à l’entrée, le rouge à la sortie et le bleu au joueur.

La seconde épreuve faisant appel au même processus décrit pour la première épreuve, on stockait dans un variable tampon la saisie de l’utilisateur puis on vérifiait lors de l’appui sur la touche “#” si la combinaison correspondait à celle enregistrée dans une variable en mémoire non volatile.

La troisième et ultime épreuve de ce challenge CTF2024 demandait précision et rapidité de la part des joueurs.
De mon côté j’ai organisé mon code de manière à ce qu’aucune tentative de contournement ne puisse être mise en oeuvre.
Il fallait donc coder selon 3 critères :

– Le premier était celui du temps où aucune déconnexion de fils ne devait être tolérée avant la fin du temps imparti.

– Le second était de laisser une marge d’erreur au joueur : le temps de réaction d’un humain étant de 250ms, 300ms de battement était alloué à la fin du décompte final avant de vérifier la déconnexion des fils.

– Le troisième était de vérifier si les fils déconnectés correspondaient à ceux mis en mémoire.

Un affichage de “courtoisie” mentionnait les secondes restantes avant la fin d’une vague de déconnexion, ce sur lequel venait s’additionner une séquence de bips sonores, rajoutant du stress à l’épreuve.

Conclusion & Prise de recul

Cette expérience de conception d’une solution m’a permis de développer et renforcer mon panel de compétences. Sur le plan des compétences développées, j’ai pu appliquer mes acquis en C++ et en électronique. Cette application s’est déroulée en deux phases : la première s’étendant sur la conception d’un prototype et d’une simulation virtuelle, la seconde correspondant à la réalisation du produit final clé en main. Aucune de ces deux phases ne m’a posé de points bloquants, la principale difficulté étant de gérer les imprévus et de changer le modèle en temps réel. La fragilité des claviers fut mise à l’épreuve lors du collage des éléments sur le support final, ce qui engendra un dysfonctionnement de plusieurs touches. Un simple ajustement de code a suffi à régler le problème.

 

La partie la plus complexe de ce projet fut la gestion du temps, de la communication et du projet en lui-même. Rendre un livrable dans les temps pour un projet ayant pris deux mois de retard faute de logistique rodée était ma source de motivation. J’ai pu ainsi développer ma résistance au stress, car aucune personne de l’équipe du CTF n’aurait pu valider ou remettre en question quelconque tournure du projet, étant la seule personne maîtrisant ce domaine au sein de l’équipe d’organisation.

En prenant du recul, je souhaite pour le futur m’entourer d’une équipe afin de pouvoir polariser mes idées et surtout pouvoir augmenter la marge de sûreté d’un projet. J’aime tutoyer l’impossible, ce qui fut mis à rude épreuve lors de deux nuits blanches, mais il me paraît primordial de pouvoir être épaulé afin de prévenir tout risque et de mieux répartir les taches à réaliser lors de futurs projets d’une envergure tout autre.