Aujourd’hui, j’aimerais mettre en avant un outil qui amène vos compétences en piratage à un tout autre niveau, et ce, sans vous ruiner – en fait, étant donné le temps de débogage que vous pouvez gagner, le nombre d’activités amusantes que vous pouvez débloquer, et les nombreuses fonctionnalités que vous pouvez ajouter, cela pourrait être l’un des outils les moins chers que vous obtiendrez. Qu’il s’agisse de déboguer des problèmes étranges, d’optimiser votre code, de sonder un gadget sur lequel vous faites de l’ingénierie inverse ou peut-être d’essayer de comprendre la bibliothèque open source de quelqu’un, vous manquerez probablement beaucoup de choses si vous n’avez pas d’analyseur logique sous la main. !
Cela me brise le cœur que certains pirates informatiques ne connaissent toujours pas la valeur qu’apporte un analyseur logique. À maintes reprises, l’application tactique d’un analyseur logique m’a aidé à voir une perspective totalement différente sur quelque chose sur lequel je piratais, et c’est exactement ce que j’aimerais démontrer aujourd’hui.
Plonger dans
Un analyseur logique possède un certain nombre d’entrées numériques et il lit en permanence l’état de ces entrées numériques, les envoyant à votre ordinateur ou les affichant sur un écran – c’est comme un oscilloscope au niveau logique uniquement. Si vous disposez d’un bus I2C avec un MCU contrôlant un capteur, connectez un analyseur logique aux broches d’horloge et de données, câblez la terre, lancez le logiciel de l’analyseur logique sur votre ordinateur et voyez ce qui se passe réellement.
Par exemple, avez-vous déjà remarqué les broches ID_SC et ID_SD sur le connecteur GPIO du Raspberry Pi ? Vous vous demandez à quoi ils servent ? Vous ne voulez pas vérifier ce qui se passe réellement sur ces épingles ? Faisons-le maintenant !
J’utilise un analyseur logique à 10 $ que vous pouvez acheter sur Aliexpress ou Amazon, un ordinateur portable et un Raspberry Pi avec une carte SD et une alimentation. Ici, c’est câblé : vous n’avez besoin que de trois fils femelle-femelle, de deux signaux et d’une masse. « SD » et « SC » ressemblent à I2C – la fréquence I2C typique est généralement de 100 kHz ou 400 kHz. Une bonne règle de base consiste à définir votre fréquence pour qu’elle soit trois ou quatre fois supérieure à la fréquence d’horloge du flux de données que vous êtes sur le point de capturer. En tant que tel, je prévois de régler la fréquence d’échantillonnage de mon analyseur logique sur 2 MHz. S’il s’avère trop lent pour rattraper les données transférées, je peux augmenter la fréquence d’échantillonnage et simplement refaire l’échantillonnage.
Le logiciel que j’utilise est Pulseview – c’est une merveilleuse interface graphique pour les analyseurs logiques et peut s’interfacer avec une grande variété d’analyseurs logiques. Il est open source, compatible Linux, piratable et possède une bonne UX, même s’il n’a pas été récemment maintenu. Vous pouvez l’installer à partir du référentiel de votre distribution ou télécharger le .exe si vous êtes sous Windows. L’analyseur logique connecté, je le branche sur mon port USB, lance Pulseview, règle la fréquence d’échantillonnage et la durée de lecture, qui peut être infinie, désactive toutes les voies sauf les deux qui m’intéressent, appuie sur ‘Capturer’ et branche le Pi au pouvoir.
Après avoir branché le Pi, les niveaux logiques sur les deux broches augmentent à mesure que la puissance de 3,3 V apparaît – et, après quelques secondes, il y a une brève explosion d’activité sur ces deux broches. En zoomant, l’activité ressemble effectivement à I2C – et dans Pulseview, c’est assez facile à décoder ! Appuyez sur le bouton « Décodeurs de protocole » dans la barre des tâches des paramètres, tapez « I2C » sur votre clavier, sélectionnez le décodeur I2C, puis double-cliquez sur la balise du décodeur à gauche et sélectionnez quels canaux sont SCL et SDA – c’est facile à dire, SCL ressemblera à comme un signal d’horloge avec des hauts et des bas égaux, tandis que les intervalles hauts et bas sur SDA varient ; sur l’image ci-dessus, D1 est SCL et D0 est SDA. En zoomant sur les événements I2C décodés, nous pouvons voir que cette activité est constituée de requêtes I2C de lecture de données de l’adresse 0x50, et ces requêtes sont suivies d’événements NACK (marqueur rouge), ce qui signifie qu’elles ne reçoivent pas de réponse.
Maintenant, si vous avez examiné la conception du Raspberry Pi HAT, vous devinerez peut-être déjà que ces requêtes I2C proviennent du chargeur de démarrage du Raspberry Pi, qui recherche l’EEPROM I2C contenant les informations sur le périphérique HAT, afin que le Pi puisse charger le périphérique. Arborez les données de superposition et utilisez ces données pour configurer n’importe quel matériel sur le HAT connecté. Vous n’avez pas besoin de vous fier au peu d’informations disponibles en ligne sur ce processus : avec un analyseur logique, vous pouvez enquêter sur ce qui se passe réellement, trouver les fonctionnalités cachées et les mises en garde, de sorte que même le matériel propriétaire ne soit que peu un obstacle pour vous. que possible.
Tromper le micrologiciel propriétaire du Pi
Ceci est un exemple simple de ce que vous pouvez faire avec un analyseur logique et un Raspberry Pi avec un connecteur à 40 broches. Accélérons le tout ! Sur la seule carte Pi, I2C est utilisé à plusieurs endroits différents – configuration de l’écran HDMI, configuration de la caméra Pi, un expanseur GPIO sur le Pi 3 qui compense le manque d’E/S sur le CPU – il y en a beaucoup. Vous pouvez explorer tout cela pour le plaisir, mais atteignons un objectif pratique réel.
Que pourriez-vous faire avec tout cet I2C ? Eh bien, voici un petit problème situationnel avec les caméras Raspberry Pi : elles ne sont pas connectables à chaud ; et s’il y a une chose dont nous sommes sûrs, c’est que vous n’êtes pas toujours obligé de respecter les limites de votre technologie. Vous ne voudrez peut-être pas toujours que votre caméra Pi pende sur un câble, par exemple – c’est un peu médiocre, il est juste de vouloir que la caméra soit branchée uniquement si vous voulez réellement prendre une photo. Eh bien, maintenant nous pouvons réellement vérifier ce qui se passe sur le bus I2C de la caméra, et si c’est le coupable, le rendre hotpluggable ressemble exactement au genre de chose que nous pourrions réaliser – en plus, nous allons nous battre contre le firmware propriétaire sur le Pi pendant qu’on y est !
Techniquement, le micrologiciel Pi ne reconnaîtra une caméra Pi que si elle est branchée lors du démarrage – le chargeur de démarrage à code source fermé vérifie la présence de la caméra pendant le démarrage, ce qui implique certainement une communication via I2C, peut-être même en définissant certains registres I2C spécifiques à la caméra ; si aucune caméra n’est branchée lors du démarrage, cela n’arrivera pas et vous devrez redémarrer votre Pi pour que la caméra fonctionne. Mais après le démarrage, vous pouvez débrancher la caméra et la rebrancher, et cela fonctionnera très bien !
Compte tenu de cette énigme, je suppose qu’il n’y a vraiment aucune raison pour qu’une caméra Pi ne fonctionne pas si elle est branchée plus tôt, mis à part la logique inflexible de détection au démarrage. Le FPC de la caméra par défaut n’est pas non plus mécaniquement compatible avec le hotplug, je vais donc contourner ce problème en modifiant le FPC afin que les broches GND entrent en contact en premier lorsque vous le branchez à chaud. Le principal problème demeure cependant : le chargeur de démarrage Pi est à source fermée et nous ne pouvons pas modifier la logique de détection, ce qui fait qu’il ne s’exécute qu’une fois que le logiciel tente réellement d’accéder à une caméra. Nous pouvons cependant le pirater en connectant notre propre MCU à ce bus I2C et en le rendant présent comme une caméra sur le bus I2C !
Voici la feuille de route – nous connectons l’analyseur logique au bus I2C de la caméra Pi, voyons quel type d’activité se produit lorsque le Pi démarre, puis nous ajoutons un MCU qui exploite les broches I2C de la caméra – un RP2040 fera bien l’affaire, étant donné que il peut fonctionner comme un périphérique I2C. Le matériel nécessaire pour un tel hack est minime : une carte microcontrôleur et quelques câbles de démarrage, c’est tout.
Pirater un Pi avec un Pi
Après avoir soudé les résistances de rappel du bus I2C de la caméra sur un Pi Zero, j’ai capturé les communications I2C au démarrage avec la caméra v1 branchée, et voici mes résultats. Il y a trois adresses I2C interrogées au démarrage – 0x10, 0x1a et 0x36, ma caméra répond à 0x36. Apparemment, 0x10 est utilisé pour le capteur de la caméra Pi v2, et je suppose que 0x1a est la caméra 12 MP.
Avec l’appareil photo v1 5 MP que j’ai utilisé, rien n’est écrit dans les registres – il semble qu’il n’y ait que trois transactions qui lisent à partir des registres du capteur de l’appareil photo, chaque transaction envoyant d’abord deux octets d’écriture, ce qui est généralement une adresse de registre dans de telles transactions. Avoir des adresses de registre sur deux octets rend ces transactions un peu bizarres ! Cela dit, le fait de pouvoir débrancher et rebrancher la caméra sans problème m’amène à penser que cela ne devrait pas poser de problème.
Maintenant que je sais ce qui se passe sous le capot, je vais débrancher les trois câbles de liaison de l’analyseur logique, les connecter à une petite carte RP2040 que j’ai et me lancer dans le piratage du côté logiciel du projet. Si je parviens à faire fonctionner le firmware d’émulation de périphérique I2C, j’aurai le hotplug de la caméra Pi v1 opérationnel pour tous mes besoins de construction d’appareils portables ! Juste comme ça, avec un analyseur logique et trois fils, nous avons trouvé un moyen d’ajouter une capacité de connexion à chaud à la caméra Raspberry Pi – ce qui était considéré comme impossible, jusqu’à ce que nous décidions de le sonder.
Ce type de hack est le cas où un analyseur logique est le meilleur outil pour le travail, et vous avez peut-être remarqué que quelques parties cruciales de ce hack, à savoir le reniflage des données I2C transmises, ne sont pas réalisables sans un analyseur logique.
Il vous donne également un aperçu du fonctionnement des éléments propriétaires – à la fois dans l’exemple de détection HAT EEPROM et dans l’exemple de détection de caméra, nous pouvons voir que chaque transaction échouée est répétée trois fois, et vous n’auriez pas tort de deviner que le chargeur de démarrage du Raspberry Pi Le code a un wrapper de transaction I2C qui réessaye les transactions I2C en cas d’échec fallacieux d’une transaction – une bonne pratique de bout en bout !
Vous envisagez de vous procurer un analyseur logique ? Les analyseurs sont parfaits pour ce qu’ils sont et seront suffisants pour la majorité des tâches, et ils coûtent environ 10 $ sur les marchés en ligne typiques – plus que suffisant pour tout ce que vous voudrez peut-être sonder. Vous pouvez également utiliser un Pi Pico comme analyseur logique – même si vous constaterez que vous devrez probablement compiler Pulseview et le logiciel sous le capot vous-même pour inclure la prise en charge de cela, faisable mais moins simple que d’utiliser l’un des logiciels basés sur FX2. analyseurs avec support Pulseview d’origine.
Gardez votre analyseur logique à portée de main et il vous aidera à sauter des étapes entières de votre parcours de piratage, simplement en dépassant les limites et en vérifiant ce qui se passe réellement. La prochaine fois, j’aimerais vous montrer où les analyseurs logiques brillent et où ils échouent – leurs capacités, contraintes et faiblesses, ainsi que les différents types d’opérations que vous pouvez trouver, tout en piratant une tâche matérielle amusante – restez à l’écoute !
