Nous avons commencé par déterminer les descripteurs HID il y a une semaine, et je vous ai montré comment envoyer des paquets HID bruts à l’aide d’un fork MicroPython. Nous avons encore une tâche devant nous : fabriquer un appareil à écran tactile. Pour cela, donnons-nous les outils nécessaires pour capturer un descripteur existant à partir d’un écran tactile, puis montrons comment le modifier et comment cela se passe au final.
Emballage pour le braquage
Quand il s’agit de ce genre d’aventure, nous ne pouvons pas nous passer d’outils et d’armes – cela pourrait être dangereux ! Sans eux, vous pourriez même abandonner votre projet à mi-chemin ! Voici suffisamment d’outils et de munitions de haute précision pour vous permettre de surmonter tous les obstacles que vous pourriez rencontrer. À l’exception des outils Web, ces outils sont destinés à Linux, mais n’oubliez pas que vous pouvez toujours utiliser une machine virtuelle ou un Raspberry Pi. De toute façon, personne n’utiliserait Windows pour un braquage, à cause de toute la télémétrie et autres.
Le premier outil sert à lire les descripteurs – nous en avons besoin pour apprendre, c’est comme une carte d’accès que vous pouvez montrer à un agent de sécurité et scanner à l’entrée du coffre-fort. Bien sûr, avec la RFID, vous voulez avoir suffisamment d’exemples, comparer les bits entre quelques cartes et tout. Pour l’instant, les descripteurs HID n’ont pas de contrôle d’authenticité, mais il semble que cela pourrait changer à l’avenir. Laissez à Apple et Microsoft le soin de les ajouter, comme d’habitude. Sous Linux, voir les descripteurs est simple : en tant que root, allez dans /sys/bus/usb/devices/recherchez votre appareil grâce à son lsusb chemin de l’arborescence des périphériques, puis suivez le répertoire contenant le VID/PID. Ce répertoire contiendra un report_descriptor déposer – hexdump il. La commande entière pourrait ressembler à ceci :
sudo hexdump -v -e '/1 "%02X "' /sys/bus/usb/devices/3-6.2/3-6.2\:1.1/0003\:0C40\:8000.0022/report_descriptor`
Encore une fois, vous aurez peut-être besoin de root pour trouver ce chemin, alors utilisez sudo -i si tu dois. La chaîne de format dans le hexdump La commande vous donne une sortie conviviale pour l’analyseur. Plus précisément, pour l’analyse, j’utilise cette page Web – c’est merveilleux, ajoutant même des onglets qui délimitent différentes sections du descripteur, rendant sa sortie d’autant plus lisible ! Vous pouvez également enregistrer cette page Web localement, c’est un outil très intéressant. En dehors de cela, vous pouvez essayer d’autres outils locaux comme celui-ci !
Maintenant, vous disposez d’un descripteur pour un appareil dont vous souhaitez imiter le comportement, et vous pouvez l’analyser pour voir ce qui le motive. Merveilleux! Mais pas quelque chose que vous pouvez comprendre d’un seul coup d’œil, pas encore ? Le descripteur seul ne se prête pas à la création d’une carte mentale, il peut contenir plusieurs ID de rapport et certains descripteurs seront suffisamment génériques pour prêter à confusion. Par exemple, de nombreux appareils ont des descripteurs qui sont en fait des points de terminaison pour les mises à jour du micrologiciel, vous risquez donc de passer du temps à déterminer quand le descripteur n’est réellement jamais utilisé. Jetons un coup d’œil à ce que notre appareil envoie réellement lorsque nous interagissons avec lui, de quel identifiant de rapport nous devrions tirer des leçons – et surtout, comment un système d’exploitation Linux l’interprète.
Pour cela, nous n’avons besoin que de VID et PID. En tant que root encore une fois, allez sur /sys/kernel/debug/hid/trouvez un répertoire avec votre VID et votre PID, puis cat c’est events déposer. Vous y trouverez une jolie description lisible par l’homme de chaque événement que vous recevez de votre appareil, dès son apparition. Parfois, le processus d’impression a des problèmes et s’arrête au milieu de l’événement – cela peut être dû à la façon dont il se déroule. cat‘ed, mais ce n’est généralement pas une grosse perte. C’est une merveilleuse façon de voir ce qui se passe réellement lorsque votre appareil HID est actif. Le premier octet est l’ID du rapport, puis le paquet est imprimé tel qu’il a été reçu, et après cela, nous voyons les résultats de l’analyse du système d’exploitation. C’est tout simplement un outil incroyable à avoir ! Voici un exemple de ligne de commande :
sudo cat /sys/kernel/debug/hid/0003\:2E8A\:0005.0029/events
Enfin et surtout, vous aurez besoin d’un moyen de voir les événements tels que les couches d’entrée de votre système d’exploitation les interprètent réellement. Oui, c’est différent : si un paquet arrive, il n’est pas nécessairement converti en un événement d’entrée au niveau du système d’exploitation, il est parfois rejeté car il ne remplit pas une certaine condition. Par exemple, à un moment donné, mes paquets d’écran tactile ont été rejetés parce que j’envoyais uniquement des coordonnées et j’ai omis un élément crucial indiquant au système d’exploitation qu’un écran tactile transmettait actuellement un événement tactile valide par opposition à un toucher parasite. Ce bit est au premier plan dans les « notes d’application » de Microsoft sur la création de numériseur, et voir que mon système d’exploitation n’a pas « pris en compte » mes événements construits était le coup de pouce dont j’avais besoin pour jeter un coup d’œil dans la note d’application et vérifier ce que mon paquet pouvait manquer.
Pour cela, j’ai mon propre petit script Python qui imprime les événements au fur et à mesure qu’ils sont reçus par les couches de bibliothèque d’entrée, et ce script me sert depuis environ une décennie maintenant. Téléchargez-le simplement et exécutez-le – vous devrez installer la bibliothèque Python `evdev`, mais elle est disponible à la fois dans les référentiels Debian/Ubuntu et dans `pip`. Vous devez également exécuter celui-ci en tant que root, mais cela se produit lorsque vous l’exécutez automatiquement en tant que `./listen_keys.py`.
Je préfère exécuter toutes ces différentes commandes dans tmuxdifférents petits volets pour différentes tâches en cours – voici mon espace de travail lorsque je développais et déboguais le code de l’écran tactile, où a) affiche l’impression brute des événements HID, b) affiche l’impression du descripteur HID et c) affiche le code d’affichage de l’événement d’entrée.
Un déguisement parfait
Avec ces outils, construire un écran tactile était le travail d’une soirée. J’avais les coordonnées de la bibliothèque XPT2046 que j’utilisais, donc tout ce que j’avais à faire était de créer un descripteur. Au départ, j’ai pensé réutiliser le descripteur « position absolue de la souris » fourni utilement par [] avec le code, mais le script d’impression des événements d’entrée m’a montré que même les pressions sur les boutons de la souris de ce script n’étaient pas captées par l’interface utilisateur – et bien que les événements MOUSE_ABS soient apparus, ils n’ont en aucun cas affecté mon bureau.
Déboguer le travail du descripteur de souris ne semblait pas amusant, d’autant plus que je n’ai même pas de souris absolue et fonctionnelle pour apprendre ! Au lieu de cela, j’ai décidé de reconstruire le descripteur absolu de la souris en descripteur de numériseur, puisque j’ai à la fois le descripteur de numériseur et les paquets ! Le descripteur absolu de la souris a été utilement exposé séparément dans les sources MicroPython et prêt à être peaufiné également ! Changer le USAGE et USAGE_PAGE Les seules catégories à celles du descripteur de l’écran tactile USB ont permis à mon système d’exploitation de reconnaître ma carte RP2040 comme un numériseur.
Les changements réels n’étaient pas compliqués – la bibliothèque XPT2046 fournissait deux coordonnées entières, j’ai donc copié une structure à partir d’un descripteur qui décrivait une valeur X et une valeur Y, chacune longue de 16 bits et donc divisée en deux octets chacune, tout comme mon écran tactile USB. Avec l’aide du mécanisme d’impression de débogage des paquets HID, j’ai pu rapidement remarquer quand mes octets supérieur et inférieur étaient échangés, car mon système d’exploitation n’interprétait pas correctement les coordonnées. Après avoir résolu ce problème, mes paquets seraient analysés correctement mais n’apparaissaient pas parmi les événements d’entrée, et en comparant les paquets d’écran tactile USB fabriqués en usine aux paquets construits à la main de mon écran tactile DIY, j’ai pu remarquer qu’un bit « toucher valide » manquait. En ajoutant cela, l’appareil se comporte comme un écran tactile à toutes fins pratiques !
Maintenant, j’ai un écran tactile DIY connecté par USB, et il suffisait de voler un descripteur HID sur un autre écran tactile, puis de l’imiter d’assez près. De plus, quand je le souhaite, je peux passer mon écran tactile en mode pavé tactile en lui faisant envoyer des paquets avec un ID de rapport différent qui correspond au descripteur de souris du firmware – il ne lui manque que deux boutons de souris pour être un pavé tactile complet pour ordinateur portable ! Étant donné que je l’utilise pour prototyper un écran portable, cela sera extrêmement utile.
À l’entrée et à la sortie, nous avons sécurisé les marchandises
En l’état, l’écran tactile USB nouvellement baptisé a besoin d’un peu de filtrage et d’étalonnage, mais ce sont de minuscules correctifs – ils pourraient probablement également voler certains algorithmes de filtrage des pilotes Linux XPT2046 ! Il est plug&play, facile à utiliser et piratable – ce n’est plus l’écran tactile SPI qu’il était censé être. Surtout, c’est un excellent exemple : si vous souhaitez créer un périphérique HID un peu farfelu, ce n’est pas difficile à faire, et Linux vous propose une boîte à outils puissante qui vous aide à détecter tout problème HID, peu importe jusqu’où vous le souhaitez. aller.
Il y a des tonnes de choses que vous pouvez faire si vous comprenez HID. Par exemple, vous pouvez créer un afficheur braille compatible sans avoir à vous soucier des numéros de série USB-UART. Sur Hackaday Discord, [mupf] a piraté un appareil compatible avec la manette adaptative XBox qui utilise un magnétomètre et un gyroscope pour envoyer le système d’exploitation, avec le descripteur HID fortement informé par un descripteur vidé d’une manette adaptative Xbox d’origine. La spécification HID décrit un grand nombre de choses, même des affichages de caractères connectés par USB, et des choses comme : vous pouvez envoyer des quaternions avec l’aide de HID, entre autres !
La prise en charge de HID rend votre périphérique d’entrée convivial et l’aide à mieux interagir dans le monde des logiciels. HID est, à la base, un langage compris par tous les systèmes d’exploitation principaux, et donner à votre appareil une interface HID vous permet d’éviter d’ajouter une couche de langage propriétaire entre votre appareil et tout type de logiciel avec lequel vous souhaitez interagir. Et, bien sûr, HID est un excellent outil de piratage – cet outil d’automatisation de smartphone en témoignera à lui seul !
La prochaine fois, j’aimerais vous en montrer plus sur I2C HID – l’envoi de paquets et de descripteurs HID via I2C, sans nécessiter de port USB du tout et en utilisant uniquement une connexion I2C, qui est désormais assez omniprésente ! Dans ce contexte, je vais vous montrer comment réutiliser un pavé tactile d’ordinateur portable Framework, qui utilise I2C-HID pour ses communications. J’espère modifier QMK afin que nous puissions nous entraîner à ajouter des pavés tactiles I2C à tous les claviers contrôlés par QMK, mais nous pourrions simplement nous contenter de modifier KMK, qui est l’équivalent de QMK mais dans CircuitPython. Je vais également vous montrer comment connecter rapidement un périphérique I2C-HID à votre SBC Linux – c’est plus facile que vous ne l’imaginez ! Et, si les étoiles s’alignent et que la prise en charge du mode périphérique I2C dans le MicroPython RP2040 s’avère suffisamment stable, nous pourrions même construire notre propre périphérique HID I2C alimenté par le RP2040 en guise de dessert.
