👨🏿‍✈️ 🏴‍☠️ 🌻 Protection et piratage de la Xbox 360 (partie 3) 🌪️ 🎄 🧒🏻

En 2011, 6 ans après la sortie de la console de jeu Xbox 360, les chercheurs ont découvert un fait intéressant - si le signal «0» est envoyé à la sortie RESET du processeur central pendant très peu de temps, le processeur ne réinitialisera pas son état (comme il se doit), mais à la place changez votre comportement! Sur la base de cette «fonctionnalité», Reset Glitch Hack (RGH) a été développé , avec l'aide duquel il a été possible de compromettre complètement la protection de la Xbox 360, d'exécuter du code non signé, ouvrant ainsi la voie au piratage du système lui-même et à la défaite des lecteurs DG-16D5S «incassables» .

Examinons de plus près comment RGH a fonctionné, comment les développeurs ont essayé de corriger un trou et comment ces correctifs ont pu se déplacer!

Qu'est-ce qu'une attaque glitch?

Le processeur est assez stupide, quoi qu'en disent les spécialistes du marketing. Tout le code de haut niveau écrit par les programmeurs est réduit à l'exécution de commandes simples - arithmétique avec des nombres, déplacement de données, sauts conditionnels et inconditionnels. Il est supposé que le processeur exécute toujours ces commandes sans erreur et que le résultat correspond à la documentation.

En effet, la compilation du code

i = i + 2;

vous comptez sur le fait que la valeur de la variable i augmentera exactement de 2, sans même savoir comment cela pourrait être autrement.

Les attaques Glitch violent cette confiance - leur objectif est de s'assurer que le processeur est «buggé» et se comporte mal. Il y a plusieurs façons de "bégayer" le processeur, par exemple:

Réduisez la tension du processeur
Pour donner une impulsion supplémentaire à la fréquence de référence du CPU
"Briller" sur le pourcentage de rayonnement

Il existe des dispositifs spéciaux pour effectuer de telles attaques - par exemple, ChipWhisperer offre une large gamme d'attaques en fréquence et en puissance:

Dans le cas de la Xbox 360, un «pépin» se produit à la suite de l'exposition à la ligne RESET. Le processeur commence la procédure de réinitialisation, mais en raison de la très courte durée du signal, il n'a pas le temps de le terminer et continue de fonctionner comme si de rien n'était. Mais juste pour ce bref instant, alors que le signal RESET est actif, son comportement change!

Processeur Glitch

La protection de la Xbox 360 repose sur des chargeurs de démarrage se vérifiant les uns les autres dans une chaîne. En fin de compte, la vérification à chaque étape revient à appeler la fonction de comparaison de la somme de hachage avec le «modèle». C'est alors qu'ils ont appliqué l'attaque glitch, forçant le processeur à ignorer le décalage. Une impulsion vers la ligne RESET immédiatement après avoir appelé la procédure memcmp force le processeur à "parcourir" une autre branche et à continuer le chargement, même si la somme de hachage est incorrecte:

Le meilleur endroit pour attaquer a été trouvé dans le chargeur de démarrage de la deuxième étape, "CB". Les étapes ultérieures sont plus difficiles à attaquer (et faciles à corriger), mais à la première étape du chargement ("1BL", ROM), l'attaque a échoué en raison d'une construction légèrement différente du code du programme.

Cela semble simple, mais en fait, lors de la tentative d'attaque, de nombreuses nuances ont été découvertes.

Premièrement, afin de mener avec succès une attaque par pépin, il est nécessaire de déterminer très précisément le moment où une impulsion RESET doit être appliquée. Si vous faites une erreur au moins pendant une microseconde, envoyez une impulsion trop courte ou trop longue, l'attaque ne fonctionne pas.

Heureusement, sur Xbox 360, chaque étape de démarrage s'accompagne d'un changement de valeur sur le bus de débogage POST_OUT. De plus, la sortie de débogage est si souvent arrangée qu'une nouvelle valeur POST est définie immédiatement avant de comparer la somme de hachage:

Ainsi, fermer l'emplacement de la sortie de débogage du site d'attaque était un déclencheur extrêmement pratique. POST_OUT est un bus parallèle et est émis vers 8 sites de test sur la carte de circuit imprimé, chacun étant responsable d'un des bits de la valeur. Il a même été possible de simplifier le schéma de connexion en utilisant un seul bit et en comptant le nombre de changements dans son état depuis le démarrage du système:

Il s'est également avéré qu'en raison de la fréquence élevée du processeur, il est presque impossible d'arriver au bon moment en termes de précision et de durée. Le temps d'exposition doit être très court, de l'ordre du temps d'exécution d'une instruction par le processeur. Mais plus le processeur tourne lentement, plus l'intervalle de temps nous convient. Par conséquent, nous prenons et ralentissons le processeur!

