Windows-Wiederherstellungsumgebung und bootfähiger USB-Generator mit 200 KB

 (github.com/joshuacline)
3 Punkte von GN⁺ 2024-07-29 | 1 Kommentare | Auf WhatsApp teilen
  • Das Windows Deployment Image Customization Kit ist ein Windows-Image-Deployment-Tool auf Basis einer nativen Command Shell und wird laut HN-Titel als 200 KB großer Generator für Windows-Wiederherstellungsumgebungen und bootfähige USB-Sticks vorgestellt
  • In Bezug auf SecureBoot ist bekannt, dass die Verwendung von bootmgfw_EX.efi aus dem Ordner EFI_EX in boot.wim statt der normalen bootmgfw.efi weniger Kompatibilitätsprobleme verursacht
  • Derzeit wird abgewartet, in welche Richtung Microsoft standardisieren wird; falls diese Richtung nicht klar wird, ist geplant, den EFI_EX-Bootloader zu übernehmen oder eine Auswahl zwischen den beiden Verfahren zu ermöglichen
  • Aktuell können Nutzer den Bootloader selbst aus dem Speicherort EFI_EX holen, ihn in den cache-Ordner legen und anschließend in recovery die Aktualisierung der Boot-Dateien starten
  • Wird SecureBoot deaktiviert, kann Windows normal weiterverwendet werden, bis Microsoft entscheidet, welchen Bootloader es standardisieren wird

Windows-Image-Deployment-Tool

  • Das Windows Deployment Image Customization Kit ist ein Windows-Image-Deployment-Tool auf Basis einer nativen Command Shell
  • Im HN-Titel wird dieses Projekt als 200 KB großer Generator für Windows-Wiederherstellungsumgebungen und bootfähige USB-Sticks vorgestellt
  • Das README enthält Bilder der GUI-Oberfläche und der MenuScript-Ansicht

SecureBoot und Umgang mit Bootloadern

  • Wenn statt der normalen bootmgfw.efi die bootmgfw_EX.efi aus dem Ordner EFI_EX innerhalb von boot.wim verwendet wird, gibt es weniger SecureBoot-Kompatibilitätsprobleme
  • Der Grund, warum die Änderung derzeit nicht direkt übernommen wird, ist, dass Microsofts Richtung noch nicht klar ist
  • Falls Microsofts Richtung nicht klar wird, könnte eine der folgenden Änderungen umgesetzt werden
    • den Bootloader aus dem alternativen Ordner EFI_EX übernehmen
    • eine Auswahlmöglichkeit zwischen den beiden Bootloader-Verfahren schaffen
  • Man möchte eine Situation vermeiden, in der eine Änderung jetzt vorgenommen und später wieder zurückgenommen werden muss

Aktuell mögliche manuelle Abhilfe

  • Nutzer können den Bootloader selbst aus dem Speicherort EFI_EX holen
  • Danach können sie den übernommenen Bootloader in den cache-Ordner legen und in recovery die Aktualisierung der Boot-Dateien starten
  • Wenn SecureBoot deaktiviert wird, kann Windows normal genutzt werden, bis Microsoft die Richtung für den Standard-Bootloader festlegt

