A Guide to UEFI Firmware Analysis and Modification

1. Introduction

1. Introduction

I will be using a Lenovo Yoga 710-15IKB with a 7th Generation Intel i5-7200U and 8GB of RAM. The 7th Generation Porcessor lacks the TPM needed to upgrade to Windows 11. It also employs Intel Boot Guard preventing me from using an open-source BIOS/UEFI such as Coreboot.

Since I cannot override the proprietary BIOS/UEFI, I will prepare it for virtualization use with a Type 1 Hypervisor. Modern virtualization relies on a suite of hardware-assisted features built into the processor and supporting platform components. A quick and dirty confirmation is to check from the Task Manager.

Ctrl+Shift+Esc to open Windows Task Manager, and navigate to the Performance tab, select the CPU monitor and in the bottom left you should see "Virtualization:".

I had to dig a bit deeper into the spec sheets of my specific hardware configuration. This confirmation is critical, as it eliminates the processor as a potential point of failure and definitively proves that the hardware is, at its core, capable of performing the desired function.

A thorough analysis of the official technical specifications for the SoC processor models reveals that all late-2016 Yoga Hardware configurations provide full, unequivocal support for the entire suite of relevant Intel® Virtualization Technologies. This includes not only the baseline VT-x but also with Extended Page Tables (EPT) and VT-d.

Intel® VT-x

This is the foundational instruction set extension that allows the hypervisor to create and manage secure, hardware-isolated virtual machines by providing hardware hooks that allow a hypervisor, or Virtual Machine Monitor (VMM), to efficiently manage and isolate multiple guest operating systems on a single physical processor. VT-x accelerates the execution of privileged instructions within a virtual machine (VM), significantly reducing the performance overhead that would otherwise be incurred by pure software emulation. The presence and activation of VT-x are prerequisites for running nearly all modern 64-bit virtual machines.

Extended Page Tables (EPT): A hardware feature that dramatically accelerates memory virtualization by adding a second layer of address translation, allowing the CPU to convert a VM's memory addresses to the actual physical RAM in silicon without constantly interrupting the hypervisor. This substantial reduction in overhead leads to faster memory access, more efficient CPU usage, and stronger, hardware-enforced memory isolation between virtual machines.

Intel® VT-d

Extends hardware assistance beyond the CPU to the system's I/O pathways. It is an I/O memory management unit (IOMMU) technology that remaps I/O Direct Memory Access (DMA) transfers. In practical terms, VT-d allows a hypervisor to securely and directly assign physical hardware devices, such as a network interface card, a storage controller, or, most commonly, a discrete graphics processing unit, to a specific guest operating system. This process, known as "passthrough," gives the guest VM exclusive, near-native performance access to the hardware device.

1.0.1. Entering the Yoga 710-15IKB BIOS

Lenovo provides several distinct methods for entering the BIOS setup utility, accommodating different scenarios from a cold boot to a restart from within the operating system.

Function Key Method: This is the most traditional method. Power on the laptop from a fully off state. As soon as the Lenovo logo appears on the screen, immediately and repeatedly press the F2 key. On some models, it may be necessary to hold down the Fn key simultaneously while pressing F2 (i.e., Fn + F2). This action must be performed within a very short time window before the operating system begins to load, and it may take several attempts to succeed.
Novo Button Method: A feature specific to many Lenovo consumer laptops is the Novo button. This is a small, recessed button typically located within a pinhole on the left or right side of the laptop's chassis, often marked with a small U-shaped arrow icon. To use this method, the laptop must be completely shut down. Then, using a straightened paperclip or a SIM card ejector tool, gently press and release the Novo button. The laptop will power on and display the "Novo Button Menu," which provides options to enter the normal startup sequence, the BIOS Setup, the Boot Menu, or the System Recovery environment. Selecting "BIOS Setup" from this menu will directly enter the configuration utility.
Windows Advanced Startup Method: If the system boots too quickly to reliably press the function key, the BIOS can be accessed from within a running Windows 10 or Windows 11 operating system. Navigate to Settings > Update & Security > Recovery. Under the "Advanced Startup" section, click the Restart now button. The system will reboot into a blue options menu. From here, select Troubleshoot > Advanced options > UEFI Firmware Settings. Clicking this final option will prompt one more restart, after which the system will boot directly into the BIOS setup utility.

