How to get Windows 10 to boot in legacy mode? (UEFI on MBR)?

OK, so here's the deal.....I did a little experimenting awhile back and found that booting Windows 10 in UEFI mode on MBR partitioning works fine (http://reboot.pro/to...-gpt-very-easy/). My Samsung SSD is MBR-partitioned, and has a FAT32 EFI system partition, marked with the "EFI" flag in GParted. All runs fine, drivers install, updates install, games work, no BSODs. I chose MBR because this will allow me to boot legacy OSes as well. And I can use softwares like rEFInd and Clover for UEFI booting. I imagine that Linux should generally work fine on this setup too.

 

But now I have the issue of wanting to boot 10 in legacy mode. This of course requires the appropriate boot files, and an appropriate MBR. But if Clover's code (or whatever) is to occupy my disk's MBR, then Windows' MBR cannot live there too. So I'm thinking that maybe there is a way to chainload the Windows MBR, from something like GRUB4DOS, then it loads the Windows boot files, and (hopefully) 10 boots without BSODing.

 

I will also note that my C drive is encrypted with BestCrypt Volume Encryption, which to my surprise worked without a hitch. But if I am to boot 10 in legacy mode, then I will need to use the appropriate BC MBR so that it can decrypt and boot the C drive. This is another barrier that needs to be considered.

 

On a side note, I used the following command when installing 10, after installing the OS with imagex:

 

bcdboot C:\Windows /l en-US /s A: /f UEFI

 

C of course represents the C drive, A represents the letter I assigned to the EFI system partition. Valid options for /f are UEFI,BIOS, or All. I had tried the "All" option in the past and hit issues with BestCrypt and GRUB2.

 

Thanks again!

You normally need not any "fancy" MBR.

The MBR on BIOS is just some means to load and execute the bootsector (PBR or VBR code).

If you use grub4dos you can even bypass that and directly chainload BOOTMGR directly, and - advised for experiments - you can still get away with a "Vista Boot floppy" image or similar.

That will work just fine, the complication is only given by your BestCrypt setup.

I am not familiar with the way Bestcrypt modifies the booting chain, but seemingly:

https://www.jetico.c..._in_version.htm

 

 

Since v.2 advanced users can move contents of BCVE code from MBR to first sector on removable device (floppy or USB stick) and restore original contents of the MBR sector. After that boot of encrypted operating system is possible only from the removable device, or, if the computer is dual-boot, only not encrypted system will load without displaying BCVE boot-time password prompt.

Several interesting schemes of booting computers can be invented with the help of the feature, example for dual-boot computers is only one of them. Although now the functionality is helpful rather to advanced users, future versions of BCVE will use it for enhancing security of the software.

there is no real need of the Bestcrypt IPL in the MBR, and very likely this feature can be "ported" to a floppy image loaded via grub4dos.

 

Wonko

Thanks for the response. Do you mind explaining what an IPL is? The point for me is to be able to boot in either UEFI or legacy modes, or with a UEFI emulator like Clover or DUET. There is no real need for doing this, apart from just "because I want to see if it is possible". Another issue I would like to avoid is the Windows Updates and hibernation issues that some in @milindsmart's "BIOS on GPT" thread seem to be experiencing. I think it is happening for them because some of them are loading Windows boot files from a floppy image. I do use hibernation sometimes and it is important to me that Windows Updates are able to install without failing because of arcane, unorthodox booting scheme or partitioning method. I am of course booting in UEFI on MBR, not GPT, but I think I might experience the issues they are having if I go the floppy route.

 

Are you saying that I just need to somehow find a way to make a copy of BC's bootloader code (that asks for the volume password), then chainload it with some other bootloader?

 

Thanks!

Are you saying that I just need to somehow find a way to make a copy of BC's bootloader code (that asks for the volume password), then chainload it with some other bootloader?

 

Thanks!

More or less yes.

 

IPL is the acronym for Initial Program Loader which is in itself an old (and now probably deprecated) "blanket" term that can be applied to anything that actually loads a program, typically on PC (BIOS) that is the code in a PBR/VBR (read as bootsector).

 

