Projets étudiants cryptographie et sécurité/BodinDeWinter XBOX RGH

I. Introduction

Présentation du "Reset Glitch Hack" Xbox 360 permettant l'exécution de code non signé par Microsoft

De document est destiné à un usage éducatif uniquement. Nous ne sommes pas responsables de l'utilisation frauduleuse des informations présentes dans ce document.

La Xbox 360™ est une console de salon développée par Microsoft© et commercialisée entre 2005 et 2006 partout dans le monde. Depuis son lancement, la console a été écoulée a plus de 83 millions d'exemplaires faisant de cette console la sixième plus vendue de tous les temps.

Tout comme un ordinateur classique, la Xbox 360™ est assemblée sur une carte mère avec les composants classiques : un CPU (Central Processing Unit), une GPU (Graphics Processing Unit), de la RAM GDDR3, un décodeur audio XMA, … La console de Microsoft© a été optimisée afin de faire fonctionner des applications graphiques exigeantes, or encore aujourd'hui, près de 10ans après sa sortie, des jeux au graphismes étonnant sont encore développés sur cette plateforme.

Processeur : Xenon triple-coeurs RAM : 512MB (2005) Disque dur : 20, 60, 120, 250, ou 320 GB Processeur graphique : ATI Xenos 512MB

II. Présentation du CPU

1) Caractéristiques techniques

Le processeur Microsoft XCPU ou Xenon est le cœur du système. Crée par IBM© et Microsoft© à partir de la série POWER (Performance Optimization With Enhanced RISC), le Xenon est composé de 3 cœurs compatible SMT 2 voies capable de virtualiser 6 processeurs. Le procédé de fabrication du Xenon a été amélioré durant la période de commercialisation de Xbox 360™ afin de résoudre les problèmes de température de la console. Le processeur est passé d'une finesse de gravure de 90nm en 2005, à 60nm en 2007 (Falcon), puis à 45nm en 2010 (Trinity).

Le Xenon est munis de 128 bits de eFUSE, des "fusibles électronique" crées par IBM qui permettent de vérifier la version du Kernel : à chaque modification / mise à jour du Kernel, un eFUSE est détruit empêchant toute rétrocompatibilité.

Nom : Xenon Nombre de transistors : 165 millions Nombre de coeurs : 3 Vitesse d'horloge : 3,2 GHz Mémoire intégrée : ROM et 64Kb de SRAM contenant le Secure Bootloader de la console et l'hyperviseur de cryptage qui génère

2) Processus de lancement le l'OS : Secure Boot-loader

a) Qu'est-ce qu'un Boot-loader ?

Un Boot-loader est un programme écrit qui, au démarrage d'une machine, permet de charger un système d’exploitation plus complexe. Il a plusieurs tâches à accomplir :

• Intégrer le système d'exploitation dans la mémoire,
• Donner à celui-ci les informations dont il a besoin pour fonctionner correctement,
• Changer l’environnement pour quelque chose de convenable au système,
• Enfin il transfert le contrôle au système d’exploitation.

b) Le Secure Boot-loader de la Xbox 360

Le Secure Boot-loader de la Xbox 360™ fonctionne comme un boot-loader classique à la différence que le kernel est signé. Plus précisément, il charge les données de l'OS présentes sur la mémoire interne de la console (la nand) puis les hash à l'aide du SHA (Secure Hash Algorithm) en les comparants à des hash obtenu grâce à l'hyperviseur de cryptage contenu dans la ROM du processeur. Microsoft© a mis en place cette protection dans le but de rendre la console incompatible avec toutes autres OS que ceux déployé par eux même. Il est ainsi en théorie impossible de lancer autre chose qu'un OS signée par Microsoft©.

c) Processus de lancement supposé du kernel

Les informations concernant la méthode de génération du hash à partir de l'hyperviseur de cryptage sont un peu floues car Microsoft© n'as pas souhaité dévoiler le processus exact de fonctionnement de son Secure Boot-loader.

• 1. Lancement de la console,
• 2. Le processeur exécute les premières instructions présentes dans sa ROM : le Secure Boot-loader,
• 3. Copie des données de l'OS dans la RAM,
• 4. Hashage des données de l'OS à l'aide du SHA,
• 5. Génération d'un hash à l'aide de l'hyperviseur de cryptage de la ROM,
• 6. Comparaison des deux hash obtenu à l'aide de memcmp :

→ Si les deux hash correspondent, alors le boot peut se poursuivre : On transfert le contrôle du système au kernel.

→ Si les deux hash sont différents, alors le boot est arrêter et la procédure de lancement plante.

Problématique : Comment contrer cette protection et parvenir à lancer un OS quelconque depuis une Xbox 360 ?

III. Présentation du Reset Glitch Hack (RGH)

On a vu précédemment que le bootloader joue un rôle essentiel pour le démarrage de la console et permet à lui seul de charger l'OS, si on parvient à passer la sécurité du bootloader on est en théorie maître de notre console et on peut lancer n'importe quel code dessus.

