UEFIExtract: Cannot get the uncompressed body of LzmaF86 section

[platomav]

Hello,

Given an UEFI image, my goal is to retrieve the uncompressed bodies of LZMA-F86 compressed sections. The LZMAF86 GUID is D42AE6BD-1352-4BFB-909A-CA72A6EAE889 (BDE62AD45213FB4B909ACA72A6EAE889), thus I decided to use UEFIFind followed by UEFIExtract.

UEFIFind_NE_A68 U30_1.42_06_20_2018.signed.flash header list BDE62AD45213FB4B909ACA72A6EAE889

UEFIFind returns the following:

• 9E21FD93-9C72-4C15-8C4B-E77F1DB2D792
• 299D6F8B-2EC9-4E40-9EC6-DDAA7EBF5FD9

UEFIExtract_NE_A68 U30_1.42_06_20_2018.signed.flash 9E21FD93-9C72-4C15-8C4B-E77F1DB2D792 -o output -m body -t 17

The above fails with Code 8 (I think it means FILE not found). I used type 17h to get the Volume image section in this example, which should be included within that GUID.

What is strange is that using either "-m all" or "-m info" does work. But not "-m body" or "-m header". And the only one which seems to work correctly is "-m info" because "-m all" appears to dump the entire image tree but with all other folders empty in terms of bodies, headers, info etc.

I also tried to use type 02h which is what UEFITool shows as the section type of the LzmaF86CustomDecompressGuid, but that never works (same error 8).

In general, the goal here is to get the exact same result as when using UEFITool, right-clicking LzmaF86CustomDecompressGuid and selecting "Extract body uncompressed". Moreover, choosing a section type 17h for example does not work for the 2nd GUID because it has no Volume image within. So, the type should be omitted (FF) but then nothing works.

Am I doing something wrong? I cannot really understand the output of UEFIExtract.

U30_1.42_06_20_2018.signed.zip

[NikolajSchlej]

Could not react sooner, but I'll check this out.

[NikolajSchlej]

This will require additional commandline syntax because for compressed items, their body and compressed_body are 2 different blobs, with the later not even getting saved by UEFIExtract anywhere, and not getting enumerated by UEFIFind the same way.

[NikolajSchlej]

Should be fixed after ff42cec

There's no good way to get an actual body (because header stripping is done differently for this special case), but it should not be a blocker.

[platomav]

Thanks for the update, @NikolajSchlej. I still see Error 8 though on the attached sample, with either "body" or "unc_data" modes:

UEFIExtract.exe U30_1.42_06_20_2018.signed.flash 9E21FD93-9C72-4C15-8C4B-E77F1DB2D792 -o output -m unc_data -t 17

[NikolajSchlej]

Investigated further, the main issue here is with the on-by-default limitation of "we only need to dump the leafs from the item tree if the mode is not DUMP_ALL", which was expressed as "if a given item has child items, skip it". That volume image file does indeed has children, so it is getting skipped unless DUMP_ALL is also set, but it's currently impossible to set such a combination from the command line.

The proper fix for this would require a bit of reworking on how the recursive tree traversal works. Meanwhile, you can work around the current behavior by dumping all everything, filtering out the required unc_data.bin files, and removing the rest. It is not ideal, but possible.

[platomav]

Trying with "all" mode, I see the following:

I cannot find any "unc_data.bin" blob to be honest.

Edit: I forgot to remove the type (-t 17), the workaround works without it, as you described.