Vous voyez le principe du wallet crypto au format carte bancaire ?

Ça se compose d'une puce, d'un code, et de vos précieuses clés privées cryptos planquées dedans. Et bah figurez-vous que Baptistin Boilot, un chercheur de chez Ledger Donjon, vient de montrer qu'avec un laser, un scalpel et une sacrée dose de patience, on peut imposer un nouveau code à une carte Tangem sans jamais connaître l'ancien. C'est en tout cas la démonstration que vient de publier son labo, et le plus dingue, c'est que ça se joue sur un secure element Samsung certifié EAL6+, autrement dit le très haut du panier en matière de puces sécurisées.

Un petit pulse laser d'une nanoseconde envoyé pile au bon endroit, et le taux de réussite pour remettre à zéro le code secret de la carte monte à 100 % !!

Alors oui, Ledger Donjon c'est le laboratoire de sécurité de Ledger, concurrent frontal de Tangem, et Tangem n'a évidemment pas manqué de le rappeler. Sauf que la faille a été divulguée à la marque en février 2026, bien avant publication, donc tout a été fait dans les règles de l'art. Et puis Ledger n'a pas vraiment de leçons à donner niveau boulettes (rappelez-vous la fuite de sa base client ), donc on va juger le boulot technique plutôt que la rivalité commerciale.

Leur cible, c'est l'instruction SetPin, celle qui gère le code protégeant vos fonds. Quelque part là-dedans, la puce se pose une question toute bête, du genre "cette carte est-elle en mode récupération ?". Et le tir laser vient fausser ce test à l'instant exact où il s'exécute. Il ne grille rien du tout hein, il fausse juste le résultat une fraction de seconde, ce qui permet à la puce d'accepter un nouveau code sans jamais vérifier le vôtre.

Après, y'a quand même un sacré ticket d'entrée car pour en arriver là, les chercheurs ont ouvert la carte au scalpel, retiré le blindage métallique, dessoudé la puce, recâblé le tout sur une carte maison, et remplacé l'antenne NFC par une alimentation filaire pour piloter chaque signal. Un vrai travail d'orfèvre ! Ajoutez environ 250 000 dollars de matériel entre le laser, l'oscilloscope et la sonde électromagnétique et puis beaucoup de temps : 1 heure de balayage laser pour la première réussite, puis 2 heures par carte ensuite, sans parler de toute la R&D en amont.

La puce se défend, en plus. Elle tient un compteur de fautes en mémoire flash et se verrouille pour de bon au bout de quelques centaines de ratés. Sauf que les chercheurs ont trouvé la parade qui est de couper l'alimentation au moment précis où la puce s'apprête à noter l'incident. Du coup le compteur ne grimpe quasiment plus, et une carte qui aurait dû se bloquer très vite a encaissé plus d'une journée de tirs laser !

Alors, la question que vous vous posez forcément c'est : est-ce que votre Tangem est toujours fiable ? Pour vous, au quotidien, oui car il faut un accès physique à la carte. Puis l'opération laisse des dégâts parfaitement visibles (une carte charcutée au scalpel, ça se remarque), et je pense que personne ne va monter un labo à un quart de million pour siphonner votre wallet.

Maintenant, c'est vrai que cette faille ne sera jamais corrigée, car les cartes Tangem n'embarquent aucun mécanisme de mise à jour du firmware. Ça peut vous sembler absurde, mais en fait c'est pas si con que ça parce que qui dit pas de mise à jour dit pas de mise à jour vérolée. Hé hé.

Mais maintenant que le trou existe, et qu'aucun patch n'est possible, cela veut dire que toutes les cartes en circulation, dont la vôtre peut-être, restent vulnérables à vie. Et celle que vous achèteriez aujourd'hui ? Bah vulnérable tout pareil, tant que Tangem ne revoit pas son design.

