Broken Intel Management Engine

ok thanks,
so do I extract an me from Lenovo bios update and add it in like the guide sudgests?

Yes, there are also some quirks there. Compress and attach the 2MB & 4MB images and I’ll fix it for you. It will take a lot less time. I can do it from the official Lenovo BIOS as well but better be safe just in case your Flash Descriptor is slightly different.

thankyou, I was getting worried I wouldn’t have my laptop back to normal for a short while.
ive attached the files requested,
thankyou very much! (3.24 MB)

Here is the fixed 2MB SPI image. Flash only that chip. To reset the ME state after reflashing it, either run Flash Programming Tool with "fptw -greset" command or remove all power (cord + batteries) for 1 minute or so.

25Q16DVSIQ(UH52)_Fix.rar (1010 KB)

your very kind! thankyou for taking the time to help me! I’m very much in your debt!

flashed it today, works perfectly! thankyou

Hello Everyone,

Currently I have a Lenovo M90z that has the ME/MEBx disabled and no matter how many times I reflash the BIOS it still shows as disabled. These systems do have full VPro capability but for some strange reason it cannot be switched apparantly.

The main issue I am having is that the system has a constant High Fan Speed and the system will not power off once I do a shut down. A shut down restart works fine though. Also if the system goes to sleep after thirty minutes or so it does not wake up and I have press and hold the power button to turn it off.

I have read through the forums and guides and it appears that my Region 2 maybe corrupt and also locked. I am seeking all of your knowledge and assistance when you all have sometime to respond. I am attaching all images/text of what I have done to come to this conclusion.

What I am wondering is, if it is possible at all to somehow enable this mode on these systems once this option has been set to enable the full VPro functionality? As obviously all the motherboards are identical so this data must be stored somewhere preventing the ME/MEBx from starting. Is this a situation where I will have to use the Pinmod solution? I appreciate any help that can be provided.

fptw -d spibin.png

fptw -dumplock.PNG

fptw -greset.png



From your description, your ME region firmware is corrupted. You cannot test “-greset” command and your Flash Descriptor is locked. So you need to do the “pinmod” indeed. Usually such “workstation” motherboards have a jumper which does the “pinmod” or a BIOS option similar to “HMRFPO”, “ME Disable”, “Enable ME ReFlash”, “Disable Flash Protection” etc. From the maintenance manual I can see that there is a “recovery” jumper at the CMOS reset one (page 70 connector 9, instructions at page 274) but it’s probably not the one we are looking for, maybe for bad BIOS flash only, not sure if you can boot at the OS with that and check if the FD is locked or not. If not, try the BIOS options. Otherwise, you need to do the “pinmod” manually. Once you do that and can dump your SPI chip, compress and attach it here to take a look.

Thank yo for the response. Yes, I do have a “ME_DISABLE” pins on this mother board. Are you stating I should be able to just jump these pins with a jumper and it should allow for a dump? On this motherboard the chip for “pinmod” is buried under a ventilation fan just below the CPU and it has 64 pins. I’ll test jumping the ME_DISABLE and see if it will allow the dump.

Yes, that jumper is what you need. Short them and then you can dump.

Plutomaniac you are a genius as been stated all over the forum. I jumped the "ME_DISABLE" pins and was able to successfully read and dump the spi.bin Now I understand why the chip is buried underneath the fan. Please see the attachment. Thank you very much for all of your insight. Happy New Year!

fptw -d spibin123116.PNG

spi.rar (3.69 MB)

