Wiki du LAMA (UMR 5127) - Contributions [fr]

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

2016-03-12T19:48:02Z

JorisBodin : /* IV. Le hack au fil du temps */

=== Auteurs : Joris BODIN et Tim DE WINTER ===

== I. Introduction ==
[[Fichier:1.png|thumb|Illustration d'une Xbox 360 elite (gauche) et d'une Xbox 360 S (droite).]]
''' 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.

{| class="wikitable alternance centre"
|-
! scope="row" | Processeur
| Xenon triple-coeurs
|-
! scope="row" | RAM
| 512MB
|-
! scope="row" | Disque dur
| 20, 60, 120, 250, ou 320 GB
|-
! scope="row" | Processeur graphique
| ATI Xenos 512MB
|-
|}

== II. Présentation du CPU ==

''' 1) Caractéristiques techniques '''

[[Fichier:xboxcpu.png|thumb|Illustration du processeur XCPU Xenon]]
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é.

{| class="wikitable alternance centre"
|-
! scope="row" | Nom
| Xenon
|-
! scope="row" | Nombre de transistors
| 165 millions
|-
! scope="row" | Nombre de coeurs
| 3
|-
! scope="row" | Vitesse d'horloge
| 3,2 GHz
|-
! scope="row" | 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'''

[[Fichier:xboxcpupllbypass.jpg|thumb|Emplacement du signal CPU_PLL_BYPASS sur la carte mère.]]

''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''

[[Fichier:xboxcpureset.jpg|thumb|Emplacement du signal CPU_RESET sur la carte mère.]]

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''

[[Fichier:xboxcpupostout.jpg|thumb|Emplacement du signal POST_OUT sur la carte mère.]]

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

{| class="wikitable alternance centre"
|+ En résumé
! scope="col" | Point
! scope="col" | 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.

'''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.

==IV. Le hack au fil du temps==

[[Fichier:xboxpluspostout.png|thumb|A droite la corona et à gauche la trinity (première slim), on voit bien que la connectivité au POST_OUT a été retirée.]]
[[Fichier:xboxpostfix.png|thumb|Outil permettant d'accéder au POST_OUT directement sur le processeur.]]
[[Fichier:xboxpostfixw.jpg|thumb|Nouveau processeur présent sur les nouvelles cartes mères depuis moins de 4 mois. Il est plus petit rendant le POSTFIX actuel obsolète.]]

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.

'''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==

[[Fichier:Xboxxell.png|thumb]]

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

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

2016-03-12T19:47:27Z

JorisBodin : /* V. Xellous */

=== Auteurs : Joris BODIN et Tim DE WINTER ===

== I. Introduction ==
[[Fichier:1.png|thumb|Illustration d'une Xbox 360 elite (gauche) et d'une Xbox 360 S (droite).]]
''' 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.

{| class="wikitable alternance centre"
|-
! scope="row" | Processeur
| Xenon triple-coeurs
|-
! scope="row" | RAM
| 512MB
|-
! scope="row" | Disque dur
| 20, 60, 120, 250, ou 320 GB
|-
! scope="row" | Processeur graphique
| ATI Xenos 512MB
|-
|}

== II. Présentation du CPU ==

''' 1) Caractéristiques techniques '''

[[Fichier:xboxcpu.png|thumb|Illustration du processeur XCPU Xenon]]
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é.

{| class="wikitable alternance centre"
|-
! scope="row" | Nom
| Xenon
|-
! scope="row" | Nombre de transistors
| 165 millions
|-
! scope="row" | Nombre de coeurs
| 3
|-
! scope="row" | Vitesse d'horloge
| 3,2 GHz
|-
! scope="row" | 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'''

[[Fichier:xboxcpupllbypass.jpg|thumb|Emplacement du signal CPU_PLL_BYPASS sur la carte mère.]]

''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''

[[Fichier:xboxcpureset.jpg|thumb|Emplacement du signal CPU_RESET sur la carte mère.]]

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''

[[Fichier:xboxcpupostout.jpg|thumb|Emplacement du signal POST_OUT sur la carte mère.]]

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

{| class="wikitable alternance centre"
|+ En résumé
! scope="col" | Point
! scope="col" | 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.

'''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.

==IV. Le hack au fil du temps==

[[Fichier:xboxpluspostout.png|thumb|A droite la corona et à gauche la trinity (première slim), on voit bien que la connectivité au POST_OUT a été retirée.]]
[[Fichier:xboxpostfix.png|thumb|Outil permettant d'accéder au POST_OUT directement sur le processeur.]]
[[Fichier:xboxpostfixw.jpg|thumb|Outil permettant d'accéder au POST_OUT directement sur le processeur.]]

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.

'''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==

[[Fichier:Xboxxell.png|thumb]]

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

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

2016-03-12T19:47:03Z

JorisBodin : /* IV. Le hack au fil du temps */

=== Auteurs : Joris BODIN et Tim DE WINTER ===

== I. Introduction ==
[[Fichier:1.png|thumb|Illustration d'une Xbox 360 elite (gauche) et d'une Xbox 360 S (droite).]]
''' 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.

{| class="wikitable alternance centre"
|-
! scope="row" | Processeur
| Xenon triple-coeurs
|-
! scope="row" | RAM
| 512MB
|-
! scope="row" | Disque dur
| 20, 60, 120, 250, ou 320 GB
|-
! scope="row" | Processeur graphique
| ATI Xenos 512MB
|-
|}

== II. Présentation du CPU ==

''' 1) Caractéristiques techniques '''

[[Fichier:xboxcpu.png|thumb|Illustration du processeur XCPU Xenon]]
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é.

{| class="wikitable alternance centre"
|-
! scope="row" | Nom
| Xenon
|-
! scope="row" | Nombre de transistors
| 165 millions
|-
! scope="row" | Nombre de coeurs
| 3
|-
! scope="row" | Vitesse d'horloge
| 3,2 GHz
|-
! scope="row" | 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'''

