Jump to content

Acronis ISO Boot on UEFI PC


zamarac

Recommended Posts

You can download without issues the clean trial ISOs someone posted, just follow safe download suggestions.

Thanks. Doing that right now. It might have to wait till tomorrow before I have a chance to look into this closer.

scan file system options are On by default

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

hence EFI Fat is visible

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.

But the "other" image (extracted by UltraISO as .bif from bootsector of a mounted by ImDisk ISO ) is not, which you can test yourself by using jaclaz's batch jointly with ImDisk

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.

extracted by UltraISO as .bif from bootsector of a mounted by ImDisk ISO ) is not, which you can test yourself by using jaclaz's batch jointly with ImDisk

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.

what do you mean under "shows El-Torito Information"? Which folder do you refer to on what screenshot?

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

Is its content shown by ISOBuster sufficient to boot the ISO in BIOS and/or UEFI modes?

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.

where is the "other" image?

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.

Link to comment
Share on other sites


@Isobuster
The point is that besides the "main" (no-emulation in these cases) image, a boot catalog (per ISO standard) can contain more than one bootable image.
If you peek inside the batches I posted I have inserted in them some references to the data structures.
These structures are coded in the El-Torito specifications:
http://download.intel.com/support/motherboards/desktop/sb/specscdrom.pdf
(Figures 2, 3, 4 and 5)
Isobuster deals with these correctly :), listing ALL the available boot images.
 
BUT there are a few issue (some only as my opinions, some as facts), when the left-hand "bootable disk" is selected Isobuster lists (in the .iso I am testing with):
Opinions:

  • BootCatalog.cat <- this is a "fake" filename AND IMHO it is NOT a "file" but rather a "folder", and of course the .cat extension is "arbitrary"
  • Acronis.img <- this is a half-fake filename, as the text "Acronis" is actually in the boot catalog entry, but the .img extension is "arbitrary"
  • BootImage.img <- this is a fake filename, as the text in the boot catalog entry is all 00's, and the .img extension is also "arbitrary" as above

Facts:

  • The column "Size" is "deceiving", as the data in the entries does NOT mean "size of the image" but rather "size to be loaded", actually the specifications do not have a field for "size of the image"
  • As well the column "Last LBA" is "deceiving" and also actually "wrong" as clearly it is a "calculated field" from LBA+(apparent) size of the image.
  • There is no distinction between the "main" image (Acronis.img) and the second one (BootImage.img)
  • There is no hint about the Type of image or "Platform ID" (it is missing somehow a column), the Acronis.img is type "00" (i.e. 80x86) whilst the "BootImage.img" is type "EF" (i.e. EFI see below)

I have NOT checked the UEFI specifications (that were more than 2000 pages last time I checked :w00t:) but I trust (the exception that confirms the rule ;)) the good MS guys when they say that the UEFI specifications extended the El-Torito addding an "EF" id for EFI platforms:
http://support.microsoft.com/kb/947024/en-us

The Windows PE CD-Rom can be started from BIOS firmware or from UEFI firmware. The CD-ROM has two boot catalog entries. One platform ID entry corresponds to the BIOS, and one corresponds to the UEFI.
...

pEF
Sets the platform ID to “EF," as defined by the UEFI specification.
...


Now, the fact that the specifications miss a real size for the image and an offset to the actual bootsector when the image, as the "Acronis.img" in the example, is marked as "no-emulation" but contains a whole largish FAT image with a loader prepended to it) and that the good Acronis guys have been "naughty" (IMHO breaking the compliance) with the "BootImage.img" by NOT filling any of the other fields in the entry (apart the 91 for the "last image", the "EF" for the "type" and the 88 for bootable and the actual LBA start) are not good reasons for a tool aimed to "bust" an .iso to "completely miss" the "Acronis.img" and to provide "queer" data for both the "Acronis.img" and the "BootImage.img".

 

It would be nice if your nice tool could *somehow* deal with these little queernesses and provide *somehow*  a way to deal with the "hidden image", i.e. an image that is listed on the boot catalog but that does not begin with a known filesystem data structure such as a bootsector and it's BPB, after all, without zamarac observations, looking at one of these Acronis iso's would have lead to completely "miss" the files listed in post #7: http://www.msfn.org/board/topic/172610-acronis-iso-boot-on-uefi-pc/?p=1084987

 

