UEFI相关笔记整理

# UEFI基础知识

UEFI分析

参考Blackhat的Analyzing UEFI BIOS from Attacker & Defender Viewpoints 不想看一大堆代码，可以从下面两个部分入手：

Beyond BIOS: Developing with the Unified Extensible Firmware Interface 2nd Edition一书
https://uefi.org/specifications

UEFI固件

常用的专业术语：

FD，Firmware Device，固件设备，比如SPI flash芯片之类的。
FD，Flash Descriptor
固件卷（FVs，Firmware Volumes）
固件文件系统（FFS，Firmware File System）

UEFI存储在SPI Flash芯片中，SPI Flash芯片当前分为5个区域，详情如下图所示： FD（Flash Descriptor）为Region 0，每个分区间的用途和访问控制权限不同。在研究UEFI固件时，需要重点关注UEFI/BIOS区域。Firmware Device是一个物理组件，比如Flash芯片就是一个物理组件。但是我们重点关注的部分是逻辑区块，也就是固件卷（FVs，Firmware Volumes）。 FVs实际上是逻辑固件设备，包含了多个固件分区，通常可在PEI或DXE代码中提取出固件卷(volumns)。固件卷通常由一个或多个固件文件系统（FFS, Firmware File System）封装而成，FFS的基础单元是一个文件。FV实际的偏移量不会与FD(Firmware Descriptor)中的BIOS分区的起始位置对齐。固件卷的结构构成如下：上图中很好地展现了FV-FFS-Section之间的关系，文件数据存放于Section的数据区中，下图右侧的部分就是Section数据区中的文件，右侧绿色的部分是固件文件首部的结构，白色则是文件数据。固件文件的文件格式是PE（Portable Executable）文件，或者可以说是一个TE（Terse Executable）文件，TE文件可以看作一个极简的PE文件，其首部的数据结构如下：

固件文件系统(FFS)分析工具

UEFITool，利用UEFIExtract命令行版本能够快速地提取出所有的文件，有图形化界面。
UEFI Firmware Parser，当所有的文件可解析时，提取文件的速度非常快，安装python模块即可使用。

UEFI启动流程

UEFI启动流程图 UEFI系统从加电到关机的7个阶段：

SEC：安全验证
PEI：EFI前期初始化
DXE：驱动执行环境
BDS：启动设备选择
TSL：操作系统加载前期
RT：Run Time
AL：系统灾难恢复期在SEC、PEI、DXE这三个阶段中，UEFI会进行初始化。DXE阶段结束后UEFI环境已经准备完毕。BDS和TDL是操作系统加载器作为UEFI应用程序运行的阶段，接下来会对上述过程进行详细的分析。

Security（SEC）阶段

SEC阶段是平台初始化（PI，Platform Initialization）的第一阶段
存储了CPU首先执行的代码
运行环境基于以下条件：
- Small/minimal code typically hand-coded assembly so architecturally dependent and not portable ——小/极小代码通常需要手动编译，因此依赖PI架构而且非可执行文件，能够单独运行的可以看作为一个绿色软件，双击.exe文件就可以直接运行了。
- 直接从flash中运行
- 代码未经过压缩
在平台初始化的过程中，该阶段应该执行核心安全检测代码，但实际上并没有，攻击者往往会在这个阶段之前破坏系统。
SEC阶段的任务
- SEC阶段会处理所有的系统重置事件（power on, wakeup from sleep等等）
  - 系统会基于电源的起始状态选择引导（Boot）时代码执行路径
    - ACPI知识点补充：睡眠模式（Sleep Mode）
      - ACPI(Advanced Configuration and Power Interface, 高级配置与电源接口)
      - 由睡眠模式决定的备用引导（Boot）路径可能会使 BIOS 产生漏洞
      - 从睡眠模式唤醒的系统的引导（Boot）代码执行路径不同，这种不同的代码执行路径，会使系统不能与断电状态下系统引导路径一样可以锁定系统。
      - 比如：当您从关机打开电源时，BIOS可能会锁定，但在从睡眠中醒来时不会锁定。
