Pour ce dernier article de ma série de l’été, je vais vous raconter l’histoire d’un type absolument génial que vous ne connaissez peut-être pas mais qui, lui aussi, a mis sa pierre à l’édifice de la sécurité informatique. Thomas Dullien, plus connu sous le pseudo “Halvar Flake”, c’est un peu le MacGyver du reverse engineering, sauf qu’au lieu de désamorcer des bombes avec un trombone, il désamorce des malwares avec des graphes mathématiques.

Ce gars est surtout à l’origine de BinDiff , un outil légendaire capable de comparer des binaires, très utile par exemple pour comprendre ce que Microsoft a patché dans une mise à jour de sécurité. Cet outil peut vous sortir une analyse graphique qui vous montre exactement où se trouvent les différences entre l’ancienne et la nouvelle version. À l’époque, en 2005, cet outil c’était comme avoir des super-pouvoirs.

Mais commençons par le début. Thomas Dullien, c’est un mathématicien allemand qui a grandi à une époque où Internet commençait tout juste à exploser. Le gars était destiné à devenir avocat, mais à la dernière minute, il change d’avis et s’inscrit en maths à l’Université de Bochum. Best decision ever, comme on dit. Il finit par obtenir son Master en mathématiques en 2008, après avoir commencé un doctorat qu’il abandonne pour se concentrer sur son entreprise.

Son pseudo “Halvar Flake” vient d’un personnage de dessin animé. C’est le chef d’un village viking dans la série télé “Vicky le Viking”. Et l’anecdote est géniale quand il l’explique : “J’étais petit, gros, j’avais des cheveux longs, et je buvais beaucoup de bière, alors les gens m’appelaient Halvar”, raconte-t-il avec humour. Bon, aujourd’hui le nom est resté même si la description ne colle plus vraiment !

Dans les années 90, alors qu’il est encore adolescent, Thomas commence à s’intéresser au reverse engineering et à la gestion des droits numériques (DRM). À l’époque, c’est le Far West total. Les protections logicielles sont simplistes, les entreprises pensent que leur code est impénétrable, et de petits génies comme lui s’amusent à démonter tout ça pièce par pièce. Il écrit même son premier fuzzer à 19 ans, mais refuse de l’utiliser lui-même par fierté… en vrai il préfère trouver les bugs en lisant le code ! Des années plus tard, il admettra que c’était stupide et que le fuzzing est quand même une technique incroyablement efficace.

En 2000, à seulement 19-20 ans, il fait alors sa première présentation à Black Hat Amsterdam sur “Auditing binaries for security vulnerabilities”. En réalité, il voulait rencontrer un pote du Sri Lanka mais aucun des deux n’avait les moyens de payer le billet d’avion alors ils ont décidé de faire une présentation à la même conférence. C’est donc comme ça qu’il commence sa carrière de formateur en reverse engineering… une carrière qui durera plus de 20 ans.

Pendant les années qui suivent, Halvar devient alors LA référence en matière de reverse engineering. Il développe des techniques révolutionnaires comme l’exploitation des tas Windows ( heap exploitation ), le patch diffing (comparer des versions patchées et non patchées de logiciels), et plein d’autres trucs que les chercheurs en sécurité utilisent encore aujourd’hui. Il donne des talks sur l’analyse binaire basée sur les graphes à Blackhat USA 2002, Blackhat Asia 2002, et CanSecWest 2002, où il se plaint déjà qu’IDA Pro ne gère pas bien les fonctions non-contiguës !

Mais son coup de génie, c’est au printemps 2004 quand il fonde SABRE Security, qui deviendra rapidement zynamics. L’idée c’est qu’au lieu de comparer les binaires octet par octet comme tout le monde, il utilise la théorie des graphes. En gros il faut voir ça comme une carte routière avec des intersections (les fonctions) et des routes (les appels entre fonctions). Et chaque programme a la sienne. BinDiff compare alors ces cartes pour trouver les différences.

Cette approche est innovante parce qu’elle fonctionne même si les programmes sont compilés avec des options différentes ou des compilateurs différents. Entre la publication DIMVA de 2004 et début 2005, Rolf Rolles, un autre génie du reverse engineering, contribue au projet avec de nouvelles idées qui améliorent grandement la capacité de BinDiff à matcher les blocs de base.

Puis en 2005, ils publient ensemble “Graph-based comparison of executable objects” au SSTIC… une présentation que Thomas donne en français et qu’il décrit comme “la seule présentation de conférence que j’ai jamais donnée en français. Et parce que j’étais terrifié, c’est probablement aussi celle que j’ai le plus répétée de ma vie”.

En 2006, coup de tonnerre : zynamics remporte le prix Horst Görtz, avec une récompense de 100 000 euros, pour leur technologie de classification de malwares. C’est à l’époque le plus gros prix privé en sciences naturelles d’Allemagne ! Ce prix récompense leur travail sur la similarité de code basée sur les graphes et cet argent leur permet de rester indépendants sans avoir besoin de capital-risque. “Le capital-risque était trop restrictif”, explique Thomas, qui finissait alors son Master tout en dirigeant l’entreprise.

L’entreprise grandit alors jusqu’à une douzaine d’employés, tous des ninjas du reverse engineering. Ils développent non seulement BinDiff, mais aussi BinNavi (essentiellement un IDE pour le reverse engineering centré sur la visualisation interactive de graphes, l’analyse de couverture et le débogage différentiel) et VxClass , qu’ils décrivent comme “un laboratoire d’analyse antivirus dans une boîte”.

L’impact de BinDiff sur l’industrie est énorme. Le nom devient même un verbe… les gens disent “je vais bindiff ça” pour dire qu’ils vont comparer deux binaires. C’est un peu comme quand on dit “googler”… alors quand votre outil devient un verbe, vous savez que vous avez réussi !

Thomas Dullien

Mais l’histoire prend un tournant dramatique en juillet 2007. Halvar arrive aux États-Unis pour donner sa formation annuelle à Black Hat Las Vegas, une formation qu’il donne depuis 7 ans sans problème. Mais cette fois, catastrophe, les douanes américaines trouvent ses supports de présentation dans ses bagages et le retiennent pendant 4 heures et demie. “Si vous allez faire du profit en tant que conférencier individuel, vous avez besoin d’un visa différent”, lui disent-ils. Le problème c’est qu’il avait un contrat avec Black Hat Consulting en direct en tant qu’individu, pas en tant que représentant de son entreprise.

L’ironie de la situation c’est que la plupart des participants à ses formations sont des employés du gouvernement américain ! Mais ça ne change rien et ils le renvoient en Allemagne sur le prochain vol. “Vous n’avez aucun droit, parce que techniquement vous n’êtes pas encore dans le pays”, lui ont-ils dit. Le programme d’exemption de visa lui est désormais interdit à vie. La communauté Black Hat est furieuse, mais Thomas reste philosophe… il finit par obtenir un visa business et revient l’année suivante, plus fort que jamais.

VxClass devient alors rapidement le produit phare de zynamics. C’est une infrastructure capable de traiter automatiquement les nouveaux malwares en les classifiant automatiquement en familles en utilisant l’analyse de graphes de flux de contrôle. L’outil peut générer des signatures privées en octets (au format ClamAV) pour toute une famille de malwares. VxClass peut par exemple, à partir de 160 extraits de malwares, les classifier automatiquement comme une seule famille et générer un seul pattern pour trouver chaque variante. Mandiant annonce même l’intégration avec VxClass dans leur logiciel de forensique mémoire Memoryze.

Le chevauchement de 2 malwares de la même “famille”

Et en mars 2011, Google rachète zynamics. C’est la consécration ! C’est d’ailleurs probablement VxClass qui intéresse le plus Google dans ce deal, étant donné l’intérêt de l’entreprise pour classifier les malwares et les sites malveillants. Le prix de BinDiff passe alors de plusieurs milliers de dollars à seulement 200 dollars. Google veut démocratiser ces outils de sécurité, et Halvar se retrouve propulsé dans la cour des grands avec le titre de Staff Engineer.

Illustration du principe de l’attaque Rowhammer

Chez Google, il travaille d’abord sur l’intégration et le scaling de sa technologie, puis il retourne à la recherche pure et dure et c’est là qu’il tombe sur quelque chose d’absolument dingue : le Rowhammer.

Le Rowhammer avait été découvert en juin 2014 par des chercheurs de Carnegie Mellon et Intel Labs (Yoongu Kim et ses collègues) dans leur papier “Flipping Bits in Memory Without Accessing Them”. Mais là où les académiques voient un problème de fiabilité, Thomas et Mark Seaborn de l’équipe Project Zero de Google voient une faille de sécurité monumentale.

Le Rowhammer, c’est une de ces découvertes qui font dire “mais comment c’est possible ?!”. En gros, imaginez que la mémoire de votre ordinateur est comme un parking avec des places très serrées. Si vous ouvrez et fermez la portière de votre voiture des milliers de fois très rapidement (on appelle ça “marteler” une ligne de mémoire), les vibrations peuvent faire bouger les voitures garées à côté (les bits dans les lignes adjacentes). Plus concrètement, quand on accède sans arrêt à une même zone de la mémoire, ça crée des perturbations électriques qui peuvent modifier les données stockées juste à côté… un peu comme si l’électricité “débordait” sur les zones voisines.

En mars 2015, Thomas et Mark publient alors leur exploit sur le blog de Project Zero. Les contributions techniques de Thomas incluent une méthode pour attaquer la mémoire des deux côtés en même temps (le “double-sided hammering”… imaginez-vous en train de marteler un mur par les deux faces pour le faire céder plus vite) et une technique astucieuse (le “PTE spraying”) pour transformer cette faille en véritable exploit, même s’il admet modestement que Mark a fait 90% du travail.

Ils surnomment même affectueusement le premier ordinateur où l’exploit fonctionne “Flippy the laptop” ! Leur exploit fonctionne donc en utilisant le row hammering pour induire un bit flip (une inversion de bit) dans une entrée de table de pages (PTE) qui la fait pointer vers une page physique contenant une table de pages appartenant cette fois au processus attaquant. Ça donne alors au processus attaquant un accès en lecture-écriture à une de ses propres tables de pages, et donc à toute la mémoire physique. Les chercheurs rapportent des bit flips avec seulement 98 000 activations de lignes !

La présentation de leurs résultats à Black Hat 2015 fait alors l’effet d’une bombe. Hé oui, une faille qui existe dans pratiquement toute la RAM moderne, qui ne peut pas être patchée par du logiciel, et qui peut être exploitée même depuis JavaScript dans un navigateur ! C’est le cauchemar ultime des responsables sécurité. Cette découverte devient alors le point d’origine de toute une famille d’attaques hardware (RowPress, Half-Double, etc.).

En août 2015, Halvar reçoit le Pwnie Award pour l’ensemble de sa carrière. C’est l’Oscar de la sécurité informatique, avec un jury de chercheurs en sécurité renommés qui sélectionne les gagnants. Et ces derniers reçoivent des trophées “My Little Pony” dorés ! À seulement 34 ans, il est alors décrit comme un “gourou du reverse engineering ayant déjà révolutionné le domaine plusieurs fois”.

Le fameux trophée Pwnie Award - un “My Little Pony” doré remis aux légendes de la sécurité informatique

Quoi qu’il en soit, cette découverte du Rowhammer change profondément la vision de Thomas sur l’informatique. Il se passionne pour la physique informatique, c’est-à-dire ce qui se passe réellement dans le processus de fabrication des puces. “C’est le plus grand spectacle sur Terre”, dit-il, et tire plusieurs leçons importantes. La première c’est qu’on a besoin d’une vraie théorie de l’exploitation. Aussi, que le hardware n’est pas correctement analysé pour anticiper tout ce qui pourrait arriver de pire, et enfin que la recherche sur les défauts des puces dus aux variations de fabrication est extrêmement intéressante.

Après un congé sabbatique d’un an, il retourne alors chez Google en 2016 et rejoint Project Zero, l’équipe d’élite qui cherche les failles zero-day. Son travail se concentre sur la découverte automatique de fonctions de bibliothèques liées statiquement dans les binaires et sur des recherches de similarité ultra-efficaces sur d’énormes quantités de code.

Mais en janvier 2019, nouveau virage à 180 degrés. Thomas quitte Google et co-fonde Optimyze. Cette fois, il change complètement de domaine : fini la sécurité, place à la performance et à l’économie du cloud ! Après 20 ans passés à casser des trucs, il décide de les rendre plus efficaces.

L’idée d’Optimyze est géniale puisqu’avec la fin de la loi de Moore et le passage au SaaS/Cloud, l’efficacité logicielle redevient super importante. Leur produit est un profileur continu multi-runtime qui peut s’installer sur des milliers de machines Linux et vous dire exactement où votre flotte dépense ses cycles CPU, jusqu’à la ligne de code, peu importe le langage (C/C++, Java, Ruby, PHP, Perl, Python, etc.). Le tout avec une technologie eBPF qui permet un déploiement sans friction.

Thomas remarque en effet qu’il y a, je cite, “une quantité énorme de calculs inutiles partout”. Avec les coûts du cloud qui explosent et l’attention croissante sur le CO2 et l’efficacité énergétique, aider les entreprises à optimiser leur code devient crucial. “Avec la fin de la loi de Moore et de Dennard scaling, combinée avec le passage au cloud et la transformation digitale continue de la société, l’efficacité computationnelle va recommencer à compter”, explique-t-il.

En octobre 2021, Elastic rachète Optimyze. Leur idée c’est de combiner le profiling continu d’Optimyze avec les capacités d’analyse et de machine learning d’Elastic pour offrir une observabilité unifiée. Thomas devient alors Distinguished Engineer chez Elastic, où il continue à travailler sur l’efficacité à grande échelle.

Début 2024, après avoir intégré Optimyze dans l’écosystème Elastic, Thomas annonce à nouveau qu’il quitte l’entreprise pour prendre une pause prolongée. Il veut se reposer, et se consacrer à sa famille, sa santé et l’écriture. Mais il ne reste pas inactif longtemps puisque depuis 2019, il est aussi Venture Partner chez eCAPITAL, où il se concentre sur les investissements en cybersécurité et technologies climatiques. Enfin, depuis 2025, il dirige avec Gregor Jehle le groupe de projet Engineering au CNSS e.V.

Ces dernières années, on le voit donner des conférences passionnantes. Par exemple à QCon London en mars 2023, où il présente “Adventures in Performance”. Il y explique comment les choix de design des langages impactent les performances. Notamment comment la culture monorepo de Google et la culture “two-pizza team” d’Amazon affectent l’efficacité du code, et pourquoi la variance statistique est l’ennemi.

