Il y a trois mois, Andy Nguyen (theflow0 pour les intimes) lâchait PS5-Linux et posait direct cette limite bien nette, à savoir que ça ne concernerait que les PS5 Phat, et pas les Slim ni les Pro. Bon ben cette limite vient de sauter pour les Slim. En effet, depuis fin juin, son ps5-linux-loader supporte le firmware 7.61, et comme c'est justement celui qui équipe les consoles fines, votre Slim peut à son tour se transformer en PC Linux complet.

Le rythme de sortie des nouvelles releases est d'ailleurs assez dingue. En avril, le hack se limitait aux firmwares 3.xx et 4.xx , autant dire à des consoles oubliées au fond d'un placard et aujourd'hui la liste grimpe jusqu'à la 7.61, en passant par les 5.xx et 6.xx. Attention quand même, ce n'est pas open bar sur tout ce qui est en dessous de 7.61, puisque PS5-Linux ne prend en charge que ce qu'il y a sur une liste bien précise de versions. Et puis surtout, les tout premiers firmwares 1.xx et 2.xx restent sur le carreau.

Pour les anciennes versions, faudra toujours passer par l'exploit umtx2. Et pour tout ce qui va de la 6.00 à la 7.61, Andy est passé par une autre faille touchant l'hyperviseur que Sony a déjà colmatée dans ses mises à jour récentes. Mais comme la 7.61 date de 2023, ça ouvre le hack à un sacré paquet de Slim vendus ces dernières années. Filez dans Paramètres, Système, Informations console pour vérifier votre numéro de firmware et s'il figure dans la liste supportée par le projet (jusqu'à la 7.61 incluse), vous êtes bon.

Par contre, rien pour la PS5 Pro qui elle est coincée en firmware 8.0.

Puis au-delà du support firmware, le reste avance également puisque le Bluetooth interne, le lecteur Blu-ray et l'Ethernet sont enfin fonctionnels... ça grossit, ça grossit... Après comme ça reste un soft mod, y'a pas de dual boot possible et faudra relancer l'exploit à chaque fois que vous voulez lancer Linux. Mais c'est pas grave, on est dans l'expérimental et peut-être que le multi boot pérenne arrivera bientôt.

Si vous n'avez pas peur de la ligne de commande, je vous renvoie vers mon article d'avril pour la procédure d'install complète et la liste du matos nécessaire. Une fois en place, ça vous ouvrira surtout les portes de Steam et des émulateurs !

Reprendre la main sur une bécane qu'on a payée plein pot, c'est quand même la base quand on est bidouilleur de l'extrême ^^. Puis couplé à la fuite des clés BootROM de la PS5 fin 2025 , je trouve que l'écosystème commence enfin à respirer un air plus libre.

Source

Md Jueal Mia et Hadi Amini, deux chercheurs de Florida International University , ont mis au point une méthode qu'ils ont baptisée JaiLIP qui permet de forger une image capable de contourner les garde-fous des LLM pour les jailbreaker.

Pour cela, ils utilisent 2 techniques en simultanée. La première dit à l'image "reste identique à l'originale, qu'aucun humain ne voie la moindre différence" et la seconde dit "pousse le modèle à cracher la réponse interdite". Ainsi, en poussant ces 2 curseurs d'un coup, ils obtiennent une photo qui au premier abord a l'air normale mais qui fait dérailler les modèles IA.

Vous, vous repérez un chat, des contours, une scène et vous lui courez derrière pour lui faire des papouilles. L'IA, elle voit une grille de chiffres et des corrélations entre pixels. Du coup sa vie est nulle mais surtout, une retouche minuscule, totalement invisible à votre œil, suffit à déplacer ce qu'elle comprend de l'image.

Sur leurs tests, l'image trafiquée a quasiment doublé la part de réponses dangereuses par rapport à la même image laissée intacte, la toxicité étant mesurée avec des outils standards du domaine. Dans l'un de leurs exemples, ils ont trafiqué une image de signalisation routière qui a permis au modèle ensuite d'expliquer OKLM comment ignorer les règles de circulation et éviter les PV.

Les chercheurs ont testé l'attaque sur deux modèles vision-langage open source, BLIP-2 et MiniGPT-4. GPT-4V, Gemini et les autres gros modèles fermés, eux, n'ont pas été testés dans l'étude. Donc non, contrairement à ce que j'ai pu lire par ci et par là, ce n'est pas une faille prouvée dans ChatGPT ou peu importe l'assistant IA que vous utilisez tous les jours.

Et tromper une IA avec une image bricolée, ça existe depuis une bonne dizaine d'années. Mais la nouveauté de JaiLIP, c'est surtout sa recette d'optimisation. En jouant sur les deux pertes à la fois, l'image reste plus discrète à l'œil tout en se montrant un cran plus efficace que les bidouilles précédentes.

