Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

Strange or "odd" multi or single boot CD/DVD El-Torito images

- - - - -

  • Please log in to reply
42 replies to this topic

#26
IsoBuster

IsoBuster

    Newbie

  • Member
  • 39 posts
  • Joined 02-September 14
  • OS:Windows 7 x64
  • Country: Country Flag

Strange, I never got an email from the system alerting me of a response.  Good that I came to have a look (something to remember for the future should I not respond)

 

In other words *somehow* choosing the "guess" overrides the detection of the two extents, providing an actually "more accurate" result than the "proper" parsing of the boot info table

 

The image with the boot info-table triggers IsoBuster to read all its sectors, to be able to determine if the checksum matches. 

 

While doing this, since all blocks are read anyway, IsoBuster checks for MBR/BPB signatures in every block, and it seems to find them in the second block of this image, hence why the two extents.

It should not make a difference, since it's still one file with a correct length, it just happened to be split up in two extents.

 

The file without the table, does not trigger IsoBuster to read every sector (there is no need), hence no MBR or BPB is found, hence why no extents are created.

 

When I have time to implement the checkboxes in the GUI (options) I plan to also allow the boot info-table size data without verifying the checksum.  That will be faster, as not all sectors need to be read.  It will also have the same effect then as the image without the info-table, because not all sectors will be read.  The size may be wrong then, but it's up to the user to put checksum checking on or not.

 

Maybe an added column with...

 

I'm not adding columns.  Implementation is then for all objects in all situations and this only makes sense for boot images, a minute part of the functionality.

I contemplated putting something in the properties window as well for this, but have not done so (yet).

 

I still have to try creating test .iso's with the old isolinux versions, will do and report.

 

Yes, do some tests if you can.  Cheers.


www.isobuster.com



How to remove advertisement from MSFN

#27
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,649 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

The image with the boot info-table triggers IsoBuster to read all its sectors, to be able to determine if the checksum matches. 

 

While doing this, since all blocks are read anyway, IsoBuster checks for MBR/BPB signatures in every block, and it seems to find them in the second block of this image, hence why the two extents.

It should not make a difference, since it's still one file with a correct length, it just happened to be split up in two extents.

 

The file without the table, does not trigger IsoBuster to read every sector (there is no need), hence no MBR or BPB is found, hence why no extents are created.

 

When I have time to implement the checkboxes in the GUI (options) I plan to also allow the boot info-table size data without verifying the checksum.  That will be faster, as not all sectors need to be read.  It will also have the same effect then as the image without the info-table, because not all sectors will be read.  The size may be wrong then, but it's up to the user to put checksum checking on or not.

 

I see. :)

 

And yes :yes:, this might be set as an additional option, as if the boot image is very large (the Acronis) this read will slow down operations (let alone the case of defective media :ph34r:) .

 

Still - IMHO - in the case of the "divided in two extents" image, the size of "first extent" is evidently either of (please bear with me) "LBA start until PBR of second extent is found" OR "Info in the boot catalog (2048 bytes)" while size of the second extent is "Size in boot info table - size of first extent".

 

If this size of 2nd extent is not matching with any "recognized size" in the MBR or PBR "leading" the second extent, this second extent is an "artifact" in the sense that it doesn't compare with a "righteously identified because a MBR or PBR valid structure was recognized" one).

 

Not an issue of course :), but still ....  :rolleyes:

 

jaclaz



#28
IsoBuster

IsoBuster

    Newbie

  • Member
  • 39 posts
  • Joined 02-September 14
  • OS:Windows 7 x64
  • Country: Country Flag

Again no notification email ... I wonder what changed ?

 

Anyway,

The size of the file is what is recorded in the catalog OR what is found via one of the alternative methods.

 

IF the file is split in extents, the first part is from the start address (LBA) till the address where the MBR/BPB was found.

The second extent's size is the file-size minus the size of the first extent.  Basically the combined size of both extents is the file-size.

 

 

 

If this size of 2nd extent is not matching with any "recognized size" in the MBR or PBR "leading" the second extent, this second extent is an "artifact" in the sense that it doesn't compare with a "righteously identified because a MBR or PBR valid structure was recognized" one).

 

I honestly do not know what you mean... could you please elaborate? 


www.isobuster.com


#29
IsoBuster

IsoBuster

    Newbie

  • Member
  • 39 posts
  • Joined 02-September 14
  • OS:Windows 7 x64
  • Country: Country Flag

I uploaded a new test version

 

- Right mouse click a boot image and choose "Properties".  On the second tab you can see how the size was determined.

  Possible values are:  Bootcatalog / MBR / BPB / Next Image / Mkisofs / Hard coded (e.g. old ISOLINUX) / Via another file system

 

