Operation Practice

Recovery 实战：
存储平面解密与多模态链路审计

“进入 Recovery 界面仅仅是获得了物理访问权。真正的挑战在于如何穿透硬件支持的文件级加密（FBE）协议，并建立稳定的宿主机通信链路。在 2026 年的安卓安全环境下，解密不再是简单的密码比对，而是 TEE 环境下的多重握手。”

1 存储审计：Data 分区解密深度对策

现代 Android 系统（11+ 及 2026 年主流的 15+）强制采用 File-Based Encryption (FBE 2.0)。这种加密不再是针对全磁盘的，而是针对每个文件的 inode 进行单独加密。

技术原理补充：DE 与 CE 存储层

FBE 将存储分为 Device Encrypted (DE) 和 Credential Encrypted (CE)。DE 存储区（如系统核心日志）在设备开机后即可通过硬件密钥自动解密，因此即便 Recovery 没解密，你有时也能看到部分系统文件；而你的照片和私聊记录所在的 CE 区，必须在 TEE 通过你的用户凭据（锁屏密码）后才会派生出真正的解密主密钥。

当 Recovery 引导后，底层内核尝试挂载 /data 分区，如果未能通过硬件 Keymaster 验证，你将看到全路径乱码（如 /d/y7u1_x8...）且分区大小显示为 0MB。

1.1 硬件 TEE 握手协议 (Credential Decrypt)

这是最理想的解密方式。Recovery 会通过 vold 守护进程调用系统的加密组件，要求你输入锁屏密码。

输入审计：如果系统设置了数字或图案锁，Recovery 应能弹出对应的键盘。注意：部分第三方 Recovery（如早期版本的 OrangeFox）对复杂的特殊字符（如引号、分号）支持不佳，会导致密码虽然正确但校验失败。
延迟策略：若连续输错 5 次，硬件芯片（TEE）将触发 Back-off 保护机制。此时，硬件计数器会锁定解密接口 30 秒至 30 分钟，导致 Recovery 在此期间永久报错。审计建议：此时必须完全重启一次设备，以重置 TEE 的会话状态。

1.2 异常状态审计：当 Recovery 无法弹出密码框

在某些特定场景下（如更换了非官方内核、系统大版本跨越式更新），Recovery 可能无法成功调用 Keymaster。此时，你需要进行以下审计操作以确定数据恢复的可能性：

Metadata 挂载状态

Android 10+ 引入了独立于 Data 的 /metadata 分区，它存储了 Data 分区的 DE 密钥描述符。如果 Recovery 连该分区都无法挂载，说明分区的加密标志位（Encryption Footer）已物理损坏，Keymaster 将无法找到密钥入口。

密钥版本冲突 (KM Version)

如果手机从 Android 14 升级到了 15，底层的 Keymaster/Keymint 协议可能发生了静默升级。若 Recovery 内核版本过低，它将因无法解析 TEE 返回的加密握手包而永久显示 0MB，这种情况只能等待适配新版 REC 或使用 ADB Sideload 绕过。

核心审计结论：清除 (Wipe) vs 格式化 (Format)

这是导致大多数“无限重启”或“无法解密”故障的根源。在执行操作前，必须分清两者的物理意义：

操作类型	物理行为	对解密的影响
高级清除 (Wipe)	递归执行 `rm -rf` 指令，仅删除文件系统中的目录树条目。	无法移除 Inode 加密标志。重启后系统依然会通过 TEE 检索旧密钥，导致要求输入密码或解密失败报错。
格式化 (Format Data)	执行 `make_f2fs` 或 `mke2fs`，彻底重写 Superblock 和分区表头。	彻底物理重置。擦除所有加密描述符，Data 将恢复为未加密状态直至下次系统启动重新初始化。

1.3 持久化移除加密：强制降级 (DAP 解密补丁)

对于需要频繁在 Recovery 中通过文件管理器修改配置的开发者，GAOJI.UK 建议采用“解除强制加密”策略。这通常通过修改 fstab 文件实现，将系统挂载策略从加密引导（Required）降级为可选引导。

DFE (Disable Force Encryption) 审计流程

Kernel-Level Security Modification

通过刷入 DFE 补丁，可以修改内核或 Vendor 镜像中的 fstab 挂载表，将 fileencryption=ice 标志改为 encryptable。

