SpaghettiKart est sorti en juin dernier et c’est le portage sur PC / Switch de Mario Kart 64, signé HarbourMasters. Si ce nom vous dit quelque chose, c’est normal car ce sont les mêmes qui ont porté Zelda Ocarina of Time avec Ship of Harkinian, Zelda Majora’s Mask avec 2Ship2Harkinian, et Star Fox 64 avec Starship . Quatre jeux N64 majeurs portés avec la même méthode, ce n’est plus du bricolage. Ils ont industrialisé le portage N64, je pense !

Et la clé, c’est libultraship . Il s’agit d’une lib qui d’éviter le gros du boulot technique pour porter des jeux N64 vers des plateformes modernes. Grâce à ça, chaque nouveau portage devient un projet de quelques mois au lieu de plusieurs années. Ship of Harkinian a défriché le terrain et maintenant, le pipeline est bien rodé.

Le fonctionnement de SpaghettiKart est simple. Vous lui fournissez votre ROM Mario Kart 64 US légale, vous générez un fichier O2R avec l’outil fourni, et vous lancez le jeu ! SpaghettiKart tourne sur Windows, Linux, macOS (pas de binaire dispo encore) et même Nintendo Switch. Comme les backends graphiques supportent DirectX11, OpenGL et Metal, c’est multiplateforme dès le départ.

Et les fonctionnalités sont celles que Nintendo devrait proposer mais ne propose pas comme le support ultrawide et 4K, une fréquence d’images élevées, de l’antialiasing, un niveau de détails poussé au mac et des contrôles personnalisables. Y’a même la possibilité de mettre vos assets customs et d’éditer des circuits donc autant dire que les moddeurs vont de régaler…etc. Bref, tout ce que Mario Kart 64 aurait dû devenir si Nintendo y avait mis 1 % de l’énergie qu’ils mettent à envoyer des DMCA .

L’expert en sécurité Lander, a passé des semaines à cracker le format .lin de Splinter Cell sur la Xbox originale. C’est un format de fichier qui est resté mystérieux pendant deux décennies et c’est pas parce qu’il était ultra-sécurisé ou chiffré de fou.

Non, c’est juste parce qu’il était optimisé pour du matos obsolète !

En effet, les fichiers .lin, c’est le format utilisé par la version Xbox de Splinter Cell pour stocker tous les assets du jeu. Ce sont des archives compressées en zlib contenant des packages Unreal Engine 2, sauf que contrairement aux formats classiques que vous pouvez ouvrir tranquille avec n’importe quel outil d’extraction, ceux-là résistaient à tout depuis +20 ans. Hé oui, durant toutes ces années, la communauté modding essayait de les décoder mais sans succès…

On pensait que le problème venait du chiffrement mais en fait, pas du tout ! Le problème c’est que ce format était juste conçu d’une manière totalement inadaptée aux outils modernes. C’est ce que Lander appelle dans son article un “non-seekable format with lazy loading and interleaved exports”. En gros, vous pouviez pas juste pointer sur un offset et lire le fichier car tout était entrelacé, chargé à la demande, et optimisé pour la RAM limitée de la Xbox originale.

Du coup, impossible d’utiliser les extracteurs classiques d’archives UE2. La seule solution qu’il restait c’était donc de comprendre exactement comment le jeu chargeait ces fichiers en mémoire sur la console d’origine.

Lander a alors sorti l’artillerie lourde. D’abord l’émulateur xemu pour faire tourner la Xbox sur PC et ensuite il a posé des breakpoints mémoire pour capturer le moment exact où le jeu charge un fichier .lin.

Il a ensuite sorti IDA Pro pour analyser le code assemblé du jeu et quand l’analyse statique suffisait plus, il a patché directement le binaire du jeu pour forcer certains comportements…

Et bien sûr, pour notre plus grand plaisir, il documente tout ça dans un article avec des captures d’écran d’IDA Pro et des explications sur les structures de données. Bref, c’est du bon gros reverse engineering pur et dur, à l’ancienne, avec hex editor et la patience d’un moine bouddhiste.

