19
sept.
'19

Challenge Black Badge leHACK 2019: le vainqueur

Publié le 19 septembre 2019

Lors de la première édition de leHACK qui a eu lieu en juin dernier, tous les participants se sont vu remettre un badge électronique assez minimaliste. Ce badge était constitué d'une LED et de ce qui ressemblait à une antenne. Et quelques petits trucs en plus, sensiblement cachés dans le circuit imprimé.

Premières fausses pistes

Ce n'était pas le premier challenge lié au badge que je réalisais, mais celui-ci a eu tout de même son lot d'erreurs. La plus grosse fut de ne pas mettre directement, comme je l'avais fait il y a deux ans, un indice ou un lien vers le début du challenge. Du coup, tous ceux qui s'y sont collés n'ont pas vraiment su par où commencer, et bon nombre d'entre eux ont repéré l'indice placé sur le badge: "Place me somewhere and be enlightened". Aussi se sont-ils empressés de chercher où placer le badge, harcelant le staff et moi-même pour avoir un indice permettant de localiser l'endroit en question.

Et il y a ceux qui ont cru que l'antenne était une antenne NFC (il y avait de quoi s'y méprendre), et qui ont essayé de "lire" le badge avec différentes applications. Ce qui a eu pour conséquence de faire clignoter la LED, avec un motif propre au fonctionnement du NFC. Certains ont pris cela pour le début du challenge, et ont ainsi cherché à décoder la trame, qui n'était qu'une conséquence de la tentative de communication du téléphone avec le badge. Ce dernier ne répondant bien évidemment pas.

J'ai ainsi rectifié le tir via un tweet indiquant qu'il y avait un indice pour identifier l'endroit où démarrait le challenge, qu'il s'agissait d'une URL, mais que ce n'avait rien à voir avec le texte. On était déjà l'après-midi, la journée était bien entamée.

Finalement, plusieurs participants ont tiqué sur la présence de mon avatar sur le circuit imprimé, et sont allé chercher du côté de ce blog. D'autres ont juste pensé qu'il s'agissait d'une sorte de signature, là encore un manque de clareté de ma part dans la conception de ce challenge.

Les différentes étapes

Quand j'ai pensé à ce challenge black badge, je voulais qu'il y ait différentes techniques et connaissances mises en oeuvre. Pour varier les plaisirs, mais aussi pour amener les participants sur des terrains qu'ils ne connaissent pas forcément, bien qu'il n'y ait rien eu de super exotique en soit. Les étapes étaient donc les suivantes:

  • Une petite épreuve de stéganographie des familles, avec un fichier polyglote très simple (coucou Ange !) et une truc moins sympa pour trouver l'URL de l'épreuve suivante ;
  • Un peu de cryptographie, là encore rien de très difficile si l'on connaît les différents modes d'opération ;
  • De la rétro-ingénierie de firmware, avec du nRF51822 et du Micropython dedans ;
  • Une capture radio d'une émission de données, à analyser avec certains outils dont je parlais (oh surprise) dans mon talk ;
  • Une devinette finale qui imposait de m'envoyer par email tout un ensemble d'informations répondant à celle-ci.

Je ne vais pas entrer dans les détails de la résolution de ces épreuves car différents write-ups ont été écrits et publiés par les participants (liens plus bas), mais je vais élucider certains points techniques et l'origine de certaines étapes.

Tout d'abord, la seconde étape. Je voulais intégrer une épreuve de cryptographie abordable, pas techniquement très complexe mais qui joue avec la manière dont elle est mise en oeuvre plutôt que la robustesse des clés ou des algorithmes. Disons que le bruteforce c'est bien, mais l'objectif était d'amener une vulnérabilité moins triviale qu'une clé de chiffrement facilement devinable (ou factorisable), et des concepts de mathématiques rebutant le débutant. Il m'a semblé intéressant d'explorer les modes d'opération, car tout le monde connaît le mode CBC (on dit un grand "merci" aux attaques par oracles de padding), mais je me suis rendu compte que les autres modes étaient un peu délaissés. j'ai donc opté pour une épreuve basée sur le mode CTR, qui est méconnu de certains bien que très utilisé (notamment dans divers protocoles utilisant de l'AES-GCM ou de l'AES-CCM).