- 初始化临时存储区域
  - 临时存储区域——使用了CAR技术（Cache as RAM），将CPU缓存作为RAM使用
  - SEC阶段仅CPU和CPU内部资源被初始化，内存还未进行分配，所有的读写操作都必须在CPU缓存（Cache）上操作。
  - 利用CAR技术初始化栈，为C代码执行准备环境
    - CAR: Cache as RAM，当Cache被配置为no-eviction模式时，可以作为内存使用，读命中时返回Cache中的数据，读缺失时不会向贮存发出缺失事件；写命中时将数据写入Cache，写缺失时不会向主存发出缺失事件。
  - 引导启动进程（Boot Strap Processor）的缓存在SEC阶段被使用，该进程于启动时激活。
SEC阶段的进程在实模式下运行，实模式是指程序地址为真是的物理地址，可以访问任意地址空间，这样不同进程可能访问到其他进程程序，造成严重错误。
SEC阶段的段寄存器是相同的
- CS:IP = F000:FFF0
- CS.BASE = FFFF_0000h
SEC阶段的入口vector为JMP指令
- SEC执行分为两大部分：临时RAM生效之前成为Reset Vector阶段，临时RAM生效后调用SEC入口函数从而进入SEC功能区。
- 在Reset Vector部分，系统还没有RAM，因此不能使用基于栈的程序设计，所有的函数调用都使用JMP指令模拟。
微指令（microcode）是在SEC阶段进行更新的，通过给microcode打补丁可以减少或降低microcode中的错误带来的影响。如果此时刚好microcode打补丁的过程中出现了问题，并且攻击者获取了最新的BIOS/UEFI，且可在最新的microcode进行写操作，那就有可能实现攻击。
SEC阶段传递给PEI阶段（PeiCore）的参数说明：
- SEC Core Data
  - SecCoreData指向含有操作系统环境信息的数据结构，数据结构中包含信息如下：
    - 临时RAM的位置及其大小
    - 临时RAM中栈所在的位置
    - Boot固件卷（BFV, Boot Firmware）的位置
      - 根据GUID定位Flash文件系统（Flash File System）位置
      - GUID： 8C8CE578-8A3D-4F1C-3599-35896185C32DD3
      - 如果未能定位BFV的位置，系统运行中止
- PPI（PEIM-to-PEIM Interface） List
  - PEI Core最初安装时所需的PPI描述符列表
- 指向vendor-specific data的空指针
- PeiMain执行之后不会返回到SEC阶段，直至下一次系统重置

PEI(Pre-EFI)阶段

PEI阶段的任务
- 初始化内存（可长期使用，非临时存储区域）
- 在HOB（Hand-off-Blocks）列表中向DXE阶段描述内存信息，HOB列表是PEI要传递到DXE的信息
- 在HOB中描述固件卷（Firmware Volume）的位置信息
- 将控制权转交到DXE手中
- 判断Boot模式，若适用，从睡眠状态恢复
  - Boot代码执行路径会基于电源状态（Power State）进行选择
PEI的组成
- Pre-EFI初始化模块（PEIMs，Pre-EFI Initialization Modules）
  - 存储在FFS文件中的模块化单元，包含了代码和（或）单元
  - 作用：获取内存、FV（Firmware Volume）的信息，创建HOB列表等等
  - 可基于已安装的PPIs（PEIM-to-PEIM Interfaces）运行
    - 相关依赖项由PEI Dispatcher检查
- PEIM-to-PEIM接口（PPI, PEIM-to-PEIM Interface）
  - 允许PEIMs间通信
    - PEIM可与其他PEIM间协作完成任务并实现代码复用
  - PEIM中包含了数据结构EFI_PEI_PPI_DESCRIPTOR，该数据结构中带有一个GUID和指针
  - PPI分为两类：Architectural PPI和Additional PPI
    - Architectural PPI：依赖PEI内核（PEI Foundation）的PPIs，比如给ReportStatusCode()这个PEI服务提供通信接口的PPI就是这种类型的。
    - Additional PPI：不依赖PEI内核（PEI Foundation）的PPIs
