IsoBuster

That's good news

The final version is (finally) out: http://www.isobuster.com/news/isobuster_3.5_release_notes From now on these changes are available in all future versions, no need to work with test or beta versions anymore. Merry Christmas !

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).

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.

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

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".

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

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.

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).

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.

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. I honestly do not know what you mean... could you please elaborate?

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) 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'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). Yes, do some tests if you can. Cheers.

I found a bit of time today to make a new test version Changes: 1) Following change was reverted again to previous state: 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 ?

I uploaded a new test version. 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. 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 ? I'll look into it, maybe on Wednesday. Tomorrow I don't think I will find the time.

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.

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 !

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) ?

Not really no but last resort I'm sure we can find somebody who is What was the filename of that image file ? Not sure which file you're referring to 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 ?

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 ! 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) ? Sure, but your tool is designed for this purpose alone and IsoBuster needs to adhere to some other rules as well. 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.

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. I'm not familiar with this tool. How does it determine the size ? 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. 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 can look into broadening the warnings that are already in place for certain situations 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'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)

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 ? 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. 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. 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. 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.

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. That's the ISO9660 file system icon !??

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.

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.