Lander a ainsi réussi à extraire une partie du contenu tels que les textures, certains fichiers système, des données sur les niveaux du jeu, mais surtout, il a documenté la structure complète du format. Et ça, c’est peut-être plus important que l’extraction elle-même, parce que dans 10 ans, quand un autre passionné voudra bosser sur la préservation de Splinter Cell Xbox, il aura la doc. Il comprendra pourquoi ce format était comme ça, comment ça fonctionnait, quelles étaient les contraintes hardware de l’époque et j’en passe…

Voilà, une fois encore la préservation du jeu vidéo, c’est pas juste télécharger des ROMs mais c’est aussi comprendre les architectures, documenter les formats propriétaires, et reverse engineerer le code avant que ce ne soit trop tard !

Bravo Lander !

TwoFace est un outil développé par Synacktiv qui permet de créer des binaires Linux ayant 2 comportements bien distincts. Un comportement parfaitement inoffensif qui s’active dans 99% des cas et un comportement malveillant qui ne se déclenche que sur une machine ciblée spécifiquement pour l’occasion.

Comme ça, votre sandbox verra toujours la version “propre” parce qu’elle n’aura pas le bon UUID de partition.

D’après la doc de Synacktiv, voici comment ça fonctionne : Vous avez deux binaires en fait… Y’en a un qui est inoffensif et un autre malveillant. TwoFace les fusionne alors en un seul exécutable. Ainsi, au moment du build, le binaire malveillant est chiffré avec une clé dérivée depuis l’UUID des partitions disque de la machine cible. Cet UUID est unique, difficile à deviner, et stable dans le temps ce qui est parfait pour identifier une machine spécifique.

Ensuite au lancement, quand le binaire s’exécute, il extrait l’UUID du disque de la machine. Pour ce faire, il utilise HKDF (Hash-based Key Derivation Function) pour générer une clé de déchiffrement depuis cet UUID et tente de déchiffrer le binaire malveillant caché. Si le déchiffrement réussit (parce que l’UUID match), il exécute le binaire malveillant. Par contre, si ça échoue (parce que l’UUID ne correspond pas), il exécute le binaire inoffensif.

Le projet est écrit en Rust et c’est open source ! Et c’est une belle démo (PoC) d’un problème que tous ceux qui font de l’analyse de binaires ont. En effet, d’ordinaire, pour révéler le vrai comportement d’un malware on l’exécute dans une sandbox et on peut ainsi observer en toute sécurité ce qu’il fait, les fichiers qu’il crées, les connexions réseau qu’il établit etc…

Mais avec TwoFace ça casse cette façon de faire. Et c’est pareil pour les antivirus qui verront toujours la version inoffensive tant que l’UUID ne correspond pas.

Techniquement, TwoFace utilise memfd_create() pour exécuter le binaire déchiffré en mémoire, sans toucher au disque, ce qui veut dire zéro trace sur le système de fichiers. Le binaire malveillant apparaît directement en RAM, s’exécute, puis disparaît. Et si vous utilisez io_uring pour l’écriture mémoire, il n’y a même pas de trace syscall visible via strace.

Et ça, c’est la version basique car le document de Synacktiv mentionne également d’autres techniques avancées possibles comme du déchiffrement dynamique page par page du binaire ELF, des mécanismes anti-debugging, des chained loaders multi-niveaux…etc…

Le parallèle avec la backdoor XZ Utils backdoor est très instructif car celle-ci a failli compromettre des millions de serveurs Linux parce qu’un seul mainteneur a poussé du code malveillant dans une lib compressée. Elle a alors été découverte parce qu’un dev a remarqué un ralentissement SSH bizarre et a creusé… Et TwoFace montre qu’on peut faire encore pire sans toucher à la supply chain.

Pas besoin de corrompre un mainteneur de projet, de pousser un commit suspect chez Github. Là suffit d’écrire du code parfaitement propre, de le compilez avec TwoFace pour une machine spécifique, et de le déployez. Le code source sera alors auditable ainsi que le binaire mais l’audit ne révèlera rien parce qu’il se fera dans un environnement qui n’aura pas le bon UUID.

Après, techniquement, une défense existe. Vous pouvez par exemple détecter les appels à memfd_create(), monitorer les exécutions en mémoire, tracer les déchiffrements crypto à la volée…etc., mais ça demande du monitoring profond, avec un coût performance non-négligeable. Et ça suppose aussi que vous savez ce que vous cherchez…

Bref, si ça vous intéresse, c’est dispo sur GitHub !

