Rufus 4.2 BETA is now available from the usual location.
This new version brings the following changes:
- Add detection and warning for UEFI revoked bootloaders (including ones revoked through SkuSiPolicy.p7b)
- Add ZIP64 support, to extract .zip images that are larger than 4 GB
- Add saving and restoring current drive to/from compressed VHDX image
- Add saving and restoring current drive to/from compressed FFU (Full Flash Update) image [EXPERIMENTAL]
- Fix a crash when trying to open Windows ISOs, with the x86 32-bit version
- Increase ISO → ESP limit, for Debian 12 netinst images
- Make sure the main partition size is aligned to the cluster size
Of special interest, I will mention the first item that has to do with warning users if they are using a UEFI bootloader that has been revoked, which mostly stems from the slew of revocations that have been added in the wake of Black Lotus.
As of now, and with the big question mark of what tomorrow's patch tuesday will bring for the second phase of Microsoft's inscrutable Black Lotus mitigation (see here), Rufus will attempt to detect revoked bootloaders from the official UEFI DBX as well as Windows' SkuSiPolicy.p7b, which means that, on a Windows system that have received the relevant May update, you will see something similar to this in your log:
Found 517 officially revoked UEFI bootloaders from embedded list
Found 2351 additional revoked UEFI bootloaders from this system's SKUSiPolicy.p7b
Then, if you happen to use a Windows or ISO that happens to use a revoked bootloader, you will see one of these screens depending on whether the revocation came from the DBX or SKUSiPolicy.p7b on account that SKU Policy based revocation are not handled by the UEFI firmware itself but by Microsoft's boot manager:
However, this whole Black Lotus revocation thing is still a massive mess, especially as, currently, every single of these 3 lines from Microsoft's official https://uefi.org/sit...elease_info.pdf detailing the revocation is inaccurate:
• Boot Managers from Windows 8 to Windows 10, version 1507: revoked by DBX entries
• Boot Managers from Windows 10, version 1507 to Windows 10, version 1607: revoked by hash by SKU SiPolicy
• Boot Managers from Windows 10, version 1703 to today: revoked by version number by SKU SiPolicy
First one is inaccurate on account that, currently, the Boot Managers from official Windows 8 releases, such as en-gb_windows_8.1_with_update_x64_dvd_4048142.iso are being let through.
Second one is inaccurate on account that. currently, the Boot Managers from official post 1507 and pre 1607 Windows 10 releases, such as en_windows_10_multiple_editions_version_1511_x64_dvd_7223712.iso or en_windows_10_multiple_editions_version_1511_updated_feb_2016_x64_dvd_8379634.iso are not revoked from SKU SiPolicy.
And finally, the third one is inaccurate because the SKU SiPolicy that Microsoft published in May contains absolutely no rule to revocate any binaries by version numbers.
For more on this, you may want to see https://github.com/p...fus/issues/2244. Thus. seeing how botched Microsoft's current Black Lotus mitigation appears to be, one can only wonder how on earth they were left in complete control of the whole Secure Boot signing process (Oh, and you gotta love the irony of Microsoft pushing for their own version of Secure Boot that is "more secure than Secure Boot", where, on Microsoft controlled hardware, they don't allow standard Secure Boot signed bootloaders to go through by default, on account that, according to Microsoft, they might not be as trustworthy as the oh-so-much-safer bootloaders Microsoft produces, only for Microsoft to get exposed with their pants down with a vulnerability that, by the first quarter of 2024, will have forced them to essentially revoke every single Secure Boot signed Windows bootloader that they produced before March 2023).
But anyway, provided Microsoft eventually get their act together, Rufus will try to detect and warn you about using a vulnerable UEFI bootloader...
The other point that might be of interest is experimental support for saving and restoring .ffu image media.
While not much has been made of .ffu to date (and I certainly have not seen Microsoft providing Windows .ffu installation images like they provide Windows ISO installation images), one of the big advantages of .ffu, provided that most of your media you use a Windows file system like NTFS, is that it is smart enough not to perform a sector by sector copy, where you then have to contend with any garbage left over from using quick format rather than slow/full format, but only copy the clusters that are actually in use by the file system, which, can lead to both drastic save/restore speed as well as unheard levels of compression.
For instance, you could create a UEFI:NTFS media from a 1 TB drive, and find that it will compress to only the amount of NTFS data that is actually be used, and create or restore the whole 1 TB .ffu media in a matters of seconds. Note however that, as far as NTFS is concerned, this requires the NTFS partition size to be an exact multiple of the cluster size (hence the reason for the last item from the new ChangeLog).
But of course, unless you create NTFS based Linux installation media, and that doesn't include anything fancy like persistence (or weird ISOHybrid partitions -- there's a reason why Rufus does not default to using DD mode with ISOHybrid), you can forget about benefiting from the .ffu advanges on anything non Windows...
