Jump to content











Photo
- - - - -

Isolinux, and the boot table checksum field


  • Please log in to reply
44 replies to this topic

#1 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 29 December 2017 - 05:58 PM

Hi Guys,

 

It appears that since Syslinux 4.x, the boot table checksum in isolinux.bin field (offset 0x14) is incorrect.

 
Consequence is that one cannot use isolinux.bin boot loader without forcibly recomputing the checksum and updating the boot table.
 
The intention from the developpers thus is to distribute isolinux.bin with a correct checksum so that one can eventually ignore the boot table and use the bootloader as is.
 
The following post are splitted from this the original thread here and are meant to explain the "as is" and "to be".
 
Cheers,
Erwan


#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 January 2018 - 10:00 AM

I did a few checks, and it is my fault. :blush:

 

 

I have deceived you, managing somehow[1] to fail to understand what I wrote myself :w00t: :ph34r:

 

The isolinux actually needs the -boot-info-table both if the -boot-load-size 4 is used or if it is not used to work properly.

 

The bootinfotable is actually pre-populated in isolinux, but only partially and it won't work for booting "as is", the checksum does comprise the  bi_file: address (that needs to be changed to where the file starts in the .iso, and then the checksum needs to be recalculated).

 

EDIT: the above is incorrect. the checksum is from offset 64 to the end of the file, and as such does not include any part of the bootinfoitable, see following  post, the issue is that for *some reasons* the checksum "as is" is wrong.

 

In theory, when there is no boot-info-table, the isolinux as is should work, and as a matter of fact seemingly "finds the rest of itself" (with offset 0@0x10) but in practice the checksum doesn't validate, maybe there is some glitch that I am completely failing to detect. :(

 

The size of the whole file bi_pvd: is actually pre-written, and isn't changed, so your approach reading size of the boot file at offset 16/0x10:

http://reboot.pro/to...keiso/?p=205315

is valid (but it is valid only for isolinux or if -boot-info-table is used, as other loaders like grub4dos have NOT that field pre-populated). 

 

I abandoned the thread on MSFN as the main info needed (for isobuster to detect properly image) was solved, but I did so short of investigating how the checksum works and reproducing it, and never actually tested properly the whole stuff without bootinfotable :frusty:.

 

:duff:

Wonko

 

 

