* Because PowerShell forces us to close the script we downloaded prior to execution, it is possible for a
malicious background process (running unprivileged, as the same user that launches Rufus) to replace the
Fido script after we downloaded and validated it, but before we actually execute the PowerShell command
to run it.
* See https://github.com/pbatard/rufus/security/advisories/GHSA-hcx5-hrhj-xhq9, which led to CVE-2026-23988.
* To mitigate this, we now use a security descriptor, to force the script to be saved with Administrator
and System access only so that an unprivileged user process does not have the capability to replace it
before execution.
* Issue discovered and responsibly disclosed by @independent-arg.
* Fix also suggested by @independent-arg.
* Whereas their location in AppData should prevent other users from replacing these files,
it is still possible for an unprivileged app ran by the same user to alter them after
they have been downloaded.
* To prevent this (as well as more elaborate TOCTOUs on these specific files) we now open
a read-only handle (with *no* file sharing rights), then validate the SHA256 hash (since
these files are known at the time of compilation) and only once validated (but without
relinquishing the exclusive handle) run or access the content of the file.
* Also add an arch suffix to the oscdimg.exe, so that we don't run into a situation where
x86 and x64 Rufus may complain about a previously downloaded exe.
* Also improve error handling from SaveImage() and fully qualify the dism.exe calls.
* It appears that Bitdefender now mounts a 32 MB VHD on the system where it is installed, so filter it out.
* For reference, this is how it is otherwise detected by Rufus:
Found VHD device 'Microsoft Virtual Disk'
Disk type: FIXED, Disk size: 33 MB, Sector size: 512 bytes
Cylinders: 4, Tracks per cylinder: 255, Sectors per track: 63
Partition type: GPT, NB Partitions: 1
Disk GUID: {3A182634-ECAF-4D9C-9CE0-9E61EC7A093A}
Max parts: 128, Start Offset: 17408, Usable = 33520128 bytes
Partition 1:
Type: Microsoft Basic Data Partition
Name: 'Bitdefender Partition'
Detected File System: NTFS
ID: {BA5FBC33-B5DD-4468-B9FB-349269EF43B8}
Size: 31.9 MB (33488896 bytes)
Start Sector: 64, Attributes: 0x8000000000000001
* Our image type selection forgot to shift the actual type to ISO when FFU is not supported,
leading to dism being invoked instead of oscdimg.
* Closes#2889.
* Also make sure the UDF label is no more than 32 characters.
* Also increase the oscdimg.exe commandline size as 256 characters may not be enough with long paths.
* Also try to report 'oscdimg.exe` errors in the log instead of silencing them.
* Also fix devices with (non-USB-compliant) VID 0000 being ignored by default.
* Factorise the PROCESS_BASIC_INFORMATION for 32 and 64 bit.
* Add a (currently unused) GetPPID() function.
* Increase the size of the buffer for reporting processes and their parameters.
* Don't report stale/killed processes in our main process conflict report.
* Some (newer) SSD devices appear to have very long Hardware IDs, with tons of underscore
(eg: "SCSI\DiskNVMe______________________________NVME_SSD_512GBS1111H0L")
* Because of this, and because Hardware ID is a REG_SZ, where entries can be repeated many
times, our static MAX_PATH buffer can be too small, preventing UAS disks from being
properly listed.
* Fix this by bumping our buffer to 4 KB, as well as reporting errors on Hardware ID fetch
in enum debug mode.
* Closes#2894.
* The folks at umbrelOS seem to have mastered their ISO in a way where the /usr/lib/systemd/system/system-systemd/ directory
is not declared (or not declared with attribute _STAT_DIR) on the ISO-9660 file system, which results in Rufus producing an
error when trying to create the /usr/lib/systemd/system/system-systemd/x2dcryptsetup.slice file.
* To fix this, add a workaround to create missing directories if we encounter ERROR_PATH_NOT_FOUND during ISO-9660 extraction.
* The `IsMsDevDrive` function is refactored to use the `FSCTL_QUERY_PERSISTENT_VOLUME_STATE` control code
for detecting Microsoft Dev Drives.
This replaces the previous approach of analyzing drive layout which was not always correct.
* Closes#2873.
* UPX compressing exes makes it impossible to reference the PDB when debugging
which means that, ever since we switched to using the MSVC executables for
both standalone and appstore in 4adfa4f37e the
appstore dumps we get on crashes have become basically unusable for debug :(
* We therefore revert to producing non UPX compressed executable for MSVC by
default, so that we can resume investigating appstore crashes on next release.
* At the same time, on release builds, we add new UPX compressed executables to
the GitHub Actions artifacts.
* Also update actions/checkout to v6 and close#2868.
* This aims at reducing errors with Windows and other apps trying to keep a hook into
existing ESPs and other partitions, thereby causing access errors.
* This is expected to potentially help with #2776 and similar issues.
* Closes#2776.
* Thank the C standard for choosing not to "standardize" the size of long (as
one would rightfully expect from a *standard*) and instead going for a
"should be at least" super vague definition, that led to lseek() on Windows
and UNIX effectively using different offset sizes, and programmers everywhere
getting bitten when taking a UNIX codebase and porting it to Windows...
* Closes#2837.
* Note that if you use this toggle even once, then you will no longer be able to use
system settings to toggle Dark Mode, unless you *MANUALLY* delete the registry key.
* Closes#2821.
* Also update github/codeql-action to v4.
* Closes#2833.
* Alter the WUE CA 2023 option text and remove duplicate translation for "ISO Image".
* Force cache-only when invoking CertGetCertificateChain (This should address #2781).
* Explicitly report the SVN/SBAT number comparison in the log.
* Also don't perform revocation checks on unsigned bootloaders.
* Also add provision for CRLF handling when parsing our remote SBAT.
* Because of Dark Mode support, and the fact that Microsoft does not offer system
dialogs that support Dark Mode (even the more "modern" Task Dialog is a joke in
that respect, with people having to resort to using detours to fix this massive
letdown from Microsoft. See https://github.com/SFTRS/DarkTaskDialog), we had to
switch to use our own custom dialogs instead of using MessageBox().
* And of course, since we had to recreate the whole smorgasbord of what Microsoft
offers in terms of button configuration, it's unsurprising that we forgot to add
support for one conf (MB_YESNOCANCEL) that some of the download prompts use.
* Closes#2813.
...or with an option that doesn't require poking into boot.wim.
* Closes#2815.
* Also report the use of the CA 2023 option in the log.
* Also set rufus-next to 4.11.
* Use MessageBox()'s MB_ constants instead of redefining our own.
* Fix the *BROKEN* 200% scaling that Microsoft uses for warnings, that includes a pixel
that should have been set to transparent but that instead was set to white.
* This'll allow us to switch to using our Dark Mode compatible notifications dialogs in
a future commit, instead of relying on the non Dark Mode compatible MessageBox().
* The current wimlib code makes repeated attempts to close stdin (0) on cleanup when a WIM cannot
be opened, which doesn't sit too well with MSFT's _close() as it invokes an invalid parameter
exception handler that can make the application crash...
* This may happen when we try to open the WIM from an ISO that has been truncated because it
resides on a path that is longer than MAX_PATH on account that wimlib repeatedly attempts to
close the phantom stdin fd's it sees assigned to its internal (and unused) WIMStruct after it
errors out on trying to open the image.
* So we declare stdin as invalid for use with Visual Studio compiled apps.
* For good measure we also increase the size of the string arrays we used for WIM paths to 1024
UTF-8 characters, and add explicit asserts in case we have to truncate these paths (since we
are quite curious about real-life scenarios where people need paths longer than 1024).
* Closes#2777.
* Also improve the safe_strcp() and safe_sprintf() macros and fix some unwarranted "Command was
terminated by user" messages introduced in commit ea01cd41c0.
* The Nutanix phoenix.x86_64-fnd_5.6.1_patch-aos_6.8.1_ga.iso contains a GRUB bootloader that somehow stripped
the 'fshelp' source string from the fat module, and therefore prevents Rufus from detecting that FAT32 support
is available.
* As a result, since NTFS is also not supported, no file system able to be selected by the user for ISO mode,
and the media creation process fails with "Could Not Partition Drive".
* Fix this by only disabling FAT32 in ISO mode if NTFS is available, and producing a warning in the log if we
have to forcefully enable FAT32 even if we didn't detect FAT32 compatibility.
* Closes#2769.
* Also add the setup wrapper binaries produced from previous commit and harmonise the casing of WARNING messages.
