Exploit Xbox 360 : Quelques Détails

[80Y]

lol moi j'en ai déjà 4, dont une limited simpson bref là n'est pas le sujet

j'attends d'en savoir plus pour filer au mag'

[Hack-Tarus]

lol moi j'en ai déjà 4, dont une limited simpson bref là n'est pas le sujet

j'attends d'en savoir plus pour filer au mag'

sur tes 4 ( bon la simpson on y touche pas, normal ) , elles sont tout maj et pas moyen d'utiliser cette faille ( euhhh cette probable faille qui verra le jour ... euhhhhh...????)?

[tedou]

le wiki de free60 ne fonctionne plus "microsoft"??

[jeux397]

le wiki de free60 ne fonctionne plus "microsoft"??

Fonctionne toujours pour moi !!!

[naruot_xbox]

je pense qu'il faut en acheter une sous peu, pour être sûr de ne pas se chopper la nouvelle maj

Voila pourquoi je m'en suis repris ... C'est histoire d'être tranquille ! Puis si le hack s'avere trop dur ba c'est pas grave elle serviront à autre chose

[80Y]

lol moi j'en ai déjà 4, dont une limited simpson bref là n'est pas le sujet

j'attends d'en savoir plus pour filer au mag'

sur tes 4 ( bon la simpson on y touche pas, normal ) , elles sont tout maj et pas moyen d'utiliser cette faille ( euhhh cette probable faille qui verra le jour ... euhhhhh...????)?

simpson > don't touch

demokit > don't touch

ma Elite > pour jouer

et j'ai une xenon sans lecteur kernel 6717 celle ci va servir de cobaye, mais je ne garantie pas la fiabilité

Modifié 14 août 2009 par 80Y

[MarilynSethKnot]

faire tout sa sans souder quoi ke se soit

il me semble pas , puisqu'il faut quand meme utiliser un programmateur pour acceder et injecter les données au moment precis de l'acces a la memoire , ne fusse qu'un connecteur sur un des emplacements presents sur la CM

Tant mieux, ça laissera du travail pour les bidouilleurs "pro"

Money, quand tu nous tiens

Surtout, ça évitera aux moins avertis de griller leur console... (pour je ne sais quelle raison).

Non pas que j'empêche les gens d'essayer (on a tous commencé par là).

Modifié 14 août 2009 par MarilynSethKnot

[jeux397]

Microsoft n'aura pas le choix, il vont devoir sortir une mise à jour payante pour avoir une xbox 360 débarrée !!!!!!!

Les pauvres, il sont sur le point de se faire hacker leur console en grande !!!

Bye

[Afterdie]

Oui mais faut dire qu'ils l'ont su bien avant nous...

[kogami]

Vivement plus d'info sur ce hack !!!

Modifié 15 août 2009 par kogami

[zouzzz]

T'en vlà : http://free60.cvs.sourceforge.net/viewvc/f...amp;view=markup

Source : http://www.xboxhacker.net/index.php?topic=...g79962#msg79962 / http://free60.cvs.sourceforge.net/viewvc/free60/imgbuild/

[Bono2007]

python build_image.py image_backup.bin input/C{B,D}.1920 input/4532_upd.bin \

input/xell-backup.bin input/xell-1c.bin input/smc_hacked.bin

ça va plaire à certains ça

[mamadoo]

Mais là c'est le début ou on a déjà des trucs qui tournent ?

Il faut quoi comme matos ?

Comment déterminer mon kernel ?

Satu!

[80Y]

T'en vlà : http://free60.cvs.sourceforge.net/viewvc/f...amp;view=markup

Source : http://www.xboxhacker.net/index.php?topic=...g79962#msg79962 / http://free60.cvs.sourceforge.net/viewvc/free60/imgbuild/

merci zouzzz pour les liens

Je comprends la moitié lol, on est encore loin d'une utilisation grand public et c'est normal

[tedou]

toute compte fait sa va pas etre donner a tous le monde j'ai l'impréssion

[Quentin67]

oui sa a pas l'air simple mais peut être que en français on trouvera sa plus simple

[Gab76]

toute compte fait sa va pas etre donner a tous le monde j'ai l'impréssion

montre moi où c'étais écrit que ce serait facile

et il y a des bricoleurs qui sont là pour ça, tout comme les poseurs de puces.

[-Zou-]

