Android玩机小记

2025/8/29 Android

字数统计: 3.8k字 | 阅读时长: 14分 | 总文章阅读量：次

前言

原先的二手红米用了三年主板烧了，索性换了台能直接解 bl 的一加 ace5pro，就这样，从解 bl 入门到变砖速通（bushi）

参考：

https://doraemon.xlog.app/Android-wan-ji-ji-chu-zhi-shi-md?locale=zh

https://wiki.uotan.cn/index.php

https://www.daowuya.love/2024%E5%B0%8F%E7%B1%B3%E7%B3%BB%E5%88%97%E7%BA%AF%E5%B0%8F%E7%99%BD%E5%85%A8%E5%A5%97%E5%88%B7%E6%9C%BA%E6%95%99%E7%A8%8B%EF%BC%8Cmagiskkernelsulsposed%EF%BC%8C%E7%AE%80%E5%8D%95%E7%B2%97%E6%9A%B4/

基础知识

玩机的一切操作，本质都是在手机启动的某一环节进行修改：

① BootROM（固化在 SoC，不可改）
      ↓ 验证签名
② SPL / ABL（bootloader，即 fastboot 模式跑的东西）
      ↓ 加载
③ boot / init_boot / vendor_boot / dtbo  （内核 + ramdisk + 设备树）
      ↓ 内核启动，挂载
④ super（动态分区，内含 system / vendor / product / system_ext）→ /system 等
      ↓ 执行
⑤ init（解析 *.rc，启动所有服务，切换 SELinux enforcing）
      ↓ 启动
⑥ zygote / zygote64（预加载 ART 与系统类）
      ↓ fork
⑦ 每个 App 进程（系统应用与第三方应用一视同仁）

安卓分区

Boot 分区：

存放有启动和引导的文件，与开机启动引导相关
包含了操作系统的 Kernel (内核) 与 Ramdisk (虚拟内存)
Root 操作就是修改在 boot 分区
如果 boot 分区被擦除或者损坏，手机就会卡在开机的第一屏（bootloader 阶段，显示如手机制造商的 logo）

System 分区：

存放安卓系统和系统应用
系统分区包含了整个操作系统与系统软件
系统升级或者刷机很多时候都是在操作这个分区
system 分区损坏会卡在开机的第二屏（kernel 阶段，显示如设备 logo 或与内核相关的画面）

Vendor 分区：

与 system 分区相似的还有一个 Vendor 分区。

它包含了开发厂商定制的一些应用与库文件
很多厂商也会直接把 Vendor 分区这些文件放进 system 分区里面，方便后期的更新和维护

Data 分区：

数据分区存放用户数据，包括应用、音视频、图片、系统设置等
擦除 data 分区会清空用户数据，但不会影响到手机的正常启动

Cache 分区：

安卓的缓存区
缓存可以帮助你快速的打开系统最常访问的数据和应用程序，不需要重复加载
擦除缓存并不会影响个人数据，后续使用还是会自动生成

Recovery 分区：

恢复分区包含一个简易 Linux 系统用于恢复和维护手机
可以用来恢复和更新其他分区的内容 (如擦除数据)，类似于 Windows PE (Pre-installing environment)

AB 分区：

近年来出现了越来越多不存在 recovery 分区的手机，这是因为安卓从 7.0 开始引入了新的 OTA 升级方式，A/B System Updates（AB 分区）

这种升级方式把 boot 和 system 分区设置了两套，SlotA 和 SlotB ，平时用的 Slot 是主分区，另一个 Slot 是备用分区

这样在系统升级的时候可以做到无缝升级，用户可以边用手机后台边升级系统 (更新备份分区的内容)，升级完成之后重启手机，备份分区就会自动切换成主分区，若升级失败系统无法启动是就会切回之前的分区，缺点就是会占用双倍的 system 空间。

VA/B 分区：

为了解决空间占用的问题，于是又出现了 AB 分区的改进版 OTA 升级方式， Virtual A/B System Updates （VA/B 分区）：两代系统，相同文件共用，不同文件存于虚拟 A/B 分区

