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 :

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