Connexion Premium

Un hacker parvient enfin à pirater la Xbox One, 12 ans après son lancement

La question n'est pas si, mais quand

Un hacker parvient enfin à pirater la Xbox One, 12 ans après son lancement

Hack de la Xbox One par Markus Gaasedelen – capture d’écran

La Xbox One, réputée particulièrement bien sécurisée à son lancement, aura résisté treize ans aux assauts des pirates avant de rendre les armes : un hacker vient de présenter la méthode grâce à laquelle il a réussi à faire exécuter le code de son choix au niveau du composant chargé du démarrage, en dépit des innombrables protections déployées. La vulnérabilité qu’il exploite est en théorie impossible à corriger, mais elle suppose une action matérielle sur la console.

Le 17 mars à 10h57

La lutte contre le piratage a toujours été un enjeu crucial pour les fabricants de console, à plus forte raison quand ils sont également éditeurs de jeux vidéo. Et sur ce terrain, Microsoft a mis les bouchées doubles, particulièrement à partir de la Xbox 360. Lancée en 2005, celle-ci inaugurait un hyperviseur chargé d’empêcher l’exécution de code non signé.

Bien que ses défenses aient fini par tomber, la console a pendant vingt ans exigé une modification matérielle (ajout d’une puce dédiée) pour obtenir le fameux « jailbreak », qui permet d’outrepasser les limitations implantées par le constructeur (pour, par exemple, faire tourner des homebrews). Il a ensuite fallu attendre 2025 pour qu’un exploit logiciel surnommé Bad Update (hébergé sur Github) permette de prendre le contrôle au moyen d’une clé USB.

Entre temps, la Xbox One a remplacé la 360 dans le salon des joueurs, et Microsoft pouvait jusqu’ici se targuer d’une console à la sécurité inviolée. Bien qu’un certain nombre de manipulations dépassant le périmètre prévu par le constructeur aient été mises au jour pendant les douze années d’existence de la console, le hack ultime, celui qui donne le plein contrôle, échappait encore aux cyber crocheteurs.

La donne a changé grâce à Markus Gaasedelen, chercheur en cybersécurité : le 13 mars dernier, il a dévoilé lors de la conférence RE//verse 2026 la méthode matérielle grâce à laquelle, avec beaucoup d’obstination et un peu de chance, il a réussi à finalement pirater la console en réussissant à exécuter du code au niveau de la séquence de démarrage, avant même que l’hyperviseur ne s’enclenche. L’équivalent d’un « god mode », affirme-t-il, puisque le fait de casser la toute première des protections permet d’invalider toutes les suivantes. Cerise sur le gâteau, la vulnérabilité ne peut a priori pas être corrigée de façon logicielle, puisque le boot ROM de la console est immuable.

Un boot ROM conçu comme une « forteresse »

Côté logiciel, il aboutit à la conclusion que le code du boot ROM est « simple, linéaire et bien relu ». Autrement dit, il serait donc virtuellement inviolable, ce qui ne laisse qu’une possibilité : passer à une attaque matérielle. Pour ce faire, Gaasedelen s’intéresse en premier lieu à la méthode dite du Reset Glitch Hack, précisément celle par laquelle la Xbox 360 a pour la première fois été pleinement piratée en 2011, par un hacker français, GliGli.

La technique en question consiste à envoyer de très brèves impulsions électriques au processeur pour corrompre l’exécution d’une instruction et ainsi obtenir une modification du comportement attendu. Si elle était relativement simple à mettre en oeuvre sur Xbox 360, la donne est différente sur la Xbox One, dont le boot ROM a été conçu comme une « forteresse », estime le chercheur. Dans sa présentation, il explique notamment que Microsoft a verrouillé tous les accès qui permettaient soit de mesurer l’état d’avancement du processus ou d’obtenir les codes de diagnostic, soit de ralentir la séquence, pour mieux déterminer l’instruction à cibler.

La mise en oeuvre du Bliss hack n’est pas exactement triviale – capture d’écran

