← 返回列表
Article · BIOS 刷机

联想小新 Pro 14ACH 2021 BIOS 黑砖自救

2026-03-21

记录一次 Lenovo XiaoXin Pro 14ACH 2021 BIOS 黑砖后的修复过程

省流版请看最后。

因为平时一直用台式机，这台小新吃灰很久了。前阵子把它翻出来，想着顺手更新一下 BIOS，结果这一更直接把自己送走了。

最开始我还以为只是普通更新翻车，重启几次或者找个官方包刷回去就差不多了。后来很快发现事情没那么简单：机器已经进了典型的黑砖状态，上电、风扇转、键盘灯亮，但屏幕就是不亮。既然已经到这一步，后面基本就只能走编程器这条路。

不过我以前刷过不少设备，也踩过不少砖，所以这次虽然机器已经黑了，脑子里还不至于完全没概念。至少有两件事我是比较明确的：

  • 先把能读出来的东西尽量都备份下来
  • 直接刷官方固件可能不行，因为刷 BIOS 是底层操作了，会整个重写，会丢一部分原机固化的信息

所以说，想完成救砖，至少思路是比较清晰的：

  • 第一种方案是拿到同型号机器的整个 Flash rom 备份，然后替换 S/N，序列号之类的原机自带信息
  • 第二种方案是先确保开机，开机之后再想办法补

机器情况

  • 型号：Lenovo XiaoXin Pro 14ACH 2021
  • 主板：NM-D691
  • BIOS 架构：InsydeH2O
  • 刷写方式：SPI 编程器离线刷写

先把备份读出来

真正开始折腾之前，我踩了一个小坑。

因为以前用过编程器，所以机器黑砖之后，第一反应就是直接买了一个 CH341A。东西到手后，我也是按以前的经验直接上，结果夹上去之后，软件这边连芯片都识别不出来，于是我拍了芯片上的丝印，去查一下这个芯片是不是有什么需要什么特殊手段读写。

上面的丝印写的是 Winbond 74M12JWSIQ，这个型号不算常见，一开始搜了很久都没搜到特别直接的资料。后面才在 Winbond 官方的产品资料一个 pdf 里找到一些线索，里面能看到 W74M12JW：

  • 1.8V
  • 128Mb
  • WSON 8x6-mm

看到 1.8V 这个字眼，我去软件里面翻了一下芯片列表，发现大部分都是 3.3V 和 1.8V，感觉有点不妙，因为夹上去之前没考虑过电压的事，没准我这一夹直接把芯片烧坏了也不是没可能，甚至概率很大。

我没敢再继续折腾，赶紧补买了一个 1.8V 转接板，又等了两天快递。等转接板到了之后，再把它接到 CH341A 上去读，并完整备份下来了，这里比较保险的做法其实是多备份几次，每次都重新插拔，防止有时候由于各种原因，备份的数据不完整。

Winbond 那张表里有个规律很明显：

  • 12 对应 128Mb
  • 25 对应 256Mb
  • 51 对应 512Mb
  • 01 对应 1Gb
  • ...JV 这一类是 3V
  • ...JW 这一类是 1.8V

所以 W74M12JWSIQ 就是 1.8V / 128Mb，而 128Mb 也就是 16MB，这表明我需要刷的 BIOS 应该是 16MB 的。

下面这张图就是当时组起来的编程器和 1.8V 转接板。

编程器与 1.8V 转接板

参考资料：

找别的备份

备份读出来之后，下一步就是去找同型号、同板号、别的机器的 dump 来做参考。目的倒不是直接拿别人的 ROM 当答案，而是先确认这台机器的 BIOS 结构到底长什么样，顺便看看哪些区域是通用内容，哪些区域更像是机器自己的身份信息。

这里面那份同型号备份也不是一下就找到的。前前后后全网搜了很久，不只是搜本机型，也搜过一些套娃机型和可能共板的型号，比如 Yoga 系列，想看看有没有能对上结构的 dump。最后那份能用来参考的备份，是在一个 Telegram 群里翻到的：

之后我读到了整个 NVRAM 镜像，并把我本机的这部分整体替换到这个同型号备份中并写入芯片，发现并不能开机。

拆官方包

别的备份这条路走不通，后面我才换了个方向，去拆联想官方的升级包，先做一份能稳定开机的底包。

这个“官方底包”并不是下载下来直接就能给编程器刷，因为联想给的默认是 Windows 下升级用的东西，要先把编程器能用的那部分提出来。

联想官方提供的是一个 Windows 下运行的升级 exe，运行之后一般会给“安装”或者“解压”两个选项。我走的是“解压”这条路，先从里面拿到 BIOS.cap。但 BIOS.cap 前面还带着一段 capsule/header，这一段对在线升级是正常的，对编程器直刷就不是实际要写进 SPI flash 的内容了。

这一步如果没处理好，后面你在 BIOS.cap 里看到的结构，和编程器读出来的 16MB dump 就根本对不上。

