* Obviously, this does not use the same Authenticode credentials we use for actual releases
(which we wouldn't be able to export anyway, as it resides on a hardware token), but it
should help officialize our GitHub builds, as well as remove an extra prompt.
* Also move the revoked UEFI bootloader check before the DD vs ISO check, so that people
choosing DD mode still get alerted about the revoked bootloaders.
* Also don't refresh the device list after saving to image, and fix a Coverity warning.
* Requires the download of oscdimg.exe, courtesy of Microsoft's symbol servers.
* UDF only, since this is mostly intended for Windows and even with Joliet, Microsoft's
implementation of ISO-9660 is crippled (fails to use multi-extent for >4GB files, which
results in BROKEN ISO images) and too limited.
* Note that this is different from our other save to ISO feature (Alt-O), that dumped
the first optical media found on the system to an ISO.
* Also fix a Coverity warning as well as a possible crash in PopulateWindowsVersion()
when opening an invalid image (such as the ISO-9660 ones created by oscdimg).
* Per MS documentation, _mktime64() *ALTERS* the time being passed to first add/substract
the timezone offset before converting to an epoch.
* This resulted in our evaluated epoch from the DBX GitHub commit being a few hours more
recent than the epoch we store for our embedded files (which is UTC) for timezones that
are behind of UTC, since their epoch have an offset added to convert localtime to UTC.
* Fix this by using _mkgmtime64() that does not suffer an unwanted time manipulation.
* For safety, also use -u for epoch format conversion in our script just in case.
* Closes#2762.
* Also comment the "unsupported check; not verifying file integrity" warning for XZ
decompression, improve XZ ARM64 support and add an exception for some Samsung UFDs.
* The "Quick Format" and "Create extended label" checkbox could be enabled when no device
is detected by checking the "List USB Hard Drives". Fix that.
* Also fix/silence some Coverity warnings (div by zero, overflow, unreachable code, uninit'd mem).
* Also ad @ozone10 to the credits for the Dark Mode UI.
* Also fix erroneous use of EndDialog() instead of DestroyWindow() in rufus.c,
which resulted in WM_DESTROY/WM_NCDESTROY messages not being generated.
* Closes#2713.
* Closes#2510.
* Closes#1453.
* 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.
