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 !
J'sais pas si vous avez vu, mais Google vient de mettre en ligne une page d'aide qui explique comment déverrouiller le bootloader d'un Googlebook ! Je pensais pas écrire ça un jour. Les Googlebook, ce sont des portables mi-Android mi-ChromeOS qui sont commercialisé en France depuis hier, pour la modique somme de 1 099 euros.
Perso, je ne vois toujours pas l'intérêt d'acheter ce truc...
Je vois vraiment ça comme un PC bridé, ou un Android avec un gros clavier et je pense que c'est bien se compliquer la vie que d'acheter ce truc plutôt que de prendre un vrai PC ou un petit Macbook. Sauf, évidemment, si on est une personne qui n'a pas envie de s'emmerder la vie à apprendre quoique ce soit de nouveau, et qu'on veut juste aller sur le site de La Poste consulter le prix des timbres, ou faire un Mappy pour savoir comment se rendre au bureau de vote le plus proche.
Mais grâce à cette "possibilité" de déverrouillage, John Wu, le créateur de Magisk , a annoncé travailler sur une version de Magisk pour ces machines.
Pour déverrouiller le Googlebook, vous devez donc activer le déverrouillage OEM dans les options pour développeurs, vous passez ensuite en mode récupération avec Échap + F2 puis le bouton d'alimentation, et l'option "Unlock bootloader" se trouvera dans les options avancées. Google précise également que ça efface toutes les données, que ça désactive la sécurité de l'appareil, que les modifications ne sont pas supportées et que la garantie peut y passer.
Et côté root, Wu a posté dans la nuit du 4 au 5 octobre "Magisk on Googlebook", en promettant du code et des instructions dans les jours suivants.
Son profil indique d'ailleurs qu'il bosse sur Android chez Google, et il voit dans le Googlebook la plateforme idéale pour bidouiller ! En effet, sur un téléphone rooté, les applis bancaires et de paiement cassent, alors qu'ici vous pouvez y accédez depuis le navigateur, comme sur n'importe quel portable.
Le blocage, selon lui, vient du mode utilisateur du système. Googlebook OS fait tourner Android en Headless System User Mode, c'est-à-dire que l'utilisateur 0 reste en arrière-plan et que vous travaillez sur un compte secondaire, alors que Magisk part du principe qu'il n'y a qu'un utilisateur principal. Le support de ce mode a été fusionné dans la branche principale du dépôt dans la nuit du 5 au 6 octobre, par contre, aucun commit ne cite pour le moment le Googlebook.
Reste que rien n'est livré officiellement encore... La dernière version stable de Magisk, la 30.7, date de février et donc aucune version stable ne contient ce code. Sans oublier que pour flasher la machine, Wu explique que le fastboot par USB ne marche pas sans câbles spécialisés. Cependant, il dit avoir trouvé une solution, sans la détailler.
Donc voilà... aujourd'hui, le root d'un Googlebook n'a aucune méthode publique, et le déverrouiller maintenant en suivant la technique de Google, revient à couper la sécurité de la machine sans rien pouvoir en faire de plus côté root. Donc autant attendre les instructions de Wu pour Magisk qui devraient arriver dans les jours qui viennent.
Source : 9to5Google
Depuis quelques jours, la scène PlayStation 5 a un nouveau nom en bouche : Relapse !
Il s'agit d'un tout nouvel exploit qui vise assez large puisqu'il "libère" les consoles jusqu'alors restées bloquées du firmware 7.00 jusqu'à la version 13.60, pour les PS5 comme les PS5 Pro. C'est d'autant plus impressionnant que c'est la première fois qu'une faille kernel publique va aussi loin...
Mais ce qui a fait réagir tout le monde surtout, c'est la vitesse ! Car l'ancienne méthode, baptisée P2JB, pouvait prendre jusqu'à cinquante minutes avant que le jailbreak n'aboutisse, alors que Relapse, lui, fait le taf en quelques secondes à peine.
Pour réaliser ce jailbreak, il faut d'abord faire pointer le DNS de la console vers un serveur tiers, puis ouvrir une page web cachée dans le guide utilisateur avec le navigateur de la console. C'est à ce moment-là qu'une faille du moteur WebKit ouvre une première porte d'entrée pour un second exploit qui peut alors toucher le cœur du système afin d'obtenir un accès en lecture ET en écriture sur le système de fichiers.
Ensuite, grâce à cet accès, on peut lancer du code maison (les fameux homebrews) comme des applis ou encore des mods non officiels que la console refuserait normalement. Des utilisateurs sur le Reddit r/PS5_Jailbreak rapportent même avoir réussi à y faire tourner des jeux récents, comme le remaster de The Witcher 3 sorti le jour même !! Bien sûr, rien pour le moment n'a été vérifié sérieusement... On verra bien.
Par contre, on n'est pas encore sûr de la PS5 débridée pour la vie car l'exploit est éphémère... en effet, à chaque extinction on en perd les effets et il faut alors le relancer à la main au reboot suivant. Et surtout ce n'est pas toujours très clean car d'après des joueurs qui l'ont testé, il peut parfois provoquer des plantages (freeze, reboot...etc) mais rien de dramatique non plus. Voilà, avec cet exploit, l'accès reste donc partiel et pour le moment, y'a pas de Linux installable ni de réel contrôle complet de la machine.
Et surtout Relapse s'arrête à la 13.60, et le nouveau firmware 14.00 publié le 16 septembre corrige le bug, ce qui met hors course toute console mise à jour ces deux dernières semaines.
Maintenant si vous avez une PS5 qui n'a pas encore eu cette MAJ 14.00 car vous la gardez soigneusement à l'écart du PlayStation Network parce que Sony bannit sans pitié le matériel modifié, y'a peut-être moyen de tester, en n'oubliant pas non plus que ce fameux DNS dont je vous causais au début de l'article envoie le trafic de votre console vers un serveur dont on ignore encore le vrai propriétaire...
De son côté, Sony n'a pas encore réagi à part en publiant cette mise à jour de son firmware.
Source : le dépôt Relapse sur GitHub.
Andy Nguyen, le développeur qui portait le projet Linux sur PS5 , a annoncé mardi soir qu'il arrêtait tout !!! Plus de PS5 Linux, plus de scène PS5, c'est terminé pour lui. Adios donc le support de la PS5 Pro dont la sortie était prévue pour 2027.
Alors que s'est-il passé ? Hé bien pour lui, la scène était autrefois un groupe de chercheurs très doués et maintenant, c'est devenu une bande de débutants qui utilisent des LLM et écrivent des hacks qu'ils "ne comprennent même pas". Des "slop kiddies", comme il dit !
Ce qu'il leur reproche, c'est surtout d'avoir trouvé la toute dernière faille d'hyperviseur selon lui, celle qu'il avait lui aussi dans ses tiroirs, et d'être allés la signaler à Sony. Il leur avait pourtant demandé une seule chose : Attendre la sortie de GTA 6, pour que les gens puissent acheter le jeu normalement et profiter ensuite de Linux. Les slops kiddies avaient dit oui et pourtant, le lendemain, la faille se retrouvait dans les mains de Sony.
C'est moche ! Surtout que sa demande n'avait rien d'un caprice. GTA 6 sort le 19 novembre, et pour l'acheter sur le PSN il faut être à jour niveau firmware. Sauf qu'un firmware à jour, c'est ce qui referme le hack... Nguyen essayait donc de tenir les deux bouts durant des mois, en attendant que tout le monde ait son jeu.
Face à lui, on retrouve donc Jordy, celui qui a envoyé le rapport à Sony via HackerOne, et qui s'est exprimé publiquement sur cette affaire dès le lendemain. Il ne nie rien, explique que le bug est bien celui de Nguyen, qu'il lui avait demandé de ne pas le signaler, qu'il avait accepté. Mais comme quelqu'un d'autre a trouvé la même faille quelques heures plus tard, avec une IA, il l'a alors signalé histoire d'être le premier et de toucher le bounty.
Bref, tout ça, ce serait encore la faute de l'IA... Mais moi ce que je vois surtout, c'est qu'il n'y a plus vraiment d'étiquette respectée entre les hackers, qu'il soit confirmé ou du dimanche, et ça, c'est bien dommage.
Maintenant la bonne nouvelle c'est que Linux continue de tourner sur les PS5 Phat et Slim en firmwares 3.00 à 7.61, avec la sortie HDMI 4K60, l'Ethernet et le SSD M.2. Tout ça repose sur des failles que Sony a déjà corrigées et les cinq dépôts sont toujours en ligne. Bref, comme aucun n'est archivé, et que le loader est sous GPL-3.0, n'importe qui peut reprendre le travail là où Nguyen l'a laissé. Si ça vous tente !
Bref, pour moi toute cette histoire ce n'est pas uniquement un problème d'IA, c'est surtout un problème de gens qui font n'importe quoi. Je comprends donc parfaitement qu'il arrête, il doit être dégoûté le pauvre... des mois de boulot partis aux chiottes et on en paie tous le prix.
Après évidemment, Sony a poussé un nouveau firmware PS5 ce mercredi, et pas mal de monde dans la communauté, dont Jordy, incite fortement les gens qui aimerait installer Linux sur leur PS5 dans un futur proche, à ne surtout pas l'installer ! Tu m'étonnes !
Source : PC Gamer
Cloudflare a mis en ligne sur son GitHub un skill trop super génial d'audit de sécurité qui leur a servi de point de départ à leur propre système de chasse aux failles de sécu. Ce package pour faire des audits de sécu boostés à l'agent IA c'est un dossier de consignes en Markdown que vous déposez dans votre agent de code, et qui le fait bosser comme un vrai auditeur et pas simplement comme un "relecteur" de code.
Dans ce dépôt, vous trouverez un fichier par famille d'attaque : la corruption mémoire, l'injection de prompt, le cadrage des requêtes HTTP, l'isolation entre locataires. Et avec ça, un schéma JSON qui décrit à quoi doit ressembler un rapport, et deux validateurs écrits en JavaScript sans la moindre dépendance.
Le dossier du skill sur GitHub : un fichier de consignes par famille d'attaque, et les deux validateurs en bas de liste ( Source )
L'agent déroule ensuite six phases, de la reconnaissance au rapport final. Il commence par cartographier l'architecture, les frontières de confiance et les points d'entrée, puis il écrit sa propre grille de couverture. Ensuite il envoie des chasseurs isolés case par case et chaque piste qui remonte part chez un vérificateur tout frais tout beau qui n'a pas participé à la chasse.
Chaque piste se termine ensuite avec un rapport technique. Un rapport confirmed qui exige une trace source complète et un résultat réellement observé. Un rapport needs_validation qui nomme le fait précis qui manque, et surtout qui n'a droit à aucun niveau de gravité. Et le rapport des rejected qui garde la mémoire de ce qui a été réfuté, pour que la passe suivante ne vous ressorte pas la même chose.
Le validateur, lui, c'est du vrai code qui vérifie la "forme" de la preuve. Les empreintes doivent être uniques, et le suivi du parcours des tests qui doit partir d'un point d'entrée pour finir sur un point d'impact. Ainsi une trouvaille confirmée dont le parcours ne tient pas debout est recalée.
En revanche, sachez-le, l'indépendance du vérificateur est demandée dans les consignes, mais pas contrôlée (chez Cloudflare, c'est leur orchestrateur maison qui s'en charge, et il n'est pas dispo publiquement).
Cloudflare explique sur son site ce que donne un de ces agents lâché sur du code sans garde-fou. Il modifie la source pour que son exploit fonctionne, puis il annonce fièrement le bug qu'il vient de créer lui-même. Ou alors il pond un test qui démontre que exec() exécute des choses, donc que c'est forcément une faille critique... Et ça vous l'aurez compris, c'est de la merde et c'est absolument ce qu'on ne veut pas.
Voilà donc exactement ce que ces consignes cherchent à lui interdire.
Pour l'installer, il vous faut le CLI skills de Vercel Labs :
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit
Ensuite, vous lancez votre agent dans le dépôt à auditer et vous lui demandez un audit de sécurité. Le skill se déclenche tout seul et c'est le modèle de votre agent qui pilotera les sous-agents en parallèle (utilisez donc un modèle qui sache faire ça, c'est mieux lool). Par défaut, le rapport atterrit ensuite dans un dossier ~/security-audit-skill, en dehors du dépôt audité.
Ce qui est cool c'est que ce skill est conçu pour limiter les bêtises. Par exemple il refuse d'exécuter le code qu'il audite s'il n'a pas de bac à sable (sandbox) imposé par le système d'exploitation, avec le réseau coupé, la cible en lecture seule et des limites de CPU et de mémoire. Ce bac à sable, le dépôt ne le fournit pas, et c'est à vous de le mettre en place avec par exemple
un outil d'isolation comme Fence
. Sans lui, la piste de l'audit finira tout bonnement en needs_validation au lieu d'être véritablement suivie et tranchée.
Après, c'est le temps qui fera la différence. Chez Cloudflare, ils ont un gros système qui leur permet, par exemple avec un dépôt d'environ 30 000 lignes de code, de ne passer que 3 à 4 heures sur l'audit pour avoir un résultat correct. Mais chez vous, en local, ce sera beaucoup plus long. Cloudflare prévient aussi qu'une seule passe n'est pas suffisante puisqu'elle trouve à peu près la moitié des failles à chaque fois. Il faudra relancer ça plusieurs fois.
Allez, si vous cherchez également un filet de sécurité pour tout ce qui concerne vos pull requests, sachez qu'Anthropic maintient de son côté un reviewer de sécurité pour Claude Code qui lit le diff et vient commenter directement dessus.
Le dépôt de Security Audit Skill de Cloudflare est sous licence MIT, et il lui faudra Node.js pour faire tourner ses deux validateurs.
En tout cas, ce que je vous conseille, c'est d'aller lire le SKILL.md avant de lancer la première passe, pour vous assurer que tout sera OK au sein de votre harness.
Source : security-audit-skill sur GitHub
Meta a reconnu que son modèle Muse Spark 1.1 avait compromis les systèmes d'une société extérieure au cours d'une évaluation de cybersécurité. L'entreprise touchée n'a pas été identifiée.
Le déroulé est assez simple, une erreur de configuration a laissé le modèle atteindre l'internet public depuis son environnement de test, après quoi il a exploité une faille dans un service tiers et modifié les réglages internes de la société visée.
Cet environnement de test c'est le bac à sable. Une machine coupée du reste du monde, censée laisser un logiciel s'agiter sans qu'il puisse toucher quoi que ce soit de réel.
Le partenaire chargé de ces évaluations s'appelle Irregular. Le nom vous dit peut-être quelque chose, puisque c'est exactement le même prestataire qui avait laissé passer un modèle d'OpenAI vers un vrai site web, dans une affaire révélée la veille.
Dans ce cas-là, le nom inventé pour la cible de l'exercice correspondait à un domaine réellement déposé, et le modèle avait fini par récupérer des identifiants et administrer le site.
Anthropic avait ouvert le bal fin juillet en reconnaissant que ses propres modèles avaient pénétré trois entreprises pendant des tests.
Irregular assure de son côté qu'il s'agit du même problème d'environnement de test que celui déjà signalé par Anthropic, et pas d'une évasion de bac à sable ni d'une attaque sophistiquée.
Sauf que le point qui pose vraiment problème est ailleurs. Trois éditeurs différents, un seul prestataire d'évaluation, et la même erreur de configuration qui laisse un modèle sortir sur le réseau public alors qu'on lui a dit qu'il n'y avait pas accès.
Tous les incidents ne viennent pas d'Irregular, cela dit. L'institut britannique de sécurité de l'IA a observé de son côté un modèle monter une attaque contre un projet open source bien réel, en fabriquant de faux comptes et en faisant de l'ingénierie sociale sur ses mainteneurs.
Les modèles, eux, se comportent exactement comme prévu. On leur demande de trouver et d'exploiter des failles dans un système, ils trouvent et ils exploitent, et personne ne leur a donné les moyens de savoir que la cible était bien réelle.
Meta annonce une rétrospective complète. Irregular affirme de son côté qu'aucun problème de sécurité ne reste ouvert. Bref, on n'a pas fini d'entendre parler de ce genre de cas.
Source : Bloomberg
Il y en a qui récupèrent des vieux canapés dans des bennes à ordures et puis il y a eWastelander qui passe son temps à récupérer du matériel électronique pour ses futures bidouilles . Sa dernière prise, c'est une Xbox 360 à 15 dollars, dénichée au fond du rayon des "défectueux" d'un magasin de jeux qui soldait tout à moitié prix. Elle démarre parfaitement mais son unique défaut, c'est un contrôle parental verrouillé par un code que plus personne ne connaît.
C'est un modèle E, le dernier de la gamme, sorti à peu près au moment de la Xbox One . Malheureusement, ce verrou lui interdit tout ce qui dépasse la classification E, soit l'équivalent américain du tout public. Par exemple, le jeu Rock Band Blitz est classé T, donc bloqué. Autrement, dans cette console, il n'y a pas de disque dur, il n'y a aucun profil qui a été enregistré. Et il n'y a absolument rien à récupérer de l'ancien proprio. Voilà, il y a juste le code PIN et c'est tout.
Alors évidemment première tentative, la question secrète de récupération. "Quel est votre plat préféré ?" Il tape pizza, puis burger, puis chicken mais aucun ne passe...
Deuxième tentative, le code de réinitialisation d'usine planqué dans les menus. Il va donc dans les paramètres de la console où se trouvent les informations système. Il faut alors enchaîner une autre combinaison secrète de 6 boutons toujours identiques (gâchette gauche, gâchette droite, X, Y, bumper gauche, bumper droit) suivi de 4 pressions supplémentaires qui, elles, changent d'une console à l'autre. eWastelander programme alors les combinaisons en macros sur une manette 8BitDo, branchée via un adaptateur Brook Wingman et déroule toute la liste. Mais RIEN !
Mais il ne se laisse pas battre par le désespoir et amorce une troisième tentative : l'exploit logiciel bad update, qui se lance sur une console de série sans avoir à l'ouvrir et donne accès à une appli homebrew capable d'afficher le code en clair. Cet exploit ne se déclenche que depuis 2 jeux, Tony Hawk's American Wasteland et Rock Band Blitz. Sauf que, comme je vous le disais, Rock Band Blitz est classé T, et le verrou le bloque. Il bascule alors sur un autre exploit nommé bad avatar, mais la console freeze ! Quel enfer ! Comme cette 360 n'a aucun stockage interne, et que l'exploit réclame un disque dur ou une unité mémoire pour fonctionner, bah ça plante.
Restait la méthode "officielle", telle que décrite sur wiki Console Mods. Cela consiste à enregistrer la console sur son compte Microsoft puis à demander un reset du code, ou appeler le support qui le communique. Mais ce même wiki précise que la méthode "aurait été abandonnée d'après les retours négatifs, mais reste ici pour mémoire". Bref, y'a plus personne au comptoir !
Sa dernière option, qui se présente à lui, un peu comme la solution de la dernière chance, c'est d'effectuer un brute force sur la console. Et ça tombe bien parce qu'un autre dev surnommé Agent24 avait repris en janvier 2020 le code d'un autre bidouilleur (écrit à la base pour Arduino) puis adapté au Teensy.
Le Teensy, si vous ne connaissez pas, c'est une carte qui se fait passer pour un clavier USB et tape les combinaisons une par une. Cela représente 10 000 possibilités pour un code à 4 chiffres, soit entre une seconde et 17 heures selon la chance qu'on a. eWastelander coupe alors l'extinction automatique, laisse la carte tourner, et se barre...
5 heures après, il revient voir ce qu'il en est et, oh magie, sa console est déverrouillée !!
Bravo. Encore une fois, le brut de force a triomphé et ça ne date pas d'hier puisqu'en 2013, déjà, je vous parlais d'un bricoleur qui cassait le code PIN d'un GPS Garmin avec un Arduino et un vieux scanner, sur exactement le même nombre de combinaisons que pour la Xbox.
Et voilà comment ressusciter une console qu'on croyait perdue pour toujours à cause d'un simple code de contrôle parental !
Benjamin Code , le développeur préféré de votre développeur préféré, a reçu ce week-end un e-mail d'achat bidon avec le mot pentester dedans. En grattant un petit peu, il a découvert que quelqu'un s'amusait à trifouiller l'un de ses SaaS sans le prévenir.
Visiblement, c'est un autre créateur, Melvyn (melvynx), qui lui propose des formations autour de l'IA, qui pour les besoins d'une vidéo a fait tourner Kimi K3 en mode "hack" pour poutrer certains sites et montrer, vidéo à l'appui, que l'IA trouvait les failles toute seule.
Depuis, X s'écharpe. D'un côté, ceux pour qui la faille est corrigée et tout le monde y gagne, zéro dégât. De l'autre, ceux qui parlent d'accès illégal, pur et simple.
Alors qu'en est-il exactement ?
Eh bien, parlons de la loi d'abord, parce qu'en France, elle est limpide. L'article 323-1 du Code pénal punit "le fait d'accéder ou de se maintenir, frauduleusement" dans un système informatique de "trois ans d'emprisonnement et de 100 000 € d'amende". Créer un faux compte, simuler un paiement avec de faux numéros de CB, toucher aux données, ça aggrave les choses et on passe rapidement à cinq ans et 150 000 € (article 323-3).
Pour moi, l'argument du "il n'a rien cassé" ne tient pas une seconde en droit. Dans l'affaire Bluetouff, la Cour de cassation a validé une condamnation pour maintien frauduleux alors que les fichiers étaient accessibles sans mot de passe, tout simplement parce que Bluetouff avait continué en sachant l'accès anormal. Je trouve que ce qui est arrivé à Bluetouff, c'était abusé, mais peu importe mon avis, cela montre bien qu'aux yeux de la loi, zéro dégât ne veut pas dire qu'il n'y a pas d'infraction.
Ce qui fait basculer un pentest légal en délit, ce n'est ni la compétence, ni la bonne intention de la personne derrière, ni même ce que j'en pense. C'est UNE seule chose : L'autorisation préalable du propriétaire du système. Et je ne crois pas que Benjamin Code pratique le bug bounty sur ses systèmes...
Si on parle d'un point de vue hacking éthique, voire tout simplement en matière de nétiquette, la règle (et le bon sens, et la courtoisie) c'est d'abord d'avoir l'accord écrit avant de faire le test, et puis bien sûr de signaler la faille en privé à l'éditeur, tout en lui laissant assez de temps pour la corriger avant de communiquer dessus publiquement.
Par exemple, un bug bounty, c'est ça... C'est un périmètre défini, un canal de signalement, une protection pour le chercheur qui reste bien dans ce cadre. En dehors, il n'y a aucune protection. Et le dispositif français qui couvre les lanceurs d'alerte (article L2321-4 du Code de la défense) ne protège que le signalement de bonne foi à l'ANSSI, jamais l'intrusion elle-même.
Melvyn a reconnu lui-même juste après son "exploit" que "certains tests sur des SaaS tiers n'ont pas été précédés d'une autorisation écrite". Tu m'étonnes...
Alors les kikoulol de X.com peuvent bien jouer les spécialistes en long en large ou en travers, ça ne change rien. Kimi K3 ou pas, dégâts ou pas, tester le système d'un autre sans son feu vert, même avec une IA autonome, ça a un nom dans le Code pénal...
Maintenant, je ne pense pas que ça ait besoin d'aller plus loin que ça... Dans un monde idéal, ce qui serait super, c'est que Melvyn fasse des excuses publiques à Benjamin Code et aux autres créateurs de SaaS qu'il a "poutrés", et puis qu'il évite de refaire ce genre de conneries dans le futur.
Source : le billet de Melvyn sur Codelynx
727 mots de passe testés par seconde, c'est le score incroyable d'une Game Boy Advance reprogrammée en casseur de mots de passe par solst-ice, un développeur qui avait visiblement une console de 2001 qui traînait et pas mal de temps à tuer ^^. Son projet s'appelle GBA-Hashcat, et c'est un "port" de hashcat (le célèbre outil de crackage) sur le petit hardware portable de Nintendo.
Enfin, un port entre grosses guillemets, parce que le vrai hashcat gère plus de 300 algorithmes de hash optimisés et une palanquée de méthodes d'attaque alors que là, vous avez le droit à un seul truc, du SHA-256, et rien d'autre.
Le programme embarque la wordlist ignis-1M, une liste de 8 Mo qui contient environ 1 million de mots de passe parmi les plus courants. Pour chaque ligne, la GBA calcule le hash SHA-256, le compare à un hash cible codé en dur dans le programme, et regarde si ça correspond.
C'est une attaque par dictionnaire, quoi, sauf que, je vous rappelle, ça tourne sur une puce ARM7TDMI cadencée à 16,78 MHz avec 288 Ko de RAM.
Du coup, forcément, ça rame de fou... au rythme de 727 hachages par seconde mais c'est normal car cette console n'a jamais été pensée pour ce genre de calcul. Pour vous donner une idée, un PC moderne avec un GPU décent va environ 30 millions de fois plus vite, soit des milliards de tentatives par seconde.
Alors que la GBA, elle, met une bonne vingtaine de minutes à avaler toute sa liste de 1 million de mots.
Après côté bidouille c'est assez fort car, certes, la wordlist de 8 Mo tient dans la cartouche, mais faire tourner une routine SHA-256 propre sur une puce aussi poussive, avec ses malheureux 288 Ko de RAM pour bosser, il faut le vouloir ! Solst-ice s'est donc appuyé sur le moteur Butano, un framework C++ open source taillé pour développer des jeux GBA, qu'il a détourné pour faire mouliner des hashs à la place de sprites.
Et voilà, ce projet loufoque rejoint la longue tradition des gens qui font faire n'importe quoi à leur Game Boy Advance, comme ce clavier GBA à monter soi-même que je vous montrais récemment.
Bref, comme un ministre ou un notaire, ça ne sert strictement à rien, et c'est pour ça qu'on kiffe ! Le code est sur le GitHub de solst-ice si vous voulez jouer.
Vous branchez une clé USB sur un PC, vous démarrez dessus, et le temps de vous servir un petit café, hop, tout le contenu de la mémoire vive est recopié sur la clé. Le rêve pour les gens qui font du forensic, car dans la RAM on trouve des mots de passe, des clés de chiffrement et tout ce qui traîne. De quoi choper de sérieux indices !
Parce que oui, si vous pensiez être bien tranquille avec votre disque chiffré grâce à BitLocker, FileVault ou LUKS, sachez que la clé de déchiffrement se balade en clair dans la RAM. Pas la peine de casser de la crypto quand il suffit d'aller cueillir la clé là où elle traîne. C'est cet angle mort qu' ElcomSoft exploitait déjà en 2012 pour cracker TrueCrypt et BitLocker .
Sauf que pour aller cueillir cette clé, encore faut-il que la machine soit allumée, non ?
Eh bien pas forcément car contrairement à ce qu'on croit, la RAM ne s'efface pas d'un coup quand on coupe le courant.
Hé oui, les données restent lisibles plusieurs secondes, voire une minute, ce qui est largement suffisant pour récupérer des infos importantes. Et si vous refroidissez les barrettes (par exemple jusqu'à -60°C avec de l'azote liquide), le contenu peut tenir plusieurs heures !!
Ce phénomène n'a rien de neuf. On appelle ça une cold boot attack, et ce sont des chercheurs de Princeton qui l'ont mise en lumière dès 2008, en révélant un truc totalement contre-intuitif : une mémoire vive censée se vider dès qu'on l'éteint, garde en réalité ses secrets bien après.
Alors on va me dire que tout ça, c'est mitigé depuis des lustres : Le scrubbing mémoire au boot, où le firmware écrase la RAM au démarrage, les clés planquées dans les registres du CPU façon TRESOR, le chiffrement mémoire chez Intel et AMD, les barrettes carrément soudées à la carte mère... les parades existent, c'est vrai. Sauf qu'en 2018, deux chercheurs de F-Secure ont remis une pièce dans la machine en montrant comment désactiver ce fameux scrubbing sur quasiment tous les ordi portables modernes, Dell, Lenovo et même les Mac.
Et c'est là qu'arrive BareMetal RAM Dumper, un outil signé pIat0n qui rejoue justement cette vieille attaque de 2008. Le truc tient dans 5 Ko d'assembleur x86 et démarre directement sur le BIOS en mode legacy, avant de basculer en unreal mode pour aller taper dans toute la mémoire au-dessus de 1 Mo.
La récupération totale ne dépassera pas 4 Go par contre, car l'unreal mode ne grimpe pas plus haut, mais en général c'est bien suffisant pour repêcher quelques clés d'accès. Et surtout, ça fait gagner un temps fou aux gens qui font du forensic : plus besoin d'un labo dédié, une clé USB et le tour est joué. Ça rejoint donc la longue liste des façons d'ouvrir un disque soi-disant blindé, comme BitPixie qui déverrouille BitLocker en cinq minutes .
Bref, c'est aussi une bonne piqûre de rappel qu'un chiffrement ne protège vraiment vos données que quand la machine est éteinte pour de bon. Le code est sur GitHub sous licence AGPL !
Il y a des gens qui se détendent en regardant une petite série. Aaron Christophel, lui, se détend en désossant des bracelets connectés Xiaomi pour leur faire cracher du code qu'aucun ingénieur de la marque n'avait prévu.
Ce bidouilleur allemand, plus connu sous le pseudo atc1441, vient de s'attaquer au Mi Band 10, et il en a tiré ce que la communauté du hack matériel considère comme le sacre suprême depuis trente ans : un portage de Doom, le jeu de tir sorti en 1993.
Le jeu n'était pourtant pas le problème. La puce, si.
Le Mi Band 10 utilise un BES2700iMP, un composant fabriqué par Bestechnic, un fondeur chinois qu'on croise surtout dans des écouteurs sans fil parce qu'il est taillé pour la basse consommation. Petite subtilité qui complique tout : chez Bestechnic, cette même puce répond aussi au nom de code BEST1503.
Or pour programmer un composant pareil, il faut son SDK, autrement dit le kit fourni par le fabricant avec la documentation et les outils pour développer dessus. Et là, surprise : pour ce modèle, aucun SDK public. Rien du tout. Christophel s'est donc retrouvé face à une puce muette, sans plan ni notice.
Sa porte d'entrée, il l'a trouvée du côté d'une cousine quasi jumelle. Le BEST1306, un autre composant Bestechnic, partage la même architecture, et lui possède un SDK qui a fuité par le biais de kits de développement audio. En recoupant patiemment les deux, il a reconstitué par rétro-ingénierie, ce travail qui consiste à remonter le fonctionnement interne d'un appareil sans en avoir les plans, un SDK compatible avec le BES2700iMP.
Le reste a suivi. Firmware maison, c'est-à-dire le logiciel bas niveau qui pilote directement le matériel, puis portage de Doom via le projet GBADoom. Tout n'est pas nickel pour autant : l'écran fonctionne en SPI un seul bit au lieu du quad-SPI dont il est capable, deux manières d'envoyer les pixels dont la seconde va nettement plus vite, ce qui plombe ici la fluidité et écrase les couleurs.
Screenshot
Bref, ça se joue, mais c'est moche. Et sur une dalle large de quelques centimètres, on reste évidemment dans l'exploit pour l'exploit plus que dans la séance de jeu.
Le détail qui fait un peu marrer vu le contexte actuel, c'est l'aveu de Christophel sur l'intelligence artificielle : elle ne lui a quasiment servi à rien. Les données techniques de ces puces propriétaires n'existent nulle part dans les corpus d'entraînement des modèles, du coup les assistants brassaient du vide.
Et ce n'est pas fini. Le Mi Band 9 embarque exactement le même matériel, ce qui signifie que le SDK reconstitué devrait y tourner tel quel, sans toucher une ligne. Tout est documenté et publié sur GitHub, à la disposition de quiconque veut prolonger cette bien belle aventure.
Bref, faire tourner un jeu de 1993 sur un bracelet de sport ne sert objectivement à rien, et c'est précisément pour ça que c'est toujours très cool.
Source : Hackaday
Le FBI possède sa propre ville, sauf que personne n'y habite, et pour cause, elle a été montée de toutes pièces dans un hangar de Huntsville, en Alabama, avec ses maisons meublées, son hôtel, sa station-service, son épicerie, son tribunal, son hôpital et jusqu'à sa compagnie d'électricité, le tout dans un seul but assez vertigineux, la pirater dans tous les sens sans jamais déranger âme qui vive.
Le décor porte d'ailleurs un nom, le Kinetic Cyber Range, près de 2 000 mètres carrés de fausse bourgade américaine ouverte en février 2025 et pensée comme un gigantesque bac à sable pour cyberattaques en conditions réelles.
Rien là-dedans n'est pourtant en toc, puisque chaque bâtiment grouille d'appareils et de systèmes qui réagissent exactement comme dans une vraie commune ou une vraie entreprise, à une nuance près, tout reste confiné à l'intérieur pour qu'une attaque lancée pendant un exercice de derappe jamais et impacte de vrais habitants.
Le nom vient justement de là, puisque le terme kinetic renvoie aux dégâts bien physiques d'un piratage, ce moment où une simple ligne de code éteint un feu rouge, bloque une pompe à eau ou plante les machines d'un hôpital.
Au cœur du dispositif, on trouve du coup une salle bourrée de plus de 200 serveurs physiques, ces gros ordinateurs qui font tourner les services d'une entreprise, pour moitié sous Windows et pour moitié sous Linux, histoire de coller au capharnaüm que les enquêteurs découvrent réellement quand ils débarquent après une intrusion ou avec un mandat de perquisition. Le responsable du site, Dave Beachboard, n'enjolive d'ailleurs rien et décrit des salles froides, exiguës, bruyantes et sombres, bref aussi pénibles que dans la vraie vie.
Plus de 1 400 personnes y sont quand même déjà passées, des agents du FBI mais pas seulement, puisque s'y ajoutent des collègues d'autres administrations fédérales et locales venus s'entraîner sur le terrain.
Le gros morceau de la formation, ce sont les rançongiciels, ces logiciels qui prennent vos fichiers en otage et réclament une rançon pour vous les rendre, l'objectif étant d'apprendre à garder son sang-froid pendant qu'une attaque se déroule sous les yeux tout en travaillant la criminalistique numérique, c'est-à-dire l'art de fouiller une machine après le passage des pirates pour reconstituer qui a fait quoi.
Si le FBI se donne autant de mal, c'est que c'est un problème massif, son rapport sur la cybercriminalité chiffre les pertes américaines à près de 21 milliards de dollars sur l'année et place les rançongiciels en tête des menaces qui visent les infrastructures critiques, ces hôpitaux, réseaux électriques et stations d'eau dont on oublie l'importance jusqu'au jour où ils s'arrêtent net.
Bref, bâtir une ville entière dans le seul but de la pirater, c'est quand même assez fou.
Source : TechCrunch
Si vous faites un peu de renseignements (OSINT) et que ce que vous cherchez, c'est des pseudos de cybercriminels, spmedia a un truc qui devrait vous plaire. Son repo GitHub Threat-Actor-Usernames-Scrape rassemble environ 773 000 pseudos uniques récupérés sur des forums de cybercriminels. C'est gratuit, en accès libre. Et ça peut vous faire gagner pas mal de temps si vous faites de l' OSINT .
Son délire, c'est de scraper les sections "Who's Online", les threads et les réponses de forums comme HackForums, DarkForums, BreachForums, XSS.pro, Dread, OGUsers et une vingtaine d'autres, ou de récupérer des extraits de fuites. L'intérêt de ce genre de truc, c'est de capter ces données pour ensuite les réutiliser dans vos propres projets. Ça vous permet par exemple de préparer un fichier texte propre par forum, qui est prêt à être ingéré dans un TIP (Threat Intelligence Platform) ou croisé avec vos données.
Au total, y'a environ 820 000 noms d'utilisateurs dans ce repo, dont ~46 000 en double. Les plus gros forums actifs sont Cracked.sh (~226 000 pseudos collectés), DarkForums.su (~75 000) et Altenen.is (~74 000). Côté forums morts, BreachForums.st domine avec ~57 000 entrées, devant la fuite Nulled (~42 000) et BreachForums.as (~39 000).
Il y a de quoi fouiller, quoi...
Spmedia a monté ce projet parce qu'il en avait marre des boîtes de threat intel qui facturent 5 à 6 chiffres par an pour accéder au même genre de données. On peut donc lui dire merci, même si ça ne remplace pas un vrai service CTI avec contexte et analyse. C'est juste des noms d'utilisateur sans autre enrichissement. Faudra donc croiser ça avec d'autres sources mais pour du pistage de pseudo ou une wordlist ciblée, ça peut aider.
Vous pouvez par exemple utiliser ces listes pour repérer un même pseudo sur plusieurs forums, constituer des wordlists ou simplement suivre quels sites ressortent après un takedown. Certains disparaissent, d'autres reviennent 48h plus tard sous un nouveau TLD (ambiance hydre de lerne, quoi).
Chaque fichier contient un pseudo par ligne et l'import dans un SIEM ou un script Python vous prendra 2 minutes. N'oubliez pas non plus qu'une bonne partie de ces comptes sont des kiddies ou des curieux, donc croisez toujours avec d'autres sources avant de pointer du doigt qui que ce soit...
Bref, si la chasse aux cybercriminels vous branche, vous pouvez récupérer les listes sur GitHub et voir ce que ça donne.
Amusez-vous bien !
Les Bus Pirate , si vous ne connaissez pas encore, ce sont des petites sondes que les bidouilleurs utilisent pour "parler" à des puces inconnues, lire une EEPROM ou dumper des firmwares. C'est assez spécifique comme matos, alors c'est pourquoi geo-tp a eu une autre idée, à savoir foutre l'équivalent d'un Bus Pirate dans un ESP32 pour en faire un Cardputer (contraction de "card" + "computer") de hacker.
Bus Pirate
Et voilà comme son bébé, nommé Bit Pirate transforme un ESP32, c'est à dire une carte à 30 balles en multitool de hacking matériel qui cause plus de 20 protocoles.
Grâce à ça, vous pouvez vous brancher sur n'importe quelle puce et lire / modifier ce qu'elle contient, sans dessouder tout l'appareil. Côté bus numériques, vous avez le I2C (scan, glitch, dump d'une EEPROM 24Cxx), le SPI pour lire une flash 25Q ou une carte SD, l'UART avec auto-détection du baudrate, le 1-Wire et le JTAG/SWD compatible OpenOCD.
Bref, en un seul firmware, il remplace une palanquée de petits outils dédiés.
Côté radio, c'est aussi beaucoup plus musclé, mais attention, tout ne sort pas d'une ESP32 nue. Le Wi-Fi (sniff, deauth), le Bluetooth (BLE HID, spoofing) et l'infrarouge tournent direct sur l'ESP32 mais le Sub-GHz, le RFID, le bus CAN d'une bagnole ou le dump d'une carte SIM nécessiteront des puces spécifiques en plus (un CC1101, un PN532, un transceiver, un peu de câblage...etc), ou une carte qui les embarque déjà comme la LILYGO T-Embed CC1101.
Forcément, j'imagine qu'en lisant ça, vous pensez au Flipper Zero mais c'est pas vraiment le même objet. Le Flipper, c'est un produit fini, boîtier, batterie, interface léchée, et lui aussi est open source d'ailleurs. Alors que le Bit Pirate, c'est plus brut, avec des fils qui dépassent, un firmware en plein chantier...etc... C'est plus un outil de bench pour bidouilleurs, qu'un gadget clé en main et surtout la vraie différence, c'est le prix et le fait que ça tourne sur du matériel tout ce qu'il y a de plus banal.
Ça marche donc sur un ESP32-S3 nu, mais le combo qui fait rêver c'est le M5 Cardputer , ce mini-ordinateur avec clavier vendu autour de 30 euros. Vous le flashez, et hop, vous avez un Bus Pirate autonome avec écran et clavier dans la poche !
A titre de comparaison, un Flipper Zero, c'est plutôt dans les 200 balles donc y'a pas photo. Et pour l'installer, pas besoin de toolchain, puisque geo-tp a mis en ligne un flasher web qui déploie le firmware depuis le navigateur en un clic, via Web Serial (oui, la même techno qui débarque enfin dans Firefox ).
Ensuite une fois que le firmware est en place sur votre matos, vous pilotez la bête de 3 façons : soit via un terminal série classique, soit une CLI web par Wi-Fi, ou en standalone sur le clavier du Cardputer.
Les trois disposent exactement des mêmes commandes et pour les petits feignants surproductifs TDAH que vous êtes, rassurez-vous ça se scripte, soit en bytecode façon Bus Pirate historique, soit en Python par-dessus le port série pour automatiser un dump de flash. Et notez qu'il sait aussi se faire passer pour un simple dongle USB-UART, un programmateur SPI ou un analyseur logique quand vous avez juste besoin de ça.
Le firmware Bit Pirate aura besoin d'au moins 8 Mo de flash, et attention à la tension, car l'ESP32 bosse en 3,3V sur ses broches, donc pour taquiner un bus en 5V il vous faudra une carte ou un module prévus pour, sinon vous cramerez la puce. Et selon le modèle que vous choisissez, vous n'aurez pas forcement le même nombre de broches GPIO donc le brochage demandera parfois un peu d'ajustement. Et niveau radio, sniffer le Wi-Fi du voisin ou rejouer un signal Sub-GHz dans la nature, c'est interdit sachez le !! Donc les mêmes précautions qu'avec un Flipper Zero s'appliquent.
C'est surtout pour tester votre propre matériel et apprendre, et pas pour faire le malin et finir en zonzon.
Bref, si le hacking matériel vous démange, sachez que Bit Pirate c'est open source, que le matos n'est pas cher et que ça s'installe facilement grâce au flasher web... Ce serait donc dommage de vous en priver...
Merci à Nicolas pour le lien !
Daniel Estévez est ce qu'on appelle un radioamateur de haut vol. Spécialisé dans le décodage de signaux satellites et de sondes spatiales, l'Espagnol partage ses analyses techniques sur son blog depuis plusieurs années.
Cette fois, il s'est attaqué à un gros morceau : la télémétrie de Tianwen-2, la sonde chinoise actuellement en route vers l'astéroïde géocroiseur Kamo'oalewa.
Pour capter le signal, Estévez s'est appuyé sur le radiotélescope de Dwingeloo, aux Pays-Bas. Cette antenne historique, construite en 1956 par les radioastronomes néerlandais et longtemps abandonnée, a été remise en service par une association de passionnés qui l'utilise en particulier pour suivre les missions spatiales lointaines. La sonde émet en bande X (une plage de fréquences radio utilisée par la plupart des engins interplanétaires), autour de 8428,19 MHz, soit pratiquement la même fréquence que sa grande sœur Tianwen-1.
Là où ça devient intéressant techniquement, c'est sur l'encodage du signal. Tianwen-1 utilisait un encodage Reed-Solomon (une méthode classique de correction d'erreurs, indispensable quand le signal voyage sur des centaines de millions de kilomètres) avec une astuce un peu bricolée qui obligeait à zapper certains octets pour faire rentrer le tout dans la trame.
Tianwen-2, elle, utilise un encodage concaténé avec une longueur de trame mieux pensée. Du coup, les codewords Reed-Solomon rentrent pile-poil, sans bidouillage. C'est un détail qui peut sembler insignifiant, mais ça simplifie la vie de tout radioamateur qui veut suivre la mission depuis chez lui.
La sonde a été lancée le 28 mai 2025 et doit atteindre Kamo'oalewa en juin 2026. L'objectif est ambitieux : prélever un échantillon et le ramener sur Terre, comme l'avait fait la mission japonaise Hayabusa2 sur Ryugu en 2020.
Mais Tianwen-2 vise encore plus loin. Après Kamo'oalewa, la sonde poursuivra sa route vers la comète 311P/PANSTARRS pour une étude rapprochée, dans une mission double assez inédite. Si l'opération réussit, ce sera une nouvelle étape importante pour le programme spatial chinois, qui enchaîne les missions depuis plusieurs années.
Estévez documente tout publiquement, avec les paramètres exacts du signal, les outils utilisés (essentiellement GNU Radio, un framework open-source de traitement de signal), et les écueils techniques rencontrés. Pour les passionnés, c'est une mine d'or. Pour les autres, c'est surtout une démonstration que l'observation spatiale n'est plus l'apanage des agences gouvernementales.
Source : Hackaday
Y'a des entreprises qui claquent des millions pour bien aligner leurs modèles d'IA afin qu'ils refusent toutes les questions sensibles qui font flipper nos amis puritains d'outre-Atlantique et y'a Heretic , un outil signé Philipp Emanuel Weidmann, qui balaye toute censure sur n'importe quel modèle en moins de 30 minutes avec une simple carte graphique de gamer.
Je vous explique... Vous devez avoir Python et une version récente de PyTorch sur votre machine, puis vous tapez pip install heretic-llm, puis heretic Qwen/Qwen3-4B-Instruct-2507 avec le nom du modèle que vous voulez décensurer.
Et l'outil fait alors sa vie et 20 à 30 minutes plus tard, vous récupérez une version du modèle qui a lâché prise sur l'essentiel de ses refus. Pas de dataset à préparer et surtout pas besoin de comprendre les entrailles d'un transformer, avec ce truc !
Dans un modèle aligné, le réflexe de refuser (le fameux "désolé, je ne peux pas vous aider avec ça") correspond souvent à une direction précise dans ses calculs internes. Les chercheurs appellent ça la "direction de refus". Et l'idée de l'abliteration, c'est de repérer cette direction et de la gommer des poids du modèle. En gros, on coupe le câble qui déclenche le "non", en touchant le moins possible au reste.
D'autres outils d'abliteration existaient déjà , mais leur réglage restait largement manuel et il y a aussi des gens comme mlabonne ou huihui-ai qui publient des modèles décensurés en ajustant les paramètres à la main, modèle par modèle, avec des résultats souvent inégaux. Mais Heretic, lui, automatise complètement le réglage. Pour cela, il s'appuie sur Optuna, un framework d'optimisation qui teste des dizaines de configurations et garde les meilleures tout seul. Et son seul objectif c'est de virer un max de refus tout en abîmant le moins possible le modèle d'origine.
Et de ce que je comprends, ça marche super bien ! Sur Gemma-3-12B, le modèle de Google de base refuse 97 fois sur 100 les prompts sensibles du benchmark maison. Mais après un petit passage dans Heretic, il tombe à 3 refus sur 100, soit le même niveau que les meilleures "nettoyages" manuels.
Et surtout, Heretic affiche une divergence de 0,16 là où les versions faites main grimpent à 0,45 voire 1,04 (C'est une mesure de l'écart de comportement sur les questions normales... plus c'est bas, mieux c'est).
Cela veut donc dire qu'il abîme beaucoup moins le modèle au passage.
Maintenant, tous les modèles n'y passent pas, car un gros calibre demande bien plus de VRAM et cela peut grimper à plusieurs heures. De plus, une étude comparative récente montre que le raisonnement mathématique est ce qui souffre le plus de ce genre d'abliteration, quel que soit l'outil utilisé.
Et surtout, y'a déjà des chercheurs qui bossent sur des défenses pour rendre les modèles résistants à ce genre d'attaque. Donc on verra bien, mais tant que c'est possible autant en profiter car des modèles sans bridage, ça permet notamment à des chercheurs d'étudier leurs propres failles, ou pour des usages du quotidien, de faire passer des demandes banales qui seraient bloquées (genre texte créatif, reverse engineering ou demande de conseils médicaux, ce genre de choses...)
Voilà, si vous bidouillez du LLM en local , allez voir ce projet car ça peut vous "ouvrir" quelques portes ^^.
Un développeur connu sous le pseudo ThroatyMumbo a réussi à porter Windows CE 2.11, un Windows allégé que Microsoft avait sorti à la fin des années 90 pour les petits assistants personnels et certains routeurs, sur une vraie console Nintendo 64
On ne parle pas d'un émulateur ici, mais bien d'une N64 qui démarre sur un vrai bureau Windows, avec sa barre des tâches, son explorateur de fichiers et la possibilité de lancer des programmes CE.
Pour bien comprendre le délire, il faut savoir que la N64 et Windows n'ont pas grand chose en commun. La console utilise un processeur MIPS et un système maison signé Nintendo. Windows CE, c'est l'inverse : un système Microsoft conçu pour tourner sur des appareils embarqués comme les assistants personnels.
Sauf que les deux mondes se croisent sur deux points clés. Windows CE tournait déjà sur des puces MIPS à l'époque, et il était conçu pour vivre avec à peine 1 Mo de RAM, ce qui correspond pile aux capacités de la N64. ThroatyMumbo s'est inspiré de l'IBM Workpad Z50, un ancien assistant qui tournait sous CE sur du MIPS, pour se dire que le portage était techniquement faisable.
Côté méthode, le kernel Windows CE d'origine n'est pas modifié. Tout le travail est dans la couche d'abstraction matérielle, la fameuse HAL, qui sert d'interface entre le système et le matériel. Le développeur a écrit la sienne de zéro pour la N64 : démarrage, gestion des interruptions, du timing, de l'affichage.
Le contrôleur N64 devient une souris (le bouton A pour clic gauche, le B pour clic droit, logique). L'EverDrive-64 X7, une cartouche qui fait office de lecteur SD, sert de disque dur. Et le son passe par la puce audio d'origine de la console.
Ce qui marche est franchement bluffant : déplacer les fenêtres, fermer une boîte de dialogue, naviguer dans les fichiers, lancer des exécutables CE tiers, et même afficher une démo 3D qui utilise la puce graphique de la console. Ce qui ne marche pas : pas de clavier physique, pas de réseau, et il faut le SDK Windows CE 2.11 de Microsoft, qui n'est plus commercialisé depuis longtemps.
Aucune utilité concrète, évidemment. Personne ne va remplacer Mario Kart 64 par Word pour Windows CE. Mais c'est rigolo, et permet de prouver qu'on peut faire un truc complètement absurde, juste parce que c'est techniquement intéressant.
Source : Hackaday
PS5-Linux est là !!
Andy Nguyen, le security engineer alias theflow0, vient de publier le hack qui transforme une PS5 Phat (les modèles originaux, pas les Slim ni les Pro) en PC 100% Linux. Et le truc cool c'est que ça marche désormais sur les firmwares 3.xx et 4.xx, et pas seulement sur les premières consoles oubliées dans leur boîte !
Pour rappel, en mars dernier, Andy Nguyen avait fait tourner GTA 5 Enhanced en ray tracing sur sa PS5 , mais l'exploit était limité aux firmwares 1.xx et 2.xx, donc autant dire à des consoles qui n'avaient jamais vu Internet. Mais depuis hier, le projet est officiellement sorti sur GitHub avec un guide d'installation complet, et il a élargi son périmètre.
Concrètement, le hack utilise une vulnérabilité patchée de l'hyperviseur PS5 (corrigée dans les firmwares récents, d'où la liste fermée) pour débloquer le hardware. Une fois en place, la PS5 expose son CPU 8 cores (16 threads) à 3.5 GHz max et son GPU à 2.23 GHz max (les fréquences de boost de la console, en pratique ça tape souvent un peu plus bas pour éviter la surchauffe), ce qui suffit largement pour faire tourner Steam et des émulateurs sans que ça rame.
Et surtout, la sortie HDMI 4K à 60 Hz fonctionne, l'audio aussi, et tous les ports USB de la console sont opérationnels !
Côté firmwares supportés, c'est précis, attention ! Les versions 3.00, 3.10, 3.20 et 3.21 fonctionnent, mais sans support M.2. Les versions 4.00, 4.02, 4.03, 4.50 et 4.51, elles, supportent en plus le SSD M.2 dédié à Linux.
Du coup, plus la console est récente dans cette plage, plus on a de flexibilité. Pour les firmwares 5.xx, ça pourrait ensuite arriver plus tard, mais Linux tournera dans un environnement virtualisé restreint à côté de GameOS, donc avec des perfs et des fonctionnalités un peu dégradées.
Maintenant, pour vérifier votre firmware avant de tenter le coup, c'est dans Paramètres > Système > Informations console.
Pour l'install, il vous faudra une clé USB de 64 Go minimum (un SSD externe est recommandé), un clavier/souris USB, un adaptateur Ethernet ou Wi-Fi USB, et en option un dongle Bluetooth si vous voulez utiliser la DualSense. Le Bluetooth interne de la PS5 n'est pas encore supporté par contre.
Les ports recommandés pour booter sont l'USB Type-C en bas à l'avant ou les Type-A à l'arrière.
Pour réussir ce tour de passe-passe, l'exploit passe par
umtx2
, qui simule un faux DNS sur l'URL manuals.playstation.net pour envoyer le payload via socat. Du pur travail de hacker, mais le README est plutôt bien fichu et vous tiendra la main tout au long de l'install.
Évidemment, c'est encore expérimental.... Pas de dual-boot, donc il faut relancer l'exploit à chaque démarrage en mode Linux, le mode standby ne fonctionne pas, le screen saver est buggé, et certains écrans ont du mal avec la sortie HDMI. C'est donc pas pour du grand public et il vaut mieux être à l'aise avec la ligne de commande pour s'y mettre.
Reste que voir Andy Nguyen continuer son bon boulot sur la sécurité de la PlayStation, c'est toujours cool. Le mec est derrière plusieurs jailbreaks PS4 et début PS5, et combiné avec la fuite des clés BootROM PS5 fin 2025 , l'écosystème commence enfin à respirer un air plus "libre".
Donc si vous avez une PS5 Phat sortie entre 2020 et début 2022 qui traîne avec un firmware d'époque, c'est peut-être le moment de la ressortir du placard.
Source : Notebookcheck
478 binaires Unix peuvent servir à devenir root sur un système mal configuré.
C'est ce que recense GTFOBins , le projet open source monté par Emilio Pinna et Andrea Cardaci, qui est devenu LE bookmark obligatoire de tout pentester Linux.
Ce ne sont pas des exploits, hein, mais juste des fonctions parfaitement légitimes de programmes installés partout, et qui dans le bon contexte (genre un bit SUID oublié, qui fait tourner un binaire avec les droits du propriétaire, souvent root) permettent de spawner un shell, lire un fichier protégé, ou grimper d'un cran dans la hiérarchie des privilèges. Petit rappel quand même, faut déjà avoir un pied sur la machine, ce n'est pas une porte d'entrée magique depuis Internet.
Une fois sur leur site, vous tapez le nom d'un binaire dans le moteur de filtre (ou vous cliquez sur une fonction), et hop, vous tombez sur les commandes exactes à recopier-coller, et c'est plié en moins de dix secondes.
Par exemple, si votre cible a un sudo find sans mot de passe, le site vous donne sur un plateau d'argent sudo find . -exec /bin/sh \; -quit.
Un mawk qui tourne en SUID root ? Direct, mawk 'BEGIN {system("/bin/sh")}' et bonjour le shell privilégié. Un vim mal configuré (compilé avec le support Python ou Lua, ce qui est le cas dans la plupart des distros desktop) ? La page documente comment l'utiliser via :py ou :lua pour exécuter du code arbitraire et retomber sur ses pattes.
C'est donc la fin des recherches désespérées sur StackOverflow à 3h du matin pendant un CTF...
La philosophie de ce projet est claire... on ne casse rien, on détourne juste l'usage prévu. Le hic, c'est que la frontière entre détournement et exploitation est mince quand un sudoers mal écrit donne accès à un binaire trop puissant.
Les 478 binaires sont rangés selon 11 fonctions et 4 contextes d'exécution. Côté fonctions, vous avez : Shell (228 binaires permettent de spawner un shell, oui presque la moitié du catalogue), File-read (199), File-write (84), Inherit (71), Upload (34), Download (32), Command (30), Reverse-shell (21), Privilege-escalation (14), Library-load (11), et Bind-shell (7). Côté contextes : Unprivileged, Sudo, SUID, et Capabilities.
Et sur la page d'un binaire, chaque case du tableau vous dit super clairement "voilà comment t'en sors selon ce que tu as sous la main".
Les champions toutes catégories ce sont les langages interprétés et les shells eux-mêmes. zsh, socat, ruby, python, php, node, lua plus bash, tous cumulent 7 fonctions différentes chacun. C'est logique, dès que vous avez un interpréteur sous la main vous pouvez faire à peu près tout (lire, écrire, exécuter, ouvrir une socket).
D'ailleurs c'est pour ça que les sysadmins paranoïaques tirent une tête bizarre quand on leur dit qu'on a installé Python sur un serveur de prod sans cas d'usage explicite. Pfff... je les comprends, un Python qui traîne sur un serveur Debian avec un sudo NOPASSWD au-dessus, c'est game over en trois lignes.
Y'a un autre détail que je trouve cool également, c'est l'intégration
MITRE ATT&CK
. Chaque fonction du site est mappée à une technique du framework officiel, accessible via /mitre.json.
Donc pour les blue teams qui veulent justifier une règle de détection en réunion, c'est tout simplement cadeau !! Et pour ceux qui automatisent leurs scans, l'API JSON complète est dispo sur /api.json, du coup vous pouvez parser les 478 entrées avec un jq ou un petit script Python pour générer des règles de monitoring custom.
Bref, GTFOBins c'est aussi un cadeau pour les défenseurs, à condition de retourner la logique du projet. Voilà, ça vaut le coup d'y passer dix minutes par mois sur un audit.
Pour les Windowsiens qui se sentent oubliés, sachez que l'équivalent existe et s'appelle LOLBAS (Living Off The Land Binaries And Scripts), bien suivi par les analystes Windows depuis 2018. Même philosophie, même format, même utilité, juste appliqué aux exécutables Microsoft signés que Windows installe par défaut.
Les deux projets se citent mutuellement et forment ensemble la cartographie communautaire des techniques de Living Off The Land cross-OS. Si vous bossez sur les deux côtés du fossé, gardez les deux onglets ouverts en permanence ^^ !
Maintenant si l'angle élévation de privilèges via shell restreint vous intéresse, j'avais déjà couvert une vieille faille sudo qui permettait carrément de sortir d'un chroot , et plus largement la bibliothèque Payloads All The Things qui complète bien GTFOBins sur tout ce qui est exploitation web et post-exploitation. Les deux projets sont complémentaires, GTFOBins se concentre sur les binaires Unix et les abus locaux de fonctionnalités légitimes (shells, transferts, lectures, élévation conditionnelle), PayloadsAllTheThings ratisse plus large côté exploitation web.
Côté admin, le réflexe utile, à vrai dire c'est de lister vos binaires SUID avec find / -perm -4000 -type f 2>/dev/null, vérifier /etc/sudoers plus les fichiers /etc/sudoers.d/* avec sudo -l, puis de passer chaque candidat dans le filtre GTFOBins.
Si une entrée matche, c'est qu'il y a une fuite potentielle à boucher. Attention quand même, l'absence dans GTFOBins ne valide pas une règle sudo ou un SUID custom (wildcards, variables d'env, paths inscriptibles peuvent toujours créer un chemin d'évasion). Bref, c'est à faire avant de filer le moindre sudo NOPASSWD à quelqu'un !
pgAdmin, l'outil "officiel" pour administrer vos bases PostgreSQL, c'est le type d'interface qu'on n'a pas vraiment envie d'ouvrir un lundi matin ! C'est lent, c'est cheum de ouf en mode figé dans les années 2000 et ça rame sérieusement dès qu'on tente un export un peu costaud. Alors oui je sais, DBeaver, c'est plus joli, mais faut se coltiner Java et un workspace qui traîne au démarrage.
Du coup quand bbDump est passé sur mon radar, j'ai eu envie de creuser un peu. C'est un gestionnaire PostgreSQL moderne, en Electron + Vue + TypeScript, signé par Poups, un dev indé français. L'outil reprend tout ce que vous faites habituellement en CLI (pg_dump, pg_restore, coups d'œil aux tables, schéma de la DB) et met ça dans une interface vraiment propre.
Le dashboard bbDump, tout de suite plus respirable que pgAdmin
Côté fonctionnalités classiques, vous avez ce qu'on attend d'un client PostgreSQL correct. Gestion multi-bases organisée par projet, backups avec liste, restauration, filtre par base, tailles et dates. De leur côté, les tâches planifiées via expressions cron sont configurables par base, et il y a même une visionneuse de logs en temps réel qui trace chaque opération pg_dump.
Ajoutez à ça un navigateur de tables avec édition inline (avec support complet des types), un constructeur de requêtes SQL visuel en plus de l'éditeur brut, l'export CSV, et un diagramme entité-relation interactif via Vue Flow pour visualiser les tables et les clés étrangères. Grâce à bbDump, plus besoin d'aller chercher un outil externe pour comprendre une base héritée d'un projet qui traîne !!
Le schema visualizer en mode ERD interactif, pratique pour décortiquer une base héritée
Mais le vrai twist, c'est l'intégration du MCP (Model Context Protocol) puisque bbDump expose 31 outils MCP aux agents IA, ce qui veut dire que votre Claude d'amour ou votre LLM peut interroger la DB, regarder un schéma, tester une requête. Et comme les mutations passent par un système de confirmation, pas de DROP TABLE à l'insu de votre plein gré !
Je vous avais déjà parlé de cette approche avec Ghidra MCP côté reverse engineering et BrowserWing côté automatisation navigateur. bbDump rejoint donc la famille côté backend de données.
Autre détail sympa, le dev a pensé à la sécurité puisque les backups sont chiffrés en AES-256-GCM, donc si vous synchronisez vos dumps sur un cloud random, pas de panique sur les données sensibles. Sur macOS, y'a même une mini-app menu bar pour accéder aux bases et aux connexions proxy sans ouvrir l'app complète.
Côté installation, c'est facile :
curl -fsSL https://poups.dev/bbdump.sh | bash
sur macOS et Linux (qui reste en beta). Bien sûr, si balancer un script dans bash direct vous fait tiquer (normal), vous pouvez aussi chopper le DMG ou l'AppImage en release sur GitHub et inspecter avant. Le code est sous licence MIT, avec une doc dédiée et une page Ko-fi si vous voulez soutenir le projet. Par contre, rien pour Windows pour l'instant.
Le projet est encore tout jeune puisque sorti fin mars de cette année donc si vous cherchez un outil ultra-stable pour une prod critique, attendez un peu. Mais pour vos projets perso, votre dev local, ou juste pour arrêter de râler sur pgAdmin, ça vaut clairement le coup d'œil.
Bref, un dev français de talent qui se lance en indé sur un créneau pourri d'outils vieillots, avec une vision cohérente et une intégration MCP propre, moi j'aime bien. Je pense que Poups mérite d'être soutenu sur ce coup-là, d'où mon article !
La chaîne YouTube Works By Design vient de sortir un projet qui fait pas mal jaser chez les passionnés de crochetage : une serrure dont le cylindre se met littéralement en position fermée après que la clé ait été tournée, rendant l'accès aux goupilles quasi impossible pour n'importe quel individu qui tente de la manipuler sans la bonne clé.
Le principe est assez simple. Quand vous glissez la clé dans la serrure, elle se fixe grâce à un système de magnétisme commutable. C'est le genre de mécanisme qu'on trouve sur les bases magnétiques utilisées en usinage.
Une fois tournée, la clé bascule l'ensemble dans une configuration où le canal d'entrée est masqué. Du coup, même un crocheteur expérimenté avec ses tensors et ses picks classiques se retrouve face à une paroi complètement aveugle. Works By Design a aussi ajouté un système anti-bumping pour couper court à une éventuelle attaque par percussion.
Avant d'arriver à la version définitive, le créateur a imprimé plusieurs prototypes en 3D pour valider le mécanisme, puis il a fini par usiner la version finale en métal en CNC. Un serrurier à qui il avait envoyé le modèle CAO en amont n'avait pas réussi à identifier de vulnérabilité évidente. Premier bon signe.
Sauf que voilà, quand les serrures tests ont été distribuées à la communauté Lock Pickers United (qui rassemble une bonne partie des meilleurs crocheteurs amateurs du monde), certains ont pointé une faille potentielle : l'attaque par impressioning, où l'attaquant utilise une clé vierge pour marquer progressivement l'empreinte des goupilles.
Côté solidité, plusieurs commentateurs doutent de la fiabilité du système magnétique sur le long terme, surtout avec l'usure et la poussière qui viendraient s'y loger.
La serrure reste donc en phase d'évaluation à grande échelle. Historiquement, les innovations en serrurerie finissent quasi toutes par tomber, c'est une question de temps avant que quelqu'un trouve l'angle d'attaque. Mais l'approche de cacher physiquement le canal de la clé plutôt que de multiplier les goupilles est assez originale pour mériter qu'on la suive.
C'est clairement le genre de projet qui ne révolutionnera pas forcément le marché là maintenant tout de suite, mais qui peut faire un peu avancer le schmilblick côté conception mécanique et sécurité.
Source : Hackaday
Des attaquants se sont fait passer pour un responsable connu de la Linux Foundation sur le Slack du TODO Group, un groupe de travail dédié aux bureaux de programmes open source. L'objectif, piéger les développeurs en les amenant à cliquer sur un lien d'apparence officielle, puis à installer un faux certificat racine sur leur machine.
Le lien était hébergé sur Google Sites, ce qui aide à passer les filtres de sécurité et donne un vernis légitime. Les victimes arrivent sur une fausse page d'authentification Google Workspace, qui récupère leur adresse email et un code de vérification, avant de leur demander d'installer un "certificat Google" pour finaliser la connexion.
C'est là que tout bascule. Installer un certificat racine, c'est donner à l'attaquant la possibilité de signer ou d'intercepter n'importe quel trafic TLS sur la machine.
Sur macOS, le faux certificat télécharge et exécute un binaire nommé gapi depuis une IP externe (2.26.97.61), avec toutes les conséquences qu'on imagine. Sur Windows, c'est une boîte de dialogue de confiance navigateur qui pousse l'installation. Dans les deux cas, la machine est compromise.
OpenSSF, Socket et Help Net Security ont documenté la campagne, qui s'inscrit dans une tendance plus large.
Les attaquants visent de plus en plus les workflows développeurs et les relations de confiance interne plutôt que de chercher une faille zero-day dans le code, parce qu'un ingénieur qui fait confiance à un Slack privé reste une cible bien plus rentable que la lecture de 50 000 lignes de C obscures.
La règle de sécurité à retenir est simple. Aucun service légitime, jamais, ne vous demandera d'installer un certificat racine via un lien reçu en chat ou par email.
Si un message Slack vous y pousse, même depuis un compte interne qui semble légitime, c'est un compromis ou une usurpation. Signalez, ne cliquez pas.
Ce qui est relou, c'est que l'attaque marche précisément parce que les devs open source travaillent beaucoup sur Slack, au milieu de messages techniques qu'ils traitent à la chaîne. C'est donc franchement fourbe.
Bref, vous l'avez compris, un certificat racine demandé par chat, c'est toujours non.
Source : The Register
Gérald Darmanin veut que la France aille puiser dans les ADN stockés chez les sociétés américaines de tests récréatifs pour faire tourner le FNAEG. Rien que ça !! Ces tests sont pourtant interdits dans l'Hexagone depuis belle lurette, et la fiabilité de ces boîtes est tellement douteuse qu'elles ont déjà validé des échantillons d'ADN de chien comme des résultats humains parfaitement cohérents. Franchement, y a de quoi hurler.
Bienvenue dans la Loi Sûre !
Le garde des sceaux a annoncé la couleur le 20 octobre dernier depuis le pôle cold cases du tribunal judiciaire de Nanterre. Le projet de loi SURE (pour Sanction Utile, Rapide et Effective) est arrivé en Conseil des ministres le 18 mars de cette année, avec passage au Sénat cette semaine du 13 avril et débat à l'Assemblée Nationale prévu pour juin. Au menu, la généalogie génétique autorisée sous contrôle du juge, réservée aux crimes les plus graves comme les meurtres, viols, et autres enlèvements. Selon Darmanin, une trentaine d'affaires non élucidées trouveraient ainsi une réponse, et les 50 000 traces du FNAEG qu'il mentionnait sans correspondance connaîtraient peut-être enfin leur propriétaire. Vous vous souvenez peut-être de Bruno L., surnommé le "prédateur des bois" ? C'est déjà comme ça qu'il a été coincé fin 2022, avec un coup de main du FBI. C'était une première en France.
Alors sur le papier, ça sonne plutôt bien. Sauf que le problème c'est que la technique repose sur un truc vraiment gênant : comparer l'ADN d'une scène de crime avec les bases américaines remplies de millions d'échantillons envoyés volontairement par des particuliers curieux de leurs origines.
En fait, ces tests ADN récréatifs sont interdits en France depuis des années. L'article 16-10 du Code civil limite l'examen génétique à des fins médicales ou scientifiques, et le Code pénal (article 226-28-1) prévoit 3 750 euros d'amende.
En 2019, le député Jean-François Eliaou déposait d'ailleurs la question (question parlementaire n°15638 pour ceux qui la veulent) pour rappeler que ces pratiques constituent une "atteinte à la personne humaine". Sauf qu'en pratique, rien n'a jamais empêché les curieux de balancer leur crachat dans une enveloppe direction le Texas ou Israël. Alors pour rattraper le coup, plutôt que d'assumer ce vide juridique, le Garde des Sceaux préfère aller exploiter les données qu'on aurait jamais dû laisser partir. Certes la loi sera encadrée par un juge, mais ça ne change rien à l'origine bancale des échantillons.
Et puis y'a la fiabilité de ces boîtes. Vous allez voir, c'est dingue. Gizmodo avait documenté le cas d'une société de tests qui avait analysé sans sourciller un échantillon d'ADN de labrador en lui crachant un beau résultat de généalogie humaine. Des journalistes ont aussi obtenu des rapports cohérents avec des échantillons bidons. J'en parlais déjà en 2018 dans un vieil article , et rien n'a vraiment bougé depuis. Ces sociétés vendent du rêve sur de la flotte, parce que leur modèle économique repose sur le divertissement, pas sur la rigueur forensique.
Et c'est avec ce genre de base qu'on veut bâtir des enquêtes criminelles françaises ??? Serieux ?
Attendez, y'a pire ! Bah oui, n'importe qui peut s'inscrire avec le nom qu'il veut et envoyer l'ADN de son voisin. Ou de son ex. Ou de la personne qu'il rêve de coincer pour un règlement de compte. Aucune vérification d'identité sérieuse, aucune authentification du donneur. Donc autant dire qu'un type un peu motivé peut polluer une base entière avec des échantillons bidons, et regarder ensuite le FNAEG avaler des correspondances pourries sans broncher. C'est du grand art.
Bienvenue dans le consentement éclairé à la sauce marketing.
Et pendant ce temps, le Comité Consultatif National d'Éthique, qui devrait normalement être saisi sur un texte qui légalise l'exploitation de données génétiques obtenues hors cadre légal français, n'a pas été consulté par le gouvernement sur cette Loi SURE.
Voilà, voilà. Encore de la grande démocratie bien exécutée, comme à leur habitude...
Bref, petit rappel, les amis, si vous avez déjà envoyé votre ADN à ce genre de boîte, foncez dans vos paramètres pour vous "opter out". Ça ne retirera pas l'échantillon des bases, mais vous sortirez des listes de matches accessibles aux enquêteurs.
C'est toujours ça de pris.
Source : Le Monde
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
