PROJET AUTOBLOG


Korben

source: Korben

⇐ retour index

TPMS - Vos pneus balancent votre position en clair

vendredi 27 février 2026 à 14:55

Gaël Musquet, mon copain hacker, me parlait déjà de tracking TPMS en 2020. Du coup, quand je vois des chercheurs publier un document de recherche en 2026 pour "découvrir" qu'on peut pister une voiture via ses capteurs de pneus, bon, comment dire... je suis pas tombé de ma chaise.

Mais faut reconnaître que l'étude en question va quand même plus loin qu'une discussion entre 2 stands au FIC. En effet, une équipe d'IMDEA Networks et d'armasuisse (le labo de défense suisse, rien que ça) a posé 5 récepteurs SDR dans une ville pendant 10 semaines. Coût du matos, environ 100 dollars par capteur, qui est en gros un Raspberry Pi 4 avec un dongle RTL-SDR à 25 balles. Et grâce à cela, ils ont capté plus de 6 MILLIONS de messages, provenant de plus de 20 000 véhicules !

un Raspberry Pi 4 avec un dongle RTL-SDR - Source

Car oui, vous ne le savez peut-être pas, mais les capteurs de pression des pneus (TPMS pour les intimes) émettent régulièrement dès que le véhicule roule, sur 433 MHz en Europe. Et ces signaux contiennent un identifiant unique... qui bien sûr est en clair ^^. Pas de chiffrement, pas d'authentification, QUE DALLE. Donc avec un logiciel open source comme rtl_433 , ça devient vite facile de capter tout ça à plusieurs dizaines de mètres à la ronde.

En croisant les identifiants captés par plusieurs récepteurs, les chercheurs ont pu reconstituer les trajets des véhicules, identifier leurs horaires de travail, détecter les jours de télétravail et même estimer les variations de charge du véhicule (et potentiellement déduire la présence de passagers, même si c'est encore approximatif). Le tout sans caméra, sans GPS, et sans accès au réseau du véhicule !

Il suffirait de trouver l'identifiant d'une voiture précise pour déclencher par exemple automatiquement un lâcher de confettis en papier parfaitement inoffensifs à son passage, si vous voyez ce que je veux dire.

Alors attention, tous les véhicules ne sont pas logés à la même enseigne. Les TPMS dits "directs" (dTPMS), qu'on trouve souvent chez Toyota, Peugeot, Citroën, Hyundai ou Mercedes, émettent ces fameux signaux radio captables. Alors que les systèmes "indirects" (iTPMS), utilisés par la plupart des modèles Volkswagen, Audi ou Skoda, se basent sur les capteurs ABS et n'émettent rien par radio. Bref, si vous roulez en Golf de base, y'a de bonnes chances que vous soyez tranquilles sur ce coup-là même si certaines versions sportives ou haut de gamme (Golf R, GTI selon les marchés) peuvent embarquer du dTPMS.

Et le pire dans tout ça c'est que la réglementation UN R155 sur la cybersécurité automobile n'impose pas explicitement le chiffrement des TPMS. En gros, les constructeurs ne sont pas forcés de sécuriser ces transmissions. Pirelli et Bosch bossent bien sur un "Cyber Tyre" en Bluetooth Low Energy, mais c'est réservé au haut de gamme et c'est pas demain que ça arrivera sur votre Clio.

Donc côté protection, soyons honnêtes, y'a pas grand-chose à faire côté utilisateur. Vous ne pouvez pas désactiver vos TPMS (c'est obligatoire depuis 2014 pour les voitures neuves en Europe), et les capteurs ne proposent aucune option de chiffrement. Sauf si vous roulez en véhicule vintage d'avant 2014, c'est open bar. Une des parades serait que les constructeurs implémentent un système de rotation d'identifiants, un peu comme le fait déjà le Bluetooth avec les adresses MAC aléatoires, mais pour l'instant on en est loin.

Pour ceux qui veulent creuser le sujet, j'avais fait une rencontre avec Gaël Musquet il y a quelques années, où il expliquait déjà comment reprendre le contrôle de nos véhicules connectés. Et si vous voulez comprendre comment on hacke une voiture de manière plus générale, c'est un rabbit hole sans fond !

Bref, la prochaine fois que vous gonflez vos pneus... dites-leur bonjour de ma part.

Source

Shells Unix - 5 redirections que vous copiez sans comprendre

vendredi 27 février 2026 à 09:53

