Le dernier recours : déboguer les systèmes embarqués avec des méthodes non conventionnelles 🇫🇷

Un débogueur est toujours un outil précieux pour la recherche de vulnérabilités, notamment dans les systèmes embarqués impliquant plusieurs périphériques. La plupart des cibles prennent en charge des protocoles de débogage standardisés tels que JTAG ou SWD, ou s'appuient sur des alternatives propriétaires. Ces ports de débogage sont souvent verrouillés pour empêcher tout accès non autorisé. Une fois verrouillés, selon la puce, il peut être possible de les réactiver en exploitant un bug. Dans les rares cas où cela n'est pas possible, une modification directe du firmware peut être envisagée. Dans ce cas, un débogueur intégré peut être implémenté au sein même du firmware. Bien que potentiellement instable, ce type de débogueur peut s'avérer très utile pour l'analyse du firmware et le développement d'exploits. Cette présentation offre un aperçu des concepts de base liés aux interruptions, suivi d'un guide détaillé sur la création d'un débogueur intégré, abordant les différents choix et défis qui peuvent survenir au cours du processus. Pour commencer, un canal de communication est nécessaire, de préférence un canal qui reste opérationnel même pendant une interruption de débogage. Un point d'arrêt initial doit être défini sur la cible pour déclencher le débogueur. Un gestionnaire de débogage, idéalement écrit en assembleur, doit être implémenté et configuré pour écouter les commandes de lecture et d'écriture du contenu de la mémoire et des registres. Un serveur intermédiaire entre GDB et la cible doit également être créé. Plusieurs squelettes open source sont disponibles pour faciliter cette tâche. De plus, la présentation met l'accent sur la conception d'un débogueur léger, destiné aux cibles embarquées. Elle présentera donc des techniques permettant de minimiser le code et d'en optimiser l'efficacité.
