Dumping my Laptop’s Flash Chip

a measurement clip attached to a SPI flash chip on a computer motherboard

I’d like to know what firmware is running on my Thinkpad. Not only out of curiosity, but wouldn't it be nice to change the boot logo, patch features, or explore free alternatives like Coreboot?

But before doing anything dangerous, I wanted to create a full backup of the flash chip. Doing this with physical access to the chip has several advantages:

  • You can bypass potential software checks like rollback-prevention features or integrity tests of the firmware when (re-)writing the chip

  • You can be sure that you get read and write access on the full chip, not just the sections that are meant to be accessible for a user firmware update.

To get to the firmware image and create the backup, I used a FlashcatUSB Pro device for reading out the memory chip. The chip is a standard SPI flash in an SO-8 package. I also hooked up a Saleae Logic Analyzer for debug purposes, as the connection of those test adapters can be a bit wonky at times.

After acquiring the dump, my goal was to analyze the image to find (and eventually change) the Lenovo boot logo.

Analyzing the dump

First, I analyzed the dump with binwalk and strings to see if I can spot anything interesting right away. Binwalk did indeed find some stuff, including the Lenovo boot logo, certificates and more. Looks promising.

I proceeded with a more tailored analysis by using UEFITool. This is an open source UEFI image viewer which can parse the flash image. After fiddling with endianness, the memory dump was recognized by the tool and showed me the contents of the firmware dump:

screenshot of uefitool showing the contents of the firmware image
UEFITool showing the LenovoSplashDxe driver.

As you can see, there are many DXE files stored in the image, which conveniently come with a descriptive text. One DXE driver is called “LenovoSplashDxe”, which likely contains the code necessary for displaying the splash screen with the Lenovo logo. Loading the PE32 executable into Ghidra does indeed reveal some code and the embedded logos in different resolutions:

Ghidra screenshot showing the embedded manufacturer logos in the firmware image
Ghidra analysis showing the boot logos in different resolutions.

Altering the firmware

Even without disassembling a single instruction I discovered the boot logos. Now I just have to patch the file to include any GIF logo I want, reflash the chip, and I'm done, right?

After experimenting, I noticed that my system would not boot anymore after only minor changes to the firmware binary. I am quite sure that this is due to some integrity verification mechanism, most likely backed by Intel Boot Guard. With this, it is very difficult to alter the firmware, as the image must be signed by the OEM. Their keys may have been burned into the CPU by OTP fuses at the time of manufacturing, making it impossible to change them. This could maybe be bypassed by injecting data on the SPI bus the flash chip sits on, provided that verification and execution of the code results in two different accesses. But I haven’t got time to try this yet.

It is possible to check for the presence of Intel Boot Guard using intelmetool, which returns the following output on my system:

MEI found: [8086:2e0] Comet Lake Management Engine Interface

ME Status   : 0x94000245
ME Status 2 : 0xf58506

ME: FW Partition Table      : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : YES
ME: Manufacturing Mode      : NO
ME: Boot Options Present    : NO
ME: Update In Progress      : NO
ME: Current Working State   : Normal
ME: Current Operation State : M0 with UMA
ME: Current Operation Mode  : Normal
ME: Error Code              : No Error
ME: Progress Phase          : ROM Phase
ME: Power Management Event  : Clean Moff->Mx wake
ME: Progress Phase State    : (null)

ME: Extend SHA-256: 0a2b4a8a7baa52c01b786eec0cc86afea385051d8947c939c4d73c0f753ae58d

ME: Firmware Version 14.1.1969.65 (code) 14.1.1969.65 (recovery) 14.0.1367.39 (fitc)

ME Capability: Full Network manageability                 : ON
ME Capability: Regular Network manageability              : OFF
ME Capability: Manageability                              : ON
ME Capability: Small business technology                  : OFF
ME Capability: Level III manageability                    : OFF
ME Capability: IntelR Anti-Theft (AT)                     : OFF
ME Capability: IntelR Capability Licensing Service (CLS)  : ON
ME Capability: IntelR Power Sharing Technology (MPC)      : OFF
ME Capability: ICC Over Clocking                          : OFF
ME Capability: Protected Audio Video Path (PAVP)          : ON
ME Capability: IPV6                                       : ON
ME Capability: KVM Remote Control (KVM)                   : ON
ME Capability: Outbreak Containment Heuristic (OCH)       : OFF
ME Capability: Virtual LAN (VLAN)                         : ON
ME Capability: TLS                                        : ON
ME Capability: Wireless LAN (WLAN)                        : ON
Boot Guard MSR Output : 0x30000007d
Measured boot        : ON
Verified boot        : ON
FACB in FPFs         : ON
Module revoked       : OFF
TPM type             : TPM 2.0
TPM success          : ON
NEM enabled          : ON
Verified boot is enabled and ACM has enabled Cache-As-RAM.
You can't flash other firmware!

Unfortunately, this seems to confirm that my laptop has Boot Guard enabled, which seems to be the standard configuration for modern notebooks. This prevents “easy” manipulation of the firmware. However, there might still be security vulnerabilities in the firmware that might allow an attacker to execute arbitrary code anyway, e.g., through a memory corruption bug. A good example of this is LogoFAIL.

If I find the time I will take a closer look at some of the firmware code itself. Another thing to discover during reverse engineering might be hidden features, such as the “advanced” settings present in some Thinkpad firmwares.