辰渊尘站

其一：IonStack#

CyberMeowfia 是安全研究团队 NebuSec 发布的内核漏洞利用 PoC 仓库，核心是 IonStack 漏洞利用链——一个无需解锁 bootloader 即可获取 Android 设备 root 权限的方案。

项目包含两个 CVE：CVE-2026-10702（浏览器入口）、CVE-2026-43499（内核提权）

我们本次用到的是 CVE-2026-43499（内核提权），利用 Linux 内核 futex PI（Priority Inheritance）机制的 stack-UAF（栈上释放后重用）漏洞。漏洞利用流程：

1. 触发 UAF：通过 FUTEX_WAIT_REQUEUE_PI + FUTEX_CMP_REQUEUE_PI 的竞态条件，制造 futex 死锁，导致内核栈被释放后仍被引用
2. 栈喷射控制：利用多种 syscall（prctl、setsockopt、pselect、process_vm_readv、keyctl、timerfd、futex）将可控数据喷射到被释放的内核栈上
3. pipe buffer 物理读写：通过伪造 pipe buffer 结构，获得对任意物理地址的读写能力（physrw）
4. KASLR 绕过：通过泄露内核代码段地址，计算内核基址偏移
5. 提权：修改进程 cred 结构体，将 uid/gid 设为 0，设置完整 capabilities
6. SELinux 禁用：将 selinux_enforcing 写为 0，关闭 SELinux
7. seccomp 绕过：清除 TIF_SECCOMP 标志和 no_new_privs，移除 seccomp 过滤器
8. 安装 su 守护进程：部署持久化的 root shell 守护进程

受影响设备极广，涵盖了15年来几乎所有内核版本且成功率极高

其二：高通 8e5 efisp 签名缺失#

这个漏洞来自高通骁龙 8 Elite Gen5（以下简称 8e5）的启动架构变更。

高通在 8e5 平台上引入了 GBL（Google Bootloader）取代传统的 ABL。GBL 是一个标准的 UEFI 应用（.efi），存储在 efisp 分区中。理论上 XBL（eXtensible Bootloader）在加载 efisp 分区内的 EFI 文件时，应该对其进行严格的数字签名校验——但实际并没有。

简单来说就是：

1. XBL 搭建好 UEFI 环境后，会挂载 efisp 分区并加载其中的 GBL
2. 正常情况下，XBL 应该用硬件里的 OEM 公钥验证 GBL 的签名
3. 但在 8e5 近期的特定固件分支中，这一步校验被跳过了
4. 这意味着我们可以把一个自己编写的未签名 EFI 应用刷入 efisp，XBL 照样会执行它

利用这个特性，我们编写一个简单的 UEFI 应用，通过高通的 QCOM_VERIFIEDBOOT_PROTOCOL 直接读取并修改 RPMB 中存储的 Bootloader 锁定状态，从而实现解锁。

完整的攻击链涉及四个阶段：

更详细的技术原理分析可以参考这篇文章：基于高通骁龙8 Elite Gen5架构的小米设备 Bootloader 解锁漏洞及底层技术原理剖析

前置条件#

• 搭载高通骁龙 8 Elite Gen5 的小米设备（小米 17 全系、K90 Pro Max 等）
• 已登录小米账号并开启”OEM 解锁”选项（开发者选项中）
• 电脑已安装 ADB 和 Fastboot 工具
• 已获取适配小米设备的 IonStack 漏洞利用编译产物（preload.so、su）

关于魔改 efisp#

我使用的不是原始的 PoC efisp，而是经过魔改的版本，加入了以下新特性：

步骤概要#

WARNING

以下步骤涉及刷写底层分区，操作不当可能导致设备变砖。请务必提前备份重要数据！

第一步：获取系统基本信息

连接设备，确认内核版本、当前槽位和解锁状态：

1
adb shell uname -vr
2
adb shell id
3
adb shell getprop | grep suffix
4
adb shell getprop | grep locked

第二步：IonStack 提权

将编译好的漏洞利用产物推送到设备并执行：

1
adb push source/build/bin/preload.so /data/local/tmp/preload.so
2
adb shell 'chmod 0644 /data/local/tmp/preload.so'
3
adb shell 'LD_PRELOAD=/data/local/tmp/preload.so /system/bin/true'

验证 root 是否获取成功：

1
adb shell '/data/local/tmp/su -c id'

如果输出 uid=0(root) 则说明提权成功。

NOTE

由于小米 6.12.23 内核使用 Rust 工具链，部分内存布局与官方 PoC 预设不同，利用过程中可能会有差异，属正常现象。

第三步：刷入旧版未修复 efisp 漏洞的 ABL

获取 root 后，先用 dd 命令覆盖当前 ABL 为旧版（保留 efisp 漏洞未修复的版本）：

1
adb push MI17P_abl-efisp/ABL_with_superfastboot.efi /sdcard/abl.img
2
su -c 'dd if=/data/media/0/abl.img of=/dev/block/by-name/abl_a(b)'

NOTE

槽位后缀（abl_a / abl_b）请根据第一步获取的 suffix 属性确定。

第四步：写入魔改 efisp

1
adb push MI17P_abl-efisp/efisp_superfastboot.img /sdcard/efisp_superfastboot.img
2
su -c 'dd if=/data/media/0/efisp_superfastboot.img of=/dev/block/by-name/efisp'

第五步：重启并解锁

写入完成后重启设备：

1
adb reboot

亮屏后等待1秒立即按住音量减键，进入 SuperFastboot 模式，然后执行：

1
fastboot flashing unlock

设备会自动重启进入系统。

第六步：验证解锁状态

系统开机后，BL 状态在系统层面依旧显示为锁定（这是内存伪装的效果），但实际已经解开。可以通过 Fastboot 验证：

1
adb reboot bootloader
2
fastboot getvar unlocked

如果输出 yes 则说明解锁成功。

后续操作#

解锁完成后就是常规流程了——用 Alpha Magisk、KernelSU、ReSukiSU 等管理器修补 init_boot 获取永久 Root 权限，这里不再赘述。

优势#

• 不清数据：不需要恢复出厂设置，所有数据保留
• 完美 TEE：可信执行环境正常工作，硬件级安全功能不受影响
• 不影响 Google 下发 keybox：Play Integrity / SafetyNet 正常通过
• 无需额外环境隐藏：不需要 Shamiko、Zygisk 之类的 BL 状态伪装模块
• 去除 OEM 解锁限制：不需要小米账号、不需要等待期

劣势#

• 不能修改带校验的分区：修改任何受 vb 校验的分区都会导致无法开机（变砖风险）
• 官方熔断风险：新版本固件如果熔断旧版 ABL 分区，当前方案将失效（数据飞走了）