Vue lecture

Les clés BootROM de la PS5 ont fuité et Sony ne peut pas patcher

Alerte rouge chez Sony ! En ce début d'année 2026, la scène hacking vient de faire sauter le bouchon de champagne d'une façon que le constructeur japonais n'apprécie vraiment pas. Les clés BootROM de la PlayStation 5, c'est à dire ces secrets cryptographiques stockés dans la mémoire en lecture seule du processeur, se baladent maintenant en liberté sur le net.

Tout a commencé le 31 décembre, quand des figures bien connues de la scène comme @BrutalSam_ et @Shadzey1 ont commencé à partager des infos sur cette fuite massive. Leurs posts ont rapidement été supprimés, mais le mal était fait puisque les clés et leurs "keyseeds" sont maintenant listées publiquement sur psdevwiki.com .

Pour comprendre pourquoi c'est si grave, il faut plonger un peu dans les entrailles de la bête. Ces clés BootROM, qu'on appelle aussi clés "Level 0", sont utilisées pour déchiffrer les premières étapes du démarrage de la console. Elles font partie de ce qu'on appelle la "Chain of Trust", la chaîne de confiance qui vérifie que chaque composant logiciel est bien légitime avant de passer la main au suivant. Le bootloader, le kernel, le système d'exploitation, tout repose sur cette fondation cryptographique.

Et le problème, c'est que ces clés résident dans la mémoire morte du processeur AMD de la PS5, définie lors de la fabrication. Sony ne peut pas les modifier avec une simple mise à jour firmware puisque la BootROM est par définition immuable. La seule solution serait de fabriquer de nouveaux APU avec des clés différentes, ce qui ne concernerait que les futures consoles. Les PS5 déjà vendues conserveront cette même clé, ce qui les rend potentiellement exposées à de futurs exploits.

