之前一直没想解开bl的，会导致部分应用识别比较麻烦，但是国行的内置各种应用还有应用安装验证太逆天了。记录下codex全自动解开BL的过程，就是期间很容易弹审核

小米 14 Ultra Ti 解锁 BL、刷入 Xiaomi.eu 实录：从驱动故障到成功进入系统

操作时间：2026 年 9 月 15—16 日；整理于 9 月 17 日。

这是一台具体设备的操作实录，不是所有小米 14 Ultra 都适用的一键教程。过程中实际改写了启动组件、分区表和用户数据，出现过无法进入系统的情况。最终成功不代表这条路线可以保证成功或保留数据。

最后的结果

这次最终完成了两件事：解锁国行小米 14 Ultra Ti 的 Bootloader，并刷入 Xiaomi.eu 社区版 HyperOS。

刷完后通过 ADB 确认：系统启动完成、首次设置完成，Xiaomi.eu 标识存在；换回 ROM 自带的启动组件后，BL 仍然保持解锁。没有停留在“工具显示成功”这一步。

整段经历可以概括为：

ADB 连接 → 文件审查与补齐 ABL → 单独测试提权 → 原脚本执行遇到多设备问题 → fastboot 驱动修复 → 重启发现系统无法启动 → 从 fastboot 分阶段继续解锁 → Ennea → 写回 GPT → 核验解锁 → 刷入 Xiaomi.eu → 完成小米与 Google 账号验证 → 核验系统。

1. 设备和环境

个人重要数据此前已备份，但开始时没有准备好匹配的完整恢复包，也没有验证失去 fastboot 后的恢复路线。这是本次准备不足的地方，不应作为后来者照搬的做法。

文中不公开设备序列号。示例命令中的 <SERIAL> 必须替换成自己的设备序列号。

2. 第一个误区：ADB 看不到，不等于电脑完全看不到手机

最开始运行 adb devices -l，列表为空。一开始只查了 ADB，判断不够完整：手机当前处于什么模式、Windows 有没有识别 USB、驱动是否正常，都需要一起看。

后来手机在正常系统中重新开启 USB 调试、完成连接授权后，ADB 成功识别设备。这时可以读取型号、系统版本和内核信息。

ADB 和 fastboot 是两种连接

本次两个模式的驱动状态也不同：ADB 曾经工作正常，切到 fastboot 后却出现了驱动安装失败。

后来在 fastboot 下重跑完整解锁入口，它一直提示“正在检查 ADB 连接”，就是因为它从系统里的提权步骤开始，不能识别当前阶段并自动续跑。

3. 工具包不是下载下来就完整可用

仓库里的三个入口很容易混淆：

静态检查发现，Ultra 分支所引用的文件中，脚本要求的 images/abl.elf 没有放在目标位置。转移包另外保存了从作者 v6.0.0 的 Xiaomi14ultra 专属路径取得的候选文件。

核对 SHA-256 后，将它复制到：

unlockFolder/factoryImages/Xiaomi14ultra/images/abl.elf

本次使用的 ABL SHA-256：

6f74cd39b64863e71dafb86544e18ba04455689268e60e4ab4b2412879294cc1

这是工程 ABL 候选，不是原手机 ABL 分区备份。文件齐全，只能说明脚本引用的文件存在，不能直接证明整机适配。

还有一个容易误判的细节：原作者脚本给 Ultra 选择的是 bin/Redmik80 里的提权程序。这是原脚本的映射，不等于后续可以混刷 K80 的固件。

中文乱码怎么解决的

原 BAT 是 GBK 编码，而终端代码页是 UTF-8（65001），导致中文提示乱码。

本次保留原文件编码，在 toUnlock.bat 的 @echo off 后加入：

chcp 936 >nul

修改前备份了原入口。此改动只处理显示，不改变解锁流程。

4. 先做了一次独立提权测试

为了不在提权成功后立即写入 ABL，新增了 toUnlock-simple.bat 和配套 PowerShell 脚本。

这个测试入口固定目标设备、核对提权文件哈希，上传 exploit 和 su，只调用一次 exploit，然后读取 UID 和 SELinux 状态。失败不自动重试，也没有调用完整解锁脚本。

结果是：

