想和代码谈谈

玮仔的个人博客

2026-03 小米 / 高通 GBL 解锁事件：一次从私有变现走向公开化的漏洞扩散（基于公开信息 + 笔者推演）

发表于 分类于 阅读次数： Valine：
本文字数： 6.6k 阅读时长 ≈ 6 分钟

说明：截至目前，厂商尚未公开完整的技术复盘。本文依据公开可交叉验证的 AOSP 文档、第三方公开 PoC、论坛讨论，以及笔者这几天持续跟进到的玩家侧反馈，对这次“小米 / 高通免拆机解锁 BootLoader”事件做一次阶段性分析。文中涉及根因、传播路径、厂商修补策略与后续影响的部分，均为推测，不代表事实结论。

1）先说结论：这不是一次普通的“解锁教程流出”

如果只把这次事件理解成“某个厂商的解锁入口被绕过了”，其实是低估了它。

从目前公开线索看，这件事更像是：

  • Android 新一代引导架构里，原本给系统标准化、可更新、可维护而设计的一层能力；
  • 在具体厂商实现上，被人找到了一个可以串起来的利用链；
  • 这条链先在小圈子里验证、变现、扩散；
  • 最终随着远程化、工具化、脚本化，走向公开化。

也就是说，这不是“一个命令”或者“一个脚本”本身厉害，而是 Android 启动链的某个新边界，第一次被更大规模的玩家群体感知到了。

换句话说，这次的冲击，不只是“有人能绕过解锁资格”，而是让很多人第一次意识到：

在 Android 生态里，BootLoader、Verified Boot、UEFI/GBL、Root、KernelSU，这些过去看起来很分散的东西，正在重新连成一条线。

2）先列出当前大致能确认的事实

截至目前，外部能较为明确对上的信息大致有这些：

  1. AOSP 在 2026 年 1 月正式新增了 Generic Bootloader（GBL）总览文档，并明确将其定义为“标准化、可更新的 bootloader 方案”；文档中也写明了 GBL 负责 Android 核心引导逻辑、Fastboot、以及 UEFI protocol handlers 等能力。(source.android.com)
  2. AOSP 的 GBL 部署文档要求设备具备 android_esp_a / android_esp_b 两个 FAT 分区，并明确说明 OTA/rollback 依赖这一层；更新 GBL 时，需要更新整个 android_esp_${SLOT_SUFFIX} 分区。(source.android.com)
  3. GitHub 上已经出现公开的第三方 PoC 仓库 hicode002/qualcomm_gbl_exploit_poc，仓库 README 直接声称：gbl 以 UEFI app 的形式存在于 efisp 分区，向其中写入 EFI 文件后，可以借此执行未签名 UEFI app，并改写 RPMB 里的锁状态；仓库中还公开提供了 gbl_efi_unlock.efi、gbl_efi_relock.efi 与相关源码文件。(github.com)
  4. 论坛公开讨论也已经从“有人私下可做”逐步转向“围绕 8E5 / GBL exploit 的集中讨论”；至少从公开时间线看，到 2026 年 2 月初与 3 月初，这件事都已经不再是极少数人的私密话题。(xdaforums.com)
  5. Android 官方对 BootLoader 锁定状态的标准设计仍然非常保守：解锁需要进入 bootloader，执行 fastboot flashing unlock，并通过用户交互确认，且会触发数据擦除；重新上锁也对应 fastboot flashing lock。官方还明确要求，某些 critical section 的锁定状态切换不应允许纯程序化完成，而需要物理交互。(source.android.com)
  6. 2026 年 2 月 Android Security Bulletin 已发布，但公告本身并没有直接点名这条 efisp / GBL 利用链；同时，AOSP 也明确写道，Android device 和 chipset manufacturers 还会单独发布自己产品相关的安全细节，这意味着“是否修了”不能仅从 Google 的月度公告标题直接反推。(source.android.com)

上面这些事实拼在一起，至少能支持一个判断：

这次事件不是“古早厂商私有接口泄露”那么简单，而是和 AOSP 正在推动的一套新引导架构发生了真实交叉。

3）这次事件，为什么会让刷机圈这么兴奋？

表面上看，大家兴奋的是“终于有人能免拆机解锁了”。

但再深一层，真正刺激玩家情绪的其实是三件事。

3.1 它动摇的不是单个厂商政策，而是“解锁门槛的正当性叙事”