À ISSTA 2024 en septembre à Vienne, il donne une keynote intitulée “Reasons for the Unreasonable Success of Fuzzing”, où il analyse pourquoi le fuzzing marche si bien alors que théoriquement, ça ne devrait pas. Il raconte notamment comment dans la culture hacker des années 90, le terme “fuzz-tester” était utilisé comme une insulte pour ceux qui ne savaient pas trouver des bugs en lisant le code.

Ce qui est fascinant avec Thomas Dullien, c’est surtout sa capacité à voir les problèmes sous un angle complètement différent. Là où d’autres voient des bugs, il voit des opportunités. Là où d’autres voient de la complexité, il voit de jolis graphes. Là où d’autres voient des problèmes de fiabilité hardware, il voit des failles de sécurité. C’est cette vision unique qui lui a permis de faire progresser ses domaines de prédilection.

Son approche de l’enseignement est aussi unique. Ses formations Black Hat étaient limitées à 18 étudiants maximum, avec des prérequis techniques élevés et aujourd’hui, Thomas continue d’influencer l’industrie. Que ce soit par ses recherches, ses talks, ou les outils qu’il a créés, son impact est partout. BinDiff est maintenant open source et supporte IDA Pro, Binary Ninja et Ghidra. Le Rowhammer a donné naissance à toute une famille d’attaques hardware et les idées d’Optimyze sur l’efficacité logicielle deviennent de plus en plus pertinentes avec la crise climatique.

Voilà l’histoire de Thomas Dullien. C’est l’histoire d’un gars qui a su transformer sa curiosité en innovations. Une chose est sûre, quand Halvar Flake s’intéresse à quelque chose, l’industrie entière devrait y prêter attention. Que ce soit pour casser des trucs, les analyser, ou les rendre plus efficaces, il trouve toujours un angle nouveau que personne n’avait anticipé.

Sources : Site personnel de Thomas Dullien , Google Project Zero - Exploiting the DRAM rowhammer bug , Black Hat Archives - 2007 US Entry Denial Incident , Silver Bullet Podcast - Interview with Halvar Flake , Elastic acquiert Optimyze , ISSTA 2024 - Keynote on Fuzzing , QCon London 2024 - Adventures in Performance , Heise - Horst Görtz Prize 2006 , Dark Reading - Pwnie Awards 2015 , OffensiveCon - Halvar Flake Biography , eCAPITAL - Thomas Dullien Venture Partner , GitHub - BinDiff Open Source , zynamics - BinDiff , Intel Technology Podcast - Interview with Thomas Dullien , Wikipedia - Row hammer

Je me souviens encore de ce 7 septembre 2017 quand j’ai vu l’annonce du hack d’Equifax débouler dans mes flux RSS. 143 millions d’Américains touchés avec leurs numéros de sécurité sociale, leurs dates de naissance, leurs adresses…etc… tout était dans la nature. Mais le pire dans cette histoire, c’est que ce n’était pas juste une faille technique. C’était un concentré de négligence, d’incompétence et de cupidité qui allait devenir le cas d’école de tout ce qu’il ne faut pas faire en cybersécurité. Trêve de blabla, je vous raconte tout ça tout de suite !

Pour comprendre l’ampleur du désastre, il faut d’abord comprendre ce qu’est Equifax. Fondée en 1899 sous le nom de Retail Credit Company (oui, cette entreprise est plus vieille que le FBI), c’est l’une des trois grandes agences de crédit américaines avec Experian et TransUnion. Ces entreprises collectent des informations sur pratiquement tous les Américains adultes telles que l’historique de crédit, dettes, paiements, emplois… Bref, tout ce qui permet de calculer votre score de crédit, ce fameux nombre qui détermine si vous pouvez avoir un prêt, louer un appartement, ou même décrocher certains jobs.

Le truc avec Equifax, c’est que vous n’avez jamais demandé à être leur client. Ils collectent vos données que vous le vouliez ou non. En 2017, ils avaient des dossiers sur environ 820 millions de consommateurs dans le monde, dont 147 millions rien qu’aux États-Unis. C’est comme si une entreprise privée détenait le dossier médical de chaque citoyen, sauf que là, c’est votre vie financière. John Oliver l’a parfaitement résumé pendant son émission : “Nous ne sommes pas les clients d’Equifax. On n’est pas le gars qui achète le bucket de poulet… On est les putains de poulets !”

Richard Smith en était le CEO depuis 2005. Un vétéran de General Electric où il avait passé 22 ans, grimpant les échelons jusqu’à devenir Corporate Officer en 1999. Diplômé de Purdue University en 1981, Smith était le parfait exemple du CEO corporate américain : costard impeccable, sourire Colgate et salaire de base de 1,45 million de dollars par an, plus des bonus qui pouvaient tripler ce montant. Sous sa direction, Equifax était devenue une machine à cash, avec des revenus dépassant les 3 milliards de dollars par an et une capitalisation boursière qui était passée de 3 à 20 milliards.

Mais derrière cette façade de réussite, l’infrastructure IT de l’entreprise était un véritable château de cartes…

Richard Smith lors de son témoignage devant le Congrès américain en octobre 2017

Tout commence donc le 7 mars 2017. Ce jour-là, Apache Software Foundation publie un bulletin de sécurité critique estampillé CVE-2017-5638. C’est une vulnérabilité dans Apache Struts, un framework Java utilisé par des milliers d’entreprises pour leurs applications web. La faille est sérieuse car elle permet l’exécution de code à distance via une manipulation du header Content-Type dans les requêtes HTTP. En gros, un hacker peut injecter des commandes OGNL (Object-Graph Navigation Language) et prendre le contrôle total du serveur.

Bref, si vous avez une application vulnérable exposée sur Internet, n’importe qui peut devenir root sur votre machine…

Apache publie alors un patch le jour même. C’est là que les choses deviennent intéressantes car le 8 mars, le Department of Homeland Security envoie une alerte à toutes les grandes entreprises américaines, dont Equifax. “Patchez immédiatement”, dit le message. Le 9 mars, l’équipe sécurité d’Equifax fait suivre l’alerte en interne avec pour instruction de patcher tous les systèmes vulnérables sous 48 heures. Graeme Payne, le Chief Information Officer responsable des plateformes globales, supervise l’opération.

Sauf que voilà, Equifax, c’est une entreprise avec des milliers de serveurs, des centaines d’applications, et une dette technique monumentale. Le portail ACIS (Automated Consumer Interview System), utilisé pour gérer les litiges des consommateurs sur leur crédit, tourne sur une vieille version d’Apache Struts datant des années 1970, et devinez quoi ? Personne ne le patche. Les scans de sécurité lancés le 15 mars ne trouvent rien.

Pourquoi ?

Et bien parce que l’outil de scan n’était pas configuré pour vérifier le portail ACIS. En gros, c’est comme chercher ses clés partout sauf dans la poche où elles sont.

Apache Struts, le framework vulnérable au cœur du hack d’Equifax

Le 10 mars 2017, trois jours après la publication du patch, les premiers hackers frappent. Ce ne sont pas encore les gros poissons, juste des opportunistes qui scannent Internet avec des outils automatisés. Des kits d’exploitation de CVE-2017-5638 circulent déjà sur le dark web, et Metasploit a même sorti un module le 7 mars à 6h21 UTC. Les premiers intrus trouvent alors le portail ACIS d’Equifax grand ouvert.

Les logs montreront plus tard que ces premiers hackers étaient probablement des amateurs. Ils se baladent un peu dans le système, réalisent qu’ils sont chez Equifax, mais ne vont pas plus loin. Pourquoi ? Probablement parce qu’ils ne réalisent pas la mine d’or sur laquelle ils sont tombés. Ou peut-être qu’ils ont eu peur. Toujours est-il qu’ils font ce que font tous les petits hackers quand ils trouvent un gros poisson : ils vendent l’accès.

C’est là qu’entrent en scène nos véritables protagonistes : l’unité 54th Research Institute de l’Armée Populaire de Libération chinoise. Wu Zhiyong, Wang Qian, Xu Ke et Liu Lei. Quatre officiers de l’armée chinoise spécialisés dans le cyber-espionnage économique. Ces types, c’est pas des script kiddies qui utilisent des outils trouvés sur GitHub. Non, ils font partie de l’élite cyber de la Chine, formés et financés par l’État pour voler les secrets économiques de l’Occident. Le 54th Research Institute, c’est le cousin moins connu mais tout aussi dangereux de la fameuse Unit 61398 (APT1) basée à Shanghai dont je vous parlais il y a quelques jours.

Les hackers chinois commencent leur travail mi-mai. Ils sont méthodiques, patients. D’abord, ils installent 30 web shells, des portes dérobées qui leur permettent de revenir quand ils veulent. Puis ils commencent à explorer le réseau. Et c’est là qu’ils tombent sur le jackpot, un truc tellement énorme qu’ils ont dû se pincer pour y croire.

Dans un répertoire non protégé, ils trouvent un fichier texte. Un simple fichier texte contenant… les identifiants et mots de passe de dizaines de serveurs. En clair. Pas chiffrés. Juste là, comme ça…

Parmi ces identifiants, plusieurs utilisent la combinaison sophistiquée “admin/admin”. Oui, vous avez bien lu. Une entreprise qui gère les données financières de 147 millions d’Américains utilisait “admin” comme nom d’utilisateur et “admin” comme mot de passe. C’est le genre de truc qu’on voit dans les films où on se dit “c’est trop gros, personne n’est aussi con”. Eh bien si.

Mais attendez, ça devient encore mieux.

Susan Mauldin, la Chief Security Officer d’Equifax à l’époque n’a aucun background en sécurité informatique. Elle a juste un Bachelor et un Master en… composition musicale de l’Université de Géorgie. Oui, la personne responsable de la sécurité des données de 147 millions d’Américains avait fait des études de musique. Certes, elle avait travaillé chez HP, SunTrust Banks et First Data avant d’arriver chez Equifax en 2013, mais son profil LinkedIn (qu’elle a rapidement rendu privé après le hack en changeant son nom en “Susan M.”) ne mentionnait aucune formation en sécurité. Dans une interview supprimée depuis, elle avait déclaré : “On peut apprendre la sécurité”.

Visiblement, pas assez bien…

Avec ces identifiants “admin/admin”, les hackers peuvent maintenant se balader dans le réseau d’Equifax comme chez eux. Ils accèdent à trois bases de données ACIS, puis à 48 autres bases de données. Au total, ils vont exécuter plus de 9 000 requêtes SQL sur une période de 76 jours. Plus de deux mois durant lesquels nos quatre militaires chinois pillent les données les plus sensibles de la moitié de la population américaine, et personne ne s’en aperçoit.

Mais comment c’est possible ? Comment une entreprise de cette taille peut-elle ne pas voir que des téraoctets de données sortent de ses serveurs ? Et bien la réponse tient en deux mots : certificat expiré.

Equifax avait bien des outils de monitoring réseau. Des trucs sophistiqués qui analysent le trafic, détectent les anomalies, sonnent l’alarme quand quelque chose cloche. Sauf que ces outils ont besoin de déchiffrer le trafic SSL pour voir ce qui se passe. Et pour ça, il leur faut un certificat SSL valide. Sauf que le certificat d’Equifax avait expiré… 10 mois plus tôt. Personne ne l’avait renouvelé, du coup, tout le trafic chiffré passait sans être inspecté. Les hackers pouvaient donc exfiltrer des gigaoctets de données chaque jour, et c’était invisible pour les systèmes de sécurité.

Dommage…

Et les hackers sont malins. Ils ne veulent pas se faire repérer, alors ils procèdent méthodiquement. Ils compressent les données en petits paquets de 10 MB. Ils utilisent 34 serveurs relais dans 20 pays différents pour masquer leur origine. Ils effacent les logs au fur et à mesure. C’est du travail de pro, le genre d’opération que seul un État peut financer et organiser.

Entre mai et juillet 2017, ils aspirent tout : 145,5 millions de numéros de sécurité sociale, 147 millions de noms et dates de naissance, 99 millions d’adresses, 209 000 numéros de cartes de crédit avec leurs dates d’expiration, 182 000 documents personnels contenant des informations sur les litiges de crédit. Sans oublier les permis de conduire de 10,9 millions d’Américains et les données de 15,2 millions de Britanniques et 19 000 Canadiens. C’est le casse du siècle, version numérique.

Pendant ce temps, la vie continue chez Equifax. Richard Smith touche son bonus de 3 millions de dollars pour l’année 2016. Susan Mauldin, la Chief Musician Security Officer, gère la sécurité de l’entreprise tranquillou. Les affaires tournent, l’action monte. Tout va bien dans le meilleur des mondes. C’est déjà le troisième incident de sécurité majeur depuis 2015, mais bon, qui compte ?

L’action Equifax continuait de grimper pendant que les hackers pillaient les données

Puis le 29 juillet 2017, un samedi, un administrateur système décide enfin de renouveler ce fameux certificat SSL expiré. Probablement un stagiaire qui s’ennuyait ou un admin consciencieux qui faisait du ménage. Dès que le nouveau certificat est installé, les outils de monitoring se remettent à fonctionner, et là, c’est la panique ! Le système détecte immédiatement du trafic suspect vers la Chine avec des gigaoctets de données qui sortent du réseau.

L’équipe sécurité est alors appelée en urgence. Ils coupent l’accès au portail ACIS, analysent les logs (ceux qui n’ont pas été effacés), et commencent à réaliser l’ampleur du désastre. Le 30 juillet, ils appellent Mandiant, la Rolls-Royce des entreprises de sécurité informatique rachetée par FireEye, spécialisée dans les incidents de ce type et qui avait déjà enquêté sur les attaques de l’Unit 61398.

Et le 31 juillet, Graeme Payne informe Richard Smith de la situation. Le CEO comprend immédiatement que c’est une catastrophe. Smith dira plus tard au Congrès : “J’étais ultimement responsable de ce qui s’est passé sous ma surveillance.” Mais au lieu d’informer immédiatement le public, la direction décide d’abord de… “gérer la situation en interne”.

Et c’est là que l’histoire devient vraiment sale. Le 1er et 2 août, alors que seule une poignée de dirigeants connaît l’ampleur de la fuite, trois executives d’Equifax vendent pour 1,8 million de dollars d’actions. Le CFO John Gamble vend pour 946 000$, le président de l’unité US Information Solutions Joseph Loughran pour 584 000$, et le président de Workforce Solutions Rodolfo Ploder pour 250 000$. Pure coïncidence, bien sûr.

