421 replies to this topic

[alacran]

There does not seem to be any pxe

 

You could try the suggestion from 2011whp mentioned on this post  perhaps Shivan didn't edited fine his embedded menu.

 

alacran

[steve6375]

Thanks, source files show no code  implemented for  pxe and ipxe commands.

But I was not asking about pxe/ipxe support. I was asking about the wimboot code which was originally part of the ipxe project and which can be called by grub2 to load wim files and boot to them (nothing to do with network/internet).

https://ipxe.org/wimboot

 

I get a 'kernel too old (0x0203 < 0x020b)' message with the ipxe wimboot binary.

 

a1ive ntloader does not seem to work with (0xff) devices mapped to ISOs and cannot inject files into the X: drive?

https://github.com/grub4dos/ntloader

Edited by steve6375, 25 July 2021 - 11:12 PM.

[alacran]

If no network/internet involved, you can use ntloader by a1ve which is useful to boot WIM files, it works on grub2, a1ve's grub2, and grub4dos (MBR and UEFI versions), see this post and 2 following.

 

EDIT: Look carefully to Advanced options on README.md, depending of your desired use, you could need to use them, but I haven't needed to use them so far to boot a PE WIM or boot/ramboot a VHD.

 

alacran

[alacran]

New UEFI version is: grub4dos-for_UEFI-2021-07-28.7z 976K,  no new features mentioned on ChangeLog_UEFI.txt, this .txt file remains same as on version grub4dos-for_UEFI-2021-07-23 (its English translation was attached to this post.).

 

But time out of embedded menu is now set back to 0, and also some other modifications, for more info see:

https://github.com/c...ba004400d8a97dd

 

New MBR version is: grub4dos-0.4.6a-2021-07-28.7z 564K

 

Reboot, typo on "commandline" fixed, and some other modifications, for more info see:

https://github.com/c...8d8dc45324733db

 

alacran

[wimb]

 

So I would expect my test computer to be securely dual-bootable to Windows 10/11 and Debian 10, with the latter's signed Grub2 for UEFI to be able to chainload our new Grub4DOS for UEFI, such that I could do my unsecure booting experiments with virtual disks, right? Which would be the menu entry for Grub2?

 

 

Multi-Boot in MBR BIOS mode with Windows Boot Manager using Boot folder on active FAT32 partition (3_M2_BOOT) allows:

- Boot with Windows 11 on GPT (partition 0_W11 of 1 TB SSD)

- Boot with Windows 10 in VHD FILEDISK located on GPT

- Boot with Windows 10 in VHD FILEDISK located on MBR partition 3_M2_W10

- Boot with PE from RAMDISK using Win10XPE boot.wim file

- Boot with Grub4dos - e.g. Linux ISO Or Linux in VHD as FILEDISK Or Mini-10x64.vhd from RAMDISK

- Boot with Grub2 grub\core.img launched from Grub4dos - e.g. KALI.vdi.vtoy - /grub/vdiskchain

- Grub2 can chainload with all Linux ISO and Linux in VHD and Win10 VHD options

 

Multi-Boot in UEFI Secure Boot mode with Grub2 in EFI folder on FAT32 partition (3_M2_BOOT) allows:

- Boot with Windows 11 on GPT (partition 0_W11) - after chainload with Windows Boot Manager

- Boot with Windows 10 in VHD FILEDISK located on GPT - after chainload with Windows Boot Manager

- Boot with Windows 10 in VHD FILEDISK located on MBR partition 3_M2_W10 - after chainload with Windows Boot Manager

- Boot with PE from RAMDISK using Win10XPE boot.wim file

- Grub2 can chainload UEFI Grub4dos with all  Win10 VHD booting from RAMDISK options

- Grub2 can chainload with all Linux ISO and Linux in VHD and Win10 VHD options - e.g. KALI.vdi.vtoy - /grub/vdiskchain

 

-  KALI Linux has 600 Forensic and Penetration Testing Tools and is based on Debian Linux

 

"Verouderd" is Dutch for Legacy = MBR BIOS Mode

 

MBR active FAT32 Boot drive is the most Universal Boot Drive with Boot and EFI folder and Grub4dos and Grub2 

 

as made with UEFI_MULTI and USB_FORMAT according to VHD_WIMBOOT PDF and allows:

 