uid=0(root) ... context=u:r:shell:s0
Enforcing

也就是说，本次取得了 UID 0，但 SELinux 仍在强制执行策略，尚未达到原脚本要求的 Permissive 条件。

临时 root 成功，不等于 BL 解锁成功，也不能推导出整条链路一定成功。 此测试也不是只读操作：提权程序报告修改了内核，退出测试不会自动撤销修改。调用一次程序，也不代表程序内部只尝试了一次。

后来原脚本的输出里出现了多轮 GPU 读写尝试，部分失败后再次尝试成功。我们没有获得足够证据，把每次报错都归结为某个确定原因。

5. 原脚本执行中断：多设备、驱动和不完整日志

运行完整入口后，出现了：

adb: error: failed to get feature set: more than one device/emulator
adb: error: connect failed: more than one device/emulator
工程abl推送失败，请保持通信稳定回车重新推送

这些错误表示：当时 ADB 看到了多个连接，而原脚本没有指定目标序列号。不能仅凭它们判断是数据线不稳定。

之后手机进入 fastboot，但电脑的 fastboot devices 仍为空。Windows 的实际状态是：

USB\VID_18D1&PID_D00D\...
CM_PROB_FAILED_INSTALL

这一次确实是 fastboot 模式对应的驱动问题。

驱动最后怎么修好的

先确认解锁脚本已经退出，避免驱动恢复时另一个流程自动开始刷写。

Google SDK 的 USB 驱动包虽然签名有效，但其中没有列出当时的 VID_18D1&PID_D00D。最终从 Microsoft Update Catalog 获取了匹配该硬件 ID 的驱动，核对 64 位 INF 匹配项和微软签名，再安装。

修复后的设备名称是 Android Bootloader Interface，Windows 状态正常，fastboot 可以枚举并执行只读查询。

后续操作全部固定目标序列号，例如：

fastboot -s <SERIAL> getvar product
fastboot -s <SERIAL> oem device-info

原始日志没有完整保存屏幕输出

虽然入口用了 PowerShell Transcript，但本次 unlock_log.log 主要保存了会话头尾，没有完整捕获原 BAT 的输出。因此，不能指望只看这个日志就准确恢复原脚本的执行位置。

后续改为逐条执行命令，直接捕获输出到日志，并检查每条命令的退出码。设备仍能枚举、画面出现“成功”，都不再作为替代证据。

6. 最紧张的一步：重启后出现 “The system has been destroyed”

驱动修好后，手机仍然报告 BL 锁定。此时执行了一次 fastboot reboot，希望回到正常系统，但手机显示：

The system has been destroyed

这时原脚本已经执行了多少写入并不清楚。现有输出无法确认两槽 ABL 的具体内容，也不能确定到底哪个组件导致了启动失败。

这次重启判断过早。 在写入状态不明确时，应先整理执行记录，不能把“fastboot 连接恢复”理解为“原系统一定还能正常启动”。

好在按电源键＋音量下键后，仍能进入 fastboot。读取到的状态包括：BL 仍锁定，当前槽位 A，B 槽标记不可启动。本次没有盲目切换到 B 槽。

7. 从 fastboot 继续，才真正完成了解锁

经过明确选择，这次继续了工具原定的 fastboot 后半段。不过，没有直接让原 BAT 不加检查地一路跑完，而是固定设备、按原 Ultra 分支顺序逐条执行，任何失败立即停止。

主要阶段如下。这里记录动作范围，不提供可直接复制执行的整串破坏性命令。

阶段一：写入工具包 Ultra GPT 和启动组件

先写入 Ultra 工具包 GPT，随后执行机型脚本中的两槽启动组件替换、boot 擦除、metadata/userdata 擦写及其他相关写入，最后回到 bootloader。

所有执行的命令均返回成功。到这个阶段，原系统已经不能直接启动，必须继续完成解锁并恢复完整 ROM。

阶段二：解锁 GPT 与 Ennea

写入 Ultra 专用解锁 GPT，启动工具包的 8650-Ennea.img。两条命令均返回 OKAY。

手机屏幕随后是黑的，没有可供记录的成功界面。按电源键＋音量下键手动回到 fastboot，再写回工具包 Ultra GPT。