Plus tard, une enquête interne conclura qu’ils n’étaient pas au courant de la fuite au moment de la vente. Smith témoignera devant le Congrès : “Nous avons notifié le FBI et engagé un cabinet d’avocats le 2 août. À ce moment-là, nous ne voyions qu’une activité suspecte. Les trois individus ont vendu leurs actions les 1er et 2 août. Nous n’avions aucune indication de brèche de sécurité à ce moment.” Permettez-moi d’être sceptique car c’est une sacrée coïncidence de vendre ses actions juste avant l’annonce d’une catastrophe qui va faire chuter le cours de 35%.

Pendant ce temps, Mandiant mène son enquête. Leurs experts reconstituent le puzzle, identifient la vulnérabilité Apache Struts, découvrent les fichiers de mots de passe en clair, tracent les connexions vers la Chine via les 34 serveurs relais. Le rapport est accablant : négligence à tous les niveaux, absence de segmentation réseau, données sensibles non chiffrées, monitoring défaillant, 120 millions de numéros de sécurité sociale stockés en clair, données de cartes de crédit dans des fichiers Excel sans protection. C’est un manuel de ce qu’il ne faut pas faire en sécurité informatique.

Le 7 septembre 2017, six semaines après la découverte, Equifax annonce enfin publiquement la faille. Le communiqué est un chef-d’œuvre de langue de bois corporate : “Equifax a subi un incident de cybersécurité potentiellement impactant environ 143 millions de consommateurs américains.” Potentiellement ? 143 millions, c’est 44% de la population des États-Unis !

La réaction est immédiate et brutale. L’action chute en bourse de 13% en quelques heures, passant de 142$ à 92$ en quelques jours. Les médias s’emparent de l’affaire et John Oliver dédie un segment entier de “Last Week Tonight” au désastre, expliquant que si ça n’était pas arrivé pendant une période où chaque jour les gros titres étaient “Tout Part en Couilles Encore Aujourd’hui”, le hack d’Equifax aurait été LA nouvelle du mois. Les politiciens demandent des comptes et plus de 52 000 plaintes sont déposées. Les class actions pleuvent.

Et les 147 millions de victimes ? Elles découvrent qu’elles sont peut-être victimes d’un vol d’identité sans avoir jamais entendu parler d’Equifax.

Mais attendez, ça devient encore pire car Equifax met en place un site web pour que les gens puissent vérifier s’ils sont affectés : equifaxsecurity2017.com. Sauf que le site est tellement mal fait que les experts en sécurité pensent que c’est un site de phishing ! Brian Krebs, expert renommé en sécurité, qualifie la réponse d’Equifax de “dumpster fire” (feu de poubelle)et un développeur, Nick Sweening, achète même le domaine securityequifax2017.com pour démontrer à quel point c’est facile de créer un site de phishing crédible.

Et vous voulez savoir le plus drôle ?

Le compte Twitter officiel d’Equifax tweetera huit fois le lien vers le FAUX site !

En plus, les termes et conditions du site incluent une clause d’arbitrage qui stipule que si vous utilisez le site pour vérifier si vous êtes affecté, vous renoncez à votre droit de poursuivre Equifax en justice ! La grogne est telle qu’ils doivent retirer cette clause après quelques jours. Sans compter que le site retourne des résultats apparemment aléatoires. Par exemple, des journalistes testent avec des fausses données et obtiennent quand même des réponses.

Le 15 septembre, à peine une semaine après l’annonce publique, Susan Mauldin, la CSO, “prend sa retraite”. David Webb, le CIO, fait de même. Et leurs profils LinkedIn disparaissent comme par magie. Même leurs interviews sont retirées d’Internet. Equifax utilise d’ailleurs le mot “retraite” plutôt que “licenciement”, ce qui signifie qu’ils partent probablement avec de confortables indemnités.

Et le 26 septembre, c’est au tour de Richard Smith. Le CEO “prend sa retraite” lui aussi, mais contrairement à ses subordonnés, on connaît exactement ce qu’il emporte : 90 millions de dollars. Oui, vous avez bien lu. 90 millions. 72 millions pour 2017 (salaire + stocks + options), plus 18,4 millions de retraite. Pendant que 147 millions d’Américains vont devoir surveiller le montant de leurs crédits pour le reste de leur vie, lui part avec l’équivalent de 61 cents par victime.

Techniquement, il ne touche pas de prime de départ puisqu’il “démissionne”. Mais il garde toutes ses stock-options et ses droits à la retraite. C’est beau, le capitalisme américain, quand même non ?

Richard Smith est parti avec un parachute doré de 90 millions de dollars

Pendant ce temps, Graeme Payne, le CIO qui avait supervisé les scans de sécurité ratés, se fait virer le 2 octobre. Pas de retraite dorée pour lui. Il est désigné comme bouc émissaire pour ne pas avoir fait suivre un email sur la vulnérabilité Apache Struts. Dans son témoignage au Congrès, il dira : “Dire qu’un vice-président senior devrait faire suivre chaque alerte de sécurité à des équipes trois ou quatre niveaux en dessous… ça n’a aucun sens. Si c’est le processus sur lequel l’entreprise doit compter, alors c’est ça le problème.”

L’enquête du Congrès est un spectacle en soi. Le 4 octobre 2017, pendant que Smith témoigne devant le Senate Banking Committee, une activiste nommée Amanda Werner, déguisée en Rich Uncle Pennybags (le Monopoly Man), s’assoit juste derrière lui.

Pendant toute l’audition, elle essuie son front avec des faux billets de 100$, ajuste son monocle et twirle sa moustache. Les images deviennent virales instantanément. Werner expliquera plus tard : “Je suis habillée en Monopoly Man pour attirer l’attention sur l’utilisation par Equifax et Wells Fargo de l’arbitrage forcé comme carte ‘sortie de prison gratuite’ pour leurs méfaits massifs.”

Amanda Werner déguisée en Monopoly Man trollant l’audition au Sénat

Le témoignage de Smith devant le Congrès révèle l’ampleur de l’incompétence. Les sénateurs, notamment Elizabeth Warren, le grillent sur le timing suspect des ventes d’actions et les failles de sécurité. Warren est particulièrement féroce, demandant pourquoi Equifax a obtenu un contrat de sécurité avec l’IRS après le hack.

Le rapport du Government Accountability Office qui s’en suivra est cinglant : “Equifax n’a pas segmenté ses bases de données pour limiter l’accès, n’a pas chiffré les données sensibles, et n’a pas maintenu à jour ses certificats de sécurité.” En gros, ils ont fait absolument tout ce qu’il ne fallait pas faire. Le rapport révèle aussi que le système ACIS datait littéralement des années 1970 et n’avait jamais été vraiment modernisé.

Mais le plus fou dans tout ça, c’est que malgré l’ampleur du désastre, les conséquences pour Equifax ont été… limitées. En juillet 2019, ils acceptent un accord avec la FTC de 575 millions de dollars, extensibles à 700 millions. Ça paraît énorme, mais divisé par 147 millions de victimes, ça fait moins de 4 dollars par personne.

Les victimes peuvent réclamer jusqu’à 125$ en cash, ou 10 ans de monitoring de crédit gratuit. Mais y’a un hic que personne n’a vu venir… le fond prévu pour les paiements n’est que de 31 millions. Avec 147 millions de victimes potentielles, si seulement 248 000 personnes demandent les 125$, le fond est vide. Au final, 4,5 millions de personnes réclament le cash. Alors la plupart des gens qui demandent cet argent cash reçoivent… 7 dollars. Pas 21 cents comme initialement calculé par les pessimistes, mais pas 125$ non plus. Sept malheureux dollars pour avoir eu toute leur vie financière exposée.

Pendant ce temps, Equifax se porte bien. Leur action, qui était tombée à 92$ après le hack, est remontée à plus de 240$ en 2025. Ils ont même eu le culot d’essayer de vendre des services de protection d’identité TrustedID Premier aux victimes. “Vos données ont été volées à cause de notre négligence, mais pour 19,99$ par mois, on peut surveiller si quelqu’un les utilise !” Le cynisme à l’état pur. Sans compter que les termes d’utilisation de TrustedID incluaient initialement une clause d’arbitrage forcé où en vous inscrivant, vous renonciez à votre droit de les poursuivre.

Et les hackers chinois ?

En février 2020, le département de Justice inculpe officiellement Wu Zhiyong, Wang Qian, Xu Ke et Liu Lei. Les charges sont fraude informatique, espionnage économique, fraude électronique. Le grand jury d’Atlanta retient neuf chefs d’accusation contre eux mais c’est symbolique car comme vous le savez, ils sont en Chine, intouchables. Ils ne seront jamais extradés ni jugés et cela même si le FBI a bien mis leurs photos sur son site “Wanted”, avec une récompense pour toute information… Mais tout le monde sait que c’est du théâtre.

L’ironie, c’est que malgré le vol de 147 millions d’identités, y’a eu étonnamment peu de cas de fraude directement liés au hack Equifax. Une étude de Carnegie Mellon University l’a même confirmé.

Pourquoi ? Et bien parce que les hackers étaient des espions du 54th Research Institute, et pas des criminels de droit commun. Leur but n’était donc pas de vendre les données sur le dark web ou de vider des comptes bancaires. C’était de l’espionnage d’État, probablement pour identifier des cibles potentielles pour le recrutement, des agents à retourner, ou simplement pour constituer une base de données géante sur la population américaine pour de futures opérations.

Mais ça ne rend pas la situation moins grave, au contraire car quelque part en Chine, y’a une base de données avec les informations personnelles et financières de la moitié de la population américaine. Et ces données ne périment pas… Dans 10, 20, 30 ans, elles seront toujours utilisables puisque les numéros de sécurité sociale ne changent pas. C’est donc une épée de Damoclès permanente au-dessus de la tête de 147 millions de personnes.

Ce hack a eu pour effet d’accélérer l’adoption de lois sur la protection des données. Le CCPA (California Consumer Privacy Act) et d’autres réglementations similaires sont en partie une réponse au hack d’Equifax. L’idée que des entreprises puissent collecter et stocker des données sensibles sans le consentement explicite des consommateurs et sans protection adéquate est devenue inacceptable. Smith lui-même a suggéré dans son témoignage de remplacer les numéros de sécurité sociale par un système plus sécurisé, proposant un “partenariat public-privé pour évaluer comment mieux protéger les données des Américains”.

Mais fondamentalement, le modèle n’a pas changé. Equifax, Experian et TransUnion continuent de collecter les données des américains sans leur permission. Elles continuent de les vendre à qui veut payer. Et elles continuent d’être des cibles de choix pour les hackers du monde entier. D’ailleurs, hasard de la publication, TransUnion vient en 2025 d’être victime d’un hack, exposant les numéros de sécu de 4,4 millions d’américains. L’histoire se répète…

Bref, ce hack d’Equifax, c’est l’histoire de la faillite d’un système. Un système où des entreprises privées ont un pouvoir démesuré sur des vies, sans avoir de comptes à rendre. Un système où la négligence criminelle est punie par une tape sur les doigts et un golden parachute de plusieurs millions de dollars. Un système où les victimes sont laissées à leur compte pendant que les responsables s’en tirent….

Mais c’est aussi une leçon sur le danger de la dette technique accumulée depuis les années 1970. Sur la nécessité de régulations strictes pour protéger les données personnelles. Et surtout, sur le fait qu’aucune entreprise n’est “too big to fail” quand il s’agit de cybersécurité. Si vous pouvez être hacké avec “admin/admin”, vous méritez presque de couler, d’ailleurs…

Aujourd’hui, en 2025, Equifax a un nouveau CEO, Mark Begor, un nouveau CISO (un vrai cette fois), Jamil Farshchi, ancien de Visa et Time Warner, et des procédures de sécurité renforcées.

Quoiqu’il en soit, dans le monde de la collecte de données, nous ne sommes pas des clients. Nous sommes le produit. Et quand le produit est volé, c’est encore nous qui en payons encore le prix.

Et c’est ça, le vrai scandale.

Sources : Rapport officiel du Congrès américain sur le breach Equifax (2018) , Inculpation du Department of Justice contre les hackers chinois (2020) , Rapport du Government Accountability Office , Témoignage de Richard Smith devant le Congrès (2017) , Analyse technique de la vulnérabilité Apache Struts CVE-2017-5638 , Settlement FTC-Equifax (2019) , Rapport Mandiant sur l’investigation forensique , Timeline détaillée du breach - CSO Online , John Oliver sur Last Week Tonight , Interview d’Amanda Werner, le “Monopoly Man”

Imaginez-vous devant votre webcam, en train de contracter méthodiquement vos zygomatiques pour essayer de reproduire le sourire le plus mécanique de l’histoire de la tech. Bienvenue sur SmileLikeZuck.com , probablement l’utilisation la plus absurde de la reconnaissance faciale que j’ai vue cette année.

Le concept est simple : vous activez votre webcam, le site vous montre une photo de Zuckerberg avec son fameux sourire robotique, et vous devez reproduire exactement la même expression faciale. Plus votre mimique se rapproche de celle du patron de Meta, plus votre score augmente. C’est débile, c’est addictif, et c’est exactement le genre de projet que j’adore !

Lidée de ce site serait née au Recurse Center, un endroit à New York décrit comme un endroit de “retraite” pour les développeurs. Le concepteur de ce projet voulait au départ créer un jeu plus générique où on imiterait n’importe quelle grimace, mais ça manquait de direction artistique…

Techniquement, tout repose sur MediaPipe de Google, une bibliothèque qui permet de faire du tracking facial directement dans le navigateur. Le développeur avoue que faire fonctionner MediaPipe avec React peut être un peu galère, mais le résultat vaut le coup. L’application analyse en temps réel les points clés de votre visage et les compare avec ceux de Zuckerberg sur la photo de référence.

Les expressions faciales de Zuckerberg et les votres sont alors analysées à partir des unités d’action faciale AU 6 (muscle qui relève les joues) et AU 12 (muscle qui tire les coins de la bouche). SmileLikeZuck transforme donc cette analyse scientifique en jeu absurde.

Alors, prêts à entraîner vos muscles faciaux pour atteindre le niveau de robotisation du sourire de Zuck ? Attention, c’est plus difficile qu’il n’y paraît.

Direction smilelikezuck.com pour tenter l’expérience et n’oubliez pas de cliquer sur Zuck+ à la fin, ça vous fera un petit bonus marrant quand vous relancerez une session.

Merci à Lilian pour cette découverte !

Hier soir, je suis tombé sur NetPeek et franchement, ça m’a fait plaisir de voir qu’enfin quelqu’un s’attaque au problème de la complexité de nmap pour les utilisateurs normaux.

NetPeek, c’est donc cette nouvelle application qui vient d’arriver sur Flathub et qui promet de simplifier drastiquement le scanning réseau sous Linux. Développée par ZingyTomato avec Python et GTK4/libadwaita, l’app adopte le design moderne de GNOME pour offrir une alternative graphique aux outils en ligne de commande comme nmap.