Sur un PC ordinaire, la fréquence du CPU est définie comme le produit de la fréquence et du multiplicateur externe de référence:

Ainsi, dans la Xbox 360, les lignes externes de la fréquence de référence conviennent au processeur, et à l'intérieur de cette fréquence est multipliée par PLL . Et sur les anciennes révisions «épaisses» du décodeur, le mécanisme PLL pouvait être désactivé, ce qui ralentissait le processeur jusqu'à 128 fois:

Sur les versions «Slim», l'astuce PLL est impossible (la ligne n'est pas séparée sur la carte), et comme nous ne pouvons pas influencer le multiplicateur «Slim», nous allons réduire la fréquence «référence»!

Il est généré par la puce HANA et peut être configuré via le bus I2C:

Malheureusement, il n'a pas été possible de réduire beaucoup, «à basse vitesse», la fréquence finale du processeur a commencé à «nager» fortement, ce qui a réduit les chances de succès. L'option la plus stable a été un ralentissement de 3,17 fois. Pas 128 fois, mais au moins quelque chose.

Tout? Non, pas tous. C'est loin d'être un fait que l'attaque fonctionnera du premier coup (surtout sur Slim). Et si le démarrage échoue, le préfixe redémarre et essaie de redémarrer. Seulement 5 tentatives sont données pour démarrer, après quoi le préfixe s'arrête et commence à clignoter «l'anneau rouge de la mort». Par conséquent, nous corrigeons également le micrologiciel du pont sud (SMC) afin qu'il ne souffre pas d'ordures et redémarre le préfixe jusqu'à ce qu'il devienne bleu:

Donc, nous obtenons l'algorithme:

patch SMC
pour cent de ralentissement (via PLL ou I2C)
en attente d'un déclencheur POST
en attente de N microsecondes
envoyer une impulsion à RESET
accélérer pour cent en arrière

Pour une plus grande précision des calculs, nous prenons la fréquence du même HANA (48 MHz):

Et nous obtenons une telle conception basée sur le CPLD Xilinx XC2C64A peu coûteux:

N'oubliez pas de chamaniser avec la longueur et l'emplacement du câblage sur le RESET (faites attention à la "bobine" en bas de la photo) et en avant, j'espère que le lancement se fera en une minute.

Mais ce n'est que du côté matériel. Comment patcher le chargeur de démarrage et remplir notre code?

Chargeurs de patchs

Comme je l'ai mentionné, le chargeur de démarrage de deuxième niveau, «CB», est attaqué. Ce chargeur de démarrage est chiffré avec une clé fixe, la même pour toutes les consoles, mais juste «CB» ne peut pas être modifié, nous l'attaquons seulement. Mais le suivant est déjà chiffré avec une clé CPU, unique pour chaque décodeur. Et pour la modifier, il faut connaître cette clé ...
Ou pas?

Dans les anciennes révisions «épaisses» de la Xbox 360, le mode dit «Zero-Pairing», qui était utilisé au stade de la production du décodeur, était pris en charge dans le chargeur de démarrage «CB». L'en-tête de chaque chargeur de démarrage à l'offset 0x10 contient un ensemble de données de couplage aléatoire qui est utilisé dans le cadre de la clé de déchiffrement. Et si cet ensemble de données était entièrement composé de zéros («Zero-Pairing»), la clé du processeur a été ignorée et une clé zéro fixe a été utilisée à la place!

Avec cette astuce, il a été possible d'assembler une image avec le "CB" d'origine, de crypter le chargeur de démarrage suivant, "CD" (avec son propre code) avec une clé zéro et de l'exécuter en utilisant RGH!

Dans les consoles, «Slim» a encapsulé cette astuce, supprimant le mode «Zero-Pairing» et divisant le «CB» en deux parties. Ici, "CB" était divisé en un "CB_A" très simple et petit et chiffré par la clé de processeur "CB_B":

Mais le chiffrement avec l'algorithme RC4 (à savoir, CB_B est chiffré avec cet algorithme) a une particularité. Dans le processus de cryptage basé sur la clé, un flux de données pseudo-aléatoire est généré, qui est «additionné» binaire (opération «exclusif ou», «xor») avec les données source. Lors du décryptage, en conséquence, la même chose se produit, l'ajout avec le même flux pseudo-aléatoire ramène les données à leur valeur d'origine:

Mais l'opération d'addition binaire est commutative et associative, ce qui signifie que nous pouvons modifier les données cryptées sans connaître la clé, juste pour xor 'et le code crypté avec le patch dont nous avons besoin!