1.0.2. Virtualization (VT-x) Activation and disabling Secure Boot

Once inside the BIOS setup utility, navigate the menus to find the available virtualization settings. For Lenovo IdeaPad and Yoga series laptops, this option is most commonly located under the Configuration tab. Regardless of manufacturer, the setting is typically labeled simply as Intel Virtualization Technology.

Next, turn off secure boot as this feature will prevent an unsigned UEFI shell from loading. Navigate to the "Security" tab and ensure that the "Secure Boot" option is set to Disabled.

Secure Boot: Security standard designed to ensure that a device boots using only software that is trusted by the Original Equipment Manufacturer (OEM). By default, many systems are configured to only trust bootloaders signed by Microsoft, potentially hindering the installation and use of a Hypervisor.

While disabling Secure Boot does remove a valuable security layer, it only protects the moments before the main operating system takes over. Since all other security measures are still fully active, the setup can still be considered safe by focusing on other security principles, especially in a controlled server environment. The safety comes from mitigating the specific risks that Secure Boot protects against.

Secure Boot is most effective at stopping threats that require physical access, if your server is in a physically secure location (like a locked server closet or a data center), this risk is already heavily mitigated.

We will be installing Xen and Debian from the official, cryptographically verified Debian repositories. This ensures you aren't installing a pre-compromised hypervisor. The Debian host (Dom0) will be a minimal installation with functions limited to only managing VMs. As long as you won't be browsing the web, checking email, or plugging in untrusted devices to the host OS, you drastically reduce the chances of malware ever reaching it in the first place.

You can, and should, enable Secure Boot for your individual guest VMs (DomUs), provided their operating systems support it. This means that even if the host hypervisor booted without Secure Boot, your guest operating systems can still benefit from that layer of protection within their own virtualized environment.

1.0.3. VT-d Activation

To ensure no compatibility issues down the line, we will also need to enabled I/O passthrough so that the virtualization software can utilize all of our hardware beyond just the CPU.

On most consumer laptops, it's unlikely to be able to simply activate IOMMU from the standard UEFI. This is a standard practice for delinneating consumer from professional product-lines laptops, where manufacturers often create artificial restrictions to advanced features like VT-d, which are frequently reserved for more expensive, enterprise-oriented product lines such as the ThinkPad series.

Direct UEFI Variable Modification for VT-d Enablement

This section provides a detailed protocol for enabling Intel® VT-d by directly modifying hidden configuration variables within the UEFI firmware.

Attempting high-risk firmware patching without first acquiring a CH341A programmer and creating a valid backup is an act of extreme recklessness. The hardware programmer is the safety net that makes advanced firmware exploration possible.

A CH341A programmer is an inexpensive, widely available USB device designed to interface at a hardware-level directly with the 8-pin Small Outline Package (SOP) inregrated circuit. Also known as an SPI (Serial Peripheral Interface) flash memory chip. With a SOP8 Test Clip, it allows a user to read the chip's entire contents to a file (creating a perfect backup), erase the chip, and write a new file (a new firmware image) back to it.

This tool operates completely independent of the laptop's CPU, operating system, and all software-based security mechanisms. It bypasses digital signature verification, checksum validation, and any restrictions imposed by the manufacturer's flashing utilities. For this reason, it is the ultimate tool for both advanced firmware modification and, more importantly, for recovering a system from any form of firmware corruption. The physical accessibility of the SPI flash chip represents a "hardware backdoor" that provides total control to anyone with the right tools and physical access to the device. We will be continuing without one for now as we will be focusing on Non-Persistent Modification using variable manipulation.

