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

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.