Honnêtement, avec la puissance actuelle de nos LLM, finalement, est-ce qu'on a encore besoin d'avoir des applications ?

Un outil type Claude Code ou Microsoft Copilot, à côté, un gros tas de données diverses et variées, quelques accès à des services et basta ! C'est peut-être ce vers quoi on se dirige, à notre grand détriment...

La preuve avec cette vidéo qui traîne sur le Discord de BetaWiki, tournée en 2024 et dont Microsoft ne dit mot. Des sources internes ont authentifié le clip pour le compte de Windows Central , le site qui a sorti l'affaire en premier. Dedans, un prototype d'OS baptisé Project Aion, où Copilot remplace le menu Démarrer, la barre des tâches et tout le shell classique. Il n'y a plus d'applications à lancer comme d'habitude mais une simple boîte de dialogue pour piloter votre machine, et c'est à peu près tout.

J'sais pas si vous avez remarqué mais autant sous iOS on peut mettre une authentification Face ID sur n'importe quel app, autant sous MacOS, on peut certes verrouiller tout son ordi, mais on ne peut pas locker une app en particulier.

Et c'est chiant parce que parfois, on doit laisser son ordi à un collègue, un enfant ou PIRE sa mère, et ils ont alors accès sans restriction à vos Messages, vos Photos, votre gestionnaire de mots de passe , votre boîte mail et j'en passe des vertes et des pas mûres...

Dweep Desai, un développeur qui s'est visiblement retrouvé dans cette galère, a heureusement sorti FaceGate , un petit utilitaire open source tiers qui ajoute enfin du verrouillage par application sur macOS, avec déverrouillage à la trombine !

curl -fsSL https://raw.githubusercontent.com/dweep-desai/FaceGate-Mac/main/install.sh | bash

Microsoft vient de lâcher un truc qui va faire plaisir à tous ceux qui bidouillent fort des conteneurs Linux depuis leur machine Windows. Ça s'appelle WSL Containers (WSLC pour les intimes, et pas WSL 3) et l'objectif c'est de faire tourner des conteneurs Linux nativement sous Windows sans avoir à passer par des outils tiers du genre Docker.

Pour en profiter, tapez la commande suivante :

wsl --update --pre-release

Cela mettra à jour votre WSL en version 2.9.3 ou supérieure et vous obtiendrez alors une toute nouvelle commande : wslc.

WSLC est un alias qui lance en réalité container.exe et qui permet de gérer tout le cycle de vie d'un conteneur Linux avec des commandes très classiques : run, stop, build, tag, push, pull, prune. Voici un vrai exemple tiré de la doc de Microsoft :

wslc run -d --name=webtop -e PUID=1000 -e PGID=1000 -e TZ=Etc/UTC -p 3000:3000 -p 3001:3001 lscr.io/linuxserver/webtop:ubuntu-kde

Ce qu'on lance là c'est bien une image en provenance de LinuxServer dont je vous ai déjà parlé, et comme vous pouvez le voir, vous ne serez pas dépaysé si vous connaissez déjà un peu Docker.

La GameCube, on la connaît pour avoir fait tourner la meilleure version de Smash Bros et pour son look de petit cube vaguement "rectangulaire". Mais on ne la connait pas vraiment pour faire tourner un système d'exploitation de bureau du milieu des années 90.

Et pourtant, une bande de bidouilleurs emmenée par Rairii (alias Wack0), épaulé par NTx86 et stonedDiscord, s'est amusée à virer les jeux pour loger un vrai Windows NT là-dedans. Oui, le vrai NT de Microsoft.

Merveilleux non ?

Et le plus beau, c'est que ce n'est même pas de l'émulation, c'est carrément un portage natif. Le truc que j'ignorais, c'est qu'à une époque Microsoft avait sorti une version PowerPC de Windows NT, du temps où le système supportait encore des architectures un peu exotiques. Or la GameCube tourne justement sur un processeur PowerPC, le fameux Gekko.

