手动挂载apex镜像

1.loop设备

在类 UNIX 系统里loop 设备是一种伪设备(pseudo-device)或者也可以说是仿真设备。它能使我们像块设备一样访问一个文件。

这要先从mount的流程来理解挂载操作实际上就是把设备上的文件系统/目录文件连接到指定的目录directory下在操作系统层面就是把挂载设备和挂载目录的对应关系加到内核中的Vfsmount里的对应表单里内核启动后会从硬盘上加载到内存里这样我们就可以通过访问目录路径来访问设备上的数据了。

loop mount是另一种mount方式如果说普通mount解决了实际硬件存储设备的挂载bind mount解决了目录到目录的挂载那么loop mount则解决了将档案文件到目录的挂载

档案英文Archive与文件file不同是一个打包好的文件集里面一般包含许多文件, 比如 tarjariso img就是常见的档案格式

那又是怎么实现将档案文件挂载到目录下呢

实际上系统先把档案文件比如某个.iso文件映射到loop设备上
#losetup  /dev/loop0   xxxx.iso        使系统误认为xxxx.iso为存储设备/dev/loop0

再欺骗mount命令使他认为  /dev/loop0真的是个设备在运行挂载到指定目录
#mount   -t   xxxx.iso   /dev/loop0    /loop设备路径    

但前提是被访问的loop设备里的档案文件具有linux识别的文件系统像tar, jar, zip 这样的档案只是一种压缩格式本身不是文件系统即使通过loop mount挂载上去了直接访问他也读不出什么数据这很好理解就像在windows下不装任何解压软件就无法打开压缩文件一样。所有一般我们都是拿img、iso映射到loop设备。

2.apex包结构

APEX文件格式如下

从顶层看APEX文件是一个Zip文件其中的文件均是未压缩的。

其中的四个文件有apex_manifest.jsonAndroidManifest.xmlapex_pubkeyapex_payload.img

• apex_manifest.json文件包括package name和版本用来标识该APEX文件

• AndroidManifest.xml可以允许APEX文件使用一些apk的工具像adb、package manager、 app install app等。举个例子APEX文件可以使用aapt检查文件的metadata。该文件还包括packcage name和版本号这些内容通常也会再apex_manifest.json文件中。

• apex_payload.img是依赖dm-verity的EXT4文件系统镜像。该镜像在运行时通过一个回环设备加载。具体地说metadata和hash tree是通过libavb创建的。apex_payload.img还没有被解析因为要求该文件是可挂载的。一些常规文件包含在该镜像中。

• apex_pubkey是用来给文件系统签名的公钥。该公钥确保下载的apex文件是以编译阶段相同的方式签名。

3.开始实验

1. 将apex解压缩上传到Linux中

   

其实apex包就是个压缩包将后缀名改成.zip自行使用Windows解压工具进行解压

上传后我们可以看下它的文件结构和它的文件系统属性

amx@amxxxx:~/Android/system$ file apex_payload.img 
apex_payload.img: Linux rev 1.0 ext2 filesystem data, UUID=7d1522e1-9dfa-5edb-a43e-98e3a4d20250 (extents) (large files) (huge files)

amx@amxxxx:~/Android/system$ tune2fs -l apex_payload.img 
tune2fs 1.44.5 (15-Dec-2018)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          7d1522e1-9dfa-5edb-a43e-98e3a4d20250
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr dir_index filetype extent sparse_super large_file huge_file uninit_bg dir_nlink extra_isize shared_blocks
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              32
Block count:              8213
Reserved block count:     0
Free blocks:              8
Free inodes:              5
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         32
Inode blocks per group:   2
Filesystem created:       Thu Jan  1 08:00:01 1970
Last mount time:          n/a
Last write time:          Thu Jan  1 08:00:01 1970
Mount count:              0
Maximum mount count:      -1
Last checked:             Thu Jan  1 08:00:01 1970
Check interval:           0 (<none>)
Lifetime writes:          32 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     32
Desired extra isize:      32
Default directory hash:   half_md4
Directory Hash Seed:      7d1522e1-9dfa-5edb-a43e-98e3a4d20250

2. 查看当前空闲的loop设备

amx@amxxxx:~/Android/system$ sudo losetup -f
/dev/loop0

可以看到当前空闲的loop设备为/dev/loop0所以我们打算将apex与/dev/loop0进行关联

3. 将apex镜像与loop设备关联

amx@amxxxx:~/Android/system$ sudo losetup /dev/loop0 apex_payload.img

4. 将loop设备挂载到目标节点上

amx@amxxxx:~/Android/system$ sudo mount -o ro /dev/loop0 /home/amx/Android/apex/com.android.i18n

这里我模仿了安卓将它挂载到了/home/amx/Android/apex/com.android.i18n

这里只能使用ro只读形式挂载因为apex_playload.img采用了ext4文件系统且在文件系统中添加了shared_block属性该属性不允许随意修改镜像文件也是为了将镜像文件尽量压缩到最小从名字就可以看出来共享块。这里可以通过改变inode结构改变这个属性但是有点难度需要了解ext文件系统才行。

5. 查看是否挂载成功

可以看到我们可以像访问块设备一样访问apex包啦

4.参考

• https://blog.csdn.net/shengxia1999/article/details/52081286?spm=1001.2014.3001.5506
• https://blog.csdn.net/qq_28351465/article/details/106458089?spm=1001.2014.3001.5506