Le bannissement du XBOX Live

Il s’agit ici de rendre compte des tests effectués pour essayer
de contrer le bannissement du XBOX LIVE par Microsoft des consoles
XBOX 360. Ces tests ne sont pas toujours fructueux mais c’est ce
travail souterrain fait par des anonymes qui est intéressant de
raconter. Si ça aboutit tant mieux sinon tant pis, l’important
est de participer.

Le but des tests

Ce petit article a aussi pour but de montrer deux méthodes
susceptibles de pouvoir tromper les serveurs du XBOX Live.

Pour cela il a fallu un volontaire ayant à sa disposition
deux consoles (une bannie et une autre non bannie) sachant
souder et sachant sniffer (le réseau). Je vais remercier
ici la personne qui m’a servi de cobaye et à qui j’ai
envoyé une puce INFECTUS pour ses tests. Je remercie
aussi Birdy pour cette partie du test.

Hypothèse A : Ecoute du réseau

L’idée de la première hypothèse était de surveiller ce qui
se passe sur le réseau lors de la connexion aux XBOX Live
pour mieux comprendre ce qui se passe et éventuellement
trouver une solution. C’est d’ailleurs ainsi que la
Gamecube avait été hackée avec le jeu Phantasy Star
Online avec une faille dans le serveur de noms (DNS).

