Salut les amis,

Aujourd'hui, c'est un jour un peu spécial pour moi, puisque c'est l'anniversaire de mon site web ! Alors je tenais à célébrer ça avec vous parce que les années filent à la vitesse de l'éclair et qu'on ne fête jamais assez les choses.

Et il s'en est passé des choses en 22 ans quand même. J'ai démarré ça comme un site perso, et qui, parce que les gens aiment bien ranger les trucs dans des cases, est devenu un "blog", puis un "média", et qui sait ce que ce sera demain...

Mais pour moi, c'est toujours mon petit bout de moi sur le web et l'objectif est toujours le même : Partager les trucs qui m'intéressent pour vous donner de quoi bidouiller à la maison ou au boulot. Toujours pas de ligne éditoriale claire, parfois de l'actu, parfois des tutos, parfois des reviews de logiciels, parfois des trucs plus perso... Peu importe tant que ça me plait.

Sachez qu'en 2025, j'ai publié environ 1300 articles sur ce site. C'est beaucoup mais moins qu'en 2011 et 2012 où j'étais à +1400 par an. Et en 2008, aïe aïe, record du monde avec +1600 articles dans l'année. C'était une époque où j'avais du temps et surtout où il se passait pas mal de choses au niveau tech. Envie de tout tester, de toucher à tout, et de tout vous raconter ! Comme aujourd'hui finalement !

Et en 2026, malgré quelques moustiques qui tentent de me faire dérailler, ça va être encore plus riche puisque j'ai délégué une partie de "l'actu fraiche" à mon ami Vincent qui fait un boulot top ! L'objectif est de me libérer un peu de temps pour à la fois mettre un point final aux combats actuels dans lesquels mon site se trouve depuis 6 mois (et dont je ne peux malheureusement pas vous parler mais ça viendra) et également avoir plus de temps pour la bidouille et les Patreons qui me soutiennent ! Je leur suis tellement reconnaissant !

