Syslinux - May 2012 - isohybrid.c, problem reports and questions

Hi,

i am currently exploring the boot data of Matthew Garret's Fedora LiveCD.
For that i read utils/isohybrid.c from git resp. 4.05.
(I assume Matthew used options  --efi --mac --type 0 .)

Some stumblestones showed up:
-----------------------------------------------------------------------

In initialise_gpt() i see unhealthy usage of string constants. Like:

  memcpy(part->name, "ISOHybrid ISO", 28);

This seems to assume dealing with 16 bit characters. (Wikipedia states about
GPT that the character set shall be UTF-16LE.)
The result in Fedora-LiveCD.iso is:

  $ dd if=Fedora-LiveCD.iso bs=1 skip=8248 count=28 | od -c
  0000000   I   S   O   H   y   b   r   i   d       I   S   O  \0   I   S
  0000020   O   H   y   b   r   i   d  \0   A   p   p   l

which is probably a patchwork from constants "ISOHybrid ISO",
"ISOHybrid",
and "Apple" that can be found in the code.

FWIW:
  $ echo "ISOHybrid ISO" | iconv -f UTF-8 -t UTF-16LE | od -c
  0000000   I  \0   S  \0   O  \0   H  \0   y  \0   b  \0   r  \0   i  \0
  0000020   d  \0      \0   I  \0   S  \0   O  \0  \n  \0

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

The block counts in the Apple partitions obviously assume 512 bytes per
block, whereas the start block numbers obviously assume 2048 as announced
in the APM header.
In initialise_apm() i see two occasions where block counts are handled:

- This should probably be 4 rather than 0x10:
    part->block_count = bendian_int(0x10);

- These _count variables should probably be divided by 4 before being
  submitted to bendian_int():
    part->block_count = bendian_int(efi_count);
    part->data_count = bendian_int(efi_count);
    part->block_count = bendian_int(mac_count);
    part->data_count = bendian_int(mac_count);
  The numbers stem from read_efi_catalogue() which deals with EFI blocks
  of 512 bytes.

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

The "Last LBA" of the first GPT entry is 1329448, the size of the ISO
image
in blocks of 512. But Wikipedia states that this number is inclusive.

Thus in initialise_gpt()
    part->lastLBA = lendian_64(psize);
one should probably subtract 1 from psize before submitting it to
lendian_64().

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

The second Apple partition map entry points to the VFAT image file
/isolinux/efiboot.img but announces as partition type "Apple_HFS".
Is this ok ? 

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

What is the reason for calling function reverse_uuid() ?
Is it intentional that it only byteswaps the first 8 of 16 bytes ?

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


The explored ISO image stems from
  http://mjg59.fedorapeople.org/Fedora-LiveCD.iso
Matthew advised it to me at his article "Anatomy of a Fedora 17 ISO
image"
  http://mjg59.dreamwidth.org/11285.html

The current state of my emerging description is at
 
http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt
Newly emerging is the chapter "SYSLINUX isohybrid for UEFI and
x86-Mac".
Comments, hints, bug reports are welcome.


Have a nice day :)

Thomas

Hi,

i think i found a further problem in isohybrid.c.
The backup GPT seems to be dislocated by 512 bytes.

The last usable LBA in the GPT headers (byte 40 to 47) is the same
as the start of partition entries in the backup GPT header.
(The value is 0x144fde in http://mjg59.fedorapeople.org/Fedora-LiveCD.iso)
To my understanding of GPT these numbers should differ by 1.

The backup GPT header starts 1024 bytes before the end of the image, despite
this comment in main():
        /*
         * Seek far enough back that the gpt header is 512 bytes before the
         * end of the image
         */

        if (fseek(fp, (isostat.st_size + padding) - orig_gpt_size - 512,
                  SEEK_SET))

Further above, i see that orig_gpt_size accounts for the GPT header size:
        orig_gpt_size = gpt_size = 512 + (128 * 128);

So subtracting 512 in the fseek call seems wrong.


Have a nice day :)

Thomas