La première chose qui frappe quand on lance NetPeek, c’est donc sa simplicité. L’interface est épurée, moderne, et on comprend tout de suite ce qu’on doit faire. Vous saisissez votre plage d’adresses IP (notation CIDR, ranges ou adresses simples), vous cliquez sur “Scanner” et hop, l’application se met au travail.

Ce qui rend NetPeek particulièrement efficace également, c’est son système “multithreadé” qui accélère considérablement les scans. L’app détecte ainsi automatiquement votre plage IP locale, ce qui évite de se prendre la tête avec les configurations et une fois le scan terminé, les appareils s’affichent dans l’ordre croissant avec leurs ports ouverts. Ensuite, vous pouvez copier les adresses IP d’un simple clic.

L’outil s’appuie sur des bibliothèques Python classiques telles que socket pour les opérations réseau, ipaddress pour la validation des IP, threading pour le scan concurrent et ping3 pour tester la disponibilité des hôtes.

Et ce qui me plaît avec NetPeek, c’est qu’il ne cherche pas à rivaliser avec les mastodontes comme nmap ou Zenmap. Non, son objectif est clair, à savoir répondre à la question “Quels sont les appareils actifs sur mon réseau et quels ports sont ouverts ?” sans avoir besoin d’un doctorat en administration réseau. D’une certaine manière, ça me fait penser un peu à Angry IP Scanner …

L’installation se fait principalement via Flathub avec la commande

flatpak install flathub io.github.zingytomato.netpeek

Mais les utilisateurs d’Arch Linux peuvent aussi passer par les packages AUR netpeek ou netpeek-git.

L’app s’intègre notamment parfaitement dans l’environnement GNOME moderne avec son interface libadwaita qui respecte les thèmes système. Voilà, si ça vous chauffe, vous pouvez télécharger NetPeek directement depuis Flathub ou consulter le code source sur GitHub .

Ça devrait bien vous aider pour surveiller votre réseau domestique, diagnostiquer des problèmes de connectivité ou simplement découvrir tous les appareils connectés chez vous.

Source

Bon, alors voilà. Il faut que je vous parle d’un truc un peu gênant. Vous vous souvenez de mon article bien trollesque sur Windows qui transformait vos SSD en gruyère de Schrödinger ? Bah il semblerait que j’aie un peu… comment dire… trollé trop fort sur ce coup-là.

Hé oui car Microsoft vient de sortir un démenti officiel dans lequel ils déclarent qu’après investigation, ils n’ont trouvé “aucune connexion entre la mise à jour de sécurité Windows d’août 2025 et les types de pannes de disques durs rapportés sur les réseaux sociaux.”

Oups.

Donc voilà ce qui s’est passé… des utilisateurs, principalement japonais, avaient signalé que leurs SSD disparaissaient mystérieusement après avoir installé la mise à jour KB5063878. Sur le papier, ça semblait crédible puisqu’il y avait des témoignages précis, des modèles de SSD identifiés (Western Digital SA510, Corsair Force MP600), des contrôleurs spécifiques mentionnés (Phison, Maxio). Même Phison avait réagi en reconnaissant des “effets à l’échelle industrielle”.

Mais Microsoft, de son côté, a fait ses propres tests avec ses partenaires fabricants de stockage et résultat, leur télémétrie interne n’a montré aucune augmentation des pannes de disque. Et leurs tests en labo n’ont rien révélé non plus de probant.

L’histoire avait commencé avec un utilisateur Twitter @Necoru_cat qui avait signalé le problème, repris ensuite par les médias japonais puis internationaux. Toutefois, malgré le communiqué de Microsoft, Phison continue de dire qu’ils “travaillent avec Microsoft pour résoudre le problème”. Donc soit ils sont très diplomatiques, soit il y a encore des zones grises… mais bon, face au démenti catégorique de Microsoft avec tests à l’appui, je dois reconnaître que mon article bien trolling était basé sur des informations incomplètes au moment où je l’ai rédigé.

Bref, tout ça pour vous dire que je fais mon mea culpa. J’ai relayé pour l’amour du lol, une info qui semblait solide mais qui finalement s’est révélée inexacte. Ça arrive, même aux meilleurs (dont je fais sans aucun doute partie ^^). Notez que Microsoft a demandé aux utilisateurs qui pensent avoir été affectés de leur faire des retours pour creuser davantage, mais leur position officielle reste claire : Il n’y a pas de lien établi entre KB5063878 et les pannes SSD.

Source

Ce matin, j’ai lu un truc qui m’a fait tilter. Vous saviez que Super Mario 64, ce chef-d’œuvre absolu qui a changé le jeu vidéo à tout jamais, était en fait un gouffre à mémoire sur Nintendo 64 ? C’est un programmeur nommé Kaze Emanuar s’est amusé à disséquer le code source et les résultats de son analyse sont plutôt… surprenants.

Pour comprendre l’ampleur du problème, il faut se replacer dans le contexte. La N64 avait 4 Mo de RDRAM rapide. Pour vous donner une idée, c’est à peine la taille d’une photo prise avec votre smartphone aujourd’hui. Et dans ces 4 Mo, il fallait caser les textures, le code, la musique, les buffers de sortie et les états des acteurs. Autant dire que chaque octet comptait.

Et pourtant, Mario 64 dilapidait cette précieuse mémoire comme s’il n’y avait pas de lendemain. Le jeu semble en effet avoir été livré dans une version debug avec “du code inutile partout”.

Le système audio à lui seul bouffe 512 Ko. Mais le plus dingue, c’est qu’au lieu de réutiliser intelligemment les buffers, le jeu alloue 4 buffers d’échantillons par note alors qu’un seul suffirait. Du coup c’est 51 Ko de RAM qui partent en fumée, soit l’équivalent de 17 textures. Ouch.

Les fonctions mathématiques ne sont pas en reste non plus. Les tables de sinus et cosinus auraient pu être divisées par quatre grâce à la symétrie circulaire, économisant 12 Ko supplémentaires. C’est assez pour 4 nouvelles textures de plus et un léger gain de performances.

Mais le plus gros gâchis se trouve sans doute dans la gestion des objets. Chaque acteur, même les plus simples, se voit allouer 608 octets peu importe sa complexité. Une allocation uniforme complètement inutile qui fait mal au cœur de tout développeur qui se respecte. Et je ne parle même pas du chargement des assets ! Le jeu charge des banks mémoire complètes incluant des objets totalement non pertinents comme des algues ou des mines aquatiques, alors qu’un seul élément est nécessaire.

Le build NTSC de Mario 64 n’utilisait même pas les optimisations du compilateur. Comme si Nintendo avait oublié d’activer le mode “optimisé” avant de lancer les cartouches en production. Mais bon, avant de taper sur l’équipe de développement, remettons les choses en perspective. On parle de 7 programmeurs qui avaient seulement 20 mois pour créer un jeu incroyable sur une console dont le hardware et les outils de développement étaient encore en cours de finalisation. Dans ce contexte, avoir 4 Mo de RAM rapide, c’était le luxe absolu et l’optimisation pouvait attendre.

Les travaux récents de programmeurs comme Kaze Emanuar montrent donc qu’avec les techniques modernes, on peut obtenir des performances 6 fois meilleures en utilisant le N64 Expansion Pack, qui est quelque chose que l’équipe originale n’avait pas.

La preuve que les développeurs ont appris de leurs erreurs c’est The Legend of Zelda: Ocarina of Time, sorti plus tard, qui était infiniment plus optimisé. Les leçons avaient été tirées et les outils s’étaient améliorés.

Au final, Mario 64 reste un monument du jeu vidéo malgré ses défauts techniques. Et franchement, quand on voit le résultat final, on se dit que quelques Mo gaspillés, ça valait largement le coup pour un jeu qui a changé l’industrie.

Source

Ça va, elle vous plait toujours ma série de l’été ? Je suis loin d’avoir fini mais on fera une petite pause bientôt. Toutefois, rassurez-vous, j’en ai encore sous le pied. La preuve avec cette nouvelle histoire d’un ver informatique qui a foutu le bordel sur Internet en juillet 2001.

Code Red. Un nom qui fait encore trembler les admins système qui l’ont vécu. Des centaines de milliers de serveurs infectés en quelques heures, des milliards de dégâts, et la Maison Blanche obligée de changer l’adresse IP de son site web pour éviter une attaque DDoS massive.

Et tout ça, découvert par deux hackers qui buvaient du Mountain Dew Code Red dans leur bureau de Californie un vendredi soir. Mais le plus dingue dans cette histoire, c’est surtout que la vulnérabilité exploitée avait été découverte un mois plus tôt.

Microsoft avait même publié le patch MS01-033, mais personne ne l’avait installé. Du coup, le 19 juillet 2001, Internet a découvert ce que pouvait faire un ver capable de se propager automatiquement sans intervention humaine….

Voici donc l’histoire complète de Code Red, depuis la découverte de la faille jusqu’à la panique mondiale.

L’histoire commence avec Riley Hassell, qui travaille chez eEye Digital Security à Aliso Viejo en Californie. En juin 2001, ce chercheur en sécurité passe ses soirées à chercher des vulnérabilités dans les logiciels populaires. Pas pour faire le mal, juste pour le défi, pour la gloire dans la communauté underground. Riley fait partie de cette génération de hackers qui considère que trouver des failles est un sport intellectuel.

Un soir, Riley s’attaque à IIS (Internet Information Services), le serveur web de Microsoft. IIS propulse des millions de sites web dans le monde, des petites entreprises aux gouvernements et si vous trouvez une faille dedans, c’est le jackpot. Riley commence donc à fuzzer l’ISAPI (Internet Server Application Programming Interface) d’IIS, envoyant des requêtes malformées pour voir comment le serveur réagit. Il faut savoir qu’à l’époque, IIS 5.0, intégré à Windows 2000, était devenu une cible de choix avec ses nouvelles fonctionnalités WebDAV et ses méthodes d’authentification avancées.

Et là, bingo. Riley découvre que si vous envoyez une requête GET avec une URL super longue au fichier idq.dll (utilisé par l’Indexing Service d’IIS), le serveur plante. Mieux encore, avec la bonne séquence de caractères, vous pouvez exécuter du code arbitraire sur le serveur. C’est ce qu’on appelle un buffer overflow, le Saint Graal des vulnérabilités. Plus précisément, la faille se trouve dans la façon dont idq.dll gère les requêtes puisque le filtre ISAPI .ida (indexing service) ne vérifie pas correctement les limites de ses buffers d’entrée.

Riley et l’équipe d’eEye publient leur découverte le 18 juin 2001. Microsoft réagit immédiatement en publiant le bulletin de sécurité MS01-033 et un patch. L’alerte est claire, cette vulnérabilité est critique car elle permet de prendre le contrôle total d’un serveur IIS avec des privilèges SYSTEM. Le bulletin précise aussi que la vulnérabilité affecte IIS 4.0 sur Windows NT 4.0 et IIS 5.0 sur Windows 2000.

Sauf que voilà, personne n’installe ce patch. C’est dramatique, mais les admins système sont débordés, les entreprises ont peur de “casser” leurs applications, et puis bon, qui va vraiment exploiter cette faille ? Un mois passe et les serveurs restent vulnérables…

Les premiers signes d’alerte apparaissent finalement le 12 juillet 2001. Ken Eichman, ingénieur sécurité senior chez Chemical Abstract Services, remarque quelque chose d’étrange dans ses logs. Trois tentatives d’accès illégales depuis une seule adresse IP, apparemment en provenance de l’Université de Foshan en Chine. Et le lendemain, le 13 juillet, c’est l’escalade : 611 attaques depuis 27 serveurs différents. Eichman, contributeur régulier de DShield.org, alerte alors Johannes Ullrich. Le samedi 14 juillet, les sources d’attaque dépassent les 1 000. Le lundi 16 juillet, la confirmation tombe : c’est un ver.

A l’époque, les experts pensent à des scans de routine, donc rien d’alarmant. Mais ils ont tort car le ver est programmé pour rester relativement dormant jusqu’au 19 juillet inclus. C’est donc une énorme bombe à retardement.

Car quelque part dans le monde, un ou plusieurs programmeurs anonymes ont en réalité créé quelque chose de dangereusement nouveau… Ils ont pris la vulnérabilité découverte par Riley et codé le premier véritable ver informatique à propagation automatique. Pas besoin d’envoyer des emails, pas besoin d’interaction humaine. Le ver scanne Internet, trouve les serveurs IIS vulnérables, les infecte, et utilise ces nouveaux zombies pour scanner encore plus vite. Le code, écrit en assembleur Win32 Intel, ne fait que quelques milliers d’octets… C’est une œuvre d’art malveillante en miniature.

Le ver exploite astucieusement l’absence d’ASLR (Address Space Layout Randomisation) et de DEP (Data Execution Prevention) dans Windows 2001. Les DLLs se chargent toujours aux mêmes adresses sur tous les systèmes. Comme ça, le ver sait que l’adresse mémoire 0x7801CBD3 pointera vers MSVCRT.DLL, qui est la bibliothèque Microsoft Visual C Runtime. À cette adresse précise, il trouve l’instruction machine CALL [EBX], et ce registre EBX contient une adresse sur la pile modifiée par le fameux buffer overflow. Du coup le CPU exécute directement le code du ver. C’est du génie maléfique !

Dans les bureaux d’eEye Digital Security en Californie, Marc Maiffret et Ryan Permeh travaillent tard ce jeudi 19 juillet. Maiffret, qui n’a que 20 ans, est déjà une légende dans le milieu. Ancien hacker sous le pseudo “Chameleon”, il a fondé eEye à 17 ans après une visite du FBI chez lui. Ironie du sort, quelques semaines après cette visite, il s’associait avec Firas Bushnaq pour créer la société. Ryan Permeh, son collègue et ami, est quant à lui surnommé “Overflow Ninja” pour son expertise en reverse engineering.

Marc Maiffret (à gauche), Ryan Permeh (au milieu) et Riley Hassel (à droite) - source

Vers 20 heures, leurs systèmes de détection s’affolent. Un truc bizarre se passe sur Internet. Des milliers de serveurs IIS tentent de se connecter à d’autres serveurs avec des requêtes étranges contenant “/default.ida?” suivi d’une longue chaîne de caractères de ‘N’ et de shellcode encodé. Maiffret et Permeh commencent alors à analyser le trafic. Et ce qu’ils découvrent les glace.

