- guiguixbox360 aime ceci
- LS forums
- → Affichage d'un profil : Aime: Razkar
Statistiques de la communauté
- Groupe Shining VIP
- Messages 6 098
- Visites sur le profil 89 273
- Titre HomeBrew Lover
- Âge Âge inconnu
- Anniversaire Avril 26
-
Sexe
Homme
#354736 ??? FAQ Reset Glitch Hack ???
Posté par Razkar
- 21 septembre 2011 - 20:36
#354734 ??? FAQ Reset Glitch Hack ???
Posté par Razkar
- 21 septembre 2011 - 20:34
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.
* 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.
?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 des tutoriels complet pour la réalisation du Hack:
Général
Special puces Glitchip
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.
- guiguixbox360 aime ceci
#353760 Le point sur le lancement du NXE avec le Reset Glitch Hack
Posté par Razkar
- 20 septembre 2011 - 12:02
C'est exactement ca !Merci pour cette news bien complète. Si j'ai bien compris, lancer un kernel hacké via le Glitch Hack est à la portée des devs (et ils l'ont peut être déjà fais). Mais, aucun pour le moment ne veut être le premier à publier ça et ils respectent le travail de Gligli qui ne veut pas de piratage.
- Pilip75 aime ceci
#351270 Matrix Glitcher 360 : les stocks sont disponibles à la vente sur le LSstore
Posté par Razkar
- 15 septembre 2011 - 15:40
My name is Razkar and i approve this messageEt si avant d'acheter, on attendais au moins la sortie du module de SoulHeaven ???C'est un membre du forum, il est francais, et on a un support sur le forum...Dommage d'acheter a une compagnie qui vendra partout dans le monde, au lieu de preferer un membre respectable.Soutenons SoulHeaven

- skillz aime ceci
#350602 Les samples des X360Glitchip bientôt chez les testeurs *maj : vidéos*
Posté par Razkar
- 14 septembre 2011 - 07:19
Par contre sur FAT c'est normale que le code s'exécute plus rapide, le success rate se rapproche plus des 50% et le code met -30sec pour s'exécuter (généralement - de10sec).
Mais effectivement sur Slim le code s'executera plus vite que sur d'autre puce ... il est fort notre Soul =)
- Mikabox aime ceci
#343658 POC of Tank360 by JQE : un petit homebrew libXenon
Posté par Razkar
- 31 août 2011 - 22:45
Salut Ski||eR,Dans la ligné de mon Pong 360 sortie à l'époque :
http://www.xboxhacke...p?topic=12707.0
Qu'on peut d'ailleurs trouver sur le forum de libxenon
Je releaserais les sources quand j'aurais un moment, comme je me sers de la SDL, à but éducatif sa peut être intéressant, même si c'est pas grand chose.
Bien vue JQE
Ouai ce serai super sympa si tu pouvais poster les sources de ton petit homebrew sur libxenon.org ca pourra servir d'exemple pour ceux qui voudrais s'y mettre.
- Télémaque aime ceci
#340091 Le LT+1.92 pour LiteOn Slim est passé en phase de test
Posté par Razkar
- 25 août 2011 - 23:21
C'est moi qui est supprimé ton post sur le forum. Si tu veux poster une news il faut le faire depuis le site => http://www.logic-sun...actualites.htmlJe peux savoir pourquoi mon Post annonçant la nouvelle a été effacé et celui là a été crée ?
C'est vraiment n'importe quoi, je n'ai rien à foutre du fait de qui post le premier ! mais puisque c'est fait, je ne vois pas pourquoi l'éffacer pour en créer un autre, juste pour dire que c'est moi lannonceur peut être.
- Télémaque aime ceci
#338625 JTAG vs X360Key
Posté par Razkar
- 23 août 2011 - 16:25
Le XGD3 c'est pas du tout du triple couche, c'est une nouvelle architecture du DVD qui permet de graver plus de donner sur le disque (tu gagnes 1Go en gros). Tu pourras les graver normal quand Xbox Backup Creator sera mis à jour (il l'ai dejà mais developpé à partir du beta Halo Reach donc on redline att la sortie du vrai 1er jeux). Tu crois ton lecteur DVD de xenon de 2006 il va lire les Triple couche comme ca ... par magie sans le hardware qui va derrière
Les jtag c'est chère, mais c'est toujours ca quand tu viens apres la bataille quand elles sont sorti ... ba ca coutait rien (99 la jasper 512 à auchan) ... puis aujourd'hui une Jasper Jtag Neuve ca reste moins chère qu'une PS3 neuve donc bon chère c'est relatif je trouve ^^. Et les jtag ca lance tous et ca lancera toujours tout ...
Après faut pas rever non plus, les Xkey utilise en partie le FW hacké de C4E pour la partie lecture des ISO de l'émulation du lecteur donc l'avenir du x360key passe et passera par C4E et ses FW ...
#335246 Des images du futur DashBoard de Microsoft leakées sur la toile
Posté par Razkar
- 16 août 2011 - 23:07
- chemi et Heydex-Lyon aiment ceci
#331544 LetterBomb : Le nouvel exploit Wii sans jeu disponible *MAJ*
Posté par Razkar
- 10 août 2011 - 17:43
Tsss qu'est ce qui faut pas lire ....Mais aujourd'hui c'est la Team Twiizers qui lui vole la vedette en releasant avant lui l'exploit fonctionnel qui pour le coup a changé de nom et devient Letterbomb.
Les beaux enculés.
Giantpune a fait une demande de donation pour releaser son travail ... donc les mec qui ont vraiment l'esprit de la scene libre et du partage ont refait l'exploit en version free.... et ils ont completement raison
ca sert a rien de trouver des exploit si c'est pour les vendres
Fuck la cashscene
- Chakipik aime ceci
#331438 Recherche un testeur pour Trident MX
Posté par Razkar
- 10 août 2011 - 14:34
- nounours_59, Manethon et zoontek aiment ceci
#318320 Les firmware LT 1.9 des lecteurs 0272, 0225 et 0401 sont-ils prêt ?
Posté par Razkar
- 17 juillet 2011 - 21:03
- LS forums
- → Affichage d'un profil : Aime: Razkar
- Privacy Policy