1. 执行 Format Data
(物理抹除旧密钥)

2. 刷入 DFE 补丁
(阻断密钥生成)

3. 禁用 AVB 校验
(防止系统检测内核篡改)

2 通讯链路审计：ADB Sideload 救砖协议

当系统由于分区损毁无法进入（Bootloop），且内部存储因解密失败无法读取时，ADB Sideload 是 Recovery 提供的最高级别通讯协议。它通过 USB Gadget 驱动 开启一个特殊的侦听端口，允许宿主机（PC）通过二进制流（Binary Stream）直接将固件推送到 RAM 并实时解压刷入。

2.1 链路握手审计 (Protocol Handshake)

开启 Sideload 模式前，必须通过描述符审计确保宿主机与设备之间的驱动协议栈已正确加载。

状态 A：设备端侦听

操作逻辑：进入 Advanced -> ADB Sideload。勾选 Wipe Dalvik/Cache（可选）。
物理表现：设备将卸载 MTP 驱动并挂载 ADB Bulk 接口，底部显示 Starting ADB sideload feature...。此时 CPU 处于半阻塞循环，持续扫描 USB 数据报文。

状态 B：宿主机审计

指令：adb devices
关键判定：返回值必须显示为 sideload。若显示 unauthorized，说明 Recovery 无法读取 Data 分区中的 ADB 授权密钥；若显示 offline，则通常是因为 USB 线缆抗干扰能力不足，导致数据包校验和错误（Checksum Error）。

传输指令与校验流程 (Audit Command)

Sideload Protocol MD5/SHA256 Checksum: Enabled

adb sideload full_ota_package.zip

深度细节：在传输进度达到 47%（文件流传输结束）或 94%（后置脚本执行结束）时，进度条可能会长时间停顿。这是因为 Recovery 正在利用底层内核进行 ZIP Signature Verification。切勿在此阶段强行断开 USB，否则会导致 Super 分区索引 损坏。

2.2 挂载点冲突审计 (Mount Conflict)

在使用 Sideload 刷入涉及分区表（GPT）改动的模块时，Recovery 可能抛出著名的 Error 7。这通常代表脚本检测到了物理互斥状态。

Error 7 深度审计对策表

分区已挂载 (Mount Lock) 先在 Mount 菜单手动取消勾选 System/Vendor 以释放 I/O 句柄

代号校验失败 (Device Mismatch) 修改 updater-script 中 getprop ("ro.product.device") 指令值

逻辑卷溢出 (No Space) 进入 FastbootD 模式通过 lpflash 重置动态分区 Extent 大小

3 分区安全审计：高级清除与数据隔离

在 Recovery 的 Wipe 菜单中，误操作可能导致设备丢失基带（No IMEI）或由于 SELinux 标签丢失 而无法引导。我们需要基于分区功能进行“权限分级”审计，确保操作在安全边界内。

3.1 标准“三清”协议 (Standard Clean Flash)

当你准备更换一个新的 ROM（例如从 MIUI 切换到 LineageOS）时，执行以下三项审计清除是维持系统底层一致性的最低要求，旨在抹除 AOT (Ahead-of-Time) 预编译文件的干扰：

Dalvik / ART Cache

清除已编译的字节码缓存。注：不同 ROM 的 Java 虚拟机版本不同，旧缓存会导致指令集冲突从而引发 App 闪退。

安全审计

Data (不含 Internal Storage)

清除用户 App 及数据库配置。注意：高级清除里的 Data 选项仅操作 /data/app，通常不破坏你的照片和视频挂载点。

推荐审计

Cache

系统日志与 OTA 临时文件存储区。在 A/B 分区设备上，此分区已被虚拟化，清除动作仅具象征意义。

无损审计

危险审计：严禁触碰的红区

在高级清除菜单中，除非你是专业内核开发者，否则基于 硬件信任根 的保护，绝对禁止手动勾选以下分区：

Vendor / System: 抹除后将失去全部底层驱动。在动态分区架构下，这可能导致 Super 分区表偏移，无法通过刷包恢复。
Persist / EFS / Modem: 存储了基带频率、IMEI 串号、以及指纹传感器的物理校准数据。一旦物理抹除且无备份，手机将永久失去通信功能。

