最近折腾了一台 Redmi K80 标准版，目标很明确：解锁 Bootloader（引导加载程序），用 KernelSU（内核级超级用户权限方案）取得 Root（超级用户权限），再处理解锁和 Root 留下的环境痕迹。

网上每一段都有教程，真正麻烦的是把它们连起来：解开 BL 不等于取得 Root，取得 Root 也不等于银行、办公和游戏类应用还能正常运行。应用列表、存储目录、挂载状态和设备完整性证明，实际上是几套不同的问题。

这篇记录我已经走通的部分，也把仍未验证的部分单独留下。它不是适用于所有 K80 的通用教程，更不适合不清楚救砖流程的人照抄。

先说风险

• 本文实测设备为 Redmi K80 标准版，系统版本为 OS2.0.109.0.VOKCNXM。机型、固件和工具版本不同，结果可能完全不同。
• 解锁会清除手机数据，并可能带来无法开机、失去部分安全能力、影响保修或后续升级的问题。动手前必须完整备份。
• 强解依赖特定版本的漏洞窗口。不要因为本文成功，就在更新后的系统上盲目尝试，也不要随意 OTA（在线系统更新）。
• 环境检测没有“全绿即绝对安全”的结论。本文只记录自有设备上的兼容性调试，不代表任何应用都会放行。

1 这次使用的设备环境

这几个信息必须放在一起看。尤其是系统版本，同一台 K80 在不同安全补丁下，能否使用同一套解锁方法并没有保证。

2 先理清三件事：解 BL、Root 和环境隐藏

可以先用一句话区分：

1
2
3

解锁 Bootloader：允许设备启动经过修改的镜像
KernelSU Root：由内核决定哪些应用可以取得最高权限
环境隐藏：分别处理应用、文件、挂载和完整性证明留下的痕迹

Android 底层使用 Linux 内核，root 对应 UID 0 的超级用户。普通应用被限制在各自的沙箱里；取得 Root 后，经过授权的程序可以读取或修改原本无法访问的系统资源。

这带来了冻结预装应用、控制后台行为、备份应用数据和使用系统增强模块等能力，也会放大误操作与恶意软件的风险。错误的镜像或不兼容模块可能让设备卡在开机画面；给错应用 Root 权限，则相当于主动拆掉 Android 原有的隔离边界。

KernelSU 与传统的用户空间提权方案不同，它在 Linux 内核侧管理授权。但“权限入口更靠近内核”不等于设备从此没有痕迹。检测方仍可能从包名、目录、挂载点、注入框架和硬件证明等多个维度判断设备状态。

3 解锁 Bootloader：我走通的是特定版本方案

这部分主要参考了「一碗饭」的 Redmi K80 8Gen3 强解 BL 锁 + 刷入 KernelSU 经历，实际使用的是莫离然然维护的 Xiaomi-QC 工具和搞机工具箱。

• 莫离然然酷安主页
• 莫离然然资源站

公开社区在 2026 年集中出现了几套高通平台引导链研究与自动化工具，因此很多机友把这段时间称为“大解锁时代”。相关项目包括：

• gbl-chainload
• gbl_root_canoe
• Mi8E5-Unlocker-by-CVE-2026-43499

这些项目能说明社区确实在研究 GBL、UEFI 引导组件和特定漏洞链，但不能据此断言所有工具都使用完全相同的实现，也不能把社区对封堵版本的判断当成厂商正式说明。对普通用户而言，最有用的结论仍然是：强解高度依赖机型和固件版本。

3.1 我准备的文件

当时选择的是工具中的方案 1，也就是面向较早固件的方案。电脑上提前准备了：

1
2
3
4
5

K80 官方 Fastboot 完整线刷包：
zorn_images_OS2.0.109.0.VOKCNXM_20250409.0000.00_15.0_cn_6aaae94dd7.tgz

机型专用工程小包：
Redmi_K80工程小包-已测试-用于解锁BL

工具执行过程中会多次重启设备，并在不同阶段要求选择官方包和工程小包中的 boot.img。两个文件同名但用途不同，选错镜像可能直接导致启动失败，所以每次都要按界面提示确认来源。

