Une minute dix pour ouvrir un microcontrôleur automobile

Comment accéder à une interface de debug protégée sans connaître son mot de passe ? Sous un titre facétieux, « Glitch me et glitch moi sont dans une auto », cette conférence de BarbHack 2026 a répondu de la manière la plus concrète qui soit : en montrant le contournement des protections anti-debug de deux microcontrôleurs automobiles, en audit boîte noire, avec un banc à environ 500 euros. Chrono affiché sur scène : 88 tentatives et une minute dix sur le premier, 268 tentatives et quatre minutes sur le second.

Cinquième volet de notre couverture de BarbHack. Celui-ci s’adresse autant aux gens du matériel qu’aux directions qui pensent qu’un secret est en sécurité parce qu’il est dans une puce.

Le principe : sortir la puce de son domaine de fonctionnement

Une puce est spécifiée pour une plage de tension, de température et de fréquence. L’injection de faute consiste à l’en faire sortir juste assez pour atteindre un état d’instabilité où elle fonctionne encore, mais plus normalement. Dans cet état, des bits basculent, sur le bus de données, en mémoire ou dans les registres. Ces bitflips ne sont pas du bruit : ce sont des primitives.

Les effets exploitables présentés étaient de quatre natures :

• Muter une instruction. Une comparaison suivie d’un branchement vers le code d’erreur devient, au prix de quelques bits, une instruction qui n’affecte pas les registres testés. Le contrôle n’a pas été trompé : il n’a tout simplement pas eu lieu, et le firmware continue de tourner.
• Renverser un drapeau de condition, et donc le résultat d’un test.
• Falsifier une lecture d’OTP. Les bits de fusibles sont lus au démarrage sur un bus lent. Faire passer de 1 à 0 le bit « protection activée » pendant cette lecture, et la puce redémarre en mode développement.
• Détourner le flux d’exécution. En mutant le registre de destination d’une instruction pour y substituer le compteur de programme, on redirige l’exécution vers une adresse maîtrisée. C’est le scénario le plus puissant.

Quatre façons de provoquer la faute

• Glitch d’horloge. Insérer de fausses impulsions, assez courtes pour casser le cycle fetch-execute, assez longues pour être reconnues : l’instruction est chargée mais pas exécutée. Simple, mais réservé aux puces à horloge externe.
• Voltage glitching. Mettre très brièvement le rail d’alimentation à la masse pour retirer l’énergie et provoquer l’instabilité. Excellent rendement, mais intrusif : il faut retirer les condensateurs qui lisseraient l’attaque, et accepter le risque de « petite fumée ».
• EMFI, l’impulsion électromagnétique focalisée. Une sonde ferrite au-dessus du boîtier produit un effet proche du voltage glitch, sans toucher à la cible. Non invasif, mais long à régler : coordonnées spatiales, polarité, caractéristiques propres à chaque sonde.
• Laser. Décapsulation, exposition du die, tir sur des lots de transistors. Précision maximale, matériel et compétences en conséquence.

Tout se joue sur le déclencheur

C’est le message central de la conférence, et il est contre-intuitif pour qui découvre le domaine. La difficulté n’est pas de produire une faute : c’est de la produire toujours au même instant par rapport à l’opération visée. Un déclencheur imprécis ne réduit pas un peu le taux de succès, il l’effondre.

Un déclencheur assis sur un événement de communication, par exemple la fin d’une transmission série, souffre de gigue. Un déclencheur assis sur une mesure physique de la puce en train de travailler, non.

Autour de ce point s’organise une méthode en cinq temps : reconnaissance du système et des fonctions visées, préparation matérielle (retrait des condensateurs, choix du point d’injection), déclenchement, temporisation (l’attaque part plusieurs cycles avant l’événement, le temps que l’énergie soit effectivement retirée), puis observation et caractérisation.

La caractérisation mérite qu’on s’y arrête, parce que c’est là que le travail se fait vraiment. Elle produit une cartographie des paramètres, en quatre couleurs : vert pour l’exécution normale, jaune pour le crash léger ou les sorties bizarres, violet pour le crash violent, rouge pour le succès. Les succès se logent à la frontière entre le vert et le jaune, dans la zone de fonctionnement marginal. Une fois cette frontière repérée, le champ de recherche de l’attaque réelle se réduit énormément.

Deux scripts de test structurent cette phase, et le second est le bon :

• des boucles imbriquées à valeur finale connue : elles détectent qu’une faute a eu lieu, mais ne disent pas laquelle, le compilateur ayant introduit branches et instructions diverses ;
• une instruction unique répétée des milliers de fois, avec mesure précise du résultat. Si on attend 1024 et qu’on obtient 1023, l’instruction est peut-être devenue un NOP ou l’immédiat est passé de 1 à 0 ; si on obtient 1025, l’incrément a peut-être muté en incrément de 2. On identifie ainsi le bit exact qui a basculé et la mutation correspondante.

Cas 1 : RH850 (Renesas), la protection IDCODE

Le premier microcontrôleur expose un protocole de debug simple sur UART, protégé par deux mécanismes : un verrouillage irréversible, et un mot de passe de 16 octets, l’IDCODE. Détail précieux pour l’attaquant : même debug désactivé, la puce répond aux commandes d’initialisation par un refus explicite. Ce refus est un canal d’observation gratuit, et donc le point d’appui de toute la campagne.