De même, il me semblait inévitable de réaliser une épreuve de rétro-ingénierie de firmware. Le souci, c'est que le RE d'instructions ARM est devenu mainstream et qu'avec la sortie de Ghidra, eh bien c'est devenu beaucoup plus simple. J'ai alors pensé à une fonctionnalité que j'avais découvert quand je bossais sur le développement de Radiobit: les frozen modules. Le système Micropython, que l'on trouve notamment sur le Micro:Bit, permet lors de sa compilation d'intégrer des modules complémentaires développés en Python, mais de façon native. Un outil permet alors de transposer le code python du module en question en code C, et de le compiler et de l'intégrer aux bibliothèques de base. Bien sûr, le code C contient le bytecode du module ainsi que des métadonnées, et donc toutes les informations pour désassembler et interpréter le code du module (méthode pour les furieux). Par ailleurs, le code principal de cette troisième étape en a fait buggé plus d'un: on a bien le code Python du programme principal, mais pas de trace du module crackme ! Plusieurs solutions utilisant différentes techniques ont été trouvées, dont certaines assez originales. Je vous laisse lire les write-ups pour vous faire une idée des différentes méthodes. Cette étape a été la plus difficile à résoudre, beaucoup de participants l'ayant téléchargée mais peu résolue durant l'évènement.

L'étape suivante, la quatrième donc, consistait à aller au stand de digital.security et de demander la "boîte magique", une boîte spécifiquement conçue pour utiliser l'antenne du badge pour transmettre une donnée via un signal lumineux. Seulement voilà, il y avait un hic. Ma super boîte magique n'a pas supporté le voyage, et ne voulait plus faire allumer la LED du badge. J'ai passé quelques heures à debugger le truc, sans succès, puis j'ai indiqué aux personnes du stand de renvoyer ceux qui demanderaient cette boîte vers moi (via Twitter ou e-mail). Bizarrement, personne ne m'a contacté durant l'après-midi ou dans la nuit. Le troisième niveau aura eu raison de la majorité des participants.

J'ai donc, durant les jours suivants, distribué par Twitter et autres médias l'URL de la cinquième étape: un fichier de capture radio effectué via un SDR. L'objectif était clairement d'extraire le contenu de la communication. Là encore, rien de difficile pour qui connaît le domaine, mais c'est loin d'être le cas de la majorité des hackers présents: ces derniers savent utiliser GQRX ou des outils similaires, mais quand il faut enchaîner les blocs GNURadio, c'est une autre histoire. Avec la bonne méthode d'analyse (subtilement abordée dans mon talk de leHACK), cela allait tout seul et l'extraction ne posait plus trop de problème. On trouvait alors un lien vers l'épreuve finale: la devinette de la mort.

La devinette de la mort était la suivante:

Already there when I started to hack, it is nowadays gone and will never come back. This platform was once among the bests, providing an early hacking contest and amazing tasks to solve without a rest.

Show me your abilities by telling me what this platform is. But don't yell it here, just whisper it to my ear, show me what it did look like, show me what I did look like at this time, and the black badge will no longer be mine.

Virtualabs

L'objectif était donc d'identifier une plate-forme où j'ai découvert le hacking, de me montrer à quoi elle ressemblait, et à quoi je ressemblais à cette époque (histoire de ressortir les photos dossier).

Le vainqueur

La première personne à m'avoir fourni tous les éléments, et je dis bien TOUS les éléments, est Vincent Dehors. Bravo à lui, il remporte le Black Badge leHACK 2019 ! Il y aura peut-être un visuel dans les semaines à venir, qui sait.

Write-ups

Encore bravo à vous deux d'avoir complété la majorité de ce challenge, j'espère que vous l'avez apprécié !

04
sept.
'19