我没有把工具的按钮顺序写成固定流程，因为这类工具更新很快，旧版界面和新版不一定一致。这里真正需要记住的是：

1. 先核对设备代号与完整版本号；
2. 准备对应版本的完整线刷包和机型专用小包；
3. 备份数据并确保电脑供电、数据线和驱动稳定；
4. 严格按当前工具提示选择镜像，不混用其他机型文件；
5. 解锁完成后，先确认设备能正常进入系统，再继续 Root。

解锁成功后，Bootloader 状态会从 Locked（已锁定）变成 Unlocked（已解锁），同时设备通常会清除数据。这一步只是打开了启动修改镜像的入口，还没有取得 Root 权限。

4 刷入 KernelSU：这次使用 LKM 模式

Root 部分仍使用莫离然然搞机工具箱。当时的选择是：

1
2

KernelSU 原版 3.x
└── LKM

完成后安装 KernelSU Manager，管理器显示版本 32601-2、模式为 LKM、内核为 6.1.75。到这里，“K80 解 BL + KernelSU Root”这一段才算完成。

LKM 是 Loadable Kernel Module（可加载内核模块）的缩写。它与直接写入内核镜像的 GKI（通用内核镜像）方案不是一回事，后续刷模块、升级系统或更换内核时不能混着理解。

Root 完成后，我先遵守了两个最基本的规则：

• KernelSU 只给确实需要的应用授权，不做全局放行；
• 每次只新增一个模块，确认能开机并观察一段时间后再继续。

5 为什么 Root 后还要处理环境兼容

应用检测设备状态时，常见信号大致可以分为四层：

我最初把这些都叫作“Root 隐藏”，后来才发现它们互不替代。应用列表藏住了，不代表存储目录没有泄露；本地检测没有明显异常，也不代表服务器侧的完整性证明能够通过。

5.1 一键隐藏包只是起点

刚完成 Root 时，我参考了“传说中的小菜叶”的一键隐藏方案：

• 传说中的小菜叶博客

后来才知道社区里还有“月虹”等整合方案：

• 月虹个人分享页

我当时选择小菜叶没有复杂原因，只是手边教程使用了这套方案，实际也能完成基础配置。整合包的价值是降低首次配置门槛，但其中包含哪些模块、怎样设置作用域，应以使用时的发布说明为准。工具升级后组合会变，不能拿某个版本的模块清单去推断所有版本。

对新手而言，一键包最容易造成的误解是“运行成功就全部隐藏完成”。实际上，模块冲突、作用域错误和规则过期都很常见。刷完以后仍然需要知道每一层在处理什么，并逐项验证。

6 HMA-OSS：控制目标应用能看到什么

HMA-OSS 用来限制目标应用查询已安装应用列表。它可以让某个应用看不到 KernelSU Manager、LSPosed 和其他敏感工具，因此属于应用列表隐藏层。

它处理的是“目标应用能否通过包管理和相关接口发现某个应用”，并不负责处理文件系统、挂载点或硬件证明。配置时也不应简单套用全局模板，应先确定哪些目标应用确实需要隔离，再检查隐藏规则是否生效。

7 FuseFixer：处理存储目录侧信道

即使 HMA-OSS 已经藏住某个包名，检测器仍可能尝试访问类似目录：

1

/storage/emulated/0/Android/data/xxx.xxx.xxx/

如果目录探测结果暴露了敏感应用的存在，应用列表隐藏就会被绕开。FuseFixer 处理的正是这类存储侧信道。

可以粗略记成：

1
2

HMA-OSS：控制应用列表查询结果
FuseFixer：处理外部存储目录探测

我在实测中还遇到一个问题：把春秋 Native Check 加进 FuseFixer 作用域后，春秋会闪退。取消错误作用域后恢复正常。因此不要因为某个应用是检测器，就把它加入所有模块的作用域；应按模块文档和实际问题配置。

8 用多款检测器交叉观察

环境隐藏不能只看某一个应用顶部的“正常”或“异常”。不同工具检查的信号不同，同一工具的综合结论也可能受规则、网络和扫描时机影响。我使用了下面几类工具交叉观察：

