* 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.
* 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.
* 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 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.
* Per MS documentation, _mktime64() *ALTERS* the time being passed to first add/substract
the timezone offset before converting to an epoch.
* This resulted in our evaluated epoch from the DBX GitHub commit being a few hours more
recent than the epoch we store for our embedded files (which is UTC) for timezones that
are behind of UTC, since their epoch have an offset added to convert localtime to UTC.
* Fix this by using _mkgmtime64() that does not suffer an unwanted time manipulation.
* For safety, also use -u for epoch format conversion in our script just in case.
* Closes#2762.
* Also comment the "unsupported check; not verifying file integrity" warning for XZ
decompression, improve XZ ARM64 support and add an exception for some Samsung UFDs.
- Side load SetupAPI.dll, as this is the DLL that was causing the CfgMgr32.dll local load.
This reverts part of 622e60659c since we no longer have to hook into CfgMgr32.dll directly.
- Also set the redefinition of DECLSPEC_IMPORT, which we need for MinGW32 x86, in the global AM_CFLAGS
of configure.ac, so that we no longer have to worry about forgetting to do it in a source and experience
crashes on 32-bit as a result (See 965759f58a).
- Also delay-load crypt32.dll while we're at it.
- Also add provision for enabling /DEPENDENTLOADFLAG:0x800 on MinGW, by leaving a properly crafted entry
in the .rdata section that can then be used with the loadcfg.py Python script.
- Sadly, per https://github.com/pbatard/rufus/issues/2701#issuecomment-2874788564 and subsequent comment,
having DependentLoadFlags set to LOAD_LIBRARY_SEARCH_SYSTEM32 is still not enough to take care of side
loading issues, as, ever since the introduction of wimlib support, we are seeing CRYPTBASE.DLL being
side-loaded in MinGW, and, even with crypt32.dll being delay-loaded there is literally *nothing* we can
do about it!
- The end result of all the above is that we will have no choice but ditch MinGW for release executables
as it's just impossible to properly take care of side-loading vulnerabilities with MinGW (and Microsoft
are REALLY not helping with this whole mess either, when they don't even use LOAD_LIBRARY_SEARCH_SYSTEM32
for Windows' system DLLs).
- In preparation for this, we add UPX compression to the x86_64 and x86_32 MSVC executables.
- Finally, we also fix one last Coverity warning in xml.c and remove duplicates in .vcxproj for ARM64.
* Current Rufus and earlier versions (when compiled with MinGW) suffer from a side-loading vulnerability
due to cfgmgr32.dll being attempted to be loaded from the same directory as the executable. This may
result in someone being able to execute elevated malicious code if they already have gained user-level
access to the platform and were able to drop an arbitrary cfgmgr32.dll in the same directory as rufus.
* While we were able to address similar vulnerabilities using delay-loading, this method does not appear
to work for MinGW with this specific DLL, so we remove all the implicit CM_ function calls, that result
in automated DLL loading that cannot be mitigated, to replace them with direct DLL hooks, which are
not subject to Windows' default (vulnerable) DLL lookup behaviour. We still add the def for the delay
loading in case we manage to find how to delay load cfgmgr32 with MinGW in the future...
* Fixes CVE-2025-26624 (https://github.com/pbatard/rufus/security/advisories/GHSA-p8p5-r296-g2jv).
* This vulnerability was discovered by @EmperialX working with @Shauryae1337 and reported by @EmperialX.
* Similar to what we already do with IgnoreUSB##, except this time, users
can add REG_SZ keys IgnoreDisk01 to IgnoreDisk08, with a string like
"{F333EC2E-25C9-488D-A7FC-9147C2367623}" to ignore a GPT disk with this
specific GUID.
* This may be useful for people who mount fixed virtual drives, or people
who have enabled Hot Swap on their SATA storage, and who want to make sure
they won't be able to inadvertently select that disk in Rufus.
* Also set rufus-next to 4.7.
* buf could be freed twice in iso.c.
* Using HRESULT_CODE(error_code) in WindowsErrorString() could lead to "Error: SUCCESS" messages.
* Closes#2524.
* Also try to address potential issues that appear to have been seen in the wild.
* 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.
* 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.
* 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.
* 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.
* 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
* 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 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 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 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.
* 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
* 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...
