Intel ME System Tools v11.0 r14:

Flash Image Tool: 11.0.0.1194
Flash Programming Tool(DOS, Windows, Windows64): 11.0.0.1194
MEManuf(DOS, EFI64, Windows, Windows64): 11.0.0.1194
CCT(DOS, EFI, Windows): 11.0.0.1194
Manifest Extension Utility: 11.0.0.1194

If you want it just for that, it's not worth the trouble. The ME region is usually locked from read/write access so it won't be updated when you perform a BIOS/SPI image reflash either way. Besides, you can use FWUpdate tool to quickly update it if you want which is very easy compared to most other firmware of any such kind out there. Otherwise, download latest ME, open the OEM SPI image with Flash Image Tool, open the latest ME with another Flash Image Tool and start transferring settings. To extract only the now-configured ME region make sure the Number of Flash Components at the Flash Descriptor settings of FITC are set to 0. Then replace the old ME Region of the SPI image with the new either manually via a Hex Editor or with UEFITool after making sure the size of both modules is identical. An old guide can be found here (for reference only).

1. UBU does not interfere with the ME region, only the BIOS region. The tool that shows such info is MEA and UBU happens to call it as well for users to also know their ME firmware. But the showing of ME info is not part of UBU.
2. It's FPT (Flash Programming Tool) and not FTP (File Transfer Protocol). You can use that with command -d spi.bin to check if your Flash Descriptor is locked and thus the ME read/write rights. A "cpu access" or similar errors means it's locked, otherwise it's unlocked.
3. You do not seem to understand what UBU and MEA do exactly. They display/mod info of the SPI image you want to flash and not what's already flashed inside the SPI chip. Read this.

What MEA reports as "unlocked" is the Flash Descriptor of the SPI image and not the SPI chip's. You could have a locked flash descriptor yet the SPI image from the OEM report Unlocked. It doesn't matter because the SPI image you are about to flash cannot alter the already locked SPI chip's flash descriptor. However, if your SPI chip's FD is unlocked and you flash a SPI image which has it locked (according to what MEA says) then your SPI chip's FD will be locked as well after flash completion. Since you were able to dump your full SPI image with FPT and MEA does detect a ME region inside then yes, your SPI chip's FD is unlocked.

Read the first post carefully to learn whether you can get "unstuck" from 9.1 firmware. If you see something that points to that then go for it, otherwise it's obviously not possible.

Zitat von davidm71 im Beitrag #1889

---

For example FITC when it dumps the ME region the size of the file doesn't match a production ME firmware release by like 400 kbs. The copy paste method was very specific how many bytes to select but it didn't match.

---

Zitat von davidm71 im Beitrag #1889

---

Second are there serial OEM keys that need to be transferred? On my bios dump I didn't see any in that according to FITC they were all zeros.

---

Zitat von davidm71 im Beitrag #1889

---

Also even though my ME passed diagnostic tests certain Intel features are disabled like Intel anti theft feature and others. Can they be enabled?

---

Zitat von davidm71 im Beitrag #1889

---

Lastly if I had a locked ME is FITC what you use to unlock? Saw one true false option somewhere in there for overriding writes.

---

Zitat von lordkag im Beitrag #1892

---

Isn't there a better way? If the ME is intended for the same system, wouldn't it be easier to just update on one system, dump and then copy that ME Region with UEFITool?

---

What you are missing, at least for 5MB/Corporate, is MEBx. That is configured by each individual user for his/her own system. The OEM defines the manageability mode in FITC but the rest are user configurable like IP, Password and so on. For example, if user A assigns a MEBx password and shares his dump, user X won't be able to access the MEBx settings afterwards without knowing that password. Such and other info are kept in the ME firmware on the field (after FITC). Also, LOCL, even though I don't have experience with it, I assume that if user A uses Spanish for SOL then the SPA $LOCL will be transferred as well in firmware. The second argument might be wrong but the first seems solid to me.