Aller au contenu


Photo

Le Reset Glitch Hack : un nouvel exploit sur Xbox 360 *MAJ* [ FR ]


  • Veuillez vous connecter pour répondre
214 réponses à ce sujet

Posté 28 août 2011 - 13:52

#1
Razkar

Razkar

    HomeBrew Lover

  • Shining VIP
  • 6 098 messages
  • Sexe:Male

Le développeur et hacker français, GliGli, est fier de vous livrer aujourd'hui, via les forums Xbox-Hacker.org, ce que la majorité des fans de homebrews attendait depuis plus d'un an : un nouvel exploit sur Xbox 360. Cet exploit baptisé "Reset Glitch Hack" nécessite l'installation d'une puce et est compatible avec tous les modèles Slims et certaines FAT : Zephyr et Jasper (le support des carte mère Falcon viendra ultérieurement lorsque l'auteur en aura une sous la main).

 

Pour faire (très) simple, la 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. Si vous voulez plus de détails, vous pouvez lire l'explication de l'auteur ci-dessous et voir les sources du hack disponible ICI.

 

Les avantages de ce Hack :

 

? Toutes les consoles seront compatibles sauf les Xenons

? Il n'est pas patchable, en effet le CB intervient tellement tôt dans le processus de boot de la console qu'il ne peut être révoqué.

 

Ses Inconvénients:

 

? Nécessite l'installation d'une puce.

? Le temps de boot est variable et peut aller jusqu'a 2-3 minutes.

 

 

 

Voici l'explication complète du Hack par GliGli et traduit par nos soins :

 

***************************************
* The Xbox 360 reset glitch hack *
***************************************

Introduction / quelque faits importants
=============================

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.

 

Ce hack, comme l'a expliqué l'auteur n'a pas vocation à promouvoir le piratage, qui n'est d’ailleurs pas possible actuellement puisqu'il ne permet que le lancement de XeLL, lui même offrant la possibilité de lancer du code libre comme les  homebrews libXenon, Linux etc ....

 

Nous vous serons gré de bien vouloir respecter le travail et la volonté de l'auteur, si vous ne vous sentez pas concerné par ce hack, merci de passer votre chemin. Les messages du style "ça sert à rien", "vivement le lancement des backups" seront supprimés et votre compte placé en prévisualisation, voire banni.

Merci de votre compréhension.

 

RETROUVEZ NOTRE TUTORIEL COMPLET POUR LES SLIM ICI

 

*MAJ*

Ajout du tuto pour les consoles FAT

RETROUVEZ NOTRE TUTORIEL COMPLET POUR LES FAT ICI

Liens utiles :

 

? http://gligli360.blogspot.com/

? http://libxenon.org/
? http://sourceforge.n...rojects/free60/
? http://free60.git.so...itweb-index.cgi
? http://www.free60.org/Main_Page


  • Retour en haut

Posté 28 août 2011 - 13:53

#2
Millenium

Millenium

    Sunriseur PRIVILEGE

  • Shining VIP
  • 3 134 messages
  • Sexe:Male
sérieux ? c'est terrible :)
  • Retour en haut

Posté 28 août 2011 - 13:56

#3
_n3o_

_n3o_

    ▪■▄█▓▒░ Pixélisé ▒▓█▄■▪▪

  • Newser Expert
  • 3 291 messages
  • Sexe:Male
^^gg gligli
  • Retour en haut

Posté 28 août 2011 - 13:58

#4
pastoche

pastoche

    Sunriseur

  • Members
  • PipPip
  • 156 messages
  • Sexe:Male
  • Lieu:nantes
Super nouvelle
  • Retour en haut

Posté 28 août 2011 - 14:04

#5
Yoshee

Yoshee

    -= Serial Trocker =-

  • Modérateur
  • 3 654 messages
  • Sexe:Male
  • Lieu:Le Havre (76)
C'est quoi cette NEWS de fou ?
Mais là je suis sous le choc... Je reviens après pour être sur d'avoir bien lu XD
  • Retour en haut

Posté 28 août 2011 - 14:04

#6
M@DBoX

M@DBoX

    censored by Chuck Norris

  • Technicien LS expert
  • 4 795 messages
  • Sexe:Not Telling
  • Lieu:Impossible
Enorme !!!

xell reloaded sur slim mdr


GG GliGli ! B)
Ma Chaîne YouTube.
  • Retour en haut

Posté 28 août 2011 - 14:06

#7
Yoann-95

Yoann-95

    Yoann-95

  • Shining VIP
  • 5 947 messages
  • Sexe:Male
  • Lieu:IDF
JTAG Sur toutes console?
  • Retour en haut

Posté 28 août 2011 - 14:09

#8
artik

artik

    \0/ Shake it baby ! \0/

  • Administrateur
  • 9 889 messages
  • Sexe:Male

JTAG Sur toutes console?

Il y des chances !