过去几年，很多厂商一边强调“安全”，一边不断把 BootLoader 解锁做成一个越来越高门槛、越来越长链路、越来越像资格审查的过程。

从厂商视角，这件事当然有合理性：

  • 要控制售后成本；
  • 要降低风控风险；
  • 要减少被滥用后反向甩锅；
  • 要维护 DRM、支付、完整性验证和商业合作链条。

但从玩家视角，这套叙事的问题也很明显：

  • 手机是我买的；
  • 刷机风险我自担；
  • 为什么我获得设备最终控制权，反而越来越像是在申请特许经营？

所以这次事件真正点燃情绪的地方，是它把长期以来被压抑的那种感觉重新放了出来：

用户对自己设备的控制权，到底是“厂商赋予的权限”，还是“设备所有权的自然延伸”？

3.2 它让“Root”重新从老玩法，变成了新议题

如果这次事情只是“偷偷帮几台小米开了 BL”，其实影响不会这么大。

真正让它有时代感的，是它和另一条线天然接上了：

不解锁 BootLoader，是否也可能在某些条件下拿到一种类似 iOS 越狱的控制力？

这里我很认同维术文章里的一个观察：

这次被公开的，不只是 BL 解锁方法，而是 Android 侧“越狱模式”重新进入现实讨论的起点。

这个观点为什么重要？

因为它把问题从“能不能刷机”提升成了“能不能重新定义 Android 的控制边界”。

过去大家理解 Root，多半还是：

  • 先解锁 BL；
  • 再刷 boot；
  • 再上 Magisk / KernelSU；
  • 然后围绕完整性校验、模块、隐藏、对抗做长期博弈。

但如果某条利用链能够在 不先完成官方解锁动作 的前提下，获取足够高的控制权，那么 Android 玩家生态会被重写：

  • Root 不再完全依赖厂商给不给“解锁资格”；
  • KernelSU 这类内核态方案的想象空间会突然增大；
  • “解锁”和“越狱”这两个词，在 Android 世界里会重新靠近。

这也是为什么，这次事件在很多老玩家眼里，看起来不像一次单纯的漏洞传播，而更像一个时代隐喻。

3.3 它还意味着：Android 的“安全边界”正在迁移，而玩家也开始顺着新边界研究

从 AOSP 近几个月对 GBL 的正式文档化来看，Google 的目标很清晰：

  • 减少碎片化 vendor bootloader；
  • 把 Android boot 逻辑、Fastboot、UEFI handler 等东西收敛成更标准的一层；
  • 让引导链更统一、更可更新、更可维护。(source.android.com)

这原本是标准化、工程化、提升安全性的方向。

但工程世界有一个很常见的现象：

一旦某一层被标准化、公开化、文档化，它就更容易成为新的研究热点。

过去很多厂商 bootloader 是一团高度私有、难以复用、难以系统研究的黑盒；现在你把其中一层逐渐拉到更统一的 UEFI / GBL / protocol 框架上，研究门槛就会发生变化。

不是“更不安全”，而是“更容易被系统性研究”。

4）把问题拆开看：这次事件到底包含哪几层？

围绕这件事，外部讨论经常把很多层混在一起。实际上，至少应该拆成下面五层：

层次讨论的问题当前判断
1. 引导架构层efisp / GBL / UEFI 这一层是不是正式 boot chain 的一部分？是，且 AOSP 已经明确文档化。(source.android.com)
2. 技术漏洞层是否存在一条可以通过 GBL/EFI 载荷影响锁状态的利用链？第三方公开 PoC 已经明确这么主张，但厂商尚未公开确认。(github.com)
3. 实战利用层这条链是否所有同代高通设备都稳定适用？未必。理论范围和现实可用范围通常不同。(xdaforums.com)
4. 传播路径层它是一夜之间突然出现，还是早就被小圈子掌握？更像后者，公开爆发大概率晚于最初发现。
5. 生态影响层它只是一次 BL 绕过，还是会改写 Android Root / 越狱生态？我倾向于后者至少已经开始进入讨论区。

如果不把这几层拆开，就很容易在讨论里互相错位：

  • 有人拿“PoC 已公开”去证明“所有机型都能打”；
  • 有人拿“我擦了分区没事”去证明“这个分区没用”；
  • 有人拿“Google 月度补丁没写”去证明“厂商肯定还没修”；
  • 也有人拿“没被静默重锁”去证明“后续一定不会有影响”。

