boot、init_boot、vendor_boot、vbmeta 装什么？一次不刷机的拆包实验

Android 13 并不自动意味着每台设备都有同样的 init_boot：从 Android 13 起发布的新布局与升级上来的旧设备可能不同。本教程只在电脑拆解当前构建的官方镜像，重打包到新文件并比较；默认绝不刷入，因此适合先理解 Magisk、KernelSU 与 APatch 为什么选择不同目标。

你会完成什么#

• 识别 boot、init_boot、vendor_boot 与 vbmeta 的典型职责和版本条件。
• 用 magiskboot 或 AOSP unpack_bootimg 只读记录 header、kernel、ramdisk、compression、DTB、cmdline。
• 保存原始/重打包文件的 SHA-256、大小、工具版本和 stdout 差异。
• 将 Magisk、KernelSU LKM/GKI 与 APatch 的分区规则映射回启动链，而不执行 flash。

先看结论#

心智模型#

bootloader → vbmeta/AVB 验证链 → boot(kernel)
                           ├→ init_boot(generic ramdisk)
                           └→ vendor_boot(vendor ramdisk + DTB)
                                     ↓
                               first-stage init
只读拆包 → 记录 → repack 到新文件 → hash/元数据比较 → 不 flash

AOSP 说明 Android 11 的 GKI 布局规范了 vendor_boot，Android 13 launch 设备把 generic ramdisk 移到 init_boot；但 launch 与 upgrade 是关键区别。AVB 还验证启动链并提供 rollback protection，结构能被工具解析不代表签名、大小和 bootloader 策略允许启动。

工具清单#

项目全景：内核与启动镜像的 11 个项目，一个不漏#

十一项按 boot/init_boot 操作、AVB/vbmeta、内核 Root/安全、设备内核资料和 GPU 调优分层。教程的核心是先认清镜像和分区，再谈 patch 或 flash。

1. boot/init_boot 提取、修补与刷写 · 3#

比较 Boot-img-flasher、Boot-image-Extractor 和 ksupatcher 的输入、输出与权限需求。每个产物记录构建号、目标分区和哈希，提取成功不等于可以安全刷写。

本组共 3 项：3 个源项目、0 个 Fork，其中 0 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

2. AVB、vbmeta 与启动验证 · 2#

用 vbmeta_tool 和 MTK vbmeta patcher 解释 digest、验证链和关闭验证的代价。默认只读取；任何写入必须有精确原图和官方恢复路径。

本组共 2 项：2 个源项目、0 个 Fork，其中 0 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

3. 内核 Root、Patch 与防护 · 3#

mi_nobl_root、RootGuard 和 AndroidKernelPatch 展示内核级 Root/Hook/防护边界。不开源或免解锁宣称先隔离审计，不在日用机验证。

本组共 3 项：3 个源项目、0 个 Fork，其中 0 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

4. 设备内核、固件档案与工具合集 · 2#

Nokia 6300 4G 档案和 Android_Tools 合集用于资料发现。先识别 KaiOS/Android 边界、维护状态和真正的原始仓库，不把合集当作可刷镜像。

本组共 2 项：2 个源项目、0 个 Fork，其中 1 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

5. GPU 超频与降压 · 1#

KonaBess-Next 消费 Root 权限修改 Snapdragon GPU 参数，不属于启动镜像工具。只讲备份原频压表、单档测试、温度监控和恢复默认。

本组共 1 项：1 个源项目、0 个 Fork，其中 0 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

开始前#

从厂商官方 exact-build 完整固件提取一组镜像，记录 model/codename/region/build、包 URL/hash。不要从当前 A/B 动态分区随意 dd，否则可能拿到错误槽、snapshot 或更新中状态。把原始镜像复制到实验目录，设为只读，另建 repacked/ 输出目录并保存 magiskboot/unpack_bootimg 版本。

于 2026-08-09 核验时，APatch 官方仍只 patch boot，Magisk 依据 ramdisk/设备/Samsung 规则选目标，KernelSU LKM/GKI 则有自身镜像和 KMI 要求。一个工具的教程不能替代另一个工具的分区规则。

操作步骤#

1. 建立原始镜像台账#

对 boot.img、存在时的 init_boot.img、vendor_boot.img、vbmeta.img 分别记录字节大小与 SHA-256。将厂商包的 build/region/hash 放在同一表，确保没有从另一个版本混入文件。保留 untouched 子目录，后续所有命令只对复制品运行。

2. 只读拆包并解释输出#

对启动镜像执行 magiskboot unpack <image-copy> 或 AOSP 工具等价的只读拆解，保存 stdout/exit code。记录 boot header version、page size、cmdline、kernel、ramdisk、压缩、DTB 和 vendor ramdisk fragments；vbmeta 只读查看 descriptor/algorithm/rollback 信息，不修改 flag。

3. 重打包到新文件并比较#

不改任何解包内容，使用同一工具 repack 到 repacked/<name>-repacked.img，绝不覆盖原图。计算新 hash/大小，重新拆解新文件并对比 header、cmdline、ramdisk tree 与 compression。hash 不同不自动代表失败：时间戳、压缩或重建格式可能造成非确定性，但必须解释差异。

4. 映射 Root 方案并结束实验#

把本机真实布局填入表：Magisk 关注可修补 ramdisk与设备特例；APatch 只接受 clean stock boot；KernelSU LKM/GKI 需当前官方规则及精确 KMI。写下每个候选的输入镜像与回滚文件。到此结束，不尝试 fastboot boot 或 flash；若未来操作，进入对应独立文章重新做身份与恢复检查。

验证#

“重打包成功”只证明工具产生了文件；本文故意不验证其可启动性，因为那需要设备特定签名、分区大小、AVB 和可靠恢复等另一组前置。

排错#

完成清单#

• □四类镜像均来自同一 exact model/region/build 官方包并保存 URL/hash。
• □untouched 原图只读保存，所有操作都针对复制品和独立输出目录。
• □header、kernel、ramdisk、compression、DTB/fragments、cmdline 与 AVB 已记录。
• □repack 产物重新拆解并比较 size/hash/metadata，没有覆盖原图。
• □已按本机布局区分 Magisk、APatch 与 KernelSU 规则，不互换教程。
• □未运行 flash、禁用 verity/verification 或从另一个槽/设备混用镜像。

一手资料#

• AOSP Generic boot partition
• AOSP Vendor boot partition
• AOSP Bootloader 概览
• AOSP Verified Boot / AVB
• Magisk 工具说明
• Android Image Kitchen