Some SPI images have Engine firmware kept at specific GUIDs as well. These are usually for recovery purposes or enforced downgrade methods like the ones used by ASRock and ASUS from time to time. MEA notifies the user that an Engine firmware may be found under that GUID for him/her to manually extract and check. Sometimes those GUIDs are valuable because they tend to hold RGN (clean) firmware compared to the EXTR (configured) pointed at the Engine Region of the Flash Descriptor.

ME Analyzer v1.6.0 :

ME Analyzer is now Open Source, licensed under GNU GPL v3
ME 11.0 SKU is now automatically detected when possible
Added parameter to scan all files of a given directory (-mass)
Help screen now shows all (previously) hidden parameters
Fixed issue that caused always showing FD lock state
Removed parameter -info for viewing system's versions
Updated Intel Engine Firmware Repository Database to r62

Engine Firmware Repository Database r62 :

Latest ME 11.0 COR H SKU to 11.0.17.1002
Latest ME 11.0 CON LP SKU to 11.0.16.1000
Latest TXE 1.0 3MB IT SKU to 1.0.3.1164
Added ME 11.5.1.1006_CON_LP_XX_UKPDM_PRD_RGN
Removed ME 11.5.1.1006_CON_LP_XX_UKPDM_PRD_EXTR
Added ME 11.0.17.1002_COR_H_D0_UKPDM_PRD_RGN
Added ME 11.0.16.1000_CON_LP_C0_UKPDM_PRD_EXTR
Added ME 11.0.12.1003_CON_H_D0_UKPDM_PRD_RGN
Added TXE 2.0.0.2058_1.375MB_PRD_EXTR
Added TXE 1.0.3.1164_3MB_IT_PRD_RGN
Added SPS 02.04.00.043_PRD_REC
Added SPS 02.04.00.043_PRD_OPR

ME Analyzer v1.6.1 :

Added ME 11.6 KBL firmware detection
Impoved ME 11.x SKU detection based on Kernel
Updated Intel Engine Firmware Repository Database to r63

Engine Firmware Repository Database r63 :

Latest ME 11.6 CON H SKU to 11.6.0.1102
Latest ME 11.6 CON LP SKU to 11.6.0.1102
Latest ME 11.6 COR LP SKU to 11.6.0.1069
Latest ME 11.5 COR LP SKU to 11.5.1.1006
Added ME 11.6.0.1102_CON_H_XX_UKPDM_PRD_EXTR
Added ME 11.6.0.1102_CON_LP_XX_UKPDM_PRD_EXTR
Added ME 11.6.0.1069_COR_LP_XX_UKPDM_PRD_EXTR
Added ME 11.5.1.1006_COR_LP_XX_UKPDM_PRD_RGN

ME Analyzer v1.6.2 & DB r64

@ SoniX:

TXE3 is not supported because MEA is not ready for it. Intel has changed many things at APL. The TXE is not kept as a "region" at the SPI but more like parts. So that's why MEA shows the firmware as "Update", it cannot find the Engine header because it's not there. From what I can see, FIT v3 can "rebuild" a TXE region but with a slightly different header (not detected by MEA properly yet) and with fewer subsections, only those included at the SPI image. FIT is now able to load CPU Microcodes and some new type of OEM-specific modules. These modules all use the same ME11.x manifest format (apparently Intel wants to use it everywhere) which causes MEA to go bananas because these are not Engine firmware. It's messy, thankfully there is some documentation to guide us (Lordkag, you and me) in order to add support at some point in the future. Needless to say, UEFITool doesn't work at all with APL/BXT SPI images too. Unfortunately I don't expect it to be updated now that CodeRush is out of the picture. Hopefully I'm wrong.

So to answer the question, to "extract" the TXE region use FIT v3 and check the decomp folder. For BIOS, the BIOS_Region.bin of the SPI image which is easily extracted by FIT v3 (until UEFITool can support APL) now has a small header with subsections (name 0x4 + offset 0x4 + size 0x4 + reserved 0x4). I think the actual BIOS we are interested at is the 3rd section (largest) called ΝOBBP.