Les deux étaient donc faits pour se rencontrer, et il ne manquait qu'un type assez taré pour les marier. Le projet s'appelle entii-for-workcubes , et il ne s'arrête pas à la GameCube. Vous pouvez aussi le booter sur une Wii, sur une Wii Mini (qui réclame quand même un petit hardmod pour la carte SD), et même dans le mode vWii de la Wii U.

Petit retour en arrière quand même pour les plus jeunes... Dans les années 90, Windows NT n'était pas du tout le truc Windows-x86-only qu'on connaît aujourd'hui. Il tournait sur MIPS, sur DEC Alpha, sur PowerPC, parce que Microsoft voulait un OS portable, qui ne soit pas marié à un seul fabricant de puces. L'histoire a tranché en faveur du x86 et tout le reste est tombé dans l'oubli. Sauf que ces vieux binaires PowerPC existent toujours, et c'est ce qui rend ce hack possible 25 ans plus tard.

Une seule petite ligne de code envoyée au mauvais endroit pouvait transformer un Surface Laptop en bloc de métal inutilisable. C'est sur cette faille que Microsoft a discrètement travaillé pendant trois mois, avant qu'elle ne soit rendue publique le 12 juin.

L'histoire commence de façon assez improbable. Jack Darcy, un chercheur en sécurité australien, a demandé à Microsoft Copilot (l'assistant IA intégré à Windows) de régler le rétroéclairage de son écran, rien de dingue donc. Bien gentil, Copilot écrit tout seul un script Python, l'exécute, et la paf, il rend l'ordinateur totalement inopérant. Plus de démarrage, plus d'accès au BIOS, rien, queudalle.

En creusant, Darcy comprend ce qui vient de se passer. Le script a écrit n'importe quoi dans le firmware du SAM, le Surface Aggregator Microcontroller, cette petite puce qui coordonne le matériel sur les Surface : alimentation, ventilateurs, clavier, capteurs. Une fois sa mémoire corrompue, la machine ne sait tout simplement plus démarrer.

Le problème de fond, c'est que cette puce n'avait aucun garde-fou. Elle acceptait n'importe quelle valeur en écriture sans vérifier si elle avait le moindre sens. Pire, les commandes de lecture et celles d'écriture partageaient la même numérotation, ce qui rendait toute exploration prudente impossible. "Vous ne pouvez littéralement pas scanner deux commandes qui se suivent sans une chance sur deux de tomber sur une commande d'écriture", résume Darcy.

Du coup, un seul paquet expédié pouvait griller la carte mère pour de bon. Aucune réparation logicielle, aucune réinitialisation d'usine, aucun accès USB de secours : direction le remplacement complet de la carte mère, soit plusieurs centaines d'euros.

Tout n'est pas si noir quand même. Pour déclencher la catastrophe, il fallait déjà disposer des droits administrateur sur la machine et avoir désactivé Secure Boot et Secure Core, les deux protections activées par défaut sur les Surface. Autrement dit, un parc d'entreprise géré normalement ne risquait rien, et les seules machines réellement exposées étaient celles des bidouilleurs tournant sous Linux, en configuration gaming allégée ou avec des pilotes maison.

Les modèles concernés vont du Surface Laptop 3 au Surface Laptop 6 et du Surface Book 1 au Surface Book 3. Les Surface Go semblent épargnés, et les versions ARM n'ont pas été testées.

Côté correctif, Microsoft a plutôt bien joué le jeu. Prévenu le 10 mars, l'éditeur a reconnu le défaut puis déployé des mises à jour de firmware via Windows Update dès le mois de mars, si bien que la grande majorité des appareils touchés sont désormais protégés. Darcy a récupéré un Surface tout neuf pour le dédommager.

Un point chiffonne quand même. Microsoft a refusé d'attribuer un CVE, l'identifiant officiel qui répertorie une faille de sécurité, estimant que le bug "n'atteignait pas le seuil" requis. Pour un défaut capable de tuer une machine de façon irréversible, l'argument laisse songeur.

