此帖是记录笔者研究Intel Management Engine 以及 Intel-SA-00086 安全漏洞的记录。笔者也不知道能研究多深入，所以研究一点是一点，顺便发出来也给各位大佬参考以及讨论。说结论：当前只能说解锁了一半，暂时还没有找到一个能完全解锁ME的路径。我会把我研究的所有过程和思路都展示出来，各位师傅如有兴趣，可以一起来研究。（零AI注水放心阅读）

平台选择我更换了成了Z270但是实际上Z370也是一样得没区别，所以没必要去追低版本。之前Z370平台被我弄坏了也可能是二手质量太差。
主板：华硕 Z270 - A
CPU: I5 7400
展示一下新的平台：

上一章主要讲解了ME解包以及Bios固件得DCI解锁手法但是由于没有展示完全得实战过程，有些师傅对我得手法和思路有些质疑，所以我重点讲解一下我是如何链接DCI。

我们要调试CPU需要安装Intel System Studio 2019，这个版本在看雪有人发过。（如有需要可以私信我我发你网盘）。
第一个坑：这个软件实际上是基于win7开发的，最好是在win7环境下运行。如果在win10上需要打开安装软件请设置兼容模式。

软件只需要安装这个即可：

需要注意安装Intel System Debugger 2019 需要安装Net3.5可以去微软官网下载这里就不介绍了。
在win11环境下安装会提示没有安装win7的安全补丁导致无法进行，我通过逆向分析发现有一个参数可以关闭这个检查。

如图会弹出这个提示，在运行的时候加 --noprereq 不会有问题了。
过掉环境检测后他会有一个License的校验

虽然公开资料里面附带一个License文件但是window版本是没法用的失效状态，这里我逆向了一下他的校验机制。核心的校验代码在issa.dll 中，

如图我拿其中一个展示一下，主要就是这三个函数用来校验，都是导出函数没什么好介绍的直接patch后，替换进去校验就行了。
安装完我们的调试软件后还需要安装我们的驱动组件，我这里直接从iso里面提取出来，我会发到附件里面去。

安装完会生成如下两个目录：

首先需要打开 ConfigConsole 软件用来配置DCI链接：

首先根据你的平台和版本的不同进行配置：

根据配置名分析：
KBL是Kaby Lake CPU
OpenDCI也就是DCI线缆链接
SPT 指的是200系主板
DBC 指的就是 Debug Class 也就是我们这种线缆链接。
选择完后就可以直接点右上角链接即可。

在DAL_1.1839.428.110目录下找到：
PythonConsole.cmd，运行就可以打开我们的DCI调试的界面了。这个主要是Python2.7作为CLI的基础。

通过help()函数和dir的帮助。以及AI辅助后大概了解了一些基础命令：

itp.halt() 在当前状态下，直接调用这个函数会直接超时，cpu会拒绝。

这个发现是我之前逆向ME固件的时候的一个意外发现。

这里我整理了一个图展示一下

在这个里面我发现了UTOK模块，根据AI查询后的解释是：
UTOK = Unlock Token ← Intel 为 OEM 留的"后门"解锁机制，作用：无需硬件熔丝，通过 SPI Flash 写入数据 → 解锁 DFX 调试接口
，位置：SPI Flash 的 FPT 分区表中一个独立分区。这方面我确实不是很了解暂时先信任一下。
根据分析来看：
我整理一下UTOK的整个流程

我拿出最核心的检测调试区判断作为例子如下图：

通过逆向分析，rbe_utok_check一开始是会拿到fpt区域

me的运行base是0x4000所以说字符串是2ad4如下图，UTKO首先会定位fpt区域


函数内部是一个链表，链表结构如下：

上面是运行时的结构

先介绍一下 FPT（Flash Partition Table） 表：Flash 上的物理分区目录，主要是启动时候需要加载的一张路由表，所以这个里面存储了我们刚刚上面介绍的信息。
它位于 ME 区域的固定偏移处，记录了 ME 内每个分区的位置、大小和类型。这张表的作用很简单：ROM 和 RBE 启动时没有文件系统，不知道 UTOK 在哪、FTPR 在哪、kernel 在哪——全靠查 FPT 来找到对应分区的物理位置。
FPT 头部结构：

上面表格信息从UEFIExtract 源码中提取：解析FPT流程如下：

010如下图：

UTOK区域偏移：

UTOK区域

根据逆向分析的结果：

我们需要的标志位就是0X298，吧这个标志位置1后就启动了部分调试能力，厂家默认这部分是FF，所以是不启动的。

这是我逆向后整理一个图，从读取UTOK以及后面干了什么，UTOK标志位影响什么，还有哪些会影响到我们的调试接口的权限开放 ：

根据逆向分析一共分成9层校验：
第一层：UTOK[0x298] == 1

第二层：boot_mode == 2

boot_mode 来自 0xF00B1050 寄存器的 >> 4 位（PCH 硬件 strap），代码在 0x4109C。
第三层：boot config 解析成功

解析器逐字段匹配 "utknknobs"、"uniquepid" 等字符串，通过 0x5A4E4 表（35 项，每个 stride 24 字节）映射字段名到类型码。
第四层：0x8416C == 1

loc_1D187 是 bup_cfg_handler 中链表搜索失败后的兜底路径。只要走到这里，0x8416C 就被无条件设为 1。
第五层：0x8416D == 1

紧跟在第四层之后，0x8416D 也被无条件设为 1。
第六层：flag_84884 == 0

flag_84884 == 0 时，sub_A14C 中 arg_4=1 < 0x40，走不到加密验证逻辑，直接 return 0。
第七层：CT Handler

CT Handler 遍历配置表（stride=8B），将 type=1 条目的值和地址写入 state 0xC7，type=2 条目的值写入 state 0xCF。这些状态通过 ME 内部总线控制 PCH 的 DCI 传输层。
第八层：var_B7 == 0x36

var_B7 是在栈上分配的一块内存。走非 VFS 路径时（flag_84204 bit0 == 0），sub_1A141 不会写入 *edx（即 var_B7）。var_B7 未被初始化，其值为栈上之前代码路径残留的数据。
第九层：FPF Debug Auth

0x83E38 是 ThreadX 在加载 BUP 时通过 copy-down 初始化的上下文指针。消费板的初始化数据中该指针指向的结构体的 +0x48 处 bit1 为 0。

这里通过分析整个DCI认证的时候发现的一些校验的字段与对应的变量关系。整个UTok就是从本地拉去到内存后进行解析最后映射到不同的变量上去。

这里我定位了一下 Intel-SA-00086 公开泄露的这个位置：
传统的一个溢出漏洞：


核心就是这个数组，这个实际上是一个CT文件的缓冲区，但是没有对CT文件进行校验吗，所以可以构造畸形CT文件来让他直接溢出，当我们的V12超过100的时候这个数组就溢出了。
CT文件格式如下：

这个函数就是我们的从缓冲区拷贝函数：

这里的v11和v12实际上可以认为是一个结构体

[内核课程]《Windows内核攻防实战》！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。