Bref, j’ai participé à mon 1er CTF (à 54 balais)…

Unlock your brain…

Samedi 17 novembre dernier, à Brest, avait lieu la 3e édition de « Unlock Your Brain, Harden Your System » (#UYBHYS), journée de conférences sur le thème de la sécurité numérique, organisée cette année non seulement par l’équipe de la Cantine Numérique de Brest, à l’origine des 2 premières éditions (notamment les infatigables Jess et Nico, cœur sur vous* <3), mais aussi par DIATEAM, société brestoise d’ingénierie numérique possédant un pôle cybersécurité très performant, et Bretagne Développement Innovation, agence économique régionale œuvrant pour le développement et l’attractivité de notre territoire.

* suite à la réception de ouat milliards de plaintes concernant l’apparente discrimination sous-entendue dans la manifestation de mon débordement d’affection, je rectifie: <3 gros cœurs sur toutes les organisatrices et tous les organisateurs (déso, j’suis pas à l’aise avec l’écriture inclusive dans ce genre de cas tordus), qui ont sué sang et eau pour mettre sur pied cette superbe journée et les précédentes ! Oui, toi aussi, Goulag Parkinson. 😀

J’ai eu l’insigne honneur d’être invité à intervenir lors de cette journée pour y présenter un sujet de mon choix (en l’occurrence ce qu’implique, en termes de mesures de sécurité, la mise en oeuvre d’un serveur de mail « à l’état de l’art » en 2018, pour IMT Atlantique Alumni – slides à venir), au milieu de plein d’autres orateurs bien plus talentueux et aguerris que moi (malgré mon grand âge), à savoir Rayna Stamboliyska, Manuel Dorne alias Korben, Sébastien Larinier, Alexandre Dulaunoy, Patrice Auffret et Jérôme Léonard… Bref, une tétrachiée de gens tous plus intéressants les uns que les autres, et dont les propos étaient autant d’invitations à déverrouiller notre cerveau afin de sortir des idées préconçues ou approximatives telles qu’elles nous sont retransmises à longueur de temps par les médias. Malgré l’excellent moment passé entre passionnés et l’intérêt indéniable des conférences (il paraîtrait que même la mienne, malgré ma très mauvaise gestion du temps, a trouvé grâce aux yeux de certains – sûrement les plus indulgents), je vais plutôt, dans la suite de ce billet, vous parler de ce qui s’est passé après, au cours de la soirée, à savoir le « CTF » !

Harden your system !

CTF ? WTF ?

L’un des intérêts de l’édition de cette année a été la mise en place d’un CTF (pour « Capture The Flag »), sorte de « serious game » dont le but est de tenter d’exploiter les vulnérabilités affectant les logiciels présents sur une plateforme informatique créée pour l’occasion, afin de s’introduire sur les ordinateurs pour y récupérer des « drapeaux », chaînes de caractères spécifiques et constituant les preuves de l’intrusion (en matérialisant, en quelque sorte, une fuite de données) et faisant gagner des points à l’équipe qui s’en empare.

Il existe plusieurs modes de jeu. Le plus courant est le mode dit « Jeopardy » qui consiste, pour chaque équipe, à tenter de résoudre un certain nombre de challenges de difficulté variable et rapportant un certain nombre de points, fonction de cette difficulté. L’autre grand mode est celui qui a été choisi pour #UYBHYS par DIATEAM, co-organisatrice de cette journée et « grand architecte » du CTF : il s’agit du mode appelé « attaque-défense », dans lequel chaque équipe est dotée d’une infrastructure informatique en tous points identique à celle des adversaires, et sur laquelle tournent un certain nombre de services réseau, dont certains sont rendus volontairement vulnérables. Le but de chaque équipe est double, ce qui à mon sens rend le jeu beaucoup plus intéressant que dans le mode « Jeopardy ». Il faut en effet à la fois :

  • défendre son infrastructure, en détectant le plus rapidement possible les vulnérabilités présentes sur les services exposés et en les corrigeant pour éviter de se faire voler le drapeau correspondant ;
  • attaquer l’infrastructure des autres équipes en présence, pour tenter d’exploiter les vulnérabilités et voler leurs drapeaux avant qu’elles aient elles-mêmes patché leurs propres services.

Il s’agit d’un jeu à somme nulle, concernant les gains : chaque équipe débute la partie avec un score de 0. Le seul moyen de gagner des points est d’arriver à voler les drapeaux des autres équipes. A peu près tout autre événement fait perdre des points, notamment :

  • se faire voler un drapeau par une autre équipe (bien évidemment) ;
  • arrêter l’un de ses services pour éviter qu’il ne soit piraté ;
  • modifier la valeur d’un drapeau pour « gruger » l’équipe qui vous l’a volé (car dans ce cas-là il n’est pas reconnu comme valide par le système d’arbitrage) ;
  • attaquer les autres équipes en déni de service (action considérée comme de l’antijeu) ;
  • toute forme de triche en règle générale.

L’organisation matérielle et logicielle

Le CTF de #UYBHYS pouvait accueillir jusqu’à 15 équipes (il y en a eu 12 au final). La plateforme mise en place était constituée de machines virtuelles, au nombre de 4 par équipe : un serveur web, un bastion où tournaient certains services, un « Programmable Logic Controller » (PLC), et un firewall de type pfSense, interconnectées entre elles ainsi qu’aux machines des autres équipes au travers d’un logiciel développé par DIATEAM : Hynesim (pour « Hybrid Network Simulation »), initialement pour DGA/MI. Une version open source de ce logiciel est d’ailleurs disponible (il existe même des paquets de binaires précompilés pour certaines distributions Linux). Le tout était hébergé sur un gros serveur (que l’on peut voir sur la photo ci-dessous au centre de la pièce) : la bête était équipée de 256 Go de RAM, et d’un ensemble de processeurs représentant un total de 56 cœurs.

CTF Sea Monsters (UYBHYS du 17/11/2018)

Dispositif en place pour le CTF « Sea Monsters » (avec l’aimable autorisation de @Korben)

Une logistique parfaitement adaptée

Il va de soi qu’un tel déploiement ne s’improvise pas. DIATEAM a, de fait, quasiment « industrialisé » cette phase, et intervient régulièrement dans de nombreux organismes avec une plateforme quasi-identique à celle dont nous disposions, comme on peut le voir sur la vidéo ci-dessous, featuring Guillaume « G0ul4g » Prigent, CTO de la boîte 😉 :

Le résultat est que l’on a affaire à une équipe parfaitement rodée, et un dispositif au top, avec entre autres :

  • un thème (bien entendu totalement indispensable 😉 ) : celui de ce CTF était « les monstres marins » (on est à « Brest même », gast !), avec des graphismes marrants et sympas mettant en exergue le côté ludique – comme je souhaitais monter une équipe de dino^H^H^H^Hvieux crabes, j’ai assez logiquement choisi la team « Crabal ». Les autres noms d’équipes, pour ceux que cela intéresse, sont consultables sur le site ;
  • un superbe « scoreboard » temps-réel : le logo de chaque équipe, affublé de son score (en vert si positif, en rouge si négatif) et d’une petite maquette de village qui ressemble à New-York pour les meilleures équipes, et plutôt au Beyrouth des années 80 pour d’autres, tourne sur un disque en pseudo-3D ;
  • des boissons et des pizzas pour tout le monde (hmmm, les doigts gras sur les claviers…), ce qui n’a pas empêché les « pros » de venir avec leur stock de boissons énergisantes, preuve que certains prennent vraiment la chose au sérieux (et c’est tout à leur honneur) ;
  • une animation hors-pair par les organisateurs, toujours prêts à aider les « p’tits nouveaux » par leurs conseils (sans pour autant les avantager), ou à encourager la compétition entre les équipes.

Les différents intérêts du jeu

Outre la sollicitation des compétences purement techniques des participants, dans de nombreuses disciplines touchant à la sécurité informatique (administration système, programmation dans des langages divers et variés, cryptographie, etc.), un CTF présente également des intérêts indéniables dans des domaines correspondant à ce qu’il est convenu d’appeler « les compétences transverses » : travail en équipe pluridisciplinaire, collaboration, résistance au stress, endurance, priorisation des tâches à effectuer, le tout dans un cadre contraint ! Le but premier étant d’aller « pirater » les machines des adversaires, ce qui dans la vraie vie (est-il besoin de le rappeler) n’est pas vraiment permis, d’aucuns pourraient se dire que basta, puisqu’on flirte avec des interdits, tous les coups sont permis ! Rien n’est plus faux : les règles du jeu sont strictes, et toute erreur ou tricherie se paie « cash »…

Le réalisme

Bien entendu, les vulnérabilités présentes ont été volontairement introduites sur les différents logiciels de la plateforme. C’est un jeu, il faut qu’il reste jouable en un temps raisonnable (quelques heures), mais là encore, que l’on ne s’y trompe pas: ces failles correspondent bel et bien à ce que l’on peut trouver dans la réalité… Erreurs de codage permettant un débordement de tampon, services mal configurés (à titre d’exemple, l’un des drapeaux les plus simples à obtenir, dans le CTF « Sea Monsters », était présent dans un l’un des enregistrements d’un DNS mal protégé et permettant – à tort – les transferts de zones), vulnérabilités de services web permettant des injections de fichiers ou de commandes…

Et pour couronner le tout et permettre aussi à ceux qui le souhaitent de se la jouer stratégique, un « dark market » était également disponible, chaque équipe pouvant acheter, pour quelques centaines ou milliers de points, des informations : codes sources, patches, etc., leur permettant de mieux se protéger, ou de rendre leurs offensives plus efficaces. Et comme dans la  vraie vie, pour acheter sur le dark market, on peut aussi s’endetter… au risque de finir dans les profondeurs du classement !

Les outils nécessaires

Au niveau matériel, du classique : l’indispensable ordinateur portable (ou pas, d’ailleurs), et les périphériques éventuellement souhaités pour tenir plusieurs heures : écran, clavier externe, souris…

Côté logiciels, il vaut mieux disposer des bons outils avant le début de l’épreuve, car il se peut (et c’était le cas lors du CTF « Sea Monsters ») qu’aucun accès à Internet ne soit autorisé. Idem pour la documentation éventuellement nécessaire.

Comment constituer une bonne équipe ?

Même en tant que débutant dans le domaine, il apparaît que la formation et le fonctionnement d’une bonne équipe de CTF doivent répondre à certains critères (assez universels, il est vrai) :

  • il n’est pas forcément nécessaire que les joueurs se connaissent bien (tout au moins s’ils ne visent pas la 1ère place), mais il est important qu’ils n’aient pas de difficulté de communication, une bonne partie de la réussite reposant sur l’entraide au sein de l’équipe ;
  • les profils doivent (quand-même) être plutôt techniques, et de préférence variés (par exemple, un mix d’admins systèmes et de développeurs);
  • il faut exploiter les compétences spécifiques de chacun, et à cet effet, une phase d’observation commune en début de partie, permettant de tenter de définir la nature de chacune des failles auxquelles on fait face, n’est pas inutile ;
  • partant de là, chacun peut tenter de s’atteler à une tâche (soit défense, soit attaque) sur une faille donnée, l’important étant, encore une fois, de communiquer (mais à voix basse : les adversaires ne sont qu’à quelques mètres 😉 ) pour éviter d’être plusieurs à travailler sur le même drapeau et perdre un temps précieux.

« Toute première fois »

Comme le titre du billet le laisse entendre (doux euphémisme), je ne suis pas un lapin de 6 semaines (autre doux euphémisme), et j’ai derrière moi quelques années d’administration système, tant au niveau professionnel que comme bénévole dans différentes associations. A ce titre, j’ai également été confronté à pas mal de problématiques de sécurité informatique. Pour autant, même s’il ne se passe quasiment pas une journée sans que j’aie à lancer un wireshark ou un nmap , même si j’ai écarquillé les yeux à la sortie de l’article « Smashing the stack for fun and profit » dans Phrack en 1996, et failli tomber de ma chaise en expérimentant et en constatant par moi-même que les failles décrites étaient très facilement exploitables, et même s’il m’arrive d’utiliser des outils comme netcathpingsocat ou metasploit, ou encore de m’amuser à « fuzzer » un serveur web ou tenter de réaliser des injections SQL (notamment pour effectuer des auto-tests), je n’avais jamais participé à un tel challenge. Et vous voulez que je vous dise ? Je le regrette… 😉

En effet : même si l’on a de l’expérience dans le domaine de l’administration système, que l’on observe des bonnes pratiques, que l’on a déjà géré des gros coups de stress parce que toute l’infra a décidé de partir en vrille d’un coup et que les téléphones commencent à sonner de partout, on n’est pas pour autant préparé à ça… Arriver sur une plateforme dont on ne connaît rien, aller fureter partout pour voir où sont les failles, c’est un métier en soi. Ca tient à la fois du pentest, de l’expertise système et de l’analyse forensique, en fait. Et dans ces domaines, il y a des gens (que l’on peut légitimement qualifier de spécialistes, voire d’experts), qui n’hésitent pas à faire plusieurs centaines de kilomètres pour le plaisir de se confronter à d’autres joueurs. Inutile de dire que nous avions peu de chances de « péter un score ». 😀

Un seul regret

Outre le fait de ne pas avoir (eu|pris) le temps de tenter une telle activité avant, j’ai un seul regret concernant cette soirée : nous étions trèèèès loin de la parité… Seule une jeune femme avait répondu présente pour cette 1ère édition brestoise. Certes, ce n’est pas spécifique aux CTF. Laissons du temps au temps, comme on dit.

Bref, j’ai participé à mon 1er CTF…

En conclusion, même si le résultat de notre équipe n’a pas été exceptionnel (mais pas ridicule non plus, considérant qu’elle était exclusivement constituée de débutants dans le domaine : nous avons fini en 6e position, au beau milieu du classement), j’ai en tout cas passé, et mes coéquipiers aussi je l’espère, une super soirée, et je compte bien participer aux éditions suivantes si elles ont lieu.

Comme l’a dit Pierre de Coubertin : « l’important dans la vie n’est pas le triomphe mais le combat ; l’essentiel n’est pas d’avoir vaincu mais de s’être bien battu ».

Une chose est sûre, en tout cas : si après la participation à une telle activité, vous n’avez pas compris qu’il faut durcir votre système, on ne peut plus rien pour vous… 😉

Publié dans Cybersécurité, Sécurité numérique | Commentaires fermés sur Bref, j’ai participé à mon 1er CTF (à 54 balais)…

TEMPEST en série dans un petit port…

USB et DB9 sont dans un bateau…

Alors donc, voilà… Pour un projet, au boulot, nous avons dû acheter du matos TEMPEST… Outre son prix exorbitant (mais certainement justifié – ne serait-ce que par le poids du métal), l’engin de marque SILTEC nous a, au déballage, réservé quelques surprises…

Ses connecteurs sont, en effet, pour le moins… particuliers. Le but étant de bénéficier d’un blindage le plus efficace possible, à défaut de pouvoir se payer une cage de Faraday, il est somme toute assez logique de trouver, en lieu et place du connecteur RJ45 habituel pour la connexion réseau, des connecteurs à baïonnette pour fibre optique, de type ST (norme CEI 61754-2). En revanche, un truc auquel nous ne nous attendions pas, ce sont les connecteurs DB9, au nombre de 4, et surmontés chacun du logo USB :

USB DB9

Perplexe, je me suis demandé pendant quelques secondes s’il ne s’agissait pas tout simplement de connecteurs RS232 « classiques », mais l’explication ne tient pas la route. Tout simplement, déjà, parce que dans ce cas il n’y a aucune raison pour qu’un logo USB orne chacun de ces connecteurs, mais aussi parce qu’une DB9 sur un châssis est généralement un connecteur mâle, et que par ailleurs le clavier et la souris sont clairement des modèles récents (donc a priori USB, pas PS/2 ou série), et sont malgré tout affublés du connecteur DB9 complémentaire.

USB tombe à l’eau…

Damned. On n’avait pas prévu ça. Surtout que, comme @H_miser qui se pose la question sur twitter, j’ai aussi, finalement, quelques doutes sur la réelle supériorité du blindage d’une prise DB9 et je commençais sérieusement à me demander pour quelle raison ce choix avait été fait… Un coup d’œil au catalogue nous permet de dénicher un hub « prévu pour », et là, en regardant la bête, la raison d’être des connecteurs DB9 apparaît clairement :

Vous avez remarqué, je suppose, que ce périphérique est muni d’un couvercle. Celui-ci est destiné à éviter toute émission de signal compromettant : on insère la clé USB ou la carte mémoire, on ferme le couvercle hermétiquement, on branche le bouzin sur le port DB9, et là, on peut commencer à bosser…

Le « level » noté après la référence du boîtier correspond au niveau de protection souhaité. Le niveau B exige que les signaux compromettants soient inexploitables au-delà de 20 mètres, le A, lui, est beaucoup plus strict puisque ces signaux doivent être inexploitables à moins de 1 mètre de la machine.

Les prises utilisées sur le châssis du PC ont donc vraisemblablement pour but principal de « dé-standardiser » la connectique afin d’empêcher, ou tout au moins de rendre malaisée, la connexion directe de clés USB ou d’autres périphériques non blindés « intrinsèquement ». Je n’ai pas encore eu entre les mains le hub en question, mais je suppose (et je crois d’ailleurs le distinguer sur la photo) qu’il comporte un mécanisme de verrouillage qui impose la fermeture du capot pour permettre le fonctionnement. Ce serait logique…

Demande de devis envoyé à notre fournisseur : 1 adaptateur coûte la bagatelle de… 980 € HT ! En d’autres termes (avec par avance toutes mes excuses pour ce jeu de mots laid), ça coûte une blinde, (d’ailleurs, si quelqu’un connaît l’étymologie de cette expression, ça m’intéresse 😉 ).

Qu’est-ce qui reste ?

En attendant, il faut qu’on avance. On doit nitrater le contenu du disque dur, où un Windows 7 version polonaise a été installé par défaut, et tenter de mettre en place une version qu’on comprend un peu mieux, et surtout, qu’on aura installée nous-mêmes… Dans ces phases de tests, on n’a pas forcément besoin de se protéger des Chinois du FBI, ni des grandes oreilles américaines, et j’envisage donc de faire un simple câble de conversion avec une DB9 mâle de récup (j’en ai plein mes poubelles), et en sacrifiant une rallonge USB. Aucune doc technique en ligne, bien entendu. Le souci, c’est que déjà, le catalogue, on l’a cherché un moment (d’ailleurs si vous faites une recherche Google sur « siltec catalogue » vous avez toutes les chances de tomber en premier lieu sur la version hébergée par Wikileaks 🙂 ), alors un « service manual », faut pas rêver. Et puis bon, en polonais… Au fait, je vous ai dit que j’étais nul en polonais ?

Un petit appel à mes followers sur Twitter ne me donne pas de réponse directe, mais l’info est retweetée et @vincib me fait remarquer  qu’il n’y a pas grand risque à tester la prise. C’est vrai… Il y a des jours où, à force d’être dans le bouillon, je manque singulièrement de bon sens. A moins que ça ne soit un début d’Alzheimer…

Le lendemain, me voici donc armé :

  • d’une rallonge USB ;
  • d’une prise DB9 mâle ;
  • d’un fer à souder ;
  • de soudure RoHS (et puis quoi encore ? J’ai du stock à épuiser, moi… Et honnêtement, vous avez déjà tenté de souder avec de la brasure sans plomb ? Hmmm ?) ;
  • de tresse à dessouder ;
  • d’un multimètre ;
  • d’un oscillo portable Philips PM97 (qui au final n’aura pas beaucoup aidé), et…
  • d’une résistance de 1,5 kΩ.

J’allais oublier de mentionner la dose d’inconscience de culot nécessaire pour aller renifler le derrière d’un machin qui vaut dans les… euh, non, finalement, ça je le garde pour moi, ça frise l’indécence.

… Le DB9 !

Alors déjà, l’USB, comment ça marche ? Au niveau électrique, un connecteur type A est relativement simple : 4 broches, dont 1 alim (5 V), une masse, et 2 broches de données (D+ et D-) qui fonctionnent en mode différentiel.

Un p’tit coup de voltmètre pour trouver le 5 V (la référence de masse étant prise sur le châssis) : c’est la broche 1. Pas d’autre candidate.

Un p’tit coup d’Ohmmètre maintenant, pour trouver la masse : elle est sur la broche 2. C’est la seule qui présente une impédance nulle par rapport au châssis. Toutes les autres broches ont une impédance élevée voire infinie, aucun doute à avoir, donc.

Après, ça se complique un petit peu : comment trouver les broches de données ? C’est là que la résistance de 1,5 kΩ entre en jeu…

D’après la spécification USB 2.0, les broches D+ et D- de chaque prise « upstream » (ce terme, désignant une prise qui, dans une connexion, est plus près de l’UC, est parfaitement arbitraire et me fait un peu penser aux « sens des retours » et « sens des départs » dont nous abreuve régulièrement notre Bison Fûté national et toutes les télés et radios qui s’en font le relais) doivent être équipées de résistances de rappel (« pull-down ») d’environ 15 kΩ. Donc, lorsqu’aucun périphérique n’est connecté, D+ et D- sont au niveau bas (0V).

Comment se fait la détection d’un périphérique ? Tout simplement par la mise de l’une des 2 broches de données à un niveau électrique situé, d’après la spécification, entre 3,0 V et 3,6 V, typiquement 3,3 V. Laquelle des broches ? Eh bien tout dépend du type de périphérique. Un périphérique « low speed » mettra la broche D- à 3,3 V, et un périphérique « full speed » se signalera, lui, en mettant la broche D+ à ce niveau, comme indiqué sur le schéma ci-dessous, extrait de la page 141 (sur 650) de la spec :

full-and-low-speed-usb

Bon, alors, OKER, si j’avais voulu m’enquiquiner un peu, j’aurais fait un pont diviseur ayant les caractéristiques souhaitées, c’est à dire (avec R1 connectée au 5 V, R2 au 0 V, et le 3,3 V au point de connexion entre R1 et R2) :

  • R2/(R1+R2) = 3,3/5 (équation 1)
  • (R1*R2)/(R1+R2) = 1500 (équation 2)

Même les moins matheux d’entre vous auront reconnu un système d’équations. Je vous fais grâce de la démonstration, mais le résultat donne à peu près R1=2250 Ω et R2=4500 Ω. Comme ces valeurs n’existent pas dans les séries normalisées, on prendra des valeurs approchantes, 2,2 kΩ et 4,7 kΩ dans la série E12, par exemple, même si elle n’existe plus (au fait, je vous ai dit que j’étais un vieux c.. ?) et a été remplacée par la série E24.

Tout ça c’est pour vous dire qu’en théorie, il aurait vraiment fallu se faire braire, mais la différence la plus intéressante entre la théorie et la pratique, c’est qu’en théorie c’est pareil, mais en pratique, c’est différent. Et en pratique, le pont diviseur… ben on s’en fout, mais alors d’une force… Tout ce qu’on risque, c’est que notre détection ne marche pas, car les broches D+ et D- sont bel et bien prévues pour supporter du 5 V, donc aucun risque de destruction.

Au final, lorsqu’on fait le test avec une simple résistance de 1,5 kΩ, ça marche bien, tout au moins sur ce PC. Il m’a suffi de mettre l’une des pattes de la résistance dans la broche 1 (5 V) du connecteur, et d’essayer de mettre l’autre patte successivement dans toutes les autres broches (sauf la 2 dont on sait déjà qu’il s’agit de la masse), pour provoquer une réaction de la bête (qui détectait la connexion d’un périphérique USB) lors de l’introduction dans les broches 3 et 4.

Il reste un dernier problème : laquelle est D+, et laquelle est D- ? Le message affiché par Windows est le même, qu’il s’agisse d’un périphérique « low speed » ou « full speed ». Sous Linux, peut-être, aurais-je eu plus d’informations, avec l’apparition d’un « new full-speed USB device » ou d’un « new low-speed USB device » dans les logs. Il y a certainement un moyen également sous Windows, mais je ne le connais pas (au fait, je vous ai dit que j’étais une burne en Windows ?).

Du coup, que faire ? J’ai bien tenté d’utiliser mon oscillo, mais ce qui passe sur les lignes de données en l’absence de périphérique réel n’est pas vraiment exploitable. Du coup, j’ai forcé la chance. Je n’avais pas joué au Loto depuis, euh… En fait je ne me souviens pas avoir jamais joué, mais là aussi, ça peut être Alzheimer.

J’ai donc fabriqué un câble en prenant une hypothèse : D+ (fil vert) sur la broche 3, D- (fil blanc) sur la broche 4. Mesdames et Messieurs les jurés, à ce stade de l’histoire, je réclame votre indulgence. Je suis sûr que ce câble me vaudrait d’être pendu haut et court par n’importe quel électronicien (avec ledit câble, d’ailleurs), mais à ma décharge (électrique),  j’avais pas mes yeux…

adaptateur-usb

Et puis franchement, moi, il me va bien ce câble. Surtout que pour une fois, Murphy ne s’est pas manifesté, et que la clef USB que j’ai introduite dans le connecteur femelle USB type A a été détectée immédiatement… Si j’avais eu tout faux (inversion de D+ et D-), le périphérique n’aurait pas fonctionné, car le code NRZI utilisé par l’USB n’aurait pas pu être correctement interprété, et de plus, la détection du type de périphérique (full speed vs. low speed) aurait aussi échoué car activant la mauvaise broche… En revanche, la manip était électriquement totalement sûre, aucun risque de cramer quoi que ce soit, c’est juste une histoire d’interprétation des données dans les couches supérieures.

La morale de l’histoire…

Vous allez me dire qu’il y a peu de chances qu’un jour vous soyez confrontés au même type de matériel. Honnêtement, je ne peux pas vous donner tort… Mais peut-être serez-vous confrontés à un problème de port USB défaillant, ou de connecteur au brochage inconnu sur une carte-mère. Et puis au final, même si ça ne sert à personne, au moins, la prochaine fois, moi, je saurai où trouver l’info ! 😉

Publié dans Bidouille | Laisser un commentaire