Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


jaclaz

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

Recommended Posts

But there is another one calculating the checksum of bytes 64-2048, I'll see what I can do, but from this to "translate" it into an algorithm that you can re-implement, it is possibly a largish "leap" :ph34r:, I actually hoped you were expert in asm.

Not really no but last resort I'm sure we can find somebody who is

it would come useful for other loaders (like the grub4dos GRLDR example I posted).

What was the filename of that image file ?

Not sure which file you're referring to

I have quickly checked a very early version (2.00) and that boot info table is not there, however :(.

You have an image filename on this one as well (supposing I have the file downloaded ?) ? So that I know what is supposed to work and what is not ?

Share this post


Link to post
Share on other sites

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

Wait a second ... wait a second

This is the mkisofs patch stuff that is already implemented !!!!

The checksum is already implemented

and it is because the checksum test fails that the data is not used !!!

So the question here is, why doesn't the cheksum not match or is there an issue in my code and/or when can I ignore the checksum and use the data anyway (since from your testing the length is there anyway) ?

Share this post


Link to post
Share on other sites

So the question here is, why doesn't the cheksum not match or is there an issue in my code

I found an issue in my mkisofs patch when the size of the image is perfectly dividable by 2048 (no rest value)

I'll fix that in next test build (a few hours from now, I have to run now). Possibly this 'fix' will result in a number of boot images' sizes to be seen correctly and it will certainly make the isolinux investigation unnecessary.

More later !

Edited by IsoBuster

Share this post


Link to post
Share on other sites

The bad news are that evidently yes :( *somehow* your checksum and the one that is "embedded" in Isolinux seemingly do not match.

 

The good news :) are that - though it would be of course much better to understand the reason of the mismatch and solve it properly - to identify an Isolinux (at least any actually used version) there is not really-really a need to use the checksum.

Check the attached file (Excel format .xls, let me know if you have issues with this).

 

There is definitely a "pattern" ;).

 

About the GRLDR image, the snippet I posted was with an old version of parted magic.

 

Without opening a discussion on the choice of the Author that converted the package from Free to Commercial and deleted from servers all previous versions :w00t:  

 

Of course previous versions are redistributable, so if you want to work on the same one I can upload it to somewhere, but more easilu (give me some time) I will make a small empty .iso making use of GRLDR and will attach it.

 

jaclaz

 

 

 

 

Isolinux_versions.zip

Share this post


Link to post
Share on other sites

Hi,

 

Ok, I made a new test version (Beta version this time, as that makes more sense)

 

To be downloaded (for a little while) here

 

Changes:

 

- Several rewrites internally to reduce the read count, and improve things, hopefully noting broke.

- Fixed the mkisofs patch which means that now a lot more Linux related boot images will probably be listed with their proper length

- In case "ISOLINUX" is found in the first block of a loader, and the bootcatalog doesn't contain a name for the boot image, the listed file is called "IsoLinux"

- Since the bootcatalog file has no time and date, now "N/A" is shown for its time and date.

 

At this point we need to determine what still doesn't work and if there are reasonable workarounds for those situations.

 

I also need to find time to add a few more checkboxes to the options for these different, extra, tests.

Share this post


Link to post
Share on other sites

Very good. :)

 

The new beta works fine.

 

The GRLDR issue (please find attached two "demo" .iso) is now also much clearer.

 

Whilst the good Syslinux guys have decided (as seen since version 2.12) to pre-embed the size and the checksum (and write EFBEADDE as "filler"), the good grub4dos guys leave the whole set of bytes set to 00's.

 

The net effect is that IF the .iso is made with mkisofs AND the -boot-info-table option was chosen, Isobuster has no troubles with it.

 

Otherwise the size is still found as 2048 bytes since the bootinfotable in the first sector is all 00's.

Given the complexity of the options of mkisofs I would guess that the amount of GRLDR based .iso's around made with the "-boot-info-table" represent maybe 0.01% of the total number of GRLDR based .iso's.

 

And I plead guilty, too :blushing: , for having built numberless of such .iso's without the switch:

http://reboot.pro/topic/9696-oscdimg-and-grub4dos/?p=84348

 

I may ask tinybit/chenall  (current grub4dos maintainers :thumbup ) if they would consider to pre-populate the size and checksum in the bootinfotable in future versions of GRLDR (unless there is any size effect since GRLDR doubles as hard disk MBR + hidden sectors loaders).

 

In any case, the "do a scan for listed file starting on same sector as the bootimage.img" option would be useful in Isobuster for past and current builds (and may cover a number of "other non 2048 bytes sectors").

 

To "cover" the ISOLINUX's iso's created WITHOUT the -boot-info-table switch with ISOLINUX's BEFORE 2.12, what happens if we find the first two sets of EFBEADDE and approximate (by excess) the size to 5 CD sectors or 10240 bytes?  :huh:

 

jaclaz

testgrldrisos.zip

Share this post


Link to post
Share on other sites

I uploaded a new test version.

 

The GRLDR issue (please find attached two "demo" .iso) is now also much clearer.

 

For one the size is stored in the mkisofs structure, for the other it isn't.

 

I noticed that at offset (3*512) inside the first block there is a FAT file system as well.