MBR BIOS Mode == UEFI Secure Mode

== 

[Wonko the Sane]

"Verouderd" is Dutch for Legacy = MBR BIOS Mode

It is also seemingly much more offensive than "legacy" as it seemingly means mainly outdated, obsolete.

 

Wonko

[wimb]

It is also seemingly much more offensive than "legacy" as it seemingly means mainly outdated, obsolete.

 

 

Yes, you are right, "Verouderd" is a bad translation of "Legacy" 

[steve6375]

For booting VHD and WIM files, I use this batch file code (so far):

 

ISOC holds the full path of the ISO

#use ntloader
call :getdrv %ISOC%
uuid %drv% > nul
set UUID=%?_UUID%
set WW=%ISOC%
# get rid of device name
if "%WW:~0,1%"=="(" echo %WW% > (md)0x300+1 && cat --locate=/ --number=1 --length=14 (md)0x300+1 > nul &; call set WW=%^WW:~%?%,199% > nul
# get rid of spaces in filepath (spaces are "/ ") replace spaces with :
echo -e !BAT\nset*WW=%WW% > (md)0x300+1 ;; cat --locate=\x20 --replace=: (md)0x300+1 > nul ;; cat --locate=* --replace=\x20 (md)0x300+1 > nul ;; call (md)0x300+1
kernel (bd)/%grub%/efi_utils/ntloader uuid=%UUID% file=%WW%
initrd (bd)/%grub%/efi_utils/initrd.lz1
set UUID=
set drv=
set uuid=
boot

#ntloader options

#Enable Test Signing mode: kernel /ntloader uuid=%?% file=/xxx.vhd testmode=1
#Use the highest graphical resolution: kernel /ntloader uuid=%?% file=/xxx.wim hires=1
#Disable hardware abstraction layer (HAL) and kernel detection: kernel /ntloader uuid=%?% detecthal=0
#Load the Registry SYSTEM hive as a volatile hive (WinPE mode): kernel /ntloader uuid=%?% minint=1
#Disable the use of VGA modes: kernel /ntloader uuid=%?% novga=1
#Disable VESA BIOS calls: kernel /ntloader uuid=%?% novesa=1
#Configure Physical Address Extension (PAE): kernel /ntloader uuid=%?% pae=Enable|Disable|Default
#Configure Data Execution Prevention (DEP): kernel /ntloader uuid=%?% nx=OptIn|OptOut|AlwaysOff|AlwaysOn
#Set Windows load options: kernel /ntloader uuid=%?% file=/xxx.vhd loadopt=XXX
#Specify the path of winload.exe or winload.efi: kernel /ntloader uuid=%?% winload=/Windows/System32/winload.efi
#Specify system root: kernel /ntloader uuid=%?% file=/xxx.vhd sysroot=/Windows
#Boot Windows 7 (UEFI): kernel /ntloader uuid=%?% win7
#Hook UEFI SecureBoot variable (UEFI): kernel /ntloader uuid=%?% file=/xxx.vhd secureboot=off
#Change the boot logo (UEFI): kernel /ntloader uuid=%?% file=/xxx.vhd bgrt
#Disable debug messages: kernel /ntloader uuid=%?% file=/xxx.vhd quiet
#Text mode messages: kernel /ntloader uuid=%?% file=/xxx.vhd text
#Disable paging (BIOS): kernel /ntloader uuid=%?% file=/xxx.vhd linear
#pause: kernel /ntloader uuid=%?% file=/xxx.vhd pause

:getdrv
set drv=
set drv=%~d1
if "%drv%"=="()" set drv=(bd)
goto :eof

Notes:

The drive part  (hd0,0) or whatever is not passed in the ntloader file=  parameter, so it must be stripped

Spaces are replaced by : (colons)

?_UUID  is the same as ? and is destroyed by some subsequent commands such as cat and map.

 

ntloader supports 2 uefi boot protocols: uefi chainloader and linuxefi (kernel command in g4e)

so for grub4efi, kernel /ntloader can be used everywhere.

protocol        bios linux16   efi32 chainloader   efi32 linuxefi   efi64 chainloader    efi64 linuxefi
ntloader.i386        ✓                ✓                  ✓                ✕                    ✕
ntloader             ✓                ✕                  ✓                ✓                    ✓