Run “fptw -i” command and show me a picture. At the dump image you provided there are some weird things. The Flash Descriptor points to a wrong BIOS starting offset. It says that the BIOS starts at 0x500000 even though it starts at 0x580000. The first address points to somewhere inside the ME region, which does not make sense. That should be the reason behind the failure to perform a general reset (-greset). Once the BIOS start offset is fixed, I noticed via UEFITool that two BIOS modules have incorrect checksums which I also fixed by rebuilding them with the same tool. Now the image can be properly read by all tools such as UEFITool, MMTool and Flash Image Tool. So the next step is to fix the ME by following the cleanup guide & disabling the defunct/problematic Intel Anti-Theft technology. Problem is, I don’t think that the ME configuration (DATA) settings are read properly. This is probably due to a corrupted ME region and not because of the old FITC version that we have for ME6 (we have 6.0.40, still newer than Lenovo’s 6.0.31 firmware). I’d like to check another dump from such a system to see if these problems I’ve seen are a one time thing. From what I can read, these issues are universal. The SPI image of these systems was messed up from the factory. It seems that Lenovo had also recalled a lot of these machines due to fire hazard back in the day even though that is not really related to this extra issue. Not a very successful machine apparently.

Anyway, what I suggest is for you to first flash the “fix_1” image I’ve build and attached which has a proper BIOS start and corrected BIOS module checksums. It’s probably the wrong BIOS address which causes all these issues. After you flash it, remove the jumper and restart. Then post another picture of “fptw -i” and retry “fptw -greset”. If after the reset the problem remains, we’ll need to clean/fix the ME region as well. But I’m not very confident doing that as long as Flash Image Tool cannot properly detect the ME region’s OEM settings/configuration. We will try it though if “fix_1” fails.

spi_fix_1.rar (3.69 MB)

I tried to re flash the spi_fix but I received the following error.

"Error 28: Protected Range Registers are currently set by BIOS, preventing flash access.
Please contact the target system BIOS vendor for an option to disable Protected Range Registers."

I also ran the fptw -i before I tried to re flash and I have the image attached. Is there any hope?

fptw -f spi_fix.PNG

fptw -i before flash.PNG

What I said can also be seen at the "fptw -i" picture, the ME ends at 0x580000 whereas the BIOS starts at 0x500000 instead of 0x580000. That BIOS access error you get might be an actual implemented security measure or could be due to the broken BIOS start offset at the Flash Descriptor. You can reflash/fix the FD and after a restart reflash the BIOS by using "fptw -f desc_fix.bin -desc" and "fptw -f bios_fix.bin -bios" commands respectively. Remove the ME_Disable jumper and test again after another restart.

bios_fix.rar (1.79 MB)

desc_fix.rar (511 Bytes)

Okay I followed the instructions restarted flash both files. They both reported flashed correctly and verified. Removed ME_DISABLE jumper reboot and now all I hear is two beeps black screen fast fans and that’s it. Sounds like the security measure you stated may have kicked in and killed it.

So the system boots with the jumper set but it doesn’t otherwise? Check the manual to see what these beeps mean.

No, actually is does not boot at all. I will try the recovery mode and see if I can get it to boot.

We should have tried the FD fix only for starters. Maybe the two small BIOS checksum fixes caused this. If the system worked after fixing the FD but not after BIOS then it’s surely that. When you flashed the BIOS only, it worked, right? Meaning, it didn’t complain about protected ranges? In such case, that previous error was indeed due to the FD mess-up. But that doesn’t change the fact that the BIOS probably needs a reflash now. Try a clear CMOS first just in case but I doubt it will help with the current problem. Hopefully you can recover the BIOS via whatever method Lenovo has implemented. If you do, leave the BIOS as it is and check if the FD is fixed by running “fptw -i” command. To not have to mess with the ME and figure out why the settings are not read properly by FITC, we would need the wrong BIOS offset at FD to be the cause of your initial troubles.

Yes, that is correct. The FD went on fine and didn’t complain about protected ranges and rebooted . Flashed BIOS when on fine and verified, but on reboot it gave two short beep, beep and nothing else. I will continue to research a recovery possibility.

You have an AMI bios. At the Lenovo M90z Hardware Maintenance Manual, you will find the procedure on how to repair a bad BIOS flash at pages 274-275. These steps assume you have created a BIOS update optical disc, instructions for which can be found at pages 273-274. Lenovo includes the BIOS region only at their updates so it should only affect the BIOS and not the fixed FD. What’s interesting is that the stock Lenovo BIOS does not show any checksum errors at UEFITool, which good and the opposite of your own dump.