OOB region too small to fit the whole DXE volume free space, needs a workaround

[Kostr]

Recently I've encountered an image (BIOS.zip) in which UEFITool can't parse DXE volume.

For example here I search for (D6A2CB7F-6A18-4E2F-B43B-9920A733700A = DxeCore) and as it can be seen this GUID is only found in the unparsed padding area:

At the same time MMTool successfully finds the DxeCore EFI module:

Not sure if this is relevant, but UEFITool outputs some debug information at the image load:

Can I get some hints about what is wrong and how can I get DXE FV and parse it with the UEFITool?

[NikolajSchlej]

Nice catch!

The problem with this particular image is that a volume of 0x407000 bytes is inserted into an OBB region of 0x37A000 bytes, and Intel FIT (the software that created all those structures) has no diagnostics to detect that, but UEFITool has some.

It is a problem with the image itself, and it will stop being harmless and start breaking the image once the actual non-FF file content of that volume will become larger than 0x37A000.

I don't have any ideas yet on how to fix it in UEFITool other than creating "bruteforce" parsing mode that would ignore any non-UEFI structures.

[ulion]

Same issue with the OBB and 0x37A000:

afuwin.rom.zip

[platomav]

(this is a copy of chipsec/chipsec#2483 but decided to place it here as well because there are samples which can be used to potentially add a workaround for this - mostly IFWI 2.0 - issue)

There are cases where the last FV of an UEFI image has a larger reported size than what's actually available within the image and/or SPI region. This appears to happen when vendors build UEFI images and (intentionally ?) cut padding at the end of the last volume, presumably to save flash space, but without adjusting the FV header (and/or blocks) accordingly.

Asus_E203MA-AS.302.zip
Asus_E410MA.300.zip
Dell_1_System_BIOS_v1.28.0.bin.zip
Intel_R01010009_TennesseePass_LBG_ICX_UpdateCapsule_prd.bin.zip

The most common example of this is the IFWI 2.0 implementation from the APL, GLK and GLK-R platforms. Most (if not all) SPI images using IFWI 2.0 have the last FV cut-off, either completely or by stepping into the contents of the (unused/padded, usually) DevExp SPI region. This was first spotted ~9 years ago, when APL first came out:

• https://winraid.level1techs.com/t/me-analyzer-intel-engine-firmware-analysis-tool-discussion/30876/189?u=plutomaniac

For example, in this picture, you can see that the FV within IFWI (2.0) > BPDT 2 > OBB is cut off because its header reports size 0x410000, but its contents cover the first 0x36B000:

There are also cases where that last FV is separated (outside IFWI structure) but still cut off:

[NikolajSchlej]

Looks like we could try tolerating the "free space" in FFS volumes being cut out, but only if there's nothing else in there, because it is clearly a working way to build an image (even if it breaks the spec yet again).

[platomav]

In that case, it would need to be contained within a given SPI (Intel FD) region at least. So that if DevExp1 is used but the "BIOS" (IFWI 2.0) region ends with a partial FV, it will be allowed. If no Intel FD is detected, then available data until EoF or volume-declared size.

It should also be possible to detect the presence of IFWI 2.0 and only tolerate this (Intel FIT) spec-breaking behavior for those UEFI-like blobs only.