Connexion
REA , pour "Reverse Engineer Anything", c'est un serveur MCP qui buzze ces derniers jours et qui permet de connecter votre agent IA (Claude Code, Codex, Cursor...) sur Ghidra, Hopper ou IDA, et sur des analyseurs pour les applis Electron, .NET ou les sites web.
Vous repérez ainsi une fonction qui vous plaît dans une appli, puis l'agent la décortique sans le code source et vous en code une version toute fraiche... Tiens ça me rappelle quelque chose...
Comme je voulais voir ce que ça donnait, je me suis donc monté un petit banc d'essai à l'arrache sur mon ordi avec Claude Code en Opus 5.5, REA 6.4.0 comme seul serveur MCP et Ghidra comme moteur.
Mes tests se découpent donc en 4 exercices : un keygen, un patch, une fonction d'appli à recréer ainsi que des codes de triche. Pour les deux premiers, j'ai bien sûr compilé des programmes maison avec un faux système de licence afin de ne pas sombrer dans l'illégalité en codant un vrai keygen ou un crack (et au passage me faire delete mon compte Anthropic ^^).
rea doctor valide Ghidra 12.1.4
Mon crackme, c'est donc une fausse app nommée "PixelNote Pro" qui réclame un nom d'utilisateur et une clé d'activation, compilé pour Mac ARM.
Une fois que je lui ai dis ce que je voulais faire, l'agent a donc ouvert le binaire dans Ghidra via REA, lu le pseudo-code, l'a recoupé avec l'assembleur là où le décompilateur écrivait une rotation de bits sous une forme peu lisible, et m'a pondu un keygen en Python en 2 minutes chrono pour un coût API de Claude 50 centimes. J'ai ensuite fait tourner son générateur sur 479 noms tirés au hasard et le binaire les a tous acceptés.
Le crackme ouvert à la main dans Ghidra : la fonction entry et son pseudo-code
La boucle de calcul de la clé, dans le pseudo-code que REA sert à l'agent
Le patch, c'est le plus bluffant j'ai trouvé. Le petit utilitaire que je me suis fait a pour mission de compter les lignes et les mots d'un fichier texte. C'est très basique. Et j'ai donc voulu faire un patch pour qu'il affiche aussi les caractères. Comme REA, avec Ghidra, ne touche pas aux octets de l'exécutable, l'agent a donc dû faire le reste à la main... il a logé ses instructions dans une zone remplie de zéros de la partie exécutable, détourné trois instructions d'origine vers elles, puis re-signé le binaire pour que macOS le lance :
Le compteur d'origine, sa version patchée par l'agent, puis le keygen du crackme accepté par le binaire
Pour mon 3ème exercice, je me suis dit que j'allais cloner la fonction d' Amphetamine qui garde mon Mac éveillé tant qu'une appli donnée est ouverte. Via Ghidra, malheureusement REA a refusé le binaire universel Intel et ARM d'Amphetamine, alors l'agent en a extrait lui-même la partie ARM. Il a alors trouvé qu'Amphetamine posait une assertion d'énergie du système et surveillait la liste des applis lancées. Et magie de l'IA, il a ensuite codé en Swift un petit outil qui fait tout pareil. J'ai testé avec la Calculatrice, ça marche, à condition de lui donner le nom de l'appli dans la langue du système, ou son identifiant.
pmset ne montre l'assertion d'éveil que pendant que la Calculatrice est ouverte
Et le dernier, c'est Wolfenstein 3D (j'ai pris la version shareware 1.4) dont l'exécutable DOS est compressé. L'agent a donc écrit son propre décompresseur, puis retrouvé dans le code le raccourci clavier pour tricher (c'est M+L+I qui met santé à 100, munitions, clés, mitrailleuse... et score remis à zéro), le paramètre goobers qui, avec Maj gauche + Alt + Retour arrière, débloque les touches de debug comme le mode Dieu, et même un juke-box caché. Tout correspond au code source publié depuis par id Software.
Par contre, ses logs montrent qu'il cherchait ces codes par leur nom avant de les avoir vus. Je me suis donc fait avoir puisque le modèle les connaissait déjà. Par contre, il les a bien retrouvé dans le binaire.
Début de partie du shareware 1.4 dans DOSBox, lancé avec le paramètre goobers
Les trois occurrences de goobers dans l'exécutable décompressé
Alors, REA est-il indispensable ?
Hé bien pour le savoir, j'ai relancé les quatre exercices avec le même modèle, les mêmes fichiers et les mêmes consignes, mais avec REA en moins... juste Claude Code qui pilote Ghidra. Hé bien Claude tout nu a tout réussi lui aussi, mais en écrivant quand il en avait besoin ses propres scripts Ghidra en Java, là où REA lui servait le pseudo-code et l'assembleur sur un plateau.
Bref, ce que je peux vous dire avec mes tests, c'est que REA ne fait pas mieux qu'un Claude à qui on demande d'installer Ghidra et de l'utiliser. Par contre, REA a été plus rapide sur le keygen (2 minutes 22 contre 2 minutes 48 pour Claude), sur Amphetamine (9 minutes contre 16 minutes pour Claude) et sur Wolfenstein (10 contre 14 pour Claude), mais plus lent sur le patch (7 minutes et demie contre un peu plus de 2 pour Claude).
A voir ce que ça donnerait avec un modèle local genre Qwen (débloqué avec Heretic , alleeeez)...
REA est sous licence MIT et l'analyse tourne en local (même si ses résultats partent quand même chez le fournisseur de votre modèle, donc évitez d'y passer un binaire confidentiel), et Hopper comme IDA restent des outils commerciaux dont REA ne fournit aucune licence.
Notez aussi que son créateur exclut le contournement de licences et la fabrication de patchs pour les jeux, d'où encore une fois mon crackme fait maison et les codes qu'id a lui-même mis dans Wolfenstein ^^.
Autre précaution à prendre si vous vous lancez et qui touche cette fois à la fiabilité de ce que l'agent IA peut vous raconter : Des chercheurs ont publié fin mai un préprint montrant qu'un binaire piégé peut donner ses propres ordres à l'IA qui l'analyse . Pour cela, il suffit d'y glisser des chaînes de texte sans effet à l'exécution, qui se retrouvent ensuite dans le code décompilé et soufflent de fausses instructions au modèle, pour lui faire mal interpréter le programme. Je n'ai pas testé REA là-dessus, mais le principe vaut a priori pour tout agent branché sur Ghidra, donc faites bien attention avant de donner un échantillon suspect à votre agent IA préféré.
Et si seul Ghidra vous intéresse, sachez que le ce MCP dont je vous ai parlé en février permet aussi de faire le pont agent IA <> Ghidra.
Voilà, pour installer REA, un petit :
Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi) npx rea-agents setup
Et c'est parti !
Mighty DOOM, le petit shoot roguelite que Bethesda avait sorti sur mobile en mars 2023, tourne de nouveau !! Alors bien sûr pas sur les serveurs officiels, qui sont éteints depuis deux ans, mais sur un serveur monté et hébergé par des fans, qui ont refait tout le boulot à la main.
Mais avant, pour ceux qui ont raté un épisode, en fait, le jeu est mort parce que Microsoft a fermé Alpha Dog Games, le studio qui le développait, en mai 2024, c'est-à-dire en même temps qu'Arkane Austin et Tango Gameworks (le studio de Redfall et celui de Hi-Fi Rush... tout ça le même jour, l'hécatombe). Et ce qui devait arriver arriva, puisque trois mois plus tard, le 7 août 2024, les serveurs de Mighty DOOM se sont arrêtés.
Et ce n'est pas rien parce que le jeu avait quand même été téléchargé 7,6 millions de fois sur mobile...
C'est pour ça que le projet Mighty Resurrection a décidé de redistribuer lui-même un APK Android du jeu. Il nécessite Android 10 minimum et il pointe directement sur le serveur de la communauté, dont le compteur annonçait déjà au moment d'écrire ces lignes, 449 comptes enregistrés.
Au-delà de l'APK "client", ce qui est cool, c'est qu'en face, il y a un logiciel serveur dont le code est public et que vous pouvez également lancer chez vous, si vous le souhaitez.
Ce qui est impressionnant surtout, c'est le taf. Parce qu'il a fallu régler l'authentification, les chapitres du jeu, l'inventaire des objets, les talents, la boutique, le battle pass, et même tout ce qui était achats intégrés et gestion de l'identité Xbox. En gros, chaque morceau que le jeu Android réclamait au serveur officiel, il a fallu entièrement le recoder.
Le truc un peu fou, c'est qu'Alpha Dog Games a retrouvé son indépendance cet été. Le studio est donc de nouveau entre les mains de ses fondateurs, sauf que la licence DOOM, elle, ne lui appartient pas. Donc impossible pour eux de rallumer leur propre jeu. Par contre, ils ont les sources, donc je me dis que s'ils étaient un petit peu sympas, ils pourraient aider les développeurs de Mighty Resurrection en leur offrant le code.
On verra bien si ça leur traverse l'esprit.
Merci à Maxime pour l'info.
Source : le site de Mighty Resurrection et le dépôt du serveur sur GitLab .
Après quatre ans de travail, le bidouilleur canadien DiscoStarslayer a annoncé que son firmware du MechaCon était enfin sorti ! Si vous ne connaissez pas le MechaCon, c'est la puce de sécurité que Sony avait posée en 1999 dans les premières PlayStation 2, et c'était encore jusqu'à aujourd'hui, l'un des derniers composants de la console dont personne n'avait pu obtenir le code...
Ce MechaCon tire son nom de la mécanique qu'il surveille, à savoir le lecteur optique et la mémoire flash, sauf que ces petits malins de Sony lui ont confié bien plus que ça... En effet, cette bestiole sais déchiffrer les cartes mémoire MagicGate, et surtout c'est elle qui décide si le disque que vous venez d'insérer est authentique ou pas. Donc une PS2 dont le MechaCon est raide mort, ça devient une jolie brique
La puce, soudée sur une carte mère Sony de 1999 ( Source )
Pour aller lire dedans, il a fallu y aller à la manière forte... La puce a donc été ouverte chimiquement pour mettre le silicium à nu, puis lue au microscope. C'est une opération délicate qui consiste à recopier optiquement le contenu de la ROM directement depuis le circuit. C'est lent, et c'est source d'erreur, mais ces dumps crasseux n'étaient pas le but, mais plutôt le moyen... En effet, Libby, un autre hacker qui a collaboré au projet, y a trouvé une faille exploitable, et c'est cette faille qui a ensuite permis de sortir le contenu de la puce via logiciel.
Comme ça, plus besoin de sacrifier une console pour en lire une.
Le firmware extrait, ouvert dans un éditeur hexadécimal : les chaînes laissées par le développeur Sony sont encore dedans ( Source )
Après attention, il s'agit pour le moment uniquement du premier MechaCon, c'est à dire de celui des PS2 d'avant les SCPH-500xx. Celui des modèles suivants, un ARM que Sony avait baptisé Dragon, était déjà tombé au combat, et c'est de ce dump-là qu'était sorti par la suite l'exploit MechaPwn . Donc ni les Slim ni les dernières Fat ne sont concernées ici par ce nouvel exploit.
Alors qu'est-ce que ça débloque ?
TechPowerUp écrit qu'il y a de bonnes chances que ça finisse par permettre un vrai émulateur de lecteur optique, un de ces boîtiers qui remplacent le bloc optique par une carte SD, ce que les fans réclament depuis des années. Sauf qu'un des développeurs qui ont participé au reverse est allé démentir ça sur Hacker News : les dumps seuls ne donnent pas assez d'informations pour fabriquer un tel boîtier. En effet, il manque de quoi rejouer le dialogue côté lecteur, et c'était justement ça la partie difficile.
Après pour lancer des copies de jeux non plus, il n'y a rien de neuf là-dedans puisqu'on les lance déjà depuis une carte mémoire, un disque dur ou l'exploit du lecteur DVD. Ce qui devient envisageable par contre, c'est une puce qui prendrait la place du MechaCon en laissant le processeur de signal de la console continuer à lire les disques. Autrement dit, une console que son MechaCon a brické pourrait être réparée au lieu de finir à la poubelle.
Et ça, je trouve que c'est plutôt une bonne nouvelle même si la méthode d'extraction écrit énormément dans la NVRAM de la console, et ça use le matériel.
Ahet il n'y a pas que des consoles de salon dans l'affaire puisqu'on retrouve également le MechaCon dans des cartes d'arcade à base de PS2, dont les Namco System 246 et System 256.
Quoiqu'il en soit, ces dumps serviront aussi à l'émulation, parce que toute la sécurité des cartes mémoire et des exécutables signés passe par cette puce. Ça devrait être bien utile !
Source : Hardware Busters et TechPowerUp .
Vous jouez sous Linux et votre bibliothèque Steam, GOG ou Epic tourne à peu près entièrement grâce à Proton ? Cela signifie que, malheureusement, vos jeux Xbox PC et ceux du Game Pass, eux, restent à la porte... C'est con d'avoir un catalogue entier, payé tous les mois rubis sur l'ongle et de ne pas pouvoir y toucher ailleurs que sous Windows, via le streaming cloud.
Mais cette époque est révolue puisque Xodus est un projet open source qui rétro-ingénierie la chaîne Xbox PC pour faire tourner ces jeux directement sur Linux. Son dépôt coche déjà la connexion de l'appareil, celle du compte, l'autorisation Xbox, la récupération des licences, le téléchargement des paquets de jeu et le déchiffrement des exécutables à la demande. Bref, la douane est passée (non pas Hamza, celle de Microsoft).
Ce qui bloquait n'a jamais été Proton puisqu'en fait un jeu Xbox PC moderne repose sur le GDK de Microsoft et arrive emballé dans un conteneur MSIXVC chiffré, dont les clés dépendent de la licence attachée au compte.
Rien à voir donc avec un .exe posé dans un dossier.
L'équipe, emmenée par Paweł Lidwin qui contribue aussi à Heroic , a donc dû fabriquer ses propres briques, une bibliothèque d'authentification Xbox, un lecteur capable de parcourir ces conteneurs, et surtout une réimplémentation libre de xgameruntime.dll, le composant par lequel les jeux réclament les services Xbox (Celle-là est toujours en chantier). Le projet entretient même ses propres versions modifiées de Wine et de Proton.
Sauf qu'on ne joue toujours pas... Aucun binaire n'est distribué, il faut tout compiler soi-même, et les fameux services Xbox doivent encore être servis aux jeux à travers Wine. Le lancement, c'est donc le gros morceau restant même si un jeu auquel vous avez droit se récupère et se déchiffre.
Côté catalogue, il faut du GDK et du MSIXVC. Le MSIXVC2 n'est pas géré, Gears of War 4 reste sur le carreau, et les titres rétrocompatibles se récupèrent mais réclameront peut-être des correctifs dans wine ou dxvk. Quant au déchiffrement, il s'appuie sur les instructions AES du processeur. Cela signifie que sur une machine trop vieille pour les avoir, ça ne ramera même pas... ça s'arrête juste net sur une instruction "illegal".
Et puis, vous vous en doutez, il y a Microsoft... Le projet n'est ni affilié ni approuvé par Redmond, donc c'est à utiliser à vos risques et périls, car rien n'empêche l'éditeur de changer une clé ou de modifier un bout du protocole et de refermer la porte du jour au lendemain. Avec Xodus, personne n'a rien promis, et c'est un pari sur un avenir incertain... Toutefois le dépôt avance bien quand même, sans binaire à la clé pour le moment.
C'est triste mais la toute première version de Clash of Clans, celle de 2012, n'était plus jouable nulle part depuis longtemps. En effet, les serveurs officiels rejettent ses vieilles connexions depuis des années, et donc plus personne ne pouvait y remettre les pieds.
Mais c'était sans compter sur Mike, le dev derrière Atrasis Retro et fidèle lecteur de Korben.info, qui vient de ressusciter l'app ! Et, oh magie de l'internet, vous pouvez y rejouer direct depuis votre navigateur, maintenant là tout de suite, sans rien avoir à télécharger.
Vous cliquez ici et hop, vous voilà dans le village originel tel qu'il était il y a maintenant plus de dix ans. Bien sûr, tout cela représente un boulot de dingue puisque Mike est parti d'un seul artefact, un binaire iOS de 4 Mo compilé en ARMv7 32 bits en 2012. Il l'a décompilé à coups d'IDA, traduit instruction par instruction en C++ au moment de la compilation (et pas à l'exécution, pour avoir zéro perte de perf), réimplémenté tout l'environnement iOS autour (UIKit, OpenGL ES, les sockets...etc.), puis recompilé le tout en WebAssembly pour que ça tienne dans un seul onglet.
Le mec est fou !
Et comme les serveurs officiels de Supercell envoient bouler les vieilles connexions en v1.70, il a carrément reconstruit un serveur compatible de zéro lui aussi, en C#, qui parle le même protocole réseau d'origine (c'est du RC4 sur TCP) et qui rejoue la même synchronisation déterministe que le jeu de l'époque. Résultat, vous vous retrouvez avec le jeu de 2012 dans son jus, avec les classements et les batailles multijoueur. Que du bonheur quoi !
Pour moi, c'est dans le même esprit que le port natif de Twilight Princess dont je vous parlais, que ce Zelda 64 recompilé , ou que l'outil de recompilation de ROMs que je suis en train de faire. Prendre un vieux binaire et le faire revivre par la recompilation plutôt que par l'émulation, moi j'adore !! Puis pour une fois, c'est pas un classique de Nintendo vu et revu mais quand même l'un des plus gros hits mobiles de l'histoire du smartphone. C'est une vraie capsule temporelle pour tous les anciens jeunes que vous êtes, loool. (Moi je suis toujours jeune, me faites pas chier ^^)
Maintenant, faut quand même que je précise un truc, et Mike est le premier à le dire... Son portage embarque évidemment les ressources du jeu de Supercell. On n'est donc pas du tout sur du "juridiquement" blindé. De plus, Supercell interdit noir sur blanc les serveurs privés dans sa fan content policy , et la boîte a déjà dégainé des DMCA contre des projets qui touchaient à son code. Donc autant en profiter tant que ça tourne en eau de boudin...
Ou alors Supercell se dit que son jeu a bien vécu et que ce portage leur fait une jolie pub gratuite et n'est aucunement une nuisance pour eux. Bah quoi, ce serait bien qu'un jour, les ayants droits aient un peu de souplesse sur ce genre de projets faits par des fans.
Bref, voilà, si vous avez connu Clash of Clans à ses débuts, allez y faire un tour, c'est gratuit et surtout, savourez l'instant car on ne sait jamais combien de temps ça va rester en ligne.
Je ne me lasse jamais de tous ces projets qui ressuscitent des vieux jeux. Et celui dont je vais vous parler aujourd'hui, c'est à neuviemeporte qu'on le doit. Celui-ci s'est donné pour mission de reconstruire ligne de code par ligne de code, ce bon vieux F-15 Strike Eagle II, le simulateur de vol de combat sorti chez MicroProse en 1989. Et hier, le 20 juin dernier, le projet a passé un cap important puisque le portage est enfin jouable. Et son dev cherche maintenant des pilotes d'essai pour le mettre à l'épreuve.
Donc si ça vous chauffe, mes petits Maverick en herbe, faut récupérer les exécutables sur son dépôt, ensuite vous les balancez dans le dossier de votre copie du jeu à la place des originaux (faites un backup avant, hein) et vous décollez !! Et si ça plante, si un truc s'affiche de travers, si une touche ne répond plus, vous lui remontez le bug, tout simplement.
Je reconnais quand même que le boulot derrière, est dingue car ce n'est ni une émulation ni une recompilation à partir d'un code source volé. neuviemeporte a vraiment désassemblé le binaire de 1989, réécrit chaque morceau en C, et recompilé tout ça. Puis ensuite, il a comparé les instructions machine produites avec celles du jeu original et tant que les opcodes n'arrivent pas identiques au bit près, c'est que la reconstruction est faussée. Alors il recommence et ainsi de suite ! Je ne sais pas s'il utilise l'IA pour ça mais je lui conseille fortement afin d'automatiser au maximum tout ce travail de débugging. C'est exactement ce que je suis en train de faire avec mon recompilateur de Roms et à la main, ça me prendrais facile 10 ans, je crois...
Le plus fou, c'est qu'il a d'abord dû retrouver quel compilateur MicroProse utilisait à l'époque. Il a fait des recherches sur certaines chaînes de caractères présentes dans le code et il est tombé au fond de l'exécutable sur celle-ci : "MS Run-Time Library - Copyright (c) 1988, Microsoft Corp". Verdict, c'est du Microsoft C 5.1. Et sans ce détail, il n'avait aucune chance de générer exactement la même séquence d'instructions que le binaire d'origine.
Et puis il y a ce petit détail que j'adore... En fait, le mec fait une reconstruction "bug-for-bug". En gros, les bugs du jeu de 1989 doivent rester. Ainsi, si dans la version originale votre avion se met à tomber vers le ciel quand il est à l'envers et en panne de carburant, et bien il doit continuer à tomber vers le ciel... Même comportement, mêmes défauts, mêmes sensations qu'à l'époque.
Mais alors, d'où ça lui vient, cette obsession ?
Hé bien comme nous tous, de ses jeunes années de passion dévorante avec l'informatique, quand il était scotché à son premier 386 et qu'il a découvert là son premier monde ouvert sur son ordinateur. Et ce truc lui est resté... Développeur C/C++ le jour, dingue de MS-DOS et de reverse engineering la nuit, comme il le résume lui-même sur son site. Il a lancé ce projet de recompilation en 2022 et avoue que le rythme actuel le dépasse un peu aujourd'hui...
Mais c'est ce genre de "missions de vie" qui a déjà sauvé d'autres classiques. Je pense par exemple à Mario 64 qui a été décompilé au point de tourner aujourd'hui dans un navigateur , et plein de vieux jeux DOS ne survivent que parce que des passionnés s'en occupent un par un, un peu comme l'ont fait les ancêtres nés avant l'an 2000 (je me mets dans le lot, 1982 FTW! les gars !).
Un petit mot quand même pour les futurs testeurs, parce que ce n'est pas tout à fait du plug-and-play... La version reconstruite ne passe pas par l'écran de configuration d'origine car elle part du principe que vous êtes en affichage MCGA/VGA, sans son et sans joystick. Donc pas la peine de régler votre Roland MT-32 virtuel, ça démarre direct au manche. Et pour signaler un souci, une capture via Ctrl+F5 dans DOSBox + une description de ce qui se passait avant le plantage et c'est réglé.
Voilà, si une copie traîne dans vos archives, allez voir son appel et reprenez les commandes.
Si vous faites un peu de reverse engineering sous Android, vous savez que les malwares modernes font absolument tout ce qu'ils peuvent pour planquer leurs mauvaises intentions, un peu comme vos parents toxiques... Code obfusqué, chargement dynamique, packing...etc, etc.
Mais c'était sans compter sur une équipe de chercheurs italiens menée par Giorgio Giacinto ont carrément changé de stratégie avec RAMwavDroid qui au lieu de désassembler le code , permet de le transformer en son et ensuite, laissent une IA l'écouter. Et cela permet d'obtenir un niveau de 98% de détection des malwares.
J'vous explique la sorcellerie de ce truc...
En effet, d'habitude, pour analyser une appli Android, on décompile l'APK et on récupère le code, notamment des fichiers smali, un équivalent lisible par un humain du code bas niveau Dalvik.
Mais avec leur RAMwavDroid, vous prenez le fichier, et chaque octet, qui vaut une valeur entre 0 et 255, devient directement une amplitude sonore. Pas de normalisation, ni de désassemblage mais simplement une forme d'onde, stockée dans un vrai fichier WAV ou MP3 + des réseaux de neurones qui apprennent à reconnaître la texture sonore d'un malware.
Le transformer utilisé, c'est Wav2Vec2, qui était même à la base entraîné sur de la voix humaine.
Comment RAMwavDroid transforme les octets d'une appli en forme d'onde
Mais alors pourquoi passer par le son ?
Hé bien parce que les antivirus classiques s'appuient sur le "sens" du programme, ses permissions, ses appels API, la structure de son code...etc. Or c'est exactement ça que les vrais malwares un peu filous brouillent pour passer entre les mailles. Alors que la texture brute des octets, elle, reste la même, peu importe l'habillage que son concepteur a donné à son malware.
Et ça, une oreille artificielle finit par le repérer.
Mais le vrai coup de génie c'est que plutôt que d'analyser le fichier au repos, RAMwavDroid lance l'appli dans un émulateur et prend un instantané de sa mémoire vive juste après le démarrage. Ça permet de parcourir les fichiers chargés en mémoire, les processus, et surtout le code que le packing a déjà déchiffré pour pouvoir s'exécuter. Cette analyse forensique de la mémoire fait alors grimper la précision de près de 94% en statique à jusqu'à 98% en dynamique.
Le spectrogramme d'une appli malveillante, vu comme un son
Sur un extrait de dataset de malwares utilisé pour leurs tests, composé de 600 applis (moitié saines moitié vérolées), RAMwavDroid tape jusqu'à 98% de bonnes réponses, avec dans sa meilleure configuration quasiment aucun faux positif.
Un faux positif, c'est quand il n'y a pas de malware, mais que l'antivirus clignote quand même en rouge, donc ça montre bien l'efficacité de leur technologie. On est au même niveau que VirusTotal qui fait bosser des dizaines de moteurs de détection en parallèle.
Bien sûr, c'est un résultat de laboratoire sur un échantillon limité d'apps, et le code source n'est pas encore disponible publiquement, donc on ne peut que les croire sur parole. Surtout que leur système fonctionne uniquement dans un émulateur (pour accéder à la RAM) et ça c'est un truc typique que les malwares sont capables de détecter... Donc bon, à voir...
En plus ce système se fait avoir par les applis bourrées de gros SDK légitimes qui noient également le signal, et par les malwares minimalistes trop simples pour faire du bruit. Bref, la robustesse face à l'obfuscation avancée, ce sera pour plus tard mais j'ai trouvé cette façon de faire plutôt originale.
Peut-être qu'à terme, les créateurs de malware mixeront leur binaire avec un MP3 de Jul ou Gims pour tromper ces futurs détecteurs audio ^^.
7 dollars, c'est le prix d'une bague connectée chinoise sur AliExpress, et c'est surtout tout ce que Saksham Bhutani a payé pour se bricoler un coach santé privé. Son truc s'appelle PulseLoop , et c'est une app iPhone open source qui transforme ce gadget à deux balles en tracker de fréquence cardiaque, de sommeil et d'activité, sans abonnement ni cloud à la con.
Le principe, c'est de prendre une bague avec capteurs vendue trois fois rien (la même qui traîne sur AliExpress sous le nom de SMART_RING et en un peu plus cher sur Amazon ) et de la débrancher complètement de son app d'origine, la fameuse JRING. À la place, vous clonez le projet, vous compilez ça dans Xcode, et hop, votre iPhone causera alors directement à la bague en Bluetooth.
Fréquence cardiaque, nombre de pas, calories brûlées et kilomètres sont relevés par la bague, ainsi que le parcours par le GPS du téléphone (si vous avez votre smartphone avec le GPS actif dans la poche), et tout est agrégé et stocké en local sur le téléphone et nulle part ailleurs.
Côté sommeil, on peut grâce à ça, suivre jour après jour la qualité de la nuit qu'on vient de passer et ainsi essayer d'atteindre plus de régularité pour améliorer son score de sommeil. Pour ma part, ce genre de trackers d'activité ne sont jamais restés bien longtemps à mon poignet, mais j'avoue que bidouiller le sien change un peu la donne et me fait reconsidérer la chose.
Et là où ça devient du vrai boulot de bidouilleur, c'est que rien de tout ça n'était documenté. Saksham a donc sorti Wireshark et un dongle Nordic nRF52840 pour renifler les échanges Bluetooth de la bague, puis il a tout reconstruit. Résultat,
un second repo
qui documente le protocole de A à Z, avec une petite CLI Python où vous tapez des commandes du genre hr run 45 ou spo2 run 45 pour déclencher une mesure. Y'a même un mode selfie planqué dedans, vous serrez le poing et la bague déclenche la prise de photo sur le téléphone !
Le truc marrant (enfin, marrant... je me comprends), c'est ce qu'il a trouvé en chemin... Car OUI la bague balance tout en clair sur un service maison avec 0 chiffrement. ou signature. Vos battements de cœur transitent donc à poil sur le Bluetooth ! D'ailleurs, on a vu avec l'affaire Strava que ces données de tracking peuvent révéler bien plus que prévu, alors une bague à 7 balles qui cause sans aucune protection, ça craint un peu...
En tout cas, c'est ça qui a énervé Saksham au départ. Il avait acheté un Google Fitbit, il aimait l'idée, mais pas le reste. A 100 balles l'appareil + 10 balles de plus par mois d'abonnement, et une app bourrée d'IA à tous les étages, sans oublier ce flux continu de son rythme cardiaque, de son sommeil et de ses déplacements envoyé non-stop chez Google pour qu'ensuite ils les revendent... Ça commençait à faire un peu trop pour lui. Chez Whoop, Oura ou d'autres, c'est tout pareil, vos données SONT le produit.
C'est pour cela qu'avec PulseLoop il a décidé de casser ça...
Au-dessus, il a même collé un coach IA plutôt malin qui lit vos mesures en local et vous sort des trucs du style "ton rythme au repos a grimpé les trois nuits où tu as dormi moins de 6 heures". Il fait des graphiques, repère des tendances, retient vos objectifs. Après ce coach-là tourne sur l'API d'OpenAI avec VOTRE clé du coup dès que vous lui posez une question, vos données partent chez OpenAI et vous payez à l'usage. Mais bon, même sans ça, le reste de l'app marche très bien.
Après, faut pas rêver sur la qualité de l'appareil car une bague à 7 dollars c'est pas un capteur Oura... les capteurs valent ce qu'ils valent et le décodeur de sommeil est encore expérimental (il ne choppe même pas les phases REM pour l'instant). On est dans l'esprit d' AsteroidOS , sauf qu'ici on "libère" une bague plutôt qu'une montre.
Mais bon je me dis que les capteurs vont évoluer, ils vont en devenir de mieux en mieux et cet outil sous licence libre sera toujours là pour en reprendre le contrôle. Pour moi c'est un projet à suivre, même s'il est encore ultra jeune (et uniquement sur iPhone pour le moment).
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...
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…
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.
Le tout communiquait avec la cartouche DS par infrarouge. Sauf que voilà, si vous perdez la cartouche (ce qui arrive plus souvent qu'on ne le croit après 15 ans), votre Pokémon reste coincé dans le Pokéwalker. Pas de cartouche, pas de transfert retour. C'est exactement le problème auquel s'est retrouvé confronté Etchy, un créateur de contenu spécialisé dans Pokémon Gen 4.
Le travail de fond, c'est Dmitry qui l'avait fait il y a quelques années en décortiquant complètement le Pokéwalker. A l'intérieur : un microcontrôleur Renesas H8, une EEPROM de 64 Ko, un accéléromètre Bosch et un émetteur infrarouge générique. La communication entre la cartouche et le Pokéwalker passe par un protocole IR à 115 200 bauds, et chaque octet est simplement XOR avec 0xAA avant envoi.
Dmitry avait même réussi à exécuter du code arbitraire sur l'appareil en exploitant un débordement de buffer dans la décompression. Etchy s'est appuyé sur tout ce travail pour tenter sa mission de sauvetage. Son idée : créer une nouvelle sauvegarde avec les bons identifiants pour tromper le Pokéwalker.
Le dispositif ne vérifie que la version du jeu (HeartGold ou SoulSilver), la région et les identifiants du dresseur. En manipulant le générateur de nombres aléatoires du jeu, Etchy a réussi à générer une sauvegarde avec des IDs correspondants.
Et ça a marché. En partie. Le Pokéwalker a accepté la connexion et transféré les données du Pokémon. Sauf que le vrai identifiant unique du Pokémon, son PID, celui qui définit ses stats, sa nature, son apparence, n'existe que sur la cartouche d'origine.
Le Pokéwalker ne stocke qu'une version allégée des données : l'espèce, les attaques, l'objet tenu, le genre. Le PID, lui, restait sur la cartouche perdue. Du coup, le Pokémon récupéré n'est qu'une copie incomplète. Ca ressemble à votre Typhlosion, ça porte son nom, mais ce n'est pas vraiment lui. Comme le résume Etchy dans sa vidéo : il n'y a pas de moyen de sauver un Pokémon piégé dans un Pokéwalker.
C'est le genre d'histoire qui parle à tous ceux qui ont grandi avec une DS dans la poche. On a tous eu ce moment où un accessoire, une sauvegarde ou un périphérique finissait au fond d'un tiroir, avec des données qu'on pensait sans importance.
Etchy et Dmitry montrent qu'il y a une vraie communauté prête à passer des heures sur du reverse engineering pour trois octets de données. C'est beau et un peu absurde en même temps. Le plus cruel dans l'histoire, c'est que Nintendo n'avait visiblement pas prévu qu'on puisse perdre sa cartouche tout en gardant le Pokéwalker. Bref quinze ans plus tard, votre Typhlosion attend toujours dans son petit boîtier, et personne ne viendra le chercher.
Source : Hackaday
