After flashing the 7.1.91.3272 update with the patch for CVE-2017-5689, I ran into some problems: sleep wouldn't work (it would initially seem to go to sleep, do the sleep-jingle etc but then cut all power, resulting in a dirty shutdown) and restart would result in power being cut turning back on. I suspected this was because I was on a modified version of the 1.42 BIOS that unlocks RAM speed, removes the WLAN whitelist, and exposes other advanced features, so I updated to the latest 1.43 BIOS, and then, without rebooting, to a similarly modified version of the 1.43 BIOS (so that at no point would the WLAN whitelist be triggered). The modified BIOS can be found here. Unfortunately this didn't fix anything. I reflashed the 7.1.91.3272 update, still nothing - sleep still didn't work, and restart was still cutting power before booting.

I wasn't really sure at this point about the nature of the problem. So, after running a chkdsk (required after so many dirty shutdowns), I tried doing a System Restore to before I had done any flashing. Upon rebooting to complete the system restore however, my main mSATA system drive ceased being recognized, and the 'ME is in Recovery State' message began showing up. After rebooting a couple of more times - I don't remember if I used CTRL-ALT-DEL or cut power - the mSATA drive began being recognized, and Windows began booting normally. And while, unfortunately, the 'ME is in Recovery State' error persists, sleep and shutdown are working normally again. Here's what the 'ME is in Recovery State' screen looks like when the BIOS is set to show diagnostics:



At this point my situation seems pretty similar to the one in this thread, though MEInfo and MEManuf logs are slightly different.

MEInfo - per the original thread I upgrade the ME drivers to 11.0. UNS and LMS versions show up as "Not Available".

• What consequences are there to not fixing this, other than a slightly longer boot-up time?
• I understand, per the other thread, that the code 26 error can be circumvented via shorting together a couple of pins on the audio circuit. I'm not sure I have anything slight enough that it would only touch those two pins. Are there any recommendations for a specific tool to do this with?
• The procedure to fix this appears to involve extracting a current BIOS, replacing the ME region from a stock image, and reprovisioning it properly, as per the guide here.
  
  • It appears that in my case this would require extracting the 'clean' ME Region from 7.1.80.1214_5MB_ALL_PRD_RGN.bin. Is this correct?
  • If so, can I later upgrade to the 7.1.91.3272 version with the patch without issues? Or is this somehow rolling the dice?
  • In the other thread, both of the people helped ended up getting a code 28 error when trying to flash the 'fat' image, and are then instructed to only flash Descriptor and ME Regions.
    • How are specific descriptor and ME Region files made?
    • Can/should these be flashed directly, without first flashing the 'fat' image with the entire bios? (I mean it certainly looks like flashing the fat image won't work...)
  
  

Accidentally hibernating my system appears to have triggered a global system reset. While this has gotten rid of the "ME is in Recovery State" message, standby and restart are broken again. fptw still can't dump. Not really sure how to proceed. Regardless, I guess this means I can't avoid trying to deal with this :/

On a lark I tried downgrading using FwUpdLcl.exe. Running "FwUpdLcl.exe -blist" resulted in a pretty short blacklist - only 7.0.10.1203 and 7.1.13.1088 were disallowed. So, I took 7.1.80.1214_5MB_ALL_PRD_UPD.bin from the repository pack, and modified the install script that came with the official 7.1.91.3272 upgrade package from Lenovo to use it instead. (The only distinctive thing in the script is the feeding of the OEMID parameter to FwUpdLcl, which I figured was important.) Long story short, I appear to have rolled back to 7.1.80.1214 successfully, with no sleep or restart issues and the ME in normal, rather than recovery, state. (The only thing is, the MEManuf test still fails with errors 9313/9296, but it's unclear if this matters in practice...)

There are two newer firmwares, 7.1.85.1216 and 7.1.86.1221, that I guess can also be tried, but I'm not really sure what they change that is of any benefit. In contrast, I would still like to be using 7.1.91.3272 as CVE-2017-5689 looks pretty severe. Does it seem like my sleep issues were due to the order in which I did the flashing, or is it a problem with 7.1.91.3272 itself? If not, I guess I can just disable AMT for now or something (not like I ever use it).

Zitat von plutomaniac im Beitrag #4

---

@LastSilmaril

Hello LastSilmaril, sorry for the delay. It is very impressive how much research you've done before opening a new topic. Such a thing is not common. Thank you for that, great work.
...

---

Zitat von plutomaniac im Beitrag #4

---

I suggest to:

1) Update the BIOS to the latest version from Lenovo's website
2) Update the ME to the latest version from Lenovo's website (they definitely have 7.1.91.3272 for all their affected machines)
3) If the problems re-appears, try a "fpt -greset" or a manual one if the former fails.
4) If the problem persists, we have ruled out BIOS/MEBx incompatibility so the issue is almost certainly a corrupted ME region (its code or settings).
5) In such case, the only way is to unlock the FD and reflash the ME region manually after following the CleanUp Guide.
6) The reflashed firmware will be 7.1.80.1214 (last RGN), after which you can use FWUpdate to go to 7.1.91.3272.

If everything above fails, I suggest you downgrade to the last working ME firmware (7.1.85 maybe, whatever you want) and unprovision+disable AMT from MEBx. Maybe contacting Lenovo could help at such point.

---