Of course if one "scans" the whole .iso looking for FAT ISOBUSTER willl find the "missing part", but it would be IMHO nicer if the tool could "parse deeper" the actual Boot Catalog entries.

It would also be nice if (on the left tree) the "unnamed" FAT filesystem were given a "fake name" like:

Start_%lba%_Extents_%sectors%

i.e. basically the data that I get through my half-@§§ed batches, as this would IMHO make visually easier to interpret the contents of the .iso.

@zamarac

No, I have no idea, though most probably the WinPE version uses a "normal" no-emulation bootsector, 1, 2 or however a few sectors in size. (i.e. there is in it no "hidden image" at all.
The point is IMHO the other way round, i.e. how (the heck) it can access a .bif file which first sector is not a bootsector. :unsure:
 
Temporarily, try this modified batch (this is really @§§ed :w00t:, it will list on "normal" .iso's with a "small" no-emulation bootsector the EFI image twice).

In other words, your results with the WinPE based .iso were EXPECTED.

There is NO question about how a WinpE CD/DVD boots on BIOS, it boots through a "real" no-emulation bootsector, what is called in jargon "Arnes Bootrecord" or "MicrosoftCorporation.img" i.e. a self-standing real-mode loader that was 2,048 bytes in size in PE's 1.x and became 4,096 bytes since the advent of  Vista/PE 2.x. (this is the thingy that checks the hard disk and if it is partitioned and has an active partition, loads BOOTFIX.BIN, which is the thing that prints on screen "press any key to boot from CD ....")

I am not sure to understand this:

As to the 2nd image (efi.img), its size is wrong resulting in mounting a CD instead of floppy.

 

What do you mean by "wrong" size? :unsure:

And what by resulting in mounting a CD instead of floppy? :w00t:

AFAIK the "automatic" setting in IMDISK uses "other parameters from size" to choose the device type (and no, I don't know exactly how it decides the kind of virtual device it auto-selects).

 

Open the image with a hex editor and check the number of sectors in the BPB.

 

In IMDISK do not let it choose "automatic" settings, choose yourself manually either "floppy" or "harddisk volume", set the volume to "read only", run CHKDSK on it.

 

jaclaz

Link to comment
Share on other sites

 

But I most be missing something, why does Linux put the other stuff on there ?

Kindly enlighten me.

 

When jaclaz invited you here, I'm sure he felt confident enough to answer these questions, so he did.   :thumbup  

 

UltraISO indeed can't see the "other" image when exploring the ISO. But it can extract it as "boot file" .bif from a mounted ISO, which sounds in contrast with what your definition of CD boot image is, i.e. El-Torito Floppy.   :huh: Also, jaclaz's batch can similarly find both images and mount with ImDisk. It appears that one image is used to boot the ISO in BIOS mode, and the other in UEFI mode. Both images are possibly referred to from "fake" files in the El-Torito floppy, or comprise the content of these IMG files inside the Floppy, if ISOBuster reflects their sizes incorrectly. In this case the Floppy is pretty big.

 

As to "Find missing..." feature, ISOBuster indeed produced the "other" image and more in both Linux and WinPE ISOs. As was mentioned earlier, the "other" image was not referenced in the CD structure (in a certain way may be?).

 

qx2bma.jpg

 

 

If El-Torito Floppy content is correct (let's assume it is) then the disc is bootable.

 

Is there a way to mount and explore images it contains after extracting the floppy - it appears to be sized and hence extracted incorrectly as per jaclaz? This way we might be able to figure out how the boot sequence works for different FW modes. I know, jaclaz already gave his "opinions" about it.  :)

 

264t0sj.jpg

 

One might assume that the ISOs have dublicate Acronis_Media structure for "uniformity". It looks like "Acronis_Media" internal ISO is used in UEFI Mode in 2014 Linux and WinPE ISOs (but its content becomes either redundant or not detectable by ISOBuster in 2015 Linux ISO), while "Acronis_Media" folder is used in BIOS mode in both ISO types. 

Edited by zamarac
Link to comment
Share on other sites

 

What do you mean by "wrong" size?  :unsure:

 

I know duplicate was "expected" in unspecified cases. "The wrong size" clause came from comparing 140Mb size of the mounted by ImDisk ISO or IMG with actual content size of EFI folder - sorry its correct size now. :}  ImDisk options don't play any role here.

 

Is it possible that both full size images your batch identifies are in fact inside the single El-Torito Floppy, and what we need is to identify correctly the size of that floppy, and mount it by ImDisk in a way that would allow to explore both FAT images inside it?

 

Btw, this thread was read 300+ times for the last 2 days. This shows actual community interest in booting Acronis ISOs directly from HDD instead of extracting their content to a USB Thumb.

Edited by zamarac
Link to comment
Share on other sites

Isobuster deals with these correctly :), listing ALL the available boot images.

Whoohoo. All this was implemented a loooooooon time ago, when I was still a young man ;)

 

