Oh you were talking about the Most Significant Bit, alright. Got it now. So that way it shouldn’t matter what $MN2 header ME Analyzer scans. Currently, it has to take that into consideration. Whether it’s C0 or whatever it’ll detect that it’s not Production. Basically Production is 0 and PRE/ROMB are 1 when looking at the MSB. I’ll see if I can add that to ME Analyzer. Thanks for the suggestion.
.
Yes. Only the Intel MEI driver is required, not the additional software.
Pure drivers don’t have and don’t need an installer. You can install all drivers directly from within the Device Manager (by doing a right-click onto the related device and choosing the option "Update Driver Software…").
.
Since the OP has been created by plutomaniac, only he knows the answer, but I suspect, that this is the original installer of the complete Intel MEI Drivers & Software Set v10.0.39.1003. The size difference is obviously caused by the removal of the other MEI Software components.
If you want to get the pure Intel MEI drivers v10.0.30.1054 without using any installer, please use the attached package.
Intel MEI Drivers v10.0.30.1054 WHQL.rar (3.01 MB)
Regarding the installer: Oubadah is right. The installer is not a modded version of the full driver. At the 5MB kits there is a folder called MEI-Only Installer. It contains usually only one small file that directly installs the MEI & SOL drivers.
Regarding which driver to install: Fernando is right. For your Z97 system (1.5MB ME firmware) only the installer is really needed.
Small correction: Really needed is only the driver and not any installer.
By the way: Both Intel ME architectures (1.5M and 5M) are using the same Intel MEI Driver, but different Intel ME Software…
Updates:
Re-Upload: Intel MEI Driver v10.0.30.1054 MEI-Only Installer (repacked to reduce size from 9.24MB / 45% → 6.39MB / 31%)
Added: Intel MEI Driver v10.0.30.1054 INF for manual installation
Added: Intel MEI Driver v9.5.24.1790 INF for manual installation
Added: Intel MEI Driver v9.0.0.1287 (8.1.40.1416) INF for manual installation
Added: Notice regarding KMDF 1.11 driver under Windows 7 (section A)
Redesigned: Section A (MEI Drivers) to fix all misunderstandings
Before:
After:
Is this the latest IME firmware for my Msi Mpower Max ac z97 mb.Me anilizer showes I have firmware version: 9.1.25.1005 .
So yes
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.
Hey all, wanted to thank everyone involved in this thread for all the information and updates.
In any case, is this new driver a beta release as mentioned at station drivers?
If so do you feel it’s stable enough to be recommended just installing and forgetting about it?
Maybe note whql official and beta/stable on first page download links in the future?
Thank you pluto and fernando and everyone else for the drivers here and on station drivers for the last couple of years I have appreciated them greatly.
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.
@plutomaniac
I was about to say we have the same ideas with small differences. But then I saw your edit and it is what I also observed. It is neither visually nor logically appealing to say the pointer is at the end of the 0x10 bytes, it is easier to say that the name has 0xC bytes reserved and the rest is filled with null bytes, if the name is shorter. I agree with the size of sections being 0x18 and the number being after $CPD. The data sections might also follow the same structure, just that the pointer is outside SPI. Even if it is not the case, the reserved should still be 4 bytes, it is not OK to have 7 with 5 when you can have 8 with 4. And the metadata section should always follow data section, because it is related to it, it makes no sense to have a metadata section without something to describe.
The extensions name makes sense, which makes me think that $CPD must also mean something. Either way, with one single image you covered more than enough. Without a second version and at least one corporate, there’s not much to extract without running in a circle.
@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.
ME11_Text.rar (388 Bytes)
Well, when I use 0x it is meant as hex number, thus 0x4 is 4 in hex = 4 in dec, 0xA is A in hex = 10 in dec and so on.
They are pointers. It is too random to be a flag, too precise - like a size, plus the names tells you what important they are. If kernel is not to be protected, then what is?
Edit: and the 02 in front of those protected regions from co-processor is not a flag, but part of the size. Today’s SPI are 0x800000 or 0x1000000, so 0x2XXXXXX will fall outside SPI and be interpreted as 0xXXXXXX in the protected region.
Here is something weird. Ignore the starting 02 and take the rest of the size. Every section will start with 00 00 00 40 … But the size is wrong, it could mean that the rest is continued on the chipset?
Edit: it could mean that the decompressed size is the one from size [0x4]. So 02 will be flag for compression. Either this or the rest is on chipset.
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.
I first thought that it is a sign to jump over SPI size and into co-processor, but then I saw how tidy they are and went to that pointer. It makes sense now, except the size next to it. Apart for decompressed size, I don’t know what it could mean. But how they know what is the compressed size? They take everything until the next pointer?