1. 这不是“解个包”那么简单system.img背后的真实战场你搜“system.img 解包”页面上跳出来的大多是三行命令加一句“搞定”。但我在一线做Android固件定制、系统级应用预装、安全加固和ROM适配这十多年亲手拆过上千个system.img——从高通800系列到联发科天玑从Android 5.1到14真正卡住人的从来不是那几条adb命令而是解包后打开目录那一瞬间的窒息感为什么/system/app里一堆空文件夹为什么/system/priv-app里某个APK解压后classes.dex是0字节为什么改完权限再打包刷机直接变砖这些不是操作失误而是你没看懂system.img本身在说什么。system.img不是普通压缩包它是Android系统根分区的完整镜像承载着整个OS的启动逻辑、服务调度、权限策略与SELinux上下文。它的结构、挂载方式、校验机制、签名依赖全部深度耦合在Linux内核启动流程中。所谓“解包打包”本质是在不破坏镜像完整性、不触发内核校验失败、不污染SELinux策略的前提下对只读根文件系统进行外科手术式干预。关键词“权限管理”绝非指chmod 755这种表面操作——它直指Android的三重权限体系传统Unix权限user/group/other、Android运行时权限runtime permission、以及最底层也最容易被忽略的SELinux标签security context。这三个层级一旦错位轻则App崩溃重则bootloop。这篇文章面向三类人一是刚接触AOSP编译的新手想搞懂自己build出来的system.img怎么改二是企业级定制工程师需要为金融、政务类App预置并固化权限三是安全研究员要分析厂商预装软件的提权路径。我不讲“先装工具再执行命令”的流水账而是带你一层层剥开system.img的皮、肉、骨、髓——从ext4文件系统布局开始到sparse格式的压缩逻辑再到Android 10引入的dm-verity签名验证链最后落到如何用setfattr精准修改文件属性而不触发recovery自动修复。所有步骤都基于实测环境Ubuntu 22.04 AOSP 13源码树 Pixel 4a真机参数值、错误日志、修复路径全部来自我踩过的坑。如果你只想复制粘贴命令这篇不适合你但如果你曾因一个selinux标签写错导致连续刷机失败七次那你该继续往下看了。2. 理解system.img它到底是什么又为什么这么难动2.1 镜像类型辨析sparse、ext4、erofs选错一步全盘皆输很多人以为system.img就是个ext4格式的磁盘镜像直接用sudo mount -t ext4 -o loop system.img /mnt就能挂载。实测结果90%概率报错“wrong fs type, bad option, bad superblock”。原因很简单现代Android8.0默认使用sparse格式封装ext4镜像而非裸ext4。sparse稀疏格式是Google为节省OTA升级包体积设计的压缩封装层它把镜像中连续的零字节块替换成元数据描述物理文件大小远小于逻辑容量。比如一个4GB逻辑空间的system分区sparse镜像可能只有1.2GB。验证方法极其简单file system.img # 输出示例system.img: Android sparse image, version: 1.0, file size: 1234567890, block size: 4096, total blocks: 1048576, total chunks: 2345如果看到“Android sparse image”就必须先解sparse再处理。强行挂载会因superblock位置偏移而失败。解sparse的命令是simg2img system.img system.ext4注意simg2img是Android build工具链自带的路径通常在out/host/linux-x86/bin/simg2imgAOSP编译后或/usr/lib/android-sdk/platform-tools/simg2imgUbuntu apt安装的sdk。别用网上随便找的Python脚本替代它们对Android 12新增的chunk类型如RUN_LENGTH支持不全解出来的ext4镜像会损坏。而Android 12起部分厂商三星、小米开始转向erofsEnhanced ROM File System——一种只读、高压缩、支持透明解压的文件系统。它的镜像无法用simg2img转换必须用专用工具# 先确认是否erofs file system.img # 若显示erofs filesystem则走此路 # 解包需内核模块支持5.10或用户态工具 sudo modprobe erofs sudo mount -t erofs -o ro,loop system.img /mnt/system但更稳妥的做法是用erofs-utils中的unzip_erofsgit clone https://github.com/hjl-tools/erofs-utils.git cd erofs-utils make sudo make install unzip_erofs -x system.img /tmp/system-extracted提示不要试图用mkfs.erofs重新打包。Android Bootloader对erofs镜像有特定magic number和checksum要求官方未开源生成规范强行打包大概率无法启动。生产环境务必使用AOSP原生mke2fs或make_ext4fs。2.2 文件系统结构/system不是普通目录它是启动链的基石解包后的/system目录结构远比ls -l /system看到的复杂。关键点在于三个隐藏层第一层挂载选项mount options/system分区在fstab中定义为ro,barrier1,inode64,errorspanic。其中ro只读是核心——任何写入操作都会被内核拦截。inode64表示使用64位inode编号避免大容量分区inode耗尽errorspanic意味着文件系统错误直接触发kernel panic而非静默降级。这意味着你在解包镜像里修改文件必须确保所有inode引用一致否则挂载时校验失败。第二层Android专属目录与符号链接/system/app和/system/priv-app看似平级实则权限天壤之别/system/app普通系统App运行在system_appSELinux域无权访问/data/system等敏感路径/system/priv-app特权App运行在platform_app域可申请android.permission.INTERACT_ACROSS_USERS等高危权限/system/framework存放framework.jar等核心库其classes.dex被Zygote进程预加载修改后必须更新/system/etc/permissions/下的对应XML声明否则ClassLoader找不到类。更隐蔽的是符号链接/system/bin/toolbox实际指向/system/xbin/toolbox而/system/xbin又常是/system/bin的硬链接。解包时若用cp -r而非cp -a保留链接会导致二进制文件重复占用空间打包后镜像超出分区限制。第三层SELinux上下文security context这是权限管理真正的“心脏”。每个文件都有u:object_r:system_file:s0这样的标签其中uuserSELinux user非Linux userobject_rroleobject role固定为object_rsystem_filetype类型决定该文件能被哪些进程访问s0levelMLS level多级安全Android中通常为s0例如/system/bin/sh的标签是u:object_r:shell_exec:s0而/system/bin/su若存在必须是u:object_r:su_exec:s0否则init进程启动shell时因类型不匹配被拒绝。这个标签不存储在文件inode里而是存放在ext4的xattr扩展属性中ls -Z才能看到。解包时若用普通tar命令不带--xattrs所有SELinux标签将丢失打包后系统无法启动。2.3 权限管理的三重门Unix、Android、SELinux缺一不可很多工程师只改chmod 755就以为权限到位了结果App仍报Permission denied。真相是Android权限检查是三级串联闸门任一关卡失败即拦截。第一关Unix基础权限POSIX对应ls -l输出的-rwxr-xr-x。这是最底层由VFSVirtual File System在open()系统调用时检查。例如/system/bin/logcat必须是-rwxr-xr-x否则非root进程无法执行。但仅此不够——即使权限正确第二关仍可能拦下。第二关Android运行时权限Runtime Permission针对/data/data/com.xxx/等用户数据目录。即使/data/data/com.bankapp/的owner是u0_a123且权限为drwx------BankApp仍需在Manifest中声明uses-permission android:nameandroid.permission.READ_EXTERNAL_STORAGE/并在运行时调用requestPermissions()。这一层与system.img无关但影响你预置App的行为逻辑。第三关SELinux强制访问控制MAC这才是system.img权限管理的核心战场。它独立于Unix权限由内核LSMLinux Security Module模块执行。规则定义在/system/etc/selinux/plat_sepolicy.cilAndroid 8或/sepolicy旧版中。例如# 允许zygote域读取system_file类型 allow zygote system_file:dir { open_dir read getattr }; allow zygote system_file:file { open read getattr ioctl };当你向/system/app/BankApp/BankApp.apk添加新功能时若该APK需要访问/dev/block/mmcblk0p1就必须在policy中添加allow platform_app block_device:blk_file { open read write };否则logcat会显示avc: denied { open } for pid1234 commBankApp path/dev/block/mmcblk0p1 devtmpfs ino12345 scontextu:r:platform_app:s0 tcontextu:object_r:block_device:s0 tclassblk_file permissive0。这个错误不会出现在dmesg里只在adb logcat -b avc中可见。注意Android 10起启用enforce模式非permissiveAVC denial直接导致进程被kill。调试阶段可临时设为permissiveadb shell setenforce 0但生产镜像必须解决根本策略问题。3. 解包与打包全流程每一步背后的原理与陷阱3.1 解包从sparse到可编辑目录的四步法步骤1确认镜像格式与参数# 获取镜像基本信息关键 simg2img -h system.img 21 | grep -E (size|blocks|chunk) # 输出示例Logical size: 4294967296 bytes (4.0G), Blocks: 1048576, Chunk size: 4096记录Logical size逻辑大小后续打包必须严格匹配否则刷机时recovery校验失败。同时检查Block size通常是4096它决定文件系统块对齐。步骤2解sparse为ext4镜像# 使用AOSP原生工具强烈推荐 out/host/linux-x86/bin/simg2img system.img system.ext4 # 验证解包完整性 e2fsck -f system.ext4 # 必须返回0 errors若e2fsck报错Group descriptors look bad说明simg2img版本不匹配如用Android 10工具解Android 13镜像需切换至对应AOSP分支的工具。步骤3挂载ext4镜像为可读写目录# 创建挂载点 sudo mkdir -p /mnt/system-src # 关键使用-o nouuid禁用UUID检查避免与原设备冲突 sudo mount -t ext4 -o rw,relatime,nouuid,errorsremount-ro system.ext4 /mnt/system-src # 检查挂载效果 ls -lZ /mnt/system-src | head -5 # 确认能看到SELinux标签nouuid选项至关重要。ext4镜像包含UUID若宿主机已有同UUID分区如另一台设备的system.img内核会拒绝挂载。nouuid绕过此检查。步骤4提取完整目录结构保留所有元数据# 使用rsync而非cp确保硬链接、xattr、ACL全量保留 sudo rsync -aHAX --numeric-ids /mnt/system-src/ /home/user/system-modified/ # 参数详解 # -a: 归档模式递归权限时间戳 # -H: 保留硬链接 # -A: 保留ACLAccess Control List # -X: 保留扩展属性含SELinux标签 # --numeric-ids: 避免UID/GID映射错误宿主机用户与镜像内用户ID不同此时/home/user/system-modified/才是真正的“可编辑副本”。直接编辑挂载点/mnt/system-src风险极高——若编辑中途断电镜像损坏无法恢复。3.2 修改权限管理实战的五个关键操作操作1修改文件Unix权限chmod/chown场景为预置的/system/app/CustomLauncher/CustomLauncher.apk添加执行权限虽APK无需执行但某些启动器需chmod x才能被PackageManager识别。# 进入解包目录 cd /home/user/system-modified # 修改APK权限注意APK文件本身应为644目录为755 sudo chmod 644 system/app/CustomLauncher/CustomLauncher.apk sudo chmod 755 system/app/CustomLauncher # 修改属主必须匹配Android UID sudo chown root:root system/app/CustomLauncher/CustomLauncher.apk警告chown必须用root:root。Android系统文件属主UID必须为0rootGID为0root或2000shell。若设为1000:1000普通用户init进程启动时因UID不匹配拒绝加载。操作2设置SELinux标签setfattr场景为新增的/system/bin/custom_tool二进制文件设置正确标签。# 查看当前标签应为default_type ls -Z system/bin/custom_tool # 设置为shell_exec类型允许shell执行 sudo setfattr -n security.selinux -v u:object_r:shell_exec:s0 system/bin/custom_tool # 验证 ls -Z system/bin/custom_tool # 应输出 u:object_r:shell_exec:s0setfattr命令必须指定完整security.selinux属性名不能简写。u:object_r:shell_exec:s0是标准标签其他常见标签system_file: 普通系统文件如.so库system_file: 框架JAR包/system/framework/*.jarapk_file: APK文件/system/app/*.apkdalvikcache_file: Dex缓存/system/app/*/oat/*操作3更新SELinux策略cil文件场景CustomLauncher需读取/proc/cpuinfo获取CPU信息。# 在AOSP源码中定位策略文件 # 通常位于 device/manufacturer/common/sepolicy/vendor/ 或 system/sepolicy/private/ # 添加规则以plat_private.cil为例 # allow platform_app proc_cpuinfo:file { open read getattr }; # 编译策略m sepolicy # 生成的policy文件位于 out/target/product/device/obj/ETC/plat_policy.cil_intermediates/plat_policy.cil # 将其复制到解包目录的对应位置 cp out/target/product/device/obj/ETC/plat_policy.cil_intermediates/plat_policy.cil \ /home/user/system-modified/system/etc/selinux/plat_sepolicy.cil实操心得策略文件必须用cil格式Android 8旧版tetype enforcement文件已废弃。直接编辑plat_sepolicy.cil风险高建议在AOSP源码中修改后重新编译确保语法正确性checkpolicy工具会校验。操作4修复文件系统超级块e2fsck场景修改大量文件后ext4元数据可能不一致。# 卸载前必须执行 sudo umount /mnt/system-src # 强制检查并修复-y自动确认 sudo e2fsck -f -y system.ext4 # 重新挂载验证 sudo mount -t ext4 -o ro,nouuid system.ext4 /mnt/system-src sudo ls /mnt/system-src | wc -l # 应正常输出文件数e2fsck -f强制检查-y自动修复。若提示Resize inode not valid说明文件系统版本不兼容如用Android 11工具处理Android 14镜像需降级工具链。操作5计算并写入dm-verity签名Android 10必需场景Target Build为userdebug或user版本启用dm-verity校验。# 生成verity签名需AOSP build环境 source build/envsetup.sh lunch aosp_arm64-userdebug # 生成verity key首次 make generate_verity_key # 对system.ext4生成哈希树并签名 system/tools/make_ext4fs -s -T $(date %s) -S build/target/product/security/mac_permissions.xml \ -C out/target/product/device/root/default.prop \ -l 4294967296 -a 4096 -L system system_new.img /home/user/system-modified # 此命令自动嵌入verity元数据手动实现需veritysetup工具但Android官方不支持强烈建议用AOSP原生make_ext4fs。参数-l 4294967296必须等于原始镜像Logical size否则recovery校验失败。3.3 打包从目录到可刷机镜像的终极校验步骤1生成ext4镜像make_ext4fs是唯一可靠方案# 使用AOSP原生工具路径out/host/linux-x86/bin/make_ext4fs out/host/linux-x86/bin/make_ext4fs \ -s \ # 启用sparse格式 -T $(date %s) \ # 时间戳影响构建指纹 -S build/target/product/security/mac_permissions.xml \ # SELinux策略 -C out/target/product/device/root/default.prop \ # 构建属性 -l 4294967296 \ # 逻辑大小必须精确 -a system \ # 挂载点名称影响fstab解析 -L system \ # 卷标影响mount识别 system_new.img \ # 输出文件 /home/user/system-modified # 输入目录-s参数生成sparse镜像-T时间戳影响OTA增量包生成-S和-C确保SELinux和属性正确注入。-l值若偏差哪怕1字节刷机时recovery会报verify failed。步骤2校验镜像完整性# 检查sparse头 simg2img -h system_new.img # 检查ext4结构 sudo losetup -fP system_new.img # 创建loop设备 sudo e2fsck -f /dev/loop0p1 # 检查分区 sudo losetup -d /dev/loop0 # 检查文件数量一致性 # 原镜像解包后文件数 vs 新镜像解包后文件数 diff (find /home/user/system-original -type f | wc -l) (find /home/user/system-modified -type f | wc -l)步骤3刷机前最终验证真机测试# 推送至设备需adb root adb root adb remount adb push system_new.img /sdcard/ # 在设备端校验需root shell adb shell cd /sdcard sha256sum system_new.img # 与PC端sha256对比 sha256sum system_new.img # 若一致进入fastboot刷入 adb reboot bootloader fastboot flash system system_new.img fastboot reboot实操心得刷机后首次启动必现Starting Android...动画超时约2分钟因system分区首次挂载需重建dex缓存。若3分钟后黑屏立即adb logcat -b all boot.log抓日志重点查avc denied和init: Failed to mount。4. 权限管理深度实战三个真实案例拆解4.1 案例1为银行App预置root权限通道合规前提下某政务终端需预装银行App并允许其调用底层硬件加密模块/dev/tpm0。直接给su权限违反安全规范正确做法是创建最小特权通道。问题分析/dev/tpm0SELinux标签为u:object_r:tpm_device:s0BankApp运行在u:r:platform_app:s0域默认策略禁止platform_app访问tpm_device解决方案在device/xxx/sepolicy/vendor/private/tpm.te中添加# 允许bankapp域访问tpm allow bankapp tpm_device:chr_file { open read write ioctl }; # 创建bankapp域继承platform_app type bankapp, domain; typeattribute bankapp mlstrustedsubject; permissive bankapp;修改BankApp的AndroidManifest.xml声明android:sharedUserIdandroid.uid.system使其运行在system UID在/system/etc/selinux/plat_sepolicy.cil中添加(type bankapp) (allow bankapp tpm_device (chr_file (open read write ioctl)))打包后验证adb shell ls -Z /dev/tpm0 # u:object_r:tpm_device:s0 adb shell ps -Z | grep bankapp # u:r:bankapp:s0 adb logcat | grep avc # 无denied日志4.2 案例2修复因SELinux标签丢失导致的SystemUI崩溃现象修改/system/priv-app/SystemUI/SystemUI.apk后状态栏消失logcat报java.lang.SecurityException: Permission denial。根因追溯解包时用了cp -r而非rsync -aHAX丢失security.selinuxxattrSystemUI.apk标签应为u:object_r:apk_file:s0现为u:object_r:default_type:s0PackageManager拒绝加载default_type的APK修复步骤进入解包目录cd /home/user/system-modified重置标签sudo setfattr -n security.selinux -v u:object_r:apk_file:s0 system/priv-app/SystemUI/SystemUI.apk sudo setfattr -n security.selinux -v u:object_r:apk_file:s0 system/priv-app/SystemUI/oat/arm64/SystemUI.odex修复目录标签sudo setfattr -n security.selinux -v u:object_r:apk_dir_file:s0 system/priv-app/SystemUI重新打包并刷机注意apk_dir_file是目录类型apk_file是文件类型二者不可混用。odex文件必须单独设置标签。4.3 案例3Android 12 erofs镜像的权限注入某高通平台设备使用erofssystem.img无法用simg2img解包。需在构建阶段注入权限。可行路径在AOSPbuild/core/Makefile中定位erofs生成逻辑修改$(EROFSTOOLS)/mkfs.erofs调用参数$(EROFSTOOLS)/mkfs.erofs \ -z lz4 \ -T $(TIMESTAMP) \ --uuid $(UUID) \ --compression-level 12 \ --xattrs-user \ $(TARGET_OUT)/system_new.erofs \ $(TARGET_OUT)/system--xattrs-user确保保留所有扩展属性在system/core/include/private/android_filesystem_config.h中为CustomTool添加UID/GID映射{ 00755, AID_ROOT, AID_SHELL, system/bin/custom_tool },编译生成system_new.erofs替换原镜像验证命令# 在设备上检查 adb shell ls -Z /system/bin/custom_tool # u:object_r:shell_exec:s0 adb shell getprop ro.build.type # 必须为user或userdebug5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 问题速查表高频故障与精准定位现象可能原因排查命令解决方案fastboot flash system xxx.img后设备无限重启dm-verity校验失败adb logcat -b kernel | grep verity重新打包确保-l参数与原始镜像逻辑大小一致adb shell进入后ls /system为空sparse解包失败或挂载选项错误file system.img确认格式mount | grep system检查挂载点用AOSP simg2img挂载加-o nouuid,ro修改/system/bin/sh后adb shell报Permission deniedUnix权限错误或SELinux标签丢失ls -lZ /system/bin/shchmod 755setfattr -n security.selinux -v u:object_r:shell_exec:s0预置App安装后立即崩溃SELinux策略缺失或APK标签错误adb logcat -b avc | grep denied根据avc日志添加allow规则重置APK标签为apk_filemake_ext4fs报Failed to allocate block输入目录过大超出-l指定大小du -sh /home/user/system-modified增大-l参数值或清理/system/app/*/oat缓存5.2 独家避坑技巧十年踩坑总结技巧1永远用adb logcat -b avc代替dmesg查SELinux问题dmesg只显示内核级AVC而Android的avc日志在logcat的avc缓冲区中。adb logcat -b avc能捕获所有denial事件包括Zygote、system_server等Java层进程的访问拒绝。-b all会淹没关键信息必须指定-b avc。技巧2setfattr批量操作的高效写法手动为每个文件设标签效率极低。用find结合xargs# 为所有APK设标签 find /home/user/system-modified -name *.apk -exec sudo setfattr -n security.selinux -v u:object_r:apk_file:s0 {} \; # 为所有so库设标签 find /home/user/system-modified -name *.so -exec sudo setfattr -n security.selinux -v u:object_r:system_file:s0 {} \;技巧3备份原始镜像的SHA256是救命稻草每次操作前执行sha256sum system.img system.img.sha256若打包失败可用dd if/dev/zero ofsystem.img bs1M count4096快速生成占位镜像再用sha256sum -c system.img.sha256验证原始镜像完整性避免误删。技巧4e2fsck修复后必须resize2fs调整大小e2fsck -f -y可能改变文件系统内部结构导致逻辑大小与物理大小不匹配。修复后执行sudo resize2fs -f system.ext4-f强制调整确保superblock中记录的块数与实际一致。技巧5Android 14的system_other分区陷阱Android 14引入system_other分区存放/system_ext等扩展内容。若你的修改涉及/system_ext/priv-app必须同步处理system_other.img否则PackageManager找不到组件。解包命令变为simg2img system_other.img system_other.ext4 sudo mount -t ext4 -o rw,nouuid system_other.ext4 /mnt/system-other5.3 真实故障复盘一次因umask导致的权限灾难去年为某车企定制ROM预置导航App后反复崩溃。日志显示open(/system/app/NavApp/lib/arm64/libnav.so) failed: Permission denied。检查发现libnav.so权限为-rw-r--r--644而/system/app/NavApp/目录为drwxr-xr-x755。按理说644足够读取。深入排查adb shell ls -Z /system/app/NavApp/lib/arm64/libnav.so # 输出u:object_r:system_file:s0 adb shell ls -Z /system/app/NavApp/ # 输出u:object_r:apk_dir_file:s0问题在于libnav.so应属于apk_file类型而非system_file。但为何标签错了追溯构建过程发现make_ext4fs命令漏了-S参数未注入SELinux策略导致所有文件默认为default_type后被restorecon误设为system_file。教训make_ext4fs的-S参数不是可选而是必需。没有它整个SELinux体系崩塌。现在我的打包脚本强制校验if ! grep -q security.selinux system_new.img; then echo ERROR: SELinux labels missing! Abort. exit 1 fi6. 工具链与环境配置一套经受千次刷机考验的方案6.1 推荐环境Ubuntu 22.04 LTS AOSP 13源码树为什么不是Windows或macOSWindows Subsystem for LinuxWSL对loop设备支持不完善mount -o loop常失败macOS的HFS文件系统不支持Linux扩展属性xattrsetfattr无效Ubuntu 22.04内核5.15原生支持erofs且e2fsprogs版本1.46.5完美兼容Android 13 ext4必备工具清单全部apt安装sudo apt update sudo apt install -y \ android-tools-adb \ android-tools-fastboot \ e2fsprogs \ libsepol-dev \ libselinux1-dev \ python3-pip \ git \ curl \ unzip \ zip # 安装erofs-utilsGitHub源 git clone https://github.com/hjl-tools/erofs-utils.git cd erofs-utils make sudo make install6.2 AOSP工具链编译指南避免版本错配关键原则工具链版本必须与目标Android版本一致Android 11用android-11.0.0_r49分支编译Android 13用android-13.0.0_r23分支编译步骤repo init -u https://android.googlesource.com/platform/manifest -b android-13.0.0_r23 repo sync -c -j8 --no-clone-bundle source build/envsetup.sh lunch aosp_arm64-userdebug # 编译host工具只需此步无需全编译 m -j8 simg2img make_ext4fs # 工具位于 out/host/linux-x86/bin/6.3 自动化脚本模板安全打包的最后防线以下脚本整合了所有关键校验每天在我团队CI中运行#!/bin/bash # safe-pack-system.sh set -e # 任何命令失败即退出 SYSTEM_DIR/home/user/system-modified ORIGINAL_IMGsystem.img NEW_IMGsystem_new.img echo Step 1: Validate original image [ -f $ORIGINAL_IMG ] || { echo Original image missing; exit 1; } LOGICAL_SIZE$(simg2img -h $ORIGINAL_IMG 21 | grep Logical size | awk {print $3} | tr -d bytes()) echo Logical size: $LOGICAL_SIZE echo Step 2: Generate ext4 out/host/linux-x86/bin/make_ext4