En août 2011 un français dont le pseudo est "GliGli" a dévoilé un bug permettant de contourner la protection mise en place par Microsoft©.

1) Principe du reset glitch hack :

Texte original écrit par GliGli :

"We found that by sending a tiny reset pulse to the processor while it is slowed down does not reset it but instead changes the way the code runs, it seems it's very efficient at making bootloaders memcmp functions always return "no differences". memcmp is often used to check the next bootloader SHA hash against a stored one, allowing it to run if they are the same. So we can put a bootloader that would fail hash check in NAND, glitch the previous one and that bootloader will run, allowing almost any code to run."

Traduction en français :

"Nous avons découvert qu'en envoyant de petites impulsions de reset au processeur pendant qu'il était ralenti ne le remettait pas à zéro, mais changeait plutôt la manière dont le code tournait. Il semble que ceci soit très efficace pour que les fonctions comparatrices de mémoires des bootloaders renvoient toujours l'information "pas de différence". Les fonctions comparatrices de mémoires sont utilisées entre-autres pour comparer le hash SHA du bootloader suivant avec celui stocké, et permettant s'ils sont identiques de le lancer. Nous pouvons ainsi mettre un bootloader qui ne passera pas la vérification de hash dans la NAND, glitcher le précédent et ce bootloader se lancera permettant le lancement de presque tout code." Donc le principe du RGH est très simple, il est de faire buguer (glitcher) le processus de boot de la console, pour qu’il fasse croire que le bootloader injecté auparavant dans la nand soit un officiel.

(référence http://free60.org/Reset_Glitch_Hack)

Le principe du Reset Glitch Hack est assez simple : il permet, plutôt que d'avoir à connaître le procédé de fonctionnement du superviseur de cryptage, de passer outre celui-ci en rendant la fonction qui vérifie si les données sont bien signées obsolète.

Pour faire simple, nous avons besoin de :

• a) Ralentir le CPU
• b) Envoyer le signal RESET au processeur durant un temps précis pendant la comparaison des données.
• c) Vérifier l'état du boot (pour vérifier si le hack a fonctionné)

2) Détails du hack

a) Ralentir le CPU

Un internaute un nom de "Cjak" à découvert qu'en activant le signal CPU_PLL_BYPASS de la carte mère, l'horloge du CPU ralentissait énormément, il y a un point de test sur la carte mère qui permet de connaître la vitesse du CPU, il est à 200Mhz lorsque l'os de la Xbox 360™ est lancé, 66.6Mhz lorsque la console démarre et 520kHz lorsque le signal est activé.

b) Envoyer le signal RESET au processeur

Il faut se connecter au signal CPU_RESET de la carte mère pour envoyer ce signal. Celui-ci fait "glitcher" le processus de comparaison du boot.

c) Vérifier l'état du processeur

Pour vérifier l'état du processeur il faut pouvoir accéder au signal POST_OUT de la carte mère.

En résumé :

Point : Effet :

CPU_PLL_BYPASS Ralentit le CPU à 520kHz

CPU_RESET Envoie le signal de reset au processeur, à basse fréquence celui-ci se comporte différemment et les fonctions memcmp retournent toujours l'information pas de différences

POST_OUT Contrôle l'état du processeur

Procédure exacte pour les Xbox 360™ Fat :

• 1. Activation du CPU_PLL_BYPASS pour baisser la fréquence du CPU.
• 2. Attendre que le comparateur de mémoire s'exécute jusqu’à 62% de la longueur totale.
• 3. Envoyer une pulsation de 100ns sur le CPU_RESET.
• 4. Attendre un certain timing puis désactiver le CPU_PLL_BYPASS.
• 5. La vitesse du CPU redevient normal, et avec un peu de chance, à la place d'obtenir une erreur, le processus de boot se poursuit, et lance le code modifié.
• 6. Si le processus de boot ne se poursuit pas, on recommence la procédure.

IV. Le hack au fil du temps

Il y a eu énormément de révision de la carte mère de la Xbox 360™ depuis sa sortie, ce qui fait que le hack n'est pas tout à fait le même suivant ces révisions.

1) Xbox 360™ fat

La première version du hack sur les Xbox 360™ fat a été décrit dans le détail le chapitre précédent.

2) Xbox 360™ slim

Les slim sorties après les fat, ne proposent plus le point de signal CPU_PLL_BYPASS, donc le hack des slim est un peu différent :

Les hackers ont découvert que sur la puce HANA (HDMI scaler chip), la fréquence d'horloge peut être contrôlée par le registre programmable PLL, et ce registre peut être réécrit par un bus I²C. Ainsi la puce HANA devient leur arme de choix pour ralentir le CPU, mais cette fois ci c’est seulement à 100Mhz.

Par rapport au hack des fat, la seule chose qui change, est ce qu’on utilise pour ralentir le CPU, Pour les fat c’est un signal CPU_PLL_BYPASS de CPU, et pour les slim c’est la puce HANA, par contre avec la puce HANA, nous ne pouvons pas baisser la fréquence jusqu’à 520Khz (mais 100Mhz), donc pour les slim, le taux de réussite est généralement plus bas que chez les fat.

