Reprise du message précédent :
C'est paramétré comme cela par défaut, appuie sur le bouton Power du PC, éteint le PC comme dans le Menu Démarrer

La màj KB5089549 du dernier patch Tuesday a l'air d'être bien merdique:
- des installations de la màj qui échouent à la toute fin entrainant une boucle téléchargement/redémarrage/retour à un état antérieur (sans pertes de données certes) et donc une màj inapplicable;
- des Wi-fi qui sont ralentis ou coupés après l'installation de la màj car les drivers trop vieux "cross-signed" non certifiés via le WHCP sont bloqués, du coup obligé de réinitialiser le paramétrage Wi-fi et de réinstaller les vieux drivers à la main.

.
RAS
 

Pareil sur tous mes PCs.

ras également

Hello,

Petit retour tardif sur ce problème.

J'ai réussi a réparer les certificats de démarrage garce à la clé usb faite en amont (en suivant la procédure de Microsoft) Après avoir booté dessus, j'ai eu un écran bleu rapide (pas eu le temps de prendre une photo) et le pavé rouge du bios à disparu. Une fois sous Windows, Secure Boot est bien activé dans msinfo32 et les derniers certificats sont OK dans le centre de sécurité.

Problème réglé et une épine de moins dans le pied.

Merci encore pour avoir apporté ton aide et bon week-end !

J'ai toujours un pc acer (compatible win11) en attente des nouveaux certificats, à 1 mois de la dead line je n'y crois plus trop.
Et un un vieux dell de 2014, j'ai testé de forcer la clé AvailableUpdates à 0x5944.
J'ai bien les nouveaux certificats et bootloader, mais j'ai un message qui indique qu'il n'y a pas de nouveau certificat kek disponible pour cette machine.

Je pose ça là :
https://pausehardware.com/bitlocker [...] indows-11/

windows 11
 

 

putaclic contraire à la charte du forum

Faille corrigée depuis juillet 2025, c'est dans l'article.

Petit coucou aux boulets qui désactivent les mises à jour

 
Les systèmes protégés et les mesures à retenir
Les machines configurées avec un TPM + code PIN pré-démarrage ne sont pas vulnérables à cette méthode, car une interaction physique est alors requise pour libérer les clés. Même constat pour les systèmes ayant finalisé la migration de la mise à jour KB5025885 vers le certificat numérique moderne Windows UEFI CA 2023.
 
 
 

 
Encore plus simple : https://korben.info/une-faille-perm [...] e-usb.html
 
 

Et quand cette faille sera corrigée, une autre aussi simple sera découverte

C'est à celle ci que je pensais, j'ai été induit en erreur par la quasi simultanéité de date des deux publications.

2026, et il y a encore des gens qui mettent des liens vers le site de Korben (et même continuent à le fréquenter tout court), au lieu de liens vers de vraies sources non  putaclic…

Ben poste les "bons" liens au lieu de juste faire ta karen.  

journaldugeel, clubic, zataz, korben ....... des appeaux à pigeons qui ne font pas honneur à la langue de Molière.    
 
apprenez l'anglais  

Il a quoi Korben

Vu que la question revient régulièrement, j'ai fait un tuto sur comment mettre à jour les certificats Secure Boot 2011 vers 2023.

Par curiosité, j'ai essayé YellowKey avec mon desktop et mon laptop, mais dans les deux cas c'est un échec.
 
J'ai bien le cmd direct au reboot en Windows RE après avoir mis les fichiers d'exploit dans le System Volume Information. (Donc a priori la corruption de WinRE via le Diff Transactionnel du système de fichier se fait bien).
Pour la ref du TxF: https://learn.microsoft.com/en-us/w [...] tfs-portal
(Et il faut remettre le diff transactionnel à chaque essai ce qui peut être relou)
 
Mais niet, les volumes ne sont pas déverrouillés.  
Essayé avec des clés USB de taille différentes (en NTFS et en ExFat).
J'ai aussi fait un export de la clé BitLocker en fichier physique (une explication était que la clé était dupliquée à ce moment dans la partition de récup, mais ça a pas forcément de sens, vu que le concept c'est de stopper WinRE au moment où il fait son déverouillage-popotage-reverrouillage des partitions BitLockées, donc dans ce cas ça vient du TPM).
 
