* Due to a typo in vhd.c where the second safe_stricmp() should be against ".vhd" and not ".vhdx" again.
* Also enable the ignore boot marker bypass for VHD/VHDX/FFU and don't misreport those images as
"compressed disk images".
* Closes#2309.
* 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.
* Per https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#Directory_entry it
is possible to have a FAT directory entry with a 'EFI' volume label alongside with
a 'EFI' subdirectory.
* If that happens, then the current Syslinux libfat_searchdir() code may treat the
'EFI' volume label as an empty subdirectory and say that there are no bootloaders,
even if the 'EFI\Boot\Boot###.efi' binaries really do exist.
* Fix this by filtering out entries with the 'volume label' attribute (0x08).
* For good measure, also filter out entries with the 'device' attribute (0x40), as
it is technically possible to create a 'EFI' device leading to the same issue.
* Closes#2288.
* Closes#2289.
* 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.
* SymLoadModuleEx() on the DLL fails (with ERROR_SUCCESS, sic) on ARM64, so we have to resort
to loading the DLL in memory and look for the "RSDS" section to access the GUID and Age.
* Except that, once you sort that, you end up with SymEnumSymbols() producing two separate
addresses for each symbol, on account that the Windows 11 ARM64 DLLs are actually an
unholy union of X64 and ARM64 *in the same binary*, under an abomination that Microsoft
calls ARM64X (See https://learn.microsoft.com/en-us/windows/arm/arm64x-pe for details).
* And, of course, Microsoft did not provide any means during PDB enumeration to tell which
address is for which arch. Especially, the bloody pSymInfo->TypeIndex, that they could
easily have used for this, is utterly pointless as it remains set to 0...
* This means that, even after all this effort, we're still nowhere close to have a solution
that can make DLL address resolution work on Windows 11 ARM64.
* 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.
* Having NTFS partitions properly aligned to the cluster size can drastically
improve the speed of capturing a disk to an FFU image, as, when the size
is aligned, the FFU capture uses the actual NTFS allocation map to only read
and capture the clusters that are actually in use, whereas, if no aligned,
FFU capture falls back to a sector by sector copy that is both much slower
and also includes unwanted leftover garbage.
* Also only enable FFU when we detect FFUProvider.dll as a system library.
* 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.
* 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.
* 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.
* 32-bit x86 running on 64-bit x86 Windows needs to get SKUSiPolicy.p7b from sysnative.
* Also fix automatic extension switching in file dialog and a small MinGW warning in Bled.
* The ZIP64 extra record may not be the first one, so add processing for all extra zip records.
* Also add extra sanity checks to try to appease Coverity and properly detect short writes.
* This adds ZIP64 support, which is required to extract zip archives that are larger than 4GB.
* Closes#2264
* Also fix a MinGW warning in pki.c and improve the UEFI revocation messages.
* 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.
* Also revert GRUB 2 core.img to vanilla 2.06, with the hope that GRUB will
*ACTUALLY* bother to release in 2023 and we will be able to update to
GRUB 2.12 (or whatever non-sequential version they decide to go with) to
say a most welcome goodbye to this whole 2.06 incompatibility crap!
* 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...
* Yet another example in the long list of how not releasing your project IN A
TIMELY MANNER is creating HUGE PROBLEMS downstream... Looking at you GRUB!!!
* Closes#2233
* 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.
* With the removal of Windows 7 support, wrong platform archs in the check for updates
(that has now been fixed) and switch to an x86_64 default MinGW binary, we have enough
breaking changes to warrant a version bump for the major. So just do that.
* Also fix a couple Coverity warnings and update a URL.
* 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.
* Having Windows append "SCSI Disk Device" screws up the scoring regarding
disks that are actually describing themselves as SCSI, so replace that
with "UAS Device", as it should be.
* Closes#2221.
* Also fix a MinGW warning.
* 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.
* Required because some users appear to force kill Rufus while we're doing WUE patching of boot.wim,
and Windows prevents a .wim with the same path and index from being mounted twice, even if the
original .wim has become stale or deleted. Oh, and of course the WIM APIs don't have a force-mount
flag that would take care of this whole situation.
* Basically, this forces us to parse HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WIMMount\Mounted Images
and check each instance for a .wim/index match, so that we can access to the existing mount path
so that we can actually unmout the image (because, in typical Microsoft fashion, WIMUnmountImage
requires both the mount path and the source image to be provided).
* Closes#2199.
* Also improve the existing VHD code to use a struct where possible.
* Also avoid using LPTSTR in lieu of LPWSTR (even if they do resolve to the exact
same thing) and force the use of app_dir when looking for a local .loc file.
* Closes#2193
* Boy do you not want to use chars in struct iso_su_ce_s as
from_733() will sign extend the bytes and you will end up
with an offset like 0xffffffc4 instead of 0x000000c4...
* Addresses the leftover from 6c44dccc10.
* Also some headers clean up and pick up latest libcdio changes.
* Note that, because of an unrelated libcdio bug where it does not properly
detect Rock Ridge symbolic links, some files may still not be instantiated.
* Also remove unneeded checks for ISO9660/UDF function cleanup and remove
a workaround for an issue that has since been fixed in libcdio.
* Closes#2164
* Also add breakdown of score computation when device enumeration debug is active
* Also fix a minor Code Analysis warning in msapi_utf8.h
* 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...
* Not using our own FAT32 formatting may result in access errors due to
Microsoft's hare-brain handling of ESP access.
* Also update upcoming translations and copyright year.
* This means we don't need to worry about conversion issues regarding signedess. In addition,
the behavior will no longer be undefined if for some reason the conversion cannot happen.
* Closes#2104.
* 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.
* Update the relevant loc messages.
* Also add a -z commandline option to force the Windows version (but without letting
this option work as an override, if running on an unsupported platform).
* Also fix typos and broken URLs.
* Since 8814944c35 we may mount an ISO for the lookup of the Windows version,
which produces DBT_DEVNODES_CHANGED messages being issued when the virtual DVD is being created or removed
* This in turn leads to unwanted device refreshes.
* This patch makes sure we ignore DBT_DEVNODES_CHANGED while scanning.
* Also improve comments in iso.c.
* Arch recently added a "search --no-floppy --set=root --label <LABEL>" into their
grub.cfg, which we didn't have provision for patching, which means that, as soon
as the user changed the label or used an Arch derivative with a label that isn't
compliant with FAT (e.g. Athena Linux), search, and therefore boot would fail.
* Also alter the code so that we modify for more than one token if needed.
* Closes#2086
* GPT was fine but MBR led to the creation of EFI bootable images using NTFS as the file
system, but without the UEFI:NTFS partition (e.g. UwUntu-22.10-desktop-amd64.iso).
* 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\
* These are reserved usernames that are created by default, so we should not use them.
* Also fix missing format specifier in ApplyWindowsCustomization() and make sure we
print wim_index for both mount and unmount.
* Closes#2067 (with thanks to marcosfrm)
* 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.
* 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).
* Remove last ditch effort on systems that are clearly broken for localization
and always report an explicit error to the user.
* Also update GitHub Actions actions/checkout (Closes#2036).
* Existing code was trying to detect if GRUB patching was needed for GRUB bootloaders
even if they were using standard prefixes, and as a result dropped GRUB support for
any versions that wasn't 2.04 or 2.06, since we don't have a patch for those.
* This patch restores the expected behaviour to ensure that we don't disable GRUB if
a standard prefix is being used, regardless of the version being reported.
* Note that this issue only affected BIOS GRUB boot. UEFI GRUB boot was unaffected.
* Also set rufus-next to 3.21.
Pete Batard
AJIOB
ИEØ_ΙΙØZ
Abdulmajeed Almarzoqi
Sivert Løkkesveen
Minh Nguyễn Quang
五月雨
Mike Handberg Hovedskov
Mattayawerakiat Suttirak
Ahmed Rasnaama
Kaloyan Nikolov
Fedorovici Constantin-Robert
Marcos Mello
Yanottama Oktabrian
Jakub Mierzejewski
Marco A. Ramirez Madrid
Erfan Al
Костянтин Сергійович
Csizmadia Gábor
Дмитрий Ерохин
VenusGirl
cupofocha
Christos Alvanos
Riku Brander
Martin Kubánik
Aldis Tutins
Itiel
Mehmetali Kuran
Dinis Medeiros
Wang JiaWei
Thilo Langbein
Marcello Gianola
HRxiaohu
Miloš Ljubičić
Thomas De Rocker
Sopor Spr
Richard Kahl
Rose
dependabot[bot]
Jeffrey Walton