2025年底的安卓搞机备忘录

　　在云服务高度绑定、系统权限不断收紧、厂商深度定制愈发封闭的今天，解锁 Bootloader、Root、刷 Rom 这些曾经被视为 Android 精神内核的操作，正在逐渐从“折腾的乐趣”变成“高风险行为”。马上 2026 年了已于2026年9月更新，你还在玩 Android 机吗？

更新记录

  • 2026-09-02： 修正 TrickyStore 的拼写； JingMatrix 版 LSPosed 仓库已改名为 Vector； HMA-OSS 从 LSPosed 模块改为 Zygisk 模块； TrickyStore + Play Integrity Fork 的双模块组合改为 AlwaysStrong 单模块； TS Enhancer Extreme 已改名 FS-Enhancer-Extreme； 补充 Zygisk Next、KernelSU、APatch 的版本现状与几个检测 APP 的维护状态。
  • 2025-12-28： 初版发布。

环境隐藏/过检测

　　随着 Android 应用安全策略的持续收紧，解锁 Bootloader 或获取 Root 权限的设备，越来越容易被各类应用识别为“高风险运行环境”。常见受影响的应用类型包括但不限于银行、支付、购物、外卖及即时通讯类应用。在检测到异常运行环境后，不同应用可能采取不同处理策略，包括但不限于：

  • 弹窗提示风险
  • 应用强制退出（闪退）
  • 功能受限或账号触发风控机制

　　可以说，当今时代，如果你的手机解锁了 Bootloader 或者刷了自定义的 ROM，想要用它作为主力机来使用， 环境隐藏可能是你绕不开的话题。
　　在实际使用中，Alliot 早期使用的基于 Delta Magisk（Kitsune）的环境隐藏方案已长期未更新，部分银行类应用开始提示运行环境风险并拒绝启动。为满足日常使用需求，Alliot 对当前主流 Android 运行环境隐藏方案进行了调研与实践验证，下文对相关结论进行整理说明。

root方案选择

　　现在的 Root 方案主要分为 Magisk 面具阵营与内核 root 阵营（APatch, KernelSU, SukiSU），内核级 Root 隐藏能力更强（简单测试了一下, SukiSU应该是当前(2025-12)隐藏能力最强的）
　　2026-09 补充： 内核 root 阵营这半年迭代不慢， KernelSU 已到 v3.3.0（2026-08），APatch 为 11224（2026-08），SukiSU-Ultra 也仍在活跃维护。 上面“隐藏能力最强”是 2025-12 的测试结论，本次没有重新验证。

　　由于我个人不玩手机游戏，测试下来 alpha Magisk 已经能够满足我对日常使用的 APP 隐藏环境了， 加上我自己写的一些模块暂时也懒得去适配 ksu， 因此本文就以 alpha Magisk 为例。

注意： 当前 alpha Magisk 并没有开源，使用前需自行评估来源可信度及潜在风险。 作者的发布渠道是 蓝奏盘 与 T*群

面具模块列表