Accrochez-vous à vos paravoiles mes petits potes, parce que Nintendo vient de balancer les premières images officielles de son film The Legend of Zelda et c’est pas le cosplay de Link qui me plait le plus, non, non… C’est le nom juste à côté du générique : Sony Pictures.

Car laissez-moi vous expliquer pourquoi cette collab est probablement l’événement le plus dingue de l’histoire du jeu vidéo.

Mais bon, d’abord les faits !

Nintendo vient d’annoncer que le tournage avait démarré en Nouvelle-Zélande avec Benjamin Evan Ainsworth dans le rôle de Link et Bo Bragason dans celui de Zelda. Le film sortira le 7 mai 2027, soit quelques semaines avant que Macron ne modifie la constitution rester président à vie (j’rigole !!).

Miyamoto a donc posté un message tout gentil avec le compte de Nintendo sur Twitter (oui, ça énerve Musk qu’on continue à dire Twitter, donc vous pouvez compter sur moi) afin de dire que le tournage progresse bien et qu’on doit patienter encore un peu.

Mais revenons à ce qui m’intéresse vraiment : Nintendo + Sony ! Pour vous, ça sonne peut-être comme un partenariat banal, car après tout, Sony Pictures c’est juste la branche ciné de Sony, et pas la division PlayStation. Normal… Sauf que voilà, faut que je vous raconte une histoire.

On est en 1988 et Nintendo domine le marché du jeu vidéo avec sa NES et cherche un partenaire pour développer un lecteur CD pour sa future console. Sony se propose alors et pendant trois ans, les deux boîtes bossent ensemble sur un prototype baptisé PlayStation (oui, déjà ce nom-là). Tout roule jusqu’au jour où Nintendo plante Sony en public lors du Consumer Electronics Show de 1991 pour s’allier avec Philips à la place.

Idée de merde et surtout une humiliation totale pour Sony.

La réaction de ces derniers est alors historique !

“Ah ouais ? Bah si c’est comme ça, je vais faire ma propre console alors.”

Et c’est exactement ce qu’ils ont fait puisque la PlayStation sort en 1994, et devient la console la plus vendue de sa génération. Éclate alors une gueguerre qui durera 30 ans. Donc quand je vois “Produced by Nintendo and Sony Pictures” sur le film Zelda, je me dis que ces deux-là ont passé trois décennies à se tirer dessus à coups de consoles, de jeux exclusifs et de pubs agressives et maintenant, ils s’associent pour produire ce qui sera probablement le plus gros film de jeu vidéo de 2027 ! Et je trouve ça magique !

Comme des images du tournage ont leaké quelques jours avant l’annonce officielle, Nintendo a décidé de réagir rapidement en publiant les images officielles, histoire de reprendre le contrôle de sa com’. Voici donc les vraies images :

Le film est réalisé par Wes Ball, le gars derrière Maze Runner et Kingdom of the Planet of the Apes. C’est pas le choix le plus évident pour un Zelda, mais c’est pas idiot non plus quand on y réfléchit car il sait gérer l’action, l’émotion et les gros budgets. Et surtout, il tourne en Nouvelle-Zélande, le pays qui a transformé Le Seigneur des Anneaux en trilogie culte.

Les paysages d’Hyrule vont être magnifiques, ça c’est sûr ! (Bon, moins que s’il avait tourné en Auvergne mais quand même…)

Sony Pictures a l’expertise d’Hollywood, Nintendo a l’univers, les personnages, la vision créative, et surtout, ils ont compris après le succès incroyable du film Super Mario Bros qu’il y avait un paquet de fric à se faire dans l’adaptation de leurs licences au cinoche.

Je me suis amusé à faire ce petit fan-art à base d’IA.

Et ce choix de Benjamin Evan Ainsworth pour jouer Link est aussi intéressant… Il a 17 ans et vous l’avez peut-être vu dans The Haunting of Bly Manor (sur Netflix) . On va donc avoir droit à un Link très jeune, dans l’esprit d’Ocarina of Time ou Breath of the Wild, et en regardant les photos, je trouve aussi que les costumes ont l’air super fidèles aux jeux. Zelda porte sa robe bleue royale inspirée de BotW, et Link a sa tunique verte iconique. Bref, ils ont bien respecté le truc.

A voir maintenant ce que ça donnera mais pour cela, faudra attendre 2027.