Modern UEFI firmware architecture store configuration settings, both those visible in the UEFI and those that are hidden, in protected data blocks called "VarStores". The graphical UEFI is merely a front-end for modifying a subset of these variables. However, it is possible to bypass this limited interface by booting the system into a command-line environment known as a UEFI Shell. From within this shell, specialized tools can be executed to directly read from and write to these underlying configuration variables, allowing for the modification of settings that the manufacturer has chosen to hide from the user. The principal tool for this task is a command-line utility named setup_var.efi.
1. Toolkit Assembly
  
  The procedures described in this section are performed entirely at the user's own risk and are not supported by Lenovo. Modifying UEFI variables involves writing directly to the system's non-volatile firmware storage. An error in this process, such as specifying an incorrect variable offset, writing an incorrect value, or interrupting the process, can lead to irreversible firmware corruption. This can result in a "bricked" system, meaning the laptop will be permanently unable to power on or boot. There is also a risk of data loss. Before proceeding, ensure all critical data is backed up to an external device. Proceed only if the requirement for VT-d functionality is critical and outweighs the substantial risk of rendering the hardware permanently inoperable.
  
  To perform the firmware modification, the following software and hardware components are required:
  
  The Official BIOS Update File
  The 2xcn38ww.exe file for the Yoga 710-15IKB, which contains the raw firmware image to be analyzed.
  
  UEFITool
  A utility for parsing and navigating the structure of UEFI firmware images. This is used to locate the specific module containing the setup variables.
  
  Universal IFR Extractor
  A tool that can decompile a UEFI setup module into a human-readable text file, revealing the names, options, and memory offsets of all configuration variables.
  
  Bootable UEFI Shell
  A pre-compiled UEFI Shell environment (e.g., from the open-source project pbatard/UEFI-Shell) that provides the command-line interface.
  
  setup_var.efi Utility
  The command-line tool used to read and write UEFI variables from within the shell.
  
  USB Flash Drive
  A spare USB drive of any common capacity (e.g., 8 GB), which will be formatted to create the bootable UEFI environment.
  
  The most critical part of this process is to identify the precise memory offset of the hidden VT-d setting within the UEFI variable store. This offset is specific to the hardware model and BIOS version. Using an incorrect offset will corrupt the firmware. Therefore, it is essential to perform this analysis on the specific firmware file. The following steps outline this analytical process.
2. Download the BIOS Image:
  Navigate to the manufacturers product specific support page and ensure you download a copy of the most recent BIOS Image. The Lenovo Support Center download link will requre you enter the device serial number to ensure the downloaded image contains the right drivers for your exaxt system config.
  
  Once you have been redirected, you can right click on the download button and select Copy Link Address. Paste the link into the text box here to create a curl command for collecting the download.
```
curl -Lo "__BIOS_URL__"
```
  BIOS URL:
3. Verify the BIOS Integrity
  In the BIOS Download page from Lenovo Support Center, there is a View Checksum hyperlink. It is a digital fingerprint, used to check whether errors have occurred in transmission or storage. We will compare this provided checksum with the checksum of our downloaded file.
```
sha256sum 2xcn38ww.exe
```
  For our specific BIOS, it should be:
```
bfbaf6e9d5ad060dab798101773d2d370f62a85ae323f7357c03c2ad08be17f5 
```
4. Extract the Raw BIOS Image:
  We will use the archive extracting utility, innoextract, to extract the contents of the self-extracting installer.
```
innoextract -l 2xcn38ww.exe
```
  It should return the following;
```
Listing "Lenovo BIOS Update Utility" - setup data version 5.5.7
 - "app/2XCN38WW.exe" (5.99 MiB) - overwritten
 - "app/2XCN38WW.exe" (5.99 MiB)
Done.
```
```
innoextract -e 2xcn38ww.exe
```
```
Extracting "Lenovo BIOS Update Utility" - setup data version 5.5.7
 - "app/2XCN38WW.exe" - overwritten
 - "app/2XCN38WW.exe"
Done.
```
  Next, we will navigate to the extracted directory, app/, and attempt to continue to extract the contents until a single, raw firmware image file is located.