- PEIM调度器（PEIM Dispatcher）：找出系统中所有所需的PEIM,并根据PEIM之间的依赖关系按顺序安装、执行PEIM。
- Dependency表达式（DEPEX，Dependency Expression）
  - PPI的GUID必须在PEIM加载或执行之前分配好。
- 固件卷（Firmware Volumes）：用户存储PEIM，在该阶段（PEI阶段）不会被解压，但是在DXE阶段会解压。
- PEI Services
  - 允许所有的PEIM、PPI使用，PEI内核也能使用
  - 提供各种服务，比如InstallPpi()、LocateFv()等。
- PEI执行流程
  - 上图为PEI内核在PEI阶段的执行流程图
  - PEI内核负责PEI服务表的创建
  - PEI内核的核心围绕着PEIM调度器，PEIM调度器负责PEIM的定位和执行
  - 最后一个调度的PEIM为DXE IPL(Initial Program Load) PEIM，该PEIM负责过渡到DXE阶段。
- PEIM调度器
  - PEIM调度器本质是上一个有限状态机（State machine）和PEI阶段的核心
    - 状态机（State machine）的意思是其输出取决于输入时的状态及输入值。
  - 遍历每一个已遍历过的PEIMs的PPI例表上的Dependency表达式
  - 如果DEPEX检测某个PEIM的返回值为True，就会调用该PEIM，否则就会检测下一个PEIM
    - UEFI会避免PEIM A和PEIM B处于死循环的状态中。（X和Y是PPI）
  - 一个PPI是EFI_FIND_FV_PPI可以调用每一个固件卷上的任意一个PEIM
  - 一旦所有的PEIM都已经执行过了，最后一个执行的PEIM是DXE IPL PEIM，该PEIM会传递DXE阶段所需的信息给DXE
- DXE所需的Handoff退出的条件
  - HOB例表必须包含下述的HOB（Handoff Block）：

DXE(Driver Execution Environment)阶段

DXE阶段在足够高的层级上执行代码，该层级不依赖任何架构
与PEI有许多相似之处，比如DXE阶段创建的服务只能用于该阶段，DXE阶段有DXE调度器，调度器负责查找和加载DXE驱动等。
- PEI与DXE相似之处比较
  - PEIMs相当于DXE驱动
  - PEI调度器相当于DXE调度器
    - DXE使用一个识别系统（identical system）
    - PEI加载和调用独立的功能单元需要DEPEXs
  - PPI相当于Protocol
    - DXE驱动寄存器会搜索Protocols
  - Sec Core Data相当于HOBs
    - PEI从SEC阶段获取Sec Core Data
    - DXE从PEI阶段获取HOBs
系统管理模式设置（System Management Mode）、Secure Boot强制和BIOS更新签名检查通常都在此阶段实现。因此该阶段是UEFI启动流程中的安全检查核心步骤。
DXE服务表
Boot服务表
Runtime服务表
DXE和SMM（System Management Mode）的关系
- DXE加载SMM IPL（Initial Program Loader）
- SMM IPL加载SMM Core
- SMM Core加载SMM驱动

BDS(Boot Device Selection)阶段

BDS通常会封装到单个文件中，该问文件会由DXE阶段加载
BDS会获取配置信息，这个配置信息决定是引导（Boot）一个操作系统还是进行其他内容
BDS阶段有权限访问DXE阶段设置的整个UEFI Boot服务表
- 攻击者能够在DXE阶段获取UEFI Boot服务表的访问权限
与SEC->PEI、PEI->DXE的过渡不同，在进入BDS阶段之前不用收集信息并传递
DXE阶段会给BDS及其下一个阶段提供一个指向系统表的指针，该系统表会指向boot服务和DXE服务表。

TSL（Transient System Load）阶段

该阶段会获取固件派生（firmware-derived）代码产生的数据，通常会将这部分数据传递给HD存储（HD-stored）代码
若系统在Secure Boot开启状态下运行，BDS会将这个阶段加载的所有代码在加载之前进行签名校验，未经过签名校验的代码不允许加载
未经签名校验（未开启Secure Boot）的攻击路径
经过签名校验（开启Secure Boot）攻击失败的路径
- 考虑一下，若强制引导（Boot）一个随机操作系统上不存在的安全应用会发生什么问题？前提：在理想情况下，使用TPM/TXT(Trusted Boot)保证该应用的可信度。

