Jump to content

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


jaclaz

Recommended Posts

In a topic that was originally intended to be specific to Linux based and specific to a known Software firm boot CD's, here for the record:
http://www.msfn.org/board/topic/172610-acronis-iso-boot-on-uefi-pc/
it came out how there are (still) some "not entirely standard" or not "entirely documented" ways to make bootable CD's by using (or abusing) the No-Emulation provisions of the El-Torito standards.
 
Additional the relatively recent introduction of EFI bootable CD/DVD's gives reasons to attempt revising the way these CD/DVD's are made and how to interpret their contents.
 
A known tool to inspect the contents of a .iso in the Windows world is Isobuster:
http://www.isobuster.com/
a tool that is partially freeware (with limited functionality), with a Commercial license for the "full set" of available functions/features.
 
Taking advantage :w00t: of my familiarity with Isobuster's Author on another forum, I invited him to discuss here issues/features/changes/ideas/whatever about his tool when looking at these .iso's, he gladly accepted, and now there is this brand new thread to hopefully discuss the matter peacefully.
 
Quick recap:

  • traditionally it was believed (by me at least) that El-Torito no-emulation images were reserved to "special" loaders, such as:
    • the known "ArnesBootRecord" or MicrosoftCorporation.img (sized 2,048 bytes and used in Windows NT based OS install disks and PE 1.x's)
    • the known etfsboot.com (sized 2,048 bytes and used in Vista :ph34r: install disks and PE 2.x's)
    • the known etfsboot.com (sized 4,096 bytes and used in 7 and later Windwos OS and in PE's >2.x)
    • ISOLINUX.BIN (part of the Syslinux project, typically between 10 and 14 Kb in size)
    • GRLDR (part of the grub4dos project, typically around 250 Kb, but of which only the first 4 sectors, i.e. 2,048 byes are actually the "boot image"
    • other "special crafted" bootloaders still in the few Kbytes range in size
  • it is possible to have El-Torito No-emulation images that are either a whole (large) volume (hundreds of Mbytes in size)  or a volume (still large) with prepended to it a loader
  • in passing by the extension to the El-Torito standard adding to it the "EF" type of boot image (which is normally represented as a very small FAT formatted volume containing just the \efi\boot\ folder and an efi executable, such as bootia32.efi, bootia64.efi or bootx64.efi) has been talked about
  • it also came out that this "EF" no-emulation boot image can be a rather largish FAT formatted volume
  • the El-Torito standard does not include anywhere in boot catalog a field for the SIZE of such images (though it includes a field for "Size to be initially loaded")

The discussion provided some ideas to make clearer the structure of these .iso's, and allow the user to  have valid data about the size of these images and the possibility to "extract" them "correctly", i.e. in a way that these images can be re-used to create other images and or be mounted/accessed with other commonly uised tools.

 

Isobuster (the nick with which the Author of the Isobuster tool has registered on MSFN) already made a series of changes to the tool and we are in the phase of experimenting the modified tool on several different .iso's to see how efficient and useful are these changes and/or to propose new, further changes (where needed), etc.

 

jaclaz

Link to comment
Share on other sites


I'm still organizing my thoughts on a few things but I'll make the latest unofficial version available here for some testing on your end:
http://www.isobuster.com/downloads/isobuster/IsoBuster-Test.zip

Changes compared to the commercially available 3.4 version:

1. In case of no emulation, I check for the mkisofs structure if enabled in the options
This is old stuff but I improved this to be a bit, to be more strict as I noticed it triggered on (at least) one of the test images and was reading sectors (hence loosing time, especially on bad media)

2. In case of no emulation and if mkisofs is ignored or not valid, I check the first sector of the image (size or not) and check if there is an MBR or PBP. If there is, I derive the size from either of the two structures

 

3. I do the same (check the first sector of the image and check if there is an MBR or PBP) in case of  HD (Boot media type == 4) (*)

4. In case of no emulation and in the case that I don't get additional size information (from mkisofs or MBR or PBP) and in the case that another image follows the image, I use the following image start address to calculate a size. This is more guessing than anything else, but it's fair to assume that most (?) mastering applications will in fact organize the data this way.

5. In case of no emulation and in case an image file is called "Acronis.img", a hard coded check tests the 12th (*) and 13th sectors of that image to see if it doesn't contain an MBR or PBP
If it does, that is the point where I will let the code look for FAT, when FAT file systems are to be explored this way.

Since it is one file, I show it as one file, but I split the file up in two extents.  In IsoBuster this means you can inspect the different sub-parts (extents), and extract them seperately as well, for engineering purposes for instance.

6. A FAT file system, explored from a bootable image will be named after that boot file (the name appended)
 

7. Right mouse click an image (listed under "Bootable Disc") and choose properties to see the ID, which is the name as it is recorded in the boot catalog.  In case there is no name, "N/A" will be displayed (*)

 

8. Also in properties you can now see "EFI" for Platform, if it is an EFI boot image. (*)

 

I hope I didn't forget to mention anything.  Feel free to comment.

(*) New changes compared to previous test version.

I'll comment on the image files, put before me in another thread, in my next post here.

Edited by IsoBuster
Link to comment
Share on other sites

The El-Torito standard does not include anywhere in boot catalog a field for the SIZE of such images (though it includes a field for "Size to be initially loaded")

 

It looks like there were attempts made to discuss El-Torito standard supplements. I wonder if that standard was / is ever reviewed, so this discussion can become even more useful if these reviewers are invited. It sounds reasonable to periodically review any standards that are still in use.

 

 

I addressed the earlier mentioned 'open issues' of points 4 and 5 and I went ahead and split up the Acronis image into two extents.

Let me know what you think.

 

I'm glad we can discuss this topic without hijacking other threads. Note, all discussions on this forum are public.

 

As to your invitation to "let you know", I don't see Acronis image split into two extents in the last ISOBuster revision. Also, can you explain why Acronis_Media folder at the left pan's top is empty, and why its called ISO folder?  :)

 

2qlcxeh.jpg

Edited by zamarac
Link to comment
Share on other sites

Following feedback is on the image files that were discussed and proposed as test cases in another thread:

The feedback is based on the latest and greatest test version that I made available in previous post (above)

 

ATIH2015BM_WinPE5.iso

 

Seems to work fine ?  Can't fault anything.  Let me know if I'm missing something

 

ATIH2014P_6688_en-US.iso

 

Same comment.  Works fine since this last version (included also checking sector 12 of the Acronis image)

 

ATIH2015_3203_en-US.iso

 

Works fine !  Already did in previous test versions.

 

slitaz-3.0.iso

 

The boot image is only one sector.  I'm not sure what the correct size is supposed to be ?

I'm running into the El Torito limitations and poor implementation of it.

 

If the suggestion is to look in ISO9660 or Joliet, in search for a file that matches the start address, then that is not a good solution.

It means I have to explore one or both of those file systems first before I can complete expanding the bootable file "folder"

 

kav_rescue_10.iso

 

The boot catalog does not reference an EFI image !  There doesn't seem to be one ?  Only a so called BIOS image for PC.

However, when I do scan for missing files and folders, I can find a FAT12 file system that starts at LBA 73004

 

Unless you see it, I don't see where this FAT image is referenced from and hence how UEFI hardware (or IsoBuster) is supposed to find it ?

 

It may be that this image is simply not working right as well.  We shouldn't assume that all images tested are also 'good' images that work well under all circumstances.

 

To comment on earlier reported problem with this image, there is noting pointing to an "eltorito.img" and I'm not familiar with bextract.cmd

 

AcronisAntimalwareScanCD.iso

 

Very much the same comments as for previous image.

I can find a FAT12 image at LBA 170.494 but this FAT image seems to be corrupt as well. 

I don't see any UEFI bootability from this FAT image at all

 

2os.8.10.1.iso

 

Seems to be working fine !

The image is 7 blocks according to El Torito.

Extracts fine as well, contrary to earlier reported problem.  Please elaborate, because this works fine for me.

 

Nothing for UEFI present that I can see, so no issues there either.

 

2os316.iso

 

The image is only one block according to El Torito but at least the mkisofs patch fixes that, and IsoBuster shows 7 blocks as well (if enabled in options).

 

Nothing for UEFI present that I can see, so no issues there either.

 

 

I hope the changes in IsoBuster help and as far as I can see everything works, taking in account the limitations we run into because of the poorly executed limited El Torito standard.

Link to comment
Share on other sites

The screenshot here shows there is no split to extents as claimed. If you refuse to answer valid on-topic forum member questions, we'll need to discuss what is the actual purpose of this thread - ISOBuster package advertising?

 

If you feel offended in any way by any previous interaction, unfortunately - me too by the attempts to hijack to ISOBuster another thread I started. But it shouldn't prevent a normal discussion on topic in this thread of any interested parties. Always think of - who is the first offender...  :)

Edited by zamarac
Link to comment
Share on other sites

I don't see Acronis image split into two extents in the last ISOBuster revision.

Check if you have displaying the icon enabled in the options.

Also check if you truly have the latest version (you never know with caching).  So check to see if the file was signed today !

 

I can't seem to add screenshots without jumping through more hoops, so I'll not do that unless necessary.

 

Also, can you explain why Acronis_Media folder at the left pan's top is empty, and why its called ISO folder?  :)

 

That's the ISO9660 file system icon !??

Link to comment
Share on other sites

@Isobuster

Very good. :)

 

Still, the original "issue" that is about ISOLINUX.BIN based CD/DVD's where the ISOLINUX.BIN is "hidden", remains:

 

Files on which bextract.cmd works fine (but latest posted Isobuster does not :( ):

http://reboot.pro/topic/12406-editing-iso-files/

http://mirror.slitaz.org/iso/3.0/slitaz-3.0.iso

http://mirror.slitaz.org/iso/4.0/slitaz-4.0.iso

 

 

 

As I see it there are two ways to solve these issues (both IMHO not entirely "proper") :unsure:

  1. search in the 2,048 bytes that are listed in the boot catalog for the ISOLINUX string and/or the syslinux.com one (or other "pattern recognizer) and then find the ISOLINUX:BIN in the other filesystems structures (or find the file that starts on the same LBA as the boot image, as it may have been renamed) and use that size instead <- this would "cover" only part of the images, but should be OK for the vast majority of the "pure" ISOLINUX based ones, no matter the tool with which the .iso were made
  2. check if there is any "hole" in the LBA addressing starting from the LBA of the image in boot catalog and derive from this "hole" the real size of the image <- this would be somehow "risky" and would provide in nay case results rounded to 2,048 bytes, which may be "wrong"

Or, do *something like* the above checks and then show a window/message to the effect of:

Size of this boot image has not been exactly determined with enough  certainty.

Please review the image contents manually and input manually the extraction size:

LBA start: xx

Extension: _________

 

 

It is just my opinion of course :), but I would personally prefer the software telling me that it has doubts about something or that it is not 100% sure of something better that having it  seeming to work 100% but providing at the end a "wrong" image (or image extents).

 

About the 2OS images, there must have been a "glitch in the matrix" (on my side :blushing: ) when extracting, I retested and everything is fine now (re:size :thumbup ), still I would like to understand why (unlike other similarly based ISOLINUX.BIN images) the boot image is "recognized" as "Magic ISO Boot Record.img"

 

The kav_rescue_10.iso and AcronisAntimalwareScanCD.iso are also OK , no EFI images in them AFAICT, I must have had inadvertedly turned off the "mkiso patch setting" :unsure:.

 

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

Check if you have displaying the icon enabled in the options.

 

That's the ISO9660 file system icon !??

 

Thanks. Now I have the icons checked. Split icon now shows up in "Bootable Disk" folder, the package was re-downloaded today. But the extracted folder contains the same Acronis.img, not 2 split files, and the image is impossible to read: once mounted with ImDisk, it doesn't contain a valid file system. So no extents... When extracted separately from the folder - again no extents. When "Show Extents" is selected - no extraction...  :lol:

 

Also, may I suggest to show extents UNDER Acronis.img file (as expended folder) similar to any mounted archive, rather then in a separate window.

 

23krbew.jpg

 

Also, when I try to extract the same Acronis.img separately from left pan (assuming, may be this will give 2 extents), it asks for payment - how then you expect us to test the changes you make?  :rolleyes: And that file is also called Acronis.img that raises the question whether its content is the same as of Acronis.img from "Bootable Disk" folder - how to check that?

 

2qktg7t.jpg

 

As to Acronis_Media folder called ISO in the left pan, you mentioned to have downloaded Acronis 2014 ISO. Can you explain, why for ATIH2015_Linux.iso that folder is empty, but for ATIH2014_Linux.iso it is full with files?

Edited by zamarac
Link to comment
Share on other sites

But the extracted folder contains the same Acronis.img, not 2 split files, and the image is impossible to read: once mounted with ImDisk, it doesn't contain a valid file system. So no extents... When extracted separately from the folder - again no extents. When "Show Extents" is selected - no extraction...

As explained, the bootcatalog 'lists' one or more boot images. These boot images can be executable code of some kind (loaders) or self contained FAT file systems, OR in the case of Acronis, a combination of the two, fused together in one file.

Those are the files that IsoBuster lists, as those are the 'files' (eventhough they are not really files) that IsoBuster makes available for extraction.

Then it's up to the developer to do with that data as (s)he likes. A hex editor goes a long way for instance.

It's not in the scope of IsoBuster to interpret the data inside all 'files', its scope is to provide a means to extract the files, so that you can do something with it.

Because of the limitations of El Torito and because of the 'freedom' mastering applications use to implement El Torito the sizes of these boot images are often wrong. This exercise is to try and 'guess' those sizes as good as possible so that the files can be extracted.

As an EXTRA, I also show the FAT content IF such a boot image is in fact a FAT volume. And to add to that, you'll notice the hard-coded patches mentioned earlier, I even try to figure out where the FAT volume starts INSIDE the boot image.

It's still one file. The fact that a there is a volume inside the file does not change the fact that it is still one single file.

Extents, in the file system world, are parts of a file. A simple file comprises one extent of contiguous blocks. But the moment files are fragmented on the media they are comprised of two or more extents. That's what extents are. It's still one single file, the file just happens to be located on several locations on the disc.

As a perk, to make it easier for developers, I said in previous thread, "why don't I split the file in two extents for you", even though these two extents are in a contiguous space. This way you get a visual trigger as to where the FAT volume starts inside the file. Hec, you can even extract the separate extents if you like (downside is you need a [Professional] license for that).

So, when you extract the file, ImDisk will not work at offset 0, because there is no FAT there, that's the loader part, however if you give it an offset that you can clearly see in IsoBuster (for instance 12 * 2048) it WILL work. Hence why I went the extra mile of actually figuring out for you where the FAT volume starts.

 

Are things starting to make sense now ?

 

Also, may I suggest to show extents UNDER Acronis.img file (as expended folder) similar to any mounted archive, rather then in a separate window.

This is a design choice. This is true for all files (NTFS, FAT, UDF etc.) When 'fragmented' (more than one extent) this is the way to see the different sub parts of the file. Just try it on your NTFS drive for instance.

 

it asks for payment - how then you expect us to test the changes you make?

I don't expect you to test anything ? The people who actually asked for this will give it a go. But even that is not necessary. It works. the LBA's and sizes are there to be inspected.

I'm making changes to help the people who are into this stuff determine the sizes of the boot images. It's not something I need to do either. I do it because people seem to be interested in finding out. And since it's technical stuff I understand, I like to implement it. After that it still requires you to do whatever it is that you want to do with the boot images.

 

And that file is also called Acronis.img that raises the question whether its content is the same as of Acronis.img from "Bootable Disk" folder - how to check that?

 

Are you referring to the FAT file systems ?

I explained earlier that I append the boot filenames to the FAT file system names, to make it visibly clear where the FAT file systems come from.

When a FAT file system has no name (again lousy boot implementations) then that's the name you get.

 

As to Acronis_Media folder called ISO in the left pan, you mentioned to have downloaded Acronis 2014 ISO. Can you explain, why for ATIH2015_Linux.iso that folder is empty, but for ATIH2014_Linux.iso it is full with files?

Because it's empty in the one, and not in the other !

Because the 'makers' of the disc did not put files nor folders in the empty one. That's all.

I'm sorry but a lot of this is very basic stuff and I really don't have time to go so deep on all these topics. I'm more than willing to try and help, and my contribution can be to add features to IsoBuster to make your work easier (THAT is where I can help), but it is still your work at the end of the day. If it's not appreciated I really shouldn't bother.

Edited by IsoBuster
Link to comment
Share on other sites

it asks for payment - how then you expect us to test the changes you make?

 

I'll try and clarify more:

The whole El Torito functionality is entirely for free in IsoBuster and it does not require a license at all !

 

You can see/explore the content, extract the files etc. without limitations.

However, because people in the forum suggested to find a way to show that some files have a FAT file system inside I suggested an elegant solution could be to split the file in two extents (internally).

Then it's still one file, everything is conform how IsoBuster deals with the boot images (one file per boot image) and you have a visible aid that shows you the file consists of two parts.  One loader part and one image part.

Showing these extents (sub-parts) and their properties (LBA and size) is also perfectly free and available to anybody.  No license required whatsoever.

However, and I mentioned this before, the downside of this solution is that if you want to extract an extent on its own (not the file, but a sub-part, an extent) you need a [Professional] license.  But there is NO reason whatsoever to test this.  I see no reason to extract the extents by themselves.  Btw. this is old functionality that has been proven to work for many years now.  The whole point of the exercise is that you get to see 1) that the file consists of two parts and 2) that you now now where these parts start and end.

I you want to mount the resulting file with ImDisk (for instance) you can look at the the size of the first extent (loader), and input that in ImDisk as Offset (this is the bottom left edit control when you mount the image).

Alternatively you can extract only the second part using the (also free) IsoBuster functionality Extract From-To.  Use the start address of the second extent, extract the amount of blocks of the second extent and extract user data only (2048 bytes per block).  That's it.

 

I hope this puts that issue to rest.

Next ... B)

