从一加到小米：从「TEE 损坏」到「TEE 自身完备」
长官，我是小米人
原本我其实更偏向一加。
原因很简单：一加的 BootLoader 解锁一直相对省心。对我这种本来就喜欢折腾系统的人来说，设备能不能顺利解锁，几乎会直接影响购买意愿。
反过来看，小米这几年在解锁上的门槛确实高了不少：
- 要申请
- 要等待
- 甚至还要小米高考
对只想折腾系统的人来说，这套流程多少有点劝退。所以一开始，我其实是打算继续买一加的。
结果后来情况变了。
小米这边突然爆出了新的解锁漏洞，相当于把原本最麻烦的门槛直接绕过去了。再加上这一代机器价格确实很香，3899 拿下旗舰机，几个因素叠加下来，我最后还是入手了 Xiaomi 17 标准版 16+512。
关于漏洞细节，可以去看 3.8 解锁节漏洞解析深度解析小米 8e5 系列漏洞解锁 BL 原理。
准备动作
我最后选的是酷安上 白羊唐黎明 的官改 ROM，版本是：3.0.301.0
这个包并不是直接拿来刷就行，它需要配合指定的官方底包：3.0.44.0
所以整套流程的第一步，不是直接梭哈官改，而是先把官方底包刷进去。
和一加类似，一加那边阿木大侠维护了一个一加 ROM 站，可以直接检索下载一加的 ROM，小米这边也有 ，可以快速检索 ROM。
刷机工具选择的是 MiFlash，看起来足够简单？ MiFlash 本身是 Windows 下的线刷工具，常见做法就是搭配 Fastboot 固件 使用。它也自带一些驱动，正常情况下装好后就能直接识别设备。
不过这里有个我自己踩过的坑，必须单独提一下：
MiFlash 最好放在中文 Windows 环境下运行。
如果你用的是其他非 ZH-CN 的语言环境，可能会碰到一些莫名其妙的报错。表面上看像是驱动问题、路径问题，甚至像底包有问题，结果最后一排查，根源其实是环境。所以如果你想尽量少走弯路，直接在中文环境下操作会省事很多。当时我甚至都开始怀疑 mirom 下载的包有问题了。
刷官方底包
先把下载好的 Fastboot 线刷包 解压到任意目录。
然后让手机进入 BootLoader。
这一点我想刻意讲清楚，因为很多文章喜欢笼统地写“进入 Fastboot 模式”，但这个说法其实非常模糊，如果是一加转小米，更容易把人带偏。
在小米设备上：
adb reboot bootloader如果不用命令，也可以关机后按住：音量下 + 电源键 进入 BootLoader 界面。
之所以要写得这么细，还有另一个原因：不同厂商对“Fastboot”这个词的使用场景并不一致。比如在一加上， Recovery / fastbootd 界面里本身也能刷 Fastboot 包，所以“Fastboot”这个词本来就不够精确，因为存在用户态的 Fastboot -> Fastbootd，也存在解锁后的 BootLoader Fastboot。统一叫 BootLoader，反而最不会出歧义。
进入之后，打开 MiFlash，流程很标准：
- 点击 Driver 安装驱动
- 点击 刷新设备，确认手机已经被识别
- 选择刚刚解压好的底包目录
这里最关键的一步一定要记住：
如果这里手滑回锁，会变得麻烦，你还得重新利用漏洞解锁，44 版本还好，还可以利用漏洞解锁。
不得不提 miflash 的默认选项真的有点大病。
这里还要额外提醒一个非常关键的点。 官改版本是 3.0.301.0，而这个版本对应的 Android 安全补丁级别是 2026-02-01。这个补丁已经修复了骁龙 8e5 的漏洞利用。也就是说： 一旦你在这个版本上执行回锁，后面基本就没法再用这条漏洞路线重新解锁了。
这不是简单的“麻烦一点”，而是真有可能直接把后路堵死。如果你真的想回锁了，出于保留退路的考虑，建议是走降级回锁这条路，永不更新，这样才还有继续解锁的机会，所以这一步千万不要心存侥幸。
确认没问题之后，点击 Flash，接下来耐心等它刷完即可。
刷官改 ROM
底包刷完后，先让手机正常开机。快速走完初始化流程，确认都没问题之后，再重新进入 BootLoader，把官改包解压出来。
如果包里附带驱动，那就先把驱动装一下。接着一般直接双击它自带的刷机脚本，剩下的就是等进度条跑完、手机自动重启。
到这里，官改 ROM 基本就刷好了。
Root：我选择了SukiSU-Ultra
官改包里其实自带了 KernelSU，但我没有沿用这一套。我选择的是 SukiSU-Ultra。 至于原因，其实非常朴素：主要是 SukiSU-Ultra 的图标好看，没别的。
我的做法也很直接：
- 从官改包里拿出来
init_boot.img，adb push 到手机里面 - 让 SukiSU-Ultra 对 init-boot 进行修补
- 把修补后的镜像刷回设备
- 直接切换到 SukiSU-Ultra
刷入命令是
adb reboot bootloader
fastboot flash init_boot_ab .\kernelsu_patched_20260314_152108.imgRoot 定下来之后，后面的模块环境就比较清晰了。Meta Module 用的是 Hybrid Mount。
这种东西平时不一定最显眼，但底层挂载方案其实会直接影响整体体验，所以我这里干脆一步到位，直接用了它。
Play 完整性与环境处理：TEE 模拟器组合拳
这一部分，我最后采用的组合是：
- ZygiskNext
- TEE Simulator
- Integrity-Box
项目地址：
- ZygiskNext：https://github.com/Dr-TSNG/ZygiskNext
- Integrity-Box：https://github.com/MeowDump/Integrity-Box
- TEE Simulator：https://github.com/JingMatrix/TEESimulator
为什么不用 Tricky Store
原因很简单：Tricky Store 现在已经闭源了。 对我来说，这就不再是最优选。
而且从 Integrity-Box 的项目说明来看，它本身的前置条件就是：
- Official Tricky Store / TEE Simulator 二选一
- ZygiskNext / ReZygisk 二选一
所以我的选择非常明确： ZygiskNext + TEE Simulator + Integrity-Box
模块刷入顺序
我的顺序是：
- ZygiskNext
- TEE Simulator
- Integrity-Box
刷完之后重启即可。
顺带一提，ZygiskNext 本身的定位也很明确：它是 Zygisk 的独立实现，主要给 KernelSU 等环境提供 Zygisk API 支持，用来替代 Magisk 内置的 Zygisk。这一点对于后面整套模块的兼容性很关键。
而 Integrity-Box 则更像是一个总控型工具：既管 Play Integrity，也管 Keybox 实现，还会处理 target、keybox、认证状态、系统清理等一整套东西。它自己 README 里写得也很直白，本质上就是一个 Play Integrity 与系统环境管理工具箱。
关于 TS 模块的 WebUI，我选择了 Tricky Addon Enhanced，因为它能自动把新安装的 App 添加到 TEE Simulator 的 Target 中，避免我去手动设置。
TEE 完整
如果只看表面，这一套主要解决的是这些问题：
- Play 完整性
- 系统环境信号
- Root 隐藏
- 应用对 BootLoader 解锁状态的检测
但如果只把重点放在“能不能过完整性”，其实还不够。对我来说，这次折腾里真正有意思的地方反而是：TEE 本身是不是完整的
以前在一加上，BootLoader 解锁之后经常会碰到一个很典型的问题：TEE 损坏 这是高通给的机制，解锁 BL 以后 TEE 假死，OPPO 的做法是切换密钥槽，这个槽的密钥不完整，三星就更离谱，直接熔断，没办法玩，小米比较特殊，魔改了 TEE 是 miTEE，解锁后不掉。
系统当然还是能刷，Root 当然也还能做，甚至可以折腾得很深。但底层信任链一旦断掉，很多事情就总有种“补出来的感觉”。
这次换到小米上，用我现在这套方案之后，最让我满意的点反而不是“完整性能不能过”，而是：TEE 本身就是完整的
这件事对我来说，比单纯看到几项检测变绿更有意义。 也正因为这样，这篇文章标题里写的 “从 TEE 损坏到 TEE 自身完整可用”，其实比“刷机成功”更接近我这次折腾真正想表达的东西。
HyperCeiler
好像叫做西米露？这个我也很喜欢，定位上有点像 ColorOS 的 Lucky Tool，但我自己会更偏向它一点；这样说有点倒反天罡，应该是先有西米露，后有 Lucky Tool 类似的工具。
它主要是拿来改：
- 系统行为
- 界面逻辑
- 细节设置
属于那种刷完之后基本会第一时间装上的工具。
总结：为什么我执着于「TEE 完整」
这次折腾下来，我始终在意的一件事，其实不是“检测能不能过”，而是：TEE 本身到底是不是完整的。很多人玩 Root、模块和完整性环境，最终目标往往很明确： 把各种检测绕过去。 比如：
- Play Integrity 过了
- 国内银行 App 能正常打开
- 国内钱包功能可以使用
对不少人来说，只要结果达成，中间到底是怎么实现的，并没有那么重要。但这是一场猫捉老鼠的游戏，检测与绕过是一直在对抗的。我这次更在意的，反而是另一件事：TEE 到底是真实可信，还是只是伪装出来的。
原因也很简单：Android 的信任体系，正在发生变化。
本地 Keybox 的时代，正在结束
以前 Android 设备的硬件认证，在很大程度上依赖 本地 Keybox。
设备出厂时，会在 TEE 中写入一组密钥。当应用发起 硬件级 Attestation 时，TEE 就会使用这些 Keybox Key 来签名并证明一些关键信息，例如：
- 设备型号
- Boot 状态
- Verified Boot 状态
- 系统完整性
所以过去很多“过检测”的方案，本质上都是这一套思路：
拿到泄露的 Keybox
↓
导入到设备
↓
伪装成官方设备这一套在过去几年里确实非常流行，也确实有效。但问题同样很明显：对于 Google 来说，Keybox 一旦泄露，就很难彻底回收。
如果 Google 想吊销某个泄露的 Keybox，整个流程其实很复杂：
- 收集泄露证据（报告给对应的 OEM，说明有吊销的必要性）
- 更新吊销列表
- 推送到系统组件
- 等设备更新生效
这个过程周期很长，而且很难做到真正实时。也正因为如此，Google 一直在推进本地 Keybox 信任到云端的 RKP 信任
Google 正在全面转向 RKP
现在 Google 正在逐步推进新的体系：Android Remote Key Provisioning（RKP）
RKP 的核心思路很直接： 设备不再长期持有 Attestation Key，而是改为通过 Google 云端动态下发。
简化后的流程大致是这样：
设备 TEE
↓
向 Google RKP 服务请求 Attestation Key
↓
Google 下发短期证书
↓
TEE 使用该证书完成硬件 Attestation这里有两个非常关键的变化。
1. 证书是短期的
RKP 下发的不是长期固定证书，而是短期证书。典型有效期通常只有：两周。到期之后，设备需要重新向云端申请新的证书。
2. Google 可以更快吊销
如果 Google 发现某个设备密钥泄露、异常，或者某条链路存在风险，那么它不再需要沿用过去那套笨重的 Keybox 吊销流程。它只需要在云端：吊销对应设备的 Attestation Key。这样一来，设备去做 TEE Challenge 请求的时候，直接认定是失败。
这对“伪装方案”意味着什么
这件事带来的变化，其实已经非常明显了。过去的逻辑大概是：
泄露 Keybox
↓
导入设备
↓
长期稳定使用而未来更可能变成：
没有 Google 云端签发的有效 Attestation Key
↓
硬件认证直接失败换句话说： 依赖泄露 Keybox 来伪装 TEE、伪装官方设备的路线，未来只会越来越难走。
过去那种“拿到一套东西，导进去，长期稳定骗过检测”的思路，在新体系下未必还能持续成立。
我在 OnePlus 上遇到过的真实情况
这一点，其实我在 OnePlus 上已经切身遇到过了。
有时候即使你已经做到这些：
- Play Integrity 全绿
- 环境隐藏得很彻底
- Root 检测基本全部绕过
Google Wallet 依然有可能识别出设备状态异常。
最典型的提示通常就是：
This device doesn't meet security requirements也就是说，哪怕系统层面的环境已经“看起来很干净”，Wallet 依然可能判断这台设备没有通过官方安全认证。
类似的问题，在一些海外银行 App 上也能看到。
甚至还有一种说法是：抖音的设备安全检测级别非常高。一些逆向分析的结论甚至认为，抖音在设备检测上的强度，可能还高于部分银行 App。
当然，具体实现细节外界很难完全确认，但有一点基本可以确定： 越来越多的 App，正在直接依赖硬件 Attestation 的结果。
这意味着，单纯“把表层环境伪装干净”，未来未必还够。
为什么我更在意「TEE 本身完整」
也正因为这样，这次我在小米上的思路，其实和以前不太一样。我不太想继续走这种路线：
伪造环境
↓
伪造 Key
↓
尽量骗过检测我更希望做到的是：
TEE 本身完整
↓
硬件 Attestation 正常
↓
系统只是 Root换句话说就是：Soter Key 是正常的，能够正常使用 WeChat Pay 的指纹，而并非使用模块代替输入密码
这也是为什么这篇文章标题里，我会专门写一句：从「TEE 损坏」到「TEE 自身完备」
对我来说，这比单纯“过了完整性检测”更有意义。
因为如果未来 Android 的认证体系继续全面转向 RKP，那么现在很多流行的绕过方式，迟早都可能逐渐失效。
而真正更稳定、也更有长期价值的方案，往往反而是最朴素的那一种：
- 设备本身可信
- TEE 完整
- 信任链存在
至于剩下的折腾，无非只是系统层面的修改而已。