这里的“写回 GPT”是写回工具包里的文件，不是恢复本机事先备份的原始 GPT。

阶段三：读取真实锁状态

这次查询得到：

Device unlocked: true
Device critical unlocked: true
unlocked: yes

这才是本次 BL 解锁的直接证据。我们没有通过 check-unlock.bat 或 FRP 擦除来“检查”成功。

但当时仍在工程启动环境下，所以还需要刷完正式可用的系统后再次确认。

8. 选择 Xiaomi.eu，并完成整包校验

这里选择的是 Xiaomi.eu 社区 ROM，不是小米官方 EEA 欧洲版。

本次安装文件：

xiaomi.eu_AURORA_OS3.0.306.0.WNACNXM_16.zip

来源为 Xiaomi.eu 发布方提供的 SourceForge 链接。包内机型检查使用 aurora，构建元数据包含 aurorapro。这些是对应关系的证据，不代表所有 Ti 功能都已提前通过验证。

下载起初很慢，后来切换为 aria2 的 16 连接断点续传，保留已下载的数据。下载中一度达到约 30 MiB/s，最终下载器报告完成。

发布页当时只展示 MD5 的前缀 ca3146a0f4，本地计算值与此前缀一致。没有取得发布方完整哈希做独立对照，不能把前缀匹配写成“完整官方哈希校验通过”。

9. 一个很有价值的发现：写回 GPT 后，要确认 bootloader 重新读取了它

正式刷 ROM 前，对安装脚本中各镜像的目标分区和容量做了检查，包括 sparse 镜像的逻辑大小。

检查中发现，fastboot 没有列出 vbmeta_a 和 vbmeta_b，单独查询也返回不存在。此前明明已经成功写回工具包 GPT。

于是只重启到 bootloader，再查询：

partition-size:vbmeta_a: 0x20000
partition-size:vbmeta_b: 0x20000

分区重新出现，BL 和 critical 仍保持解锁。这与 bootloader 此前仍使用旧分区表枚举的解释一致；没有进行更底层的实现验证。

这一步说明：GPT 写入命令成功，不代表当前会话中的分区枚举已经更新。 如果没有刷前检查，就可能把后面的失败误判为 ROM 缺件或不兼容。

10. 刷入 Xiaomi.eu：49 条命令逐条通过

以包内 windows_install_and_format_data.bat 为依据生成安装计划，核对 49 条命令涉及的镜像和目标容量，记录镜像哈希。

实际执行时继续使用 SDK fastboot，固定序列号，每个镜像写入前复核哈希，每条命令执行后检查退出码。

安装内容包括：

• 设置 A 槽为活动槽位。
• 写入 ROM 中的 ABL、XBL、TZ、keymaster、基带等固件。
• 写入两槽 boot、init_boot、vendor_boot 和 recovery。
• 顺序写入 12 个 super 分段。
• 擦除 metadata 和 userdata。
• 重启进入系统。

全部 49 条命令成功，日志没有 FAILED。安装计划没有重新锁定 BL 的命令。

这份 ROM 覆盖了主要启动固件和系统，但不能把它描述成“已逐字节还原所有曾经改动的分区”。本次没有对所有辅助分区做完整原机对照。

11. 能开机之后，还遇到了两道账号验证

手机进入 HyperOS 启动画面后，并不是直接到桌面，而是先后遇到了小米和 Google 的设备验证。

小米账号激活锁

提示大意是：设备关联了已有小米账号，需要输入密码验证。

这是刷机后的账号所有权验证，使用原先绑定的小米账号完成。它与 Bootloader 锁是两回事，输入账号密码本身不是重新上锁 BL 的操作。

Google 恢复出厂保护（FRP）

随后 Google 要求登录之前在这台设备上添加并同步过的账号。

这里的“设备已恢复出厂”是在描述刚发生的清数据状态，不是要求再清一次。小米账号验证通过，也不会自动替 Google 验证放行。

开始时曾尝试把设置过程当成普通初始化，通过离线设置绕过联网步骤。看到明确的 FRP 提示后，就知道这个建议不适用于当前验证页面，最终需要原账号和可用的 Google 网络连接。

国内网络与 Clash Verge

