Un générateur d’environnement de récupération Windows et de clé USB bootable en 200 Ko

 (github.com/joshuacline)
3 points par GN⁺ 2024-07-29 | 1 commentaires | Partager sur WhatsApp
  • Windows Deployment Image Customization Kit est un outil de déploiement d’images Windows basé sur un shell de commandes natif, présenté dans le titre HN comme un générateur d’environnement de récupération Windows et de clé USB bootable de 200 Ko
  • Concernant SecureBoot, il est pris en compte que l’utilisation de bootmgfw_EX.efi, situé dans le dossier EFI_EX de boot.wim, à la place du bootmgfw.efi classique entraîne moins de problèmes de compatibilité
  • Pour l’instant, le projet attend de voir dans quelle direction Microsoft va standardiser ; si cette direction ne devient pas claire, il prévoit soit de récupérer le bootloader EFI_EX, soit de permettre de choisir entre les deux approches
  • Pour le moment, l’utilisateur peut récupérer lui-même le bootloader depuis l’emplacement EFI_EX, le placer dans le dossier cache, puis lancer la mise à jour des fichiers de démarrage depuis recovery
  • En désactivant SecureBoot, Windows peut continuer à fonctionner normalement jusqu’à ce que Microsoft décide quel bootloader standardiser

Outil de déploiement d’images Windows

  • Windows Deployment Image Customization Kit est un outil de déploiement d’images Windows basé sur un shell de commandes natif
  • Dans le titre HN, ce projet est présenté comme un générateur d’environnement de récupération Windows et de clé USB bootable de 200 Ko
  • Le README inclut des captures d’écran de l’interface graphique et de l’écran MenuScript

SecureBoot et gestion du bootloader

  • Utiliser bootmgfw_EX.efi, situé dans le dossier EFI_EX à l’intérieur de boot.wim, à la place du bootmgfw.efi classique entraîne moins de problèmes de compatibilité avec SecureBoot
  • La raison pour laquelle ce changement n’est pas appliqué immédiatement est que la direction de Microsoft n’est pas encore claire
  • Si la direction de Microsoft ne se clarifie pas, l’un des changements suivants pourrait être appliqué
    • Récupérer le bootloader depuis le dossier alternatif EFI_EX
    • Rendre sélectionnable l’une des deux approches de bootloader
  • L’objectif est d’éviter une situation où un changement effectué maintenant devrait ensuite être annulé

Réponse manuelle possible aujourd’hui

  • L’utilisateur peut récupérer directement le bootloader depuis l’emplacement EFI_EX
  • Après avoir placé le bootloader récupéré dans le dossier cache, il peut lancer la mise à jour des fichiers de démarrage depuis recovery
  • En désactivant SecureBoot, Windows peut être utilisé normalement jusqu’à ce que Microsoft décide de l’orientation du bootloader standard

Distribution et documentation

  • Miroirs :
    • MajorGeeks : miroir de Windows Deployment Image Customization Kit
    • Softpedia : miroir de Windows Deployment Image Customization Kit
  • Documentation :

À lire aussi