Link to comment
Share on other sites

Still, the original "issue" that is about ISOLINUX.BIN based CD/DVD's where the ISOLINUX.BIN is "hidden", remains:

 

What do you mean with hidden ?

That the size is not properly shown ?

We really run into the limitations of El Torito (and the lousy implementation of it) here.

I have, in the images you provided, seen at least 3 different variants of this isolinux boot loader.

So a hard coded solution may not be appropriate (find the "ISOLINUX" string and base size on that), also because you earlier stated that the size may vary between 10 and 14 KB.

If you (or anybody else) can point me to the internals of this file, if there is a field from which I can derive a file-length, I'll do that ! A quick search did not yield to anything usable.

I personally see the latter a viable solution if somebody can help me determine the size from the file contents itself.

 

Files on which bextract.cmd works fine (but latest posted Isobuster does not

 

I'm not familiar with this tool. How does it determine the size ?

 

As I see it there are two ways to solve these issues

 

Both suggestions 1 and 2 require 'other' file systems to be explored and that is something that goes against the design of IsoBuster.

The intent is to be able to explore any file system entirely on itself, and that same logic goes for the El Torito file system (if you can call it that).

There are lots of other possibly problems associated with that. Which file system lists the file. ISO9660, Joliet, UDF, HFS, others ? Is the file listed at all ? (It certainly is not a requirement of El Torito.).

Having to explore the other file systems, one by one if one doesn't list it, can potentially add a lot of unwanted time to the simple opening of an El Torito file system.

And yes in an image file this is all rather fast, but on a bad disc this may take forever.

 

show a window/message to the effect of:

I don't want to do that. Sorry. I can see if I can make it clearer that the values are not to be trusted (at best) but then it's up to the user/developer/engineer to extract what (s)he thinks is the correct length.

One possible and easy mechanism to do that is to use the IsoBuster Extract From-To functionality.

 

I would personally prefer the software telling me that it has doubts about something

 

I can look into broadening the warnings that are already in place for certain situations

 

still I would like to understand why (unlike other similarly based ISOLINUX.BIN images) the boot image is "recognized" as "Magic ISO Boot Record.img"

 

Simple, because that's how it is recorded in the boot catalog. That is where IsoBuster gets the name from, if present.

Do a Sector View with IsoBuster on the bootCatalog.cat file and you'll see

I could look into, in case no name is recorded in the catalog, and if it turns out to be an "ISOLINUX" file (based on that signature inside the first block), to name the boot image "IsoLinux.img"

Link to comment
Share on other sites

As said I have no "foolproof" solutions, the one I use in the batch is only suitable for the case where ISOLINUX.BIN (or other file) is listed in the filesystem, but at least works for a number of ISOLINUX (and non-ISOLINUX) based images.
 
What I simply do in bextract.cmd (have you had a look at it? it is all in all a 6 kb batch file, and though it uses a few external programs it doesn't really bite - unless provoked ;) )
http://reboot.pro/topic/12406-editing-iso-files/
http://reboot.pro/topic/12406-editing-iso-files/?p=108486
 
It parses the output of isoinfo -d, this is the output for the slitaz3.0 file:

CD-ROM is in ISO 9660 format
System id: LINUX
Volume id: SliTaz core
Volume set id:
Publisher id:
Data preparer id: pankso
Application id: GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR © 1993 E.YOUNGDALE
© 1997-2006 J.PEARSON/J.SCHILLING © 2006-2007 CDRKIT TEAM
Copyright File id:
Abstract File id:
Bibliographic File id:
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 15161
El Torito VD version 1 found, boot catalog is in sector 32
NO Joliet present

SUSP signatures version 1 found
Rock Ridge signatures version 1 found
Rock Ridge id 'RRIP_1991A'
Eltorito validation header:
Hid 1
Arch 0 (x86)
ID ''
Cksum AA 55 OK
Key 55 AA
Eltorito defaultboot header:
Bootid 88 (bootable)
Boot media 0 (No Emulation Boot)
Load segment 0
Sys type 0
Nsect 4
Bootoff 21 33

getting the bolded red info.
If the disk is bootable (88) and if it is No emulation (0) it gets the 33.
Then it parses the output of isoinfo -l -i, here is a snippet:

Directory listing of /
d--------- 0 0 0 2048 Mar 28 2010 [ 24 02] .
d--------- 0 0 0 2048 Mar 28 2010 [ 24 02] ..
d--------- 0 0 0 2048 Mar 28 2010 [ 26 02] BOOT
d--------- 0 0 0 2048 Mar 28 2010 [ 25 02] IMAGES
---------- 0 0 0 1987 Mar 28 2010 [ 40 00] INDEX.HTM;1
....
Directory listing of /BOOT/ISOLINUX/
...
---------- 0 0 0 256 Mar 28 2010 [ 14984 00] HU.KBD;1
---------- 0 0 0 6536 Mar 28 2010 [ 14985 00] IFMEM.C32;1
---------- 0 0 0 14336 Jun 9 2009 [ 33 00] ISOLINUX.BIN;1
---------- 0 0 0 146 Mar 28 2010 [ 14989 00] ISOLINUX.CFG;1
---------- 0 0 0 57 Mar 28 2010 [ 14990 00] ISOLINUX.MSG;1
....

looking for any file starting on sector 33 and then uses the 14336 as size of the no-emulation loader image to be extracted and then extracts it:
 

---------- 0 0 0 14336 Jun 9 2009 [ 33 00] ISOLINUX.BIN;1

No Emulation Boot Image found:
\BOOT\ISOLINUX\ISOLINUX.BIN;1 - size 14336 bytes

Attempting to extract (No Emulation Boot) with size 14336 bytes as ISOLINUX.BIN

OK, 14336 bytes, 0.031s, MD5 = a2327349f92d53738ee5d4522eb3fbc7
07/09/2014 12.41 14.336 ISOLINUX.BIN

Additionally (if there is one) it attempts to extract the commands used in mkisofs to create the image, saving them in a file in a folder named <name_of_the_iso_boot>, in this case of slitaz3.0.iso there is not such info, but, as an example if you try the batch on an image like pmagic4.0.iso, you get:
 

---------- 0 0 0 215016 Mar 31 2009 [ 35 00] GRLDR.;1

No Emulation Boot Image found:
\/=\GRLDR.;1 - size 215016 bytes

Attempting to extract (No Emulation Boot) with size 215016 bytes as GRLDR.

OK, 215016 bytes, 0.000s, MD5 = 1ff49d4810d9ac186e15a8479cb9e216
Directory di C:\Downloaded\pmagic-4.0_Boot
07/09/2014 12.51 215.016 GRLDR
1 File 215.016 byte
2 Directory 168.625.807.360 byte disponibili

This .ISO file was created with MKISOFS on Sat Apr 4 07:16:05 2009

Version 2.01.01a57

with this command line (saved in Rebuild.txt):

MKISOFS -R -b grldr -no-emul-boot -boot-load-size 4 -o pmagic-svn.iso current

 
The "hidden" is only connected to the fact that isoinfo -x cannot extract "hidden" files (though isoinfo -l does list them) hence I resolved to do the extraction using a "direct access" tool, the dsfo from the DSFOK packkage.
 
About the time needed to scan the filesystem(s), maybe you could add a "right click" option when you select the "Bootimage.img" shown as 2,048 bytes in size (and have this option ONLY when the size is 2,048 bytes :unsure:) to the effect of "Verify size by scanning the volume" (or something along the same lines, this way the scanning becomes "optional" and is performed by user decision). 
 

Simple, because that's how it is recorded in the boot catalog. That is where IsoBuster gets the name from, if present.
Do a Sector View with IsoBuster on the bootCatalog.cat file and you'll see

I could look into, in case no name is recorded in the catalog, and if it turns out to be an "ISOLINUX" file (based on that signature inside the first block), to name the boot image "IsoLinux.img"

I see :), which however brings us back on how it would be nice to distinguish at first sight (colour was suggested, but bolding would be also a good enough option) between "real names" (the ones you get from the bootcatalog.cat) and the "fake" names (like the generic "bootimage.img").

Or maybe I completely missed it in the docs :blushing: , the current behaviour is that if there is a set name in the boot catalog that name is displayed with appended the ".img", whilst if the entry is blank, the "generic" BootImage.img is shown, right?

 

You will have to agree that (when it works :ph34r:) my directory searching approach is a bit more "user friendly".
 
jaclaz

Edited by jaclaz
Link to comment
Share on other sites

In the meantime I checked a bit around.
It seems like there is a "hardcoded" size in ISOLINUX.BIN.
I checked the isolinux.asm of version 3.82, here is a snippet:
 

; ---------------------------------------------------------------------------
; BEGIN CODE
; ---------------------------------------------------------------------------

;
; Memory below this point is reserved for the BIOS and the MBR
;
section .earlybss
trackbufsize equ 8192
trackbuf resb trackbufsize ; Track buffer goes here
; ends at 2800h

; Some of these are touched before the whole image
; is loaded. DO NOT move this to .uibss.
section .bss2
alignb 4
ISOFileName resb 64 ; ISO filename canonicalization buffer
ISOFileNameEnd equ $
CurrentDir resb dir_t_size ; Current directory
RootDir resb dir_t_size ; Root directory
FirstSecSum resd 1 ; Checksum of bytes 64-2048
ImageDwords resd 1 ; isolinux.bin size, dwords
InitStack resd 1 ; Initial stack pointer (SS:SP)
DiskSys resw 1 ; Last INT 13h call
ImageSectors resw 1 ; isolinux.bin size, sectors
; These following two are accessed as a single dword...
GetlinsecPtr resw 1 ; The sector-read pointer
BIOSName resw 1 ; Display string for BIOS type
%define HAVE_BIOSNAME 1
BIOSType resw 1
DiskError resb 1 ; Error code for disk I/O
DriveNumber resb 1 ; CD-ROM BIOS drive number
ISOFlags resb 1 ; Flags for ISO directory search
RetryCount resb 1 ; Used for disk access retries

alignb 8

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

 
So, the data is actually there.
If mkisofs and the -boot-info-table are used the data are written by it, but if not the size is however already hardcoded in the field.
 
And the corresponding binary dump still for 3.82 version where isolinux.bin is 14336 bytes, hence 0x3800 has it nicely set at offset 0x10:

FA EA 77 7C 00 00 90 90 10 00 00 00 00 00 00 00
00 38 00 00 D6 B0 57 61 EF BE AD DE EF BE AD DE
EF BE AD DE EF BE AD DE EF BE AD DE EF BE AD DE
EF BE AD DE EF BE AD DE EF BE AD DE EF BE AD DE


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

I'll do a few more checks, versions 4.07 and 5.10 also have the size explicited in that field :) to find if earlier versions have the data *somewhere* else.

To make sure that the field is there and is correct, I guess it would be possible to re-calculate the checksum of the file and compare it with the next field, though I still have to see/understand how the checksum is calculated.

 

jaclaz

 

Link to comment
Share on other sites

About the time needed to scan the filesystem(s), maybe you could add a "right click" option when you select the "Bootimage.img" shown as 2,048 bytes in size (and have this option ONLY when the size is 2,048 bytes :unsure:) to the effect of "Verify size by scanning the volume" (or something along the same lines, this way the scanning becomes "optional" and is performed by user decision).

I suppose that could work yes !

Though for now I'd like to try to explore the other option and that is to derive the size from the first block. Good work done on that btw ! Cheers !

 

which however brings us back on how it would be nice to distinguish at first sight (colour was suggested, but bolding would be also a good enough option) between "real names" (the ones you get from the bootcatalog.cat) and the "fake" names (like the generic "bootimage.img").

Or maybe I completely missed it in the docs :blushing: , the current behaviour is that if there is a set name in the boot catalog that name is displayed with appended the ".img", whilst if the entry is blank, the "generic" BootImage.img is shown, right?

You're correct, that is exactly how it works at the moment.

But especially for you I added new functionality (see point 7 of my first post in this thread) and I now also show what is recorded in the boot catalog, via the properties window. That is the best I can do at the moment B)