Ça me rappelle l'exploit fusée-gelée de la Nintendo Switch. Dans ce cas-là, c'était une faille dans le code du bootROM Tegra (un bug permettant l'exécution de code) plutôt qu'une fuite de clés, mais le principe reste le même... une fois le processeur sorti d'usine, impossible de patcher. La PS3 avait connu un sort similaire en 2010-2011 avec l'incident fail0verflow .

Mais ne vous précipitez pas encore pour sortir vos tournevis car cette fuite ne constitue pas un jailbreak en soi. Avoir les clés permet d'analyser le processus de démarrage en détail, de comprendre ce qui était jusqu'ici une boîte noire. Mais pour exécuter du code non signé sur une console retail, il faut encore trouver un point d'entrée, un exploit, puis construire toute une chaîne de privilèges. C'est un travail de fond qui va prendre du temps...

On pourrait quand même voir apparaître des custom firmwares et des loaders de backups plus sophistiqués courant 2026. Ça va aussi faciliter le travail des équipes qui bossent sur l'émulation PS5 sur PC, puisqu'elles auront enfin une documentation complète du boot flow.

Sony n'a pas communiqué sur le sujet pour le moment, mais une révision matérielle avec de nouvelles clés reste une option possible pour les futures PS5, comme Nintendo l'avait fait après fusée-gelée. En attendant, tous les possesseurs actuels sont dans le même bateau, avec une console dont le cadenas vient de perdre sa clé maître !

Si vous avez acheté votre PS5 récemment en pensant qu'elle serait la plus sécurisée du lot, c'est raté. Mais si vous êtes du genre à bidouiller et que vous patientez sagement pour un futur jailbreak, 2026 s'annonce plutôt prometteur de ce côté-là...

Source

  •  

Poésie contre l’IA : les garde-fous débordés

Des poèmes malveillants contournent les garde-fous de 25 modèles d’IA, révélant une vulnérabilité systémique des mécanismes d’alignement actuels.
  •  

Il installe iOS 6 sur un iPod touch 3

Vous vous souvenez des vieux iPod touch ? Je dois encore en avoir un qui traine au fond d’un tiroir et malheureusement, l’iPod touch de 3ème génération, sorti en 2009, n’a jamais officiellement reçu iOS 6 puisqu’Apple a décidé de le laisser sur le bord de la route avec iOS 5.1.1. Snif c’est pas gentil ! Mais c’était sans compter sur NyanSatan , un dev qui vient de prouver que c’était parfaitement possible faire tourner iOS 6 dessus.

Le projet s’appelle SundanceInH2A et l’idée bien que tordue est géniale, vous allez voir. En effet, l’iPod touch 3 partage quasiment le même hardware que l’iPhone 3GS qui, lui, a eu droit à iOS 6 officiellement. C’est la même famille de puces (S5L89xx), une architecture proche et donc on peut se demander pourquoi Apple n’a pas voulu le support si c’était aussi similaire. Probablement une histoire de segmentation marketing, mais bon, bref, passons…

La manip c’est donc de prendre le firmware iOS 6 de l’iPhone 3GS et de le transplanter sur l’iPod touch 3. Mais ça implique de modifier pas mal de trucs : le DeviceTree (la carte d’identité matérielle du device), le kernelcache (le noyau + toutes ses extensions), le bootloader iBoot, et même des morceaux du système comme le dyld shared cache.

Le plus technique dans l’histoire, c’est la reconstruction du kernelcache car l’iPod touch 3 avait des builds internes d’iOS 6 avec un noyau compatible, mais les kexts (extensions kernel) n’étaient pas tous présents. Du coup, NyanSatan a dû utiliser un outil Apple non public appelé kcgen pour reconstruire tout ça proprement. Et pour installer ce firmware modifié sans que l’appareil refuse de démarrer, il a exploité une faille HFS+ dans le bootloader d’iOS 5, permettant un jailbreak untethered.

Cette restauration prend alors environ 5 minutes et vous vous retrouvez sur l’écran de configuration d’iOS 6. Bon après, faut pas s’attendre à des miracles niveau utilisation quotidienne car iOS 6 date quand même de 2012 ce qui fait que la plupart des services en ligne (y compris ceux d’Apple) ne fonctionnent plus. Mais pour les collectionneurs et les curieux de l’archéologie iOS, c’est un exploit technique sympa !

Et NyanSatan a tout documenté ici en détails. Les firmwares des coprocesseurs (Wi-Fi, Bluetooth, multitouch) viennent d’iOS 5.1.1, le SpringBoard a été patché pour fusionner les capacités des deux versions, et même le démon FairPlay a été modifié pour permettre l’activation et NyanSatan envisage d’étendre ça à l’iPad 1, un autre appareil qu’Apple avait laissé aussi sur le carreau…

Son code est dispo sur GitHub pour ceux qui veulent tenter l’aventure mais attention quand même, c’est potentiellement dangereux pour votre appareil. Mais bon, après si vous avez un iPod touch 3 qui prend la poussière, vous ne risquez pas grand chose…

Source

  •  

La poésie est une arme... pour contourner la sécurité des LLMs

Hé bien les amis, on savait déjà que les LLM avaient quelques petites failles de sécurité, mais celle-là est quand même assez… poétique. En effet, des chercheurs de DEXAI et de l’Université Sapienza de Rome viennent de découvrir que reformuler une requête malveillante sous la forme d’un poème permet de contourner les sécurités dans plus de 90% des cas chez certains fournisseurs d’IA.

L’équipe a ainsi testé la robustesse de 25 modèles de langage provenant de 9 fournisseurs majeurs : Google, OpenAI, Anthropic, DeepSeek, Qwen, Mistral, Meta, xAI et Moonshot et ils ont pour cela converti 1 200 requêtes potentiellement dangereuses en vers et comparé les résultats avec les mêmes demandes mais en prose classique.

Et là surprise ! Le taux de succès des attaques passe de 8% en prose à 43% en formulation poétique. 5x plus de succès, c’est pas rien ! Je me suis demandé comment c’était possible et d’après le doc de recherche, c’est parce que les filtres de sécurité des LLM fonctionnent principalement par pattern-matching sur des formulations classiques.

Ainsi, quand vous demandez en prose comment fabriquer un truc dangereux, le modèle reconnaît la structure et refuse. Mais quand la même demande est enrobée de métaphores condensées, de rythme stylisé et de tournures narratives inhabituelles, les heuristiques de détection passent à côté.

En gros, les garde-fous sont entraînés à repérer des formes de surface mais pas l’intention sous-jacente, qui elle est nuisible. Voici le tableau. Plus c’est rouge plus le modèle est sensible à l’attaque par poème.

ASR c’est le taux de succès de l’attaque.

Bizarrement, les modèles plus petits refusent plus souvent que les gros. GPT-5-Nano (0% de taux de succès d’attaque) fait mieux que GPT-5 (10%)par exemple. Les chercheurs n’expliquent pas vraiment pourquoi, mais ça suggère que la taille du modèle n’est pas forcément synonyme de meilleure sécurité. C’est peut-être aussi parce que les gros modèles sont tellement doués pour comprendre le contexte qu’ils comprennent aussi mieux ce qu’on leur demande de faire, même quand c’est caché dans des alexandrins.

Au niveau des domaines testés, c’est l’injection de code et les attaques cyber qui passent le mieux avec 84% de réussite. Le contenu sexuel reste le plus résistant avec seulement 24% de taux de succès. Les autres domaines comme le CBRN (chimique, biologique, radiologique, nucléaire), la manipulation psychologique et la perte de contrôle se situent entre les deux…

Bon, après faut quand même nuancer un peu car l’étude se limite aux interactions single-turn (c’est à dire en une seule requête, sans réelle conversation), utilise un seul méta-prompt pour la conversion poétique, et n’a testé que l’anglais et l’italien. Les chercheurs reconnaissent aussi que leurs mesures sont conservatives, donc les vrais taux de succès sont probablement plus élevés. Mais cela n’enlève rien au fait que les implications sont quand même sérieuses.

Prochainement, l’équipe prévoit d’analyser précisément quels éléments poétiques provoquent cet effet (la métaphore ? le rythme ? la rime ?), d’étendre les tests à d’autres langues et d’autres styles, et de développer des méthodes d’évaluation plus robustes face à ces “variations linguistiques”.

Bref, si vous voulez que votre IA vous ponde des choses “non autorisées”, écrivez un joli sonnet, ça a plus de chance de passer ^^.

Source

  •