目前出厂搭载安卓 11 以上的机型普遍采用了 VA/B 分区

从玩机的角度来讲 A/B 或者 VA/B 分区刷第三方 recovery 会比较麻烦一点，因为这两种分区都把 recovery 分区并入了 boot 分区

Bootloader

喜闻乐见的 bl 环节

如果把 recovery 比作 PE，fastboot 阶段所属的 bootloader 就相当于电脑上的 BIOS/UEFI。
bootloader 顾名思义就是 **引导 (boot) 加载器 (loader)**，长按电源键开机的那一刻起，bootloader 就已经开始工作了。
在这段时间里 **bootloader 会初始化手机里的硬件设备，引导操作系统内核 (boot 分区里的 Kernel)**。
在引导后期我们可以选择进入一个叫 fastboot 的阶段 (手机上一般长按电源 + 音量减键进入)，这就是我们常说的刷机模式。
fastboot 比 recovery 更加底层，fastboot 下可以把手机连接电脑，输入命令来直接刷机。
解锁手机，注入 boot 镜像，线刷系统等很多操作都要通过 fastboot 来进行。
bootloader 并不属于某个系统分区，如果系统某个分区损坏导致手机变砖，一般可以进入 fastboot 救砖
使用 fastboot 刷机一般称为线刷（数据线连接电脑），使用 recovery 刷机一般称为卡刷 (卡刷包下载到手机)

解 bl 前需要退出谷歌账号

GKI

GKI（Generic Kernel Image，通用内核映像）是 Google 在 Android 11 及更高版本中引入的标准化 Linux 内核

在 GKI 架构下，Google 负责提供统一的通用内核，而高通、联发科等 SoC 厂商以及设备制造商（OEM）则将硬件专用的驱动程序编译为可加载模块。

SELinux

SELinux 是内核里的强制访问控制（MAC）模块，规则是”默认全禁，逐条放行“，相较于传统 Unix 的权限管理有如下区别：

	传统 Unix 权限（DAC）	SELinux（MAC）
依据	谁拥有文件（uid/gid + rwx）	进程的”域”能不能操作对象的”标签”
谁能改	文件主人（root 更是无所不能）	只有策略能改，root 自己说了不算
粒度	文件/目录	文件、目录、套接字、Binder、系统属性、进程……
效果	root = 上帝	root 也会被拦

SELinux 里每个进程和每个对象都带标签（security context），格式是 user:role:type:level

user：SELinux 用户（Android 基本只用 u）
role：角色（进程是 r，文件是 object_r）
type：真正起作用的部分——进程的 type 叫”域（domain）”，文件的 type 叫”类型”
level：MLS 级别（Android 基本是 s0）

adb shell id        → uid=2000(shell) ...  context=u:r:shell:s0     ← 无 root 的 adb shell 域
adb shell su -c id  → uid=0(root)   ...  context=u:r:su:s0        ← root shell 的域

这里的 root shell 的 type 是 su，su 域被策略额外放行了很多操作，这就是我们 root 能干的事

SELinux 有三种运行状态，Android 上实际只会见到前两种：

状态	策略评估	拒绝时是否拦截	见到的效果
Enforcing（强制）	照常评估	拦截，操作失败（返回 EACCES/EPERM）	功能报错 + 内核记 `avc: denied ... permissive=0`
Permissive（宽容）	照常评估	不拦，只记日志	功能正常 + 内核记 `avc: denied ... permissive=1`
Disabled（关闭）	不加载策略	—	Android 5.0+ 实际上不存在这种状态

出于安全考虑，不建议长期使用 Permissive 模式

Root

Android 的 root 意味着能拿到 uid 0 并能在 SELinux enforcing 下正常工作

现代方案都不再是”往 /system 塞一个 setuid 的 su”，而是：

开机早期启动一个 root 守护进程（magiskd / ksud / apd）；
该守护进程与 App 通信，App 请求提权时弹窗（或按配置直接放行）；
授权后把 shell 以 uid 0 拉起，并给出合适的 SELinux context（如 u:r:su:s0）。

常规方案

