I got a new to me X1 carbon with gen 11 CPU. I want to do my thing and turn off ME and enable undervolting, yada yada. First I tried with software, but nvram variable writing is blocked. Then I tried with FPT and it can read but cannot write. Even though bios region unlocked, writing is not possible from EFI shell or system. No Ru.efi, UMAF, grub, etc either.
Ok, time to whip out the hardware programmer. Read the rom, several times with both PI and dedicated programmer. This is weird, header is shifted and stuff is missing. Especially compared to the FPT dump.
In the FPT dump, I can find the setup store and edit the flags I need, easy peasy, unfortunately the nvstore and our previous happy patch to “lnvsec” to make any other bios mods is missing. It’s like either the progammers are wrong or the stuff is encrypted now. I can at least do HAP bit inside the “shifted” header but I’m scared to flash back. I did not try to downgrade bios yet with vendor tools to see if the situation changes. I think limit for me is 1.6x because previous versions cause charging mosfets to burn out. Never have seen this on the internet before.
Newer machines tend to have a anti- tamper / backup / recovery image on another chip (half size or same size as firmware chip) which isn’t accessible by fpt and doesn’t have a normal firmware structure.
If you’re lucky you have an option in bios to disable it but I’m not sure if you can disable anti- tamper completely
Your programmer dump is a typical recovery image, last part of bios in the middle, in the beginning 2 times EC firmware, after bios region parts there’s parts of the ME region.
Yea, I asked multiple places because not so many people interested anymore. No surprise with what it takes to play with these bios. Even with a real read and editing the nvstore the system may say nvram checksum invalid. I don’t know any other attacks that would undo spi lock in this bios.
Yes, and it’s quite unpredictable how these recovery tries will work out. We had two examples of bricked machines stumbling over tamper protection / firmware recovery after using a hardware programmer ( 1 , 2 )
Haven’t heard from these two, hopefully they found someone who was able to unbrick those machines!
Oh wow, that’s scary. I can at least compare the dump I get to the one I took with FPT. I don’t see that he used the proper PR for the 15.x me hap bit.
Hmm… that guy posted about fit tool not working with his image if I read that right.
The bios region in the recovery chip corresponds to the bios region of the active bios region. BUt this doesn’t correspond to an same version update file since one EFI volume from update file ‘disappears’ / changes to empty padding in working bios region:
I wonder if it always compares the recovery to the bios and fails if it’s not the same. That’s why the sites have you flashing both chips. I read somewhere that they keep a previous version of EC or ME in there but the ones you find are the same.
The question is what happens when I downgrade officially. If backup on the recovery chip changes and if the FPT reread bios opens in FIT again.
I want to at least solve part of the mystery, whether I try to mod it or not.
It’s not always the same and might in addition dependant on update structure. Forr your machine the last 5 updates had the same EC version included, it might be that the two EC versions if the latest update had updated EC version, too.
(I wonder why there’s nothing about CSME data, there should be, nut I assume it’s encrypted. There were missing hints for the TPM, though, maybe since this Thinkpad has a fTPM.
EDIT
I’d recommend to run MEInfo -verbose on that machine
MEInfo - possible protection mechanisms (examples from a Thinkbook 16 G6)
Factory Defaults Restoration Status Disabled
…
Factory Defaults Recovery Status Enabled
…
CSME Measured Boot to TPM Disabled
BIOS Recovery State Enabled
FW Supported FPFs FPF UEP
BSMM Firmware Version Control Enabled Enabled # Disabled=0, Enabled=1
CSE FW Firmware Version Control Enabled Enabled # Disabled=0, Enabled=1
CSME Bootstrap Firmware Version Control Enabled Enabled # Disabled=0, Enabled=1
DNX Firmware Version Control Enabled Enabled # Disabled=0, Enabled=1
Error Enforcement Policy 0 Enabled Enabled # Disabled=0, Enabled=1
Error Enforcement Policy 1 Enabled Enabled # Disabled=0, Enabled=1
Flash Descriptor Verification Disabled Disabled # Disabled=0, Enabled=1
Glitch Detection Disabled Enabled Enabled # Enabled=0, Disabled=1
IDLM Firmware Version Control Enabled Enabled # Disabled=0, Enabled=1
…
Measured Boot Enabled Enabled # Disabled=0, Enabled=1
Verified Boot Enabled Enabled # Disabled=0, Enabled=1
Key Manifest ID 0x01 0x01
Force Boot Guard ACM Enabled Enabled # Disabled=0, Enabled=1
OEM key Hash RSA key size Enabled Enabled # Disabled=0, Enabled=1
…
PMC Firmware Version Control Enabled Enabled # Disabled=0, Enabled=1
…
ROT Firmware Version Control Enabled Enabled # Disabled=0, Enabled=1
…
Secure boot KM Firmware Version Control Enabled Enabled # Disabled=0, Enabled=1
…
uCode Firmware Version Control Enabled Enabled # Disabled=0, Enabled=1
I am also trying to mod a newer Lenovo laptop (P14S Gen4) with nearly identical defenses. Greatly interested to see what folks can figure out. I suspect things like their NVRAM CRC checks can be worked around, there is just a lot of security through obscurity / not enough people looked into it yet. What I worry is some of these defenses use the EC’s flash memory. Lenovo laptops don’t usually have easy JTAG access (yes, JTAG debug ports exist, but typically microscopic test points on top of mobo).
Btw, for the PreOs_VerifyHash string in the unknown 0x18E6000 - 0x19D7570 region, it is part of some ME firmware (RBEP partition). Not all ME firmware has that string, however.
Regarding self-healing functionality- this is what I am getting stuck on besides CRC checks for NVRAM. On my device, I have one large 64 MB WSON8 BIOS chip (there is a 16 MB SOIC8 chip for EC, but seems like ME firmware). I used Intel CSME v16 MFIT to decompose the 64 MB WSON8 dump. Interestingly, the image BIOS region is duplicated in the EcPlugin#EcRegion.bin. I did a diff on a UEFITool report for the BiosPlugin#BiosRegion.bin original BIOS and EcPlugin#EcRegion.bin duplicate, it is the same, except EC duplicate has no NVRAM content.
I have not tried modding both the heal region + original BIOS at same time yet. Unfortunately, much of my BIOS is protected by Intel Boot Guard, including Phoenix hash file which covers SMM/etc. I am not very optimistic.
The Thinkpad T14 G4 in the linked post had the 64/16 MByte configuration you mentioned. Even if you can find sources / relations for all the code and data duplicates, it’s unclear where hashes are stored. Lenovo’s known for having a security chip / using parts of the EC- chip as secure storage, now they might have hardware TPM in addition.
And that Tp T14 G4 had a discrete TPM and some hints that it’s been used for the duplicate data:
In addition there’s the second VSS2 store which looks kinda corrupted / unstructured in UEFIToolNE, but stores data related to recovery / tampering:
This store har references to parts of the 16 MByte file and the TPM (pics from the machine in this thread)
I’m mostly interested in recovery of these firmware images, but even emptying NVRAM or cleaning an ME seems almost impossible for these configurations.
Slowly reversing some of their protection mechanisms. For example, MeResiliencyDxe is responsible for triggering the recovering ME firmware dialog if you flash the SOIC8 16KB chip (I tried to flash using old dump from another forum for the same device). Still working through the code as I am not too experienced with reversing UEFI firmware modules.
Regarding your comments on TPM/security chip, they definitely measure various firmware metrics into TPM and a few different event logs, but 1) you should always be able to flash back to original and it should work, e.g., if you change things one boot session, fail a CRC check, and restore flash to original, next boot should be back in working order. 2) unless you have important things in TPM, surely must be a way to disable it (via FIT option or maybe setup variables if we can get pass NVRAM defenses). Even EC, I have read on some other modding forums people successfully shorting things like LPC to unlock bios password / break EC-backed defenses (unfortunately, the documented attack is for older devices with LPC communication to EC, vs. eSPI on newer devices). Though maybe Intel TXT is relevant here too which is something I lack experience with.
I have not tried many of these methods because I first want to understand how their defenses work and what they rely on rather than throwing things at the wall and seeing what works.
New findings to share:
Somewhat interestingly, if you replace the ME partition in both the SOIC8 16 KB and WSON8 64 KB flash chips, it will still trigger ME recovery, but it fails halfway through on my device and still boots. If one of your goals is to clean ME, I wonder if it’s worth simply following regular ME cleaner guides, at the expense of needing to wait for the recovering firmware dialog at every boot. Obviously not ideal, but a start.
I also made some progress on the confusing 16 KB flash chip. On accident, I loaded the SOIC8 16 KB “recovery” dump (instead of WSON8 64 KB dump) into CSME v16 MFIT- it was recognized as “Intel(R) AlderLake P Chipset - FWUpdate - SPI”. Not sure if you knew this, I see references to this fact in the thread you linked. In that same thread, you also mention how the end of the 16 KB chip (0xE00000 onward) had unknown data related to “TPM backup header” strings. I did some reversing, this data is set by TpmResiliencyDxe. My hypothesis reading the code is 0xE00000/NtcTpmFwBackupHeader and 0xF00000/IfxTpmFwBackupHeader, whose addresses are directly referenced by TpmResiliencyDxe, store backup firmware for Infineon and Nuvoton TPMs respectively. Doesn’t seem relevant unless you wanted to flash the TPM with custom firmware, but haven’t thoroughly looked into it (e.g., decoded firmware payload).
Unless I am missing something, this should be the entire layout of the 16 KB chip: Intel FWUpdate up to 0xE00000, Nuvoton Firmware up to 0xF00000, Infineon Firmware onward to end of flash.
While looking for more info on FWUpdate payloads, I found this helpful post from @sierzant which discusses how he built a cleaned FWUpdate image via MFIT.
For cleaning ME, I wonder how the system will react if you follow the same instructions to create a cleaned FWUpdate image, use standard guides to swap ME in 64 KB WSON dump with cleaned ME, flashed 16 KB SOIC8 with the cleaned FWUpdate, and flashed 64 KB with a swapped clean ME (both FWUpdate ME and 64 KB ME should be identical). This seems like a promising avenue.
One final discovery I wanted to share in case there are any ME experts lurking. I noticed that in the MFIT End of Manufacturing config for the Lenovo BIOS, they seem to only lock the flash descriptor, not the OEM config. In the image above, the left is MFIT with the Lenovo BIOS, right is an unrelated Dell BIOS image. Dell locks both descriptor AND OEM config. I am not familiar enough with ME, but I am very curious about the implications of OEM config not being committed to FPFs. What control does being able to change OEM configs give us? Also, maybe worth verifying this discovery via MEInfo dump before we get too excited, to make sure Lenovo isn’t manually committing OEM config to FPFs or something.
If you manually alter nvram region does it fail? I found the strings to disable undervolting lock in several places, at least 3 or 4 within the nvram. I was going to flip the 2 bits on all of them. For ME, I think you only have to set the HAP bit inside the FD.
In the other “desktop” thread. FIT had an option to disable the second chip. I will have to see what happens when my clip comes. This is the most expensive thinkpad I bought at $500 usd. For now all I can do is downgrade the bios and read out both chips again (one with FPT to see what alters and if FIT ingests it)
For cleaning ME, I wonder how the system will react if you follow the same instructions to create a cleaned FWUpdate image
Can this be used to flash a bios region image if it opens in FIT? With full nvram variables?
Yes, you can set most NVRAM variables via flash access. I misunderstood earlier and believed they were smart enough to hash the entire NVRAM region to prevent direct flash modifications. They only monitor a few NVRAM variables related to “security settings”. Haven’t reversed exactly which ones/what parts.
I am interested in more than overclock unlocking, but seems like if that’s all you want, you should be able to use direct flash access to overwrite the CpuSetup NVRAM variables.
I don’t believe so. From what I can tell, these FWUpdate images are just for the ME region. You might be able to clean ME with just software. I am using a WSON8 test probe for direct access, vs. software approach.
Following up on an earlier discovery where I found that the self healing BIOS region is stored as the EC region in MFIT. I tried doing a simple modification to a DXE driver in this backup BIOS image and the real BIOS image. Not protected by Intel Boot Guard, just the Phoenix hash file. I used UEFI Tool v28 for most of it. I verified that no data was lost by doing a diff of the UEFITool report from before and after my modification. Everything was well-formed (including CRCs etc).
Unfortunately at boot, the ESC/F1/F4 keys briefly flash for 4-10 seconds, after which the only light that remains is the power button. The machine does not boot from that point. I waited 20-30 minutes in this state. The power button does not work either; I had to manually disconnect battery.
Edit: I also tried a mod where I only swapped the BIOS recovery region with a modified version. Works fine, not sure if I can trigger BIOS recovery via UI, but suspect the same result would occur even if I got the software to do the BIOS edit for me.
I saw some past forum posts where folks were able to modify the firmware code by simply swapping the DXE driver. I thought what might prevent this in modern devices is the recovery mechanism, but it seems like they’re actually verifying both. After manual power disconnect, I dumped flash and compared with what I wrote. There were no changes (interesting because usually there are event log additions at every boot). Unclear if what is halting boot is EC. I have a hunch it might actually be the proprietary “security chip” but total speculation. Probably need to PCH JTAG debug to step through code and find culprit.
At least it seems good that full backups will restore the machine to a bootable state as long as they are correct. What more can I get besides undervolt? I know previously it was possible to enable advanced menu and that would be nice. At least my theory to modify the nvram is sound. Makes me more confident in trying things when the clip arrives.