Edited by steve6375, 16 August 2021 - 12:53 PM.

[JoeyBB]

Hello people of Reboot Pro,

 

Not sure if I'm posting this in the right section or under the right topic. Please move my post or point me in the right direction, I'm new here. 

 

I'm trying to achieve a W10 RAMDisk over UEFI.

With the help of this community, I was able to achieve a W10 RAMDisk as part of a Proof-of-Concept where I work. I was able to use WinNTSetup, BOOTICE, RMPrepUSB, VHD_WIMBOOT and a plethora of other tools since I started this PoC a few weeks ago. We got everything working properly over BIOS. We need to use a stripped version of Windows 10 as a shell around our JavaScript kiosk app, which is essentially a Chrome webbrowser in lockdown using NW.js. I was able to boot up this application over a W10 RAMDisk, using startup scripts and the Windows registry to further configure my 3.9GB VHD.

 

So, why am I here?

Well, once I started digging into GRUB4DOS for UEFI, things started to get a little sketchy and experimental... The guides and resources I had were no longer helpful. Since I'm on a Linux daily driver, I have to use many of the apps (like WinNTSetup and VHD_WIMBOOT) in Windows virtual machines. This is great, because that way I don't mess up any BCDs on main devices. 

 

Getting our app launched within a Windows RAMDisk was very challenging, because there isn't much to find online (other than from you guys ). I would not have been able to manage this without GRUB4DOS or the Reboot Pro community, so thank you guys for your hard work. However, now I'm trying to achieve the same thing over UEFI, because our client wants the entire product to run with Secure Boot...

 

Newer laptops sometimes come in UEFI-only mode, or with Secure Boot enabled by default. I'm trying to make our Windows 10 RAMDisk work on these types of devices. Currently, I am able to create a bootable USB, using 2 partitions (FAT32 + NTFS). The FAT32 partition is used with GRUB4DOS for UEFI and points to the VHD on the NTFS partition. I had to do this manually, because the USB_FORMAT tool isn't working for me. I've gotten to the point where GRUB4DOS loads after I enable UEFI on the machine. Everything works the same as with the BIOS RAMDisk, up until the VHD is loaded in RAM... Then I get an Error 17 from GRUB4DOS: "Cannot mount selected partition".

 

What am I doing wrong here?

[steve6375]

Type of vhd?
Size?
Partitions in vhd?
Menu used to boot vhd ?
Do any vhds work?
Presumably win10 UEFI64?

[wimb]

 

Newer laptops sometimes come in UEFI-only mode, or with Secure Boot enabled by default. I'm trying to make our Windows 10 RAMDisk work on these types of devices. Currently, I am able to create a bootable USB, using 2 partitions (FAT32 + NTFS). The FAT32 partition is used with GRUB4DOS for UEFI and points to the VHD on the NTFS partition. I had to do this manually, because the USB_FORMAT tool isn't working for me. I've gotten to the point where GRUB4DOS loads after I enable UEFI on the machine. Everything works the same as with the BIOS RAMDisk, up until the VHD is loaded in RAM... Then I get an Error 17 from GRUB4DOS: "Cannot mount selected partition".

 

What am I doing wrong here?

 

You should first follow the working procedure as described in VHD_WIMBOOT PDF page 1 and use computer running Win 10x64 Operating System

 

Tell precisely at what step you have a problem and give detailed description of the problem and illustrate it with ScreenShots

 

[JoeyBB]

Type of vhd?
Size?
Partitions in vhd?
Menu used to boot vhd ?
Do any vhds work?
Presumably win10 UEFI64?

Type of vhd?: FIXED
Size?: 3,9 GB
Partitions in vhd? (2, FAT32 boot part + NTFS with VHD)
Menu used to boot vhd ?

 

title SVBus Windows Prototype RAMDisk (UEFI)

find --set-root --ignore-floppies /W10.vhd

map --heads=2 --sectors-per-track=18 --mem (md)0x800+4 (99)

map --mem /W10.vhd (hd0)

map --hook

rootnoverify (hd1,0)

chainloader /EFI/Boot/BOOTX64.EFI

map --status

Do any vhds work?: Yes, everything works in Legacy mode. My difficulty is getting it working for UEFI.
Presumably win10 UEFI64?: Correct. I stripped an Windows LTSC (IoT) using MSMG Toolkit.

 