RT（Runtime）阶段

进入RT阶段后，系统的控制权从UEFI内核转交到OS Loader手中。
通常OS boot loader（操作系统引导加载器）加载完成之后，它会调用UEFI Boot服务表中的ExitBootSevices()该服务会回收UEFI大部分内存，以便OS能够使用这些内存。
UEFI还会保留部分内存，这部分内存由运行时服务（Runtime Services）使用。
随着OS Loader的执行，OS最终取得系统的控制权

AL（After Life）阶段

这个阶段一般不会作为实施攻击的阶段
该阶段可以在选择正常关闭时做某些操作，比如清除机密。
一般情况下，在RT阶段，如果系统（硬件或软件）遇到灾难性错误，系统固件需要提供错误处理和灾难恢复机制。

Secure Boot

判定一个可执行文件是否被允许在UEFI/BIOS引导（boot）过程中加载/执行
当发现一个可执行文件比如Boot加载器或Option ROM，UEFI会进行如下检查：
- 可执行文件是否已经过认证密钥签名
- 可执行文件的密钥、签名或哈希值是否已存储在已经过认证的签名数据库中
UEFI flash上的模块（SEC,PEI,DXECore）没有签名校验
- BIOS的flash镜像在更新过程中会有签名校验（固件签名，Fireware Signing）
  - 当可以直接对flash芯片直接操作的时候，BIOS不会在每次运行的时候进行签名校验。（可作为一个绕过BIOS签名校验的方法）
UEFI Secure Boot：阻止底层的攻击，比如bootkit之类的
- DXE会对非嵌入式XROM、DXE驱动程序、UEFI应用程序和引导加载程序进行签名认证。
- 下图为UEFI Secure Boot进程
Windows 8 Secure Boot
- 微软Windows 8在Secure Boot的基础上增加了Secure Boot的检测机制。建立了一条认证链：
  - UEFI Boot Loader-> OS Loader -> OS Kernel -> OS Drivers
- Windows 8 Secure Boot的绕过姿势

UEFI非易失变量（Non-Volatile Variables）

UEFI使用CMOS/NVRAM代替BIOS配置机制，使用CMOS/NVRAM具有可延展性且更安全
- NVRAM——non-volatile RAM，是EFI用于存储Boot期间需要长期保存的变量，其中大部分的非易失变量（Non-Volatile Variables）是由架构定义的。若给NVRAM设置了无效选项，将使机器无法正常进入Boot流程。
会使用SPI flash芯片存储部分BIOS代码
至少有两个系统的非易失变量处理过程存在漏洞，一旦变量空间被填满，系统就会崩溃。当一个操作系统的Logging机制发生问题的时候就会造成变量空间被填满。
非易失变量（Non-Volatile Variables）会在PEI阶段访问，CapsuleUpdate变量中的VU#552286项就是在这个阶段被访问的。但大部分变量更有可能在DXE阶段或者后面的阶段被访问，访问变量最靠后能到RT阶段。
EFI变量属性：每一个UEFI变量都会通过属性告知固件如何存储和维护该变量对应的数据
- 单个属性介绍
  - NON_VOLATILE属性：存储在flash中的变量
  - BOOTSERVICE_ACCESS属性：可在Boot期间被访问或修改，需要按照Runtime_Access设置的访问顺序给该属性的变量赋值。
  - Runtime_Access：变量可以被操作系统或应用修改
  - Hardware_Error_Record：存储在NVRAM（flash）的一部分，用于存储报错记录
  - Authenticated_Write_Access：变量只能被已经认证私钥签名的应用或当前用户修改
    - KEK和DB就是经认证（Authorized）变量
  - Time_Based_Authenticated_Write_Access：变量需要有时间戳（time-stamp）作为认证凭证
  - Append_Write：变量可添加数据