　　这些模块比较推荐安装：

  • Zygisk Next: 为复杂 Root 对抗场景设计的“更强、更隐蔽、更兼容”的 Zygisk 注入框架，用来解决原生 Zygisk 在新系统和高强度检测下的不足。 简单来说，原生 Zygisk 在新系统和高强度检测场景下更容易被识别，当前更推荐使用该方案。 装它的同时要把 Magisk 内建的 Zygisk 关掉（zygisk=0），否则冲突。 当前版本 v1.5.0（2026-08-26）。

    • 升级只看 GitHub Releases： 模块 updateJson 指向的 lsposed.zip 更新源里 versionCode 长期滞后，在 Magisk 里查更新会一直看不到新版本。
    • 同类实现还有 NeoZygisk（v2.4，2026-08）与 ReZygisk（v1.0.0，2026-05）， 但同时只能装一个： 依赖 Zygisk 的模块（例如 HMA-OSS）在安装时会检查框架数量，发现多个会直接中止安装。

  • AlwaysStrong: 用于修复或伪装系统关键安全组件状态，在 Bootloader、TEE 及完整性校验相关检测中具有重要作用。 它是 TrickyStore 路线的整合版，自述为 “TEESimulator-RS + PlayIntegrityFork bundled”： 模块 id 仍然是 tricky_store，配置路径也还是 /data/adb/tricky_store/{target.txt,keybox.xml}，旧配置可以直接沿用。 装了它就不要再单独装 Play Integrity Fork 和 TS/FS Enhancer，功能重复。 当前版本 v1.0.3（2026-08）。

    • 原版 TrickyStore 最后一次发布是 1.4.1（2025-11），最后一次提交 2025-11-30，已长期没有动作； 如果你仍在用原版，配套的增强模块是 FS-Enhancer-Extreme（原名 TS-Enhancer-Extreme，仓库已改名）。
    • Play Integrity Fork 本身仍在活跃维护（v18，2026-08），单独用没问题： 部分应用（比如 谷歌钱包、ChatGPT 等客户端）要求完整性校验至少通过基础完整性与设备完整性两项。 顺带一提，原版 chiteroman/PlayIntegrityFix 仓库已经删库，osm0sis 的 fork 就是现在的主线。
    • keystore 相关： AlwaysStrong 自带 keybox_fetch.sh / autopif.sh 会自动拉取，security_patch.txt 支持写 all=YYYY-MM-DD 统一伪装补丁级别。

  • Vector: 即原来的 LSPosed-JingMatrix 版本，仓库已改名为 Vector（旧链接会重定向）。 原 LSPosed 已转为内测发布，Vector 是仍在维护的开源分支，移除了一些容易被检测的实现细节，当前稳定性表现良好。 它现在以 Zygisk 模块的形式安装（模块 id zygisk_vector，需要上面的 Zygisk 框架托底），数据仍在 /data/adb/lspd，对模块暴露的还是 LSPosed 兼容 API。 稳定版 v2.2（2026-08），另有 canary 通道。

  • HMA-OSS: 必装。 原 HideMyApplist 的 OSS 版本，部分(或者说绝大部分国产)APP会读取你手机的应用列表，用于风控或其他目的，这个模块用于对特定的APP隐藏特定的已安装应用，达到防止检测的目的。 这个 OSS 版本预置了一些规则模板， 可以自行选用。 最好的还是自己配置黑名单模板，将一些 Root 与玩机相关的 APP 加入， 给部分敏感应用应用模板。

    • 它已经不是 LSPosed 模块了： 现在发布的是 Zygisk 模块（资产名形如 HMA-OSS-ZYGISK-<版本>-release.zip，模块 id hma_oss_zygisk，只注入 system_server），所以刷在面具里而不是装在 Vector 里。
    • 从旧版迁移不用手动搬配置： 模块 zip 内置管理 APP 并自动覆盖安装（签名与旧版一致，原地升级），服务启动时会扫描 /data/misc 下任意 hide_my_applist* 目录复用原有 config.json； 新版 APK 不再声明 xposedmodule，装好后它会自动从 Vector 的模块列表里消失。
    • 不要停留在 oss-135 及更早版本： 那些版本的无障碍 hook 会把返回值无条件包成 ParceledListSlice，在 MIUI 14 / Android 13 上与框架签名不匹配，风控类 APP 一查无障碍服务列表就会打崩 system_server，表现为手机自己“重启”。

可选模块，可以按需安装:

Xposed（Vector）模块

　　HMA-OSS 原本放在这一节， 它从 2026 年起改为 Zygisk 模块，已经挪到上面的面具模块列表。 这一节现在没有环境隐藏相关的必装项， Vector 里装什么按自己需求来即可。

环境检测APP

　　配置好上述环境后， 可以用下面的一些环境检测APP来测试一下效果， 这些APP模拟了市面上大部分APP检测环境的逻辑， 具备一定的参考价值。
当然，各家 APP 检测的点都不一样， 这些检测 APP 的结果也只够参考，检测过了不代表你用的APP检测不到，同理，检测没过也不一定代表你用的APP就用不了。

  • APPlist Detector: 顾名思义，检测应用列表。 仓库自 2023-10-31 起没有新提交，久未更新，检测逻辑相对老旧，参考价值有限
  • Momo: 检测 Root, Rom
  • Riru: 检测 Root, XPosed
  • TB Checker: 比较全面，包含了 Root, XPosed, Play Integrity, SafetyNet 检测
  • Hunter: 看雪论坛的一位专业做这块大佬做的检测Demo，检测内容也很全面，暂时没找到集中发布的地址，当前(2025-12)手上找到的是 6.52版本。
  • Integrity Checker: 谷歌完整性检测，通常大家说的三绿就是这个APP的三项检测都是绿色通过。这个APP必须自己从谷歌应用商店下载，检测出的结果才有效， 切记。
  • Native Detector: 检测 Root

