64bit Program to capture disk MBR?

[Tripredacus]

I'm working on a project to port an old deployment method to a new one and have run into an issue. The old method would put Windows install media in a single partition disk and boot from it. Ghost was used to put an MBR onto that disk. To eliminate Ghost I would need to recreate the situation without having the install media on the disk (I have an idea) or to get the MBR onto the disk using another method.

Terabyte Unlimited's MBRWORK is 32bit only and does not work on modern WinPE. I have not tested their MBR.EXE yet but I am hoping that it will work. For that there is a 64bit binary available.

What are some 64bit programs that can capture the MBR from a disk?

Requirements are that the program be portable such as not require extra stuff like .net framework or whatever.

If there is something different than MBR.EXE to apply MBR to a disk, in 64bit, same requirement but would require command line as well.

[jaclaz]

Never tried it (as I am 32 bit only) but dd for Windows has a 64 bit release:

http://www.chrysocome.net/download

http://www.chrysocome.net/downloads/ddrelease64.exe

jaclaz

[alacran]

@Tripredacus

For Backup/Restore and also install new MBR to hard disks you may use BootIce, there is a 32 and a 64 bits version. Totally portable (runs on WinPE x86 and x64).  Also can be used in Commandline.

Edited August 5, 2018 by alacran
Typo

[Tripredacus]

DD Release doesn't seem to work properly in WinPE. It just shows the copyright info in the CMD and doesn't return to a prompt or show error info, nor open a GUI of any sort.

Bootice seems to work fine, however my requirements have totally changed. I no longer need to capture/write an MBR, instead now something to change EFI boot entries. Bootice can do this in the GUI but not in the cmdline. :\

[jaclaz]

I cannot test it, but of course (being a CLI tool) it won't have any GUI, and being a port a total rewrite of dd it will default to standard input if you do not provide parameters to it (like "normal" dd).

Try in it (in an opened command prompt):

dd --list

and/or any command as documented for the 32 bit version:

http://www.chrysocome.net/dd

About the (stupid) EFI/UEFI stuff, is Commercial software OK?

https://www.easyuefi.com/index-us.html

