i have been disabling and neutering intel ME on a variety of whitebox and laptop machines for several years, but i am having trouble disabling ME on a recent thinkpad t14 gen 4 laptop i have.
historically, i use a ch341a programmer to read and write bios images, and me_cleaner to modify the bios to the enable HAP bit. i have found me_cleaner (with pull request 384) works fine on recent standalone motherboards that run ME 16.1, specifically 16.1.25 and 16.1.30.
me_cleaner does not work on the ME 16.1.27.2192 that is on this thinkpad t14, so i expect what i’m seeing here is the sku-dependent location of the HAP enable bit. i have come to learn that csme system tools (mfit in particular) allow you to access ME configuration and set the reserved bit in the ME kernel options, which is how me_cleaner was able to find the HAP enable bit locations.
when i use mfit on the 16.1.25 and 16.1.30 bios images i referenced above, i can see the intel ME kernel options and have confirmed that setting the reserved bit maps to the bit flipped by me_cleaner. when i load the bios image from this thinkpad in mfit, it does not show the intel ME kernel options section at all, so i cannot set the reserved bit and enable the HAP bit.
to rule out that this issue was specific to the bios image i had from this machine, i checked out several similar ME images from station drivers that had the same sku, Consumer LP. what i found was that all the images on that site that had the same sku had the same problem: mfit would not show intel ME kernel options after decomposing the image.
is this a known issue that certain skus, e.g. consumer LP, cannot access the intel ME kernel options set via mfit? is there some other known tool for this that i am unaware of?
i assume there is no such tool for this, but figured it couldn’t hurt to ask. my inference is that the only remaining option is informed bit flipping and testing.
can anyone give advice on how to do some informed bit flipping?
What do you mean? Were these complete firmware images with the desired ME version or were that the ME images station drivers provides and which per definition don’t contain these settings?
i got the ME region binaries from station drivers here. i had fetched the LP ones for 16.1.27.2176, 16.1.27.2192, and 16.1.32.2418. on further review, I find that I cannot see the intel ME kernel options for the Consumer S/H sku when loading just the ME region that is found on this site.
i am having trouble uploading my full bios image here. is that expected, given this is my 2nd post?
Those are update images, not regions, and can’t be configured (or: One can do a basic configuration but it’s meaningless since the config never is used in the update process) nor can they be used as a region.
The dump you provided doesn’t seem to be a valid dump. Even with HAP bit set there should be a valid FD defining the regions for boot and a valid bios region.
In addition it has a ME update image where a ME region should possibly begin.
And just the bios region provided from Lenovo for a T14 Gen 4 is 25MB in size while your ‘complete dump’ is 16MB.
the image i provided for the t14 gen 4 is what i read off the winbond chip on the board via flashrom. i’ve done several reads and confirmed that the data is consistent.
it sounds like that dump is not the complete bios image, so i am guessing that is the backup image. there is a wson-8 chip next to the winbond one, and that is likely the one with the full bios image.
unfortunately, when i try to read that chip with my 6x8 pogo pin adapter, the chip comes up as unsupported by flashrom. i checked the flashrom hw support list and a similar chip, gigadevice 25B512MF, just had support added 2 weeks ago, but this chip is a gigadevice 25B512ME. i can try building latest flashrom from source to read this chip, but i suspect it still won’t work.
any thoughts on how to work around flashrom lacking support for this chip?
Don’t see relevant differences? The ME type has DTR listed, but I don’t think this is used by a programmer. I don’t use flashrom, no command line switches to define a chiptype?
you’re suggesting i manually specify the MF chip instead of the ME because they should work the same for the purposes of reading and writing the image, correct?
my familiarity with bios details like this is obviously limited, thus my checking before i go and build flashrom from master.
i will post some pics once i confirm this image is the correct one. i am indeed keen to make this process easy to reproduce for others who are less persistent than i am.
noted re neoprogrammer support. i’m a computer security nut, so i haven’t run windows in a very long time. glad to know it’s a fallback option tho
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?
