Secure Boot: UEFI-bootmanager controleren in Windows

Voor een eerste, snel overzicht volstaat een blik op de eerste kolom van de tabel. Onder Bestand staat niet alleen de naam van het betreffende bootmanager-bestand, de cel is ook gekleurd gemarkeerd.

Als hier alles groen is, zullen alle door het script onderzochte bootmanagers op je pc opstarten, of ze nu op de interne schijf of op een USB-stick staan. Maar als je wilt weten waarom bepaalde bestanden gekleurd zijn, moet je de andere kolommen bekijken. Laten we ze een voor een doornemen.

De tweede kolom geeft het volledige pad naar het bootmanager-bestand weer. Bij bestanden die op de interne schijf staan, begint het pad meestal niet met een stationsletter, maar met <ESP>:. Deze afkorting staat voor ‘EFI System Partition’, een schijf die in Verkenner standaard niet zichtbaar is.

De ESP is aanwezig op alle computers die via UEFI opstarten. Het verschilt van een normale gegevenspartitie door een speciaal partitietype, dat ervoor zorgt dat Windows het extra beschermt en verbergt. Meer details hierover vind je in [1, 2]. In [3] hebben we een script laten zien waarmee je een overzicht van de inhoud kunt krijgen.

Bij bestanden die op een USB-stick staan, geeft c’t-UEFILoaderInfo het pad wel vaak weer met een stationsletter. Maar ook hier kan het gebeuren dat de belangrijke bestanden op een verborgen partitie staan. Dan begint het pad met <USB>:. De kolommen Disk, Part. en Vol. geven in Diskpart-terminologie de nummers aan van het fysieke opslagmedium, de partitie en het volume.

De kolom Producent is bedoeld om je te helpen de bestanden te classificeren. Standaard heten namelijk vooral op USB-schijven alle bootmanager-bestanden hetzelfde: Bootx64.efi. Het maakt daarbij niet uit of er een bootmanager voor Windows of Linux in zit. De naam is zo voorgeschreven door de UEFI-specificatie.

Kenners hebben de kolom Producent eigenlijk niet nodig, want ze kunnen aan de hand van het certificaat zien of een bootmanager van Microsoft komt of niet. Maar omdat de aanduidingen MS (voor Microsoft) en Non-MS makkelijker uit elkaar te houden zijn, hebben we de kolom toch toegevoegd.

Het pad \EFI\Boot\Bootx64.efi kent elke UEFI-firmware standaard. Je kunt echter ook andere paden instellen. Bij het installeren van Windows schrijft het installatieprogramma bijvoorbeeld het pad <ESP>:\EFI\Microsoft\Boot\bootmgfw.efi in de firmware-instellingen (bij Linux heet de tegenhanger shimx64.efi) en staat niet in de map Microsoft, maar in een map die dezelfde naam heeft als de fabrikant of de distributie. Daardoor wordt <ESP>:\EFI\Boot\Bootx64.efi een fallback-optie. Deze wordt niet meer gebruikt, tenzij bootmgfw.efi ontbreekt of defect is.

De naam van bootx64.efi is architectuurafhankelijk, want zo heet het bestand alleen op computers met een x86-processor met 64-bits uitbreiding (door Microsoft aangeduid als ‘x64’). Op 64-bits ARM-computers heet het bestand in plaats daarvan Bootaa64.efi. De zeer zeldzame 32-bits tegenhangers zijn bootia32.efi (x86) en bootarm.efi (ARM).

Achtergrond: niet alleen moet alle gangbare software compatibel zijn met de processorarchitectuur om te kunnen draaien, maar dat geldt ook voor UEFI-firmware en de bootmanager. Die van andere architecturen werken niet.

Mocht je je nu afvragen waarom oude 32-bits-programma’s dan wel draaien op een x64-pc met 64-bits Windows: daarvoor gebruikt het besturingssysteem een emulatielaag die zo soepel werkt dat je er bijna niets van merkt.

De UEFI-firmware heeft echter geen emulator, daarom is op een moderne x64-pc een 64-bits bootmanager nodig. Let op: ons script toont EFID-bestanden van alle architecturen. Zo’n mix kun je bijvoorbeeld tegenkomen op opstartbare USB-sticks die voor meerdere architecturen zijn bedoeld. Alles wat op je huidige computer niet opstart alleen vanwege de verkeerde architectuur, wordt wit gemarkeerd, mits het om geldig ondertekende bestanden gaat.

De kolom Microsoft-certificaten laat zien of een bootmanager-bestand is ondertekend met een certificaat dat door Secure Boot wordt erkend. Hiervoor moet het in de UEFI-certificaatopslag in de toestemmingsdatabase db staan (meer hierover in het vorige artikel).

Bovendien mag het niet in de verbodsdatabase dbx staan, want wat hierin staat, heeft altijd voorrang. Een bootmanager die is ondertekend met een certificaat uit de dbx, wordt door de UEFI-firmware geblokkeerd.