2>&1, >, >>, 2>/dev/null... Si ces symboles dans votre terminal Linux ou macOS vous font autant flipper qu'un regex, respirez un grand coup ! Quand vous aurez lu cet article, vous verrez qu'en fait c'est super simple à comprendre, et en 5 minutes vous saurez enfin ce que vous copiez-collez depuis des années depuis StackOverflow.

En fait, dans les shells Unix (bash, zsh, etc.), y'a 3 canaux de base : stdin (entrée, numéro 0), stdout (sortie normale, numéro 1) et stderr (les erreurs, numéro 2). Tout le reste, de > à 2>/dev/null, découle de ces 3 numéros.

> - Écrire dans un fichier (et tout écraser)

echo "Salut" > fichier.txt

Ça redirige stdout vers fichier.txt. Si le fichier existe déjà... c'est mort, il est écrasé sans sommation. Du coup, faites gaffe avec vos logs, une commande mal placée et ce sont des heures de données qui disparaissent.

D'ailleurs, si vous êtes du genre parano (et oui, vous avez raison !), set -o noclobber dans votre .bashrc empêchera > d'écraser un fichier existant lors d'une commande tapée à la main. Pour y arriver, il faudra utiliser >| pour forcer.

>> - Ajouter à la suite

echo "Ligne 2" >> fichier.txt

Même principe que >, sauf que ça ajoute à la fin au lieu d'écraser. C'est ce que vous voulez 99% du temps pour des logs (sauf si vous voulez repartir de zéro, là > fait le job). Une lettre de différence entre "tout va bien" et "où sont passés mes logs, boudiouuu ???".

2> - Rediriger les erreurs

commande_foireuse 2> erreurs.log

Le 2 c'est stderr, en gros (y'a pas d'espace entre le 2 et le >, sinon bash croit que 2 est un argument). Tout ce qui sort en erreur finit dans erreurs.log au lieu de polluer votre terminal. Perso, je trouve ça super pratique pour garder une trace propre quand vous lancez des scripts via crontab -e.

Et 2>> existe aussi, pour cumuler les erreurs au fil du temps au lieu d'écraser le fichier à chaque exécution.

2>&1 - Fusionner erreurs et sortie normale

commande > output.log 2>&1

Le fameux ! Le &1 dit à bash "le 1 c'est un file descriptor, pas un fichier qui s'appelle littéralement 1". Du coup stderr (2) est redirigé vers le même endroit que stdout (1), ou plutôt vers là où stdout pointe au moment où bash évalue la ligne. Ça va, vous suivez toujours ? ^^

Attention, l'ordre compte ! Bash lit les redirections de gauche à droite. > output.log 2>&1, stdout pointe vers le fichier, puis stderr suit... tout va dans le fichier. 2>&1 > output.log, stderr copie stdout qui pointe ENCORE vers le terminal, puis stdout est redirigé vers le fichier. Résultat, les erreurs restent dans votre terminal. Le piège classique.

Et &> fait la même chose en plus court :

commande &> output.log

&> est super pratique, mais spécifique à bash / zsh donc pour la portabilité, préférez quand même > fichier 2>&1.

2>/dev/null - Le trou noir

find / -name "*.conf" 2>/dev/null

/dev/null, c'est le trou noir d'Unix. Tout ce que vous envoyez là-dedans disparaît. Super pratique avec find qui vous crache 200 "Permission denied" pour un seul résultat utile.

Et si vous voulez TOUT faire disparaître (stdout + stderr) ? Un petit &>/dev/null et c'est réglé. Pratique dans vos scripts /etc/cron.d/ quand vous voulez zéro bruit (bon, j'exagère un chouïa, je sais...).

Si vous aimez les raccourcis bash , j'ai aussi ce qu'il faut.

Bref, voilà ce sont juste 5 opérateurs à retenir, et avec ça vous couvrez à peu près tout. Donc la prochaine fois que vous copierez un 2>&1, au moins vous saurez pourquoi.

Source d'inspiration

sudo-rs - 40 ans de silence cassés par des astérisques

vendredi 27 février 2026 à 09:33

Si vous utilisez Ubuntu 26.04, vous avez peut-être remarqué un truc bizarre dernièrement en tapant votre mot de passe sudo... Ouiiiiii, y'a des petites étoiles qui apparaissent !! Pas de panique, c'est "normal". Enfin, c'est nouveau...