[[Fichier:xboxcpupllbypass.jpg|thumb|Emplacement du signal CPU_PLL_BYPASS sur la carte mère.]]

''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''

[[Fichier:xboxcpureset.jpg|thumb|Emplacement du signal CPU_RESET sur la carte mère.]]

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''

[[Fichier:xboxcpupostout.jpg|thumb|Emplacement du signal POST_OUT sur la carte mère.]]

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

{| class="wikitable alternance centre"
|+ En résumé
! scope="col" | Point
! scope="col" | 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.

'''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.

==IV. Le hack au fil du temps==

[[Fichier:xboxpluspostout.png|thumb|A droite la corona et à gauche la trinity (première slim), on voit bien que la connectivité au POST_OUT a été retirée.]]
[[Fichier:xboxpostfix.png|thumb|Outil permettant d'accéder au POST_OUT directement sur le processeur.]]
[[Fichier:xboxpostfixw.jpg|thumb|Outil permettant d'accéder au POST_OUT directement sur le processeur.]]

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.

'''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

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

2016-03-12T19:45:52Z

JorisBodin : /* IV. Le hack au fil du temps */

=== Auteurs : Joris BODIN et Tim DE WINTER ===

== I. Introduction ==
[[Fichier:1.png|thumb|Illustration d'une Xbox 360 elite (gauche) et d'une Xbox 360 S (droite).]]
''' 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.

{| class="wikitable alternance centre"
|-
! scope="row" | Processeur
| Xenon triple-coeurs
|-
! scope="row" | RAM
| 512MB
|-
! scope="row" | Disque dur
| 20, 60, 120, 250, ou 320 GB
|-
! scope="row" | Processeur graphique
| ATI Xenos 512MB
|-
|}

== II. Présentation du CPU ==

''' 1) Caractéristiques techniques '''

[[Fichier:xboxcpu.png|thumb|Illustration du processeur XCPU Xenon]]
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é.

{| class="wikitable alternance centre"
|-
! scope="row" | Nom
| Xenon
|-
! scope="row" | Nombre de transistors
| 165 millions
|-
! scope="row" | Nombre de coeurs
| 3
|-
! scope="row" | Vitesse d'horloge
| 3,2 GHz
|-
! scope="row" | 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'''

[[Fichier:xboxcpupllbypass.jpg|thumb|Emplacement du signal CPU_PLL_BYPASS sur la carte mère.]]

''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''

[[Fichier:xboxcpureset.jpg|thumb|Emplacement du signal CPU_RESET sur la carte mère.]]

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''

[[Fichier:xboxcpupostout.jpg|thumb|Emplacement du signal POST_OUT sur la carte mère.]]

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

{| class="wikitable alternance centre"
|+ En résumé
! scope="col" | Point
! scope="col" | 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.

'''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.

==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.

'''3) Xbox 360™ corona'''

[[Fichier:xboxpluspostout.png|thumb|A droite la corona et à gauche la trinity (première slim), on voit bien que la connectivité au POST_OUT a été retirée.]]
[[Fichier:xboxpostfix.png|thumb|Outil permettant d'accéder au POST_OUT directement sur le processeur.]]

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''
[[Fichier:xboxpostfixw.png|thumb|Outil permettant d'accéder au POST_OUT directement sur le processeur.]]

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

Fichier:Xboxxell.png

2016-03-12T19:45:34Z

JorisBodin :

Fichier:Xboxpostfixw.jpg

2016-03-12T19:45:19Z

JorisBodin :

Fichier:Xboxpostfix.png

2016-03-12T19:41:43Z

JorisBodin :

Fichier:Xboxpluspostout.png

2016-03-12T19:41:24Z

JorisBodin :

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

2016-03-12T19:39:19Z

JorisBodin : /* III. Présentation du Reset Glitch Hack (RGH) */

=== Auteurs : Joris BODIN et Tim DE WINTER ===

== I. Introduction ==
[[Fichier:1.png|thumb|Illustration d'une Xbox 360 elite (gauche) et d'une Xbox 360 S (droite).]]
''' 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.

{| class="wikitable alternance centre"
|-
! scope="row" | Processeur
| Xenon triple-coeurs
|-
! scope="row" | RAM
| 512MB
|-
! scope="row" | Disque dur
| 20, 60, 120, 250, ou 320 GB
|-
! scope="row" | Processeur graphique
| ATI Xenos 512MB
|-
|}

== II. Présentation du CPU ==

''' 1) Caractéristiques techniques '''

[[Fichier:xboxcpu.png|thumb|Illustration du processeur XCPU Xenon]]
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é.