C’est un ver qui exploite la vulnérabilité MS01-033 découverte par leur collègue Riley Hassell. Mais contrairement aux virus classiques, ce ver n’a pas besoin d’intervention humaine. Il scanne les adresses IP de manière pseudo-aléatoire avec une seed fixe, cherchant le port 80 (HTTP). Quand il trouve un serveur IIS non patché, il envoie sa charge utile et prend le contrôle du serveur.

Une fois installé, le ver fait plusieurs choses. D’abord, sur les systèmes en anglais, il défigure le site web en affichant un message : “HELLO! Welcome to http://www.worm.com ! Hacked By Chinese!” Un message provocateur qui fait immédiatement penser à une attaque chinoise.

En effet, le contexte géopolitique est tendu car trois mois plus tôt, le 1er avril 2001, un avion espion américain EP-3 et un chasseur chinois J-8 sont entrés en collision au-dessus de la mer de Chine méridionale. Le pilote chinois Wang Wei est mort, et l’équipage américain a été détenu pendant 11 jours. S’en est suivie une cyber-guerre entre hackers patriotes des deux pays. Ainsi, la Honker Union chinoise et des groupes américains se sont affrontés, défaçant des centaines de sites.

Maiffret et Permeh réalisent l’ampleur de la catastrophe. Ils ont besoin d’un nom de code pour l’incident. Sur le bureau, une canette de Mountain Dew Code Red, la nouvelle boisson caféinée rouge cerise lancée quelques semaines plus tôt. “Code Red”, dit-il. Le nom est parfait car c’est une alerte rouge pour Internet.

Mais ce n’est que la partie visible de l’iceberg. Le ver installe aussi une backdoor, désactive le service d’indexation d’IIS pour éviter les plantages, et surtout, il contient une bombe logique car à partir du 20 juillet, et jusqu’au 28 de chaque mois, tous les serveurs infectés lanceront une attaque DDoS coordonnée contre l’IP 198.137.240.91. C’est celle de www.whitehouse.gov . Des centaines de milliers de serveurs zombies s’apprêtent à bombarder simultanément le site du président américain. C’est de la cyberguerre, ni plus ni moins, cependant, le ver a une faiblesse : il cible une IP hardcodée, et pas le nom de domaine.

Les deux chercheurs passent la nuit à analyser le ver. Le code est relativement simple mais très efficace. Avec ses 100 threads simultanés pour scanner Internet, chaque serveur infecté devient un nouveau point de départ pour l’infection. C’est de la croissance exponentielle pure. Le ver cherche d’abord kernel32.dll en mémoire, scannant la plage 77E00000h–78000000h par incréments de 64K à la recherche de la signature ‘MZ’. S’il ne trouve rien, il essaie à partir de 0BFF00000h, supposant qu’il tourne peut-être sur Windows 9x plutôt que NT.

Le plus brillant dans le code, c’est la méthode de génération des adresses IP. Grâce à un générateur pseudo-aléatoire avec une seed fixe basée sur la date, tous les vers scannent les mêmes adresses dans le même ordre, évitant ainsi de saturer inutilement les mêmes cibles. C’est de l’optimisation de haute volée. Si SP1 ou SP2 est installé sur la machine, ou si elle tourne sous Windows NT 4.0, le ver ne peut pas se propager et le service WWW Publishing d’IIS plante simplement.

Au matin du 19 juillet, eEye publie une alerte d’urgence. Mais c’est déjà trop tard. Le ver se propage à une vitesse folle. À midi, plus de 100 000 serveurs sont infectés. David Moore et Colleen Shannon du CAIDA (Cooperative Association for Internet Data Analysis) à l’UC San Diego observent des chiffres hallucinants : en 14 heures, Code Red infecte 359 000 serveurs. Le pic d’infection atteint plus de 2 000 nouveaux hôtes par minute. Les réseaux commencent à saturer sous le trafic de scan.

Les CERT (Computer Emergency Response Team) publient l’Advisory CA-2001-19 à 14h00 et Microsoft republie en urgence son patch avec des avertissements en gros caractères. Les FAI commencent à bloquer le trafic suspect mais le ver est déjà partout. Le FBI et le NIPC (National Infrastructure Protection Center) lancent une enquête.

La communauté de la sécurité informatique est en ébullition. Sur Bugtraq, SecurityFocus, et les mailing lists, les experts échangent frénétiquement des informations. Comment stopper le ver ? Comment protéger les serveurs ? Comment éviter l’attaque DDoS contre la Maison Blanche prévue pour le lendemain ?

Car c’est ça le vrai danger. Si des centaines de milliers de serveurs attaquent simultanément whitehouse.gov, non seulement le site tombera, mais les dégâts collatéraux seront énormes. Les routeurs Internet pourraient saturer, les DNS pourraient flancher. C’est potentiellement Internet tout entier qui pourrait être affecté. 43% des serveurs infectés sont aux États-Unis, 11% en Corée, 5% en Chine, 4% à Taiwan.

La Maison Blanche prend la menace au sérieux. Une réunion de crise est organisée avec Akamai Technologies, qui héberge le site. La décision est radicale : Il faut changer l’adresse IP de whitehouse.gov. Si le ver attaque l’ancienne IP hardcodée, il ne touchera qu’une adresse vide.

Le 19 juillet au soir, Akamai procède au changement d’IP en urgence. L’opération est délicate : il faut propager la nouvelle adresse dans tous les serveurs DNS du monde. Normalement, ça prend 24 à 48 heures. Ils n’ont que quelques heures….

Les dégâts sont considérables car des milliers de sites web affichent “Hacked by Chinese!” au lieu de leur contenu normal. Des entreprises perdent des millions en revenus. Les équipes IT travaillent jour et nuit pour patcher et nettoyer les serveurs. Le coût total sera estimé à 2,6 milliards de dollars par Computer Economics : 1,1 milliard en coûts de nettoyage et 1,5 milliard en perte de productivité.

Mais le pire est évité. Le 20 juillet à 20h00, quand les serveurs infectés lancent leur attaque DDoS, ils bombardent l’ancienne IP de whitehouse.gov. Et rien. Ouf, la Maison Blanche a réussi son pari. Le stratagème a fonctionné parfaitement.

De plus, le ver Code Red original a une particularité : il ne survit pas au redémarrage. Il persiste uniquement en mémoire vive. Redémarrez le serveur, et il disparaît. Mais si vous ne patchez pas, il sera réinfecté en quelques minutes par un autre serveur zombie. C’est Sisyphe version numérique. Le ver est d’ailleurs programmé pour arrêter de scanner après minuit UTC et reprendre son activité le 1er et le 19 de chaque mois.

Et le 31 juillet, sans surprise, le ver se réactive comme prévu provoquant une nouvelle vague d’infections, et un nouveau chaos. Cette fois, les admins sont mieux préparés, mais les dégâts restent importants. Le CERT publie l’Advisory CA-2001-23 “Continued Threat of the Code Red Worm”.

Et puis, le 4 août 2001, c’est l’escalade. Une nouvelle variante apparaît : Code Red II. Malgré son nom, c’est un ver complètement différent, écrit par d’autres auteurs qui ont juste inclus la chaîne “CodeRedII” dans leur code. Au lieu de défigurer les sites, il installe une backdoor permanente qui survit aux redémarrages.

Code Red II modifie le système pour permettre l’exécution de commandes à distance. Il copie cmd.exe (l’invite de commandes Windows) dans les répertoires web comme “scripts” et “msadc”. N’importe qui peut maintenant exécuter des commandes sur les serveurs infectés via une simple URL. C’est la porte ouverte au pillage de données. Le ver installe aussi un rootkit appelé “Virtual Root” et n’a pas de fonction DDoS mais cherche à infecter les systèmes proches géographiquement.

Code Red II a été programmé pour se propager plus agressivement en Chine. Si le système infecté est configuré en chinois, le ver lance alors 600 threads de scan au lieu de 300. C’est drôle, vu le message “Hacked by Chinese!” de la première version. Le ver s’arrête de fonctionner après le 1er octobre 2001.

Bien sûr la communauté chinoise proteste contre l’amalgame créé par le message et le gouvernement chinois dément toute implication. Les experts en sécurité sont également sceptiques car le message semble être une diversion. eEye pense que le ver vient de Makati City aux Philippines, le même endroit d’où venait le ver VBS LoveLetter .

En réalité, l’origine de Code Red reste encore aujourd’hui mystérieuse car contrairement à ILOVEYOU (de Onel de Guzman aux Philippines) ou Solar Sunrise (deux ados californiens), aucun auteur n’a jamais été identifié. Les théories abondent bien sûr. Certains pensent que ce seraient des hackers chinois de la Honker Union, d’autres un groupe criminel russe, ou un script kiddie américain provocateur, ou encore un false flag d’une agence de renseignement… Le mystère reste entier…

Ce qui est sûr, c’est que Code Red a fait découvrir au monde la puissance des vers à propagation automatique. Plus besoin de social engineering, plus besoin que des utilisateurs cliquent sur des pièces jointes. Un ver se propage maintenant tout seul, exploitant la négligence des admins.

Grâce à sa découverte, Marc Maiffret devient une célébrité du jour au lendemain. Ce jeune de 20 ans qui a baptisé Code Red est invité sur CNN, interrogé par le FBI, consulté par le Congrès américain…etc. Ryan Permeh, plus discret mais tout aussi brillant, continue à l’époque son travail de reverse engineering et dans les mois qui suivent, lui et Maiffret découvriront des dizaines d’autres vulnérabilités critiques dans les produits Microsoft. De son côté, Permeh co-fondera plus tard Cylance, vendue à BlackBerry pour 1,4 milliard de dollars en 2020, puis rejoindra SYN Ventures comme partenaire.

Riley Hassell, le découvreur de la vulnérabilité originale, dira bien plus tard dans une interview : “J’ai publié la vulnérabilité de manière responsable. Microsoft a publié un patch. Ce n’est pas ma faute si personne ne l’a installé.” Il travaillera ensuite pour @stake, Immunity, et d’autres grandes boîtes de sécurité.

L’impact de Code Red sur l’industrie sera d’ailleurs profond et durable débutant en janvier 2002, par Bill Gates qui lancera l’initiative “Trustworthy Computing” afin que la sécurité soit au cœur du développement. Le projet Windows Server 2003 sera même arrêté pendant deux mois pour former tous les développeurs à la sécurité. C’est un tournant historique pour Microsoft.

Microsoft accélère aussi son programme de patchs mensuels “Patch Tuesday”, lancé en octobre 2003 et les entreprises commencent à prendre au sérieux la gestion des vulnérabilités. Les outils de scan automatique et de déploiement de patchs deviennent la norme et Windows Server Update Services (WSUS) est développé.

Code Red inspire aussi une nouvelle génération de malwares tel que, en janvier 2003, SQL Slammer (seulement 376 octets !) qui infectera 75 000 serveurs en 10 minutes, doublant de taille toutes les 8,5 secondes. Un record jamais battu. Puis en août 2003, Blaster exploitera une faille RPC Windows. Il y a eu également Welchia/Nachi qui tentera de nettoyer Blaster… un ver “bénéfique” mais qui en réalité causera autant de problèmes. Sans oublier Conficker en 2009 qui infectera des millions de machines.

Le Mountain Dew Code Red, la boisson qui a donné son nom au ver, profite également de la publicité gratuite. Lancé quelques semaines avant l’incident, le soda devient rapidement culte dans la communauté tech et les hackers et les admins système adoptent la boisson comme leur carburant officiel.

En 2002, David Moore, Colleen Shannon et leurs collègues du CAIDA publieront une analyse détaillée dans IEEE Security & Privacy et leurs conclusions sont glaçantes : si Code Red avait été mieux conçu, il aurait pu infecter la quasi-totalité des serveurs vulnérables en moins d’une heure. L’article devient une référence, mais aussi un manuel involontaire pour les futurs créateurs de vers. C’est le dilemme éternel de la recherche en sécurité qui est de publier pour éduquer et protéger, au risque d’armer les attaquants.

Bref, la prochaine fois que Windows vous harcèle pour installer des mises à jour, pensez à Code Red et cliquez sur “Installer maintenant” !!!

Sources : Wikipedia - Code Red , CAIDA Analysis of Code-Red , ACM SIGCOMM - Code-Red case study , Microsoft Security Bulletin MS01-033 , CERT Advisory CA-2001-19 , GIAC - The Code Red Worm , Scientific American - Code Red , GAO Report on Code Red , Microsoft Trustworthy Computing , Houston Chronicle - Code Red costs

Spotify à 12 balles par mois, YouTube Music et Apple Music qui vous taxe 11 euros… Franchement, à ce rythme, écouter de la musique va bientôt nécessiter un crédit à la conso chez Cofidrisse. Heureusement, un développeur nommé Valeri Gokadze a décidé de renverser la table avec Musify , une app de streaming musical complètement gratuite et open source qui fait tout pareil, mais sans vous demander un rond.

Car oui, pourquoi payer pour accéder à de la musique qui est déjà disponible publiquement ? L’app utilise les API de Piped (un frontend alternatif pour YouTube respectueux de la vie privée) pour streamer directement les morceaux depuis YouTube Music. Du coup, vous avez accès à des millions de titres sans pub, sans compte, sans abonnement et sans que Google ne vous traque comme un lapin dans la forêt.

Développée en Flutter, cette petite merveille tourne sur Android et propose des fonctionnalités qui feraient pâlir les géants du secteur. Un mode hors ligne pour écouter votre musique sans connexion, la possibilité de créer des playlists personnalisées, mais également les paroles synchronisées pour vos karaokés solo, et du SponsorBlock pour zapper automatiquement les segments sponsors dans les podcasts. Ah et cerise sur le gâteau, l’interface Material Design s’adapte dynamiquement aux couleurs de votre fond d’écran si vous êtes sur Android 12 ou plus.

Les dev ont porté beaucoup d’attention aux détails d’ailleurs… L’app propose 21 langues différentes, un thème noir pur pour les écrans OLED, et même un système d’import/export de vos données pour ne jamais perdre vos playlists. Les audiophiles apprécieront également l’optimisation sonore intégrée, tandis que les paranos de la vie privée seront ravis d’apprendre qu’il n’y a absolument aucun tracking. Pas besoin des services Google, pas de collecte de données, nada.

Bref, Musify offre une expérience fluide et agréable pour streamer de la musique, rendant la découverte de nouveaux morceaux simple et la lecture sans effort. L’app fonctionne même quand votre téléphone est verrouillé avec les contrôles média sur l’écran de verrouillage, même si le changement de piste peut parfois être un peu lent.

Pour installer Musify, vous avez maintenant plusieurs options. La plus simple reste F-Droid , sinon, vous pouvez récupérer les dernières versions directement sur GitHub ou sur le site officiel du projet . Vous téléchargez l’APK, autorisez l’installation depuis des sources inconnues, et c’est parti mon kiki !

