* The static_/safe_ string macros were not properly designed to handle the case where
an expression such as strlen() rather than a static value was passed for the count,
leading to unexpected results, such as excessive truncation of strings. Fix that.
* Also fix a buffer overflow in GetDevices() due to using a wrong string length.
* _snprintf() is not always guaranteed to NUL terminate a string which could
lead to buffer overflows in iso_extract_files() and iso_extract_files().
* Fix this by switching to using the more secure _snprintf_s().
* Vulnerability discovered and reported by Mansour Gashasbi (@gashasbi).
* For good measure, we also switch to the strncat_s() where possible and also
use memmove() instead of memcpy()/strcpy() as the behaviour of the latter on
overlapping memory regions is undefined.
* Also fix some additional MinGW warnings regarding casts and nb_blocks.
* Also add Ctrl-A as a new cheat-mode to toggle the use of Rufus MBR (which is enabled by default)
which replaces the previous UI checkbox. The Disk ID field is now completely removed as we now
use the default values for XP and non XP installs, and will expect people with multiple disks to
disconnect all except the one where they plan to install Windows.
* This allows *runtime* validation of UEFI bootable media, such as Windows
or Linux installers, which, considering the unreliability of USB flash
drives, we assert is a a much better proposal than write-time validation
that utilities like balenaEcther (and to a lesser extent MCT) provide.
* Based on uefi-md5sum (https://github.com/pbatard/uefi-md5sum).
* Unconditionally activated on ISO extraction for GPT targets for now.
This will be changed to a user selectable option later.
* This enables the use of Ctrl-SELECT to also extract files from a .zip
when using non-bootable, DOS, UEFI-NTFS, etc.
* Also clean up some uprintf line terminations and some additional code.
* Also fix some Coverity and MinGW warnings.
* The AMI UEFI NTFS driver (version 0x10000), which is used in many modern systems from
ASUS, Gigabyte, intel and so on, has a major bug whereas depending on the size of the
buffers that are used to write the data onto the NTFS volume from Windows, as well as
read the data from the NTFS volume from UEFI, the data being read may be incorrect
(for details on this, see https://github.com/pbatard/AmiNtfsBug).
* Especially, it appears that if the size of the buffer used to write data on Windows is
smaller than the NTFS cluster size, the bug may be triggered.
* Because of this, we increase the size of ISO write buffer to 64 KB since, per
https://support.microsoft.com/en-gb/topic/default-cluster-size-for-ntfs-fat-and-exfat-9772e6f1-e31a-00d7-e18f-73169155af95
this is the maximum cluster size that can be used for NTFS volumes.
* This increase in size should also help with performance somewhat.
* Also add support for C11's _Static_assert() which may come handy.
* Per linuxmint/linuxmint#622 some ISOs may have a /EFI/boot/bootx64.efi that
is a symbolic to a nonexisting file.
* This is originally due to a Debian bug that was fixed in:
5bff71fea2
* Work around this by trying to extract a working bootx64.efi from the El-Torito image.
* Also improve DumpFatDir() to not replace already existing files.
* Mint have decided to make their installation rely on a working /live/ ➔ /casper/ symlink for LMDE
thereby breaking the promise of File System Transposition that all Debian derivatives should have.
* Because of this, trying to use FAT32 with LMDE will fail, as reported in linuxmint/live-installer#152.
* Therefore, now that we can replicate symlinks on NTFS, we add an exception to always enforce the use
of NTFS for LMDE.
* Removes the annoyance of having to wait for the process search to complete before media creation can start.
* Also update the "Process Hacker" references to its new "System Informer" name.
* This is placed behind an expert wall (Ctrl-Alt-E) on account that:
- If you happen to boot a Windows To Go drive in S Mode on a computer, it may set any
existing Windows installation there to S Mode as well, *even if their disk is offline!*
- It can be *exceedingly* tricky to get out of S Mode, as the SkuPolicyRequired registry
trick alone may not be enough (i.e. You can have very much a Windows install in S Mode
*without* SkuPolicyRequired being set anywhere).
* Also set version to rufus-next and fix a ChangeLog typo.
* 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.
* With ISO-9660 being case sensitive, we could end up in situations where trying to extract
'/efi/boot/bootx64.efi' for revocation validation would fail if the file on the image was
stored as '/EFI/boot/bootx64.efi' (e.g. Debian 12).
* Fox this by storing the exact UEFI bootloader path we detected during ISO scan, and using
this path for file extraction.
* Also add a Cancel choice to the revocation dialog and harmonize whitespaces.
* Full Flash Update (FFU) image support was added to dism with Windows 10 1709
and is an alternate way to save a virtual hard disk for restoration.
* While more modern than VHD/VHDX, FFU creation only works for drives with file
systems that Windows natively recognizes (FAT, NTFS) and that look like Windows
installation media, so you can forget about FFU'ing a Linux disk.
* The other *intentional* drawback that Microsoft added is that they don't want
anybody but themselves being able to create and restore FFU images, so, even
as they have nice FfuApplyImage()/FfuCaptureImage() calls in FfuProvider.dll
they have decided not to make these public.
* This means that, since we don't have time to spend on figuring and direct
hooking internal DLL calls for x86_32, x86_64, ARM and ARM64 (and worrying
that Microsoft may ever so slightly change their DLL between revs to break
our hooks), we just call on dism.exe behind the scenes to create the FFU.
* Now that we don't have to deal with Windows 7, we can use CreateVirtualDisk() to
automatically dump a physical disk to VHD/VHDX, so do just that
* Also move the relevant VHD/ISO imaging call to the appropriate source.
* Remove duplicates from Microsoft's SKUSiPolicy.p7b
* Also display the number of revoked from embedded
* Also use Microsoft's official capitalization for SKUSiPolicy.p7b's target path
* Instead of embedding the content of the most recent revoked bootloader hashes in db.h
we now parse the system's SkuSiPolicy.p7b to do so. This has the drawback of not alerting
users running Rufus on systems where SkuSiPolicy.p7b is not up to date, but I believe the
trade-off is worth it.
* We now also copy the system's SkuSiPolicy.p7b to the created media when possible (for
Windows 10 or later), so that Microsoft's WDAC UEFI revocations can apply during boot.
* Considering that alerting users to potential security breaches that may be
exploited by boot media should also be performed by application that create
them, we add detection for all the currently known revoked UEFI bootloaders,
be it the ones from the official UEFI DBX as well as the ones from Windows'
SkuSiPolicy.p7b, and warn the user when one such bootloader is detected on
their source media.
* Note that, to actually be revoked, the bootloaders flagged through SkuSiPolicy
require the copying of the .p7b to the boot media, which we are currently
not enacting but will perform in a subsequent commit.
* Also fix a Coverity warning in hash.c.
* Debian 12 ARM64 netinst ISOs have doubled in size to be larger than 512 MB,
so we need to increase MAX_ISO_TO_ESP_SIZE as a result.
* Also add extra NULL checks in process.c as some people seem to run into
NULL deref issues.
* Also set version to rufus-next and update some URLs/text files.
* The BlackLotus malware shows that it is possible to download individual
executables and DLLs straight from Microsoft's symbol servers, so we use
that capability to download the missing Windows 8.1 'diskcopy.dll', that
contains the flat floppy disk image with MS-DOS files we need. See:
https://randomascii.wordpress.com/2013/03/09/symbols-the-microsoft-way/
* Also reorder entries in the "Boot selection" dropdown.
* Also use CreateFileWithTimeout() in GetLogicalName().
* As was *ENTIRELY PREDICTIBLE*, the lack of timely releases from the GRUB
project has resulted in distro maintainers (Ubuntu, Fedora, etc.) taking
matters in their own hand and applying patches on top of their 2.06 version.
However, these patches result in 2.06 bootloaders that are incompatible
with 2.06 modules that don't have the same patches applied. Especially this
now results in the infamous "452: out of range pointer" error message when
using patched modules with unpatched bootloader or unpatched modules with
patched bootloaders.
* Making this issue worse, we also have distro maintainers who won't add a
suffix to their GRUB version, AS ONE SHOULD DO WHEN ONE APPLIES TONS OF
PATCHES ON TOP OF A PROJECT'S SOURCE, and MISreport their non 2.06 GRUB as
"2.06", and, because we can't detect what patches are needed from modules
themselves (unlike what is the case for grub_debug_is_enabled), we have no
way of telling incompatible GRUB 2.06 binaries from one another.
* As a result, we have no choice but to append a sanitized version of the ISO
label to the GRUB version, as a means to differentiate between incompatible
versions, and tweak our existing bootloader download mechanism to *ATTEMPT*
to download a compatible 'core.img' from our server... where we will have
to waste a lot of time adding new binaries and symlinks to try to make all
these GRUB "2.06" based images work, and will probably miss quite few with
the end results that users who are just trying to install Linux will be left
stranded.
* Again, I have to point out how the end result of regular users wanting to
try Linux and being unable to do so is the *DIRECT* result of the GRUB project
maintainers having sat on a 2-year influx of CONTINUOUS patches, and thinking
that "Release Early, Release Often" is only a gimmick, and not something that
should apply to their project, even as they have been warned before, by yours
truly, that *NOT* releasing on a timely basis is causing actual grievances...
That's because, had the GRUB maintainers released on a timely basis (at least
once a year) Fedora and Ubuntu would be using vanilla GRUB 2.07 with the memory
patches, and we wouldn't be trying to mix that with old GRUB 2.06 binaries.
* For more on this, see #2233, noting that we will need to apply a compatibility
breaking change during the 4.1 release, to revert the patches we applied to
the default 2.06 'core.img' in pbatard/rufus-web@320b800592.
* Some Windows Store reports suggest that the existing call might freeze
on CreateFile() leading some users to kill the app. So switch to using
a CreateFile() call that times out instead of waiting forever...
* This means that someone running Rufus x64 or ARM64 should be
proposed Rufus ARM64 rather than Rufus x64 as an upgrade.
* Also switch the BETA channel from x86 to x64.
* Also remove the _chdirU(app_dir) when using -i in commandline.
* Passing a non-formatting buffer as first parameter of uprintf() can lead
to an exception if this buffer happens to contain a '%' character, so
usage of uprintf() with string buffers that may contain '%' should be
sanitized.
* Also drop the _uprintf/_uprintfs aliases as they are no longer required.
* 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.
* This is required because, even though it's easy to change a local account name
post install, doing so does not change the directory name in C:\Users\
* This reverts most of 3528ca773d in order to download 'core.img' from our server instead of patching it.
* Also solve the issue of downloading a custom 'core.img' for Fedora 37, that introduced
a new 'grub_debug_is_enabled' symbol without altering their GRUB version string.
* This is accomplished by doing what the distro maintainers should have done on their
own, by appending a custom suffix to the GRUB version string.
* 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.
Pete Batard