Analyse de la carte
Identifier les composants, les points de test et les connecteurs de débogage, et retracer ce qui est relié à quoi.
Pentest hardware et embarqué
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.
En bref
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.
Nos prestations
Identifier les composants, les points de test et les connecteurs de débogage, et retracer ce qui est relié à quoi.
Consoles UART, JTAG et SWD : verrouillées, ouvertes, ou seulement réputées verrouillées.
Par le port de débogage, par le fichier de mise à jour ou directement depuis la puce flash.
Chaque étape vérifie-t-elle la suivante ? Où sont les clés, et qui peut les lire ?
Glitchs de tension et d’horloge pour sauter des vérifications que le logiciel seul ne permet pas de contourner.
Analyse du firmware dans Ghidra : secrets, logique de mise à jour, commandes cachées et erreurs mémoire.
Pourquoi c’est important
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.
Études de cas
Nous pouvions voir et activer les appareils d’autres clients via MQTT, et géolocaliser leur lieu d’installation.
Nous avons testé un système d’arrosage connecté : une configuration MQTT défaillante permettait de voir, piloter et localiser les appareils d’autres clients.
Lire l’étude de casAccès root complet sur l’appareil, et accès à la caméra WebRTC en direct d’autres utilisateurs via l’API cloud.
Nous avons testé un robot aspirateur à caméra : accès root sur l’appareil, et failles de l’API cloud ouvrant la caméra en direct d’autres utilisateurs.
Lire l’étude de casFAQ
Deux ou trois. Une attaque matérielle peut détruire un appareil, par exemple lorsque nous dessoudons une puce flash.
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.
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.
Passez à l’action
Parlez-nous de l’appareil, de son processeur et de ses interfaces. Vous recevez une offre à prix fixe après l’appel.

Vous échangerez avecTom ZaubermannFondateur et CEO, Zyberum
Nous répondons sous un jour ouvré.
Votre vie privée
Nous utilisons des cookies et des technologies similaires pour mesurer l’audience de notre site et l’efficacité de nos annonces. Vous choisissez ceux que nous pouvons utiliser. Vous pouvez modifier votre choix à tout moment via « Paramètres des cookies » en bas de page. Politique de confidentialité