En conséquence, nous pouvons chiffrer "CB_A", patcher le "CB_B" chiffré (afin qu'il n'effectue pas du tout le déchiffrement) et mettre en clair "CD" avec son code!

En bref, si vous l'assemblez, le lancement ressemble à ceci:
(XeLL est le chargeur de démarrage de homebrew, Linux, et il affiche également les clés du processeur)

Microsoft riposte

Bien sûr, Microsoft a essayé de tout rafistoler.

Dans la nouvelle mise à jour du système, toutes les anciennes consoles ont été transférées vers un démarrage «séparé» de «CB_A» et «CB_B», fermant ainsi définitivement le mode «Zero-Paired». Sur Slim, les chargeurs de démarrage ont également été mis à jour. Les nouveaux bootloaders ont été sérieusement modifiés pour se protéger contre RGH, avec le plus grand accent mis sur la protection de CB_A:

Sortie de débogage complètement supprimée dans POST
La vérification du hachage a été refaite et dupliquée pour plus de fiabilité
Tout au long du code, sleep () a été défini pour une durée aléatoire (en fonction de la clé CPU !!)
Ajout de la vérification de fusion CBLDV pour révoquer CB_A

La liste des innovations ne laisse aucune chance à RGH. Mais attention au dernier élément de la liste - avant cela, il n'y avait pas de contrôle de fusion dans CB_A! Erreur fatale. De plus, comme nous le rappelons, la clé processeur n'est pas impliquée dans le décodage "CB_A". Cela signifie que le chargeur CB_A vulnérable à RGH peut être lancé sur n'importe quelle console, et cela ne peut pas être interdit.

Mais pour commencer quelque chose avec l'aide de ce "CB_A" vulnérable, vous devez esquiver un peu. Si nous ne connaissons pas la clé CPU, il ne nous reste plus qu'à patcher le «CB_B» existant. Mais que se passe-t-il si, au lieu de modifier des sections individuelles, nous remplaçons complètement le chargeur de démarrage entier? Et pour cette raison, "écrire" l'ancien chargeur de démarrage, que nous savons déjà patcher, pour remplacer le nouveau? Ils ont donc fait:

Nous chiffrons le CB_A vulnérable de la même manière que dans l'image d'origine
XOR notre CB_B avec le nouveau, obtenant la «différence»
Nous l'avons mis sur le "CB_B" crypté!

Tout, encore une fois, sans connaître la clé, nous avons réussi à remplacer le contenu crypté et à mettre le chargeur de démarrage vulnérable. Les consoles piratent, Microsoft est surpris.

Les développeurs ont travaillé dur, et dans la prochaine mise à jour du système ... ont légèrement modifié la méthode de cryptage "CB_B", maintenant la clé de cryptage est également devenue dépendante de la version de "CB_A":

Maintenant, lors de la tentative de xor 'et de transfert des données vers le "CB_A" vulnérable de l'ancienne version, le chargeur a déchiffré les ordures en raison de différences de clés. Et le nouveau chargeur de démarrage ne peut pas être piraté, il est bien protégé contre les attaques glich. Jusqu'à présent, victoire pour Microsoft!

Corona pose des problèmes

Pendant ce temps, une nouvelle révision de la Xbox 360, Corona, est entrée sur le marché, et elle a posé des problèmes aux moddeurs:

Pas assez de jetons sur la carte, pouvez-vous le trouver? C'est vrai, la puce HANA était "cachée" dans le pont sud. Il n'y a nulle part ailleurs pour prendre la fréquence de 48 MHz pour la puce mod, les précédentes commandes de ralentissement I2C ne fonctionnent pas. Qu'est-ce que c'est, le flash NAND de 16 Mo, qui a servi de stockage système Xbox 360 toutes ces années, a été perfidement remplacé par une puce de 4 Go avec une interface eMMC! (Vrai, seulement dans la version moins chère de la console, mais quand même):

Mais rien, tout a été réglé. Nous avons compris comment lire / écrire la mémoire flash via un lecteur de carte:

Trouvé de nouvelles commandes de ralentissement I2C, un oscillateur à cristal externe de 48 MHz a remplacé HANA:

Scripts de construction terminés, prise en charge supplémentaire de 4 Go de NAND ...

Mais Microsoft a continué de mettre des bâtons dans les roues. Par exemple, sur les nouvelles cartes, certaines résistances ont disparu, sans lesquelles la puce de mod a cessé de fonctionner:

Certes, cela a été résolu en installant des cavaliers avec un fer à souder:

Les choses sont devenues plus sérieuses lorsque les pistes POST_OUT ont disparu du plateau:

Mais ici, Microsoft n'a pas eu de chance, les «boules» de CPU nécessaires pour RGH étaient à l'extrême:

Et, bien sûr, ils ont pu se connecter avec eux. Tout d'abord, les plus douces, forant légèrement le bord du processeur et soudant directement à la balle avec le câblage:

Et puis les Chinois ont sorti un cadre avec une aiguille à ressort, reposant exactement sur la balle, et le problème a été résolu pour tout le monde:

La dernière frontière

Après avoir vaincu la «couronne», il y a eu un problème - les nouvelles versions du système n'ont pas cédé au piratage. Pour démarrer RGH, vous devez connaître la clé CPU et pour connaître la clé CPU, vous devez exécuter RGH au moins une fois. Le problème du poulet et des œufs en général.

Et puis une pensée a surgi - et vérifions non seulement l'authentification «glitch», mais nous allons également sauter le décryptage! Si cela fonctionne, alors nous n'avons pas besoin de connaître la clé, mettez "CB_B" en clair, c'est tout. Cette idée a formé la base de Double Glitch Hack (DGX):

Cette puce a «bogué» deux fois le pourcentage, la première impulsion a sauté la phase de décryptage du chargeur de démarrage et la deuxième impulsion a sauté l'authentification. Cela a fonctionné beaucoup moins stable, car au moins un lancement réussi a été nécessaire - nous obtenons ensuite la clé CPU et procédons comme auparavant.

DGX n'a pas été pertinent pendant longtemps, après 3 mois, les Chinois ont lancé la sortie de "DGX RIP" avec des images qui s'exécutent sur n'importe quel décodeur, fonctionnaient avec RGH standard et, bien sûr, ont commencé beaucoup plus stable:

Ces images contenaient une version spéciale du chargeur de démarrage CB_A utilisé dans la production Xbox 360 et, en fait, est un analogue complet du bon vieux mode «Zero-Pairing». Au lieu de la clé du processeur, ce "CB_A_mfg" a déchiffré "CB_B" avec une clé nulle fixe:

Et voici Microsoft. Dans cette version «service» de «CB_A», il n'y avait pas non plus de contrôle de fusion et il était impossible de l'interdire. Il suffisait d'enregistrer l'image selon la révision de la Xbox 360, de souder la puce - et tout fonctionnait.

Winchester!

RGH a été entièrement corrigé uniquement dans la nouvelle révision de la console, appelée Winchester. Pour la première fois, processeurs CPU et GPU réunis en une seule puce, la carte a été simplifiée au maximum:

Les pistes POST_OUT n'ont pas seulement été supprimées. Même si vous soudez à la plate-forme sous le processeur:

Et même si vous soudez le processeur à une version spéciale de la carte pour les développeurs, XDK, où ces pistes sont toujours là:

Sur POST_OUT, une seule impulsion est visible au démarrage de la console. Bus verrouillé:

De plus, il n'est bloqué qu'au stade de la production. Si vous prenez un processeur «propre» dans une usine où vous n'avez pas encore brûlé de fusibles, POST_OUT fonctionne dessus!

Mais RGH dessus ne fonctionne plus. Peu importe comment vous essayez de donner une impulsion de réinitialisation, le processeur effectue correctement une réinitialisation ou ignore votre signal en raison de sa durée trop courte. Apparemment, un module logique spécial a été ajouté au processeur, filtrant la ligne RESET et a finalement corrigé l'erreur matérielle.

Post Scriptum

Il s'avère que la dernière révision de la Xbox 360 est impossible à pirater?

Oui et non. Pour le moment, il n'y a qu'une seule façon connue d'exécuter un système modifié sur les révisions de Winchester.

Le kit de développement logiciel (XDK) contient diverses clés privées pour signer le code compilé. Et il s'est avéré que parmi eux, la clé de signature «shadowboot», un chargeur de démarrage de troisième niveau pour les systèmes XDK, était encombrée. Et avec lui, vous pouvez collecter une image signée légitime avec un firmware modifié. Il suffit de travailler sur des consoles ordinaires "en magasin", il ne le fera pas. Nous avons besoin d'un processeur avec la version XDK de la console, ou d'un CPU «propre» avec des fusibles non fusionnés (vous pouvez le voir sur Aliexpress):

Et alors seulement vous aurez l'occasion d'envisager une telle inscription dans les "informations système" du shell personnalisé:

Et c'est tout! Comme d'habitude, je suis prêt à répondre à vos questions dans les commentaires :)

Protection et piratage
Xbox 360 , partie 1 Protection et piratage Xbox 360 , partie 2
Protection et piratage Xbox 360, partie 3

Protection et piratage de la Xbox 360 (partie 3)