So what about my suggestion to name the file "IsoLinux.img" in case I find the "ISOLINUX" string in the first block (and in case the bootcatalog contains no name for it) ?

 

You will have to agree that (when it works :ph34r:) my directory searching approach is a bit more "user friendly".

Sure, but your tool is designed for this purpose alone and IsoBuster needs to adhere to some other rules as well.

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

I'll do a few more checks, versions 4.07 and 5.10 also have the size explicited in that field :) to find if earlier versions have the data *somewhere* else.

To make sure that the field is there and is correct, I guess it would be possible to re-calculate the checksum of the file and compare it with the next field, though I still have to see/understand how the checksum is calculated.

Thanks for this information, I will look into this this afternoon, try to make a new test build

However, how do I now what version I'm dealing with ? In other words how do I know I can trust the DWORD's value ?

I suppose I could link trusting it with this checksum: FirstSecSum resd 1 ; Checksum of bytes 64-2048 since it can be done on the first block's content only.

In that case, yes please figure out the checksum calculation as well. I have NO idea where to start looking for it but you clearly know your way around this stuff.

Link to comment
Share on other sites

However, how do I now what version I'm dealing with ? In other words how do I know I can trust the DWORD's value ?

I suppose I could link trusting it with this checksum: FirstSecSum resd 1 ; Checksum of bytes 64-2048 since it can be done on the first block's content only.

