So I double checked the result of running MEA on my bios backup I made with the FTK Tool (or FPTW -d backup.bin) and indeed the resulting bios image hosts the updated ME firmware
compared to the original bios file. My eyes must have been tired that night I asked for help. Also MEA says that its unlocked. So next question is that there is no way to go from 9.1 firmware
to version 11? Your stuck on 9.1 forever?
Thanks
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.
Well I had already flashed my ME to the latest 9.1 version. I just wanted to share my bios mod online with others and at the time I couldnât figure out how to get my new ME version in there to share. Thanks to the links you provided I have a better understanding. Only few areas of confusion. 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. 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. Also even though my ME passed diagnostic tests certain Intel features are disabled like Intel anti theft feature and others. Can they be enabled? 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.
Thanks
What do you mean "dump"? The "ME Region.bin" file it creates upon loading of an SPI image or the resulting "outimage.bin" built after adjusting settings? That guide was a reference, I said to check so that both ME regions (from OEM SPI & Latest with FITC adjusted settings) are of the same size and then replace based on that size. It doesnât matter though. There is another simpler way. Just copy your OEM SPI image and input it at FITC. From FITC, load the latest ME Region provided at first post and change all ME settings according to the original SPI image from the OEM (you can view these for example with another FITC window running). Then rebuild the full SPI image with FITC and the "outimage.bin" file will now be your original OEM SPI image + new ME Region + configured new ME region based on OEM settings. That way you leave any size adjustments and hex replacing to FITC. Easier, safer. Afterwards, you can load that SPI image to UBU and mod the BIOS region as well. FITC doesnât mess with the BIOS region and UBU doesnât mess with the ME region either way.
If you mean IDs such as FWUpdate and so on then these are considered "ME settings". You transfer them like everything else ME-related. If they are 0 then leave them at 0, nothing changes.
Leave all "ME settings" just like the OEM configured them. Anti-Theft has been dead/EOL for more than a year.
Yes, the FD locks can be adjusted via FITC > Flash Descriptor. To disable they need to be FF on CPU/BIOS, ME, GbE. Keep in mind what I said at my previous post about whether these new settings will be applied after flashing the new modded SPI image.
Very interesting. Thank you for taking the time to write all those replies!
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?
Depends on some factors. One is SKU. For example, I wouldnât recommend the dump on a 5MB/Corporate system because some system-specific settings are kept in the ME region (MEBx, LOCL maybe). For a 1.5MB system I guess it would be ok. Another factor is "safety", I have seen a lot of people report erratic behavior and MEInfo/MEManuf reports with errors because their system works but the ME filesystem is corrupted for example. Maybe there are garbage somewhere from something else causing issues and maybe these get transferred to another healthy system via the "dirty" dump.
I agree with the second part, it is best to start with a clean file and transfer the settings. But why the first part is not safe? By dumping the ME Region with FPT (where it is possible), shouldnât you obtain the same result as Clean + FITC? Or is there something Iâm missing, like settings stored in ME Region after FITC, settings resulted from that specific system and user?
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.
Yes, this seems like solid evidences against sharing a dump, even for the same system. But for the sake of argument, are you aware of similar limitations to Consumer, apart from the possible corruption?
For 1.5MB/Consumer when using it for the identical OEM system, no. I canât think of something solid. For non-vPro systems all settings are pre-configured by the OEM so the user doesnât really have to do anything else. Apart from filesystem corruption I can only think of advanced users (the ones who usually create SPI mods and distribute them) having modded the ME firmwareâs ICC to allow overclocking on mobile systems or for non-K cpu SKUs where that is possible/applicable which may result in some unwanted (for other users) limitations on power savings and so on. As you said, thatâs for the sake of the argument, most people donât mess with these things on 1.5MB/Consumer either way.
I can tell you that I did a file compare analysis in Hx Edit of the clean production release of 9.1.1037 and the FPT dump of that flashed ME version using FITC and the two files were slightly different. Probably some modification is being made by bios after flashing ME and reboot?
The ME firmware is not "static". The ME co-processor does slightly modify it while on the field (after flash) so those changes are normal. I generally recommend to do it the harder way (FITC,settings etc) especially since you plan to release it to the general public. Wouldnât want to corrupt multiple other peopleâs firmware by mistake. Iâm not saying that your system is corrupted or something, just justifying why I always recommend the more tedious method of upgrading the ME inside the SPI image. 
If thatâs the case I wonât share my updated ME version. Found the hard way a little confusing. I mean I understand how to copy paste the ME region short of transferring settings. So not sharing the updated ME version. Wouldnât want to brick anyoneâs board. Thanks.
Iâve said this before. I donât see OEMs doing eye-for-an-eye poke with two instances of FITC. I believe I have tested this (better if someone interested confirms it) and the easiest and probably recommended way is to open original ME from OEM, save XML, open clean ME, open saved XML and the settings should be transferred. Iâm not sure about the last step, if saved XML needs to be open before or after clean image.
@ davidm71:
Well, honestly it should be ok in your case. Your MEInfo, MEManuf reports show that everything is ok and you will release it only for the same system, plus itâs 1.5MB firmware which doesnât really get dirty. The FITC method is very easy, just takes 5-10 minutes to move settings. You donât have to care about HEX Editing, sizes or anything. I should have recommended that option when we first spoke, donât know what I was thinking with all those size checks and so on. Anyway, itâs up to you. Remember thereâs always the extremely easy FWUpdate tool which doesnât mess with any ME DATA, just the CODE (version)so itâs safe no matter the OEM, Model etc as long as the correct fw (9.1 1.5MB) is used on the correct platform (9-series/X99) with the correct tool (FWUpdate v9.1).
So using FITC and transferring xml settings is kind of like updating sandy bridge video rom and transfering the video settings. I get it. Ok.
@ davidm71:
Yes, sort of. Similar, ME is easier (less settings compared to BMP).
@ lordkag:
If I remember properly, these XML have versions/revisions. So if we have an old FITC but a much newer ME firmware there might be inconsistencies. Similar to Intel BMP + BSF but not the same. I will try it though later. For example, 11.0.0.1160 has xml version 9.59 whereas 11.0.0.1194 has 9.62.
Intel Management Engine Interface (MEI) Version 11.0.0.1177 WHQL
http://www.station-drivers.com/index.phpâŚid=2019&lang=fr
Intel MEI Driver v11.0.0.1176
Intel MEI Drivers & Software v11.0.0.1177 for Consumer systems
Thanks to tObber166 for letting me know and Station-Drivers for the new drivers.
@lordkag
I did some quick tests with the XML. You were right this time (thatâs rare⌠
). I underestimated FITC, it seems that it is clever enough to notice the loading of both an older or newer XML file. It seems that Intel keeps a record of any XML/firmware setting changes inside FITC so if you load an older firmware it will adjust it and automatically fill the missing/new options with defaults. If you load a newer XML it will tell you that there should be a newer FITC available based on that XML version and warn of possible misconfiguration. I tested with ME 10.0.25 and 10.0.47 FITC. I will write in the future a guide regarding Flash Descriptor (check lock state, difference with SPI image/chip) and another about transfering xml settings (maybe inside this one). I will look into the XML fringe cases then a bit more, for example ME6 for which we still have a very old FITC and so on. But from now on I will recommend the XML method. Itâs there for a reason and Intel thankfully does some checking before loading these files. I canât say the same about FWUpdate 11 though, that is just insane.
