New :
Intel Management Engine (ME) Firmware Version 11.6.0.1136 (S&H)(1.5Mo)
Intel ME 11.6 Consumer PCH-H Firmware v11.6.0.1136
Version: 11.6.0.1136 (1.5Mo)
For: Intel 100/200-series Consumer S/H chipsets
Inclus: Flash, Info tools & Firmware.
http://www.station-drivers.com/index.php…id=2572&lang=fr
Intel MEI Driver v11.6.0.1035 MEI-Only Installer
Intel ME 11.6 Consumer PCH-H Firmware v11.6.0.1136
Intel ME System Tools v11.6 r3
Big thanks to Pacman/SD for the new firmware! 
Intel ME 11.0 Consumer PCH-LP Firmware v11.0.18.1002
Intel ME 11.0 Corporate PCH-LP Firmware v11.0.18.1002 (PDM+NOPDM)
Hello, i wanted to know if it works to update from 11.0 to 11.6 firmware on z170 chipset motherboard like asus maximus viii extreme, as it say that works with 100 series but for systems that came with it and i am a little confused.
Thanks! 
@sucka :
The latest BIOS for your mainboard has still the Intel ME Firmware v11.0 series.
According to my knowledge you should wait until ASUS has realeased a new BIOS, which contains the Intel ME v11.6 series. After having flashed that upcoming BIOS, you can update to the latest suitable v11.6 series ME Firmware.
My Asus notebook X456UR (Skl-U BGA1356) Bios v203 came with ME v11.0 series. Accidentally I’ve updated the ME firmware 11.6.0.1126 Con-LP but without issues so far.
After reading your post I tried change back to ME firmware 11.0.18.1002 but unfortunately it does’nt work via FWupdate.
On the Asus support page for my notebook are 2 newer Bios versions 301 and 303 but Asus-Winflash don’t let me update, maybe they are only for slightly different notebooks X456UR(Q)K or whatever.
Now I’m not sure what to do, just leave it as it is or update with upcoming ME 11.6 firmware versions?
Intel ME 11.6 Corporate PCH-H Firmware v11.6.1.1142
Thanks to Pacman/SD for the new firmware!
@ wasisdn
Another fast way to know if your OEM has added KBL support is to check the included microcodes. In your case, any BIOS after 300 (301,303 etc) does include the KabyLake CPUID 806E9 so in theory you are ready for v11.5 or v11.6. At this point I don’t know why there are two branches (11.5, 11.6) and that’s why I mentioned both. What ASUS usually does at notebooks is to release a ME Update utility which will use FWUpdate + desired firmware. Since it works without issues, you can update to latter v11.6. Just update the BIOS as well to anything post-300 to have proper KBL support.
For those who are interested :
http://hardenedlinux.org/firmware/2016/1…_ivybridge.html
https://www.coreboot.org/pipermail/coreb…ber/082016.html
https://libreboot.org/docs/hcl/gm45_remove_me.html
https://github.com/corna/me_cleaner
@plutomaniac
Slightly off topic, but take a look at these:
https://github.com/corna/me_cleaner
http://hackaday.com/2016/11/28/neutraliz…agement-engine/
@Tito :
Thank you very much for your very interesting links.
@all:
This is the main message given by Brian Benchoff, the author of the article, which has been linked as second by Tito:
@plutomaniac :
What is your comment regarding this statement given by Brian Benchoff?
Intel ME 11.6 Corporate PCH-LP Firmware v11.6.1.1142
Thanks to Pacman/SD for the new firmware!
@ DoZe, Tito, Fernando
Thank you for letting me know of these developments. The statements of “Brian Benchoff” are not meaningful in any way as he is not the one who did the research, just someone who wrote an article about it. An article which by the way has certain mistakes and exaggerations. Exaggerations which target views and readers. Saying that it has access to your files and that it can send info over the network for example is partially true but assuming that nothing can be done to verify what is being send without removing it, is stupid. For example, a hardware/router firewall can monitor all traffic and determine what it tries to do over the network. Don’t get me wrong, it has been known for years that the ME is shady in the way that it’s closed source and that it has a very significant attachment to the rest of the system which makes it almost impossible to remove. I have no inclination to defend it as it’s true that we don’t know exactly what goes on behind closed doors. But every so often someone writes an article about that which blows up for some days until people realize that these “findings” were done years ago by various researchers such as Igor Skochinsky and people from coreboot and libreboot projects. The libreboot project aims to remove anything that is not open source so they use different hardware (NIC, RAID, TPM, GPU etc) that fall under that category. So removing the ME for something that is open source while keeping the functionality (system control, remote management & security) is very important for them. All these are not new, not in any way. In the end it comes down to whether you can trust Intel with the security of their platform. A lot of times it doesn’t have to do with whether they have implemented a backdoor but more like “what if someone has found a vulnerability which Intel missed and uses it already”. Despite all these, I find it ridiculous from libreboot to suggest to people to use Core2Duo (G45, 2008) or earlier systems at which the ME can indeed be removed entirely as back then it had no ties with the rest of the system apart from the remote management capabilities such as KVM, AMT etc. It’s also ridiculous to suggest ways to remove the ME even though that means a system with various problems all around. I find these notions to be extreme/radical. It’s great that they are trying but unless a solution is found which keeps all the functionality without a broken system, I don’t see why most people should care.
Now, for “me cleaner”, it is indeed very interesting to see that the ME indeed “works” (allows the CPU to initialize at all) in such a crippled way. As can be seen at MEA too, FTPR is the recovery section and thus the most important. The idea of keeping only that had not occurred to me before. So that is indeed interesting from a research standpoint. I did some tests of my own and yes it works. Obviously the system has problems with clocks, no overclocking, no GbE, no Rapid Start, weird behavior after BIOS and before Windows loads and many more. That’s why I said above that, for now, it doesn’t matter. It only matters to researchers. So before someone tries to do that on his/her system thinking that they will be “safe”, just don’t.
@Pacman
Hello, thank you for the firmware. A question: did you remove the ISHC section from $FPT and it’s data or was it not there to begin with? I think it was because the $FPT header states that there are 11 sections yet only 10 are found. I observed recently that a wrong checksum at $FPT will make the system unbootable but I haven’t tested how it reacts when the section count is wrong. If it reacts badly, the problem should be shown when flashing with FPT or programmer after adjusting settings with FITC (which by the way does not fix the section count) and not FWUpdate as that works differently. We can make sure that does not happen at all of course by fixing the section count and checksum at $FPT but I was mostly curious if the image came that way from the extracted SPI or was cut afterwards.
I padded the ISHC section in the header, FWUpdate 11.6 still gives error 1 with extracted images, but i forgot to include the original extracted image in the archive,
so i have now uploaded a new one with that also.
How can the section Count be corrected?
Intel ME 11.6 Consumer PCH-H Firmware v11.6.1.1142
Thanks to Pacman/SD for the new firmware!
With the help of MEA v1.7.0_9 or later (will upload the new dev to github today at some point). The section count is exactly after $FPT tag (value 0x0B in this case, 0x0A without ISHC) and the checksum is found 0x7 after $FPT, meaning 0x1B from ME region start (value 0x0F in this case with 0x0B section count, should be 0x10 with 0x0A section count).
After changing 0x0B to 0x0A (always -0x1 after removing ISHC section), run MEA with parameter -fptchk and it will display the detected & expected $FPT checksum values.
MEA now has a check to verify the $FPT checksum on all Engine firmware and displays a warning if it’s wrong. The user can then fix it by using -fptchk parameter and manual checksum byte adjustment.
In future 1.7.0 dev versions I will add $FPT section count check as well as end of firmware check based on last section address & size at $FPT. Also, the actual ISHC section data can be removed once the mention at $FPT is gone which is easy because it’s always the last section and code sections can be found by searching the $CPD tag (in this case the ISHC is empty, no data, just $FPT mention). Only for FWUpdate use of course. But we know it works with the ISHC data leftovers so, for that removal, wait for a newer MEA version which will check where the firmware ends (this functionality is found at Lordkag’s UEFIStrip > ZyxWorker > mesize command).
I am reinstall a X38-based PC for a friend and am trying to figure out whether it even has MEI at all. There’s no unknown device in Device Manager and I can’t seem to get any results from Google.
Maybe QST firmware, not AMT. No OS communication device for the former even if it is indeed used.