Et ce genre de détournement nous concerne tous parce que des modèles qui regardent des images, il y en a partout maintenant. Les agents IA qui bossent à partir de captures d'écran, les assistants à qui vous balancez vos photos, sans oublier la modération automatique qui trie les images avant publication. À cause de ça, l'image est dorénavant un canal d'attaque, exactement comme l'était déjà le texte...

On l'a vu avec le son inaudible qui pirate les assistants vocaux , on l'a vu avec les IA qu'on manipule sans qu'elles s'en aperçoivent , et c'est toujours la même logique qui revient. Ce n'est pas parce qu'en tant qu'humain, nous ne percevons rien, que l'IA elle n'est pas capable de capter le message 5/5.

Le cousin de cette attaque, côté perception, c'est par exemple le sticker qui trompe une voiture autonome . Et côté parade, nos chercheurs esquissent une piste légère : virer au hasard 10 à 30% des mots passés en entrée, histoire de casser l'attaque sans réentraîner le modèle.

Prometteur d'après eux, mais c'est pas encore une solution blindée. Pour le reste, leurs conseils tiennent du bon sens : Ne passez pas d'infos sensibles en image à un modèle, limitez qui peut envoyer des images à vos systèmes, et auditez sérieusement la sécurité avant de mettre un VLM en prod.

C'est pas le graal mais c'est mieux que rien. Bref méfiez vous des images que vous donnez à vos IA. On ne sait jamais.

Source : le papier JaiLIP sur arXiv

Depuis quelques jours, les Kindle sortis en 2012 ou avant ont perdu l'accès à la boutique Amazon : plus d'achat, plus d'emprunt, plus de téléchargement, vous gardez bien sûr les bouquins déjà chargés sur l'appareil, mais c'est tout.

Alors est ce qu'on chiale comme des petits fragiles victimes d'Amazon ??

Bah non parce que la communauté KindleModding documente depuis des années comment reprendre la main sur ces liseuses, et leur wiki tombe à pic !

Le principe, c'est de jailbreaker le Kindle pour y installer ce qu'Amazon ne veut pas voir en particulier ces 2 outils qui changent tout : KOReader d'abord, un lecteur libre qui avale l'EPUB, le PDF, le CBZ et à peu près tout le reste, et Mesquito, qui remplace carrément la boutique Kindle par un store communautaire. Et voilà comment votre vieille liseuse peut enfin lire les formats ouverts et charger des livres sans passer par la caisse d'Amazon.

Et côté compatibilité, c'est large ! WinterBreak par exemple couvre tous les Kindle en firmware 5.18.0 ou antérieur, soit l'écrasante majorité des modèles d'avant 2024. Les firmwares plus récents, de 5.18.1 à 5.18.5, passent eux par AdBreak. En gros, presque tous y passent, sauf le Kindle Scribe, encore trop verrouillé pour l'instant.

Et vous allez voir, KOReader, c'est le jour et la nuit face au lecteur d'origine. Typographie réglable au poil comme sur Korben.info ^^, dictionnaires perso, annotations de pro, et surtout zéro format imposé. Votre Kindle redevient grâce à ce hack, une vraie liseuse.

Et avec Mesquito, vous installez des apps tierces, vous virez enfin l'écran de pub des modèles Special Offers, vous sideloadez vos livres en USB, et vous coupez les mises à jour automatiques pour qu'Amazon n'aille pas tout re-verrouiller dans votre dos.

Après, même si le risque reste faible quand on suit le wiki à la lettre (il y a une section entière pour récupérer un Kindle dans les choux), faut quand même faire gaffe car un flash de firmware alternatif, c'est jamais anodin. Et bien sûr la garantie saute, mais franchement, sur une liseuse de 2012 elle est morte et enterrée depuis un bail, alors pourquoi se priver !

Dernier truc, un Kindle jailbreaké restera coincé avec le DRM des livres Amazon que vous avez déjà, et KOReader ne fera pas de miracle là-dessus. Donc vous devrez peut-être faire sauter les verrous de vos livres avant.

Et un petit conseil au passage, sur un vieux Kindle encore enregistré, évitez de le réinitialiser ou de le désenregistrer car après vous ne pourrez plus jamais le réenregistrer. Donc on bidouille tranquillou mais on ne fait pas de reset à l'aveugle en mode gros bourrin ^^.

Après le vrai sujet, je trouve, c'est que ce Kindle de 2012, il marche encore parfaitement. L'écran e-ink tient, la batterie tient, rien n'est cassé... Mais non, y'a Amazon qui décide de casser les couilles à distance en bloquant l'achat de livre dessus. En vrai c'était une location de liseuse alors ? On nous aurait menti ?