Moi j'ai surtout l'impression que certains se sont trop habitué (ou n'ont peut-être connu que ça) à des hack fait en 2 temps 3 mouvements ou à des softmod. C'est pas parce qu'on réussit à faire des softmod sur des ancienne console que d'office ça sera le cas sur les autre.

C'est clair qu'on aimerait tous que ça soit facile mais certains ne se rendent pas compte du niveau de sécurité et des contraintes techniques.

[kogami]

Ce que vous ne comprenais pas, c'est qu'en faite la 1er étape viens d'être franchis, à savoir lancer du code sur une 360 sans à avoir à signer les .xex (les .xex pour ce qui ne save pas corresponde au .exe dans le monde du PC)

De là il faut maintenant créer des outils pour la 360 !!! Du style un dashboard alternatif, un explorateur de fichier (genre de Explorateur Windows) créer un client FTP (pour ce connecter au disque dur de la 360)

Voilà, tout ca ne ce fais pas en 1 jour bien évidement, il faut laissé que la faille fasse son effet sur les programmeur enderground.

Les avancés vont venir au fur et à mesure, mais le plus gros pas à été franchis !!!

[jeux397]

Bonjour, voici une traduction de la méthode que j'ai traduit moi-même pour la partie qui nous intéresse, mais j'ai laisser Google faire pour la partie explicatif à la fin :

(MOI)

LE BUT

------

Il ya un nouveau hack qui permet de démarrer les codes homebrew en moins de 5 secondes. Voir

à la fin de ce document pour une description de la manière dont fonctionne le hack. Pour l'instant,

nous avons tous besoin de savoir, c'est que c'est une nouvelle façon d'exploiter le fameux noyau 4532,

d'une manière qui fonctionne comme sur la mise à jour des machines, sauf si elles ont été

mis à jour par la mise à jour de l'été'09. Il fonctionne également sur tous les types de matériel.

Ce document est une description technique destiné aux personnes qui veulent

comprendre le hack. Si vous ne comprenez pas un mot, du calme - il y aura probablement, dans l'avenir,

une releaes plus facile, etc howtos

S'il vous plaît également remarquer que, d'un côté fonctionnel, le résultat sera le même

que le KK-hack, il est juste plus rapide, fonctionne sur plus de matériel et est plus

fiable. Ainsi, il remplace le KK-hack, pas moins et pas plus.

Comment faire

-------------

Première des chose, il faut déterminer la version de notre Kernel. Ce pack

à été vérifié et il fonctionne pour les consoles ayant les mises à jours

inférieurs à 849x(été 2009).

Il faut déterminer votre type de console, à savoir si c'est une Xenon (no HDMI), Zephyr

(HDMI, mais 90nmCPU/80nm GPU), Falcon/Opus (60nm CPU) or Jasper (nouveau

Southbridge, 60nm GPU, 60nm CPU).

Vous aurez besoin de quelques fichiers, qui ne font pas partie de ce paquet. Nous sommes encore

à travailler sur les bon fichiers à avoir et le moyen juridiques pour obtenir ces fichiers, par exemple en

leur obtention à partir de fichiers que vous avez déjà (comme une sauvegarde de NAND).

Donc, vous aurez besoin .....

- Du "CB / CD pack". Il s'agit d'une partie du BOOT de démarrage, et vous avez besoin d'un

version spécifique pour votre type de matériel:

Xenon: 1921

Zephyr: 4558

Falcon: 5770

Jasper: 6712

(Surtout sur Xenon, vous pourriez être en mesure d'utiliser une version plus ancienne, aussi. Mais

les plus récents fonctionne dans tous les cas.)

- un code SMC hacké, *pour votre type de matériel*.

- un controller JTAG, ou un SMC hacké avec code JTAG.

- La Kernel 4532 extracté pour ainsi avoir le fichier xboxupd.bin

- Un outil pour les fichiers .bin qui permet de rechercher les chaines avec architecture ppc64.

- Une compilateur, comme XeLL

- La possibilité de reprogrammer la NAND flashée. Vous pouvez utiliser un programateur externe,

un programateur SPI, qui sera "releasé" sous peu, ou d'autres matériels qui seront déterminés,

si tel est le cas.

Construction de l'image

-------------------------

Afin de produire une image pour le HACK, nous avons besoin: (récapitulatif)

- un firmware SMC patché, qui démarre le CMD 07 "READ SECTOR(S) DMA" au

bon momment. Note que vous avez besoin d'utiliser le bon SMC, basé sur

votre matériel. Oui ils sont tous différents. Executer un pré-jasper code sur un

jasper-southbridge est particulièrement difficile à recouvrir. soyez prudent.

- un firmware micro-controller qui fait la meme chose qu'un JTAG, implanté dans le SMC patché

- une combinaison 2BL/4BL pour votre type de machine, avec la version 1920 ou plus.

- le 5BL (la base du kernel 1888), qui à toujours le même code binaire.

- le patch 4532 (or 4548), extrait du 4532/4548 system update. (mise à jour)

- un bloc de configuration SMC, qui enregistre quelques ennuyeux données SMC connexes.

- Notre "tampon" exploitable, qui est dans le noyau DMA'ed / HV

- le code que nous voulons utiliser...(XeLL, for example)

Le build_image.py peut construire une image flashrom si vous lui donner les bons

items.

example:

python build_image.py image_backup.bin input/C{B,D}.1920 input/4532_upd.bin \

input/xell-backup.bin input/xell-1c.bin input/smc_hacked.bin

où

- image_backup.bin est le contenu de votre NAND originale,

- C{B,D}.1920 est la combinaison 2BL/4BL, dans sa forme décrypté

- 4532_upd.bin est le xboxupd.bin de la mise à jour 4532 extractée,

- xell-1c.bin et xell-backup.bin sont XeLLs lié à 0x01c00000

- smc_hacked.bin est le SMC avec le gestionnaire rtc piraté lu (et éventuellement

aussi le jtag stuff)

Plusieurs parties de l'image sera générée dans le répertoire de sortie. Vous aurez

besoin de flasher tous cela, à la bonne position.

Flasher cette image dans la NAND XBOX 360. Inutile de dire de faire une mise à jour

en premier. Aussi, supprimez la résistance R6T3! Sinon, il y a un code qui peut brûler

les fusibles, et ainsi il est susceptibles de rendre inutilisables la machine. En supprimant

la R6T3, cela ne sera pas un problème. Ajouter les 3 résistances, si vous souhaitez utiliser

le SMC-fondé sur le JTAG hack.

Branchez un câble VGA, et mettre sous tension la XBOX 360. Si vous êtes accueilli par un écran

bleu, XeLL écran, félicitations, tout est parfait! "Have fun!"

SMC GPIOs

---------

Nous avons donc besoin de matériel qui utilise le JTAG pour définir la cible de l'adresse DMA

dans la séquence de démarrage, tant que JTAG fonctionne encore. Nous avons commencé à l'aide d'un

microcontrôleur externe, mais nous avons déjà un système de micro, le SMC! Il ya des restes de

GPIO ports, qui sont, au moins sur les carte mère Xenon, facilement accessibles sur la gauche.

Ils fonctionnent à 3.3V, D'où l'importance des résistance pour les résistance pour le 1,8 V

au niveau du GPU.

La Zephyr n'est pas aussi disponible pour le port GPIOs. Rassurez-vous, nous avons trouvé une

solution, là aussi.

Dans le cas où vous utilisez le piratage avec le SMC GPIO, s'il vous plaît utiliser 330 Ohm

de connecter les résistances

J1F1.3 --- [330R] --- J2D2.1

J1F1.4 --- [330R] --- J2D2.2

J1F1.5 --- [330R] --- J2D2.4

(Google)

Comment cela fonctionne?

-----------------------

Pour comprendre ce nouveau hack, d'abord regarder ce que fait l'exploit KK

Une erreur fatale dans le bug de l'hyperviseur syscall Handler, présenté dans la

mise à jour du noyau 4532 . Pour plus de détails, jetez un oeil à

http://www.securityfocus.com/archive/1/461489/30/0/threaded qui explique

le problème en détail.

Le KK exploite le noyau bugé et ainsi exploité par la modification d'une un shader non signé, à

faire une série de soi-disant d'exportation de mémoire. Ceci est une opération où le GPU peut

écrire les résultats d'un pixel ou vertex shader dans la mémoire physique. Le

shader a été écrit pour écraser le contexte Idle-fil pour faire passer le noyau à une certaine

position dans la mémoire, avec des registres dans le cadre de notre contrôle.

Afin de contrôler tous les registres, une deuxième étape était nécessaire, cette fois en sautant

dans le gestionnaire pour interrompre la restauration. Cela permet un usage générale du CPU afin

de remplir, au régistre, des valeurs déterminées. Le programme peut être restauré à une

instruction syscall dans le noyau, avec des valeurs pré-inscrire afin qu'ils déclenchent l'exploit.

L'exploit permet essentiellement de sauter dans une adresse 32-bit de l'hyperviseur.

Pour sauter dans un emplacement arbitraire, nous avons juste utilisé une "mtctr, bctr" qui peut

s'inscrire, soit la paire en hyperviseur, qui redirige l'exécution des flux tout en 64-bit

adresse. C'est important, car nous avons besoin de dégager la partie supérieure du 32 bits

(c'est-à-dire, fixer le MSB de désactiver le Hrmo), puisque le code que nous voulons passer, est

en fait la mémoire.

Ce code charge habituellement une deuxième phase de chargement, par exemple XeLL, en

la mémoire, et de le démarrer. XeLL alors tente de rattraper toutes les threads cpu

(parce que le premier fil est affectée par notre exploit), et de charger les

code d'utilisateur, par exemple à partir de DVD.

Ainsi, la mémoire suivants sont concernés:

- Idle Thread contexte, à 00130360 dans la mémoire physique

Ce pointeur de pile (et quelques autres trucs), lorsque le fil de ralenti

a été suspendue. En changeant le pointeur de pile, puis attente de la

noyau de passer au fil de ralenti, le pointeur de pile peut être mis en

notre contrôle. Une partie de l'interrupteur est également un contexte de restauration, sur la base de

le nouveau pointeur de pile.

- Contexte de restaurer, partie 1, emplacement arbitraire, KK expl. utilise 80130AF0

Le fil ne permet pas de restaurer tous les registres, mais nous nous le contrôle du PIN

( «la prochaine instruction" pointer). Nous configurons le PIN au point d'interrompre le

contexte de restauration, qui fait un SP-charge relative de la plupart des registres.

- Contexte de restaurer, partie 2, la base même endroit que la partie 1

Nous venons de ré-utiliser le même pointeur de pile, car les domaines où le premier

contexte de restauration et de l'interruption de la charge de rétablir ne se chevauchent pas.

Le deuxième contexte nous permet de rétablir la pré-établis avec tous les registres arbitraires

Valeurs de 64 bits.

- Le HV compenser, au 00002080 pour syscall 0x46 sur 4532

En raison de la HV bug, on peut écrire ce décalage, en fait la mémoire,

nous donnant la possibilité de sauter dans n'importe quel endroit dans l'espace hyperviseur

(c'est-à-dire avec une certaine «cryptage préfixe"). En général, nous écrivons ici 00000350,

qui pointe vers un "mtctr% r4; bctr" instruction paire hyperviseur, ce qui

nous permet de passer à r4%.

- Notre code de chargement, à un emplacement arbitraire

Ce code sera exécuté à partir de hyperviseur. C'est la première de notre code qui

sera exécuté. r4% sur l'entrée syscall est au point de ce code.

Seul le ralenti et le contexte du thread HV adresses fixes ont compensé.

Il est facilement possible de fusionner ce afin que seuls les deux blocs distincts à

être écrit en mémoire, mais il n'est pas possible de fusionner en une seule

bloc.

Heureusement, le contrôleur permet de faire lire la NAND DMA où la charge utile

données est séparé de la "ECC" données. Chaque page est de 512 octets de charge utile, et

16 octets de données ECC. Ainsi, une seule lecture DMA peut être utilisée pour charger tous les

adresses mémoires. Nous avons choisi de lire la charge utile, le Idle Thread

Contexte, le contexte et la restauration du chargeur de code. Les données portent ECC

la HV offset.

Pour une lecture DMA, la NAND registres doivent être écrits:

ea00c01c Adresse pour la charge utile

ea00c020 Adresss pour ECC

ea00c00c adresse dans NAND

ea00c008 commande: lire DMA (07)

Le Système de Management Controller (SMC) est un 8051 de base à l'intérieur de la

Southbridge. Il gère le pouvoir de séquençage, et est toujours actif lorsque le

Xbox 360 a (veille ou totale) de puissance appliquée. Il contrôle la face avant

boutons, a une horloge temps réel, décode IR, les contrôles des températures et des ventilateurs

DVDROM et le bac. Il parle de la face avant de fixer le bord de LEDs.

Lorsque le système est en cours d'exécution, le noyau peut communiquer avec le SMC, pour

exemple à la requête de l'horloge temps réel, ouvrir le tiroir-dvd etc Cela arrive

bidirectionnelle sur une FIFO (à ea001080 / ea001090). Voir le code XeLL SMC

pour plus de détails.

Le SMC peut lire la NAND, car elle nécessite l'accès à une page NAND

qui contient un bloc de configuration SMC. Ce bloc contient l'étalonnage

information pour l'isolation thermique des diodes, des objectifs et de la thermique etc 8051

base NAND a accès à des registres, qui sont mappées dans la SFRS 8051. Il

utilise le même protocole que le noyau les utilise, il écrit une adresse, un fait

"LIRE" de commande, puis lit les données sur les «données» des registres.

Il pourrait aussi faire un "READ (DMA)"-commande. Ainsi, en piratant le SMC, nous avons pu

faire de la boîte de faire l'exploit, sans shader - le SMC peut accéder à la NAND

contrôleur de tous les temps, même lorsque le noyau est en cours d'exécution (même si elle

susceptibles d'interférer avec le noyau). Ainsi, nous venons juste de déclencher la lecture DMA

lorsque le noyau a été chargé, et tout va bien.

Right?

Eh bien, ce serait trop facile. Alors que la plupart des registres sont mappés NAND, ils DMA

l'adresse des registres (1c, 20) ne le sont pas. Nous pouvons DMA, mais seulement à la valeur par défaut

l'adresse de zéro (ou le noyau DMAed en dernier). Fail.

Le GPU, le (H) ANA (le "Scaler" - qui, en fait, ne se classe pas du tout, c'est

"juste" un ensemble de CED, et, depuis le Zephyr, un adaptateur DVI / HDMI codeur), le

Southbridge et le CPU ont leurs ports JTAG exposés sur le plateau. Ils sont

têtes inhabitées, mais les signaux sont là. JTAG CPU est un autre

(complexe) l'histoire, et SB JTAG ne compense pas beaucoup funcationality. ANA est JTAG

ennuyeux car l'ANA ne pas s'asseoir sur une intéressante bus. Cela laisse GPU

JTAG.

GPU JTAG inverse a été conçu jusqu'à un point où l'écrit est arbitraire PCI

possible, jusqu'à un certain point. Alors que, il est possible de se parler

Périphérique PCI dans le système, y compris le contrôleur NAND. Ainsi, nous pouvons tout simplement

l'utiliser à la place de la SMC pour démarrer le DMA?

Right?

Eh bien, pas tout à fait. Le problème est que le "VM code", le code qui fait un

beaucoup de l'initialisation du système, comme la mémoire (ce code est également responsable

pour générer les 01xx "RROD" Errors), fixe un certain bit dans certains GPU

registre, ce qui désactive l'interface JTAG. Le code est exécuté VM manière

avant que le noyau est actif. C'est donc l'échec, aussi.

Mais la combinaison de travaux - par la programmation de l'adresse cible DMA via JTAG,

et de lancer l'attaque via SMC. L'attaque peut être lancée dès que le

noyau est en cours d'exécution, et très tôt, il interroger le SMC pour le CCF. Nous

l'abus de cet appel pour lancer l'attaque au lieu de cela, qui est un parfait point de

nous.

Mais comment pouvons-nous lancer un kernel exploitable à tous? La plupart des machines sont mises à jour

déjà. Permettez-moi de rafraîchir vos connaissances sur le processus de démarrage de nouveau:

1BL (bootrom)

Enfoui au plus profond de la CPU mourir, ce ~ 32kb du code de la ROM est chargé de

2BL de la lecture de la NAND flash et le déchiffre dans la SRAM intégrées dans le

CPU. Il vérifie le hash de l'image déchiffrée avec la signature d'un bloc à la

début de la 2BL, et arrêter l'exécution de cette inadéquation de hachage. Cet

code contient également un certain nombre de fonctions de test, qui peut être activé par

tirant sur la 5 "POST" EN-pins, qui sont disponibles sur le dos de la

PCB. Aucun de ces tests semble particulièrement intéressant (à partir d'une exploitation

perspective) - le plus souvent, ils semblent être liés à la FSB (l'autobus entre

CPU et GPU). Ce code est fixé, et tous les systèmes de code identique ici.

2BL ( "CB")

Ce code est généralement située à 0x8000 en flash NAND. Il est décrypté par 1BL,

et va de SRAM interne.

Il fait un matériel de base d'initialisation, et le "fusible code de vérification",

qui vérifie la 2BL version ". Les fusibles devrait enregistrer la version.

Les magasins 2BL une "version" et un "AllowedMask" (= BITFIELD), et

cela est généralement stocké à l'adresse 0x3B1 / 0x3B2 .. 0x3B3.

Xenon Zephyr Falcon Jasper

2 0003 1888, 1901, 1902

4 1920 "nouveau zeropair code"

5 0010 1921 4558 5760, 5761,5770 6712 TA-fixe

Il vérifie ensuite la liaison des informations stockées dans la tête 2BL. Partie de

cette vérification est un contrôle de vérification de la NAND zone qui a été utilisé pour

charger le code de la SMC.

Il contient aussi une machine virtuelle et une

l'exécution de code sur cette machine. Le code de la machine virtuelle, ce qui est assez

compliquée, ne les choses suivantes:

- Initialisation de la carte PCI-Pont

- Désactivez le GPU PCIE test port JTAG

- Initialiser le port série

- Parler à la SMC pour effacer la "poignée de main" bits

- Initialisation de la mémoire

- Je l'espère pas: RROD produire si la mémoire n'est pas init

Après cela, le commerce extérieur (512 Mo) de mémoire seront initialisées et utilisable. 2BL

décrypte ensuite le 4BL dans cette mémoire. Mémoire de cryptage sera déjà

permis - pas de code exécutable est * jamais * écrit en clair.

4BL ( "CD")

Ce code est responsable du contrôle et déballage 5BL, ainsi que l'application

mise à jour de correctifs. Tout d'abord, les fusibles sont lus pour déterminer la console "Mise à jour

Des séquences ", un numéro, qui compte essentiellement le nombre de mises à jour.

Depuis les mises à jour sont, au même titre que 2BL, associé à une console, ce qui permet

de configurer la console de manière à mettre à jour le vieux sera utilisé. Ainsi, chaque

mise à jour des créneaux horaires des magasins de la valeur maximale de brûlé fusibles (en fait, essentiellement la

valeur exacte). Le noyau de base a également une valeur associée, en général zéro,

mais cela peut être changé dans la liaison 2BL bloc de données. C'est ce que le

moment-attaque des augmentations, en vue de revenir à la 1888 noyau.

5BL ( "HT / noyau»)

La HV et du noyau sont fusionnées en une seule image, qui est compressé avec un

algorithme (LDIC).

6BL (CF), 7BL ( "CG")

Cela fait partie d'un système de mise à niveau. Chaque console dispose d'un soi-disant "Base

Noyau », qui est le noyau de 1888 qui était disponible au lancement en

2005. Ensuite, il ya deux "mise à jour de créneaux horaires" - les zones de chaque 64k (128k sur

Jasper), qui contiennent un 6BL et 7BL. 6BL est le code qui s'applique

mise à jour, en utilisant un astucieux delta-compression. 7BL est le delta-comprimé

mise à jour, qui est essentiellement un diff binaire.

Oh, des mises à jour> 64k. Alors que la première 64k sont effectivement stockées dans le

mise à jour de créneaux horaires, le reste est stocké dans le système de fichiers comme un fichier spécial. Depuis

6BL ne contient pas un analyseur de fichiers, un blockmap est ajoutée qui 6BL

points pour les secteurs qui contiennent le reste de la mise à jour.

Zero-Pairing

Maintenant il ya une situation particulière: si le bloc de liaison 2BL est de zéro, la

bloquer la liaison ne sera pas contrôlé. Toutefois, un bit est réglé de telle manière que le noyau

ne démarre pas le tableau de bord des binaires, mais seulement un binaire nommé

"MfgBootLauncher", où "Mfg" probablement synonyme de "fabrication". Ainsi, cette

est un vestige du processus de production, où le flash est utilisé sur l'image

tout le matériel, et aussi sans doute avant tout CPU-clé a été programmé.

Par abus de cette fonctionnalité, ce qui permet facilement de produire une image flash

qui fonctionne sur tous les matériels. Toutefois, 4BL ne sera pas à mettre à jour des créneaux où il

détecte ce mode, si nous nous retrouvons dans le noyau de base 1888. Et nous ne pouvons pas courir

le tableau de bord, il est donc impossible d'échapper à ce mode.

Auparavant, il a été jugé très inintéressant, parce que d'abord la 1888

n'est pas exploitable par l'exploit KK, et ensuite parce qu'il est impossible de

KK lancer le jeu quand même.

Toutefois, à partir de 2BL version 1920, s'est produit une chose intéressante:

La clé de chiffrement pour 4BL est généré à l'aide de la clé CPU maintenant.

Cela signifie que, sans la CPU-clés, il n'est pas possible de décrypter le 4BL

plus. Notez que chaque 2BL a exactement une seule valable 4BL binaire - 2BL

contient un éditeur de hash pour le 4BL, et ne pas utiliser RSA.

Toutefois, zero'ed liaison de données est détectée, le CPU-clé n'est pas utilisée dans le présent

processus, comme il l'était auparavant. Cela signifie également que vous ne pouvez pas zéro-out

la liaison de données plus - le 4BL sera décrypté avec la mauvaise clé

puis. En revanche, vous avez besoin pour déchiffrer le 4BL (qui nécessite de connaître les CPU

clé), et re-chiffrer avec l'ancien algorithme.

Toutefois, 1920 a été pour le moment suspecible attaque - pour un CPU-clé de récupération

a été possible sur une console, qui nous a permis de décrypter les années 1920 4BL. Que

4BL montre une évolution très intéressante: Chaque fois que la liaison zéro est détecté, le

mise à jour de créneaux horaires ne sont pas ignorées plus. En revanche, si la mise à jour des créneaux sont

zéro jumelé ainsi, ils sont appliqués.

Ce changement nous permet de démarrer n'importe quel noyau, à condition que nous avons un (1920 et plus)

2BL/4BL ensemble qui tourne sur cette machine. Cela est très important, parce que nous

peut construire une image qui se déroule maintenant dans le kernel 4532, quelle que soit la manière dont

mise à jour de nombreuses mèches sont fixées. Toutefois, le processus de révocation 2BL doit être

passé, nous ne sommes donc pas totalement indépendant de la fusibles, encore. Mais depuis

nous utilisons zéro le jumelage, la SMC n'est pas question de hachage plus (il ya d'autres

les moyens de contourner le problème de hachage SMC, comme l'AT, mais nous pour obtenir cette

gratuit). Cependant, nous MfgBootLauncher dans le démarrage (en maintenant la version 4532,

qui fait un rouge / vert clignotant thingie - vous remarquerez une fois que vous le voir,

il est tout à fait unique et ne ressemble à aucun RROD ou so). Mais grâce à la

SMC / JTAG hack ci-dessus, cela nous permet de lancer notre attaque de ce

état.

Les nouvelles consoles (qui ont la TA fixe) ne courent pas plus de 1920. Ils courent, pour

Ainsi, 1921. Le problème est que nous ne pouvez pas exécuter de code HV sur ces machines,

que nous ne connaissons pas le CPU clé. Toutefois, si l'on compare les 1921 et 1920 2BL

(dont on peut encore déchiffrer), le seul changement est l'ajout de la date

attaque fixe (c'est-à-dire le remplacement de deux memcmp cas d'une fonction memdiff).

Aussi, nous savons que les attendus de la valeur de hachage décryptée 4BL. Sur la base d'une 1920

4BL, et de la deviner ce qui a changé de fonctions, et la nouvelle taille de la

4BL, nous avons été capables de deviner les modifications, ce qui donne une image qui

passe le 2BL hash check. Notez que ce n'est pas une fonction de hachage de collision - nous l'avons fait

simplement tirer l'image exacte de l'application du 2BL changements entre 1920 et 1921

2BL en 1920 4BL, soit de 1921 4BL.

Le 1921 2BL théoriquement fonctionne sur toutes les machines à ce jour, même les TA-preuve.

Mais il s'écrase sur Zephyr, Falcon et de Jasper. La raison en est la VM code,

qui ne couvre pas les différents GPU (Xenon a 90nm GPU, Zephyr et

Falcon ont 80nm, 60nm Jasper a, il ya donc 3 révisions de GPU au total).

Mais l'étape de 1921 à, disons, 4558, est encore plus petit. C'est la

numéro de version différents, plus une légère différence dans les memcpy code, qui

peut être à nouveau portés depuis 2BL.

Jasper 67xx est une chose différente, puisque ce code ajoute le support pour la

largeblock flash utilisés dans les "Arcade"-Jasper unités. Nous avons utilisé le peu de magie pour

récupérer ce code.

Donc, nous avons maintenant TOUS 4BL versions. N'est-ce pas génial? Cela signifie que tous les

machines peuvent exécuter le noyau 4532. Les bonnes nouvelles sont que le noyau 4532

soutient faucon consoles, et tourne assez longtemps de travailler sur jasper

consoles (parce que nous exploitons bien avant les différents GPU est touchée à

tout).

Dépannage

---------------

Q: "L'alimentation est rouge quand le branchement de puissance!"

R: Vous avez court-circuité une broche d'alimentation, probablement V33_SB, l'un attaché à la NAND

flash. Attentivement pour les résidus de soudure. Utilisez un grand nombre de flux et un

bien chauffé fer à souder.

Q: "L'alimentation reste en jaune lorsque je presse le bouton d'alimentation, et rien

d'autre se passe. "

A: Le SMC code n'est pas valide. Ce peut être une misconnected flashrom, illégale

image, un mauvais flash ou tout simplement un mauvais code SMC.

Vérifier:

- Les connexions électriques en premier.

- Avez-vous avec le bon flash ECC paramètres? Le flash d'images, nous sommes

travailler avec des matières premières en général ECC information, c'est-à-dire 512 +16 octets par

secteur. Assurez-vous que votre programmeur de flash n'est pas de modifier ces 16

octets, mais écrit que ceux qu'ils sont.

- Avez-vous utilisé le droit SMC image?

Q: "Les fans de fonctionnement à plein régime immédiatement."

A: Cela est très probablement d'une mauvaise config SMC secteur. Avez-vous toutes les pièces flash

généré par l'outil de création d'images à la bonne position?

Notez que les compensations sont donnés à titre de charge utile des compensations, sans compter les octets ECC.

Habituellement, cette moyenne correspond à ce que votre NAND programmeur vous dira, mais en

Si vous ré-assemblé ces en une seule image, prendre soin de bien

convertir les décalages.

Q: «J'ai E79"

A: Cela signifie que, félicitations, votre console est encore de démarrer dans un

noyau, et ne peut pas aller plus loin (qui devait être exepcted, étant donné que

il n'y a pas de système de fichiers plus).

Vous y êtes presque, mais pour certaines raisons, la DMA attaque n'a pas été exécuté.

Cela peut être soit que vous n'avez pas utilisé un patché SMC, ou que la cible

l'adresse n'a pas été inséré correctement.

Q: "Console de pouvoirs, mais je reçois un écran noir."

A: Eh bien, il ya de nombreuses raisons ici. Tout d'abord, attendre un certain temps (~ 1

minute), et voyez si vous obtenez un RROD. Si vous le faites, le code n'a pas VM

poignée de main avec le SMC (code d'erreur XXXX), ce qui signifie habituellement qu'il

s'est écrasé, et le chien de garde SMC déclenché de nouveau jusqu'à ce que trop souvent.

Avez-vous d'utiliser la bonne image 2BL/4BL pour votre type de machine? Avez-vous utilisé une

SMC version assez récente? Depuis le VM code a pris de plus en plus de temps

(d'environ une demi-seconde en 1888 pour quelques secondes en 1920), la SMC

code a été modifié de temps plus tard. Assurez-vous d'utiliser un bon savoir-SMC

version, si possible, basé sur la version qui a été installé avant.

Si vous n'obtenez pas de RROD, s'il vous plaît essayer de vérifier votre code postal. Vous pouvez le faire

ce CPU via jtag, ou par la mesure de la POST 8 broches.

Code postal 6C:

L'exploit n'a pas, en quelque sorte.

Post code 10:

Notre code est en cours d'exécution! C'est super, mais il n'a pas copier le XeLL-charge

de flash. Essayez de démarrer dans l'autre chargeur (voir ci-dessous dans la

«exploiter loader" section), ou reflash.

Post code 11:

Exploit Code de course, et a sauté dans XeLL. XeLL s'est écrasé. Essayez d'autres

chargeur, ou upload de série pour la récupération, si vous en avez vraiment foutu à la fois les

primaire et secondaire chargeur. (Vous avez manqué, dans ce cas.)

Codes postaux> = 0x80:

Ce sont des erreurs du chargeur de démarrage. S'il vous plaît vérifier le démontage du

les chargeurs de voir ce qui ne va pas exactement. Il ne devrait pas se produire à moins que vous ne

ont un mauvais flash.

Code postal 0xA0:

Votre 2BL ne veut pas fonctionner sur votre matériel en raison de la révocation 2BL

fusibles. Utilisez une version plus récente 2BL/4BL ensemble de votre matériel. Si vous êtes déjà

fonctionnement (1921, 4558, 5770, 6712), alors vous n'êtes pas de chance. Votre boîte a été

déjà mis à jour à une nouvelle 2BL, ce qui devrait fixer ce que nous avons utilisés pour

exploiter. Restaurer R6T3, de restaurer l'image flash, et l'utilisation de cette console pour

jouer à des jeux. Obtenir une autre console, et essayez à nouveau.

S'il vous plaît noter que certains éléments matériels ne sont pas correctement initialisé à la

début du temps de l'exploiter. Cela affecte:

Processeur:

- Le processeur est initialisé en mode ", où elle fonctionne à un quart de la vitesse.

Réglage du mode de puissance CPU est bien sûr possible, mais doit être

la rétro-ingénierie de l'hyperviseur correspondant syscall.

GPU:

- Un écran de configuration est nécessaire, y compris la programmation de la

ANA-puce. Code est disponible pour la mise en place d'un mode VGA 640x480, support

pour d'autres résolutions, il convient d'ajouter.

- EDRAM doivent être "formés". C'est ce qui échoue lors de l'E-74 est l'erreur

s'affiche. Le code est assez complexe, et a été

reverse-enginnered, mais ne fonctionne pas encore correctement. Toutefois, il a été

montré à travailler un peu, et peut probablement être modifié pour fonctionner correctement.

SATA:

- SATA probablement besoin d'une certaine séquence de réinitialisation. Le noyau Linux ne présente bien, mais

XeLL ne fonctionne pas.

Toutes ces questions devraient être fixées.

Cette astuce peut aussi être utilisé pour le redémarrage de Microsoft dans un noyau, afin de garder la

possibilité de jouer à des jeux sur place. Ce n'est pas dans le champ d'application du présent

document, et est en fait pas lié à ce hack à tous. Cette astuce permet de

vous l'exécution d'un logiciel - et que vous décidez ce que le logiciel qui devrait être.

Il pourrait être linux, votre émulateur, ou une rebooter.

Notez que nous ne soutenons pas de patch pour le noyau de Microsoft contre le piratage

en toutes circonstances. Aussi, jouer sur le Live avec une console modifiée

ne sera pas possible sans être interdit, jamais. Il existe déjà

défis en place de détecter toute modification non autorisée. Nous vous demandons instamment de

à ne pas abuser de ce hack pour le piratage.

EXPLOIT LOADER

--------------

La première propre code qui est exécuté est un petit chargeur, qui opère dans

de la façon suivante:

- Si un personnage est présent sur le port série, il sera lu.

- Si ce n'est le caractère '@', nous allons entrer en mode de téléchargement de série.

- Si ce caractère est ', nous allons utiliser le chargeur de démarrage de sauvegarde

- Si pas de série le mode de téléchargement:

- POST 0x10

- Lire de démarrage de flash (ou de sauvegarde ou de la normale)

- POST 0x11

- Courir

- Le mode de téléchargement de série:

- Output '>'

- Recevoir des caractères

- Après 10 consécutifs' x ', arrêtez upload

- Output '! "

- Courir

Cela permet une sorte de récupération, si vous voulez mettre à jour l'en-flash

chargeur de démarrage.

Les adresses utilisées sont les suivantes:

FLASH_BASE est l'emplacement dans la flash de la sauvegarde d'amorçage,

FLASH_BASE + 0x40000 est l'emplacement du chargeur de démarrage principal,

CODE_BASE est l'adresse mémoire du chargeur de démarrage en mémoire.

Par défaut, la carte mémoire est utilisée:

00000000 .. 00100000: SMC, KV, CB, CD, CE, CF, CG, la sauvegarde de démarrage

00100000 .. 00140000: chargeur de démarrage principal

00140000 .. 00f7c000: espace vide

00f7c000: smc config bloc

00ffc000: exploiter tampon

Mais cela peut être tweaeked.

CREDITS:

Beaucoup. Tout d'abord, merci à vous tous qui ont travaillé sur Xbox 360

l'ingénierie inverse. Merci à toutes les personnes impliquées dans les discussions techniques

sur xboxhacker.net.

(dans l'ordre d'apparition)

récupération des CB1920 par robinsod,

JTAG initiale inverse enginneering par tmbinc,

se importants faits par SeventhSon,

première description de la manière dont il a travaillé par Martin_sw,

SMC JTAG code, beaucoup de tests et de débogage en Tiros,

Modifié 15 août 2009 par jeux397

[tedou]

quand il dit mise a jour été 2009 cela englobe le 8495,8496???

[-Zou-]

Oui

[tedou]

je laisse tomber j'y comprend plus rien une fois on me dit que les kernels 8495 et 8496 sa passe et que seul le 8498 pose probleme et le lendemain on me dit que c'est rapper

"RidLeY : De Tmbinc :

No, even if you know your CPU key, it's not possible to downgrade back from 8498."

il parle pas des version 8495,8496

Modifié 15 août 2009 par tedou

[kogami]

Moi ce que j'ai compris c'est que le kernel 8495 et 8496 est compatible avec la faille, mais par contre on ne pourra pas downgrader sa version, le kernel 8498 est lui complètement verrouillé pour tout modif sur la NAND (du moins pour la faille du loadboot)

[tedou]

et no downgrade=no homebrew c'est sa en faite??