Alors oui, l'attaquant ne lit pas vos secrets, il prend juste le contrôle du wallet en lui imposant son propre code, un peu comme une carte à puce sécurisée qu'on déverrouillerait de force sans en lire le contenu. C'est pourquoi Tangem estime que le risque est quasi inexistant, en rappelant au passage que n'importe quel secure element finira au bout d'un moment par céder si on y consacre assez de temps et d'argent.

Bref, si vous avez une Tangem au fond d'un tiroir, pas de panique, gardez-la juste bien à vous, parce que côté correctif, vous pourrez attendre longtemps, il n'y en aura jamais.

Source

Vous le savez, j'adore mon Kindle ! Je manque effectivement de temps pour lire tout ce que je voudrais mais bon, on verra ça quand la retraite sera là ^^.

En attendant, ce que j'ignorais, c'est que sur les Kindle récents, il y a encore un petit navigateur web, plus exactement un vieux Chrome de 2019 bien planqué dans des menus qu'on n'ouvre jamais. Et c'est à ce module précisément que Tanguy Dubroca de Synacktiv s'est intéressé. Et en creusant, il a découvert qu'une faille s'y cachait et permettait de prendre le contrôle total de la liseuse avec votre compte Amazon en supplément salade tomate oignon.

Son objectif premier c'était de comprendre comment prendre la main sur un Kindle verrouillé sans le jailbreaker. Alors il a fouillé dans le firmware de son Paperwhite 5 et y a découvert ce vieux Chrome et son moteur Webkit d'une quinzaine d'années, prêt à céder à toutes ses demandes... niark niark.

Il n'a eu plus qu'à piocher dans les vieilles failles déjà bien connues de Chrome et en a choisi une présente dans le moteur Javascript V8 patchée par Google en 2022. Sauf que normalement, elle ne devait pas marcher sur un Kindle, parce qu'Amazon avait désactivé le composant vulnérable.

Enfin, avait essayé...

Parce que dans la commande censée le désactiver, il manquait deux petits tirets. Une faute de frappe qui faisait que l'option était ignorée en silence, et donc que le moteur JS d'époque restait allumé avec cette porte grande ouverte...

L'attaque n'a ensuite besoin que d'une seule chose qui est que vous ouvriez un site web piégé dans le navigateur de la liseuse. Pas de panique donc, car ça ne se déclenche pas tout seul quand vous recevez un livre, mais une fois la page web ouverte, elle peut trafiquer la mémoire de l'appareil, ce qui permet au chercheur de prendre la main sur le navigateur pour ensuite, via une seconde vulnérabilité dans le composant qui lance les applis, obtenir des droits administrateur et donc l'accès complet.

Une fois avec ça, il peut tout faire comme exécuter n'importe quel programme, vous espionner, détourner votre compte Amazon, et même rebondir vers les autres appareils présents sur votre réseau Wi-Fi. La totale !!

Dubroca a prévenu Amazon en décembre 2025, qui a classé le truc en critique, lâché 20 000 $ de prime, et poussé un correctif dans le firmware 5.19.2 en janvier. La mise à jour se fait toute seule une fois le Kindle branché et connecté au Wi-Fi alors si votre liseuse dort dans un tiroir depuis des mois, un petit coup de Wi-Fi et elle se mettra à jour, hop. D'ailleurs c'est la deuxième faille Kindle en 7 mois , après celle du livre audio piégé. Deux équipes françaises, deux fois le même appareil, ça commence à faire beaucoup pour de vieilles liseuses qu'Amazon laisse doucement vieillir .

Bref, une liseuse c'est comme un ordinateur, ça se pirate mais ça peut se mettre à jour ^^. Ouf !

Source

Le chercheur derrière RoguePlanet affirme que le correctif pour Windows Defender permet un déni de service saturant le disque local.

Le post Windows Defender : le patch RoguePlanet aurait des effets de bord a été publié sur IT-Connect.

L'Euro NCAP renforce son protocole de crash-test à compter de l'année 2026. Les premiers élèves à passer l'examen sont les BMW iX3 et Zeekr 7GT, et les résultats se sont soldés par la note maximale pour les deux modèles : 5 étoiles.