VHD's boot, VHD RAMDisks boot, but I want them over UEFI because we are trying to achieve Secure Boot RAMDisks.

[steve6375]

Can you double-check that the menu you posted is correct?

Why mount the vhd as hd0 and then try to boot from hd1 ???

P.S. map --hook is not needed or used in grub4efi.

What is the purpose of the map --heads=2 --sectors-per-track=18 --mem (md)0x800+4 (99)  line?? Normally, this is used when writing a string to memory for a later driver to load it (like firadisk), but no string is written to (99)?

 

also grub4efi can use ntloader to directly boot wim files  and VHD files. Maybe you could try that?

 

 

Leaving aside the issue of booting UEFI VHDs using grub4efi,

How do you intend to get Secure Boot working since grub4efi is not signed so it will never directly secure boot.

 

There are various ways to get it to Secure Boot but these rely on you adding a 'whitelisted' key using MokManager, or using a signed shim such as the Kaspersky shim which is often blocked/blacklisted by Windows adding an entry into the dbX UEFI BIOS blacklist database.

[alacran]

Type of vhd?: FIXED
Size?: 3,9 GB
Partitions in vhd? (2, FAT32 boot part + NTFS with VHD)
Menu used to boot vhd ?

Do any vhds work?: Yes, everything works in Legacy mode. My difficulty is getting it working for UEFI.
Presumably win10 UEFI64?: Correct. I stripped an Windows LTSC (IoT) using MSMG Toolkit.

 

VHD's boot, VHD RAMDisks boot, but I want them over UEFI because we are trying to achieve Secure Boot RAMDisks.

 

Grub4dos for UEFI can't boot directly if Secure Boot is enabled, as steve6375 said in previous post.

 

So for now disable Secure Boot to run your first tests.

 

Is part remarked in blue right?

 

Because as it is now it means:

 

Your VHD has a first FAT-32 partition and a second NTFS partition that holds inside it a second VHD, and that is not the right way to make your VHD.

 

If you made your VHD that way, that could answer steve6375 question:

 

Why mount the vhd as hd0 and then try to boot from hd1 ???

 

The right partition scheme of a two partitions VHD is:

 

A MBR initialized VHD having a (64 to 100 MB) first primary active FAT-32 partition for MBR/CSM + UEFI boot files/folders, and a second NTFS primary partition where the Win OS is located.

 

Assuming you already have SVBus installed and you edited properly your internal and external BCD files.

 

On the USB FAT-32 partition:

 

UEFI menu.lst default location is /EFI/grub/menu.lst

 

MS bootmgfw.efi located into /EFI/Microsoft/Boot/bootmgfw.efi can be renamed to bootx64_win.efi

 

BOOTX64.EFI from grub4dos for UEFI (G4E) can be renamed and copied to /EFI/Microsoft/Boot/bootmgfw.efi, to boot from it, but Secure Boot has to be disabled.

 

Following an example of commands to Ramboot a 2 partitions VHD (adapt to your needs):

 

 

title Boot /Mini-10x64.vhd - UEFI Grub4dos  SVBus  RAMDISK  - 2 GB
find --set-root /Mini-10x64.vhd
map --mem --top /Mini-10x64.vhd (hd)
chainloader (hd-1)

 

It is also possible make a NTFS single partition VHD, but it requires additional auxiliary files, so to make things easy for a first test use the 2 partitions VHD for now.

 

All this can be made almost automatically with wimb programs, just follow his instructions on this post.

 

alacran

[wimb]

Only that Grub2 which I used here for chainloading "Grub4EFI" obviously does not include a Linux kernel or any other code that is responsive to Secure Boot mode. I understand the Debian Wiki such that only the first-stage bootloader Shim, the "root of trust", then kills the next binary to be chainloaded if that file is not signed. But that's not the case for openSUSE's Grub2, and Shim neither knows nor cares what Grub2 will do later.

 

 

I have installed openSUSE Tumbleweed on GPT partition and can boot openSUSE Linux in UEFI Secure mode.

 

However, chainload of UEFI Grub4dos (Grub4EFI) fails in UEFI Secure mode with the message: bad shim signature

 

So indeed the secure boot chain is broken as expected already by alacran

[alacran]

I really don't feel any happy because I was right.

 

