Comment débuter dans le hacking hardware — la méthode de Philippe Laulheret

Résumé de la présentation DEF CON 21 (2017) • Avaya 9611g • De la reconnaissance à l’exploitation

Philippe Laulheret est security researcher chez McAfee, en charge des recherches sur les téléphones et l’embarqué. Il n’est pas ingénieur électronique. Avant de faire de la sécurité matérielle, il a passé deux ans en sécurité embarquée et avant ça il était développeur C++. Quand il a commencé à s’intéresser au hardware, il le trouve un peu intimidant, un peu étranger. Mais il a découvert que c’est accessible si on a une bonne méthode et de la patience.

Sa présentation à DEF CON est une introduction au hacking hardware. Il prend un téléphone VoIP Avaya 9611g comme cas d’étude — un appareil courant dans les entreprises, qui tourne sous Linux, qui a un accès réseau, un microphone, une caméra. Et il montre comment obtenir un shell root dessus, identifier et exploiter une faille réelle connue depuis 10 ans, et transformer l’appareil en microphone d’écoute à distance.

Ce qu’il veut surtout transmettre : le processus. Pas seulement le résultat. Car ce qui marche sur un appareil peut ne pas marcher sur un autre. Avoir une idée de ce qu’on peut faire, et de ce qu’on ne peut pas faire, aide à aborder n’importe quel appareil.

Pourquoi s’y mettre ?

Deux raisons principales, selon Philippe.

La première est que c’est amusant. Ouvrir un appareil qu’on a chez soi, comprendre comment il marche à l’intérieur, c’est satisfaisant. Au lieu de laisser un objet comme une boîte noire, on commence à le prendre à morceaux et à le comprendre.

La deuxième raison est plus pragmatique. Le logiciel est devenu difficile à exploiter. Trouver une vulnérabilité dans un serveur web, une application, c’est devenu compliqué. À l’inverse, ouvrir un appareil, souder quelques fils, obtenir un shell — c’est souvent plus accessible. Philippe appelle ça les « low hanging fruits ». Sur des appareils anciens qui n’ont jamais reçu de patch, c’est particulièrement vrai.

Philippe lui-même a trouvé deux vulnérabilités remote code sur un téléphone VoIP Avaya 9611g. Cet appareil date de 2006. Il tourne sous Linux. Il a un accès réseau. Et il a été utilisé dans le siège de l’ONU en 2006. Les failles étaient là depuis environ 10 ans sans être repérées. Elles avaient même été présentées à DEF CON une décennie plus tôt — sans qu’elles soient exploitées.

Comment on s’y prend, d’une manière générale

Philippe utilise un téléphone Avaya 9611g comme exemple. Le processus qu’il détaille est réutilisable sur d’autres appareils. Il se décompose en plusieurs phases.

Avant d’ouvrir quoi que ce soit

On fait des recherches avant d’enlever les vis.

FCC. Tout appareil avec Wi-Fi ou Bluetooth doit avoir une certification FCC. On trouve souvent sur le site FCC des photos du produit, des schémas des composants internes. Philippe les utilise pour avoir une idée de ce qui est à l’intérieur avant même de toucher l’appareil.

Manuels et documentations. Philippe a trouvé un manuel utilisateur avancé qui mentionnait qu’une connexion série nécessitait un « boîtier spécial ». Ça confirme que le port série est présent sur l’appareil, même si on n’a pas encore l’hardware pour l’utiliser.

Forums et discussions. Il a retrouvé les mots de passe par défaut dans des discussions d’administrateurs systèmes et des forums de support.

Firmware disponible. Parfois le firmware est téléchargeable directement. Parfois il est chiffré. Parfois il faut le récupérer autrement. Dans le cas de Philippe, le firmware était disponible sans difficulté.

Ouvrir et identifier les composants

Une fois qu’on a une idée de ce qui se trouve à l’intérieur, on ouvre l’appareil et on fait le tour des éléments.

Ce qu’on retrouve typiquement :

Le CPU, souvent sur un bord, parfois sous un bouclier métallique (pour réduire les interférences — quand c’est une antenne Wi-Fi, par exemple).
La RAM, à côté du CPU.
La flash, ou le stockage, qui contient le firmware.
Des connecteurs de debug non soudés (des headers vides, avec des pads laissés intentionnellement).
Des points de test (des petits pads étiquetés TP1, TP2, etc.), souvent disséminés sur la board.
Parfois un connecteur RJ45 « keyed » — un port Ethernet avec un connecteur spécial pour éviter de brancher le câble incorrect.