J'ai l'impression que c'est lié au fait que mes deux machines ont été faites avec un ISO FR à la base, et l'exploit ne fonctionne que pour les binaires US, et les offsets collent plus (mais je m'attendrais à un crash dans ce cas). J'ai pas mal joué à bouger les partitions aussi, donc autre explication potentiel mais mouef.  
Je penche pour les binaires WinRE de l'ISO FR qui seraient pas les bons pour le diff.
 
En tous cas l'attaque par le TxF ne semble pas pointer du doigt que c'est une backdoor. (Et laisser sous-entendre que l'auto-supression du diff est une preuve, heu très mouef).
 
Par contre, maintenant que le TxF est connu comme un vecteur d'attaque, ça va être un festival dans les prochaines semaines/mois, va falloir s'accrocher à son slip
Le bordel y va être deprecated en panique chez MS.

Sympa le test que tu as fait
 
J'ai cru lire qu'un mdp pour accéder aux paramètres du BIOS serait un frein contre l'exploit. Je ne vois pas trop en quoi

Intuitivement, je vois pas pourquoi, ça a pas de rapport avec l'accès au TPM par le kernel à priori.
(Néanmoins mes deux machines ont des mdp de bios)

Ben oui

Il ne reste plus que le code PIN de déverrouillage et/ou le périphérique USB contenant la clé complète pour combler cette merde, en attendant un correctif, si jamais il corrige le problème sans bourse délier

De toutes façons, Bitlocker a ses limites par design: A partir du moment où le système boote jusqu'au login user, bon bah tu auras toujours des vecteurs de pétage. (donc oui il faut un blocage le plus tôt possible)
C'est plus une protection anti-branleur qui fume du pétard et qui tomberait par hasard sur ton matos
 
Fondamentalement, si t'as pas de limites en moyens (genre un état), tu peux coller un analyseur logique sur le bus de la DRAM et inspecter à la volée ce qui passe et capturer si tu vois un pattern qui te plait. Bon faut des thunes, et c'est plus facile si c''est une vielle gen de matos.

Je suis allé au plus court avec une rapide recherche Google.

Voilà la source alors :
https://www.tomshardware.com/tech-i [...] t-backdoor

Ca va ? satisfait ?

Je viens de tester YellowKey, ça a fonctionné du 1er coup. Clé Verbatim 16Go en USB3. C'était une clé d'install windows 11. Windows en français.
Par contre mon AV (Gdata endpoint) était pas d'accord

(Windows Defender a chouiné, mais j'ai vérifié avec un git diff que le repo avait pas été altéré)
 
Hah bah alors je suis jaloux Ce serait bien de savoir porké.
Là tu est parti d'une clé préparée pour une Install, je suis parti d'une clé formatée et j'avais dû me donner les droits sur le Volume System Information.
-Mais- j'arrive bien directement au CMD comme si WinRE avait bien été tapé par l'exploit.
 
---
Bon testé sans mdp dans le bios (ce qui n'a aucun sens), et avec l'ISO FR 25H2 (via Rufus), déploiement dans le System Volume Information, pareil WinRE va direct sur le cmd, rien débloqué. (unknown dans Diskpart list volume)
Je suis déçu, je suis colère.
 
Je dois avoir un WinRE qui a été torturé le long des upgrades majeures. (ma machine a fait le 23H2, 24H2, 25H2, la dernière clean install est donc le 22H2).

Si je fais un reagentc /info j'ai la 10.0.26100.8455. Donc la dernière issue de la KB5089593, donc YellowKey doit être bloqué par ce build.

J'ai pas testé diskpart, j'ai juste navigué sur mon c: et copier un fichier sur ma clé.
T'as essayé de copié un fichier avec la fenêtre dos qui s'ouvre ?
Sinon le pc sur lequel j'ai testé n'a plus la même CM d'origine et était sur 10 à la base.
Sinon j'ai testé 2 autres clés, une strelec et une autre fraîchement formatée en exfat.
Je vérifierai demain mais normalement je suis bien à jour.

Les disques bitlockés ne sont pas visible chez moi. Ils ne sont pas montés, et affichés en unknown dans diskpart (ce qui est le comportement logique tant que le volume est pas déchiffrable).
 
Je pense que tes machines ont pas la KB5089593 qui doit silencieusement bloquer YellowKey (c'est pas dans le changelog).
 
Mais justement à vérifier.

,

J'ai un phénomène assez étrange avec l'activation de Windows 11 sur une nouvelle configuration.

Dimanche j'ai changé la configuration complète de mon HTPC sauf le SSD. J'ai fais un premier démarrage sur le vieux Windows 11 (qui utilise un compte local seulement) avant de faire un formatage et une réinstallation de Windows 11.

Et aujourd'hui je me suis rappelé que je n'avais pas activé Windows et que je n'ai pas eu la watermark.

Je lance mon HTPC et je vois que Windows est activé. Je suis toujours en compte local.

Est-ce que le fait d'avoir démarré sur le SSD avec l'ancien Windows activé a permis l'activation numérique sur la nouvelle configuration ?

PS : C'est une clé acheté sur Rakuten  

Normalement, ce premier démarrage devrait avoir fait sauter l’activation (puisque sur une nouvelle CM, donc une nouvelle machine selon MS, peu importe que tu aies gardé le boîtier). On ne saura jamais si ce fut le cas, puisque tu n’as pas regardé à ce moment-là.
 
Mais il est possible que la nouvelle installation, puisqu’elle a détecté qu’il y avait déjà eu un Windows présent dessus (même cette seule fois), ait alors permis une activation automatique quand elle s’est terminée, car l’ID matériel utilisé pour celle-ci aura été envoyé lors de ce premier démarrage après changement de config et avant réinstallation.

Pour moi aussi ça devait sauter. La carte mère est neuve, le processeur et la ram viennent de mon PC principal que j'ai upgrade.

C'est un mystère. A la limite avec un compte MS ok, mais là je n'ai fais que des installations avec un compte local.  

Si je me rappelle bien, l'activation est sauvegardé dans Windows\System32\spp\store (pour un compte local, je ne sais pas avec un compte MS)
En démarrant avec W11 activé, ça a peut-être "sauvegardé" l'activation

Je pense aussi. Le fait d'avoir démarré une première fois le PC avec le Windows qui était installé sur l'ancienne config a dû transférer la licence sur la nouvelle la config.  
 
Etrange, mais bon je vais pas me plaindre, ça me fait économiser 90cts.  

Ça dépend surtout du type de licence.
Une licence OEM va forcément se désactiver et tu devras racheter une licence.
Une licence avec droit de transfert se transférera d'elle même lors de la prochaine activation, liée à un compte Microsoft ou non.
 
Et techniquement l'activation n'est pas stockée sur le PC mais chez Microsoft, son statut uniquement mis en cache en local.

Je ne veux pas être mauvaise langue mais j'ai besoin de raler (et d'un coup de main) avec mon W11 j'ai des problèmes que je n'avais jamais eu avec tous les windows précédent (depuis 3.1) !
 
Bref 2 trucs  :
- assez régulièrement les associations des applications sautent, mes images ne s'ouvrent plus avec irfanview, mes pdf avec adobe, mes html avec firefox... c'est juste chiant à refaire !
Une idée ?
- dernière embrouille en date : mes icones de fond d'écran clignotent un peut plus vite que un herz et j'ai le temps de reconnaitre l'icone par défaut avant que la "normal" ne revienne.
 
Internet m'a dit de virer/remettre les driver GPU (rx9070) ce que j'ai fait sans aucun changement.
C'est tellement cheloud que j'en ais fait une vidéo :
https://youtu.be/q2kvRS6Ogjo

Tu peux essayer en supprimant le fichier IconCache.db dans AppData\Local et redémarrer le processus explorer.exe
Pas sûr que ça aidera mais ça coûte rien d'essayer

testé => aucun changement :-/
J'ai aussi essayé de killer et relancer explorer.exe
et
sfc /scannow puis DISM /Online /Cleanup-Image /RestoreHealth

Le truc c'est que je 'narrive aps à savoir à quel moment ça c'est mis à faire ça.
C'est récent mais il me semble qu'après avoir maj les drivers AMD ça fonctionnait encore correctement.
Ya un truc que j'ai fait c'est que j'ai recréé la bonne entrée
MouseHoverWidth
dans Ordinateur\HKEY_CURRENT_USER\Control Panel\Mouse
avec un valeur chaine à 2000
Je vais remettre comme avant pour voir.

Edit : ce n'est pas ça.
Je vois que j'ai 2 périph avec un warning je vais essayer de résoudre ça