L’app n’est disponible que sur Android pour le moment (désolé les utilisateurs d’iPhone), et comme elle dépend de YouTube pour le contenu, certains morceaux peuvent parfois être indisponibles selon votre région, mais franchement, pour une app gratuite, sans pub et open source, c’est difficile de faire la fine bouche.

Puis le code est complètement ouvert sous licence GPL v3 donc vous pouvez le forker, le modifier, l’améliorer, et pourquoi pas créer votre propre version.

Bref, si vous en avez marre de jongler entre vos abonnements streaming ou si vous cherchez simplement une alternative éthique et gratuite, Musify mérite clairement le détour.

Si vous avez déjà passé 20 minutes à déboguer un cron job qui ne se lance pas parce que vous aviez mis un espace au mauvais endroit dans la syntaxe * * * * *, vous allez adorer CronMaster .

Car le problème avec cron, c’est pas le concept en lui-même. L’idée de planifier des tâches automatiques reste géniale depuis les années 70. Non, le souci c’est cette syntaxe ésotérique qui fait que même les devs expérimentés doivent vérifier trois fois leur ligne avant de valider. Un petit 0 2 * * 1-5 et vous vous demandez si ça va se lancer tous les lundis ou tous les jours de la semaine à 2h du matin.

CronMaster arrive donc avec une proposition simple qui est de conserver la puissance de cron tout en rendant son utilisation intuitive. L’interface web affiche vos jobs sous forme de cartes visuelles, avec le nom de la tâche, sa fréquence d’exécution en langage humain et la possibilité de les activer/désactiver d’un clic. Plus besoin de commenter/décommenter des lignes dans le crontab.

CronMaster ne réinvente pas cron. Il se pose juste comme une couche visuelle par-dessus le système existant. Vos jobs continuent de tourner via le crontab système, mais vous les gérez depuis une interface moderne avec du dark mode, des stats système en temps réel (CPU, RAM, uptime) et même la possibilité de gérer des scripts bash directement depuis l’interface.

L’installation passe par Docker, ce qui simplifie énormément le déploiement. Un simple docker-compose.yml avec quelques variables d’environnement et vous avez votre interface accessible sur le port 40123. Le projet supporte aussi bien AMD64 qu’ARM64, donc ça tourne aussi bien sur votre serveur que sur un Raspberry Pi.

CronMaster n’est pas le seul dans sur créneau. Y’a Cronicle qui propose par exemple une solution multi-serveurs avec des graphiques de performance en temps réel et une gestion des dépendances entre tâches ou encore Crontab-UI qui mise plutôt sur la simplicité avec import/export de configurations et système de backup automatique.

Mais CronMaster a ses propres atouts. Son système d’informations système intégré permet de voir en un coup d’œil l’état de votre serveur pendant que vos jobs tournent. Et le support des variables d’environnement HOST_PROJECT_DIR facilite l’intégration dans des workflows existants. Sans oublier la possibilité de gérer plusieurs utilisateurs crontab depuis la même interface est pratique pour les équipes.

Un détail technique important… CronMaster nécessite les droits root dans le conteneur Docker pour accéder au crontab système. C’est un choix assumé du dev pour garantir une intégration transparente avec le système existant. Donc si vous préférez une approche plus isolée, Zeit propose une alternative desktop en C++ qui tournera sur votre ordi.

Le format cron reste toujours le même : minute (0-59), heure (0-23), jour du mois (1-31), mois (1-12) et jour de la semaine (0-7), mais avec CronMaster, vous avez des sélecteurs visuels qui génèrent automatiquement la bonne syntaxe comme ça, plus besoin de se rappeler que */5 signifie “toutes les 5 minutes” ou que 0,30 veut dire “à la minute 0 et 30”.

L’interface affiche aussi les logs d’exécution de chaque job, ce qui facilite grandement le debug. Au lieu de fouiller dans /var/log/syslog ou de configurer des redirections complexes avec >> /var/log/monjob.log 2>&1, tout est accessible depuis l’interface web.

Pour les développeurs qui bossent sur plusieurs projets, la fonctionnalité de commentaires sur chaque job est également super pratique. Vous pouvez documenter pourquoi tel script doit tourner à 3h du matin ou rappeler les dépendances d’un job particulier. Ces métadonnées restent attachées au job dans l’interface, contrairement aux commentaires dans le crontab qui peuvent facilement se perdre.

Voilà, donc si vous gérez régulièrement des cron jobs et que vous en avez marre de cette syntaxe cryptique, vous adorerez CronMaster !! C’est à découvrir ici !

On a déjà tous passé 10 minutes à chercher dans notre historique bash LA commande SSH avec tous les bons paramètres pour nous connecter à ce foutu serveur obscur qu’on a configuré il y a 3 mois… Port custom, clé spécifique, nom d’utilisateur bizarre… Un vrai cauchemar. Et du coup, je me suis souvenu d’un outil dont on m’avait parlé y’a pas longtemps : GGH .

Écrit en Go par Binyamin Yawitz, ce petit outil CLI garde en mémoire toutes vos sessions SSH et vous permet de les retrouver instantanément. Plus besoin de fouiller dans votre historique comme un archéologue ou de maintenir un fichier notes.txt avec toutes vos connexions.

Le principe est con comme la lune… à chaque fois que vous utilisez GGH pour vous connecter, il enregistre tout (hôte, utilisateur, port, clé). Après, vous tapez juste ggh et vous avez une liste interactive de toutes vos sessions précédentes. Vous pouvez même filtrer en tapant quelques lettres, comme ggh - stage pour retrouver tous vos serveurs de staging.

Pour l’installer, c’est rapide. Sur Unix/Linux/Mac, une petite ligne de curl :

curl https://raw.githubusercontent.com/byawitz/ggh/master/install/unix.sh | sh

Sur Windows avec PowerShell :

powershell -c "irm https://raw.githubusercontent.com/byawitz/ggh/master/install/windows.ps1 | iex"

Ou si vous avez Go installé :

go install github.com/byawitz/ggh@latest

Une fois installé, utilisez-le exactement comme SSH. Par exemple :

ggh [email protected]
ggh [email protected] -p2222

La magie opère quand vous tapez simplement ggh sans paramètres. Vous obtenez une liste interactive de toutes vos connexions précédentes, triées par fréquence d’utilisation. Flèche haut/bas pour naviguer, Entrée pour se connecter. Simple et efficace.

Ce qui est malin, c’est que GGH lit aussi votre fichier ~/.ssh/config. Du coup, si vous tapez ggh -, vous avez accès à tous vos hôtes configurés. Et vous pouvez filtrer directement, genre ggh - prod pour voir uniquement vos serveurs de production.

Notez que GGH ne remplace pas SSH. C’est juste un wrapper intelligent qui facilite la vie. SSH doit encore être installé sur votre système pour que GGH fonctionne. L’outil se contente juste de mémoriser vos connexions et de relancer les bonnes commandes SSH.

Le projet est open source sous licence Apache 2.0, le code est propre, écrit à 80% en Go, et l’outil reste super léger. Pas de dépendances folles, pas de configuration complexe. Ça fait le job, point.

Quelques commandes utiles à connaître :

• ggh --config pour voir où sont stockées vos configs
• ggh --history pour accéder directement à l’historique
• ggh tout seul pour la liste interactive

Voilà, si comme moi vous en avez marre de chercher vos commandes SSH dans votre historique ou de maintenir des alias à n’en plus finir, donnez une chance à GGH , vous m’en direz des nouvelles.

Vous savez ce qui est frustrant quand, comme moi, on fait plein de trucs avec Claude Code ? C’est de devoir rester scotché à son ordi pour suivre l’avancement d’une build ou d’une tâche un peu longue. Heureusement des ingénieurs de San Francisco ont ressenti exactement la même frustration, et au lieu de râler dans leur coin comme des cons, ils ont créé Happy .

L’idée leur est venue dans au café où ils passaient leur temps à vérifier constamment l’avancement de leurs projets sur Claude Code. Comme ils l’expliquent sur leur site , ils checkaient leurs laptops toutes les 5 minutes pendant les pauses déjeuner et ça commençait à les relouter. Du coup, ils ont développé une solution mobile qui permet de garder un œil sur Claude Code depuis n’importe où, avec des notifications push et tout le tralala.

Happy fonctionne de la manière suivante. Sur votre machine, vous remplacez simplement la commande claude par happy dans votre terminal et l’application se charge ensuite de créer un pont chiffré de bout en bout entre votre ordinateur et votre téléphone. Comme ça, quand vous voulez contrôler Claude depuis votre mobile, le système bascule automatiquement en mode distant. Simple et efficace.

L’installation de Happy est simple. Vous téléchargez l’app iOS ou Android, puis vous installez le CLI sur votre ordi avec

npm install -g happy-coder

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/happy-mobile-claude-code/happy-mobile-claude-code-1.mp4">lien vers la vidéo</a>.

À partir de là, y’a plus qu’à utiliser happy au lieu de claude dans votre terminal habituel. L’interface mobile reprend alors toutes les fonctionnalités de Claude Code, avec en prime la possibilité de recevoir des notifications push quand une tâche importante se termine ou qu’une erreur survient. C’est vraiment top ! Pour tout vous dire, j’avais ce besoin et je m’étais codé une interface web accessible depuis l’extérieur de chez moi (via un VPN), avec un terminal ttyd dedans pour y lancer Claude Code mais c’était un peu archaïque et pas très pratique.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/happy-mobile-claude-code/happy-mobile-claude-code-1.webm">lien vers la vidéo</a>.

Niveau sécurité, Happy dispose d’un système de chiffrement de bout en bout comme ça, vos sessions Claude restent privées et sécurisées, même quand elles transitent par les serveurs de Happy pour la synchro. Les développeurs ont clairement pensé aux professionnels qui travaillent sur des projets sensibles et qui ne peuvent pas se permettre de faire fuiter du code propriétaire.

L’aspect open source du projet mérite également d’être souligné car tout le code est disponible sur GitHub, et est divisé en trois composants principaux : happy-cli pour l’interface en ligne de commande, happy-server pour le backend de synchronisation chiffrée, et happy-coder pour le client mobile.

Faut que je prenne le temps d’aller jeter un œil au code aussi pour voir comment ils encapsulent Claude Code dans leur CLI Happy et comment il lui injectent des commandes, parce que ça va me permettre de mettre au point un contrôleur tiers qui viendra faire la même chose mais pour des automatisations complètes de Claude Code (voire, pourquoi pas, pilotable par une autre IA… Du genre GPT-5.0 qui commande Claude Code…). Oui je sais, j’ai des délires chelous.

Au final, Happy résout un problème concret qu’on est nombreux à avoir. Donc pour tous ceux qui passent leur journée à coder avec Claude, pouvoir suivre et contrôler leurs sessions depuis leur téléphone change clairement les chose. Plus besoin de rester collé à son bureau pour superviser un déploiement, le dev d’un bout de code ou une suite de tests.

Source

Vous vous souvenez de l’époque où on pouvait consulter Twitter sans avoir de compte ? Ah, c’était le bon temps mais depuis qu’ Elon Musk a instauré son login wall “temporaire” en juillet 2023 , impossible de jeter un œil à un profil ou un thread sans passer par la case inscription.

Alors oui je sais, les réseaux sociaux avec Twitter en tête (pardon X), c’est devenu de la merde. L’effet de foule stupide & agressive y est devenu légion et c’est pourquoi j’ai arrêté d’y aller et de partager mes articles sur ces plateformes via mon compte @Korben . Mais faut reconnaître que sur certains comptes bien spécifiques qui se comptent sur les doigts d’une main, c’est quand même sympa pour la veille. Petite parenthèse, c’est d’ailleurs super dommage que ces gens qui font ce travail de veille la filent gratos à Elon Musk plutôt que de se faire un vrai site web, une newsletter ou un flux RSS. Bref, quelque chose qui leur appartient vraiment.

Heureusement, des développeurs malins ont créé des solutions pour contourner ce mur de connexion forcée. TwitterViewer en fait partie et c’est plutôt efficace. Le principe est simple puisque c’est un proxy qui se connecte à votre place et vous retransmet le contenu public des profils X. Vous entrez un nom d’utilisateur, et hop, vous avez accès à ses tweets, ses médias, et aux infos du profil, le tout de manière 100% anonyme.

Ça reste plus rapide que de créer un compte jetable à chaque fois qu’on veut vérifier un truc et le service se présente comme respectueux de la vie privée. Votre IP reste cachée, vos données de navigation ne sont pas collectées, et vous n’alimentez pas les algorithmes de X avec votre comportement.

Un compte bien vide… ^^

Mais TwitterViewer n’est pas seul sur ce créneau. Je pense par exemple à Nitter , une alternative open source historique déclarée morte en février 2024 qui a finalement ressuscité miraculeusement le 6 février dernier. Cette solution reste la plus complète si vous cherchez une interface épurée sans JavaScript ni trackers.

Il y a aussi Tweet Binder qui permet de suivre des hashtags et mots-clés sans compte, ce qui est pratique pour surveiller les tendances. Twillot propose également des extensions Chrome et des apps mobiles pour iOS et Android. Et si vous êtes vraiment désespéré, Google reste votre ami : tapez “site:x.com” suivi du nom d’utilisateur qui vous intéresse et vous aurez accès aux tweets indexés.

Musk avait quand même vendu son login wall comme une mesure d’urgence contre les scrapers de données mais au final, ces scrapers ont trouvé d’autres moyens d’accéder aux données, tandis que les utilisateurs lambda, eux, sont toujours bloqués. Même les développeurs tiers ont été éjectés avec l’augmentation délirante des prix de l’API, et maintenant on se retrouve avec un écosystème parallèle d’outils pour simplement consulter du contenu public.

Je trouve que TwitterViewer et ses alternatives représentent une sorte de résistance face à ce renfermement progressif des plateformes sociales. Et surtout, pourquoi est ce qu’on devrait se créer un compte sur ce site de nazⁱe juste pour lire un fois ou deux des tweets publics ?

Y’a quelques mois, je me suis amusé à reprendre le projet DeepSite d’Enzostvs et à le transformer complètement pour fonctionner en 100% local. J’ai baptisé ça LocalSite , et ça permet en gros de générer des pages web ou des éléments HTML / CSS / JS à l’aide d’une IA mais en local.

Ça s’appuie donc sur Ollama pour faire tourner les modèles d’IA directement sur votre ordinateur, comme ça, pas de connexion cloud, pas d’abonnement à payer, pas de données qui partent on ne sait où en Chine ou ailleurs. Vous tapez une description de ce que vous voulez, vous sélectionnez un modèle Ollama, et hop, votre site web se génère sous vos yeux.