Opinions:

  • BootCatalog.cat <- this is a "fake" filename AND IMHO it is NOT a "file" but rather a "folder", and of course the .cat extension is "arbitrary"
  • Acronis.img <- this is a half-fake filename, as the text "Acronis" is actually in the boot catalog entry, but the .img extension is "arbitrary"
  • BootImage.img <- this is a fake filename, as the text in the boot catalog entry is all 00's, and the .img extension is also "arbitrary" as above

From recollection and without checking the code I think you are spot on yes !

 

Facts:

  • The column "Size" is "deceiving", as the data in the entries does NOT mean "size of the image" but rather "size to be loaded", actually the specifications do not have a field for "size of the image"
  • As well the column "Last LBA" is "deceiving" and also actually "wrong" as clearly it is a "calculated field" from LBA+(apparent) size of the image.
  • There is no distinction between the "main" image (Acronis.img) and the second one (BootImage.img)
  • There is no hint about the Type of image or "Platform ID" (it is missing somehow a column), the Acronis.img is type "00" (i.e. 80x86) whilst the "BootImage.img" is type "EF" (i.e. EFI see below)

 

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 ?

 

Now, the fact that the specifications miss a real size for the image and an offset to the actual bootsector when the image, as the "Acronis.img" in the example, is marked as "no-emulation" but contains a whole largish FAT image with a loader prepended to it) and that the good Acronis guys have been "naughty" (IMHO breaking the compliance) with the "BootImage.img" by NOT filling any of the other fields in the entry (apart the 91 for the "last image", the "EF" for the "type" and the 88 for bootable and the actual LBA start) are not good reasons for a tool aimed to "bust" an .iso to "completely miss" the "Acronis.img" and to provide "queer" data for both the "Acronis.img" and the "BootImage.img".

 

It would be nice if your nice tool could *somehow* deal with these little queernesses and provide *somehow*  a way to deal with the "hidden image", i.e. an image that is listed on the boot catalog but that does not begin with a known filesystem data structure such as a bootsector and it's BPB, after all, without zamarac observations, looking at one of these Acronis iso's would have lead to completely "miss" the files listed in post #7: http://www.msfn.org/board/topic/172610-acronis-iso-boot-on-uefi-pc/?p=1084987

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

 

2l5c42.jpg

 

Of course if one "scans" the whole .iso looking for FAT ISOBUSTER willl find the "missing part", but it would be IMHO nicer if the tool could "parse deeper" the actual Boot Catalog entries.

I don't get this second content at all in the file I downloaded ?

Which ads to my confusion ?

 

It would also be nice if (on the left tree) the "unnamed" FAT filesystem were given a "fake name" like:

Start_%lba%_Extents_%sectors%

In the file I downloaded this FAT FS has a proper name ?

Edited by IsoBuster
Link to comment
Share on other sites

IsoBuster

 

I don't know what ISO you were referred to, but this post has links to all 3 different ISOs depicted in various places of this thread. They all have different content, so I had to download all 3, but in each ISO extra files or image (in Linux ISO) were found by "Find missing" feature. 

 

Is it possible that both full size images the "Find Missing" identifies in Linux ISOs are in fact inside the single El-Torito Floppy, and what we need is to identify correctly the size of that floppy and files inside it, and extract the floppy in a way that would allow to explore both FAT images inside it?

Edited by zamarac
Link to comment
Share on other sites

but it would be IMHO nicer if the tool could "parse deeper" the actual Boot Catalog entries.

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.

Link to comment
Share on other sites

IsoBuster

 