So I extended the MBR/BPB check to look at every 512 byte offset in the first block and determine the size.

The effect is that there is a plausible size now, based on the FAT image, yet the size in reality seems to be much smaller.

This is annoying.  It also means the MBR/BPB test is highly unreliable for some type loaders/images.

I will revert this test again in next version and only check 2048 byte aligned.

 

To "cover" the ISOLINUX's iso's created WITHOUT the -boot-info-table switch with ISOLINUX's BEFORE 2.12, what happens if we find the first two sets of EFBEADDE and approximate (by excess) the size to 5 CD sectors or 10240 bytes?

 

I did not see this variant yet but have it implemented.  Test if you can as I can not see if it works ?

However, based on the xls you sent, the length will be a block too much for v1.60 ?

 

In any case, the "do a scan for listed file starting on same sector as the bootimage.img" option would be useful in Isobuster for past and current builds (and may cover a number of "other non 2048 bytes sectors").

 

I'll look into it, maybe on Wednesday.  Tomorrow I don't think I will find the time.

Share this post


Link to post
Share on other sites

Yep.

I will test the new-new beta.

 

GRLDR is a "very" flexible file.

It can be used as:

  • no-emulation bootsector on CD
  • as "full featured" loader (invoked by the bootsector code of a volume instead of NTLDR or BOOTMGR)
  • chainloaded by BOTH NTLDR (from BOOT.INI) and BOOTMGR (from either \boot\BCD or BOOT.INI)
  • chainloaded by it's own MBR (+hidden sectors) file the GRLDR.MBR (which is actually a "subset" of the whole GRLDR)

and can be used for many, many "tricks", and in order to do that it needs some common filesystem PBR's. 

A current GRLDR has :

  1. on sector 2 a FAT32 bootsector (with 00ed size)
  2. on sector 3, a FAT12/16 bootsector (with 1.44 floppy size)
  3. on sector 4 code that may be detected as a bootsector (possibly for EXT2/3 :unsure:)
  4. on sector 5 a NTFS bootsector (with 00ed size)

so that is very easy that the one or the other is recognized as the beginning of a "valid" image.

 

 

 

 

To "cover" the ISOLINUX's iso's created WITHOUT the -boot-info-table switch with ISOLINUX's BEFORE 2.12, what happens if we find the first two sets of EFBEADDE and approximate (by excess) the size to 5 CD sectors or 10240 bytes?

 

I did not see this variant yet but have it implemented.  Test if you can as I can not see if it works ?

However, based on the xls you sent, the length will be a block too much for v1.60 ?

 

 

Yep.

That is an issue. :(

Though the number of .iso's created with versions 1.60-1.64 (in version 1.65 the isolinux.bin is already 8552 bytes) will be so low to be of no practical relevance, the (optional) "advanced" scan may be needed to see if any file/structure is allocated on the LBA n+4, and if it is, lower the guessed size from 5 to 4. :unsure:

 

But (i will have to test a couple of .iso's), even if the isolinux.bin occupied area "overlaps" the "next" file/structure, if it extracted as 5 sectors and re-burned it should work alright, the only side issue would be that the recreated .iso is one sector larger/with contents shifted by one sector.

The alternative would be scanning the first sector for the "ISOLINUX x.yz" string, but I understand how that is not very "elegant".

 

 

jaclaz

Share this post


Link to post
Share on other sites

I found a bit of time today to make a new test version

 

Changes:

 

1) Following change was reverted again to previous state:

 


So I extended the MBR/BPB check to look at every 512 byte offset in the first block and determine the size.

The effect is that there is a plausible size now, based on the FAT image, yet the size in reality seems to be much smaller.

This is annoying.  It also means the MBR/BPB test is highly unreliable for some type loaders/images.

I will revert this test again in next version and only check 2048 byte aligned.

 

2) I added the suggested function to scan other file systems for a file with same LBA and then use the size of that file.

Initiate this scan via a right mouse click on a Boot Image file

(PS. limited to only ISO9660 file systems and derivatives (Joliet / Rock Ridge))

 

3) I added the ability to manually edit the properties of a Boot Image (address, length, name)Also the extents if there are any.

Normally this functionality falls under a [Professional] license but I unlocked it for Boot Images.

 

I hope this helps ?

Share this post


Link to post
Share on other sites

Yep, it seems to me like everything is fine :).

 

The provided test GRLDR based image (the one WITHOUT boot-info-table) show as a 2048 bytes bootsector but if one chooses "use other filesystem to guess the files' size" it is parsed/recognized correctly.

 

With the provided test GRLDR based image (the one WITH boot-info-table) the boot image shows as a "composed image", with a "first extent" of 2048 bytes and a "second extent" for the rest 268339 bytes[1].

 

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. :unsure:

 

Maybe an added column with - say - a "c" if the size has been determined by contents of the boot catalog, a "t" if the size has been determined by contents of boot info table  and with a "g" (added once the "use other filesystem to guess the files' size" has been run and it determined a different size from "first look") may expose more clearly the data.

 

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

 

jaclaz

 

 

[1] not that it matters, as long as the data is valid, but how is this extent size calculated?

Edited by jaclaz

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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? 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

 

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...