* Oh, and thanks a lot Microsoft for introducing a major .NET regression that prevents file system
monitoring from working on anything but the system drive, and causing me to waste a full day trying
to sort it out, without success. With this utter bullshit, you have cemented my choice of going with
anything but .NET, when creating utility applications in the future...
* See https://github.com/ublue-os/bazzite/issues/4374. Also, great job following STANDARDS, Fedora!
* Also silence a warning in libcdio (triggered by Bazzite not knowing of to master their ISOs).
* Group the static elements in dialog-specific structs.
* Use 0 rather than -1 for unset elements.
* Also fix initial checkbox value for Silent Install not being properly set.
* This option disables most of the unwanted crap that Microsoft tries to push onto users by default.
* Also make sure the Silent Install option is only enabled if the 'Disable data collection' check box is checked.
* Also add a big scary warning for the Silent Install option.
* This should make it more explicit to Windows users to identify the installation media.
* Also update crazy-max/ghaction-upx to latest (Closes#2936).
* Also fix a Coverity warning and use improve StrArray handling/init.
* Note that this will completely repartition and erase the first disk available on the target system ⚠WITHOUT ANY PROMPT⚠.
* Also, this is dependent on the local account name and duplicate regional WUE options to be selected.
* With a special mention to Claude AI, that said that detecting whether a one or multiple disks were available was impossible
to accomplish using only unattend XML commands... which we therefore promptly managed to disprove.
Please wake me up when there is any semblance of "intelligence" in the LLMs that are currently destroying our planet...
* This basically accomplishes the steps described in https://support.microsoft.com/kb/5042562 on first logon.
* Note that we use the installed system's SkuSiPolicy.p7b rather than the host system's, even if the latter
is usually more up to date, because otherwise, the user may run into Error code: 0xc0000428 on first reboot.
* Likewise, we do not provide this option for Windows To Go, as it could prevent the existing Windows install
from booting, and we'd have to extract SkuSiPolicy.p7b from `install.wim` to do so.
* Also remove dead code related to SkuSiPolicy.p7b hash parsing (which Microsoft no longer uses).
* Closes#2919 (though it doesn't actually address the issue reported there, which we couldn't replicate).
* Rather than waste our time reimplementing the wheel, use the descriptions from gdisk.
* Also update the DB SHA-266 entries to latest.
* Also set version to rufus-next and update GitHub Actions to latest (Closes#2929).
* 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.