Pourquoi ces éléments sont là ? Parce que souvent le board de production est le même que le board de développement. Les ingénieurs laissent des connecteurs de debug, des points de test pour le flashing en usine, ou pour diagnostiquer des pannes sur le terrain.

Ce qu’il faut regarder de plus spécifique :

UART. Un port série avec 3 ou 4 pins (masse, TX, RX, et parfois VCC à 3.3V ou 5V). C’est souvent la première chose à chercher pour obtenir un console.

JTAG. Un protocole de debug hardware qui permet de contrôler le CPU instruction par instruction. Souvent présent sur les boards de développement. Parfois laissé sur les boards de production sans connecteur soudé — il faut alors souder soi-même.

Points de test inopinés. Certains peuvent servir à reset l’appareil si on les court-circuite avec la masse.

Outils pour interfacer avec le hardware

Philippe présente une liste d’outils. Pour débuter, on peut se contenter de quelques-uns.

Sécurité. Débranchez l’appareil avant de le modifier. Travailler dans une pièce ventilée.

Loupe ou microscope de soudure. La soudure fine est faisable même si les mains tremblent. Philippe, qui boit beaucoup de café, fonctionne malgré tout — en maintennant le bras droit, bien ancré, sous le microscope.

Flux de soudure. Une substance qu’on met sur les pads avant de souder. Sans elle, la soudure ne s’applique pas correctement. Un détail qui fait toute la différence pour les soudures fines.

Fils de cuivre fins (magnet wire). Fil de cuivre ultra-fin, avec une couche de laque isolante. Utiles pour les soudures point à point.

Désoldant (wick). Une mèche de cuivre qui absorbe l’excès de soudure quand on en a trop mis.

Ventilateur de chaleur (heat gun). Environ 60 euros. Permet de décoller des composants en chauffant et en les retraitants.

Multimètre. Pour mesurer la tension d’une puce inconnue, et surtout en mode continuité — quand les deux sondes sont reliées, ça pie. Ça sert à vérifier ses soudures.

Analyzeur logique. Un petit appareil (souvent à bas prix, quelques dizaines de dollars) qui capture des signaux sur plusieurs fils et les transforme en données lisibles. Philippe l’utilise pour voir les communications SPI entre le CPU et la EEPROM. La marque Saleae est une référence populaire.

Câble FTDI. Un câble série qui se branche sur un port UART, et qui apparaît comme un port série sur l’ordinateur. Avec ça, on peut se connecter au console et voir le boot.

Bus Pirate. Un petit appareil qui peut parler différents protocoles hardware (SPI, I2C, UART, etc.) et qu’on peut programmer en Python. Philippe l’utilise pour lire la EEPROM du téléphone — il parle le protocole SPI et envoie les commandes pour lire la mémoire.

Debuggers JTAG. Dispositifs qui se connectent aux pins JTAG du CPU. Le « Flyswatter » (environ 30 euros) fonctionne correctement. Le J-Link de Segger est plus chère et plus fiable. Le JTAGulator de Joe Grand brute-force automatiquement les pins JTAG sur un board.

Lecteurs de flash. En circuit (avec un clip qui se fixe sur la puce sans la retirer) ou hors circuit (en désoulant la puce et en la mettant dans un socket). Un Raspberry Pi peut parfois faire le job en circuit, mais il y a des pièges (le Pi peut ne pas avoir assez de puissance, ou le CPU peut communiquer avec la flash et corrompre la lecture). Retirer la puce est souvent plus fiable.

Glitch hardware (option avancée). Des appareils comme ChipWhisperer permettent de couper l’alimentation du CPU pendant une fraction de seconde pour provoquer des erreurs d’exécution et bypasser des vérifications.

Trois approches pour obtenir du firmware ou un shell

Philippe structure sa méthodologie autour de trois voies. Il souligne qu’il est souvent nécessaire d’en essayer plusieurs sur le même appareil.

UART / console série

On se connecte au port UART avec un câble FTDI. Souvent, au démarrage, on peut appuyer sur Espace ou Escape pour interrompre le boot et obtenir un prompt. Philippe a obtenu un console partiel sur le téléphone — le système affichait des messages, mais la console était fixée sur /dev/null, ce qui rendait l’interaction impossible.

