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

[pelzflorian (Florian Pelz)]

On Fri, May 10, 2019 at 06:27:17PM +0200, Thomas Schmitt wrote:
> Hi,
> 
> Florian Pelz wrote:
> > This is not an install ISO but a USB install medium.  The USB drive
> > was written by the Windows Media Creation Tool.  Copying instead a
> > Windows ISO created by the Windows Media Creation Tool to a USB drive
> > does *not* yield a bootable USB drive; it does not even boot on other
> > computers.
> 
> This would bring the MS-World back in sync with my understanding of UEFI
> specs and other info sources.
> 
> But there are substantial rumors that the ISO boots from USB stick.
> Microsoft is said to advertise it for DVD+R DL and USB stick.
> (I could not get my hands on ISO or advertising yet ...)
> 
> 

The Windows 8.1 ISO image that I downloaded from Microsoft yesterday
also cannot be booted from a USB drive on neither this Macbook or
another computer.  I will continue testing the Windows 10 USB install
medium:

On Fri, May 10, 2019 at 03:46:56PM +0200, Thomas Schmitt wrote:
> 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.
> 

address@hidden ~$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 7.5 GiB, 8053063680 bytes, 15728640 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3093e6cb

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdb1  *     2048 15728639 15726592  7.5G  c W95 FAT32 (LBA)
address@hidden ~$ sudo dd if=/dev/sdb of=windoof
Password: 
15728640+0 records in
15728640+0 records out
8053063680 bytes (8.1 GB, 7.5 GiB) copied, 324.929 s, 24.8 MB/s

So I calculate 512*2048+454=1049030.

I do:

address@hidden ~$ sudo dd if=/dev/zero bs=1 count=16 seek=1049030 of=/dev/sdb

It still boots.  I believe what I calculated was wrong.  I do not continue.



> 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
> 

Regards,
Florian