ZeroBEC a repéré DEBULL, un kit de phishing qui abuse du device code Microsoft pour pirater des comptes Microsoft 365 sans voler de mot de passe.

Le post DEBULL : ce kit de phishing détourne le device code de Microsoft 365 pour contourner le MFA a été publié sur IT-Connect.

Depuis le printemps 2026, des pirates appellent des salariés sous prétexte d'enrôler une passkey Entra. Pendant ce temps, l'attaquant enregistre la sienne.

Le post Microsoft 365 : pendant que la victime est au téléphone, l’attaquant crée sa propre passkey Entra a été publié sur IT-Connect.

Des propriétaires de Denza (marque de BYD) se sont improvisés sauveteurs dans des zones touchées par de graves inondations en Chine. Incités par la communication ultra-sécurisante de la marque, ces usagers se sont pourtant exposés à des dangers malgré les avertissements des autorités.

Découverte à l'aide d'une IA, GhostLock (CVE-2026-43499) est une faille du noyau Linux présente depuis 2011. Elle permet à un utilisateur local de devenir root.

Le post GhostLock : cette faille Linux vieille de 15 ans offre un accès root sur la majorité des distributions a été publié sur IT-Connect.

Alors ça, Google va adorer ! En effet, depuis hier (le 8 juillet), le navigateur DuckDuckGo bloque les pubs YouTube tout seul comme un grand. Le pre-roll interminable avant votre tuto Docker , la double coupure en plein milieu d'un unboxing, ou encore la pub pour une appli de casino que vous n'avez jamais demandée... tout dégage, en mode par défaut sans avoir besoin d'ajouter une extension.

iOS, Windows et Mac sont servis d'office, et sur Android ça s'active à la main dans Settings > Ad Blocking (le par défaut arrive bientôt).

Le canard américain ne réinvente rien puisqu'il embarque tout simplement les listes de filtres communautaires du projet uBlock Origin , mises à jour régulièrement pour suivre les parades de la régie pub de Google.

Sur son blog , ils annoncent donc que leur fonctionnalité bloque la "plupart" des publicités. Donc pas 100% et ils préviennent qu'un peu de buffering peut également apparaître au lancement d'une vidéo. Ouais ça c'est la petite astuce de Google pour contrarier les utilisateurs d'AdBlocker...

Mais une fois la lecture partie, plus d'interruption !

Sur ordi, vous verrez une petite icône vidéo à côté du bouclier vert dans la barre d'adresse, c'est là que ça se pilote.

Le réglage Ad Blocking, planqué dans le menu du navigateur

Sur mobile, je le précise encore parce que ça ne coule pas de source pour tout le monde, c'est seulement si vous ouvrez YouTube dans le navigateur DDG. L'application YouTube officielle , elle, continuera de vous balancer des tunnels de pubs tranquillement.

Et si vous utilisez déjà Duck Player , le mode théâtre sans cookies de pistage, les 2 fonctionnent ensemble sans se marcher dessus.

Bon, les blasés de la vie me diront que Brave fait ça nativement depuis des années et c'est vrai. Mais ce qui est intéressant ici, c'est que c'est un blocage activé par défaut pour madame et monsieur Tout-le-monde, sur un navigateur qui se télécharge gratuitement . Le blocage de pub n'est plus une bidouille de geek, mais c'est devenu un argument marketing pour "vendre" son navigateur.

Du coup, dans le bras de fer entre YouTube et les bloqueurs de pubs , qui s'est durci depuis fin 2023 à coups d'avertissements, de ralentissements volontaires et de lectures bloquées, je pense que la riposte de Google ne va pas tarder donc préparez les popcorns.

Mais quoi qu'il en soit, c'est encore un coup dur pour les youtubeurs. Bon, il restera toujours la possibilité de faire des segments sponsorisés directement dans la vidéo... Ah mais non, oups, c'est vrai, il y a SponsorBlock qui se débarrasse de ça aussi. Ouin !