3.2 资产抢救审计：MTP 交互协议

如果 FBE 解密成功，但系统依然无法进入（卡 Logo），你可以利用 Recovery 内置的 MTP (Media Transfer Protocol) 服务开启紧急数据通道。

MTP 链路建立与故障审计

Emergency Data Extraction Logic

在 Mount 菜单中确认已勾选 Data 或 Micro SD Card。只有挂载后，MTP 守护进程才能扫描到文件系统的 Inode。

点击 Enable MTP。此时宿主机应弹出对应的盘符。若连接断开，请检查 Recovery 设置中的 USB ID (VID/PID) 是否正确。

审计注意：若电脑无反应，通常是由于 USB 描述符竞争。请尝试先点击 "Disable MTP" 物理切断逻辑链路，插拔数据线后再次点击 "Enable MTP"，强制宿主机重新进行热插拔枚举。

4 镜像备份审计：构建 Nandroid 物理快照

在 Recovery 环境下进行的备份被称为 Nandroid Backup。它不同于应用层的云备份，它是对分区扇区的字节级克隆。一旦系统实验失败，你可以通过回滚快照实现“时光倒流”，将分区状态恢复至哈希校验完全一致的时刻。

4.1 分区备份优先级审计 (Backup Strategy)

由于现代设备存储动辄 256G/512G，且 Virtual A/B 架构导致快照体积巨大，全盘备份已不现实。我们需要针对不同实验目的制定精准的审计备份策略：

最小审计集

Boot / DTBO / Vendor_Boot
仅 100MB 左右。刷入 Magisk、第三方内核或精简驱动前的必备物理底线。

安全审计集

EFS / Persist / Bluetooth
包含 IMEI 和硬件校准。每个新机到手后应备份一次并存入物理冷存储（网盘/U盘）。

全量审计集

Data / Super (System+Vendor)
体积巨大。仅在进行系统大版本跨越（如 Android 15 升 16）前执行。

校验一致性审计 (Integrity Check)

Recovery 在备份时会同步生成名为 .md5 或 .sha256 的哈希清单。

审计注意：恢复（Restore）前，内核会逐一比对分卷哈希。如果你手动重命名了备份文件夹导致其与 MD5 记录不符，或者存储卡因 NAND 老化 产生逻辑坏道导致数据翻转，校验将失败。此时绝不要强制跳过校验，否则会导致分区表写入不完整，造成底层引导永久损坏。

4.2 离线存储审计：跳出手机物理环境

备份在手机内部存储（Internal Storage）是极不稳固的，因为 Format Data 会物理抹除该区域。GAOJI.UK 建议采用物理隔离的审计转移方案：

方案 A：MicroSD / OTG (USB-C) 挂载

在 Backup 页面将 Storage 更改为 External SD，直接将字节流写入外部物理介质。

方案 B：ADB Pull 流式镜像拉取

执行 adb pull /sdcard/TWRP/BACKUPS ./Local_Audit_Store。此方案绕过了 MTP 的识别限制，传输更稳定。

5 高级终端审计：Shell 交互与物理干预

Recovery 环境本质上是一个基于 Linux Kernel 的精简操作系统，内置了完整的 BusyBox / Toybox 指令集。通过底层的 Shell 交互，我们可以绕过 GUI 菜单执行更精准的补丁修复。

5.1 锁屏凭证强制重置 (Credential Reset Logic)

如果你在更换系统后，由于 TEE 信任链断裂 导致无法进入 Android 系统（密码虽然正确但提示加密错误），可通过以下审计指令物理移除凭证数据库：

Terminal Security Bypass Target UID: 1000 / /data/system


                    # 进入系统配置目录

                    cd /data/system

                    # 移除硬件门禁密钥文件

                    rm -f gatekeeper.password.key

                    rm -f gatekeeper.pattern.key

                    # 移除锁屏设置数据库及其日志

                    rm -f locksettings.db*

操作后效应：重启进入系统后，旧的生物识别（指纹/人脸）会因密钥不匹配而失效，滑动即可进入桌面。此时必须立即进入设置重新录入凭证，以触发 TEE 重新生成 Master Key。

5.2 权限与属性审计 (CHMOD & CHOWN)

