@Lost_N_BIOS - I had to restart my laptop after the vars flash because of a Windows update and, after restarting and running the fptw command again, I get the same error 451. However, I don’t have much knowledge about how this variable flash works but I don’t know for sure if the updates we’ve tried really do apply at BIOS level. I mean, you said that enabling the “Me Fw Re-Flash” option will make my laptop’s fan run at maximum speed and show wrong values, but it just as peaceful and accurate as it always been. Also, no new BIOS option showed in BIOS. Is there a way I can figure out if these changes really apply, since the command prompt result is always “Operation successful”? Maybe there is something I am doing wrong, but I live with the sensation that it is all fine. Anyway, thank you very much for involvement and for help!
Plutomaniac ME Re-Flash only allows ME FW Update tool to update ME, correct, or have I always understood that incorrectly? Or this can sometimes allow a normal BIOS update process to update ME FW too.
No matter what, ME FW update tool can’t be used, since it’s corrupt ME. But you are the ME Wizard, so I’m sure you’re correct!! I’ve never had to enable this option for anyone to FPT flash the ME, only unlock FD for ME or other locks such as PRR/FPRR.
I did give user vars with ME FW Re-Flash enabled, and they tried ME FW update via FPT, still error 451 (FPRR error, result at #17)
Thanks for link!
@marianFCBT - yes, these are being applied at the NVRAM level only, however these settings can be stored and used by the BIOS from several different locations.
The FPRR one in particular can be locked in a file itself too that needs edited directly, thus actual BIOS edit/flash may need to occur before that lock is removed.
As for the vars changes not seeming to apply, this could be true, your BIOS may only access what’s stored in the setup module instead, which we can only change if you can flash BIOS region. Or they may apply, all except FPRR change due to other files locking this down.
In the last vars I sent you ME FW Re-Flash option was not changed, so nothing would happen in regards to what I mentioned with this. Anyway, lets test and see if BIOS settings are being used from NVRAM or not, by checking if BIOS lock is now disabled.
This is stored in NVRAM/vars and setup module, but can also be locked down with FPRR settings too, so still may fail.
So, please test dumping BIOS region now (new dump) >> FPTw.exe -bios -biosreg.bin
And then immediately flash it back >> FPTw.exe -bios -f biosreg.bin
If BIOS settings are used from vars/NVRAM then BIOS lock is now disabled, so this should not give you error. If you do get error, stop and tell me the error. Do not proceed with the flash at all if you get a red or size warning.
Since you mention your fans are running just fine that is odd, usually fans ramp up when ME FW is corrupted, but I guess maybe that doesn’t always happen.
No new things should be showing in BIOS, we aren’t doing any BIOS menu edits here. If you can now flash BIOS region, then I can make some changes you’d visible see, and I can disable BIOS Lock/FPRR on all modules that contain these.
Hello back! The “FPTw.exe -bios -biosreg.bin” command does not work, it reports “User input error”. I assume it should have been FPTw.exe -bios -d biosreg.bin. I ran this one and I got a biosreg.bin file, which I tried to flash using the “FPTw.exe -bios -f biosreg.bin” command. However, I got this message:
“Error 316: 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.
FPT Operation Failed.”
No. That option enables "Re-Flash" (Section E6 of [Guide] Unlock Intel Flash Descriptor Read/Write Access Permissions for SPI Servicing), so you can manually read/write the Engine firmware region of the SPI/BIOS chip. It has nothing to do with FWUpdate capability.
Yes, sorry, typo there, my fault 
Should be this as you suspected >> FPTw.exe -bios -d biosreg.bin
Same/similar error >> 451/316 = FPRR/PRR. Not much else you can do without opening the system up to pinmod or dump the BIOS, we’ve attempted to disable this in the only way possible for now (via NVRAM edit)
The only way to disable this lock is via setup edit, or the actual file/files that control/process the lock itself, which you can’t edit due to this lock in place so this puts you at a stand-still.
You need flash programmer, or there is a slight chance it may be possible for me to edit the Lenovo stock Insyde files to make it flash in a modified BIOS, let me dig into it.
Please link me (At Lenovo’s site) to the BIOS you are using, I can only find this one https://pcsupport.lenovo.com/us/en/downloads/ds500895
I will need to make a simple edit, then give you the package, you try to flash, then show me image of the error/errors it gives you, then I edit the iscflash.sys try and get you around those errors.
This works most often on older BIOS, or BIOS that do not reboot to flash. Does this reboot to flash when you flash a stock BIOS, or does it flash it, say complete and then ask to reboot (or something like that)?
plutomaniac - thanks for confirmation. I’ve never had to enable that for anyone to use FPT to flash ME, only to allow BIOS itself to reflash ME or attempt to allow that to happen during BIOS update/reflash.
I know you know all about ME, but this just my experience with BIOS and BIOS editing, anyone I’ve ever helped flash ME via FPT only had to unlock FD and then they could write to ME. I’ve always thought that was for allowing or denying ME FW tool updates
In the end though, none of that matters for this system, the only edits that can be made are to NVRAM via H20UVE vars edit, and these are apparently not being used by the BIOS during these checks as all have been ignored so it must be obtaining the settings from Setup module or other modules instead (For PRR/FPRR for sure)
Hello! This is the link for the Bios Update executable: https://pcsupport.lenovo.com/ro/ro/downloads/ds500140
Sadly, the update procedure is the folowing: it starts to flash, then it reboots, shows on the screen how it is flashing the EC Roms. Then, it reboots again, verifies each EC Rom and then reboots back to Windows. I’ve thought about the idea that we may be able to mod the Bios file that the upgrader uses so that it can flash the settings we want to make. I have a questiin though. If it happens that we can’t fix this via software, and Lenovo support prompts me to send in my laptop for repair (which I don’t want to do, because I depend on this laptop daily), would a Usb flash programmer do the job? After all, I did’t buy the laptop from Lenovo, but from a third party reseller. I know the name of the repair facility they work with, but:
1. I don’t know if they would send my laptop to repair at all, since they might say that it wasn’t my job to do such updates
2. If I use a flash programmer I theoretically void my warranty, but I don’t know if, let’s say, I have problems with my screen they will check my Bios or dump it to check if I made any modifications, or teardown it to see any unattended modifications. It is only one month old, so I still hope that I don’t need to void it’s warranty, but if we can’t do it the software way, I will see what I am going to do. Thank you both for support!
Yes, USB Flash programmer will resolve anything you want to do with BIOS, but you will have to open the bottom of the laptop up.
I don’t think they can deny you warranty/RMA service due to BIOS update, since those are posted on their website for customers to use, also now Microsoft is sending out some BIOS updates with windows updates too, forcing pushed BIOS updates out to many systems bricking them.
Not that this applies to your situation, but you can see from that how BIOS update can’t be described as something user shouldn’t do when windows updates are doing it to people, and as mentioned they post the BIOS update for user to use and a crashed update is due to their EXE not you.
As for the warranty, and opening the laptop, yes, that is “against the rules” for warranty coverage, but unless you damage something usually there is no way they can check this on a BIOS re-program, because you are not putting on different thermal paste or anything like that where’d they’d be able to easily notice.
If there is a sticker you must break/cut to get in there, then yes, they’d know that way. As for what they do under service, it’s tough to say, usually they would update/fix the BIOS to latest version, but not always is that done, especially if you don’t mention BIOS this may or may not be done.
If you send it in for screen repair, hard to say what they would check and how, and same as above about BIOS if display was the issue mentioned for sending in they may or may not check/update BIOS.
Mentioning BIOS or ME would be best thing for you to do if you send it in, tell them it crashed at their BIOS update process and you followed all directed procedures/instructions during the BIOS update process.
Now, onto what I asked about and what you answered some in regards to how the stock BIOS updates/reboots etc. You mentioned it reboots and updates EC FW, but you didn’t mention anything about the BIOS update, when/where do you see that part of the process take place?
You said it “Starts to flash, then reboots” What does “Start to flash” mean to you, do you see it updating stuff, anything mentioned on screen, can you see/tell if BIOS is updated at that point, then reboot is for EC update only?
We can enable log file via the ini, but I’m not sure if this one would be used or the ini on chip. Default is disabled. Lets test, please flash this stock BIOS and then check in this same folder once it’s done for H2OFFT.log (if you don’t find there, look in windows temp - C:\Users\yourusername\AppData\Local\Temp)
In this package there is two BIOS files. Please remove 8MBcut.fd and set aside in another folder or your desktop, then run H2OFFT-W.exe and let it do it’s thing, then check for the log file in both places mentioned above. If you find, rename to log1 and then copy to somewhere else, delete the original.
Then remove BIOS.fd from the folder, and put back in 8MBCut.fd, and run H2OFFT-W.exe, once done check for new log and then if you get rename it to log2 and send both to me.
http://s000.tinyupload.com/index.php?fil…964383107937137
After this, with or without logs, I will make you simple test mod BIOS, so we can try to flash via stock package files and you can show me when and what the exact error you get is that stops mod BIOS from flashing.
Then I will attempt to go around that for you, if we can tell it’s not doing the BIOS flash post-reboot, usually if it’s done after a reboot that often means the files I would edit may not be used but we can still try then too.
@Lost_N_BIOS Hello, and sorry for posting after such a long time! I was in a holiday for a few days, and I saw yout post, but I didn’t have the laptop with me and I realized that my description of how the BIOS update procedure actually works, so I created this short clip. I’m really sorry for the quality of the material, but I recorded it at night, to better show you how long it actually takes to cold boot or reboot and, also, to show you exactly how this procedure works. That being said, I will wait your response to know if I can go ahead with the H2OFFT program, because I don’t know what it actually does. Does it flash anything, or does it only create a log file? Also, the 8MBCut file you sent me has a .bin extension. Can I just change it’s extension to .fd?
Also, there is one more thing: I trust you to the bitter end, but is there any chance I can brick my laptop? I’m not (very) afraid to do what you think that it will solve my problem, but I would feel better if I know from the very beginning what is the risk I’m exposing to. Thank you very much for all your help!
@marianFCBT - It’s OK about later reply, never in a hurry here and I’m always behind too, so it’s OK 
H2OFFT is the stock flashing tool that comes with your BIOS exe, the files above are what is extracted from the stock exe. Yes, it flashes, and then we attempt to make it create log in those two instances (stock BIOS is what is source BIOS there)
Yes, sorry, please change that 8MBcut.bin to .fd, I must have forgot. All the same, but it will be looking for .fd first, unsure if it looks for bin next or what happens.
No, with the above stuff, you can’t brick anything other than what risk you take every time you flash stock BIOS (always a risk to flash BIOS, stock or mod). The above is not edited BIOS, only stock and only stock files.
You have to do something, unless you want to ignore all these issues? I mean, you have to lets figure this out and or you get a flash programmer and we sort it directly, or send it in for a RMA. Those are only two options here, only you can decide what you want to do.
As for your video, I’s probably not helpful here, but I will check it out. I say this because the way the stock BIOS is configured, it will check BIOS version and if that is same as flash attempted it wont flash BIOS
So I wouldn’t see BIOS update in that video, unless you flash some newer version, or use the above files I made since I changed this option. * Edit, great, I see you downgraded and upgraded to avoid this, good catch 
Check your UEFI Folder/partition, see if you see a copy of H2OFFT there now, if not it’s using one in on-board BIOS and we can’t modify .sys file to get around that.
We can try and see if it uses the one in folder, but generally if it reboots like that and then flashes this doesn’t work because it uses in onboard BIOS files to flash. Maybe we can get luck though, only way to find out is to try.
First I’d need to send you mod BIOS with some simple edit, see the error you get from that, then edit the .sys file to bypass that, then have you retry and see if error changes or not.
But, you have to decide what you want to do first.
Hello back! I tried to run the H2OFFT-W program from the archive you sent me but, after the laptop restarted, I got an error message saying: "Invalid firmware image. Press any key to reboot".
Try everything exactly as mentioned in post #27, then give me both logs
Hi! After renaming the 8MBCut file to BIOS.fd, I get the following error: “It only supports to flash secure BIOS on current platform. The image to be updated is not a secure BIOS.” I noticed that, after running the program, a text file called FlsHook.txt appears, so I guess this might be the log file you are looking for. I didn’t find anything in the Temp folder though.
Edit: Oops, sorry, I know discovered a text file called H2OFFT, and I guess this is what your’re looking for.
hopefully_what_you_need.rar (1.13 KB)
Did you get a log from the BIOS.fd flash attempt or not? Log file will be named H2OFFT.log, and will either appear in that folder you run from, or the temp folder I mentioned (May be in randomly named folder in temp, search for H2OFFT.log, or dump temp before you do it, then look in what is there after)
As for the error you mention above, when do you see that, before reboot or after reboot on that black update screen?
What is in the flshook.txt, upload for me or copy here in a spoiler tag.
* Edit, please show me an image of this error, I need exact wording so image will be best, thanks
I uploaded the two log files in the post above. This is the content of the flshook.txt file:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[08/19 09:33:36] OnEnableHook()
[08/19 09:33:36] Save Power Button Configurations
[08/19 09:33:36] LidAcIndex: 1
[08/19 09:33:36] LidDcIndex: 1
[08/19 09:33:36] PwrButtonAcIndex: 1
[08/19 09:33:36] PwrButtonDcIndex: 1
[08/19 09:33:36] SleepButtonAcIndex: 1
[08/19 09:33:36] SleepButtonDcIndex: 1
[08/19 09:33:37] OnDisableHook()
[08/19 09:33:37] OnStopAp()
[08/19 12:20:11] OnDisableHook()
[08/19 12:20:11] OnDisableHook() - skip
[08/19 12:20:11] OnStopAp()
[08/19 13:18:39] OnDisableHook()
[08/19 13:18:39] OnDisableHook() - skip
[08/19 13:18:39] OnStopAp()
As for the second error, it occurs before restarting, and the application closes. With the first case (the original BIOS.fd file you sent me), I get the error after restarting.
Edit: I attached the photo with the second error
Thanks. See my edit above. FlsHook.exe and that log looks like it’s for the power scheme enable/disable, to unlock something and allow that EC Update, nothing we’re dealing with
Sadly, I’m not finding error, invalid, or even “Secure BIOS” in the usual files I would edit for this error, so either it’s using file within the onboard BIOS for this, or they’ve removed the textual descriptions for the error in the iscflash.sys files, I’ll keep looking
I’ll look in H20FFT itself instead, since that is a pre-reboot error, maybe it’s stopping it instead of the .sys file that usually does. Anyway, I will keep looking and let you know, thanks for the image.
I see error #4 in log2, which file did you try to flash then? This is version compare check, if it finds same version then it stops, I disabled this, but maybe I missed an instance, or as mentioned it may use the ini from the onboard BIOS
Once I know which file I will double check it. I also see this may be EC Part check version fail, but I doubt it’s that.
The other log file has 4 attempts in it, so I need these to be redone one at a time, log removed and renamed between each, so I have a clean log of a single instance for each BIOS file, and a single flash attempt only, from the package and method I outlined in post #27
The log2 text file is the renamed 8MBCut.fd file. The other one is the original BIOS.fd file you sent me in the same archive. In 5 minutes I’ll sent you the new log files.
Edit: uploaded new log files
new_logs.rar (1.02 KB)
Thank, one of those original logs you sent had many log entries, so I couldn’t be sure what was what. I think I missed something in the settings.
Here, try this, and if it fails, then I will enable the settings option interface for you and you can then show me what all options the tool allows you to configure aside from what I am changing in platform.ini
Please try replacing platform.ini (two are included in this file). First, replace edited one in there now with this new one, then after first test rename platform2.ini to platform.ini for second test, replace first one with second after first test
Delete all logs before these tests, after test one, save log and delete, so second test log will be new and only contain those results.
For this test, use the 8MBCut BIOS, renamed to BIOS.fd
http://s000.tinyupload.com/index.php?fil…585877360568650
* Edit - Secondary test, stock files only here, except I edited platform.ini to enable ME FW reflashing only and disabled BIOS flash + logging enabled. And I cut to 8MB BIOS, since there is a in-BIOS ini file that would be used otherwise, and if I edit that in place it would be signed BIOS that would have broken signature
I am not sure how this ME flashing option works on Insyde BIOS, but ME REflash is our goal, hopefully it’s using this ini file and not one in onboard BIOS
After testing this, especially if you see some ME Updating process or “BIOS Flashing” please check ME via MEInfoWin -verbose and show me image of entire report or text of report in spoiler tags
http://s000.tinyupload.com/index.php?fil…400494971885729
Hello! Here are the results!
For this test, I still get this pesky message: "It only supports to flash secure BIOS on current platform. The image to be updated is not a secure BIOS." I am not entirely sure, but maybe there is a problem with the fact that I’ve changed the extension from .bin to .fd, as the 8MBCut isn’t a .fd file.
Regarding this test, I get an interesting result: the fans start to kick in but, eventually, I hit this error: "Warning: Current ME Region does not have R/W rights".
For both tests, I’ve attached the log files. Thank you for help!
logs.rar (138 KB)
It’s nothing to do with the BIOS extension, don’t worry, fd/bin/rom all same. This is due to I cut out the security capsule info and the internal ini, since we are tying to flash in a mod BIOS eventually to then allow ME re-write
I think by default, it’s pulling the ini info from the onboard BIOS, not using the changes I’m putting in, however, we’ll go back to this later after below test, because there is one or two more settings I can change in regards to this, before we would confirm it’s not using the platform.ini we’re giving it.
Good, interesting result on the last test there, maybe for this method, we can use original uncut BIOS… But, I think we need to get FD unlocked first for that, this is what it’s saying NO about.
Please try same again on the ME last package, replace first with the platform.ini not in a folder, then try and see what error you get. Then if same, or similar error, replace that platform.ini with the on in the FD folder, then flash, if it’s successful that means we unlocked FD (Flash Descriptor, this is what locks a lot of things down)
If the FD flash goes over successfully, go back and try the BIOS/ME and platform.ini I originally packaged together as mentioned at post #37
http://s000.tinyupload.com/index.php?fil…148004665173841
Hello! Sadly, after replacing the platform.ini file in the ME package with the ones you last sent me, I get a new error: "Warning: Current DESC does not have R/W rights". I have attached both a screenshot and a log file that resulted from the H2OFFT utility. Thanks for help!
fd_unlock_attempt.rar (120 KB)