Even wat achtergrond over de Microsoft-certificaten: als je met andere tools, zoals Microsofts Sysinternals-freeware Sig-Check.exe, een bootmanager-bestand onder de loep neemt, zul je veel meer certificaten ontdekken. Ook in Verkenner kan het in de eigenschappen van het bestand op het eerste gezicht lijken alsof een bestand op een andere manier is ondertekend. De reden: een bootmanager wordt eerst ondertekend door de producent, dus door Microsoft, een Linux-distributeur of iemand anders. Maar is de producent wel wie hij zegt te zijn?

Dat wordt bevestigd door iemand met nog een certificaat. Of die bevestiging op zijn beurt weer betrouwbaar is, wordt door nog een ander certificaat gegarandeerd, en zo ontstaat er een certificaatketen. Aan het einde zit bijna altijd Microsoft (root-certificaat), de details hierover hebben we in het eerste artikel van deze reeks beschreven.

Het belangrijkste: in de db hoeft niet per se een specifiek certificaat uit de vertrouwensketen te staan om de UEFI-firmware een daarmee ondertekend bestand door te laten, maar gewoon eentje uit de keten. In de praktijk zijn dat nu eenmaal die van Microsoft.

Uiteindelijk is weer de kleurmarkering van de cel het belangrijkste. Als het certificaat waarmee een bootmanager-bestand is ondertekend in de db zit, is de cel groen, anders rood. Dat laatste is ook het geval als het certificaat zowel in de db als in de dbx zit, want dan heeft het dbx-verbod voorrang.

Ons script baseert zich bij het beoordelen van de certificaten trouwens niet op de betreffende namen. Maar in principe zeggen die niets. Voor demonstratiedoeleinden konden we zonder problemen een bestand ondertekenen met maar liefst twee certificaten die de relevante namen dragen. Maar dat is natuurlijk een vervalsing van onze kant, want we hebben de privésleutel van Microsoft voor het ondertekenen niet (die heeft alleen Microsoft zelf). c’t-UEFILoaderInfo herkent zo een vervalsing en markeert deze rood.

De kolom Geldig tot geeft de vervaldatum aan van het certificaat waarmee een bestand is ondertekend. Als er nog meer dan een jaar te gaan is, is de datum groen; bij minder dan een jaar resterende looptijd is hij geel, en als hij al is verlopen, is hij rood.

Als een certificaat is verlopen, kan het niet meer worden gebruikt om geldige handtekeningen te maken. Dat is geen technische beperking, maar een afspraak die de betrouwbaarheid moet waarborgen.

De laatste kolom geeft een checksum (hash) weer. Het is echter geen checksum van het volledige bestand, want die zou veranderen zodra de maker de handtekening aan het bestand toevoegt.

Daarom wordt de hash weliswaar met het SHA-256-algoritme gegenereerd, maar wordt daarbij alles weggelaten wat verandert bij het invoegen van de checksum en de handtekening. Dit wordt in het kort PE256 genoemd (PE staat voor Portable Executable, de standaard voor uitvoerbare bestanden onder Windows).

De hashes spelen naast de certificaten de tweede belangrijke rol bij Secure Boot. Ze zijn bedoeld om afzonderlijke bootmanagers te blokkeren, zonder meteen alles te hoeven blokkeren wat met hetzelfde certificaat is ondertekend. Daarom zitten er vaak een paar in het dbx-bestand. Als de hash van een bootmanager in het dbx-bestand staat, kleurt ons script deze rood.

De hash-vermelding in de tabel dient nog een ander doel. Het kwam al ter sprake dat bestanden met de naam bootx64.efi zowel Windows- als Linux- of zelfs andere bootmanagers kunnen bevatten. De checksums laten dat zien: op een pure Microsoft-computer zijn de checksums van bootx64.efi en bootmgfw.efi identiek, bij Linux zijn dat die van bootx64.efi en shimx64.efi. Zo kun je zien wat er in het bestand zit.

Je kunt de tabel sorteren door op de kop van de kolom PE256-Hash te klikken, zodat je dubbele checksums sneller ziet. Op deze manier sorteren werkt ook met alle andere kolommen. Je kunt de weergave resetten via de knop Terugzetten in de menubalk.

Met de tabel van ons script zie je in één oogopslag welke bootmanagers er zijn en of ze op deze pc zullen werken als Secure Boot actief is.

Belangrijk is de kleur van de eerste kolom Bestand. Een groene achtergrond betekent dat alles in orde is. Rood betekent daarentegen ‘geblokkeerd’. In dat geval komt de rode kleur ook voor in een andere cel van dezelfde kolom, waarin dan de reden wordt vermeld.

Maar wat kun je nu met deze informatie doen? In het volgende artikel over zelf maatregelen nemen lees je hoe en wanneer je moet ingrijpen en wanneer het zinloos is om je daar druk over te maken.

Axel Vahldiek en Marco den Teuling

Overzicht van links bij dit artikel

Literatuur

[1] Axel Vahldiek en Noud van Kruysbergen, Partitionering in kaart gebracht, c’t 7/2026, p. 84

[2] Axel Vahldiek en Noud van Kruysbergen, FAQ: Partitionering onder Windows, c’t 7/2026, p. 90

[3] Axel Vahldiek en Noud van Kruysbergen, Een overzicht van de EFI-systeempartitie, c’t 8-9/2026, p. 111