- I added a number of new checkboxes to the options menu so that you can determine what method will be used to determine the size of the boot image.


Edited by IsoBuster, 10 September 2014 - 03:54 PM.

www.isobuster.com


#30
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,649 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

 

If this size of 2nd extent is not matching with any "recognized size" in the MBR or PBR "leading" the second extent, this second extent is an "artifact" in the sense that it doesn't compare with a "righteously identified because a MBR or PBR valid structure was recognized" one).

 

I honestly do not know what you mean... could you please elaborate? 

I mean, you are not actually "veryfying" or "double checking" that the first 512 bytes of a sector represents a MBR or a PBR.

Seemingly you just check that at offset 510 there are Magic Bytes 55AA and from this you assume that the sector is a MBR or a PBR.

 

In the example grldr based image (the one with the boot info table filled), if I hexedit the offset 510 of second sector (i.e. offset 2048+510=2558) of the grldr file in the .iso (and correct the checksum in the boot info table), Isobuster does not "create" or "detect"  the two extents.

 

This is of course (and as said) a very minor issue.

 

I uploaded a new test version

 

- Right mouse click a boot image and choose "Properties".  On the second tab you can see how the size was determined.

  Possible values are:  Bootcatalog / MBR / BPB / Next Image / Mkisofs / Hard coded (e.g. old ISOLINUX) / Via another file system

 

- I added a number of new checkboxes to the options menu so that you can determine what method will be used to determine the size of the boot image.

Very, very nice. :thumbup

 

jaclaz



#31
IsoBuster

IsoBuster

    Newbie

  • Member
  • 39 posts
  • Joined 02-September 14
  • OS:Windows 7 x64
  • Country: Country Flag

Seemingly you just check that at offset 510 there are Magic Bytes 55AA and from this you assume that the sector is a MBR or a PBR.

 

True !

At that stage that is all I test yes.

 

I could look into a stricter test (I'm not promising and it may be next week before I find time for that).


www.isobuster.com


#32
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,649 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

 

Seemingly you just check that at offset 510 there are Magic Bytes 55AA and from this you assume that the sector is a MBR or a PBR.

 

True !

At that stage that is all I test yes.

 

I could look into a stricter test (I'm not promising and it may be next week before I find time for that).

 

No hurry and no worry. :)

 

I re-checked the older Isolinux versions and (unwantingly of course) I brought you on a "wrong" path. :w00t: :ph34r:

 

Earlier versions of Isolinux NEED the -boot-info-table switch in mkisofs to be actually bootable.

 

The pre-embedded valid boot info table in later Isolinux has seemingly been implemented to avoid the need for the -boot-info-table switch.

 

In other words (apart the "source" isolinux.bin in the original tool archive) it seemingly cannot exist "In nature" a bootable Isolinux based CD without correct bootinfotable data (no matter of course if that is the pre-embedded or the mkisofs calculated/patched one), in practice a .iso made with Isolinux before 2.12 with mkisofs without the -boot-info-table switch won' t be bootable.

 

As such, now that the bootinfotable checksum verifying is corrected, there is no need :no: for the "EFBEADDE" check, as any "real world" .iso based on Isolinux is correctly identified :yes: by the size and checksum in the bootinfotable. 

 

I hate it when it turns out that I am  more royalist than the king ! :blushing:

 

jaclaz



#33
IsoBuster

IsoBuster

    Newbie

  • Member
  • 39 posts
  • Joined 02-September 14
  • OS:Windows 7 x64
  • Country: Country Flag

As such, now that the bootinfotable checksum verifying is corrected, there is no need :no: for the "EFBEADDE" check, as any "real world" .iso based on Isolinux is correctly identified :yes: by the size and checksum in the bootinfotable.

 

I see .. so the hardcoded option is not really needed ?

Well ... I 'll leave it in, for when people uncheck the 'mkisofs' test but leave the hardcoded checkbox on.

Maybe I'll have to add another hardcoded check again at a later date.


www.isobuster.com


#34
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,649 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

I see .. so the hardcoded option is not really needed ?

No.
 

Well ... I 'll leave it in, for when people uncheck the 'mkisofs' test but leave the hardcoded checkbox on.

But, if I get it right, it will never detect anything. :ph34r:

The isolinux.bin before 2.12 has ALL fields set to "EFBEADDE" BUT it cannot be used without the mkisofs -boot-info-table switch that will fix with the right values into first (only used) 4 fields with the right data AND fill all the other fields with 00's.
The isolinux.bin 2.12 and later will have the first 4 fields pre-set and all the other ones set to "EFBEADDE" (i.e. it will work with or without the mkisofs switch, and the only difference will be whether the other unused fields will "EFBEADDE" or "00000000").

If you are checking for "EFBEADDE" in the first 4 sectors fields, you will never find a bootable .iso based on isolinux with those values.
 

Maybe I'll have to add another hardcoded check again at a later date.

Keeping the "hardcoded check" routine handy may be of use in the future, but right now the option is (sorry, my bad :() not useful.

jaclaz


Edited by jaclaz, 12 September 2014 - 04:39 AM.


#35
IsoBuster

IsoBuster

    Newbie

  • Member
  • 39 posts
  • Joined 02-September 14
  • OS:Windows 7 x64
  • Country: Country Flag

If you are checking for "EFBEADDE" in the first 4 sectors, you will never find a bootable .iso based on isolinux with those values.

 

I see !

I'll turn it off by default then.  I'll leave the GUI stuff in place for now.


www.isobuster.com


#36
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,649 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

Re-reading your quote of my post I noticed I miswrote "sectors" for "fields" :blushing: , corrected in the original post.

 

jaclaz



#37
IsoBuster

IsoBuster

    Newbie

  • Member
  • 39 posts
  • Joined 02-September 14
  • OS:Windows 7 x64
  • Country: Country Flag

Hello,

 

Small update.

 

This version tests a bit stricter for a FAT volume (so not just the 0x55AA signature)

Nothing else changed.  I didn't really test but I'm confident ;)

 

I decided to leave the "hard coded" option checked by default because it also includes the test for "ISOLINUX" and the name change of "BootImage.img" to "IsoLinux.img".


www.isobuster.com


#38
IsoBuster

IsoBuster

    Newbie

  • Member
  • 39 posts
  • Joined 02-September 14
  • OS:Windows 7 x64
  • Country: Country Flag

Did you have the chance to download ?  I will removed the file soon.  Cheers.


www.isobuster.com


#39
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,649 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

Yep :yes:, sorry I had no time to test latest/latest, I now have done it and it seems like it's fine :).

 

A further (semi-random) thought (still connected with the generic concept of making the user more aware about what is going on).

What if you (if possible of course, and with a low-low priority) add a small icon near the boot image file, indicating the method used to detect/analyze it?

Something *like*:

c - catalog

m - mkisofs

o - other ISO filesystem structures

v - volume or hard disk image PBR or MBR

...

 

Still to be picky (as I am ;)), what would  happen if I use (for the fun of it) a non FAT filesystem for a "queer" image like the Acronis one?