常见的检测点

  • Bootloader 解锁： 弱检测 alpha Magisk 通常可直接应对， 强检测需结合 AlwaysStrong（TrickyStore 路线）等模块处理。
  • TEE 损毁： 常见于三星设备物理熔断、一加设备 TEE 异常，通常需借助 AlwaysStrong（TrickyStore 路线）等模块修复或伪装。
  • 发现恶意APP： 检测应用列表，有root相关的APP和模块就会被发现， 使用 HideMyApplist 能够解决大部分场景。
  • 谷歌完整性未通过： 安装 AlwaysStrong 这类模块后， 模块自带的 keystore 可能被很多人使用被谷歌吊销， 因此可能需要手动去替换 keystore 文件。
  • 发现 Magic Mount: 类似 ZA Bank 等银行软件会检测到设备风险。 这主要是由于你的部分 Magisk 模块使用 Magic Mount 方式修改了 /system/ 相关的文件，被检测到。 当前(2025-12) alpha Magisk 方案没法隐藏，要么禁用这些模块， 要么在自定义 Rom 构建阶段直接写入修改。 KernelSU 等方案可通过元模块改变挂载方式规避检测，但未进行深入验证。

官方 Rom 解包/重打包

　　在玩机的时候，我们可能需要提取或者解包官方发布的刷机包，获取一些配置/APP， 或者制作官改包。 这里记录一下 Alliot 常用的一些工具:

  • payload-dumper-go: 一个命令行工具， 可以从线刷包中的 payload.bin 中提取特定的分区镜像:
1
2
3
# 从payload.bin中提取 boot 分区镜像
./payload-dumper-go -p boot payload.bin
./payload-dumper-go -p product payload.bin
  • erofs-utils: 针对 erofs 文件系统的一些工具， 现在新的安卓刷机包大多数使用 erofs 分区， 你可能需要它来帮你解包:
1
2
3
4
apt install -y erofs-utils
# 将system.img镜像解包到 system_out 路径下  
mkdir system_out
fsck.erofs --extract=system_out system.img

  • DNA for Android: 安卓上的一款很方便的ROM工具箱，用于做包很方便。 类似的还有 MIO-kitchen

  • MT管理器: 非常好用的一款文件管理器， 左右布局方便操作。 可能会被部分APP检测包名为风险应用， 可以下载官方的共存版或者加入隐藏应用列表中。

DSU sideload

　　有时候有新包想要体验一下，但是又不想都把整个系统重刷，这时候可以利用 DSU（Dynamic System Updates，动态系统更新）这个 Android 原生机制来临时启动并运行另一套 Android 系统镜像。
　　我们可以自己动手解包制作 DSU 侧载包，并利用 DSU-Sideloader 这个 APP 启动侧载系统。
　　做 DSU 包总结就是一句话： 提取目标 rom 的 system.img、system_ext.img、 product.img 以及 本机的 vendor、odm 压缩成 zip 文件即可（可以用前面提到的工具）。 但是有个前提就是你的目标包与当前系统在分区表和内核上兼容，否则侧载可能无法开机。
DSU-sideloader

结语

　　回头看 Android 这些年的变化，难免会产生一种强烈的时代落差感。早年从 Android 2.x 开始接触智能手机时，Root、刷机、模块几乎是默认选项，系统的可塑性被视为 Android 平台最核心的价值之一。
　　而如今，解锁 Bootloader 已成为少数设备才保留的“特权”，Root 被直接定义为安全风险，系统完整性校验、运行环境检测与账号风控机制层层叠加。用户往往只被授予设备的 “使用权”——它可以成为信息入口、广告载体，甚至是数据采集的终端，却唯独难以是完全按照你的意志运行、属于你的一部手机。 这也许是我后来对高配的手机没有太多兴趣的最主要原因吧。
　　或许有一天，当折腾的成本高于折腾本身的意义时，所谓的“玩机尽头”，真的会变成 iPhone 与 Pixel 的双持方案。