* 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).
* Commit 9dc045a701 introduced a regression on account that we didn't set the
file pointer to 0 before clearing the disk.
* This leads to the MBR not being properly cleared, with the result that Windows may in turn
produce errors when trying to repartition the disk.
* Fix this by making sure we do invoke SetFilePointerEx() before calling WriteFileWithRetry().
* Also set rufus-next to 3.17
* Also fix a MinGW warning
* Remove BypassRAMCheck from Extended Windows 11 installation since the minimum
RAM requirements for Windows 11 are 4 GB and not 8 GB as pointed out in #1791.
* Display Windows edition code when we can't resolve it.
* VS2019 wants us to have PackageOptionalProjectsInIdeBuilds enabled? So be it.
* If 'Extended Windows 11 Installation' mode is selected, the system registry hive of
'sources\boot.wim' is patched to add the Setup\LabConfig registry keys that bypass
the TPM 2.0/Secure Boot/8GB+ RAM Windows 11 system requirements.
* Use sources/compatresources.dll, when available, to try to detect the Windows ISO version and build.
* Also report what facility we use for formatting.
* Since version 8.2, and rhinstaller/anaconda@a766101954,
Red Hat derivatives have changed their CD-ROM detection policy which leads to
the installation source not being found when writing the media in ISO mode.
* Replace 'inst.stage2' by 'inst.repo' in the kernel options.
* Closes#1777 (See also rhinstaller/anaconda#rhinstaller/anaconda#3529).
* Note that this reverts part of 9c8fa40995.
* Windows 11 appears to be a lot more proactive in locking system partitions (ESPs, MSRs)
than previous versions of Windows were, resulting in format or access errors.
* Try to work around these by disabling exclusive drive locking as needed.
* Also use build number to detect Windows Server 2019 and Windows 11
since Microsoft are COMPLETE ASSES about their version reporting.
* Also fix a compilation warning.
* In replace_in_token_data() when looking for lines starting with a specific
token but finding lines containing a larger version of the token (e.g. looking
for 'linux' but finding 'linux16') we would forget to output the non matching
line as we rejected it.
* This produced issues such as the one described at:
https://ubuntuforums.org/showthread.php?t=2465291&page=10&p=14052629#post14052629
* Fix this by ensuring that we always output the lines that we reject.
* write_sector() should really only be used when writing single sectors as it
is way to slow for anything else => Switch to using WriteFileWithRetry().
* Also revert an unwarranted change from f0047986e7.
* ...that didn't get the memo about using UPPERCASE 11-chars max ISO labels.
* There's a reason why Arch labels its ISOs 'ARCH_YYYYMM', people!
* Anyway, EndeavourOS should now work in ISO mode when booted from UEFI.
* In their great wisdom, the openSUSE maintainers added a 'set linux=linux'
line to their grub.cfg, which means that their kernel option token is no
longer 'linux' but '$linux'... and we have to add a workaround for that.
* If users set the persistent size to max, we may run into a situation
where projected size (which is always a rough estimation) is too low.
* When persistence is in use, we increase the projected size by 10%, to
ensure that the above scenario cannot happen.
* Also work around potential issues with Windows APIs when the application
is launched from the root of a drive.
* While this is intended to solve the issue of saving GRUB/Syslinux files for the
App Store version, we apply this change globally, as it allows the user to move
the Rufus executable around while preserving access to existing downloads.
* Closes#1744
* This basically means that the script is validate *TWICE*, using two
completely independent signatures, before it is allowed to run, which
should add another mitigation layer against TOCTOU (which we already
friggin' mitigated against anyway) and other potential vectors of
attack.
* Also remove -DisableFirstRunCustomize option and the associated cookie
prompt monitoring, which the latest version of Fido no longer requires.
* Also update WDK version for signtool and flesh out PKI error messages.
* Trying to mount accessible partitions after writing an image may lead to the
creation of the infamous 'System Volume Information' folder on ESPs, which in
turn leads to checksum errors for Ubuntu's boot/grub/efi.img (that maps to the
Ubuntu ESP). So comment out that code.
* Also fix a missing CRLFs in the log after displaying write progress.
* Anaconda broke ISO compatibility, most likely with the following commit:
84529204fe
* However, Ret Hat, and its followers, have drunk the "DD only" kool aid, and
appear to be blissfully unaware of the very real drawbacks that enforcing a
"DD only" mode for ISOHybrid can actually place on distro users.
* Rather than spend another wasted effort trying get people, who appear to be
impervious to even remotely consider the idea that DD imaging can have flaws,
to look into the possibility that Red Hat might indeed have introduced a
regression, and given the downright hostility I have been subjected to from
trying to state this *very verifiable* fact, we'll just force DD mode for the
affected Red Hat and derivatives, whilst trusting that users will be smart
enough to compare their more limited installation experience against the ones
from other distros (such as Arch, Debian or Ubuntu, which, unlike Red Hat and
co., appear to fully understand that the whole ISOHybrid vs DD mode situation
is not all black and white), and see for themselves which distros do actually
place *their* interests first, rather than just the interests of the distro
maintainers...
* GRUB 2.0 maintainer think they're doing a fine job, even when there are
CRITICAL SECURITY FIXES that should warrant an immediate out of bound
release, and instead consider that waiting MONTHS or YEARS to release
anything is not a big deal at all.
* Ergo, distros, such as Ubuntu, start to pick whatever security patches
they see fit, since they can simply not RELY on the upstream project to
produce security releases in a timely manner. One such patch is:
https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00012.html
* But since there is no new GRUB release per se, they still call their GRUB
version, onto which they applied patches that have come into existence
more than 2 years after the actual 2.04 release, "GRUB 2.04".
* Obviously, since GRUB 2.04 + literally hundreds of cherry picked patches
does deviate a lot from the last release, THINGS BREAK IN SPECTACULAR
FASHION, such as the recently released Ubuntu 21.04 failing to boot with
the error: grub_register_command_lockdown not found.
* Oh, and of course, regardless of all the above, if you ask anyone, they'll
tell you that there's nothing fundamentally wrong with the GRUB release
process (even if they should long have released 2.05, 2.05-1 and 2.05-2,
were their maintainer ready to acknowledge that delaying releases DOES
CREATES MAJOR ISSUES DOWSTREAM, as many people REPEATEDLY pointed to them
on the GRUB mailing list) or with the Ubuntu GRUB versioning process (that
really shouldn't be calling their version of GRUB "grub-2.04" but instead
something like "grub-2.04_ubuntu"). Oh no siree! Instead, the problem must
all be with Rufus and its maintainer, who should either spend their lives
pre-emptively figuring which breaking patch every other distro applied out
there, or limit media creation to DD mode, like any "sensible" person
would do, since DD mode is the ultimate panacea (Narrator: "It wasn't").
* So, once again, a massive thanks to all the people who have been involved
in the current GRUB 2.0 shit show, whose DIRECT result is to make end
users' lives miserable, while GRUB maintainers are hell bent on continuing
to pretend that everything's just peachy and are busy patting themselves
on the back on account that "Fedora recently dropped more than 100 of the
custom patches they had to apply to their GRUB fork" (sic). Nothing to see
here, it's just GRUB maintainer's Jedi business as usual. Besides, who the
hell cares about Windows users trying to transition to Linux in a friendly
manner anyway. I mean, as long as something doesn't affect existing Linux
users, it isn't a REAL problem, right?...
* Combined with the increase in buffer size from previous commits, this
should help us get close to a device's maximum write speed.
* Also add async write support to winio.h
* Also increase the buffer size for bad blocks check operations
* This is in preparation for async reads
* Also move open/close image operations to WriteDrive()
* Also increase DD buffer size to 32 MB to improve performance
* 2e1833e91e introduced issues with VDS since, despite what
Microsoft's documentation says, balancing CoInitialize with CoUninitialize
leads to VDS not properly relinquishing disk access.
* Of course, since Grub4DOS's grldr.mbr hasn't changed from previous releases
there's not much to update there, but then again, people like version bumps.
* InternetGetConnectedState() is next to useless and doesn't provide
coherent outcome on the ARM64 platform I'm testing with. This results
in Rufus declaring that Internet is unavailable on platforms that do
have actual Internet connectivity.
* Swicth to using INetworkListManager::GetConnectivity(), which actually
reports a dependable result.
* Closes#1691
* Also remove the mutex for uprintf(), which may produce thread lockout
and remove an unwanted double GetSignatureName() call on startup.
* Looks like executables installed from the Windows Store launch with a "/InvokerPRAID"
added parameter, which of course BREAKS apps that have a defined set of parameters
and don't except that Microsoft would gingerly add random unwanted stuff there...
* The provision of this extra parameter also appears to be tied to using one of:
- <TargetDeviceFamily Name="Windows.Universal" ...>
- <uap:SplashScreen ...>
- <Application EntryPoint="$targetentrypoint$" ...>
in the appxmanifest.
* This resulted in our argument processing loop to cause early exit on account that an
unexpected option was provided.
* Fix this by adding an explicit check for /InvokerPRAID and not exiting on unhandled
params and removing or altering the 3 appxmanifest options listed above.
* Also set an explicit Windows.FullTrustApplication and remove splash screen.
* Also update _pre-commit.sh to update appstore build number automatically.
* Also remove splash screen images, add store listing CSV and toggle App builds to manual.
* Closes#1690
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
* Due to the partition gymnastic that is required by the hack that is ISOHybrid,
some ISOHybrid images that are written in DD mode, such as Ubuntu 20.10, may
result in Windows somehow "losing" the target disk from some of its listings.
* This "removal" can be seen for instance if you have diskpart already open and
issue 'list disk' after Rufus 3.13 completed its image writing.
* In the worst case scenario, Windows may flat out refuse to access the disk at
the sector level be it in diskpart or disk manager, which forces ones to clear
the partition tables on Linux or some other OS to be able to "recover" the disk.
* This appears to be mostly due to Windows VDS cache (which Microsoft assures
should be able to do a proper job of refreshing itself on its own, in the same
stride as they also feel the need to introduce IVdsService::Refresh whose sole
purpose appears to work around a limitation that Microsoft knows exists) not
being in sync with the actual disk layout.
* So we now add calls to VDS layout refresh where needed, to work around the issue.
* Also fix an ext2fs Coverity warning.
* For blank disks, GetVdsDiskInterface() may return success with a NULL pAdvancedDisk.
* Also silence the annoying "Failed to read label" error on ERROR_UNRECOGNIZED_VOLUME.
* When writing images such as tails, that contain a large ESP, Windows forcibly
removes the media while we are writing it, unless we lock the logical drive.
* Also fix a Bled Coverity warning.
* Remove early locking of logical volume (no longer necessary due to previous commits).
* Relax exclusive locking of physical drive when an ESP is created.
* This should help with #1637 and #1640
* Also add an extra check for sector size in WriteDrive()
* Factorize drive letter removal into a RemoveDriveLetters() call.
* Improve MountVolume() and RemountVolume() calls.
* Also bump Rufus version to 3.13
* Make sure that instantiated objects are released.
* Factorize the instantiating of disk interfaces.
* Allow the provision of an offset to delete a single partition.
* Add a ListVdsVolumes() call (which is pointless since Microsoft *CRIPPLED* its VDS implementation).
* SetAutoMount()/GetAutoMount() should check for INVALID_HANDLE_VALUE and not NULL.
Also we don't actually need to open MOUNTMGR_DOS_DEVICE_NAME rw to issue an IOCTL.
* ToggleEsp() failed to exit properly when an ESP offset was specified.
* Introduce PI_MAX to explicitly set the size of the partition_information table.
* write_sectors() has write retry, so there's no need to perform one on top of it.
* When we exit FormatThread(), GetLogicalName() should attempt to look for the the
main partition and be silent.
* Make sure that if we skip a deep directory during scan, we count at
least one block of data.
* Also produce a note about deep directory long scan times and improve
the formatting of some messages.
* Ubuntu switched to using GRUB for BIOS, so our update_md5sum() code was not being called.
* Move update_md5sum() to being called unconditionally to fix this.
* Closes#1616 (again...)
* GRUB have cherry-picked patches from the "BootHole" vulnerability fix at
https://lists.gnu.org/archive/html/grub-devel/2020-07/msg00034.html and
have applied them to their 2.04 GRUB loader.
* This results in breakage with "error: symbol 'grub_calloc' not found" when
using the release GRUB 2.04 version of core.img.
* Therefore, we too cherry-picked some patches to apply on top of GRUB 2.04
release to make our core.img compatible with Ubuntu 20.10.
* Closes#1616
* Also increase the maximum write stride for ms-sys to 64 KB (required to
write the GRUB 2.05 bootloader which is larger than 32 KB) and update hash DB.
* The presence of a > 4 GB file forces the use of NTFS which is incompatible with
SysLinux 4.x or earlier. As such, if an image uses SysLinux only, there's no
point in enabling MBR as SysLinux won't boot.
* Required for ISOs such as securityonion-2.0.1-rc1.iso.
* Commit 77d319267f broke lookup of ISO filenames since iso9660_open()
enabled the Rock Ridge extensions by default, despite using ISO_EXTENSION_NONE
for the internal call, and we addressed a FIXME related to this.
* This resulted in Rufus not being able to lookup 'boot/grub/i386-pc/normal.mod' to parse GRUB's
version, since without Rock Ridge, 'i386-pc/' is unable to match the ISO-9660 'I386_PC/' dir.
* Closes#1573 and addresses part of #1616.
* Also fix a MinGW compilation warning.
* These bootloaders will require LFN support. Since we don't expect that
many people to create bootable media for RISC-V derived from bootloaders
contained in a 'efi.img`, we simply ignore these for now.
* Don't use hDrive handle for longer than necessary
* Move all the popcount() function calls into missing.h
* Ensure that the thread_affinity[] array is properly sized
* Improve timeouts for conflicting process search
* A user is reporting that, on one of their platforms, Rufus is writing to the wrong target during the file-copy
phase and using their existing Y: local drive instead of the drive associated to the USB, despite the fact
that Rufus is passing the right volume name to GetVolumePathNamesForVolumeName().
* Here's the PowerShell wmic output, confirming that the volume GUID obtained by Rufus is the right one:
DriveLetter : Y:
DeviceId : \\?\Volume{000349b1-17d0-69f6-c13f-f31162930600}\
Capacity : 118540464128
FileSystem : NTFS
Label : Y-DISK
DriveLetter : H:
DeviceId : \\?\Volume{b150ff4a-d62b-11ea-86e3-f49634660e54}\
Capacity : 15791824896
FileSystem : FAT32
Label : ADATA16GB
* And here's the Rufus log demonstrating that GetVolumePathNamesForVolumeName() is returning the *WRONG* letter:
Found volume \\?\Volume{b150ff4a-d62b-11ea-86e3-f49634660e54}\
\\?\Volume{b150ff4a-d62b-11ea-86e3-f49634660e54}\ is already mounted as Y: instead of H: - Will now use this target instead...
* The last line shows, without the shadow of a doubt, that we did feed "\\?\Volume{b150ff4a-d62b-11ea-86e3-f49634660e54}\" to
GetVolumePathNamesForVolumeName() and that this API call was successful (returned a non zero size) but ultimately returned
the wrong letter (Y: instead of H:)...
* Therefore, Windows is BUGGY and the use of GetVolumePathNamesForVolumeName() must be avoided.
Maison
Marcos Mello
Pete Batard
Vlad
Dinis Medeiros
Matthias Kruk
Tatsuhito KATO
Csizmadia Gábor
SiderealArt
Jeon Hyun-seok
marcellogianola
Austin Wise
Dimitri Papadopoulos
marcellogianola
Mihai-Octavian STRĂUȚ
longpanda
Oree111
Sasa Vujanic
Gintaras Venslovas
anni deer
Matej Horvat
Tiryoh
Костянтин Сергійович
Suttirak Mattayawerakiat
Jakub Zieciak
MaKK
Martin Kubánik
Riku Brander
Dinis Medeiros
Chocobo1
Jiawei Wang
Thilo Langbein
Miloš
Itiel
Aldis Tutins
Roberto Boriotti
Thomas De Rocker
Uk-Jin Jang
Arif Budiman
Sopor
Mehmetali Kuran
Tiago Filipe Silva
Fardin