# Nous ouvrons le boîtier. Puis le firmware.

> Un test d’intrusion matériel (pentest hardware) attaque physiquement un système embarqué : interfaces de débogage comme UART, JTAG et SWD, puces mémoire, processus de démarrage et firmware lui-même. Les objectifs : extraire le firmware et les secrets, contourner le secure boot, obtenir l’exécution de code et trouver des failles qui touchent tous les appareils du même modèle. Zyberum réalise ces tests dans son propre laboratoire, sur des produits IoT, des ECU automobiles et des composants industriels.

Pentest hardware de systèmes embarqués : interfaces de débogage, extraction et rétro-ingénierie de firmware, secure boot, injection de fautes.

Source: https://zyberum.com/fr/pentest-hardware

Points de test, ports de débogage, puces flash et bootloaders : tout ce qu’un attaquant muni d’un tournevis et d’un week-end ira regarder. Nous le faisons dans notre laboratoire, avec les mêmes outils et davantage de patience.

## De la carte électronique au shell root

### Analyse de la carte

Identifier les composants, les points de test et les connecteurs de débogage, et retracer ce qui est relié à quoi.

### Interfaces de débogage

Consoles UART, JTAG et SWD : verrouillées, ouvertes, ou seulement réputées verrouillées.

### Extraction du firmware

Par le port de débogage, par le fichier de mise à jour ou directement depuis la puce flash.

### Secure boot et clés

Chaque étape vérifie-t-elle la suivante ? Où sont les clés, et qui peut les lire ?

### Injection de fautes

Glitchs de tension et d’horloge pour sauter des vérifications que le logiciel seul ne permet pas de contourner.

### Rétro-ingénierie

Analyse du firmware dans Ghidra : secrets, logique de mise à jour, commandes cachées et erreurs mémoire.

## Un seul appareil ouvert peut exposer tout le parc

Les attaques matérielles exigent un accès physique, ce qui semble rassurant. Ce ne l’est pas : un attaquant achète un appareil, en extrait le firmware, trouve la clé partagée ou le service caché, puis utilise ce qu’il a appris contre tous les appareils en service, à distance.

C’est pourquoi la réglementation l’exige désormais. Le Cyber Resilience Act, les exigences de cybersécurité de la directive RED (EN 18031) et l’IEC 62443-4-2 attendent tous des interfaces de débogage fermées, des secrets protégés et des mises à jour sécurisées.

**Voir aussi**

- Tests complets de produits IoT, application et cloud compris
- Tests d’ECU pour l’automobile
- Développement sécurisé et conception du secure boot
- Preuves pour le CRA et l’EN 18031

## Ce que nous avons trouvé sur de vrais appareils

## FAQ

**De combien d’appareils avez-vous besoin ?**

Deux ou trois. Une attaque matérielle peut détruire un appareil, par exemple lorsque nous dessoudons une puce flash.

**Testez-vous aussi l’application et le cloud ?**

Oui, dans le cadre d’un test complet de produit IoT. Beaucoup des pires failles naissent de la combinaison d’une faille matérielle et d’une faiblesse côté cloud.

**Pouvez-vous tester des microcontrôleurs verrouillés ?**

Souvent, oui. La protection en lecture peut parfois être contournée par injection de fautes ou grâce à des faiblesses connues de la puce. Lors de l’appel de cadrage, nous vous disons ce qui est réaliste pour votre appareil.

---
Zyberum GmbH. Canonical page: https://zyberum.com/fr/pentest-hardware