Faute de savoir où et quand interférer avec le chargement du boot ROM, Markus Gaasedelen explique donc avoir dû avancer à tâtons. Ses travaux l’ont notamment conduit à se connecter aux ports GPIO de la carte mère pour observer le comportement des différents rails d’alimentation lors de la séquence de démarrage. En introduisant des baisses de tensions ponctuelles au niveau de l’alimentation du northbridge, il découvre qu’il est possible de réactiver les POST codes qui documentent la séquence d’amorçage du système. De là, il parvient à remonter petit à petit les différentes étapes du démarrage, et notamment la façon dont ce dernier est sécurisé par le coprocesseur dédié à la sécurité de la console.

Glitch sur glitch

L’APU de la Xbox One, fourni pour mémoire par AMD, intègre en effet un PSP (Platform Security Processor), chargé de verrouiller l’ensemble des opérations sensibles, qu’il s’agisse du boot, du chiffrement, de la gestion des DRM au sein des jeux, ou de l’authentification auprès des serveurs du Xbox Live. Le fonctionnement de ce dernier (qui a plus tard présidé à la conception de la technologie de sécurité Microsoft Pluton) avait été présenté en détails par Tony Chen, architecte de la sécurité de la Xbox, lors d’une conférence organisée à Redmond en 2019. Il soulignait à l’époque que le système ne souffrait que d’une seule porte d’entrée potentielle : son boot ROM.

En 2019, Tony Chen présente les missions du PSP de la Xbox One – capture d’écran

Force est de constater que Microsoft avait bien fait les choses. Au fil de sa présentation, Markus Gaasedelen égraine les protections rencontrées sur son chemin, entre fusibles électroniques (efuse) et décrochages randomisés du signal électrique. Après plusieurs semaines d’efforts, il finit toutefois par parvenir à ses fins, en utilisant non pas un, mais deux glitchs successifs. Le premier neutralise le MPU (Memory Protection Unit), composant chargé d’isoler certaines zones mémoire (jails) en cas d’action non conforme. Le second profite de la brèche ainsi ouverte pour faire passer en mémoire un pan de code personnalisé à la place du SP1 header en interférant avec une instruction memcopy. La combinaison des deux finit par donner le contrôle sur la machine.

Baptisé « Bliss hack », le procédé n’a rien de trivial. Le chercheur explique ainsi avoir dû procéder à des milliers de redémarrages automatisés pour réussir à appliquer chacun de ces deux glitchs au bon moment, l’échelle d’action étant de l’ordre de la nanoseconde.

Glitch sur glitch, Markus Gaasedelen résume le hack Bliss qui lui a permis d’obtenir les droits complets sur une Xbox One – capture d’écran

Quel impact ?

Markus Gaasedelen souligne que sa découverte n’est valable que pour la première version de la Xbox One (console dite « fat »), mais estime qu’il est probablement possible d’adapter sa méthode pour déverrouiller les modèles produits les années suivantes. Il se montre en revanche plus circonspect concernant les Xbox One S et Xbox One X, commercialisées à partir de 2016, dont la sécurité aurait encore progressé d’un cran, et précise ne pas avoir étudié la configuration des versions sorties après 2020.

Concernant la Xbox One première du nom, il conclut que son Bliss hack ouvre théoriquement la voie à un modchip, c’est-à-dire un piratage standardisé grâce à l’ajout d’une puce matérielle sur la console, mais explique se désintéresser du sujet.

Commentaires (11)

votre avatar
Merci pour l'article.
Ça me donne l'impression qu'on arrive vers une ère où les systèmes seront tellement bien sécurisés qu'ils seront inviolables (que ce soit à coût acceptable, ou absolument), même matériellement.
Je me demande si je dois m'en réjouir ou pas.
votre avatar
C'est jamais inviolable (la preuve via ces glitch) mais ca peux tenir suffisamment longtemps pour que le hack ne soit plus un danger économique.

