Petakpa1 akart a laptopjára 2023-as UEFI CA certeket tenni. Nem lett jó vége. És már ez is furcsa, mert semmi nem indokolta, hogy a gép a certek hozzáadása után fekete képernyővel haljon meg. Pedig a Secureboot, Surestart ki volt kapcsolva 
Live Linux alól lett futtatva sbctl parancs, ami a Secureboot beállítására szolgál, pl. cert updatere. Na itt került hozzám a gép hogy EEPROM íróval próbáljam meg helyretenni. A típus 2025 végével EOL lett, hiába Windows 11 kompatibilis (8.gen Intel), ez a cert nincs meg neki a legutolsó UEFI-vel sem.
UEFI 2023
A 2023-as UEFI Certificate of Authenticity azért szükséges, mert a Secureboot bevezetésekori 2011-es cert lejárt idén nyáron.
A Secureboot maga ugye arról szól, hogy a gépen csak tanúsított, piszkálatlan oprendszer futhat. Tehát a EFI ellenőrzi a saját kulcsa alapján, hogy a bootloader aláírása (certificate-e) megfelel-e, majd a loader a kernelt. Ha a loader kulcsa újabb (azaz a EFI nem ismeri) akkor nem engedi elindulni, mert ez ugyanaz az eset, amikor valami ismeretlen kulcsot akarna használni. (Ezek ugyanolyan aszimmetrikus kulcsok, mint a SSL vagy a SSH-hoz használhatóak, tehát a publikus kulcsot kell az UEFI-nek tárolni, azzal ellenőrzi a gyártó által kiadott aláírást a loaderben.) A lejárt kulcs használata azért gond, mert 10 év alatt az akkori algoritmussal előállított kulcsot már visszafejthették kevésbé jó szándékú szereplők, ugyanúgy, mint SSL certeket.
A Microsoft hamarosan nem fogja használni a 2011-es certet a Windows bootloaderében (jelenleg még ott van benne a 2011 és a 2023 is, legalábbis 25H2-ig mindenben), így azokon a gépeken, amiken UEFI update vagy kézi úton nem került be a kulcstárolóba a 2023-as kulcs, nem fog elindulni a Windows Secureboottal (úgy néz ki, hogy ami régebbiről van upgradelve, azokban is ott marad a 2011-es cert, de kérdés mi lesz, ha újra lesz telepítve egy újabb verzióval). És ki tudja mikor majd csak azzal fog elindulni, Rufus ide vagy oda. (Gondolom a kompromittálódott kulcsokat is azért nem sietett a MS visszavonatni, mert sok gép ledöglött volna tőle, de így már semmit nem ér az egész, csak macera.)
Tehát a Secureboot amúgy nem hülyeség (sokféle támadás ellen valóban véd, pl ha valami megmókolja a kernelt, bootloadert... szóval ilyen módon egy malware sem tud perzisztenciát elérni), de szokásos MS logika szerint nem tűnik úgy, hogy a 10-es évek elején valaki átgondolta volna, mi lesz, ha lejár a cert (meg sok minden mást se). 
Amúgy a kulcsok maguk a CA (a certificate, amivel a Microsoft bootloader eredetiségét lehet igazolni), PK (Platform key, amivel a HW platformét), KEK (Key exchange key). A CA a db nevű adatbázisba kerül, a többi OS kulccsal (pl. a Linuxon MOK-nak nevezettel), a dbx adatbázis pedig a visszavont kulcsokat tartalmazza.
Nyomozzuk ki mi baja
Persze, meg lett próbálva FAT32 pendrive-al, billentyűnyomás mellett bekapcsolni... Áh. 
Szerencsére az alja nem volt rajta már amikor érkezett, szóval csak a műanyag keretet kellett leszedni.
Nem szép, de működött. A UEFI flashtől balra a Surestart flash chipje.
A barna egy adapter, amivel a flash íróba be lehet dugdozni a drótok végét.
Szóval ki kellett olvasni a BIOS-t. Hát, az könnyű. ...lenne, ha SOIC8 tokos lenne a flash, mint minden rendes gépen, de ezen WSON8. Kösz... Tehát forrasszunk rá 8 vezetéket (baromi ronda lett 
) és reménykedjünk, hogy a hivatalosan-5-voltos-de-amúgy-3,3v-os CH341A olvasó nem vágja haza. Tehátsudo flashrom --programmer ch341a_spi -r backup.bin -c W25Q256JV_Q(A flash ugyanis Winbond W25Q64JVEQ.)
Nem vágta (mint kiderült, bajban lettünk volna, ha megdöglik a chip). Tehát volt egy dumpom. Jött az ötlet, hogy ha csak valami beleírt a certekbe, akkor azt ki is lehet javítani, és mivel nem tudtuk, hogy esetleg a (z amúgy meg kikapcsolt) Surestart keze van-e a dologban (ez a HP plusz védelme boot módosítás ellen, konkrétan ha illegális módosítást észlel, helyre tudja állítani az egész UEFI-t), amiről azt biztosan tudni, hogy akár a SB certeket is simán visszaírja, jobbnak tűnt a gyári tartalommal próbálkozni.
A Chatgpt csapágyasra hajtása után (végig elég sok AI segítség volt a módszerek kikeresésére, ellenőrzésre, szóval Google helyett) az tűnt valószínűnek, hogy a NVRAM területen a EFISystemNvDataFvGuid volume borult meg (ebben vannak a Secureboot kulcsok is).
Javítsuk ki
Letöltöttem a HP-tól a legújabb BIOS-t. 1.31. Mondjuk a kiolvasott tartalomban nem az volt a verziószám, de amúgy Petakpa1 mondta, hogy fel volt húzva a legújabbra, szóval ez a sokadik WTF. 
Uefitool 0.73-al megnyitva a kiolvasott dumpot meg a HP update-ét, látszott, hogy a két terület mérete azonos, de az update-ben üres ez a volume. Az update maga amúgy egy rakás adatot nem tartalmaz, nem is a flash terület elején kezdődik, szóval azt simán felírni nem lett volna jó ötlet.
Az update-ből kiexportáltam az üres EFISystemNvDataFvGuid -t, de a 0.73-as Uefitool nem tud beleírni a dumpba. Tehát kellett egy 0.28-as, ami bele tud, csak a változóneveket nem ismeri fel A megfelelő változót így a Filesystem GUID alapján sikerült megtalálni, mert a 0.28 ezzel mutatott mindent ( FFF12B8D-7696-4C8B-A985-2747175B4F50, ez látszik az Uefitool 0.78-ban is a jobb oldalon ). Méret és stb. is egyezett.
0.73-as Uefitool Linuxon, az említett GUID is pont látszik
A kész BIOS file visszaírásra került a flashbe,sudo flashrom --programmer ch341a_spi -w backup_newnvram.bin -C W25Q256JV_Q
és bekapcsolva a gépet, az szépen adta is a HP logot Párszor újraindult. Szóval a neheze megvolt 
Párszor rebootolni kellett, meg először nem volt bootmenü, csak PXE-ről akart bootolni, de aztán magához tért az egész, és normálisan működött.
#navégremán.
Mégiscsak kéne az a 2023-as CA
Mert hát azért kezdődött ez a macera. Jobb ötletnek tűnt nekem megpróbálni, mint még egyszer oda-vissza adni a gépet.
Első körben volt a BIOS-ban egy Enable Microsoft CA 2023 opció. Alapvetően nem jöttem rá, mit csinál. Papíron ennek engedélyeznie kellene a 2023-as certet, de ettől még nem lett ott a kulcsok között. Na de hogy kerül be? (Van némi outaded, de talán hasznos HP doksi is.) A művelet előtt a Surestart, Secureboot off (ha esetleg be lett volna kapcsolva), TPM clear, SB kulcsokat törölni, és Reset to setup mode.
Van a HP UEFI-ben opció kulcsok importálására. Fél napnyi macera volt AI segítséggel előállítani 4 kulcsot, amit esetleg megeszik a HP updater, ezeknek megfelelően a NVRAM változó tartalomnak kellett benne szerepelni, a változó fejléc nélkül. Letenni ezt a 4 file-t az EFI partícióra a háttértáron, reboot, és... persze hogy nem ette meg A PK-t meg elő se lehet állítani, mert a HP privát kulcsa ugye nincs meg senkinek (legálisan ). Bár mint kiderült, a PK pont nem fog kelleni (Amúgy a 2023-as CA beszerezhető.)
Van még a Keytool EFI script, ami megoldás lehet a problémára; nekem nem működött (valószínűleg a HP UEFI-jének valami architekturális problémája, ezen EFI shell sincs, és bár az EDK2 shell (közben leesett, hogy ezt ismeri az egyszeri IT-s EFI shell néven ) működik, ha a boot menüből elindítja az ember, de a Keytool sehogyan). Ez azért lett volna jó, mert alapvetően jó egy minél alacsonyabb szinten futó, és authentikált kóddal macerálni a kulcsokat.
Még a tulajdonos (aki amúgy sok használható anyagot kitúrt az egészhez 
) küldte a Garlin nevű Github user scriptjeit. Ezek a korábban történtek fényében rizikósnak számítottak, de a már működő BIOS-ról is csináltam egy mentést, szóval reménykedtem, hogy vissza lehet írni, ha ez is megborul. Nosza, lefuttatjuk, aztán lesz ami lesz.
(Még hogy Windows alatt nem kell parancssor. Most az egy dolog, hogy telepíthettem fel egy 11-et )PS C:\Users\user\Desktop\share\SecureBoot-CA-2023-Updates> .\Update_UEFI-CA2023.ps1Downloading "edk2-x64-secureboot-binaries.zip" from GitHub.Successfully wrote "Default3PDb.bin" to UEFI db.Successfully wrote "DefaultDbx.bin" to UEFI dbx.Successfully wrote "DefaultKek.bin" to UEFI KEK.ERROR: Failed to write "DefaultPk.bin" to UEFI PK.Wrong signature for this UEFI variable.PS C:\Users\user\Desktop\share\SecureBoot-CA-2023-Updates>
Láthatólag a PK-t nem tudta felírni, így volt némi para, de simán újraindult, működött ahogy kell.
Az egy bajom az, hogy így a CA csak egy sima kulcs. Egy Secureboot ki-be nem törli, de egy "Reset to setup mode" vagy kulcstörlés az igen. Viszont elvileg ezt csak így lehet, szóval úgy tűnik, hogy minden rendben van az UEFI-ben. A Garlin scriptjei között levő ellenőrzés viszont azt mutatta, hogy még aktív a 2011-es CA. (Ellenőrizni a Garlin cuccai között levőCheck-UEFI.bat -verbose scripttel lehet.)
Lehetne visszavonni a 2011-es certet is (ilyenkor az átkerül a dbx adatbázisba) de nem voltam ilyen bátor A Surestart maradt kikapcsolva.
Próbáltam keresni olyasmit, ami csak a 2023-as CA-val van már aláírva, de sem az Ubuntu 26.04, sem a 25H2 Win11, sem semmi nem ilyen még, mindegyik loadere tartalmazza a 2011-es CA-t is. Viszont ezek mind simán működtek Secureboot mellett, és a gép eredeti SSD-jén levő Windows 11 is bootolt (mivel nem volt Bitlockeres). Petakpa1 később ellenőrizte, hogy milyen certtel is hitelesített be a futó Win11, és elvileg az újjal, szóval örülünk