L’installation est assez simple. Il vous faut d’abord Ollama installé sur votre machine et ensuite, vous récupérez un modèle, par exemple deepseek-r1:7b avec la commande

ollama pull deepseek-r1:7b.

Et une fois Ollama lancé avec

ollama serve

il ne reste plus qu’à installer LocalSite avec npm :

git clone https://github.com/Korben00/LocalSite.git
npm instal
npm run dev

Ensuite, direction localhost:3001 et c’est parti.

Pour l’interface, vous avez donc un éditeur Monaco intégré (le même que dans VS Code), une preview en temps réel qui s’adapte aux différentes tailles d’écran (desktop, tablette, mobile), et la possibilité de basculer entre génération et édition manuelle du code. C’est super pratique pour peaufiner le résultat une fois que l’IA a fait le gros du travail.

Pour ceux qui se demandent quels modèles utiliser, d’après les benchmarks 2025 , CodeLlama 34B reste une référence pour la génération de code HTML/CSS/JavaScript. Mais si votre machine est plus modeste, les versions 7B ou 13B font déjà très bien le job. Qwen2.5-Coder est aussi une excellente alternative, surtout si vous voulez intégrer du code plus complexe dans vos pages. Vous pouvez aussi tenter avec des modèles “Thinking” comme GPT OSS si ça vous chauffe…

Bref, là où DeepSite original nécessite obligatoirement une connexion à Hugging Face et utilise les serveurs API de DeepSeek (donc ça coûte aussi des sous), mon petit LocalSite fait tout en local. Vos données restent chez vous, vous pouvez bosser offline, et surtout, pas de limite d’utilisation. Vous pouvez donc générer autant de sites que vous voulez, tester différents modèles, expérimenter sans compter comme dirait Macron.

L’aspect vie privée n’est pas négligeable non plus car ça permet de prototyper rapidement, et avoir une solution 100% locale évite pas mal de questions juridiques sur la confidentialité des données.

Techniquement, l’architecture repose sur Node.js côté serveur et communique avec Ollama via son API locale. Le code généré est du pur HTML/CSS/JavaScript vanilla, donc compatible partout. Et vous pouvez directement copier-coller le résultat ou télécharger le projet HTML complet (j’ai ajouté un import / export de projets zip). Pas de framework lourd, pas de dépendances obscures, juste du code web standard.

Pour les développeurs qui veulent pousser plus loin, le code source est bien sûr disponible et modifiable. Vous pouvez ajouter vos propres templates, personnaliser les prompts système, ou même intégrer d’autres modèles compatibles avec Ollama.

Il vous faudra quand même un minimum de RAM pour faire tourner les modèles (comptez 8 Go pour les modèles 7B, 16 Go pour les 13B, et 32 Go pour les gros modèles 33B+) mais vu les capacités de génération et l’indépendance totale vis-à-vis du cloud, ça vaut le coup surtout que les modèles dispo dans Ollama progressent rapidement et deviennent de plus en plus optimisés. Je pense par exemple à GPT-OSS.

Bref, j’ai pris une idée cool (DeepSite), et je l’ai réadapté à l’aide de Claude Code et de mes maigres connaissances, pour la rendre accessible et respectueuse de la vie privée et du coup, je trouve ça encore plus cool ^^. Par contre, je suis un garçon assez occupé et je ne suis pas mainteneur de projet open source donc si vous voulez des modifs dedans ou si vous voyez des bugs, faudra vous y coller vous-même ^^.

Si ça vous dit de tester, c’est par ici.

Je pense qu’on n’est pas encore vraiment prêt pour ces conneries… De quelles conneries je parle ? Et bien par exemple d’un ransomware qui réfléchit, qui s’adapte, et qui génère même ses propres attaques en temps réel ! Oui, Terminator mais sans muscles, et ce n’est plus de la science-fiction, c’est maintenant une réalité.

ESET Research vient en effet de découvrir PromptLock , le tout premier ransomware alimenté par l’intelligence artificielle et ce qui le rend vraiment unique, c’est qu’il ne suit pas de script prédéfini. Non, non, au lieu de ça, il utilise le modèle gpt-oss-20b d’OpenAI, installé localement sur la machine infectée via l’API Ollama. Du coup, ça permet au ransomware de génèrer ses propres scripts Lua malveillants à la volée, en fonction de ce qu’il trouve sur votre système. Chaque attaque devient ainsi potentiellement unique, ce qui rend la détection par signatures quasi impossible.

La beauté diabolique du truc, c’est que tout fonctionne en local. Donc pas besoin de connexion internet constante, pas de communications suspectes vers des serveurs de commande et contrôle. Le modèle d’IA tourne directement sur votre machine. Cette approche permet ainsi au ransomware d’éviter les détections heuristiques traditionnelles et le tracking d’API.

Les chercheurs d’ESET ont trouvé les artefacts de PromptLock sur VirusTotal le 25 août dernier. Ce ransomware est écrit en Golang et existe pour le moment en versions Windows et Linux et d’après l’analyse du trafic réseau, il envoie des requêtes POST vers un endpoint Ollama local (172.42.0.253:8443). L’adresse Bitcoin présente dans les prompts découverts appartiendrait à Satoshi Nakamoto lui-même. L’enfoiré, je savais qu’il était toujours dans le coin !!! Ouais, non, c’est surtout un gros clin d’œil des développeurs de cette saloperie.

Ce qui inquiète réellement les experts, c’est la simplicité avec laquelle ce ransomware peut être déployé. Plus besoin d’être un expert du mal (et du code) pour lancer une attaque sophistiquée.

Le ransomware utilise l’algorithme de chiffrement SPECK 128-bit et peut potentiellement exfiltrer vos données, les chiffrer, ou même les détruire. Heureusement, cette dernière fonctionnalité ne semble pas encore implémentée. Les scripts Lua générés sont compatibles cross-platform et fonctionnent sur Windows, Linux et macOS. Bref, une vraie plaie universelle.

Pour l’instant, PromptLock semble donc être plutôt un proof of concept plutôt qu’une menace active mais si un simple PoC peut déjà faire ça, imaginez ce que des cybercriminels motivés pourraient développer avec les mêmes techniques.

On s’attend tous à voir dans les années à venir de plus en plus de malwares autonomes capables d’apprendre et de s’adapter en temps réel. Cela veut dire que les défenses devront elles aussi intégrer l’IA pour suivre le rythme. C’est une nouvelle course aux armements technologiques qui s’annonce, avec évidemment nos données personnelles et les données des entreprises comme champ de bataille.

Donc comme d’hab, la meilleure défense c’est la prudence. Ne téléchargez que des fichiers de sources fiables maintenez vos systèmes à jour, et faites des backups 3-2-1-1-0 .

Bon courage les amis !

Source

A chaque fois que j’ouvre la boite de Tic Tac que j’ai dans ma voiture, au lieu de prendre un bonbon en tout délicatesse, je m’en verse 3 dans la paume, puis 5, puis au final je suis à 2 doigts de tous les bouffer. Heureusement, un maker génial vient de résoudre ce problème existentiel avec l’arme ultime : un pistolet à Tic Tac imprimé en 3D.

L’ingénieux système créé par “It’s On My Mind” utilise un mécanisme à ressort pour transformer vos petits bonbons en projectiles à la menthe qui atterrissent directement dans votre bouche. Fini la poignée de Tic Tac, maintenant place à la précision balistique.

Vous retirez l’étiquette de votre boîte de Tic Tac, vous enlevez le couvercle et ce distributeur s’interface parfaitement avec la forme du couvercle d’origine. Ensuite, vous clipsez le tout et hop ! Votre boîte de bonbons devient une arme de destruction massive contre la faim.

Mais attention, cette petite merveille peut tirer plus fort que prévu. Les créateurs vous auront prévenu : ne visez jamais un visage, le vôtre ou celui d’autrui. Les bonbons, c’est pour la bouche, pas pour les yeux.

La communauté maker sur Thingiverse a même développé plusieurs variantes de ces pistolets à Tic Tac, tous conçus avec la sécurité en tête pour éviter les étouffements. Certains modèles utilisent même des élastiques pour propulser les bonbons avec un mécanisme de glissière plutôt réaliste.

L’impression nécessite quelques précautions également, notamment avec les supports qui doivent être retirés délicatement après impression, car certaines zones autour du mécanisme sont fragiles. Donc surtout, attendez que l’impression soit complètement refroidie avant de manipuler quoi que ce soit car la manipuler trop tôt peut déformer les ressorts intégrés et affecter les performances de tir.

Sur Cults 3D , on trouve même des versions “ultimes” avec des systèmes à élastique encore plus sophistiqués. Bref, la communauté DIY continue d’innover sur ce concept. Moi j’ai plus qu’à en trouver un qui peut se ranger dans ma voiture et qui ne passe pas pour une arme la prochaine fois que je croise la police pulicinalle, nulisimal, numicipal, argh, foutue dyslexie ! La police municipale, pardon !

Source

En ce moment, les développeurs s’extasiaient sur un truc appelé Jujutsu , ou “jj” pour les intimes. Au début, j’ai cru à une énième tentative de réinventer la roue puis j’ai creusé, et j’ai compris pourquoi ça fait autant parler.

Vous connaissez cette frustration avec Git ? Quand vous galérez avec l’index, que vous oubliez de stash vos modifs avant de changer de branche, ou que vous priez pour ne pas foirer votre rebase ? Eh bien, Martin von Zweigbergk, ingénieur chez Google et ancien contributeur Mercurial, a décidé qu’on méritait mieux.

Du coup, il a créé Jujutsu, un système de contrôle de version qui garde tous les avantages de Git en supprimant ses complexités.

Le principe de Jujutsu tient en une phrase : votre répertoire de travail EST un commit. Poh Poh Poh !!

Fini l’index, fini le staging area, fini les acrobaties pour synchroniser vos modifications. À chaque fois que vous sauvegardez un fichier, jj crée automatiquement un nouveau commit avec un hash différent, mais conserve un “change ID” stable qui survit aux réécritures. C’est complètement fou et pourtant ça marche.

Installation de Jujutsu

Pour installer jj, vous avez plusieurs options selon votre OS. Sur macOS avec Homebrew :

brew install jj

Sur Linux, utilisez le gestionnaire de paquets de votre distribution ou installez via Cargo :

# Via Cargo (nécessite Rust)
cargo install --locked jj

# Sur Arch Linux
pacman -S jujutsu

# Sur NixOS
nix-env -iA nixpkgs.jujutsu

Sur Windows, utilisez Winget ou Scoop :

# Via Winget
winget install --id martinvonz.jj

# Via Scoop
scoop bucket add extras
scoop install jujutsu

Une fois installé, configurez votre identité (comme avec Git) :

jj config set --user user.name "Votre Nom"
jj config set --user user.email "[email protected]"

Premiers pas avec Jujutsu

Pour initialiser un nouveau repo jj ou coexister avec un repo Git existant :

# Créer un nouveau repo jj
jj git init myproject

# Coexister avec un repo Git existant
cd existing-git-repo
jj git init --git-repo=.

# Cloner un repo Git avec jj
jj git clone https://github.com/user/repo.git

Concrètement, ça change tout. Plus besoin de git add, plus de git stash avant de changer de contexte, plus de commits temporaires pour sauvegarder votre travail en cours. Jujutsu traite votre copie de travail comme n’importe quel autre commit dans l’historique, ce qui simplifie drastiquement le modèle mental.

Voici les commandes de base pour travailler avec jj :

# Voir l'état actuel (équivalent de git status + git log)
jj st
jj log

# Créer une nouvelle branche de travail
jj new -m "Début de ma nouvelle feature"

# Modifier des fichiers (pas besoin de git add !)
echo "Hello Jujutsu" > README.md
# Les changements sont automatiquement suivis

# Voir les modifications
jj diff

# Créer un nouveau commit basé sur le précédent
jj new -m "Ajout de la documentation"

# Revenir au commit précédent
jj edit @-

# Naviguer dans l'historique
jj edit <change-id></change-id>

Gestion des conflits façon Jujutsu

Le système gère aussi les conflits différemment car là où Git vous force à résoudre immédiatement, jj peut sauvegarder les conflits directement dans l’arbre de commits , sous forme de représentation logique plutôt que de marqueurs textuels. Vous pouvez donc reporter la résolution et vous en occuper quand vous avez le temps. Une fois résolu, jj propage automatiquement la solution aux commits descendants.

# Merger deux branches (les conflits sont sauvegardés si présents)
jj new branch1 branch2

# Voir les conflits
jj st

# Les conflits sont stockés dans le commit, vous pouvez continuer à travailler
jj new -m "Travail sur autre chose pendant que le conflit existe"

# Revenir résoudre le conflit plus tard
jj edit <conflict-commit-id>

# Après résolution manuelle
jj squash # Pour intégrer la résolution</conflict-commit-id>

Manipulation de l’historique

L’outil brille aussi par sa puissance d’annulation. L’operation log dépasse largement les reflogs de Git en gardant une trace atomique de toutes les modifications de références simultanément. Comme ça, vous pouvez expérimenter sans crainte, sachant qu’un simple jj undo peut rattraper n’importe quelle erreur.

# Voir l'historique des opérations
jj op log

# Annuler la dernière opération
jj undo

# Revenir à un état précédent spécifique
jj op restore <operation-id>

# Réorganiser des commits (équivalent de rebase interactif)
jj rebase -s <source> -d <destination>

# Éditer un commit ancien
jj edit <change-id>
# Faire vos modifications
jj squash # Pour intégrer dans le commit actuel

# Split un commit en plusieurs
jj split</change-id></destination></operation-id>

Workflow quotidien avec Jujutsu

Voici un exemple de workflow typique pour une journée de développement :

# Commencer une nouvelle feature
jj new main -m "feat: ajout authentification OAuth"

# Travailler sur les fichiers
vim auth.js
vim config.js

# Pas besoin de git add ! Les changements sont auto-trackés
jj diff # Voir ce qui a changé

# Créer un checkpoint pour continuer
jj new -m "wip: OAuth provider setup"

# Oh, un bug urgent à fix sur main !
# Pas besoin de stash, on switch directement
jj new main -m "fix: correction crash login"

# Fix le bug
vim login.js

# Revenir à notre feature OAuth
jj edit @- # Revient au commit précédent

# Finaliser la feature
jj describe -m "feat: authentification OAuth complète"

# Pusher vers Git
jj git push

Intégration avec Git

Côté compatibilité, c’est du 100% Git. Jujutsu utilise les dépôts Git comme backend de stockage, ce qui signifie que vos collègues peuvent continuer avec Git classique sans même savoir que vous utilisez jj. Et si vous changez d’avis, supprimez juste le dossier .jj et tout redevient normal.

# Synchroniser avec le remote Git
jj git fetch

# Pusher vos changements
jj git push

# Créer une branche Git depuis un change jj
jj branch create ma-feature
jj git push --branch ma-feature

# Importer les changements depuis Git
jj git import

# Exporter vers Git (automatique généralement)
jj git export

Commandes avancées utiles

Selon les retours d’utilisateurs , même les experts Git qui maîtrisent parfaitement les rebases complexes découvrent qu’ils n’ont plus peur de manipuler l’historique. Réordonner des commits, corriger une modification ancienne, jongler avec plusieurs branches non mergées… tout devient trivial avec jj.

# Voir l'historique en mode graphique
jj log --graph

# Chercher dans l'historique
jj log -r 'description(regex:"fix.*bug")'

# Travailler avec plusieurs parents (merge commits)
jj new parent1 parent2 parent3

# Abandonner des changements locaux
jj abandon <change-id>

# Dupliquer un commit ailleurs
jj duplicate <change-id> -d <destination>

# Voir les changements entre deux commits
jj diff -r <from> -r <to>

# Créer un alias pour une commande fréquente
jj config set --user alias.l 'log --graph -r "ancestors(., 10)"'
jj l # Utilise l'alias</to></from></destination></change-id></change-id>

Configuration et personnalisation

Pour personnaliser jj selon vos besoins :

# Définir votre éditeur préféré
jj config set --user ui.editor "code --wait"

# Activer les couleurs dans le terminal
jj config set --user ui.color "always"

# Configurer le format de log par défaut
jj config set --user ui.default-revset "@ | ancestors(@, 10)"

# Voir toute la configuration
jj config list --user

# Éditer directement le fichier de config
jj config edit --user

Le projet évolue rapidement et l’équipe travaille sur plusieurs backends, y compris un natif qui pourrait dépasser Git en performance sur de gros dépôts.

Évidemment, Jujutsu reste expérimental. L’écosystème est plus petit, les intégrations IDE limitées (bien qu’il y ait déjà des extensions VSCode et Vim), et la terminologie différente demande un temps d’adaptation. Mais pour ceux qui cherchent une approche plus intuitive du contrôle de version, ça vaut franchement le détour.

Pour aller plus loin, je vous conseille de parcourir le tutoriel officiel qui couvre des cas d’usage plus avancés, ou de rejoindre le Discord de la communauté où les développeurs sont très actifs et répondent aux questions.

Bref, vous l’aurez compris, jj ne remplace pas Git dans l’immédiat . Il le sublime en gardant la compatibilité totale. C’est une approche intelligente qui permet d’adopter progressivement un workflow plus fluide sans perturber les équipes de dev.

Un grand merci à friendly_0day pour le partage !

Vous savez ce qui m’a plu en découvrant aujourd’hui MathJax 4.0 ?

Ce n’est pas tant les nouvelles fonctionnalités (pourtant impressionnantes) que le chemin parcouru depuis 2009. Car il y a 15 ans, afficher une simple équation mathématique sur une page web relevait du parcours du combattant et aujourd’hui, avec MathJax c’est tout ce qu’il y a de plus trivial.

Alors pour ceux qui ne connaissent pas, MathJax c’est LE moteur JavaScript open-source qui permet d’afficher des équations mathématiques sur n’importe quel navigateur. Sans plugin, sans galère, juste du JS pur.

Et cette v4 règle enfin des problèmes qu’on traîne depuis des années. Prenez par exemple le retour à la ligne automatique… Jusqu’à présent, si vous aviez une équation trop longue, tant pis pour votre mise en page. Et bien avec la v4, MathJax gère maintenant le line-breaking intelligent, aussi bien pour les équations en ligne que pour celles en bloc.

Les performances ont aussi pris un coup de boost considérable grâce à l’équipe qui a déplacé la génération de la synthèse vocale dans des web workers séparés. Concrètement, ça veut dire que même sur des pages bourrées d’équations complexes, votre navigateur reste réactif. Fini les freezes quand vous chargez un document de 200 pages avec des maths partout.

Côté typographie, c’est également du très lourd puisque MathJax 4.0 introduit un nouveau système de fonts par défaut avec une couverture de caractères bien plus étendue. Vous pouvez maintenant choisir parmi plusieurs polices mathématiques selon vos besoins.

L’intégration HTML dans les expressions LaTeX et MathML, sont également très cool car ça permet d’inclure des éléments HTML directement dans vos formules mathématiques. Des liens cliquables dans une équation, des tooltips interactifs, des animations… Les possibilités sont énormes pour créer des contenus éducatifs vraiment engageants.

Pour l’utiliser, il vous suffit d’inclure l’appel vers ce JS dans votre page HTML :

<script id="MathJax-script" async src="https://cdn.jsdelivr.net/npm/mathjax@4/tex-mml-chtml.js"></script>

Puis d’aller lire la documentation ici pour apprendre à l’utiliser.

Voici un exemple d’intégration :

<!DOCTYPE html>
<html>
<head>
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width">
 <title>MathJax example</title>
 <script id="MathJax-script" async
 src="https://cdn.jsdelivr.net/npm/mathjax@4/tex-mml-chtml.js">
 </script>
</head>
<body>

 When \(a \ne 0\), there are two solutions to \(ax^2 + bx + c = 0\) and they are
 \[x = {-b \pm \sqrt{b^2-4ac} \over 2a}.\]

</body>
</html>

Et voici ce que c’est censé rendre visuellement :

Et si vous avez un Wordpress, y’a même des plugins pour ce truc .

L’accessibilité n’est pas en reste avec un explorateur d’expressions mis à jour qui s’active par défaut comme ça, les utilisateurs de lecteurs d’écran peuvent naviguer dans les formules complexes avec une bien meilleure ergonomie. Ça permet de rendre les maths accessibles à tous.

Ah et j’allais oublier, MathJax 4.0 est maintenant disponible en modules ES6 en plus des modules CommonJS. Pour les développeurs qui bossent avec des stacks modernes, c’est un vrai plus pour l’intégration et l’optimisation des bundles.

Pour les développeurs de plateformes éducatives, de blogs scientifiques ou de wikis techniques, cette mise à jour va donc considérablement vous simplifier la vie. Plus besoin de bidouiller des solutions custom pour gérer les équations trop longues ou optimiser les performances sur mobile.

Un grand merci à Newa pour la découverte !

Une startup de Singapour vient de prouver qu’en matière IA, David peut encore battre Goliath car avec seulement 27 millions de paramètres selon leur papier de recherche , leur modèle HRM (Hierarchical Reasoning Model) pulvérise des géants comme GPT-4 sur des tâches de raisonnement complexe. Alors comment c’est possible ??? Et bien tout simplement en s’inspirant directement du cerveau humain.

L’équipe de Sapient Intelligence a levé 22 millions de dollars en janvier 2025 et vient enfin de libérer leur code sur GitHub . Leur approche consiste en deux modules qui bossent ensemble comme les régions de notre cortex. Le premier est un module “lent” pour la planification abstraite, et le second, un module “rapide” pour tout ce qui concerne les calculs détaillés.

Et les chiffres de ce qu’ils annoncent donnent le vertige. Selon VentureBeat , HRM délivre des performances jusqu’à 100 fois supérieures aux LLM classiques avec seulement 1000 exemples d’entraînement. Pour vous donner une idée, entraîner HRM sur des Sudoku de niveau professionnel prend environ 2 heures de GPU, et pour le benchmark ARC-AGI super complexe, entre 50 et 200 heures. Une broutille comparée aux ressources astronomiques des modèles de fondation d’OpenAI, de Google, d’Anthropic et j’en passe.

Mais sur le terrain, ça donne quoi ?

Et bien HRM cartonne sur l’ARC-AGI Challenge avec 40,3% de réussite selon l’analyse ARC Prize , alors que des modèles bien plus massifs ramassent. Il résout quasi parfaitement des Sudoku extrêmes et trouve le chemin optimal dans des labyrinthes de 30x30. Tout ça sans pré-entraînement, sans données Chain-of-Thought.

D’ailleurs, en parlant de Sudoku, c’est intéressant de noter que des chercheurs français du cluster IA ANITI à Toulouse avaient déjà publié en 2023 à IJCAI une architecture neuro-symbolique qui fait encore mieux. Avec seulement 22 000 paramètres (oui, 22k, pas 22 millions), leur modèle atteint 100% de réussite sur les Sudoku extrêmes après apprentissage sur 1000 grilles. Et le plus fou c’est qu’avec l’augmentation de données (celle que HRM utilise aussi mais ne mentionne pas trop…), une seule grille leur suffit pour apprendre à jouer parfaitement. Leur approche, détaillée dans ce papier , peut même apprendre à partir d’images de grilles et a été adaptée pour résoudre des problèmes de graphes ou concevoir des molécules .

La magie de ce modèle opère grâce à ce qu’ils appellent la “convergence hiérarchique”. En gros, le module haut niveau cogite lentement sur la stratégie générale pendant que le module bas niveau calcule à toute vitesse les détails. Exactement comme votre cerveau quand vous résolvez un problème complexe : une partie planifie, l’autre exécute. C’est d’ailleurs le principe de base de toutes ces approches neuro-symboliques qui combinent apprentissage profond et raisonnement logique, une voie que la recherche européenne explore depuis plusieurs années.

Cette approche ouvre des perspectives énormes pour les entreprises mais également dans le médical, où Sapient teste déjà HRM sur des diagnostics de maladies rares où les données sont éparses mais la précision critique. En climatologie, ils atteignent un joli 97% de précision sur les prévisions saisonnières.

L’aspect le plus dingue c’est que contrairement aux mastodontes verrouillés et payants, HRM est complètement open-source. Le code tourne sur votre laptop, et vous pouvez le modifier, l’améliorer. Même philosophie chez les chercheurs d’ANITI qui mettent aussi leurs travaux en accès libre, permettant à toute la communauté de bénéficier de ces avancées.

Alors faut-il vraiment des centaines de milliards de paramètres quand l’intelligence peut émerger de structures plus compactes mais mieux organisées ? HRM suggère qu’on a peut-être fait fausse route en privilégiant la taille brute à l’efficacité architecturale. Et les travaux antérieurs en neuro-symbolique, comme ceux d’ANITI avec leurs 22k paramètres, montrent qu’on peut aller encore beaucoup plus loin dans la compacité tout en gardant, voire en améliorant, les performances.

Du coup, les géants de la tech vont-ils revoir leur copie pour adopter une approche semblable ? On verra bien ! En tout cas, que ce soit avec HRM ou les architectures encore plus légères développées en Europe, une chose est claire : la course aux milliards de paramètres n’est peut-être pas la seule voie vers l’AGI.

Un grand merci à Lorenper et Thomas pour l’info !

Source

Vous la connaissez cette fatigue de quand vous lancez votre serveur de dev et que ce satané message d’erreur EADDRINUSE vous annonce que le port 3000 est déjà utilisé ? Et bien moi oui, et visiblement je ne suis pas le seul puiqu’un développeur de talent a décidé que c’était la goutte d’eau et a créé Port Kill , une petite app macOS qui vit tranquillement dans votre barre de menu et qui surveille les ports ouverts comme le vigile de Franprix vous surveille.

Comme ça, au lieu de jouer au jeu du chat et de la souris avec lsof, netstat et kill dans votre terminal, Port Kill scanne automatiquement tous les ports entre 2000 et 6000 toutes les 5 secondes et vous dit ce qui est ouvert. Alors pourquoi cette plage ? Hé bien parce que c’est là que la plupart d’entre nous faisons tourner nos serveurs de développement. React sur 3000, Vue sur 8080, votre API custom sur 5000… Vous voyez le tableau.

Ce qui est sympa avec Port Kill, c’est l’interface. L’icône dans la barre de menu change de couleur selon le nombre de processus détectés. Vert quand tout est clean, rouge quand vous avez entre 1 et 9 processus qui traînent, et orange quand ça part en cacahuète avec plus de 10 processus. Un clic sur l’icône et vous avez la liste complète avec la possibilité de tuer chaque processus individuellement ou de faire table rase d’un coup.

Techniquement, c’est du solide puisque c’est écrit en Rust (hé oui parce qu’en 2025, si c’est pas du Rust, c’est has-been), l’app utilise les commandes système lsof pour détecter les processus. Et la stratégie de kill de l’outil est plutôt intelligente puisqu’il fait d’abord un SIGTERM poli pour demander gentiment au processus de se barrer, et si au bout de 500ms ce dernier fait le têtu, PAF, un SIGKILL dans les dents. C’est la méthode douce-ferme, comme quand vous demandez à votre chat de descendre du clavier.

Le contexte, c’est qu’on a tous galéré avec ça. L’erreur EADDRINUSE est un classique du dev web. Vous fermez mal votre serveur avec Ctrl+C, ou pire, vous fermez juste la fenêtre du terminal, et hop, le processus continue de tourner en arrière-plan comme un zombie. Sur macOS, c’est encore plus vicieux depuis Monterey avec AirPlay qui squatte le port 5000 par défaut.

Il existe d’autres solutions, bien sûr. Par exemple, Killport est autre un outil en ligne de commande cross-platform écrit aussi en Rust qui fait un job similaire. kill-my-port est un package npm qui fait la même chose. Mais ces outils nécessitent de passer par le terminal à chaque fois. Port Kill, lui, est toujours là, discret dans votre barre de menu, prêt à dégainer.

L’installation est simple : vous clonez le repo GitHub, un petit cargo build --release si vous avez Rust installé, et vous lancez avec ./run.sh. L’app tourne en tâche de fond, consomme quasi rien en ressources, et met à jour son menu contextuel toutes les 3 secondes. Pas de fenêtre principale, pas de configuration compliquée, juste l’essentiel.

Pour les puristes du terminal, oui, vous pouvez toujours faire lsof -ti:3000 | xargs kill -9. Mais franchement, avoir une interface graphique pour ce genre de tâche répétitive, c’est pas du luxe. Surtout quand vous jonglez entre plusieurs projets et que vous ne vous rappelez plus quel port utilise quoi.

Le seul bémol, c’est que c’est limité à macOS pour l’instant donc les développeurs sur Linux et Windows devront se contenter des alternatives en CLI. Mais bon, vu que le code est open source, rien n’empêche quelqu’un de motivé de faire un portage.

Voilà, donc si comme moi vous en avez marre de cette danse répétitive pour trouver et tuer le processus qui squatte votre port, Port Kill mérite que vous y jetiez un oeil.