A)

I was looking into the $CPD manifest which is the start of FTPR region. As we said before we are interested in the .met sections. Each one is 0x30 in size and the first 0x14 bytes are structured this way:

name.met + "padding/filler" + pointer [4] + size [4]

The pointer [4] is always at end end of the first 16-byte row. The size [4] is right after the pointer. The name depends and so between that and the pointer some 00 "padding" exist. This padding varies of course. Visually:



So far I haven't found the way to determine quickly how many .met sections are there. Previously we had to look at the $MN2 header (exactly after the $MN2 text if I'm not mistaken) but at ME11 this is always 0.

Each pointer leads to the contents of a .met section and all of them have this header to signify the beginning: 0A 00 00 00 38 00 00 00 02 00 00 00 00. Visually:



EDIT 14/04/2015: The above is sort-of correct. Turns out, all sections under $CPD are 0x18 bytes and are categorized as .man (manifest, $MN2) , .met (MetaData) and no_extension (text) which includes info about the upcoming .met section. Structure:

Manifest (.man , 0x18) --> Name [0xC] + Pointer [0x4] + Size [0x4] + Reserved [0x4]
Meta Data (.met , 0x18) --> Name [0xC] + Pointer [0x4] + Size [0x4] + Reserved [0x4]
"File"/Data (text , 0x18) --> Name [0xC] + Data [0x7] + Reserved [0x5]

For "file", maybe Reserved is [0x4] and Data is [0x8] but not sure yet.

Also, the number of $CPD sections can be found right after $CPD so for 11.0.0.1120 firmware that is 2D or 45 such 0x18-byte sections. Visually:



B)

Now, regarding the SKU. There is a chance that "skumgr" is the place to find it. I checked the known ME firmware and $SKU always existed under only one $MN2 region, the one inside FTPR region. With that in mind, I extracted the FTPR of ME11 and the only reference to SKU in there is the text "skumgr" under policy.met section with a full size of 0x12 (including the probably useless 00 at the start & end).



There is a very high chance I'm completely wrong on this one but until I have new firmware or someone proves otherwise, ME Analyzer will be using that as a point of reference.





C)

I was also informed that there is a utility out there called "UnHuffME" which is mainly build to find and extract the Huffman compressed sections of ME 2-10/SPS 3 firmware. It seems that the dictionary is now almost entirely known. Generally, the tool resembles a little bit Igor's unpack_me. As far as ME11 is concerned, obviously it's not supported yet but and it can still show the partition table entries. Coincidentally, it resembles the picture I made 2 days ago about pointer, size & empty regions:



I had visited that website in the past as well but there was less info and not any such useful tool available. Anyway, this is the LINK if case you are interested.

Updates:

NEW! Intel MEI Drivers & Software v11.0.0.1115 for Consumer/1.5MB systems complete package
NEW! Intel MEI Driver v11.0.0.1115 INF for manual installation

Source: Station-Drivers

Note 1: The latest v11 drivers are usable with all Intel chipsets from 6-Series & up (including Skylake 100-series).

Note 2: This is the first driver since 8.1.40.1416 (9.0.0.1287) that does not cause error code 10 or 43 after wakeup from sleep on certain Z77 systems.

All ME drivers are WHQL. The "install & forget" type. Alpha/Beta or not, I don't know in this case because I don't know the source. It's very likely that 11.0.0.1115 is a beta release though if you think that Skylake will be released in the future.

@lordkag

I realized that the 0x30 theory is wrong yesterday but for some weird reason I never noticed that the "text" is always followed by a .met of the same name. It was right in front of me the whole time. LOL. Anyway, the latter and the fact that the number of sections is after $CPD were told to me by the user sewers and I thank him for that.

And yes, it's "File" (text , 0x18) : Name [0xC] + Data [0x8] + Reserved [0x4]

Speaking of the "text": My first thought when looking at the text/data was that indeed it follows the same structure as .man & .met even with pointers out of the SPI image, but there is something strange. Instead of 0x, the sections "rbe", "kernel", "syslib" & "bup" use 2x as a pointer. These are all the text sections under $CPD with that observation:



Due to that "anomaly" I concluded that it's actually data [0x8] and not pointers [0x4] & sizes [0x4]. Today, sewers told me that these are probably a flag. I'm thinking that maybe 00 means SPI image and 02 refers to somewhere else at the rest of the firmware inside the ME co-processor.

The protected ones (02) start with 00 00 00 40
The rest of them (00) start with 36 00 40 00

Yes, 02 is probably a flag. Compression makes a lot of sense since as you said these sections are protected. The previous ME were protected with the custom Huffman method if I'm not mistaken. That's why the tool I mentioned above is important (UnHuffMe).

Edit: It doesn't make sense for 02 to be part of the size, it would break the current "structure". So even the 02 ones actually point to the SPI image but their contents are compressed. Whether the size represents the compressed or uncompressed section, I don't know. Makes more sense to be the latter as you said since following that size leads nowhere in the current form.

Zitat von lordkag im Beitrag #1126

---

They take everything until the next pointer?

---

Thank you CodeRush for the input.

Lordkag: Most probably that size is the uncompressed one. I tested both (via header size & by manually finding the end of section) and the image from the header size is always larger. I couldn't figure it out where the compressed size is. Maybe at the .met of each section or the general FTPR $MN2 manifest. Enough progress for one day.