La procédure exacte pour les Xbox 360™ Slim :

• 1. Envoyer une commande I²C vers l'HANA afin de ralentir le CPU.
• 2. Attendre que le comparateur de mémoire s'exécute.
• 3. Envoyer une pulsation de 20ns sur le CPU_RESET.
• 4. Attendre un moment et ensuite envoyer une commande i2c en direction de l'HANA afin que l'horloge du CPU revienne à son état normal.
• 5. La vitesse du CPU redevient normal, et avec un peu de chance, à la place d'obtenir une erreur, le processus de boot se poursuit et et lance le code modifié.
• 6. Si le processus de boot ne se poursuit pas, on recommence.

3) Xbox 360™ corona

Une version plus récente de la génération des slim n’a plus la puce HANA, l'horloge est maintenant intégrée directement dans le southbridge. Un contre de Microsoft© qui s’est avéré être un échec, puisque un quartz en bonne qualité sur le circuit qui envoie les impulsions suffit pour remplacer le HANA.

Depuis plusieurs amélioration du hack ont été effectuées, déjà le quartz permet un hack plus fiable, la dimension des câbles utilisé aussi a une importance, mais aussi les interférences qui pourrait être causé par les bobines ou la cage de faraday de la console.

Pour effectuer ce hack nous avons besoin d’un circuit logique programmable qui permet de générer des impulsions, on va l'appeler générateur d'impulsions pour le moment.

Normalement sur un générateur d'impulsions à 5 points de signal, mais maintenant ils en ont plus que 4 avec le remplacement par le quartz du point “STBY_48M” qui était connecté à la puce HANA (qui depuis à même été retiré par Microsoft©, mais sans effet).

Il y a donc le :

• Point CPU_reset : Il envoi le signal CPU_reset sur l’un des pins du processeur pour faire s’effondrer le mécanisme de vérification du BOOTLOADER, ainsi on peut charger le bootloader officieux.
• Point POST_OUT1 : Ce point surveille le statut du système, il va donc faire stopper les envois de CPU_reset en cas de succès.
• Points bus I²C (2 points) : Envoie le signal pour baisser la fréquence de CPU.
• Il faut aussi alimenter la puce, on utilise du 3.3v fourni par la console pour ça.

Le CPU_reset a tout simplement changé de place avec les dernières révisions des cartes mères, pas très efficace encore une fois. Puis Microsoft a carrément retirer la piste qui reliait le POST_OUT au processeur, il était donc impossible de connaître si le boot était un succes ou pas, mais un outil qui enfonce une aiguille sous le processeur pour atteindre directement le pin du processeur POST_OUT est sorti pour résoudre ce problème.

4) Xbox 360™ Winchester

La version plus récente de la Xbox 360™ à été modifiée. En effet, Microsoft© à modifier la taille du CPU rendant l'outil permettant d'accéder au POST_OUT incompatible, de plus la NAND est différente et illisible par les méthodes actuelles. Les hackers sont au travail.

V. Xellous

Le xellous souvent appelé « xell », est un petit OS (environ 1mo) basé sur linux qui permet de récupéré les clés de cryptage de la nand et du lecteur de la console, mais surtout pour exécuter des applications compilé avec la librairie « libxenon ».

VI. Conclusion

Le RGH a été créé dans un premier temps pour lancer des applications créées avec la bibliothèque libre “libXenon” qui s’exécute grâce à un os ultra simplifié sur la base UNIX, on parle donc ici de “homebrew”, des logiciels non certifié par Microsoft©, mais en aucun cas de piratage. C’est d’ailleurs pour cette raison que le hack ne s’est pas beaucoup répandu à ses débuts. Par la suite une autre équipe de hackers a réussi à rendre compatible l’OS de la console modifiée avec ce hack, depuis il est devenu extrêmement populaire car il permet de lancer des jeux non-officiels.

Microsoft© a déjà essayé d’améliorer la protection du mécanisme de vérification de Xbox 360™, alors que le principe du hack n’a pas changé (et ne changera pas), car l’architecture du processeur ne peut être changée, Microsoft© fait à chaque fois des petits changements pour empêcher le hack actuel d’être fonctionnel, mais il existera toujours une solution pour le rendre de nouveau fonctionnel. Pourquoi Microsoft© ne corrige-t’il pas le bug de ce processeur?

Il faudrait modifier complètement l’architecture du processeur pour cela, outre le coût important de cette modification, il rendrait tous les jeux sorti jusqu’à ce jour obsolète, changerais complètement la console. Depuis la nouvelle Xbox est sorti, la Xbox One™ basé sur une architecture beaucoup plus classique, la x86. Il ne reste maintenant plus qu’au hacker à trouver une nouvelle faille dans cette nouvelle console.

Références : www.logic-sunrise.com free60.org