* GitHub appears to have updated their HTTP servers to enable gzip compression when requested.
* Unfortunately, the default from Rufus was to attempt to use compression where possible
(ironically in an effort to save GitHub some bandwidth), which doesn't seem to sit too well
with Windows' HttpQueryInfoA(HTTP_QUERY_CONTENT_LENGTH) API, as it errors out on trying to
produce the content-length *DESPITE* the field being reported by GitHub in the HTTP header.
* As a result, we switch all HTTP downloads *not* to try to use compression by forcing
"Accept-Encoding: identity".
* Unfortunately, besides affecting the download of resources such as GRUB/Syslinux ones, it
also affects the ability to look for updates, which means that NONE of the version of Rufus
prior to 4.9 (outside of the Windows Store ones) will be able to find that there exists a
newer version to update to... :(
* Closes#2756.
* Add systemd-boot version reporting and fix GRUB version detection for CentOS
* Add notes about the various Secure Boot gotchas (log only)
* Enable download of remote active/revoked Secure Boot certificate thumbprints
* Also rename the ceiling/floor align macros
* Visual 2022 version 17.14.2 changes the way it performs optimizations with /O2
which results in innocuous C statements, such as invoking strtoul() twice on
the same line, and using the pointer returned by the first call in the second,
crashing the application with a read access violation (when built as RELEASE).
* To alleviate that, we break down the Syslinux strtoul() invocation, as well as
harden our Syslinux version processing while we're at it.
* Hopefully this is the only line of code where the new mode of MSVC optimisation
creates a problem with...
* Closes#2740.
* The openSUSE maintainers don't care about their users, so we have to care in their stead.
* As for Nobara images, that use the Red Hat GRUB bootloaders with no support for NTFS and
that include files larger than 4 GB, we now attempt to detect the filesystems supported
by EFI GRUB, in order to decide how we can proceed with the writing of such images.
We take this opportunity to improve our reporting on the GRUB bootloaders we detect.
* Plus the usual Coverity dance.
* Since we are now liking with ntdll directly, we can remove all the hooks we applied
and just use regular calls. We also rename process.h to ntdll.h as a result.
- Side load SetupAPI.dll, as this is the DLL that was causing the CfgMgr32.dll local load.
This reverts part of 622e60659c since we no longer have to hook into CfgMgr32.dll directly.
- Also set the redefinition of DECLSPEC_IMPORT, which we need for MinGW32 x86, in the global AM_CFLAGS
of configure.ac, so that we no longer have to worry about forgetting to do it in a source and experience
crashes on 32-bit as a result (See 965759f58a).
- Also delay-load crypt32.dll while we're at it.
- Also add provision for enabling /DEPENDENTLOADFLAG:0x800 on MinGW, by leaving a properly crafted entry
in the .rdata section that can then be used with the loadcfg.py Python script.
- Sadly, per https://github.com/pbatard/rufus/issues/2701#issuecomment-2874788564 and subsequent comment,
having DependentLoadFlags set to LOAD_LIBRARY_SEARCH_SYSTEM32 is still not enough to take care of side
loading issues, as, ever since the introduction of wimlib support, we are seeing CRYPTBASE.DLL being
side-loaded in MinGW, and, even with crypt32.dll being delay-loaded there is literally *nothing* we can
do about it!
- The end result of all the above is that we will have no choice but ditch MinGW for release executables
as it's just impossible to properly take care of side-loading vulnerabilities with MinGW (and Microsoft
are REALLY not helping with this whole mess either, when they don't even use LOAD_LIBRARY_SEARCH_SYSTEM32
for Windows' system DLLs).
- In preparation for this, we add UPX compression to the x86_64 and x86_32 MSVC executables.
- Finally, we also fix one last Coverity warning in xml.c and remove duplicates in .vcxproj for ARM64.
* Recent changes broke the check for whether the source image is larger than the target drive
in the case of uncompressed VHDs (that have a 512 byte footer), so fix that by making sure
we always compare with the projected size.
* Closes#2729.
* Also fix some more Coverity warnings.
* DwmGetWindowAttribute() from dwmapi.dll is delay-loaded so it requires the MinGW DECLSPEC_IMPORT workaround.
* Closes#2728.
* Also fix a bunch of Coverity warnings in wimlib and ezxml.
* Now that we have wimlib, we might as well add this has an option for people who really
don't want to use NTFS, even if it falls way short of the performance we get with NTFS.
* Also use wimlib to read the install.wim version.
* Also fix a couple Coverity warnings in stdfn.c/stdio.c.
* This should greatly improves performance when patching boot.wim for WUE or creating Windows To Go drives.
* This also allows us to discard all the bulky (and limited) native WIM API function calls.
* Also add some UTF-8 wrappers to wimlib and a GetTempDirNameU() function call.
* Also revert to the old ssize_t definition in unistd.h, since trying to be too smart throws static analysers off...
* Factorize the log progress bar update into a new uprint_progress() call.
* Add a new FP_NO_PROGRESS flag to disable progress reporting when formatting.
* Alter the progress reporting frequency of wimlib.
* Also update some copyright dates we missed before.
* This includes all the changes applied to wimlib for MSVC compilation support.
* The vast majority of these changes were original, but a very small set came
was lifted from https://github.com/ebiggers/wimlib/pull/6 (which we discovered
after we went through this whole exercise on our own...)
* ezxml was partially altered with some changes from PRs found at https://github.com/lxfontes/ezxml.
* Also apply some small improvements to msapi_utf8.h.
* With Microsoft having finally relinquished the terms of use of DBX binaries (where their
previous legalese pretty much made it illegal for anyone who wasn't an OS manufacturer to
download DBX for use in applications) we can now formally embed, as well as download the
DBXs when they are updated.
* This is accomplished by querying the https://github.com/microsoft/secureboot_objects
GitHub repo (which is now the official repository for the UEFI Forum's revocation files)
through api.github.com and checking the timestamps of the last commit on the relevant files.
If a more recent DBX is found than the one embedded (or a previously downloaded one), Rufus
will now prompt the user to download it, as part of its regular update check (if enabled).
* Note that, since there have been no official revocations for them yet, IA64, RISCV64 and
LoongArch64 are currently placeholders.
* Also note that we currently don't use this mechanism for Microsoft's SVN revocations, as
we already have a more efficient check for it through SBAT.
* Also fix the handling of the RISCV64 MD5Sum UEFI bootloader, whose offset was incorrect.
* Current Rufus and earlier versions (when compiled with MinGW) suffer from a side-loading vulnerability
due to cfgmgr32.dll being attempted to be loaded from the same directory as the executable. This may
result in someone being able to execute elevated malicious code if they already have gained user-level
access to the platform and were able to drop an arbitrary cfgmgr32.dll in the same directory as rufus.
* While we were able to address similar vulnerabilities using delay-loading, this method does not appear
to work for MinGW with this specific DLL, so we remove all the implicit CM_ function calls, that result
in automated DLL loading that cannot be mitigated, to replace them with direct DLL hooks, which are
not subject to Windows' default (vulnerable) DLL lookup behaviour. We still add the def for the delay
loading in case we manage to find how to delay load cfgmgr32 with MinGW in the future...
* Fixes CVE-2025-26624 (https://github.com/pbatard/rufus/security/advisories/GHSA-p8p5-r296-g2jv).
* This vulnerability was discovered by @EmperialX working with @Shauryae1337 and reported by @EmperialX.
* Needed to read 12 chars instead of stopping at 11 and therefore inserting a NUL.
* Closes#2534.
* Also enable detection of bootriscv64.efi and bootloongarch64.efi bootloaders from FAT images.
* Move the cpu.c/cpu.h in more logical places and remove these sources files.
* Add detection for LoongArch64 EFI bootloaders.
* Pass the detected CPU arch when invoking Fido.
* Also fix some Bled Coverity warnings.
* Based on the latest Bled, which adds ztsd compression support.
* Note that initial extraction of the 512 bytes MBR is very slow, because is seems
clear that ZSTD was never designed for fast init or processing small elements of
data, but instead for post init large volume streaming.
* Also note that this code adds 400 KB to the Rufus executable *AFTER UPX COMPRESSION*!
Hopefully, the BusyBox folks can come up with a better and smaller way to add zstd
support, because it's clear that the method used by the current BusyBox proposal,
which is to leave as much of the original code untouched, isn't for the best...
* Closes#2590.
* Closes#2620.
* Closes#2621.
* Per https://github.com/actions/runner-images/issues/10981 and plenty of other similar
reports, GitHub Actions can no longer compile ARM32 binaries by default using the
latest Visual Studio toolchain, due to Microsoft current Windows SDK having dropped
the ARM32 toolchain (per https://github.com/zufuliu/notepad4/issues/839).
* Well, I have better things to do then try to maintain platforms in the process of
being deprecated, so I'll let the people who care about Rufus on ARM32 propose a
non-intrusive workaround that can work with current GitHub Actions.
* Similar to what we already do with IgnoreUSB##, except this time, users
can add REG_SZ keys IgnoreDisk01 to IgnoreDisk08, with a string like
"{F333EC2E-25C9-488D-A7FC-9147C2367623}" to ignore a GPT disk with this
specific GUID.
* This may be useful for people who mount fixed virtual drives, or people
who have enabled Hot Swap on their SATA storage, and who want to make sure
they won't be able to inadvertently select that disk in Rufus.
* Also set rufus-next to 4.7.
Pete Batard