En effet, sudo-rs, la réécriture en Rust de la bonne vieille commande sudo, a décidé d'activer pwfeedback par défaut. En gros, quand vous faites un sudo apt install bidule, au lieu du trou noir habituel, vous voyez maintenant des ***** défiler pendant la saisie du mot de passe. C'est un changement qui casse une convention vieille de 40 ans... et ça, forcément, ça fait du bruit !

Pour rappel, Ubuntu a basculé sur sudo-rs (le remplaçant en Rust du bon vieux sudo en C) depuis la version 25.10. Ça fait partie du même mouvement de réécriture des outils système en Rust, comme les coreutils dont je vous avais parlé. Et la 26.04 vient de "cherry-picker" comme on dit, un patch upstream qui active le feedback visuel par défaut.

Un bug report sur Launchpad ( #2142721 ) est bien sûr arrivé direct, en mode vénère genre "*ÇA FAIT DES DÉCENNIES qu'on n'affiche pas la longueur du mot de passe pour empêcher le shoulder surfing ! C'est quoi ce bordel !!?? *"

Et la réponse des devs : Won't Fix. Circulez les relous !

En fait, leur argument c'est que le bénéfice sécurité est "infinitésimal". Parce que bon, votre mot de passe sudo c'est le même que celui de votre session (celui que vous tapez à l'écran de login, devant tout le monde). Et le bruit des touches trahit déjà la longueur de toute façon. Du coup, ils ont préféré régler le problème UX qui paume les débutants depuis le début des années 80.

D'ailleurs, en 2013 je vous expliquais comment activer ces étoiles manuellement avec sudo visudo (ça date de fou !!) et maintenant c'est l'inverse, faut expliquer comment les virer ! Linux Mint avait d'ailleurs déjà sauté le pas de son côté depuis un moment.

Perso, le truc qui me gonfle c'est pour les tutos vidéo. Quand vous faites un screencast, les astérisques révèlent la longueur de votre mot de passe à tous vos spectateurs. Du coup faut aller reparamétrer chaque machine avant de filmer ou faire du masquage en post prod. C'est pas la fin du monde, mais bon, la flemme...

Alors pour désactiver ces jolies zétoiles :

sudo visudo

Et ajoutez cette ligne à la fin de /etc/sudoers :

Defaults !pwfeedback

Sauvegardez (Ctrl+X sous nano), et c'est réglé. Attention, ne touchez à rien d'autre dans ce fichier, une erreur de typo et sudo ne marchera plus. Grâce à cette manip, ce sera retour au trou noir ! Youpi !

Source

AirSnitch - L'isolation client WiFi ne vous protège pas

vendredi 27 février 2026 à 09:25

Bon, vous connaissez la théorie du travailleur nomade... vous vous posez dans un café avec votre laptop, vous chopez du WiFi gratuit, et vous vous dites que l'isolation client du routeur vous protègera des autres branquignols connectés au même réseau.

Hé ben non ! Car des chercheurs viennent de démontrer que cette protection, c'était du vent... Oui oui, tous les routeurs qu'ils ont testés se sont fait contourner en 2 secondes.

Mais avant, pour ceux qui se demandent ce que c'est, l'isolation client c'est une option que les admins réseau activent sur les bornes WiFi pour empêcher les appareils connectés de communiquer entre eux. En gros, votre laptop ne peut pas voir celui du voisin. Enfin... ça c'est en théorie.

Parce qu'en fait, le truc c'est que cette fonctionnalité n'est même pas définie dans le standard WiFi (IEEE 802.11) ce qui oblige chaque fabricant à faire sa propre tambouille dans son coin, et du coup ça fuit de partout.

L'équipe derrière cette trouvaille, c'est des chercheurs de l'UC Riverside et de KU Leuven, dont Mathy Vanhoef, le même gars qui avait déjà mis le WPA2 à genoux avec KRACK en 2017. Pas un amateur, quoi et leur outil, baptisé AirSnitch, vient d'être présenté à la conférence NDSS 2026 .

Ils ont ainsi trouvé 3 méthodes différentes pour contourner la protection d'isolation. La première abuse de la clé de groupe (GTK), normalement réservée au broadcast, pour envoyer du trafic directement à un appareil ciblé. Le pire, c'est que macOS, iOS et Android acceptent ce trafic sans broncher (merci les gars !).

La seconde fait rebondir les paquets via la passerelle, et la troisième vole carrément l'adresse MAC de la victime sur un autre point d'accès pour intercepter son trafic.

Brrrrrr.... 11 routeurs testés, du Netgear R8000 au Cisco Catalyst 9130 en passant par TP-Link, ASUS, Ubiquiti et même OpenWrt 24.10. Et ils sont TOUS vulnérables, sans exception ! Et que vous soyez en WPA2 ou en WPA3, réseau perso ou entreprise, c'est pareil. Donc autant vous dire que ça pue !

Ils ont même réussi à effectuer un Man-in-the-Middle complet (interception de tout le trafic entre vous et Internet) en 2 secondes chrono. La "victime" qui regardait YouTube n'a même pas remarqué de lag et c'est comme ça qu'ils on pu intercepter tout son trafic, ni vu ni connu.

Alors du coup, on fait quoi ? Hé bien si vous gérez un réseau, oubliez l'isolation client toute seule et passez aux VLANs avec un VLAN par client. Oui c'est lourdingue à mettre en place, mais c'est le prix à payer pour avoir une sécurité solide. Certains constructeurs bossent aussi sur des clés de groupe individuelles par client, ce qui règlerait le problème à la source.

Côté utilisateur, la solution est plus simple... VPN !! Attention, ça ne marche que si le VPN est activé AVANT de vous connecter au réseau, pas après. HTTPS vous protège déjà pour le contenu des sites, mais selon Google, 6 à 20% des pages ne sont toujours pas en HTTPS... et même quand elles le sont, l'attaquant voit quand même où vous surfez et peut tenter du DNS spoofing. Donc sur n'importe quel réseau WiFi public , partez du principe que quelqu'un peut voir votre trafic, parce que visiblement c'est le cas.

Le code source d' AirSnitch est dispo sur GitHub si vous voulez tester votre propre config mais notez que ça nécessitera une carte WiFi compatible avec le mode monitor comme les Alfa (lien affilié), donc pas celle de votre laptop de base.

Bref, la prochaine fois que le WiFi de l'hôtel vous demande d'accepter les CGU en échange d'un accès "sécurisé"... ben gardez votre VPN allumé, hein.

Source

PinMe - Le web immuable en une commande

vendredi 27 février 2026 à 09:07

Les 404, c'est la plaie du web... J'en sais quelque chose, je fais la chasse à ça en permanence sur mon propre site. C'est vrai que c'est relou parce que vous bookmarkez un projet cool, vous y retournez trois mois après... et pouf, ça a disparu. Le dev n'a pas renouvelé son nom de domaine, l'hébergeur a fermé boutique, le contenu s'est évaporé ou que sais-je encore... En fait, sur le web, RIEN n'est permanent.

PinMe prend le problème à l'envers en collant vos fichiers directement sur IPFS . En gros, au lieu de dépendre d'un serveur unique qui peut tomber n'importe quand, vos pages sont distribuées sur un réseau décentralisé et identifiées par un hash CID unique. Du coup, tant que le réseau tourne, votre contenu existe. Pas besoin de renouveler quoi que ce soit, pas besoin de payer un hébergeur... ça fonctionne tout seul.

L'installation se fait en une ligne :

npm install -g pinme

Pour déployer votre site statique, c'est hyper simple :

pinme upload dist/

L'outil détecte le dossier de build, ou plutôt il le devine tout seul selon votre framework : dist/ pour Vite et Vue, build/ pour Create React App, out/ pour Next.js en export statique. Ça évite d'avoir à se palucher de la config.

Côté limites, on est sur 200 Mo par fichier et 1 Go au total ce qui est largement suffisant pour une landing page ou une démo ! Et c'est GRATUIT. Pour ceux qui veulent un domaine lisible plutôt qu'un hash cryptique, y'a aussi des domaines ENS (les .eth sur Ethereum) ou des sous-domaines en .pinit.eth.limo. Après pour les domaines custom faudra un compte VIP par contre.

Le truc sympa c'est que vos fichiers restent accessibles via n'importe quelle passerelle IPFS, genre dweb.link ou w3s.link. Ainsi, si votre hébergeur ferme ou que votre domaine expire comme je le disais en intro, on s'en fiche ! Le contenu est toujours là, épinglé quelque part sur le réseau. C'est du stockage immuable, basé sur le contenu lui-même... du coup personne ne peut modifier ou supprimer ce que vous avez publié. (Et en fait vous non plus, faut le savoir.)

Et y'a aussi des commandes pour exporter en fichiers CAR et réimporter ailleurs, ce qui est pratique pour archiver ou migrer entre passerelles.

Voilà c'est gratuit pour 1 Go de stockage, c'est open source (licence MIT) et c'est par là . Merci à Lorenper pour la découverte !