Le montage : voltage glitching visant non pas le rail externe mais la ligne du régulateur interne (ISOVCL), condensateurs de cette ligne retirés pour éviter le lissage, plateforme ChipWhisperer à environ 500 euros, et une carte de développement portant la même puce pour préparer les scripts sans risquer l’équipement de production.

Premier déclencheur : la fin de transmission du mot de passe sur l’UART. Résultat : de la gigue, et un seul contournement après deux ou trois jours. Autant dire rien. L’analyse par canal auxiliaire change la donne : la mesure de consommation instantanée révèle un pic correspondant à la vérification du mot de passe, et ce pic n’est pas aligné avec la fin de la transmission. D’où un déclencheur combiné, que la plateforme sait gérer : la fin du mot de passe amorce, puis un seuil de consommation, calibré au début de chaque campagne, déclenche réellement l’injection au moment où la puce compare.

Nouveau résultat : 88 tentatives, environ une minute dix, debug activé.

Reste un problème pratique, et sa solution est instructive. Lire un firmware de plusieurs kilo-octets alors que la puce est maintenue dans un état d’instabilité, c’est risquer des données corrompues et des plantages. L’intervenant utilise donc une option du protocole pour redéfinir le mot de passe sur une valeur par défaut, sans effacer la mémoire. L’accès debug devient permanent et stable, GDB compris, et le reverse se fait ensuite dans des conditions normales. Autrement dit : la faute ne sert qu’à ouvrir la porte, après quoi on change la serrure.

Cas 2 : TC275 TriCore (Infineon), et le Lockstep

Le second cas est plus coriace. Protocole de debug propriétaire et synchrone, mot de passe transmis en huit blocs de quatre octets avec échange à chaque bloc, et surtout une protection Lockstep : chaque cœur est doublé d’un checker core qui exécute les mêmes instructions en parallèle, une porte logique comparant les résultats. Toute divergence provoque un reset. Sur le papier, c’est précisément conçu pour rendre une faute inopérante.

Sur le papier. La phase de caractérisation montre en effet des bitflips simultanés sur le cœur principal et sur son checker. Or si les deux dévient de la même façon, la comparaison ne détecte rien. La condition nécessaire au contournement est là, et elle est physique : le glitch n’affecte pas un cœur, il affecte la puce.

L’attaque se concentre alors sur l’envoi du dernier bloc de mot de passe, les blocs précédents ne semblant pas validés individuellement, la vérification étant faite globalement à la fin. Démonstration mesurée : 268 tentatives, quatre minutes deux, accès permanent obtenu. Le tout avec un montage plus rudimentaire que sur le premier cas, glitch appliqué directement sur le rail d’alimentation.

Ce qu’on en retient chez Humanix

• Un mot de passe de debug n’est pas une frontière de sécurité face à un accès physique. Seize octets et un verrouillage matériel tombent en une minute dix, pour 500 euros de matériel et quelques jours de caractérisation. C’est un ralentisseur, dimensionnez-le comme tel dans votre analyse de risque, pas comme un rempart.
• Sûreté de fonctionnement n’est pas sécurité. Le Lockstep protège remarquablement contre la faute accidentelle, celle d’un rayon cosmique ou d’un défaut d’alimentation. Contre une faute provoquée, qui frappe les deux cœurs en même temps, il ne protège pas. Confondre les deux est une erreur d’architecture fréquente, et pas seulement dans l’automobile.
• Tout organe en circulation doit être considéré comme accessible. Un calculateur se trouve sur un véhicule d’occasion, chez un casseur, dans un lot de pièces détachées. Si la confidentialité de votre firmware ou d’une clé embarquée est le seul obstacle entre un attaquant et votre flotte, le modèle de menace est à revoir : firmware chiffré et signé, secrets propres à chaque équipement, et surtout aucune hypothèse de confiance fondée sur l’inviolabilité du silicium.
• Le canal d’erreur est un canal. Une puce qui répond « refusé » de manière déterministe offre à l’attaquant exactement ce dont il a besoin : un signal fiable pour mesurer ses tentatives. Les réponses d’échec méritent le même soin de conception que les réponses de succès.
• Et c’est là que la démonstration change tout. Expliquer à un constructeur que son anti-debug est « théoriquement contournable » ne déclenche aucune décision. Lui montrer le chrono, la cartographie des paramètres et l’accès GDB obtenu, si. C’est notre façon de travailler : la preuve avant le verdict.

Note. Compte-rendu, à visée pédagogique, d’une conférence de BarbHack 2026 consacrée aux attaques par injection de faute sur microcontrôleurs automobiles, en contexte d’audit boîte noire. Les travaux présentés portent sur du matériel largement documenté publiquement et s’appuient sur des publications antérieures relatives à l’IDCODE du RH850 ; les vulnérabilités matérielles décrites sont inhérentes à la technologie et ne relèvent pas d’un défaut corrigeable par mise à jour. Cinquième volet de notre couverture de l’événement. Un équipement embarqué, un calculateur ou un firmware à mettre à l’épreuve ? Contactez-nous.