- 多个属性组合介绍
  - 如果一个变量同时拥有Runtime和Authenticated的属性，那么该变量只能已经过认证的密钥签名的应用修改
  - 如果一个变量具有Runtime属性但是没有Authenticated属性，那么这个变量可以被任何应用修改
    - VU#758382项的Setup变量就是这样的一个变量
认证方式——Key和Key Stores
- UEFI通过四个变量实现认证机制，这四个变量负责存储密钥、签名或hash值
  - PK(Plateform Key)
    - PK建立起平台所有者和平台固件间的信任关系
    - PK控制访问其自身和KEK变量
    - 仅有物理意义上的当前用户或者经PK签名的应用才有权限修改PK的值
    - 需要开启Secure Boot，否则系统在设置模式下密钥可以被任意应用修改
  - KEK(Key Exchange Key)
    - KEK建立起操作系统和平台固件间的信任关系
    - KEK用于更新签名数据库
    - 后缀名的.efi文件经KEK签名后才能正常执行
  - DB（Signature Database）
    - 二进制的密钥、签名或哈希值的白名单
  - DBX（Forbidden Database）
    - 二进制的密钥、签名或哈希值的黑名单
- UEFI变量（Key和Key Store）
  - Key和Key Store这部分变量存储于flash的文件系统中
    - SPI flash一旦未被正确锁定，这些密钥或哈希值可被攻击者重写
    - UEFI变量的安全必须且只能依赖SMM，第二道防线的范围保护寄存器不能正常使用
    - UEFI变量必须保持可写状态，因为有些时候系统需要写入变量
    - 有两个关于阻止SMI(System Management Interrupt)实现将Charizard PoC的bootkit添加到DB白名单的例子
      - ALL YOUR BOOT ARE BELONG TO US
      - Extreme Privilege Escalation on Windows 8/UEFI Systems

UEFI攻击面

下面的图只呈现了UEFI固件的威胁攻击模型，如果有时间也可以了解一下Intel ME和AMT，它们最近也是安全问题频发。而过去，出现漏洞最多的是BMC。 UEFI攻击面攻击面分类如下：

Post-Exploitation（加电自检漏洞利用）
- Secure Boot Bypass：绕过Secure Boot机制
- SMM Privilege Escalation：SMM(System Management Mode)提权，
- UEFI Firmware Implant：UEFI固件后门植入
- Persistent Implant：持久后门植入
- Non-Persistent Implant：非持久后门植入
Compromised Supply Chain(供应链攻击)
- Misconfigured Protections(防护配置错误)
- Non-Secure Root of Trust(不安全的安全信任根)
- Malicious Peripheral Devices
- Implanted BIOS Updates
- Unauthenticated BIOS Update Process
- Outdated BIOS with known security issues

UEFI攻击流程概述

这部分内容是参考文章What makes OS drivers dangerous for BIOS?的，发现其中有一个图讲得非常详细，描述了UEFI攻击过程： UEFI攻击流程图

按照上图可以攻击可分为以下四个阶段：

用户模式：该阶段实际上是一个利用客户端的漏洞提权的过程，举一个例子，web浏览器远程代码执行(RCE，remote code execution)，在系统上下一个恶意的installer，这个installer再利用其他的漏洞提权，提升到LOCALSYSTEM的权限之后，使用该权限继续执行代码。
内核模式：installer需要先绕过代码签名机制，在内核模式下执行代码。内核模式下运行payload（driver）然后获取SMM的权限
系统管理模式（SMM, System Management Mode）：SMM的Shellcode成功执行之后，实现提权，并且能够关闭SPI flash内存的修改防护机制（一种阻止SPI flash内存被修改的机制）。
SPI Flash：所有的SPI flash的防护机制都被关闭之后，可以实现在flash中任意写入的效果。任意写入之后能够实现rootkit/implant(固件层的后门)安装到SPI flash芯片上的固件中。到此，实现了系统中最高级别的持续化后门植入。

加电自检漏洞利用(Post-Exploitation)

常用的专业术语：