I don't know what ISO you were referred to and by whom, but this post has links to all 3 different ISOs depicted in various places of this thread. They all have different content, so I had to download all 3, but in each ISO extra files or image (in Linux ISO) were found by "Find missing" feature.

I downloaded: ATIH2015BM_WinPE5.iso

It doesn't seem to contain the second FAT image ?

 

IsoBuster

Is it possible that both full size images your batch identifies are in fact inside the single El-Torito Floppy, and what we need is to identify correctly the size of that floppy, and mount it by ImDisk in a way that would allow to explore both FAT images inside it?

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.

Edited by IsoBuster
Link to comment
Share on other sites

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

Yes, this is the idea.

The no emulation "Acronis.img" contains a proprietary boot loader.

This loader mounts the FAT image located behind the boot loader.

There is no file system or El Torito hint about this FAT image.

The interesting files are located at the FAT image.

The WinPE5 and Linux ISO uses different layouts. Don't mix this two one.

Link to comment
Share on other sites

IsoBuster

 

WinPE ISO has only one small boot image, its evident from this post pics. I suggest to download two Linux ISOs, since they each contain 2 images, but the content of Acronis_Media ISO inside the Linux ISOs as depicted in ISOBuster is different: 2014 ISO contains duplicate content of same name folder, while 2015 ISO is empty. It may be related to how ISOBuster reads the ISOs. This is in addition to "other" image missing issue.

 

While you think that El-Torito floppy content is not important, since all files are located on CD somewhere anyway, if fact it is important. This is because once that Floppy is extracted as an IMG, it can then be copied to a USB Thumb where content of Acronis ISO is also extracted, to make the Thumb bootable. So its quit important to understand how all these files are linked to each other, and what's actually inside this Floppy and each file inside it, as some adjustments may be required. I still "think", both actual images might be inside this floppy. In WinPE ISO, there is also a problem in booting it in UEFI mode, so its handy to figure out content inside the floppy.

Edited by zamarac
Link to comment
Share on other sites

Thanks to zamarac ;) mixing liberally different versions there is a lot of confusion :w00t:.

There are TWO "types" of Acronis .iso discussed in this thread:

a. Windows PE based ones

b. Linux based ones

 

The Windows PE based ones are NO issue in ANY way, they are normal, plain, Windows PE .iso's with TWO images in the boot catalog, they are created according to the "normal" way to create these DVD's:

1) First image is a "normal" El-Torito No-emulation bootloader, 4,096 bites in size, type 0 or "80x86", corresponding to etfsboot.com,  EXACTLY according to documentation (already linked to):

http://support.microsoft.com/kb/947024/en-us

2) Second image is a "normal" (for EFI booting) El-Torito No-emulation floppy image, 1,474,560 bytes in size, type EF or "EFI", corresponding to efisys.bin,  EXACTLY according to documentation (already linked to):

http://support.microsoft.com/kb/947024/en-us

 

There is NOTHING to discuss, doubt or question about the Windows PE based .iso's (with a small exception that is however comprised in the more general issues, and that I might re-highlight later).

 

Please, please, please, let's STOP talking or citing the Windows PE based .iso's for the moment, they have NOTHING "peculiar".

 

Back to the "issues", this is about the "Linux based" .iso's (and NOT about the PE ones).

 

BIOS booting:

We are used to use in traditional BIOS booting any of the 4 El-Torito modes, from the batch:

 

IF %%B==00 ECHO No-emulation image
IF %%B==01 ECHO Floppy 1.20 Mb image, actually CHS nx2x15
IF %%B==02 ECHO Floppy 1.44 Mb image, actually CHS nx2x18
IF %%B==03 ECHO Floppy 2.88 Mb image, actually CHS nx2x36

IF %%B==04 ECHO Hard disk image

The fact that modes 1/2/3 do not really mean "given size floppy image" but rather "with same HS geometry as given size floppy image" is a relatively recent discover by Rloew (and cdob) details are here:
http://www.msfn.org/board/topic/152399-on-bootable-cds-floppy-emulation/

(this shows how even after all these years the actual specifications were not fully clear)

 

Traditionally ONLY actual floppy sized images were used for modes 1/2/3, but as seen this is not really-really what El-Torito says.

 

As well, traditionally for mode 0 a loader was used, commonly:

1) "Arnesbootrecord" or "MicrosoftCorporation.img" image sized 2048 bytes <- Windows install CD's up to Server 2003 and PE's loading SETUPLDR.BIN in the \i386 folder on root of the "accessible area" of the CD (and BOOTFIX.BIN)

2) etfsboot.com sized 4,096 bytes <- Windows install DVD's since Vista :ph34r: and PE's  1.x, loading BOOTMGR in root of DVD (and BOOTFIX.BIN)

3) isolinux.bin based, this is LARGER than 2048 bytes, yet the "size to be loaded" is still 4 sectors, and I had to write a small batch:

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

to extract it properly, BUT the isolinux.bin was also listed in the "accessible area" of the CD

4) grldr (gruib4dos) based, also larger than 2048 bytes, but still with the "size to be loaded" normally set to 4 sectors in the boot catalog and with the grldr file also listed in the "accessible area" of the CD.

 

To recap, we are used to see "No emulation images" that consist in a smallish loader that when booting chainloads other file(s) that is/are on the normally accessible area of the CD.

 

The Linux based Acronis .iso is different:

  • the No emulation image is hundreds of megabytes in size
  • it consists of a loader prepended to a large FAT volume
  • at boot the loader evidently "mounts" this large FAT volume and runs files in it
  • the contents of this FAT volume are NOT (nor the FAT volume itself as an image file)  indexed/listed  in the "accessible area" of the CD

The El-Torito standard does NOT include in the boot catalog entry a field for SIZE of the image, it only has a field for the LBA START (location) of the image and a field for the INITIAL LOAD size:

 

Sector Count. This is the number of virtual/emulated sectors the system will
store at Load Segment during the initial boot procedure.

 

 

Now, if the first sector at the LBA START address of the image is either a MBR (in the case of type 4 or hard disk emulation image)  or a PBR (in case of type 1/2/3 floppy emulation) it is possible to calculate the size of the image from the data in them.

As well, in the case of a No-emulation image where the image is also listed in the "normally" accessible area of the CD/DVD, it's size can be derived from the CD/DVD filesystem (be it ISO9660, Joliet ot Rockridge).

As well (though not written anywhere in the specifications, and yet AFAIK to be found "in nature") if the image is set to no-emulation mode but it's first sector is a PBR (and possibly also a MBR :unsure:) it is possible to determine it's size from the data in this first sector.

BUT the Acronis image has a loader pre-pended (in the image I analyzed 12x2048 sectors or 48x512 sectors in size) so there is no way to know it's real size if not by either "scanning" for a PBR or making calculations from the LBA addresses NOT used in the "normally accessible" CD/DVD filesystem.

 

EFI booting:

I am not familiar with a great number of EFI booting CD's/DVD's, but it is clear from this experience that the specs uses in boot catalog:

a. a Type 0 "no emulation" image

b. an ID "EF"

c. the Initial Load size (even if the MS CD/DVD do set it to 1 sector or 512 bytes) is completely irrelevant as the EFI firmware (unlike BIOS) has a "full featured" FAT filesystem driver and accesses the \BOOT\EFI\ folder and the file bootia32.efi, bootia64.efi or bootx64.efi ignoring it (and the good Acronis guys, in their simplicity ;), set this field to 00's)

d. it is mandatory that the image is a FAT image AND that it starts with a PBR on first sector

 

Now the "issues".

  • Ultraiso takes the "whole lot", including BOTH the "BIOS" no-emulation image AND the "EFI" no-emulation image and exports them as .bif, without differentiating or making access separately to both of them. The .bif file may (but seemingly only the first image in it) be parsable by the same ultraiso (or it may be not).
  • Isobuster has NO issues with the second (EFI) image, as it's first sectror is a PBR and a PBR of a "known" filesystem (FAT) but it cannot do anything about the first image (since it starts NOT with a PBR, but rather with the Acronis loader).
  • The fact that doing a "sector scan" it can find the first image volume fine :thumbsup: is NOT (IMHO) a "solution" (another CD/DVD may contain n other images or parts of them including a valid PBR) and there would be nothing to point out that one among them is part of the first no-emulation boot image, and pertains more to "recovery" than to access .iso contents.
  • IMHO the "visual representation" that Isobuster does of the Boot Catalog as if it was a "file", naming it BootCatalog.cat is partially deceiving, as what the boot catalog represents is a set of addresses/names, not unlike what a directory represents, and as such it would be nicer if it was represented as a "folder" containing the boot images.
  • The data shown when Bootable Disc is selected in the left hand pane is partially deceiveing and/or incomplete or "wrong" :ph34r:, as the only "useful" information in it is the LBA start of the images (the name - as seen - may be "real" or "faked" or "half-faked", the Size column is mislabeled, the last LBA can be either correct or wrong depending if the total size of the image is the same as the size set for initial loading).

