Le développement logiciel sur microcontrôleur s’est considérablement simplifié ces dernières années, entres autres par l’arrivée de SDK et de librairies toujours plus intégrées. Cela permet de démarrer plus rapidement de nouveaux projets et accélère la mise à disposition de "proof of concept". Dans un second temps, vient la phase de mise au point (et/ou debug) où une bonne compréhension des mécanismes internes d’un microcontrôleur deviennent plus importants.
L’objectif de cette formation est de voir (ou revoir) les techniques de debug pour des logiciels embarqués sur microcontrôleur au moyen d’un challenge ludique : hacker une clef USB.
Résumé
Logiciels : GCC, OpenOCD, GDB
Durée : 14 heures sur 2 jours
Objectifs :
– perfectionner la démarche de debug en embarqué
– appréhender la sécurité des firmwares
Pré-requis : avoir une première expérience de développement logiciel sur microcontrôleur et avoir les bases du langage C
Public : tout personne ayant une expérience en développement embarqué
Méthodes mobilisées : alternance d’apports théoriques et d’exercices de mise en application pratique. Chaque aspect théorique est illustré par des exemples concrets issus de cas réels de traitements en embarqué. Des travaux pratiques mettant en œuvre l’ensemble des savoirs sont réalisés dans des machines virtuelles et sur des cartes réelles.
Modalités et délais d’accès : sur inscription préalable au minimum 1 semaine avant le début de la formation selon disponibilité du formateur.
Modalités d’évaluations : une évaluation du niveau des stagiaires est réalisée avant l’entrée en formation par téléphone ou au moyen d’un questionnaire. Évaluation des acquis et de la satisfaction en fin de formation.
Accessibilité aux personnes en situation de handicap ou présentant des difficultés d’apprentissage : nous pouvons proposer des solutions de compensation de nos prestations en adaptant les moyens pédagogiques, techniques et d’encadrement (les précisions).
Taux de satisfaction 2i2L : 96,34 % des stagiaires sont satisfaits à l’issue de leur formation.
Tarif : pour une demande de formation interne, nous consulter.
Présentation
Cette formation dédiée aux développeurs juniors, comme aux plus expérimentés, permet de découvrir ou redécouvrir les outils et méthodes pour faire du debug sur le code d’un microcontrôleur. Le sujet de départ est simple "Il faut hacker un dongle USB !". Identifier et mettre en place les outils, analyser la mémoire, exécuter le code pas à pas, et surtout mesurer l’impact du debug sur le comportement du logiciel, sont les aspects qui sont abordés dans cette formation.
– OpenOCD : Open On-Chip Debugger
– GDB : The GNU Project Debugger
Programme
Prise en main de la cible
Lorsque l’on commence à travailler avec un nouvel appareil, ou device, ou produit, l’identification de son architecture et des composants principaux est une étape importante de prise en main.
– Analyse visuelle d’une carte électronique
– Recherche des documentations nécessaires
– Identification des ports de communication et interfaces disponibles
Chaîne de debug et OpenOCD
Quelque soit le type de composant, les différents éléments de la chaîne de debug sont toujours les mêmes. Durant cette formation, nous allons utiliser le logiciel OpenOCD mais les principes abordés sont applicables avec d’autres outils.
– Présentation d’OpenOCD : une boite à outils universelle
– Interface CMSIS et cible ARM
– Introduction aux scripts GDB
Manipulation de la mémoire de la cible
Connaître l’état d’un programme, c’est avant tout savoir ce qui se trouve dans la mémoire ou plutôt dans les mémoires auquel le processeur a accès.
– Lire et écrire dans la RAM
– Consulter et modifier l’état des périphériques mappés en mémoire
– Mesurer l’impact du debugger sur la mémoire (an particulier les caches)
– Analyser la stack
Analyse du code et exécution pas à pas
Après l’étude statique de la mémoire qui donne une image à un instant *t*, place à l’exécution ! L’utilisation de points d’arrêts et l’exécution pas à pas permettent de rentrer dans le fonctionnement dynamique du programme.
– Consulter l’état des registres du processeur
– Les points d’arrêt ... hardware ou software ?
– Masquer les interruptions ... ou pas
Comment protéger un programme
Selon le contexte, le terme *protection* peut faire référence à la fiabilité du fonctionnement ou bien à la sécurité face à une tentative d’intrusion. Dans cette dernière partie, l’objectif est de faire une introduction à quelques techniques de protection, des techniques d’intrusion, les contres-mesures ...
– Les blocs MPU, MMU (... et présentation de meltdown et KPTI)
– ARM TrustZone
– Secure Boot, un firmware chiffré est-ce vraiment suffisant ?