Lenovo BIOS weirdness

During 37C3, I met a nice person with a broken Lenovo laptop, in particular an Ideapad Flex 5 14ALC05. Bespoke device was broken, and with the person being nice, we tried together to recover. During the process I learned a couple of thinks which might be worth sharing, hence this posting.

Symptoms

How did we fix it?

Step 1: Acquire BIOS ROM Image

Go to https://pcsupport.lenovo.com and search for your laptop model, 14ALC05 for us. This device ID might still not be unique! In our case, the model number yielded two results, one with the flex hinge, one without it. Naturally, pick the right one!

Then, find a BIOS firmware update file. Today, this was the navigation flow through the page: Drivers & Software -> Select Drivers -> BIOS/UEFI. Once you are presented with the selection of BIOS firmware update files, think:

Did the latest update brick your device?

If so, maybe try the recovery with the second newest version instead! Sometimes Lenovo seems to remove updates that are known to cause problems after a couple of days. Unfortunately, only one latest version was offered in the download section. However, the numbers in the file name represent version numbers, and the old download links remain intact for some time. This allows us to download an older version:

# loads the most recent version found on the website
curl --remote-name --remote-header-name --location https://download.lenovo.com/consumer/mobiles/gjcn33ww.exe

# loads the second most recent version found on the website
curl --remote-name --remote-header-name --location https://download.lenovo.com/consumer/mobiles/gjcn32ww.exe

Now we have the file, but surely the BIOS will not flash a windows portable executable, will it?

Step 2: Extract the Actual Firmware Update

As hinted already, we have to extract an EFI capsule that contains the firmware update and is consumable by the recovery function. First, we use innoextract to extract the contents of the initial .exe and inspect the results:

innoextract gjcn32ww.exe
cd 'code$GetExtractPath'

In the extracted files we find among other things a GJCN32WW.cap, which using UEFITool we can quickly confirm to be an UEFI capsule. Now that we do have the capsule containing a healthy BIOS ROM image, its time to prepare a USB drive in order to feed it to the BIOS’s recovery function.

Step 3: Serve the Capsule

A neat thing about UEFI is that it understand FAT32 file systems. This makes a flash drive connected via USB an ideal carrier for our capsule. UEFI expects a GUID Partition Table (GPT), with a FAT32 file system. So, prepare a USB flash drive accordingly.

# think before copy pasting
DEVICE=/dev/disk/by-id/usb-...

# you likely need sudo
parted $DEVICE mklabel gpt
parted $DEVICE mkpart ESP fat32 1MiB 100%
parted $DEVICE set 3 esp on

# check for the correct suffix of the partition
mkfs.fat "$DEVICE"p0

This drive has the convenient side effect of also being a valid boot target for a working UEFI, a fact which may become handy later. Now that we have the drive prepared, mount it, and copy the .cap file over to it, naming it BIOS.cap.

Tip some people report other names that worked for them. For us however, BIOS.cap did the trick.

Step 4: Make the Patient Swallow the Capsule

Warning the following section may be inaccurate. Unfortunately we fixed the device, and where not able to reproduce the initial situation. Hence we could not extensively test, whether some of the following steps are really required.

Make sure the device is switched off. Insert the USB drive to the broken laptop, disconnect the charger. Then hit the following two keystrokes repeatedly in an alternating pattern:

It is fine if you do not lift the Fn key. Maybe (likely!) just pressing Fn + R repeatedly suffices. While still smashing the keys, connect the charger. If the device does not power on itself by connecting the charger, power it holding the power button for approximately one second. Eventually (after a dozen of seconds approximately) the recovery function should pick up the file and start.

But how does on recognize that this happens? During the recovery procedure, the screen backlight turns on. The screen does however not display anything, just the black gets lit. Other indicators are the read activity led on your flash drive (if any) and the fans kicking in. During the recovery, the device may restart multiple times, and the backlight as well will toggle. The entire procedure should take about two minutes, after which the device is recovered!

Step 5 (Bonus): Boot your System

Quite commonly, after fiddling with UEFI settings and/or updating UEFI firmware, the boot entries get lost. Worse, many implementations do not actively scan boot targets on the EFI System Partitions (ESP) of internal disks (but only on removable ones, if any are present). This can leave you in a state where none of your previously available boot targets is present, hence breaking boot. A neat way to recover from this is Rod Smith’s rEFInd Boot Manager. Once installed to a CD or a USB drive, it features a UEFI bootable bootloader which itself thoroughly looks for other UEFI boot targets, and presents them in a nice visual menu. It is extensively documented, so go check it out if you have trouble with missing boot entries!