* If you attempt to read past the end of a mounted VHD, not only will Windows happily
return data that doesn't exist (instead of returning End of Disk), but it will also
corrupt the existing data!
* So, to appease the capricious Windows gods, we now make sure that we never attempt
to read (or write) past the boundaries of the source or target when writing images.
* This should address the last issue from #2468.
* Also set version to rufus-next and make some small improvement in winio.h.
* As usual, Microsoft products are so poorly designed that they can't deal with
multiple instances of one thing. In this case, if the Windows installer sees
two ESPs after you select the drive where you want to install Windows and it
creates its own ESP there, it will fail during the "CopyinG Windows Files"
step.
* So make sure that the UEFI:NTFS partition is *not* set to ESP type, even
though it is really an ESP, which is something that we used to do, but that
got reverted in 0f23c47184.
* I don't think we want to make this setting permanent for the time being as
this may result in drawbacks like people using the UEFI Shell going through
an unwanted MD5Sum check because they forgot to turn it off.
* Make them more explicit by ensuring that they use a size suffix.
* Also improve whitespace consistency.
* Also make sure that we display the search for conflicting process message
in the status on a search operation that may timeout.
* Also fix a potential buffer overflow when displaying the detailed HDD vs UFD score due to the
safe_sprintf() macro re-evaluating the expression passed as parameter.
* Also refactor and clean up the the safe_###() macros to avoid similar issues.
* Also use FOF_NO_UI as flag for SHDeleteDirectoryExU(), which may alleviate some Alt-D errors.
* As opposed to the ERROR_HANDLE_EOF we get when reading sectors from the VHD file directly, now that we mount
VHD/VHDX for reading, and access them as regular disks, we also need to process ERROR_SECTOR_NOT_FOUND as an
indicator for the end of the drive.
* Also switch to using GetOverlappedResultEx() with a timeout since we no longer have to cater for Windows 7.
* Closes#2468.
* Ubuntu changed their GRUB config format yet again, so our search for the kernel
config no longer works, and the 'persistent' option doesn't get added.
* Switch to a more generic '/casper/vmlinuz' search, though it might have unintended
consequences...
* Also fix a possible double free in FormatExtFs().
* is_in_md5sum() could partially match a string against another one, which, aside from matching
unwanted files, could also lead to files not being identified as being in the md5sum.txt if
the previous partial match happened to be with the current search target.
* Fix this by making sure that we always match a whole path followed by '/n', '/r' or '/0'.
* Not all md5sum.txt (e.g. Ubuntu 24.04) will reference the UEFI bootloader,
so we can't rely on using that data for the bootloader extraction.
* Instead, formally test for the presence of the bootloader on disk.
* The call returned the size occupied in blocks rather than the actual file size,
leading to issues such as Rufus not being able to identify the GRUB version used
by Ubuntu 24.04.
* 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.
* p[safe_strlen(p)] = 0; was pointless and could lead to a buffer overflow if
the string was not already NUL terminated, so remove it and make sure we
process a buffer that either contains legitimate Syslinux version strings
(that are NUL terminated always) or that has been read through read_file()
(that always adds a NUL terminator to the buffer).
* Also fix some whitespaces in related code sections and switch to using
read_file() for GRUB version lookup.
* Vulnerability discovered and reported by Mansour Gashasbi (@gashasbi).
* Whereas the length of the buffer allocated for the UTF-8 filename string is
the same length as the UCS-2 (which means it can store twice as many UTF-8
bytes as there are characters in the filename), it is still possible for the
converted UTF-8 string to overflow this buffer if the name contains glyphs
that use 3 or 4-byte sequences.
* As a result, use strncpy with the actual size of the UTF-8 filename buffer
(the following bytes are calloc'd to zero so the truncated string will be
NUL terminated) and produce a warning if the filename is truncated.
* Vulnerability discovered and reported by Mansour Gashasbi (@gashasbi).
* 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.
* The legacy code we used for writing disk images used the size of the source image as
the maximum number of bytes we should copy, which is fine for uncompressed DD or VHD
images, but not so much for compressed VHDX ones. So we now make sure to use the
actual size of the virtual disk, which we obtain when mounting the VHD/VHDX.
* Also fix log progress update as well as a MinGW warning.
* Mint users sure are lucky that one of them *lied their way through* pretending that
persistence actually used to work with previous version of Mint, when it never did,
because they got us going through a whole refactor of the partition creation process
just so we could make Mint persistence work.
* Closes#2428.
* Also fix a Coverity warning.
* Use of '*.*' as pattern in file save dialog could lead to assert and crash, so
we now try to derive the type of image to be saved from the file extension. We
also did not properly handle user cancellation in the file save dialog.
* Also update iso9660/iso9660_fs.c to latest proposal of El Torito image handling.
* Also add a couple asserts in the hash table functions so that, if these ever get
triggered we will pick them from Windows Store reports, and clean up code.
* 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.
* Also update copyright year and improve uprintf error handling
* Also bump GitHub Actions dependencies. Note that we do NOT want to update to
upload-artifact v4 because it BREAKS the creation of artifacts from matrix.
See: https://github.com/actions/upload-artifact#v4---whats-new
* Closes#2382
* Closes#2383
* 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.
* For some weird reason appending the base directory to the root syslinux.cfg
we create does not appear to work with Slax. So we now always patch ldlinux.sys
to include the base directory.
* Also add an exception to move the /slax/boot/EFI directory to /EFI.
* It should be noted that, as of slax-64bit-slackware-15.0.3.iso, the Slax UEFI
Syslinux bootloaders appear to be broken (since creating a media without using
Rufus at all per the Slax documentation does *not* produce a USB drive that was
bootable in UEFI mode on 2 of the machines I tried).
* Also clean up some iso.c code and fix some unreachable code in ntfssect.c.
* Closes#2336.
* Closes#2338.
* 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.
* Duplicated symlinked Rock Ridge files were not counted into the total size needed
to process the image and as a result, progress could go over 100% when extracting
data (e.g. debian-live-12.1.0-amd64-lxqt.iso).
* Fix this by adding the duplicated files twice in the total block size.
* '.wic' are DD images used by the Yocto project.
* Why Yocto chose to use their own extension instead of using the de-facto '.img' is beyond me but hey...
* Also update GitHub Actions dependencies to latest.
* Closes#2319.
* 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.
* sr-SR is not a country code that Microsoft accepts (and from what I can see
is not valid, because it should be sr-RS).
* This has the unfortunate effect of preventing the installation of Rufus from
the Windows Store, which fails with error 0x80070057 (Invalid parameter).
* Fix this by using a country code for Serbia that Microsoft does accept: sr-Latn-RS
* Closes#2015
* First thing I'm gonna say is that, if your app validation process is unable to catch universal
installation errors like the one above, then your app validation process *SUCKS*, Microsoft!
* Hopefully, this has to do with the additional languages not being passed to MakePri's /dq
option. And there I also have to say thanks to Microsoft for *NOT* documenting how the heck
one is supposed to pass multiple languages with /dq, so that you actually end up with
<qualifier name="Language" value="en-US;ar-SA;bg-BG;..."> in priconfig.xml.
* What's that quote again? "Show me an App Store than only triples my work, and I will happily
let it take a third of my revenue"...?
* 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.
* How nice of "Open Source proponent" IBM/Red-Hat/Fedora to fix double space typos while making sure the
provenance of the software they are using is hidden:
https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/0024-Don-t-say-GNU-Linux-in-generated-menus.patch
* Long story short: Fedora fixed the double space in "GRUB version", but of course they didn't upstream
this change since it is part of a patch that removes every possible mention of GNU. This made our GRUB
version detection break, since it relies on finding a "GRUB version" string.
* Fix this by looking for both "GRUB version" and "GRUB version".
* This, however, does not fix Fedora Rawhide BIOS boot, since they also added custom GRUB calls such as
'grub_debug_is_enabled', which we don't have in our vanilla produced GRUB binary.
* Closes#2002.
* Local account is created with the same name as the current user along with an *empty* password
(which we force the user to change on next logon). This is done to assuage users who might be
weary of entering a password in a third party application, and has the benefit of enabling
autologon when the install is complete.
* Note that the creation of a local account through an answer file prevents Windows 11 22H2
from bugging users about MSA *even with an active network connection*.
* For convenience reasons, only duplication of the current username is enabled. We *may* add a
dialog to enter any random username in a future version, but for 3.20, this is all you get.
* Likewise, the locale duplication is only carried out during OOBE and *not* WinPE (which means
that you still get the initial "Windows setup language and user preferences" prompt). This is
intentional as otherwise the default screen and "Repair Windows" options are not presented.
* It's not my fault that the Windows password change screen is super ill conceived, whereas it
doesn't hide the current password field as it should when the current password is blank, and
one needs to click on a very small arrow to get the changes applied, instead of a PROMINENT
button that should intuitively have been positioned right next to "Cancel".
* If you want to complain that we should just "present the user with XYZ and be done with it",
please bear in mind that we can't add new dialogs to Rufus as willy-nilly as you believe we
can. *ANY* new UI interface requires major planning, which is the reason why, for the time
being, we are limited to reusing a simple dissociated list of checkboxes for all WUE options.
* In a manner that defies logic, Microsoft designed Windows setup to parse Autounattend.xml
for windowsPE tasks in the PE environment, but only carry out the copying of that file
to %WINDIR%\Panther for subsequent processing with the other passes *IF* there exist an
actual windowsPE section.
* In short, when using the Autounattend.xml method, Microsoft have made all passes there
dependent on the existence of a windowsPE pass, regardless of whether that pass has any
use or not.
* Working around this would be fine and all (just add an empty windowsPE pass so that the
later passes get executed) if the absence of a windowsPE pass didn't also determine
whether the user will be presented with the default Windows setup screens that include
the "Repair your computer" option or a completely different set of screens (c.f. #1971).
* This means that, to keep users happy, we need to add yet another method to carry out
tasks that should have remained the realm of boot.wim's Autounattend.xml, and instead
create a \sources\$OEM$\$$\Panther\unattend.xml when there are no windowsPE tasks (on
account that setup copies anything found under \sources\$OEM$\$$\ to %WINDIR%\).
Only through this can we have the specialize and oobeSystem tasks actually carried out
(for bypassing MSA requirements of skipping the data collection screens) while keeping
the original Windows Setup look and feel.
* Closes#1981
* The use of an unattend.xml to create the TPM/Secure Boot/Disk/RAM bypass keys was
prompted by Microsoft restricting the ability of Windows Store app from manipulating
offline registry hives.
* However, the use of a windowsPE phase in unattend.xml to insert the keys results in
a windows command prompt briefly appearing when setup launches, as well as slightly
different Windows setup screens from the default.
* So we are now reverting to trying to edit the boot.wim registry hive offline (which
should work for the non Store version of Rufus) while falling back to using a PE
unattend section if that doesn't work.
* Closes#1971
* This is for Knoppix images that have a /boot/syslinux that links to /boot/isolinux/
with EFI Syslinux trying to use /boot/syslinux/syslnx[32|64].cfg as its config file.
* Note to Knoppix devs, you could have ensured EFI File System transposition by using
the same approach as we do here, which is to create non-symlinked /boot/syslinux
config files that point back to the isolinux ones.
* This should produce the same output while improving compatibility with systems that have a broken VGA implementation.
* Also fix an LD error with newer gcc toolchains.
* See https://lists.gnu.org/archive/html/libcdio-devel/2022-06/msg00000.html
* This partially fixes ISO mode support for Gentoo Live, though, since the Gentoo
maintainers appear not to have a kernel NTFS driver in the current images, the
installer still fails to mount the installation media.
* This is enabled by default for Windows 11 images and is done to prevent the
annoying behaviour of Windows 11 *automatically* upgrading all ReFS drives
it sees to latest version, thereby instantly preventing you from accessing
these drives ever again with Windows 10.
* See: https://gist.github.com/0xbadfca11/da0598e47dd643d933dc#Mountability.
* I've never seen that watermark in the first place, therefore can't test if the option is
working, and, as opposed to the other options, users can deal with it post install anyway.
* Also ensure that we prompt for customization when selecting an install.wim.
* This moves the extended Windows 11 options (bypass TPM & Secure Boot) away from
"Image options" into a new explicit dialog, along with supplementary customization
such as enabling offline account (for Windows 11 22H2) and skipping all data
collection questions.
* This customization is now enacted through an unattend.xml file rather than offline
registry manipulation, so that this *should* also work with the Windows Store version.
* Also update arch detection and rework/reorganize upcoming translation changes.
* Note: The 'Remove "unsupported hardware" desktop watermark' option is *UNTESTED*.
* Now uses read-only NTFS drivers v1.3 from https://github.com/pbatard/ntfs-3g.
* Like previous ones, aa64, ia32 and x64 versions are Secure Boot signed (but not arm).
* Fixes the recent potential vulnerabilities found in https://github.com/tuxera/ntfs-3g.
* Note that we have asked Microsoft to add the previous signed NTFS drivers to the UEFI
Revocation List, even as we believe that the ntfs-3g vulnerabilities are not exploitable
in the limited context of UEFI:NTFS.
* This enables the provision of Registry/Settings key IgnoreUsb01 to IgnoreUsb08 where
one can specify a USB device to ignore by providing its VID:PID as a 32-bit hex value.
* Closes#1879.
* Also update rufus.ini sample for current Rufus version.
* Also fix status display for Alt-Q.
* 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.
* ISOs with tons of Rock Ridge deep directory entries (such as OPNsense)
can be very slow to scan due to the nature of deep directory parsing,
which requires processing the whole ISO9660 fs, for each deep directory
file, in order to find the relevant LSN entry.
* Since we don't expect much of the content we care about to reside in a
deep directory entry, we amend the code to cut short the scan of any
directory that contains such elements.
* Note that this only applies for ISO scan and it does nothing to speed
up the ISO extraction process.
* Related to issue #1575
* Closes#1467
* Also ensure that previous element is set when repositioning a
control to preserve tabbing order
* Also fix x64 version being able to download x86 BETA
* This is mostly aimed at Debian 11 netinst on the Raspberry Pi 4
* Only available for regular UEFI ISOs if GPT and FAT are selected (no MBR ESPs).
* Also fix a MinGW warning in GetUnusedDriveLetter()
* Now use version 1.6 of the EfiFs drivers that enables firmwares that
don't provide EFI_DEVICE_PATH_TO_TEXT_PROTOCOL to mount NTFS partitions
regardless.
* Also use the latest version of UEFI:NTFS that displays additional info
about the system.
* Closes#1213.
* Also update version to Rufus-next.
* ASLR is enabled by default for Visual Studio builds but that isn't the case
for MinGW builds. Fix that and also add -Wformat-security while we're at it.
* Closes#1518
* Also ensure that we'll never write protective MBR message for non-bootable
GPT drives, even as we are not calling WriteSBR() for those anyway.
* Also fix SBR message not being written for bootable images
* Also add an extra partition refresh after deleting partitions to try
to further force Windows take its stinking paws off our drive.
* Fix RTL location of "ISO" in the "Copying ISO files" translation for Arabic and Persian
* Fix whitespace/message ending issues for various translations
* Sync all .po's with .loc to avoid another German progress update is missing issue
* We distractedly chose to populate the message from our protective MBR
for GPT/UEFI-only boot media into the 4KB that directly followed the
MBR, which of course is space that is being used by the primary GPT.
* This resulted on systems having to fall back to using the secondary
GPT, which not all appear to be designed to do.
* Alter the code to ensure the protective message is written at LBA 34,
after the primary GPT.
* Closes#1507
* If a converted label contains mostly underscore, the proposed
label is used for FAT32 instead. However this label still has
the KB/MB/GB symbols localized so it may be invalid.
* Ensure that we use a non-localized version of the size when
using such a label.
* Closes#1506.
* Also fix a VS2019 static analysis warning in net.c.
* The upcoming Ubuntu 20.04 comes with MD5 validation turned on by default.
* When creating persistent boot media, we may update some of the validated files
to add persistence, update the search labels, etc.
* Make sure that the files we modify get their MD5 updated where needed.
* Also add 'loopback.cfg' to the list of config files we can add persistence to.
* Part of #1499
* Among other nefarious things, ubuntu 20.04 added a $casper_flavour suffix
to their grub.cfg /casper/vmlinuz kernel option, so we can no longer rely
on 'persistent' being inserted in a proper location.
* Switch to latching on file=/cdrom/preseed and hope that it will work for
all of Ubuntu & derivatives.
* Part of #1499.
* Commit 4c5adf092e moved us away from using CreateFile()
when extracting a file on the target media, and as such the error code returned when
failing to create an 'autorun.inf' due to a security solution has shifted.
* Make sure we handle the new error and don't bail out on 'autorun.inf' creation.
* Also update the actual name of the RtlDosPathNameToNtPathNameXXX function we use.
* Closes#1496
* Recent versions of Windows can set the deafult locale to codepage 65001 (UTF-8).
* This produces an assert due to a missing entry in cp_hr_list[], so fix that.
* However, this fix alone is not enough, as a GetOEMCP() that returns 65001 means
that any systems set to UTF-8 will fall back to codepage 437 for DOS, which is
definitely not what we want => Add an extra call to determine the actual OEM
codepage when UTF-8 is detected.
* Closes#1468
* Commit [e522ef6c55] (PR #1426) regressed the '%s'
progress messages back to '%0.1f%%' which results in the percentage remaining at
zero when the UI is in German.
* Surround macro params to ensure expected results
* Fix copy-paste errors
* Fix a potential buffer overflow in SetSectionHeaders()
* Add const modifier where relevant
* Use GetWindowLongPtr() everywhere
* Use proper sprintf format for unsigned int
* Use %s for printf-like funcs (https://www.viva64.com/en/w/v618/print/)
* Closes#1464
* Status code assignation was removed when the original code
was altered to use pfNtFsControlFile(). Fix that and also
make the code more similar to other calls.
* Closes#1459
* msg.S now reads an ASCII message (with escaped colour sequences)
from the following blocks, which is both more flexible and allows
for more content to be displayed.
* Also adds Bochs testing to the MBR build facility
* Hopefully using DICS_FLAG_CONFIGSPECIFIC instead of DICS_FLAG_GLOBAL is all that was needed
to get device disabling/re-enabling work without creating zombie devices, because we sure
need to force Windows' hand when it comes to detecting logical volumes...
* Implement CreatePreallocatedFile() which uses NtCreateFile() to create files with preallocated sizes.
This is used during ISO extraction to improve performance.
* Remove now-unused preallocate_filesize which was called after CreateFileU().
* Closes#1445
* ClearMBRGPT() attempts to write WRITE_RETRIES times, even if all those times succeed.
* Instead, skip the remaining retries on success.
* Also improve code readability.
* Closes#1454
* So, as it happens, when assigning the product of two 32-bit variables into a 64-bit one,
compilers default to being *DUMB* and, against all reasonable expectations, do not perform
that multiplication as a 64-bit operation (even when the code is compiled as x64). Wow,
that's really great decision making by compiler designers if I ever saw some... Whoever
decided that C developers would much rather want truncation and 32-bit overflows, instead
of the expected *LOGICAL* behaviour of conducting arithmetic operations as 64-bit when the
result will be assigned to a 64-bit variable, need to be condemned to a lifetime of trying
to help elderly folks trying to conduct simple computing tasks as a punishment...
Anyhoo, nt_write_blk()'s offset.QuadPart = block * channel->block_size + nt_data->offset
was overflowing 32-bit as soon as block * channel->block_size went over the 4 GB mark,
with the disastrous results one can expect. Considering that this is code we practically
lifted verbatim from e2fsprogs, I guess e2fsprogs' NT I/O manager was never properly
tested with anything larger than a 4 GB. Awesome!
* We fix the above by doing what unix_io.c does and setting the 32-bit read/write_blk()
calls to be wrappers around their 64-bit counterpart (since, once you deal with a 64-bit
block variable, the computation is conducted as 64-bit).
* Also remove a bunch of stuff we don't need from config.h
* Closes#1396
* Fix use of EXT2_BLOCK_SIZE() instead of EXT2_INODE_SIZE() during inode
initialization, that made us zero way many more blocks than was needed.
* Also disable sparse_super feature and improve block setup.
* Also explicitly use IS_POWER_OF_2 macro where required.
* Most distros (Debian, Ubuntu) have moved to using Sylinus 6.04 even
as it has NOT officially been released, so we want our fallback to
work against this too.
* pre1 since the Syslinux folks advise against using pre2 or later...
* Closes#1444
* Only applies for blank UEFI:NTFS drives for now. UEFI:NTFS Windows drives are
still set to use NTFS only (since Windows 7 doesn't support UEFI exFAT boot).
* While compressed EFI bootloaders are not an issue for UEFI:NTFS, some UEFI firmwares
embed an NTFS driver that doesn't support NTFS compression.
To address that, also uncompress the EFI bootloaders on NTFS.
* Closes#1424
Yet another link in the long chain of Microsoft making it UNFATHOMABLY DIFFICULT
to figure out what version of Windows an application is actually running on...
* When using compressed NTFS, having a compressed bootmgr prevents BIOS boot, so we
now call `compress -u` where needed to leave the relevant bootmgr files uncompressed.
* Closes#1381
* Also fix a minor warning in ext2fs
* Windows platforms prior to Windows 10 1703 cannot access any logical partition besides the
first one (we don't even get a volume for those).
* This fix enables the use of physical + offset for ext# formatting to work around this,
which is file since we don't actually need to mount the partition.
* Also fix ext2fs_open2() not handling normalized versions of Windows drive paths ("\\?\...")
* Also fix an issue where we would make the drive letter unavailable after formatting a
standalone partition to ext#.
* Also ensure that we return an error if the drive we attempt to locate a partition on
through an offset does not match the currently selected one.
* Also remove some unused calls in drive.c.
* Closes#1374
* While we need to detect that 'txt.cfg' is a Syslinux config file, so that
we can alter it for persistence, it should never be used as a main config
file, such as the one we link to when we create /syslinux.cfg.
* Closes#1375
* Because we install our own ldlinux.sys, we must ensure that if the ISO contains
an ldlinux.sys in the root directory, this file is not copied over. However, our
comparison for the 'ldlinux.sys' string was case sensitive which means that some
ISOs such as R-Drive Image boot ISO, that use 'LDLINUX.SYS' were trying write over
our file, resulting in a file extraction failure.
* This patch ensures that the string comparison for 'ldlinux.sys' is case insensitive.
* Also add 512px sized icon (upscaled using waifu2x)
* Make sure they are always unchecked for pure DD images
* Make sure Quick Format is checked and disabled for ReFS or Large FAT32
* Also make sure Fixes for old BIOSes is disabled for pure DD images
* Remove unused iso_op_in_progress and use a single op_in_progress that gets
set when we disable the controls.
* Also fix an issue where Ctrl-L was being processed as Alt-L due yet another
completely backwards Windows behaviour where the message that is meant to
indicating whether Alt is pressed is also sometimes used to indicate that
another key is being pressed if the dialog doesn't have keyboard focus...
* You can use <Alt> to switch modes during an operation that supports it (e.g. Checksum
computation, DD image writing or zeroing, save to VHD, download, etc.
* IMPORTANT: This is *NOT* available for all operations. Especially, if you were hoping
to get transfer speed or ETA during ISO or WIM extraction, you *WILL* be disappointed.
* Also harmonize the code in checksum.c
* This is to avoid Microsoft's appalling refresh of the partition layout,
which can result in partitions not being assigned a volume GUID.
* Mostly reverts a change that was applied in 1c39a80d72.
* Also add some more enum output and bail if we can't get a logical drive.
* Closes#1351
* Also fix another round of Coverity trigger-happy warnings (Seriously, those FALSE
POSITIVES about fwprintf can £$%^&* off — fix your frigging detection, Synopsys!)
* Only UEFI boot for now (GRUB) & requires a post 2019.07.26 ISO for Ubuntu.
* This adds the relevant persistence/persistent kernel option to the conf file, sets the
expected volume label and creates a /persistence.conf file where needed.
* Also improve token parsing by ensuring a token is followed by at least one white space.
* Only happens on Win7 due to MinGW not automatically initializing variables to zero on that platform.
* Root of the problem was that GetWindowTextU() did not properly handle empty text controls, due to
GetWindowTextW() returning 0 on empty strings. As a result, the UTF-8 label was not properly set to
the empty string, but kept whatever data it contained, which is garbage on Windows 7 and resulted in
an invalid label (even after sanitizing, since we don't sanitize low-level ASCII characters).
* Closes#1352
* Regression was introduced with 3c1ef23ff3 and 2ff6da49f0.
* Because of it extended label and icon, fixes for old BIOSes and Rufus MBR were not applied.
* Closes#1348
* Sorry Azerbaijani speaking people, but this was only added out of
good will and, with no new translator volunteering, this out-of-date
translation was holding us back.
fs.c:61:25: warning: taking address of packed member of 'struct fat_boot_sector' may result in an unaligned pointer value [-Waddress-of-packed-member]
61 | sectorsize = get_16(§buf->bsBytesPerSec);
| ^~~~~~~~~~~~~~~~~~~~~~~
* Only enabled when Advanced format options are shown
* Also enable reading of extfs volume label
* Also improve GRUB lookup fallback
* Also fix possible truncation when sanitizing labels
* Also write a zeroed MBR when non-bootable is selected
* Add VDS formatting support (through an Alt-V cheat mode)
* Add partition index support
* Improve(?) Windows To Go support by following Microsoft recommended partition order
* Code refactoring & cleanup
* Add display of persistence controls on relevant images
* Add progress on ext3 formatting and improve error reporting
* Also improve MountVolume() and fix some Coverity warnings
* NtWow64QueryInformationProcess64() fails because sizeof(PVOID64) happens to be 4 instead of 8 in MinGW32 (WTF?!?) and
therefore sizeof(pbi) is set to 44 instead of 48, resulting in NTSTATUS code 0xC0000004: STATUS_INFO_LENGTH_MISMATCH...
=> Use an ULONGLONG instead and don't rely on MinGW32's improper definitions.
* Also fix an issue whereas, when we find multiple conflicting processes, the first one's path is duplicated to all others...
* Also disable Launch button while we do so
* Also add new <Ctrl>-<Alt>-<Y> cheat mode
* Also terminate update thread before exiting if running
* Also set version to rufus-next
* Since we have compression available through Bled we might as well use it
* Also validate that the download URL comes from https://github.com/pbatard/Fido
* Also prevent the check for update from running while we are downloading ISOs
* Also fix an issue where Rufus doesn't report an error if 'fmifs.dll' can't be found (#1284)
* Also improve GitHub issue template to mention that Ctrl-L can also be used to access the log
* This should help Windows users who create a GPT/UEFI drive and try to use it in BIOS/Legacy
* Also make sure that we take into account the split space for both "SELECT" and "DOWNLOAD"
* What would be nicer was if half these Coverity issues weren't false positives...
* Also update Readme and fix progress bar colour not being reset after error
* FS selection might default to NTFS instead of FAT32 after having selected a Linux ISO if
no drive was plugged in when the ISO was selected and then a drive was plugged using NTFS.
* Also display Fido's exist code
* Closes#1255
* Center dialog on open
* Close dialog on main application exit
* Display ISO short name & size on status bar during download
* Display ISO download progress on taskbar
* Also fix improper detection of EAGET Mass Storage USB Device as HDD
* This is accomplished through Fido (https://github.com/pbatard/Fido), a *SIGNED*
PowerShell script, that is downloaded from GitHub and that resides in memory for
the duration of a session.
* The reason we use a downloaded PS script, rather than an embedded on, is because:
- Microsoft have regularly been changing the deal with regards to how retail ISOs
can be downloaded, and not for the better, so we can't simply embed a static
means of downloading ISOs and expect that to work forever.
- By using an external script, we can immediately respond to whatever new means of
*ANNOYING* their legitimate users Microsoft will come up with next, as well as
make sure that, the minute a new retail version of Windows becomes available, it
also becomes available for download in Rufus.
* Note that if you are concerned about downloading a remote PS script that is being
run at the same level as an elevated application, you should understand that:
- Only scripts downloaded from GitHub, from an account that is protected with 2FA,
are allowed to run (i.e. someone would first have to steal a *physical* 2FA key
to be in a position to upload a malicious script).
- On top of this, only scripts that are signed with a separate private key (RSA +
AES-256), that is itself also protected with a strong unique password which only
a single person knows (and must manually enter each time they want to make a new
version of the script available for download), are allowed to run.
The above means that there's about as much chance for someone to manage to upload
a malicious script on the GitHub servers, that Rufus would allow to run, as there
is for someone to upload a malicious version of Rufus itself.
Still, if you are paranoid and have concerns that, even as you can validate from
its source that Rufus does not attempt to execute any remote script unless a user
actively selected and clicked the DOWNLOAD button, you can also completely disable
the remote script download feature, if you just set the update check to disabled
(which, by the way, Rufus *EXPLICITLY* asks you to choose whether you want to
enable or not, the very first time you run the application).
* Also remove _unlinkU() which duplicates what DeleteFileU() already does.
* Closes#1268
* Issue was introduced in 521034da99 and has
to do with VS2017's handling of static strings in RELEASE mode.
Fix is to use a static char array instead.
* Also fix MinGw build warnings and increase process search timeout
* Relying on system MUIs was too brittle and provides us with no guarantee
that the translated messages we need will actually be there.
* Also fix space before question mark in French translation.
* With no thanks whatsoever to Microsoft for *NOT* documenting that you need
to pass flag 0x2000000 to WIMCreateFile() if you want to avoid an open error.
One has to wonder if Microsoft isn't deliberately adding *BULLSHIT FLAGS*
that only they know of, to hinder competing third-party tools...
* Also revert a472e96e87 as this is creating
unwanted detection issues as per #1239. We'll try to devise a better way
to avoid intempestive refreshes later on.
* efi.img was not always being properly process (e.g. proxmox-ve_5.2-1.iso)
* Note that this doesn't mean that the ISO will properly boot, just that we will
now properly detect and install the EFI bootloaders that reside within the .img
* Instead of x86_32 and x86_64.
* This should aid with our appxbundle creation and if Microsoft want to
be wholly incorrect in their arch designations, who am I to judge?...
* FAT32 would become available and selected as default FS when
selecting a Windows ISO with a >4GB file and then clicking
"Show advanced drive properties".
* Range not being set when plugging a drive
* Set position to zero when no drive is selected
* Make sure the restored position can not be greater than the max
* As per https://github.com/appveyor/ci/issues/838, 'res/*' means
all files within directory, non-recursive, whereas we want 'res/'
for all files within directory, recursive.
* Make sure translations that are the same as English are removed in the .po
* Automate digital signature
* Add a more distinguishable icon
* Also update French translation
* Now only use major.minor for version references
* Drop the use of LOC_FRAMEWORK_VERSION. We'll use custom handling if we ever need a framework change.
* Also update/fix some of the UI elements for persistent partition
* Also reposition the language selection menu when we don't have a large number of them
* Also fix last lang message not being properly processed
* Also update loc file comments in preparation for the new framework
* Also update Rufus version data
* Ctrl-Alt-Z can now be used to zero a drive, while skipping blocks that are detected empty
* Depending on your hardware, as well as the existing drive content, this strategy can greatly
speed up zeroing operations, especially if the flash memory's read speed is much higher than
its write speed.
* Closes#1174
* Also add a test ISO to display these controls
* The intent is to use the next round of translation to get these new UI elements localized,
as any translation work takes _months_, and it is a precondition to start working on #691.
* Also fix new issues with image options when switching language
* This doesn't mean we'll get persistence support any time soon, but any UI work
on this needs to be carried out *MONTHS* in advance because of the translators.
* Use a default block size of 128 KB (can speed up read operations)
* Reorganise patterns to suit different types of NAND cells (SLC, MLC and TLC)
* Only run fake drive test on first pass
* Also update rufus-next to 3.2
* Now preallocate the file size for each extracted file, to help the target
filesystem avoid fragmentation issues and thus increase writing speed.
* Closes#1170
* Add a proper delay before retrying a write operation and increase retry count to 4
* Add retries when clearing boot records or when zeroing a drive
* Also improve log output from USB device reset
* Some Thai UTF-8 notification messages went over the buffer size limit we used for vsnprintf()
* Also, revert part of 645184f11e and use LRE+PDF marks instead:
Don't handle in the code what is better handled in the loc file.
* We now auto resize the height of the Notification dialog according to the
number of lines of the message.
* Also harmonize local RECT variable names according to what we do elsewhere.
* *THIS* is what you need to do to replace Microsoft's broken SetDllDirectory("")
implementation and mitigate DLL sideloading from local directories.
* Also fix some comment typos
* We were switching the global boot type variable to something other than BT_IMAGE,
which prevented ISO extraction whenever a GRUB secondary boot record was written.
* Closes#1145
* This is a "stealth" update for the 3.0 release
* The issue was that we are picking the UTF16 file system name from
the dropdown, and where we use the "(Default)" suffixed version,
it now has an RLE at the beginning which we must skip.
* This prevented RTL languages from being able to format a drive as FAT32...
* Looks like the openSUSE people are abusing the ISO9660 file system,
and libcdio should be a bit more relaxed about it.
So we alter libcdio to be more chill...
* Also relax the annoying 'from_733: broken byte order' messages
* Closes#1136
With thanks to Itiel
* Fix a potential buffer overflow in lmprintf for RTL languages
* Automatically apply RLE/PDF to all RTL messages, and remove the RLE/PDFs from the .loc
* Fix Windows messing up of multiline RTL tooltips (The trick is, if you want actually
want RTL, you need to *disable* RTL... Sure, Microsoft, that makes a lot of sense?!?)
* Also properly scale the length of the multiline tooltips according to the zoom factor
* Closes#1132
* Because of Windows' poor handling of toolbar buttons' tooltips, an unwanted
tooltip could be displayed onscreen after closing the log.
* Also fix an issue when Rufus would reset the partition type to GPT after a
user created an MBR flash drive (e.g. after creating a Windows bootable USB).
* Also add a retry in PKI's GetSignatureName()
* This should help with getting a "The downloaded executable is
missing a digital signature" message when launching an update.
* Closes#1130
* Whole screen was being refreshed when calling InvalidateRect() in ResizeMoveCtrl()
* Progress bar bounding rectangle could be erased at 0.0%
* No progress was displayed when writing ISOHybrid images in DD mode
* Also fix an issue when write error would not display the error string
* File indexing is too much of an annoyance on removable drives anyway
and this should help with perf and access issues
* Alt-Q cheat mode is now changed to re-enable file indexing
* Also fix a rogue 'else' in the code
* Needed because native Windows produces obnoxious tearing on redrawing.
* Also rename global partition scheme variable back to 'pt'
* Also fix major and minor version numbers in the .rc
* Super-strange behaviour, that happens on Windows 7, at low zoom
factors, only when compiled with MSVC (MinGW is fine) and only
when the advanced options are set to be displayed on startup...
* Looks like TB_GETIDEALSIZE is screwy - Thanks a lot Microsoft!
* If, for example, you have a truncated gz-compressed file and try to
write it to disk, bled_uncompress_with_handles() will return an error.
Previously, this was not reported back to the user.
* Closes#1040
* Add timestamp processing for nested signature and check for anomalous differences
* Also prevent attack scenarios that may attempt to leverage multiple nested signatures or countersigners
* Simplify code by using CryptDecodeObjectEx/WinVerifyTrustEx and improve timestamp reporting
* This commit effectively fixes https://www.kb.cert.org/vuls/id/403768 (CVE-2017-13083) as
it is described per its revision 11, which is the latest revision at the time of this commit,
by disabling Windows prompts, enacted during signature validation, that allow the user to
bypass the intended signature verification checks.
* It needs to be pointed out that the vulnerability ("allow(ing) the use of a self-signed
certificate"), which relies on the end-user actively ignoring a Windows prompt that tells
them that the update failed the signature validation whilst also advising against running it,
is being fully addressed, even as the update protocol remains HTTP.
* It also need to be pointed out that the extended delay (48 hours) between the time the
vulnerability was reported and the moment it is fixed in our codebase has to do with
the fact that the reporter chose to deviate from standard security practices by not
disclosing the details of the vulnerability with us, be it publicly or privately,
before creating the cert.org report. The only advance notification we received was a
generic note about the use of HTTP vs HTTPS, which, as have established, is not
immediately relevant to addressing the reported vulnerability.
* Closes#1009
* Note: The other vulnerability scenario described towards the end of #1009, which
doesn't have to do with the "lack of CA checking", will be addressed separately.
* Introduced in 369a392af0 because, of course when Microsoft has a
call that goes (###, param1, param2) they define a macro for it that goes (param2, param1)...
* Required to support Debian Live 9.1 in ISO mode
* Note that this only works if the efi.img boot files do not require
additional content besides the one extracted from the ISO.
* Don't duplicate the PrintInfo() from DownloadFile()
* Make sure caret is disabled and displayed text will not appear selected
* Also update MSG_085 and remove unneeded MSG_240
* Add a WaitForSingleObjectWithMessages() call so that we can process Windows messages
while waiting on events (prevents lockup while issuing log messages)
* Limit the total duration of CheckDriveAccess() to 2 seconds
* Allow for user cancellation
* Also update code to use the Edit_####() predefined macros for Edit controls instead of EM_### messages
* The process search appears to be blocking on some platform, and we
also don't want users to have to wait too long on format startup
* Also update the update check for Windows XP SSL errors
* Rufus now checks for processes with handles opened on the drives/volumes before
starting the format operation and asks the user if they want to continue.
* This mimics Windows' behaviour when formatting drives, and actually uses the
same message as the one from shell32.dll.mui.
* Closes#773
<!--PLEASE READ THIS CAREFULLY: You*MUST* read and complete the checklist below, by placing an x into each [ ] (so that it shows [x], without any space inside [ and ]), BEFORE clicking on 'Submit new issue'. Failure to perform these steps, WHICH ARE ONLY THERE TO HELP*YOU*, will result in the issue being dismissed without warning.-->
Checklist
---------
- [ ] I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
- [ ] I performed a search in the issue tracker for similar issues, using keywords relevant to my problem.
- [ ] I clicked the `Log` button in Rufus and copy/pasted the log into the line that says `<FULL LOG>` below.
- [ ] The log I am copying is the FULL log, starting with the line `Rufus version: x.y.z` - I have NOT removed any part of it.
Additionally (if applicable):
- [ ] I ran a bad blocks check, by clicking the "bad blocks" check box in Rufus, and confirmed that my USB is not defective
- [ ] I also tried one or more of the following:
- [ ] Using a different USB drive
- [ ] Plugging the USB into a different port
- [ ] Running Rufus on a different computer
- [ ] If using an ISO image, I clicked on the `#` button (at the bottom of the Rufus interface), to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.
1. You *MUST* read and complete the steps from the checklist below, by placing
an x into each [ ] (so that it shows '[x]', NOT '[ x]' or '[x ]'), BEFORE
clicking on 'Submit new issue'.
2. Failure to perform these steps, WHICH ARE ONLY THERE TO HELP *YOU*, will
usually result in your issue being dismissed without notice.
3. If you are reporting an issue when trying to run Rufus, or when trying to
boot a media created by Rufus, you *MUST* provide a log, period. Please do
not assume that the developer(s) will be able to "guess" the specifics of
your environment, what image you used, what type of media you used it with
or the many many other critical parameters that the log provides data for.
To investigate an issue, a log from Rufus is ALWAYS required.
4. If you still *choose* not to provide a log when reporting a problem, you
agree that your issue will be closed without any further investigation.
YOU HAVE BEEN WARNED.
-->
Checklist
---------
- [ ] I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
- [ ] I performed a search in the issue tracker for similar issues using keywords relevant to my problem, such as the error message I got from the log.
- [ ] I clicked the 'Log' button (🗒️) or pressed <kbd>Ctrl</kbd>-<kbd>L</kbd> in Rufus, or used [DebugView](https://learn.microsoft.com/en-us/sysinternals/downloads/debugview), and copy/pasted the log into the section that says `<FULL LOG>` below.
- [ ] The log I am copying is the FULL log, starting with the line `Rufus version: x.y.z` - I have NOT removed any part of it.
Additionally (if applicable):
- [ ] I ran a bad blocks check, by clicking _Show advanced format options_ then _Check device for bad blocks_, and confirmed that my USB is not defective.
- [ ] I also tried one or more of the following:
- [ ] Using a different USB drive.
- [ ] Plugging the USB into a different port.
- [ ] Running Rufus on a different computer.
- [ ] If using an image, I clicked on the `(✓)` button to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.
* Modern and familiar UI, with [38 languages natively supported](https://github.com/pbatard/rufus/wiki/FAQ#What_languages_are_natively_supported_by_Rufus)
- if [%COMPILER%]==[MSVC] msbuild rufus.sln /m /p:Configuration=%CONFIGURATION%,Platform=%PLATFORM% /logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
- if [%COMPILER%]==[MinGW] C:\msys64\usr\bin\bash -lc "export PATH=/mingw%BITS%/bin:$PATH; cd /c/projects/rufus; ./configure --build=%PLATFORM%-w64-mingw32 --host=%PLATFORM%-w64-mingw32 --disable-debug; make -j4"