Mais alors qu'est-ce qu'on va devenir, nous, les créateurs de contenu ?

Eh bien c'est simple. Si vous aimez bien ce qu'on fait, faut nous soutenir. Moi, par exemple, j'ai un Patreon et il y a plein de gens dessus qui me soutiennent, ce qui est super cool, j'ai vraiment beaucoup de chance. Et je les remercie tous.

J'encourage les autres créateurs de contenu à faire pareil, y compris les YouTubers, à mettre en place ce genre de système. Et sachez qu'on n'est pas obligé de se prendre la tête avec des contreparties...etc parce qu'on n'a pas vraiment le temps, on a déjà beaucoup de choses à faire. L'important c'est d'être transparent avec votre communauté, vous dites juste que c'est pour continuer à faire ce que vous faites d'habitude, c'est pour continuer à faire tourner la chaîne dans la joie, la bonne humeur et ça devrait très bien se passer.

Moi mon rêve c'est qu'un jour le Patreon ramène suffisamment d'argent pour que je puisse me passer à 100% de partenaires pub. Un jour peut-être, on verra bien.

Source

Dans un communiqué publié le 8 juillet 2026, les mainteneurs d'OpenMandriva ont dénoncé une tentative de sabotage de leur distribution Linux. Ils pointent directement du doigt un ancien contributeur, qui aurait agi par représailles après l'exclusion d'un proche du projet.

Microsoft a corrigé RoguePlanet (CVE-2026-50656), la zero-day de Defender qui donnait les privilèges SYSTEM sur Windows 10 et 11. Voici comment se protéger.

Le post RoguePlanet : Microsoft corrige la zero-day qui donnait les privilèges SYSTEM a été publié sur IT-Connect.

Dans un communiqué publié le 8 juillet 2026, les mainteneurs d'OpenMandriva ont dénoncé une tentative de sabotage de leur distribution Linux. Ils pointent directement du doigt un ancien contributeur, qui aurait agi par représailles après l'exclusion d'un proche du projet.

On reçoit tous des mails un peu bizarres avec des liens qu'on n'ose pas ouvrir, et pourtant on est curieux, on est tenté parfois... C'est difficile de résister mais heureusement l'équipe de Linuxserver.io a pondu un truc super pour ça.

Il s'agit tout simplement d'une instance de Firefox qui tourne dans un conteneur Docker et qui est totalement pilotable depuis votre navigateur habituel.

Comme ça, quand vous recevez un lien louche que vous voulez ouvrir, vous le mettez là-dedans, dans une session jetable qui est totalement coupée de votre vraie machine. Et comme ça, si ça part en couille, vous butez le conteneur et on n'en parle plus.

Voilà, ça se présente juste comme une page HTTPS avec un navigateur dedans. Et comme c'est LinuxServer qui maintient l'image, vous êtes tranquilles parce que c'est du sérieux.

L'avantage d'avoir ce truc, c'est qu'un Firefox en conteneur ne voit ni votre répertoire personnel, ni vos cookies, ni vos sessions Google, ni vos extensions, absolument rien, il est totalement isolé. Donc si un site tente un drive-by download ou un exploit navigateur, eh bien en principe les dégâts resteront coincés dans le conteneur. Et le simple fait de le redémarrer remettra tout à 0.

Attention quand même, un conteneur, ce n'est pas une machine virtuelle. Une vulnérabilité au niveau du noyau pourrait en théorie s'en échapper. Mais c'est pas le genre d'attaque qui se fait avec juste un clic douteux sur une page web.

Les chercheurs en sécu s'en servent pour ouvrir des pièces jointes chelou, les marketeux pour jongler avec 12 comptes ad sans cookie cross-tracking , et les paranos dans mon genre pour cliquer sur les liens des mecs bizarres de Discord sans rien flinguer chez eux..

