前言

我于近日购入了一台 OnePlus 15T 12G+256G 抹茶绿版本。

本来都打算一辈子不用安卓手机了的，但是我不知道怎么鬼脑发力了就想买一个玩玩，于是在深思熟虑下选择了国内为数不多方便解锁 Bootloader 的机型。

初 Root

等待深度测试通过的时间令人煎熬，但一旦通过了就令人兴奋不已，可能比我更兴奋的是我的友人 Keritial。

#define 卡批 "Keritial"

通过的时间是凌晨，一刻没有为困意哀悼，电光火石间赶来的，是卡批对我手机的一顿操作，让我吃上了 KernelSU，Zygisk Next, LSPosed, etc.

我上次玩机的设备是小米 10（案底致歉），退坑时恰好赶上 KernelSU 刚刚兴起的时间，所以对这些东西了解不深，之前基本都只会在 Magisk 里修补 boot.img 然后刷入（btw 这也是我第一次用上有 a/b slot 的设备）。

赛博洁癖初现

我有很强的赛博洁癖，这是我转战 Apple 全家桶的一大动机，无法忍受国产厂商对于自己 ROM 的各种老牧师修改，而用 Pixel 的话，更无法忍受的是十八码的 SoC 性能。

虽然是以所谓“备用机“的名号购入的，但也不能不讲究。

之前玩机用的环境检测器一般是 Momo，我十分狼狈的没能让那个黄豆露出过舌头（雾），现在我将复仇。

卡批给我装了 Duck Detector，我也简单了解了一下，基本这就是目前 Android 设备环境检测最严厉的父亲了。

第一次打开满屏的红色，我也跟着红温了，这无疑唤起了我的折腾热情。

下面仅列出我遇到且能解决的问题，那么让我们来一条一条攻破吧。

击败！Duck Detector

Custom ROM

没什么好说的，我购入的机型不存在国际版本，自然也没什么人适配第三方 ROM，况且 ColorOS 16 也是国产厂商系统里最好用的一批了，我没有更换的理由，这一条没有不过的风险。

TEE & Play Integrity（Bootloader）

哦不不不不这无疑是最难通过的。

众所周知高通设备在解锁 Bootloader 后，TEE 会死掉（除了魔改了的小米），我在酷安搜索教程，一开始只看一个烧录 TEE，且是不可逆方案，这我无疑是不敢用的。

如果什么都不做的话，高通设备的 Soter Key, Attestation Key 大概率会死掉，Play Integrity 也会死掉，which is 苦臭disgusting。

卡批其实一开始 Root 就给我简单的修复了一下，使用 TrickyStore 加上未知来源泄露出的 keybox.xml，是可以通过玩正直（指 Play Integrity）的三个 MEETS 的，但是 Soter Key, Attestation Key 使用这个方法依旧无解。

我苦苦搜寻之下，终于找到了一个方案：伪回锁。

gbl_root_canoe 是一个基于 EDK2 的工作区，主要用于修补高通 ABL 内的 efi 程序。该项目利用 GBL (Generic Bootloader Loader) 漏洞注入自定义efi，其主要目的是在骁龙 8 Gen 5 / 8 Elite (Gen 5) 设备上实现假回锁（绕过 Bootloader 的解锁状态检测）。修补后的efi通常会被直接注入并刷入手机的 efisp 分区中。

幸运的是，我手上这台设备恰好搭载了 Snapdragon 8 Elite Gen 5，但不幸的是，ColorOS 在 16.0.7 版本之后修改了 abl，跳过了 efisp 分区的检查，半修复了该漏洞。

好在我们可以刷入旧版本的 abl 来暂时解决这个问题，只不过等到 ColorOS 17 出了之后还能不能好好继续使用老版本 abl 就不知道了。

（至少是 OnePlus 15T 用户）所要做的：

1. 获取 16.0.5.701 的 abl.img
2. 获取修改过的 efisp
3. 将 Step 1 获取的 abl.img 刷入你目前对应的 slot
4. 将 Step 2 获取的 ABLwithsuperfastboot.efi 更名为 ABLwithsuperfastboot.img，然后刷入 efisp 分区
5. 重启至 Recovery, 抹除 Data
6. 启动后，在拨号盘界面输入 *#899# 进入工程模式，查看 Key 状态，如为全绿则大功告成

接下来如果要 OTA，建议先在网络上搜寻 OTA 后伪回锁是否还能成功开机的案例，如果可以的话，你要做的就是

1. 将 KernelSU 安装至另一 slot
2. 将当前 slot 的 abl 复制到另一个 slot

这里有一个模块可以方便地帮你完成 Step 2。

完成了伪回锁后，你将不再需要使用 TrickyStore, Play Integrity Fix 等模块，也不需要寻找可用的 keybox，因为在系统看来你的设备现在是锁上的，Duck Detector 的 TEE 检测将会顺利通过。

Zygisk

无论你使用哪种 Zygisk 实现，都应当启用仅还原挂载并打开使用匿名内存。

HMA Style Concealment （Dangerous Apps）

当你使用 HMA / HMA-OSS(Zygisk) 时，可能会遇到的该问题。

Duck Detector 通过两种方式获取 Package List，并对比是否有所不同，它内置了一个 sus Apps 列表，像我就被检测出了 Storage Redirect 和 Hook Vip。

解决方案是使用 SuSFS，不过这个需要自定义的内核，这个见仁见智吧，有些人不是很喜欢 KernelSU 的 GKI 模式，不过我还是干了（

一加用户可以使用 WildKernels，其他机型可以自行搜索。

详细的安装步骤可以参考 Release 界面的 Installation Instruction，这里不再赘述。

唯一需要注意的是，如果你使用了伪回锁，由于 WildKernels 内置了 Baseband Guard（防止修改 Critical Partition 的东西），你需要在刷入 AnyKernel3 压缩包的时候注意他的提示，他会让你使用音量键将 abl, efisp 分区加入白名单。

2026/7/17 日更新：

这条检测实际大多使用了 Unicode ZWC 漏洞，可以尝试使用 FuseHide 模块来解决，应该不需要使用 SuSFS。

LSPosed

将你的模块加入 HMA Hidelist 里，确保不要有模块 hook 检测器。

SELinux

在 KernelSU 里阻止 App 检测 SELinux 的修改，永远不要将你的 SELinux 设为宽容。

System Properties

这一项会检测 USB 调试之类的设置，我不常用所以直接关了开发者模式。

2026/7/17 日更新：

7月15日的 Duck Detector 构建里合并了 feat(systemproperties): treat sys.oem_unlock_allowed as dangerous on B and higher 这个 PR，修改了检测 sys.oem_unlock_allowed 的行为。针对 Android 16+ 系统，如果检测到了 sys.oem_unlock_allowed 这个 property 则判为 Dangerous（btw 我觉得有点莫名其妙），而 Android 15 及以下的系统则是 sys.oem_unlock_allowed = 1 判定为 Dangerous。

某些系统行为比较诡异，这条 property 还存在于系统中，则可能会被误判（我也不知道能不能称为误判）。

可以通过以下方法来临时解决。

resetprop --delete sys.oem_unlock_allowed

我也特意写了一个模块，会在开机后自动执行：remove sys.oem_unlock_allowed.zip。

Written on macOS Golden Gate