Pour moi la vrai question c'est pour l'abandon du matériel (ce qui n'est pas le cas ici , la Xbox One est toujours supportée , non ? J'avoue que je ne sais pas):
Beaucoup de matériel , surtout informatique est obsolète très vite, supplanté par la génération N+1.
Or déjà que bcp de matériel cassé fini à la déchetterie, avec ces protections on en arrive à une situation où du matériel fonctionnel est jeté simplement par obsolescence logicielle.

Aujourd'hui déjà le hack est pas toujours simple mais si demain en plus il y a des DRM sur le boot, ben là si la société ne file pas la clé c'est fichu. Et quid si la société arrête le produit, si elle a sous-traité la réalisation et n'est même pas consciente du problème, si la personne qui a la clé est passé sous un bus... bref.
Combien de véhicules actuellement roulent avec leur GPS de bord obsolète alors qu'un passage en opensource aiderais...

Ca pour moi c'est vraiment grave.
votre avatar
Ces glitches sont généralement des side channels sur l'alimentation.
Je connais une puce qui en est victime.
Ça a pris 2-2.5 générations mais le constructeur bosse sur une version qui mesure l'alimentation pour permettre de déclencher des actions en cas d'injection de faute.
A voir la fiabilité du résultat.
votre avatar
Ca ne veut rien dire, tout est ouvrable ce n'est qu'une question d'argent. Les puces TPM et tout ce genre de chose peuvent être analysés matériellement mais il faut une expertise et du matériel qui ne sont ni abordables financièrement ni facilement accessibles.
Si on avait mis une boite spécialisée ou une agence type ANSSI (pas sûr du tout que ce soit dans ses missions) la durée aurait été certainement été plus courte.
votre avatar
La question que je me pose, c'est : est-ce vraiment toujours ouvrable, ou est-ce qu'il est possible, qu'un jour, un système ne le soit plus du tout ?
votre avatar
Même question que toi, c'est potentiellement une question d'échelle... Attaquer une puce 45 nm et une puce 2 nm ne doit pas requérir le même matériel. Quid de l'empilement de couches avec par exemple 3 couches superposées ?
votre avatar
Il faut demander aux sachants américains et tawainais mais probablement quand on sait que les US utilisent des puces avec une litho jusqu'à 5nm pour du matériel militaire type radar ou défense AA et donc qu'ils font tout pour les protéger contre le reverse.
votre avatar
C'est toujours une course, généralement plus un marathon, mais ça finit par tomber pour des raisons d'évolution technologique, des outils qui n'existaient pas avant sont arrivés pour simplifier le hack, que ce soit matériel et/ou logiciel.

La "sécurité absolue" n'existe pas, la seule chose c'est de rendre les choses trop longues pour que ce soit interressant.
votre avatar
Hacker vaillant, rien d'impossible !
votre avatar
Ah, ces fameux codes sortant un "compteur" hexa 8 bits sur un afficheur à 2 digits qu'on trouve encore sur les cartes d'évaluation Intel et sans doute aussi AMD... La précaution de couper par défaut cette sortie d'information fut prise, sans doute via un simple flag, mais il eu mieux valu que le code utilisé ne soit carrément pas dans le build release du BIOS de la console.

C'est tout con, mais mine de rien cela fonctionne dès la sortie de reset et sans aucune initialisation requise (un simple uart en requiert un peu + espace adressage IO indépendant du reste sur x86). C'est un peu l'idée des qq leds d'état qu'on trouve encore sur certaines SBC, mais avec la capacité d'en sortir 256 de manière condensée avec une unique instruction.
votre avatar
Le mec qui balance juste comme ça "J'ai créé un émulateur de la Boot ROM avec de l'IA pour l'étudier" et plus tard "J'ai un montage en place pour diffuser en direct une compromission depuis mon appartement, ce que j'aurais exploité si j'étais certain que cela pouvait durer une minute ou deux".
Pépouse.

Belle prouesse de partir de pas grand chose, et d'arriver à… ça.
Petite pensée pour toute la partie complexe gérant les clés, qui arrive juste après. :mdr:

Inspirant, mais aussi flippant de sagacité & capacité, le monsieur. :stress: