Le YouTubeur Marcin Plaza a réussi à transformer un téléphone pliable tout pété en une pièce unique qui va vous rappeler l’âge d’or des claviers physiques sur les smartphones…

Pour lui, les smartphones modernes sont devenus tristement uniformes. Des milliers de modèles qui se ressemblent tous, des rectangles de verre fragiles produits par millions. Même le Galaxy Z Flip, avec son design pliable censé apporter de l’originalité, reste finalement assez conventionnel…

Alors il a récupéré un Z Flip cassé sur eBay (beaucoup moins cher qu’un neuf), l’a démonté entièrement, a retiré le mécanisme de charnière défectueux, et a conçu une carte PCB from scratch afin de lier le smartphone avec un clavier BlackBerry Q10.

Un sacré boulot !

Vous avez déjà fixé votre terminal en vous disant “il lui manque quelque chose” ?

Bien sûr que oui, et ce quelque chose, c’est une représentation précise de la Lune en pur ASCII 7-bit !!

Aleyan, un développeur visiblement obsédé par les détails astronomiques, a créé ASCII Side of the Moon , un projet qui va faire de votre terminal un observatoire lunaire minimaliste.

Mais attention, ce n’est pas juste un dessin statique de la Lune. L’outil calcule en temps réel la phase lunaire, la distance Terre-Lune ET même l’angle de libration. Pour ceux qui se demandent, la libration c’est ce petit mouvement d’oscillation de la Lune qui nous permet de voir environ 59% de sa surface au fil du temps, au lieu des 50% théoriques. Et oui, tout ça est visible dans l’ASCII art généré.

Pour les curieux qui veulent tester immédiatement, c’est con comme la Lune (justement ^^). Vous pouvez soit utiliser curl directement dans votre terminal :

curl -s "https://aleyan.com/projects/ascii-side-of-the-moon?date=2025-09-01"

npx ascii-side-of-the-moon

329 menaces détectées, c’est le score qu’affiche Windows Defender quand vous téléchargez Kali Linux. C’est pas mal pour un simple fichier ISO, non ? D’après les discussions sur SuperUser , c’est parfaitement normal et ça arrive surtout avec les payloads Metasploit inclus dans la distribution. Mais le plus drôle dans cette histoire, c’est que ce “problème” existe depuis plus de 25 ans et touche toutes les distribs.

Jesse Smith de DistroWatch reçoit en effet régulièrement des messages paniqués de nouveaux utilisateurs Linux. Leur crime ? Avoir osé télécharger une distribution Linux pendant que Windows montait la garde. Et boom, l’antivirus s’affole comme si vous veniez de DL la peste bubonique. Le gars explique que sur 1000 alertes de ce genre, 999 sont des faux positifs donc autant dire que votre antivirus a plus de chances de se tromper que vous de gagner au loto.

Mais pourquoi cette paranoïa des antivirus Windows face aux ISOs Linux ?

La réponse est presque trop logique et simple pour être vraie. Un fichier ISO, c’est une archive qui contient du code exécutable. Du code qui peut modifier les partitions, installer un bootloader, toucher au kernel… Bref, exactement le genre de trucs qu’un malware adorerait faire sur Windows… sauf que dans le cas de Linux, c’est précisément ce qu’on veut qu’il fasse !

Et quand on réalise que les développeurs Linux bossent quasi exclusivement sur… Linux, les chances qu’un malware Windows se glisse accidentellement dans une ISO Linux sont à peu près aussi élevées que de voir Microsoft open-sourcer Windows demain matin. C’est techniquement possible, mais hautement improbable.

Le problème est particulièrement visible avec les distributions orientées sécurité, ce qui est normal, car elles embarquent des outils de pentest qui ressemblent furieusement à des malwares du point de vue d’un antivirus. Password crackers, frameworks d’exploitation, outils d’accès distant… Pour Windows Defender, c’est Noël tous les jours.

Ce qui devient vraiment problématique, c’est l’impact sur les nouveaux utilisateurs qui prennent peur. Il y a eu des cas où même des fichiers boot innocents comme memtest64.efi, bootia32.efi ou grubx64.efi sont flaggés comme suspects, alors je vous laisse imaginer la tête du débutant qui veut juste essayer Linux et qui se retrouve face à une avalanche d’alertes rouges.

La situation a même empiré récemment puisque selon les rapports de septembre 2025 sur Windows Forum , il y a eu une augmentation notable des signalements ces dernières semaines. Différentes distributions, différents antivirus, mais toujours le même refrain : “Attention, virus détecté !”

Donc pour vérifier que votre ISO n’est pas réellement infectée (spoiler : elle ne l’est pas), la procédure est simple. Téléchargez la depuis les sources officielles, vérifiez le hash SHA256 fourni sur le site, et si vous êtes vraiment parano, scannez la avec un autre antivirus. Si deux antivirus différents détectent exactement le même malware spécifique, là vous pouvez commencer à vous inquiéter. Sinon, c’est juste Windows qui fait sa drama queen.

Le côté pervers de ces fausses alertes répétées, c’est qu’elles poussent également les utilisateurs à désactiver leur protection ou à ignorer systématiquement les avertissements. Et ça c’est un vrai problème de sécurité car à force de crier au loup pour rien, les antivirus finissent par perdre un peu crédibilité.

Alors bien sûr, Microsoft pourrait facilement créer une liste blanche pour les ISOs des distributions Linux majeures, mais après 25 ans d’inaction, on peut raisonnablement penser que ce n’est pas leur priorité. Puis j’sais pas, peut-être qu’ils trouvent ça amusant de voir les nouveaux utilisateurs Linux flipper avant même d’avoir booté sur leur clé USB.

Voilà, donc attendant, si votre antivirus vous dit que votre ISO Ubuntu contient 42 virus, respirez un grand coup. C’est juste Windows qui ne comprend pas qu’on puisse vouloir utiliser autre chose que lui…

Source

C’est fou quand même qu’en 2025, les débogueurs de base comme GDB et LLDB soient toujours aussi pénibles à utiliser qu’il y a 20 ans. Par exemple faut taper x/30gx $rsp pour examiner la pile et obtenir un bloc de nombres hexadécimaux sans contexte. C’est donc super chiant pour comprendre tout ce qui se passe dans votre programme, sans être ultra concentré (et donc ultra fatigué à la fin de la journée).

Hé bien c’est exactement ce que s’est dit Zach Riggle quand il a commencé à bosser sur pwndbg (prononcez “/paʊnˈdiˌbʌɡ/”, oui comme “pound debug”). L’idée c’était de créer un plugin qui transforme ces débogueurs préhistoriques en véritables outils modernes pour les reverse engineers et les développeurs d’exploits.

Le truc avec pwndbg, c’est qu’il ne cherche pas à réinventer la roue, non, bien au contraire, puisqu’il s’appuie sur une architecture Python modulaire afin d’ajouter une couche d’intelligence par-dessus GDB et LLDB. Concrètement, ça veut dire que vous gardez toute la puissance de ces débogueurs, mais avec une interface qui ne vous donne pas envie de jeter votre clavier par la fenêtre, avant de vous y jeter vous-même ^^.

Pour l’installer, quelques lignes suffisent et hop vous aurez un environnement de debugging qui ferait pâlir d’envie les outils commerciaux.

Si vous êtes sur Linux ou macOS, la méthode la plus simple c’est la ligne magique avec curl qui va tout faire pour vous :

curl -qsL 'https://install.pwndbg.re' | sh -s -- -t pwndbg-gdb

Les utilisateurs de Mac peuvent aussi passer par Homebrew avec un simple

brew install pwndbg/tap/pwndbg-gdb

Et pour les hipsters des gestionnaires de paquets, y’a même une option avec Nix qui vous permet de tester l’outil sans rien installer en dur sur votre système. Maintenant, si vous préférez la méthode old school avec les packages classiques, pas de souci !

Récupérez le package qui correspond à votre distro sur la page des releases et installez-le avec votre gestionnaire de paquets habituel et en deux minutes chrono, vous avez votre environnement de debug GDB boosté aux stéroïdes avec toutes les fonctionnalités de pwndbg pour analyser vos binaires comme un chef.

Ensuite, que vous fassiez du débug de kernel Linux, du reverse sur des binaires ARM ou RISC-V, ou que vous développiez des exploits pour des systèmes embarqués, pwndbg saura s’adapte. Il gère même le debugging avec QEMU pour l’émulation user-space. Par contre, petit bémol pour les utilisateurs macOS, le debugging natif de binaires Mach-O n’est pas supporté avec GDB… Pour le moment, seul le debugging distant ELF fonctionne.

Un des aspects les plus cools de pwndbg, c’est son approche “consistency first”. Que vous utilisiez GDB ou LLDB, l’expérience reste cohérente. Vous pouvez donc switcher entre les deux débogueurs sans avoir à réapprendre tous les raccourcis et commandes. Bon, le support LLDB est encore expérimental et peut contenir quelques bugs, mais ça progresse vite.

Les développeurs low-level, les hardware hackers et les chercheurs en sécurité sont les premiers à adore pwndbg parce qu’au lieu de vous noyer sous des informations inutiles, il affiche exactement ce dont vous avez besoin à savoir le contexte des registres, l’état de la pile, le code désassemblé avec coloration syntaxique, et même une vue hexdump digne de ce nom (oui, en 2025, les débogueurs de base n’ont toujours pas ça par défaut).

Le projet est sous licence MIT, donc vous pouvez l’utiliser dans n’importe quel contexte, commercial ou non et si vous voulez contribuer, comme d’hab avec la plupart des projets que je vous présente, la porte est grande ouverte.

Pour ceux qui veulent se lancer, il y a même un cheatsheet complet à imprimer et garder sous la main. Parce que bon, même avec une interface aux petits oignons, un bon aide-mémoire reste toujours utile quand on débugge des trucs complexes à 3h du matin.

Au final, pwndbg c’est la preuve qu’on n’a pas toujours besoin de réinventer complètement un outil pour le rendre génial. Parfois, il suffit juste d’ajouter la bonne couche d’abstraction au bon endroit.

Encore bravo à Zach Riggle et son équipe ont vraiment tapé dans le mille !!

Connaissez-vous PowerMail , le spécialiste français de l’hébergement mail pour les pro ? Peut-être pas, mais on va remédier à ça, car derrière PowerMail, il n’y a pas une multinationale avec des milliers d’ingénieurs, mais une petite équipe française qui a décidé de créer sa propre technologie email de zéro. Et ça, dans le contexte actuel c’est assez courageux.

Dans un monde dominé par Google et Microsoft, ces gars-là développent tranquillement leur propre serveur mail depuis les Pays de la Loire. Et ils ne font pas semblant puisque PowerMail héberge aujourd’hui des dizaines de milliers de boîtes, ce qui représente 25 000 utilisateurs, 91 millions de messages, et plus de 58 To de data, avec une clientèle qui va de la PME aux collectivités. Pas mal pour une alternative 100% française lancée en 2007, à une époque où tout le monde basculait déjà vers les solutions américaines.

Et leur approche technique est très osée, puisqu’au lieu de se contenter d’utiliser des solutions existantes comme Exchange ou Zimbra comme la plupart des hébergeurs mail, eux ont développé leur propre serveur POP/IMAP/SMTP. Et ça, ça demande un sacré niveau en programmation et une vision à long terme, parce que créer un serveur mail from scratch, le personnaliser et l’optimiser aux petits oignons… c’est pas donné à tout le monde. Mais c’est aussi ce qui leur permet d’avoir la main sur absolument tout et de ne pas dépendre d’un éditeur tiers.

D’un point de vue infrastructure, ils ont également fait le choix de la redondance maximale, et c’est là qu’on voit qu’ils ne plaisantent pas. Chaque client dispose ainsi de deux serveurs synchronisés en temps réel, dans des datacenters différents et chez des opérateurs distincts. Comme ça, si l’un tombe, l’autre prend le relais automatiquement. Détection de panne en ~1 minute, bascule DNS en ~1 minute, et un taux de dispo annoncé à 99,99%. Et contrairement à certains qui annoncent des chiffres au doigt mouillé, eux ont un vrai monitoring externe avec UptimeRobot qui certifie ces stats. Bref, du solide.

Sur la sécurité, c’est carré aussi puisqu’ils supportent SPF/DKIM/DMARC (ce qui devrait être la base en 2025, mais vous seriez surpris…), antivirus, et même une double authentification (2FA) pour verrouiller l’admin côté web.

Mais là où PowerMail se démarque vraiment, c’est sur l’interface d’administration. Certes, c’est à l’ancienne niveau design (ne vous attendez pas à du Material Design ou des animations partout) mais c’est clair, précis et accessible. Tout paraît simple à configurer et vous avez tout sous la main.

En testant leur espace client, je comprends mieux maintenant pourquoi les DSI l’apprécient. Quand on gère des centaines de boîtes, on veut de l’efficacité, pas du bling-bling.

Au travers de cette interface, vous avez donc trois niveaux d’accès : administrateur général, gestionnaire de domaine, et utilisateur final. Chacun peut ainsi configurer ses propres règles antispam, ses redirections, ses répondeurs automatiques. C’est ce degré de contrôle granulaire qui fait la différence quand vous gérez plusieurs centaines de comptes. Et franchement, même Microsoft 365 ne fait pas beaucoup mieux, et cela pour un prix bien supérieur.

Concernant l’antispam, ils ont aussi sorti l’artillerie lourde puisque leur moteur maison combine plus d’une vingtaine de critères : bayésien, RBL, géolocalisation, analyse de la structure et du respect SMTP, filtrage par langue/alphabet, détection des newsletters, Google Safe Browsing/URIBL pour les liens, greylisting, analyse de l’heure/jour d’envoi… Et le top, c’est vraiment la quarantaine centralisée comme ça, au lieu d’avoir les spams éparpillés dans chaque boîte, tout remonte vers une boîte unique sous contrôle de l’admin (débannir en un clic, supprimer direct ce qui vient d’une liste noire, etc.).

C’est du bon sens, mais étonnamment, peu de solutions le proposent aussi simplement. Et cadeau bonux, vous pouvez recevoir également des rapports antispam périodiques pour vérifier ce qui a été bloqué.

Côté fonctionnalités, PowerMail intègre aussi des trucs qu’on ne voit pas ailleurs ou qu’on ne voit qu’en SaaS séparé à prix d’or. Je pense par exemple à l’e-mail recommandé avec accusé PDF signé (*LRAR dans l’objet), la signature électronique de documents par les destinataires (*SIGN), l’envoi différé côté serveur (*DELAI=…) (donc ça marche même si votre client mail est fermé), la copie carbone individuelle (*INDIV) pour du mail‑merge propre, l’envoi de fax par mail (*FAX=…) (oui, certains secteurs en ont encore besoin), les dossiers IMAP partagés, l’archivage automatique, et les alertes SMS sur réception de messages importants (ponctuelles ou récurrentes, avec mots‑clés/expéditeurs).

Essayez de trouver tout ça chez un concurrent au même prix.

Et pour les pièces jointes, pas de prise de tête puisque vous pouvez y aller jusqu’à 1 Go par envoi, avec détachement automatique au‑delà d’un seuil configurable et lien de téléchargement en haut du mail pour le destinataire (avec accusé quand il récupère les fichiers). Pratique, et ça évite de saturer les boîtes de tout le monde !

Ils proposent également un système de calendriers et contacts (CalDAV / CardDAV) pour rester en synchro entre PC et smartphones, comme sur un Exchange mais en plus ouvert. Et le webmail, c’est du Roundcube, régulièrement mis à jour. Pas le plus sexy, certes, mais c’est fonctionnel et éprouvé.

Bref, ils partent des vrais besoins métier de leurs clients plutôt que de chercher à faire le buzz avec la dernière techno à la mode. Côté références, on croise notamment TotalEnergies, 4Murs, les Pompiers de Paris, la Région Bretagne et du secteur régulé avec les Notaires (ADSN) qui ont signé une convention cette année. Tous ont comme point commun un besoin fort de maîtriser leurs communications sans dépendre d’un GAFAM et sans voir leurs données partir aux États-Unis.

Car oui, la souveraineté numérique, c’est pas juste un argument marketing ici. Vos données restent stockées à 100% en France, pas de Cloud Act, pas d’IA qui scanne vos mails pour vous proposer de la pub. Et pour le support, c’est par e‑mail 7j/7 et téléphone du lundi au samedi (9h-20h sur un numéro non surtaxé). Essayez d’avoir quelqu’un au téléphone chez Google, bon courage.

Maintenant, les tarifs !! Et c’est là que ça devient vraiment intéressant.

Pour les particuliers, ils proposent un service e‑mail gratuit en @powermail.fr avec 3 Go de stockage. C’est une offre réservée aux particuliers en France, pas de support, et certaines fonctions pro ne sont pas incluses (fax, alertes SMS, signature électronique, CalDAV/CardDAV). Mais pour un mail perso souverain et gratuit, c’est cadeau !

Et pour les entreprises, on est par contre sur du mutualisé à la carte à partir de 0,40 € HT / utilisateur / mois (oui, 40 centimes !), et du cluster dédié (2 serveurs privés en temps réel, 2 DC/2 opérateurs) sur devis. Leur priorité, clairement, c’est donc la qualité de service plus que les gros volumes. Et à ce prix-là, franchement, pourquoi s’en priver ?

Alors bien sûr, tout n’est pas parfait. L’interface mériterait un petit lifting, il manque quelques fonctions modernes (Ils ont une API mais elle n’est pas REST, pas d’app mobile dédiée), et ils ne peuvent certes pas rivaliser avec tout l’écosystème Office 365 ou Google Workspace. Mais pour du mail qui fonctionne à 100%, avec des fonctions qu’on ne trouve pas ailleurs, hébergé en France, avec un vrai support, le tout à un prix défiant toute concurrence… PowerMail c’est l’exemple parfait de ce qu’on peut faire avec une équipe technique compétente et une vision claire.

Et dans un secteur complètement dominé par les géants américains, je trouve qu’ils arrivent plutôt bien à proposer une alternative crédible et souveraine tout en développant leur propre stack technologique. Pas de bullshit marketing, pas de buzzwords, juste un service qui fait le job. Et ça, pour une boîte française de taille humaine qui tient tête aux mastodontes depuis 14 ans, c’est plutôt remarquable.

Bref, si vous cherchez une alternative aux GAFAM pour vos mails pro, PowerMail mérite vraiment qu’on s’y intéresse.

60 millions de documents, c’est ce que LEANN peut indexer sur votre petit laptop sans faire exploser votre SSD. C’est ouf non ? Car pendant que tout le monde se bat pour avoir le plus gros modèle d’IA avec des milliards de paramètres, des chercheurs de UC Berkeley ont décidé de prendre le problème à l’envers en compressant tout ça pour que ça tienne sur un Macbook Air ou équivalent.

L’idée est tellement… au lieu de stocker tous les embeddings vectoriels (ces représentations mathématiques qui permettent à l’IA de comprendre vos documents), LEANN les recalcule à la volée quand vous en avez besoin. C’est comme si au lieu de garder 10 000 photos de votre chat sous tous les angles, vous gardiez juste une photo + un algorithme capable de reconstituer les autres instantanément.

Le truc vraiment fou, c’est que cette approche réduit l’espace de stockage de 97% par rapport aux solutions classiques comme Pinecone ou Qdrant. Pour vous donner une idée, là où une base vectorielle traditionnelle aurait besoin de 100 Go pour indexer vos documents, LEANN s’en sort avec 3 Go seulement. Et selon les benchmarks publiés , ça maintient 90% de précision avec des temps de réponse sous les 2 secondes.

Concrètement, LEANN utilise une technique qu’ils appellent “graph-based selective recomputation with high-degree preserving pruning” (oui, les chercheurs adorent les noms à rallonge). En gros, au lieu de parcourir tous les vecteurs pour trouver une correspondance, le système navigue dans un graphe optimisé qui ne garde que les connexions les plus importantes. C’est un peu comme utiliser Waze au lieu de vérifier toutes les routes possibles pour aller quelque part.

L’installation est d’une simplicité déconcertante :

curl -LsSf https://astral.sh/uv/install.sh | sh
uv venv
source .venv/bin/activate
uv pip install leann

Et hop, avec ça vous pouvez indexer vos PDFs, vos emails Apple Mail, votre historique Chrome, vos conversations WeChat, et même votre codebase entière. Le système est d’ailleurs assez malin pour comprendre la structure du code (fonctions, classes, méthodes) plutôt que de bêtement découper le texte tous les 500 caractères.

Et LEANN s’intègre directement avec Claude Code via un serveur MCP. Pour ceux qui utilisent Claude Code (coucou les Vibe Coders, on est ensemble !! ^^), vous savez que le plus gros problème c’est qu’il fait toujours des grep qui ne trouvent presque jamais rien. Alors qu’avec LEANN, une seule ligne de config et boom, vous avez de la recherche sémantique intelligente dans votre IDE.

Les cas d’usage sont d’ailleurs assez dingues puisque certains l’utilisent pour créer leur propre second cerveau qui indexe tout ce qu’ils ont lu, écrit ou consulté. D’autres s’en servent en entreprise pour faire de la recherche dans des bases documentaires sensibles sans rien envoyer dans le cloud. Y’a même des développeurs qui l’utilisent pour naviguer dans des codebases monstrueuses de millions de lignes. Moi je suis en train de le dompter pour lui faire bouffer tout le contenu de mon site et voir ce que je peux en tirer…

Le projet arrive donc pile au bon moment pour moi, mais aussi pour tous ceux qui s’inquiètent de leur vie privée et des données qui partent chez OpenAI ou Google. Avoir une solution 100% locale qui tourne sur votre machine, c’est top surtout dans des domaines comme la santé ou la finance où envoyer des données dans le cloud, c’est juste pas une option.

Et les chercheurs de Berkeley ne se sont pas arrêtés là puisqu’ils ont aussi intégré du support multilingue, donc vous pouvez chercher en français dans des documents en anglais et vice versa. Et cerise sur le gâteau, tout est open source sous licence MIT, donc vous pouvez tripatouiller le code comme bon vous semble.

Évidemment, LEANN a ses limites car le recalcul à la volée consomme plus de CPU que de simplement lire des vecteurs pré-calculés. Donc sur une machine vraiment faiblarde, ça peut ramer un peu. Et pour des cas d’usage où vous avez besoin de réponses en millisecondes (genre un moteur de recherche public), c’est peut-être pas l’idéal. Mais franchement, pour 97% d’économie de stockage et une vie privée totale, c’est un compromis que beaucoup sont prêts à faire. Surtout quand on sait que le prochain macOS va probablement embarquer de l’IA partout et qu’on aimerait bien garder nos données pour nous.

Voilà, pour ceux qui veulent creuser, le papier de recherche détaille toute la théorie derrière. Les benchmarks notés dans ce papier montrent même que LEANN bat certaines solutions cloud sur des requêtes complexes, tout en tournant sur un laptop à 2000 euros au lieu d’un cluster à 100 000 balles.

Bref, LEANN c’est l’exemple parfait qu’on n’a pas toujours besoin de plus de puissance ou plus de stockage. Suffit juste d’être plus malin !

Merci à Letsar et Lorenper pour le partage !

Ça y est, c’est la rentrée et votre YouTubeur préféré a sorti 15 vidéos pendant vos vacances… Ouin !!! va tout falloir rattraper ! Ou pire, le gars a supprimé ses anciennes vidéos sans prévenir ! Heureusement, c’est le genre de problème que Subarr vient résoudre, et de manière plutôt chouette, vous allez voir.

L’idée derrière Subarr, c’est en fait de transposer la philosophie de Sonarr (qui automatise le téléchargement de séries TV) au monde chaotique de YouTube. Le développeur Derek Antrican a d’ailleurs tellement poussé le concept qu’il a même repris l’interface utilisateur de Sonarr pour que les habitués s’y retrouvent immédiatement. Et après avoir hésité avec le nom “YouTubarr”, il a même opté pour “Subarr”, un clin d’œil aux flux RSS sur lesquels repose tout le système.

Le principe est donc très simple puisqu’au lieu de scraper YouTube comme un bourrin (ce qui vous vaudrait un ban rapide), Subarr utilise les flux RSS officiels que YouTube met à disposition pour chaque playlist et chaîne. Ces flux sont limités aux 15 derniers items, mais Subarr construit sa propre base de données au fil du temps, en gardant une trace de tout ce qui passe. Une fois qu’une nouvelle vidéo est détectée, vous pouvez alors déclencher n’importe quelle action comme envoyer une notification Discord, lancer yt-dlp pour télécharger la vidéo, ou même exécuter un script custom de votre création.

Contrairement à des solutions comme TubeArchivist qui nécessite 4GB de RAM minimum, Subarr est très léger et peut tourner tranquillement sur un Raspberry Pi avec quelques centaines de MB. Le développeur insiste d’ailleurs sur ce point : Il l’a voulu volontairement minimaliste ! Pas de gestion de métadonnées complexes, pas d’interface de lecture intégrée, juste de la surveillance et du déclenchement d’actions.

L’installation se fait en trois commandes :

git clone https://github.com/derekantrican/subarr.git
cd subarr
npm install && npm run start-server

Boom, vous avez votre instance qui tourne sur le port 3000. Par contre, attention, il n’y a aucune authentification intégrée, donc si vous l’exposez sur internet, pensez à mettre un reverse proxy avec auth devant, ou utilisez quelque chose comme Cloudflare Tunnel.

Certains l’utilisent pour archiver automatiquement les chaînes de vulgarisation scientifique avant qu’elles ne disparaissent. D’autres s’en servent pour créer leur propre bibliothèque de tutoriels techniques hors ligne. Et puis il y a ceux qui veulent juste être sûrs de ne jamais rater un épisode de leur podcast vidéo favori, même quand ils partent en vadrouille sans connexion.

Le projet a quand même ses limites, qu’il faut garder en tête. D’abord, si Subarr est down pendant que 20 vidéos sont publiées sur une chaîne, vous allez en louper 5 (rappelez-vous, les flux RSS sont limités à 15 items). Ensuite, c’est vraiment conçu pour du monitoring de nouveautés, pas pour aspirer l’intégralité d’une chaîne existante. Pour ça, yt-dlp en ligne de commande reste plus adapté.

Voilà, entre ArchiveBox qui archive tout le web, les diverses interfaces web pour yt-dlp, et maintenant Subarr qui fait le pont avec l’univers *arr, on a vraiment l’embarras du choix maintenant pour construire son propre “Netflix personnel” alimenté par YouTube.

Et pour ceux qui veulent aller plus loin, il est possible de synchroniser Subarr avec ytsubs.app pour importer automatiquement toutes vos souscriptions YouTube. Vous pouvez aussi utiliser des regex pour filtrer le contenu (pratique pour exclure les Shorts ou les vidéos sponsorisées), et même chaîner plusieurs post-processeurs pour créer des workflows complexes.

Au final, Subarr c’est top pour les accros au self-hosting qui souhaitent reprendre le contrôle sur leur consommation de contenu sans dépendre du bon vouloir de l’algorithme YouTube ou de la stabilité des serveurs de Google. Avec cet outil, vos vidéos préférées seront toujours chez vous, sur votre NAS, accessibles même quand internet flanche.

Merci à Letsar pour le partage.

Quatre euros, c’est le prix d’un café dans certains endroits, mais c’est aussi le coût d’un Raspberry Pi Pico capable d’extraire tous les mots de passe WiFi stockés sur un ordinateur en moins de 15 secondes.

Hé oui car pendant que les entreprises investissent des millions dans la cybersécurité, un petit projet GitHub nous rappelle que les vulnérabilités les plus dangereuses restent souvent les plus simples.

Ce type d’attaque par injection de touches proposé par ce projet atteint quand même 94,28% de taux de réussite, selon cette étude publiée sur ResearchGate . En gros, vous branchez ce qui ressemble à une clé USB innocente, et en quelques secondes, l’appareil simule un clavier qui tape plus de 1000 mots par minute. Y’a aucune alerte antivirus, aucun avertissement de sécurité… Pour le système, c’est juste un clavier qui tape très, très vite.

Ce projet WiFi-password-stealer d’AleksaMCode transforme donc cette théorie en un outil accessible. Son créateur a en effet développé ce système pendant l’été 2022, initialement pour démontrer les capacités d’un Rubber Ducky à petit prix et aujourd’hui, avec la dernière version de CircuitPython, la configuration ne prend plus que 5 minutes.

Concrètement, l’attaque fonctionne en exploitant la confiance aveugle que nos systèmes accordent aux périphériques USB. Sous Windows, le dispositif utilise PowerShell pour extraire les identifiants WiFi stockés, puis les envoie par email via SMTP. Sous Linux, c’est encore plus direct puisque les mots de passe sont copiés depuis /etc/NetworkManager/system-connections/ directement sur une clé USB. Le script grep avec des expressions régulières positives lookbehind ((?<=ssid=).* et (?<=psk=).*) fait tout le travail d’extraction.

Pour rendre l’appareil plus discret, il suffit de connecter un fil entre les pins GPIO15 et GND et le Pico disparaît alors complètement de l’explorateur de fichiers, ne laissant aucune trace visible de sa présence. Un autre câble entre GPIO5 et GND permet également de basculer entre plusieurs payloads selon la cible. Ces petits détails transforment alors un simple microcontrôleur en outil d’infiltration redoutable.

Le plus inquiétant ? +80% des utilisateurs réutilisent le même mot de passe selon les données collectées lors de ces attaques. Un seul ordinateur compromis peut donc ouvrir les portes de dizaines de comptes. Faut pas oublier que la majorité des gestionnaires de réseaux sous Linux stockent ces informations en clair dans des fichiers .ini, ce qui rend l’extraction hyper simple pour qui a les bonnes permissions.

Face à ces menaces, les défenses existent mais restent sous-utilisées. Désactiver les ports USB sur les machines sensibles reste la protection la plus efficace et les solutions EDR (Endpoint Detection and Response) peuvent aussi détecter les patterns d’injection de touches suspectes… Mais combien d’entreprises les ont vraiment configurées correctement ? Il y a aussi des adaptateurs USB “préservatifs” qui bloquent les données tout en permettant de charger les appareils, mais qui les utilise vraiment ?

Alors, paranoia ou prudence légitime ? En tout cas, la prochaine fois que vous verrez une clé USB abandonnée dans un parking ou qu’un collègue vous demandera de “juste brancher ça deux secondes”, vous y penserez peut-être à deux fois.

530 millions d’euros . C’est l’amende que TikTok vient de se prendre dans la tronche pour avoir transféré illégalement des données d’utilisateurs européens vers la Chine. Et vous savez quoi ? C’est juste la partie émergée de l’iceberg. Une étude récente d’Incogni sur 400 apps populaires révèle un truc complètement dingue : les applications étrangères collectent en moyenne 3 fois plus de données personnelles que leurs homologues européennes.

Faites le test maintenant : tapez votre nom complet sur Google. Allez-y, je vous attends…

Alors ? Adresse, numéro de téléphone, historique professionnel, peut-être même des photos que vous pensiez privées ? C’est flippant, non ? Moi, j’ai trouvé mon adresse complète sur 12 sites différents, mon numéro de téléphone sur 8, et même mon salaire estimé sur 3 sites de data brokers. Non, je déconne, c’est pas vrai parce que j’utilise Incogni !!

C’est Meta (Facebook, Instagram, WhatsApp) qui arrive en tête avec 29 types de données collectées. TikTok les suit de près avec 26 types de données. Et pendant ce temps, Signal se contente de… 3 types de données. Vous ne voyez pas un problème ?

Le pire dans tout ça, c’est que vos infos ne restent pas gentiment stockées dans ces apps. Non, elles sont revendues à des data brokers, ces entreprises de l’ombre qui compilent des profils détaillés sur vous et les vendent au plus offrant. On parle quand même d’un business à 434 milliards de dollars en 2025 . Vos habitudes, vos déplacements, vos achats, tout y passe…

⚠️ Chaque jour que vous attendez, c’est :

• 10 nouveaux data brokers qui récupèrent vos infos
• Des milliers de requêtes sur votre profil
• Votre vie privée vendue au plus offrant

Et le pire c’est que une fois vos données dans la nature, c’est exponentiellement plus dur de les récupérer. C’est comme essayer de remettre du dentifrice dans le tube.

Alors certes, le RGPD nous protège un peu en Europe avec le fameux “droit à l’oubli” . Mais entre nous, qui a le temps d’envoyer des demandes de suppression à des centaines de data brokers ? Surtout que ces parasites recollectent immédiatement vos données dès que vous avez le dos tourné.

La bonne nouvelle ? On peut se défendre !!

D’abord, un petit audit s’impose. Comme je vous le demandais en intro, tapez votre nom ou votre adresse sur Google et notez tous les sites qui affichent vos infos personnelles. Ensuite, direction vos comptes de réseaux sociaux pour tout passer en privé et désactiver la personnalisation publicitaire. Facebook propose même une option pour supprimer définitivement votre compte via Paramètres > Centre des comptes > Détails personnels > Propriété et contrôle du compte.

Pour Google, utilisez leur outil de suppression dédié . Il suffit de collecter les liens problématiques et de suivre les instructions. C’est relativement simple et ça marche plutôt bien pour les résultats de recherche.

Mais le vrai combat, c’est contre les data brokers. En Californie, le DELETE Act qui entre en vigueur en 2026 permettra de soumettre une demande unique de suppression à tous les courtiers enregistrés. Génial pour les Californiens, mais nous en Europe, on fait comment ?

C’est là qu’ Incogni entre en jeu 🛡️

Pour une dizaine d’euros par mois, ils s’occupent de contacter les data brokers à votre place et de faire supprimer vos données. Le service scanne en permanence des centaines de bases de données et envoie automatiquement les demandes de suppression.

Mon expérience personnelle, c’est qu’en 3 années de bons et loyaux services, ils avaient déjà supprimé mes infos de 232 data brokers différents. 232 ! Et moi qui pensais faire attention…

Mon dashboard Incogni après 3 ans : 244 demandes envoyées, 232 suppressions confirmées

Et je ne suis pas le seul convaincu car plus de 100 000 personnes utilisent déjà Incogni en Europe. Et les résultats parlent d’eux-mêmes car en moyenne, 95% des demandes de suppression aboutissent.

L’étude d’Incogni montre aussi un truc flippant : les apps de shopping sont les pires en termes de collecte de données. Aliexpress et Temu aspirent littéralement tout ce qu’ils peuvent et les apps de fitness et de santé mentale ne sont pas mieux, puisqu’elles vendent allègrement vos données les plus intimes.

Pour les vieux comptes que vous n’utilisez plus, pensez aussi à faire le ménage. Checkez par exemple votre gestionnaire de mots de passe et cherchez dans vos emails les mots-clés comme “bienvenue”, “inscription”, “compte créé”. Vous allez halluciner du nombre de services où vous êtes inscrit sans même vous en souvenir.

On peut suivre dans le détail chaque requête

Un dernier conseil, méfiez-vous particulièrement des apps gratuites et encore plus si elles ne sont pas européennes. Cette autre étude montre en effet que 88% des apps américaines et 92% des apps chinoises partagent vos données avec des tiers , contre seulement 54% pour les apps européennes. Si c’est gratuit, c’est vous le produit, comme on dit.

Sachez qu’effacer complètement sa présence en ligne est quasi impossible aujourd’hui mais avec un peu de méthode et les bons outils comme Incogni, on peut drastiquement réduire notre empreinte numérique. Entre les amendes records contre TikTok et Meta, et les nouvelles lois comme le DELETE Act, les choses bougent enfin dans le bon sens.

🔥 Offre Limitée : -55 % avec le code KORBEN55 🔥

Franchement, à un peu moins de 6 € HT / mois avec le code KORBEN55 , c’est moins cher qu’un sandwich. Et entre nous, qu’est-ce qui est le plus important, votre prochain sandwich ou votre vie privée ?

→ Cliquez ici pour en savoir plus sur Incogni ←

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.

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) datant des années 1970, et utilisé pour gérer les litiges des consommateurs sur leur crédit, tourne aujourd’hui sur une vieille version d’Apache Struts, 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 root@monserveur.com
ggh user@192.168.1.100 -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>.

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>.

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.