[AMI PFAT Extractor] Issues while unpacking TigerLake PFAT image for ASUS ZenBook Flip S UX371 about biosutilities HOT 5 CLOSED

The structure is the same thankfully. The issue is with that line only. I expect that blocks[i][2] is either 0 (No) or 1 (Yes) but the last section (BU.bin) has a value of 9 (1001b), so the list overflows. That number is probably a 4-bit flags field instead.

I've fixed that internally but commenting out that line should still produce a valid image. And it does, I checked via UT. What do you see that is out of the ordinary?

from biosutilities.

The image doesn't really look valid, i.e. it has ME at the very end of it, and and expected VTF to be there instead.

from biosutilities.

Alright, here is what I've understood about PFAT:

1. The BIOS Guard (PFAT) SDK is from Intel. That includes any data within the "PFAT Block Header" & "PFAT Block Script" sections.
2. The AMI implementation of the PFAT SDK is called AMIPFAT. That includes any data within the "PFAT Main Header" and "PFAT Block Signature" sections.

This script unpacks AMIPFAT. The next version (3.x) will fully support/unpack the Intel PFAT SDK (Block Header, Script) with the help of BIOS Guard Script tool by @allowitsme (need to verify its license first) for the BGSL section. Example:

AMIPFAT does not have an explicit file/FV order. The AMI BIOS Guard Firmware Update Tool (AFUBGT) updates files/FV based on the Main Header Flags/Parameters (probably /P /N etc) and each file/FV's Entry Flags. The exact contents of these two flag fields are unknown to me so their hex representation is shown instead.

Since no order exists, the extractor will save each file/FV separately (like Dell PFS) and the user will have to pick and choose. However, I also plan to keep 1 merged image of all of them (like before, v2) for whenever that makes sense. Sometimes OEMs wrap an entire SPI image (FD, CSE, BIOS/EC) into an AMIPFAT and in such cases, the merged file is an actual flashable SPI image. But not always, it depends on OEM design during AMIPFAT creation.

Now, regarding any data after AMIPFAT, these will be saved as the last file/"FV" for the user to manually look into. Their contents are not standard and vary depending on OEM design/needs. However, if this extra data includes an additional AMIPFAT, the script will automatically unpack it as well. Example:

In this example, the input PFAT has some files (1_x -- *****.bin) and their merged image (1.bin). However, at its end data (1_10 -- DATA_AFTER_PFAT_1.bin), another PFAT exists so it is automatically extracted as 2.bin and 2_x -- *****.bin accordingly. Any additional PFAT would be 3.bin, 4.bin etc.

Does this look proper to you as well? Also, if anyone has better name suggestions for the merged file (1.bin, 2.bin etc) and the last file when data outside the PFAT exist (DATA_AFTER_PFAT_X), I am all ears (eyes?). 😛

from biosutilities.

Does look better for sure.

from biosutilities.

fa1283e

from biosutilities.