coremaze/me2-writeupReconstruire un protocole USB mort : les secrets d’une console portables déverrouillés par un couteau chaud, un voyage multidisciplinaire pour ressusciter une interface USB oubliée
En 2024, bjiru a mis en ligne une vidéo sur le dispositif portable ME2, un jouet produit vers 2008 qui permettait d'utiliser l'USB pour synchroniser des points et des gemmes entre votre appareil et un monde en ligne. Le jeu était extrêmement de niche, donc aucun logiciel, pilote ou actif n'avait été archivé, du moins jusqu'à ce que bjiru se manifeste avec le client du jeu en ligne.
Je suis le leader de Miuchiz Reborn, un effort qui a commencé en 2015 pour préserver, rétro-ingénieriser, émuler et maintenir l'accessibilité d'un jeu similaire à celui-ci, avec une partie en ligne et une partie portable connectée via USB. En raison de l'âge et du type de jeu similaires, le ME2 avait déjà été porté à mon attention par ma communauté Miuchiz en 2018, car ils pensaient (à tort) qu'ils pourraient partager des similitudes architecturales. Bien que j'aie été conscient de l'existence de l'appareil pendant des années, la vidéo de bjiru m'a finalement incité à commencer des recherches à son sujet.
Mes premiers efforts étaient uniquement consacrés à recréer le serveur nécessaire pour rendre à nouveau fonctionnelle la copie de bjiru du jeu informatique, mais en cours de route, mon attention a inévitablement dérivé vers le portable. Une reconstitution du jeu en ligne ne pourrait sûrement jamais être complète sans le mécanisme de synchronisation de vos points depuis et vers l'appareil. Cette communication entre votre ordinateur et le ME2 était après tout le principal argument du jeu. Je pensais que mon expérience antérieure avec les appareils portables Miuchiz m'aiderait à démêler rapidement le rituel de communication qu'ils attendent... tant que je pouvais obtenir du code à rétro-ingénieriser.
Ma curiosité exigeait le sacrifice de ME2. eBay exigeait le sacrifice d'argent fiduciaire. Peu de temps après, ces spécimens gisaient devant moi.
Ce sont de petites unités avec seulement quelques boutons et un port mini-USB femelle. Un câble est inclus dans la boîte, mais il n'y a aucun disque pour le logiciel et les pilotes. Ce port USB serait le moyen de synchroniser les points entre votre ordinateur et le portable, mais lorsque j'ai entrepris le même voyage pour l'appareil portable Miuchiz, j'ai obtenu un accès complet à sa mémoire flash en rétro-ingénierisant le fonctionnement de son logiciel Windows d'accompagnement. Sans un tel logiciel pour le ME2, il n'y a rien à rétro-ingénieriser pour comprendre comment communiquer avec l'appareil. Même après avoir vérifié Wayback Machine et bjiru, il ne semble y avoir aucune copie survivante du logiciel utilisé pour parler à ces objets. Je pense qu'il s'appelait ME2 Desktop Buddy, mais cette application était distincte du client de jeu que bjiru a récupéré. Le portable se présente comme un périphérique de stockage amovible, mais son contenu vous dirige simplement en ligne pour télécharger le jeu ME2, qui n'est plus disponible.
La voie à suivre est claire, car il ne reste qu'une seule option : ouvrir le matériel.
Le firmware principal du ME2 est stocké sur une SST39VF3201, une puce flash de 2 megawords (4 mégaoctets, avec des unités adressables de 16 bits). Le microcontrôleur principal est... sous un glob-top d'époxy dur. C'est ce qu'on appelle un chip-on-board (CoB) et c'est généralement une mesure d'économie de coûts, mais cela a pour effet secondaire de cacher toute information d'identification sur le circuit intégré à l'intérieur. Une puce emballée normalement aura généralement des marquages qui l'identifient, tout comme la puce flash. Étant donné que les microcontrôleurs utilisés dans des appareils comme ceux-ci contiennent souvent une ROM interne, il est possible qu'une partie ou la totalité du code USB que je voulais rétro-ingénieriser se trouve dans cette ROM. Avoir ce code en ROM présente l'avantage de permettre la récupération d'un appareil brické ou, si le fabricant le choisit, de flasher l'appareil après assemblage. Cette ROM existerait à l'intérieur d'une puce que je n'avais aucun moyen d'identifier.
Récupérer les données de la puce flash est un processus simple et bien documenté : dessouder la puce, la mettre dans un programmateur flash standard comme ceux de XGecu, et l'utiliser pour dumper le contenu. Si j'avais également besoin d'informations de la ROM du microcontrôleur, c'est moins simple, mais c'est faisable pour un appareil comme celui-ci où la protection est peu probable. Par le passé, j'ai ajouté du code à la flash SPI d'un Tamagotchi Pix qui copierait sa ROM de démarrage dans l'espace libre de la puce flash, qui pourrait ensuite être lue par le même programmateur flash que j'avais utilisé pour injecter le code. Cependant, dans ce cas, le microcontrôleur était correctement emballé et portait des informations de modèle imprimées, donc je pouvais trouver sa fiche technique pour connaître le jeu d'instructions utilisé et où se trouvait sa ROM dans l'espace mémoire. À ce stade, je n'avais aucune de ces informations pour le mystérieux chip-on-board du ME2.
Malgré les incertitudes, la seule voie apparemment possible à partir de là est de dessouder la puce flash. J'avais également acheté des sockets pour la puce flash dans l'espoir de pouvoir en souder une sur le PCB du portable. Cela me permettrait de reprogrammer le ME2 et d'itérer rapidement si je devais écrire du code pour dumper la ROM interne du microcontrôleur.
Malheureusement, je n'ai pas réussi à enlever la puce flash avec un fer à souder sans endommager la puce. Pour résoudre ce problème de compétence après plusieurs tentatives infructueuses, j'ai plutôt acheté une station de rework (effectivement un pistolet à air chaud qui prétend pouvoir atteindre 500 °C) et j'ai retiré la puce en faisant fondre la soudure avec de l'air chaud. Cela m'a permis de dumper le contenu de la flash sans problème, mais cela a révélé qu'utiliser réellement les sockets que j'avais achetés allait au-delà de mes capacités. Non seulement je devrais souder les 48 minuscules broches sur le PCB, mais je devrais aussi le faire assez rapidement pour éviter de faire fondre le plastique des sockets. Je n'avais ni les outils ni les compétences pour gérer cela, donc si j'avais besoin de la ROM, il me faudrait une autre stratégie.
Le dump avait l'air bon, cependant, et en utilisant un outil que j'avais déjà construit spécifiquement pour trouver des bitmaps non compressées dans les dumps de firmware, j'ai pu trouver des images qui seraient normalement affichées sur l'appareil :
J'ai obtenu un dump du firmware de la puce flash, mais avant de pouvoir faire de la rétro-ingénierie sérieuse, j'ai au moins besoin de savoir quel jeu d'instructions l'appareil utilise. Il n'y avait aucun marquage sur le matériel lui-même, donc il faudrait deviner. J'ai essayé d'analyser le code dans Ghidra, un désassembleur, décompilateur open source, et cauchemar bancal qui me maintient employé, avec presque tous les types de spécifications de processeur qu'il propose. Une variante ARM ? Un descendant 6502 ? MIPS ? Littéralement autre chose supporté par Ghidra ? Tout était un "non" retentissant.
J'ai tout essayé, et rien ne désassemblait ce code. Je savais que c'était du code, car je pouvais même trouver des parties du code que je cherchais !
Grâce à mon travail antérieur sur l'appareil portable Miuchiz, j'avais une certaine familiarité avec le fonctionnement des périphériques de stockage de masse USB. J'ai identifié cet extrait comme étant presque certainement en train de déplacer 'U', 'S', 'B', 'S' quelque part, ce qui est une signature spécifique au type de communication de stockage de masse USB que je recherchais. Une partie ou la totalité du code USB que je devais rétro-ingénieriser pour comprendre comment interagir avec cet appareil se trouvait définitivement dans ce dump de flash, mais sans aucun indice sur le jeu d'instructions dans lequel il était écrit, je ne pouvais pas le désassembler.
À ce stade, j'avais quelques unités ME2 cassées. Cela semble stupide, mais peut-être y a-t-il des marquages quelque part sous les blobs d'époxy ? Probablement pas, mais pour la phase de recherche, une unité complètement décimée est parfois plus précieuse qu'une unité simplement cassée.
Eh bien, j'avais un pistolet à air chaud, et j'avais un couteau. Comme on dit, quand on a un pistolet à air chaud et un couteau, tout ressemble à... un clou ? Je pense que c'est comme ça que va le dicton.
En réglant la station de rework à sa température maximale et en faisant levier avec un couteau, j'ai libéré tout le blob d'époxy. Son départ n'a révélé aucun marquage sous le chip-on-board désormais hors de la carte. On peut voir le dessous du die en silicium du microcontrôleur, et l'époxy a quelques bulles d'air à travers lesquelles on peut voir les fils de bonding.
Comme je l'ai dit, parfois une unité décimée vaut plus qu'une unité cassée, et j'avais un pistolet à air chaud, un couteau, et un besoin urgent de rafraîchir mes idiomes.
Oh.
Hein.
Je n'avais aucune idée qu'on pouvait décapsuler un CoB de cette façon. Il est simplement sorti proprement, et vu sa température, je suis content qu'il ne l'ait pas fait dans ma direction. C'est très joli, mais il y a en fait une voie à suivre à partir de là. Laissez-moi juste y regarder de plus près avec mon microscope électronique.
Eh bien, c'est ce que son manuel d'utilisation prétend qu'il est. Pour être juste, j'ai vérifié, et il contient au moins un électron.
Alors que je détruisais "hackais" d'autres jouets dont les petits composants mettaient mes yeux au défi, il est devenu évident que je savais rarement ce qui se passait à l'autre bout de mon fer à souder. Une recommandation très courtoise d'un ami a abouti à l'achat d'un microscope numérique bon marché, destiné aux pièces de monnaie et au soudage.
Bien qu'il ne soit pas vraiment un équipement adapté à la tâche, contrairement aux affirmations de son manuel, j'ai capturé cette image avec le microscope. Elle est loin de pouvoir déchiffrer un texte sur le die, mais la disposition générale est claire, et je savais où je pouvais trouver plus d'images comme celle-ci.
Siliconpr0n, maintenant connu sous le nom de Siliconprawn, possède une archive où de nombreuses personnes ont téléchargé des photos de die, bien qu'habituellement de meilleure qualité que la mienne. Malheureusement, il n'y a aucun moyen utile de rechercher le site étant donné les informations dont je disposais, j'ai donc commencé à cliquer, et à faire défiler, et à répéter...
Ses empreintes digitales sont dans le registre !
Après plusieurs heures, à 4 heures du matin, j'ai enfin repéré quelque chose de familier. C'est de meilleure qualité que la mienne, mais la disposition est indubitable. J'ai un GPL162002A (ou B) tourné de 180 degrés par rapport à l'image correspondante prise par John McMaster. C'est un microcontrôleur GeneralPlus, sa fiche technique est disponible sur Internet, et son jeu d'instructions est μ'nSP.
μ'nSP, s'avère être assez courant pour les jouets de ce type et de cette époque. J'espère que l'on me pardonnera de ne pas avoir deviné que c'était un jeu d'instructions dont le nom contient des caractères qui ne font même pas partie de l'alphabet latin. Malgré cela, il reste suffisamment niche pour ne pas être supporté par Ghidra par défaut. Heureusement, il existe un travail tiers existant pour cela, j'ai donc pu commencer à le désassembler dans Ghidra, à nommer les fonctions et à importer les noms de registres à partir de la fiche technique.
Voici la fonction dont j'étais si certain qu'elle était du code USB simplement d'après son dump hexadécimal, interagissant avec les registres USB comme spécifié dans la fiche technique du microcontrôleur :
Comme je l'ai noté précédemment, j'étais déjà quelque peu familier avec la façon dont les périphériques de stockage de masse USB comme celui-ci communiquent, notamment grâce à un travail expérimental de portage de ma bibliothèque USB Miuchiz vers macOS en utilisant libusb. Les périphériques de stockage de masse USB tunnelisent essentiellement des commandes SCSI, et celles-ci sont bien documentées en ligne. Par exemple, il existe des commandes pour demander une lecture ou une écriture sur le périphérique.
Cependant, je savais qu'en général, les commandes standard, comme pour la lecture ou l'écriture, ne me seraient pas utiles. Ce sont celles que votre ordinateur sait déjà faire avec ses pilotes de stockage de masse intégrés. Il les émettra pour interagir avec lui comme avec n'importe quel périphérique de support amovible ordinaire. Dans ce cas, la commande de lecture récupérera simplement le système de fichiers contenant le fichier d'aide, et la commande d'écriture ne fera rien, car il n'est pas censé être inscriptible. Ce ne sont pas pour interfacer toute la puce flash ; au lieu de cela, ils sont effectivement un minuscule CD-ROM simulé pour aider les utilisateurs novices.
Certains ID de commandes, cependant, sont réservés à ce que le vendeur souhaite implémenter. Des gestionnaires pour certains ID réservés sont grossièrement injectés avant que la recherche d'ID normale ne s'exécute.
Grâce à une analyse statique, j'ai pu identifier et nommer les fonctions que je cherchais : lire, programmer et effacer la flash. Ce sont toutes des commandes non standard qui ont été implémentées pour le ME2 et peut-être d'autres appareils GeneralPlus, et presque certainement utilisées par le logiciel et les pilotes qui accompagnaient originalement l'appareil. Vous pouvez créer un message USB pour déclencher n'importe lequel de ces chemins. Lire vous permet de récupérer des données de la flash. Programmer vous permet de "programmer" la flash. Effacer vous permet de remettre tous les bits d'une région flash à 1, ce qui, combiné avec la commande de programmation, peut émettre une écriture complète sur la flash, car la "programmation" ne peut que passer des bits de 1 à 0. Chacune des commandes personnalisées qui m'intéressaient utilise l'ID réservé 0xFF suivi d'IDs pour les sous-commandes et tous les paramètres nécessaires à l'opération.
Les structures exactes des commandes ne sont pas particulièrement pertinentes pour le lecteur, mais la méthodologie pourrait l'être. J'ai utilisé libusb (en fait, rusb) pour faciliter toute mon interaction via USB. Cette méthode permet d'écrire du code en espace utilisateur pour interagir avec votre périphérique USB, par opposition à l'écriture d'un nouveau pilote.
Lorsque le logiciel Windows ME2 a disparu d'Internet, c'était comme si l'avant-dernier locuteur de sa langue était mort. Le dispositif portable ME2 est devenu, en un sens, un locuteur terminal. Avec un peu d'expérimentation et un peu de lecture de décompilation parfois correcte, je lisais son esprit pour apprendre les mots de sa langue presque éteinte. Lorsqu'il a répondu, j'ai su que j'étais sur la bonne voie.
Č̶̯a̴̩͗n̵͉͆ ̴͍͠Ǐ̶̜ ̴͈͌h̷̙̔á̶͉v̸͈̽é̴̢ ̵͍͛a̵̞͝ ̴̤̉s̵̡͊ē̴̮c̸̭̅t̶̛͖o̸̡͠r̶̺̊ ̶̥̀ǫ̸̀f̸̦́ ̷̈ͅỳ̷͎o̶̦̐u̵͙̚r̶͙͒ ̵̥̕f̸̡͝l̷͈̄a̶͍͋s̸̢̓h̸̗͝?̴̪̕
...Non ? Ce doit être mon accent. Laissez-moi ajuster et demander à nouveau : Puis-je avoir un secteur de votre flash ? Et le secteur suivant ? Êtes-vous prêt à programmer certains des bits de ce secteur ? Puis-je avoir votre flash à nouveau pour voir si elle est différente maintenant ? Oserais-je vous demander d'effacer un secteur... et d'espérer comprendre lequel je vous demande de détruire ?
Une par une, j'ai écrit le code pour structurer, remplir et transmettre les messages que le ME2 devait entendre. Une fois que nous étions sur la même longueur d'onde, je lui ai demandé de m'envoyer quelques dumps de flash tout en ayant différentes quantités de points. Après les avoir comparés, j'ai pu identifier où les points sont stockés dans la flash et enfin utiliser mon ordinateur pour les modifier !
En effet, je pouvais faire ce que je voulais à l'appareil en utilisant ces commandes, tant que cela n'impliquait pas d'effacer du code en cours d'utilisation. Le ME2 a rejoint ma collection d'appareils affichant l'emblème de Miuchiz Reborn à des endroits où il ne devrait pas être, y compris le microscope numérique qui a pris la photo du die.
J'avoue, la première fois que j'ai essayé de lire/écrire la flash, j'étais un peu imprudent, car je ne pouvais pas voir tout le code qui s'exécutait. Par exemple, du code appelle la ROM interne du microcontrôleur, ou des routines RAM copiées là par la ROM. Certaines de mes suppositions pour les autres fonctions étaient éclairées par la façon dont les registres d'accès direct mémoire (DMA) étaient configurés. Si le DMA est configuré pour copier depuis le tampon USB, par exemple, il utilise probablement ces données pour programmer la flash, pas pour lire la flash.
Ce code, par exemple, appelle une fonction résidant en dehors de la flash, afin de ne pas retirer du code de dessous lui-même, avant de revenir au code qu'il vient de retirer de dessous lui-même de toute façon. Il faut être très prudent pour ne pas bricker l'appareil.
La région mémoire en question est clairement disposée par la fiche technique :
Il y a 128 kilowords de ROM particulièrement "embadded" à laquelle je n'avais pas encore accès, ce qui m'empêchait de comprendre complètement le système.
Heureusement, la fonction pour la commande de lecture flash personnalisée n'effectue pas de vérification des limites. Cela signifie qu'avec un message spécialement conçu qui tente une lecture à partir d'une adresse flash très élevée, on peut contourner tout l'espace d'adressage du microcontrôleur, pour revenir au début. Parce que cela équivaut à une capacité de lecture arbitraire, je n'avais pas besoin d'écrire de code de dump sur l'appareil cette fois-ci ! Toute la mémoire est lisible avec ce bug, je l'ai donc utilisé pour lire la ROM Embadded, que j'ai sauvegardée pour une rétro-ingénierie ultérieure.
Avec toute la mémoire, j'ai pu repérer le framebuffer de l'appareil dans la RAM, affichant l'image qui était sur l'écran de l'appareil à ce moment-là :
J'ai également pu lire les registres d'entrée/sortie à usage général (GPIO) de l'espace d'adressage de l'appareil en me référant à l'endroit où la fiche technique disait qu'ils devaient se trouver. En déclenchant le bug des dizaines de fois par seconde, je pouvais effectivement interroger les pressions de boutons et le transformer en contrôleur USB si je le souhaitais : (Vidéo)
À un moment donné pendant mes tests, j'ai remarqué une modification étrange d'une valeur dans la flash qui ne semblait même pas être censée être des données de sauvegarde.
0x00AA (rappelez-vous, la taille de mot de ce système est de 16 bits) a été écrit à un endroit de la flash que je n'avais pas demandé. Avec la ROM Embadded, nous pouvons enfin voir le code qui explique cela.
Processeur : Hé flash ! Je veux commencer à programmer un autre mot !
Flash : Reçu cinq sur cinq ! Programmation de 0xAA en 0x5555 !
Processeur : ...Hein ?
En raison des cycles de commande désynchronisés, la flash confond le premier cycle de la commande suivante avec le dernier cycle de la commande précédente, et 0xAA est programmé en 0x5555. L'adresse équivalente pour des octets typiques de 8 bits est 0xAAAA, ce qui correspond à l'endroit où 0x00AA a été écrit dans mon dump flash.
Cela pourrait potentiellement être utilisé pour une écriture arbitraire, tant que vous acceptez de corrompre ce mot spécifique dans la flash, mais l'appareil est déjà suffisamment « pwned » pour que je ne sois pas intéressé à briquer d'autres unités. Il serait peut-être possible de sauver ces appareils, car le reverse engineering de la ROM embarquée a également montré qu'elle contient son propre gestionnaire USB et des implémentations de lecture/programmation/effacement flash. Cependant, je n'ai réussi à faire entrer la ROM dans cet état (au lieu de démarrer dans le code flash) qu'une seule fois, et jamais plus. D'après la décompilation de la ROM, je soupçonne qu'elle pourrait dépendre d'un port GPIO qui est laissé flottant, mais je n'en suis pas sûr. Quoi qu'il en soit, ma mission ici était déjà accomplie.
Le résultat final de cette malice est un utilitaire en ligne de commande qui peut :
Ceci, avec le code du serveur de jeu et d'autres recherches, est disponible dans le dépôt ME2-Restoration. Puisque les détails d'implémentation y sont disponibles et ne sont probablement pas intéressants pour le lecteur typique, les détails techniques spécifiques ont été omis ici en faveur d'une description des processus et techniques.
Plus important encore, cela démontre que le logiciel PC original n'est pas strictement nécessaire pour comprendre ou préserver sa fonctionnalité. Même avec le logiciel officiel perdu dans le temps, il a été possible d'ouvrir la boîte noire qu'était le ME2 et de reconstruire son protocole à partir de son matériel et de son firmware, restaurant une interface autrement morte en quelque chose de réutilisable. Cela ne se limite pas aux interfaces comme USB, non plus. Découvrez comment j'ai recréé un serveur de licence mort depuis longtemps pour redonner vie à un éditeur vectoriel vieux de dix ans.
C'est aussi la première fois que je décapsule un circuit intégré, donc pour lui rendre le respect qu'il mérite, j'ai acheté un meilleur microscope et j'ai depuis contribué la photo de la plus haute qualité du GPL162002A/B à siliconprawn, prévisualisée ici à une résolution réduite pour être compatible avec le web :