[1] Which either means that when I write I am not as clear as I thought or that I am getting old anf losing little grey cells in the process :(

 

It appears that since Syslinux 4.x, the boot table checksum field is incorrect.
 
Consequence is that one cannot use isolinux.bin boot loader without using recomputing the checksum and updating the boot table.
 
The intention from the developpers thus is to distribute isolinux.bin with a correct checksum so that one can eventually ignore the boot table and use the bootloader as is.
 
The following post are splitted from this the original thread here.
 
EDIT : this post is here so that it can be quoted in posted in post #1...


#3 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 January 2018 - 02:58 PM

Ok, maybe I understood the base issue. :unsure:

 

The checksum created by mkisofs is the 32 bit sum of bytes 64 up to the end of the whole isolinux.bin. (i.e. in the case of Syslinux 4.07 24576-64=24512 bytes starting from offset 64).

 

The intention of the pre-filling of the bootinfotable in isolinux.bin is confirmed to be an actual attempt to have it boot also if no -boot-info-table parameter is provided, BUT (and here comes the mistery :w00t:) the checksums in both isolinux.bin and isolinux-debug.bin are WRONG! :ph34r:

 

Once the checksums are corrected, the isolinux boots fine (up to the "boot:" line, since in the test no config was used), at least in qemu, WITHOUT the -boot-info-table switch.

 

The isolinux code "understands" (most probably because the bi_file: is found being 0) that no bootinfotable is provided and attempts to guess the LBA start of the second part, it seemingly (at least in this simplified case) guesses it just fine and proceed to load the rest of itself (but since the original checksum is wrong, it chokes with the original whilst with the fixed checksum it continues just fine).

No boot info table, assuming single session disk ...

Spec packet missing LBA information, trying to wing it ...

 

 

 

So the theory was (mostly) right, only *somehow* in practice it is flawed.

 

Most probably noone, ever, used those files without using -boot-info-table (which is recommended on the Syslinux wiki) and thus noone managed to notice the issue.

 

Attached is a pre-made test scenario, including a mkisofs.exe (just for convenience) and the two isolinux.bin and isolinux-debug.bin (both the original and the fixed versions 4.07), besides two quick batches to create a number of test .iso's using the one or the other bootsector with various parameters.

 

:duff:

Wonko

Attached Files



#4 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 06 January 2018 - 03:45 PM

I will look at your attached scenario.

 

I would say the checksum should always be rewritten (to be safe).

And to extend this, the boot table should always be updated (all fields), preferably not in isolinux (before generatinf the iso) but in the iso itself at the starting boot sector.

 

Also, from my experience (but i need to look at your zip file) : mkisofs does update the boot catalog with :

starting sector=file lba and sector count=file length (unless you specify boot load size).

 

This always work although one could argue that :

-sector count should be 4 (to keep compatibility with legacy bios).

-starting (boot) sector could (should?) be the sector after the boot catalog (running for 4 sectors to match previous condition).

-these 4 boot sectors should initiate the stage2 either reading the filesystem to locate the boot file (grub4dos, etfsboot.com, ...) or contain the lba of the boot file (isolinux, grub2, etc).

 

 

MakeIso does the above (when patching the boot table).



#5 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 06 January 2018 - 04:06 PM

Notice the difference on starting_sector & virtual_sector_count.

 

Both works.

Which is right "by the book"?

 

With mkisofs

using  mkisofs.exe -iso-level 4 -hide boot.catalog -udf -hide-udf boot.catalog -no-emul-boot -volid "mkisofs" -b c:\iso_folder\isolinux.bin 

    -boot-info-table -o c:\temp\isolinux.iso c:\iso_folder
 
boot-catalog
->Validation Entry [entry #0]
platform_id:0
manufacturer:
->Initial/Default Entry
boot_indicator:$88
boot_media_type:0
starting_sector:$000008A9 (4540416)
virtual_sector_count:$0058 (45056)
boot_table.bi_pvd_lba:$00000010 (32768)
boot_table.bi_file_lba:$000008A9 (4540416)
boot_table.bi_length:45056
boot_table.bi_csum:$3CBA9E9E

With MakeIso

boot-catalog
->Validation Entry [entry #0]
platform_id:0
manufacturer:Microsoft
->Initial/Default Entry
boot_indicator:$88
boot_media_type:0
starting_sector:$00000014 (40960)
virtual_sector_count:$0004 (2048)
boot_table.bi_pvd_lba:$00000010 (32768)
boot_table.bi_file_lba:$00000046 (143360)
boot_table.bi_length:45056
boot_table.bi_csum:$3CBA9E9E


#6 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 06 January 2018 - 04:16 PM

Testing the below iso (in that order), they all boot OK except 5 & 6.

  1. fixednobit4.iso
  2. fixednoparams.iso
  3. oribit4.iso
  4. oribitno4.iso
  5. orinobit4.iso
  6. orinoparams.iso
 
This is indeed expected since the checksum is wrong and/or not corrected by boot-table option from mkisofs.

 

My feedback :

 

1/

I stick to my previous argument : best is to always re compute the checksum and not depend on the checksum in isolinux.bin ("trust no one" and surely not a developper :) ).

 

2/

Also notice that boot_table.bi_file_lba:$00000000 (0) does not seem to prevent isolinux to boot : case 1 & 2.

But here again I would not take this for granted and would always also fill in that field.

 

3/

Also notice that mksisofs is using the actual lba of the file itself in starting_sector field rather than using sectors right after the boot catalog.

That may explain why mkisofs patches the file (isolinux.bin) on the hardrive, then writes it to the iso?

That defeats a bit the idea of stage1/stage2?

boot_table.bi_file_lba is purposedly there for that purpose : 4 (boot) sectors located @starting_sector will load the second part found @boot_table.bi_file_lba.

 

4/

As a whole, about the boot table : I would say it is either all or nothing.

Either take care of all fields or ignore it.

fixednobit4.iso
boot-catalog
->Validation Entry [entry #0]
platform_id:0
manufacturer:
->Initial/Default Entry
boot_indicator:$88
boot_media_type:0
starting_sector:$0000001A (53248)
virtual_sector_count:$0030 (24576)
boot_table.bi_pvd_lba:$00000010 (32768)
boot_table.bi_file_lba:$00000000 (0)
boot_table.bi_length:24576
boot_table.bi_csum:$F6E70191
fixednoparams.iso
boot-catalog
->Validation Entry [entry #0]
platform_id:0
manufacturer:
->Initial/Default Entry
boot_indicator:$88
boot_media_type:0
starting_sector:$0000001A (53248)
virtual_sector_count:$0030 (24576)
boot_table.bi_pvd_lba:$00000010 (32768)
boot_table.bi_file_lba:$00000000 (0)
boot_table.bi_length:24576
boot_table.bi_csum:$F6E70191
oribit4.iso
boot-catalog
->Validation Entry [entry #0]
platform_id:0
manufacturer:
->Initial/Default Entry
boot_indicator:$88
boot_media_type:0
starting_sector:$0000001A (53248)
virtual_sector_count:$0004 (2048)
boot_table.bi_pvd_lba:$00000010 (32768)
boot_table.bi_file_lba:$0000001A (53248)
boot_table.bi_length:24576
boot_table.bi_csum:$F6E70191
oribitno4.iso
boot-catalog
->Validation Entry [entry #0]
platform_id:0
manufacturer:
->Initial/Default Entry
boot_indicator:$88
boot_media_type:0
starting_sector:$0000001A (53248)
virtual_sector_count:$0030 (24576)
boot_table.bi_pvd_lba:$00000010 (32768)
boot_table.bi_file_lba:$0000001A (53248)
boot_table.bi_length:24576
boot_table.bi_csum:$F6E70191
orinobit4.iso
boot-catalog
->Validation Entry [entry #0]
platform_id:0
manufacturer:
->Initial/Default Entry
boot_indicator:$88
boot_media_type:0
starting_sector:$0000001A (53248)
virtual_sector_count:$0004 (2048)
boot_table.bi_pvd_lba:$00000010 (32768)
boot_table.bi_file_lba:$00000000 (0)
boot_table.bi_length:24576
boot_table.bi_csum:$34C6230E
orinoparams.iso
boot-catalog
->Validation Entry [entry #0]
platform_id:0
manufacturer:
->Initial/Default Entry
boot_indicator:$88
boot_media_type:0
starting_sector:$0000001A (53248)
virtual_sector_count:$0030 (24576)
boot_table.bi_pvd_lba:$00000010 (32768)
boot_table.bi_file_lba:$00000000 (0)
boot_table.bi_length:24576
boot_table.bi_csum:$34C6230E


#7 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 January 2018 - 05:11 PM

I still have to understand how the whole mess could have happened, your iso_info reports make all sense (and of course the tool cannot determine whether the.iso will actually boot or not).

 

The actual checksum is probably inverted:

boot_table.bi_csum:$F6E70191 is actually written to file as F6E70191 but it should be representing number 0x9101E7F6 (or maybe leaving it as is it is more readable, but then you should remove the $, and IMHO better, replace it in the other fields where there is a hex number with the 0x prefix)

 

(just like the boot_table.bi_pvd_lba:$00000010 which means 0x00000010 is actually written as 10000000 on file).

 

About your post #82:

http://reboot.pro/to...keiso/?p=205444

 

I don't understand, which mkisofs command parameters did you use, with which file? 

 

It seems like in that you didn't use the -boot-load-size 4, and thus the whole filesize was used, but the file lba start?

 

With mkisofs it seems right:

starting_sector:$000008A9

boot_table.bi_file_lba:$000008A9 (4540416)

(the two fields, both pointing to the beginning of the bootfile are the same)

 

With your tool (besides it being "earlier") it doesn't seem right:

starting_sector:$00000014 (40960)

boot_table.bi_file_lba:$00000046 (143360)

(the bootfile EITHER starts on LBA 14 OR on LBA 46) :w00t:

 

:duff:

Wonko 



#8 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 06 January 2018 - 05:30 PM

About your post #82:

http://reboot.pro/to...keiso/?p=205444

 

I don't understand, which mkisofs command parameters did you use, with which file? 

 

It seems like in that you didn't use the -boot-load-size 4, and thus the whole filesize was used, but the file lba start?

 

 

 

I have edited my post with the mkisofs command line used.

You assuumption is correct.



#9 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 06 January 2018 - 05:31 PM

 

The actual checksum is probably inverted:

boot_table.bi_csum:$F6E70191 is actually written to file as F6E70191 but it should be representing number 0x9101E7F6 (or maybe leaving it as is it is more readable, but then you should remove the $, and IMHO better, replace it in the other fields where there is a hex number with the 0x prefix)

 

(just like the boot_table.bi_pvd_lba:$00000010 which means 0x00000010 is actually written as 10000000 on file).

 

will look into it.



#10 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 06 January 2018 - 05:35 PM

With mkisofs it seems right:

starting_sector:$000008A9

boot_table.bi_file_lba:$000008A9 (4540416)

(the two fields, both pointing to the beginning of the bootfile are the same)

 

With your tool (besides it being "earlier") it doesn't seem right:

starting_sector:$00000014 (40960)

boot_table.bi_file_lba:$00000046 (143360)

(the bootfile EITHER starts on LBA 14 OR on LBA 46) :w00t:

 

I disaggree :)

Not only does the iso generated with MakeIso boot OK but I believe this is how it should be?

"starting sector" (worded incorrectly may be?) point at a stage1 boot will which load a stage2 boot (by either looking for the file in the filesystem OR using a hardcoded LBA like the file LBA in the boot table).

 

You can actually either "abuse" specs (at least i read it that way) :

-by writing all sectors at sector 0x14 (with sector count >4)

-by having start sector point directly at your file in the filesystem (in which case the file lba in the boot table is not much of a use / redundant)

 

CD boots, load 4 sectors located at "starting sector", minimal code loads and jumps/chains (whatever the right word) to "bootfile LBA"

boot starting sector <> boot file LBA (even if the 4 sectors are obviously identical at both locations).

 

 

To illustrate my argument above, quoting https://en.wikipedia.org/wiki/GNU_GRUB :

One possible approach for boot loaders to load kernel images is by directly accessing hard disk sectors 
without understanding the underlying file system. Usually, additional level of indirection is required, 
in form of maps or map files – auxiliary files that contain a list of physical sectors occupied by kernel images. 
Such maps need to be updated each time a kernel image changes its physical location on disk, due to installing new kernel images, 
file system defragmentation etc. Also, in case of the maps changing their physical location, 
their locations need to be updated within the boot loader's MBR code, 
so the sectors indirection mechanism continues to work. This is not only cumbersome, 
but it also leaves the system in need of manual repairs in case something goes wrong during system updates.[8]

Another approach is to make a boot loader aware of the underlying file systems, 
so kernel images are configured and accessed using their actual file paths. 
That requires a boot loader to contain a driver for each of the supported file systems, 
so they can be understood and accessed by the boot loader itself. 
This approach eliminates the need for hardcoded locations of hard disk sectors and existence of map files, 
and does not require MBR updates after the kernel images are added or moved around. 
Configuration of a boot loader is stored in a regular file, 
which is also accessed in a file system-aware way to obtain boot configurations before the actual booting of any kernel images. 
As a result, the possibility for things to go wrong during various system updates is significantly reduced. As a downside, 
such boot loaders have increased internal complexity and even bigger footprints.[8]


#11 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 06 January 2018 - 05:38 PM

I shall add to make it more confusing :

 

-if the checksum in isolinux is correct BUT the boot file LBA in isolinux is not correct -> Failure (actually wrongly reports a misleading "checksum error")

-if the checksum in isolinux is correct AND the boot file LBA in isolinux is 0 -> OK 

 

Indeed in my code, I was not updating the checksum if it was reading ok (why would i rewrite it if it is OK...).

Still, in some scenarios, I was getting "checksum error" despite the checksum being OK.

Only to realise the file LBA was incorrect.

Zeroing it fixed the issue or better, putting the right LBA also fixed the issue.

 

The chances of getting a isolinux.bin with a dodgy boot table is high, hence better rewrite the boot table each time.

Preferably perform this step in the iso while generating it, not in isolinux.bin before generating the iso as if you share this file with someone who does not use the boot table option, then it will lead to failure.



#12 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 January 2018 - 06:34 PM

Yep, I think that you are actually *somehow* abusing the specs, but as always, as long as it works, it is just fine, the main thing is to have a "plan B" in case it doesn't work.

 

But then, if I get it right, you have the file duplicated on two different LBA's?  :unsure:

 

The issue with mkisofs "patching" the boot info table on the source (before writing it to target) is a known one, the point is that as long as you use mkiosfs (with the -boot-info-table switch as Syslinux docs suggest) at every rebuild the "source" isolinux.bin is re-patched, so for the "intregralists" it is a non-problem, for people reusing an extracted from .iso bootfile with a program that doesn't patch the bootinfotable (or even if they don't use the right switch with mkisofs) it  has all the potentiality to become a nightmare.

 

So, writing the bootinfotable "on target" does sound a lot better. :)

 

:duff:

Wonko



#13 ady

ady

    Frequent Member

  • Advanced user
  • 165 posts

Posted 07 January 2018 - 04:39 PM

From the discussion(s) in this topic, I can think of at least 2 derivative topics that might interest members of reboot.pro:

_ Are there GUI tools for Windows (other than Erwan's MakeIso) aimed at building ISO images that would then be capable of booting both, BIOS and UEFI systems? Bonus points for compatibility with older versions of Windows (Vista, XP, 2k,...)

_ Can isolinux.bin be improved? Are there any inconsistencies/problems/bugs regarding the checksum and/or the patching of the boot info table?

I am not sure whether these 2 questions actually deserve their own respective forum topics; I guess it depends on what the "short" answers would be.

#14 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 07 January 2018 - 05:02 PM

From the discussion(s) in this topic, I can think of at least 2 derivative topics that might interest members of reboot.pro:

_ Are there GUI tools for Windows (other than Erwan's MakeIso) aimed at building ISO images that would then be capable of booting both, BIOS and UEFI systems? Bonus points for compatibility with older versions of Windows (Vista, XP, 2k,...)

_ Can isolinux.bin be improved? Are there any inconsistencies/problems/bugs regarding the checksum and/or the patching of the boot info table?

I am not sure whether these 2 questions actually deserve their own respective forum topics; I guess it depends on what the "short" answers would be.

 

About point 1, for now I have limited to win7 and up.

Thus it would not take much efforts to make it work down to XP (with some limitations thus here and there).

About compatibility down to 2k, well ... do we have to? :)

I have not encountered yet GUI handling multi boot but i dont know them all.

By GUI I mean a "true" GUI i.e not an "simple" interface to a command line tool (I made a GUI in the past for mkisofs, check my signature).

 

About point 2 and Isolinux, for sure the boot table option is "disturbing" to say the least.

If you are lucky, i.e your isolinux.bin has the right checksum but also a zero boot file lba, you can just ignore the boot table.

If you are not lucky, i.e your isolinux.bin is incorrect (checksum AND/OR file LBA), you cannot ignore the boot table and have to take care of it.

If you ask me, dont rely on luck and just patch your boot table each time.

Now related to that question is : "where" (and actually "when" from a dev p.o.v) should you patch the boot table ? in the isolinux.bin file or in the iso?

 

Let me add a point #3 : what should you do with the boot catalog (which contain a starting sector and a sector count field) ?

-> should the starting sector point to the 4 sectors usually sitting right after the boot catalog sector or should it point to the isolinux.bin LBA?

-> should the sector count be equal to 4 or should it be equal to the isolinux.bin file length?



#15 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 January 2018 - 05:07 PM

_ Can isolinux.bin be improved? Are there any inconsistencies/problems/bugs regarding the checksum and/or the patching of the boot info table?

 

I am in the process of checking the various Isolinux.bin (and isolinux-debug.bin) versions to try and understand what could have caused the "quirk".

 

I have written (actually blatantly copied/pasted with very little modifications from the in-built "sum8" ) a "sum32" function for Tiny-Hexer, to see if I can understand the reason.

 

But, all in all, since mkisofs.exe will calculate the "right" checksum, It will be easier to just use it to create the right checksum.

 

I am thinking about making a small batch to automate this.

 

But there remains another (little) mistery with the "reserved" bytes, that in isolinux.bin are set to "deadbeef" and that both Imgburn (as you provided) and mkisofs "reset" to 00's.

 

The .iso's created by my batch with the "fixed" bootloaders, maintain the "deadbeef" (and they boot just fine) so those "reserved" bytes are seemingly not used at all and could be *anything*. 

 

I may update the already posted .xls to provide the re-calculated checksums for the various versions, but I need to make sure to have all the various versions up to the latest, in order to do something "complete".

 

:duff:

Wonko



#16 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 07 January 2018 - 05:43 PM

From isolinux.asm.

 

If values in isolinux.bin are different from default values then the boot table is used, if not isolinux attemps to find the bootfile LBA by itself.

Quote from the code "mov eax,[trackbuf+28h] ; First boot entry ; And hope and pray this is us..." :)

 

For the record, offset 28 in the boot catalog is the "starting sector" field.

That same field that is used by the bios to load the initial 2k boot code (which i probably call "stage1").

 

Later in this file is also the checksum formula used.

Interesting enough it seems that the checksum is built on bytes 64-2048 when I am using whole file bytes starting at bytes 64 (but still end up with a correct checksum and identical to mkisofs).

 

Code below is pretty easy to read and understand the logic.

bootsec		equ $

_start:		; Far jump makes sure we canonicalize the address
		cli
		jmp 0:_start1
		times 8-($-$$) nop		; Pad to file offset 8

		; This table hopefully gets filled in by mkisofs using the
		; -boot-info-table option.  If not, the values in this
		; table are default values that we can use to get us what
		; we need, at least under a certain set of assumptions.
		global iso_boot_info
iso_boot_info:
bi_pvd:		dd 16				; LBA of primary volume descriptor
bi_file:	dd 0				; LBA of boot file
bi_length:	dd 0xdeadbeef			; Length of boot file
bi_csum:	dd 0xdeadbeef			; Checksum of boot file
bi_reserved:	times 10 dd 0xdeadbeef		; Reserved
bi_end:

and then later

; Alright, we have found the drive.  Now, try to find the
		; boot file itself.  If we have a boot info table, life is
		; good; if not, we have to make some assumptions, and try
		; to figure things out ourselves.  In particular, the
		; assumptions we have to make are:
		; - single session only
		; - only one boot entry (no menu or other alternatives)

		cmp dword [bi_file],0		; Address of code to load
		jne found_file			; Boot info table present :

and later on

%ifdef DEBUG_MESSAGES
		mov si,noinfotable_msg
		call writemsg
%endif

		; No such luck.  See if the spec packet contained one.
		mov eax,[sp_lba]
		and eax,eax
		jz set_file			; Good enough

%ifdef DEBUG_MESSAGES
		mov si,noinfoinspec_msg
		call writemsg
%endif

		; No such luck.  Get the Boot Record Volume, assuming single
		; session disk, and that we're the first entry in the chain.
		mov eax,17			; Assumed address of BRV
		mov bx,trackbuf
		call getonesec

		mov eax,[trackbuf+47h]		; Get boot catalog address
		mov bx,trackbuf
		call getonesec			; Get boot catalog

		mov eax,[trackbuf+28h]		; First boot entry
		; And hope and pray this is us...

		; Some BIOSes apparently have limitations on the size
		; that may be loaded (despite the El Torito spec being very
		; clear on the fact that it must all be loaded.)  Therefore,
		; we load it ourselves, and *bleep* the BIOS.

set_file:
		mov [bi_file],eax

found_file:
		; Set up boot file sizes
		mov eax,[bi_length]
		sub eax,SECTOR_SIZE-3		; ... minus sector loaded
		shr eax,2			; bytes->dwords
		mov [ImageDwords],eax		; boot file dwords
		add eax,((SECTOR_SIZE-1) >> 2)
		shr eax,SECTOR_SHIFT-2		; dwords->sectors
		mov [ImageSectors],ax		; boot file sectors

		mov eax,[bi_file]		; Address of code to load
		inc eax				; Don't reload bootstrap code
%ifdef DEBUG_MESSAGES
		mov si,offset_msg
		call writemsg
		call writehex8
		call crlf
%endif


#17 ady

ady

    Frequent Member

  • Advanced user
  • 165 posts

Posted 07 January 2018 - 06:13 PM

About point 1, for now I have limited to win7 and up.
Thus it would not take much efforts to make it work down to XP (with some limitations thus here and there).


If I understood correctly some of your comments to Wonko, supporting older-than-Seven would be possible but without supporting more than one boot image (i.e. only one section in the boot catalog, the default one), which would mean that the resulting ISO image would be bootable either on BIOS or in UEFI, not both (in the same ISO). :(
 

About point 2 and Isolinux, for sure the boot table option is "disturbing" to say the least.
If you are lucky, i.e your isolinux.bin has the right checksum but also a zero boot file lba, you can just ignore the boot table.
If you are not lucky, i.e your isolinux.bin is incorrect (checksum AND/OR file LBA), you cannot ignore the boot table and have to take care of it.
If you ask me, dont rely on luck and just patch your boot table each time.
Now related to that question is : "where" (and actually "when" from a dev p.o.v) should you patch the boot table ? in the isolinux.bin file or in the iso?


That sounds more related to the capabilities and/or options available in each program (MakeIso, ImgBurn, whatever). The point I am trying to bring up is about the upstream isolinux.bin file itself, "as-is".

There seem to be some investigations going on (at least from Wonko, perhaps Erwan too?) about isolinux.bin, its checksum and the need/convenience/recommendation to patch the boot info table when building ISO images.

If upstream isolinux.bin could be improved so as to obtain better hardware support (i.e. higher chances of successfully booting, whichever options or whichever program is used in order to build the ISO image, or easier management of boot-related options in ISO-building programs), that's an important/interesting point to report upstream.
 

Let me add a point #3 : what should you do with the boot catalog (which contain a starting sector and a sector count field) ?
-> should the starting sector point to the 4 sectors usually sitting right after the boot catalog sector or should it point to the isolinux.bin LBA?
-> should the sector count be equal to 4 or should it be equal to the isolinux.bin file length?


I think this is an important point too. I'll try to investigate this by re-reading some of the links I already posted in this topic. Since I am not a developer, it might take me some time.

 

I am in the process of checking the various Isolinux.bin (and isolinux-debug.bin) versions to try and understand what could have caused the "quirk".

I have written (actually blatantly copied/pasted with very little modifications from the in-built "sum8" ) a "sum32" function for Tiny-Hexer, to see if I can understand the reason.

But, all in all, since mkisofs.exe will calculate the "right" checksum, It will be easier to just use it to create the right checksum.

I am thinking about making a small batch to automate this.

But there remains another (little) mistery with the "reserved" bytes, that in isolinux.bin are set to "deadbeef" and that both Imgburn (as you provided) and mkisofs "reset" to 00's.

The .iso's created by my batch with the "fixed" bootloaders, maintain the "deadbeef" (and they boot just fine) so those "reserved" bytes are seemingly not used at all and could be *anything*.

I may update the already posted .xls to provide the re-calculated checksums for the various versions, but I need to make sure to have all the various versions up to the latest, in order to do something "complete".

:duff:
Wonko


IMHO, the goal would be to improve isolinux.bin upstream, independently of what mkisofs and Syslinux are currently using / recommending / suggesting.

I am eager to read the results of your tests.

FWIW, I have never seen the isolinux.bin file being modified outside the ISO image; the source directory for the ISO image contains an isolinux.bin file and it remains unmodified after building the ISO image. OTOH, I am not surprised to see that the isolinux.bin file within the resulting ISO image is slightly different than the original file located in the source directory. That has been my experience, for years.

Now, if the checksum (or whatever other part/code/section) within upstream's isolinux.bin is incorrect or not ideal (i.e. can be improved), I think this is worth investigating and reporting upstream.

#18 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 January 2018 - 06:38 PM

@erwan.l
 

From isolinux.asm.

isolinux.asm my sock! :ranting2: 
WHICH §@ç#ing version?  :realmad:
 
Only to show you how having repositories with all versions ;) helps in tracking WHEN and WHERE a bug may have happened ... :whistling:

@All
Ok, this is the relevant part,  without going in further detail:
1) first version with the provision (2.12) has checksum OK
2) last version of 2.x, (2.13) is OK
3) first version of 3.x (3.00) is OK
4) last version of 3.x (3.86) is OK
5) first version of 4.x (4.0) is NOT OK
6) all tested version after the above (4.07, 5.00, 5.10, 6.00, 6.02) are NOT OK
 