在手动向 /system 或 /data 注入文件（如自定义补丁或配置文件）后，如果 UID/GID (用户组 ID) 设置不当，系统将由于 Permission Denied 无法加载关键库文件，导致卡启动。

权限校准指令审计

chmod 644 /path/to/file 常规配置文件（三位读写）

chmod 755 /path/to/script 二进制执行文件（含执行权）

深度技巧：LOG 实时流导出
如果刷包过程中抛出 "Error 1"，但屏幕滚动太快无法精确定位物理行号，可在终端输入：
cp /tmp/recovery.log /sdcard/audit_error.log
然后通过 MTP 将该 Audit Log 导出。它可以记录所有二进制脚本在执行时的 Stderr 输出，是向开发者反馈故障的核心证据。

6 引导流转审计：重启逻辑与环境固化

在点击“Reboot System”之前，必须完成最后一轮环境审计。对于现代 A/B (Seamless Updates) 分区设备，忽略槽位（Slot）状态是导致 Hard Brick 或进入原厂 Recovery 的头号原因。

6.1 A/B 槽位一致性审计 (Slot Switching Logic)

如果你的设备支持双槽位，请在 Reboot 菜单中确认当前的 Active Slot。

场景 A：增量 OTA 后的审计

刷入官方全量包后，系统通常会将固件写入 非活动槽位 (Inactive Slot)。此时你必须手动切换 Slot（如 A -> B），并立即重新刷入 Recovery 持久化补丁或 Magisk，否则重启后 SoC 会自动加载未被修改的原厂引导链。

场景 B：底层 Bootloader 更新

某些底包更新仅涉及单槽位的 GPT 表。如果在切换 Slot 后无法引导（屏幕黑屏且无法进入 Fastboot），请长按音量减+电源强制切回原槽位，通过审计日志确认另一槽位的 vbmeta 校验是否被强制开启。

6.2 持久化守卫：物理拦截原厂脚本

如前所述，Android 系统内置了位于 /system/bin/install-recovery.sh 的重写脚本。要在重启后保留第三方 Recovery，必须通过以下 防回滚审计 动作：

持久化审计操作清单

修补引导扇区：刷入 Magisk 或 KernelSU。它们会修改 boot.img 的 Ramdisk，从而在系统挂载根目录前移除自动恢复脚本的执行权。
AVB 状态审计：在高级设置中勾选 "Disable Stock Recovery Replacement"，强制内核忽略 recovery-from-boot.p 的差异补丁。
逻辑冷重启：首次重启必须手动组合键进入一次 Recovery，确保其完成 FBE 策略自解压 逻辑，否则系统可能因 Data 挂载点死锁而回滚分区。

优雅重启指令审计

在 UI 界面由于触摸偏移无法点击时，通过终端精确控制跳转目标是开发者必备的防御技能：

reboot recovery

重启至 REC 验证持久化状态

reboot bootloader

回退至物理层重新刷入 vbmeta

7 终期审计：实战操作合规性确认

在宣告你的 Recovery 实战演习圆满成功之前，请对照 GAOJI.UK 实验室定义的 "Final Audit Protocol" 进行最后一次物理确认。

存储挂载审计 (Data Accessibility)

重启进入 Recovery 后，无需再次格式化即可看到 /sdcard 的明文文件。证明 FBE 2.0 硬件解密驱动 已成功与当前系统的 Keymaster 环境闭环握手。

引导链完整性审计 (Bootlink Integrity)

设备能够无缝从 Recovery 切换至 System，且未触发 "Orange State" 之外的 Corruption Warning。这说明 dm-verity 校验已处于非强制性挂载模式。

链路应急响应审计 (Emergency Interface)

已在宿主机 PC 上成功执行过一次 adb shell id。这标志着即使未来 UI 物理层由于硬件故障崩溃，你仍保留了通过 Sideload/Shell 协议接管设备的终极管理权。

Audit Phase Complete

“至此，你已不仅仅是设备的使用者，
而是其底层逻辑的真正主理人。”

Recovery 的高级实战已为你打通了系统的所有毛细血管。下一阶段，我们将利用这些权限，深入 Android 的核心，开启 Root 权限的终极审计与精细化管理。

开启下一阶段：Root 权限终极审计