Depuis 2004, tout a évolué c'est vrai. Le paysage tech a changé, les sujets d'intérêts des uns et des autres ont évolué (je l'espère pour vous ^^), et moi-même je m'intéresse à de nouvelles thématiques. En 2004 c'était comment optimiser eMule, comment installer Ubuntu et des astuces de base de registres Windows... En 2026, c'est plutôt comment faire tourner ses propres IA en locale, comment auto-héberger tel ou tel truc, ou encore comment se mettre en sécurité suite à la découverte de telle ou telle faille de sécurité...etc.

Et je sais qu'il y en a parmi vous qui sont là depuis le tout début. Vous m'avez vu changer 2 fois de CMS, je-sais-plus-combien de fois de design, plusieurs fois d'hébergeur, passer de la bannière pub omniprésente à un site sans aucune pub programmatique...etc. Vous vous reconnaitrez et cet anniversaire, c'est autant le vôtre que le mien !

Je continue aussi à vous en proposer pour tous les goûts... Des articles vulgarisés pour les débutants, des tutos plus complexes pour les gens + confirmés, et des choses qui peuvent parfois intéresser 15 000 personnes ou n'en intéresser que 4 ou 5... Peu importe. Ma boussole ce sont les retours que vous me faites par mail ou via le Patreon, et le seul filtre que je m'impose est "Est ce que ça m'intéresse ?". Parce qu'il n'y a rien de plus chiant que d'écrire sur un sujet qui ne m'intéresse pas. C'est pour ça que je ne traite pas de TOUTE l'actu tech qui passe... Je "cherry pick" comme on dit, que ce qui me plait et basta.

Et ça semble plutôt fonctionner puisque l'audience est au rendez-vous. Vous êtes en effet depuis le début de l'année entre 1,5 et 2 millions à passer ici chaque mois.

Je mets ça sur le compte de la refonte technique du site qui est + rapide, + agréable à lire (mode sombre, mode dys, etc.), sans bannière pub ni cookies publicitaires mais aussi sur l'augmentation du nombre d'articles grâce à Vincent et grâce à mes problèmes actuels qui m'empêchent de dormir et qui font que je me réfugie dans le boulot. Et il y a aussi l'arrivée des LLM qui m'ont permis de gagner du temps sur la recherche d'information, sur ma propre compréhension de certains sujets, sur des aspects plus pratiques comme la relecture, la validation des infos, la saisie des méta données, les images et j'en passe...

Grâce à ça, je fais moins d'impasses, je dis moins de conneries, je peux rentrer plus dans certains détails qui autrefois m'auraient échappé...etc. Je suis plus dans une recherche de qualité et de consistance dans mes articles que de productivité (j'sais pas si je battrai mon record de 2008 ^^). Et évidemment, ça a un impact... Des articles plus fouillés et moins fouillis, un meilleur référencement naturel et surtout, des lecteurs qui reviennent parce qu'ils découvrent des trucs.

Bien sûr, tout n'est pas parfait et ça ne le sera jamais mais je pense que j'ai trouvé un bon équilibre avec ces nouveaux outils.

Maintenant les bases restent les mêmes qu'en 2004... Un site ouvert, avec un flux RSS complet, sans paywall, sans article réservé aux abonnés, sans newsletter premium. Tout est ici, pour tout le monde, gratuit, indexable, citable. Le Patreon existe en parallèle pour celles et ceux qui veulent un peu plus (et surtout pour me soutenir directement, ce qui me touche énormément), mais 100% de ce qui est publié sur korben.info est accessible librement. C'était une évidence en 2004, et c'est resté un choix en 2026.

Alors bien sûr, tout n'est pas rose. Je sais que le site ne plaît pas à tout le monde et c'est OK. 22 ans à publier presque tous les jours, forcément ça intrigue, ça énerve, ça incite même parfois à m'inventer un vie ou des anecdotes à mon sujet. Mais bon, c'est le revers de la médaille et si tout le monde était d'accord avec moi, ce serait pas drôle. Donc tant pis pour ceux que j'irrite, et merci à ceux qui me lisent encore... y compris en cachette ^^.

Après j'ai pas de grand plan pour la suite. Pas de roadmap, pas de pivot, pas de levée de fonds, pas de série documentaire sur ma vie. Juste l'envie de continuer à faire ce que je fais depuis 22 ans : Chercher des trucs qui m'intéressent, les tester, les comprendre et vous les raconter. Et même s'il ne se passe pas une journée où je ne me pose pas la question de tout arrêter, et bien je continue parce que j'adore ça.

Merci d'être là !

Si vous utilisez le gestionnaire de mots de passe intégré à Microsoft Edge, et que vous le trouvez cool, hé bien accrochez-vous les amis, car Tom Jøran Sønstebyseter Rønning, chercheur norvégien en cybersécurité, vient de publier sur GitHub un PoC qui dump TOUS vos credentials en clair directement depuis la mémoire du processus du navigateur ! Et de ce que j'ai compris, Microsoft a l'air d'assumer ça tranquillou...

Et n'allez pas croire qu'activer "l'Authentification avant remplissage automatique" dans Edge règle le souci... Ça ne change absolument RIEN au problème, parce que les credentials sont chargés en clair en RAM dès l'ouverture du navigateur. Cette option bloque uniquement l'interface, et pas la mémoire. La seule vraie parade, c'est donc de basculer carrément vers un gestionnaire de mots de passe comme Bitwarden, KeePassXC, ou Mistikee car tant qu'ils restent verrouillés, ils ne chargent rien en mémoire.

Le PoC, baptisé EdgeSavedPasswordsDumper, tient en un seul fichier C#. Tom a choisi .NET Framework 3.5 plutôt qu'une version récente, parce que AMSI, l'Antimalware Scan Interface qui inspecte en temps réel le code .NET sous Windows, a une couverture vraiment réduite sur la 3.5 par rapport aux versions modernes. Du coup, le binaire passe plus facilement sous les radars des EDR et antivirus.

Maintenant, le truc, c'est que ce sujet n'est pas nouveau. En effet, en juin 2022, Zeev Ben Porat de chez CyberArk publiait déjà un papier détaillant exactement la même méthode appliquée à Chromium en général (et dont Edge découle...). Il utilisait les APIs Windows OpenProcess et ReadProcessMemory pour lire la mémoire privée des processus du navigateur et y récupérer URLs, logins, mots de passe et même cookies de session. Et à l'époque, Microsoft et Google avaient répondu en gros pareil, à savoir que c'était hors du "threat model", donc que c'était pas la peine de corriger.

Sauf que 4 ans plus tard, Tom Rønning n'arrivait pas à reproduire le dump sur Chrome avec la même méthode. En effet, le navigateur de Google semble charger ses credentials de façon plus granulaire (lazy loading, déchiffrement au besoin) plutôt que tout exposer en RAM dès l'ouverture. Alors que Edge, lui, n'a pas évolué et charge encore TOUS les credentials en clair dès le démarrage du navigateur, qu'on en ait besoin ou pas, et surtout les garde en mémoire tant que le processus parent tourne. Et c'est cette différence-là que Tom met en lumière avec son outil.

Après concernant la dangerosité de ce problème, faut que je nuance un peu tout ça car pour viser sa propre session Edge, l'attaquant n'a pas besoin d'être admin (un malware tournant sous votre compte y arrivera). Par contre, pour aller lire la mémoire des AUTRES utilisateurs sur la même machine, là, il faut les droits administrateur.

Et c'est surtout ce scénario que Tom met en avant dans son README. Il y parle d'un terminal server où plusieurs utilisateurs seraient connectés simultanément via RDP, et sur lequel un admin compromis pourrait dumper les mots de passe de tous les autres avec leur Edge ouvert, y compris les sessions déconnectées tant que le processus parent tourne. C'est assez spécifique quand même mais pas impossible évidemment...

Microsoft, contacté par Tom avant publication, a bien sûr répondu que le comportement était "by design"... Leur doc Edge enterprise explique même noir sur blanc que les attaques physiquement locales et les malwares sont hors du modèle de menace et qu'aucun navigateur n'est armé pour résister à un attaquant déjà infiltré dans le compte utilisateur.

C'est cohérent c'est vrai... Mais ça occulte un truc qui reste très "gênant" comme disent les ados. C'est que leur implémentation expose une surface d'attaque plus large que leurs concurrents basés sur le MÊME moteur Chromium. C'est pas normal....

Et côté communauté, ça n'a pas trainé non plus, puisque Whitecat18 sur GitHub a déjà sorti un portage Rust du PoC. C'est intéressant car Rust offre encore moins de surface AMSI que .NET 3.5 et se compile comme un binaire natif sans aucune dépendance. Donc pour un attaquant, c'est un upgrade de furtivité significatif... Et pour un défenseur, c'est surtout une raison de plus de pousser vos utilisateurs vers des vrais gestionnaires de mots de passe.

Concernant la divulgation responsable , Tom Rønning a fait les choses dans les règles : signalement à Microsoft, attente de la réponse officielle, présentation publique le 29 avril 2026 à BigBiteOfTech (l'évènement Palo Alto Networks Norway), puis publication du PoC.

Voilà... Microsoft persiste, Edge reste as-is (lumière !), et la sécurité de vos mots de passe est officiellement votre problème. Donc si vous utilisez Edge, je pense que ça vaut clairement le coup de migrer vers un gestionnaire externe... vous verrez, c'est pas la mer à boire.

Source

Jellyfin sans GPU, c'est la croix et la bannière dès que quelqu'un lance un film en 4K. Mais c'était sans compter sur ffmpeg-over-ip qui est capable de transformer un serveur équipé d'un GPU en endpoint de transcoding distant, accessible via un simple binaire qui se fait passer pour ffmpeg. Y'a pas de passthrough GPU, ni besoin de vous lancer dans la config de point de montage réseau exotique.

Le principe c'est que le client reçoit les commandes ffmpeg de Jellyfin (ou Emby), les sérialise et les envoie ensuite via TCP (port 5050) vers un serveur qui lui dispose d'un bon GPU. Et côté Jellyfin, rien ne change puisque le binaire répond exactement comme ffmpeg le ferait (et je vous rassure, y'a un peu d'authentification pour éviter de vous faire squatter votre serveur de transcoding à l'insu de votre plein gré).

Alors imaginons un peu dans quelle situation ça peut être utile... Par exemple, vous pourriez avoir un NUC ou mini-PC tout neuf qui fait tourner Jellyfin dans Docker, et à côté une vieille tour avec une GTX qui traîne dans un coin pour le transcodage. L'avantage c'est que plusieurs clients peuvent ainsi partager le même serveur GPU en parallèle, donc ffmpeg-over-ip peut valoir le coup si vous avez du matériel qui dort dans un coin.

L'outil est signé Anees Iqbal (steelbrain) et voici comment l'installer (pensez à vérifier le contenu du .sh avant) :

curl -fsSL https://ffmpeg-over-ip.com/install-client.sh | sh

ln -s ffmpeg-over-ip-client ffprobe

Vous connaissez ICON, qui imprime des maisons en béton avec ses grosses machines ? Hé bien Terran Robotics fait en fait pareil, mais avec de la terre, ou plutôt avec l'argile extraite directement du terrain. Du coup ça revient carrément moins cher.

Leur techno consiste en un robot suspendu par des câbles entre quatre tourelles dressées aux coins du chantier qui crache de l'argile. Zach Dwiel (CEO, ex-Intel) et Danny Weddle (CDO, architecte) ont développé ce système depuis 2019 et leur premier chantier est actuellement en cours.

D'abord la pince robotisée ramasse l'argile sur place. Ensuite elle la dépose couche par couche sur les murs en construction. Un outil de compactage tasse chaque dépôt, et des caméras couplées à du machine learning évaluent la qualité de la paroi en continu.

Le matériau c'est ce qu'on appelle de l'adobe . Rien à voir avec Photoshop, hein... De l'adobe c'est un mélange entre de l'argile, de la terre, de l'eau et de la paille. L'avantage c'est que tout est sourcé directement sur le terrain.

Bon, ça suppose que la terre soit suffisamment argileuse, ce qui n'est pas garanti partout, mais dans la plupart des cas ça passe. D'après l'un des inventeurs : "C'est le matériau le moins cher pour construire. Notre but c'est le logement abordable." L'adobe offre en prime une bonne inertie thermique et régule naturellement l'humidité et le son.

Source : Terran Robotics

Par contre, je vais rien leur dire mais de ce que je connais au BTP, c'est quand même pas l'idée du siècle de construire SUR un terrain argileux à cause du gonflement et de la rétractation de l'argile en période de pluie / sécheresse... Breeeef, j'suis pas sûr que j'opterai pour ça moi... Après si l'argile est récupérée plus loin, pourquoi pas...

Quoi qu'il en soit, la première maison sort au Texas, sur le campus Proto-Town, un terrain de 485 hectares près de Lockhart financé par Josh Kushner, Bill Ackman et Fred Ehrsam (co-fondateur de Coinbase).

Ce 1er chantier a 2 murs en adobe et 2 en bois seulement pour tester... Mais la prochaine maison sera réalisée 100% en terre et ils visent la construction de 20 maisons cette année. La portabilité c'est l'argument fort de cette techno car au lieu de déplacer un gros engin qui mobilise une logistique complète, tout tient dans un petit camion. Ainsi, un opérateur peut gérer plusieurs chantiers simultanément.

Comparé à de l'impression 3D béton à la ICON, le fait d'utiliser directement ce qui se trouve sur le terrain, c'est moins de capital de départ, moins de matière transportée, et surtout c'est déployable n'importe où. C'est le principe des robots à câbles parallèles (CDPR) appliqué au bâtiment... dans l'esprit des projets robotiques open source mais à l'échelle d'une maison entière !

Bref, construire avec de l'argile je trouve ça chouette car c'est quand même une méthode qui a fait ses preuves et que l'humain emploie depuis des millénaires. Mais construire sur de l'argile, j'suis moins fan. Quoi qu'il en soit, c'est une chouette invention je trouve !

Source : KXAN / Terran Robotics / Proto-Town

Deux fois plus rapide que LZ4 en décompression ?? Ah bon c'est possible ? Évidemment, quand Bertrand Lebonnois a publié zxc sur GitHub , et m'a envoyé un email pour me prévenir, j'ai été jeter un œil, surtout aux benchmarks.

Eh bien après analyse, c'est bien réel !

La philosophie de zxc est assez tranchée vous allez voir. Il s'agit d'une lib WORM (Write-Once, Read-Many) qui permet de compresser une fois lentement, à la compilation ou en CI, et ensuite de décompresser comme vous voulez des millions de fois sur les appareils de vos utilisateurs à la vitesse de l'éclair. Avec zxc, on accepte que la compression soit lente et complexe (pour trouver le bitstream parfait), afin que la décompression soit méga rapide et simple pour le processeur. C'est aussi simple que ça.

Le revers de la médaille, c'est que si vous voulez de la compression à la volée ou du streaming temps réel, ce n'est clairement pas adapté. Par contre, si vous produisez des assets une fois et qu'ensuite, vous les servez des milliers de fois, alors vous êtes exactement dans la cible.

En pratique, sur macOS M2 avec un corpus de test standard, zxc dépasse les ~12 000 Mo/s en décompression, contre ~5 600 Mo/s pour LZ4 --fast dans le même test. L'écart reste également hyper solide ailleurs : 1,8× sur ARM serveur (Google Axion) et 2× sur x86_64 (AMD).

Et l'API proposée par zxc ne s'arrête pas à un compresseur basique. En effet, un mode "seekable" permet d'accéder à n'importe quelle position d'une archive sans scanner le fichier depuis le début. Par exemple, vous packagez vos assets de jeux vidéo dans une seule archive zxc, et quand le joueur charge une texture précise, vous lisez directement le bon bloc, et pas tout le fichier.

Côté installation, c'est simple : brew install zxc sur macOS, apt install zxc sous Debian ou Ubuntu, pip install zxc-compress, npm install zxc, cargo add zxc-compress ou vcpkg install zxc sous Windows.

Des bindings officiels existent aussi pour Rust, Python, Node.js, Go et WASM et la communauté a aussi ajouté Nim et Free Pascal de son côté. Et comme c'est codé en C, y'a aucune dépendance lourde.

Sache que pour assoir la crédibilité du projet, zxc a été intégré dans lzbench et TurboBench, les deux outils de référence permettant de comparer les algos de compression. Et le paquet est déjà dispo dans les versions testing et unstable de Debian, ce qui veut dire que les mainteneurs ont validé le truc !

Bref, si vous gérez de la compression d'assets ou de firmwares dans votre pipeline, ça vaut le coup d'y jeter un oeil.

Merci à Bertrand pour l'info et chapeau pour le boulot !

Si vous utilisez Claude Code au quotidien, vous connaissez ce goût de sang qui vous monte dans la bouche lorsque, sans prévenir, cette putain de limite de quota imposée par Anthropic vous explose à la gueule ! Et le pire c'est que vous n'avez pas l'impression d'avoir fait grand chose.

En réalité, la vraie raison c'est surtout le "bruit" de toutes vos sorties shell. Un git log, un cargo test, un npm build... votre agent IA ingère tout ça comme du petit lait alors qu'il n'a besoin que d'une fraction pour comprendre ce qui se passe.

Breeef, c'est pas ouf quoi.

Heureusement pour vous RTK (Rust Token Killer) vient régler en partie ce problème. RTK c'est développé par un Français et c'est un proxy CLI en Rust qui s'intercale entre votre shell et votre agent IA, intercepte les commandes courantes et compresse leur sortie avant qu'elle n'atterrisse dans le contexte de votre agent.

Comme ça plutôt que de massacrer vos prompts ou de changer vos habitudes (et dieu sait que vous avez horreur de changer d'habitudes..lol), il attaque le bruit à la source grâce à 4 stratégies de compression : un filtrage du boilerplate, un regroupement des lignes similaires, une troncature intelligente et de la déduplication des répétitions.

Et tout ça s'intègre merveilleusement bien via un hook pour Claude Code, GitHub Copilot, Cursor, Gemini CLI, Windsurf, Cline, Codex... soit une bonne dizaine d'outils supportés !

Ainsi, votre git status devient rtk git status sans changer quoi que ce soit à vos habitudes... RTK fait tout le filtrage dans votre dos, ce qui est parfait ! C'est un outil qu'on installe et qu'on oublie.

Par exemple un git diff passe de 12 000 tokens à 960, soit 92% d'économie, un npm test tombe de 6 000 à 600 tokens et une session de refactoring sur 12 fichiers passe de 74 700 à 6 960 tokens d'après les benchmarks. En pratique, les utilisateurs constatent des économies autour de 70% sur l'ensemble d'une journée de boulot, ce qui représente plusieurs millions de tokens par semaine pour ceux qui bossent avec des agents IA à plein régime.

Moi ça fait plusieurs mois que je le teste et voici mes stats. Ça donne quand même 81,5 % d'économie de tokens !!

L'installation se fait en une commande : brew install rtk sur macOS, ou un script curl pour les autres plateformes, ou cargo install --git https://github.com/rtk-ai/rtk si vous préférez compiler ça vous-même.

Avec la commande rtk gain vous verrez un tableau comme ci-dessus avec les statistiques par commande, et rtk gain --history donnera l'historique détaillé. Y'a plus de 100 commandes couvertes, de git aux runners de tests en passant par AWS CLI, kubectl et docker. Par contre, ça marche pas super bien si vos sorties de commandes sont déjà très courtes. Ça ne fera pas de miracle mais pour des diffs volumineux ou de suites de tests qui crachent 3 000 lignes à chaque fois, c'est tip top !

Si vous utilisez des agents en mode autonome où une boucle tourne sans intervention, c'est même encore plus pertinent car chaque itération accumule du bruit de façon cumulative, et du coup le contexte se remplit de trucs inutiles à vitesse grand V. Moins de bruit grâce à RTK, c'est donc une économie de tokens mais c'est également un meilleur signal pour votre agent.

RTK est dispo en open source sur GitHub sous licence Apache 2.0.

Vous avez un service qui tourne sur le port 8080, mais aucune authentification native dessus et vous voulez ajouter OAuth2 sans avoir à toucher au code ? Vous êtes vraiment exigeant dans la vie !

Mais comme vos désirs sont des ordres, je vous présente oauth2-proxy dont c'est EXACTEMENT le boulot !

Le principe avec cet outil c'est qu'il se glisse entre l'utilisateur et votre application. Ainsi, si la personne n'est pas connectée, elle est alors redirigée vers son provider OAuth2 ou OIDC. Et une fois le token validé, popopop, la requête repart vers son point d'origine avec les infos utilisateur dans les headers HTTP. Et voilà comme votre app reçoit le nom, l'email, et les groupes associés à l'utilisateur ! Plus besoin de gérer l'auth dans votre code c'est que du bonheur !

Et la liste des providers supportés par oauth2-proxy est longue : Google (c'est celui par défaut), GitHub, GitLab, Microsoft Entra ID, Keycloak, Gitea / Forgejo, NextCloud, DigitalOcean, LinkedIn, Bitbucket, Cisco Duo... et un bon vieux client OIDC générique pour tout ce qui expose un accès standardisé. Comme ça si votre SSO interne parle OIDC, vous êtes déjà couvert !

Côté déploiement, c'est un simple binaire en Go et c'est également disponible en image Docker sur quay.io/oauth2-proxy/oauth2-proxy, pour AMD64, ARM64, ARMv6/v7, et quelques architectures plus exotiques du genre ppc64le, s390x pour les bandeurs de mainframes ^^.

Ensuite, l'outil peut fonctionner de 2 façons : Soit en proxy autonome devant votre service, ou en middleware intégré dans un reverse proxy existant comme nginx via le mécanisme auth_request. Dans ce second mode, oauth2-proxy ne fait en réalité que vérifier la session et répondre du code 202 ou 401. C'est nginx qui gère le routage et le proxy lui se contente d'authentifier les gens.

Et voilà, si vous cherchez à minimiser la surface d'attaque, c'est la config à privilégier. Tout est là : github.com/oauth2-proxy/oauth2-proxy , avec la doc complète. Et si vous cherchez quelque chose de plus intégré, avec tunnel et gestion des tunnels VPN en prime, il y a aussi Pangolin dont je vous ai parlé. Et pour du plus simple en contexte Docker, TinyAuth fera également très bien le taf.

Merci à Mathieu Passenaud pour le lien !

Comme vous le savez, les LLMs sont assez probabilistes de par leur nature. C'est leur force mais également leur principal problème de sécurité car si votre agent IA a une probabilité de 1% de faire une grosse connerie des enfers par session, sur 100 sessions vous montez à environ 63% de chances qu'il en arrive au moins une.

Heureusement, Agent Safehouse vous permet d'encapsuler votre agent préféré dans un profil sandbox macOS au niveau du kernel afin de réduire drastiquement la surface d'attaque sur votre système de fichiers.

Le principe de base, c'est le deny-default. Tout est refusé par défaut puis des autorisations sont ensuite ouvertes au compte-gouttes : lecture/écriture dans le répertoire du projet, accès lecture seule aux toolchains installés, et les exceptions système nécessaires au fonctionnement (runtimes, homebrew, réseau).

Par défaut, les clés privées SSH et les fichiers de credentials AWS ne sont pas lisibles donc si l'agent essaie d'accéder à ~/.ssh, il se prend une erreur "operation not permitted". C'est une couche de durcissement mais pas une barrière de sécurité absolue puisque le réseau, lui, reste ouvert par défaut, et des variables d'environnement peuvent encore exposer vos credentials. Mais pour tout ce qui est erreurs accidentelles et autres hallucinations destructrices en mode Claude a fumé la moquette, ça permet de leur couper la chique.

Cela repose sur le mécanisme sandbox-exec , l'outil natif macOS qu'Apple a fini par marquer "deprecated" sans vraiment le retirer. Agent Safehouse s'en sert tout simplement comme fondation et y ajoute de la configuration par profil et les intégrations agents par dessus.

Sandbox-exec est en effet le seul mécanisme natif macOS qui s'applique en wrapper arbitraire depuis la ligne de commande, sans avoir besoin de se taper un setup préalable comme on pourrait le faire avec Docker ou une VM.

Et c'est surtout plus léger et plus pratique pour un usage au quotidien donc si vous faites tourner Claude Code ou Codex plusieurs heures par jour, ça peut servir, au moins pour votre tranquillité d'esprit.

L'installation se fait via Homebrew comme ceci :

brew install eugene1g/safehouse/agent-safehouse

safehouse claude --dangerously-skip-permissions

Hier soir Lilian, fidèle lecteur de Korben m'a envoyé une vidéo incroyable qui retrace 5h de combat sur Age of Empires 2 résumées en 34 minutes par TheGreatReview.

Faut savoir que je suis fan d'Age of Empires depuis le premier épisode de 1997 . AoE 1, 2, Mythology, AoE 3... j'ai laissé un nombre indécent d'heures sur ces titres, donc forcément, voir ces longues heures de matchs condensées en chouette récit, ça ravive de vieux souvenirs !

BrowserQuest est de retour les amis ! Hé ouais, el famoso MMO HTML5 que Little Workshop avait pondu pour Mozilla en 2012 vient de ressurgir sur threej.in , alors que Mozilla avait officiellement archivé le repo GitHub en janvier 2024.

En allant sur ce lien, vous choisissez le nom de votre personnage, et hop, vous vous retrouvez comme y'a plus de 10 ans, dans un monde 2D en pixel art prêt à vous taper avec des rats et des squelettes direct dans le navigateur.

Petit rappel pour les endormis du fond à côté du radiateur, quand BrowserQuest est sorti en mars 2012, c'était un événement !! Mozilla voulait avec ce jeu, montrer au monde entier que le navigateur pouvait faire tourner un MMO temps réel sans Flash, sans aucun plugin, mais juste avec du HTML5 et des WebSockets. Le studio parisien Little Workshop (les frères Guillaume et Franck Lecollinet) avait alors livré une démo incroyable qui ressemblait à un Zelda 16 bits, avec des quêtes, de l'équipement, un chat intégré et même du combat coopératif. Comme je suis viiieux de fous, je vous en avais même parlé à l'époque .

Car techniquement, c'était du sérieux... Canvas pour le rendu 2D, Web Workers pour charger la map sans freezer la page, localStorage pour sauvegarder votre perso, CSS3 Media Queries pour s'adapter au mobile, et surtout WebSockets pour la communication bi-directionnelle avec le serveur Node.js.

Du coup le jeu pouvait encaisser des CENTAINES de joueurs simultanés, avec un pic réel enregistré à plus de 1 900 connexions en même temps. C'est ouf ! Faut dire que 2 ans plus tôt, Quake 2 tournait déjà en HTML5 et on commençait alors tous à comprendre que notre navigateur allait devenir une véritable plateforme gaming.

Sauf que voilà, Mozilla n'a jamais vraiment maintenu BrowserQuest après le buzz initial. Le serveur officiel browserquest.mozilla.org a fini par mourir, le repo GitHub a basculé en mode DEPRECATED, et en janvier 2024, la fondation a appuyé sur le bouton "Archive" pour de bon. Fin du game ! Sniiiif...

Sauf que le code est sous licence MPL 2.0 et le contenu en CC-BY-SA 3.0 donc en gros, n'importe qui peut reprendre le bousin, le réhéberger et le relancer !

Hé bien c'est exactement ce que threej.in a fait et ça fonctionne parfaitement, y compris l'aspect multijoueur. L'écran de crédit affiche même encore "Made for Mozilla by Little Workshop" comme si rien n'avait bougé.

Perso, je trouve ça cool qu'un projet open source archivé aussi culte puisse continuer à vivre grâce à un inconnu qui a pris la peine de le remettre en ligne. C'est aussi à ça que servent les licences libres finalement... prolonger la vie des programmes au-delà de la motivation de leurs créateurs. Chouette hein ?

À l'époque, encaisser 1900 joueurs en simultané sur un backend Node.js relevait de la prouesse technique, alors qu'aujourd'hui, tout semble beaucoup plus facile puisqu'on trouve des dizaines de jeux .io et autres qui tournent dans un onglet de browser sans que ça nous fasse lever un sourcil. La techno derrière BrowserQuest est devenue tellement banale qu'on a tous oublié à quel point elle était impressionnante à l'époque !

Bref, c'est gratuit, c'est dans le navigateur, et ça tient toujours debout !

À découvrir ici !

Quand j'achète un truc avec ma CB, c'est vrai que j'évite maintenant de demander le ticket de carte bancaire. Ça ne me sert à rien, et puis j'en fais quoi après ? Je le jette à la poubelle ?

Heureusement qu'il n'y a pas de données confidentielles dessus et que tous les chiffres de ma CB sont masqués avec des petites étoiles sauf une partie, généralement les 4 derniers, qui sont en clair évidemment.

Bref, tout roule, nan ? Hé bien noooon, parce que Metin Ozyildirim, un chercheur en sécurité, vient d'expliquer sur son site comment ces étoiles en fait c'est pas vraiment un secret.

En fait, quand vous effectuez un achat en ligne, le marchand pose une question à votre banque pour valider la carte, du genre "hey Crédit Agricole, est-ce que ce numéro existe ?" et la banque répond connement oui ou non.

Et le souci c'est que cette question, n'importe qui peut la poser depuis n'importe où dans le monde, en testant des numéros au pif jusqu'à tomber sur le bon. C'est ce qu'on appelle du brute force, et avec une bonne machine et une connexion correcte, ça permet de tourner tranquillement à la fréquence de 6 tentatives par seconde, soit environ 130 000 essais possibles étalés sur une nuit. C'est donc très largement assez pour reconstituer les chiffres manquants quand on n'en a que 6 à deviner.

Et surtout, il arrive parfois que le marchand soit un peu trop bavard. Par exemple si vous tapez un mauvais numéro, il vous répond "Cette carte de crédit n'est pas valide". Si la date d'expiration est fausse, il vous dit gentiment "Cette carte a expiré". Et si le CVV est faux ? "Le code CVV n'est pas correct".

Comme le dit Metin dans son post, ce genre d'indice aide carrément à bruteforcer les infos de la CB. Bah oui, si le marchand vous confirme noir sur blanc que vous êtes à 3 chiffres près du jackpot, pourquoi s'arrêter hein ? C'est un peu comme dans ces films où y'a un gars qui braque un coffre-fort qui fait "clic" à chaque bon chiffre.

Et comme ça donc que Metin Ozyildirim s'est fait piller son compte bancaire il y a environ 1 an. L'attaquant a fait tourner son bruteforce comme ça durant 6 heures, en répartissant ses requêtes sur plusieurs sites e-commerce différents pour passer sous les radars.

Et une fois la carte complète reconstituée, restait plus qu'à dépenser le pognon ! Et là pareil, certains marchands acceptent encore les paiements sans demander la double authentification 3D Secure. Ces marchands là, ce sont eux qui payent en cas de fraude, car ils prennent le risque. L'attaquant a juste eu à choisir un de ces marchands "hack-friendly", et a transféré l'argent vers un porte-monnaie électronique, qu'il a ensuite converti en cash.

Et voilà comment le plafond de la carte de Metin était à zéro avant qu'il ait terminé son premier café du matin !

La bonne nouvelle, c'est que la banque l'a remboursé. Par exemple en France, vous avez 13 mois pour contester une transaction frauduleuse via votre banque. C'est un droit et pas une faveur hein ! Mais si la banque considère que vous avez été négligent (carte prêtée, code partagé, phishing évident...etc), elle peut tout à fait refuser le remboursement, donc gardez des preuves et contestez vite !

Maintenant, la mauvaise nouvelle, c'est que ce qui est arrivé à Metin est de plus en plus fréquent. Visa a même documenté que ce genre d'attaques explose, et que la majorité des sites e-commerce sont mal protégés contre ce genre de bots qui font tourner ces scripts de bruteforcing.

Bref, y'a pas grand chose à faire de notre côté pour nous protéger de ça, si ce n'est d'activer les notifs de notre banque sur chaque transaction, configurer le plafond le plus bas possible (sans que ce soit gênant), et quand votre banque vous propose une carte virtuelle à usage unique pour les achats en ligne, n'hésitez pas à l'utiliser.

Et la prochaine fois que vous laisserez traîner un reçu de CB sur la table d'un resto, dites-vous que vous offrez peut-être un accès à votre compte au prochain margoulin qui passe !

Source

Hello les amis, voici ma petite trouvaille du jour, idéale pour ceux qui jouent en ce moment avec des adresses IP : ip66.dev . C'est une base de géolocalisation IP et entièrement libre, livrée au format MMDB (le même que celui de MaxMind) qui permet de remplacer direct un fichier GeoLite2 dans vos libs existantes (Python, Go, Node.js), sans toucher au code.

L'équipe de Cloud 66 maintient cette liste à jour sous licence CC BY 4.0 et tout est utilisable simplement en récupérant le fichier mmdb.

Pour le télécharger :

curl -LO https://downloads.ip66.dev/db/ip66.mmdb

go install github.com/maxmind/mmdbinspect/cmd/mmdbinspect@latest
mmdbinspect -db ip66.mmdb 8.8.8.8

Flash à sa grande époque c'était quand même tout un truc, mais est-ce que vous vous souvenez de Shockwave ? Le grand frère de Flash (techniquement c'était une autre techno bâtie sur Director mais bref...), qui était capable de faire tourner des trucs bien plus complexes que les vieux .swf ?

Et ben l'équipe derrière DirPlayer s'est tapé tout le reverse-engineering du moteur Director from scratch pour le ressusciter grâce à Rust et le rendre à nouveau fonctionnel dans nos navigateurs modernes !

Faut savoir qu'Adobe a débranché Shockwave Player en avril 2019 et Flash un peu plus tard, et avec eux c'est un pan entier du web rétro qui s'est retrouvé inaccessible du jour au lendemain. Du genre tous ces jeux qui tournaient sur Shockwave.com ou les vieux portails de mini-jeux des années 2000, paf, d'un coup plus moyen d'y rejouer.

Alors heureusement, pour Flash, y'a déjà Ruffle qui fait tourner les bons vieux .swf. Hé bien ici c'est le même principe avec DirPlayer pour les .dcr Shockwave.

L'outil se décline sous 3 formes. D'abord une extension Chrome qui détecte automatiquement les balises Shockwave qui traînent encore sur les vieux sites web, ce qui peut être sympa pour redécouvrir des sites des années 2000.

Y'a aussi une version standalone construite avec Electron qui embarque carrément un debugger Lingo (le langage de scripting de Director, super pratique si vous voulez bidouiller du contenu existant). Et enfin un polyfill JS auto-contenu qui réécrit les et directement sur votre site web.

Perso, pour vous faire une idée, je vous invite surtout à jeter un oeil à la démo web pour tester rapidement parce qu'il n'y a rien à installer. Mais dès que vous voudrez analyser ou debugger un vieux jeu en profondeur, faudra plutôt opter pour la version standalone.

Notez que DirPlayer utilise Ruffle en submodule Git donc les 2 projets sont liés et bonus côté sécurité, le tout tourne en WebAssembly avec le sandboxing du navigateur, donc y'aura plus toutes ces failles qu'on pouvait retrouver à l'époque sur l'ancien plugin Shockwave Player.

Pour les sites qui hébergent encore des applis ou des jeux Shockwave (genre archive.org, avec des musées interactifs ou des jeux des années 2000), c'est une nouvelle corde à leur arc. Et si vous avez de vieux .dcr planqués sur un disque dur, la démo web devrait pouvoir les avaler aussi (faudra tester quoi...).

Bref, grâce à Ruffle pour Flash et DirPlayer pour Shockwave, le web des années 90-2000 n'est pas encore tout à fait mort ! Un peu comme moi finalement ^^

Vous vous souvenez de l'époque où on s'écroulait comme des merdes dans notre canapé après une grosse journée de boulot et où on regardait juste ce que la télé nous balançait ? Pas de choix à faire sur Netflix, ni de recommandation sur l'Apple TV. On zappait juste en mode no-brain jusqu'à ce qu'on tombe sur une connerie qui réveille notre cerveau reptilien.

Eh bah le dev Chris Benincasa a créé Tunarr , un soft open source qui ressuscite ce truc-là en transformant votre Plex ou Jellyfin en chaîne de TV en continue.

Grâce à Tunarr, vous configurez vos chaînes dans une interface web (en glisser-déposer...), le soft émule un tuner HDHomeRun (le standard de la TV réseau aux US), que Plex, Jellyfin ou Emby reconnaissent ensuite comme une vraie source TV. Et voilà comment vous avez maintenant votre propre antenne maison.

Ou alors vous exportez en M3U pour des players IPTV comme Tivimate ou UHF, le tout avec un EPG intégré (c'est le guide des programmes), des bumpers (vous savez ces petites séquences Tchii Tchaaa ou M6 Mhmmmh des chaînes TV), des pubs vintage entre les programmes et même des clips musicaux pour faire authentique.

Bref, du déjà-vu, mais avec votre catalogue d'émissions à vous.

docker run -d -p 8000:8000 -v ./tunarr-data:/config/tunarr chrisbenincasa/tunarr:latest

Ouais, je sais, on est le 1er mai, et je suis pas censé bosser mais que voulez-vous on ne se refait pas ^^. Et si j'ai ouvert l'ordi ce matin, c'est pour vous parler de KULA !

KULA est un binaire tout simple qui permet de monitorer très facilement votre serveur Linux en temps réel, sans aucune dépendance. c0m4r , le dev derrière le projet, l'a codé en Go avec une obsession claire : Que ça marche partout sans rien installer à côté !

C'est vrai que les outils de monitoring temps réel sur Linux ont tendance à grossir avec le temps. Netdata est passé par exemple d'un script léger à une plateforme SaaS.

KULA veut faire exactement l'inverse ! Parce que si vous avez un VPS à 5 balles, un Raspberry Pi ou trois homelabs qui ronronnent dans le placard, c'est pas la peine de sortir un bazooka quand il y a ce petit binaire qui fait tout aussi bien.

Vous le posez sur la machine, vous lancez ./kula, et c'est plié ! Il y a même un installeur guidé en une commande (nia nia nia lisez le contenu du .sh avant de le lancer, nia nia nia, je me répète, je sais):

bash -c "$(curl -fsSL https://raw.githubusercontent.com/c0m4r/kula/refs/heads/main/addons/install.sh)"

Côté technique, le projet va chercher ses infos directement dans /proc et /sys toutes les secondes. Comme ça y'a pas besoin d'un programme "agent" séparé à installer, ni besoin de vous lancer dans du scraping HTTP. C'est juste KULA qui tourne en daemon et qui lit ce qui se passe au niveau du kernel.

Les données passent ensuite dans un moteur de stockage maison : un ring-buffer avec trois niveaux (1 seconde brut, 1 minute agrégé, 5 minutes agrégé), chacun ayant une taille max fixe (250 Mo, 150 Mo, 50 Mo par défaut). Et quand la limite est atteinte, les nouvelles données écrasent les vieilles. Comme ça l'usage disque est maîtrisé, et y'a pas besoin de faire de ménage.

Niveau métriques, c'est plutôt complet je trouve... CPU, GPU (VRAM, charge, conso), mémoire, swap, load average, processus par état, températures CPU/GPU/disque, batteries, entropie système, sync horloge. Le réseau remonte les débits par interface, les paquets par seconde, les erreurs, les drops, les retransmissions TCP, les connexions établies...etc.

Et côté disque c'est par composant : IOPS, lectures/écritures par seconde, octets/s, plus l'usage des systèmes de fichiers. Et bien sûr tout ce qui est containers Docker, podman, et même ces cgroups bruts dont vous êtes si fiers ^^, pour ceux qui font tourner des trucs sans Docker.

Et le truc auquel je ne m'attendais pas mais que j'aurais pu anticiper parce que c'est à la modeuuuuh, c'est l'assistant IA via Ollama. Vous configurez une instance Ollama locale, et le dashboard vous laisse causer à un modèle de votre choix qui peut analyser les courbes en cours, exporter du CSV par graphique, et même faire appel à une fonction get_metrics pour interroger les données en mode agent.

Tout ça en local bien sûr. C'est plutôt sympa pour debugger par exemple un pic de CPU récurrent à 3h du matin sans devoir vous taper des heures de graphes !

Le déploiement Docker c'est comme ça :

docker run -d --name kula --pid host --network host
 -v /proc:/proc:ro -v kula_data:/app/data c0m4r/kula:latest

Notez le paramètre --pid host et /proc:/proc:ro : car KULA a besoin de voir l'hôte et pas le container.

Bah ouais, c'est logique, sinon il va monitorer juste son propre container, ce qui n'a aucun intérêt, hein...

Notez que si vous êtes sur un VPS LXC mutualisé bas de gamme, certains hébergeurs restreignent l'accès à /proc du host... et là, malheureusement, KULA ne pourra remonter que ce qu'il voit ce qui est souvent pas grand-chose... sniiif.

Pour les puristes, y'a aussi des paquets .deb, .rpm, AUR pour Arch, et du multi-arch (amd64, ARM, RISC-V). Ça couvre à peu près tout ce qui se croise sur un homelab !

Et côté auth, c'est désactivé par défaut (le port par défaut est le 27960, pas le 80), mais quand vous l'activerez vous tomberez sur de l'Argon2id avec des jetons de session hashés en base.

Par contre, même si y'a quelques alertes internes (clock sync, low entropy, overload), vous n'aurez pas de notifications natives (pas de mail, ni Slack, ni webhook...etc). Et pas de support multi-node non plus puisque KULA monitore une machine à la fois.

Donc si vous avez 30 serveurs, faudra vous farcir 30 instances et 30 dashboards séparés. Pas glop ! Et bien sûr, c'est Linux only parce que tout repose sur /proc et /sys.

C'est encore un projet un peu jeune, donc à voir comment ça vieillit mais pour votre petit VPS perso d'amour ou une machine dans un setup d'auto-hébergement , c'est top pour esquiver à la fois htop qui est trop minimaliste et Grafana qui est trop usine à gaz.

Si vous voulez voir la démo, y'en a une ici : demo.kula.ovh !

Source

Vincent en avait parlé il y a peu : Firefox 149 embarque maintenant discrètement adblock-rust , le moteur Adblock de Brave, désactivé par défaut et contrôlé uniquement par deux prefs dans about:config.

A l'origine, je vous avais parlé d'une extension mais après analyse plus approfondie, celle-ci n'est pas vraiment nécessaire. Y'a juste deux valeurs à coller dans about:config et le moteur tourne. Merci donc à François qui m'a indiqué cette méthode directe.

Étape 1 : Activer le moteur

Dans la barre d'adresse, tapez about:config et acceptez l'avertissement. Cherchez la préférence suivante :

privacy.trackingprotection.content.protection.enabled

Passez-la à true. Si elle n'existe pas encore dans votre profil, créez-la : clic droit quelque part dans la liste → Nouveau → Booléen.

Étape 2 : Charger vos listes de filtres

Cherchez ensuite cette seconde préférence :

privacy.trackingprotection.content.protection.test_list_urls

Collez-y la valeur suivante, toutes les URLs séparées par des pipes :

https://easylist.to/easylist/easylist.txt|https://easylist.to/easylist/easyprivacy.txt|https://secure.fanboy.co.nz/fanboy-cookiemonster.txt|https://raw.githubusercontent.com/uBlockOrigin/uAssets/refs/heads/master/filters/annoyances-others.txt|https://raw.githubusercontent.com/AdguardTeam/FiltersRegistry/master/filters/filter_2_Base/filter.txt|https://raw.githubusercontent.com/uBlockOrigin/uAssets/refs/heads/master/filters/filters.txt|https://raw.githubusercontent.com/AdguardTeam/FiltersRegistry/master/filters/filter_3_Spyware/filter.txt|https://pgl.yoyo.org/adservers/serverlist.php?hostformat=adblockplus&showintro=1&mimetype=plaintext

Ça couvre 8 listes : EasyList, EasyPrivacy, Fanboy Cookie Monster, uBO Annoyances (les 4 de base), plus uBO Filters, AdGuard Base, AdGuard Tracking et Peter Lowe. Si vous voulez un profil plus léger, vous pouvez supprimer des URLs avant de coller.

Petite note : le préfixe test_ dans le nom de cette pref indique que la feature est encore expérimentale dans Firefox 149. Les noms peuvent donc changer dans une version future.

Désactiver ETP (optionnel mais recommandé)

La protection contre le pistage intégrée de Firefox (ETP) et adblock-rust filtrent chacun de leur côté. C'est redondant. Pour désactiver ETP, allez dans about:preferences → Confidentialité et sécurité → Protection renforcée contre le pistage → cochez "Personnalisée", puis décochez tout ce que vous voulez confier à adblock-rust.

Limitation actuelle : adblock-rust ne gère pas encore les sélecteurs CSS de masquage d'éléments, les règles ## du style uBlock Origin. Brave les supporte déjà, Firefox devrait suivre. En attendant, quelques pubs que uBO cachait via CSS resteront visibles.

Pour le contexte technique complet sur l'intégration de ce moteur, allez lire l'article de Vincent sur l'arrivée discrète d'adblock-rust dans Firefox 149 . Et si vous voulez un guide général pour bloquer les pubs et trackers sur le web , c'est par là.

Merci à François pour la méthode et la liste de filtres !

Felix "FX" Lindner est mort le 1er mars 2026 à l'âge de seulement 49 ans. Et si ce nom ne vous dit rien, c'est normal, car FX n'a jamais cherché les projecteurs. Par contre, ceux qui bossent dans la cybersécurité, eux, savent parfaitement qui il était.

Fondateur de Recurity Labs à Berlin, leader du groupe Phenoelit, co-auteur de "The Shellcoder's Handbook", et lauréat du Pwnie Award Lifetime Achievement 2017, Félix avait plusieurs casquettes. Et c'est également celui qui a forcé Huawei à créer une équipe de sécurité dédiée, tout ça grâce à une seule présentation de 45 minutes.

Felix "FX" Lindner, fondateur de Recurity Labs (CCS 2013)

Son pseudo sur Twitter/X c'était @41414141 car en hexadécimal, 0x41 c'est le caractère ASCII 65, la lettre "A". Car 4 "A" d'affilée, c'est le padding classique qu'on balance dans un buffer overflow pour écraser la mémoire. Hé oui même son pseudo était un exploit ! Petit détail au passage : ne le confondez pas avec "fefe", Felix von Leitner, l'autre Felix célèbre de la scène sécu germanophone. La confusion est fréquente, même dans les hommages post-mortem que j'ai pu voir.

Pour comprendre FX, faut remonter à 1977, à Berlin-Est, le côté soviétique du Mur. Gamin, il met les mains sur son premier ordinateur à 6 ans, lors d'une visite à l'Université de Sofia en Bulgarie puis à 10 ans, il programme en BASIC sur un Robotron Z9001 (un CPU U880 à 2.5 MHz, 16 Ko de RAM), qui était à l'époque la machine phare de la RDA (en fait c'était un des rares ordinateurs personnels fabriqués en Allemagne de l'Est). Pas exactement un Commodore 64 donc, mais bon... on fait avec ce qu'on a quand on grandit derrière le Rideau de fer.

Le Robotron Z9001, ordinateur est-allemand sur lequel FX a fait ses premières armes (Wikimedia Commons)

Et puis le Mur tombe.

En novembre 1989, FX a 12 ans et dans les décombres institutionnels de l'Allemagne de l'Est, il découvre un truc improbable : un club informatique rattaché à l'Organisation des Pionniers Ernst Thälmann, le mouvement de jeunesse du régime est-allemand (dissous quelques mois plus tard). C'est là qu'il croise ses premiers hackers, des gamins comme lui, curieux, qui bidouillent sur du matériel en voie de disparition.

Faut dire que Berlin dans les années 90, c'est un sacré terrain de jeu. Le Chaos Computer Club est déjà une institution, les loyers sont bas, l'énergie est dingue. Du coup, FX baigne là dedans tel un enfant de la Réunification, en quelque sorte.

Et c'est au tournant des années 2000, qu'il fonde Phenoelit, un groupe de recherche en sécurité basé à Berlin. Leur spécialité ? Les trucs que personne ne pense à auditer, parce que tout le monde part du principe que c'est sécurisé. Routeurs Cisco, imprimantes HP, systèmes SAP, BlackBerry RIM... tout y passe. Phenoelit, c'est de la recherche bas niveau et du reverse engineering pur et dur.

FX publie alors des outils qui deviennent des classiques. cd00r.c d'abord, une backdoor furtive qui n'ouvre AUCUN port en écoute. Le concept est trop fort puisque la machine écoute discrètement tout le trafic réseau qui passe et ne déclenche un /bin/sh que si elle voit passer un paquet "magique" porteur d'une signature codée en dur. Pas de port ouvert, pas de service à scanner, mais juste un guetteur silencieux qui réagit au bon mot de passe. Le concept inspirera plus tard le port knocking grand public.

Ensuite IRPAS (Internetwork Routing Protocol Attack Suite), un kit complet pour tester les protocoles de routage réseau. CDP, IRDP, HSRP... ces langages que les routeurs utilisent pour se causer entre eux et que personne n'avait sérieusement attaqués avant lui. Tellement utile que la suite finit intégrée dans Debian et Kali Linux. Et puis Ultima Ratio, un exploit remote code execution (RCE) pour Cisco IOS, présenté à la DEFCON.

FX avait un vrai don pour trouver les failles là où personne ne regardait.

Mais l'outil le plus connu du grand public, c'est la Default Password List. Une base de données des mots de passe par défaut de la quasi-totalité des équipements réseau du marché. Routeurs, switchs, imprimantes, caméras... pratiquement tous les pentesteurs de la planète l'ont utilisée au moins une fois. Elle a même fini dans SecLists, la bible du domaine.

Mais FX ne se contentait pas d'attaquer.

En 2010, il développe Blitzableiter (littéralement "paratonnerre" en allemand), un outil anti-exploitation Flash. En gros, ça analyse et reconstruit les fichiers .swf pour neutraliser les malwares, sans se baser sur des signatures CVE. Lors de sa démo à Black Hat USA et DEFCON 18, il balance alors 20 malwares Flash en live et 20 sur 20 bloqués. A une époque où Flash était LE vecteur d'attaque sur le web, c'était du lourd.

Quelque part avant 2007, FX lance Recurity Labs à Berlin. Audit de code C/C++, ingénierie inverse ARM et x86, architecture sécurisée... Il est rejoint par 12 consultants, chacun avec au moins dix ans d'expérience. Pas de marketing flashy, pas de bullshit corporate mais du boulot bien technique, et c'est tout.

FX décroche même un titre de Technicien Informatique Agréé et une certification CISSP, mais bon... c'est pas vraiment pour les diplômes qu'on le connaissait. C'était plutôt pour sa capacité à démonter n'importe quel système et expliquer clairement ce qui merdait dedans.

À partir de 2001, il enchaîne alors les conférences. DEFCON 9, puis 10, 11, 12, 14, 16, 17, 18... Black Hat USA, Abu Dhabi, HITB en Malaisie, PacSec, CanSecWest, Hashdays. Bref, chaque année un nouveau sujet, un nouveau système disséqué. En 2008, c'est le BlackBerry et en 2011, c'est Stuxnet et les systèmes industriels. Il n'est jamais à court de cibles.

Nous sommes maintenant le 11 octobre 2012, à Hack in the Box, Kuala Lumpur. Il y fait une chaleur étouffante, et les hackers du monde entier sont entassés dans l'InterContinental pour une conf qui attire le genre de types qui ne peuvent pas présenter leurs travaux ailleurs (car certains risquent l'extradition).

FX monte alors sur scène avec son sujet : "Hacking Huawei VRP".

VRP, c'est Versatile Routing Platform, le firmware des routeurs Huawei AR et NE. En gros, l'équivalent de Cisco IOS 12.x côté chinois et FX l'a bien sûr totalement disséqué.

Ce qu'il montre alors est accablant. Les routeurs Huawei utilisent des mots de passe statiques par défaut et un seul équipement compromis donne accès à TOUT le réseau. Y'a de quoi s'arracher les cheveux. Ce qu'il dit lors de sa conf résume tout : "Je ne sais pas s'il y a des backdoors, mais ça n'a aucune importance vu le nombre de vulnérabilités."

Et la réaction de Huawei ?

Hé bien pour une fois, plutôt correcte. John Suffolk, leur chef cybersécurité mondial, envoie une équipe d'ingénieurs rencontrer FX directement. Le géant chinois renforce alors son Product Security Incident Response Team (PSIRT, qui existait depuis 2005 mais restait peu visible) et publie des procédures de contact lisibles pour les chercheurs externes. FX racontera plus tard qu'ils ont tenu parole. C'est sa présentation qui a recalibré les pratiques de sécurité d'un des plus gros équipementiers télécoms de la planète.

Puis le 29 décembre 2013, 23h15, Saal 1 du 30e Chaos Communication Congress à Hambourg, FX est dans son élément et cette fois son sujet c'est "CounterStrike: Lawful Interception".

Le 30e Chaos Communication Congress, Hambourg, décembre 2013 (Wikimedia Commons)

L'interception légale, c'est cette fonctionnalité imposée aux fournisseurs d'accès Internet pour permettre la surveillance judiciaire. En clair... une backdoor officielle implantée dans les routeurs. Alors lors de sa conf, FX démontre que ce mécanisme viole le principe fondamental d'un routeur, à savoir transférer les paquets sans fouiller dans leur contenu, et crée ainsi une surface d'attaque massive.

Sa conclusion c'est que contourner la surveillance légale, c'est aussi facile que de tromper un antivirus. Pour lui, les backdoors "légales" ne protègent personne et fragilisent tout le monde. On est 6 mois après les révélations Snowden, et ce que FX démontre techniquement donne encore plus de poids au débat.

Snowden avait sorti les documents. FX en explique la mécanique.

Dans une interview au magazine Ethik und Militär en 2014, FX livrait surtout des opinions tranchées. Il est favorable aux capacités offensives étatiques comme complément aux défenses, mais également hyper critique du manque de responsabilité des éditeurs de logiciels, et pessimiste sur la place de l'Allemagne dans le secteur informatique. C'est pas le genre à tourner autour du pot.

Ceux qui l'ont côtoyé se souviennent également des soirées tardives, après les talks. À l'Alexis Park de Las Vegas, dans les bars de Kuala Lumpur, ou dans les clubs de Berlin, FX était de ceux qui restaient jusqu'au bout.

En 2007, il co-écrit "The Shellcoder's Handbook: Discovering and Exploiting Security Holes" avec Chris Anley, John Heasman et Gerardo Richarte. Un bouquin devenu référence pour quiconque s'intéresse à l'exploitation de vulnérabilités. Dans le milieu, c'est un classique.

Et en 2017, ses pairs lui décernent le Pwnie Award for Lifetime Achievement à la Black Hat de Las Vegas. Les Pwnie Awards, c'est un peu les Oscars du hacking, attribués par un jury de pointures (Travis Goodspeed, Charlie Miller, Katie Moussouris...). Recevoir le Lifetime Achievement, c'est la reconnaissance ultime de la communauté... Du beau monde, pour un prix super mérité.

Puis le 2 mars 2026, Nico Lindner et l'équipe de Recurity Labs publient un court message sur recurity-labs.com : "With heavy hearts, we announce that Felix 'FX' Lindner, a cherished friend, and the founder and owner of Recurity Labs, passed away on 2026-03-01."

FX nous a quittés.

Les hommages affluent alors immédiatement. Daniel Cuthbert, figure historique de l'infosec, écrit sur X : "Everyone today is a hacker in a sense but there are very few OG hackers on which shoulders we stand. Oh dude, Felix 'FX' Lindner you were so much a hackers hacker and you will be missed. RIP my friend and thank you."

Andrea Barisani, Federico Kirschbaum, des dizaines d'autres... Tous disent la même chose. FX était un vrai, quoi. Pas un influenceur sécu sur LinkedIn, pas un conférencier professionnel qui récite des slides. Mais un vrai type qui comprenait les systèmes en profondeur et qui partageait ce qu'il savait.

Felix "FX" Lindner laisse derrière lui des outils que les pentesteurs connaissent et utilisent encore, un livre que les étudiants en sécu continuent de lire, et une boîte qui continue de tourner...

Source | Wikipedia

Hier soir, je suis tombé sur GameDate et ça m'a carrément fait remonter 20 ans en arrière, à cette époque bénie l'époque où on passait toutes nos nuits sur des jeux comme Wolfenstein: Enemy Territory ou Tribes 2 sans que personne ne nous juge bizarrement. Ce site pour le moins original permet d'organiser des sessions multijoueurs pour tous les jeux que tout le monde a oubliés.

D'abord vous arrivez sur le site, ensuite vous voyez les sessions programmées par d'autres joueurs, vous cliquez sur "interested" pour celles qui vous tentent, et le jour J vous lancez le jeu pour rejoindre les autres. Chaque session affiche 2 compteurs, le nombre d'intéressés et un "expected" pondéré, histoire d'avoir une vraie idée de la fréquentation au lieu d'arriver dans un serveur fantôme.

Et si rien ne vous convient, vous pouvez créer votre propre session en quelques clics sans avoir besoin de vous créer un compte. C'est très appréciable et en parcourant le catalogue, je suis tombé sur des pépites que je croyais définitivement enterrées.

Je pense à Halo 2, Phantasy Star Online, Tribes: Ascend, Rainbow Six: Raven Shield, Total Annihilation, Worms Armageddon, GoldenEye: Source, NEOTOKYO ou Sven Co-op...etc.

La liste tourne autour de 90 jeux et continue de grandir (qui a dit CMB ?). Y'a même du Mario Kart Wii et du Mario Party en netplay pour les nostalgiques de Nintendo, du F.E.A.R. Combat pour les fans de tir tactique et toute une section pour les mods Source comme Hidden: Source ou Eternal Silence.

Après, certaines sessions du catalogue affichent "no interest" parce que personne n'a cliqué dessus, donc n'oubliez pas de vérifier les compteurs avant de poser un RTT, sinon vous risquez de débarquer dans un serveur fantôme.

Côté vie privée, le site assure puisque votre IP est transformée en hash irréversible pour empêcher les abus de vote sans permettre de remonter à vous, et la protection anti-bot passe par Cloudflare Turnstile (donc pas de captcha pénible à résoudre). Aucun cookie de tracking mais juste un localStorage pour vos préférences. Et vous pouvez en option lier un compte Discord ou Steam pour recevoir des rappels avant vos sessions.

Un site qui vous fout la paix en somme...

Même l'interface tape carrément dans la nostalgie avec un look qui nous ramène pile aux menus Steam de l'époque Half-Life 2, grâce à vgui.css , un projet open source qui réplique l'esthétique des jeux Source.

Y'a six thèmes au choix dont un "Legacy" qui pue les années 2000 à plein nez (perso je suis resté dessus, forcément). Vous pouvez alors filtrer par région (NA, EU, OCE, SAM), par tags (PvP, co-op, casual, ranked, modded, newbie-friendly...) et trier par sessions qui démarrent bientôt ou par popularité.

Je trouve que GameDate est vraiment une bonne idée parce que ça participe à 100% à ce mouvement de préservation du jeu vidéo, totalement dans la lignée de projets comme EmuOS ou des trackers communautaires qui maintiennent les serveurs en vie depuis 15 ans. Je me dis que tant que des passionnés trouvent le moyen de se retrouver pour relancer un vieux serveur Tribes 2 ou autre, ces jeux ne sont jamais vraiment morts. Ils ont juste besoin qu'on les ressorte du placard de temps en temps...

À tester donc sur gamedate.org !

Depuis qu'Amazon a coupé le téléchargement USB de nos ebooks Kindle (sniiiif), héberger sa propre bibliothèque est passé du statut de bricolage du dimanche aprem au geste héroïque de préservation de notre souveraineté !

Alors si vous voulez vous lancer, sachez que Kavita , le serveur de lecture auto-hébergé développé depuis 2020, est l'un des candidats les plus solides du moment. C'est un lecteur web qui gère EPUB, PDF, comics CBZ/CBR et manga avec mode de lecture droite-à-gauche pour les aficionados et grâce lui, nos ebooks peuvent reprendre leur indépendance.

Ce truc, ça se déploie en Docker ou via Scoop pour Windows en 4 lignes de PowerShell.

De mon côté, j'ai installé Kavita sur mon NAS Synology alors voici la marche à suivre si vous voulez faire pareil.

Installation sur NAS Synology (Container Manager)

Testé sur DSM 7.2 avec Container Manager. Pour QNAP via Container Station ou TrueNAS, la logique est la même puisque c'est du Docker standard.

Étape 1 - Préparer les dossiers

Sur votre NAS, créez deux dossiers via Panneau de configuration > Dossier partagé :

• docker/kavita/config pour la config et la base SQLite de Kavita
• data/library/books pour votre bibliothèque (pointez où vous stockez déjà vos EPUB et CBZ)

Étape 2 - Le docker-compose.yml

Ouvrez ensuite Container Manager > Projet > Créer, donnez-lui le nom kavita, et collez ce docker-compose :

services:
 kavita:
 image: jvmilazz0/kavita:latest
 container_name: kavita
 restart: unless-stopped
 ports:
 - "5000:5000"
 environment:
 - TZ=Europe/Paris
 volumes:
 - /volume1/docker/kavita/config:/kavita/config
 - /volume1/data/library/books:/manga

L'image jvmilazz0/kavita:latest est celle référencée dans la doc officielle. Côté container, les chemins sont /kavita/config et /manga (peu importe que ce soit du manga ou des romans, c'est juste le nom historique du point de montage).

Étape 3 - Lancer le conteneur

Validez le projet. L'image se télécharge (environ 200 Mo), puis le conteneur démarre. Si le port 5000 est déjà pris sur votre NAS, changez le mapping en 5001:5000 par exemple.

Étape 4 - Premier lancement

Dans votre navigateur, allez sur http://IP-DU-NAS:5000. L'écran d'accueil vous demande alors de vous créer un compte admin.

Validez, puis allez dans les préférences pour passer l'interface en français et rafraichissez la page.

Ensuite, dans les paramètres du serveur > Bibliothèques, ajoutez une bibliothèque : Type "Livre" pour les EPUB/PDF ou "Manga"/"Comic" selon le contenu, le choix du dossier pointant vers /manga. Le scan démarre automatiquement.

Étape 5 - Organisation des dossiers

Attention, Kavita est sensible à la structure des dossiers donc pour qu'il identifie correctement les séries, organisez vos dossiers comme ça :

/manga
├── Asterix/
│ ├── Asterix - Tome 01.cbz
│ └── Asterix - Tome 02.cbz
├── Stephen King/
│ ├── Ça.epub
│ └── Shining.epub

Un sous-dossier par série ou par auteur, pas tout en vrac dans un dossier unique.

Étape 6 - Accès distant (optionnel)

Maintenant, pour accéder à Kavita depuis l'extérieur, le plus propre c'est un reverse proxy avec HTTPS. Sur Synology, soit via DSM > Portail web > Proxy inversé, soit via Nginx Proxy Manager . Pointez votre sous-domaine sur IP-NAS:5000 et activez Let's Encrypt.

Ou alors, moi ce que j'aime bien faire aussi, c'est rien du tout et passer par Tailscale !

Côté fonctionnalités

Côté ergonomie, franchement ils n'ont pas chômé puisqu'on y retrouve le lecteur intégré avec modes single page, double page, webtoon ou même mode immersif plein écran. Des thèmes light, dark, sepia, + un mode personnalisé en CSS si vous voulez.

Y'a aussi de la synchro de progression de lecture entre tous vos appareils, du coup vous pouvez commencer un chapitre sur le laptop pendant votre pause café et le finir sur le téléphone dans le métro. C'est appréciable au quotidien.

Y'a aussi de la gestion multi-utilisateur avec authentification OIDC pour ceux qui aiment faire les choses bien (et ratings + listes individuels par compte, donc votre meilleur pote peut lire ses romans de Tom Clancy à côté de votre collection de docs techniques sans qu'on les mélange).

Il y a également une surveillance automatique des dossiers pour tout ce qui est import auto et de la recherche full-text avec filtres par métadonnées (titre, auteur, série, genre, langue).

Et si vous avez des enfants, il est possible de mettre en place des restrictions par classification d'âge pour éviter qu'ils ne fouillent dans vos comics de Manara. Et le clou du spectacle spécial barbu, c'est l'export d'annotations vers Obsidian via le plugin officiel pour les nerds du second cerveau.

Kavita propose même une fonction "Send to Kindle" pour balancer un EPUB vers votre liseuse Amazon. Sur Windows, vous pouvez aussi le transformer en service système avec Shawl pour qu'il démarre tout seul au boot, et côté Linux, un docker-compose suffira largement.

Voilà, dans cette jungle bordélique des outils ebooks auto-hébergeables, Kavita se positionne comme une option moderne et stable. Je préfère Kavita à Calibre car l'interface web est carrément plus moderne et hyper fluide à l'usage.

Vous l'aurez compris, côté concurrence, Kavita est historiquement plus orientée mixte ebooks-comics que Komga (qui supporte aussi les EPUB et PDF mais reste très ancré culture comics). Alors si vous hésitez entre les outils du moment, mon tour d'horizon des outils ebooks self-hosted devrait vous éclairer (avec notamment le drame Booklore !!).

Ah et y'a aussi Kavita+, la version premium à 4 $ par mois (2 $ le premier mois avec le code FIRSTTIME) qui ajoutera la sync AniList, des recommandations personnalisées, des collections intelligentes et l'enrichissement de métadonnées automatique. Après, perso, pour un usage classique, je trouve que la version gratuite fait déjà largement le job, mais si vous gérez +50 000 fichiers et que vous voulez pas passer la soirée à taguer des séries entières, là ça peut carrément valoir le coup.

Source