Analyse forensique du crash d'un aéromodèle radio-commandé

Publié le 04 septembre 2019

Cela va faire presque deux ans que je pratique à nouveau l'aéromodélisme. Je suis tombé dedans à 14 ans, et j'avais du laisser cette activité en suspend lorsque j'entamais mes études supérieures. Il y a environ deux ans, je décidais de m'y remettre et faisais alors l'acquisition d'un avion radiocommandé thermique, car mes précédents modèles n'étaient pas terminés et avaient fini en bois de chauffage (ou presque). Tout se passait bien, jusqu'à la séance de la semaine dernière où mon avion s'est lamentablement écrasé dans un champ. C'est l'occasion de mener une petite enquête style BEA afin de trouver l'origine de l'accident.

Le crash

Je m'étais installé tranquillement sur le terrain du club (homologué DGAC), et j'ai entamé cette session de vol par la vérification du modèle. Cette étape est obligatoire, durant laquelle on effectue un ensemble de vérifications avant le vol. Les pilotes d'avions grandeurs (des "vrais" avions, les chanceux) suivent exactement le même procédé avant chaque vol. Je vérifie ainsi le bon état des servomoteurs, des connections électriques et électroniques, ainsi que l'état des commandes de gouvernes, les serrages des vis, etc. Tout est passé au crible avant la mise en route du modèle, afin d'éviter toute surprise en vol.

L'avion paré pour la session de vols

J'effectue ensuite plusieurs vols afin de m'entraîner aux atterrissages, car c'est une phase qui est relativement sensible et que je dois en particulier travailler. Oui, j'ai appris à piloter assez récemment, et ceci fait partie de l'entraînement du débutant. Tout se passe bien jusque là, mes atterrissages ne sont pas parfaits mais l'avion se pose en un morceau et en douceur à chaque fois. Après avoir usé un plein de carburant, je remplis à nouveau le réservoir et entame une autre série de vols, toujours dans l'optique d'affiner ma technique d'atterrissage.

Je pose l'avion une fois et je repars dans la foulée (un "touch and go"), j'entame une autre approche et me rend compte que cela va être difficile de poser. En effet, l'avion arrive trop haut et si je prends la décision de poser, il terminera sa course en dehors de la piste et certainement dans un sale état. Dans ce cas de figure, l'usage veut que l'on remette les gaz à fond et que l'on prenne de l'altitude, ce que je fais. Enfin, l'avion reprend de la vitesse mais reste en phase de descente. La commande de profondeur, qui gère l'inclinaison de l'avion, ne semble plus répondre. Je vois ainsi l'avion foncer plein gaz vers le sol, en légère descente, avec pour conséquence un crash assuré.

En dernier espoir et vu qu'il me restait encore un peu de marge, je décide de m'acharner sur la commande de profondeur. Et elle se remet à fonctionner ! L'avion cabre un peu brusquement et reprend de l'altitude. Malheureusement, vu que j'étais en panique j'ai un peu forcé sur la commande et du coup il risque le décrochage, et là encore c'est le crash assuré. J'essaie d'ajuster l'inclinaison en faisant piquer légèrement l'avion, mais rien n'y fait. C'est le décrochage. L'avion se met à piquer vers le sol, et je n'ai pu que couper les gaz et observer le résultat: un bruit sourd fait de bois qui craque, de toile qui se froisse et de moteur qui s'écrase dans la terre. Je ramasse les restes dans le champ voisin, je mets le tout dans la voiture et rentre chez moi.

Un avion au tapis, un !

Analyse de l'accident

Une fois à la maison, je tente de rassembler mes souvenirs. Pas facile, tout cela s'est déroulé en un temps relativement court, et je crois me rappeler de choses qui au final ne sont peut-être pas arrivées. Pendant un temps je pensais que la commande des gaz ne répondait plus, mais après quelques jours j'étais à nouveau persuadé qu'elle fonctionnait bien (cf. les faux souvenirs).