```
innoextract -l 2XCN38WW.exe
```
  However, it gives the following stderr
```
Not a supported Inno Setup installer!
Done with 1 error.
```
  We can officially move to extracting with 7Zip. First, we need to examine the executable before extracting:
```
7z l 2XCN38WW.exe
```
  You should find the following:
```
   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------------------
2008-01-15 00:25:00 ....A       105886        72290  Ding.wav
2015-12-16 02:28:45 ....A          526               Microsoft.VC90.CRT.manifest
2015-12-16 02:28:45 ....A          550               Microsoft.VC90.MFC.manifest
2018-07-09 01:29:50 ....A      9152488      4455993  CIUY7212.bin
2018-07-09 02:24:47 ....A        50432         9912  platform.ini
2015-12-17 03:49:06 ....A        42440      1252052  FlsHook.exe
2012-07-02 04:50:48 ....A       225560               FWUpdLcl.exe
2016-09-23 01:20:13 ....A       891904               H2OFFT-Wx64.exe
2015-12-16 05:42:22 ....A       286664               BiosImageProcx64.dll
2015-12-16 02:28:45 ....A      1679864               mfc90u.dll
2015-12-16 02:28:45 ....A       851456               msvcp90.dll
2015-12-16 02:28:45 ....A       627200               msvcr90.dll
2015-08-26 04:49:24 ....A        67240               iscflashx64.sys
------------------- ----- ------------ ------------  ------------------------
2018-07-09 02:24:47           13982210      5790247  13 files
```
  The firmware image will typically have an extension such as .bin, .fd, or .rom. For us, we can verify it is CIUY7212.bin based on the extension, the file size and the modified date.
  
  We can now safely extract the installer to read the image.
```
7z e 2XCN38WW.exe
```
5. Load Firmware Image in UEFITool:
  We need to download the GUI UEFITool from the official GitHub repository. The maintainer at time of writing is LongSoft.
```
curl -Lo uefitool "__UEFI_URL__"
```
  UEFITool URL:
  
  Make it executable;
```
chmod +x uefitool
```
  Execute and open the raw firmware image file extracted in the previous step.
```
./uefitool CIUY7212.bin
```
  The tool will parse the file and display its hierarchical structure.
6. Extract the Setup Utility Body:
  
  Use the search function, Ctrl+F in the search dialog, switch to the "Text" tab and search for the Unicode text string "VT-d". The search results will likely point to a PE32 image section within a firmware volume. This section is the setup module that contains the definitions for the BIOS configuration screen.
  
  In the UEFITool interface, double-click the search result to navigate to the PE32 image section in the main window. Right-click on this highlighted section and choose the option Extract body.... Save the resulting file with a .bin extension (e.g., SetupUtility.bin).
7. Generate the IFR Text File:
  We will need to download the Universal IFR Extactor utility, which is also currently maintained by the same LongSoft.
```
curl -LO ifrextractor "__IFRE_URL__"
```
  IFR Extractor URL:
  
  Extract the download:
```
7z e ifrextractor
```
  Make it executable;
```
chmod +x ifrextractor
```
  Now, we need to verify the contents of the SetupUtility.bin using the new tool to read the file and print the output to the terminal:
```
./ifrextractor SetupUtility.bin list
```
  You should see various UEFI HII String Packages and UEFI HII Form Packages.