1 commentaires

 
GN⁺ 2024-07-29
Avis de Hacker News

  • C’est le plus gros fichier batch que j’aie jamais vu. Je trouvais déjà excessif celui d’un peu plus de 200 lignes que j’avais fait au lycée, mais l’acharnement à pousser batch jusque-là est vraiment impressionnant.
    Je connaissais un peu les pseudo-appels de fonctions et la syntaxe bizarre, mais rien qu’en le parcourant, je vois plein de choses que je n’avais jamais vues. D’habitude, les projets du genre « X in Y KiB » passent beaucoup par des bidouilles étranges du linker, donc celui-ci est rafraîchissant. Et les noms de fonctionnalités « Windows To Go » et « Windows To Stay » sont assez drôles.

    • Puisqu’on parle de gros fichiers batch, si vous avez déjà softmoddé une Wii, il y a de fortes chances que vous ayez utilisé ModMii, et c’est de loin le plus gros programme batch que j’aie vu.
      Le script principal [1] est un fichier batch de plus de 1 Mo. À une époque, j’étais pas mal plongé dans le modding de Wii, et je me souviens avoir échangé quelques fois avec l’auteur de ce script sur diverses choses liées aux batchs. Je n’imagine même pas maintenir un fichier de cette taille.
      [1] https://github.com/modmii/modmii.github.io/blob/master/Suppo...
    • « Windows To Go » est le nom officiel d’une ancienne fonctionnalité de Windows.
      Avec PowerShell inclus par défaut, écrire un script batch, qu’il fasse 3 085 lignes ou n’importe quelle longueur, relève de la pure folie.
    • C’est un peu hors sujet, mais ça me rappelle un fichier batch de plus de 300 lignes que j’utilisais sur un BBS au début des années 90.
      Il y avait plein de tests d’errorlevel pour gérer les changements de door, Fidonet, etc. Quand on avait vraiment besoin de fonctionnalités supplémentaires, les fichiers batch pouvaient devenir absurdement complexes.

  • À noter : aucune licence n’est indiquée.

  • D’après ce que je sais, « Windows Recovery Environment » est une version minimale et réduite de Windows, privée de la majeure partie de l’espace utilisateur standard et d’une partie du noyau, que les gens ont étendue et personnalisée de diverses manières.

    • La conception générale s’inspire de l’interface texte simple qu’utilisait ClockworkMod Recovery sur Android.
      Il n’y a aucune dépendance.

  • C’est l’un des outils basés sur un shell les plus impressionnants que j’aie utilisés. Le simple fait que ça tienne dans 200 Ko est une réussite, et c’est malin.

  • C’est un détail minuscule, mais les pluriels du type FOO’S me font tiquer.
    Si VHDXS prête à confusion, il suffit de sortir du tout-majuscules et d’écrire VHDXs.
    https://www.hamilton.edu/academics/centers/writing/seven-sin...

  • Ça a l’air chouette, mais je me demande ce que ça apporte que la partition Windows Recovery Environment standard ne fait pas.
    Est-ce destiné aux cas où l’environnement de récupération standard est cassé ? Je me demande aussi si le récent incident CrowdStrike entrait dans ce cas.

    • Pour le récent incident CrowdStrike, non.
      Sur mon ordinateur portable professionnel, l’environnement de récupération fonctionnait toujours correctement, je pouvais démarrer en mode sans échec, et le mode sans échec ne plantait pas.

  • Est-ce qu’on pourrait installer un pilote ou un firmware de moniteur avec ça ? Je me demande s’il serait possible de créer une clé USB bootable, d’y mettre l’installateur, puis d’installer le firmware.
    https://www.lg.com/au/support/product-support/cs-32GS95UE-B....
    J’ai aussi pensé à essayer avec WINE, mais ça me fait un peu peur. Malheureusement, le nouveau firmware de mon moniteur ne s’installe que via un exe, et je n’ai actuellement qu’un desktop Linux.

    • En général, je procède comme ça. D’abord, je décortique l’EXE pendant quelques heures à quelques jours. Parfois, ce n’est qu’un exécutable auto-extractible et on peut trouver le binaire du firmware d’origine. Parfois, il faut plusieurs jours à réapprendre les bases de R2/Ghidra avant de réussir à extraire le firmware.
      Ensuite, si je l’ai trouvé, je cherche comment le flasher. Quand je pense avoir trouvé une méthode, je m’assure absolument qu’il soit très tard et que je sois assez fatigué pour être vaseux. C’est comme ça que je deviens convaincu de pouvoir le faire sans le briquer. Et puis, si on ne risque même pas de le briquer, où est le plaisir ? Il suffit de prendre une quelconque pince SOIC Pomona contrefaite et de dumper une ROM au hasard depuis la puce.
      Enfin, si j’étais encore assez éveillé pour ne pas me laisser piéger par les étapes précédentes, je jette tout ce que j’ai fait jusque-là et je décide de consacrer du temps à créer une clé USB Windows bootable. Si ça ne marche pas pour l’une des nombreuses raisons possibles, j’emprunte un laptop Windows. Mais à ce stade, je suis déjà trop fatigué, donc je crée une machine virtuelle Windows dans QEMU et je redémarre l’ordinateur en boucle en bricolant la configuration de passthrough nécessaire pour connecter l’appareil. Je lance l’utilitaire et l’EXE, et ça commence à fonctionner. Je suis tellement excité que je débranche accidentellement toutes les connexions au milieu. D’une manière ou d’une autre, le moniteur semble toujours fonctionner, mais je suis convaincu qu’il y a quelque chose de subtilement anormal. Quelques années plus tard, je ressors la pince SOIC. C’est un récit composé de plusieurs de mes mésaventures.
      En pratique, oui. Il y a de bonnes chances que ce projet permette de faire ce genre de chose sans trop de problèmes. Mais il faut quand même s’attendre à ce que l’installateur soit un bloatware total qui ne marche pas du tout, ou fasse semblant de fonctionner presque jusqu’au bout avant que quelque chose ne déraille.
    • Ce genre de petit utilitaire peut parfois s’exécuter aussi sous FreeDOS/MS-DOS après démarrage depuis une clé USB ou un CD.
      Dans d’autres cas, il faut Win32, et là on finit par utiliser quelque chose comme une version récente de Hiren’s Boot CD. Si ma mémoire est bonne, les versions récentes sont basées sur Windows 10, tandis que les premières releases étaient basées sur XP.
    • Il y a probablement plusieurs méthodes, mais celui-ci est un script shell de commande Windows, donc il ne fonctionne que sous Windows.
    • Si les logiciels tiers vous conviennent, il est possible de créer une clé USB bootable pour mettre à jour le firmware.
      https://www.hirensbootcd.org/

  • Énorme. Un script shell de 3 000 lignes, quand même ; j’ai du respect pour les gens capables de maintenir ce genre de choses.
    Pour moi, ça ressemble à un sacré bazar brûlant et difficile à aborder.

    • Est-ce vraiment si difficile à aborder ? Je ne suis pas fan non plus des fichiers de 3 000 lignes, mais quand je dois en gérer un, je le traite comme si je gérais plusieurs fichiers.
      J’ouvre un onglet ou un panneau divisé pour chaque « zone » sur laquelle je travaille. Si je travaille sur trois zones, j’ouvre trois panneaux, chacun centré sur l’une d’elles, et je passe de l’un à l’autre. En pratique, c’est presque pareil que de gérer trois fichiers.