Il a suffit d’un PC équipé d’un logiciel d’analyse
réseau comme Wireshark http://www.wireshark.org
(anciennement Ethereal http://www.ethereal.com)
que l’on trouve en libre téléchargement sur le net
et de capturer les trames durant toute l’établissement
d’une session sur le XBOX LIVE.

Ce qui a montré pas mal d’espoir c’est qu’on a pu remarquer
que la console envoie en clair son ID, la version du noyau
(kernel), et l’adresse mac de la carte réseau.

Alors pourquoi ne pas remplacer l’ID avec un logiciel freeware
comme Ettercap http://ettercap.sourceforge.net/ qui autorise
ce genre de manipulation à l’aide d’un filtre ?

Si l’on tente de modifier les trames en remplaçant l’id de
la console bannie par une autre id on passe les premiers
barrages mais par la suite ça bloque un peu plus loin (test
effectué par Birdy).

En effet c’est crypté. Tout compte fait, mauvaise idée….

Hypothèse B : Copie du bios

Il s’agit ici de vérifier une hypothèse que j’avais émise
sur le forum de Metagames qui était de copier le bios d’une console
XBOX360 non bannie dans une autre console elle-même bannie. En
effet le firmware était logiquement un endroit rêvé pour stocker
une identification fiable de la console.

Comment faire ?

La bidouille du bios a été rendue possible grâce à la puce INFECTUS
et aux outils disponibles sur le site du fabricant http://www.infectus.biz
La puce INFECTUS est basée sur un composant ACTEL programmable à volonté
et qui peut se comporter comme une puce ou dans notre cas un programmateur.
Pour cela on utilise un outil nommé "NAND Programmer" disponible sur
leur site permettant de lire et d’écrire dans la mémoire flash de la
XBOX 360 via la puce INFECTUS (Infectus Programmer 0.0.3.4.D et Infectus
Tool 1.1).

Bien entendu l’opération n’est pas si innocente que cela et la manipulation
est délicate comme vous pouvez le voir sur ce site qui a été le premier
à diffuser une méthode pour lancer une distribution Linux sur la 360 :
http://mydedibox.fr/modules/smartsection/item.php?itemid=7
En effet le remplacement d’un bios n’est pas chose aisée et il
ne suffit pas que de souder une puce INFECTUS car Microsoft a
prévu une protection pour contrer le changement du bios : les
Efuses. Ce sont des composants qui sont « grillés » lors des
mises à jour un peu comme des fusibles (d’où le nom) et il est
impossible de revenir en arrière. Cette technologie provenant d‘IBM
est directement incluse dans le composant et le eFuse reroute les
infos un peu comme un aiguillage sur une voie ferrée. La console
de notre test a été downgradée en totalité car elle possédait un
kernel 4552. Avec cette version de kernel et de carte mère le
problème des Efuses ne se pose pas.

Une autre solution existe pour éviter d’utiliser une puce INFECTUS
c’est de récupérer le bios sur une console non bannie et HS de préférence
ayant un Ring of Death. Il faudra alors dessouder les composants à l’aide
d’une station air chaud ou pour les moins fortunés un pistolet à air chaud.
Evidemment avec la puce c'est beaucoup plus facile car une fois la NAND
dessoudée il faut ensuite la lire et l’écrire avec un programmateur/lecteur
spécifique…ce qui n’est pas à la portée de tous et de toute façon plus complexe.

Ca marche pas…

Avec le kernel 4552 il « suffisait » de dessouder une résistance
nommée « R6T3 » sur la carte mère de la console avant de faire un
upgrade pour empêcher que les eFuses « grillent ».Avec un tel bios
on pouvait lancer des codes non signés comme le fait le Xell Linux Loader.

A l’époque il y avait une faille dans l’« Hyperviseur ». Cet « Hyperviseur »
est encore une sécurité de la console, c’est en gros un système virtuel qui
tourne en permanence dans votre Xbox 360 et vérifie la sécurité de votre XBOX 360,
il adresse directement le hardware et peut interdire le boot de la console si
l’intégrité de la console est mise en cause.

Revenons au test. Malgré le downgrade la console est restée bannie du Live. C’est
raté mais tout espoir n’est pas perdu. Cela signifie que les données sont stockées
dans les Efuses.

Et alors ?

Une news a été diffusée il y a quelques temps sur Maxconsole.net et
elle est passée à peu près inaperçue ou diffusée sans analyse. Pourtant
elle va avoir des conséquences plus que positives sur le hack de la 360 et peut être
sur le « dé » bannissement.

Tmbinc et The Specialist ainsi que quelques membres du site
http://www.xboxhacker.net ont trouvé une méthode pour downgrader le
firmware (kernel) de la 360 même avec les eFuses grillés mais cela
nécessite une clef CPU cachée.

Sans entrer dans le détail la structure du bios de la 360 est connue
et chaque section identifiée et si la clef est découverte cela en est
fini de la protection de la 360, un peu comme la PSP. Rob ou RobinsonD
a réalisé un autre outil “Flash Dump Tool” qui permet de décrypter et
d'extraire diverses parties d'un dump de la mémoire flash. Avec ce programme,
il est possible de décomposer le kernel de base et les patches additifs.

Mais la principale information est que dans le processus d'upgrade certains
dumps d'une Xbox 360 en kernel version 4532 ont été upgradés en version
4548 ce qui est assez bizarre car en principe la version 4548 n'est pas
verrouillée contre le downgrade…Cela pourrait signifier qu’on ne peut
pas revenir en arrière avec un kernel 4548 endommagé ? De plus si l’on
compare les noyaux 4548 et 4552 il n’y a que 100 octets de différence
donc la protection est de faible taille.

On sait donc que les eFuses contiennent certaines données dont la clef
CPU qui est unique pour chaque console ("per-box-key"). Cette clef CPU
est utilisée pour le cryptage des données et l’identification de la console.
Un algorithme basé sur cette clé unique calcule la clé (keyvault) qui
crypte une partie du bios de la NAND, là où d'ailleurs est stockée la clef
du dvd-rom. Donc si la clef ne correspond pas au calcul fait à partir de
la clef unique par console, la 360 ne démarre pas.

Aujourd’hui la piste est ouverte et une fois la clef découverte c’en sera
fini de la protection et pourquoi pas de la clef du lecteur de DVD.

Quelles sont les pistes ?

Parmi les pistes possibles:

- Obtenir une clef d’une console de développement ou une console complète.
- Casser le cryptage et cela vaut aussi pour les liaisons réseau
- Intervenir électroniquement sur le composant

Cette solution nécessite un équipement complexe et coûteux disponible en
laboratoire ou dans une université. On connaît les composants Efuses :
ce sont des ibm9sf. Il existe une méthode pour lire les valeurs des Efuses.
Ca fait partie de la procédure de test à haute température que les puces
subissent en usine et certaines valeurs sont stockées dans le composant
lui-même hors de toute protection. Le plus complexe étant d’écrire ses valeurs.
Ou pourquoi pas de les remplacer ou d’intercepter les signaux. Je sens que
je vais lancer une collection de composants et retourner à la FAC…

De l’espoir ?

Aujourd’hui la seule solution pour essayer de se protéger du bannissement
est d’utiliser le firmware IXTREME mais uniquement en espérant que celui-ci
nous protège efficacement. Rien n’est fait aujourd’hui pour « dé » bannir
les consoles et c’est sur ce point que travaillent les hackers. Il est à noter
qu’une bonne dizaine de hackers parmi les plus connus travaillent sur ce sujet
et même ceux plus connus sur d’autres consoles. Cela laisse préjuger une avance
rapide dans ce domaine.

On est donc toujours dans les bios hackés avec par exemple Gary-OPA (http://www.o-p-a.ca/xsb/)
qui bosse la dessus et avec un peu de chance nous aurons sous peu une version
pour le lecteur BENQ.

A mon humble avis l’avenir passera forcément par la puce INFECTUS simplement
car elle est la seule solution simple actuelle permettant de lire/écrire dans
la NAND flash de la console. Les dernières news ne me contredisent pas et la
toute dernière méthode est d’effectuer un hack à base de la puce INFECTUS et
d’un lecteur de carte soudé sur la carte mère de la XBOX.

Robinsond a réussi à faire démarrer sa XBOX 360 avec un eFuse flashé et un
kernel 1888 en utilisant une méthode dite du “Time Attack” qui pourrait
permettre le lancement des homebrew et ouvrir la porte à Linux et au hack
par la même occasion. Bien sur avec ce vieux kernel votre 360 ne pourra plus
aller sur le LIVE qui n’accepte que la version 5766. D’ou l’utilité du lecteur
de carte qui permettra de lancer plusieurs version de kernel.

Pour faire fonctionner la méthode du Time Attack la Team INFECTUS travaille pour
insérer le code (PIC CODE) à l’intérieur de la puce. Pour cela une simple option
sera disponible dans le programmateur de la puce sous la forme d’un petit add-on, un
circuit complémentaire à la puce actuelle.

Conclusion

Au rythme ou vont les choses on est donc pas très loin du résultat et c’est encourageant…