```
UEFI HII form packages:
Index: 0, Offset: 0x91894, Length: 0x163, Used strings: 28, Min StringId: 0x0, Max StringId: 0x157E
Index: 1, Offset: 0x92B84, Length: 0x48E, Used strings: 36, Min StringId: 0x0, Max StringId: 0x1477
Index: 2, Offset: 0x94044, Length: 0x1EB, Used strings: 42, Min StringId: 0x0, Max StringId: 0x143A
Index: 3, Offset: 0x98804, Length: 0x1FFA4, Used strings: 5038, Min StringId: 0x0, Max StringId: 0x157C
Index: 4, Offset: 0xB9844, Length: 0x281, Used strings: 22, Min StringId: 0x0, Max StringId: 0x1576
Index: 5, Offset: 0xC8A74, Length: 0x24C, Used strings: 11, Min StringId: 0x0, Max StringId: 0x66
Index: 6, Offset: 0xC9D64, Length: 0xA66, Used strings: 89, Min StringId: 0x0, Max StringId: 0x141
Index: 7, Offset: 0xCB8A4, Length: 0xA04, Used strings: 77, Min StringId: 0x0, Max StringId: 0xEF
Index: 8, Offset: 0xCD2D4, Length: 0x201, Used strings: 17, Min StringId: 0x0, Max StringId: 0xE1
UEFI HII string packages:
Index: 0, Offset: 0x3E5D4, Length: 0x4AEA5, Language: en-US, Total strings: 5503
Index: 1, Offset: 0x89479, Length: 0x31EA, Language: fr-FR, Total strings: 194
Index: 2, Offset: 0x8C663, Length: 0x1C7A, Language: zh-TW, Total strings: 180
Index: 3, Offset: 0x8E2DD, Length: 0x1966, Language: ja-JP, Total strings: 114
Index: 4, Offset: 0xBBD84, Length: 0x5BDE, Language: en-US, Total strings: 322
Index: 5, Offset: 0xC1962, Length: 0x2C4C, Language: fr-FR, Total strings: 177
Index: 6, Offset: 0xC45AE, Length: 0x159B, Language: zh-TW, Total strings: 170
Index: 7, Offset: 0xC5B49, Length: 0x1E47, Language: ja-JP, Total strings: 170
Framework HII form packages: none
Framework HII string packages: none
```
  If it appears the correct PE32 Image body was extracted, we will create a new directory to extract every possible combination of the forms and strings.
```
mkdir ifr
```
  Copy the necessary files into the new directory
```
cp SetupUtility.bin ifr/
cp ifrextractor ifr/
```
  Navigate into the new directory
```
cd ifr
```
  Run the full extraction
```
./ifrextractor SetupUtility.bin all
```
8. Identify the VT-d Offset:
  Run the global search from within the 'ifr' directory.
```
grep -iE 'VT-d' *.txt
```
  You should get a similar output.
```
setupUtility.bin.3.0.en-US.uefi.ifr.txt:                Text Prompt: "VT-d", Help: "VT-d capability", Text: "N/A"
setupUtility.bin.3.0.en-US.uefi.ifr.txt:                        OneOf Prompt: "VT-d", Help: "VT-d capability", QuestionFlags: 0x10, QuestionId: 0x19F, VarStoreId: 0x2, VarOffset: 0xE3, Flags: 0x10, Size: 8, Min: 0x0, Max: 0x1, Step: 0x0
```
  From this output, three critical pieces of information must be recorded:
  
  VarStoreId
  In this example, it is "0x2".
  
  Variable Offset
  This is the hex value listed after "VarOffset:". In this example, it is 0xE3. This is the most critical value.
  
  Enabled Value
  The hex value corresponding to the "Enabled" option. In this example, it is 0x1.
  
  Next, we need to determine the VarStore Name. The grep command listed the ID, we need to open the setupUtility.bin.3.0.en-US.uefi.ifr.txt in a text editor and locate the name.
  
  It should look like:
```
VarStore Guid: 72C5E28C-7783-43A1-8767-FAD73FCCAFA4, VarStoreId: 0x2, Size: 0x1D7, Name: "SaSetup"
```
  The VarStore Name we are looking for is SaSetup.
Constructing a Bootable UEFI Shell Environment
The next phase involves preparing the USB flash drive to boot into the UEFI shell.