Amazon avait déjà retiré en février 2025 l'option de télécharger ses livres en USB, et même quand ils ont fini par autoriser l'EPUB sans DRM , c'était réservé aux auteurs indépendants. Bref, leur mouv de fond est limpide, c'est direction tout vers le verrou !

Alors plutôt que de racheter une liseuse neuve, autant réveiller celle qui dort dans un tiroir ou qui arrive en fin de vie à cause d'Amazon. Rendez-vous donc sur le wiki KindleModding qui explique la marche à suivre modèle par modèle, avec un Discord pour l'entraide.

Merci François pour le lien !

Virtualiser macOS sur un Mac, tout le monde ou presque sait le faire. Même chose avec Linux... Mais iOS c'est un peu le Graal... Le truc interdit !

Sauf que des chercheurs en sécu viennent de tomber sur VPHONE600AP, un composant planqué dans le firmware Private Cloud Compute d'Apple qui permet de faire tourner iOS 26 en VM sur un simple Mac tout simplement via le Virtualization.framework. En gros, Apple a laissé traîner la clé sous le paillasson...

Pour ceux qui débarquent, Private Cloud Compute (PCC) c'est l'infrastructure serveur qu'Apple utilise pour faire tourner Apple Intelligence et bizarrement, le firmware de ces serveurs, qu'Apple appelle cloudOS, contient un composant qui n'a rien à faire là : un iPhone virtuel. VPHONE600AP, de son petit nom.

iOS 26 dans une VM sur Mac, avec le wallpaper clownfish en guise de bienvenue

C'est vrai que jusqu'ici, on pouvait faire tourner des VM sur iOS via UTM, mais dans l'autre sens c'était niet. Mais le chercheur du nom de wh1te4ever (bien connu dans le milieu du jailbreak iOS) a documenté comment exploiter ce composant dans un writeup hyper détaillé que je vous invite à lire.

La recette, c'est pas sorcier sur le papier : on prend le firmware d'un iPhone 16 sous iOS 26.1 (~8 Go à télécharger), on y greffe les éléments vphone récupérés dans cloudOS, et on patche le résultat jusqu'à ce que le tout accepte de démarrer dans une VM. En pratique, on se doute que c'est évidemment un poil plus corsé que ça mais c'est le résultat qui compte !

Côté patches, 3 niveaux de casse-tête s'offrent à vous. Le mode Regular, le plus pépère, qui se contente de 38 modifications. Le mode Development qui en empile 47. Et le mode Jailbreak avec ses 84 patches !

Le device tree du firmware vphone, aka "iPhone Research Environment Virtual Machine"

Ces patches touchent à tout ce qui empêche normalement iOS de tourner en dehors d'un vrai iPhone : le bootloader (iBSS, iBEC, LLB), la vérification du volume système (SSV bypass), le système de fichiers APFS (seal verification), et le trustcache TXM.

Et pour simplifier tout ça, un autre dev nommé Lakr233 a créé vphone-cli , un outil en ligne de commande qui automatise tout le processus. Téléchargement des firmwares, application des patches, boot de la VM... quelques commandes dans le Terminal et c'est parti. Sans cet outil, il faudrait se taper chaque patch à la main, parce que le processus complet prend une bonne vingtaine d'étapes.

Ensuite, une fois la bête lancée, trois façons d'y accéder : SSH sur le port 22222 pour bidouiller, VNC sur le 5901 si vous voulez voir l'écran, ou RPC sur le 5910. Le tout en 1179x2556, la résolution d'un iPhone 16. Pas mal pour du virtuel !

Bon, quelques conditions quand même.... il faut macOS 15 (Sequoia) minimum, désactiver SIP et AMFI via csrutil disable en mode Recovery, et surtout un Mac Apple Silicon...

Sur Mac Intel, ça ne marchera pas. Maintenant, si vous avez déjà bidouillé de la virtualisation sur Mac , ça ne devrait pas trop vous dépayser, mais comprenez bien que c'est un outil de recherche en sécurité avant tout... même si perso, tester des apps iOS sans vrai iPhone, c'est pas du luxe quand on fait mon job.

Merci à Lorenper pour le lien de vphone-cli !

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 !

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

Et si on pouvait pirater une IA non pas en la forçant, mais en la convainquant qu’elle est toujours du bon côté de la barrière ?? Ce serait pas un truc fun à faire ça quand même ? Hé bien c’est exactement ce que vient de faire une équipe de chercheurs en sécurité avec LatentBreak, une technique qui ressemble plus, je trouve, à de l’hypnose qu’à du véritable hacking.