heart.gifFlash de votre lecteur x360 (PARIS, RP, OU PAR LA POSTE) : heart.gif
tout lecteurs ! ** GARANTIE CONSERVEE ** samsung, hitachi, benq, liteOn - CLIQUEZ ICI
heart.gifcommentaires de gens qui ont fait appel à moi : heart.gif
http://cestvouslesbons.free.fr/gueux/page1.html
heart.gifLes meilleurs prix pour les abonnements au Xbox LIVE Gold : heart.gif
www.abonnement-xbox-live.com

  • Retour en haut

Posté 28 août 2011 - 14:10

#9
_n3o_

_n3o_

    ▪■▄█▓▒░ Pixélisé ▒▓█▄■▪▪

  • Newser Expert
  • 3 291 messages
  • Sexe:Male
c'est pas le JTAG c'est le glitch, et non pas sur xenon (c'est pas plus mal)
  • Retour en haut

Posté 28 août 2011 - 14:10

#10
liteon92

liteon92

    Sunriseur

  • Members
  • PipPip
  • 37 messages
Du renouveau pour le jtag ??

il paraissait mort depuis quelque temps enfin endormie pour énerver personne, ca va redonner un coup de fouet a la scène 360
  • Retour en haut

Posté 28 août 2011 - 14:11

#11
Cantique

Cantique

    Danseuse étoile ( rosette )

  • Administrateur
  • 5 611 messages
  • Sexe:Female
ENORME !!

ca c'est tout simplement terrible !! ca sent le jtag nouvelle génération cela !! dès que j'ai finis mon déménagement, jmen vais racheter une slim et tester ca!!
  • Retour en haut

Posté 28 août 2011 - 14:17

#12
guiguixbox360

guiguixbox360

    Sunriseur avancé

  • Members
  • PipPipPip
  • 508 messages
  • Sexe:Male
  • Lieu:France
En PU**** ! :O
Enorme même sur Slim, j'en reviens pas :crazy:
Bravo, un grand bravo pour son exploit ;)
( En + c'est un FRENCH :) )
  • Retour en haut

Posté 28 août 2011 - 14:18

#13
maxaille

maxaille

    Sunriseur

  • Members
  • PipPip
  • 135 messages
  • Sexe:Male
  • Lieu:Strasbourg
Il a Free il a tous compris :D
  • Retour en haut

Posté 28 août 2011 - 14:18

#14
patograso

patograso

    Sunriseur avancé

  • Technicien
  • 949 messages
  • Sexe:Male
  • Lieu:autun(71400)
  • Passions:flash xbox, modding consoles
putain les mecs pincez moi !

Non je ne rêve pas !!

je suis heureux, super boulot !

TO BE CONTINUED....
  • Retour en haut

Posté 28 août 2011 - 14:19

#15
milhouse08

milhouse08

    Fags VAG Owner

  • Shining VIP
  • 2 842 messages
  • Sexe:Male
  • Lieu:Charleville mézières - Lille
cela sent le retour du JTAG pour toutes les consoles!
un hack FRen plus :P
bravo en tout cas!

Flash xbox360 - pose xkey / wazabi dans le 08 et 59

  • Retour en haut

Posté 28 août 2011 - 14:19

#16
Champ

Champ

    Sunriseur

  • Members
  • PipPip
  • 156 messages
  • Sexe:Male
Pas mal :)

Mais j'y pense ,dans ce cas la , le x360key va devenir obsolète , non ? Si c'est le retour du JTAG , j'ai peur pour eux x)

Modifié par Champ, 28 août 2011 - 14:25.

  • Retour en haut

Posté 28 août 2011 - 14:26

#17
copel

copel

    Sunriseur avancé

  • Members
  • PipPipPip
  • 316 messages
  • Sexe:Male
  • Lieu:-76-
enorme ca !
Image IPB
  • Retour en haut

Posté 28 août 2011 - 14:26

#18
Keko

Keko

    Nouveau / peu actif

  • Members
  • Pip
  • 8 messages
Pourquoi c'est impossible sur les Xenons ? :/
  • Retour en haut

Posté 28 août 2011 - 14:27

#19
_n3o_

_n3o_

    ▪■▄█▓▒░ Pixélisé ▒▓█▄■▪▪

  • Newser Expert
  • 3 291 messages
  • Sexe:Male
c'est pas le jtaggggggggggggggggggggggggggggggggg
C'est le Gli(gli)tchhhhhhhhhhhhhhhhhhhhhhhhhhhhh
En soit la fonction est la meme mais le nom est different (le jtag utilisais la faille ... jtag :D, d'ou son nom)
  • Retour en haut

Posté 28 août 2011 - 14:29

#20
Guest_Guest_*

Guest_Guest_*
  • Guests
Oh purée, ca c est de la balle !! :)

La news de l année ......
  • Retour en haut




0 utilisateur(s) li(sen)t ce sujet

0 invité(s) et 0 utilisateur(s) anonyme(s)