i did get latest flashrom to build, it seemed to have support for GD25B512MF, but it would not read the chip i have here when i manually specified it use the MF chip. i will contact the dev from gigadevice who is adding these devices to flashrom to see if he can add the ME chip i have here.
i fell back to running neoprogrammer on a junk windows machine i have here, and i was able to successfully read the full bios image (64 MB afaict). it immediately detected the correct chip, but it was a legit test of my fine motor skill endurance because it took 9 min 48 sec to read the chip with my ch341a.
since holding the pogo pin adapter in place for nearly 10 minutes without moving is unpleasant and difficult, i would like to know what tools i can use to speed up the read and write process. i’m guessing there is something better than the ch341a which will allow for quicker reads and writes. i did see a company 3ello that makes “professional” grade wson8 pogo pin adapters, so i might get a couple of those.
i can now read the full bios with mfit 16.1.25.2053, and i can see the intel me kernel options and the reserved bit option that will, in theory, allow me to disable ME. i will rebuild the image, write it back, and see what happens shortly.
for documentation purposes, the gigadevice wson8 ic on this board is immediately adjacent to the winbond soic8 ic. both of these ics sit between the nvme and cpu and are obvious once you remove the bottom panel of the machine.
after setting the reserved bit and building, i got a (error?) message in mfit that said
“Selected BtG profile is Boot Guard Profile 5 - FVME. User must be aware of alignment required between Intel(R) CSME FW and BIOS values. In the case of misalignment, for platforms post the EOM phase where FPFs have been burnt, boot issues may be seen.”
i attempted the write the modified image back to the chip, but the machine would not power on. then i attempted to write the original image back to the chip, and the machine is still not powering on.
any thoughts on what is going on? historically, i’ve always been able to write the original image back and get the hw booting again.
Re- configuring the ME gives new hashes wich will be different from the ones stored in bios region, too, and maybe in the TPM and in worst case on the backup chip, too. You might’ve maybe come through with just changing the HAP bit in the FD, but even the FD can have a signature in ME 16.
Searched badcaps already for dumps, didn’t find anything there.
Always make sure that you have definitely a valid dump, especially for an unknown firmware for a platform which allows for extended anti- tampering measures and from a Vendor who likes to use all these measures. (For a working machine you might even try fpt, on a Lenovo Thinkbook with ME 16 fpt -d spi.bin works and gives you a valid dump.)
Just out of curiousity- can you post a link to or attach the dump? MIght be interesting how much redundancy they packed into 64 MByte firmware. Especially since the 16 MB chip you dumped
Is the 16 MB chip the only SPI around there? For a backup there was very little structure and very little from bios region?
normally, i make sure i have 2 matching images when using a soic8 clip, but i got antsy after having to hold the wson8 adapter in place for 10 minutes during the read. this is a painful reminder that i cannot punt on this step with wson8 adapters.
looks like my posts are getting hit by some kind of semi-automated spam flagging. not sure what is going on, annoying.
fun aside - while doing research to determine if other ppl have already figured out how to disable ME on these more recent thinkpad machines, i found very little on the subject, but what little i did find led me to this forum. in particular, the marathon thread on csme system tools got my attention. i just did another search to see if i can dredge up anything further and this post showed up at the top of the search.
that is how little content there is on this topic.
Tthis forum isn’t a central place for people trying to disable ME. There’s a lot of ME knowledge here mainly because of Plutomaniacs work, but disabling wasn’t on focus. So maybe other places were possibly more lucky with disabling ME 16?
But otherwise you’re right, there’s not much to find about the structure of these firmwares.
I assume your dump is pretty much OK, all static parts of the bios region are identical to a stock bios, several copies of the EC firmeware are OK, ME is readable, there’s a copy of parts of the bios region in padding where the static parts of seem to be OK, too.
That’s the last 0x100 of the flash descriptor, seems to be a signature.
And already in the main chip there’s a complete copy of the FD in padding. Might be copies other places, too. And I don’t think the patience of this system is such way that you have infinite options to try things…
am i correct to infer that your take is that this image looks good and should, in theory, be good and it’s simply a matter of flashing it back properly? i did a read of the image i wrote and it didn’t match the hash of the image i uploaded a couple posts back that you’ve analyzed.
the other 16.1 bioses i mentioned in the first post are from mainboards that i’ve successfully disabled ME on. intel B760 boards that don’t have wacky bios configs, e.g. asus, work pretty well with disabling ME. the specific ME versions are 16.1.25.2024 and 16.1.30.2307, both Consumer H. i used me_cleaner repo pull request 384 to get this to work, but i am aware that more recent ME versions have a sku-dependent HAP enable bit location. assuming i can modify this bios and get it booting properly on this hw, i can get it incorporated into me_cleaner.
i’ve ordered a ch347 programmer in hopes that it will allow me to read and write these larger ics without it taking 10 minutes. MeatWar linked me to speed tests that suggest a ch347 is way faster than a ch341. is this the right approach to reduce the read/write times?
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.