这台机器上，我后来实际对比出来的结果是：

  • BIOS.cap 总大小：0x111B780
  • 真正的 16MB SPI 镜像大小：0x1000000
  • 原始 16MB 正文并不是从 0x0 开始，而是从 0x320 开始
  • 也就是说，前导头长度是 0x320

更直观一点说，BIOS.cap 在 0x320 这个偏移开始，才真正对齐到编程器读出来的 SPI 正文。那个位置一上来就能看到原始镜像的开头标记：

0320: 4C 44 42 47 FF FF FF FF ...
      L  D  B  G

真正能给编程器刷的 16MB 固件是：

BIOS.cap[0x320 : 0x1000320]

这里还有一个容易漏掉的细节：BIOS.cap 不只是前面多了一小段头，它在 16MB 正文后面还跟着额外数据。所以正确处理方式不是简单“去头”，而是：

  • 从 0x320 开始取
  • 只取后面连续的 0x1000000 字节

也就是只截中间那段完整的 16MB 正文，后面那一段额外数据不要带进去。

所以我当时实际做的是：

  1. 从联想官方升级 exe 里自解压出 BIOS.cap
  2. 识别出 BIOS.cap 前面的 capsule/header 长度是 0x320
  3. 从 0x320 开始截取连续 0x1000000 字节
  4. 得到真正 16MB 的编程器固件

后面文里说的“官方底包”，指的就是这个去掉前导头之后得到的 16MB 镜像，而不是原始的 BIOS.cap。

刷回官方包

最早的黑砖状态很典型：

  • 上电后键盘灯亮
  • 风扇转
  • 屏幕不亮
  • 无法正常进入系统

后来把官方 BIOS 底包刷回去之后，机器是能开机的，但显示出来的东西不对：

  • 机型变成了 IdeaPad india xxx
  • S/N、序列号、UUID、Windows 预装密钥都丢了，logo 也变成联想通用的了

也就是说，官方底包至少把机器点亮了，但机器原来那部分信息并没有一起回来。接下来要解决的问题也就明确了：机器已经能开机了，剩下要找的是那部分身份信息到底存在哪、该怎么单独拿回来。

用到的工具

这次前后主要就用到这些：

  • 编程器：CH341A + 1.8V 转接板
  • 十六进制编辑器：HxD、WinHex、hexed.it
  • UEFI 工具：UEFITool、UEFIExtract、UEFIReplace

CH341A 和 1.8V 转接板用来读写芯片。HxD、WinHex、hexed.it 主要用来看偏移、搜字符串、比对镜像。UEFITool 这些工具主要拿来拆官方包、看模块结构。

线索

官方底包已经能启动了，但后面那段时间并不是一下就找到地方了。我先是继续拿十六进制编辑器到处看，也试过那些和 DMI 相关的工具，想看看能不能直接把序列号、机型这些东西补回去，但一直没有真正找到那块地方。

这里还踩过一个 UEFITool 的版本坑。当时我一度想直接用它去替换 NVRAM，结果新版里没法像老版本那样直接 Replace as is，后面只能换回 0.28 继续弄。

前面我自己在 UEFITool 里找了很久，还是没把关键位置摸出来，后来才开始请 Codex 帮忙。但 Codex 没法直接操作 UEFITool，单靠截图也截不全，我就改用 UEFIExtract 把结构整个解出来，让 Codex 直接读这些内容。然后就是对着解出来的结构一点点翻，主要盯机型、品牌、NVRAM、SMBIOS 这些关键词，但翻了半天还是没找到真正有用的东西。

后来我给 Codex 发了机器后盖的照片，上面就有序列号、SN 这些信息，想让 Codex 帮我找找，看看能不能直接顺着这些信息在 BIOS 里搜到线索。Codex 的回复中，把这类东西归到了 DMI 这个词。简单说，DMI 就是 BIOS 里专门放机器身份信息的那部分，像序列号、机型、MTM、UUID 这些，基本都在这里面。

也是从这里开始，我才去 Google 搜 lenovo bios dmi 之类的关键词。搜到了一些工具说是可以在 EFI SHELL 中直接改 DMI，尝试了 ami-invgy_utl_uefi_vpd 和 Lenovo-U1-Tool 这俩都无果，一个直接提示不支持，另一个虽然能执行，但最后没有生效，等于没真的写进去。后来我又换了几组关键词继续搜，在 YouTube 上翻到一个相关视频：

我看了这个视频标题，觉得 decrypt dmi 跟我这个问题相关性很大。因为如果能 decrypt，我就能找到存放这些信息的位置，后面也就能回填还原我自己机子的信息，所以就跟着视频往下做。视频里是先搜 LENV，我也照着去搜，然后在 BIOS 前部找到了两处：

0x1000 - 0x1FFF
0x2000 - 0x2FFF