The "issues" are of course of relatively low relevance, as - as seen - they can be worked around with a simple batch or by knowing what we have found in this thread and use a disk/hex viewer/editor at the light of these findings, yet I believe that Isobuster could benefit from a more intuitive visual representation of the .iso structure  and from being capable of automatically recognize this particular kind of structures.

 

jaclaz 

 

 

Link to comment
Share on other sites

Back to the "issues", this is about the "Linux based" .iso's (and NOT about the PE ones).

I'm downloading one.

 

As well, traditionally for mode 0 a loader was used

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 ?

3) isolinux.bin based, this is LARGER than 2048 bytes, yet the "size to be loaded" is still 4 sectors, and I had to write a small batch:

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

to extract it properly, BUT the isolinux.bin was also listed in the "accessible area" of the CD

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 ?

4) grldr (gruib4dos) based, also larger than 2048 bytes, but still with the "size to be loaded" normally set to 4 sectors in the boot catalog and with the grldr file also listed in the "accessible area" of the CD.

Same question as before.

 

To recap, we are used to see "No emulation images" that consist in a smallish loader that when booting chainloads other file(s) that is/are on the normally accessible area of the CD.

Except that is not what I see for "BootImage.img" on the BartPE made iso ?

The Linux based Acronis .iso is different:

  • the No emulation image is hundreds of megabytes in size
  • it consists of a loader prepended to a large FAT volume
  • at boot the loader evidently "mounts" this large FAT volume and runs files in it
  • the contents of this FAT volume are NOT (nor the FAT volume itself as an image file)  indexed/listed  in the "accessible area" of the CD
The El-Torito standard does NOT include in the boot catalog entry a field for SIZE of the image, it only has a field for the LBA START (location) of the image and a field for the INITIAL LOAD size:

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 ?

Now, if the first sector at the LBA START address of the image is either a MBR (in the case of type 4 or hard disk emulation image)  or a PBR (in case of type 1/2/3 floppy emulation) it is possible to calculate the size of the image from the data in them.

Agreed

As well, in the case of a No-emulation image where the image is also listed in the "normally" accessible area of the CD/DVD, it's size can be derived from the CD/DVD filesystem (be it ISO9660, Joliet ot Rockridge).

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

As well (though not written anywhere in the specifications, and yet AFAIK to be found "in nature") if the image is set to no-emulation mode but it's first sector is a PBR (and possibly also a MBR :unsure:) it is possible to determine it's size from the data in this first sector.

Right.

Link to comment
Share on other sites

BUT the Acronis image has a loader pre-pended (in the image I analyzed 12x2048 sectors or 48x512 sectors in size) so there is no way to know it's real size if not by either "scanning" for a PBR or making calculations from the LBA addresses NOT used in the "normally accessible" CD/DVD filesystem.

The former yes, the latter no.

 

  • Isobuster has NO issues with the second (EFI) image, as it's first sectror is a PBR and a PBR of a "known" filesystem (FAT) but it cannot do anything about the first image (since it starts NOT with a PBR, but rather with the Acronis loader).

I'll look into this

 

IMHO the "visual representation" that Isobuster does of the Boot Catalog as if it was a "file", naming it BootCatalog.cat is partially deceiving, as what the boot catalog represents is a set of addresses/names, not unlike what a directory represents, and as such it would be nicer if it was represented as a "folder" containing the boot images.

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.

The data shown when Bootable Disc is selected in the left hand pane is partially deceiveing and/or incomplete or "wrong" :ph34r:, as the only "useful" information in it is the LBA start of the images (the name - as seen - may be "real" or "faked" or "half-faked", the Size column is mislabeled, the last LBA can be either correct or wrong depending if the total size of the image is the same as the size set for initial loading).

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

Edited by IsoBuster
Link to comment
Share on other sites

 