加电自检(POST, Power-On Self-Test)：
Rootkit：大多指被作为驱动程序，加载到操作系统内核中的恶意软件。
SMM: 系统管理模式，一共有用户模式、内核模式、系统管理模式、SPI Flash（存放BIOS/UEFL的内存芯片）
PI：平台初始化（Platform Initialization，简称PI）
UEFI = Unified Extensible Firmware Interface（通用扩展固件接口）

这部分内容参考文章UEFI vulnerabilities classification focused on BIOS implant delivery

Secure Boot绕过(Secure Boot Bypass)

绕过Secure Boot，其关注的重点是如何破坏安全引导过程（Secure boot process），实现攻击的前提是通过了Root认证（Root of Trust，full compromise）或在OS加载之前的引导过程中选择任意一个阶段实施攻击。Secure boot绕过可发生在引导过程的任一阶段，并且会影响其之后的执行流程，破坏后续流程的认证机制（Trust mechanisms）。

SMM权限提升(SMM Privilege Escalation)

在使用x86架构硬件上，SMM（System Management Mode, 系统管理模式）具有强大的威力，因为大部分SMM提权最终都能够实现代码执行。SMM提权通常是BIOS植入后门的最后一个步骤之一。

UEFI固件后门植入(UEFI Firmware Implant)

UEFI固件后门植入——植入长期存在于BIOS中的后门（持久化后门）的最后一个步骤，该后门可在UEFI固件启动的不同阶段（DXE, PEI）中作为一个已修改过的合法模块或独立驱动被植入。

持久化后门(Persistent Implant)

持久化BIOS后门能在完整的重启和关机周期中运行，并且，在某些情况下能在加电自检更新过程安装BIOS镜像前对BIOS更新镜像进行修改。

非持久化后门(Non-Persistent Implant)

非持久化BIOS后门不能在完整的重启和关机周期中运行，在某些情况下可以在睡眠或休眠状态下运行。该后门重点关注提权、有硬件虚拟化保护(比如Intel VT-x)的OS中的代码执行和可信执行(Trust Execution)比如使用MS VBScript。此外，该后门可将恶意代码传到内核模式下或破坏TEE(Trusted execution environment,可信执行环境)内存的隔离性。

供应链攻击(Compromised Supply Chain)

加电自检漏洞利用，需要成功完成其之前的阶段的漏洞利用过程，才能最终将持续化后门或非持续化后门植入BIOS中。供应链攻击会在未来造成严重威胁，该漏洞由BIOS开发团队或OEM硬件产商导致的未知错误引发，或由攻击者特意造成目标软件配置错误引发，该错误配置可让攻击者绕过平台的安全功能。

防护配置错误(Misconfigured Protections)

在硬件拥有者无法防止硬件被物理接触时（交给海关检查之类的），硬件和固件的错误配置会变成一个重要的攻击向量。可物理接触硬件时，可在这个时候实现BIOS后门植入，配置错误攻击向量有时候被称为“Evil Maid attack”，这个术语可用于任何可以轻易获取的攻击向量上。

不安全的安全信任根(Non-Secure Root of Trust)

硬件安全信任根介绍

恶意外部设备(Malicious Peripheral Devices)

BIOS更新后门(Implanted BIOS Updates)

未经认证的BIOS更新进程(Unauthenticated BIOS Update Process)

有已知安全问题的旧版BIOS(Outdated BIOS with known security issues)

资料收集——供应链破坏

HARDWARE SUPPLY CHAIN THREATS VULNERABLE FIRMWARE IN THE SUPPLY CHAIN OF ENTERPRISE SERVERS——服务器的固件供应链破坏

实战

UEFI固件下载及FFS文件获取过程

从IBM UEFI固件下载上下载System x3200 M3的UEFI文件

下载镜像文件H45078702.iso
解压该镜像文件，会获得四个文件，分别是ibm_fw_uefi_gye165a-1.30_anyos_i386.chg、ibm_fw_uefi_gye165a-1.30_windows_32-64.exe、ibm_fw_uefi_gye165a-1.30_windows_32-64.txt和ibm_fw_uefi_gye165a-1.30_windows_32-64.xml。
提取UEFI文件，双击.exe文件，会出现一个图形化的界面，在Action框中选中Extract to Hard Dr将文件解压到你想存放的文件夹下。
在选中的文件夹下找到后缀名为.upd的文件，将其后缀名改为.zip并解压，获得文件gye165a.tar.gz。
解压文件gye165a.tar.gz，获得FFS的文件。