So there must have been a change between 3.86 and 4.00.

:duff:
Wonko

#19 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 January 2018 - 06:42 PM

FWIW, I have never seen the isolinux.bin file being modified outside the ISO image; the source directory for the ISO image contains an isolinux.bin file and it remains unmodified after building the ISO image. OTOH, I am not surprised to see that the isolinux.bin file within the resulting ISO image is slightly different than the original file located in the source directory. That has been my experience, for years.


Recheck, one of the known "side-effects" of the way mkisofs parches the bootinfotable is that it patches it in the "source":

 

Now, if the checksum (or whatever other part/code/section) within upstream's isolinux.bin is incorrect or not ideal (i.e. can be improved), I think this is worth investigating and reporting upstream.


From mkisofo man:

 

 

-boot-info-table
Specifies that a 56-byte table with information of the CD-ROM layout will be patched in at offset 8 in the boot file. If this option is given, the boot file is modified in the source filesystem, so make sure to make a copy if this file cannot be easily regenerated! See the EL TORITO BOOT INFO TABLE section for a description of this table.

 

Since everytime you create an iso you use (as per docs) the -boot-info-table switch, the source isolinux.bin been modified by the precedent build is "transparently" re-patched and you won't notice it, still it is not (anymore) as downloaded/extracted form Syslinux package.

 

