* 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.
* Commit f453dc272b improved on error message reporting, but went a bit
too far in trying to let Windows facilities sort their messages out.
* Add a retry that clears the facility, so that, for one thing, we get wininet
messages properly processed, regardless of the official facility assigned.
* Also fix SBAT not being properly parsed for PE32 executables.
* Also fix signature truncation in GetIssuerCertificateInfo() and fall back to
returning signer data if issuer is not available (which is typically the case
for GRUB signed bootloaders).
* Also fix status messages on user cancellation/proceeding.
* This is currently only used to detect the use of 'Microsoft Windows Production PCA 2011'
signed bootloaders.
* Because the cert is still in the process of being revoked, and Windows 11 24H2 still uses
'Microsoft Windows Production PCA 2011' signed bootloaders by default, only report this if
running in expert mode.
* Also fix non-reachable code in wue.c.
* This aims at creating installation media that is compatible with systems where
'Microsoft Windows Production PCA 2011' has been revoked.
* Doesn't work, since the bootloaders being applied by the first stage installer come
from \sources\install.wim[#]\windows\system32\Recovery\Winre.wim[#]\Windows\Boot\
(instead of \sources\boot.wim[#]\Windows\Boot\ as one would naturally expect) and
Microsoft botched the ones they included there by using completely vulnerable (and
therefore revoked) ones.
See https://github.com/pbatard/rufus/issues/2244#issuecomment-2400380839.
* Still, I sure haven't gone through this excruciating ACL bullshit for nothing, so
you get an experimental option, behind the expert mode curtain.
* Per https://forums.mydigitallife.net/threads/win-11-boot-and-upgrade-fix-kit-v5-0-released.83724/
Windows 11 24H2 requires new registry bypasses to be applied to perform in-place upgrade on
non officially supported platforms, and those need to be enacted before running setup.exe.
* In order to streamline this, and because those registry bypasses require elevation, we rename
setup.exe to setup.dll and add our own setup.exe wrapper to set the registry and then call the
original setup.exe (through setup.dll).
* See https://github.com/pbatard/rufus/issues/2568
* Also fix some MinGW build warnings.
* Also fix the annoyance of TortoiseGit/Notepad++ altering the copyright symbol of rufus.rc.
* Looks like using the 'net user USERNAME /logonpasswordchg:yes" might have the side effect
of setting the main user account to expire after a few months. So to alleviate that, we'll
just set the system policy to use passwords that never expire.
* Also clean up the PE parsing code and fix 2 Coverity warnings.
* Also fix typos, misprints and ditch the UNRELIABLE timestamp.acs.microsoft.com server.
* See https://github.com/pbatard/rufus/issues/2244#issuecomment-2243661539
* Note that we don't use the GUID but the resource name for bootmgr.efi, as trying to figure
out where the heck the relevant GUID is located in the PE code is not worth the effort.
* Also add internal fallback for sbat_level.txt if the user can't access our remote version.
* Also improve PE section lookup.
* buf could be freed twice in iso.c.
* Using HRESULT_CODE(error_code) in WindowsErrorString() could lead to "Error: SUCCESS" messages.
* Closes#2524.
* Also try to address potential issues that appear to have been seen in the wild.
* Per #2272 and #1877, MinGW has issues when delay loading libraries, but
it is possible to apply a workaround to alleviate them, by redefining
DECLSPEC_IMPORT before including the corresponding headers.
* This is a bit more tricky to accomplish for virtdisk, as MinGW's windows.h
header does include virtdisk.h on its own (rather than expect a formal
include as MSVC does), so we have to prevent the virtdisk.h inclusion
first, by defining a macro, and then apply our workaround.
* Per ea87573f-65ea-44a2-b4bb-ca96c0a136ab%40akeo.ie/#msg58793876
we are hoping that this should be a temporary workaround and that the root
cause of the issue will be fixed in binutils.
* Closes#2513.
* If you attempt to read past the end of a mounted VHD, not only will Windows happily
return data that doesn't exist (instead of returning End of Disk), but it will also
corrupt the existing data!
* So, to appease the capricious Windows gods, we now make sure that we never attempt
to read (or write) past the boundaries of the source or target when writing images.
* This should address the last issue from #2468.
* Also set version to rufus-next and make some small improvement in winio.h.
* As usual, Microsoft products are so poorly designed that they can't deal with
multiple instances of one thing. In this case, if the Windows installer sees
two ESPs after you select the drive where you want to install Windows and it
creates its own ESP there, it will fail during the "CopyinG Windows Files"
step.
* So make sure that the UEFI:NTFS partition is *not* set to ESP type, even
though it is really an ESP, which is something that we used to do, but that
got reverted in 0f23c47184.
* I don't think we want to make this setting permanent for the time being as
this may result in drawbacks like people using the UEFI Shell going through
an unwanted MD5Sum check because they forgot to turn it off.