Pour la suite, Redmond mise sur le langage Rust, réputé pour empêcher ce genre de débordements mémoire. Le firmware embarqué est en cours de réécriture intégrale, baptisée "Secure EC", tout comme une partie de l'UEFI sous le nom de "Project Patina".

Bref, un Copilot qui brique tout seul le PC sur lequel il tourne, voilà une démo involontaire dont Microsoft se serait bien passé.

Source : The Register

Si vous voulez mixer vos sources audio sous Windows sans y passer vos nuits en mode David Guetta, vous allez kiffer SteelSeries Sonar et enfin dire adieu à l'interface imbuvable de Voicemeeter et la configuration ultra-pénible d'Equalizer APO !

Ce logiciel de mixage virtuel, totalement gratuit, vient en effet se greffer directement sur le système Windows pour y créer des cartes son virtuelles indépendantes. Cela vous permet alors de piloter d'un coup de curseur le volume d'un jeu, de votre chat Discord, de vos musiques Spotify ou de votre navigateur. C'est super pratique pour baisser les copains qui hurlent sans couper le son du jeu lors de vos parties nocturnes.

Le système d'App Routing permet surtout d'assigner chaque application ouverte à un canal spécifique par un simple glisser-déposer. Plus besoin donc d'aller fouiller dans les paramètres enterrés de Windows que même Microsoft a oublié, pour dire que Spotify doit sortir sur le canal "média" et Discord sur le canal "chat". Tout se gère comme ça depuis l'interface centrale en quelques clics, c'est super agréable.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/steelseries-sonar-alternative-voicemeeter/steelseries-sonar-alternative-voicemeeter-1.mp4">lien vers la vidéo</a>.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/steelseries-sonar-alternative-voicemeeter/steelseries-sonar-alternative-voicemeeter-2.mp4">lien vers la vidéo</a>.

ReactOS, le système d'exploitation libre qui recopie Windows brique par brique, fait désormais tourner Half-Life ( et oui, décidément c'est la journée ! ), le jeu de tir que Valve a sorti en 1998 et qui a propulsé toute une génération de joueurs dans les couloirs du complexe de Black Mesa. Et là, fini l'écran-titre figé qui narguait les développeurs depuis des années. La partie démarre. On y joue.

Pour mesurer l'exploit, il faut savoir ce qu'est ReactOS, parce que ce n'est ni Linux, ni un émulateur, ni une surcouche posée par-dessus un vrai Windows. C'est une réécriture intégrale de Windows, repartie de la page blanche, sans une seule ligne du code source de Microsoft, dans le seul but de faire avaler les programmes .exe et les pilotes pensés pour Windows comme s'ils tournaient sur l'original.

Le terme exact, c'est la compatibilité binaire. Vous prenez un logiciel conçu pour Windows, vous le lancez, il s'exécute, point final. Le premier commit remonte à 1996, à l'époque sous le nom de FreeWin95, et le projet vient tout juste de souffler ses trente bougies.

Half-Life qui s'initialise sur ReactOS, ce n'est pas tout à fait neuf. Dès 2018, une vidéo montrait déjà la séquence d'entraînement, le fameux Hazard Course, jouable sur la version 0.4.8, en rendu logiciel, c'est-à-dire avec chaque image calculée par le processeur faute de carte graphique reconnue pour s'en occuper à sa place.

Sauf que voilà. Jusqu'ici ça toussait, ça plantait, ça s'affichait trois secondes avant de rendre l'âme. Cette fois, les développeurs montrent une vraie partie qui tient la distance, sur la dernière mouture 0.4.15 publiée il y a peu.

Et c'est là que le bât blesse. Trente ans. Le projet en est toujours à une version 0.4, un numéro qui hurle "ce n'est pas fini", pour faire enfin tourner un jeu qui affiche lui-même vingt-huit ans au compteur.