主要是下面这三大方案：

	Magisk	KernelSU（含 KernelSU Next）	APatch
实现位置	用户空间（补丁 boot/init_boot 里的 ramdisk）	内核空间（GKI/LKM 或自编译内核）	内核空间（KernelPatch 补丁 `boot.img`）
提权方式	MagiskSU 弹窗	App Profiles（按 UID/GID/能力/SELinux 精细画像）	SuperKey
模块挂载	内置（magic mount / overlayfs）	靠 metamodule 提供挂载能力	APModule（用户空间）+ KPModule（内核）
Zygisk	内置（Magisk 24+），可开关	不内置 → 用 Zygisk Next / NeoZygisk	同 KernelSU，靠 Zygisk Next
上手难度	最低，文档/模块生态最大	中，需要内核/KMI 概念	高，生态最小
隐蔽性	需要 Shamiko 等社区工具	相对不易被看见（无用户空间守护进程特征）	类似 KernelSU
OTA 影响	需恢复原镜像或重新打补丁	LKM 模式对 OTA 相对友好（非保证）	视机型/安装方式

KernelSU 与 Magisk 的共同点

KernelSU 是 Android GKI 设备的 root 解决方案，它工作在内核模式，并直接在内核空间中为用户空间应用程序授予 root 权限。

相同点：

模块文件格式: 都以 zip 的方式组织模块，并且模块的格式几乎相同
模块安装目录: 都在 /data/adb/modules
systemless: 都支持通过模块的形式以 systemless 修改 /system
post-fs-data.sh: 执行时机完全一致，语义也完全一致
service.sh: 执行时机完全一致，语义也完全一致
system.prop: 完全相同
sepolicy.rule: 完全相同
BusyBox：脚本都在 BusyBox 中以“独立模式”运行

CVE 临时 Root

重启即失效

CVE-2026-43499

lonStack

模块

一个模块的结构：

/data/adb/modules/<模块id>/
├── module.prop          # 元信息：id / name / version / versionCode / author / description / updateJson
├── customize.sh         # 安装时执行（可修改安装行为；Magisk/KSU 均支持）
├── post-fs-data.sh      # 启动极早期执行（阻塞式，慎用：会拖慢开机甚至卡死）
├── service.sh           # 启动较晚期执行（非阻塞，适合常驻服务）
├── boot-completed.sh    # 开机完成后执行（部分管理器支持）
├── system.prop          # 属性注入（resetprop 类效果）
├── sepolicy.rule        # 补充 SELinux 规则
├── uninstall.sh         # 卸载时执行
├── system/              # 要"叠加"到 /system 的文件（systemless 挂载源）
├── zygisk/              # Zygisk 模块：arm64-v8a.so / armeabi-v7a.so
└── disable              # 存在此文件 = 模块被禁用（救砖关键）

Magisk 和 KernelSU 的挂载差异：

	Magisk	KernelSU（Next）
挂载实现	内置 magic mount / OverlayFS	Metamodule 提供（核心不做挂载 → 降低被检测面）
单实例限制	—	同一时间只能装一个 metamodule
常见选择	自带即可	`meta-overlayfs`（标准 OverlayFS）或 magic mount 兼容实现
影响	直接可用	没装 metamodule 时，模块的 `system/` 可能挂不上（脚本类模块不受影响）

模块管理：

目的	做法
启用/禁用（不卸载）	在 root 管理器 UI 里开关；底层是 `disable` / `remove` 标记文件
CLI 操作	`ksud module list / install <zip> / uninstall <id> / enable <id> / disable <id>`（Magisk 用 `magisk --list` 等）
刷入新模块	管理器 → 模块 → 从本地安装；或 `ksud module install /data/local/tmp/x.zip`
救砖	开机时长按音量键进入安全模式（禁用全部模块）；或进入 fastboot/recovery 删除模块目录

Zygisk

Zygisk（Zygote Magisk）是 Magisk 的一项高级代码注入功能（magisk 的模块内容较弱, 只支持 sh 脚本, 所以要获取更高级的能力就要用到 zygisk）

