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 responsable 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 tout 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 plate forme.

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 coeur 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 coeurs compatible SMT 2 voies capable de virtualiser 6 processeurs. Le procédé de fabrication du Xenon a été améliorer 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 (Xenon Falcon), puis à 45nm en 2010 (Xenon 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étro-compatibilité.

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 à plusieurs tâches a 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 a la différence que le kernel est signé. Plus précisément, il charge les données de l'OS présentes sur le disque dur interne de la console puis les hash à l'aide du SHA (Secure Hash Algorithm) en les comparant à des hash obtenu grâce à l'hyperviseur de cryptage contenu dans la ROM du processeur. Microsoft© à mit en place cette protection dans le but de rendre la console incompatible avec toutes autres OS que celles éditées par eux même. Il est ainsi en théorie impossible de lancer autre chose qu'une 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 SAH, 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)

La XBOX 360 est sorti il y a maintenant 9 ans, Microsoft au fil des années a amélioré et changer plusieurs fois les nombreuses protections et mécanisme de vérification dans le but de contrer tous les hacks sortis sur la 360, mais le reset glitch hack, un hack dévoilé en aout 2011 par le français “GliGli” sur le site Logic-sunrise ne peu de par sa conception même etre contré et donne beaucoup de fil à retordre pour Microsoft. Le RGH a été créé dans un premier temps pour lancer des application créées avec la bibliothèque libre “libXenon” qui s’execute grace à un os ultra simplifié sur une UNIX, on parle donc ici de “homebrew”, des logiciels non certifié par microsoft, mais dans aucun cas de piratage. C’est d’ailleurs pour cette raison que le hack ne s’est pas beaucoup répandu les premiers temps, puis une autre équipe de hacker à réussi à rendre compatible l’OS de la console modifié avec ce hack, depuis il est devenu extrêmement populaire.

1) Principe du reset glitch hack (méthode d’impulsion):

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)