Récupérer le firmware

Télécharger en ligne — parfois le firmware est disponible publiquement (cas de Philippe).
Sniffer une mise à jour — sur un réseau, on peut capturer le trafic quand l’appareil fait une mise à jour (Philippe utilise un tap réseau ou un port mirror sur un switch).
Dump la flash hardware — en circuit (avec un Raspberry Pi ou un lecteur) ou hors circuit (en retirant la puce). C’est plus complexe : quand la puce est encore connectée au système, le CPU peut continuer à communiquer avec elle pendant la lecture et corrompre les données.

JTAG

Si le JTAG est accessible, on peut souvent dump la mémoire RAM (quand le firmware est chargé dedans). Sur certains appareils, le firmware complet est chargé en RAM au démarrage — donc dump la RAM = dump le firmware.

Analyser le firmware

Une fois qu’on a le firmware, que faire ?

Binwalk. L’outil principal pour l’analyse statique de firmware binaire. Il scanne le fichier et détecte les sections imbriquées : archives zip, fichiers squashfs, JFFS2, headers ELF. Il peut extraire automatiquement ces sections. Philippe met en garde : Binwalk peut générer des faux positifs — il ne faut pas faire aveuglément confiance à ce qu’il signale.

Strings. Lancer strings sur le firmware peut révéler des segments intéressants : des chaînes de bootloader, des commandes cachées, des chemins de console.

Extraire le système de fichiers. Une fois que Binwalk a identifié un squashfs ou un JFFS2, on peut extraire tout le système de fichiers et regarder ce qui est installé sur l’appareil — comme s’il s’agissait d’un ordinateur classique.

Chercher les mécanismes de mise à jour. Comprendre comment l’appareil vérifie et applique les firmware updates. Si on peut reverse-engineer ce processus, on peut parfois récupérer les firmware updates suivants sans avoir à refaire du hardware hacking.

Chercher des secrets dans le firmware. Mots de passe, certificats, clés de chiffrement, configurations par défaut.

Analyser le bootloader. Le bootloader est souvent un endroit riche en informations : commandes cachées, configurations de console, vérifications de signature. Philippe a analysé le bootloader du téléphone Avaya avec IDA pour comprendre pourquoi la console était configurée sur /dev/null.

Obtenir un shell root : le cas Avaya

Philippe combine plusieurs techniques pour obtenir un shell root sur le téléphone.

Analyser le bootloader dans IDA. En regardant les chaînes du bootloader, il a repéré que la console était définie sur /dev/null par défaut, mais qu’un code alternatif définissait la console sur UART0 ou UART1. Il a identifié la fonction qui lisait une valeur dans l’EEPROM et conditionnait la console — si la bonne valeur était présente, la console était activée sur ttyAMA0.

Patcher l’EEPROM avec le Bus Pirate. Connaissant le protocole SPI de la EEPROM, Philippe a envoyé les commandes SPI adéquates pour modifier la valeur lue par le bootloader. Une fois le bootloader modifié, le téléphone bootait avec la console série activée.

Le problème : l’input ne marchait pas. La console affichait des messages, mais les touches ne faisaient rien. Philippe a tracé le circuit avec un multimètre en mode continuité — en suivant les traces de la board pour voir où le signal UART allait. Les traces allaient de l’autre côté du board, sous le connecteur RJ45 « keyed ».

Résoudre le mystère du RJ45. En retournant à la documentation visionnée en phase de reconnaissance, Philippe a réalisé que le connecteur RJ45 était exactement le « boîtier spécial » mentionné dans le manuel utilisateur. Le port était un port série masqué derrière un connecteur Ethernet inhabituel.

Trouver les pins de l’UART. En utilisant un câble de test branché sur la sortie TX de son câble FTDI, et en pressant des touches sur le console pendant qu’il testait chaque pin du connecteur une par une, Philippe a identifié les pins correctes au deuxième essai. Il a obtenu un shell root.

Nettoyer le console. Une fois le shell obtenu, un processus floodait le console avec des messages de debug. Philippe a identifié un watchdog qui rebooterait l’appareil si le process était tué, et une commande magique (une valeur unique aléatoire) pour désactiver le watchdog avant de killer le process.

Trouver et exploiter une faille réelle

Avec un shell, Philippe a pu faire de la recherche de vulnérabilité réelle.