Ainsi, plutôt que de bombarder ChatGPT ou Llama avec des prompts bizarres bourrés de caractères spéciaux pour les faire bugger (comme le font les anciennes techniques de jailbreak), LatentBreak joue sur la perception interne du modèle. L’IA croit en fait sincèrement répondre à une question innocente alors qu’elle génère du contenu dangereux. Un peu comme quand votre pervers narcissique préféré vous manipule pour vous faire croire que vous faites un truc bien et important alors que c’est de la merde et que ça vous enfonce encore plus…

Comme expliqué dans le document de recherche , les anciennes attaques comme GCG , GBDA ou AutoDAN ajoutaient des suffixes louches aux prompts, ce qui augmentait ce qu’on appelle la “perplexity”. La perplexity, c’est un indicateur de bizarrerie textuelle et cela, les filtres de sécurité sont maintenant capables de les détecter et de les bloquer.

LatentBreak contourne donc le problème en restant parfaitement naturel. L’algorithme remplace des mots par des synonymes, mais pas n’importe comment puisqu’il choisit chaque substitution pour déplacer la représentation interne du prompt vers les zones “sûres” du modèle, c’est à dire celles qui ne déclenchent aucune alarme. Le prompt reste alors fluide, compréhensible, inoffensif en apparence mais dans l’“inconscient” de l’IA, dans cet espace latent invisible où elle calcule ses réponses, le sens glisse subtilement vers quelque chose de complètement différent.

À chaque itération, l’algorithme de LatentBreak prend un mot du prompt et génère jusqu’à 20 alternatives via un autre modèle comme GPT-4o-mini et chaque variante est évaluée sur deux critères : est-ce qu’elle rapproche le vecteur interne du prompt d’un “centre de sécurité” dans l’espace latent, et est-ce que le sens global reste cohérent ?

La meilleure option est alors intégrée, et le nouveau prompt est testé sur le modèle cible. Si ça provoque une réponse normalement interdite, c’est gagné. Sinon, on recommence jusqu’à 30 fois de suite.

Et apparemment, les résultats sont impressionnants. Ils ont testé cette approche sur 13 modèles différents dont Llama-3, Mistral-7B, Gemma-7B, Vicuna-13B et Qwen-7B et LatentBreak affiche un taux de réussite entre 55 et 85% selon les cas. Les anciennes techniques tombant de toute façon à zéro face aux défenses modernes et tout ça en allongeant que de très peu la longueur du prompt.

LatentBreak passe d’ailleurs à travers des défenses réputées solides… Par exemple, R2D2 et Circuit Breakers, des systèmes qui analysent les signaux internes des neurones pour détecter les anomalies, se font totalement avoir parce qu’ils scannent le texte visible et les patterns de surface, mais pas la “pensée interne” du modèle.

Cette technique révèle quelque chose de fondamental à comprendre sur l’architecture des LLM modernes. Ces derniers ont une forme de dissonance cognitive qui est exploitable. Leur représentation interne ne correspond pas toujours à leur comportement affiché, et d’ailleurs les substitutions les plus efficaces se produisent près des dernières couches du modèle, là où la “décision” finale se forme. C’est à ce moment précis qu’on peut glisser le prompt dans une zone cognitive différente sans que les alarmes ne sonnent.

Bien sûr, LatentBreak nécessite un accès aux structures internes du modèle (donc pas de panique, ChatGPT ne va pas se faire pirater comme ça demain), ce qui limite son usage à des contextes de recherche ou aux modèles open source.

Le parallèle avec les techniques de social engineering qu’on connait est d’ailleurs frappant parce que quand vous manipulez quelqu’un, vous ne le forcez pas brutalement. Vous trouvez les bons mots, le bon contexte, vous lui donnez une perception qui correspond à ce que vous voulez… Bref, vous faites en sorte que la personne croie agir selon ses propres valeurs alors qu’elle fait exactement ce que vous voulez. Hé bien LatentBreak fait à peu près la même chose avec les IA en n’attaquant pas de front les protections, mais en les contournant en douceur en réécrivant la “mémoire de travail” du modèle.

Sympa non ?

Source

Oh c’est rigolo ça… Un chercheur en sécurité vient de découvrir qu’on peut faire cracher des clés Windows à ChatGPT avec trois mots magiques : “I give up”. Cette histoire nous vient de Marco Figueroa, responsable du programme de bug bounty GenAI chez Mozilla (le programme 0DIN pour les intimes), qui a trouvé une technique tellement simple que ça en devient presque gênant pour OpenAI. En gros, il propose à ChatGPT de jouer à un petit jeu de devinette.