I was trying to make the distinction between the contents of "normal" MBR code (which only chainloads the bootsector of the active partition") and the bootsector itself that actually contains code that accesses the filesystem and loads a program.

 

I was suggesting to use for experiments the floppy image approach, so that you won't mess up with your hard disk, but since you are on MBR/BIOS, you should be able to later set it up as a "plain" boot from hard disk.

On the Bios on GPT thread the issue behind the hibernation/update problems revolve essentially on the "booting media" being not available (as it is mapped in a volatile manner).

 

As said the issue here is the Bestcrypt thingy, how it works and whether it will be chainloadable, etc. is the BIG question.

 

If I were you I would make experiments in a virtual machine, first making a Windows 10 install (on MBR style disk) that can be booted BOTH in BIOS and in UEFI without any encryption overlay, then once the procedure is clear, add the encryption.

 

If you have also in the mix GRUB2 (installed to the MBR+hidden sectors) that will be a further complication, maybe that is the reason why your BCDBOOT command failed with /All (or /BIOS)

 

Wonko

Another issue I would like to avoid is the Windows Updates and hibernation issues that some in @milindsmart's "BIOS on GPT" thread seem to be experiencing.

Read the whole thread, at last the last three pages.
Go for a hard disk image. Boot from the hard disk image. Include Bestcrypt to this image first.
Mount the hard disk image early at windows boot. Use a third party disk driver to do this, not the default included vhd driver.

@cdob: Thanks for the suggestion, but unfortunately a 3rd party disk driver, like WinVBlock or FiraDisk, is out of the question if at all possible. I would like to avoid using anything that requires constant booting in test-signing mode. I prefer my drivers to have valid digital signatures.

The KernSafe Virtual Disk driver files EhSstorClass.sys and EhStorTcgDrv.sys are signed.

Small steps: try the floppy approach first.
And the "plain" boot from hard disk next.
If this works, use this.

The KernSafe Virtual Disk driver files EhSstorClass.sys and EhStorTcgDrv.sys are signed.

This sounds like a different game .

 

I presume that this will imply having the "boot" volume (the one with BOOTMGR and \boot\BCD) as a disk image initially mapped by grub4dos and later re-hooked by the KernSafe driver so that they allow the mounting of the "right" BCD as BCD0000001 in the Registry, i.e. "method #1" here:
http://reboot.pro/to...o-gpt/?p=204888

 

While till now we were on method #3

 

For method #1 any tutorial/specific howto on how to have the KernSafe drivers load before Trustedinstaller?

 

Wonko

This sounds like a different game .

Yes, and a overly complicated approach at given request.
Should be not required, take this as a last try.

Yes, it's "method #1" http://www.kernsafe....talmounter.aspx
No registry adjust, no driver load adjusting.
Most likely it's not the boot up, but the shut down. At which
Idea, not verified: The BCD has to be writable late, just before the reboot.

@IAmTheTrueMeaningOfCovfefe
As for testing:
Create a BestCrypt rescue media, a ISO image or a USB Disk.
Both integrate a floppy image. Inside the floppy image is a file bcve_mbr.bin.

Idea, not tested:
bcdboot C:\Windows /l en-US /s C: /f BIOS
Hexedit the file bcve_mbr.bin. Set the C: partiton active (0x80). Disalbe other active entries.
Can you boot from the rescue CD (ISO image) or the rescue USB Disk at BIOS mode?

Can you boot grub4dos, BIOS grub or BIOS syslinux from Clover?

Which partitons exist so far at hard disk?
Is one set active? Which one?

I have a spare USB SSD which I'm not using, so instead of going the VM route, I cannibalized it instead.

 

The setup:

1. 10 Enterprise 1709, originally installed in legacy mode, from an E2B 10 media booted in legacy mode as well

2. MBR partition table

3. 1024MB FAT32 partition is first, which has the "Boot" and "EFI" flags in GParted (I added EFI flag after setup completed, thinking it might prevent setup from finishing)

4. 100GB C drive

5. Extended partition, which contain a single logical partition, used for holding my Users folder, for which I used a method on TenForums to relocate it)