Il a identifié un processus DHClient (le client DHCP de l’appareil) qui utilisait une version modifiée datant de 2007. Cette version avait une faille connue — une stack overflow dans la gestion des options DHCP, présentée à DEF CON il y a environ 10 ans par Jon Oberheide.

La faille : le code utilisait une longueur provenant directement d’un paquet DHCP (jusqu’à 255 octets) sans la valider. Pour une subnet mask, la longueur devrait être de 4 octets. Sans validation, un attaquant pouvait envoyer une valeur plus grande et provoquer un débordement.

Philippe a vérifié dans IDA que le code compilé n’utilisait pas de canary de stack et ne limitait pas la longueur — la vulnérabilité était présente dans la version compilée.

Il a tenté d’exploiter la faille en émulation avec QEMU (Full-System emulation d’un système ARM) pour avoir un environnement de test. Le binaire DHClient de l’appareil crashait avec un segfault parce qu’Avaya avait modifié le code pour créer un socket nommé (Unix socket) que le binaire original n’utilisait pas. Philippe a ré-implementé ce mécanisme avec un script Python + socat côté hôte, ce qui lui a permis d’exécuter le DHClient modifié dans QEMU et de debuguer avec GDB.

Exploitation. Il a utilisé Scapy (une bibliothèque Python pour manipuler des paquets réseau) pour envoyer des paquets DHCP malformés avec des options de subnet mask trop longues. En observant le crash dans GDB, il a pu voir qu’il contrôlait le registre PC (program counter), ce qui lui donnait le contrôle de l’exécution. Il a ensuite crafted un shellcode qui appelait system() avec une commande arbitraire.

Post-exploitation. Une fois le shellcode exécuté, Philippe a configuré l’appareil pour exécuter un script qui fetchait des données depuis un serveur web contrôlé par l’attaquant, lire le contenu de /dev/random pour montrer que l’appareil exécutait du code arbitraire, et exfiltrer l’audio du haut-parleur principal — transformant le téléphone en microphone d’écoute à distance.

Ce qu’un débutant devrait retenir

La vidéo de Philippe est utile pour débuter parce qu’elle ne se limite pas à un « hacking magique ». Elle présente la méthodologie, y compris les choses qui ont échoué.

Quelques points à prendre pour commencer :

Commence par la reconnaissance. Avant d’ouvrir quoi que ce soit, cherche les informations publiques : FCC, manuels, forums, firmware disponibles. Ça donne une idée de ce qui est à l’intérieur sans rien casser.
Apprends à identifier les composants de base. CPU, RAM, flash, UART, JTAG, points de test. Ce sont des patterns qu’on retrouve sur la plupart des appareils.
Les outils de base sont accessibles. Un multimètre, un analyseur logique à bas prix, un câble FTDI, un Bus Pirate, un microscope de soudure — c’est suffisant pour commencer sur des appareils réels.
Attention à l’alimentation. Débranchez l’appareil avant de le modifier. Ne travaillez pas avec de l’alimentation murale directement.
La patience et le processus comptent plus que l’expertise. Philippe insiste sur ce point : il n’est pas « hardware guy » de naissance. Il a appris en faisant, en documentant ses échecs, en partageant ce qui marchait et ce qui ne marchait pas.

Ressources mentionnées

Philippe référence plusieurs ressources dans sa présentation : le Hardware Hacking Village à DEF CON, les CTF pour s’entraîner sur des aspects logiciels d’embedded, un article sur le protocole JTAG, les tutoriels d’Azeria Labs sur l’analyse ARM avec IDA, un article de Quarkslab sur l’analyse de bootloaders ARM, le cas de Scanlime sur le dump de firmware d’une tablette Wacom par glitch hardware, et sa propre présentation Stepping P3wns à RSA (2014).

Le hacking hardware n’est pas une réserve aux ingénieurs qui passent leur temps à souder. C’est une méthodologie qui peut s’apprendre — reconnaissance, bonne identification des composants, utilisation d’outils accessibles, patience pour suivre les traces électriques. Philippe a montré qu’avec ces étapes, même quelqu’un avec un background logiciel pouvait obtenir un shell root sur un appareil réel, identifier et exploiter une vulnérabilité réelle, et transformer l’appareil en un outil d’écoute à distance. Pour le débutant, le message est celui d’une grande partie du hacking en général : ce n’est pas une boîte noire. C’est quelque chose qu’on peut ouvrir, comprendre, et travailler.