Réécrire Windows à l'identique sans en avoir la recette, c'est un travail de dingue où la moindre application un peu gourmande réclame des centaines de fonctions système reproduites au détail près, et Half-Life, avec son moteur GoldSrc qui va fouiller jusque dans les entrailles de la machine, fait précisément partie de ces logiciels qui ne pardonnent pas la moindre approximation.

L'année a quand même été dense pour l'équipe. ReactOS gère maintenant les puces ARM64, a musclé l'accélération 2D et 3D sur les cartes NVIDIA GTX, et lorgne le support de l'UEFI et de machines plus récentes. Reste un détail qui calme l'enthousiasme : tout ça respire surtout à l'aise dans une machine virtuelle, beaucoup moins sur un vrai PC posé sur le bureau.

Bref, personne ne va troquer son Windows contre ReactOS pour bosser demain matin. La cible est ailleurs : ressusciter de vieux logiciels et de vieux jeux sur un socle libre, gratuit, débarrassé de la laisse tenue par Microsoft.

En tout cas, trente ans pour lancer Half-Life, c'est pas rapide. Mais un Windows entièrement libre qui exécute un vrai jeu culte, ça force le respect.

Source : Phoronix

BitLocker, je le rappelle c'est quand même le truc censé protéger vos données en cas de vol de votre bécane. Sauf que voilà, la théorie et Redmond, ça fait parfois deux... Le chercheur en sécurité Chaotic Eclipse (déjà à l'origine de BlueHammer ) vient de balancer une nouvelle vulnérabilité zero-day baptisée GreatXML , qui réduit cette promesse en miettes.

Le truc tourne autour de la façon dont Windows Recovery Environment (WinRE) traite les fichiers de configuration lors du démarrage. Plus précisément, la faille exploite des résidus laissés par l'outil d'analyse hors ligne de Microsoft Defender.

Cela signifie que si vous avez déjà lancé un scan Defender Offline, votre machine conserve des artefacts sur la partition de récupération. C'est là que le piège se referme car en manipulant des fichiers XML de configuration (notamment unattend.xml) sur la partition de récupération, un attaquant peut forcer le système à ouvrir un terminal avec les privilèges SYSTEM lors du passage en mode WinRE. Le tout sans avoir besoin de se connecter à la session, bien sûr...

Le résultat ?

Un accès complet et sans restriction au volume protégé par BitLocker. Pas besoin de fer à souder ou de bidouiller la carte mère avec un Raspberry Pi comme pour d'autres exploits TPM, là c'est une simple faiblesse logique logicielle qui permet de tout déverrouiller.

Alors oui, l'attaque nécessite un accès physique à la machine (ou un autre accès permettant de modifier la partition de récupération). Mais comme le rôle même de BitLocker est de protéger un appareil volé physiquement, c'est une sacrée épine dans le pied des administrateurs système ! D'autant plus qu'aucun correctif officiel n'a encore été publié par Microsoft.

Cette divulgation publique intervient dans un contexte tendu puisque Chaotic Eclipse multiplie les dumps de zero-days Windows suite à un différend avec le programme de bug bounty MSRC de Microsoft. On a déjà eu le droit à YellowKey et RoguePlanet ces dernières semaines et y'a peu de chances que ça s'arrête.

Bref, c'est la guerre ouverte !

Maintenant, même s'il n'y a pas encore de recommandations officielles de Microsoft pour cette faille spécifique, quelques mesures de bon sens permettent de limiter la casse. D'abord, configurer un mot de passe UEFI pour bloquer le boot externe. Ensuite, activer le mode TPM + PIN pour BitLocker car sans ce code pré-boot, la clé de déchiffrement n'est pas libérée, même si l'attaquant arrive à faire pop son shell.

Et si vous voulez couper court à toute exploitation de ce type, il reste l'option de désactiver complètement WinRE via la commande reagentc /disable.

Bref, en attendant que Microsoft sorte un patch, vous savez ce qu'il vous reste à faire.

Source