As for this TXE3 firmware, run MEA with command -prsa and if you see the following then I have the firmware. Otherwise, please report everything different.

Thank you for the reply CR. I have found APL SPI from three different OEM and all their images are like that. Also, their SPI work at FIT whereas the fixed FD ones that I tried yesterday crash it. You certainly know what's what but this what I've seen so far:

This is the APL structure which differs depending on whether it's SPI or eMMC (No FD).





The BIOS region has changed a little bit a header and Engine Manifests at the start of each section (I assume so that integrity can be verified at boot by TXE). That is currently treated as padding.





The TXE does not have it's own Region but (I think) is included at the BIOS with it's settings at a different OEM-dependent and signed module (SMIP). The region seen at the FD will be used for TXE ROM-Bypass only or something like that. There is no FWUpdate tool and so on.



There are a lot more stuff but I don't have the time to check it out in detail now. Maybe I'm wrong and the changes are not that major but from what I can read and understand, that's not the case.

EDIT: Just a quick note, I am not asking you to update UEFITool. I know you cannot. It's just an explanation as to why I think it's not just a FD mess-up.

@CodeRush

Thank you a lot for the detailed explanation. From personal experience I know it must have taken time to find out what's wrong, create the pictures, analyze it in such a way for me to understand etc.

So in actuality the problem is that the BIOS region is larger than the size assigned at the FD for it and thus crosses into DevExp. In your original modded files I remember that only the FD was changed (no BIOS) so I assume that you shranked the DevExp to start after the last BIOS section at 0x384000 with default size of 0x417000. Am I wrong? Maybe the DevExp has a standard size or at least a minimum one and that's why FIT crashed. In theory, what you proposed now (fix the last BIOS section to have a smaller size manually) should not cause any FIT problems. I haven't tested it but maybe that was the issue with the originally modded images.

Since I haven't read the EFI specs, I found manually where the size of each volume is kept by searching for the _FVH signature and moving some bytes to the left if I remember correctly. After I did that the image did work at UEFITool NE A32 but I noticed two things a) UEFITool said that the size should be 0x417000 based on some other calculation and b) the image does not really work with MMTool. For the future, to manually fix some images, is there something else that we need to change manually apart from the size (so that starting offset of last volume + fix_size = end of BIOS at FD/start of DevExp) in order to avoid these irregularities I mentioned?

Correcting one earlier statement, I found this exact issue at two difference OEMs, not three as said earlier. It's weird that both did this stupid thing. I'm wondering if they will fix it once the last volume size is actually big enough to (wrongfully) store data at the DevExp or when DevExp is not empty. It's also weird that the FD's DevExp size ends before the actual end of image and thus the last 0xFF are left unused so they are correctly treated as padding by UEFITool.

Now, to correct the second statement I made earlier. UEFITool does work with APL images (thanks to it's versatility and feature-proof code writing). It's the SPI images I tested which are broken, so OEM mess-ups.

Last, what is still true. There are plenty of changes at the BIOS modules (new modules like SMIP, Engine $MN2 manifests before each of the three BIOS sub-sections etc) and at the Engine region (part of BIOS) side of things. These are not causing issues at UEFITool but maybe in the future it can detect them properly one by one and extract/replace them instead of being treated as padding. This is not urgent though and we still have no idea how these work, what info they store, how can they be changed, whether modifications will even work without resigning etc. So I mention it for the sake of it, as a future enhancement of sorts.

Zitat von CodeRush im Beitrag #193

---

I don't know the requirements for APL FIT because I haven't used it yet, but if it crashes on a descriptor without DevExp - it's clearly a bug in the tool.

---

Zitat von CodeRush im Beitrag #193

---

Volume size is stored in 2 places

---

Zitat von CodeRush im Beitrag #193

---

I don't think it's needed to add any support for this TXE parts

---

Zitat von CodeRush im Beitrag #193

---

Please create an issue about new TXE support here, so more people can see it.

---