Il n’est pas secret que je porte un attachement particulier à la Xbox 360 (vous pouvez en apprendre davantage sur ma relation avec elle dans ce post). Déverrouiller ces consoles a été essentiellement mon premier travail et source de revenus, me permettant de mettre continuellement à l’épreuve mes compétences au fer à souder. Démonter le boîtier, retirer les vis et “faire mon truc” était naturel. J’adorais ça. C’est une part très importante de ce qu’a été mon adolescence.
Puis, bien sûr, j’ai continué ma vie. J’ai commencé mes études à l’université, et je suis passé à d’autres opportunités de revenus qui nécessitaient moins de temps et d’effort, afin de me concentrer sur mes études.
Cependant, il y a une image de cette époque dont je me souviens particulièrement avec beaucoup d’affection :

XeLL Reloaded s’exécutant sur une Xbox 360
Voir cet écran signifiait plusieurs choses : que la console fonctionnait encore, que les points de soudure étaient parfaits (j’avais l’habitude d’être fier de la qualité de ma soudure), et plus important encore, j’étais à quelques secondes d’obtenir des informations cruciales pour détruire complètement les mécanismes de sécurité que Microsoft avait mis en place.
Voir cet écran était une constante quasi quotidienne, console après console, client après client. Un élixir de satisfaction.
Et bien, avec le temps, les innovations dans ce “petit monde” devenaient de plus en plus rares. S’il y a eu de grands jalons (par exemple le RGH 3 de 2021 par le grand 15432), il ne restait apparemment plus grand-chose à faire. Les consoles Winchester ont toujours été intouchables, mais elles ne m’intéressaient pas particulièrement. Les Trinity, à mon goût, représentaient Microsoft à son meilleur. À partir des modèles Corona, je les considère comme des réductions de coûts dans les processus de fabrication.
Le 3 mars, Grimdoomer est apparu avec Xbox360BadUpdate et a accompli ce qui semblait impossible : un exploit pour toutes les révisions de la Xbox 360 (y compris Winchester). Il ne nécessite qu’une clé USB, sans aucune soudure. De la génialité à l’état pur.
Bien que le mécanisme soit encore assez instable à ce jour, avec un taux de réussite relativement faible (et la communauté continue de recommander le RGH pour une bonne expérience), c’est un jalon que la communauté n’a pas ignoré.
Et cela a provoqué une vague de nostalgie. Et avec la nostalgie, viennent les idées. J’ai vu sur Reddit ce post présentant un XeLL modifié avec le logo d’Avenged Sevenfold, et je me suis dit : « Je suis ingénieur en informatique, maintenant je comprends des choses que je ne comprenais pas avant. Comment XeLL fonctionne-t-il réellement ? ». Et après à peine deux heures de jeu, j’avais déjà mon propre XeLL modifié.
« Et si je créais une application web pour que n’importe qui puisse faire cela ? »
Et bien sûr, je ne me suis pas arrêté là. XeLL est construit avec LibXenon comme bibliothèque de base, et cette dernière était assez dépassée concernant les composants qui la constituent. Je suis obsédé par la mise à jour des logiciels, et je ne pouvais pas laisser passer l’occasion de le faire.
Mettre à jour zlib, bzip2, freetype et libpng ? C’est fait. Mettre à jour newlib et binutils et renouveler les patchs nécessaires ? C’est fait. Mettre à jour GCC ?
Putain de GCC. Je ne peux pas mettre à jour GCC parce qu’à un moment donné ils ont introduit un changement qui, malgré la mise à jour des patchs nécessaires, faisait que XeLL ne se lançait pas (il se compilait, mais ne s’exécutait pas). Bien sûr, j’ai trouvé le problème : le commit 60bd3f2 a introduit flag_cunroll_grow_size et en désactivant cette “optimisation”, XeLL fonctionnait de nouveau. Évidemment, cela a pris une semaine de souffrance, compilant commit après commit pour dénicher la faille. Une fois le problème identifié, j’ai réussi à mettre à jour GCC en 13.3.0.
Et une fois cela fait, et après avoir intégré certaines améliorations de 15432 pour ajouter le support d’écriture sur consoles eMMC, j’ai pu commencer à développer l’application web pour XeLL. Et nous y voilà.
C’est un ensemble de pièces fonctionnant en harmonie : LibXenon et toute sa chaîne d’outils pour pouvoir construire XeLL, XeLL Customizer en tant qu’application web, et XeLL Customizer API comme intermédiaire entre l’application web et GitHub Actions pour déclencher des pipelines de compilation en fonction des paramètres que l’utilisateur a sélectionnés.

Avec mon obsession, j’ai bien sûr réussi à émuler l’aspect visuel de XeLL au niveau des marges et à utiliser exactement la même typographie que LibXenon fournit depuis des années (IBM VGA 8x16 pour les curieux). Une fois terminé, j’ai décidé de le publier sur Reddit dans ce post.
Il ne s’est pas écoulé 5 minutes avant que des utilisateurs trouvent des bugs auxquels je ne m’attendais pas naïvement. J’ai fait des correctifs temporaires, et après une nuit, j’avais déjà une version stable.
L’accueil de la communauté a été vraiment incroyable. Plus de 10 000 visites en moins de 24 heures, et plus de 130 compilations personnalisées générées. Des idées de la communauté qui sont véritablement utiles, et surtout, travailler avec des choses sur lesquelles des idoles comme Swizzy, 15432, Octal450, InvoxiPlayGames et d’autres ont travaillé, c’est une sensation que je ne peux pas décrire avec des mots. Je me sens comme un imposteur marchant parmi des géants.
Avoir apporté ma “pierre à l’édifice” à la scène Xbox 360 est quelque chose que je n’aurais jamais pensé faire. Et nous y voilà. Si vous voulez essayer XeLL Theme Customizer, allez-y ! J’espère que cela vous plaira.
©2022-2026 Sebastián Barrenechea. Tous droits réservés.
Construit avec Astro v5.16.11.