Out-of-bound flash region scenarios

[staslyakhov]

With some newer generation Intel platform (Birchstream) IFD images and I ran into a few scenarios that cause a java.io.IOException: Out-of-bounds flash region in firmware.ifd.IntelFlashFileSystem. I've identified a few reasons for this:

Details

• The ME and Gigabyte regions have both been removed (marked as unused), leaving only the BIOS region behind. I've added some logging to make this clear while the fs is being parsed (note that base = 0x7FFF000 is a marker for an unused region):

DEBUG  Region BIOS. (base = 0x1000, limit = 0x3FFF000 (IntelFlashDescriptor)
DEBUG  Region Intel Management Engine. (base = 0x7FFF000, limit = 0x0 (IntelFlashDescriptor)
DEBUG  Region Gigabit Ethernet. (base = 0x7FFF000, limit = 0x0 (IntelFlashDescriptor)

• This image has another caveat: there are two flash chips that are memory mapped one on top of the other. We can see this by looking at the flash descriptor, which tells us that there are two flash chips (number of flash chips = 0 implies there is 1 chip. If it's set to 1, there are two chips!) and the platform data is still present (mapped on top of the BIOS region).

ERROR Number of flash chips = 1 (IntelFlashDescriptor)
...
ERROR Region Platform Data. (base = 0x4000000, limit = 0x5FFF000 (IntelFlashDescriptor)

This also causes a crash due to Out-of-bounds flash region. This is a bit of a shame since it is common for the code part (the one we're interested in reverse engineering) to be available in the initial in-bounds image, and it would be nice if this didn't cause a crash

Possible Solutions

As a workaround, I removed all addRegion calls but the first one aimed at FlashRegionType.BIOS.

For a proper fix, it might be worth either handling the IOException more gracefully, or avoiding the assumption going forward that all four (BIOS, ME, GIGABIT, PLAYFORM_DATA) regions are always used and available.

Since GitHub won't let me upload it, an example image can be extracted from Dell's website (e.g. using binwalk on the image, and then again on the capsule in the payload/ directory).