grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: grub-mkrescue: Problem with MBR partition table at start of EFI part


From: Thomas Schmitt
Subject: Re: grub-mkrescue: Problem with MBR partition table at start of EFI partition
Date: Fri, 10 May 2019 15:46:56 +0200

Hi,

Florian Pelz wrote:
> I would like to test but on this bootable German Windows 10
> 32-bit+64-bit USB install medium, the content is different.  How would
> I find the offset in the USB image (you call it offset 454) which I
> should zero out to break Windows?

That would be offset 454 in the EFI boot image: Start LBA field of MBR
partition 1.

You may learn the block address of the image from xorriso:

  xorriso -indev "$ISO" -report_el_torito plain 2>/dev/null \
  | grep 'El Torito boot img : .* UEFI'

should say something like

  El Torito boot img :   2  UEFI  y   none  0x0000  0x00   1     515

The last number 515 is the 2048-byte block address of the EFI image.
(That's from the japanese ISO mentioned at debian-user.)

If you write four zero bytes at byte 515 * 2048 + 454 = 1055174, then
there is start LBA 0 in the slot of partition 1. This should trigger
the stalled boot process of the Macbook.

But maybe the other bytes from 446 to 461 hamper recognition as partition
table entry. So more similar to the mformat image would be to zeroize
bytes 446 to 509 to clear the partition table, and then to write to bytes
446 to 461 what we see as partition slot 1 in the grub-mkrescue EFI
partition:

  80  00  01  00  01  01  12  4f  00  00  00  00  40  0b  00  00

-------------------------------------------------------------------------

If you are at it, i'd like to see a confirmation that the ISO indeed
boots via El Torito from USB stick. (Interesting for GRUB as background
info.)

Please in the end spoil El Torito by zeroizing the address of the
Boot Catalog in the Boot Record at 2048-byte block 17 (decimal). Byte
offset 71 to 74, little endian.

The ISO hexdumped by Chris Murphy has 0x00000016 = 22 :

  00008840  00 00 00 00 00 00 00 16  00 00 00 00 00 00 00 00

So

  dd if=/dev/zero bs=1 count=4 seek=34887 conv=notrunc of="$ISO"


You will probably see error messages when inspecting by software.
Like

  $ xorriso -indev "$ISO" -report_el_torito plain
  ...
  libisofs: WARNING : Wrong or damaged El-Torito Catalog. El-Torito info will 
be ignored.

Or a clueless assessment without checking the catalog signature:

  $ isoinfo -d -i "$ISO"
  ...
  El Torito VD version 1 found, boot catalog is in sector 0
  ...
  Eltorito validation header:
    Hid 0
    Arch 0 (x86)
    ID ''
    Key 0 0
    Eltorito defaultboot header:
        Bootid 0 (not bootable)
        Boot media 0 (No Emulation Boot)
        Load segment 0
        Sys type 0
        Nsect 0
        Bootoff 0 0

This is still less intrusive than trying to remove the Boot Record
or to camouflage it as something else.

If my theory is right, then EFI should not recognize the USB stick
as a device with EFI partition any more.


Have a nice day :)

Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]