这些推断都太大了。

5）我更相信的一条传播链路：发现 → 私有变现 → 远程扩散 → 工具化 → 公开化

在没有官方复盘、也没有“最初发现者完整自述”的前提下，我认为目前最自洽的一条链路大概是这样的：

5.1 发现期：研究者先从公开架构和代码里闻到了味道

这一步很可能不是“误打误撞 fuzz 出来”的，而是有人先看懂了：

  • GBL 在 Android 新架构里的位置；
  • android_esp_a/b 这类分区的作用；
  • Verified Boot / device state / UEFI protocol 之间的关系；
  • 再加上具体厂商实现里的某个写入入口或边界条件。

于是，原本分散的几块知识第一次被人真正串成了一条可利用路径。

5.2 小圈验证期：先不公开，先确认稳定性、边界和商业价值

一条链路从“能用一次”到“能给别人做”，中间其实还差很多工程化工作：

  • 哪些机型可用；
  • 哪些版本不可用；
  • 哪些步骤必须本地做；
  • 哪些地方一旦失败会变砖；
  • 哪些状态改了以后还会不会回去。

这一步通常不会公开，因为太早公开既赚不到钱，也容易被厂商快速封死。

5.3 线下变现期：寄修、不拆机、黑盒服务

这一步反而非常符合现实。

因为在线下黑盒服务里：

  • 用户只能看到结果；
  • 看不到关键文件；
  • 看不到判断分支；
  • 看不到真正有价值的步骤；
  • 即使失败了，也更容易被包装成“个例”。

从商业上看，这比一开始做远程要安全得多。

5.4 远程扩散期：知道的人越来越多，泄露开始不可逆

一旦方法从“线下掌握”走向“远程操作”，泄露概率会指数上升：

  • 屏幕共享会暴露工具界面；
  • 命令执行会暴露文件名；
  • 日志窗口会暴露关键判断；
  • 用户自己也会开始复盘与传播。

这时候，原本靠信息差维持的商业护城河就会迅速坍塌。

5.5 工具化 / 公开化期：有人开始选择“拿名声”而不是“继续独占”

当知道的人足够多、价格足够卷、方法足够分散时，继续垄断它的收益会越来越低。

于是就容易走向两个方向：

  • 一部分人继续卖；
  • 另一部分人开始公开、开源、发工具、发截图、发视频，转而获取影响力、社区话语权或技术名声。

所以我更倾向于认为：

这次的公开爆发，并不是漏洞在这几天才第一次被发现，而是它经过了一段时间的小圈扩散后，终于跨过了“公开化阈值”。

6）厂商最可能怎么修：不是先“静默重锁”，而是先堵入口、再补链路

围绕这件事，大家最关心的两个问题其实是：

  1. 没解锁的人，会不会很快就被堵死？
  2. 已解锁的人，会不会被静默锁回去？

我的判断是：

6.1 对没解锁的人：高概率会很快被堵

因为这对厂商来说是最现实、最稳、成本最低的做法。

可能的修法大致有三层，从容易到困难：

  1. 先堵 Android 侧可写入口：把某个高权限服务、SELinux 策略、块设备写路径先收紧，让公开工具先失效。
  2. 再更新 GBL / ESP 内容：因为 AOSP 已经明确，GBL 是可更新组件，而且要通过更新整个 android_esp_${SLOT_SUFFIX} 分区完成。(source.android.com)
  3. 最后补状态一致性检查：让“通过异常路径写进去的状态”在后续启动或更新中被识别出来。

所以“二月补丁影响利用”这类说法，我认为大方向很可能是真的；只是更准确的说法应该是：

某些带着二月安全补丁标识的厂商 OTA，开始顺手收口这条链了。

而不是“Google 月度安全公告单独点名修了它”。Google 自己的公告也写得很清楚：并不是所有 partner / device 相关问题都必须体现在 Android Security Bulletin 的 patch level 声明里。(source.android.com)

6.2 对已解锁的人：我仍然更担心 OTA 收口，而不是云控静默重锁

我目前仍然没有看到一条足够可靠的公开资料，能证明厂商已经存在一套“云端实时、无感、批量把已解锁设备重新锁回去”的标准机制。