为解决 Google 登录页面的联网问题，检查了电脑的 Clash Verge：局域网访问已开启，Mixed 端口正在监听，并且通过电脑局域网地址的 HTTP 代理访问 Google 登录页成功。

手机 Wi-Fi 的手动代理可以填写：

不要照搬别人电脑的 IP 或默认端口。本次没有完整抓包证明设置向导的每一项请求都经过代理，也不能保证所有版本都遵循 Wi-Fi 代理。

用户完成账号验证和首次设置后，手机进入了可正常操作的系统。

12. 最终核验：不只看桌面能不能打开

新系统中重新授权 ADB 后，读取到：

ro.xiaomi.eu.ota_device=AURORA
ro.build.version.incremental=OS3.0.306.0.WNACNXM
ro.build.version.release=16
sys.boot_completed=1
ro.boot.flash.locked=0
ro.boot.vbmeta.device_state=unlocked
ro.boot.verifiedbootstate=orange

另外，首次设置完成标志为 1，SELinux 为 Enforcing，数据分区正常挂载，总容量约 941 GiB、当时可用约 933 GiB。

最重要的结论是：刷入 ROM 自带启动组件并成功进入系统后，系统仍报告 BL 解锁。 这比只在工程 ABL 中看到解锁提示更完整。

但验证仍有边界：当时两张 SIM 都报告未插入，尚未据此完成通话、移动数据、相机、指纹、NFC 和长期稳定性测试。因此本文结论是“解锁与系统安装成功”，不是所有硬件功能已获完整认证。

临时提权测试成功，也不代表最终 Xiaomi.eu 自动保留了 root；本次没有为新系统安装 Magisk 或 KernelSU。

13. 如果重新来一次，我会把哪些事提前做

1. 先备好完整 ROM 和账号验证条件。 不仅备份数据，也先确认小米与 Google 原账号能登录、验证码能收到、网络能用。
2. 先分别验证 ADB 和 fastboot。 不等到写完启动组件才发现另一个模式缺驱动。
3. 所有设备命令固定序列号。 不依赖“目前大概只有一台设备”。
4. 先读脚本，区分检查和破坏性动作。 文件名叫 check，并不代表只读；小镜像文件也不代表影响范围小。
5. 每一步保存真实输出、检查退出码。 不以设备还能枚举、未出现某个关键字或脚本打印成功作为完成标准。
6. 不在写入状态不明时随意启动系统。 先确认处于哪个阶段，以及下一步需要什么条件。
7. 写回 GPT 后重新核对分区枚举。 本次重启 bootloader 才让缺失的 vbmeta 分区重新可见。
8. 最后在新系统里复查 BL。 工程环境成功只是阶段性结果。

后续更新怎么处理

今后使用 Xiaomi.eu 对应机型的更新包，按该版本说明升级，不需要再次运行 Mi8G3 解锁工具。

本次包同时提供 windows_install_upgrade.bat，它与首次安装清数据入口不同。未来升级前仍应核对新版脚本和发布说明，不误用 install_and_format_data，也不执行重新锁定 BL 的操作。

来源和本次证据

公开来源：

• Mi8G3-Unlocker 项目
• v114514 发行页
• v6.0.0 发行页
• Microsoft Update Catalog：本次 fastboot 硬件 ID
• Xiaomi.eu／MIUIPolska 的 14 Ultra 发布页面
• 本次 Xiaomi.eu 安装包发布目录
• 小米账号激活保护说明
• Google 恢复出厂保护说明

以下是本地证据相对路径，仅在保留本工作区目录时有效：

• 转移包说明
• 原脚本恢复范围审计
• Ultra GPT 首次写入记录
• Ultra 组件刷写记录
• Ennea 阶段记录
• GPT 写回及解锁状态记录
• ROM 下载校验记录
• Xiaomi.eu 安装计划及镜像哈希
• Xiaomi.eu 完整刷写日志

分享文章时，不必附上原始日志；日志中可能含设备序列号、本机路径等信息，应先脱敏。

回头看，这次最关键的不是某一条神奇命令，而是把原本连续执行的流程拆开：分清连接模式，补齐准确的组件，在每个阶段查看实际结果，最后用新系统的状态证明结果。过程确实一波三折，也暴露了准备不足和过早重启的问题；这两部分都值得留下来，才是一份对后来者有用的记录。