This is one of those cases were you feel it was preferable to be wrong in your evaluation of something.

 

Bad news as that could have being another alternative, even if a few complicated and very long procedure was necessary.

 

And this approach could had opened the possibility to use a smaller derived distro to achieve the desired result. Or to find a way to transport the shim + grub.cfg of Devian or other distro to chainload G4E.

 

alacran

[alacran]

@ wimb

 

I hope you haven't deleted your openSUSE installation, following is part of my quote on this post , there is mentioned that you can create your own signed key and certificate:

 

 

Loading kernel modules that are not signed by a trusted key. By default, this will block out-of-tree modules including DKMS-managed drivers. However, you can create your own signing key for modules and add its certificate to the trusted list using MOK.

 

From MOK page:

 

 

MOK - Machine Owner Key

 

Generalities

A key part of the shim design is to allow users to control their own systems. The distro CA key is built in to the shim binary itself, but there is also an extra database of keys that can be managed by the user, the so-called Machine Owner Key (MOK for short).

Keys can be added and removed in the MOK list by the user, entirely separate from the distro CA key. The mokutil utility can be used to help manage the keys here from Linux userland, but changes to the MOK keys may only be confirmed directly from the console at boot time. This removes the risk of userland malware potentially enrolling new keys and therefore bypassing the entire point of SB.

 

This could be a way to make G4E comply the Secure Boot chain when chainloaded from Devian grub.cfg

 

alacran

[wimb]

I hope you haven't deleted your openSUSE installation, following is part of my quote on this post , there is mentioned that you can create your own signing key and certificates:

 

From MOK page:

 

This could be a way to make G4E meet the Secure Boot chain when chainloaded from Devian grub.cfg

 

 

The solution by using mokutil in your own Linux environment is rather complicated and not universal.

 

It will be better when UEFI Grub4dos is signed may be in future and otherwise best is to switch off Secure Boot on your own machine.

 

In any case we have already the good working solution for UEFI Secure support for Booting from USB on foreign machine

 

by using  Super UEFIinSecureBoot Disk v3 - More Info on UEFI Secure booting Grub2

[steve6375]

grub4efi will never be signed unless it's features are severely restricted  - e.g. dd, partnew, write, fat utility, unsigned module loading, running unsigned grub4efi utilities, etc.

 

MokManager/MokUtil does not work on some/many systems.

 

Easy2Boot uses the Kaspersky shim which means there is no requirement to use MOKManager/MokUtil to add a key and it Secure boots to any EFI bootloader.

 

UEFI BIOS -> /EFI/BOOT/BOOTX64.efi (mini grub2 signed Kaspersky shim) -> /boot/grub/grub.cfg (loads policy.mod) ->  (chainload any efi file - e.g. grubfmx64.efi or grub4efi64.efi)

 

The only issue is that Windows Update adds a key entry into the UEFI BIOS DBx blacklist which prevents the shim from being loaded if secure boot is enabled. The DBx list can be easily cleared by going into the UEFI BIOS Setup menu however.

 

The other issue is that a few UEFI BIOSes will not run the Kaspersky shim even if Secure Boot is disabled (no idea why not!).

 

