Preserve padding area and non-allocated space during parsing and extraction

[timevortex]

Hi,

From manual poking around, I've found that some manufacturers use unallocated space or padding area within BIOS region to store data in a propriety way. It would be great if uefi_firmware would preserve these areas during parsing so we can look in them to see if they're anything other than 0xFF.

My understanding is that currently the way search_firmware_volumes() is implemented in utils means that everything without '_FVH' magic is just ignored.

Example of a BIOS with these sections as seen in UEFITool: http://imgur.com/6LXQN7r This screenshot contains three different types of empty spaces as recognized by UEFITool: 1) "Padding" 2) "Volume free space" 3) "Pad-file"

Thanks! Parth

[NikolajSchlej]

There is no need to unpack "Volume free space" type of element, because it's either all zeros or all ones, depending on "erase polarity" attribute of the volume. Instead of it, you should add "Non-empty pad file" to the list, because some manufacturers like to add their data into pad files, which is against the spec. Right now, the master branch of UEFITool can't preserve such kind of data because all pad files are removed during image reconstruction, but it will be done for NE branch soon.

[timevortex]

Thanks @NikolajSchlej for clarifying. The use case I'm thinking of is more around extraction and then comparison with another extracted BIOS rather than reconstruction.

I really like how uefiextract preserves everything on extraction and doesn't throw anything away, including "Volume free space", "Pad-file" and "Padding". There is a clear one-to-one correlation with parsing and extraction. This is really nice to have and would be great if uefi_firmware would do the same or similar for at least the non-empty padding.

[theopolis]

Hey @timevortex, is this still on your radar, aka would it be helpful and/or are you working on a patch?

[skochinsky]

AFAIK the more common term for such non-empty areas is (ROM) Hole.