我先对了一下这两块的结构和地址，发现规律很明显：前后连着，长度一样，都是 LENV 开头，里面还能看到重复的分隔符和字段编号。搜出来的原始内容大概就是这种样子，前面是 LENV，后面跟着一大段看不懂的东西，再往后还能看到一长串重复的 €。照着视频里的规则去看，这种内容是要先做 XOR 还原的，而 XOR value 就是后面那一长串重复出来的那个值。

后面还顺着找到了一个项目：

到这一步，让 Codex 解释一下 LenovoDMIDecryptor 的代码，规则就比较清楚了：

  • 这块数据不是明文，得先按 key 做单字节 XOR
  • key 就写在 LENV 头里，是 1 个字节
  • 后面的数据区按字节跟这个 key 逐个异或，本质上就是同一个值一路 XOR 下去
  • key 不是固定值，要按当前这份 ROM 里实际写的那个来
  • 解开之后，里面能看到序列号、机型、MTM 这类机器信息
  • 同样的结构在这台机器前部放了两份

项目代码里另外还有个校验规则，也顺手能看出来：LENV 头里还有 2 字节 checksum，做法是把整块数据逐字节求和，得到 16 位结果之后，再把高低字节交换一下。

找到这两块之后，后面要看的事也就剩这几件：

  • 官方底包这两个位置里放的是什么
  • 原机坏 ROM 里这两个位置还在不在
  • 如果还在，能不能只把这一小块拿回来

下面这张图是 LENV 在 0x1000 位置的一段数据截图。

LENV 0x1000 数据截图

到了这一步，网上找到的那份同型号备份能拿来干什么，也就比较清楚了。它适合拿来对结构，但不能直接拿来当恢复数据源。

在那份别人的 ROM 里，LENV 双块处理之后，可以直接读出一整套机器标识信息，比如序列号、产品名、MTM、板号、OA3 key 之类。

而在我自己的 backup.bin 里，按正确方式处理之后，读出来的就是这台机器原本那套信息。

看到这里，两份 ROM 的分工也就出来了：

  • 别人的 ROM 用来告诉你这块结构长什么样
  • 原机坏 ROM 用来把这台机器自己的信息拿回来

对比之后还能看到另一个细节：

  • 别人的 ROM 这边，LENV key 是 0x80
  • 我自己的 backup.bin 这边，LENV key 是 0x78

同样是 LENV 结构，不同机器、不同 ROM，用的值不一定一样。现在还不太确定这里面具体是什么规律，反正实际处理的时候要按自己这台机器里的来。

后面再把官方底包对应位置拿来对比，结果就很清楚了：0x1000 和 0x2000 这两个地方同样有 LENV 头，但里面放的基本都是用来占位的 0。 前面在官方 ROM 里搜 IdeaPad 的时候，发现是能直接搜到的，所以我当时就把它理解成了一个通用的默认值。前面提到官方底包刷进去之后，机器实际显示出来的是 IdeaPad，logo 也变了。所以，我就更倾向于认为，logo 不是单独存的，而是跟机型信息有映射关系。那这次替换的重点也就很明确了，不是去单独折腾 logo，而是把这里原来那套机型信息换回去，logo 很可能也会顺便一起恢复。

回填

最后实际动手的时候，做法反而很简单，就是把 backup.bin 里这段地址上的两块数据替换回官方底包对应位置，再整体刷回去。最后动的范围就是 0x1000 - 0x2FFF，也就是前面那两个连续的 LENV 块所在的整段。没有再去大范围乱拼，也没有去搬别的机器的信息，就只动这台机器自己原来那部分内容。

刷完之后，机器就正常了。机型、品牌、logo、序列号这些信息都回来了，救砖算是结束了。

验证是否成功主要对比的是这些地方：

  • 能不能稳定点亮，进 BIOS、进系统有没有问题
  • 机型是不是回到原来的型号，而不是默认的 IdeaPad
  • 序列号、MTM、产品名称这些信息是不是正常
  • logo 和品牌信息是不是恢复了
  • 前面那种 fTPM 重置提示还会不会再冒出来
  • 系统激活状态是不是正常

省流

  • 先用编程器把原机坏 ROM 备份出来，别急着乱刷，多备份几次以免因为连接问题导致备份丢失内容。
  • 从官方升级包先解压出 BIOS.cap，再从 0x320 开始截取连续 0x1000000 字节，拿到真正能刷的 16MB 固件，这个步骤最好用 UEFITool 对比着弄，防止弄错，可以看到 0x320 开始是一个连续块，显示类型貌似是一个镜像（忘了，反正是一个整体），也可以用 UEFITool 将这个镜像解压出来，然后用 Hex 编辑器将头部那几个多出来的字节删掉。
  • 先把这份 16MB 官方底包刷进去，确认机器已经能亮，然后从备份中找到地址为 0x1000 - 0x2FFF 这段（开头是 LENV）。
  • 最后把备份里的这段回填到官方底包对应位置，再整体刷回去，测试机器的 S/N，型号等信息是否恢复正常。

参考

目录
⋯

搜索文章