Format the USB flash drive using the FAT32 file system. Ensure it is using a GUID Partition Table (GPT) partition scheme for maximum compatibility with UEFI systems.
- Open PowerShell as an Administrator: Win+x + a
- Start the DiskPart utility:
```
diskpart
```
  - List all disks to find your USB drive
    list disk
  - Select your USB drive (replace 'X' with the correct number)
    select disk X
  - Erase all data on the drive
    clean
  - Convert the disk to the GPT partition scheme
    convert gpt
  - Create a new primary partition
    create partition primary
  - Format the partition as FAT32
    format fs=fat32 quick
  - Assign a drive letter
    assign
  - Verify the file system
    detail disk
  - Verify the GUID Partition Table
    list disk
  - Exit diskpart
    exit
On the newly formatted USB drive, create a folder named "EFI\". Inside the new directory, create another direcory named "BOOT\".
```
New-Item -ItemType Directory -Path "__DRIVE_LETTER__:\EFI\BOOT\"
```
USB Drive:

The final path will be E:\EFI\BOOT\ (assuming E: is the USB drive letter).

Download the setup_var.efi utility into the root directory of the USB flash drive.
```
Invoke-WebRequest -Uri "__SETUPVARURL__" -OutFile "__DRIVE_LETTER__:\setup_var.efi"
```
setup_var URL:

Download a pre-compiled 64-bit UEFI Shell file (typically named Shell.efi or UefiShell.efi) into the E:\EFI\BOOT\ directory.

Rename the shell file to BOOTX64.EFI. This specific filename is part of the UEFI specification and designates the file as the default bootable application, ensuring the system will automatically load it.
```
Invoke-WebRequest -Uri "__UEFIURL__" -OutFile "__DRIVE_LETTER__:\EFI\BOOT\BOOTX64.efi"
```
UEFI Shell URL:
Execution of the setup_var.efi Command to Enable VT-d
This section details the direct modification of the UEFI NVRAM variable. The steps are mechanically simple but carry significant risk. Absolute precision is required.

Insert the prepared USB drive into the Yoga 710-15IKB. Power on the machine and enter the BIOS setup utility. Navigate to the "Boot" tab and change the boot order to place the USB drive as the first priority.

If the previous steps were performed correctly, the system will bypass the normal operating system bootloader and instead load the UEFI Shell, presenting a command prompt.

The UEFI shell will map your USB drive to a filesystem, typically fs0:. To confirm, type fs0: and press Enter.
```
Shell> fs0:
```
RET
```
fs0:\> ls
```
Then type ls to list the contents; you should see the setup_var.efi file.
```
Directory of: FS0:\
09/06/2025  20:33 <DIR>       16,384  EFI
09/06/2025  20:36            101,376  setup_var.efi
          1 File(s)    101,376 bytes
          1 Dir(s)
```
Now, carefully type the command using the precise offset and value identified in the firmware. The command syntax is
```
setup_var.efi <OFFSET> <VALUE>
```
Using the VarOffset and Value from earlier,
```
setup_var.efi SaSetup:0xE3=0x1
```
Press Enter to execute the command. There may be no output if the command is successful.

Perform a Hard Shutdown. Do not use a reboot command or press Ctrl+Alt+Del. Instead, press and hold the physical power button on the laptop until the machine shuts down completely. This forces a cold boot, which helps ensure the firmware correctly commits the NVRAM change on the next startup.
Final Operating System Configuration and Verification