Distribution und Dokumentation

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-07-29
Meinungen auf Hacker News

  • Die größte Batch-Datei, die ich je gesehen habe. Schon meine gut 200 Zeilen aus der Highschool fand ich übertrieben, aber die Beharrlichkeit, Batch so weit zu treiben, ist wirklich beeindruckend.
    Ein bisschen kannte ich schon Pseudo-Funktionsaufrufe und seltsame Syntax, aber schon beim Überfliegen sehe ich vieles, das mir neu ist. Normalerweise läuft es bei „X in Y KiB“-Dingen oft darauf hinaus, den Linker auf bizarre Weise zu missbrauchen; das hier ist erfrischend. Und die Funktionsnamen „Windows To Go“ und „Windows To Stay“ sind ziemlich witzig.

    • Wo wir gerade von großen Batch-Dateien sprechen: Wenn du je eine Wii softgemoddet hast, hast du wahrscheinlich ModMii benutzt, und das ist mit Abstand das größte Batch-Programm, das ich gesehen habe.
      Das Hauptskript [1] ist eine Batch-Datei mit über 1 MB. Früher war ich ziemlich tief im Wii-Modding drin und erinnere mich, mit dem Autor des Skripts ein paar Mal über Batch-Kram geplaudert zu haben. Ich kann mir nicht vorstellen, eine Datei dieser Größe zu warten.
      [1] https://github.com/modmii/modmii.github.io/blob/master/Suppo...
    • „Windows To Go“ ist der offizielle Name einer früheren Windows-Funktion.
      Da PowerShell inzwischen standardmäßig installiert ist, ist es völlig wahnsinnig, ein Batch-Skript zu schreiben – egal ob mit 3085 Zeilen oder in irgendeiner anderen Länge.
    • Das führt zwar ziemlich weit vom Thema weg, aber die Diskussion erinnert mich an eine Batch-Datei mit über 300 Zeilen, die ich Anfang der 90er für eine BBS benutzt habe.
      Da steckten jede Menge errorlevel-Prüfungen drin, um Door-Wechsel, Fidonet usw. zu handhaben. Wenn man wirklich zusätzliche Funktionen brauchte, konnten Batch-Dateien absurd komplex werden.

  • Hinweis: Es ist keine Lizenz angegeben.

  • Soweit ich weiß, ist die „Windows Recovery Environment“ eine verkleinerte Minimalversion von Windows, der der Großteil des normalen Userlands und Teile des Kernels fehlen, und die Leute haben sie auf verschiedene Weise erweitert und angepasst.

    • Das Gesamtdesign wurde von der einfachen textbasierten UI inspiriert, die ClockworkMod Recovery unter Android verwendete.
      Es gibt auch keinerlei Abhängigkeiten.

  • Für ein Shell-basiertes Tool gehört es zu den beeindruckenderen, die ich bisher benutzt habe. Dass es in 200 KB passt, ist für sich genommen schon eine Leistung – und clever.

  • Eine winzige Haarspalterei, aber bei Pluralformen im Stil von FOO'S zucke ich zusammen.
    Wenn VHDXS verwirrend ist, kann man die Großschreibung verlassen und VHDXs schreiben.
    https://www.hamilton.edu/academics/centers/writing/seven-sin...

  • Sieht cool aus, aber ich frage mich, was es leistet, was eine normale Windows-Recovery-Environment-Partition nicht kann.
    Ist das für Situationen gedacht, in denen die Standard-Recovery-Umgebung kaputt ist? Ich frage mich auch, ob der jüngste CrowdStrike-Vorfall so ein Fall war.

    • Beim jüngsten CrowdStrike-Vorfall war das nicht der Fall.
      Auf meinem Arbeitslaptop funktionierte die Recovery-Umgebung weiterhin gut, ich konnte in den abgesicherten Modus booten, und der abgesicherte Modus stürzte auch nicht ab.

  • Könnte man damit Monitor-Treiber oder Firmware installieren? Ich frage mich, ob das möglich wäre, indem man einen bootfähigen USB-Stick erstellt, die Installationsdatei darauf legt und dann die Firmware installiert.
    https://www.lg.com/au/support/product-support/cs-32GS95UE-B....
    Ich habe auch überlegt, es mit WINE zu versuchen, aber das macht mir etwas Angst. Leider lässt sich die neue Firmware für meinen Monitor nur per exe installieren, und ich habe derzeit nur einen Linux-Desktop.

    • So läuft das normalerweise. Zuerst nimmt man die EXE ein paar Stunden bis ein paar Tage auseinander. Manchmal ist es einfach ein selbstentpackendes Archiv und man findet das eigentliche Firmware-Binary. Manchmal bekommt man die Firmware erst heraus, nachdem man sich ein paar Tage lang wieder in die Grundlagen von R2/Ghidra eingearbeitet hat.
      Wenn man sie dann gefunden hat, findet man heraus, wie man sie aufspielt. Wenn man glaubt, eine Methode zu haben, muss es unbedingt sehr spät sein und man muss so müde sein, dass man benommen ist. Nur dann ist man überzeugt, dass man es schafft, ohne das Gerät zu bricken. Und was wäre überhaupt der Spaß daran, wenn man es nicht zumindest riskiert? Man nimmt einfach irgendeinen gefälschten Pomona-SOIC-Clip und dumpt ein zufälliges ROM direkt vom Chip.
      Wenn man schließlich wach genug war, um nicht auf die vorherigen Schritte hereinzufallen, wirft man alles bisher Gemachte weg und beschließt, die Zeit lieber in einen bootfähigen Windows-USB-Stick zu stecken. Wenn das aus einem von mehreren Gründen nicht klappt, leiht man sich einen Windows-Laptop. Aber bis dahin ist man schon viel zu müde, also erstellt man eine Windows-VM in QEMU und startet den Computer wieder und wieder neu, während man an den Passthrough-Einstellungen für die Geräteverbindung herumfummelt. Man startet das Utility und die EXE, und es beginnt zu funktionieren. Vor lauter Begeisterung zieht man mittendrin versehentlich alle Verbindungen ab. Irgendwie scheint der Monitor immer noch zu funktionieren, aber man ist überzeugt, dass irgendetwas subtil nicht stimmt. Ein paar Jahre später holt man den SOIC-Clip wieder hervor. Das ist eine Zusammenfassung mehrerer meiner eigenen Fehlergeschichten.
      Realistisch betrachtet: ja. Mit diesem Projekt kann man so etwas wahrscheinlich ohne größere Probleme erledigen. Man sollte sich aber darauf einstellen, dass der Installer komplette Bloatware ist und gar nicht läuft – oder fast bis zum Ende so tut, als würde er laufen, und dann irgendetwas schiefgeht.
    • Solche einfachen Utilities laufen manchmal auch unter FreeDOS/MS-DOS, gebootet von einem USB-Stick oder einer CD.
      In anderen Fällen braucht man Win32, und dann greift man zu etwas wie einer aktuellen Hiren’s Boot CD. Wenn ich mich richtig erinnere, basiert die aktuelle Version auf Windows 10, während die frühen Releases auf XP basierten.
    • Es gibt sicher mehrere Wege, aber das hier ist ein Windows-Command-Shell-Skript und läuft daher nur unter Windows.
    • Wenn Third-Party-Software in Ordnung ist, kann man einen Boot-USB-Stick für Firmware-Updates erstellen.
      https://www.hirensbootcd.org/

  • Enorm. Ein Shell-Skript mit 3000 Zeilen – ich habe Respekt vor Leuten, die so etwas warten können.
    Für mich sieht das nach einem kaum zugänglichen heißen Durcheinander aus.

    • Ist es wirklich so schwer zugänglich? Ich mag Dateien mit 3000 Zeilen auch nicht, aber wenn ich mit ihnen arbeiten muss, behandle ich sie wie mehrere Dateien.
      Für jeden „Bereich“, an dem ich arbeite, öffne ich einen Tab oder Split. Wenn ich an drei Bereichen arbeite, öffne ich drei Splits, die jeweils auf einen Bereich fokussiert sind, und wechsle zwischen ihnen. Im Grunde ist das fast dasselbe, als würde man mit drei Dateien arbeiten.