As well, traditionally for mode 0 a loader was used

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 ?

 

 

Aha. Aha! ;)

http://www.imdb.com/title/tt0094898/crazycredits?item=cz0003114

 

 

Let's wait until you can have a look at one of these Acronis images.

A number of answers to your questions will become self-evident.

 

Please do have a look at BOTH the little batch provided in the referenced thread:

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

and to the one (latest temporary version) on post # 26

http://www.msfn.org/board/topic/172610-acronis-iso-boot-on-uefi-pc/page-2#entry1085084

 

They are both rather simple, and it is easier if you read their contents to understand the procedures I used.

 

The "main" issue is not connected to Isobuster, it is a combination of a "lack" of info in the El-Torito specifications, with the way Isobuster (mis)represents the field.

With reference to the mentioned specs:

http://download.intel.com/support/motherboards/desktop/sb/specscdrom.pdf

Figure 3 and Figure 5 the value on bytes 6-7 is NOT (as it appears in Isobuster) the SIZE of the image, but the:

 

Sector Count. This is the number of virtual/emulated sectors the system will

store at Load Segment during the initial boot procedure.

 

(this is the value that is "traditionally" set to 4 sectors).

 

So, there is no real way, based on the entries in boot catalog to know the size of the image.

 

Windows up to server 2003 and PE 1.x:

With "Microsoft Corporation.img/ArnesBootRecord" there are no issues, as the loader file is actually 2048 bytes in size (and the Sector Count Field is also set to 4 sectors), if you right click on "Microsoft Corporation.img" and Extract, the result is correct

 

Windows Vista :ph34r: and later (and PE >1.x):

With "etfsboot.com" there are no issues, as the loader file is actually 4,096 bytes in size (and the Sector Count Field is set to 8 sectors), if you right click on "Microsoft Corporation.img" and Extract, the result is correct (the only issue, more philosophical than anything else is that the "fake" "Microsoft Corporation.img" filename is the same as the above)

BUT the "EF" image (which is a "common" floppy disk image, 2880 sectors in size or 1,474,560 bytes) has a Sector Count set to 1 sector, and - obviously - since Isobuster interprets this field as size of the image, if you right click on "BootImage.img" and Extract, the result is ONLY the first sector of the boot image. The extracted file CANNOT be re-used. :(

 

ISOLINUX based:

If you can download the mentioned on the reboot.pro thread Slitaz .iso (it is only around 30 Mb) and open it in Isobuster, and try to Extract the "BootImage.img", the saved file will be just the first 4 sectors of ISOLINUX.BIN (and thus at the time I half-@§§edly solved the issue through the batch). The extracted file CANNOT be re-used. :(

 

Same will happen for *any* .iso where the no-emulation file is actually larger than the size to be loaded initially (Sector Count field in boot catalog)

 

In the Acronis images (NOT the WinPE based ones) the issue with the first image is just like the above, but for the EF image it is even worse :w00t:, as - since the good Acronis guys set the Sector Count field to 0, if you right click on "BootImage.img" and Extract, the result is a 0 byte file.

 

The workaround I used for the ISOLINUX.BIN implies that the file is "listed" in an "accessible" part of the filesystem (and at the time considered only one entry in the boot catalog and would not work for the "EF" images of all kinds, since they are not "detected" by isoinfo.exe), the workaround I used now is to attempt parsing the first sector of the image looking for a FAT PBR and use that data (which works for all the "EF" images - since their first sector is actually a FAT PBR - but fails for the "special" Acronis first image) then I added temporarily a workaround to the workaround :ph34r:, parsing  a bunch of sectors until I find (hopefully) a FAT PBR, but still it won't work with an ISOLINUX.BIN or GRLDR no-emulation bootsector.

 

What Ultraiso seemingly does is to consider *anything* after the boot catalog and before the first "indexed LBA in one of the filesystems as "boot information file" and saves the whole lot of it as .bif. 

 

I have not right now a "valid" idea to solve all these issues, the only thing I can think of is to combine these different approaches, though cannot really say "how".

 

jaclaz

Link to comment
Share on other sites

If you can download the mentioned on the reboot.pro thread Slitaz .iso (it is only around 30 Mb) and open it in Isobuster, and try to Extract the "BootImage.img"

Could you point me to this image as well please ?

I'll look into it shortly

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