:duff:

Wonko



#20 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 07 January 2018 - 06:49 PM

@erwan.l
 
isolinux.asm my sock! :ranting2: 
WHICH §@ç#ing version?  :realmad:
 
Only to show you how having repositories with all versions ;) helps in tracking WHEN and WHERE a bug may have happened ... :whistling:
 

 

Good point.

I checked an old repo.

 

Thus, checking the asm code in 6.03 show (at first look) no difference on this particular part.



#21 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 07 January 2018 - 06:52 PM

@All
Ok, this is the relevant part,  without going in further detail:
1) first version with the provision (2.12) has checksum OK
2) last version of 2.x, (2.13) is OK
3) first version of 3.x (3.00) is OK
4) last version of 3.x (3.86) is OK
5) first version of 4.x (4.0) is NOT OK
6) all tested version after the above (4.07, 5.00, 5.10, 6.00, 6.02) are NOT OK
 
So there must have been a change between 3.86 and 4.00.

:duff:
Wonko

 

That's bad news actually as it means that without taking care of the boot table, there is no way to use isolinux as a cdrom boot loader...

 

And actually, google is filled with people reporting issues about making bootable cdroms since 4.x ...

The solution is there in many softwares, but as an option ... and as most users (like me) dont RTFM, it creates noise :)