Successfully modifying the UEFI variable to enable VT-d is only the first part of the process. The host operating system must also be configured to recognize and utilize this newly available hardware feature. This final section covers the necessary steps within Windows to enable supporting services and to perform a definitive verification of VT-d activation.
1. Mitigating Conflicts with Virtualization-Based Security (VBS) Features
  
  Modern versions of Windows 10 and 11 leverage hardware virtualization to enhance system security. Features such as Core Isolation and its sub-component Memory Integrity (also known as Hypervisor-Protected Code Integrity, or HVCI) use the hypervisor layer to protect critical system processes from malware.
  
  When these features are enabled, the Windows hypervisor takes exclusive control of the system's virtualization hardware (both VT-x and VT-d). This can create a conflict with third-party virtualization applications like VMware Workstation or Oracle VirtualBox, which also require access to this hardware. If such an application is launched while Memory Integrity is active, it will fail with an error message stating that VT-x is not available or disabled, even though it is enabled in the BIOS.
  
  Therefore, if the primary goal of enabling VT-d is to use it with a third-party hypervisor (for example, to perform GPU passthrough in a QEMU/KVM environment on a Linux host or within VMware), it may be necessary to disable these Windows security features. To do so, navigate to Windows Security > Device security > Core isolation details and turn the toggle for "Memory Integrity" to Off. A reboot will be required. This releases the hardware for use by other applications but comes at the cost of reduced system security against certain advanced threats.
2. System-Level Confirmation of VT-d (IOMMU) Activation
  After the firmware modification and OS configuration, a final check is required to confirm that the IOMMU is active and recognized by the system. The Windows Task Manager is insufficient for this, as its "Virtualization" status only reflects the state of VT-x. The most reliable method within Windows is to use the Device Manager.
  
  Open Device Manager, Win+x + m
  
  From the menu bar, click "View" and select "Devices by connection." Expand the device tree, starting from the ACPI PC entry. Look for the PCI Express Root Complex.
  
  If VT-d is successfully enabled and initialized by the system, an entry named Intel(R) Virtualization Technology for Directed I/O or a similar IOMMU device will be visible as a child of the root complex. Its presence is a definitive confirmation of success. In the device mangager, I have found:
  - PCI Express Root Complex
    - ELAN SMBus Driver
    - High Definition Audio Controller
    - Intel(R) 6th generation core processor family platform I/O SATA AHCI Controller
    - Intel(R) 7th Generation Processor Family Host Bridge/DRAM Registers - 5904
    - Intel(R) HD Graphics 620
    - Intel(R) Management Engine Interface
    - Intel(R) Serial IO GPIO Host Controller - INT344B
    - Intel(R) Serial IO I2C Host Controller - 9D60
    - Intel(R) Serial IO I2C Host Controller - 9D61
    - Intel(R) Serial IO UART Host Controller - 9D27
    - Intel(R) USB eXtensible Host Controller - 1.0 (Microsoft)
    - Mobile 6th/7th Generation Intel(R) Processor Family I/O Express Root Port #6 - 9D15
    - Mobile 6th/7th Generation Intel(R) Processor Family I/O PMC - 9D21
    - Mobile 6th/7th Generation Intel(R) Processor Family I/O Thermal subsystem - 9D31
    - Mobile 7th Generation Intel(R) Processor Family I/O LPC Controller (U Premium)- 9D58.
  Unfortunately, for me, this means it did not work. The "Intel(R) I/O Memory Management Unit" is not present, which is the key indicator that VT-d is inactive. We will boot back into the UEFI Shell to verify if the firmware has a security or integrity check that reverted the unauthorized change when the device was rebooted.
  
  Once back into the UEFI Shell, we will read the VarOffset;
```
fs0:\> setup_var.efi SaSetup:0xE3
```
  There are two possibilities:
  
  If the output is 0x0: The command worked temporarily, but the firmware detected the change upon reboot and reset it to the default "Disabled" value. This indicates a security feature that is very difficult to bypass.
  
  If the output is 0x1: It would mean the setting was successfully changed, but some other mechanism is preventing VT-d from being activated.
  
  My output was 0x01, this points to a much more thorough method of disabling the feature by the manufacturer. The most likely reason is that the setting is a "disconnected switch."
  
  The menu option to enable VT-d exists in the firmware code, and we successfully flipped it ON. However, Lenovo has likely removed the underlying code that connects that switch to the actual hardware function.
  
  The real control could be in a different VarStore or different offset, additionally, some BIOSes have “master enable” flags or prerequisite checks.
```
VT-x might only be enabled if “Security > TPM” or “Boot > UEFI Only” is also set.
```
  When doing additional digging in the IFR for "virtualization" I found this:
```
OneOf Prompt: "Intel (VMX) Virtualization Technology", Help: "When enabled, a VMM can utilize the additional hardware capabilities provided by Vanderpool Technology.", QuestionFlags: 0x10, QuestionId: 0x60, VarStoreId: 0x3, VarOffset: 0xCD, Flags: 0x10, Size: 8, Min: 0x0, Max: 0x1, Step: 0x0

OneOfOption Option: "Disabled" Value: 0, Default, MfgDefault

OneOfOption Option: "Enabled" Value: 1

End
```
  The VarOffset 0xCD (Intel VT-x) showing as 0x0 in setup_var.efi read, even though:
  - BIOS menu says ‘Intel Virtualization Technology’ is Enabled
  - Windows Task Manager shows ‘Virtualization: Enabled’
  The real VT-x enable bit is controlled by a CPU Model-Specific Register (MSR) — specifically IA32_FEATURE_CONTROL (MSR 0x3A) — and is typically set by the BIOS firmware during early boot, before the OS loads.
  
  What we’re seeing in setup_var.efi is a UEFI Setup Variable — which may or may not directly map to the actual hardware control. UEFI variables (like SaSetup) are configuration storage used by the BIOS setup UI. They are read by the BIOS firmware during boot, and then the firmware programs the actual CPU MSRs or chipset registers accordingly.
  
  The BIOS is likely “Faking” the Variable, where it exposes the settings in the UI but don’t actually use the associated UEFI variable — they hardcode behavior or use internal flags. This is why you found VT-d at 0xE3 but it doesn’t work — same principle.
  
  Unfortunately, this means that while our entire analysis and modification process was technically successful, the setting itself is a non-functional remnant. Lenovo's method of disabling VT-d on this machine is more complex than just hiding the option, making it impossible to enable with this technique.
  1. Manual Firmware Patching for SupressIf Neutralization
    The mechanism by which manufacturers like Lenovo hide specific settings within the InsydeH2O graphical interface is a standardized feature of the UEFI specification. The structure and content of the setup menus are defined by a data structure known as the Internal Forms Representation (IFR). Within the IFR, developers can use conditional opcodes to control the visibility of menus and individual options. The most common of these is the SuppressIf opcode. This instruction allows a developer to define a condition under which a specific UI element will be hidden from the user. For locked-down consumer devices, manufacturers often use a simple, unconditional suppression, such as SuppressIf: {0A 03 00}, which effectively translates to "Suppress if True". This allows them to use a single, comprehensive firmware codebase across multiple product lines, simply toggling the visibility of advanced features based on the target market. The VT-d option on the Yoga 710-15IKB is present within the firmware code but is hidden from the user by such a SuppressIf condition.
    
    While direct UEFI variable manipulation is the recommended approach, an alternative method exists that aims to make the VT-d option permanently visible within the BIOS setup menu. This technique involves directly patching the firmware image file itself to remove the SuppressIf condition that hides the setting.
    
    This can be accomplished in a couple ways:
    - Using a hex editor, one can locate the byte sequence corresponding to the SuppressIf instruction and alter its condition. For example, a condition that always evaluates to true (SuppressIf True) could be changed to a condition that always evaluates to false (e.g., "suppress if 1 equals 0"), thereby forcing the UI element to always be displayed.
    - A more direct approach is to overwrite the entire SuppressIf instruction with NOP (No Operation) opcodes. These are null instructions that tell the processor to do nothing and simply move to the next instruction, effectively deleting the suppression logic from the code flow.
    Since I lack the SOP8 clip or CH341A programmer needed to explore this further, I will return to enabling VT-d if I run into significant performance issues down the road.

A Guide to UEFI Firmware Analysis and Modification

Table of Contents

1. Introduction

1.0.1. Entering the Yoga 710-15IKB BIOS

1.0.2. Virtualization (VT-x) Activation and disabling Secure Boot

1.0.3. VT-d Activation