zygote 是 Android 的进程孵化器，Android 上每个 App 进程都不是从零启动的，而是由 zygote（64 位是 zygote64）预加载好 ART 运行时和系统类之后 fork() 出来的——这是为了省内存、加快启动。所以只要在开机时把一段代码注进 Zygote 进程，之后 fork 出来的所有 App 进程都会天然带着这段代码，包括系统应用。

把代码注入 Zygote32/64，然后就能提供 Zygisk 模块 API

一个 Zygisk 模块就是一个普通 root 模块，多了一个 zygisk/ 目录：

/data/adb/modules/<模块id>/
├── module.prop                 # 模块元信息
└── zygisk/
    ├── arm64-v8a.so            # 注入 Zygote 的原生库，导出 zygisk_module_entry
    └── armeabi-v7a.so

ART/Java hook 框架

以蓝牙系统应用为例，其代码分为以下三层：

① Java/Kotlin 层   ← 系统设置、蓝牙 App 的业务逻辑（编译成 DEX 字节码）
        ↓ 由
② ART 运行时       ← Android 5.0 起取代 Dalvik 的"Java 虚拟机"，负责执行 ①
        ↓ 通过 JNI 调用
③ Native 层 (.so)  ← 蓝牙协议栈本体（Fluoride/bluedroid 全是 C/C++ 机器码）
        ↓
④ Linux 内核       ← 驱动、L2CAP/HCI 等

ART（Android Runtime）：安装 App 时 dex2oat 会把 DEX 字节码提前编译（AOT）成机器码，运行时由 ART 执行。ART 在内存里给每个方法维护一个结构体（ArtMethod），里面有这个方法”从哪开始执行”的入口地址。
Hook：把这个入口地址改成你自己函数的地址。之后任何调用者调这个方法，都会先跑到你这里——调用方毫无感知，文件也没被改（只改内存，重启即还原）。
Java hook vs native hook：Java hook 改的是 ArtMethod 的入口（要配合”去优化 deopt”，把已经 AOT 编译好的方法退回可拦截状态）；native hook 是直接改 .so 里的机器码（inline hook，把函数开头几条指令改成跳转）。

Xposed 就是”hook 任意 Java 方法”的一套 API 标准：模块只写”我要 hook 哪个类的哪个方法，前置/后置做什么”，剩下的脏活（改 ArtMethod、deopt、跨进程管理）由框架实现。

Android 凭据存储

Android 把证书存放在两个地方：

**系统证书存储 (System Store)**：存放在 /system/etc/security/cacerts。这是出厂自带的，只有 Root 权限才能写入。
**用户证书存储 (User Store)**：用户在“设置 -> 安全 -> 加密与凭据 -> 安装证书”里手动安装的。

Android 6.0 及以前：App 默认信任“系统证书”和“用户证书”。只要手动装个 Fiddler 证书，就能抓 App 的包。
Android 7.0 及以后：谷歌修改了安全策略。默认情况下，App 只信任系统证书，不信任用户手动安装的证书。

一加

ColorOS

其实当时选型号的时候不应该选 ace5pro 的，所谓解 bl 会炸 tee 是高通处理器的特性（小米魔改过所以不会炸），换其他型号比如联发科处理器就没这个事了，好在我平时也几乎不用指纹支付（

隐藏 root

Zygisk Next

Shamiko

tricky store

小米（MIUI）

设备：MiPad 6 pro

突然想起来自己的 MiPad 6 pro MIUI 14 当年绑定账号之后等了七天之后就没管了，最近一时兴起发现好像依旧保持绑定状态，并且可以解锁 oem，遂做完备份直接解了 bl

https://blog.isteed.cc/post/xiaomi-13-root-guide/

~~（参考文章的作者没想到在几个月后出现了售后降级跑路法）~~

音游优化（无 root）

屏幕刷新率自定义 144 hz，对于 pjsk 的话需要使用玩机工具箱强开 120 hz
声音-音质音效：关闭
手势：系统导航方式选择经典三大金刚
自动设置时间：关闭
传送门：关闭
游戏加速

目录

LOADING