Si vous croisez un robot-chien Unitree dans un hall d'HLM, sur un parking, un chantier, ou en train de patrouiller dansv otre ville, faut que vous sachiez 2 trucs quand même :

Un, n'importe qui peut le rooter en moins d'une minute avec son téléphone. Et de deux, le robot lui-même envoie en continu un flux chiffré vers un tunnel cloud opéré depuis la Chine. C'est en tout cas ce que Benn Jordan, musicien indépendant et chercheur amateur, vient de démontrer hier dans une enquête de 24 minutes qui fait, comme il le dit lui-même, un meilleur boulot que toute l'infrastructure cybersécurité du gouvernement américain.

Pour le hacker, suffit donc de se connecter au robot en Bluetooth, puis d'injecter une commande curl à la fin du mot de passe Wi-Fi, on éteint le toutou, on le rallume, et au reboot le robot exécute votre commande quand il active le Wi-Fi. C'est tout et c'est vraiment magique !! Pas besoin d'accès root physique donc mais juste un bon vieux téléphone et un Bluetooth pourri !

Le boss !

Alors vous pensez peut-être que ce n'est pas très grâce parce que ces robots sont des gadgets mais c'est faut puisque les robots-chiens Unitree sont actuellement utilisés par les services de police de Pullman (Washington), Port St. Lucy (Floride) et Topeka (Kansas) et un peu partout ailleurs dans le monde.

Les Marines américains les déploient en test, certains armés de lance-roquettes, les forces chinoises leur sanglent diverses armes sur le dos depuis un moment et l'Ukraine s'en sert pour repérer des munitions non-explosées. Et dans le civil, ces robots circulent même dans des HLM d'Atlanta pour le compte de sociétés de surveillance privée...

En France, le tableau est un peu différent. Pas de déploiement confirmé par les forces de l'ordre ou l'armée pour l'instant. Chez nous, c'est Boston Dynamics Spot et l' E-Doggy d'Evotech (robot 100% français, utilisé au déminage pendant les JO 2024) qui tiennent ces marchés-là. Les Unitree restent encore dans les labos tels que l' INRIA Paris et le labo HUCEBOT de Nancy qui utilisent le Go2 pour leurs recherches en locomotion robotique.

