下一个偏门行业赚钱的契机

该错误仅显示约3秒钟，然后系统立即关闭电源。与其直接在仿真的EEPROM中修补哈希，我们实际上应该做与之前绕过密码提示进入设置菜单并从那里进行更改的补丁相同的补丁。

JTAG

在这一点上，我们每个人唯一想保存主板的方法就是JTAG。即使主板没有JTAG连接器，大多数英特尔芯片组也支持通过USB的JTAG。他们称其为直接连接接口或DCI，有两种形式：DbC(USB D e b ug Class)和OOB。OOB在USB引脚上实现了完全不同的有线协议，并且需要一个特殊的适配器，只能通过与Intel签署NDA来获得。使用交叉的USB 3.0 AA电缆连接到要调试的电路板，它将作为USB设备枚举。要与该USB设备接口，可以使用Intel System Studio，无需NDA即可免费下载，它会提供一个普通的调试器界面。

找到接口

我们需要弄清楚如何启用DCI。在大多数主板上，可以访问的设置实用程序仅显示可用配置选项的一小部分。由于某些原因，其他选项通常仍会被编译，即使它们一直是被隐藏的。在UEFI中看到的几乎每个接口都是基于规范HII或人机界面基础结构的。HII接口由VFR 语言进行设计，并被编译为IFR。我们需要做的就是找到显示选项的DXE，然后从中提取IFR。拥有IFR之后，我们可以对其进行分解以使其易于阅读。幸运的是，有人已经完成了编写工具来完成所有这些工作的工作。我们用了 LongSoft的Universal-IFR-Extractor的分支。为了找到正确的DXE，我们只是在设置实用程序中搜索选项之一的名称，IFR提取器的输出是字节码的反汇编版本。

 

我们将仿真EEPROM分为几个部分，我们称之为存储区。有8个存储区，每个存储区包含0x80字节。每个eepromBankID都指向两个连续的存储体，第二个存储体用于大于0x80的字节索引。我们确定对于BpwManagerDXE 重要的信息存储在bank ID 0x57中。

我们编写了一个快速的UEFI应用程序，尝试从该bank ID中读取所有0x100字节，但我们进行的每次调用均eepromRead 返回前0x80字节的错误代码。这意味着我们无法从两个组中的第一个存储组中读取数据，跟踪了在IDA中引用该错误编号的位置。通读代码，我们发现bank ID 0x5C是所有bank 的访问权限数组。每次尝试从存储区读取或写入内容时，都会根据要访问的存储区号(而非ID号)检查存储区ID 0x5C中的字节。bank ID 0x57对应于bank 编号6和7，并确保有足够的bank 编号6已被设置为不允许读取或写入，而bank 编号7允许读取。这解释了为什么我们能够从后半部分而不是前半部分读取字节。

我们试图更改bank 编号6的允许字节，但这返回了另一个错误。我们发现权限字节中还有另一位锁定了进一步的权限更改。尝试修补导致错误返回代码的跳转指令，但这也不起作用。为了追踪它，我们遵循了所有读/写请求的路径，发现它们最终以CPU IO EFI协议告终，实际操作发生在CPU之外的某个地方。

Shenanigans Boot-Time

我猜想所有模拟的EEPROM操作实际上都是由嵌入式控制器处理的，但是我并没有花费太多时间来寻找实际处理它们的方法。对我而言，了解其原理并不是那么重要。板上几乎所有其他芯片都在BGA封装中，而我们不知道其引脚排列，因此，刷新任何存储在其中的芯片都是不切实际的。

我们知道在启动过程中的某个时刻，必须将权限设置为至少允许某些操作，因为要求键入密码的提示需要与之进行比较，并且设置实用程序必须能够更改密码。我们需要的提示是，如果启动到内置应用程序(例如诊断程序初始屏幕)然后退出，则启动菜单中仍会存在设置按钮。但是，如果启动到外部应用程序(例如flash驱动器上的UEFI Shell)，则“ Enter Setup”按钮将消失，直到下一次重新启动。我们在转储中搜索了一个内置应用程序的名称，以尝试查看是否可以将其重定向到通常无法访问但内置的UEFI Shell。事实证明，它们完全是标准的NVRAM UEFI引导项，引导项的属性字段具有一个标志，表示该标志用于应用程序，并且变量包含内置应用程序的GUID，而不是要运行的文件的路径。

“问题”

我们读出了所有bank 的许可字节，发现它们允许每个bank 拥有所有许可。然后，确定了密码的哈希值位于EEPROM中的位置，并向其中写入0。如果将BpwManager密码的哈希值全部读取为0，它将认为未设置密码， 重新启动后，我们能够进入启动菜单，但是选择任何启动项都遇到此错误：

（编辑：淮南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!