Ce clone de Game Boy tournait trop vite, un seul composant a tout réglé
Il existe une catégorie d'objets qu'on achète sur un coup de tête, qu'on déballe avec enthousiasme, et qu'on range au fond d'un tiroir une demi-heure plus tard parce qu'ils sont tout bonnement inutilisables. La GB Boy de Sharopolis appartenait pile à cette catégorie. Commandée sur AliExpress il y a des années, puis oubliée.
Le principe de cette console portable est pourtant séduisant sur le papier, puisqu'elle reprend le design d'une Game Boy Pocket tout en acceptant les vraies cartouches d'origine, celles-là mêmes que vous avez peut-être encore dans une boîte à chaussures, au lieu de se contenter d'une puce bourrée de jeux pré-installés comme le font la plupart des clones chinois. Le fabricant, lui, répond au nom de Gangfeng.
Sauf qu'il y avait un gros défaut. Les jeux tournaient beaucoup trop vite. Pas juste un peu rapides, non, carrément accélérés au point que la musique partait en vrille, que les ennemis fonçaient à travers l'écran et que le moindre saut de Mario devenait un pari impossible à réussir. Injouable.
Pour remonter à la source du problème, Sharopolis a sorti le tournevis, ouvert la coque et méthodiquement comparé chaque composant de sa carte avec ceux qui équipent une vraie Game Boy Pocket signée Nintendo. Le coupable n'a pas mis longtemps à se montrer.
Il s'agit d'un petit quartz, repéré sous la référence X1 sur la carte. Ce composant joue le rôle d'horloge, c'est lui qui impose son tempo à toute la machine, exactement comme le métronome qui dicte la cadence à un orchestre entier et sans lequel chaque musicien jouerait dans son coin.
Et la valeur affichée n'était pas la bonne. Là où une Game Boy Pocket d'origine cadence son processeur à 4,194304 MHz, une fréquence d'une précision presque maniaque retenue par Nintendo à l'époque, la GB Boy embarquait pour sa part un quartz calé à 5 MHz tout rond. Près de 20 % d'écart. D'où cette sensation de jeu en avance rapide permanente.
Le reste de la carte, lui, force presque l'admiration tant il est dépouillé, avec une puce principale estampillée KF2001 chargée de reproduire à elle seule toute la logique interne d'une Game Boy, deux modestes puces de mémoire à ses côtés, et puis plus grand-chose. Le tout pour une console vendue une poignée d'euros.
La réparation, elle, tient en réalité à pas grand-chose. Sharopolis avait justement sous la main une bobine de cent résonateurs déjà calés sur la fréquence d'origine, alors il a dessoudé sans état d'âme le quartz à 5 MHz, posé un modèle correct à sa place, et regardé les jeux retrouver instantanément le rythme exact que Nintendo avait prévu pour eux il y a près de trente ans. Un composant. C'est tout ce qu'il aura fallu.
Enfin, presque. Parce qu'une fois la vitesse remise d'aplomb, un nouveau souci a pointé le bout de son nez, l'écran s'étant mis à scintiller d'une manière franchement pénible, et plusieurs habitués du fer à souder accusent déjà, dans les commentaires de la vidéo, les condensateurs bas de gamme soudés un peu partout sur la carte, ces pièces à quelques centimes qu'il faudrait remplacer une par une pour espérer enfin un affichage parfaitement stable. Mais bon, tout ne pouvait pas être si simple…
Source : Hackaday
Votre voiture peut devenir un objet connecté de plus dans votre maison
Branchez un petit boîtier dans la prise de diagnostic de votre voiture, et celle-ci se met à remonter son niveau de carburant, sa température moteur ou la pression de ses pneus directement dans votre système domotique, au même titre qu'une ampoule connectée ou un thermostat.
C'est la démonstration faite par un vidéaste connu sous le nom de The Stock Pot, repérée par Maya Posch sur Hackaday. L'idée, c'est de faire dialoguer une auto avec Home Assistant, le logiciel open source qui centralise tous les objets connectés d'une maison.
Le matériel tient dans la main. Il s'agit d'un dongle WiCAN, un boîtier basé sur la puce ESP32-S3, fabriqué par la petite société australienne MeatPi. Cette ESP32, c'est une puce Wi-Fi minuscule et bon marché qu'on retrouve dans une foule d'objets connectés faits maison.
Vous le branchez sur le port OBD-II, cette prise normalisée présente sur toutes les voitures vendues depuis le début des années 2000, celle que le garagiste utilise pour lire les codes défaut. Le boîtier s'allume tout seul dès que la voiture est sous tension.
Ensuite, il se configure en Wi-Fi exactement comme n'importe quel objet connecté, et rejoint votre réseau domestique. Rien de sorcier. À partir de là, Home Assistant le voit comme un appareil parmi les autres.
Pour dire ça plus simplement, vous pouvez suivre depuis votre téléphone le niveau du réservoir, l'intervalle avant la prochaine révision, la température du liquide de refroidissement ou encore la pression des pneus, et récupérer au passage les alertes moteur et batterie. De quoi savoir si l'auto a assez d'essence avant même de descendre dans le garage.
Le firmware WiCAN est open source et disponible sur GitHub, et The Stock Pot a partagé sa propre configuration au format YAML, le fichier texte qui décrit à Home Assistant quoi afficher et comment.
Sauf que voilà, ce n'est pas vraiment du plug-and-play. Chaque constructeur range les données à sa façon dans le calculateur de la voiture, ce qui passe par le CAN bus, le réseau interne par lequel tous les ordinateurs de bord se parlent. Du coup, il faut un réglage spécifique à chaque modèle, comme le précise d'ailleurs la documentation officielle de MeatPi.
Le dongle ne se limite pas à Home Assistant. Il fait aussi le pont vers MQTT, un protocole de messagerie léger très utilisé en domotique, et sait alimenter des applis comme RealDash pour fabriquer des tableaux de bord sur mesure. Il passe même en veille sous le milliampère quand la tension chute, histoire de ne pas vider la batterie pendant que la voiture dort. Pas mal comme idée non ?
Source : Hackaday
Vos données de navigation appartiennent-elles encore à quelqu'un ?
Posez la question à votre fournisseur d'accès internet. Orange, Free, Bouygues, SFR (ah non, RIP petit opérateur partit trop tôt) vous répondront poliment qu'ils respectent la loi. Et c'est vrai. La Loi de programmation militaire (LPM) en France, impose depuis plus de 10 ans aux FAI de conserver certaines métadonnées de connexion pendant un an.
Ce n'est pas le contenu de vos échanges. Pas vos emails, pas vos messages, pas ce que vous téléchargez. Mais assez d'informations pour reconstituer une carte détaillée de votre vie numérique. Quand vous vous connectez, depuis où, vers quels serveurs, pendant combien de temps.
Ce n'est pas une théorie du complot. C'est le cadre légal actuel. Et si cela ne vous dérange pas, tant mieux. Mais si l'idée que vos trajets numériques soient archivés par défaut vous interroge, il existe des moyens de reprendre la main. Un VPN comme Surfshark en fait partie, pas comme solution magique, mais comme outil de réduction de surface d'exposition.
Ce que votre FAI voit réellement
Quand vous naviguez sans protection, votre fournisseur d'accès a une vue directe sur votre trafic. Il ne lit pas nécessairement le contenu, grâce au chiffrement HTTPS, mais il observe les métadonnées :
- Les adresses IP des serveurs que vous contactez
- Les horaires et durées de vos sessions
- Le volume de données échangées
- Votre adresse IP publique, donc votre localisation approximative
L'air de rien ces informations, combinées, permettent pas mal de ciblage. Vos habitudes de sommeil, vos centres d'intérêt, vos relations professionnelles, voire vos opinions politiques. Pas besoin d'accéder au contenu pour dresser un profil comportemental précis.
La conservation légale de ces métadonnées vise officiellement la lutte contre le terrorisme et la criminalité organisée. Sauf qu'une fois stockées, ces données deviennent exploitables pour des réquisitions judiciaires, demandes administratives ou fuites accidentelles (et on voit chaque semaine le niveau des leaks made in hexagone). Plus il y a de copies, plus le risque augmente.
Ce qui change quand vous ajoutez un VPN
Activer un VPN comme Surfshark modifie fondamentalement ce que votre FAI peut observer. Votre trafic est chiffré entre votre appareil et le serveur VPN. Votre FAI voit toujours que vous êtes connecté, et il voit le volume de données échangées. Mais il ne voit plus les destinations finales. Tout transite vers une seule adresse IP, celle du serveur Surfshark.
Concrètement, au lieu de savoir que vous avez consulté tel site de santé, tel forum politique ou telle plateforme de signalement à telle heure, votre FAI constate uniquement une connexion chiffrée vers un serveur VPN. Le reste lui est invisible. La question se déplace et devient "faites-vous confiance à Surfshark plutôt qu'à votre FAI ?" C'est un choix conscient, pas une délégation aveugle. Et plusieurs éléments techniques permettent d'évaluer ce choix.
Les garde-fous techniques de Surfshark
La politique no-logs de Surfshark n'est pas une simple déclaration. Elle a été auditée à deux reprises par Deloitte (en 2024 et 2025), son infrastructure par SecuRing (en 2026), son protocole Dausos par Cure53 (2026), etc. Les rapports sont publics et détaillent les méthodes de vérification de l'inspection de l'infrastructure, à l'analyse du code client en passant par la revue des processus internes.
Autre point important, la majorité des serveurs Surfshark fonctionnent en mode RAM-only. Aucune donnée ne persiste sur disque. En cas de saisie physique d'un serveur ou d'intrusion, il n'y a tout simplement rien à récupérer. C'est du hardening au sens littéral.
La juridiction compte aussi. Surfshark est basé aux Pays-Bas, un pays membre de l'Union européenne, mais avec un cadre légal distinct de la France. Les réquisitions françaises ne s'appliquent pas automatiquement. Cela ne rend pas le service immunisé, disons que cela ajoute une couche de complexité juridique qui peut dissuader certaines demandes (probablement pas beaucoup, mais bon).
Le chiffrement utilisé (AES-256-GCM ou ChaCha20 selon l'appareil) protège le contenu du trafic contre l'interception. Le Kill Switch, en mode strict, coupe toute connexion si le tunnel VPN tombe, évitant les fuites accidentelles d'IP. La protection contre les fuites DNS et WebRTC empêche que votre véritable adresse ne filtre via des canaux secondaires.
Et Dausos dans tout ça ?
Surfshark a récemment développé son propre protocole, Dausos, et cette évolution touche directement la question de la souveraineté des données. Dausos fonctionne avec des tunnels dédiés par utilisateur, contrairement aux architectures classiques qui mutualisent le trafic de plusieurs sessions sur les mêmes canaux. Cette isolation réduit les risques de corrélation croisée. Même en cas d'analyse poussée des logs serveur, il devient plus difficile de relier des activités entre différents utilisateurs partageant la même infrastructure.
Le protocole utilise également AEGIS-256X2 pour le chiffrement, un algorithme moderne optimisé pour les processeurs récents. En plus d'offrir de meilleures performances, il maintient un niveau de sécurité équivalent aux standards actuels tout en étant conçu pour résister à certaines attaques cryptanalytiques avancées.
Autre élément notable, ce nouveau protocole intègre nativement une résistance post-quantique. Cela signifie que même si des acteurs stockent aujourd'hui votre trafic chiffré en attendant de pouvoir le déchiffrer demain avec un ordinateur quantique, cette stratégie devient beaucoup moins rentable. Vos métadonnées restent protégées sur le long terme.
Enfin, Dausos adapte dynamiquement ses paramètres selon la qualité du réseau. Si vous passez d'un Wi-Fi stable à une connexion mobile instable, le protocole ajuste son comportement pour maintenir le tunnel sans interruption. Cela évite les micro-coupures qui pourraient exposer temporairement votre trafic réel. Dausos est actuellement disponible en bêta sur macOS via l'App Store, avec un déploiement progressif prévu sur les autres plateformes.
Les limites à garder en tête
Utiliser un VPN ne vous rend pas invisible. Cela déplace le point de confiance. Votre FAI ne voit plus vos destinations, mais le fournisseur VPN, lui, pourrait théoriquement les observer. C'est précisément pour cette raison que la politique no-logs et ses audits indépendants sont essentiels. Si le fournisseur ne conserve rien, même sous contrainte légale, il n'y a pas de données à divulguer.
Une autre limite est que le VPN ne protège que le trafic qui transite par lui. Si vous vous connectez à un service en étant déjà authentifié (compte Google, réseau social), ce service continue de tracer votre activité, indépendamment du VPN. La protection réseau ne remplace pas une hygiène de compte rigoureuse. Enfin, la performance peut être impactée. Surfshark minimise cet effet grâce à WireGuard et encore plus via Dausos, mais un détour par un serveur VPN ajoute inévitablement un peu de latence. C'est le prix de la confidentialité.
Mettre en pratique
Si vous décidez d'utiliser Surfshark pour renforcer votre souveraineté numérique, quelques réglages méritent attention. Activez le Kill Switch en mode strict. Cela garantit qu'aucune donnée ne sort de votre appareil sans être chiffrée par le tunnel VPN.
Vérifiez l'absence de fuites DNS. Surfshark propose ses propres résolveurs DNS chiffrés, mais un test ponctuel via un outil comme dnsleaktest.com permet de confirmer que tout transite bien par le tunnel. Si vous êtes sur macOS, testez Dausos dans les paramètres de protocole. L'isolation des tunnels et l'adaptation dynamique peuvent apporter un bénéfice tangible, surtout sur des réseaux variables.
Enfin, documentez votre configuration. Notez les serveurs que vous utilisez, les protocoles activés, et la procédure de secours. La sécurité ne vaut que si elle est reproductible.
Et quand vous partez en voyage ?
Il y a un autre cas d'usage qui revient souvent quand on parle VPN et que je trouve assez sous-estimé, c'est le voyage. Vous partez en vacances ou en déplacement pro à l'étranger, et là, surprise, votre abonnement Netflix vous propose un catalogue complètement différent. Votre playlist Spotify perd des morceaux. Votre replay France TV refuse carrément de se lancer. Et ce documentaire Arte que vous vouliez finir dans le train ? Pas disponible.
Ce n'est pas un bug, c'est juste la géolocalisation par IP qui fait son boulot. Les plateformes déterminent ce qu'elles vous montrent en fonction du pays depuis lequel vous vous connectez, à cause des accords de licence régionaux. Sauf que vous, vous payez déjà votre abonnement en France, et l'idée de ne plus pouvoir regarder vos propres contenus parce que vous avez traversé une frontière, c'est franchement frustrant.
Connecter Surfshark à un serveur français pendant que vous êtes à l'étranger résout ce souci. Vos applis vous voient comme si vous étiez à la maison, votre catalogue habituel revient, et vous continuez à profiter de ce pour quoi vous payez déjà. Bonus non négligeable, le tunnel chiffré vous protège aussi des Wi-Fi d'hôtel et d'aéroport, qui ne sont franchement pas réputés pour leur hygiène réseau.
Petit rappel quand même, les VPN sont légaux dans la plupart des pays, mais utiliser un VPN pour accéder à un service en dehors de sa zone de licence peut enfreindre les conditions d'utilisation de la plateforme. Donc on reste sur l'usage "mes contenus, mon abonnement, juste en voyage", et on ne s'amuse pas à aller piocher dans les catalogues étrangers où on n'a pas les droits.
Mon point de vue
Je ne vois pas le VPN comme une solution absolue, c'est un outil de réduction de risque. En déplaçant la confiance de votre FAI vers un fournisseur qui affirme ne rien conserver, et qui le prouve par des audits publics, vous changez l'équation. Ce qui me convainc chez Surfshark, c'est la transparence sur ce qui est vérifiable. Pas de promesses vagues, pas de "we take privacy seriously" générique. Des rapports d'audit, des spécifications techniques, des explications claires sur les limites. Pour certains, ce compromis vaut le coup. Pour d'autres, non. L'important est de décider en connaissance de cause. Pas par défaut. Pas par peur. Mais par choix réfléchi.
L'arrivée de Dausos montre que l'éditeur n'attend pas que les standards évoluent pour adapter son offre. Développer un protocole maison, avec des choix techniques assumés comme les tunnels dédiés ou le chiffrement AEGIS, c'est prendre le contrôle sur la pile technique plutôt que de subir les contraintes des solutions génériques.
Est-ce que cela suffit à garantir une souveraineté totale ? Non. Mais cela réduit significativement la quantité de données exploitables stockées par des tiers, même légaux. Et dans un contexte où la conservation par défaut devient la norme, c'est déjà un levier d'action concret. La souveraineté des données ne se décrète pas. Elle se construit par des choix techniques conscients. Utiliser un VPN n'efface pas le cadre légal de conservation des métadonnées. Mais cela rend ce cadre moins opérant pour tracer vos activités spécifiques.
L'offre du moment
Côté tarif, Surfshark reste l'un des plus agressifs du marché : 2,4€ par mois (TTC) sur un engagement de 24 mois, trois mois offerts en plus (du coup le prix tombe à 2,13€ environ), et une garantie de remboursement d'un mois pour tester sans risque.
Le tout avec une couverture illimitée d'appareils, ce qui carrément intéressant si vous avez plusieurs terminaux à protéger dans la famille.
Profitez de l'offre Surfshark !
Ce lien est affilié. Cela n'impacte ni le prix que vous payez ni mon opinion sur le service. Mais cela participe au financement de ce site, en alternative aux régies publicitaires intrusives.
Libinput corrige une faille qui transformait une fausse manette en accès root
La bibliothèque libinput est passée en version 1.31.2, et pas pour ajouter des fonctions, mais pour boucher un trou de sécurité plutôt vilain. C'est elle qui gère vos périphériques d'entrée (clavier, souris, pavé tactile, manette) sur la quasi-totalité des Linux modernes, aussi bien sous Wayland que sous l'ancien serveur graphique X.Org.
Autant dire qu'elle tourne sur presque toutes les machines de bureau sous Linux, des plus grand public aux plus pointues.
Le problème permettait d'exécuter du code arbitraire avec les droits root, c'est-à-dire les pleins pouvoirs sur le système. Et tout ça en passant par un détail qu'on n'imagine pas dangereux, le nom physique d'un faux périphérique.
Sur Linux, n'importe quel logiciel peut fabriquer un périphérique virtuel via deux interfaces du noyau, uinput et uhid. Pour les regrouper, libinput s'appuie sur udev, le composant qui détecte et configure tout ce qu'on branche sur la machine.
Et c'est là que ça coince. Un attaquant pouvait créer un appareil bidon dont l'attribut PHYS, le chemin physique du matériel, contenait un simple retour à la ligne. Du coup, udev lisait cette unique valeur comme deux lignes séparées, donc deux paires clé-valeur, dont une totalement injectée par l'attaquant.
Cette ligne injectée suffisait à détourner le comportement de udev et, au bout de la chaîne, à faire tourner la commande de son choix en root. Une injection par saut de ligne. Bête, mais redoutable.
Reste une nuance importante. Fabriquer un tel périphérique demande normalement les droits root, ce qui limite déjà beaucoup le danger. Sauf que certaines règles udev personnalisées ouvrent la porte aux utilisateurs normaux.
L'exemple cité est parlant. Installer le paquet "steam-devices" sur Fedora, ce que fait n'importe quel joueur pour que ses manettes soient correctement reconnues, suffit à exposer la faille à toute personne connectée à la session. Un geste parfaitement banal, donc.
La faille a été repérée par un chercheur surnommé Csome, et Peter Hutterer, le mainteneur historique de libinput, a publié le correctif dans la 1.31.2. La marche à suivre tient en une ligne, mettre à jour dès que votre distribution pousse le paquet.
Une faille root planquée dans le nom d'une fausse manette, déclenchée par un paquet aussi anodin que celui de Steam, ça a quand même quelque chose de franchement pénible.
Source : Phoronix
Webcamoid, ou comment fabriquer une fausse webcam sous Linux sans toucher à une ligne de commande
Sur Linux, faire passer une vidéo trafiquée pour un vrai flux de webcam dans Zoom ou Discord, ça se fait depuis longtemps. Le souci, c'est que la méthode classique demande de taper des commandes assez obscures dans un terminal. Webcamoid propose de tout faire plus simplement.
Une webcam virtuelle, c'est une fausse caméra logicielle. Votre système et vos applis la voient comme une vraie webcam branchée en USB, sauf qu'à l'autre bout il n'y a aucun capteur : juste une vidéo que vous avez choisie, modifiée ou carrément bricolée avant de l'envoyer.
Webcamoid, c'est justement une application gratuite et open source écrite par l'Argentin Gonzalo Pedone, qui tourne aussi bien sur Linux que sur Mac, Windows, Android ou FreeBSD. Elle se place entre le petit visualiseur de webcam basique et les usines à gaz comme OBS Studio, le logiciel star du streaming.
Le principe est simple. Vous choisissez votre vraie caméra comme source, vous appliquez les effets que vous voulez parmi la soixantaine proposée, puis vous envoyez le résultat vers une caméra virtuelle. Les autres logiciels n'y voient que du feu.
À quoi ça sert concrètement ? À flouter ou remplacer votre arrière-plan pendant une visio, plaquer un filtre sur votre tête, ou carrément diffuser une vidéo enregistrée à l'avance pendant que vous êtes parti faire un café. Webcamoid sait d'ailleurs prendre comme source autre chose qu'une caméra : un fichier vidéo posé sur votre disque, un flux réseau, ou même une capture de votre écran.
Pour créer cette fausse caméra, deux pilotes sont possibles, un pilote étant le bout de logiciel qui fait le pont entre le matériel et le système. D'un côté v4l2loopback, qui marche en ligne de commande avec un modprobe et trois options. De l'autre AkVCam, plus carré, qui se configure via des fichiers et que Webcamoid préfère utiliser.
Bref, un outil qui pourrait bien vous servir de temps en temps, même si l'installation et la mise en route n'est pas toujours très fluide, comme ça a été raconté chez nos confrères de Hackaday.
Des circuits électroniques cuits dans de l'argile, et ça marche vraiment
Emily Velasco , bricoleuse et artiste américaine, a fabriqué une carte électronique fonctionnelle à partir d'un simple disque d'argile tourné à la main, sans la moindre plaque de fibre de verre ni le moindre bain d'acide qu'on associe d'habitude à ce genre d'objet.
L'idée vient d'ailleurs. Elle raconte avoir été inspirée par un collectif de hackeuses européennes qui fabriquait ses propres circuits à partir d'argile creusée dans le sol et cuite dans un feu de camp, et comme elle développait déjà depuis un moment ses propres émaux au cuivre pour la poterie, elle a décidé de pousser l'expérience un cran plus loin.
Une carte de circuit imprimé classique, ce rectangle vert qu'on trouve dans à peu près tous nos appareils, c'est en général du FR4, un sandwich de fibre de verre et de résine époxy sur lequel on grave des pistes de cuivre à l'acide pour relier les composants entre eux. Velasco a tout remplacé par de la terre et de l'émail.
Son procédé tient en quelques gestes. Elle a fabriqué un tampon qu'elle presse dans l'argile encore molle pour y imprimer le dessin du circuit en creux, puis elle remplit ces sillons d'un mélange de poudre de cuivre et d'émaux de poterie tout ce qu'il y a de plus ordinaires, du transparent et du céladon vert, le genre de produits qui traînent dans n'importe quel atelier (il existe aussi des émaux au cuivre qu'on utilise dans la cuisson raku, cette technique de poterie d'origine japonaise). Passage au four de potier, et l'ensemble fusionne.
Le résultat est marrant. C'est un multivibrateur astable, autrement dit le petit circuit tout bête qui fait clignoter deux LED en alternance, et il est intégralement cuit dans la céramique.
Le plus surprenant, c'est que ça conduit pour de vrai. Les pistes en émail au cuivre affichent une résistance électrique étonnamment basse une fois sorties du four, ce qui n'avait rien d'évident sur le papier.
Tout n'a pas été simple pour autant. L'émail vitrifié refusait catégoriquement de prendre la soudure, même avec du flux de plomberie, et Velasco a dû gratter la surface à la brosse métallique montée sur une Dremel avant que l'étain veuille bien accrocher. Son verdict sur le rendu, elle l'assume : "C'est moche, mais ça marche."
Le solarpunk, du coup. Derrière ce terme un peu fourre-tout se cache un courant qui rêve d'un futur écolo et optimiste, où la débrouille et le fait-maison prennent le pas sur l'industrie lourde et polluante. Une carte façonnée avec de la terre, un four et de la poudre de métal, sans résine pétrochimique ni bain chimique, tout ceci est improbable.
Il faut quand même garder les pieds sur terre. On est à des années-lumière des céramiques techniques industrielles, ce fameux LTCC qu'on retrouve dans l'aérospatial ou les hyperfréquences, avec leurs propriétés électriques quasi parfaites et leur conduction de la chaleur exemplaire. Ici, on fait clignoter deux LED sur un bout de poterie ratée. Mais c'est justement tout l'intérêt.
Honnêtement ? Voir un circuit qui marche sortir d'un four à céramique, c'est franchement réjouissant. D'ailleurs souvenez-vous, ce genre d'expérience avait déjà faite avec de l'argile, et c'est à lire ici : Comment fabriquer des circuits imprimés en argile !
Il a transformé sa radio CB en station pilotable depuis un navigateur web
Un bidouilleur connu sous le pseudo ThatCrazyDcGuy a réussi à rendre sa radio CB entièrement pilotable depuis une simple page web, et la prouesse tient surtout à ce qu'il y soit parvenu sans pratiquement ouvrir l'appareil ni modifier le moindre composant d'origine de la machine.
L'engin en question est une Albrecht AE-5900 Mini SSB, une petite radio européenne de la fameuse Citizens Band, cette bande publique située autour de 27 MHz que les routiers et les passionnés utilisent depuis des décennies pour discuter librement, sans licence ni abonnement, et que ce modèle exploite jusqu'à 12 watts en mode SSB tout en affichant la fréquence et le niveau de signal sur un écran couleur.
Le point de départ du projet repose sur une particularité assez sympa du boîtier, puisque l'AE-5900 a la bonne idée de pouvoir être entièrement commandé depuis son micro d'origine, le AMM-500, lequel dialogue avec la radio en lui transmettant des codes en hexadécimal sur une banale liaison série, exactement comme deux puces qui s'échangeraient des instructions.
Plutôt que de toucher au circuit, ThatCrazyDcGuy s'est donc inséré pile au milieu de cette conversation entre le micro et la radio, en concevant un montage qui se fait passer pour le AMM-500 et rejoue les bonnes commandes au bon moment, si bien que l'électronique d'origine ne se rend compte de rien et continue d'obéir comme si tout était normal.
Côté matériel, l'ensemble reste étonnamment sobre, puisqu'un adaptateur FTDI, cette petite puce chargée de traduire l'USB en liaison série, gère toute la partie contrôle pendant qu'une carte son USB équipée de transformateurs d'isolation s'occupe de l'audio, le tout étant regroupé derrière un connecteur RJ45 et soudé sur une plaque à pastilles glissée dans un boîtier minuscule.
Le rôle de cerveau revient quant à lui à un Raspberry Pi, ce mini-ordinateur grand comme une carte bancaire, sur lequel tourne un script écrit en Python et reposant sur le framework Flask, qui se charge à lui seul de générer l'intégralité de l'interface web consultée par l'utilisateur.
Cette interface n'a d'ailleurs rien d'un gadget puisqu'elle expose le bouton PTT (le push-to-talk, c'est-à-dire la pédale qu'on presse pour parler), le déclenchement à la voix, le balayage des canaux à vitesse réglable, ainsi que le squelch, le clarifier et le réglage du volume du micro, alors que la voix elle-même transite par Mumble, un logiciel de voix sur IP capable de transporter le son en temps réel, ce qu'une page web seule serait bien incapable de faire.
Le système prévoit même un garde-fou plutôt rassurant, car en cas de coupure de la connexion un coupe-circuit interrompt automatiquement l'émission au bout de trente secondes, histoire d'éviter qu'une radio reste bloquée à émettre toute seule dans le vide pendant des heures sans que personne ne s'en aperçoive.
Pour piloter le poste depuis l'autre bout du pays et plus seulement sur le réseau local de la maison, le projet s'appuie enfin sur Tailscale, un outil qui tisse un réseau privé chiffré entre les différentes machines sans qu'on ait à reconfigurer sa box (que j'utilise d'ailleurs au quotidien), l'ensemble du code est disponible publiquement sur GitHub sous le nom AE5900_Remote_V2.
Ce qui est sympa dans cette réalisation, c'est justement qu'elle ne charcute rien du tout, sans conversion de bande hasardeuse ni fer à souder plongé dans les entrailles de l'émetteur, l'auteur se contentant de parler le même langage que le micro pour, dit-il, redonner un peu d'attrait à une CB que le smartphone a depuis longtemps reléguée au placard.
Franchement, piloter une radio de l'âge des routiers depuis un onglet de navigateur, c'est quand même bien rigolo.
HTTP/2 Bomb : une mini-requête suffit pour faire tomber nginx, Apache ou IIS
Il y a des failles qui réclament un arsenal de hacker chevronné, et puis il y a HTTP/2 Bomb, qui se contente de quelques kilo-octets pour faire vaciller des serveurs parmi les plus utilisés de la planète. Dévoilée le 2 juin sous la référence CVE-2026-49975, elle s'attaque à HTTP/2, le protocole qui transporte une bonne partie des pages que vous consultez chaque jour.
Le résultat ressemble à une mauvaise blague. Une poignée d'octets envoyés au bon endroit, et la mémoire vive du serveur se met à enfler jusqu'à engloutir des dizaines de gigaoctets en quelques secondes, jusqu'à ce que la machine ne réponde plus à personne.
On parle ici d'une attaque par déni de service, un DoS dans le jargon, dont le but n'est pas de dérober quoi que ce soit mais d'asphyxier le serveur. Rien de bien neuf, donc, sauf que l'ampleur du désastre, elle, l'est totalement.
Toute l'astuce tient dans le mariage de deux mécanismes connus depuis des lustres. HTTP/2 sait compresser les en-têtes des requêtes pour éviter de répéter cent fois la même chose, et c'est précisément cette générosité que l'attaquant retourne contre le serveur, en faisant référence des milliers de fois à un en-tête glissé une seule fois, si bien que la machine réserve de la mémoire à tour de bras pour quelque chose qui, au départ, ne pèse presque rien. C'est le principe de la bombe de décompression, ce fichier piégé minuscule qui se déplie en montagne de données dès qu'on l'ouvre.
Et comme si ça ne suffisait pas, l'attaquant fait mine de ne pas pouvoir recevoir la réponse, ce qui interdit au serveur de boucler sa tâche et de relâcher ce qu'il a accumulé. Quelques octets envoyés de loin en loin, et la connexion reste ouverte indéfiniment. C'est diabolique de simplicité.
Les chiffres, eux, font carrément peur. Sur Envoy, les chercheurs ont mesuré un rapport de plus de 5 000 pour 1, avec 32 Go engloutis en une dizaine de secondes, là où Apache craque en moins de vingt secondes et nginx comme IIS en moins d'une minute. Une simple connexion domestique à 100 Mb/s peut donc mettre à genoux une infrastructure entière.
Le plus déroutant dans cette histoire, c'est que les deux ingrédients de la recette traînaient en accès libre depuis des années. Il aura fallu attendre l'équipe de Codex, et le chercheur Quang Luong, pour avoir l'idée de les mélanger et constater les dégâts.
Du côté des correctifs, tout le monde n'est pas logé à la même enseigne. nginx a réagi avec sa version 1.29.8 et une nouvelle option pour brider les en-têtes, Apache a corrigé dans mod_http2 2.0.41, mais Microsoft IIS, Envoy et Cloudflare Pingora attendaient encore leur rustine au moment de la divulgation.
Bref, vieille recette, ingrédients connus, mais cocktail dévastateur. Si vous gérez un serveur en HTTP/2, allez vérifier vos versions avant qu'on ne teste la recette à votre place.
Source : The Hacker News
ls, grep, cp : Microsoft fait entrer les commandes Linux nativement dans Windows
À sa conférence Build 2026, le 2 juin, l'éditeur a lancé Coreutils for Windows, un paquet qui amène directement dans Windows les commandes de base bien connues des utilisateurs de Linux.
On parle des classiques du terminal, ls pour lister des fichiers, cp pour copier, mv pour déplacer, grep pour chercher du texte, ou encore cat, find et rm. Au total, près de 75 petites commandes que tout bidouilleur tape machinalement sans même y penser.
Le but affiché est simple. Les développeurs jonglent en permanence entre Windows, macOS et Linux, et s'agacent quand une commande qui marche d'un côté refuse obstinément de fonctionner de l'autre. L'idée, ici, c'est de pouvoir réutiliser les mêmes commandes et les mêmes scripts partout, sans rien réécrire.
Le plus intéressant, c'est ce qu'il y a sous le capot. Et là, surprise. Coreutils for Windows ne réinvente rien, puisqu'il s'appuie sur uutils, un projet communautaire qui réécrit les fameux coreutils de GNU en Rust, un langage réputé pour éviter toute une famille de bugs mémoire.
Autrement dit, Microsoft reprend un travail open source mené par la communauté, l'empaquette proprement et le maintient sous son nom. Le tout s'installe en une seule ligne via WinGet, le gestionnaire de paquets maison de Windows, avec un simple winget install Microsoft.Coreutils.
Côté technique, l'astuce est plutôt élégante. Plutôt que de livrer un exécutable par commande, Microsoft fournit un unique programme, coreutils.exe, et crée à l'installation une série de raccourcis (ls.exe, cp.exe, grep.exe et les autres) qui pointent tous vers lui. Selon le nom que vous tapez, ce programme sait quelle casquette enfiler. Malin.
Tout n'a pas fait le voyage, cela dit. Des commandes comme chmod, chown ou kill restent sur le carreau, faute d'équivalent propre sous Windows, qui ne gère pas les permissions de fichiers à la manière d'Unix.
Ce n'est d'ailleurs pas un geste isolé. Depuis des années, Microsoft a glissé un vrai noyau Linux dans Windows avec WSL, ouvert le code de pans entiers de ses outils et multiplié les passerelles avec l'écosystème open source. Coreutils for Windows s'inscrit dans cette continuité, et confirme que l'éditeur a définitivement enterré la hache de guerre.
Reste que pour quiconque vit dans un terminal et passe ses journées entre WSL, la couche Linux intégrée à Windows, et l'invite de commandes classique, c'est un vrai confort au quotidien. Et voir Microsoft s'appuyer ouvertement sur du logiciel libre écrit en Rust, on n'aurait pas forcément parié là-dessus il y a dix ans.
Bref, le Microsoft qui détestait Linux est bel et bien mort, et c'est tant mieux pour ceux qui codent les deux pieds dans le terminal.
Source : Bleeping Computer