反过来，Android 官方文档对 lock / unlock 的标准路径描述得很清楚：

  • 解锁是 fastboot flashing unlock；
  • 状态会跨重启保持；
  • 上锁是 fastboot flashing lock；
  • 并伴随 reset；
  • critical section 的锁定状态切换不应允许纯程序化完成，而要有物理交互。(source.android.com)

这意味着，从标准合规设计上讲，“无感静默重锁”并不是一条自然路径。

当然，我不会说它绝对不可能。

因为如果某些第三方说法成立，厂商理论上也可以在修补后的启动链中加入更多状态校验或纠偏逻辑。但对厂商自己而言，这种操作风险很高：

  • 用户设备可能已经刷改；
  • 关键分区可能已经变化；
  • 直接改回 locked 容易引入校验冲突；
  • 甚至可能导致设备无法正常启动。

从工程现实看，“封洞、阻止新利用、检测异常状态、必要时拒绝某些升级”，通常比“偷偷把所有人锁回去”更像大厂会先做的事。

7）维术那篇文章里，有一个我很认同的判断：Android 真的开始有“越狱时代”的影子了

我觉得“越狱时代”这四个字，未必意味着 Android 以后会像当年 iPhone 那样，周期性出现全民级 jailbreak。

但它至少说明了一件事：

过去几年 Android 的改机生态，一直在被收缩；而这次事件第一次让很多人重新看到了另一条路径——不是去申请解锁资格，而是重新研究设备控制边界本身。

这是两个完全不同的方向。

前者是：

  • 在厂商允许的框架内争取自由。

后者是：

  • 重新定义这条框架本身。

当越来越多玩家开始从 BootLoader、Verified Boot、Root、KernelSU、LKM、越狱模式这些维度，把问题作为一个整体来思考时，Android 的“搞机文化”其实已经变了。

它不再只是“刷个类原生”“去个广告”“搞个模块”。

它重新变回了那个更本质的问题：

我是否真正拥有我手里的这台设备。

8）综合推演：最可能的链路是什么

在缺少厂商正式复盘的情况下，我目前认为最自洽的解释是这条：

flowchart TD
    A[公开架构与实现边界被研究] --> B[小圈验证利用链]
    B --> C[线下寄修与黑盒变现]
    C --> D[远程扩散与工具化]
    D --> E[PoC/脚本/截图公开]
    E --> F[厂商快速收口]

如果把“技术影响”和“生态影响”合在一起看，它带来的后续大概会是：

graph TD
    A[利用链公开]
    B[入口收紧]
    C[讨论升温]
    D[窗口关闭]
    E[边界重估]

    A --> B
    A --> C
    B --> D
    C --> E

它能同时解释三件事：

  1. 为什么这次事件会比普通“解锁教程”更有冲击力；
  2. 为什么它大概率不是这几天才第一次被发现；
  3. 为什么真正值得关注的，不只是“能不能解锁”，而是 Android 玩家生态是否正在迎来一次重新分层。

9）最后的判断：这是一次事故，也可能是一个分水岭

从安全角度看，这当然是事故。

因为任何能让启动链、锁状态、设备控制边界被非预期方式改写的路径，对普通用户都不是好消息。厂商快速修补，是正常且必要的。(source.android.com)

但从玩家生态看，它又不只是事故。

它像是一根针，扎破了过去几年那层越来越被默认接受的共识：

  • BootLoader 一定会越来越封闭；
  • Root 一定会越来越边缘；
  • 玩家只能在厂商给定的框架里苟活；
  • 设备控制权终究只是一个情怀概念。

至少在这一刻，这套共识出现了裂缝。

我不确定这会不会真的开启一个属于 Android 的“越狱时代”。
但我基本确定的是：

它已经让很多人重新开始认真思考，Android 用户和设备之间，到底应该是一种什么关系。

而这，可能比“又多了一种解锁方法”更重要。

参考来源（公开信息）

  1. AOSP：Generic Bootloader（GBL）overview。(source.android.com)
  2. AOSP：Deploy GBL。(source.android.com)
  3. AOSP：Lock and unlock the bootloader。(source.android.com)
  4. AOSP：Android Security Bulletins overview / February 2026 bulletin。(source.android.com)
  5. GitHub：hicode002/qualcomm_gbl_exploit_poc。(github.com)
  6. XDA 公开讨论线索。(xdaforums.com)

欢迎关注我的其它发布渠道