i’m training to build up my patience and fine motor skills for these 10 min reads and 7-8 min writes.
i did 3 reads of the chip yesterday, with 1 bad read followed by 2 good reads that had matching hashes, and the reads that matched would not open in MFIT. today i attempted 2 writes of the original dump, and after both of those attempts the machine would still not power on. i did a read after those 2 writes, and i observed something i did not expect:
the hash of the read today matched the hash of the 2 good reads i got yesterday, suggesting that, in fact, i did not have a bad write of the original dump previously. instead it would appear there is a reproducible change occurring when i write to the chip, meaning when i write the original image it succeeds and some change either occurs during the process or when i attempt to start the machine.
any thoughts on what could be occurring here?
i will do a write followed by a read prior to turning the machine on, to rule out that the image is being modified when i attempt to boot.
No, a correct flash would be a necessary but not a sufficient condition.
Large areas of the firmware / spi- chip are often re- written, that covers the data partitions in the ME, NVRAM, redundancy information, possibly signatures. If you clean a ME with FIT its state is configured, after first boot it’s initialized. To expect the complete firmware as static is a by far too simple approach.
What is the actual state when trying to start the machine?
Can you post a link to or attach the changed dump?
historically, i have only worked with 16 MB flash chips and used a soic8 adapter to read and write. if i would modify an image, write it, and it wouldn’t boot for whatever reason, i could simply flash the original unmodified image back to get it booting again.
what surprises me here is that the same process seems to not work with this 64 MB wson8 chip, despite this chip housing a full proper copy of the bios and ME prior to modification. i’ve checked the 16 MB soic8 chip image and it has been static the entire time, same as the first image i linked.
what i have observed after another write and read cycle for the 64 MB chip is that i take the apparently-good image that i linked previously, write it, then immediately read it, and i get a hash mismatch on read.
here is the image i read back after writing the original image back, which i’ve now attempted to write 3 times:
i have never seen something like this before, where i write to a chip successfully and when i read from it immediately afterwards, the image has changed.
in neoprogrammer, i open the original dump, the one on the right of your image, then i write to the chip. during previous attempts, i did have both the main battery and the small backup connected. for this last test, i did remove both the main and backup battery, but the outcome remains the same.
immediately after writing the original image to the chip, i read it back and got the image that i have linked here. i did not power the machine on after writing to the chip.
maybe neoprogrammer has a bug and it’s not writing the correct image to the chip? it seems to read fine. according to MFIT, the version i have is 16.1.25.2053, not .2049.
i will try restarting neoprogrammer and doing another write-read cycle to attempt to rule out some issue with caching an opened image.
ok, i did another cycle of write-read and got the same results as the last several attempts. both batteries are disconnected, same as the cycle i ran before this.
per your spotting the version of mfit used in each of those images, i have collected additional details about the mfit version i’m using (16.1.25.2091 on windows). the original image shows .2181, the image after writing the original back to chip shows .2049, and the modified original image with reserved bit set to yes is .2091 (which matches the mfit windows version).
i do see that FWUpdate Support is set to No in all 3 cases. could this be part of what is occurring here - the chip doesn’t allow me to update intel ME region?
based on your prior comments and this behavior being reproducible, i am guessing some portion of this chip is write protected or is otherwise overwritten after it is written externally, e.g. powering chip to write powers some additional circuitry to overwrite post write. i’m a noob when it comes to firmware, so i don’t know what to try next. i would expect portions of the chip being write protected to be something that could be detected by reading the chip.
Means that a ME region can’t be used for update, pretty much expected for newer ME versions since firmware update files and ME regions have different structure.
(In addition this MEA information can’t be taken dogmatic, a ME 14.1 update file will be considered ‘No FWUpdate Support’ when missing PHY but will update an older ME 14.0 which never had PHY just fine)
Is the result of flashing now constant- is the resulting content of the chip after each flash 100% identical or are there new differences every time?
Please post / attach the modified file you flashed which bricked your machine
the hash of the read is constant. every good read i have gotten after the initial write attempt of the modified bios has had the same hash.
here is the image of the modified bios. the only change i made was setting the reserved bit to yes and i built the image. the version of mfit used to build the image is 16.1.25.2091, which matches what is shown by MEA for this image.
i have been poking around in thinkpad forums and found this tidbit about the claimed location of the bios chip on the T14 Gen 3:
“If you still need to know where the chip is for any reason, it is on the motherboard, on the side opposite of where the CPU is located, next to the I/O and labeled ThinkShield.”
if you’ve ever taken apart a thinkpad you know it’s typically a real pain to get access to the opposite side of the motherboard because it requires removing lots of screws and other components. the 2 chips i have been working with are directly accessible after removing the bottom cover of the machine.
They mentionend MEC1723 and NPCX997 which aren’t SPIs / “bios” chips, these are EC, which have their own firmware (mostly stored directly in the chip and not / very difficult to program with a CH341) and which have been used to store passwords and other secrets.
The parts different from what you intend to flash are
0x5000 ME Boot1 BPDT partition table header = 0x2C6000
0x21A000 ME Data FPT partition table header
0x21B000 ME Data Padding 3
0x299000 ME Data FITC
0x2A1000 ME Data CDMD
0x2C6000 ME Boot2 BPDT partition table header = 0x5000
0x4DB000 ME Boot3 BPDT partition table header
0x3EEFF00 to 0x3EEFFFF bios region cryptic
The pad between ME region and bios region is
EC x 2
Stock bios region
The 16MB file
0xF00 last 0x100 sig of FD
0x1000 to 385D5F ME FWUpdate 0x1000 to 385D5F
E00000 TPMD…NTC 2 lines
E01000 - E3B88D compressed/encrypted fw backup possibly
F00000 TPMD…IFX 2 lines
F01000 - FE0CE7 compressed/encrypted fw backup possibly
The parts of the 64MB chip that are re-written are stuff that’s neither in you original dump or the modified file or uncompressed/unencrypted in the 16 MB file, most probably encrypted and/or compressed in the 16 MB file.
It’s unclear for me why these mentioned address- ranges in the 64MByte chip can’t be rewritten now. Later chips have the ability to protect certain address- ranges, never investigated that any further- and will be difficult from distance.
The compressed/encrypted ranges in the 16 MB file each have a header where the first letters are TPM*, one could take that as a hint. And they’re referenced in the (at least for UEFIToolNE) unstructured padding of the second VSS2 store.
I can’t help you any further here (and I don’t think there’s a way out of this for now).
i really appreciate your having looked into this, despite this unfavorable outcome.
at least we’ve learned something here that others can benefit from:
don’t try to externally write/flash recent thinkpad bios chips, the wson8 64 MB ones in particular.
now that we’ve seen what happens in this scenario, what are your thoughts on using either windows or linux to internally flash a modified bios image? is there a similar risk of bricking the machine, or is it more likely to work when flashing using fwupd or similar?
i got an older thinkpad with ME disabled up and running without event yesterday afternoon, but it used the old skool soic8 chip and didn’t use the newer wson8 one.
Read the datasheets, these chips come as well in SOP16 package, it naive to link this to the package form.
Otherwise read the datasheet regarding ‘Software Protection Mode’
-The Block Protect (BP4, BP3, BP2, BP1, and BP0) bits define the section of the memory array that can be read but cannot be changed.
Individual Block Protection bit provides the protection selection of each individual block.
Hardware Protection Mode: WP# goes low to protect the BP0~BP4 bits and SRP0 bit.
Deep Power-Down Mode:
In Deep Power-Down Mode, all commands are ignored except the Release from Deep Power-Down Mode command and reset command (66H+99H).
=> You have the chips, try to find out if you can read these registers and if they were used to protect the mentioned areas.
You still think that a modded firmware would work if just properly flashed. But this is still a firmware messed with and the anti- tampering measures would step in. In addition you wouldn’t be allowed to flash anything by proper means if you don’t happen to have Lenovos / Intels private keys for signing and the knowledge to prepare your update properly this is afaik not possible to circumvent.
The only possibility I could think of for changing the HAP bit would be to directly change this single bit in the FD, if Flash Descriptor Verification is set to disabled. But the vendor might have enabled additional checks that I’m not aware of to ensure an untampered FD or the ME firmware parts needed for the next verifiacation steps get disabled by HAP and the machine won’t boot because of a stop in verification / measurement process. You’ll need some more T14s to find out.
=> Read about measured boot / measured boot to TPM / verified boot / Bootguard.
=>Every time before modding a newer machine run a MEInfo / MEINfo -verbose and check what it says about “CSME Measured Boot to TPM”, “Verified Boot”, “Measured Boot” and Flash Descriptor Verification.
Only possibility to revive this board would be to desolder the 64MB chip, examine if it’s really has protected blocks and either to reprogram it with the first dump or replace it with a properly programmed new chip. But even then there’s the possibility that kinda "unrecoverable firmware’ switch already is set in the TPM / security chip / EC controller.
