IsoBuster

@jaclaz, @cdob Maybe you can start a new thread where we discuss our findings on the quirky El Torito limitations and implementations, starting from your feedback on the IsoBuster version I shared ? If it leads to ways where IsoBuster can creatively work around 'some' of the El Torito limitations, then in the end it may serve its purpose better as an engineering tool for this particular field of interest. It's something that sparked my interest so I'm willing to put in some time (actually did that already on Wednesday). Yesterday I only had so much time, so I made some small changes (can share that version in the other thread if interested ?). Cheers.

My goodness, you're a character aren't you ? Sorry to have hijacked your thread. I hope you get the answers you seek. Needless to say I strongly disagree with your comments and ... well ... I will refrain from further commenting. I will retire from this thread. I'll leave the test exe online for a few more hours, for those who care, I'll remove it later. I will gladly look into these cases cdob. contact me here: www.isobuster.com/support.php#contact and we can follow up via email afterwards. Cheers.

Hi Guys, 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. http://www.isobuster.com/downloads/isobuster/IsoBuster-Test.zip This is the last version of today and tomorrow I most likely won't be able to do much. I am downloading the 2014 image (slowly ...). I'll check that out when I can. Cheers. PS. I will delete the download file again when I'm back to follow up.

Says you I'm more concerned with giving an as good as possible representation of the content and at the same time allow to explore the file-contents if present (even if burried in the Acronis image). If one needs to extract the Acronis image, then it should be the file as is, loader and image in one, as that is what it is. To split it up in two files, I can get why, and I do see the upside, but I have to choose between one of the two ways of approaching this. Hence my (thinking aloud) idea to maybe split it up in two extents. Then you have one file, but IsoBuster allows to see the different sub-parts (extents) to possibly extract those seperately I'm not sure we are on the same page zamarac ? The different images as they are shown by IsoBuster are in a way different floppies. Some however are 'just' loaders instead, or in case of the Acronis image it's in fact a combination of the two, which is perfectly possible. I can also make an exe file (for instance) that contains executable code and a resource part at the end that contains a FAT image, that I then explore with the executable code. That's not the issue. The floppy icon as is shown is in fact a folder, based on the content of the catalog file, which I in my doubtful wisdome of the past, also added to the root of that folder. You can compare it with putting a file in every folder that contains the folder structures that led to the content of the folder. I don't see the point or use of extracting all this content into one single file ? If that file is then loaded with ImDisk, what driver do you need to install then to be able to explore the content ? Sort of an El torito file-system driver ? If you're asking me to master a new file system with those file as content, that's not something IsoBuster does, so that's far beyond the scope of what it does. I hope this explains things a bit ?

I don't know what you mean ? I can't comment on that, that is beyond the scope of what I do or why I'm involved here. It is listed as *one* image in the El torito boot catalog and to remain somewhat and still inline with what is found there, for now at least, I have kept it one file. Because that's what it essentially is ! (see my previous comment to cdob as well) Frankly I don't know what you mean ? I downloaded and tested with the 2015 version, I can't comment in the 2014 version. Is it that different ? Worth it to download as well ? Because it seems to be a loader only !? It certainly is not immediately followed by a FAT image.

Yes. Good point. Download here again: http://www.isobuster.com/downloads/isobuster/IsoBuster-Test.zip I'm not sure what to do here. Some seem to have issues with the freedom I enjoy in naming and adding things A more elegant solution may be to split the image up in two extents. Then it's still one file, but you can explore and extract both extents seperately. The only disadvantage (for you) may be that it actually requires a [Professional] license then to see and extract these different extents (not the whole file, that remains the same) I have NO idea what you mean here, can you elaborate please ?

Hi Guys, A bit later than expected but here is what I did 1. In case of no emulation, I check for the mkisofs stuff (see options, if enabled) 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 images and was reading sectors (hence loosing time, especially on bad media) 2. In case of no emulation and if mkisofs is not relevant I check the first sector of the image (size or not) and check if there is no MBR or PBP. If there is, I derive the size from either of the two structures (*) 3. 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 to calculate a size till the next image. 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. (*) 4. In case of no emulation and in case an image file is called "Acronis.img" I will hard coded check the 13th sector 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 other code look for FAT when FAT file systems are explored. An option issue (for me) is that I need to add a few more checks before I proceed (**) 5. A FAT file system, explored from a bootable image will be named after that boot file (the name appended) An open issue still is that this may be renamed/overwritten again, when the root is explored and a new name is found for the volume. (**) (*) I may change this behaviour at a later date, based on settings (cfr. the mkisof setting) ... we'll see. (**) I'll look into this again at a later date. Tomorrow I may be too swamped. I hope I didn't forget to mention anything ? I appreciate your feedback. Especially on topic 4. This is a hard coded patch to have to do as little as possible extra reads. In an image file reading is blazing fast but I have to consider that this may also happen on a bad to read CD, and then these extra checks could choke the system or hamper recovery of more important data.

