Le RGH est un hack réalisé par GliGli et Tiros permettant de lancer du code non signé sur la majorité des consoles Xbox 360, quelque soit le Kernel de celle-ci.
? Comment ca marche?
Pour faire (très) simple, une puce envoi une série d'impulsions électriques au processeur, afin de déstabiliser la console et lui faire croire qu'un CB modifié est authentique (correctement hashé et signé). Cette opération ne réussit pas à chaque fois, mais elle se répète jusquà son succès. Une fois que le CB modifié/hacké est validé par la console, il possède les droits suffisants pour lancer du code non signé, dans notre cas XeLL, le Xenon Linux Loader. Vous pouvez l'explication complète dans le spoiler ci-dessous.
Spoiler
*************************************** * The Xbox 360 reset glitch hack * ***************************************
Tmbinc l'a dit lui même, les approches logicielles pour lancer du code non signé sur la 360 ne marchent pas dans la plupart des cas, elle a conçue pour être sûre d'un point de vue logiciel.
Le processeur commence par lancer du code à partir de la ROM (1bl), qui ensuite charge du code signé en RSA et crypté en RC4 à partir de la NAND (CB).
Le CB initialise ensuite le moteur de sécurité du processeur, sa tâche sera d'encrypter et vérifier le hash de la mémoire physique DRAM en temps réel. De ce que nous avons trouvé, il utilise l'AES128 pour le cryptage et un hachage (Toeplitz?) robuste. Le cryptage est différent à chaque démarrage, car il dépends d'au moins : - Un hash du fuseset entier - La valeur du compteur de temps du CPU (timebase) - Une valeur totalement aléatoire générée par une partie hardware dédiée du processeur. Sur les FAT, ce RNG peut être électriquement désactivé, mais il y a une vérification sur "l'apparence aléatoire" (un comptage des bits à 1 en fait) dans le CB, il attends jusqu'à avoir ce qui lui semble être une valeur aléatoire correcte.
Le CB peut ensuite lancer un moteur logiciel basé sur une sorte de "bytecode" simple qui aura pour tâche d'initialiser la DRAM, le CB peut alors charger le bootloader suivant (CD) depuis la NAND, et le lancer.
Pour faire simple, le CD chargera alors un kernel à partir de la NAND, le patchera et le lancera.
Ce kernel contient une petite partie de code privilégiée (hyperviseur), quand la console tourne, c'est le seul code qui aura assez de droits pour lancer du code non signé.
Dans les kernels 4532/4548, une faille critique est apparue, et tous les hack 360 connus nécessitent d'utiliser un de ces kernels et d'exploiter cette faille pour lancer du code non signé.
Sur les 360s actuelles, le CD contient un hash de ces 2 kernels et arrêtera le processus de boot si vous essayez de charger l'un d'eux.
L'hyperviseur est une relativement petite partie de code à vérifier pour trouver une faille et apparemment aucune nouvelle version n'en contiens qui pourraient autoriser le lancement de code non signé.
D'un autre coté, Tmbinc a dit que la 360 n'avait pas été conçue pour résister à certaines attaques hardware tel que le timing attack et le "glitching".
Le Glitching ici est essentiellement l'action de cibler certains bugs processeur de manière électronique.
C'est la manière que nous avons utilisée pour pouvoir lancer du code non signé.
Le glitch du reset en quelques mots ===========================
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.
Détails pour le hack des fats =====================
Sur les FAT, le bootloader que nous faisons glitcher est le CB, afin de pouvoir lancer le CD que nous voulons.
Cjak a découvert qu'en activant le signal CPU_PLL_BYPASS, l'horloge du CPU ralentissait beaucoup, il y a un point de test sur la carte mère qui est une fraction de la vitesse du CPU, il est a 200Mhz lorsque le Dashboard est lancé, 66.6Mhz lorsque la console démarre et 520Khz lorsque le signal est activé.
Nous procédons donc de cette manière: - Nous activons CPU_PLL_BYPASS autour du code POST 36 (hex). - Nous attendons que le POST 39 démarre (le POST 39 est le comparateur de mémoire entre le hash stocké et le hash de l'image), et démarrons un compteur. - Lorsque le compteur atteint une valeur précise (c'est souvent autour de 62% de la longueur totale du POST 39), nous envoyons une pulsation de 100ns sur le CPU_RESET. - Nous attendons un moment et ensuite nous désactivons CPU_PLL_BYPASS. - La vitesse du CPU redevient normale, et avec un peu de chance, à la place d'obtenir une erreur POST AD, le processus de boot se poursuit et le CB lance notre CD modifié.
La NAND contient un CB "zero-paired", notre payload dans un CD modifié et une image SMC modifiée également. Un glitch n'est, par nature, pas fiable, nous utilisons une image SMC modifiée qui reboot infiniment (en comparaison l'image d'origine redémarre 5 fois et ensuite la console est RROD) jusqu'à ce que la console aie démarrée correctement. Dans la majorité des cas, la console boot en moins de 30 secondes après le démarrage.
Détails pour le hack des slims ======================
Le bootloader que nous faisons glitcher est le CB_A, de cette manière nous pouvons lancer le CB_B que nous voulons.
Sur les slims, nous n'avons pas été capables de trouver une piste sur la carte mère pour CPU_PLL_BYPASS. Notre première idée a été de retirer le cristal 27Mhz maître et générer notre propre horloge à la place, mais il s'agissait d'une modification complexe, et qui n'a pas donné de résultats probants. Nous avons ensuite regardé sur d'autres moyens de ralentir l'horloge du CPU et nous avons découvert que la puce HANA possède des registres PLL configurables pour l'horloge 100Mhz fournissant les paires différentielles CPU et GPU. Apparemment ces registres sont écrits par le SMC au travers du bus I2C. Le bus I2C est accessible librement, il est même accessible depuis un header (J2C3). Ainsi la puce HANA devient notre arme de choix pour ralentir le CPU (désolé tmbinc, tu ne peux pas toujours avoir raison, elle n'est pas ennuyeuse et il s'agit bien d'un bus intéressant
Nous procédons donc de cette manière : - Nous envoyons une commande i2c vers l'HANA afin de ralentir le CPU au code POST D8 . - Nous attendons que le POST DA démarre (POST DA est le comparateur de mémoire entre le hash stocké et le hash de l'image), et nous démarrons un compteur. - Lorsque le compteur atteint une valeur précise, nous envoyons une pulsation de 20ns sur le CPU_RESET. - Nous attendons un moment et ensuite nous envoyons une commande i2c en direction de l'HANA afin que l'horloge du CPU revienne à son état normal. - La vitesse du CPU redevient normal, et avec un peu de chance, à la place d'obtenir une erreur POST F2, le processus de boot se poursuit et le CB_A lance notre CB_B modifié.
Lorsque le CB_B démarre, la DRAM n'est pas initialisée, nous avons donc décidé de n'appliquer que les patchs suivants pour qu'il puisse lancer n'importe quel CD : - Activation permanente du mode "zero-paired" afin de pouvoir utiliser une image SMC modifiée. - Non-décryptage du CD, et attente d'un CD en clair dans la NAND. - Pas d'arrêt du processus de boot si le hash CD n'est pas correct.
Le CB_B est crypté en RC4, la clé provient de la clé CPU, alors comment patcher le CB_B sans connaitre la clé CPU? Le cryptage RC4 c'est en gros: crypté = texte-clair xor flux-de-clé-pseudo-aléatoire Ainsi si nous connaissons le texte clair et crypté, nous pouvons connaitre le flux de clés, et avec lui, nous pouvons encrypter notre propre code. Cela fonctionne ainsi : flux-de-clé-pseudo-aléatoire-supposé = crypté xor texte-clair nouvelle-encryption = flux-de-clé-pseudo-aléatoire-supposé xor patch-texte-clair Vous pouvez penser qu'il s'agit d'un problème du style de l'oeuf et la poule, c'est à dire comment obtient-on le texte clair en premier lieu? Facile: nous connaissons le texte en clair des CB provenant des consoles FAT, et nous avons supposé que les premiers bytes du code seraient les même que le nouveau CB_B, nous avons ainsi pu encrypter une petite partie de code pour dumper la clé CPU et décrypter le CB_B!
La NAND contient le CB_A, un CB_B patché, notre payload dans un CD en clair (non crypté) modifié, et une image SMC modifiée. L'image SMC est modifiée pour avoir un nombre de reboot infini, et pour l'empêcher d'émettre périodiquement de commandes I2C pendant que nous envoyons les nôtres.
Vous n'avez peut-être pas encore réalisé, mais le CB_A ne contient pas de vérification sur les EFUSEs de révocation, ce hack est donc non patchable.
Bémols ======
Rien n'est parfait, il y a donc quelques bémols sur ce hack : - Même si le Glitch trouvé est plutôt fiable (Taux de réussite de 25% par essai en moyenne), il se peut que la console prenne quelques minutes pour lancer du code non signé. - Ce taux de succès est lié au hash du bootloader modifié que nous souhaitons lancer (CD pour les FAT et CB_B pour les slims). - Il requiert un matériel rapide et précis permettant d'envoyer la pulsation de reset.
Notre intégration actuelle ===================
Nous utilisons un CPLD Xilinx CoolRunner II (xc2c64a), parce qu'il est rapide, précis, reprogrammable, pas cher et fonctionne avec deux niveaux de tension différents en même temps. Nous utilisons l'horloge standby 48Mhz de la 360 pour le compteur du glitch. Pour le hack Slim, le compteur tourne même à 96Mhz (incrémenté sur les fronts montants et descendants de l'horloge) Le code du CPLD est écrit en VHDL. Nous avons besoin de connaître le code POST actuel, notre première mise en application utilisait l'intégralité des 8 bits du port POST à cet usage, mais nous sommes maintenant capables de détecter les changements d'un seul bit du POST rendant le montage plus simple.
Conclusion ========
Nous avons essayé de ne pas inclure de MS copyrighté dans le pack de hack diffusé. Le but de ce hack est de lancer XeLL et d'autres logiciels libres, je (GliGli) NE promeus EN AUCUN CAS le piratage ni quoi que soit qui s'en rapproche, je veux juste avoir la possibilité de faire ce que je veux avec le matériel que j'achète, y compris lancer mon propre code natif dessus.
Crédits =====
GliGli, Tiros: Reverse engineering et développement du hack cOz: Reverse engineering, beta test. Razkar, tuxuser: beta test. Cjak, Redline99, SeventhSon, tmbinc, tous ceux que j'ai oubliés... : Précédent reverse engineering et/ou du travail de hack sur la 360.
?A quoi ca sert? Code non signé?
Le code non signé, c'est du code qui n'a pas été signé avec la signature microsoft également appelé "private key". En temps normal, si du code n'est pas encrypté avec cette clé ... il ne peut pas se lancer, avec ce hack c'est possible =).
- Ouai mais bon ... concretement ? Vous pouvez lancer des emulateurs et homebrew basé sur libxenon via XeLL, et vous pouvez lancer les jeux xbox 360, emulateur codé avec le SDK Xbox, les DLC, XBLA...
?C'est le Jtag V2 ?
NOOOOOOOOOOOOOOOOOOOOON !!!! Le Jtag comme le RGH est un exploit permettant de lancer du code non signé (ils ont donc la même finalité) mais ce sont deux choses complétement différentes, qui ne repose pas sur les mêmes principes et méthodes de hack. Pour faire une métaphore, si "lancer du code non signé" ce serait "manger pour avoir des force"... les moyens sont dans le premier cas le "RGH" et le JTAG" dans l'autre "la cote de boeuf saignante avec des patates" et "la glace au chocolat". Ben la cote de boeuf ... c'est pas la glace au chocolat V2 !!! =)
?Maintenant que j'ai tout compris, ma console est elle compatible ?
Presque toutes les consoles HDMI sont compatibles, les consoles avec des carte mère Xenon/Opus ne sont donc pas compatible. Cependant, des consoles ne sont pas compatibles : - Zephyr incompatible avec un CB supérieur à 4579 - Opus incompatible avec un CB supérieur à 5771 - Falcon incompatible avec un CB supérieur à 5771 - Jasper incompatible avec un CB supérieur à 6751 - Carte mère Xbox Slim CORONA Vous pouvez retrouvez ICI un diagramme vous permettant de savoir facilement quelle carte mère vous avez.
?Quel est le matériel nécessaire pour réaliser ce hack?
- Un cerveau !!! - Un CPLD (Cmod, Glitchip, matrix etc...) (voir LSStore). - Un module USB permettant de dumper la NAND (possible également avec un cable LPT) (voir LSStore). - Un fer a souder (12-18w) et de quoi souder (Kynar + etain). - Les logiciels Impact, nandpro d'installé
? J'ai tout ce qui faut ... maintenant ... je fais comment ?
Vous trouverez un tutoriel pour créer une nand Hacké (permettant de booter sur le NXE) => ICI
? Aurais-je les mêmes fonctionnalités qu'avec le jtag?
Oui
? Est ce que dans le futur, je pourrais aller sur le XBOX LIVE? NON, le LIVE ou le piratage ... il faut choisir. Pour ceux qui sont intéréssé par le LIVE ... vous trouverez tous ce qu'il vous faut ICI.
Attention parce que les glaces au boeuf existent ^^
Sinon bonne FAQ expliquée avec des mots simple ( le plus important dans une FAQ/tuto pour moi ).
Enfin mention spéciale pour ta dernière ligne.
Xbox360 : Flash, RGH, Réparation PS3 : Downgrade, Custom Firmware Wii/U : USB Loader, Media Center Travail propre et sérieux, de plus je conserve la garantie de la console ! SurMarseille, sous vos yeux en 20min ! > > > Contactez Moi !
Merci pour ce tuto ca risque de m'aider!
J'aimerais une petite précision je ne sais pas si je post au bon endoit... Quelle est la difference entre cette methode de flash et la puce de soulHeaven...est il possible d'avoir un tuto concernant cette puce si la methode est differente?
Toutes les consoles HDMI sont compatibles, les consoles avec des carte mère Xenon/Opus ne sont donc pas compatible.
Je me permet d'insister sur ce point : Toutes les consoles HDMI ne sont pas compatibles, les Jasper avec un CB6752 ne le sont pas ainsi que les Falcon avec un CB5772. Les nouvelles révisions de carte mère slim après Juillet 2011 ne le sont plus également donc SVP, corrigez la FAQ.
Merci
Ce message a été modifié par maxell - 12 novembre 2011 - 10:39.
Je me permet d'insister sur ce point : Toutes les consoles HDMI ne sont pas compatibles, les Jasper avec un CB6752 ne le sont pas ainsi que les Falcon avec un CB5772. Les nouvelles révisions de carte mère slim après Juillet 2010 ne le sont plus également donc SVP, corrigez la FAQ.
