2025年底的安卓搞机备忘录

发表于 评论数： 本文字数： 2.3k 阅读时长 ≈ 8 分钟

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

环境隐藏/过检测

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

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

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

root方案选择

　　现在的 Root 方案主要分为 Magisk面具阵容与内核root阵容(Apatch, KernalSU, SukiSU)，内核级 Root 隐藏能力更强（简单测试了一下, SukiSU应该是当前(2025-12)隐藏能力最强的）

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

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

面具模块列表

　　这些模块比较推荐安装：

  • Zygisk Next: 为复杂 Root 对抗场景设计的“更强、更隐蔽、更兼容”的 Zygisk 注入框架，用来解决原生 Zygisk 在新系统和高强度检测下的不足。 简单来说，原生 Zygisk 在新系统和高强度检测场景下更容易被识别，当前更推荐使用该方案。

  • TrickStore: 用于修复或伪装系统关键安全组件状态，在 Bootloader、TEE 及完整性校验相关检测中具有重要作用。

  • TS Enhancer Extreme: TrickStore 的功能增强模块，用于补充和强化其对抗能力。

  • Play Integrity Fork: 用于解决 Google Play Integrity API 校验失败问题。部分应用（比如 谷歌钱包、ChatGPT 等客户端）要求完整性校验至少通过基础完整性与设备完整性两项

  • LSPosed-JingMatrix版本: 原 LSPosed 已转为内测发布，该版本为仍在维护的开源分支，移除了一些容易被检测的实现细节，当前稳定性表现良好。

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

LSPosed 模块

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

环境检测APP

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

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

常见的检测点

  • Bootloader 解锁： 弱检测 alpha Magisk 通常可直接应对， 强检测需结合 TrickStore 等模块处理。
  • TEE 损毁： 常见于三星设备物理熔断、一加设备 TEE 异常，通常需借助 TrickStore 等模块修复或伪装。
  • 发现恶意APP： 检测应用列表，有root相关的APP和模块就会被发现， 使用 HideMyApplist 能够解决大部分场景。
  • 谷歌完整性未通过： 安装 TrickStore 和 Play Integrity Fork 类似模块后， 模块自带的 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 的双持方案。