* 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).
* This should help with the CoreELEC usage case described in #1842
* Also add MBR handling for ESP ↔ FAT cheat mode (Alt-P)
* Also set rufus-next to 3.19
* 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.
* INetworkListManager appears to depend on specific services to be able to work,
which one can actually disable while still getting full Internet connectivity.
* If that is the case, HRESULT_FROM_WIN32(ERROR_SERVICE_DEPENDENCY_FAIL) will be
returned, therefore we add a fallback to using InternetGetConnectedState(), which
does not have such dependencies (but has other limitations per b2492908be)
when we detect a dependency error.
* Also take this opportunity to switch to using INetworkListManager::get_IsConnectedToInternet().
* Also fix Coverity breakage due to Synopsys having upgraded their toolchain.
* Closes#1801
* MIRACLE LINUX is a Red Hat derivative, so it needs the same special
treatment as Red Hat, CentOS, etc to work around issues in anaconda.
* This commit adds MIRACLE LINUX to the list of Red Hat derivatives.
* Closes#1866
* This fixes the regression introduced in c28f9bc491.
* 'if ((a && !b) || (!a && b))' can not always be simplified as 'if (a != b)' when the types for 'a' and 'b' are not straight booleans.
* Closes#1862
* Also drop the use of '%C' in printf() expression, as it is intended to print wide characters and not turn a char to uppercase.
* In their great "wisdom", Microsoft made it even harder to access ESPs on Windows 11,
meaning that we have to use even more convoluted ways of providing the ISO→ESP feature.
* Closes#1855
* 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.
* Since CentOS Stream does not use the 'CentOS-8.*' labelling scheme.
* This is a follow up to #1777.
* Also fix Windows Kit location for signing scripts.
* I don't have time for this bullshit. Of course the irony is that a Microsoft product (CodeQL)
hosted on a Microsoft platform (GitHub) hasn't been updated to work with the latest Microsoft
compiler (VS2022).
* Also removed the stuff CodeQL complains about and updated README badges.
* Having two separate Visual Studio solution files, while more convenient, was a major
pain in the ass and it also required us to update versioning in the .appxmanifest for
each commit.
* Also, this new AppStore build process enables us to use the GitHub Actions executables
to further foster the complete transparency of our build process.
* This is a follow up to 1c2884ceba where the error code returned by Windows 7 platforms
that don't have KB2533623 is expected to be ERROR_INVALID_PARAMETER rather than ERROR_PROC_NOT_FOUND.
* Also update the Windows 11 'Extended' installation mode translations.
* Per 2a3e82fa96, it looks like some Windows 7 system have trouble with
LoadLibraryEx() if they don't have KB2533623 installed (which fixes a MAJOR Windows
vulnerability. Some people sure want to leave their system open to hackers...).
* Work around this by adding a fallback to LoadLibrary() in GetLibraryHandle()
* Also switch to using GetLibraryHandle() in dos.c and using LoadLibrary() in sections
where we have the full path (since these calls are not vulnerable).
