* 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.
- 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.
* 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.
* 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 https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/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.
* As opposed to what we originally asserted, Microsoft did enact a blanket revocation
in SkuSiPolicy.p7b for all post 1703 up to 2305 Windows UEFI bootloaders.
* As a result, unconditionally copying SkuSiPolicy.p7b will result in media as recent
as Windows 11 22H2 (v1) being flagged as revoked, which we don't want to enforce as
long as Microsoft themselves haven't entered the enforcing phase of their Black
Lotus mitigation (currently planned for early 2024).
* Because of this, while we add some revocation detection for post 1703 bootloaders,
we set it to only go as far as 20H1 for now, which means that all post 20H1 Windows
10 media and all Windows 11 media will not yet be flagged by Rufus as revoked and
will still boot in a Secure Boot environment due to lack of an SkuSiPolicy.p7b.
* Ultimately, per #2244 we may look for a BOOTMGRSECURITYVERSIONNUMBER resource to
blanket revoke all post 1703 - pre 2305 Windows UEFI bootloaders.
* Also remove the now unused comdlg32 library from the linker.
* MinGW32's delay loading functionality is not yet up to par with MSVC's and especially, for
some libraries (wininet, virtdisk) attempting to delay load them simply crashes the runtime.
* This results in the MinGW32 version of the app crashing when selecting a Windows ISO, as we
will then try to mount the ISO using virtdisk to poke the build version. Note that this crash
does not happen with the MinGW64 version or with MSVC.
* Closes#2272.
* Also fix a Coverity warning in SaveImageThread() and improve the VHD saving code.
* Pick the version and build number directly from the install[.wim|.esd] XML index.
This forces us to mount the ISO during scan, but it's the only way to get an accurate Build number...
* Also drop linking to version.dll (along with the whole version.dll delay-loading shenanigans).
* This reverts 3194a4dac4 on account that MinGW's delay loading of
wininet.dll causes the application to prematurely close.
* Yet another episode of the never ending #1877 saga...
* Now that we can delay-load DLLs for both MinGW and MSVC, we can also remove
the direct DLL hook that was added into dwmapi.dll due to side loading and
revert to using a direct API call instead.
* This reverts part of e1d864f755.
* Also attempt to silence that damn Coverity warning.
* Now that we can delay-load DLLs for both MinGW and MSVC, we can remove the
cumbersome direct DLL hooks into wininet.dll (which is vulnerable to side
loading when not delay-loaded) and revert to using direct API calls instead.
* This reverts part of e1d864f755.
* Also attempt to silence a Coverity warning.
* This reverts much of commits f6ac559f4d and 1947266837
so that we call the Windows APIs directly again, while ensuring that, by the time we load the DLLs,
sideloading mitigation has already been applied by the application.
* This is a continuation of #1877, and should help prevent re-introducing side-loading issues when we
link against new libraries, as well as allow us to drop some of the manual DLL hooking we've been
doing to prevent it, to clean up the code.
* Note that this is a bit more complex than what the stackoverflow post suggests, because we need to
create delayloaded libs for both 32-bit and 64-bit, which use a different calling convention and
therefore need to use different .def files. So there's a lot of gymkhana involved, with Makefiles
and whatnot, to get us there.
* Also simplify the use of CM_Get_DevNode_Registry_PropertyA() in dev.c since recent versions of
MinGW now have support for it.
* Also fix 2 small issues in net.c (potential overflow) and format.c (memory leak).