In that case, yes please figure out the checksum calculation as well. I have NO idea where to start looking for it but you clearly know your way around this stuff.

 

Not really-really, but I am quite good at sounding like I was an actual expert. ;)

 

The actual asm checking routine is this one:

 

; Verify the checksum on the loaded image.

verify_image:

mov si,7C00h+2048

mov bx,es

mov ecx,[imageDwords]

mov edi,[FirstSecSum] ; First sector checksum

.loop es lodsd

add edi,eax

dec ecx

jz .done

and si,si

jnz .loop

; SI wrapped around, advance ES

add bx,1000h

mov es,bx

jmp short .loop

.done: mov ax,ds

mov es,ax

cmp [bi_csum],edi

je integrity_ok

mov si,checkerr_msg

call writemsg

jmp kaboom

integrity_ok:

%ifdef DEBUG_MESSAGES

mov si,allread_msg

call writemsg

%endif

jmp all_read ; Jump to main code

 

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.

However, fist thing I will see if among the various tools I have around I can find a pre-made one that can recreate it.

 

The "option to scan" remains valid, since besides the specific ISOLINUX solution (once it will be "coded properly") which will however cover - say - 87.23% of Linux originated images) it would come useful for other loaders (like the grub4dos GRLDR example I posted).

 

 

jaclaz

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...