Le youtubeur Joe Lynch vient de faire jouer “ Olson ” de Boards of Canada sur un ordinateur de 1959. Pas un émulateur, hein mais le vrai PDP-1, celui qui est au Computer History Museum. 603 bytes de musique sur une bande perforée, et quatre ampoules sur le panneau de contrôle transformées en haut-parleurs… Le son est brut, lo-fi, presque primitif et je trouve ça magnifique.
Mais attendez, ce PDP-1 c’est pas juste un vieux tas de circuits et de câbles… C’est vraiment l’ordinateur qui a créé les hackers et je vais essayer de vous en raconter un peu l’histoire !
Le PDP-1 débarque au MIT en septembre 1961. Digital Equipment Corporation le vend alors 120 000 dollars en tant qu’outil de calcul scientifique. C’est très sérieux, très corporate, sauf que les étudiants du MIT s’en foutent du calcul scientifique.
Ils veulent jouer !
Steve Russell programme alors Spacewar! en 1962. C’est l’un des premiers jeu vidéo. Deux vaisseaux qui se tirent dessus autour d’une étoile et vous vous en doutez, c’est pas prévu dans le manuel. C’est un détournement de la machine… un hack.
Puis la même année, Peter Samson , un autre étudiant du MIT, remarque que les ampoules de statut du PDP-1 clignotent. On/off, on/off… Il se dit alors qu’en contrôlant la vitesse du clignotement, on peut générer des fréquences audio. Il code alors le Harmony Compiler et c’est comme ça que les quatre ampoules deviennent quatre voix musicales. C’est l’un des premier synthétiseur temps réel et polyphonique de l’histoire. Peter optimise même le système pour jouer du Bach.
C’est la naissance de la culture hacker, de l’idée que le matériel peut faire plus que ce pour quoi il a été conçu et vendu. Les limites sont là pour être contournées et ce n’est pas mal… c’est de l’exploration !
Le PDP-1 devient alors le terrain de jeu des premiers hackers du MIT. Ils codent la nuit, quand les profs sont partis et transforment cette machine de calcul en espace de créativité. Et cette étincelle de culture va créer tout ce qui suit. Unix en 1969, le Homebrew Computer Club dans les années 70, les premiers PC, l’open source, Linux…etc. A chaque fois, ce sont des étudiants qui ont décidé que les règles c’était optionnel.
Et 63 ans plus tard, Joe Lynch arrive, prend le code de Peter Samson écrit en 1962 et l’utilise pour faire jouer un morceau de 1998. Il perfore une bande papier, il la charge dans le PDP-1, les fameuses quatre ampoules s’allument et s’éteignent alors à des fréquences calculées pour l’occasion et c’est “Olson” qui sort des haut-parleurs.
Incoyrable non ?
Pour réussir cet exploit, Joe Lynch a utilisé le Harmony Compiler tel qu’il était à l’époque, sans faire aucune modification et tout fonctionne encore parfaitement. Peter Samson a écrit ce code bien avant Apollo 11, bien avant Unix, Internet et tout ce que vous connaissez. Et son code survit encore aujourd’hui alors que 50% des apps que vous avez sur votre téléphone seront totalement mortes dans 5 ans.
Voilà, j’ai trouvé ça beau, un peu comme entendre le son du premier phonogramme ou la première chanson enregistrée… Le projet est évidemment sur GitHub et Joe Lynch y a documenté tout le processus. Il y explique comment il a transcrit “Olson” dans le DSL défini par le Harmony Compiler puis comment il a séparé les quatre voix, comment il a compilé tout ça en bande perforée et enfin, comment il a chargé la bande dans le vrai PDP-1 du Computer History Museum avec l’aide de Peter Samson lui-même, maintenant conférencier pour le musée.
Le site dédié au projet c’est pdp1.music si ça vous branche !
Est-ce que vous êtes déjà demandé pourquoi les soldats blessés au combat ne réalisent pas immédiatement qu’ils pissent le sang ? Ou pourquoi votre mal de dos disparaît mystérieusement quand vous êtes en retard pour un truc important ?
Hé bien des chercheurs de l’ Université de Pennsylvanie viennent de trouver l’interrupteur neuronal responsable et c’est assez dingue comme découverte, vous allez voir !
L’équipe de J. Nicholas Betley a identifié un groupe de neurones dans le tronc cérébral qui agissent comme un bouton “Ne pas déranger” pour la douleur chronique. Ces neurones, qu’on appelle Y1R, se trouvent dans une zone appelée le noyau parabrachial latéral . Un nom compliqué pour un truc très basic… en gros, votre cerveau a un système de priorisation brutal : La survie d’abord, le confort après !
Quand vous avez faim, soif ou peur, votre cerveau libère un neuropeptide appelé NPY. Ce neuropeptide vient se fixer sur les récepteurs Y1 de ces neurones du tronc cérébral, et quand ça arrive, les signaux de douleur chronique sont réduits. Pas coupés complètement, mais clairement atténués.
Votre cerveau vous dit en gros : “Écoute bonhomme, je sais que tu as mal au dos, mais là on a un problème plus urgent à gérer”.
L’équipe a utilisé pour cela l’imagerie calcique pour observer l’activité neuronale en temps réel chez des souris. Et ils ont constaté que les neurones Y1R ne réagissaient pas aux douleurs courtes et aiguës. Par contre, ils restaient actifs en continu pendant les douleurs prolongées. C’est ce qu’on appelle une activité tonique, et quand les chercheurs ont bloqué artificiellement l’activité de ces neurones, les souris ont vu leur douleur chronique diminuer.
Mais elles réagissaient toujours normalement aux dangers immédiats comme toucher une surface chaude par exemple. Le système de douleur aiguë fonctionnait toujours, mais la douleur persistante était très réduite.
Ça pourrait expliquer par exemple pourquoi vous oubliez votre migraine quand vous êtes concentré sur un truc urgent. Ou pourquoi l’adrénaline d’une situation stressante peut vous faire oublier une blessure. C’est votre cerveau qui active ce circuit sans vous demander votre avis.
Il priorise selon ses propres critères et ses critères datent de l’époque où on chassait le mammouth ^^.
Betley dit que cette découverte ouvre une nouvelle voie de traitement, car si on arrive à mesurer l’activité de ces neurones Y1R, on pourrait avoir un biomarqueur fiable de la douleur chronique. C’est un truc qui manque cruellement aux médecins et aux labos pharma car aujourd’hui, la douleur chronique se mesure surtout par ce que vous racontez. C’est subjectif, c’est très difficile à quantifier et donc très difficile à traiter.
Là, ceux qui en font des caisses en hurlant à la mort alors qu’ils n’ont presque rien devraient vite se faire repérer (coucou les footballeurs)… alors que ceux qui douillent vraiment, mais qui serrent les dents seront peut-être mieux pris en charge.
Avec ce biomarqueur neuronal, on pourrait donc objectiver la chose et développer des médicaments qui ciblent spécifiquement ces neurones, ou même explorer des thérapies comportementales qui activent naturellement ce circuit.
Par exemple, l’idée que la faim pourrait techniquement réduire la douleur chronique est plutôt drôle… J’image déjà sur Doctissimo les articles à la con : “Jeûnez pour ne plus avoir mal au dos !” alors qu’évidemment ce n’est pas si simple. Mais bon, ça montre à quel point notre cerveau fonctionne selon des priorités qu’on ne contrôle pas consciemment.
Betley et son équipe continuent évidemment leurs recherches, car ils veulent comprendre plus précisément comment ces neurones interagissent avec les autres circuits cérébraux afin de pouvoir à terme les activer de façon ciblée sans passer par la case “avoir faim, soif ou flipper sa race”.
Y’a aussi la question des traitements médicamenteux, car comme le neuropeptide Y existe déjà, on pourrait théoriquement développer des agonistes du récepteur Y1 qui imitent son action. Les premiers tests cliniques explorent des voies intranasal et intrathecal où des molécules viendraient se fixer sur ces récepteurs pour réduire la douleur chronique sans toucher à la douleur aiguë.
Ça va nous changer du doliprane ^^ !
Bref, les prochaines étapes vont être intéressantes notamment, le passage de la souris à l’humain, qui est toujours un défi.
Si vous voulez en savoir plus sur le sujet, l’article complet est disponible sur Nature .
Vous payez 20 balles par mois pour que ChatGPT vous dise “bonjour” ? Vous attendez 5 secondes qu’une réponse revienne du cloud d’Anthropic ? Vous avez l’impression de louer votre intelligence artificielle comme vous louiez vos MP3 sur iTunes à la grande époque ?
Et bien j’ai une excellente nouvelle qui va vous plaire !! Il existe une extension de navigateur qui fait tourner de l’IA en local, sur votre machine, sans envoyer un seul octet dans le cloud. Ça s’appelle NativeMind et c’est du 100% local.
Vous installez l’extension sur Chrome, Firefox, Brave ou Edge, vous installez Ollama ou vous utilisez WebLLM directement dans le navigateur. Ensuite, vous téléchargez un modèle (DeepSeek, Qwen, Llama, ce que vous voulez) et c’est tout. Vous avez maintenant votre IA personnelle qui tourne sur votre laptop sans rien demander à personne, et accessible directement sur votre navigateur.
Le projet est open-source sous licence AGPL v3.0 et NativeMind supporte deux backends : Ollama, qui est recommandé si vous voulez de vraies performances et un contrôle total sur vos modèles ou WebLLM si vous voulez juste tester sans installer quoi que ce soit, directement dans le navigateur via WebAssembly.
Ollama c’est donc clairement la meilleure option. Vous lancez le serveur en local, il expose une API, et NativeMind s’y connecte. Vous pouvez faire tourner DeepSeek, qui est gratuit et open-source, et avoir des performances comparables à GPT-4, sans payer un centime de plus !
Vous pouvez ensuite lui demander de résumer n’importe quelle page web, de traduire un texte en gardant la mise en page intacte, d’analyser un PDF ou une image et même d’écrire pour vous !! Il est également capable de faire des tâches multi-étapes comme un agent le ferait.
Bref, tout ce que fait ChatGPT, mais sans que vos prompts partent sur les serveurs de Sam Altman.
Alors c’est moins immédiat que ChatGPT, je vous l’accorde et faut installer des trucs, mais une fois que c’est en place, vous êtes tranquille et surtout y’a pas de limite en terme de tokens ou de forfait… Puis vos données ne s’échappent pas.
Voilà, donc si vous voulez utiliser un peu d’IA pour comprendre des trucs sur des pages web, reformuler des mails que vous envoyez, générer des tweets à partir d’un contenu…etc, Nativemind est fait pour vous ! C’est largement suffisant pour des besoins d’IA classiques.
Rendez-vous sur le dépôt Github pour plus d’infos et sur le site officiel pour télécharger les extensions.
Si vous faites partie des anciens qui continuent à collectionner les liens sympa que vous trouvez sur le net, j’sais pas comment vous les gérez, mais j’ai peut-être un truc pour vous. Ça s’appelle Linkding (rien à voir avec le site rempli de teubés en costard qui parlent comme des IA nulles) et c’est un gestionnaire de bookmarks qu’on installe chez soi !
Hé oui, les champions de l’auto-hébergement, Linkding ne cherche pas à réinventer la roue… Il stocke juste vos liens, vos tags, vos notes en Markdown, et basta ! L’interface est sobre, lisible, et surtout elle ne vous balance pas des suggestions sponso à la con entre deux articles que vous vouliez lire plus tard.
Ce projet est open source sous licence MIT, et repose sur Django et SQLite. Donc c’est du solide ! SQLite pour la base de données, ça veut dire zéro configuration serveur et pas de grosse maintenance.
Vous installez le truc dans un container Docker, et ça tourne sur n’importe quoi. Ensuite, vous ajoutez un bookmark, et Linkding va automatiquement chercher le titre de la page, sa description, son icône, même une image de preview.
Autre truc cool prévu dans l’outil, c’est la possibilité de faire de l’archivage web car oui, Linkding peut créer des snapshots de chaque page que vous bookmarkez, soit en local sous forme de fichier HTML, soit via Internet Archive.
Parce que oui, il arrive parfois que les liens meurent dans d’atroces souffrances. Les sites ferment, les articles disparaissent, et dans 5 ans vous vous retrouvez avec une liste bourrée d’erreurs 404.
Alors que là, au moins, avec cet outil, vous avez une copie.
L’extension navigateur est aussi indispensable pour ajouter des bookmarks vite fait ! Elle est disponible pour Firefox et Chrome, et elle vous permet de les tagger à la volée, et même de chercher dans votre collection directement depuis la barre du navigateur. Ça ressemble un peu à ce qu’on avait avec Del.ici.ous à l’époque, en mieux.
Linkding gère aussi le multi-utilisateurs donc vous pouvez partager certains bookmarks avec d’autres personnes, ou les garder privés. C’est super pratique si vous l’installez pour toute la famille ou une petite équipe. Il y a même une API REST, donc si vous voulez automatiser des trucs ou créer vos propres outils autour, c’est possible !!
Y’a aussi une version PWA installable aussi donc vous pouvez l’ajouter à votre écran d’accueil sur mobile et l’utiliser comme une app native !
Une fois que vous y aurez goûté, difficile de revenir en arrière !
Pour tester, y’a une démo en ligne et l’installation prend moins de 10 minutes ! Ce serait dommage de s’en priver
Vous avez déjà passé plus de temps à configurer Sphinx qu’à coder votre projet Python ? Bienvenue au club !
Et oui, paradoxalement, parfois documenter son code devient plus compliqué que d’écrire le code… Vous voulez juste afficher vos docstrings joliment, mais avant ça il faut vous taper 200 pages de doc, choisir parmi 47 thèmes, configurer des dizaines d’extensions et comprendre la syntaxe reStructuredText. Breeeef, la flemme !
Heureusement, il existe une alternative qui va vous réconcilier avec la documentation : pdoc.
pdoc, c’est un outil de documentation Python qui ne nécessite pas de documentation. Vous tapez simple pdoc votre_module
et c’est tout. Pas de fichier de config interminable, pas de choix existentiels entre différents builders, pas de migration depuis votre version de Sphinx de 2018 qui refuse de compiler.
Ça génère directement une belle doc à partir de votre code existant !!
Si vous avez déjà écrit des docstrings propres et utilisé les type annotations de Python, vous avez déjà fait 100% du boulot car pdoc se contente de prendre ce qui existe et de l’afficher élégamment. Pas de traduction, pas de réécriture, pas de fichiers .rst
à maintenir en parallèle de votre code.
Votre code EST la documentation et ça c’est beau !
L’outil comprend les docstrings au format numpydoc et Google-style, fait des liens automatiques entre les identifiants, respecte votre variable __all__
et génère du HTML standalone que vous pouvez héberger n’importe où. Il y a même un serveur web intégré avec live reload pour développer votre doc en temps réel.
Pour mettre ça en place, faut installer pdoc avec
pip install pdoc
Puis vous lancez
pdoc ./votre_projet.py
ou
pdoc nom_de_votre_module
Et c’est tout !
Bien sûr si vous bossez sur un gros projet avec des besoins spécifiques, des guides utilisateurs complexes, des dizaines de pages de tutoriels et une doc multilingue, Sphinx reste le roi, mais pour la grande majorité des projets Python, ceux qui ont juste besoin d’une doc API claire et lisible, pdoc fait ça comme un chef, sans que vous ayez besoin d’un doctorat en outil de documentation.
Bref, si vous en avez marre de passer plus de temps sur votre documentation que sur votre code, pdoc mérite le détour car documenter son code devrait être aussi simple que de le coder, non ?
Pour tester pdoc, direction pdoc.dev ou directement le repo GitHub .
Vous vous souvenez de ce samedi après-midi de 1995 où vous avez modifié CONFIG.SYS pour la première fois ? Les mains moites, le coeur qui bat, parce que si vous vous plantiez, Windows ne démarrait plus. L’écran bleu (le bon vieux bleu DOS hein, pas le blue screen of death), le curseur blanc qui clignote, et cette interface minimaliste où chaque caractère comptait. MS-DOS Edit.
Votre premier vrai pouvoir sur la machine !
Hé bien bonne nouvelle, Microsoft vient de le ressusciter pour de vrai, 30 ans après.
C’est fou ! L’équipe Windows Terminal annonce en effet qu’Edit est maintenant pré-installé dans Windows 11. Plus besoin de le télécharger donc… vous ouvrez votre terminal, vous tapez “edit”, et hop, vous y êtes.
230 kilo-octets seulement, comme à l’époque c’est chouette ! Et le truc marrant, c’est que Edit n’est pas juste un coup de comm nostalgique.
Non, Microsoft comble en réalité un vide qui dure depuis plus de 20 ans, car les versions 32-bit de Windows avaient MS-DOS Edit mais les versions 64-bit n’avaient rien ! Aucun éditeur en ligne de commande par défaut. Snif !
Ainsi, si vous vouliez modifier un fichier config en SSH, fallait forcement installer vim, nano, ou se débrouiller avec notepad.exe en mode graphique comme un sauvage.
Sauf que voilà, les terminaux reviennent en force ! Les devs passent leur vie dans WSL2, PowerShell est devenu cross-platform, et même les utilisateurs lambda doivent parfois mettre les mains dans un fichier texte via la ligne de commande. Finalement, après toutes ces années à vous prendre le chou avec “ouvrez un terminal” par ci, “lancez une commande” par là…etc., ça fait de moi un visionnaire ! ^^
Bon, bref, avoir un éditeur accessible et simple, qui ne nécessite pas un doctorat en raccourcis clavier vim, en 2025 ça a du sens ! D’ailleurs, MS-DOS Edit, dans les années 90, c’était la drogue douce qui menait aux drogues dures. On commençait par modifier AUTOEXEC.BAT pour optimiser notre RAM, parce qu’un jeu ne se lançait pas et deux ans plus tard on se retrouvait sous Linux à compiler un kernel à 3 heures du matin. Edit n’était pas juste un outil, c’était le Bifröst de la bidouille… le moment où on passait d’utilisateur à “celui qui comprend comment ça marche”.
Ce nouvel Edit garde donc cette philosophie avec son interface minimaliste, mais rassurez-vous sous le capot c’est du moderne. C’est écrit en Rust, c’est open-source sous licence MIT, et avec des keybindings inspirés de VS Code. Par exemple Ctrl+P pour switcher entre fichiers, Ctrl+F pour chercher… etc. Il supporte même la souris et l’unicode fonctionne.
Si ça vous dit de tester, vous pouvez l’installer via winget si vous n’êtes pas sur la dernière preview de Windows 11. Un simple “winget install Microsoft.Edit” et c’est réglé. Ensuite vous tapez “edit” dans votre terminal, ou “edit fichier.txt” pour ouvrir directement un document et voilà…
Vos enfants, ceux qui grandissent avec des interfaces tactiles, des assistants vocaux, et ChatGPT partout vont peut-être faire leurs premiers pas de bidouilleurs avec le même outil que nous à l’époque… Qui sait ?
On a tellement l’habitude de tout traduire avec Google ou DeepL qu’on en oublie un truc basique. Ces outils envoient absolument tout ce que vous voulez traduire sur leurs serveurs. Message privé, photo d’un document confidentiel, ou menu de restaurant dans une langue bizarre. Tout part chez eux et tout le monde trouve ça normal.
Enfin, je pense que vous, ça vous saoule ! Heureusement, il existe Firefox Translator , une app Android qui fait de la traduction 100% offline. Texte, images, détection automatique de langue, dictionnaire intégré, tout se passe sur votre appareil. Y’a zéro requête serveur !
Techniquement, Firefox Translator utilise les modèles de traduction Bergamot développés par Mozilla. C’est la même technologie qui tourne dans Firefox sur desktop depuis quelques années. Pour l’OCR sur les images, c’est Tesseract4Android qui bosse quand à la détection de langue, elle passe par CLD2, et le dictionnaire intégré vient de Wiktionary. En plus tout est open source (sous licence GPL-3.0).
Pour vous en servir, c’est fastoche. Vous installez Firefox Translator, puis vous téléchargez les packs de langue dont vous avez besoin. Et après, vous pouvez traduire autant que vous voulez, tout ce que vous voulez, mode avion activé ou pas. Plus de dépendance au réseau, plus de tracking, et plus de serveurs tiers qui analysent vos traductions pour améliorer leurs algos publicitaires.
C’est utile par exemple pour les voyage à l’étranger sans forfait data, les documents confidentiels à traduire sans les envoyer dans le cloud, les zones blanches réseau, les pays avec censure ou surveillance réseau un poil lourde, ou juste le principe de conserver vos données chez vous…
Après y’a des compromis à faire car les packs prennent de la place sur votre téléphone, et la qualité de traduction est probablement inférieure à celle des gros services qui entraînent leurs modèles sur des milliards de textes et le nombre de langues disponibles est plus limité mais pour 90% des usages quotidiens, ça suffit largement !
Firefox Translator est uniquement dispo sur F-Droid.
Y’a plein de problèmes avec les IA, mais y’en a un encore un peu trop sous-estimé par les vibe codeurs que vous êtes… Ce problème, c’est qu’on leur fait confiance comme à un collègue, on leur montre notre code, nos repos privés, nos petits secrets bien planqués dans les variables d’environnement…
Par exemple, quand vous passez en revue une pull request sur GitHub, vous faites quoi ? Vous lisez le code ligne par ligne, vous cherchez les bugs, les failles de sécu, les optimisations possibles. Mais les commentaires vous les lisez ? Au mieux on les survole, c’est vrai, car c’est de la comm’ entre devs, et pas du code exécutable.
Sauf pour Copilot Chat pour qui un commentaire c’est un texte comme un autre. Et selon Omer Mayraz , chercheur en sécurité chez Legit Security, c’est exactement ce qui en fait une zone de confiance aveugle parfaite pour une attaque.
Ce qu’a découvert Omer Mayraz c’est donc une vulnérabilité critique dans GitHub Copilot Chat avec un score CVSS de 9.6 sur 10. Cela consiste à planquer des instructions malveillantes dans des commentaires markdown invisibles comme ça, ces commentaires ne s’affichent pas dans l’interface web de GitHub, mais Copilot Chat les voit parfaitement et les traite comme des prompts légitimes.
Du coup, l’attaquant peut forcer Copilot à chercher des secrets dans vos repos privés, à extraire du code source confidentiel, voire à dénicher des descriptions de vulnérabilités zero-day non publiées. Tout ça sans que vous ne voyiez rien venir évidemment !
Voici une démo complète de l’attaque en vidéo :
La première étape c’est donc l’injection de prompt via un commentaire caché. Rien de révolutionnaire, mais efficace. Ensuite, deuxième étape : le bypass de la Content Security Policy de GitHub. Normalement, Copilot Chat ne peut charger que des ressources depuis des domaines appartenant à GitHub. Il est donc impossible d’envoyer des données vers un serveur externe.
Mais c’était sans compter sur le fait que GitHub dispose d’un proxy appelé Camo, conçu à l’origine pour sécuriser l’affichage d’images externes en les servant via HTTPS et en évitant le tracking. C’est donc ce proxy de sécurité qui devient l’outil d’exfiltration. Avec ce proxy, toutes les URLs d’images externes sont automatiquement transformées en URLs Camo du type https://camo.githubusercontent.com/[hash unique]
et Mayraz a simplement utilisé l’API GitHub pour pré-générer un dictionnaire complet de ces URLs Camo, chacune pointant vers un emplacement unique sur son serveur.
Troisième étape, l’exfiltration des données. Au lieu de faire passer les secrets directement dans les URLs (trop visible), Mayraz a eu l’idée d’utiliser l’ordre des requêtes. Chaque lettre de l’alphabet correspond à une URL Camo unique. En faisant charger ces URLs dans un ordre précis, on peut ainsi transmettre des données texte comme avec un alphabet ASCII artisanal. C’est plutôt créatif comme approche, je trouve.
C’est exactement le même principe que les attaques ultrasoniques contre Alexa ou Siri. Si vous ne vous en souvenez pas, des chercheurs avaient démontré qu’on pouvait envoyer des commandes vocales à des fréquences inaudibles pour l’oreille humaine, mais parfaitement comprises par les assistants vocaux.
Bah ici, c’est pareil… On a des prompts invisibles pour les humains mais que l’IA voit et exécute sans broncher. Comme pour les enceintes, on parle à la machine sans que l’humain ne s’en aperçoive et la différence, c’est qu’au lieu de jouer sur les fréquences sonores, on joue sur le markdown et les commentaires cachés.
Du coup, chaque pull request externe est un potentiel cheval de Troie. Un contributeur externe soumet par exemple une PR apparemment légitime, avec un commentaire invisible qui ordonne à Copilot de chercher “AWS_KEY” dans vos repos privés. Vous de votre côté, vous ouvrez la PR dans votre éditeur, Copilot Chat s’active bien sûr automatiquement, et hop, vos clés API partent chez l’attaquant.
Quand on sait que GitHub a créé Camo justement pour améliorer la sécurité, ça fout un peu les boules. Bref, grâce à son proof-of-concept, Mayraz a réussi à exfiltrer des clés AWS, des tokens de sécurité, et même la description complète d’une vulnérabilité zero-day stockée dans une issue privée d’une organisation et tout ça sans aucune interaction suspecte visible par la victime.
Heureusement, notre joyeux chercheur a prévenu GitHub qui a réagi assez vite. Le 14 août l’entreprise a complètement désactivé le rendu d’images dans Copilot Chat, comme ça plus d’images, plus de problème. C’est radical, c’est sûr mais c’est efficace !
Quoiqu’il en soit, ces histoires de prompt injection c’est un problème fondamental propre aux LLM qui sont encore actuellement incapable de distinguer de manière fiable les instructions légitimes des instructions malveillantes. Ça reste donc un problème de confiance…
Dans ce cas précis, on fait confiance à GitHub pour héberger notre code du coup, on fait confiance à Copilot pour nous aider à développer, tout comme on fait confiance aux contributeurs externes pour soumettre des PR de bonne foi. Et nous voilà avec une jolie chaîne de confiance prête à être exploitée…
Bref, CamoLeak c’est que le début de cette nouvelle vague de vuln liées aux assistants IA qui se retrouvent intégrés dans nos outils de développement… Donc ouvrez l’oeil car on ne sait jamais ce qui sa cache vraiment dans une pull request.
Vous venez de claquer plusieurs milliers d’euros dans une solution antivirus dernier cri pour votre boîte car le commercial vous a convaincu avec du machine learning, de l’IA comportementale, du threat hunting prédictif et j’en passe…
Cool story ! Mais si je vous disais qu’un petit exécutable open source gratuit peut potentiellement passer à travers ? Ce programme s’appelle al-khaser et je vous assure qu’il va vous faire déchanter, car ce truc, c’est le détecteur de mensonges des solutions de cybersécurité.
Al-khaser est outil qui ne fait rien de méchant en soi… C’est ce qu’on appelle un PoC, un “proof of concept” avec de bonnes intentions car il rassemble dans un seul programme toutes les techniques que les vrais malwares utilisent pour se planquer tels que la détection de machines virtuelles, le contournement des débogueurs, l’échappement aux sandbox, et j’en passe.
Comme ça, si votre antivirus ne détecte pas al-khaser, il y a de bonnes chances qu’il rate aussi les vraies menaces qui utilisent les mêmes techniques.
Faut dire que les éditeurs d’antivirus et d’EDR adorent nous vendre leurs nouvelles fonctionnalités IA de fou alors que certaines de leurs solutions ne détectent même pas des techniques pourtant connues depuis longtemps.
Al-khaser met donc tout ça en lumière de façon assez brutale en enchaînant des dizaines de vérifications. Par exemple, il va regarder si votre processeur a vraiment le bon nombre de cœurs ou si c’est une simulation. Il va checker l’adresse MAC de votre carte réseau pour voir si elle correspond à un hyperviseur VMware ou VirtualBox. Il va mesurer le temps d’exécution de certaines opérations pour détecter si le système est accéléré artificiellement, comme dans une sandbox d’analyse. Il va même tester des API Windows classiques comme IsDebuggerPresent ou CheckRemoteDebuggerPresent pour voir si quelqu’un espionne son exécution.
Maintenant si vous voulez tester les protections anti-debug de votre système, vous tapez :
al-khaser.exe –check DEBUG –sleep 30
Oui si vous voulez voir si votre virtualisation VMware ou QEMU est bien masquée :
al-khaser.exe –check VMWARE –check QEMU
Bien sûr, ces techniques ne sortent pas de nulle part car elles sont documentées depuis des années notamment dans ce référentiel dont je vous déjà parlé .
Les équipes de pentest et les red teams adorent al-khaser car ça leur permet de montrer aux décideurs que leur gros investissement en cybersécurité n’est peut-être pas aussi solide qu’ils le pensaient. Vous lancez l’outil un vendredi après-midi dans un environnement de test, et vous voyez instantanément ce que votre EDR détecte ou pas.
Voilà, une fois encore, rassurez-vous, al-khaser ne fait rien de malveillant… Il ne vole pas de données, ne chiffre pas vos fichiers, ne lance pas de ransomware mais se contente juste de lever la main et de dire “hé ho, je suis là, regardez moi, je fais plein de des trucs louches !!”.
Bien sûr, ne lancez pas al-khaser sur n’importe quelle machine car c’est un outil de test qui doit rester dans un environnement contrôlé. Si vous le lancez sur le réseau de prod sans prévenir votre équipe sécu, vous allez déclencher des alertes partout et recevoir des appels pas très sympathiques. Et surtout, juridiquement, vous devez avoir l’autorisation du propriétaire de l’infrastructure, sinon, vous risquez de gros ennuis.
Ce projet est open source, écrit essentiellement en C++, et disponible sur GitHub . Y’a plus qu’à vous monter une VM isolée, récupérer al-khaser, et voir ce que ça donne.
Vous vous souvenez de FCKGW-RHQQ2-YXRKT-8TG6W-2B7Q8 ?
Si vous avez touché à un PC entre 2001 et 2005, y’a des chances que oui ! C’était LA clé magique qui activait Windows XP sans broncher, celle qui circulait sur tous les forums, qui était sur tous les CD gravés, et toutes les installations pirates de la planète ! Dave Plummer, le gars qui a créé le Gestionnaire des tâches et le système d’activation de produits Windows chez Microsoft, vient de raconter sur son compte X toute l’histoire et c’est un régal à lire !
Déjà, pour les djeuns qui n’ont pas connu cette époque bénie, je vais vous donner un peu de contexte… Windows XP est sorti en octobre 2001 avec un super système d’activation antipiratage. E n gros, vous installiez le système, vous tapiez votre clé produit, et normalement ça vérifiait que vous n’utilisiez pas la même clé sur 50 machines. Sauf que FCKGW, elle, passait partout…. Des installations illimitées, aucune vérification, aucun blocage. Bref, le saint Graal du piratage Windows.
Et pendant des années, personne ne savait vraiment d’où elle venait. Une fuite ? Un employé de Microsoft rebelle ? Un hack génial ? Hé bien selon Dave Plummer, la vérité est à la fois plus simple et plus embarrassante pour Microsoft. En fait, cette clé, c’était une VLK, c’est à dire une Volume License Key. Les VLK ce sont des clés qui étaient faites pour les grandes entreprises qui devaient installer Windows sur des centaines de machines sans se taper l’activation à chaque fois. Microsoft les whitelistait directement dans le code d’activation de l’OS pour qu’elles passent sans contrôle.
Le problème, ou plutôt le GROS FUCKING PROBLEME, c’est que FCKGW a fuité seulement 5 petites semaines AVANT la sortie officielle de Windows XP. Oups la boulette !
C’est le groupe warez devils0wn a mis la main dessus et l’a balancée dans la nature et comme elle était whitelistée, Microsoft ne pouvait pas la désactiver sans casser toutes les installations légitimes des entreprises qui l’utilisaient. Du coup, bah y’avait plus rien à faire et ils ont laissé comme ça…
Dave Plummer explique que ça a été l’un des plus gros échecs de sécurité de Microsoft… la clé a circulé pendant des années, installée sur des millions de machines à travers le monde. Vous alliez chez un pote pour “réparer son PC”, vous sortiez votre CD Windows XP gravé, vous tapiez la FCKGW, et hop, il avait une installation propre et activée. Pas besoin de crack ni de keygen douteux. C’était royal !
Le truc marrant, c’est que pas mal de monde connaissait cette clé par cœur. Perso, j’ai pas été loin non plus de savoir la réciter par cœur les yeux fermés, à force de la taper. FCKGW-RHQQ2-YXRKT-8TG6W-2B7Q8 est gravée dans la mémoire collective de toute une génération de bidouilleurs PC, au même titre que les codes de GTA ou que la mélodie du modem 56k.
Voilà pour cette jolie histoire… Aujourd’hui, Windows XP n’est plus supporté depuis 2014, et cette clé ne sert plus à rien et Microsoft s’en fout d’ailleurs probablement. Mais 20 ans plus tard, on s’en souvient encore et c’est devenu un fail légendaire de plus dans l’histoire de l’informatique !