心路历程，实际上在获得.upd文件之后我不知道应该怎么处理，用010 Editor查看了文件内容之后，发现这里面包含了许多文件，详情如下：就想起可以重命名该文件，说不定能直接获取fv文件之类的，就把这个文件的后缀名重命名为.zip并解压，解压之后获取了文件gye165a.tar.gz，然后再解压一次就获得我想要的FFS文件了。

DXE main获取过程

在上面的第五步之后，可以在gye165a文件夹下找到一个FvDxe.fv的文件，用UEFITool打开可以找到TEXT为DxeMain的file： DxeMain图

展开该file，然后选中PE32 image section，右键将这部分section提取出来，并将这部分重命名为DxeMain.bin。提取DxeMain图

用010 Editor查看DxeMain.bin，会发现其中的PE文件头，我们现在需要做的就是把它转化为EFI文件，然后用IDA进行分析。（改后缀名失败了…..）

发给我的Section_PE32_image_DxeMainDxe_DxeMain_body.efi和我之前提取出来的DxeMain.bin文件进行对比，发现bin文件头中比efi文件头中多了四个字节0xA4E90010。 bin和efi文件对比图

我把0xA4E90010删除之后，再把原来的DxeMain.bin改为DexMain.efi，然后再用64位的IDA打开，发现能够正常打开了。接下来，只需要对DXE main进行分析就行了。

DXE main分析过程

UEFI固件修改过程

UEFItool教程

UEFI固件刷写过程

刷固件教程

找到motherboard model和bios版本，使用命令wmic baseboard get product,Manufacturer，在google上搜索motherboard model对应的名称根据BIOS固件版本就可以下载对应的BIOS文件了。
下载华硕（ASUS）的固件，它后缀名为.cap，把这个文件放到USB中，然后主板关机。
重启电脑，然后不断地按Del键，就能进入BIOS设置的页面，然后按下F7，进入工具中找到我们之前下载的.cap文件，然后选择刷入即可。

ASUS固件（后缀名为.cap）直接拉到UEFITool就能够直接解析了，找到DxeCore部分，直接把这个提取出来就好了。

刷ASUS固件比较好用的工具有AFUWINx64_v3.05.04，输入的命令如下所示$ afuwinx64 raw_rom_name.CAP /P
$ afuwinx64 want_to_flash_name.bin /GAN

重启之后需要将安全启动中的密钥全部删除，这样就完成了刷写的全部操作。

遇到的问题及解决方法

用其他工具写的时候，遇到了Failed to disable write protection for the BIOS space的报错，可以用AFUWINx64上面的方法刷，最好是有GAN命令的。
电脑一直在EFI Shell的页面，关闭电源之后把USB拔出来，然后重启
刷完带有Shell的固件之后，重启出现The system found unauthorized change on the firmware, operating system or UEFI drivers.，这时候打开BIOS设置界面，进入安全启动项，清除安全密钥就能重启了。

资料收集

UEFI bootkit

umap

UEFI分析工具

UEFI DXE阶段的模拟器
bios_diff.py：用于对比BIOS固件间不同，看是否有修改。
ida-efiutils：有IDA分析EFI的脚本 + EFI的库文件behemoth.h。IDA在加载behemoth.h文件之前，需要在文件中添加typedef unsigned char FILLER;和typedef void VOID;，否则会出现如下6个报错：

Error …\UEFI_Ananlysis_Tool\ida-efiutils-master\behemoth.h,65: Syntax error near: @type VA_LIST
Error …\UEFI_Ananlysis_Tool\ida-efiutils-master\behemoth.h,21766: Undefined type name ‘VOID’
Error …\UEFI_Ananlysis_Tool\ida-efiutils-master\behemoth.h,21890: Syntax error near: FILLER
Error …\UEFI_Ananlysis_Tool\ida-efiutils-master\behemoth.h,21891: Syntax error near: }
Error …\UEFI_Ananlysis_Tool\ida-efiutils-master\behemoth.h,21922: Syntax error near: PEI_CORE_FV_HANDLE
Error …\UEFI_Ananlysis_Tool\ida-efiutils-master\behemoth.h,21958: Syntax error near: }
Total 6 errors