En dehors de la recherche, le cas le plus avancé est celui d'Orano, qui a testé fin 2025 le G1 humanoïde d'Unitree sur son site nucléaire de Marcoule en partenariat avec Capgemini (c'est un humanoïde, pas un quadrupède, mais même fabricant, même firmware, mêmes questions). Côté distribution, INNOV8 Power est également partenaire officiel Unitree depuis VivaTech 2025 et INGEN Geosciences distribue la marque depuis 2020. Le réseau pour vendre ces robots à des boîtes de sécurité privées françaises est donc déjà bien en place.

Du coup quand un mec démontre qu'on peut en prendre le contrôle complet rapidement, ça mérite qu'on regarde ça d'un peu plus prêt...

Et quand je dis contrôle complet, c'est pas un excès de langage. Avec cet accès root, Benn Jordan a réussi à enregistrer, télécharger et live streamer l'audio et la vidéo captés par le robot. Sans authentification donc ni même sans passer par l'app officielle. C'est assez dingue... On peut même contrôler les mouvements du robot. Une belle merde donc !

Cette faille n'est d'ailleurs pas une nouveauté absolue puisque j'avais déjà couvert le hack BLE des humanoïdes Unitree en décembre dernier. Et ensuite rebelote en mars dernier avec deux nouvelles CVE sur le Go2, partiellement patchées. La répétition des conneries devient un peu lourdingue chez Unitree...

La deuxième partie de l'enquête, elle, atteint un autre niveau puisque Benn Jordan a entendu parler de rapports affirmant que d'autres robots Unitree contenaient une backdoor envoyant des données à des serveurs étrangers. Il a donc voulu vérifier ça lui-même.

Il a donc transformé un Raspberry Pi sous Linux en routeur avec le mode moniteur activé, et lancé BetterCap pour analyser chaque paquet sortant.

Le numéro VIN de votre voiture est visible sur le bas du pare-brise et récupérable par n'importe qui qui passe à côté. Et croyez le ou non, mais c'est pourtant sur ce numéro, visible de tous, que repose en partie le modèle de sécurité de myAudi, l'application connectée pour contrôler son véhicule Audi à distance.

Un chercheur qui se présente sous le pseudo Decoder a décidé de regarder ça de plus près. Son setup c'est un émulateur Android Pixel 7, Burp Suite en proxy pour intercepter le trafic réseau ainsi que Frida Server et Objection pour contourner le certificate pinning de l'app. Des outils et du boulot classique de pentest mobile, pas particulièrement sophistiqué donc...

Et ce qu'il a découvert grâce à ça, c'est que n'importe quel utilisateur myAudi peut ajouter le véhicule de quelqu'un d'autre à son compte en entrant simplement le VIN. Le rôle attribué est "GUEST_USER" donc au premier abord, ça peut sembler anodin mais ça donne quels accès, au juste ? Hé bien on va voir ça car c'est pas si simple.

Tout d'abord, l'introspection GraphQL est activée en production sur l'API de myAudi, ce qui revient à laisser un plan d'architecte en libre accès dans le hall d'entrée d'une banque. N'importe qui peut donc cartographier l'intégralité des fonctionnalités exposées.

Plus sérieux et toujours pas patché à l'heure de la publication, via l'API msg.audi.de, un utilisateur avec le rôle GUEST_USER peut aussi récupérer l'IMEI et l'ICCID de la carte SIM embarquée dans le véhicule. Ces identifiants permettent alors potentiellement de tracer la carte SIM sur les réseaux mobiles.

Et là, la faille qui a été corrigée depuis, ce sont celles concernant les "requêtes en attente" d'un véhicule qui étaient lisibles par n'importe quel "invité". Parmi elles, les commandes "honk & flash" (klaxon + appels de phares) qui contenaient la position GPS de la voiture. Du coup, avec juste un VIN, on pouvait savoir physiquement où se trouvait la voiture... Ça rappelle un peu comment les données Strava avaient suffi à localiser le porte-avions Charles-de-Gaulle en pleine mission.

Et derrière tout ça, il y a CARIAD, la filiale "software" du groupe Volkswagen dont j'avais déjà évoqué les difficultés l'an dernier, et qui gère les services numériques pour VW, Audi, Seat et Skoda.

CARIAD a donc patché la faille GPS mais pour le reste, c'est encore "under evaluation". Je rappelle que c'est la même filiale qui, en décembre 2024, avait exposé les données de 800 000 véhicules électriques via une mauvaise configuration AWS, avec des coordonnées GPS précises à 10 centimètres près pour les modèles VW et Seat. Le Chaos Computer Club l'avait découvert, et des politiciens, des chefs d'entreprise et des forces de l'ordre se trouvaient dans le lot des données exposées...

Donc bon, y'a encore un peu de taf pour sécuriser ces voitures un peu trop connectées... En tout cas, l'analyse de Decoder est disponible sur son blog si ça vous dit. De son côté, il précise continuer à creuser l'architecture CARIAD car y'a sûrement d'autres trucs rigolo à trouver.

On verra bien...

Plus de 4 000 commits, 5 ans de décompilation acharnée, et selon l'équipe ZeldaRET le plus gros projet de reverse-engineering jamais bouclé sur un jeu Nintendo. Voilà tout ce qu'il a fallu à la team Twilit Realm pour livrer Dusk, leur portage natif de Zelda Twilight Princess sur Windows, macOS, Linux, iOS et même Android.

La sortie officielle a eu lieu samedi dernier, et le projet fait son petit effet dans la communauté retrogaming.

Link traverse les plateformes dans Dusk (capture du site officiel )

Pour faire fonctionner le jeu, vous devez récupérer le binaire Dusk sur GitHub , puis lui fournir votre propre dump du jeu GameCube car la team ne distribue aucun asset de Nintendo pour limiter le risque juridique... Après je vous fais confiance pour en trouver tombé du camion... ^^.

Et hop, en moins de temps qu'il n'en faut pour le dire, vous vous retrouvez à jouer à Twilight Princess sur votre Steam Deck, votre iPhone, votre laptop M3, votre tour Linux ARM64, peu importe... Tout ça sans émulateur Dolphin puisque le code GameCube a été reverse-engineered au niveau machine puis recompilé pour le matériel moderne, ce qui donne un vrai portage natif avec les avantages habituels : framerate déverrouillé, résolutions HD, modding facilité, performances qui dépotent (sous réserve d'un GPU compatible D3D12, Vulkan ou Metal, les vieux iGPU Intel et certains Adreno galèrent encore).

Le moteur du jeu original tournait à 30 refresh par seconde (en anglais on dit "ticks", c'est le nombre de fois où le moteur rafraîchit / recalcule la 3D du jeu) , c'est-à-dire que la simulation du monde se mettait à jour 30 fois par seconde, point final. La team a gardé ce taux à l'identique pour préserver le comportement de simulation proche de l'original, ce qui rassure surtout les speedrunners.

Sauf que maintenant, le rendu visuel, lui, peut tourner à 144 Hz ou plus. Donc entre deux refresh, Dusk calcule où devraient se trouver les objets et interpole leur position pour produire une image fluide. Vous gardez ainsi la mécanique de 2006, mais l'affichage est de 2026, donc c'est spleennnndiiiiide ! C'est une approche comparable à celle de Ship of Harkinian sur Ocarina of Time.

Côté plateformes, c'est pour Windows x86-64, macOS Intel et Apple Silicon, Linux x86-64 et ARM64, iOS via AltStore et Android en APK direct. Pas de version Switch par contre, et n'ayez pas d'espoir car l'équipe a été claire sur le sujet. Pour des raisons techniques (et j'imagine juridiques) ils n'envisagent pas de port natif sur la console actuelle. Les versions Wii et les autres régions GameCube sont également en chantier, mais pour l'instant ce sont les versions GameCube USA et EUR qui sont supportées. Le projet vérifie même le hash SHA-1 de votre dump pour s'assurer qu'il correspond à une version compatible avant de lancer quoi que ce soit.

Link en wolf enchaîné dans le donjon initial (capture du site officiel )

L'ensemble est sous licence CC0, domaine public, zéro restriction, ce qui veut dire que vous pouvez forker, modifier, redistribuer le code sans contrainte. Le projet repose sur la décompilation zeldaret/tp , menée depuis août 2020 par une communauté internationale de speedrunners et de devs reverse-engineers.

C'est le même schéma juridique qui a permis à Zelda 64 Recompilé de prospérer. Les projets évitent de distribuer des assets Nintendo, mais ça ne supprime pas tout risque de notification DMCA puisque la légalité dépend aussi de votre juridiction et de la manière dont le dump a été obtenu (DMCA section 1201 aux US, qui interdit en principe le contournement de protection, donc la prudence reste de mise).

Maintenant, faut pas se voiler la face sur le destinataire d'une lettre recommandée potentielle puisque Nintendo a fait sauter yuzu et son fork Suyu en 2024 avec 2,4 millions de dollars de règlement à la clé, Ryujinx a mis la clé sous la porte en octobre dernier sous pression directe, Garry's Mod a dû purger 20 années de contenu Nintendo de son workshop, et la société attaque actuellement Palworld sur des brevets de gameplay déposés à la va-vite.

Donc même quand un projet respecte le droit à la lettre, la firme japonaise a les moyens de noyer une équipe bénévole sous des frais d'avocats jusqu'à épuisement total. Les ports type Ship of Harkinian tiennent depuis plusieurs années déjà sans procédure, mais rien ne garantit que Dusk passera entre les gouttes. Si vous voulez profiter du jeu sur PC, je vous conseille donc de cloner le repo en local et de mettre le binaire de côté quelque part, on ne sait jamais....

Link récupère un fragment de coeur (capture du site officiel )

Pour l'installation, vous filez sur le repo GitHub, vous chopez le binaire de votre plateforme, vous pointez le launcher vers votre dump GameCube (que vous avez fait vous-même depuis une Wii moddée en suivant le guide du wiki Dolphin, hein...), et c'est parti mon kiki.

Merci à j0j0b4rj0 pour la découverte.

Spotify vient d'annoncer un truc intéressant je trouve, qui s'appelle les Personal Podcasts. Le principe c'est de demander absolument tout ce que vous voulez, par exemple un podcast sur un cours que vous venez de suivre, sur un bouquin, sur un article de Korben.info voire sur votre planning de la semaine, vos objectifs...etc etc... Peu importe... Spotify prend tout ça, et génère un épisode audio personnalisé raconté par une voix IA plus ou moins moche.

Et l'épisode apparaît alors directement dans votre bibliothèque, comme si quelqu'un avait fait un résumé audio de votre semaine.

Et pour faire ça, ils ont mis en ligne un repo GitHub save-to-spotify qui est un outil en ligne de commande permettant à des agents IA de créer ce podcast personnalisé tout ça accessible en ligne de commande ou via des agents comme Claude Code, OpenClaw ou Codex.

Que ce soit sous macOS ou Linux, ça s'installe en une ligne (allez lire le install.sh par sécurité quand même avant de l'exécuter) :

curl -fsSL https://saveto.spotify.com/install.sh | bash

/plugin marketplace add spotify/save-to-spotify

Le truc cool avec un disque de backup, c'est quand vous arrêtez de le sortir du tiroir. Et c'est ce que permet de faire le DATO Ares Q4 (lien affilié) qui se trouve être aimanté et que je peux donc coller direct sur le côté de mon Mac Studio . Je l'ai depuis bientôt un an, et c'est devenu mon disque de Time Machine à résidence.

Il est trop mignon parce qu'il est tout petit, puisqu'il mesure 64 par 64 mm, 12 mm d'épaisseur, et 40 grammes, soit à peine plus gros qu'un bloc de petits Post-it, sauf que dedans y'a 4 To de NVMe en USB4. Les aimants sont prévus pour s'accrocher à un iPhone 15/16/17 Pro façon MagSafe, mais en pratique ils tiennent aussi nickel sur n'importe quelle machine, si vous collez le petit aimant-sticker livré avec.

Après je sais pas si coller un aimant sur un ordinateur c'est le move le plus intelligent que j'ai fait de ma vie mais je l'ai collé y'a 1 an, et ça bouge pas et j'ai aucun souci. Après c'est pas des GROS aimants non plus hein... C'est assez fin et pas très aimanté non plus. Et niveau connectique, c'est livré avec un câble USB-C rikiki de 10 cm.

Côté débits l'USB4 crache du 4000 Mo/s en lecture et 3600 Mo/s en écriture et comme c'est du natif, y'a pas de puce intermédiaire entre le NVMe et le port, donc on est max de ce qu'on peut avoir en vitesse avec ce genre de disque. Par contre, faut un port USB4 ou Thunderbolt 4/5 côté Mac, sinon ça retombe sur de l'USB 3.2 classique. C'est pas dramatique mais ça va 'achement moins vite quand même.

Et comme mon Mac Studio embarque 4 To en interne, c'est pile la taille du DATO que je dédie à ma sauvegarde Time Machine. Le sparsebundle peut donc grossir jusqu'à occuper tout le disque sans que je m'en occupe ! Et comme je ne le remplis jamais à 100%, je suis assez tranquille.

En plus de ce SSD, je fais toujours des backups sur mon NAS Synology avec Carbon Copy Cloner à côté parce que je suis parano et qu'on sait jamais...

Côté chauffe, la surprise est plutôt bonne, il reste froid / tiède même en plein transfert. Alors je suis pas sûr mais je me dis que le boîtier en alu du Mac Studio, joue peut-être un petit rôle de dissipateur thermique mais j'sais pas, peut-être pas... En tout cas, ça chauffe pas quoi.

Ce disque est compatible Mac, PC, Linux, et même iPhone Pro en USB-C comme ça si vous avez besoin de filmer de la 4K ProRes HDR direct sur un SSD plutôt que sur la mémoire interne, c'est possible ! Et il est garanti 5 ans, ce qui est toujours bon à prendre.

Voilà, si ça vous intéresse, le DATO Ares Q4 (lien affilié) est dispo sur Amazon en versions 1 To, 2 To ou 4 To .

J'sais pas si vous avez vu mais le Pentagone vient de balancer 161 documents OVNI déclassifiés sur ordre de ce bon vieux Trump ! Pete Hegseth, le secrétaire à la Défense (ou à la Guerre, j'sais plus comment on dit) a donc mis en ligne 119 PDFs, 28 vidéos et 14 images couvrant les années de 1948 à 2026.

Et vous allez voir, c'est la déception scientifique du siècle !

J'ai été voir un peu de quoi il en retournait et c'est majoritairement flou et nul à chier. Les vidéos infrarouges montrent des points lumineux qui font des virages à 90 degrés au-dessus de la Grèce, sans qu'on sache quel appareil filme ni quand précisément et les images sont caviardées "pour protéger l'identité des témoins, l'emplacement des installations et des informations militaires sensibles".

Du coup, y'a des trucs intrigants qui font bosser les complotistes et autres Lone Gunmen en culottes courtes mais très peu de métadonnées techniques exploitables. Parce que en pratique, sans contexte radar, sans signature thermique, et sans plateforme de captation identifiée, c'est IMPOSSIBLE de trancher entre OVNI, drone furtif chinois, reflet dans les nuages ou simple missile expérimental. Alors à choisir entre une vidéo IR de neuf secondes dégueulasse et une vraie étude radar avec données brutes, perso j'aurais vraiment préféré la seconde.

Mais bon, c'est l'Amérique et on sait qu'ils adorent le folklore Roswell, donc ça alimente la machine à connerie mais absolument pas tout ce qui est recherche scientifique et je trouve ça dommage...

Le programme s'appelle PURSUE (Presidential Unsealing and Reporting System for UAP Encounters), parce qu'il fallait bien un acronyme trop super cool pour habiller la chose et la promesse de Hegseth est la suivante : "Ces documents, cachés derrière le secret-défense, ont longtemps alimenté des spéculations justifiées et il est temps que les Américains les voient de leurs propres yeux."

On se croirait dans une intro de X-Files. Bah voilà, là on a vu et c'est naze. En pratique, c'est comme si la NASA publiait des photos de Mars filmées avec une caméra Game Boy...

Et je vous ai pas encore tout dit car certains rapports frisent le grand n'importe quoi. Le plus beau c'est cet orbe décrit par des forces de l'ordre fédérales américaines comme "similaire à l'œil de Sauron du Seigneur des Anneaux, sans la pupille". Je vous jure, c'est la description officielle. Le vrai mystère de PURSUE je crois, c'est plutôt de savoir si ces rapports ont été écrits par des fédéraux US, ou des mecs bourrés en convention de Comic-Con.

Sauf que ça n'est pas le pire... Dans un rapport de 1966, on trouve un objet décrit comme un "rayon laser, ou rayon cobalt", "auto-enveloppant", "similaire à un cocon autour d'un ver à soie", capable d'enfermer le système nerveux entier d'une personne. Okéééé, vous pouvez développer ? Elle pousse où votre ganja les gars ? Et une fois encore, i want to believe hein, mais va falloir nous fournir autre chose que des rapports de militaires alcoolisés...

Les astronautes d'Apollo 11 auraient même observé un "objet de taille importante" près de la Lune avec une "source lumineuse assez brillante", décrite comme un "possible laser", Apollo 12 et 17 ont aussi vu des trucs et je ne vous parle pas des humanoïdes de quatre pieds (1m20, oh les tchô loulous) qui auraient été aperçus près d'engins non identifiés.

Sauf que RIEN n'est corroboré par des preuves matérielles.

Et là où ça devient carrément ouf, c'est que depuis 2 jours, y'a même un faux rapport qui circule sur les réseaux sociaux, comme s'il sortait de ces fichiers PURSUE officiels où il est question d'une femme-chat avec des oreilles pointues et une queue aperçue en 1994. Je vous rassure, ce rapport n'est PAS dans les docs officiels du Pentagone, mais je voulais aussi vous en parler parce qu'il y en a qui partagent ça en mode "voilà la preuve". Faut dire que le Pentagone a publié 161 docs si flous que même les pires hoax semblent plus sérieux au milieu de toutes ces conneries. C'est merveilleux !

Bref, ces "révélations" sont loin d'en être...

Dire que le cas que le Pentagone classe parmi "les plus convaincants" ce sont des "orbes qui lancent d'autres orbes". Ils ont été aperçus en 2023, dans l'ouest des États-Unis et c'est ça le TOP du TOP de ces preuves... donc imaginez le reste ! D'ailleurs, l'AARO (Anomaly Resolution Office) a déjà publié ses conclusions sur tout ce bordel : Aucun de ces phénomènes n'a d'origine extraterrestre confirmée.

Voilà, voilà... On verra ce qu'ils nous sortiront par la suite, mais ça risque d'être drôle. Rendez nous Jacques Pradel !!

Et dire qu'il y a 32 ans, deux ados qui cherchaient des fichiers OVNI dans les serveurs du Pentagone ont fait paniquer Washington au point de déclencher une alerte de sécurité nationale historique et aujourd'hui, le même type de fichiers sort officiellement et c'est de la bouillie pour les cerveaux crédules...

Bref, tout ça pour ça... J'suis déçu un peu quand même... Moi j'attendais une vraie photo ou vidéo nette, une vraie étude scientifique, un vrai document sérieux.

Mais à la place, on a des fédéraux qui décrivent des bidules en forme de boules de bowling sans rien de plus que leur parole... Breeef, passez votre chemin les amis !

Source

Vous avez confiance dans le nom qui est affiché à côté d'un commit GitHub ?

Bah vous pouvez arrêter tout de suite car le chercheur Shani Lavi a documenté il y a quelques années ce que les devs Git sérieux savent depuis longtemps : N'importe qui peut publier un commit avec n'importe quelle identité, et bien sûr, on peut systématiquement compter sur GitHub pour lier ce commit au profil correspondant sans broncher.

Allez, petite démonstration récente... Sur le repo no-as-a-service , il y a par exemple un commit signé "torvalds" qui ajoute un témoignage humoristique de Linus Torvalds dans le README. L'avatar de Linus s'affiche, et GitHub considère ça comme un commit parfaitement valide. Sauf que Linus n'a évidemment jamais touché ce projet humoristique qui est une petite API qui sort des excuses créatives pour dire "non".

Et ce qui est fou, c'est que vous pouvez faire pareil en dix secondes, et c'est ce qu'on va faire ensemble. Mais avant...

Pourquoi Git laisse passer ça

Git, à la base, c'est un système distribué. Quand vous faites un commit, votre client local prend alors deux infos dans votre config : user.name et user.email. Ces deux champs sont libres, et jamais validés côté client. Vous pouvez donc écrire ce que vous voulez dedans, et Git s'en fiche.

Côté GitHub, l'attribution se fait par l'email. Le service regarde alors l'email présent dans les métadonnées du commit, le compare aux emails enregistrés sur les comptes, et affiche le profil + l'avatar Gravatar correspondant. En fait, il n'y a aucune vérification que la personne qui a poussé le commit possède réellement cette adresse email.

Du coup, n'importe qui qui connaît votre email public (et il est public si vous avez déjà commit en clair sur un repo) peut publier des commits avec votre identité affichée.

Étape 1 : Reproduire le spoofing (à but pédagogique évidemment)

Avant de paniquer, faisons l'exercice nous-mêmes pour bien comprendre. Dans un repo de test que vous contrôlez :

# 1. Visualiser un commit cible pour récupérer name + email
git log --format='%an <%ae>' | head -3

# 2. Reconfigurer Git avec une fausse identité
git config --global --replace-all user.name "Linus Torvalds"
git config --global --replace-all user.email "[email protected]"

# 3. Vérifier la config
git config --global --list | grep user

# 4. Faire un commit normal
echo "Hello from Linus" >> README.md
git add README.md
git commit -m "Important kernel fix"

# 5. Pousser sur votre repo
git push origin main

Allez voir le commit sur GitHub. Vous verrez l'avatar de Linus, son nom cliquable qui mène vers son profil, et surtout aucun avertissement. Pas de mot de passe demandé ni de token compromis... non, non, non, c'est juste une config locale modifiée.

Et si quelqu'un fait un fork de votre repo, ou si un mainteneur peu attentif valide un PR sur cette base, l'illusion est complète.

Étape 2 : Repérer un commit douteux

Pour ça, le badge Verified reste l'indicateur le plus utile. À côté du SHA d'un commit, GitHub affiche surtout une étiquette verte "Verified" si le commit est cryptographiquement signé avec une clé GPG ou SSH enregistrée sur le compte de l'auteur. Sinon, y'a rien du tout (par défaut). Attention quand même, l'absence de badge ne veut pas dire qu'un commit est malveillant mais juste qu'on ne peut pas garantir qui l'a écrit.

Par exemple, si vous regardez le commit e6b4218 sur no-as-a-service, vous remarquerez l'absence totale de badge. C'est le signal mais il faut encore savoir le chercher car par défaut, GitHub n'affiche AUCUN avertissement pour les commits non signés. C'est surtout ça le problème...

Étape 3 : Signer vos commits avec SSH

Alors pour vous protéger de ça, ça commence chez vous. Plus simple que GPG, la signature SSH utilise une clé que vous avez probablement déjà. Générez une clé Ed25519 si ce n'est pas fait :

ssh-keygen -t ed25519 -C "[email protected]"

Configurez Git pour signer automatiquement avec cette clé :

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git config --global tag.gpgsign true

Dernière étape, ajoutez votre clé publique sur GitHub dans Settings → SSH and GPG keys (1), mais cette fois en sélectionnant le type Signing Key (pas Authentication Key, c'est différent) (2). Vos prochains commits afficheront le badge "Verified" en vert.

Si vous préférez GPG, le principe est identique avec gpg.format gpg et une clé GPG. Pour le détail GPG complet, j'avais déjà couvert le sujet dans le tuto sur Thunderbird et GPG .

Étape 4 : Activer Vigilant Mode

Là, on passe à l'offensive. Vigilant Mode (3) force GitHub à afficher un statut sur tous vos commits. Les signés deviennent "Verified", les non signés deviennent "Unverified" en gros et bien visible. Plus de zone grise comme ça.

Direction même endroit dans Settings → SSH and GPG keys → Vigilant mode → Flag unsigned commits as unverified. Cochez la case. À partir de là, n'importe quel commit que GitHub vous attribue (via votre email vérifié) sans signature sera affiché comme "Unverified", ce qui rend le spoofing beaucoup plus difficile à dissimuler. Petite limite par contre, ça ne protège que votre propre identité et pas celle des contributeurs qui n'ont pas activé le mode.

La position de GitHub (et pourquoi je trouve ça discutable)

GitHub considère ce comportement comme un non-bug. Sur leur page bug bounty, l'usurpation par email Git est explicitement listée comme ineligible. Leur argument c'est que ça ne donne pas accès aux repos ni de privilèges supplémentaires, donc ce n'est pas une faille au sens strict.

Sauf que dans la vraie vie, l'identité affichée influence les décisions. Par exemple, un mainteneur qui voit un PR signé d'un contributeur connu va l'examiner avec moins de paranoïa, un journaliste qui couvre un scandale va citer "le commit de tel développeur" sans vérifier la signature, et combiné à d'autres vecteurs, ça peut devenir redoutable ! Je pense surtout aux attaques supply chain récentes type Shai-Hulud où une fois le code piégé, l'attribution Git aide à le faire passer pour légitime.

Bref, dire "ce n'est pas un bug" parce qu'il faut un autre vecteur derrière, c'est un peu facile, je trouve. Voilà, donc ne comptez pas sur Github pour vous défendre et signez vos commits, activez Vigilant Mode, et apprenez à vos collègues et amis dev à vérifier le badge "Verified" avant de merger quoi que ce soit en venant d'un inconnu... même si c'est ce bon cher Linus qui propose de réécrire le kernel en Rust avec systemd intégré ^^.

Source

Justin Poehnelt, Senior Developer Relations Engineer chez Google, vient de balancer sur Github un outil en ligne de commande (CLI), codé en Rust qui permet de faire un truc trop pratique, à savoir piloter entièrement Workspace depuis le terminal. Ce logiciel nommé GWS est donc capable de gérer Gmail, Drive, Calendar, Sheets et sept autres services Google d'un coup. Et en plus, comme il a été conçu pour les agents IA, donc c'est pas juste pour vous et votre terminal !

Une fois installé via npm, cargo, brew ou un binaire pré-compilé, vous tapez gws auth login pour vous authentifier via OAuth et vous pouvez ensuite attaquer onze services depuis votre shell : Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin, Apps Script, Tasks, Workspace Events et Model Armor.

Niveau archi, au lieu de hard-coder chaque commande dans le binaire, gws interroge tout simplement le Discovery Service de Google au démarrage et reconstruit son arbre de commandes à la volée. Du coup quand Google ajoute un endpoint à l'API Sheets, le CLI le voit apparaître tout seul. C'est trop bien parce que ça évite de devoir attendre une release pour utiliser un éventuel nouveau service de Google. Et pour un agent IA qui re-fetch le schéma à chaque run, c'est plutôt une bonne idée.

Donc en plus de démarrer en moins d'une seconde, GWS crache des sorties en JSON structurées, y'a un mode --dry-run qui montre la requête sans l'envoyer, et de l'auto-pagination via --page-all. Et côté commandes utilitaires, vous avez aussi les + qui sont des helpers cousus main tels que gws gmail +send, gws drive +upload, gws calendar +agenda, gws sheets +append, gws gmail +triage et un gws gmail +standup-report qui résume vos mails de la semaine en quelques lignes.

Le repo embarque aussi 40+ skills d'agent prêts à l'emploi du type "résume mes mails non lus" ou "génère mon rapport", une extension Gemini CLI qui s'installe avec gemini extensions install https://github.com/googleworkspace/cli, et le helper +sanitize-response qui fait passer la sortie par Model Armor (le filtre anti-prompt-injection de Google Cloud) pour éviter les réponses bizarres.

En gros, c'est un outil pensé pour faire piloter votre Workspace par Claude, Gemini ou n'importe quel agent. Comme ça vous allez pouvoir écrire un workflow qui lit vos mails non lus, en fait un résumé, le poste dans un Chat et classe tout ça proprement dans Drive... sans avoir à toucher à la souris ni avoir à utiliser votre cerveau léthargique. Elle est pas belle la vie ?

Sauf que. Le projet porte le disclaimer "This is not an officially supported Google product", et un employé Google a confirmé sur le thread Hacker News (presque 1000 points, quand même) que c'est un projet DevRel. Comprendre : pas de SLA, pas de roadmap garantie, pas d'équipe SRE qui veille au grain. Vous savez comment ça finit chez Google avec ce genre de statut !

Bref si vous êtes chaud pour tester, le binaire est dispo ici . Maintenant reste à voir si Google lui donnera un statut officiel ou si GWS s'éteindra discrètement comme tant d'autres projets internes oubliés...

60% des mots de passe hashés en MD5 peuvent être cassés en moins d'une heure... C'est ce que dit en tout cas une étude de Kaspersky publiée cette semaine qui se base sur +231 millions de mots de passe qu'on peut trouver sur le dark web et tirés de fuites ayant eu lieu entre 2023 et 2026. D'après leurs tests, 48% sont craqués en moins d'une minute et 60% en moins d'une heure. C'est pas très rassurant, surtout si votre base tourne encore au MD5.

Ce qui a changé ces dernières années, c'est surtout la puissance des GPU modernes qui n'a cessé d'augmenter. Par exemple, une RTX 5090 monte à 220 milliards de hash MD5 par seconde ce qui représente une augmentation de +34% par rapport à la RTX 4090 ! Du coup, louer un GPU cloud pour lancer une attaque par dictionnaire revient à quelques dizaines de centimes à quelques dollars de l'heure. C'est rentable hein ?

L'étude souligne aussi que 53% des mots de passe du corpus se terminent par des chiffres. Et là, du point de vue des règles hashcat, c'est du pain bénit car les crackers adorent la prévisibilité. Alors attention si vous administrez un service web avec une gestion de comptes utilisateur car les attaques modernes (dictionnaire + règles hashcat) règlent aujourd'hui son compte à une bonne partie du corpus et cela en moins d'une minute. Par contre, les mots de passe longs avec symboles variés résistent encore puisque c'est exponentiel ! Vaut mieux une phrase de passe avec plein de mots et facile à retenir du genre running-douche-afford-laborer-art-amber-deftly-acetone-lego-reoccupy qu'un mot de passe court et complexe comme 3d2^vO$RZ1.

Bref, MD5 pour les mots de passe c'est mort donc si vous avez encore ça dans vos bases, migrez moi tout ce bordel rapidement ! La migration maintenant, ça se fait vers Argon2id en priorité... Je balance pas ça au pif, hein, c'est le standard recommandé par OWASP et le NIST, et c'est memory-hard, donc les GPU ne peuvent pas juste brute-forcer des milliards de hashs par seconde comme avec MD5.

Après si votre stack est ancienne et qu'Argon2id n'est pas dispo, bcrypt reste une option solide. Dans tous les cas, évitez SHA-1, SHA-256 ou SHA-512 sans algorithme adaptatif car ils sont rapides par conception, donc tout aussi crackables que MD5.

Source

Le chercheur en sécu Hyunwoo Kim vient de lâcher dans la nature Dirty Frag, un nouvel exploit kernel Linux qui enchaîne 2 vulnérabilités pour obtenir un accès root sur n'importe quelle distro majeure, avec un taux de réussite proche de 100%.

L'embargo devait tenir encore quelques semaines. Il n'a pas tenu.

Et problème (et c'est pour ça que je vous en parle) c'est que ça marche du feu de dieu, et que personne n'a encore de patch disponible !! Alerte rouge donc !!

La lignée "Dirty" a donc maintenant quatre membres. Dirty COW en 2016, avec ses 9 ans de présence silencieuse dans le kernel avant d'être découvert, Dirty Pipe en 2022, Copy Fail dont je vous parlais il y a tout juste 8 jours, découvert par une IA. Et maintenant Dirty Frag, qui s'appuie sur le même principe que Copy Fail tout en contournant sa mitigation connue.

Alors comment ça marche ?

Le concept du truc c'est l'abus d'un mécanisme tout à fait légitime du kernel Linux : splice(). Cette fonction permet de faire circuler des données entre deux descripteurs de fichiers sans les copier en mémoire. C'est très utile, très performant, mais dans certaines configurations, c'est surtout très catastrophique.

Dirty Frag exploite les modules réseau d'IPsec (ESP) et du protocole RxRPC, ainsi quand un attaquant utilise splice() pour faire passer une page du cache mémoire (disons, /usr/bin/su) dans un buffer réseau, le kernel effectue son chiffrement directement sur cette page en RAM et sans faire de copie.

Résultat, les premiers octets de /usr/bin/su en mémoire sont remplacés par du code malveillant qui ouvre un shell root. Un simple appel à su ensuite, et l'attaquant est root.

Deux CVE sont impliqués dans la chaîne. CVE-2026-43284 qui concerne les modules esp4 et esp6 et qui a été patchée depuis hier et CVE-2026-43500 qui concerne rxrpc et pour celle-ci, y'a aucun patch actuellement à l'heure où j'écris ces lignes.

Le fait de chainer les 2 exploits permet à chacun de combler les angles morts de l'autre. C'est un peu technique mais en gros, la variante ESP requiert les droits de créer un namespace utilisateur, ce qu'Ubuntu peut bloquer via AppArmor. Alors que de son côté, la variante RxRPC ne nécessite pas ce privilège, mais le module rxrpc.ko n'est chargé par défaut que sur... Ubuntu. Du coup, une fois combinés, ils couvrent toutes les distros majeures sans exception.

Hyunwoo Kim a reporté la faille aux mainteneurs des distribs le 30 avril dernier, avec un accord de divulgation coordonnée via [email protected]. Mais un tiers extérieur (appelons le "connard" ^^) a brisé l'embargo hier, d'où la publication immédiate du PoC, avec l'accord des maintainers, pour éviter qu'un exploit silencieux circule sans que personne soit prévenu.

Les versions testées et confirmées vulnérables sont donc Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44.

En gros, si vous avez un kernel compilé depuis début 2017, vous êtes dans le scope.

Tester avec Lima sur macOS

Si vous voulez reproduire ça dans un environnement contrôlé, l'idée c'est de lancer une Ubuntu 24.04 avec le kernel non patché et de faire comme ceci :

# Cloner, compiler, et lancer
git clone https://github.com/V4bel/dirtyfrag.git
cd dirtyfrag
sudo apt install gcc -y && gcc -O0 -Wall -o exp exp.c -lutil && ./exp

Et si tout se passe bien, vous obtenez alors un shell root sans faire paniquer le kernel comme chez moi ici :

Après le test, le page cache est contaminé donc avant de faire quoi que ce soit d'autre, faut le nettoyer. :

echo 3 > /proc/sys/vm/drop_caches

Ou plus simple, redémarrez la machine car la modification est uniquement en RAM, donc un reboot permet de repartir de zéro.

Alors que faire ?

Hé bien, comme aucun patch n'est disponible pour la plupart des distros à l'heure où j'écris ces lignes, vous pouvez vous mettre en boule et pleurer. Sauf si vous êtes sous AlmaLinux car eux ont déjà poussé des kernels corrigés. Après vous pouvez aussi sécher vos larmes si vous êtes sur une autre distro, et suivre cette remédiation qui vous prendra trente secondes :

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

Cette commande fait trois choses : elle blackliste les modules vulnérables pour qu'ils ne se rechargent pas au prochain boot, elle les décharge s'ils sont actifs, et elle nettoie le page cache au cas où il serait déjà corrompu.

Après c'est tranquille à faire car esp4, esp6 et rxrpc ne sont pas des modules que la plupart des machines desktop utilisent au quotidien. Les désactiver n'a donc aucun impact visible sur 99% des setups. Mais un serveur qui fait du VPN IPsec en mode transport ESP, lui, sera affecté...

En tout cas, surveillez ça de près car une fois que votre distro sortira le patch, faudra mettre à jour et rebooter.

Source : https://github.com/V4bel/dirtyfrag

Vous le savez, il y a un algorithme dans votre téléphone qui décide ce que vous allez lire aujourd'hui et il s'appelle Google Discover.

Google Discover, c'est le flux d'articles qui apparaît quand vous ouvrez l'appli Google sur Android ou iOS, ou que vous swippez à gauche depuis la home de votre smartphone Android et Chrome mobile aussi. Et pas besoin d'avoir cherché quoi que ce soit puisque Google analyse votre historique, connaît vos centres d'intérêt, et vous sert ainsi des articles « adaptés » en continu.

Sauf que l'algo confond souvent « ce que vous voulez lire » avec « ce qui génère le plus de clics ». Et là, ça part en couille sévère...

Du coup vous vous retrouvez avec des articles qui expliquent que le cash va être interdit dans deux mois, que les conducteurs avec une moustache vont devoir repasser le permis, ou que l'Union Européenne s'apprête à requalifier la pizza comme « sandwich plat » pour l'assujettir à une nouvelle taxe.

Et pendant ce temps, les vraies actus tech que vous aimez tant, elles, se noient quelque part entre deux horoscopes et une pub déguisée en article. Et c'est d'ailleurs ça le gros défaut de tous les flux algorithmiques : ils optimisent l'engagement mais pas l'exactitude. On est tous humain, alors forcément un titre alarmiste battra toujours un article de qualité sobre et bien sourcé. L'algo se contrefout royalement de respecter les 3 neurones qui vous restent... ^^

Mais Discover a quand même un truc pas con ! En fait depuis fin de l'année dernière, Google permet de suivre directement des éditeurs sur le réseau, un peu comme un flux RSS mais sans lecteur à installer ni boîte mail à gérer. Suffit de cliquer sur un bouton et hop, les articles de vos sources préférées remontent en priorité dans votre feed Google Discover !

Par exemple, si vous voulez voir les articles de Korben.info apparaître dans votre flux (de la vraie tech, sourcée, sans moustaches ni taxes pizza), c'est par là, il suffit d'aller sur mon profil Google Discover et de cliquer sur le bouton "Suivre sur Google".

Et comme ça, une fois abonné, mes publications remonteront directement dans votre Discover. Perso, je trouve ça pas mal du tout comme système.

Bref, si vous ne voulez pas que votre téléphone vous apprenne demain que les chats seront bientôt recensés comme « animaux de surveillance passive » par un nouveau décret gouvernemental, pensez à bien choisir vos sources !

Et pour trouver les liens de vos médias préférés, vous pouvez passer par cet outil de Julien .

Speedtest.net c'est pratique, sauf que ça a été racheté par Accenture en 2026 et chaque test envoie votre IP, le nom de votre FAI et votre localisation à leurs serveurs...

Alors pourquoi ne pas adopter LibreSpeed , l'alternative open source que vous hébergez chez vous, et qui ne contient aucun tracker ??? L'outil est signé Federico Dossena, ça a été lancé en 2016 et c'est sous licence LGPL v3. Et ce que ça mesure c'est la vitesse du download, de l'upload, le ping, le jitter , et ça relève aussi l'adresse IP et le nom de votre FAI.

Côté déploiement, c'est du classique. Vous déposez les fichiers sur votre serveur, dont speedtest.js et speedtest_worker.js pour le frontend, vous configurez le backend via config.json, et hop c'est lancé. Un simple VPS ou n'importe quelle autre machine sur votre LAN fera l'affaire.

Et comme vous choisissez le serveur de test, y'a pas de saturation par d'autres utilisateurs, pas de route réseau bizarre vers un data center à l'autre bout de l'Europe et surtout, les résultats sont parfaitement reproductibles donc pour les "homelabers" (c'est comme ça qu'on dit ?) ou les équipes réseau, c'est assez chouette.

Il y a aussi le mode multi-serveur pour comparer des endpoints, le partage de résultats via lien unique, et un CLI librespeed avec ses flags --server et --host pour les fans du terminal. Des backends officiels en Go et Rust existent aussi sur le github de librespeed , signe que le projet est sérieux.

Et surtout, les résultats sont fiables, sauf si votre serveur plafonne à 20 Mbit/s et dans ce cas, vous mesurerez sa liaison et pas la vôtre. Ça coule de source, mais je tenais à le préciser quand même...

Voilà, l'interface est moche, en tout cas beaucoup plus que celle de Speed.cloudflare.com , par contre l'essentiel est là. Et surtout, les mesures restent chez vous plutôt que de partir ailleurs.

Bon, maintenant que vous avez vos chaînes IPTV qui tournent via Tunarr ou xTeVe, votre flux XMLTV est super propre. Mais il vous manque un seul truc : Un guide de programme potable.

Hé bien GridTV développé par l'ami JohnnyBeGood est là pour ça !

GridTV c'est une interface web en PHP/JS/CSS qui transforme toute source XMLTV compatible en guide TV façon grille horizontale, avec l'indicateur "maintenant" visible en permanence, une barre de progression du programme en cours, et les émissions passées qui se retrouvent automatiquement grisées. C'est exactement ce à quoi ressemble le guide TV de votre box opérateur, mais en mieux, et pour votre propre contenu !

Pour le déploiement, Docker est le chemin recommandé plutôt que de tout configurer à la main : git clone, cd GridTV, docker compose up -d, et hop, vous ouvrez localhost:8080.

Un assistant de setup vous demandera alors votre source EPG obligatoire et une playlist M3U si notamment vous voulez utiliser le player intégré, et une fois validé, vous retombez directement sur la grille.

Ça se met en place en moins de 5 min mais si vous préférez installer sans Docker, ou plutôt sans la couche conteneur, il y a également sur le Github des exemples de config pour Apache et Nginx dans la doc. Caddy fonctionnera aussi et la doc concernant Traefik, c'est pour le cas où GridTV tourne en Docker mais derrière un reverse proxy.

Côté fonctionnalités, le player HLS s'ouvre en PiP (Picture in Picture) dans un coin en cliquant sur une chaîne et le multi-EPG vous permettra de configurer plusieurs sources avec un petit switch. GridTV propose aussi des rappels de programme via notifications navigateur, 15 minutes avant la diffusion. Mais pour en profiter, l'onglet du browser doit rester ouvert et les notifs autorisées.

Et il y a aussi possibilité de générer un export PDF/PNG du guide sur 24h. C'est pas indispensable mais ça permet pour ceux qui veulent d'imprimer le programme de la soirée.

Chaque visiteur de l'instance peut aussi utiliser / paramétrer ses propres URLs XMLTV/M3U, car rien n'est stocké côté serveur. Hé oui, tout passe par le localStorage du navigateur donc vous pouvez partager votre instance avec autant de monde que vous voulez, ça n'a pas d'impact.

La version Steampunk

Et il y a même des thèmes genre cyberpunk, steampunk, magazine ou le thème par défaut. Et la page de monitoring admin expose également une sonde accessible via un endpoint compatible Uptime Kuma qui renvoie le code HTTP 200 si tout va bien. Sinon, ce sera du code 503. Bref, ça vous connaissez...

Bref, l'outil est jeune mais bien construit et une démo live tourne ici guide.demo.johnnybegood.fr . À suivre donc....

Et si vous cherchez juste des listes de chaînes IPTV gratuites , c'est par là !

On connaît tous les grands noms des protocoles VPN : WireGuard, OpenVPN, IKEv2 (Surfshark VPN utilise les 3). Ce sont des bêtes solides, mais elles ont au départ été pondues pour des usages pro, avec des armées de serveurs en entreprise et des configs à rallonge. Puis on les a adaptés pour nous, les users lambda qui veulent juste binge-watcher une série sur Netflix ou checker ses mails sur le Wi-Fi crade du troquet du coin, sans se prendre la tête sur les détails techniques. Ça roule, mais c'est pas l'idéal.

Surfshark a dit stop au bricolage. Ils ont tout repris à zéro et lancé Dausos. Pas une énième couche de sauce marketing sur de l'existant, non : une architecture repensée de fond en comble. La promesse ? Vitesse, confidentialité et efficacité des ressources, sans un seul compromis. Et dans un écosystème où les VPN se battent sur le prix et les fonctionnalités cosmétiques, cette approche mérite qu'on s'y penche sérieusement. Je vais vous décortiquer tout ça, point par point, pour que vous pigiez bien ce que ça change concrètement.

Dausos en détail : pas une adaptation, une création native

Dausos, c'est le tout premier protocole VPN 100% maison chez Surfshark, taillé sur mesure pour les particuliers. Le nom ? Inspiré de la mytho balte, où "Dausos" évoque l'élévation et la protection divine, sympa comme clin d'œil pour un truc qui vous met à l'abri en ligne. L'idée centrale est de créer un tunnel qui colle pile à vos besoins, sans les contraintes des protocoles pros recyclés.

La grosse différence avec les classiques, c'est la gestion du trafic. La plupart des VPN font passer les datas de plein d'utilisateurs via des tunnels partagés sur un même serveur. C'est pratique pour l'opérateur (moins de ressources nécessaires), mais ça crée une surcharge permanente, des interférences potentielles entre sessions et un risque accru si un user foireux impacte les autres. Résultat : des perfs en dent de scie à certains moments et une sécurité des données pas toujours optimale.

Dausos inverse le principe. Chaque connexion (la vôtre) se voit coller un tunnel dédié et 100% isolé sur le serveur. Votre trafic ne croise jamais celui du voisin, même sur un même serveur bondé. Ça réduit les surfaces d'attaque (moins d'expositions aux fuites croisées), optimise les perfs en virant la contention ressource et renforce la confidentialité globale. C'est comme si vous aviez votre propre bande sur l'autoroute VPN, sans camion qui vous colle au cul.

Les briques techniques qui font la diff

Le protocole brille par ses choix d'implémentation pointus. Pas de demi-mesure ici. D'abord, le chiffrement : exit AES-GCM, la vieille garde fiable, mais datée. Place à AEGIS-256X2, un algo moderne taillé pour les CPUs récents (nouveaux Intel/AMD, Apple Silicon...). Plus rapide en chiffrement/déchiffrement, il bouffe moins de cycles processeur pour un niveau de sécu équivalent. Concrètement ? Votre débit reste au max, même sous charge.

Ensuite, la résilience post-quantique intégrée (voir aussi mon article sur Surfshark et le post-quantique ). Ici ce n'est pas une rustine ajoutée après coup, l'architecture est née quantique-ready. Avec les ordis quantiques qui pointent le bout de leur nez (merci Google et consorts), ça protège vos données sensibles pour les 10-20 ans à venir. Ça pense à l'avance, quoi.

Troisième atout : l'adaptation dynamique. Dausos scanne votre réseau et votre hardware en live et ajuste les paramètres (MTU, compression, etc.) pour coller à la réalité. Fibre optique ? Full perf. Passage en 4G foireuse ou métro ? Stabilisation automatique sans drop. Pas d'interruption visible, juste du smooth.

Et pour la crédibilité l'outil a passé avec succès un audit indépendant par Cure53. Ces gars sont des pointures en sécu (ils ont bossé sur Signal, Proton, etc.) et le rapport est public, dispo pour tous. Pas de blabla, de la preuve béton.

Les gains concrets pour votre quotidien

Surfshark balance des chiffres : jusqu'à +30% de vitesse vs protocoles standards. Comme d'hab c'est à nuancer, hein, ça dépend de votre setup, du réseau et du serveur choisi, etc. Sur une fibre stable, c'est perceptible, mais pas fou. Par contre, en mobilité ou réseaux chiants (vacances, events), l'adaptation dynamique fait des miracles. Moins de lag, une connexion plus stable, que demande le peuple ?

tunnel vpn classique

L'isolation trafic ? C'est moins flashy, mais crucial. ça réduit les risques de fuites croisées et d'attaques par corrélation (un attaquant qui matche patterns entre différents utilisateurs). Côté mobile, l'efficacité en termes de ressources sauve un peu plus de batteries. L'optimisation CPU/GPU c'est une autonomie augmentée de 10-20% en VPN constant. Un détail, mais un détail qui change tout en déplacement.

Comment l'activer et disponibilité

Pour l'instant, Dausos est en bêta exclusive sur macOS via App Store. Pas de date ferme pour iOS/Android/Windows/Linux, mais un rollout progressif est annoncé (logique pour éviter le chaos).

Étapes simples :

1. Installez/mettez à jour vers la dernière version Surfshark depuis l'App Store macOS.
2. Allez dans Paramètres > Paramètres VPN.
3. Protocole > Sélectionnez Dausos.
4. Connectez-vous à un serveur.

Si vous avez la version DMG (non-App Store), désinstallez-la d'abord pour éviter les conflits, Bêta oblige des instabilités sont possibles. Si ça vous arrive, revenez vers WireGuard/OpenVPN en attendant, et signalez le bug au support.

Ce que j'en pense pour de bon

Ce que j'apprécie toujours autant, après des années à l'utiliser, c'est cette cohérence et ce côté proactif à toute épreuve. Surfshark ne fait pas semblant : opter pour des tunnels dédiés par utilisateur, ça coûte un bras en infra serveur (plus de ressources allouées, moins d'optimisation low-cost), mais ça livre du premium pur jus.

L'AEGIS-256X2, c'est du costaud. Ils sortent des rails AES-256-GCM usés jusqu'à la corde, avec un algo qui colle aux CPUs modernes et validé par la crème de la communauté crypto. Vision long-terme aussi avec le post-quantique natif, rare chez les VPN grand public, qui attendent souvent que le problème explose pour patcher à la va-vite.

La limite bêta macOS seulement ? Ouais, frustrant pour les autres plateformes (vous n'avez qu'à avoir du goût), mais malin comme tout. Mieux vaut roder le bestiau sur un terrain contrôlé avant de lâcher les hordes sur iOS, Android ou Windows. Ça évite les bad buzz et les forums en feu.

Est-ce que Dausos seul justifie de plaquer votre VPN actuel pour Surfshark ? Nope, pas encore. Mais pour les geeks qui kiffent l'innovation transparente, sans bullshit marketing, c'est un argument massue. Une vrai killer feature dans un océan de copies carbone.

Bref, à tester ou pas ? Si vous êtes sur macOS, foncez, c'est gratos et rapide à setup. Sur autre chose ? Gardez l'œil ouvert sur les annonces, ce protocole pourrait bien devenir la référence pour les VPN perso d'ici 2-3 ans. La sécurité et les perfs, c'est pas un one-shot, c'est du boulot continu. Dausos en est l'exemple parfait. C'est grâce à ce type d'évolution discrète et solide que Surfshark a su s'imposer et creuser l'écart sur la durée.

Le tarif du moment

Si vous voulez tester Surfshark, sachez qu'un engagement de 24 mois + 3 mois offerts revient à 57,67€ TTC (soit moins de 2,15€/mois). La garantie satisfait ou remboursé de 30 jours vous laisse le temps de vérifier que l'outil correspond à vos besoins. Et l'abonnement protège tous vos appareils, sans limite.

Profitez de l'offre !

*Transparence : il s'agit d'un lien affilié. Vous payez le même prix, mais une commission me revient si vous passez par là. C'est ce qui me permet de publier ce type de contenu sans recourir aux bannières publicitaires ou aux articles sponsorisés non identifiés.  *

Y'a des génies du crime, et puis y'a Peter Stokes, alias Bouquet, 19 ans, presque toutes ses dents, double nationalité américano-estonienne, et surtout membre de Scattered Spider, le collectif qui a déjà plumé MGM et Caesars.

Le mec a tellement bien réussi son coup qu'il est parti se payer des vacances à Tokyo, sauf que pour fêter ça, en bon teubé, il a posté sur Snapchat des selfies de sa grosse tête avec un tout nouveau bijou : un collier en diamants HACK THE PLANET. Comme dans le film de 1995 mais en plus bling bling !

Hé bien grâce à ça, le FBI a fini par le coffrer lors de son escale d'Helsinki.

Bouquet (oui, j'ai pas précisé mais c'est son pseudo) opérait donc dans le groupe Scattered Spider, ce collectif d'ados anglophones qui ne s'embête pas avec des failles zero-day parce que de toute façon, ils ne sauraient pas les utiliser.

À la place, ils ont leur propre méthode super technique vous allez voir... ils appellent le support IT de la cible et embobinent un pauvre mec pour qu'il reset le 2FA d'un admin.

Et voilà comment notre cher Bouquet a pu sortir 100 Go de données d'un revendeur de produits de luxe (la plainte désigne sobrement la "Company F", mais ça pue Harrods d'après la presse anglaise) en seulement quelques heures, réclamé 8 millions de rançon, et causé plus de 2 millions de dégâts.

Du coup, plainte fédérale à Chicago, 6 chefs (wire fraud, conspiracy, computer intrusion comme ils disent là-bas avec l'accent cowboy), + extradition vers les USA en cours. C'est le bouquet final pour lui ! (Oui, jeu de mots, roh roh roh).

Tyler Buchanan, 24 ans, autre membre du club, a de son côté déjà plaidé coupable d'avoir empoché 8 millions en crypto via du SMS phishing. Faut dire qu'en 2024, le groupe envoyait fièrement des messages genre "Fuck off, FBI" aux agents fédéraux qui enquêtaient sur eux.

Très rebelles nos kikoulool ! Enfin, comme vous le savez, qui fait le malin tombe dans le ravin, et qui fait le mariole avec un collier finit avec des bracelets ^^. (J'ai pas trouvé mieux, déso... lol)

Bref, Bouquet vient à lui seul d'écrire le chapitre 1 du manuel "Comment ne PAS être un cybercriminel à succès" et dont la règle n°1 est : "Si t'es recherché par le FBI, ne montre pas ton butin sur Snapchat"

Source

Énorme retournement de situation. ShinyHunters, le groupe qui avait piraté Rockstar via Anodot mi-avril et exigé une rançon, a fini par balancer ses données sur internet quand l'éditeur a refusé de payer. Le but était de faire mal financièrement à Take-Two, sauf que les chiffres révélés étaient si impressionnants que l'effet a été l'exact opposé. En effet, l'action Take-Two est passée d'environ 202 dollars à presque 208 dollars en une matinée, soit une capitalisation boursière qui a pris à peu près un milliard de dollars dans la foulée. C'est fou !

Ce que les hackers ont mis en ligne, c'est notamment que GTA Online génère plus d'un million de dollars par jour , soit autour de 500 millions par an. Et tout cela, 13 ans après le lancement sur 5 plateformes différentes, simplement grâce aux Shark Cards (les cartes prépayées du jeu). Pour un éditeur qui s'apprête à sortir son GTA 6 en novembre prochain, faut dire que ce genre de stats montre qu'ils ont les reins hyper solides, ce qui rassure les investisseurs.

Bref, au lieu de sanctionner Take-Two pour la fuite de données et la faille Anodot, Wall Street y a simplement vu la confirmation de ce que tout le monde soupçonnait : la machine à cash de Rockstar tourne à plein régime, et un éventuel GTA 6 au même niveau de monétisation, même partielle, ferait exploser les compteurs !!

Rockstar a également publié une déclaration courte et carrée pour dire que la violation n'aurait pas d'impact sur le studio ou le dev de GTA 6. Rien de plus...

C'est donc un retournement de situation assez fou côté où des hackers, en cherchant à frapper l'éditeur au portefeuille, lui ont en fait permis de gonfler sa capitalisation d'un milliard. Difficile de faire pire en termes de coup raté ^^. À moins que les gens de ShinyHunters aient fait un peu de délit d'initié en amont avant de leaker les données... allez savoir ??

Reste à voir si la SEC ou les autorités européennes voudront enquêter sur cette fuite, sachant qu'au passage des données salariés et de joueurs ont aussi été exposées. Quoi qu'il en soit, côté marché, c'est plié et le cours de l'action est resté bien haut !

Source

En 1992, Eddie Gil de la boîte anglaise Source R&D et Frank Ballouz de Fabtek s'étaient mis en tête d'une chose : transformer la Game Boy en PDA. La console à pile AA de Nintendo avec son écran vert pissette devait, dans leurs rêves les plus fous, devenir l'agenda électronique des cadres dynamiques. Le projet s'appelait WorkBoy, et il a même été présenté au CES en 1992, puis... plus rien.

Évaporé durant 28 ans.

Jusqu'à ce qu'en 2020, Liam Robertson, le mec derrière DidYouKnowGaming , retrouve un prototype fonctionnel chez Frank Ballouz lui-même. Ballouz l'avait sur son étagère depuis trois décennies. Quand Robertson l'a contacté, il lui a lâché tranquillou : "Oh yeah, j'ai le WorkBoy derrière moi" et après 7 mois de relances, le proto est finalement arrivé dans les mains de Robertson pour être testé en vidéo :

Si vous avez committé du code depuis VS Code depuis mi-avril, allez tout de suite vérifier vos messages de commit car vous avez peut-être un nouveau co-auteur que vous n'avez jamais embauché.

En effet, Microsoft a discrètement basculé le réglage par défaut de l'éditeur pour ajouter Co-authored-by: Copilot <[email protected]> à des commits que VS Code considérait à tort comme contenant des contributions IA, même quand vous n'avez pas utilisé Copilot, et même quand vous avez explicitement désactivé toutes les fonctions IA.

Quelle lose, hein ? La Product Manager Courtney Webster a poussé cette fameuse pull request #310226 des enfers le 15 avril dernier sans aucune description, et le dev dmitrivMS l'a mergée tranquillou le lendemain.

Et le résultat de tout ce bordel, vous pouvez le lire dans la PR #310226 qui a explosé sur GitHub : 372 pouces baissés contre 2 levés, 30 réactions "confused", et des dizaines de commentaires furieux.

L' issue de suivi #314311 , ouverte ensuite par dmitrivMS pour faire son point public, a elle aussi reçu un torrent de réactions virulentes. Tu m'étonnes, ils font vraiment n'importe quoi...

Maintenant si vous êtes dans ce cas, vous pouvez neutraliser ça immédiatement, ajoutez dans votre settings.json :

"git.addAICoAuthor": "off"

Si vous faites tourner WireGuard depuis un réseau filtré par DPI (Genre en Russie, Iran, Chine, et autres pays défenseurs de la libertéééé (non)), vous avez sans doute remarqué que les tunnels tombent rapidement. En effet, les signatures des protocoles et notamment du protocole WireGuard sont devenues facilement identifiables. Les filtres modernes de censure sont ainsi capable de les bloquer en quelques secondes. C'est pour ça que wg-obfuscator , sorti par Alexey Cluster (le dev derrière le mod hakchi de la NES Classic Mini dont je vous parlais en 2017), m'a tapé dans l'œil.

Concrètement, c'est un petit proxy en C qui se glisse entre votre WireGuard et le réseau. Vous le lancez aux deux bouts du tunnel, et lui déguise les paquets pour qu'ils ressemblent à du STUN (le protocole utilisé par les outils de visioconf, rarement bloqué) ou à un flux random pas reconnaissable. WireGuard continue ainsi de tourner sans aucune modification...

C'est vraiment bien fichu son truc et surtout, par rapport à AmneziaWG (un célèbre fork de WireGuard souvent cité comme référence en obfuscation), hé bien y'a juste un binaire à rajouter, alors que AmneziaWG, lui, modifie TOUT le protocole. Il faut donc remplacer les client ET le serveur ce qui est bien relou.

Comme wg-obfuscator se contente uniquement de faire le proxy, vous gardez votre setup WireGuard classique et donc ça fonctionnera partout... Sur OpenWrt, MikroTik avec RouterOS 7.4+ sur ARM64/x86_64 via Docker, NixOS, Android, ou un simple Raspberry.

Par contre, l'outil utilise une clé symétrique en texte clair donc c'est pas du chiffrement fort, mais du camouflage.

Côté config, on est sur du fichier INI tout simple :

[main]
source-lport = 13255
target = 10.13.1.100:13255
key = votre_secret
masking = STUN
verbose = 2