#22 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 07 January 2018 - 06:55 PM

Recheck, one of the known "side-effects" of the way mkisofs parches the bootinfotable is that it patches it in the "source":

 


From mkisofo man:

 

Since everytime you create an iso you use (as per docs) the -boot-info-table switch, the source isolinux.bin been modified by the precedent build is "transparently" re-patched and you won't notice it, still it is not (anymore) as downloaded/extracted form Syslinux package.

 

:duff:

Wonko

 

About that, and since this thread is about MakeIso, please note that MakeIso does NOT modifiy the boot file (but will modify the iso is "patch boot table" is selected). :)

 

With one exception of "pure" UDF filesystem where my UDF "knowledge" is still limited : then, the user is prompted if he wants to patch the boot file (which will then be stuffed in the UDF iso).



#23 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 January 2018 - 06:55 PM

Forget about what was written here.

 

I got confused with all the versions.

 

OK, maybe one point to erwan.l :unsure: 

 

:duff:

Wonko



#24 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 07 January 2018 - 07:20 PM

@erwan.l
 
Only to show you how having repositories with all versions ;) helps in tracking WHEN and WHERE a bug may have happened ... :whistling:
 

 

Just understood what you meant : I will keep pretending did not understand ;)



#25 ady

ady

    Frequent Member

  • Advanced user
  • 165 posts

Posted 07 January 2018 - 08:36 PM

Since everytime you create an iso you use (as per docs) the -boot-info-table switch, the source isolinux.bin been modified by the precedent build is "transparently" re-patched and you won't notice it, still it is not (anymore) as downloaded/extracted form Syslinux package.


Ouch, my memory was failing me. With mkisofs, of course you are correct.


FWIW, about the difference between isolinux.asm v.3.86 to newer versions,

(prefix with http:// )
 

3.86-4.00:
repo.or.cz/syslinux.git/blobdiff/01fc061d9851463296347d3834185ea5c5618a68..738e0dd221c89e76198b0f8176369fcffc8526e3:/core/isolinux.asm

3.86-head master:
repo.or.cz/syslinux.git/blobdiff/01fc061d9851463296347d3834185ea5c5618a68..HEAD:/core/isolinux.asm


3.8x-4.00:
repo.or.cz/syslinux.git/blobdiff/08b3602db548775ca819780de77686a186156ec7..738e0dd221c89e76198b0f8176369fcffc8526e3:/core/isolinux.asm

3.8x-head master:
repo.or.cz/syslinux.git/blobdiff/08b3602db548775ca819780de77686a186156ec7..HEAD:/core/isolinux.asm






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users