6. 47703MB of unallocated space at end of disk, for SSD overprovisioning, which is what the Samsung Magician software recommends

 

This leaves me able to create additional logicals in the extended, for more legacy OSes. And I still have a free primary partition slot. I had previously tried putting the c drive as a logical too, but setup wouldn't finish, it just kept spinning on the logo forever doing nothing.

 

Anyway, the initial boot was in legacy mode, setup finished. I used imagex for applying the WIM, the same bcdboot command as above but with the /f all parameter, and bootrec to create MBR. EFI partition has both UEFI and legacy boot files, disk currently has Windows bootstrap code in the MBR (which I'll change later). The setup USB was also in legacy mode, I had tried before in UEFI mode but bootrec /rebuildbcd failed with something like partition not found, it wrecked my E2B imgptn but not the USB itself.

 

After getting to desktop I turned off fastboot and immediately rebooted, using F7 to select Windows Boot Manager entry. No BSOD, System Information confirms UEFI boot mode. So if I select Samsung SSD in my boot menu, 10 boots in legacy, and if WBM is selected it boots in UEFI. I can switch at will between the 2 modes without issues, with no need of 3rd party programs. But I will still be testing hibernation, encryption, drivers, and updates on this disk. Those are the criticals for me.

 

@cdob: I'm not sure KernSafe will work, their webpage says it is only compatible with up to Windows 7. But it's worth trying anyway. What do you mean by plain boot? Like what I already have? I haven't encrypted yet, I don't think a floppy or other method will be necessary until I do that.

 

@Wonko: Can a floppy be avoided? It just sounds like extra fluff. I think it should be possible to use G4D or Clover to directly chainload a BC MBR/ISO, or just bootmgr if not encrypted.

 

Thanks!

Well, till now you are fine.

Of course if you have both the BOOTMGR and \boot\BCD (and code in the MBR and in the PBR that chainload those in BIOS mode) besides the \EFI\Microsoft\Boot\bootmgfw.efi and \EFI\Microsoft\Boot\BCD you need not the "floppy" (which is not a floppy it is a "floppy image", but it is just a small volume image)...


Wonko

I have a spare USB SSD which I'm not using, so instead of going the VM route, I cannibalized it instead.

 
How do you cannibalized it?
Did you disasembled the USB device? And assembled the HDD into the laptop?
Do you use USB boot?

Yes, Windows 10 dual boot BIOS and UEFI works.
The fun starts at third party encryption.

Current idea:
BIOS boot to Grub or grub4dos at the MBR:
chainload clover UEFI (there are clover bootable ISO), load UEFI windows
chainload the Bestcrypt MBR (the rescue ISO, or the extracted floppy image, or the MBR file directly)

Next step:
Still at win default MBR:
add Bestcrypt, create the rescue ISO at BIOS mode and at UEFI mode.
Can you boot the cd (ISO images)?

If this works so far, contiue at another boot loader.

The KernSafe disk driver works at Windows 10.
No, most likely it's not required at given task.

@cdob: The SSD is in a USB 3.0 enclosure. Grub2/Grub4DOS isn't currently installedvin the MBR. Right now Windows bootstrap code is there. The easiest way for me to boot clover is from a USB in legacy mode, then I can select 10's UEFI boot manager efi file. I've been successful in the past at installing Clover to my internal drive's EFI partition (by just creating a Clover USB then copying the files to internal partition), followed by extracting the internal drive's MBR and adding Clover code there. But as of late I haven't been successful in replicating this, since I now have MBR, but then I was using GPT. I know Clover must work with MBR because the USB it creates also uses MBR. I used cvad's BootDiskUtility.

 

The issue I'm going to have with BestCrypt is that it detects the boot mode Windows is using. So if it detects legacy then it will write to the MBR, if UEFI is detected then its' bootloader files will go in the EFI partition. It will not create both. So, should I start the encryption process in UEFI mode, or in legacy mode, is the question? I also noticed that BC keeps templates of the UEFI/legacy rescue/boot files in its' installed program folder. I can zip up a copy of the installed folder and upload it somewhere for inspection.

The issue I'm going to have with BestCrypt is that it detects the boot mode Windows is using. So if it detects legacy then it will write to the MBR, if UEFI is detected then its' bootloader files will go in the EFI partition. It will not create both. So, should I start the encryption process in UEFI mode, or in legacy mode, is the question?

Well, it's get nasty. Do both, one after another.

Backup the MBR and windows (dism ?).

At BIOS mode: install BestCrypt, crypt the disk. Can you create a rescue boot BIOS ISO?
Can you decrypt the disk? If not, then restore windows.
Restore the MBR.

At UEFI mode: install BestCrypt, crypt the disk. Can you create a rescue boot BIOS ISO?

Try:
boot the rescue UEFI ISO.
boot the rescue BIOS ISO.

I've made progress on this in the spare time I have, and I do believe that what I'm after is achievable. So far I've managed to plain boot 10 in UEFI and legacy, no issues there. And BestCrypt will encrypt and boot the C drive in UEFI despite it being on MBR. I haven't tried with encrypting in legacy mode, mostly because I can't figure out how to load the bcve_mbr.bin in Grub4DOS.

The snags I'm hitting so far:
1. The flags that are set, or not set, appear to interfere with the behavior of the BC application. Like for instance, it may complain that it's UEFI loader isn't initialized, despite a reboot for it to kick in. Or in the case of legacy, it complains about not being able to determine the boot/system partition. I played with setting/unsetting efi/boot flags in GParted, and got varying responses from the app. I think it uses standard Windows calls to determine the booting mode and where the boot partition is located.

Right now I have a basic but functional GRUB4DOS, I installed the MBR with BootIce, and got the latest stable zip from SourceForge. 10 loads fine in legacy with it, obviously it is bypassed in the case of native UEFI.

I'm wondering if there is a way to set/unset boot/efi flags in G4D, depending on which mode I want 10 to boot in.

Thanks!

So, I'm bored today with nothing to do, and with no forthcoming replies I decided to do an experiment:

 

Googling for "grub4dos boot flag" "and "grub4dos efi flag" doesn't seem to bring up any relevant results, except in relation to Linux and Gparted. As an alternative to asking how to modify flags with G4D, I instead decided to try and locate what portion of the disk these flags are stored in (written to), figuring that if the sectors can be written to on the fly by G4D at boot, then that would be better than changing them in Gparted. It must be stored somewhere when a flag is modified, either in firmware, or a partition or in the MBR (the latter is the correct answer). Legacy booting has very limited firmware capabilities, so I figured the change must be stored on disk.

 

I created an unformatted partition with no flags, then dd'ed a raw copy of that partition to a file. Then I set the efi flag on it, and dd'ed the partition again. The result is 2 files that are exactly the same size, and both have the same sha512 checksum. So the flag change must not be stored in a partition.

 

I then unset the flag again, dd'ed the disk's MBR to a file, reset the flag then dd'ed again. The result are 2 files of identical size.....but with different checksums! Just to be sure, I unset the flag again, then dd'ed the MBR to a file once more. The 1st and 3rd MBR files have the same checksum, which is proof enough to me that setting/unsetting flags writes changes to the MBR, and it alone. This may not be the case with GPT, since GPT is much newer and more advanced, and can make better use of firmware/hardware capabilities.

 

Now I just have to inspect the MBRs in a hex editor to figure out exactly which portion is changed (boot code, partition table, or disk signature). If G4D can write a specific sector(s) at boot, then flags can be added/removed at will, which will help to solve one of my issues with BestCrypt. I need the software GUI portion of the encryption to function as expected, which is clearly related to which flags are set, if it isn't working right then I can't do much of anything.

Right now I have a basic but functional GRUB4DOS, I installed the MBR with BootIce, and got the latest stable zip from SourceForge. 

Got the latest stable of WHAT from Sourceforge?

(certainly NOT the latest stable of either grub4dos or bootice, let alone bestcrypt )

 

Wonko

Now I just have to inspect the MBRs in a hex editor to figure out exactly which portion is changed (boot code, partition table, or disk signature).

Most likely it's the partition type 0xEF. It's defined at the UEFI Specifications http://www.uefi.org/...FI Spec 2_6.pdf

https://en.wikipedia.../Partition_type

Grub4dos can write the partition type.

I've made alot of progress via intense trial and error, but it seems I've hit a wall, so I decided the best bet would be to post a detailed topic on the Jetico support forums, to determine whether what I want to do is feasible. I'm not sure they will help but it's worth a shot.

I was able to boot 10 in either encrypted legacy or UEFI encrypted, but the issue occurs when attempting to swap modes. For the sake of brevity:

http://www.smokey-se...=337026.new#new

I posted a link back to this topic as well.

To answer the previous questions:
I was using a 2009 version of G4D from SourceForge. I'm now using a much newer build from 12-2017 (0.4.6a), from chenall's website.

I got the x64 build of BootIce from MajorGeeks.

Even if the encryption aspect doesnt work out, I did still at least manage to dual-boot 10 in both UEFI and legacy on MBR, hence the topic's title.

Well, if passing control to grub4dos is obtained through booting (BIOS) the grub4dos MBR (+hidden sectors) there is no real reason to have the EFI/FAT32 partition marked as "bootable".

 

Conversely, having the grub4dos MBR (+hidden sectors) installed is EXACTLY what was NOT suggested on this thread, because it may (not necessarily will) introduce a variation that most probably (please read as surely) the good Jetico guys never tested.

 

If you really want/need to go for a non-standard MBR, then you have less risks using the UMBR (that will load grub4dos just fine, with the limit that it will load it only from a "fixed" address) that only occupies part of the MBR, leaving the initial hidden sectors available (but allowing to actually place the grldr outside any volume/filesystem).

 

Wonko

I recently got a reply not too long ago, but I'm not sure what to make of it:

 

https://www.smokey-s...h-bcve/new/#new

 

Especially the part about "2 system partitions and one boot partition", and "you will need to have BCVE boot loader on both EFI and MBR partitions".

 

Can someone here possibly help me make some sense of it?

 

@Wonko: What makes you say that UMBR is better than G4D? How could making use of G4D screw with things? How else would I boot Windows in legacy mode, especially if I'm not using Microsoft's original Windows MBR? I can only think of one way, which is to make a G4D USB flash drive, then use that to chainload the bootmgr on the internal partition.

 

Thanks!

I never said it as "better", I said you will have less risks of conflicting with anything else.

 

A normal MBR is one sector in size.

It is followed normally by 62 or 2047 "unused" sectors (often called "hidden") before the beginning of first partition.

These "unused" sectors are normally nomen est omen "not used" by anything.

 

When you install grub4dos to the MBR you are actually writing to the MBR and the first 15 of the "unused" sector the grldr.mbr code (which looks for grlrdr, which is the actual grub4dos loader, on all available partitions/volumes).

 

Another program may use any of these sectors for *whatever* use, not necessarily Bestcrypt (which I am not familiar with), but a number of programs may use this (or that) sector to hold a backup of their own loader or bootsector or only as a status flag of some kind.

 

UMBR has exactly the same scope of grldr.mbr (loading the "main" grldr), with the following differences:

1) Advantage: it occupies ONLY the MBR (i.e. the code is only one sector long) so it has no risks to have conflicts with any software making use of the "hidden" sectors

2) Disadvantage: unike the grldr.mbr code that searches the grldr file (and can find it on any partition/volume, independently from the partition having the "active" or "boot" flag set) UMBR only points to a specified address where grldr resides, which implies that if you move the grldr address you will need to correct the address in the UMBR

3) Advantage: it is usually (since it directly points to the grldr file) faster in booting than grldr.mbr (not that it makes much difference)

4) Advantage: the grldr may reside *everywhere* on disk, including outside any of the partitions/volumes (it is an advantage because you can write the grldr to a small area outside any partition/volume with no risks of ever moving it, thus mitigating the Disadvantage in #2). 

 

Wonko