UEFI Bootmgr Wipe Ideas

Hi guys!

I'm trying to come up with a way to wipe the MBR/GPT of all the drives within a system booting only to UEFI Secure Boot, without CSM. I know I can change in UEFI the settings and enable CSM but I need it to work this way.

I have a USB drive, formatted with FAT32, bootmgr, copied boot and efi folders. Tested it and boots fine in BIOS and UEFI. But now I'm looking for a way to also do a wipe of mbr/gpt of every existing disk in the system.

Here's the way i'm thinking:

UEFI -> bootmgr -> wipe command

or something like this

UEFI -> bootmgr -> very small winpe.wim -> wipe command

Is there any possibility of running a command via bootmgr, without loading a .wim image, that can kill the partition table?

I would not prefer loading a full wim due the delay of loading the image. Something very similar to what Wonko posted over this thread http://reboot.pro/to...an/#entry194793but something that will work with bootmgr.

Thank you

Hi,

Grub4dos can be chained from bootmgr : what dont do you stick to what Wonko already posted ?

Regards,

Erwan

Well, to be picky what Wonko posted there works fine with bootmgr, only it won't work with bootmgr.efi (which is what you want to use).

(EFI/UEFI don't use bootmgr).

Grub4dos won't work in EFI/UEFI.

The idea there was to load (through BIOS) a very minimal OS (which in this case is grub4dos) capable of wiping a single sector (or a few of them) via direct disk access.

You can do the same (still in BIOS) with a DOS and DEBUG.

Now, EFI/UEFI is (in theory) already a very basic OS, in practice it seems like noone wrote a EFI program capable of having direct disk access and wiping one or more sectors.

In any case (rather obviously) bootmgr.efi is not the "right" approach, maybe GRUB2 would do, but you asked, besides "EFI/UEFI only" also SecureBoot, and I really doubt that anyone is going to go through the complications of SecureBoot for somethinglike that.

IMHO you'd better find a way to have a minimal PE (and wait a little bit for it to load) or manage to use a mini-mini Linux distro (which might or might not allow SecureBoot).

Wonko

Ah correct, had forgotten that there is no grub4dos for EFI...

A small winpe is probably the easiest then.

If scripted / automated thus, I would still seek some user interfaction ("yes, sure?/no") as wiping datas is not something light.

Regards,

Erwan

I agree with winpe. But I just find the original one, of 400MB, to be of extremely large size for such a simple operation.

A small hex editor would suffice for this. Just to kill the first 510 bytes off every drive.

Would a DOS floppy work? bootmgr.efi to chainload a DOS floppy/wim image?

You can easily generate a winpe below 200mb.

Have a look at QuickPE in my signature.

I dont believe you can chainload dos/freedos from UEFI.

Would a DOS floppy work? bootmgr.efi to chainload a DOS floppy/wim image?

Of course not, DOS needs BIOS services (just like grub4dos).

As said, EFI in itself can be compared to a minimal OS (not unlike what DOS or grub4dos represent in BIOS environment) but:

http://www.rodsbooks...fi-programming/

 

Tech-savvy individuals know the Extensible Firmware Interface (EFI) and its newer variant, the Unified EFI (UEFI) as a replacement for the older Basic Input/Output System (BIOS) on PCs and other computers. What you may not be aware of is that EFI is a complex software environment, comparable in size and features to a simple OS such as DOS. As such, EFI can host a variety of programs—but those programs can't spring into existence fully-formed, like Athena from Zeus' head. Rather, they must be written by individuals.

For some reasons no programmer seemingly writes them programs (with the notable exception of our friend Akeo, Author of Rufus):
http://pete.akeo.ie/...ions-using.html

EFI disk utilities (including a UEFI diskpart) do exist:

https://firmwaresecu...disk-utilities/
http://www.intel.com...ee_diskutil.htm

so it is clear the EFI native can have direct disk access alright, but having them work/compile, actually make them run, and then modify them to wipe disk sectors AND having them work on *any* hardware and with SecureBoot enabled (if applicable) is - I believe - far from trivial.

Wonko

I downloaded the Intel EFI Disk Utilities. Copied diskpart.efi to USB stick and created a new entry in the EFI bcd store.

The error output is:

The application or operating system couldn't be loaded because a required file is missing or contains errors.

File:\EFI\Microsoft\Boot\diskpart.efi

Error code: 0xc0000007b

I don't get why it outputs this error. The paths are all correct, boot device is correct.

Sure, that error is perfectly normal
It cannot be chainloaded from the BCD, of course, that is written to chainload either a Winload.exe or a bootsector.
Though it is highly doubtful that the EFI diskpart will actually work on current EFI/UEFI, it is an internal EFI command.
You (maybe) can run it through the EFI shell (that is IF you have one and IF you can reach it, etc.).


Wonko

But BCD also loads memtest.efi, as a recovery application. I figured it is capable of also chainloading applications.

But BCD also loads memtest.efi, as a recovery application. I figured it is capable of also chainloading applications.

Well, you tried it, good , but it doesn't work, which was largely expected, as I tried to tell you.

The MS Memtest is most probably a tool specially crafted for being loaded by bootmgr.efi.

You tried it but it didn't work , don't be too surprised by it, at least you tried .

Maybe you were confused (if you checked the releasenote.txt) by the:

The pre-built binaries can be found in \binaries\ia32, \binaries\x64 and

\binaries\ipf, respectively.

To use the utilities, copy the binaries folder into a floppy or USB disk and
then mount the disk on the target. DISKPART can be invoked from the boot manager
directly because it is not a shell application. EFIFMT and EFICHK need to run
under the EFI Shell environment.

Here the boot manager is not bootmgr.efi it is the EFI boot manager, see:
https://www.happyass...ally-work-then/

Provided that it works, the diskpart tool seemingly has a "CmdClean" that can wipe "ALL" (DO NOT even THINK of using it, it will take AGES to wipe a whole disk) or just the first and last Mb of the disk.

As a side note, and as a reminder, the GPT MBR and partition table is mirrored at the end of the disk, so it is advised to wipe both the "main one" at the beginning of the disk and the "mirrror" at the end.

Wonko

if you haven't yet looked more at "reFind" (http://www.rodsbooks.com/refind/) the author of that fork also wrote a multiple purpose gpt version of fdisk, http://www.rodsbooks.com/gdisk/ that may provide some clues to help you along.  It also has a script drive variant...  See http://www.rodsbooks...alkthrough.html

It has a "zap" option...

Note: refind is a full boot manqager, and can provide some limited scripting as part of a boot manager entry - but as Wonko said, it all depends uses the efi "shell" to do this work. 

So, it probably needs something like this...

Totally automatic...

• UEFI -> UEFI boot manager of some sort -> An entry that runs the efi "shell ( shell.efi) running commands to drive something  to do the work (like sgdisk).

Or manually...

• UEFU -> UEFi boot manager (like refind that allows selecting the shell) -> run the gdisk.efi to do things interactively.

Scott

Edited by sbaeder, 10 July 2016 - 08:35 PM.

I downloaded the iso image of reFind and it freezes my boot menu for some reason. 

I'll do some more research on it.

Sgdisk is not an EFI executable. 

It is a Linux/BSD (but also windows though for some reasons is not distributed as pre-compiled binary for windows) program.

I.e. in any case an Operating System environment is needed to run those.

The EFI diskpart is instead intended to be run directly from the EFI boot manager (not from the EFI shell) so it might (or it might not) be executable by a boot manager (though not necessarily the Windows BOOTMGR.efi), though more likely it needs to be modified and recompiled, and again Alexander Ceed's request wasn't only for EFI/UEFI but also with SecureBoot in it, which is a further complication.

The fastest solution for UEFI and SecureBoot will probably be a very small Linux something though again the issues with SecureBoot may prove to be difficult to solve. 

Wonko

I was thinking if this would be possible:

Using an autounattend.xml inside the root of an windows 8 setup iso:

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
  <settings pass="windowsPE">
    <component name="Microsoft-Windows-International-Core-WinPE" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <SetupUILanguage>
        <UILanguage>en-US</UILanguage>
      </SetupUILanguage>
      <InputLocale>1033:00000409</InputLocale>
      <SystemLocale>en-US</SystemLocale>
      <UILanguage>en-US</UILanguage>
      <UserLocale>en-US</UserLocale>
    </component>
    <component name="Microsoft-Windows-International-Core-WinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <SetupUILanguage>
        <UILanguage>en-US</UILanguage>
      </SetupUILanguage>
      <InputLocale>1033:00000409</InputLocale>
      <SystemLocale>en-US</SystemLocale>
      <UILanguage>en-US</UILanguage>
      <UserLocale>en-US</UserLocale>
    </component>
    <component name="Microsoft-Windows-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <Diagnostics>
        <OptIn>false</OptIn>
      </Diagnostics>
      <DiskConfiguration>
        <WillShowUI>OnError</WillShowUI>
        <Disk wcm:action="add">
          <DiskID>0</DiskID>
          <WillWipeDisk>true</WillWipeDisk>
        </Disk>
        <Disk wcm:action="add">
          <DiskID>1</DiskID>
          <WillWipeDisk>true</WillWipeDisk>
        </Disk>
      </DiskConfiguration>
    </component>
    <component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <Diagnostics>
        <OptIn>false</OptIn>
      </Diagnostics>
      <DiskConfiguration>
        <WillShowUI>OnError</WillShowUI>
        <Disk wcm:action="add">
          <DiskID>0</DiskID>
          <WillWipeDisk>true</WillWipeDisk>
        </Disk>
        <Disk wcm:action="add">
          <DiskID>1</DiskID>
          <WillWipeDisk>true</WillWipeDisk>
        </Disk>
      </DiskConfiguration>
    </component>
  </settings>
</unattend>

And removing everything from the iso except boot.wim. Theoretically it will load the boot.wim, read unattend.xml, wipe all drives, reboot on error.

It's not pretty but I'm guessing it will work. I'll test it tomorrow.

If you are to use the boot.wim from an install dvd, you would better off add a few bytes to stuff in a script and call it from winpeshl.ini.

Cleaner; safer, more flexible ...

Anyway I don't think it would be faster than booting a Mini-Linux targeted to that, but yes, a batch called by WinPEshl.ini seems by far more flexible and controllable.

To me (and personally of course) the sheer idea of having something that boots and wipes all disks MBR/GPT tables is a perfect recipe for disaster.

I would want double (and triple) checks and explicit user confirmation (and BTW OP already got burned alright by the original grub4dos menu.lst entry):

http://reboot.pro/to...-dban/?p=195345

Still the "beginning of it all" was - unless I am mistaken - because Dban was too slow, but one could have a modified Dban (since it is already smallish and quickly booted) and run the mentioned sgdisk or a "normal" set of dd commands, I believe that booting a minimal Linux will be faster than a minimal PE 3.x and later

Wonko

To me (and personally of course) the sheer idea of having something that boots and wipes all disks MBR/GPT tables is a perfect recipe for disaster.

 

 

Yes, you are perfectly right Wonko. I got burned with that but was only because I set the Wipe Entry to be the default. I was testing something at work and wanted to ease my work.

Now, I have 2 prompts for that entry with y/n confirmation and is placed in the middle of the list.

I want to build this thing because at work we get many new laptops with this new UEFI standard. the problem is that we cannot enable legacy mode with CSM if the OS exists. These come preinstalled with Windows 10, and for some reason, when changing the legacy setting in UEFI, it does not save the change. Multi tries, save the new setting, upon restart, it does not change. But a wipe of the OS will do the trick, i tested this.

Which is why I need this.

Still the "beginning of it all" was - unless I am mistaken - because Dban was too slow, but one could have a modified Dban (since it is already smallish and quickly booted) and run the mentioned sgdisk or a "normal" set of dd commands

 

I did not use dd but I did set the bootloader to quick. I'm not that technical with linux, unfortunatelly.

I believe that booting a minimal Linux will be faster than a minimal PE 3.x and later

 

Agreed. But we don't know if it works. I know for certain that windows 8+ is able to boot through any UEFI. reFind freezes the boot process and is linux-based.

Well , all in all it is now then (related to UEFI) not anymore "the most convenient or faster", but actually the "only thing that works", and still instead of "unatttended.xml" I would use a "proper batch".

Since you MUST be attending the thingy  (as you actually want a confirmation, to avid the risk of wiping something that you may want to regret) it needs not to be in any "auto-start file" you type the batch name in the cmd windows and that counts as confirmation of your intention to wipe.

And - still - I would try using gdisk or sgdisk or  a simple batch using a dd or dd like tool given this recent report by Akeo about a bug in diskpart (related to stupid 10, but maybe same in previous versions of the OS ):
http://reboot.pro/to...eased/?p=199488

Wonko

<DiskID>0</DiskID>
<WillWipeDisk>true</WillWipeDisk>

wipe all drives

The script is probably better with startnet.cmd. The WinPEshl.ini is very sensitive if encouters errors and might restart the image without wiping anything.

Any tool in mind for this operation? Perhaps a good command-line hexeditor to wipe to first 510 bytes of the drive?

I could use diskpart but it doesn't accept command line, as it runs only via custom script. Not very customizable.

The script is probably better with startnet.cmd. The WinPEshl.ini is very sensitive if encouters errors and might restart the image without wiping anything.

 

Any tool in mind for this operation? Perhaps a good command-line hexeditor to wipe to first 510 bytes of the drive?

I could use diskpart but it doesn't accept command line, as it runs only via custom script. Not very customizable.

1) you need to wipe WAY more that just first 510 (or 512) bytes on a GPT disk , why you don't actually try to study and understand HOW EXACTLY a GPT disk is made?