Tout comme le BEA mène l'enquête lors d'accidents ou d'incidents impliquant des aéronefs, je décidais de chercher l'origine du mien. A ce stade de l'enquête, je suspecte tout de même plusieurs organes d'être à l'origine du dysfonctionnement: le récepteur peut avoir cafouillé, les servomoteurs être tombés en panne, ou les commandes des gouvernes peuvent avoir lâché.

Première étape, analyser les commandes des gouvernes. Un problème mécanique est si vite arrivé, bien que j'ai vérifié ces dernières avant le vol. Aucune surprise de ce côté là, tout est bien fixé et rien n'a lâché. Cela ne semble pas venir de la mécanique. Je passe ensuite au récepteur, l'alimente de nouveau et vérifie la connexion avec la radiocommande. Pas de perte au niveau de cette dernière, et un servomoteur branché sur les gaz répond très bien. Je teste avec le même servomoteur l'ensemble des commandes, et tout fonctionne comme prévu. Le récepteur est donc peu susceptible d'avoir eu un défaut de fonctionnement, mais un défaut de réception n'est pas à exclure. Enfin, je reconnecte tous les servos au récepteur (à l'exception des ailes) et vérifie le fonctionnement de ces derniers. Et là, surprise ! Le servomoteur gérant la profondeur ne répond pas. Pire, lorsqu'il est actionné manuellement, il bouge et se bloque de manière intempestive !

Il ressort ainsi plusieurs hypothèses des premières constatations. La première hypothèse formulée est que le récepteur a eu des difficultés à recevoir les signaux de ma radiocommande. La seconde est que le servomoteur de la profondeur a eu un défaut de fonctionnement. La troisième est que la panne a été causée par un évènement inconnu qui n'a pas survévu au crash. Parmi ces hypothèses, la première est très peu probable car au moment de l'atterrissage, ma radiocommande était proche de l'avion. La troisième est très difficile à déterminer car elle nécessite une inspection minutieuse des débris, ce qui est plus complexe à faire sur un modèle réduit que sur un véritable avion. Imaginez, un modèle réduit n'utilise pas de tôle pour ses parois mais une simple toile tendue... Je décide donc de creuser la seconde hypothèse.

Analyse du servomoteur défectueux

Le servomoteur en question est un HS-311 conçu par Hitec. Ce type de servomoteur est peu onéreux et réputé pour être fiable, et est utilisé par de nombreux modélistes. Avant d'entrer dans les détails de l'analyse, quelques rappels sur le fonctionnement des servomoteurs.

Un servomoteur est un système électromécanique permettant de convertir une information de position (la commande transmise) en mouvement mécanique asservi (la position du pignon). Le servomoteur a donc un moteur pour provoquer le mouvement mécanique couplé à un capteur de position, généralement un potentiomètre relié aux pignons du mécanisme de réduction. Le servomoteur est ainsi capable de faire tourner le moteur dans un sens ou dans l'autre, en fonction de la position à atteindre. Son système de pignons de réduction permet d'assurer un certain couple et une résistance aux efforts.

Je décide alors de démonter intégralement le servomoteur, afin d'isoler l'électronique de la mécanique. Je mets de côté le circuit imprimé qui contrôle le moteur à courant continu, et dessoude le moteur. Dans un premier temps, je me concentre sur le moteur: je câble directement le moteur sur une batterie, et tente d'appliquer un effort sur le pignon principal. Et là, j'arrive à stopper la rotation du moteur, ce qui n'est pas du tout normal. En effet, le moteur devrait se remettre à tourner mais au lieu de cela, il reste immobile. On dirait bien que le moteur est à l'origine du problème.

Je démonte alors le moteur à coups de pince, et à l'aide d'une dose de force et de subtiles coups donnés sur l'axe arrive à le démonter intégralement. Si vous n'avez jamais vu l'intérieur d'un moteur à courant continu, les photos ci-dessous vous éclaireront.

Rotor monté sur le socle

Stator du moteur

Il s'agit d'un moteur à pinceaux (ou moteur "brushed"), qui font contact avec une bague spécifique (le commutateur) qui alimente ensuite les différentes bobines et fait tourner le rotor. Le stator quant à lui est simplement composé d'un gros aimant. Le moteur ici présent possède un rotor constitué de trois bobines, chacune ayant un contact dédié sur l'axe du rotor avec lequel les pinceaux sont en contact.

Vérifions le bon état des bobines, pour cela je mesure la résistance à l'aide d'un multimètre. Si cette résistance est non-nulle (une dizaine d'ohms) cela signifie que la bobine est opérationnelle. Si cette dernière est nulle ou infinie, cela signifie que la bobine a fondu (court-circuit) ou que le fil est rompu à un endroit. Dans mon cas, il se trouve que deux bobines ont une résistance infinie, et donc que leurs bobinages sont rompus.

La conséquence de ce défaut est triviale: pour une position spécifique du rotor du moteur, la bobine associée ne produira aucun champ magnétique et donc aucun mouvement. Ceci dit, le rotor a une certaine inertie et en temps normal celle-ci permet de passer au delà du bobinage défectueux et de garder le moteur en rotation. Cependant, si le servomoteur s'arrête sur une bobine défectueuse, cela va causer une défaillance dans le couple et potentiellement un arrêt du moteur. Autrement dit, le moteur ne redémarrera pas si ce dernier est déjà arrêté avec les pinceaux alimentant une ou deux bobines défectueuses.

Recherche de l'origine du défaut du moteur

Si l'on cherche sur Internet les spécifications du moteur, on tombe au bout d'un moment sur un moteur à l'allure très proche, le JL-RF020 de Shantou Jiali Micro Motor Co. Ltd, qui possède les mêmes dimensions et la même allure:

Vue de face du moteur trouvé dans le servo

Et voici la fiche technique du JL-RF020. Jugez de la ressemblance:

Fiche technique du moteur JL-RF020

Le moteur est ainsi annoncé avec une tension nominale de 4.5 volts et une tension maximale de 5.5 volts. Etrange, car la fiche technique du servomoteur indique que ce dernier accepte une tension d'alimentation allant de 4.8 volts à 6 volts. Cette tension d'alimentation est appliquée à chaque bobine du moteur, sachant que deux bobines sur 3 sont alimentées en permanence. A l'aide de mon multimètre, j'ai mesuré la résistance de la seule bobine restante: environ 14 ohms. Cela donne un courant maximal pour le moteur de:

I = U/R = 6.0 / (1/((1/14)+(1/14)) = 0.857 A

Chaque bobine est parcourue par un courant de 430 mA environ lorsque le servomoteur est soumis à une tension de 6 volts. Une rupture du fil de bobinage d'une bobine de moteur est très probablement due à une surintensité, ce qui a pour conséquence de faire fondre ce dernier et de couper le circuit. Comme un fusible. La résistance de la bobine étant fixe, seule une tension plus élevée que 6 volts peut provoquer une intensité supérieure à 430 mA.

La tension relevée sur l'accu NiMH utilisé dans mon avion était de 6.7 volts au moment du crash. Cette tension était relevée en temps réel et affichée sur ma radiocommande dans les informations de télémétrie. Calculons l'intensité du courant fourni au moteur:

I = U/R = 6.7 / 7 = 0.957 A

Une telle intensité est au-delà de ce que peut supporter le moteur. Si l'on regarde l'intensité maximale que peut supporter le fil du bobinage, en nous basant sur son diamètre (0.18mm), on peut se rendre compte que ce dernier tolère au maximum 430 mA, soit approximativement l'intensité parcourant le bobinage lorsque le moteur est alimenté en 6V.

Si l'on alimente le moteur avec 6.7V, l'intensité parcourant le bobinage provoque un échauffement qui peut être fatal au moteur. Cependant, le fil met du temps à chauffer et fondre, et il faut que cette intensité traverse le fil durant une certaine période de temps.

Origine de la surintensité

Tout porte à croire que le servomoteur a été victime d'une surintensité qui a provoqué la rupture d'un fil de bobinage du moteur et le blocage de ce dernier. Mais comment ce servomoteur s'est-il retrouvé alimenté par une tension supérieure à la tension maximale de fonctionnement (6V) ?

J'utilise un accumulateur NiMH ("Nickel - Metal hydride"), qui est composé de 5 cellules. Chaque cellule délivre 1.2V, soit 6V au total. Mais ça, c'est dans le meilleur des mondes. Car lorsque l'on charge une batterie NiMH, les cellules peuvent être chargées jusqu'à environ 120% de leur capacité, soit 1.44V chaque. Ce qui donne une tension de sortie de 7.2 volts, au lieu des 6 volts nominaux. De fait, l'emploi de cet accumulateur lorsqu'il est pleinement chargé augmente les risques de rupture du fil de bobinage du servomoteur provoqué par une surintensité.

Il aurait mieux fallu choisir un accumulateur de 4.8 volts (composé de 4 cellules), dont la tension maximale fournie à pleine charge est de 5.8 volts, ce qui ne risque pas d'endommager le servomoteur. Le site sur lequel j'ai acheté l'avion en question recommandait l'accumulateur de 6 volts, je n'ai pas forcément cherché à vérifier les spécifications de ce dernier et ai donc suivi les recommandations du vendeur.

Conclusion

Après investigation, le moteur du servomoteur gérant la profondeur a subi une surintensité qui a amené deux des trois bobinages du rotor à se rompre, provoquant un dysfonctionnement du servomoteur. La commande de profondeur étant très sollicitée notamment lors des phases d'atterrissage, la probabilité d'un défaut de ce servomoteur était relativement élevée.

Une pleine charge de l'accumulateur de réception a amené ce dernier à fournir une tension supérieure à la tension maximale supportée par les servomoteurs, ce qui est probablement à l'origine de la surintensité qui a causé la défaillance.

Avant cette session de vol, j'avais chargé à bloc l'accumulateur de réception bien que ce dernier ait été peu utilisé lors de la session précédente. Habituellement, l'accumulateur fournit une tension autour de 6 volts (entre 6 et 6.2 volts) car je le chargeais rarement au maximum. C'est donc ma méconnaissance du fonctionnement des accumulateurs NiMH et le fait que je n'ai pas consulté la documentation du constructeur du servomoteur qui sont à l'origine de ce crash.

Leçon apprise.

Failure is always an option
12
août
'19

De retour de DEFCON 27

Publié le 12 août 2019

J'ai eu (encore) la chance de participer en tant que speaker à DEFCON cette année, qui se déroulait dans les centres de convention des casinos Paris, Bally's, Planet Hollywood et Flamingo. Pour ceux qui ne connaîtraient pas cet évènement, je vous invite à visionner le documentaire qui a été réalisé pour les 20 ans de celui-ci, qui est téléchargeable sur leur serveur média.

DEFCON dystopia

Plus gros, plus grand, plus diversifié ...

Chaque année DEFCON grandit, s'étend de plus en plus, accueille de plus en plus de personnes (30 000 âmes en ce qui concerne l'édition 2019), de challenges, de villages qui ne sont rien d'autres que des évènements dans l'évènement. Autant dire qu'il est impossible de tout voir ou de tout faire durant les quatre jours que dure la conférence. Cela signifie aussi que DEFCON s'ouvre à un public plus large, moins averti, et pas toujours au fait des traditions. On voit ainsi des gens qui filment les participants avec leurs smartphones, ou font des selfies sans se soucier de savoir si des personnes étant dans le cadre sont d'accord pour les publier sur Facebook, Instagram ou Twitter. Et du coup, ça agace certaines personnes qui ne manquent pas de le faire savoir. Et je ne parle même pas de ce type que j'ai vu passer dans un couloir du centre de convention avec un stylo caméra, et qui le tenait bien devant lui pour filmer (oui, un stylo caméra cela se remarque très facilement).

Toujours est-il que cette édition était touffue: énormément de villages, de talks, de workshops, de challenges divers, difficile de tout voir ou de tout tester. J'ai particulièrement apprécié le village Hack The Sea et celui de l'Aviation, des domaines moins connus mais où la sécurité est aussi de mise et implique des systèmes peu communs. Par exemple, un village entier était destiné aux drones et aux moyens de les pirater. Des drones étaient à disposition, et quelques-uns volaient au dessus des personnes présente dans le village. La règlementation ici aux US est différente de la notre (qui a été votée en 2018, pour rappel).

Dronewarz

Un autre village impressionnant est le Car Hacking Village. On y trouve deux voitures faisant partie d'un CTF, ainsi que des simulateurs de postes de conduite ne demandant qu'à être piraté via des bus CAN ou autres. Lors du dernier jour, une des voitures a été pas mal abîmée, notamment à coup de masse et de boule de bowling.

DEFCON Car hacking village

D'autres villages, comme l'ICS village, étaient aussi très intéressant, et offrait l'occasion de s'attaquer à des systèmes industriels simulés via quelques CTFs. Des talks étaient aussi présents sur ce village, abordant des sujets comme le pentest en environnement industriel ou des spécificités comme certains protocoles propres à ces systèmes.

ICS village

Le badge officiel de DEFCON a cette année été conçu par Joe Grand (a.k.a Kingpin), et présente un tournant dans l'histoire des badges DEFCON. En effet, celui-ci a été pensé pour être un bijou plutôt qu'un badge. Joe Grand a ainsi découvert le monde de la fabrication de bijoux, et en particulier celui du taillage de pierre, qui est je dois l'avouer assez impressionnant. Les quelques 28 500 badges Human vendus à DEFCON possèdent une pierre de quartz brésilienne taillée et montée à la main. Il n'y a pas un badge identique, chaque pierre étant unique.

Le badge reste un badge électronique, avec un challenge présent dessus que plusieurs hackers se sont empressés de résoudre. Un lecteur de badge était par ailleurs disponible afin de vérifier l'état d'avancement de ce dernier.

Badge reader

... et plus weird

Je n'arrive pas à me l'expliquer, mais j'ai eu du mal à me sentir à ma place cette année. Un truc bizarre au fond de moi qui m'a amené à m'isoler plutôt qu'aller à la rencontre des gens. Le pire dans cette histoire, c'est que je ne sais pas si c'est dû à ce que devient DEFCON ou à ce que je deviens moi (oui car voyez-vous, on ne se voit pas devenir con/crétin/idiot). Plusieurs fois je me suis assis par terre dans un couloir, avec mon ordinateur portable sur les genoux, à développer ou m'occuper à d'autres tâches qui n'ont rien à voir avec l'évènement. J'en ai eu assez de ces casinos, de cette ville de Las Vegas avec ses facettes bling bling et l'envers du décor qui au final est peu glorieux, de cette foule qui célèbre la grande messe du Hacking à base de fiestas, de pool parties et d'excès en tout genre. Désolé, je n'étais pas d'humeur.

A cela s'ajoute le sentiment de ne pas être à la hauteur, de ne rien savoir, d'autant plus lorsque l'on voit la diversité des domaines et techniques abordés dans les différents talks, challenges et villages. Je me sens rouillé, plus à la page, pas capable de résoudre des challenges simples, et je vais buter sur des trucs relativement idiots. Tenez, à votre avis qui a tenté (en vain) de résoudre le seul challenge de stéganographie du dernier CTF de Hack.lu, bien que le premier indice caché indiquait qu'il n'y avait pas de solution ? Bibi. Ce qui a bien fait rire un membre des Fluxfingers qui m'a vu m'arracher les cheveux dessus.

Quant à ma prestation à DEFCON 27, je n'en suis que partiellement satisfait. J'ai encore un mal fou avec les mêmes dans les slides: j'essaie de faire des trucs rigolos mais ça ne fait rire personne. Ajoutez à ça la différence culturelle (on est aux USA), cela rend la tâche encore plus ardue. Si ma carrière se termine en infosec, je sais au moins que je ne pourrais pas me recycler en comique. Loin de là. De plus, mon anglais est loin d'être parfait et je me force à ne pas préparer ce que je vais dire mais à tenter de simplement parler une fois sur scène. Ce qui peut expliquer les cafouillages et erreurs de grammaire ou de prononciation. Il me reste toujours l'excuse facile de dire que je suis français, et du coup ça fait toujours marrer.

La crise de la trentaine ?

Jeff Moss (a.k.a DarkTangent) évoquait lors de la cérémonie de clôture le fait que les organisateurs vieillissaient (et lançait par ailleurs un défi aux hackers du Biohacking village), ce qui se traduisait globalement par une fatigue plus ressentie et la disparition tragique de hackers, de goons, de membres de l'organisation ayant dédié des années à DEFCON. Beaucoup d'émotion d'ailleurs dans les propos tenus par Nikita, Jeff et d'autres responsables de l'organisation, endeuillés par la perte de deux de leurs membres durant l'année 2019 (Tuna et Thelockheed).

Bizarrement, c'est aussi ce que je ressens. Je me sens vieillir, je vois pas mal de choses changer chez moi, que ce soit sur le plan physique ou plus simplement sur mes aspirations. Je n'ai pas non plus le même regard sur la communauté Infosec que lorsque je l'ai rejointe, il y a de cela plusieurs années. Je vois des amis et des collègues disparaître, des hackers que je tenais en estime et qui s'en sont allés en 2019 (farewell Philemon & Ylujion). On n'a plus vingt ans, on a perdu toute insouciance, fondé des familles, réduit les nombres de nuits blanches à coder ou hacker.

Je me soigne, pas de panique !

J'ai pas mal réfléchi ces derniers jours, et je pense avoir trouvé une solution à cette période bizarre. Cela implique du hacking, une révision des priorités et de nouveaux challenges.

Premièrement, il me semble important de passer du temps avec les personnes qui me sont chères, c'est-à-dire ma famille et mes amis. Autrement dit, je vais prendre du temps avec mes deux minis-moi et ma femme, quitte à gratter sur le temps alloué aux projets personnels. Je vais ainsi pouvoir initier ma fille à Scratch, et faire tout plein de Legos avec eux (yay !).

Deuxièmement, je vais essayer de me sortir la tête de l'infosec quand c'est possible, et allouer du temps à des projets qui n'ont rien à voir mais qui relèvent quand même du hacking. Je vais ainsi prendre le temps de terminer les deux Super Minitels qui me reste à faire, et avancer sur un projet en rapport avec l'aéromodélisme (quand je vous dis que cela n'a rien à voir avec l'infosec !). Je mettrai peut-être plus d'infos ici quand il aura avancé.

Et enfin, je vais faire le tri dans les projets en cours ainsi que dans les tâches "habituelles" qui reviennent chaque année. Je vais par exemple arrêter de travailler sur la création des badges électroniques dans le cadre de leHACK et me concentrer sur l'organisation de Qui veut gagner des bitcoins, et seulement cela. Fini la conception des challenges associés au badge. Trop de temps perdu, trop de stress. Sans parler de certains fails relatifs aux badges qui se sont produits ces dernières années.

NB: ce billet de blog a été écrit à chaud, mais je pense que la réflexion qu'il présente va évoluer dans les jours et semaines à venir. Vous pouvez me donner votre feedback (insultes, encouragements, questions) via Twitter ou par mail, bien évidemment.



Les contenus disponibles sur ce blog sont publiés sous licence Creative Commons BY-NC-SA.
Vous pouvez réutiliser tout ou partie de ces contenus à condition de citer l'auteur et l'origine, vous ne pouvez en faire une utilisation commerciale, et enfin vous devez partager tout travail ou œuvre dérivée sous les mêmes conditions — c'est-à-dire avec la même licence d'utilisation Creative Commons.