8.1 春秋 Native Check

春秋覆盖原生进程、挂载、注入和文件系统等多个维度，是我使用的主检测器。出现具体检测项时，可以参考社区维护的 春秋检测问题排查仓库 和 在线文档。这份资料来自社区测试与整理，并非春秋源码说明。

8.2 DuckDetector

DuckDetector 是开源的 Android 环境完整性检测工具，覆盖 Root、Hook、Bootloader、SELinux、虚拟化和证明状态等信号。它适合作为春秋之外的交叉样本，但检测到痕迹并不等于某个实际应用必然拒绝运行。

8.3 其他检测器

• Native Test++（原生层环境检测工具）：用于观察 Native 运行时、动态库注入和 Hook 痕迹；
• Momo（经典 Root 检测工具）：更适合作为历史基准和辅助验证；
• App List Detector（应用列表检测工具）：专门检查 HMA 规则能否挡住不同方式的应用查询；
• Hunter（综合环境检测工具）：覆盖 Root、Hook、Xposed、Frida 和 ROM 环境等指标。

Hunter 在同一套环境下曾出现综合结论波动：有时显示正常设备，刷新后又显示黑灰产设备。因此我更关注展开后的具体检测项，不把顶部标签当作最终结论。这一波动的原因目前还没有通过日志定位。

9 Keybox 与 Play Integrity：暂时不能写成已完成

本地痕迹处理之外，还有 Android Keystore、KeyMint、TEE 和 Key Attestation（密钥证明）等硬件安全机制。Bootloader 解锁后，设备在完整性证明中可能反映当前状态，这不是 HMA 或 FuseFixer 能解决的问题。

社区里常见的几个名词：

1
2
3
4
5

Tricky Store
keybox.xml
Play Integrity Fix
Key Attestation
RKP

它们都和设备如何向本地应用或远端服务证明自身状态有关。Keybox（密钥盒）可以简单理解为证明过程中使用的一组密钥与证书链，但它不是“Root 后去申请一个手机密钥”这么简单，也不应使用来源不明或泄露的证书材料。

我目前还没有独立核对以下项目：

• 当前 Tricky Store 的实际配置；
• 是否已经存在并使用 keybox.xml；
• Play Integrity 各项检测结果；
• Key Attestation 的实际返回状态。

因此，这一层只保留概念和待验证项，不把它写成已经通过。

10 Root 之后的功能扩展

完成基础环境后，我还安装了两类环境模拟工具：

• LocationSpoofer：可针对单独应用模拟定位，并集成 Wi-Fi、蓝牙和基站等方案；
• Xfly：更侧重模拟 SSID、BSSID、MAC 和 Wi-Fi 扫描结果。

这已经属于 Root 后的功能扩展，不是 K80 解锁和 Root 的必要步骤，后续另开文章记录。

11 最后把整条链路画清楚

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

Redmi K80（特定固件）
│
├── 解锁 Bootloader
│
├── KernelSU Root（LKM）
│
├── 本地环境兼容
│   ├── HMA-OSS：应用列表
│   ├── FuseFixer：存储目录侧信道
│   └── Root、挂载与注入痕迹
│
├── 完整性证明（尚未完成验证）
│   ├── Tricky Store
│   ├── Keybox
│   └── Play Integrity / Key Attestation
│
├── 交叉检测
│   ├── 春秋 Native Check
│   ├── DuckDetector
│   ├── Native Test++ / Momo
│   └── App List Detector / Hunter
│
└── Root 后功能扩展
    ├── LSPosed
    ├── LocationSpoofer
    └── Xfly

折腾完这一轮，我最大的收获不是“终于把检测器刷绿”，而是分清了这些工具各自在解决什么问题。解 BL、Root、隐藏应用列表、处理存储侧信道和完整性证明是五件事。只有先把层次理顺，出现异常时才知道应该检查哪里，也不会因为某个检测器的一次结果就盲目增删模块。

这篇先记录到当前稳定状态。后续只有在补齐实际截图、模块版本、Play Integrity 与 Key Attestation 结果后，我才会把对应部分更新为可复现的实测结论。