But what does BCDboot/BCDEDIT miss? (I mean don't you just deploy a (stupid) Windows on some (stupid) UEFI hardware?) 

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-7/dd744347(v=ws.10)

https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/bcd-system-store-settings-for-uefi

Maybe you could explain/express what actually is your current procedure/what you actually need done?

jaclaz

[Tripredacus]

18 hours ago, jaclaz said:

But what does BCDboot/BCDEDIT miss? (I mean don't you just deploy a (stupid) Windows on some (stupid) UEFI hardware?)

BCDboot, when used, writes two names by default. They are "Windows Boot Manager" and it writes it into the BCD file and into the NVRAM, which is what BootIce calls EFI Boot Entries. The different locations can show data in different places. In BCD, this is usually only visible if you have multiple boot entries and you have it set to show boot menu. The name of the OS "Windows Boot Manager" is the friendly name and you can use BCDEdit to change it to something nicer.

The name in NVRAM is visible in a board's one-time boot menu, or in the boot order section in the "BIOS" setup. This is the name I need to change. This name can partially be changed with BootIce, using the manual steps. In this particular boot menu, it would appear as

Windows Boot Manager [firmware device name]

Whereas I can change the friendly name to anything, the "firmware device name" is basically what the motherboard shows the device it is sitting on as. Usually a hard drive model number, read during enumeration at POST. When Ghost was used, this entry in the boot menu would have just a name and no device. Doing it without Ghost will result in a boot entry similar to what is in the codebox.

I will still look at the MBR of a disk after applying the Ghost image, perhaps that will be the way to solve this issue.

[jaclaz]

Well, I still don't understand.

If you want to edit an entry in NVRAM the MBR (which is actually a protective MBR in UEFI) has nothing to do with that.

The board is acting strangely it seems I have to post opne line at the time and edit the post otherwise it throws an error.

When you use (if you use it) the command:

(see attached file, the stupid board software doesnt like *something* in the contents)

 

bcdedit_comment.txt

Edited August 7, 2018 by jaclaz

[Tripredacus]

20 hours ago, jaclaz said:

Well, I still don't understand.

If you want to edit an entry in NVRAM the MBR (which is actually a protective MBR in UEFI) has nothing to do with that.

well, as I put "however my requirements have totally changed"

Regarding your attachment, BCDBoot writes into the NVRAM as well as creating the BCD, which is a physical file on the disk. BCDEdit only makes changes to the BCD file, and does not make changes to the NVRAM. BCDBoot does not have (at least, documented) switches to write anything other than what it writes by default into the NVRAM.

I have found that bcfg from EFI Shell can write/overwrite a friendly name on a boot entry, and remove the device designation. However this is an extra step and it would really be nice if it could be done in WinPE to save a few manual steps.

https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#bcfg

[cdob]

2 hours ago, Tripredacus said:

BCDEdit only makes changes to the BCD file, and does not make changes to the NVRAM. BCDBoot does not have (at least, documented) switches to write anything other than what it writes by default into the NVRAM.

Can you check this at a machine?

I get at Win 10, VMware UEFI boot:

bcdedit /set  {bootmgr} description "NVRAM run \EFI\Microsoft\Boot\bootmgfw.efi"

The VMware nvram file contains the unicode string "NVRAM run \EFI\Microsoft\Boot\bootmgfw.efi".
UEFI boot selection shows ths string too.

Bcdedit does write to UEFI NVRAM.

 

Can you clarify your project?
A default windows installtion dosn't set the [firmware device name].
Which part sets the [firmware device name]?
Or does the motherboard add the [firmware device name] on the fly?

[jaclaz]

22 minutes ago, cdob said:

Bcdedit does write to UEFI NVRAM.

Yep.

jaclaz

[Tripredacus]

21 hours ago, cdob said:

Can you check this at a machine?

I get at Win 10, VMware UEFI boot:

bcdedit /set  {bootmgr} description "NVRAM run \EFI\Microsoft\Boot\bootmgfw.efi"

The VMware nvram file contains the unicode string "NVRAM run \EFI\Microsoft\Boot\bootmgfw.efi".
UEFI boot selection shows ths string too.

Bcdedit does write to UEFI NVRAM.

 

Can you clarify your project?
A default windows installtion dosn't set the [firmware device name].
Which part sets the [firmware device name]?
Or does the motherboard add the [firmware device name] on the fly?

It was already checked. I had not considered the NVRAM initially, I only knew about the descriptions in BCD. I knew in the one-time boot menu, the friendly name displayed there was "Windows Boot Manager" and knew that this was a value for {bootmgr} in BCD. So I had gone and changed that friendly name to what it was supposed to be (let's say "test" for these purposes), then rebooted and the one-time boot menu still showed Windows Boot Manager.

This was confirmed on an additional run, of running BCDboot, then view UEFI Boot entries with BootIce, then run BCDEdit to change the name, reboot, run BootIce and it showed no change. I then changed the UEFI boot entry manually with BootIce, and then the name was correct in the boot menu.

My project was to take an outdated imaging process, totally figure out what was being done and implement it into our existing system. The original process involved Ghost being used to write an MBR and set partition ID, then deploy a Windows DVD based install to a "disk" be able to hide it and get it to boot, etc. Changing what was deployed (booting WinPE instead of a WinPE ISO on SATA) was what allowed me to get rid of Ghost and the requirement of using the MBR. It seems like a short time to change my mind in a forum thread, but to be real I came into here to ask when I had no ideas left, and you know how that often works out.

Not sure where the device name comes from. I'm sure it is enumerated by the board firmware itself. Every board gets that from somewhere, even if you boot a USB key on a board, in the boot menu it has some sort of name for it.

[jaclaz]

Well, if you create a new BCD and import it, it should normally write to NVRAM.

My guess is that not all UEFI/NVRAM behave the same.

 

You could try with Powershell and the WMI provider:

https://www.codeproject.com/Articles/833655/Modify-Windows-BCD-using-Powershell

https://docs.microsoft.com/en-us/previous-versions/windows/desktop/bcd/importstorewithflags-bcdstore

jaclaz 

 

Edited August 9, 2018 by jaclaz