Hi Guys, Please try this version: http://www.isobuster.com/downloads/isobuster/IsoBuster-Test.zip Meanwhile my lasagna is ready ... I'm going to eat something. I'll be back in an hour or so (going to watch an episode of Babylon 5 ... I know .. I'm behind). When I get back I'll explain in detail what I have changed. I'd like your feedback then and if possible, please do some testing on various situations.

Could you point me to this image as well please ? I'll look into it shortly

The former yes, the latter no. I'll look into this I suppose you are right and I can't recall what my thinking was, now 10-12 years ago when I implemented this, but it's tricky to change it now. First of all, the 'folder' properties of where these images are located are from the catalog, and hence the files are in the right location as far as I'm concerned. I just chose to list the catalog as a seperate file as well and I don't recall why. Changing this however may break things for people who have relied on this layout for years now. As I said, the implementation is old. To change that now could create issues for other people. I don't really agree. All these values are based on what IsoBuster thinks are the locations and sizes. Since it has to work with incomplete data, that's the best it can do at this stage. Of course, based on this excercise, I may be able to improve a few things, we'll see. About the naming, it is entirely meant to make life easier, so that you can "extract" the file with a proper name, and so that you can load them in IsoBuster or another program to mount or explore its content. The name is based on the information that is available, and if the information is not available, a name is invented to still have an 'extractable' file. No name is not an option. The extension is to indicate what sort of file it is (or may be).

I'm downloading one. Agreeed. So why is in this particular image the 'no emulation' 'image' 'BootImage.img' in fact a FAT file system ? This strikes me as odd ? So how do you determine the actual size then ? Suppose I make a workaround for this case. Can I recognize that the size is wrong ? Or should I trigger on the name ("isolinux" ?) and then do an extra check ? Same question as before. Except that is not what I see for "BootImage.img" on the BartPE made iso ? I don't have the image downloaded yet to check, but is the FAT image located directly after the loader ? Or does the loader include an address somehow that points to the location on the disc where this FAT image is located ? In a situation where there is a loader and a FAT image, how do you suggest I list this (assuming I can detect it) ? Split in two files ? image-name.loader and image-name.img ? Is this something very much linked to Acronis ? I mean I can also hardcode that if the name is Acronis, that I check a few more sectors to try and find the linked FAT image ? Agreed Not really in IsoBuster as I try to keep file-systems unlinked. Meaning it is perfectly possibly to explore the boot stuff but not (yet) explore the ISO9660 file system with IsoBuster. So if ISO96660 is not explored yet, it's contents is not known yet, so the boot stuff can't rely on it Right.

I downloaded: ATIH2015BM_WinPE5.iso It doesn't seem to contain the second FAT image ? No I think you need to look at this virtually (certainly with no emulation). Normally there is only one bootfile and hence one could say that's the floppy content. Not that it needs to be limited to the floppy size. Now we have two images, so it more looks like two floppies actually. But that's not really the point. It's a graphical representation of all that is bootable on the disc.

Is that what you do in your batch file ? Sorry I'm not fluent in batch-ish, certainly not at this hour Is this based on information in the structures ? Or based on scanning and looking for the data ? In case of the former, what data ? In what specification ? Now I'm really signing off. Cheers.

