Plus de 4 000 commits, 5 ans de décompilation acharnée, et selon l'équipe ZeldaRET le plus gros projet de reverse-engineering jamais bouclé sur un jeu Nintendo. Voilà tout ce qu'il a fallu à la team Twilit Realm pour livrer Dusk, leur portage natif de Zelda Twilight Princess sur Windows, macOS, Linux, iOS et même Android.

La sortie officielle a eu lieu samedi dernier, et le projet fait son petit effet dans la communauté retrogaming.

Link traverse les plateformes dans Dusk (capture du site officiel )

Pour faire fonctionner le jeu, vous devez récupérer le binaire Dusk sur GitHub , puis lui fournir votre propre dump du jeu GameCube car la team ne distribue aucun asset de Nintendo pour limiter le risque juridique... Après je vous fais confiance pour en trouver tombé du camion... ^^.

Et hop, en moins de temps qu'il n'en faut pour le dire, vous vous retrouvez à jouer à Twilight Princess sur votre Steam Deck, votre iPhone, votre laptop M3, votre tour Linux ARM64, peu importe... Tout ça sans émulateur Dolphin puisque le code GameCube a été reverse-engineered au niveau machine puis recompilé pour le matériel moderne, ce qui donne un vrai portage natif avec les avantages habituels : framerate déverrouillé, résolutions HD, modding facilité, performances qui dépotent (sous réserve d'un GPU compatible D3D12, Vulkan ou Metal, les vieux iGPU Intel et certains Adreno galèrent encore).

Le moteur du jeu original tournait à 30 refresh par seconde (en anglais on dit "ticks", c'est le nombre de fois où le moteur rafraîchit / recalcule la 3D du jeu) , c'est-à-dire que la simulation du monde se mettait à jour 30 fois par seconde, point final. La team a gardé ce taux à l'identique pour préserver le comportement de simulation proche de l'original, ce qui rassure surtout les speedrunners.

Sauf que maintenant, le rendu visuel, lui, peut tourner à 144 Hz ou plus. Donc entre deux refresh, Dusk calcule où devraient se trouver les objets et interpole leur position pour produire une image fluide. Vous gardez ainsi la mécanique de 2006, mais l'affichage est de 2026, donc c'est spleennnndiiiiide ! C'est une approche comparable à celle de Ship of Harkinian sur Ocarina of Time.

Côté plateformes, c'est pour Windows x86-64, macOS Intel et Apple Silicon, Linux x86-64 et ARM64, iOS via AltStore et Android en APK direct. Pas de version Switch par contre, et n'ayez pas d'espoir car l'équipe a été claire sur le sujet. Pour des raisons techniques (et j'imagine juridiques) ils n'envisagent pas de port natif sur la console actuelle. Les versions Wii et les autres régions GameCube sont également en chantier, mais pour l'instant ce sont les versions GameCube USA et EUR qui sont supportées. Le projet vérifie même le hash SHA-1 de votre dump pour s'assurer qu'il correspond à une version compatible avant de lancer quoi que ce soit.

Link en wolf enchaîné dans le donjon initial (capture du site officiel )

L'ensemble est sous licence CC0, domaine public, zéro restriction, ce qui veut dire que vous pouvez forker, modifier, redistribuer le code sans contrainte. Le projet repose sur la décompilation zeldaret/tp , menée depuis août 2020 par une communauté internationale de speedrunners et de devs reverse-engineers.

C'est le même schéma juridique qui a permis à Zelda 64 Recompilé de prospérer. Les projets évitent de distribuer des assets Nintendo, mais ça ne supprime pas tout risque de notification DMCA puisque la légalité dépend aussi de votre juridiction et de la manière dont le dump a été obtenu (DMCA section 1201 aux US, qui interdit en principe le contournement de protection, donc la prudence reste de mise).

Maintenant, faut pas se voiler la face sur le destinataire d'une lettre recommandée potentielle puisque Nintendo a fait sauter yuzu et son fork Suyu en 2024 avec 2,4 millions de dollars de règlement à la clé, Ryujinx a mis la clé sous la porte en octobre dernier sous pression directe, Garry's Mod a dû purger 20 années de contenu Nintendo de son workshop, et la société attaque actuellement Palworld sur des brevets de gameplay déposés à la va-vite.

Donc même quand un projet respecte le droit à la lettre, la firme japonaise a les moyens de noyer une équipe bénévole sous des frais d'avocats jusqu'à épuisement total. Les ports type Ship of Harkinian tiennent depuis plusieurs années déjà sans procédure, mais rien ne garantit que Dusk passera entre les gouttes. Si vous voulez profiter du jeu sur PC, je vous conseille donc de cloner le repo en local et de mettre le binaire de côté quelque part, on ne sait jamais....

Link récupère un fragment de coeur (capture du site officiel )

Pour l'installation, vous filez sur le repo GitHub, vous chopez le binaire de votre plateforme, vous pointez le launcher vers votre dump GameCube (que vous avez fait vous-même depuis une Wii moddée en suivant le guide du wiki Dolphin, hein...), et c'est parti mon kiki.

Merci à j0j0b4rj0 pour la découverte.

Felix "FX" Lindner est mort le 1er mars 2026 à l'âge de seulement 49 ans. Et si ce nom ne vous dit rien, c'est normal, car FX n'a jamais cherché les projecteurs. Par contre, ceux qui bossent dans la cybersécurité, eux, savent parfaitement qui il était.

Fondateur de Recurity Labs à Berlin, leader du groupe Phenoelit, co-auteur de "The Shellcoder's Handbook", et lauréat du Pwnie Award Lifetime Achievement 2017, Félix avait plusieurs casquettes. Et c'est également celui qui a forcé Huawei à créer une équipe de sécurité dédiée, tout ça grâce à une seule présentation de 45 minutes.

Felix "FX" Lindner, fondateur de Recurity Labs (CCS 2013)

Son pseudo sur Twitter/X c'était @41414141 car en hexadécimal, 0x41 c'est le caractère ASCII 65, la lettre "A". Car 4 "A" d'affilée, c'est le padding classique qu'on balance dans un buffer overflow pour écraser la mémoire. Hé oui même son pseudo était un exploit ! Petit détail au passage : ne le confondez pas avec "fefe", Felix von Leitner, l'autre Felix célèbre de la scène sécu germanophone. La confusion est fréquente, même dans les hommages post-mortem que j'ai pu voir.

Pour comprendre FX, faut remonter à 1977, à Berlin-Est, le côté soviétique du Mur. Gamin, il met les mains sur son premier ordinateur à 6 ans, lors d'une visite à l'Université de Sofia en Bulgarie puis à 10 ans, il programme en BASIC sur un Robotron Z9001 (un CPU U880 à 2.5 MHz, 16 Ko de RAM), qui était à l'époque la machine phare de la RDA (en fait c'était un des rares ordinateurs personnels fabriqués en Allemagne de l'Est). Pas exactement un Commodore 64 donc, mais bon... on fait avec ce qu'on a quand on grandit derrière le Rideau de fer.

Le Robotron Z9001, ordinateur est-allemand sur lequel FX a fait ses premières armes (Wikimedia Commons)

Et puis le Mur tombe.

En novembre 1989, FX a 12 ans et dans les décombres institutionnels de l'Allemagne de l'Est, il découvre un truc improbable : un club informatique rattaché à l'Organisation des Pionniers Ernst Thälmann, le mouvement de jeunesse du régime est-allemand (dissous quelques mois plus tard). C'est là qu'il croise ses premiers hackers, des gamins comme lui, curieux, qui bidouillent sur du matériel en voie de disparition.

Faut dire que Berlin dans les années 90, c'est un sacré terrain de jeu. Le Chaos Computer Club est déjà une institution, les loyers sont bas, l'énergie est dingue. Du coup, FX baigne là dedans tel un enfant de la Réunification, en quelque sorte.

Et c'est au tournant des années 2000, qu'il fonde Phenoelit, un groupe de recherche en sécurité basé à Berlin. Leur spécialité ? Les trucs que personne ne pense à auditer, parce que tout le monde part du principe que c'est sécurisé. Routeurs Cisco, imprimantes HP, systèmes SAP, BlackBerry RIM... tout y passe. Phenoelit, c'est de la recherche bas niveau et du reverse engineering pur et dur.

FX publie alors des outils qui deviennent des classiques. cd00r.c d'abord, une backdoor furtive qui n'ouvre AUCUN port en écoute. Le concept est trop fort puisque la machine écoute discrètement tout le trafic réseau qui passe et ne déclenche un /bin/sh que si elle voit passer un paquet "magique" porteur d'une signature codée en dur. Pas de port ouvert, pas de service à scanner, mais juste un guetteur silencieux qui réagit au bon mot de passe. Le concept inspirera plus tard le port knocking grand public.

Ensuite IRPAS (Internetwork Routing Protocol Attack Suite), un kit complet pour tester les protocoles de routage réseau. CDP, IRDP, HSRP... ces langages que les routeurs utilisent pour se causer entre eux et que personne n'avait sérieusement attaqués avant lui. Tellement utile que la suite finit intégrée dans Debian et Kali Linux. Et puis Ultima Ratio, un exploit remote code execution (RCE) pour Cisco IOS, présenté à la DEFCON.

FX avait un vrai don pour trouver les failles là où personne ne regardait.

Mais l'outil le plus connu du grand public, c'est la Default Password List. Une base de données des mots de passe par défaut de la quasi-totalité des équipements réseau du marché. Routeurs, switchs, imprimantes, caméras... pratiquement tous les pentesteurs de la planète l'ont utilisée au moins une fois. Elle a même fini dans SecLists, la bible du domaine.

Mais FX ne se contentait pas d'attaquer.

En 2010, il développe Blitzableiter (littéralement "paratonnerre" en allemand), un outil anti-exploitation Flash. En gros, ça analyse et reconstruit les fichiers .swf pour neutraliser les malwares, sans se baser sur des signatures CVE. Lors de sa démo à Black Hat USA et DEFCON 18, il balance alors 20 malwares Flash en live et 20 sur 20 bloqués. A une époque où Flash était LE vecteur d'attaque sur le web, c'était du lourd.

Quelque part avant 2007, FX lance Recurity Labs à Berlin. Audit de code C/C++, ingénierie inverse ARM et x86, architecture sécurisée... Il est rejoint par 12 consultants, chacun avec au moins dix ans d'expérience. Pas de marketing flashy, pas de bullshit corporate mais du boulot bien technique, et c'est tout.

FX décroche même un titre de Technicien Informatique Agréé et une certification CISSP, mais bon... c'est pas vraiment pour les diplômes qu'on le connaissait. C'était plutôt pour sa capacité à démonter n'importe quel système et expliquer clairement ce qui merdait dedans.

À partir de 2001, il enchaîne alors les conférences. DEFCON 9, puis 10, 11, 12, 14, 16, 17, 18... Black Hat USA, Abu Dhabi, HITB en Malaisie, PacSec, CanSecWest, Hashdays. Bref, chaque année un nouveau sujet, un nouveau système disséqué. En 2008, c'est le BlackBerry et en 2011, c'est Stuxnet et les systèmes industriels. Il n'est jamais à court de cibles.

Nous sommes maintenant le 11 octobre 2012, à Hack in the Box, Kuala Lumpur. Il y fait une chaleur étouffante, et les hackers du monde entier sont entassés dans l'InterContinental pour une conf qui attire le genre de types qui ne peuvent pas présenter leurs travaux ailleurs (car certains risquent l'extradition).

FX monte alors sur scène avec son sujet : "Hacking Huawei VRP".

VRP, c'est Versatile Routing Platform, le firmware des routeurs Huawei AR et NE. En gros, l'équivalent de Cisco IOS 12.x côté chinois et FX l'a bien sûr totalement disséqué.

Ce qu'il montre alors est accablant. Les routeurs Huawei utilisent des mots de passe statiques par défaut et un seul équipement compromis donne accès à TOUT le réseau. Y'a de quoi s'arracher les cheveux. Ce qu'il dit lors de sa conf résume tout : "Je ne sais pas s'il y a des backdoors, mais ça n'a aucune importance vu le nombre de vulnérabilités."

Et la réaction de Huawei ?

Hé bien pour une fois, plutôt correcte. John Suffolk, leur chef cybersécurité mondial, envoie une équipe d'ingénieurs rencontrer FX directement. Le géant chinois renforce alors son Product Security Incident Response Team (PSIRT, qui existait depuis 2005 mais restait peu visible) et publie des procédures de contact lisibles pour les chercheurs externes. FX racontera plus tard qu'ils ont tenu parole. C'est sa présentation qui a recalibré les pratiques de sécurité d'un des plus gros équipementiers télécoms de la planète.

Puis le 29 décembre 2013, 23h15, Saal 1 du 30e Chaos Communication Congress à Hambourg, FX est dans son élément et cette fois son sujet c'est "CounterStrike: Lawful Interception".

Le 30e Chaos Communication Congress, Hambourg, décembre 2013 (Wikimedia Commons)

L'interception légale, c'est cette fonctionnalité imposée aux fournisseurs d'accès Internet pour permettre la surveillance judiciaire. En clair... une backdoor officielle implantée dans les routeurs. Alors lors de sa conf, FX démontre que ce mécanisme viole le principe fondamental d'un routeur, à savoir transférer les paquets sans fouiller dans leur contenu, et crée ainsi une surface d'attaque massive.

Sa conclusion c'est que contourner la surveillance légale, c'est aussi facile que de tromper un antivirus. Pour lui, les backdoors "légales" ne protègent personne et fragilisent tout le monde. On est 6 mois après les révélations Snowden, et ce que FX démontre techniquement donne encore plus de poids au débat.

Snowden avait sorti les documents. FX en explique la mécanique.

Dans une interview au magazine Ethik und Militär en 2014, FX livrait surtout des opinions tranchées. Il est favorable aux capacités offensives étatiques comme complément aux défenses, mais également hyper critique du manque de responsabilité des éditeurs de logiciels, et pessimiste sur la place de l'Allemagne dans le secteur informatique. C'est pas le genre à tourner autour du pot.

Ceux qui l'ont côtoyé se souviennent également des soirées tardives, après les talks. À l'Alexis Park de Las Vegas, dans les bars de Kuala Lumpur, ou dans les clubs de Berlin, FX était de ceux qui restaient jusqu'au bout.

En 2007, il co-écrit "The Shellcoder's Handbook: Discovering and Exploiting Security Holes" avec Chris Anley, John Heasman et Gerardo Richarte. Un bouquin devenu référence pour quiconque s'intéresse à l'exploitation de vulnérabilités. Dans le milieu, c'est un classique.

Et en 2017, ses pairs lui décernent le Pwnie Award for Lifetime Achievement à la Black Hat de Las Vegas. Les Pwnie Awards, c'est un peu les Oscars du hacking, attribués par un jury de pointures (Travis Goodspeed, Charlie Miller, Katie Moussouris...). Recevoir le Lifetime Achievement, c'est la reconnaissance ultime de la communauté... Du beau monde, pour un prix super mérité.

Puis le 2 mars 2026, Nico Lindner et l'équipe de Recurity Labs publient un court message sur recurity-labs.com : "With heavy hearts, we announce that Felix 'FX' Lindner, a cherished friend, and the founder and owner of Recurity Labs, passed away on 2026-03-01."

FX nous a quittés.

Les hommages affluent alors immédiatement. Daniel Cuthbert, figure historique de l'infosec, écrit sur X : "Everyone today is a hacker in a sense but there are very few OG hackers on which shoulders we stand. Oh dude, Felix 'FX' Lindner you were so much a hackers hacker and you will be missed. RIP my friend and thank you."

Andrea Barisani, Federico Kirschbaum, des dizaines d'autres... Tous disent la même chose. FX était un vrai, quoi. Pas un influenceur sécu sur LinkedIn, pas un conférencier professionnel qui récite des slides. Mais un vrai type qui comprenait les systèmes en profondeur et qui partageait ce qu'il savait.

Felix "FX" Lindner laisse derrière lui des outils que les pentesteurs connaissent et utilisent encore, un livre que les étudiants en sécu continuent de lire, et une boîte qui continue de tourner...

Source | Wikipedia

Un passionné a tenté de récupérer son Pokémon coincé dans un Pokéwalker, ce petit podomètre vendu avec Pokémon HeartGold sur DS en 2009, après avoir perdu la cartouche de jeu.

Entre reverse engineering du protocole infrarouge et manipulation du générateur de nombres aléatoires, la tentative est bien technique. Et le résultat est plutôt cruel, pour une raison que personne n'avait anticipée…

Un Pokémon sans cartouche, un vrai problème

Le Pokéwalker, pour ceux qui ne s'en souviennent pas, c'était ce petit podomètre vendu avec Pokémon HeartGold et SoulSilver sur Nintendo DS en 2009. Le principe était simple : vous transfériez un Pokémon de votre partie vers cet accessoire, vous le glissiez dans votre poche, et chaque pas comptait pour gagner des points et débloquer des objets.

2 chercheurs en sécurité, Yaron Dinkin et Eyal Kraft, viennent de publier les résultats d'une expérience qui devrait donner des sueurs froides à pas mal de monde... Ils ont découvert 521 vulnérabilités dans les pilotes du noyau Windows, dont une bonne centaine exploitables pour de l'escalade de privilèges. Et tout ça ne leur a coûté que 600 dollars !

Mais comment ont-ils fait ? Eh bien ils se sont construit un pipeline en 5 étapes. D'abord, il a fallu récupérer 1654 pilotes uniques depuis le catalogue Microsoft Update ainsi que depuis les sites des constructeurs.

Ensuite, ils ont lancé un prétraitement automatique pour classer les cibles par surface d'attaque. Pour faire simple, dans Windows, quand un logiciel veut causer à un pilote du noyau, il lui envoie des commandes appelées IOCTL (Input/Output Control)... c'est un peu la sonnette d'entrée entre le monde utilisateur et le monde noyau. Leur pipeline analysait donc la complexité des fonctions qui répondent à ces commandes (les "handlers IOCTL"). Plus un handler est complexe, plus il y a de chances qu'une erreur s'y planque.

Et ils cherchaient en priorité les pilotes qui utilisent un mode de transfert de données appelé METHOD_NEITHER, c'est-à-dire le mode "démerde-toi". Car contrairement aux autres modes où Windows joue les intermédiaires et vérifie un minimum ce qui transite, ici le pilote reçoit directement les pointeurs bruts depuis l'espace utilisateur, sans aucun filet de sécurité du noyau. C'est ensuite au développeur du pilote de tout vérifier lui-même… et spoiler : beaucoup ne le font pas correctement ! Bref, c'est le genre de truc qui sent la vuln à plein nez.

Ensuite pour la recherche de vulnérabilité, c'est-à-dire vraiment le cœur de leur système, ils ont mis en place un conseil de 3 agents LLM avec chacun un rôle bien défini. Un agent décompile d'abord le binaire et renomme les fonctions, ensuite un autre identifie la surface d'attaque, et enfin le troisième audite chaque fonction pour trouver des corruptions mémoire. Le tout via OpenRouter , en mixant les modèles pour optimiser le ratio vulnérabilités par token. Coût moyen par cible : 3 dollars.

Et les résultats obtenus sont assez crazy loco car sur 202 binaires analysés, ils ont trouvé 521 vulns au total dont 45% de bugs de lecture/écriture mémoire arbitraire. Et 70% de ces vulnérabilités sont classées High ou Critical.

Mais évidemment y'a du faux positif (environ 60%), donc ils ont dû faire une review manuelle de chacun de ces bugs. Mais même après le tri ça laisse plus de 100 bugs réellement exploitables pour de l'escalade de privilèges sur Windows 11 ! Et les vendeurs concernés, c'est pas des petits joueurs : AMD, Intel, NVIDIA, Dell, Lenovo, IBM, Fujitsu...

D'ailleurs, le cas du driver AMD Crash Defender (amdfendr.sys) est parlant. Le device est accessible en écriture par n'importe quel utilisateur, expose des IOCTLs sans validation de taille correcte et permet de la corruption heap. Avec un peu de pool grooming, on arrive donc à de l'exécution de code kernel. Et quand on sait que ce driver tourne sur les instances AWS EC2 Windows avec processeurs AMD, on comprend vite que la surface d'attaque s'étend largement jusqu'au cloud.

(En parlant de reverse engineering assisté par IA, perso en ce moment, je suis en train de faire joujou avec Claude Code et Ghidra pour un projet dont je vous parlerai peut-être plus tard si j'y arrive, et franchement ça marche troooop bien c'est fou ! Les chercheurs de l'étude notent d'ailleurs qu'aujourd'hui, ils utiliseraient probablement "juste Claude Code avec des skills custom" plutôt que leur pipeline maison. C'est dire si l'outil d'Anthropic est fou !

Après le plus flippant dans cette histoire, comme d'habitude c'est pas les bugs. Non, ce sont les réactions des constructeurs car sur 15 vulnérabilités confirmées et rapportées à 8 vendeurs, toutes avec un score CVSS (gravité de la faille, sur 10) supérieur à 7, un seul a patché ! Il s'agit de Fujitsu, avec la CVE-2025-65001 . Les autres ont rejeté les rapports ou baissé les priorités malgré des vidéos de proof-of-concept montrant par exemple un BSOD depuis un compte utilisateur standard !

Le problème c'est que certains de ces produits hardware sont en fin de vie. Donc y'a plus de support. Mais ils ne révoquent pas les certificats de signature du driver. Du coup, ces pilotes restent utilisables pour des attaques BYOVD (Bring Your Own Vulnerable Driver), où un attaquant chargerait volontairement un driver signé mais vérolé pour compromettre le noyau.

Si vous bossez en sécurité, les chercheurs ont publié une liste de 234 hashes en double-SHA256 pour vérifier si vos machines contiennent des drivers affectés. Pour checker vos drivers, c'est simple :

sha256sum driver.sys | awk '{print $1}' | tr -d '\n' | sha256sum

La Xbox One n'a jamais été hackée ! Eh oui, depuis 2013, la console de Microsoft narguait la communauté du reverse engineering pendant que les PlayStation, les Switch et autres 3DS tombaient les unes après les autres. Microsoft la décrivait même comme "le produit le plus sécurisé jamais créé" mdrrrr.

Bon bah c'est fini comme vous vous en doutez car à la conférence RE//verse 2026 à Orlando, Markus "doom" Gaasedelen a réussi à exécuter du code arbitraire sur le boot ROM de la console, autrement dit c'est un hack hardware impossible à corriger.

Du coup, comment on casse un truc réputé incassable ?

Eh bien toute la sécurité de la Xbox One repose sur un minuscule processeur ARM Cortex R4, le Platform Security Processor (PSP), planqué dans un coin du SoC AMD.

Ce PSP contient un boot ROM gravé directement dans le silicium... et c'est le seul composant que Microsoft ne peut pas mettre à jour. L'architecte de la sécu Xbox, Tony Chen, l'avait dit lui-même en 2019 : "le seul bug logiciel dont on ne peut pas se remettre, c'est un bug dans le boot ROM".

Le die shot du SoC Xbox One. Le PSP est planqué tout en bas à droite.

Sauf que Markus n'a pas cherché de bug logiciel, parce y'en a pas. Le code du boot ROM est linéaire, hyper audité, sans la moindre faille. Du coup, il est passé par le hardware avec du voltage glitching.

Le principe c'est de faire s'effondrer brièvement le rail d'alimentation du processeur (en gros, on colle un MOSFET sur le rail et on tire la tension vers le bas pendant 100 à 200 nanosecondes) pour corrompre l'exécution d'une instruction. Et Microsoft avait quand même blindé le truc en prenant soin de ne pas mettre de pin reset accessible, pas d'UART, pas de JTAG, pas de post codes de diagnostic (désactivés par des fusibles), et surtout 37 stalls randomisés qui décalent le timing du boot à chaque démarrage. En gros, c'est comme essayer de crocheter une serrure dans le noir, avec des moufles, et la serrure qui change de position toutes les 2 secondes.

D'ailleurs, c'était la première fois que Markus faisait du glitching de sa vie. Au début, il a galéré sur le mauvais rail d'alimentation (la tension 1.8V, finalement un cul-de-sac) avant de trouver le bon (le North Bridge core). Et là, en balançant ses impulsions de voltage au bon moment, il a réussi à activer les post codes que Microsoft avait désactivés par fusibles. Premier signe que la bête était vulnérable !!!!

Le setup de glitching : oscilloscope, carte mère Xbox One et fils partout.

Ensuite, il a ciblé les opérations memcopy du boot ROM, là où les données contrôlées par l'attaquant transitent dans les registres du processeur. Un glitch bien placé pendant un memcopy, et hop, le pointeur d'instruction du processeur part n'importe où. Résultat : 0x41414141 qui sort sur le bus I2C, la preuve qu'on contrôle l'exécution du boot ROM !

Bon par contre, il était enfermé dans un "user jail", une sandbox ARM avec seulement quelques Ko de code accessible. Et c'est pas si simple d'en sortir.

0x41414141 sur le bus I2C. ROP'd OUT MY POST CODE !

Et là, coup de génie du mec : un double glitch sur le même boot.

Le premier casse la boucle d'initialisation du MPU (la protection mémoire ARM, les 12 régions qui créent les jails), le second hijack le pointeur d'instruction pendant le memcopy.

Combiner les deux sur un seul démarrage, c'est du genre 1 chance sur 100 par glitch, soit environ 1 sur 10 000 pour le combo donc autant dire qu'il faut laisser tourner la machine des centaines de milliers de fois. Mais ça marche !! Avec le MPU désactivé et le pointeur d'instruction sous son contrôle, Markus obtient alors l'exécution de code en mode superviseur, avant même que le boot ROM n'ait vérifié les signatures ou déchiffré quoi que ce soit.

Bingo !! Et les conséquences sont radicales puisque grâce à ce hack, il peut maintenant déchiffrer tous les jeux, les firmwares et les mises à jour passés, présents et futurs.

Il peut aussi dé-pairer les NAND et lecteurs optiques pour la réparation. Et comme c'est gravé dans le silicium, c'est impatchable, comme le Reset Glitch Hack de la 360 à l'époque. Pour l'instant, ça concerne uniquement le modèle Xbox One Fat de 2013.

Ah et petit détail croustillant.... Microsoft avait prévu des moniteurs anti-glitch dans le SoC pour détecter les perturbations de voltage, mais sur les premières révisions ils n'arrivaient pas à les stabiliser, du coup ils les ont désactivés par fusibles. Pas de bol. Après sur les modèles suivants (One S, One X) ils sont activés, mais Markus pense que ses techniques pourraient quand même être adaptées.

Le boot flow du PSP. Le hijack se produit à l'étape 4, avant toute vérification crypto.

Le plus dingue c'est que le hack en version finale ne nécessite que 3 fils soudés sur la carte mère ! Tout le reste, les dizaines de sondes à crochet, l'oscilloscope 4 voies, l'analyseur logique branché sur le bus I2C et les GPIO, c'était juste pour comprendre ce qui se passait.

Et le fait qu'il ait construit un émulateur du boot ROM avec l'aide de l'IA pour étudier le comportement du processeur, je trouve ça encore plus incroyable !

Bref, je vous laisse avec la conf en intégralité pour les plus motivés :

C'est fou hein, mais un CD-ROM de catch sorti en 1999 a gardé ses vidéos sous DRM durant 25 piges et tout ça juste parce que le serveur qui filait les clés de déchiffrement a disparu. Du coup personne pouvait plus rien lire.

Jusqu'à maintenant.

Le WCW Internet Powerdisk, c'était un disque promo glissé dans le magazine WCW. 61 clips vidéo de catch dessus, des matchs Hogan vs Goldberg, des profils de Sting, des intros Monday Nitro... le tout en MPEG-1 à 320x240, 30 fps, et audio MP2 mono à 64 kbps. Pour lire ces vidéos, fallait passer par UlPlayer.exe qui allait chercher une clé sur un serveur distant. Et quand le serveur a disparu vers 2000, 51 minutes de contenu sont devenues inaccessibles. Du jour au lendemain. Verrouillé pour TOUJOURS... enfin presque.

Car un dev a décidé de s'attaquer au problème en analysant le programme de chiffrement utilisé à l'époque. Et le chiffrement PAVENCRYPT (oui c'est son petit nom), c'est juste une clé qui boucle sur chaque octet du fichier. Chaque fichier a sa propre clé, mais on est clairement sur du niveau exercice de première année en crypto, dans l'esprit du ROT13.

Et comme les fichiers MPEG-1 ont une structure connue, il suffit de regarder la fin du fichier chiffré pour deviner la clé. Un simple calcul, quelques secondes, et c'est plié. Sauf si le fichier est corrompu (là bon courage).

Résultat, 61 fichiers sur 61 récupérés ! 51 minutes de catch WCW avec des matchs, des promos, des segments scénarisés... tout ça converti en H.264 et mis en ligne sur l' Internet Archive . Le déchiffreur est en Python mais attention par contre, ça ne marche que sur les fichiers .PAV au format PAVENCRYPT, et pas sur n'importe quel chiffrement des années 90 ^^.

D'ailleurs, ce genre de DRM propriétaire des années 90, c'était monnaie courante. Y'a tout un tas de vieux contenus numériques qui pourrissent derrière des verrous obsolètes . Ici la protection a survécu plus longtemps que l'entreprise qui l'a fabriquée, qui a purement et simplement disparu.

Après, le chiffrement était tellement basique que c'est pas non plus un exploit de DINGUE. N'importe qui avec Python et des notions de crypto aurait pu faire pareil, sauf que personne n'avait essayé, donc voila, bravo !!

Comme quoi, un DRM n'a pas besoin d'être costaud pour bloquer du contenu pendant un quart de siècle. Suffit que personne ne s'y intéresse.

Ghidra, le framework de reverse engineering open source de la NSA, est un outil que tous les analystes sécu utilisent au quotidien pour démonter des binaires. Sauf que voilà... quand vous passez des heures à renommer des fonctions, documenter des structures et tracer des cross-references à la main, ça finit par devenir un poil répétitif.

Du coup, un développeur a eu l'idée de coller un serveur MCP (Model Context Protocol) directement sur Ghidra. "Encore un wrapper IA bidon ??"... mais non les amis car Ghidra MCP Server est un bridge Python + plugin Java qui expose pas moins de 110 outils d'analyse via le protocole MCP. Rien que ça.

Concrètement, ça veut dire que vous pouvez brancher Claude, ou n'importe quel outil compatible MCP, directement sur votre session Ghidra et lui demander de décompiler des fonctions, tracer des call graphs, renommer des variables en batch ou même créer des structures de données automatiquement.

Au niveau architecture, un plugin Java tourne dans Ghidra et expose une API REST sur localhost:8089, puis un bridge Python fait la traduction entre le protocole MCP et ces endpoints HTTP. Vous lancez Ghidra, vous activez le serveur via Tools > GhidraMCP > Start MCP Server, et hop, votre IA peut causer directement avec le décompileur.

Et c'est pas juste de la décompilation basique. Y'a de l'analyse de structures, de l'extraction de strings, du mapping mémoire complet, de la gestion de scripts Ghidra (plus de 70 scripts d'automatisation livrés avec le projet !) et même un système de documentation cross-binaire.

En gros, vous analysez un malware, vous documentez toutes les fonctions, et si vous tombez sur une variante plus tard, l'outil transfère automatiquement votre doc via un système de hash SHA-256 sur les opcodes. Plutôt chouette ! En revanche, ça marche pas si le code est fortement obfusqué... logique.

Bon, pour ceux qui connaissent déjà OGhidra (qui fait tourner des LLM en local dans Ghidra), Ghidra MCP Server c'est l'approche inverse. Au lieu d'embarquer l'IA dans Ghidra, c'est Ghidra qui s'ouvre à l'IA via un protocole standardisé. Du coup vous n'êtes pas limité à un seul modèle... Claude, GPT, Gemini, n'importe quel client MCP fait l'affaire.

Côté prérequis, faut Java 21, Maven 3.9+, Python 3.10+ et évidemment Ghidra 12.0.2. L'install se fait en quelques étapes : cloner le repo, pip install, copier les libs Ghidra dans lib/, compiler avec Maven et déployer le zip dans les extensions. Rien de bien sorcier si vous êtes déjà dans l'écosystème... sauf si vous êtes sous Windows, là faudra peut-être un peu galérer avec Maven.

Les opérations batch sont par exemple très intéressantes... Avec cette fonctionnalité, vous pouvez renommer 50 variables d'un coup, poser des commentaires sur toutes les fonctions d'un module, typer des paramètres en série.

Bref, si vous faites de l'analyse de binaires et que vous voulez arrêter de tout vous taper à la main, c'est le genre de combo reverse engineering + IA qui va vous faire gagner pas mal de temps !

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 .

Voici l’histoire de Pixelmelt, un développeur qui voulait simplement sauvegarder en local un ebook acheté sur Amazon pour le lire avec une autre app parce que l’app Kindle d’Android a crashé une fois de trop à son goût.

Mais c’est impossible. Pas de bouton download, pas d’export, que dalle… Même si vous avez acheté le livre, c’est Amazon qui décide de comment et de quand vous pouvez le lire.

Bref, frustré, il se tourne alors vers le Kindle Cloud Reader, la version web de l’app. Et là, il découvre un truc incroyable ! Amazon a créé un système d’obfuscation tellement complexe qu’il ressemble aux techniques de cryptographie des manuscrits anciens. Mais siii, vous savez, ces textes enluminés que seuls les moines pouvaient déchiffrer au Moyen-Âge. Amazon a réinventé le concept en version numérique.

Pour fonctionner, le Kindle Cloud Reader utilise un endpoint de rendu qui nécessite plusieurs tokens d’authentification. Déjà c’est pas simple. Mais ça se corse un peu plus quand on regarde le texte qui s’affiche car ce ne sont pas des lettres ! Ce sont des glyphes, essentiellement des séries de coordonnées qui dessinent une lettre. Ainsi, au lieu de stocker le caractère ‘T’, Amazon stocke “glyphe 24” qui correspond à une forme dessinée via des commandes SVG. Et ces glyphes changent de mapping toutes les 5 pages, un peu comme un codex (coucou Dan Brown ^^) où l’alphabet se transforme à tous les chapitres.

Du coup, pour son livre de 920 pages, il a fallu faire 184 requêtes API distinctes. Chaque requête récupère un nouveau jeu de glyphes soit au total 361 glyphes uniques découverts, et 1 051 745 glyphes à décoder. Oui, ça fait plus d’un million de symboles à traduire pour lire un seul livre.

Amazon a même ajouté des pièges comme des micro-opérations MoveTo complètement inutiles dans les SVG qui s’affichent parfaitement dans le navigateur mais cassent toute tentative de parsing automatique. C’est de l’anti-scraping placé là volontairement, comme des fausses pistes dans des cryptogrammes médiévaux destinées à tromper les copistes non autorisés.

Face à ce délire, notre développeur est alors devenu malgré lui un crypto-archéologue. Sa méthode a donc été de comparer pixel par pixel chaque caractères, valider chaque hypothèse, pour tout reconstruire patiemment. Je vous passe les détails techniques mais il a sorti chaque glyphe SVG sous la forme d’une image, puis a comparé ces images pour trouver leur correspondance avec les vraies lettres en utilisant un outil (SSIM) qui simule la perception humaine pour évaluer la similarité entre deux images.

Résultat, 100% des glyphes matchés ont un score quasi-parfait ce qui lui a permis de reconstruire un fichier EPUB complet avec le formatage, les styles, les liens internes…etc. Tout y est, c’est trop fort !

Bref, Pixelmelt 1 - Amazon 0 ! Et ça, ça fait plaisir ! Maintenant si vous voulez connaitre tous les détails de ça et refaire la même chez vous (pour rigoler hein, ne vous lancez pas dans dans une opération de piratage massif sinon vous finirez en taule comme Sarko ^^)

Tous les mardis soir, c’est la même chose dans le petit monde de la cybersécurité : Microsoft balance ses patches, et dès le mercredi matin, c’est la ruée vers l’or pour les experts sécu. Bienvenue dans l’univers déjanté de l’Exploit Wednesday, où des chercheurs du monde entier se transforment en cyber-archéologues pour y déterrer les vulnérabilités avant que les méchants ne s’en emparent afin de coder des exploits.

Et un nouvel outil vient de débarquer pour pimenter cette course folle : Diffrays .

Imaginez… il est 3h du matin, on est mercredi et pendant que vous dormez tranquillement, des milliers de chercheurs en sécurité sont déjà en train de comparer frénétiquement les binaires de Windows fraîchement patchés avec leurs versions vulnérables.

Pourquoi est-ce qu’ils font ça ? Hé bien c’est parce que chaque seconde compte. L’IA a réduit de 40% le temps nécessaire pour identifier une vulnérabilité à partir d’un patch et ce qui prenait des jours prend maintenant des heures, notamment aux cybercriminels, du coup, la course s’est transformée en sprint.

Et c’est là que Diffrays entre en scène. Cet outil, conçu par pwnfuzz, fait ce qu’on appelle du “patch diffing”. Pour les non-initiés, le patch diffing, c’est l’art de comparer deux versions d’un programme pour trouver ce qui a changé. Un peu comme comparer deux photos pour jouer au jeu des 7 différences, sauf que là, on cherche des bugs qui valent potentiellement des millions.

Pour cela, Diffrays utilise IDA Pro et sa nouvelle IDA Domain API pour extraire le pseudocode des fonctions et les comparer de manière structurée. Et ce n’est un vulgaire comparateur de texte…non… Diffrays génère en fait une base de données SQLite complète avec toutes les différences trouvées, et lance même un serveur web local pour naviguer dans les résultats. Vous tapez diffrays diff old.exe new.exe, puis diffrays server --db-path results.sqlite, et hop, vous avez une jolie interface web sur http://localhost:5555 pour explorer ces changements.

Grâce à cet outil, chacun peut savoir exactement comment Microsoft corrige ses bugs. Prenez par exemple l’analyse du driver Clfs.sys montrée dans la documentation de Diffrays . Les chercheurs ont téléchargé deux versions du driver. La première vulnérable (10.0.22621.5037) et la seconde patchée (10.0.22621.5189) puis ont laissé Diffrays faire son travail… Et en quelques minutes, l’outil a identifié exactement quelles fonctions avaient été modifiées et comment.

Évidemment, Diffrays n’est pas seul sur ce marché juteux. Google a son BinDiff , il y a aussi Diaphora, et maintenant même des outils boostés à l’IA comme DeepDiff qui convertissent le code en “embeddings” (des représentations mathématiques) pour trouver des similarités. Mais Diffrays a un avantage, il est open source, gratuit, et surtout, il est conçu spécifiquement pour la recherche. Pas de conneries marketing, juste du code qui fait le taf.

D’ici 2026 , les experts prédisent que le patch diffing assisté par IA sera la norme dans toutes les red teams et programmes de bug bounty. On parle même de plateformes de diffing en temps réel avec des bases de données de vulnérabilités crowdsourcées.

Voilà, donc si vous voulez vous lancer dans ce genre d’analyses comparatives de binaires, sachez que Diffrays est sur GitHub , et qu’il est prêt à transformer vos mercredis matins en séances de fouilles intensives. Et n’oubliez pas… avec un grand pouvoir vient une grande responsabilité ! Sinon, c’est la zonzon, comme pour Sarko !

Si vous aimez faire un peu de reverse engineering, et que souvent, vous galérez à déchiffrer du code assembleur qui ressemble à des hiéroglyphes, alors voici un outil qui devrait vous plaire. Développé par les frenchies Louis Gauthier et Clément Florval, DecompAI transforme vos sessions d’analyse de binaires en conversations parfaitement naturelles pour décortiquer vos binaires.

Avec DecompAI, c’est terminé le jonglage permanent entre différents outils tels que Ghidra pour décompiler, GDB pour débugger, objdump pour désassembler, ou radare2 pour analyser. Cette fragmentation vous oblige à maintenir mentalement le contexte entre les applications, ça ralentit votre workflow et ça multiplie les risques d’erreur. Du coup, cette approche conversationnelle a son intérêt car au lieu de mémoriser des dizaines de commandes cryptiques, vous décrivez simplement vos besoins en langage naturel du genre : “Décompile-moi la fonction main”, “Montre-moi les strings intéressantes” ou “Analyse cette fonction suspecte”. L’agent DecompAI orchestre alors automatiquement les bons outils avec les paramètres appropriés.