AFAIK there is no 'perfect' answer for booting unsigned code in Secure Boot mode... :-(

[wimb]

 

The only issue is that Windows Update adds a key entry into the UEFI BIOS DBx blacklist which prevents the shim from being loaded if secure boot is enabled. The DBx list can be easily cleared by going into the UEFI BIOS Setup menu however.

 

 

That means UEFI Secure booting from USB on foreign machine requires to clear in UEFI BIOS the DBx key list, which I would not like to do on foreign machine .....

 

I agree with you: there is no 'perfect' answer for booting unsigned code in Secure Boot mode

 

It is a pity that they make booting so complicated.

 

At the same time security problems will be never solved completely, whereas reliability decreases  

[alacran]

Secure Boot is the name used to undercover the desire of one company (and his associates) to control the PC marked, and with the pretext of security or safety make big money cerifiying all drivers and software you can run on a PC.

Apple did same thing on their products, and Google also did same thing on Android and both make big money from their Certified online stores. What so far has not being a so good business for MS.

It is just as Al Capone and all gansters used to make money on old times selling "protection", nothing new.

And in fact SB dont give any additional security of safety, every day are more new cases of Ransomware.

 

alacran

[Gerolf]

I have installed openSUSE Tumbleweed on GPT partition and can boot openSUSE Linux in UEFI Secure mode.

However, chainload of UEFI Grub4dos (Grub4EFI) fails in UEFI Secure mode with the message: bad shim signature

 

Well, it still works on my test machine, as described. I understand this error message you get is produced by Grub2 (not shim), which means Grub2 must have been modified to be secure-boot sensitive. I had expected this would not happen to open-source software, but in the Habr post you digged up it is clearly mentioned:

 

To prevent signed bootloader abuse with malicious intentions, Red Hat created patches for GRUB2 that block «dangerous» functions when Secure Boot is enabled: insmod/rmmod, appleloader, linux (replaced by linuxefi), multiboot, xnu, memrw, iorw. The chainloader module, which loads arbitrary .efi-files, introduced its own custom internal .efi (PE) loader without using the UEFI LoadImage/StartImage functions, as well as the validation code of the loaded files via shim, in order to preserve the ability to load files trusted by shim but not trusted in terms of UEFI.

 

I was asked to share openSUSE's shim.efi so that it would not be necessary to download the whole distro, but to my surprise, I could not immediately find the file in the Tumbleweed ISO, nor in some of the contained files I opened as archive or image. If this shim.efi is generated during installation, it might as well contain e.g. a checksum about the individual motherboard so that it would not be portable to another machine.

[alacran]

IMHO Gerolf is using for his tests a very old Lenovo laptop from 2013 and wimb is using a more modern Asus MB, the very different versions in the UEFI firmware, (based on very different versions of UEFI specs available at the time when each of them were builded), could explain the difference in the findings.

 

SB was included in the specs in 2013 perhaps the laptop firmware made in a hurry by Lenovo is more permissive. bad implemented or the SB option in it is fake, that OEM is not recognized for being trustable and was involved in the Superfish big scandal.

 

But nevertheless wimb's findings makes the approach not valid in modern cases, and it becomes a dubious option to be recommend for general use.

 

alacran

[steve6375]

Latest grub4efi

https://github.com/c...es/tag/for_UEFI

 

This includes the new debug command

debug ctrl-c-trap=0

which disables the checking for the pressing of ctrl-c after each line of a grub4efi batch file is run.

Normally, under grub4dos and grub4efi  the user can press Ctrl-c to abort the batch file.

Under UEFI, the 'check key' UEFI function is very slow (approx 100ms-300ms) so when running a batch file which has lots of loops inside, it can take many seconds to execute because after each line, check-key is called.

 

The UEFI check-key function also absorbs any key press which is in the keyboard buffer, so the following code does not work in a batch file normally:

echo Press a key
# wait 3 seconds for a user to press a key
call Fn.73 3
#get the key press (if any)
call Fn.20
#get value
set /A key=%@retval%
#check for a key (y)
if %key%==0x79 echo y was pressed
#note that if no key was pressed grub4dos returns -1, but grub4efi returns 0xFFFFFFFF which is NOT -1 !!!
if %key:~-8,8%==0xFFFFFFFF echo no key was pressed

You can put the two commands onto one line to prevent problem of the key press being absorbed after each line is executed.

call Fn. 73 .3 ;; call Fn.20

or you can disable the ctrl.c checking using the debug ctrl-c-trap=0 command.

 

 

[wimb]

Well, it still works on my test machine, as described. I understand this error message you get is produced by Grub2 (not shim), which means Grub2 must have been modified to be secure-boot sensitive. I had expected this would not happen to open-source software, but in the Habr post you digged up it is clearly mentioned:

 

 

You can easily test if Grub2 has been modified to be secure-boot sensitive by doing a reinstall on your test machine using fresh downloaded openSUSE Tumbleweed 

 

In case chainload of UEFI Grub4dos now fails for UEFI Secure Boot then you have a proof of your statement.

 

But most likely it is your special machine that allows to chainload UEFI Grub4dos in UEFI Secure Boot mode.

 

In any case there is already proof that your openSUSE Linux method cannot be advised as solution for UEFI Secure Boot of UEFI Grub4dos

 

This Lenovo laptop was sold as new, for little money, and without Windows, by a renowned German notebook shop site. It came with pre-installed FreeDOS, giving the out-of-box experience of a 1980s IBM AT.