Recovery 架构审计：
从分区载体到持久化部署
Partition Type
A/B & Dynamic
Encryption
FBE 2.0 / TEE
Verify Sec
AVB / dm-verity
Environment
FastbootD / User
“Recovery 镜像并非简单的功能插件，而是独立于安卓系统的微缩 Linux 内核。在按下回车键之前，我们必须审计其物理载体，否则将面临引导链永久性损毁的风险。”
1 载体审计：确定物理写入路径
在 2026 年的安卓生态中，Recovery 的存储位置经历了三次重大的技术更迭。你手中的设备可能采用了以下任意一种拓扑结构，这直接决定了物理写入时的偏移量（Offset）计算：
流派 A：独立 Recovery 时代 (Legacy A-Only)
这是最经典的结构（如小米 6 及以前机型）。手机拥有一个专门名为 recovery 的分区。这是最安全的结构，即使刷错也仅影响 REC 本身，不会导致系统黑屏。原理： Bootloader 直接根据 GPT 分区表的扇区标记跳转。
流派 B：Ramdisk 寄生时代 (A/B Slots)
从 Android 9 开始，由于 A/B 分区的设计，独立的 REC 分区被取消。Recovery 被打包进了 boot.img 的 Ramdisk 中。这意味着刷入 Recovery 就是在刷入新的系统内核。若内核版本不匹配，手机将无法正常引导 Android 系统。
流派 C：供应商解耦时代 (Virtual A/B & GKI)
在最新的 GKI（通用内核镜像）架构下，为了实现内核与驱动分离，Recovery 再次搬家，进入了名为 vendor_boot 的分区。这是目前旗舰机（如小米 14/15 系列）的主流标准。深度审计： 此架构下必须解除 AVB 哈希链校验，否则即使写入正确也会导致无法启动。
2 资源获取审计：预判内核兼容性
获取 Recovery 镜像（通常为 .img）后，盲目刷入是初学者的致命伤。我们需要通过特征审计，确保该镜像能够成功挂载你当前的底层固件。
内核版本对齐 (Kernel Version)
现代安卓对内核版本极其敏感。如果你的手机当前内核是 5.10.x，而你下载了一个基于 4.19.x 开发的镜像，刷入后将导致 I/O 调度崩溃。
审计重点：GKI 设备必须检查镜像是否带有 -gki 后缀，这决定了它是否遵循通用内核对象的调用规范。
安全补丁等级 (SPL)
Android 12+ 引入了更严苛的 AVB 校验。如果镜像的 SPL 日期早于当前固件，Bootloader 的 Rollback Index (回滚计数器) 会拒绝引导。
表现：在屏幕上方出现极小的一行英文："Image Rollback Version Error"。
深度技巧：使用 magiskboot 进行离线审计
在 PC 或另一台已 Root 的手机上执行：
magiskboot unpack your_recovery.img
数据特征分析：
1. 检查 header：确认 Header Version 是否为 3 或 4（对于 GKI 设备）。
2. 检查 ramdisk：如果显示 Status: No Ramdisk，而你的设备是 A/B 分区且没有独立的 Recovery 分区，说明你下载的镜像格式错误，强行刷入会导致 Fastboot 锁死。
官方库与第三方社区的权重
在寻找资源时，应当遵循以下优先级序列。GAOJI.UK 建议尽量避免使用未经审计的“一键工具箱”内置镜像，因为其内核版本往往未经验证：
3 持久化部署：协议分层与交互审计
随着 动态分区 (Dynamic Partitions) 的普及，传统的 Bootloader 已经无权直接操作由逻辑卷管理的扇区。在执行写入指令前，你必须确认设备处于正确的交互平面。
传统 Fastboot 模式
接入逻辑：由 SoC 固化代码引导。关机下按住“音量下 + 电源键”。
操作范围：仅限于修改 物理分区（如 boot, vbmeta, vendor_boot）。
关键审计点：如果你的 Recovery 位于 vendor_boot，必须在此模式操作，因为它是底层引导链的入口，不属于动态逻辑卷。
用户空间 Fastboot 模式
接入逻辑：在 Fastboot 模式输入 fastboot reboot fastboot。
操作范围：拥有对 逻辑分区 (System, Vendor, Product) 的完全读写权。它实际上是运行在 Recovery 临时内核之上的一个精简环境。
空间审计：对于虚拟 A/B 设备，如果你发现刷入 Recovery 时报错 "No space left on device"，必须在此模式下删除无用的逻辑镜像空间以腾出物理扇区。
动态指令交互演示
为了降低误操作风险，请根据你在第 1 段中审计出的分区载体，选择对应的持久化指令。错误的载体指令将导致数据偏移，造成 Hard Brick：
fastboot flash recovery your_recovery.img
校验锁定补丁：VBMETA 审计
刷入修改后的分区前，必须解除 AVB 2.0 哈希链。否则重启后 SoC 将检测到物理扇区的校验值与预存公钥不符，导致拒绝引导。请执行：
fastboot flash vbmeta --disable-verity --disable-verification vbmeta.img
4 存储审计：FBE 2.0 加密与解密策略
当你进入 Recovery 后看到乱码（乱序字符文件夹），是因为你的 Data 分区处于锁定状态。现代安卓设备使用 FBE 2.0 (File-Based Encryption)，每个文件由存储在 SoC 安全区域（TEE）的硬件密钥保护。Recovery 必须通过特定协议与 TEE 握手，才能获取明文数据。
协议 A：TEE 动态解密
原理：Recovery 内核包含解密组件（如 gatekeeper 和 keymaster），能弹出密码输入框。当你输入锁屏密码时，它会将哈希值传给 SoC 安全区进行 HMAC 比对。
审计失败表现：如果 REC 内核版本与系统版本跨度过大，会导致解密组件由于 Blob 库文件不匹配而报错，无法弹出密码框。
协议 B：强制格式化 (DAP)
原理：通过 Format Data 物理抹除整个 Userdata 分区，并重构磁盘头部的 LUKS/fscrypt 结构。这会彻底移除 metadata 分区中的加密标志。
物理代价：该操作是不可逆的。它会清开所有数据并断开与旧 TEE 密钥的物理关联。这是在 REC 无法匹配加固算法时的唯一“暴力破局”手段。
持久化博弈：防止官方 REC 自动回退
安卓系统包含一个名为 recovery-from-boot 的服务（通常位于 /system/bin/install-recovery.sh）。如果你刷入第三方 REC 后直接重启进入系统，该服务会检测到 Recovery 分区的 CRC32 校验 与预设值不符。
GAOJI.UK 审计建议：
1. 切断物理回路：在 Fastboot 写入成功后，绝对严禁 执行 fastboot reboot 指令。此指令会触发系统初始化逻辑并执行覆盖脚本。
2. 硬中断跳转：必须手动长按“音量上 + 电源键”，在屏幕黑掉的瞬间（SoC 重置电平时）松开电源键，强制引导链跳转到 Recovery 分区，以此在第一次启动时拦截官方系统的回刷指令。
FBE 解密状态审计表
| 现象表现 | 核心诱因 | 审计对策 |
|---|---|---|
| 文件夹乱码 (0KB) | FBE 密钥未解密，CE/DE 链路未通。 | 确认锁屏密码或执行 Data 分区格式化。 |
| 无法挂载 /system | EROFS 格式只读保护或动态分区表锁定。 | 在 Mount 界面尝试强制只读挂载，或使用 Magisk 环境。 |
| ADB Sideload 无响应 | Recovery 的 USB 描述符与主机驱动不匹配。 | 手动在 REC 的 Advanced 菜单中重启 ADB 守护进程。 |
5 终期审计：环境稳固性确认
在宣告部署成功之前，必须通过 GAOJI.UK 定义的三项核心指标测试。这些测试旨在模拟极端崩溃环境，只有全部通过，你的 Recovery 才具备应对底层修改风险的防御能力。
在 Recovery 中尝试进入 /data/media/0。
判定标准：如果能看到真实的文件夹结构（如 DCIM、Download），说明 fscrypt 解密驱动 与当前系统固件完全兼容。若显示乱码或 0MB，则代表持久化解密协议已失效。
连接电脑，在终端输入 adb devices。
判定标准：若返回 recovery 字样，意味着即使未来触屏损坏、屏幕不点亮或 Android 系统彻底崩溃，你仍能通过 ADB Sideload 协议进行远程刷机或执行二进制脚本挽救数据。
执行：System -> Recovery -> System 的循环引导流程。
核心目的：确认在系统启动过程中，位于 /vendor/etc 的初始化脚本没有通过 SHA-256 校验 强行将第三方 Recovery 覆盖回原厂镜像。
Architecture Conclusion
“当你完成了 Recovery 的持久化部署，
你已经接管了设备主权的第一道关隘。”
Recovery 不仅仅是一个刷机界面，它是你在面对系统崩溃、引导锁死以及数据加密高墙时的最后一份物理契约。掌握了它的架构逻辑，即掌握了对移动硬件最底层的解释权。