Yes, looks good annd I’d try with this file.
It. Freaking. Works!
@lfb6 I have no words to describe how grateful I am! Thank you SO much!
Out of interest and to better my knowledge of this, how did you get to the start and end points to copy the data, is this something learnt over time or is there a trick to this?
Thanks for the feedback- good work 
Try to find out the versions before and after update. Find which parts of the bios region are original, which are ‘new’ by comparing to corresponding stock bios regions, if accessible.
In your bios region the flashing began with the last UEFI volume but stopped very quickly. The original bios still was accessible, so smallest operation was to restore the small area already flashed with the original bytes.
You could’ve exchanged the complete bios region with stock, possibly loosing your board specific data (but they might be stored in other places, too, like TPM for example and get automatically repopulated in NVRAM), or a stock region and have transfered at least one or two NVRAM volumes to keep the data. If it’s just a small area of static code then I prefer just to replace it. Afterwards you are right there where you started.
It’s (almost) always better to search for the error than to blindly flash “something” like a foreign bios from unknown source.
I’d recoommend to update bios region and Intel ME, both are rather old!
https://download.lenovo.com/pccbbs/thinkcentre_bios/fwjybfusa.exe
https://download.lenovo.com/pccbbs/thinkcentre_drivers/11.8.92.4249_corporate.exe
1 Like
Hi again !
I havent given up hope yet on this M900. I did actually find my most ‘original’ dump of the bios immediately after it had been bricked. I’ve been trying to repair it.
UEFITool reports multiple problems - I’d appreciate any guidance on rebuilding it. I can make the microcode errors go away by replacing those sections in HxD from the official bios region from lenovo, but these errors hint to me there some problem with the structure:
FfsParser::parseVolumeNonUefiData: non-UEFI data found in volume’s free space
FfsParser::parseVolumeNonUefiData: non-UEFI data found in volume’s free space
FfsParser::parseIntelMicrocodeHeader: invalid microcode checksum 1C53FB94h, should be 18676471h
FfsParser::parseIntelMicrocodeHeader: invalid microcode checksum 56A790FFh, should be 37102A75h
FfsParser::parse: not a single Volume Top File is found, the image may be corrupted
MeParser::parseFptRegion: FPT partition is located inside another FPT partition, skipped
MeParser::parseFptRegion: FPT partition is located inside another FPT partition, skipped
MeParser::parseFptRegion: FPT partition is located inside another FPT partition, skipped
NvramParser::parseNvarStore: unable to parse AMI NVAR storage
NvramParser::parseNvarStore: unable to parse AMI NVAR storage
Something bad in the NVRAM area, or bad alignment somewhere not sure.
m900_corrupt.zip (9.7 MB)
Try the attached file. Confirm that it was flashed correctly by reading back the updated content again directly from the SPI in a separate process, store the freshly dumped content to a file and compare it to the original.
m900out.zip (8.7 MB)
Thanks for your continued assistance lfb6! Sorry for the delay replying, no time for BIOS tinkering over the weekend im afraid 
Unfortunately that one didn’t work. Did you take a stock bios area and replace the 1st volume’s nvram storage area from the corrupted dump?
Meanwhile last night Ive started a similar process of taking a stock rom and populating variable by variable the NVRAM area from my corrupted dump , ensuring the file passes the parser checks each time. I did find the section which is corrupt. Theres a beginning of a variable at offset 0x82227B which is then filled either with junk or a section of another variable with what looks like licensing info or certificate storage. If I fill the remainder of the volume with FF and restore a GUID store section then the file starts to parse correctly again in UEFI tool.
No success yet but Ill keep trying. Im convinced its not the board itself - my rationale is that some roms I’ve tried will give some different behaviour such as turning itself off and on again before staying bricked again .This hints to me that at least the BIOS is being read.
Ive also had the logic analyser on the SPI flash, and can see it negotiating up to the fast dual / quad data rate, at which point at 400Mhz, my logic analyser cannot keep up.
If the firmware from #53 with a minimal set of variables doesn’t work then a firmware with even more variables won’t work either… 
Try that file, re-initialized latest ME and latest bios- region stock/unchanged.
m900.zip (9.3 MB)
There are same differences in standard setup variables, and both bios and ME were very old, so there’s a minimal chance.
If this file against all odds would work then one could see if it’d be needed to add the old DMI variables to NVRAM again.
If this file doesn’t work, it’s not firmware related.
1 Like
ok lol. I was hoping if uefitool and similar utils couldnt parse the nvram areas then that would be why the machine wont boot if there’s something in there that is required.
Ill give that a try thank you.
Hello, I need someone to help me, I have seen that there are several experts here, the BIOS was updated through Windows and it died in the update process, I have tried everything, and in the end I bought a programmer to try to read the original another similar device and exchange it with the broken one, but I have not been successful, let’s see if one of you can repair the file for me WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free
Thanks in advance
Replace 0xE80000 to 0xE94FFF in your dump with 0x680000 to 0x694FFF from imagefw.rom of the update B3 (fwjyb3usa.exe).
(All values ‘including’)
Post / attach your result if unsure.
Thank you very much for your help, but I have not had a positive result, I connect the power and without touching anything the fan and the power light activate, black screen… I attach the bin with the modifications that you have told me. WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free
Yes, that image won’t boot. There’s just 4 bytes changed in the header of the lasti EFI volume. As written:
So I don’t know how to do it, in theory I have replaced the data from one site to another, if it’s not too much trouble, could you generate the BIN for me? THANKS THANKS
Please @lfb6
EDIT:
I don’t know if it has anything to do with it but my model is an M700 tiny, no matter how many tests I have done I can’t get it, if you have a minute of your time please help me.
As written: Post / attach your results if unsure or ask specific questions.
Hello @lfb6 I want to return to this topic, I honestly don’t know how to do what you’re telling me, I’m sorry, I’ve tried creating a file mixing it with the Hex editor and I haven’t achieved anything. Here I leave you the original BIOS in case you can help me.
Hello @lfb6
M900 Tiny is broken
Tried to replace bits according to a mall instruction bellow, Region was restored but m900 is still brick.
I would be grateful, if you could help me.
Is the dump provided the unchanged dump or is it the dump you ‘replaced bits’?
This dump is unchanged.
A quick update - I was able restore this dump:
from the last BIOS (downloaded from Lenovo, last, not 53) I took the last Region and inserted it in my current DUMP:
addresses:
BIOS downloaded from Lenovo
My dump:
E80000 + 180000 (1572864)
it worked.
also tried to replace all regions (in my corrupted BIOS) with the whole BIOS (downloaded from site). it worked. However, SN, computer type and so on were lost.
@lfb6 - could you help me with the next issues:
I suppose that Windows Key is saved in the last Region. My restored BIOS (with copied last Region) does not have this number. I tried to find this key in my initial dump. but is seems that it does not have it. all areas where it can be are empty - FF. I have this key.
could you tell me the address, where this key must be inserted in a restored BIOS ?
the second update - I was able to find it.
@lfb6 - thank you for information that you have shared in this post. It helped many people and me as well.
1 Like
Well, the last volume is relevant for the first bios phase (Pre-EFI Initialization PEI), and it’s quite astonishing that the last volume of Lenovos latest bios update worked. Your bios region was FWKT95A, latest is FWKTBFA
FWKT95A can still be downloaded (opens in 7-zip):
https://download.lenovo.com/pccbbs/thinkcentre_bios/fwjy95usa.exe
It seems that this really was a broken update since the first part of the last EFI volume is BF, last part of the last volume (and the other two EFI volumes) is 95.
Only machine specific part in the last EFI volume is in OemRomHole0:
So that’d be my reconstructed firmware:
M900t_R.zip (8.8 MB)
But good to hear that you got it working yourself already
1 Like