IsoBuster Posted September 11, 2014 Posted September 11, 2014 Seemingly you just check that at offset 510 there are Magic Bytes 55AA and from this you assume that the sector is a MBR or a PBR. True !At that stage that is all I test yes. I could look into a stricter test (I'm not promising and it may be next week before I find time for that).
jaclaz Posted September 11, 2014 Author Posted September 11, 2014 Seemingly you just check that at offset 510 there are Magic Bytes 55AA and from this you assume that the sector is a MBR or a PBR. True !At that stage that is all I test yes. I could look into a stricter test (I'm not promising and it may be next week before I find time for that). No hurry and no worry. I re-checked the older Isolinux versions and (unwantingly of course) I brought you on a "wrong" path. Earlier versions of Isolinux NEED the -boot-info-table switch in mkisofs to be actually bootable. The pre-embedded valid boot info table in later Isolinux has seemingly been implemented to avoid the need for the -boot-info-table switch. In other words (apart the "source" isolinux.bin in the original tool archive) it seemingly cannot exist "In nature" a bootable Isolinux based CD without correct bootinfotable data (no matter of course if that is the pre-embedded or the mkisofs calculated/patched one), in practice a .iso made with Isolinux before 2.12 with mkisofs without the -boot-info-table switch won' t be bootable. As such, now that the bootinfotable checksum verifying is corrected, there is no need for the "EFBEADDE" check, as any "real world" .iso based on Isolinux is correctly identified by the size and checksum in the bootinfotable. I hate it when it turns out that I am more royalist than the king ! jaclaz
IsoBuster Posted September 11, 2014 Posted September 11, 2014 As such, now that the bootinfotable checksum verifying is corrected, there is no need for the "EFBEADDE" check, as any "real world" .iso based on Isolinux is correctly identified by the size and checksum in the bootinfotable. I see .. so the hardcoded option is not really needed ?Well ... I 'll leave it in, for when people uncheck the 'mkisofs' test but leave the hardcoded checkbox on.Maybe I'll have to add another hardcoded check again at a later date.
jaclaz Posted September 11, 2014 Author Posted September 11, 2014 (edited) I see .. so the hardcoded option is not really needed ?No. Well ... I 'll leave it in, for when people uncheck the 'mkisofs' test but leave the hardcoded checkbox on.But, if I get it right, it will never detect anything. The isolinux.bin before 2.12 has ALL fields set to "EFBEADDE" BUT it cannot be used without the mkisofs -boot-info-table switch that will fix with the right values into first (only used) 4 fields with the right data AND fill all the other fields with 00's.The isolinux.bin 2.12 and later will have the first 4 fields pre-set and all the other ones set to "EFBEADDE" (i.e. it will work with or without the mkisofs switch, and the only difference will be whether the other unused fields will "EFBEADDE" or "00000000").If you are checking for "EFBEADDE" in the first 4 sectors fields, you will never find a bootable .iso based on isolinux with those values. Maybe I'll have to add another hardcoded check again at a later date.Keeping the "hardcoded check" routine handy may be of use in the future, but right now the option is (sorry, my bad ) not useful.jaclaz Edited September 12, 2014 by jaclaz
IsoBuster Posted September 12, 2014 Posted September 12, 2014 If you are checking for "EFBEADDE" in the first 4 sectors, you will never find a bootable .iso based on isolinux with those values. I see !I'll turn it off by default then. I'll leave the GUI stuff in place for now.
jaclaz Posted September 12, 2014 Author Posted September 12, 2014 Re-reading your quote of my post I noticed I miswrote "sectors" for "fields" , corrected in the original post. jaclaz
IsoBuster Posted September 15, 2014 Posted September 15, 2014 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".
IsoBuster Posted September 17, 2014 Posted September 17, 2014 Did you have the chance to download ? I will removed the file soon. Cheers.
jaclaz Posted September 17, 2014 Author Posted September 17, 2014 Yep , sorry I had no time to test latest/latest, I now have done it and it seems like it's fine . A further (semi-random) thought (still connected with the generic concept of making the user more aware about what is going on).What if you (if possible of course, and with a low-low priority) add a small icon near the boot image file, indicating the method used to detect/analyze it?Something *like*:c - catalogm - mkisofso - other ISO filesystem structuresv - volume or hard disk image PBR or MBR... Still to be picky (as I am ), what would happen if I use (for the fun of it) a non FAT filesystem for a "queer" image like the Acronis one?(FAT filesystem is of course compulsory for the EFI image), but it shouldn't be for an image made out of a loader+volume (very unlikely, but possible I believe). jaclaz
IsoBuster Posted September 17, 2014 Posted September 17, 2014 what would happen if I use (for the fun of it) a non FAT filesystem for a "queer" image like the Acronis one? Then you let me know and I'll see what I can do It already works for NTFS btw, but not for other FS. Frankly it's not that high a priority anyway as I see it. It's just about finding another volume inside the image file.The option to expand FAT from Boot image files also only works for FAT btw !! The icons ... maybe later but I'm not promising I think this project is sort of done unless issues are found or more exceptions can be implemented.
jaclaz Posted September 17, 2014 Author Posted September 17, 2014 I think this project is sort of done unless issues are found or more exceptions can be implemented. Yes, I also believe that there is no real sense in continuing until a new "queer" .iso image is spotted in the wild .More than "done", I would say "dormant" (but ready to wake up if *needed*). jaclaz
jaclaz Posted October 17, 2014 Author Posted October 17, 2014 Before I forget , in order to keep things as together as possible , here is another example of when a "peculiar" setting/edit is needed:http://www.msfn.org/board/topic/149758-win7pe-se/page-6#entry1067197 Basically, if a "dual boot" BIOS/UEFI CD/DVD is made with OSCIMG using grldr (but I believe *any* non-2048 or non 4096 bytes loader are likely to behave the same ), on some older BIOSes the thingy won' t boot and there is the need to edit the "Size to be initially loaded" to 2048 bytes. jaclaz
IsoBuster Posted November 21, 2014 Posted November 21, 2014 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).
IsoBuster Posted December 12, 2014 Posted December 12, 2014 The final version is (finally) out: http://www.isobuster.com/news/isobuster_3.5_release_notesFrom now on these changes are available in all future versions, no need to work with test or beta versions anymore. Merry Christmas ! 1
jaclaz Posted December 17, 2014 Author Posted December 17, 2014 The final version is (finally) out: http://www.isobuster.com/news/isobuster_3.5_release_notesFrom now on these changes are available in all future versions, no need to work with test or beta versions anymore. Merry Christmas ! It seems like some of the new features have found an actual practical use , JFYI:http://reboot.pro/topic/20004-boot-a-acronis-true-image-2014-iso-image-with-grub2-at-uefi/ Merry Chistmas to you too. jaclaz
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now