{| class="wikitable alternance centre"
|-
! scope="row" | Nom
| Xenon
|-
! scope="row" | Nombre de transistors
| 165 millions
|-
! scope="row" | Nombre de coeurs
| 3
|-
! scope="row" | Vitesse d'horloge
| 3,2 GHz
|-
! scope="row" | 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'''

[[Fichier:xboxcpupllbypass.jpg|thumb|Emplacement du signal CPU_PLL_BYPASS sur la carte mère.]]

''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''

[[Fichier:xboxcpureset.jpg|thumb|Emplacement du signal CPU_RESET sur la carte mère.]]

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''

[[Fichier:xboxcpupostout.jpg|thumb|Emplacement du signal POST_OUT sur la carte mère.]]

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

{| class="wikitable alternance centre"
|+ En résumé
! scope="col" | Point
! scope="col" | 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.

'''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.

==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.

'''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

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

2016-03-12T19:38:57Z

JorisBodin : /* IV. Le hack au fil du temps */

=== Auteurs : Joris BODIN et Tim DE WINTER ===

== I. Introduction ==
[[Fichier:1.png|thumb|Illustration d'une Xbox 360 elite (gauche) et d'une Xbox 360 S (droite).]]
''' 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.

{| class="wikitable alternance centre"
|-
! scope="row" | Processeur
| Xenon triple-coeurs
|-
! scope="row" | RAM
| 512MB
|-
! scope="row" | Disque dur
| 20, 60, 120, 250, ou 320 GB
|-
! scope="row" | Processeur graphique
| ATI Xenos 512MB
|-
|}

== II. Présentation du CPU ==

''' 1) Caractéristiques techniques '''

[[Fichier:xboxcpu.png|thumb|Illustration du processeur XCPU Xenon]]
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é.

{| class="wikitable alternance centre"
|-
! scope="row" | Nom
| Xenon
|-
! scope="row" | Nombre de transistors
| 165 millions
|-
! scope="row" | Nombre de coeurs
| 3
|-
! scope="row" | Vitesse d'horloge
| 3,2 GHz
|-
! scope="row" | 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.

'''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

Fichier:Xboxcpupostout.jpg

2016-03-12T19:32:49Z

JorisBodin :

Fichier:Xboxcpupllbypass.jpg

2016-03-12T19:28:55Z

JorisBodin :

Fichier:Xboxcpureset.jpg

2016-03-12T19:28:15Z

JorisBodin :

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

2016-03-12T19:25:05Z

JorisBodin : /* II. Présentation du CPU */

=== Auteurs : Joris BODIN et Tim DE WINTER ===

== I. Introduction ==
[[Fichier:1.png|thumb|Illustration d'une Xbox 360 elite (gauche) et d'une Xbox 360 S (droite).]]
''' 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.

{| class="wikitable alternance centre"
|-
! scope="row" | Processeur
| Xenon triple-coeurs
|-
! scope="row" | RAM
| 512MB
|-
! scope="row" | Disque dur
| 20, 60, 120, 250, ou 320 GB
|-
! scope="row" | Processeur graphique
| ATI Xenos 512MB
|-
|}

== II. Présentation du CPU ==

''' 1) Caractéristiques techniques '''

[[Fichier:xboxcpu.png|thumb|Illustration du processeur XCPU Xenon]]
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é.

{| class="wikitable alternance centre"
|-
! scope="row" | Nom
| Xenon
|-
! scope="row" | Nombre de transistors
| 165 millions
|-
! scope="row" | Nombre de coeurs
| 3
|-
! scope="row" | Vitesse d'horloge
| 3,2 GHz
|-
! scope="row" | 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

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

2016-03-12T19:24:24Z

JorisBodin : /* II. Présentation du CPU */

=== Auteurs : Joris BODIN et Tim DE WINTER ===

== I. Introduction ==
[[Fichier:1.png|thumb|Illustration d'une Xbox 360 elite (gauche) et d'une Xbox 360 S (droite).]]
''' 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.

{| class="wikitable alternance centre"
|-
! scope="row" | Processeur
| Xenon triple-coeurs
|-
! scope="row" | RAM
| 512MB
|-
! scope="row" | Disque dur
| 20, 60, 120, 250, ou 320 GB
|-
! scope="row" | 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é.

{| class="wikitable alternance centre"
|-
! scope="row" | Nom
| Xenon
|-
! scope="row" | Nombre de transistors
| 165 millions
|-
! scope="row" | Nombre de coeurs
| 3
|-
! scope="row" | Vitesse d'horloge
| 3,2 GHz
|-
! scope="row" | 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

Fichier:Xboxcpu.png

2016-03-12T19:24:10Z

JorisBodin :

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

2016-03-12T19:19:11Z

JorisBodin : /* I. Introduction */

=== Auteurs : Joris BODIN et Tim DE WINTER ===

== I. Introduction ==
[[Fichier:1.png|thumb|Illustration d'une Xbox 360 elite (gauche) et d'une Xbox 360 S (droite).]]
''' 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.

{| class="wikitable alternance centre"
|-
! scope="row" | Processeur
| Xenon triple-coeurs
|-
! scope="row" | RAM
| 512MB
|-
! scope="row" | Disque dur
| 20, 60, 120, 250, ou 320 GB
|-
! scope="row" | 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

Fichier:1.png

2016-03-12T19:16:09Z

JorisBodin :

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

2016-03-12T19:13:24Z

JorisBodin : /* I. Introduction */

=== Auteurs : Joris BODIN et Tim DE WINTER ===

== 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.

{| class="wikitable alternance centre"
|-
! scope="row" | Processeur
| Xenon triple-coeurs
|-
! scope="row" | RAM
| 512MB
|-
! scope="row" | Disque dur
| 20, 60, 120, 250, ou 320 GB
|-
! scope="row" | 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

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

2016-03-12T19:08:29Z

JorisBodin :

=== Auteurs : Joris BODIN et Tim DE WINTER ===

== 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

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

2016-03-12T19:07:13Z

JorisBodin : /* IV. Le hack au fil du temps */

=== Auteurs : Joris BODIN et Tim DE WINTER ===

== 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.

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

2016-03-12T18:58:46Z

JorisBodin :

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

2016-03-12T18:58:15Z

JorisBodin : /* III. Présentation du Reset Glitch Hack (RGH) */

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

2016-03-12T18:43:40Z

JorisBodin : /* III. Présentation du Reset Glitch Hack (RGH) */

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

2016-03-12T18:41:42Z

JorisBodin : /* II. Présentation du CPU */

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

2016-03-12T18:35:37Z

JorisBodin : /* II. Présentation du CPU */

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

2016-03-12T18:34:26Z

JorisBodin : /* I. Introduction */

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

2016-03-12T13:06:03Z

JorisBodin :

=== Auteurs : Joris BODIN et Tim DE WINTER ===

== 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)''

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

2016-03-12T12:57:14Z

JorisBodin :

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

2016-03-12T12:26:57Z

JorisBodin : Page créée avec « I. Introduction De document est destiné à un usage éducatif uniquement. Nous ne sommes pas responsable de l'utilisation frauduleuse des informations présentes dans ce ... »

I. Introduction
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)
4GB (2010)
Disque dur : 20, 60, 120, 250, ou 320 GB
Processeur graphique : ATI Xenos 512MB

Projets étudiants cryptographie et sécurité

2016-03-12T12:25:09Z

JorisBodin : /* Attaques, exploit */

= Sécurité informatique =

== Logiciels malveillants ==

# le virus "stuxnet" { N. Challut et T. Chisci }
# Cryptolocker { W. Lecable, M. Genovese }
# Octobre Rouge { REGAZZONI Rudy et LOMBARD Adrien } (ok)
# Virus et antivirus (ok) {EL AZHAR Said}
# Présentation et explication de l'attaque par le virus Stuxnet (ok) {PIRAT Victor et MENDES Etienne}
# Virus et antivirus { Mehdi M. et Christophe M. }
# Virus et Antivirus {L Burnet et Y Bouklinam } [[Projets_%C3%A9tudiants_cryptographie_et_s%C3%A9curit%C3%A9/BouklinamBurnet_Virus_Antivirus]]

== Attaques, exploit ==

# Présentation et explication d'une attaque historique (laquelle ?) { FLEUTIAUX Marc et AGUETTAZ Cédric}
# Tour d'horizon des attaques par Injection SQL. (ok) {MILLER Lucas et VIONNET Jean}
# Attaques sur SSL. (ok) {Ferlay Mathieu et Six Lancelot}
# Le Phreaking, piratage téléphonique (ok) {Rey Myriam}
# IP Spoofing et DNS Spoofing { Alberic Martel & Fabien Dezempte ) [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2008-2009/ip-dns-spoofing.ppt PPT]
# Les attaques médiatisées sur les systèmes informatiques {Renneville Guybert et Fabrice Noraz}
# Les attaques médiatisées sur les systèmes informatiques : Attaque de Mitnick, Morris Worm, DDOS Mafia Boy, etc <<<< { PIPARO, HUMBERT } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/Les_attaques_mediatisees_-_PIPARO_HUMBERT.pdf PDF]
# Attaques par injection de code XSS, parades <<<< { SERRA & ROCHE ) [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/Expose_securite_sur_le_XSS_-_Roche_et_Serra.pdf PDF]
# IP Spoofing et DNS Spoofing <<<< { DEMOLIS & JUMEAU )
# "Reset Glitch Hack" Xbox 360 {Joris et Tim} [[Projets_%C3%A9tudiants_cryptographie_et_s%C3%A9curit%C3%A9/BodinDeWinter_XBOX_RGH]]

== Sécurité applicative ==

# Comparaison de différents logiciels de crackage (ok) { AMBLARD Mathieu }
# Construire des bons mots de passe { Liu Siqi }
# Sécurité anti-piratage (ok) {CHEVALIER Daniel et REIGNIER David}

== Sécurité réseaux ==

# La sécurité et les chaines TV cryptées { CINDOLO Giuseppe & NARETTO Benjamin }
# Tunneling TCP/IP via SSH {RAHARISON Laurent & JEAN FRANÇOIS Michael}
# HTTPS et SSL { ASSIER Aymeric et ROLLINGER Claire } (ok)
# DMZ { COLLOMB Camille et LAURENT Corantin } (ok)
# Sécurité des réseaux sans fils (ok) { ZHONG Jie et GONZALEZ Miguel }
# Le principe de VPN et les attaques de VPN (ok) { DU Peng }
# Présentation de quelques attaques informatiques et quelques solutions proposées pour y remédier dans les réseaux P2P (ok) { Lila Zane et Ouhemmi }
# Comment Aircrack trouve les clés WEP des réseaux wifi (ok) { LANOISELIER Aurélien et MARCHANOFF Jérôme}
# Tunneling, sécurisation et piratage (ok). {COLLEN Cyril et LAQUA Johann}
# Securité des réseaux sans fils (ok) {Tounkara Mounina et Philippe Monteiro}
# Les Protocoles de sécurité dans les réseaux WiFi (WEP et WPA) <<<< { Mickaël Wang & Arnaud Villevieille } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2008-2009/Securite-wifi.pdf PDF]
# Les outils d'analyse de la sécurité des réseaux : renifleur, scanneurs de ports, outils de détection d'intruison { Anis HADJALI & Vlad VESA } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2008-2009/analyse-securite.pdf PDF]
# L'introduction SSL,SSH { Julien Roche & Yi Wang }
# Secure shell (SSH) : protocole, applications, tunnelling <<<< {BODIN}
# Sécurité des réseaux sans fil : authentification, chiffrement, WEP, WPA =>Bugnard/Berthet
# Sécuriser un réseau : pare-feu, zone démilitarisée, protection des serveurs, adressage local <<<<<< {FOLLIET et VIALA} [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/presentation_VIALA_FOLLIET.pdf PDF]
# IPsec

== Sécurité de l'hôte ==

# La sécurité dans les box de FAI { Charron Thomas & Mesurolle Anthony }
# Failles de sécurité des systèmes informatiques de grandes entreprises (LinkedIn, Apple, Sony, ...) { ARNOULD Mickaël et LEMAIRE Noémie } (ok)
# La virtualisation, facteur de sécurité ou de vulnérabilité (ok) { DIMIER Cédric et CARRIE Antoine }
# Sécurité sous Linux en entreprise { Joël Leroy Ebouele & Barbier Keller }
# Techniques et outils de chiffrements de partitions [Valat Sebastien & Bouleis Romain]
# OpenBSD : aspects sécurité <<<<<< (REVELIN et ERROCHDI) [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/OpenBSD_-_Revelin-Errochdi.pdf PDF]

== Sécurité et web ==

# Google Recaptcha { A. SAYAH, A. EL-HARRAS }
# Le Cloud et la Cryptologie { Capellaro Alexandre & Chabert Cédric }
# Sécurité atypique et empreintes des navigateurs {FONTANA Antonin}
# Injections SQL & faille XSS { GUILLOT Pierre & KRATTINGER Thibaut }
# Nouvelle philosophie de partage de fichiers avec MEGA { WAYNTAL David et DOMINATI Nicolas } (ok)
# La sécurité sur les sites Web (ok) {RABARIJAONA Domoina et BERTHET Vincent}
# Présentation des Honeypots (ok) {Adiche Rafik et Jean-François Michel-Patrique}
# Google Hacking { Julien ARNOUX & Jeremy DEPOIL } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2008-2009/ghack.pptx PPTX]

== Sécurité des mobiles et informatique ambiante ==

# Sécurité et mobile : nouvelle cible des pirates { GEVET Gwénaël et YANG Yang } (ok)
# Vulnérabilités des smartphones (ok) {Titouan VAN BELLE et Jean-Baptiste PAUMIER}
# L'Informatique Ambiante et La Sécurité:Quel Protocole? (ok) {Marclin LEON et Farid BOUKHEDDAD}
# Vulnérabilité du protocole A5/1 des mobiles GSM. <<<<< {FERNANDES} [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/Cryptologie_et_securite_informatique_-_Fernandes.pdf PDF]
# Sécurité GPRS <<<<<< (PEHME et REY) [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/Securite_GPRS_-PEHME_REY.pdf PDF]
# Sécurité Bluetooth 4.X ( Treboux Jérome ) [[Projets_étudiants_cryptographie_et_sécurité/Treboux_jerome_Securite_Bluetooth_4X]]

== Politique de sécurité ==

# Sécurité et [http://www.infosafe.fr/Armoirefortedin/Armoirefortedin.htm armoire forte ignifuge] pour les sauvegardes de données
# Fuites de donnée en entreprise (ok) {Tounkara Mounina et Philippe Monteiro}
# PRA le Plan de Reprise d'Activité {Achraf AMEUR}
# La mise en place de la sécurité informatique au niveau national et international : CERTs, sites AntiSPAM

= Cryptographie =

== Génération aléatoire ==

# Principes et techniques de génération de nombres aléatoires {BERTHON Yohann & KELFANI Hugo & REY Anthony}
# Systèmes physiques de génération de nombres aléatoires : principes et avantages. (ok) {Florent Carral et Julie Tacheau}

== Chiffrement symétrique (à clé secrète partagée) ==

# AES { Avet Anthony & Duraz Aurélien }
# IDEA { Caillet François & Di Lisio Anthony } [[Projets_étudiants_cryptographie_et_sécurité/Caillet_DiLisio_IDEA]]

== Chiffrement asymétrique (à clé publique) ==

# PGP et la sécurité de l'information {Cyrille Mortier}

== Signature, certificats ==

# La signature numérique (ok) { DJEDDI Abdelkader }
# Les certificats (PGP, X509) et les infrastructures de gestion de clés

== Empreintes et fonctions de hachage ==

== Cryptanalyse ==

# Le craquage de la cryptographie quantique ? { D. Cauwet, A. Hauguel }
# Calculateurs quantiques et applications en cryptographie { BORCARD Justine et CATHELIN Gaël }
# Vulnérabilité du protocole WEP et de RC4 pour les réseaux WiFi <<<< { PAVLOU, DALLACOSTA } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/Presentation_cryptologie_PAVLOU_DALLA_COSTA_512.mov MOV]

== Tatouage, watermarking, biométrie, DRM ==

# La stéganographie { K. Deléglise, Y. Rakotonanahary }
# La stéganographie { Bosviel Thomas & Tolron Sebastien}
# Biométrie { BACART Aurélien et BAH Abdoulaye } (ok)
# Biométrie (ok) { ZANE Bania et MENTDAHI Houda }
# Stéganographie(ok) { PONCET Johan et MARTIN Romain}
# Stéganographie ou les signatures numériques (ok) { TARDY Camille et CASSAGNERES Pierre-André}
# La biométrie, une solution miracle pour l'authentification ? (ok) { FERNANDES PIRES Anthony et GAYET Eric}
# La gestion des DRM {Petithory Thomas & Paccard Charléric}
# Le tatouage d'image et de document (watermarking) <<<< {MAESEELE, CIMINERA } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/Watermarking_Ciminera_Maeseele.pdf PDF]
# Watermarking et steganographie { Adrien DETRAZ et Julien CABALLOL } [https://lama.univ-savoie.fr/mediawiki/index.php/Projets_étudiants_cryptographie_et_sécurité/Detraz_Caballol_Watermarking_Steganographie Projets_étudiants_cryptographie_et_sécurité/Caballol-Detraz_Watermarking_Steganographie]

== Cryptographie quantique ==

# Principes de cryptographie quantique (DE ROLAND Céline, LECLAIRE Juliana) [[Projets_%C3%A9tudiants_cryptographie_et_s%C3%A9curit%C3%A9/Leclaire_DeRoland_Crypto_Quantique]]
# Cryptographie quantique: Vulnérabilités ( DCHAR Ahmed, AMJAD Nassif ) [[Projets_étudiants_cryptographie_et_sécurité/Dchar-Amjad_Cryptographie_Quantique_Vulnerabilités]]

= Sécurité, cryptographie dans la société =

== Cryptographie historique ==

# La cryptographie dans l'antiquité { Y. Lombardi, G. Badin }
# La machine de Turing et ses variantes { C. Laignel, P.E. Roux }
# La machine ENIGMA { B. Da Silva, G. Ply }
# L'histoire de la cryptographie (ok) {Costa Jean-Philippe et Morel Julien}
# Evolution de la cryptologie à travers les âges (ok, mais vaste !) { DEBAENE Aurélien et VINCENT Christophe }
# La Machine Enigma (ok) { JULLIAN-DESAYES Jeremy et GARDET Nicolas }

== Cyberguerre ==

# Cryptologie VS NSA { H. Ramamonjy, N.E. Ould Kadi }
# La cyberguerre { COLIN François et APPREDERISSE Benjamin } (ok)
# La cryptographie militaire { GIUNCHI Ryan & CIMINERA Lary }
# La cyberguerre (ok) {MAIRE Cyril et MONTCHAL Justine}
# La cyberguerre (ok) { SOUBEYRAND Martin et ROBART Laetitia }

== Monnaies électroniques ==

# le Bitcoin { H. Helbawi, A. Tang, J. }
# Le cryptosystème Bitcoin { Johanny Clerc-Renaud & Clément Montigny }
# La sécurité des monnaies électroniques {BUISSON Valentin & GENY-DUMONT Rémi}

== Cartes bancaires ==

# La sécurité des cartes bancaires { M. Salvat, Y. Salti }
# Sécurité des cartes bancaires { A. Bigane, F. Way }
# Le paiement par NFC { J. Maurice, S. Zehnder }
# Payement NFC { Montouchet Raphaël & Marois Jeremy }
# La technologie RFID et la sécurité { CHANTREL Thierry & SEZILLE Aurélien }
# La sécurité des cartes bancaires (ok) { DORIEN Christophe et LAPIERRE Rémy }
# Sécurité dans les cartes à puce (ok) { LAGHA Youssef et Nodari }
# 3DSecure { Natalia Lecoeur & Cindy Chiaberto } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2008-2009/3D_Secure.pdf PDF]

Projets étudiants cryptographie et sécurité

2016-02-16T15:17:46Z

JorisBodin : /* attaques, exploit */

= Sécurité informatique =

== Logiciels malveillants ==

# le virus "stuxnet" { N. Challut et T. Chisci }
# Cryptolocker { W. Lecable, M. Genovese }
# Octobre Rouge { REGAZZONI Rudy et LOMBARD Adrien } (ok)
# Virus et antivirus (ok) {EL AZHAR Said}
# Présentation et explication de l'attaque par le virus Stuxnet (ok) {PIRAT Victor et MENDES Etienne}
# Virus et antivirus { Mehdi M. et Christophe M. }

== Attaques, exploit ==

# Présentation et explication d'une attaque historique (laquelle ?) { FLEUTIAUX Marc et AGUETTAZ Cédric}
# Tour d'horizon des attaques par Injection SQL. (ok) {MILLER Lucas et VIONNET Jean}
# Attaques sur SSL. (ok) {Ferlay Mathieu et Six Lancelot}
# Le Phreaking, piratage téléphonique (ok) {Rey Myriam}
# IP Spoofing et DNS Spoofing { Alberic Martel & Fabien Dezempte ) [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2008-2009/ip-dns-spoofing.ppt PPT]
# Les attaques médiatisées sur les systèmes informatiques {Renneville Guybert et Fabrice Noraz}
# Les attaques médiatisées sur les systèmes informatiques : Attaque de Mitnick, Morris Worm, DDOS Mafia Boy, etc <<<< { PIPARO, HUMBERT } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/Les_attaques_mediatisees_-_PIPARO_HUMBERT.pdf PDF]
# Attaques par injection de code XSS, parades <<<< { SERRA & ROCHE ) [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/Expose_securite_sur_le_XSS_-_Roche_et_Serra.pdf PDF]
# IP Spoofing et DNS Spoofing <<<< { DEMOLIS & JUMEAU )
# "Reset Glitch Hack" Xbox 360 {Joris et Tim}

== Sécurité applicative ==

# Comparaison de différents logiciels de crackage (ok) { AMBLARD Mathieu }
# Construire des bons mots de passe { Liu Siqi }
# Sécurité anti-piratage (ok) {CHEVALIER Daniel et REIGNIER David}

== Sécurité réseaux ==

# La sécurité et les chaines TV cryptées { CINDOLO Giuseppe & NARETTO Benjamin }
# Tunneling TCP/IP via SSH {RAHARISON Laurent & JEAN FRANÇOIS Michael}
# HTTPS et SSL { ASSIER Aymeric et ROLLINGER Claire } (ok)
# DMZ { COLLOMB Camille et LAURENT Corantin } (ok)
# Sécurité des réseaux sans fils (ok) { ZHONG Jie et GONZALEZ Miguel }
# Le principe de VPN et les attaques de VPN (ok) { DU Peng }
# Présentation de quelques attaques informatiques et quelques solutions proposées pour y remédier dans les réseaux P2P (ok) { Lila Zane et Ouhemmi }
# Comment Aircrack trouve les clés WEP des réseaux wifi (ok) { LANOISELIER Aurélien et MARCHANOFF Jérôme}
# Tunneling, sécurisation et piratage (ok). {COLLEN Cyril et LAQUA Johann}
# Securité des réseaux sans fils (ok) {Tounkara Mounina et Philippe Monteiro}
# Les Protocoles de sécurité dans les réseaux WiFi (WEP et WPA) <<<< { Mickaël Wang & Arnaud Villevieille } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2008-2009/Securite-wifi.pdf PDF]
# Les outils d'analyse de la sécurité des réseaux : renifleur, scanneurs de ports, outils de détection d'intruison { Anis HADJALI & Vlad VESA } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2008-2009/analyse-securite.pdf PDF]
# L'introduction SSL,SSH { Julien Roche & Yi Wang }
# Secure shell (SSH) : protocole, applications, tunnelling <<<< {BODIN}
# Sécurité des réseaux sans fil : authentification, chiffrement, WEP, WPA =>Bugnard/Berthet
# Sécuriser un réseau : pare-feu, zone démilitarisée, protection des serveurs, adressage local <<<<<< {FOLLIET et VIALA} [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/presentation_VIALA_FOLLIET.pdf PDF]
# IPsec

== Sécurité de l'hôte ==

# La sécurité dans les box de FAI { Charron Thomas & Mesurolle Anthony }
# Failles de sécurité des systèmes informatiques de grandes entreprises (LinkedIn, Apple, Sony, ...) { ARNOULD Mickaël et LEMAIRE Noémie } (ok)
# La virtualisation, facteur de sécurité ou de vulnérabilité (ok) { DIMIER Cédric et CARRIE Antoine }
# Sécurité sous Linux en entreprise { Joël Leroy Ebouele & Barbier Keller }
# Techniques et outils de chiffrements de partitions [Valat Sebastien & Bouleis Romain]
# OpenBSD : aspects sécurité <<<<<< (REVELIN et ERROCHDI) [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/OpenBSD_-_Revelin-Errochdi.pdf PDF]

== Sécurité et web ==

# Google Recaptcha { A. SAYAH, A. EL-HARRAS }
# Le Cloud et la Cryptologie { Capellaro Alexandre & Chabert Cédric }
# Sécurité atypique et empreintes des navigateurs {FONTANA Antonin}
# Injections SQL & faille XSS { GUILLOT Pierre & KRATTINGER Thibaut }
# Nouvelle philosophie de partage de fichiers avec MEGA { WAYNTAL David et DOMINATI Nicolas } (ok)
# La sécurité sur les sites Web (ok) {RABARIJAONA Domoina et BERTHET Vincent}
# Présentation des Honeypots (ok) {Adiche Rafik et Jean-François Michel-Patrique}
# Google Hacking { Julien ARNOUX & Jeremy DEPOIL } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2008-2009/ghack.pptx PPTX]

== Sécurité des mobiles et informatique ambiante ==

# Sécurité et mobile : nouvelle cible des pirates { GEVET Gwénaël et YANG Yang } (ok)
# Vulnérabilités des smartphones (ok) {Titouan VAN BELLE et Jean-Baptiste PAUMIER}
# L'Informatique Ambiante et La Sécurité:Quel Protocole? (ok) {Marclin LEON et Farid BOUKHEDDAD}
# Vulnérabilité du protocole A5/1 des mobiles GSM. <<<<< {FERNANDES} [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/Cryptologie_et_securite_informatique_-_Fernandes.pdf PDF]
# Sécurité GPRS <<<<<< (PEHME et REY) [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/Securite_GPRS_-PEHME_REY.pdf PDF]

== Politique de sécurité ==

# Sécurité et [http://www.infosafe.fr/Armoirefortedin/Armoirefortedin.htm armoire forte ignifuge] pour les sauvegardes de données
# Fuites de donnée en entreprise (ok) {Tounkara Mounina et Philippe Monteiro}
# PRA le Plan de Reprise d'Activité {Achraf AMEUR}
# La mise en place de la sécurité informatique au niveau national et international : CERTs, sites AntiSPAM

= Cryptographie =

== Génération aléatoire ==

# Principes et techniques de génération de nombres aléatoires {BERTHON Yohann & KELFANI Hugo & REY Anthony}
# Systèmes physiques de génération de nombres aléatoires : principes et avantages. (ok) {Florent Carral et Julie Tacheau}

== Chiffrement symétrique (à clé secrète partagée) ==

# AES { Avet Anthony & Duraz Aurélien }

== Chiffrement asymétrique (à clé publique) ==

# PGP et la sécurité de l'information {Cyrille Mortier}

== Signature, certificats ==

# La signature numérique (ok) { DJEDDI Abdelkader }
# Les certificats (PGP, X509) et les infrastructures de gestion de clés

== Empreintes et fonctions de hachage ==

== Cryptanalyse ==

# Le craquage de la cryptographie quantique ? { D. Cauwet, A. Hauguel }
# Calculateurs quantiques et applications en cryptographie { BORCARD Justine et CATHELIN Gaël }
# Vulnérabilité du protocole WEP et de RC4 pour les réseaux WiFi <<<< { PAVLOU, DALLACOSTA } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/Presentation_cryptologie_PAVLOU_DALLA_COSTA_512.mov MOV]

== Tatouage, watermarking, biométrie, DRM ==

# La stéganographie { K. Deléglise, Y. Rakotonanahary }
# La stéganographie { Bosviel Thomas & Tolron Sebastien}
# Biométrie { BACART Aurélien et BAH Abdoulaye } (ok)
# Biométrie (ok) { ZANE Bania et MENTDAHI Houda }
# Stéganographie(ok) { PONCET Johan et MARTIN Romain}
# Stéganographie ou les signatures numériques (ok) { TARDY Camille et CASSAGNERES Pierre-André}
# La biométrie, une solution miracle pour l'authentification ? (ok) { FERNANDES PIRES Anthony et GAYET Eric}
# La gestion des DRM {Petithory Thomas & Paccard Charléric}
# Le tatouage d'image et de document (watermarking) <<<< {MAESEELE, CIMINERA } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/Watermarking_Ciminera_Maeseele.pdf PDF]

== Cryptographie quantique ==

# Principes de cryptographie quantique (DE ROLAND Céline, LECLAIRE Juliana) [[Projets_%C3%A9tudiants_cryptographie_et_s%C3%A9curit%C3%A9/Leclaire_DeRoland_Crypto_Quantique]]

= Sécurité, cryptographie dans la société =

== Cryptographie historique ==

# La cryptographie dans l'antiquité { Y. Lombardi, G. Badin }
# La machine de Turing et ses variantes { C. Laignel, P.E. Roux }
# La machine ENIGMA { B. Da Silva, G. Ply }
# L'histoire de la cryptographie (ok) {Costa Jean-Philippe et Morel Julien}
# Evolution de la cryptologie à travers les âges (ok, mais vaste !) { DEBAENE Aurélien et VINCENT Christophe }
# La Machine Enigma (ok) { JULLIAN-DESAYES Jeremy et GARDET Nicolas }

== Cyberguerre ==

# Cryptologie VS NSA { H. Ramamonjy, N.E. Ould Kadi }
# La cyberguerre { COLIN François et APPREDERISSE Benjamin } (ok)
# La cryptographie militaire { GIUNCHI Ryan & CIMINERA Lary }
# La cyberguerre (ok) {MAIRE Cyril et MONTCHAL Justine}
# La cyberguerre (ok) { SOUBEYRAND Martin et ROBART Laetitia }

== Monnaies électroniques ==

# le Bitcoin { H. Helbawi, A. Tang, J. }
# Le cryptosystème Bitcoin { Johanny Clerc-Renaud & Clément Montigny }
# La sécurité des monnaies électroniques {BUISSON Valentin & GENY-DUMONT Rémi}

== Cartes bancaires ==

# La sécurité des cartes bancaires { M. Salvat, Y. Salti }
# Sécurité des cartes bancaires { A. Bigane, F. Way }
# Le paiement par NFC { J. Maurice, S. Zehnder }
# Payement NFC { Montouchet Raphaël & Marois Jeremy }
# La technologie RFID et la sécurité { CHANTREL Thierry & SEZILLE Aurélien }
# La sécurité des cartes bancaires (ok) { DORIEN Christophe et LAPIERRE Rémy }
# Sécurité dans les cartes à puce (ok) { LAGHA Youssef et Nodari }
# 3DSecure { Natalia Lecoeur & Cindy Chiaberto } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2008-2009/3D_Secure.pdf PDF]