Wiping only the MBR on a GPT disk is - more or less - like attempting to empty the water entering your leaking boat with a colander.

Wiping the first 510 (or 512 better) bytes you will wipe the protective EE partition entry, that will be recreated exactly as it was at next attempt to partition/format the volume, leaving ALL the actual volume info intact (twice) and potentially creating each and every kind of conflict (+1 more).

2) JFYI, diskpart is said by MS to not accept command line and to need a script (which BTW would not be an issue at all in your specific case) as a matter of fact with a trick or two it can be made to accept command lines from a batch.

Wonko

I have created a WinPE 4.0 iso and added the diskpart script to startnet.cmd/WinPEshl.ini. WinPE freezes at the windows 8 logo on both uefi and bios systems.  Same issue as before http://reboot.pro/to...fter-boot-logo/. That one was resolved with grub4dos command map --e820cycles=0. This is very weird and don't know to fix it.

I have created a WinPE 4.0 iso and added the diskpart script to startnet.cmd/WinPEshl.ini. WinPE freezes at the windows 8 logo on both uefi and bios systems.  Same issue as before http://reboot.pro/to...fter-boot-logo/. That one was resolved with grub4dos command map --e820cycles=0. This is very weird and don't know to fix it.

Then it is likely a failed build.

It happens, try using a proven method to build the PE, like the nice QuickPE by Erwan.l, DO NOT add any script (diskpart or other, DO NOT modify startnet.cmd/WinPEshl.ini).

If it boots, re-build using EXACTLY the same method and source, but this time add the scripts and modify the startnet.cmd/WinPEshl.ini, etc.

http://reboot.pro/fi...le/340-quickpe/

Wonko

This time I used un untouched boot.wim image from Windows 8.0 ADK via copype amd64

And created the bootable iso image using oscdimg -lBUPE -h -n -m -b"etfsboot.com" -b"efisys.bin" C:\_TEMP C:\BUPE.iso

At first I only tried it with etfsboot.com. Then I tried the command with both etfsboot.com and efisys.bin. Same thing, it freezes in UEFI mode. It's got to be something I've missed. I know the original windows 8 DVD works file. It probably is some stupid driver that cannot be initialized.