With apologies to longpanda/ventoy, and since I was curious about it myself, let me detail my findings (which I hope are relatively accurate, but may of course contain errors that I'll be happy to see corrected).
The one prerequisite you need to know is the great explanation steve6375 gave here of the outline of WinPE boot process (but even then, the only thing that really matters is that winpeshl.exe is the first executable that is being run during an installation process).
- As you already know, when a Ventoy bootable drive boots, it boots in a custom version of GRUB 2.04 with extra ventoy features added. This presents the user with the choice of ISOs, and also allows you to add some additional options when booting, such as vt_debug on, which (if you add it through GRUB's e command before you boot the currenty selected image) allows you to get some very informative details on what Ventoy does.
- If a Windows ISO is selected, the first thing Ventoy does (as part of its GRUB extension) is:
- Open boot.wim from the ISO
- Locate and read the original Windows\System32\winpeshl.exe to memory (NB: I'm discounting what happens for multiple wim indexes here)
- Depending on the bitness of the image being used, inject either of the 32-bit or 64-bit version of vtoyjump.exe as Windows\System32\winpeshl.exe.
- Windows ISO is now booted from the virtual UEFI CD-ROM device (well, technically, I think 2 happens while we are doing this, so one could consider that 2-3 is a single step), which eventually leads to the altered boot.wim being read, extracted to memory and run. At this stage we quit the UEFI environment which means that the UEFI virtual CD-ROM device ceases to be available.
- Once the NT kernel launches and has completed performing pre initialisation, the altered Windows\System32\winpeshl.exe (which, again, is just vtoyjump32.exe or vtoyjump64.exe in disguise) is launched.
- The first thing the application does is read back the original Windows\System32\winpeshl.exe from memory and copy it to Windows\System32\ventoy\winpeshl.exe.
- Then the relevant ISO from the Ventoy exFAT partition (which would usually be available as the D: drive, but of course a proper lookup for it is being made by vtoyjump) is mounted, either using the native Windows 8 or later API or by loading the imdisk driver and executable.
- From there, the whole content of the installation media are accessible in a manner that Windows will be able to locate automatically, and the rest of the installation process is handed over to Windows\System32\ventoy\winpeshl.exe (i.e. the original winpeshl.exe from the image).
For those interested, I'm also leaving the Windows\System32\ventoy.log that vtoyjump.exe creates below:
[2020/05/19 12:19:34.591] ######## VentoyJump ##########
[2020/05/19 12:19:34.591] argc = 1 argv[0] = <winpeshl.exe>
[2020/05/19 12:19:34.591] Current directory = <X:\windows\system32>
[2020/05/19 12:19:34.591] ReadWholeFile2Buf <winpeshl.exe>
[2020/05/19 12:19:34.607] Success read file size:159232
[2020/05/19 12:19:34.607] Find os pararm at 125952
[2020/05/19 12:19:34.607] SaveBuffer2File <ventoy\winpeshl.exe> len:32256
[2020/05/19 12:19:34.607] Logical Drives=0x80000c Path:<\Win10_1909_EnglishInternational_x64.iso>
[2020/05/19 12:19:34.607] File NOT exist under C:
[2020/05/19 12:19:34.622] File exist under D:
[2020/05/19 12:19:34.622] GetPhyDiskUUID D
[2020/05/19 12:19:34.622] D: is in PhysicalDrive0
[2020/05/19 12:19:34.622] Disk UUID match
[2020/05/19 12:19:34.622] Find ISO file <D:\\Win10_1909_EnglishInternational_x64.iso>
[2020/05/19 12:19:34.622] This is Windows 8 or latter...
[2020/05/19 12:19:34.622] VentoyMountISOByAPI <D:\\Win10_1909_EnglishInternational_x64.iso>
[2020/05/19 12:19:34.638] OpenVirtualDisk success
[2020/05/19 12:19:34.654] Mount iso by API success
[2020/05/19 12:19:34.654] Mount ISO FILE: SUCCESS
[2020/05/19 12:19:34.654] DeleteVentoyPart2MountPoint Phy0 ...
[2020/05/19 12:19:34.654] File C:\ventoy\ventoy.cpio exist
[2020/05/19 12:19:34.654] LogicalDrive:\\.\C: PhyDrive:0 Offset:31373393920 ExtentLength:33554432
[2020/05/19 12:19:34.654] PhyDisk=0 for C
[2020/05/19 12:19:34.654] Delete ventoy mountpoint: SUCCESS
[2020/05/19 12:19:34.654] auto install no need
[2020/05/19 12:19:34.654] Ventoy jump success ...
For BIOS/Legacy Windows boot, the process is of course pretty much the same, with only the virtual CD-ROM device that's being set for loading of the boot.wim image in a BIOS environment being different.
For Linux boot, which I haven't looked into in detail at this stage, my understanding is that it's a bit more straightforward: Ventoy "simply" alters the GRUB or Syslinux boot options from the ISO so that, whereas the kernel being invoked of course remains the same, ventoy.cpio is used as the initrd.
Then once ventoy.cpio executes, it performs a lookup of the distro being booted and sets up and mount the relevant virtual CD-ROM image before handing over to the original initrd.
I have to say that what Ventoy does is quite nifty, though of course, in the case of Windows, it requires altering the original ISO files (boot.wim) and running an non-Microsoft executable early in the boot process, which puts you at the mercy of Microsoft deciding to:
- Perform an checksum validation of the ISO content, a la Ubuntu 20.04 (though if it's like Ubuntu 20.04, then this would be easy to work around, as you can just alter the checksums that are recorded in a text file on the ISO).
- Enforce some kind of tampering validation for winpeshl.exe.
Because of their corporate users, who probably want the ability to create their custom installation media without being bothered, I don't personally believe that Microsoft is going to do any of that any time soon, though I'm a bit surprised to see how much of a cavalier attitude Microsoft seems to have by default on the first executable that gets launched in the installation environment, especially considering that setup.exe from install.wim is digitally signed whereas winpeshl.exe isn't.
As a matter of fact, if you had asked me, some time ago, whether I thought that the method used by Ventoy of injecting winpeshl.exe had any chance to work, I would have said no. So props to longpanda/ventoy for actually trying it out and demonstrating I was wrong. Oh and, the way I see it, I think that the advent of Ventoy might very well mean the slow death of Rufus/RMPrepUSB/Easy2Boot and other utilities, which, as the author of Rufus, I'm kind of okay with because, even if I see minor issues with it, I think Ventoy does a great job at delivery what users have been wanting for a long time in a very simple and convenient package, so that deserves some props...
At this stage, the only major concern I have with Ventoy when it comes to security has to do with Secure Boot:
- Currently, after users have enrolled the Ventoy certificate to allow it to run in a Secure Boot environment, any unsigned bootx64.efi from any ISO will happily be launched. Ironically, whereas Secure Boot maniacs might see this as a great improvement over utilities like Rufus, that may ask them to temporarily disable Secure Boot ("See? I don't have to disable Secure Boot any more!"), it actually defeats the whole point of Secure Boot which is to only allow the execution of boot files you have some reason to trust, and effectively leaves their system wide open to the many maliciously crafted Windows ISOs that can be found floating around the internet... The irony is certainly not lost on me that some of the very people who clamour for Secure Boot will be the very same people happily leaving their system wide open for the execution of malicious content, that Secure Boot was precisely designed to protect them from....
Fortunately, fixing this should be relatively simple (famous last words), by having Ventoy detect if Secure Boot is enabled, and, if that is the case, only launch bootx64.efi files that pass the Secure Boot digital signature validation. Then, if users still want to execute non Secure Boot signed media, they still can do that, but it will become very explicit if the ISO they are trying to boot is actually Secure Boot compliant or not, which, for users who actually care about Secure Boot, is what you want.
- No matter how much I trust Ventoy (which, after having talked extensively to his friendly developer and looked at the source I most certainly do) I really don't like the idea the idea of enrolling somebody else's single global certificate into my machine's Secure Boot store, because you never know if the private key associated with that certificate might be stolen by a third party and used for nefarious purposes.
Unfortunately, unlike the above, there's no good solution to that problem, though one could provide an option for Ventoy2Disk users that could: Generate a new credential, sign the Ventoy bootx64.efi executable with this credential, destroy the private key (since it should only ever be used to sign that executable and nothing else), and then copy the certificate to the Ventoy ESP to replace ENROLL_THIS_KEY_IN_MOKMANAGER.cer. The problem of course is that, if you do that, then you have to re-enroll the new key every time Ventoy is updated, which isn't ideal. That is, unless you also provide an option for users to save and reuse the private key, which of course opens other security issues (but at least these issues would be limited to one specific user environment and wouldn't affect other Ventoy users in the same way as the leaking of Ventoy's current private signing key would do)...
If Ventoy becomes as popular as I believe it will, there will be a lot of people suddenly interested in getting their hands on the private key that matches the certificate that Ventoy uses for Secure Boot, and no matter how safe longpanda keeps it, it will always be seen as a major liability of using Ventoy for security conscious users....
When I get a chance, I will log issue #1 in the Ventoy issue tracker, because anyone who understands the point of Secure Boot will not take Ventoy seriously unless that is fixed. And I think I'll have a private discussion with longpanda (unless he/she wants to reply here) about #2, because, even if I suspect that most people, including the author of the application, will prefer to keep the current global .cer since it's a lot more convenient, I still think it will be worthwile to provide an alternative, for security minded people...
in creating the bootable ISO