(FAT filesystem is of course compulsory for the EFI image), but it shouldn't be for an image made out of a loader+volume (very unlikely, but possible I believe).

 

jaclaz



#40
IsoBuster

IsoBuster

    Newbie

  • Member
  • 39 posts
  • Joined 02-September 14
  • OS:Windows 7 x64
  • Country: Country Flag

what would  happen if I use (for the fun of it) a non FAT filesystem for a "queer" image like the Acronis one?

 

Then you let me know and I'll see what I can do :)

It already works for NTFS btw, but not for other FS.  Frankly it's not that high a priority anyway as I see it.  It's just about finding another volume inside the image file.

The option to expand FAT from Boot image files also only works for FAT btw !!

 

The icons ... maybe later but I'm not promising :)

 

I think this project is sort of done unless issues are found or more exceptions can be implemented.


www.isobuster.com


#41
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,649 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

 

I think this project is sort of done unless issues are found or more exceptions can be implemented.

 

Yes, I also believe that there is no real sense in continuing until a new "queer" .iso image is spotted in the wild ;).

More than "done", I would say "dormant" (but ready to wake up if *needed*).

 

jaclaz



#42
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,649 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

Before I forget :w00t:, in order to keep things as together as possible :), here is another example of when a "peculiar" setting/edit is needed:

http://www.msfn.org/...-6#entry1067197

 

Basically, if a "dual boot" BIOS/UEFI CD/DVD is made with OSCIMG using grldr (but I believe *any* non-2048 or non 4096 bytes loader are likely to behave the same :unsure:), on some older BIOSes the thingy won' t boot and there is the need to edit the "Size to be initially loaded" to 2048 bytes.

 

jaclaz



#43
IsoBuster

IsoBuster

    Newbie

  • Member
  • 39 posts
  • Joined 02-September 14
  • OS:Windows 7 x64
  • Country: Country Flag

FYI I released a beta version that also includes all these changes.  I'll post here when the final gets released as well (because then the beta version is removed again).


www.isobuster.com





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users