* 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.