Whoohoo. All this was implemented a loooooooon time ago, when I was still a young man From recollection and without checking the code I think you are spot on yes ! Indeed, I admit my recollection at the moment is a bit vague about this, but size was an issue when I implemented this. Though I don't know what you mean with "size to be loaded" vs. the actual size ? The Last LBA column is indeed a global implementation that is used for all objects. So if the block size of an object is wrong, that value will be wrong as well. What sort of distinction do you mean between the two images ? I'm not sure that I follow ? Do you mean more information about them ? In the 'Properties' window for these files/objects ? The hint, again properties I suppose ? Again, very rusty here. tomorrow I'll look into the code, but are the addresses (LBAs) not encoded in the catalog ? If they are, that's where the images start !? In fact, I downloaded the file I was pointed to, yet it doesn't seem to be the same as what I see in screenshots copied before. In this image file I notice that FAT is found in the IsoBuster-named "BootImage.img" file (eventhough size 0 bytes) The boot image "Acronis.img" is located before "BootImage.img", seems to be 1 or 2 blocks big, and has content, but no 'known' file-system. Are you saying that in this "Acronis.img" file there is information encoded that actually points to the real image somewhere further on the disc ? The problem here, correct me if I'm wrong, seems to be that this is a proprietary method that Acronis uses ? A bit of executable code that loads the actual image ??? I don't get this second content at all in the file I downloaded ? Which ads to my confusion ? In the file I downloaded this FAT FS has a proper name ?

Thanks. Doing that right now. It might have to wait till tomorrow before I have a chance to look into this closer. I meant, right mouse click the top most CD/DVD icon in the left pane and select "Find missing files and folders" To see if a previously unfound FAT (or other) File System shows up IsoBuster, per the option you set, can be instructed to check the boot image that is found via the El Torito structure(s) on a CD/DVD. It reads the sector(s) of the image file and looks for FAT inside. If there is FAT, the content is shown as a seperate file system in that session. I'm not aware of "another" image. I suppose this is what all this is about ? How is that image found exactly ? Where is it referenced from ? Once I have the image file to look at I may be able to answer these questions myself I suppose, we'll see. I never look at other software vendor's solutions, so I don't have UltraIso installed, and hence I cannot check, but where does UltraIso find this .bif file exactly ? Is it referenced from the ISO9660 file system ? Are you saying IsoBuster cannot see this file at all ? Why do you first have to mount the ISO ? Isn't UltraIso also supposed to be able to open iso image files ? Or is opening it from a certain offset key here ? And where does this offset come from then ? I'm not familiar with ImDisk batches although I think I have ImDisk somewhere. When IsoBuster 'sees' El Torito structures, it explores them, and expands its data under the diskette icon. In other words, IsoBuster shows it like a file system, next to other file systems it may find (e.g. ISO9660 or UDF or ...). Using the option you enabled, IsoBuster also, when El Torito info is found (and hence shown under the diskette icon), checks the boot image under the diskette icon, and expands that as well as a seperate file system IF it contains FAT If the diskette icon is there, it is a bootable disc, per the specifications for a bootable discs. Any device/computer that is capable of booting from an optical disc, checks for El Torito. If its content is correct (let's assume it is) then the disc is bootable. This sort of booting is executed by the BIOS Even if you have a device that also supports UEFI, in my opinion, for backwards compatibility, will boot from the disc, since it has the El Torito part. Otherwise all discs that are not made with these particular Linux builds (e.g. Windows software) and all older bootable discs, would suddenly not be bootable anymore on these more recent systems !? I don't buy that. But I most be missing something, why does Linux put the other stuff on there ? Kindly enlighten me. AHA, indeed, where is it, and what does it do ? :-) More tomorrow probable, unless I find the time tonight. But feel free to fill in the blanks here if you know them.

Hi, jaclaz pointed me to this thread but I have now scanned through it twice and it's all a bit too much and over my head TBH. I do not use Linux btw. and I am busy with other things as well and multi tasking is not my strength. Can somebody put some clear points in front of me ? Especially in where you feel IsoBuster fails or can be improved ? As far as I can see from the screenshots IsoBuster shows the El Torito information, which *is* the way to boot from optical media. Anything else is (as far as I know) not really optical and hence fancy stuff that is not really per the specifications (correct me if I'm wrong). I tried to download the image (I think) but my virus scanner did not allow me to proceed, so I won't. Is there an alternative download location ? Do I understand correctly and is there a partition table in this image ? Not very optical ? *.iso tells IsoBuster it's optical. To explore it as a HD image for instance, forced, try renaming the file to *.dsk Does this help ? To find a hidden FAT file system, have you tried a scan for missing files and folders ? PS. I think it's great that IsoBuster is used this way. I developed it as an engineering tool for myself, that's how it all started.