* 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.
* 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.
* 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.
* 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 #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.
* We are seeing reports of access violation exceptions being generated
when looking for processes, with the App Store version.
* Since this is not critical code, add an SEH handler to ignore those.
* MSG_900+ will be used for Windows Store translation, so add them
and makes sure these get filtered out from embedded.loc.
* Also make sure we don't get a "Translated by:" in the English version
when compiled with VS2022.
* Also add Store screenshots and update listing.csv so that we can
autogenerate and upload a complete translation update to the store.
* Even if this makes the resulting executable slightly larger, this should help
with troubleshooting, especially for the Windows Store releases.
* Also drop the "since 2019" from the Downloads badge, since once you reach 100M
the start date for the counter becomes a bit meaningless...
* Newer Intel and AMD CPUs have SSE extensions for SHA-1 and SHA-256 acceleration.
* Add new cpu.c/cpu.h sources to detect the extensions, and use them in checksum.c
if available.
* Acceleration code is taken from https://github.com/noloader/SHA-Intrinsics.
* 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).
* Some "unofficial" Windows ISOs use a custom boot.wim that only includes the Setup
image at index 1, rather than at index 2, after the PE image, for official ISOs.
* Also refactor to add a long needed vhd.h header.
* Also fix a MinGW warning.
* 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).
* WinTrust.lib is responsible for the MSASN1.dll sideloading issue described in #1877,
so, since we only use it for WinVerifyTrustEx(), hook into that function manually.
* Closes#1877 for the MinGW side.
* Note that we will probably try to use the method suggested by @assarbad and documented at
https://stackoverflow.com/questions/1851267/mingw-gcc-delay-loaded-dll-equivalent/70416894#70416894
to try to put an end to the problem of DLL side loading.
* ef2ff7179d was supposed to apply delay loading to our DLLs, for all MSVC builds,
thereby preventing sideloading attacks, but the patch actually only set the DelayLoadDLLs
property for Debug builds and not Release builds, with the result that side loading could
still be triggered for the Release executables, as demonstrated in #1877.
* This patch therefore properly sets the DelayLoadDLLs for all builds, which should take care
of the side loading vulnerability at least for MSVC executables.
* A subsequent patch will still be needed for MinGW, since there is no equivalent to DelayLoadDLLs.
* This addresses part of #1877.
* Hypothetically if the user's current directory contains a malicious DLL that DLL
could be loaded instead of the one in System32.
* Whereas the previous patch should have taken care of the one DLL referenced by
Rufus that may be vulnerable to this attack (version.dll), we nonetheless add
delay loading for all the libraries we reference as a precautionary measure.
* One can confirm that this works by using dumpbin.exe /IMPORTS to make sure
a specific DLL is delay loaded. Then putting a breakpoint in the delay load
hook should also confirm that the hook is used.
* Closes#1838
* This is part of #1838, where we need to sort the version.dll sideloading problem for MinGW.
* A subsequent patch will be applied to MSVC, to more generally delay the loading of DLLs.
* Also fix a typo with an assert expression.
* Use sources/compatresources.dll, when available, to try to detect the Windows ISO version and build.
* Also report what facility we use for formatting.
Yes!!! We are finally *much* faster than 7-zip for SHA-256, even though
we are also computing MD5 and SHA-1 in parallel. Here are some averaged
comparative results, against the 5.71 GB Win10_20H2_EnglishInternational_x64.iso
(SHA-256 = 08535b6dd0a4311f562e301c3c344b4aefd2e69a82168426b9971d6f8cab35e1):
* Windows' PowerShell Get-FileHash: 48s
* 7-zip's SHA-256 : 31s
* Rufus (64-bit release version) : 23s