IDA导入头文件的方法：File->Load file-> Parse C header file…->选中behemoth.h文件即可。 EFI Swiss Knife

FTK工具：刷BIOS的工具
- 更新:下载适合你主板的Intel ME System Tools，点击查看链接有最新的，把其中的MEInfo、Flash Programming Tool和FWUpdLcl64.exe复制到FTK10的目录下，这样FTK10就能正常使用了。

BIOS LOCK修改——UEFI层面

BIOS LOCK的修改，现在有下面3种思路：
1. 修改PchInitDxe，通过“+50h]”定位固件中的寄存器，并将其中的je改成jmp即可，但是现在缺少源码的比较，所以比较难定位具体修改的位置。详细的修改情况可以参照下一段——实际修改过程。
2. 使用RWEverything修改BIOS_CNTL.BIOSWE和BIOS_CNTL.BLE，这部分需要利用14年一个条件竞争的CVE，最终实现修改
  - RWEverything，Access-> SMBIOS Structures，修改BIOS_CNTL的BIOSWE（ BIOS Write Enable）位，改为1，能够获取BIOS区域写入的权限，BIOS Lock Enable (BLE)位设置为0，有可能SMI（ System Management Interrupt）会把BIOSWE位设置为0。
  - 可以参考这篇文章，里面有相关的POC的介绍，说不定我也能自己根据POC写一个dll文件，最终实现自动化处理这个呢，不过较新的bios可能就不能实现写入了……
3. 修改ME区域（这个暂时还没有找到具体的方案），参考依据
实际修改过程，直接用IDA打开PchInitDxe查看
1. 用ALT+T搜索+50]，勾选Find all occurrences，找到后面跟着test指令的部分，示例如下：但实际上我们不会对这个进行修改，只是一个示例而已，对照着PCH_LOCKDOWN_CONFIG数据结构查看，我们实际上要修改的是BiosLock的部分，也就是找到同时有test指令和0x10的语句，将其后面的jz或je语句直接改成jmp即可。typedef struct {
  UINT8 GlobalSmi : 1; //test with 0x01
  UINT8 BiosInterface : 1; //test with 0x02
  UINT8 GpioLockDown : 1; //test with 0x04
  UINT8 RtcLock : 1; //test with 0x08
  UINT8 BiosLock : 1; //test with 0x10
  UINT8 Reserved : 3;
  UINT8 PchBiosLockSwSmiNumber;
  } PCH_LOCKDOWN_CONFIG;
2. 将上面搜索到的语句一个个进行查看，定位同时有`test`指令和`0x10`的语句。
![PchInitDxe修改图](https://res.cloudinary.com/dq4c0zqqy/image/upload/v1588727942/UEFI%20Basic/W_SLZ_161_QK0PISZE_M7NW.png)
3. 将`jz`修改为`jmp`，在IDA页面`Edit->Assemble`，第一个弹窗将jz修改为jmp，第二个弹窗按下`Cancel`。

UEFI研究人员分类

UEFItool的开发者

文章收集

Low level PC/server attack papers collection” timeline

Get-off-the-kernel-if-you-cant-drive：通过驱动修改MSR的寄存器，最终破坏读写保护机制。

ASSESSING ENTERPRISE FIRMWARE SECURITY RISK IN 2020：2020年企业固件安全风险分析

Bypassing Firmware Security Boundaries from Embedded Controller:介绍绕过EC的，大致上介绍了UEFI几个修改的关键点

Attacking the Golden Ring on AMD Mini-PC:绕过Windows strongest security boundary

参考文章

UEFI vulnerabilities classification focused on BIOS implant delivery What makes OS drivers dangerous for BIOS? UEFI EKD2手册

UEFI原理 · 2019年4月1日 0