Après y'a des petits inconvénients. Je pense aux perfs graphiques qui prennent une claque par rapport à un Firefox natif ou encore l'audio qui transite par le pipeline du navigateur, du coup ça crachote parfois sur les vidéos lourdes. Le copier-coller marche, mais en passant par la section presse-papiers de la barre latérale Selkies , pas en direct. Et la persistance ne tient que si vous mappez le volume /config comme il faut, sinon vos onglets et vos bookmarks gicleront dès que le conteneur sera recréé (à la première mise à jour d'image, typiquement).

Côté vie privée c'est plutôt une qualité mais pour un usage quotidien, ça peut devenir relou.

Installation en une commande

L'image officielle, c'est lscr.io/linuxserver/firefox:latest. Elle tourne sur Selkies depuis juin 2025 (avant c'était KasmVNC) et démarre en Wayland par défaut depuis mars 2026. Maintenant, si un site part en vrille à cause de ça, vous ajoutez le paramètre PIXELFLUX_WAYLAND=false à la commande Docker et vous serez de retour en X11.

La commande minimale ressemble à ça :

docker run -d \
--name=firefox \
-e PUID=1000 \
-e PGID=1000 \
-e TZ=Europe/Paris \
-e LC_ALL=fr_FR.UTF-8 \
-p 3001:3001 \
-v $HOME/firefox-config:/config \
--shm-size=1gb \
--restart unless-stopped \
lscr.io/linuxserver/firefox:latest

Le --shm-size=1gb, c'est la mémoire partagée de Docker et vous n'y couperez pas, désolé. Si vous le zappez, YouTube comme les sites un peu lourds vous planteront le navigateur. Le port 3001, c'est l'accès HTTPS, avec un certificat auto-signé qui fera râler votre Firefox principal (c'est normal, faut l'accepter). Y'a aussi un port 3000, mais lui c'est du HTTP en clair, à réserver derrière un reverse proxy genre SWAG et rien d'autre.

Ensuite, direction https://localhost:3001/ et un joli Firefox vous attend. Notez que par défaut, il n'y a AUCUNE authentification. Personne ne vous demande rien, alors si vous voulez l'exposer sur votre réseau, définissez bien un CUSTOM_USER et PASSWORD pour activer le basic auth avant qu'un petit malin de votre réseau ne tombe dessus.

La version docker-compose, plus propre

Envie d'un setup versionnable, que vous pouvez reproduire ailleurs sans réfléchir ? Le compose fait ça mieux :

---
services:
firefox:
image: lscr.io/linuxserver/firefox:latest
container_name: firefox
environment:
- PUID=1000
- PGID=1000
- TZ=Europe/Paris
- LC_ALL=fr_FR.UTF-8
- CUSTOM_USER=korben
- PASSWORD=changezmoi
- HARDEN_DESKTOP=true
- HARDEN_OPENBOX=true
volumes:
- ./firefox-config:/config
ports:
- 3001:3001
shm_size: "1gb"
restart: unless-stopped

Ensuite, un docker compose up -d et roulez jeunesse. Le volume ./firefox-config conserve votre profil entre deux redémarrages avec bookmarks, extensions installées depuis le store Mozilla, tout reste en place.

Et si vous avez envie de repartir de zéro, on met le dossier à la poubelle, on relance, et voilà. Et pour glisser des outils tiers dans le conteneur (filezilla, un éditeur, ce genre de bidule), [proot-apps install](https://github.com/linuxserver/proot-apps) les posera dans $HOME, où ils survivront aux mises à jour de l'image.

Le hardening qu'il faut absolument activer

Maintenant, le piège que la doc évoque du bout des lèvres et qui mérite d'être écrit en gros c'est que l'interface web embarque un terminal avec sudo passwordless . Traduction : quiconque accède à votre Firefox conteneurisé devient root dans le conteneur en deux clics. Exposez ça sur votre réseau, ou pire sur Internet, sans durcir le machin, et vous ouvrez un boulevard.

La parade tient en une variable : **HARDEN_DESKTOP=true**, qui pose les principaux verrous d'un coup. Ça coupe sudo, ça vire les terminaux, et ça bloque xdg-open et exo-open, qui pourraient lancer des trucs hors conteneur. Vous pouvez empiler ça avec HARDEN_OPENBOX=true par-dessus, histoire de neutraliser les raccourcis clavier dangereux genre Alt+F4, de désactiver le clic droit et de masquer le bouton de fermeture. Firefox reste parfaitement utilisable, mais impossible de s'évader pour faire mumuse avec le système derrière.

Et pour une exposition sur Internet, le basic auth CUSTOM_USER/PASSWORD ne suffira pas car c'est trop léger. Moi ce que je vous recommande, c'est de coller le tout derrière un reverse proxy SWAG avec une vraie couche OAuth2 ou Authelia. Le basic auth, gardez-le pour le LAN entre potes ou collègues de confiance, mais pas au-delà.

SealSkin, le bonus qui change tout

SealSkin , c'est la cerise sur le conteneur ^^. C'est une extension navigateur, dispo pour Chrome et Firefox, qui monte la garde sur votre navigateur principal et détourne ce qui sent mauvais vers le conteneur isolé. Un lien repéré comme suspect ? Hop, il s'ouvre direct dans le Firefox conteneurisé. Pareil pour les téléchargements, qui atterrissent dans le conteneur au lieu de finir sur votre machine.

Du coup, l'isolation devient un réflexe permanent au lieu d'un machin que vous activez à la main quand vous y pensez (c'est-à-dire jamais). Seule contrainte par contre, faudra héberger le serveur SealSkin vous-même, et installer l'extension dans votre vrai Firefox. Mais vous verrez, après quelques jours à ce régime, vous aurez du mal à faire autrement.

Et sur tablette ou mobile ?

J'imagine que vous comptiez sur l'ancien tag kasm pour le tactile ? Eh bien c'est raté, puisque LinuxServer l'a déprécié début juillet. En échange, la barre latérale Selkies embarque désormais un trackpad virtuel et un clavier à l'écran, donc de quoi rendre l'interface utilisable depuis un iPad ou un smartphone sans bidouille en plus. On reste loin, c'est vrai, du confort d'un vrai desktop, et taper Ctrl+Tab au doigt c'est toujours la misère, mais pour dépanner ça fait le job.

Et voilà, votre Firefox jetable vit désormais dans son petit conteneur, bien au chaud. Comme ça, le prochain lien douteux, vous l'ouvrirez sans trembler... pour tester des sites au calme, difficile de trouver mieux, je pense.

Un identifiant Windows, le GDID, a aidé le FBI à relier un membre présumé de Scattered Spider à une cyberattaque, d'après une plainte fédérale américaine.

Le post GDID, cet identifiant Windows qui a permis au FBI de traquer un membre de Scattered Spider a été publié sur IT-Connect.

Comme je vous le disais tout à l'heure, en avril 2026, le FBI a coincé un membre présumé de Scattered Spider. Le mec planquait son trafic derrière un VPN, avec des IP dans trois pays différents. Et devinez quoi ? Ce n'est pas une fausse manip qui l'a balancé mais un identifiant que votre Windows se trimballe H24 et que Microsoft refile aux autorités quand elles le demandent : le GDID. Je vous en ai déjà causé dans cet article , et après avoir écrit l'article, je me suis demandé si on pouvait le virer.

Du coup j'ai monté une petite VM Windows 11 Pro et j'ai mis les mains dedans en me faisant assister de mon LLM préféré et voilà ce que j'ai trouvé. Ce qui marche, et surtout ce qui ne marche pas du tout, vous allez voir.

Déjà, faut comprendre ce qu'est ce GDID. C'est pas le numéro de série de votre carte mère, c'est pas un hash en lien avec votre matos. Non, c'est un PUID de 64 bits, c'est-à-dire un identifiant que les serveurs de Microsoft collent à votre compte dès que vous ouvrez une session Windows. Il est écrit en clair dans votre registre, votre machine l'enregistre dans un annuaire côté Microsoft, et un service le fait remonter peinard quand c'est nécessaire. Et si vous changez d'IP avec un VPN, bah lui il s'en fout. Le GDID ne bouge pas d'un poil.

Regardez votre propre mouchard en face

On commence par le voir de nos yeux. Ouvrez un PowerShell et collez ça :

$lid=(Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LID
"g:$([Convert]::ToUInt64($lid,16))"

Sur ma VM, ça m'a craché g:6755487812206045. C'est celui que Microsoft peut raccrocher à tout ce que je fais. (En théorie hein, parce que c'est le code qui est associé à ma VM, donc je m'en fous et c'est pour ça que je vous le montre).

Vous venez de lire l'étiquette qu'on vous a collée dans le dos.

Le supprimer ? Laissez tomber

Réflexe de base, on efface la clé dans la base de registres HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties et hop, plus de mouchard. C'est ce que j'ai testé au début... J'ai shooté la valeur, redémarré le service qui s'en occupe, et là plus rien. Gagné ? Ben non. J'ai ouvert le Microsoft Store durant deux petites secondes, et le GDID est revenu. Et pas un nouveau, hein, LE MÊME !!

C'est ça qui est fou. C'est que votre GDID n'est pas planqué sur votre disque, il est planqué chez Microsoft, bien accroché à votre compte comme une moule à son rocher. Votre PC ne fait que le retélécharger encore et encore. Après si vous réinstallez tout, Windows vous donne un nouveau numéro, d'accord, mais l'ancien et tout ce qui y était rattaché restent tout de même bien au chaud sur leurs serveurs. Le passé, on le récupère jamais...

Couper la télémétrie ne change rien non plus

Un autre conseil qu'on voit partout, c'est de désactiver la télémétrie de Windows. Sur ma VM, le service de télémétrie classique était déjà à l'arrêt. Et pourtant mon GDID était là, bien lisible, et les services qui le font remonter tournaient à plein régime. Le mouchard ne passe pas par la télémétrie que vous croyez couper. Il passe ailleurs, par les services de la plateforme d'appareils connectés et de l'optimisation de distribution.

Vous pouvez donc cliquer sur tous les boutons vie privée des réglages, il s'en tape.

Fermer le robinet pour de vrai

Alors puisqu'on peut pas l'effacer, on va faire la seule chose qui est en notre pouvoir : L'empêcher de sortir. Et sans se déconnecter du compte Microsoft, histoire de garder un PC utilisable, hein.

Et pour ça, on a 2 leviers. Le premier, c'est de désactiver les services qui enregistrent et remontent les infos de votre machine. Le second, c'est de renvoyer les serveurs de Microsoft dans le décor simplement via le fichier hosts, comme ça même si les services qui mouchardent tournent, et bien ils ne peuvent plus joindre personne... Et surtout, on ne touche pas à login.live.com, sinon adieu la connexion à votre compte.

Toutefois, il y a un petit piège, vous vous en doutez... Le service qui fait remonter le GDID, DoSvc, refuse de se laisser désactiver par la voie normale. Même en admin, Windows vous balance "Accès refusé". La parade, c'est donc de le désactiver direct dans le registre, où l'admin a le droit d'écrire là où le gestionnaire de services vous bloque.

Maintenant pour faire ça, plutôt que de vous mettre des tonnes de lignes de code à copier-coller, j'ai tout regroupé dans des scripts propres, que j'ai testés, avec une commande pour tout remettre comme avant.

Le projet est là : no-gdid sur GitHub . Vous lancez d'abord l'audit en lecture seule pour voir où vous en êtes, puis les scripts de blocage en mode aperçu, et seulement après avec l'option qui applique vraiment. Testez dans une VM avec un snapshot avant de faire ça sur votre vraie bécane, parce qu'on désactive quand même des services système. Et si vous voulez juste couper le réseau d'un process précis sans tout ce cirque, ce bon vieux ProcNetBlocker fait déjà une partie du taf.

Allez c'est parti mon canard !

Ouvrez un PowerShell en administrateur, et la première fois faites-le dans une VM avec un snapshot histoire de tester et de vous familiariser avec les commandes. Étape 1, on clone le projet :

winget install --id Git.Git
git clone https://github.com/Korben00/no-gdid
cd no-gdid

D'abord on regarde sa propre situation. Cet audit est en lecture seule, il ne modifie rien, il vous affiche juste votre GDID et quels services de la chaîne tournent :

powershell -ExecutionPolicy Bypass -File .\audit\Get-GDID-Audit.ps1

Ensuite on regarde ce que la mitigation changerait, sans rien appliquer. Sans l'option -Apply, les deux scripts tournent en mode aperçu et se contentent de lister ce qu'ils feraient :

powershell -ExecutionPolicy Bypass -File .\mitigate\Disable-GDID-Services.ps1
powershell -ExecutionPolicy Bypass -File .\mitigate\Block-GDID-Endpoints.ps1

Si ça vous va, on coupe pour de vrai. Cette fois on ajoute -Apply : les services qui enregistrent et remontent l'appareil sont désactivés, et les serveurs de Microsoft correspondants sont renvoyés dans le vide via le fichier hosts. Votre compte Microsoft, lui, reste connecté :

powershell -ExecutionPolicy Bypass -File .\mitigate\Disable-GDID-Services.ps1 -Apply
powershell -ExecutionPolicy Bypass -File .\mitigate\Block-GDID-Endpoints.ps1 -Apply

Et pour tout remettre comme avant, une seule commande :

powershell -ExecutionPolicy Bypass -File .\mitigate\Revert-GDID.ps1

Une fois appliqué, tout redeviendra calme... les services d'enregistrement seront à l'arrêt, leurs serveurs injoignables, et votre compte Microsoft restera toujours connecté. Le GDID reste bien évidemment lisible sur le disque, mais il ne remontera plus chez Microsoft.

La vérité qui pique

Après, je ne vais pas faire un tuto qui vous vend du rêve. Ces manips réduisent ce que Microsoft pourra corréler à l'avenir mais elles n'effacent pas votre GDID, qui traîne sur leurs serveurs depuis votre toute première connexion, et elles ne vous rendent pas anonyme. Ensuite, passer en compte local comme j'ai pu le lire ailleurs supprime le chemin qu'on vient de bloquer, mais rien ne prouve encore qu'un identifiant anonyme ne prend pas le relais derrière.

La seule vraie parade solide pour une activité sensible, est plus brutale : ne pas faire cette activité sous Windows. Un Linux live par exemple offre un contrôle total de ce qui sort de votre machine. Le reste, c'est que de la réduction des dégâts, rien de plus.

Voilà, défendre sa vie privée, ça commence par savoir ce qu'on vous colle sur le dos et maintenant vous le savez. Pas merci Microsoft.

Source : The Register et le reverse engineering de SmtimesIWndr .

Des chercheurs ont découvert une faille permettant d'extraire les données de dépôts privés GitHub sans aucune authentification, juste en piégeant l'agent IA chargé de répondre aux tickets.

Des chercheurs ont découvert une faille permettant d'extraire les données de dépôts privés GitHub sans aucune authentification, juste en piégeant l'agent IA chargé de répondre aux tickets.

Une vulnérabilité découverte par un chercheur en sécurité permet à n'importe quelle machine virtuelle louée sur un cloud d'aller compromettre le serveur physique qui l'héberge. Elle traîne dans le noyau Linux depuis 2010.

Une vulnérabilité découverte par un chercheur en sécurité permet à n'importe quelle machine virtuelle louée sur un cloud d'aller compromettre le serveur physique qui l'héberge. Elle traîne dans le noyau Linux depuis 2010.