original yellowkey repo is gone, add mirror

readme.md

@@ -41,7 +41,7 @@ Where code execution can be obtained inside a boot application, it may be possib
 | break out in hives: systemdatadevice element causes winload to use attacker specified SYSTEM hive | Starting from Windows 10 (th1), support for the `systemdatadevice` element was added to winload. If present, winload reads the SYSTEM hive from this device instead of osdevice.<br><br>Thus, attacker can grab SYSTEM hive from WinPE, modify Setup!CmdLine to cmd.exe, and cause winload to use this hive when booting WinRE.<br><br>When booting WinRE after this, a SYSTEM shell will open with the bitlocker keys in memory for osvolume if they were derived; thus, bitlocker bypass.<br><br>Fixed by removing the ability to load SYSTEM hive from systemdatadevice. This bug is CVE-2024-20666. | January 2024 (winre image must be patched manually) | February 2025; discovered in March 2023 | Rairii |
 | break out in hives 2: alternative method for exploiting systemdatadevice element, usable with a downgrade attack | The fix for break out in hives updated winload.<br><br>However, earlier (unfixed) revisions of winload can **potentially** still run to boot its major version of Windows (may not work in practise for every version).<br><br>Thus, attacker can bring in an old winload, modify BCD to boot from it, and repeat the attack, however a different exploitation method must be used.<br><br>**The `winpe` element must be set in BCD (if it is not, the SYSTEM hive in the bitlocker encrypted osvolume will get corrupted!)**<br><br>The working SYSTEM hive here would come from an `install.wim` image of the same major version of Windows (not WinPE/WinRE). The Win32 subsystem will not be able to initialise fully, but smss can be configured in `ControlSet001\Control\Session Manager!SetupExecute` to achieve arbitrary native subsystem code execution as SYSTEM with derived keys in memory.<br><br>Fixed by wiping `systemdatadevice` element in bootmgr if Secure Boot is enabled, but the fix was only applied to the PCA 2023-signed bootmgr_ex, so **without the KB5025885 mitigation enabled, this vulnerability is still present and remains unfixed.** This bug is CVE-2025-21213. | January 2025, in PCA2023-signed bootmgr_ex only | February 2025; discovered in January 2024 (after the original fix) | Rairii |
 | Boot environment does not check SDI when loading ramdisk, which has offset to the used WIM | When loading a ramdisk, the boot environment (and NT `wimfsf.sys`) gets the offset to the used WIM from the SDI file if it's present, and there is no validation of the SDI file used. Therefore a crafted SDI file can be used in the recovery sequence to boot an arbitrary WinPE WIM with the osdevice bitlocker keys derived.<br><br>Fixed by checking that the calculated WIM offset is equal to the actual load offset of the WIM, and returning STATUS_INVALID_IMAGE_FORMAT if not. This bug is CVE-2025-48804. | July 2025 | August 2025 (at Black Hat) | Alon Leviev and Netanel Ben Simon of Microsoft (MORSE) |
-| [YellowKey](https://github.com/Nightmare-Eclipse/YellowKey) aka trans writes: Filesystem transaction files located on one volume can affect files on another volume | Germanium introduced a new filesystem transaction feature (unrelated to NTFS transactions). Logs for this are on disk and parsed by `fstx.dll` (part of the servicing stack), and in WinPE only it is loaded by new native executable `autofstx.exe` ("Boot-time FsTx Update Recovery Utility" - "This utility recovers failed FsTx updates at boot-time.") which smss runs due to registry entry.<br><br>These logs contain full NT paths, and thus can affect files on another volume.<br><br>This can be used when booting WinRE with a removable drive attached (NTFS formatted) to delete `winpeshl.ini` on the ramdisk. With this file deleted, `winpeshl.exe` will launch a SYSTEM shell if Ctrl key is held, with the derived osdevice bitlocker keys in memory.<br><br>See also [additional writeup by Will Dormann](https://infosec.exchange/@wdormann/116565129854382214). This bug is CVE-2026-45585. | None | May 2026 | Nightmare-Eclipse |
+| [YellowKey](https://github.com/Nightmare-Eclipse/YellowKey) aka trans writes ([mirror](YellowKey-main.zip), password: `bitlocker`): Filesystem transaction files located on one volume can affect files on another volume | Germanium introduced a new filesystem transaction feature (unrelated to NTFS transactions). Logs for this are on disk and parsed by `fstx.dll` (part of the servicing stack), and in WinPE only it is loaded by new native executable `autofstx.exe` ("Boot-time FsTx Update Recovery Utility" - "This utility recovers failed FsTx updates at boot-time.") which smss runs due to registry entry.<br><br>These logs contain full NT paths, and thus can affect files on another volume.<br><br>This can be used when booting WinRE with a removable drive attached (NTFS formatted) to delete `winpeshl.ini` on the ramdisk. With this file deleted, `winpeshl.exe` will launch a SYSTEM shell if Ctrl key is held, with the derived osdevice bitlocker keys in memory.<br><br>See also [additional writeup by Will Dormann](https://infosec.exchange/@wdormann/116565129854382214). This bug is CVE-2026-45585. | None | May 2026 | Nightmare-Eclipse |
 | [ram leak](#ram-leak): Boot environment has no restrictions on ramdisk creation device | When configured to create a ramdisk, the file to load and device to load it from is provided in the BCD.<br><br>The boot environment has no checks on the device passed, and thus, BitLocker-encrypted partitions are allowed, assuming the keys can be derived.<br><br>Therefore, an attacker can set up a ramdisk with an arbitrary file from a BitLocker-encrypted partition, and the file contents will stay in RAM even if the derived BitLocker keys are wiped, and can be dumped later.<br><br>Additionally, an attacker can use this to determine whether a file exists on a BitLocker-encrypted OS partition.<br><br>Interesting targets include: hibernation file (contains derived bitlocker keys, and is compressed so should fit entirely into RAM, especially if "shutting down" aka logoff-then-hibernate from the logon screen), pagefile, SYSTEM and SAM hives, any third-party service or driver (identified from SYSTEM hive) to check for vulnerabilities. | None. MSRC closed as low priority due to misunderstanding. | May 2026, originally discovered March 2025. | Rairii |
 
 ### dangerous association