Dans l’article précédent on a vu que rooter un téléphone Android avec magisk impliquait de télécharger le firmware du téléphone avant d’en modifier une partie.

Mais que contient ce firmware au juste ?

Pour donner quelques éléments de réponse, téléchargeons-le firmware d’un pixel 7A (sur https://developers.google.com) et examinons son contenu.

Le firmware en question se présente sous la forme d’un fichier zip d’un point moins de 3Go que l’on peut décompresser :

thomas@ankou:~/articles/android_root_magisk$ ls -l *zip
-rw-r--r-- 1 thomas thomas 2971991323 16 mars   2024 lynx-ap1a.240305.019.a1-factory-7f7dfec6.zip

Une fois décompressé, on trouve deux fichiers img, des scripts et un autre zip :

thomas@ankou:~/articles/android_root_magisk/lynx-ap1a.240305.019.a1$ ls -l
total 2919252
-rw-r--r-- 1 thomas thomas   14663432 22 févr.  2024 bootloader-lynx-lynx-14.4-11290827.img
-rw-r--r-- 1 thomas thomas        993 22 févr.  2024 flash-all.bat
-rwxr-xr-x 1 thomas thomas       1110 22 févr.  2024 flash-all.sh
-rwxr-xr-x 1 thomas thomas       1057 22 févr.  2024 flash-base.sh
-rw-r--r-- 1 thomas thomas 2892830617 22 févr.  2024 image-lynx-ap1a.240305.019.a1.zip
-rw-r--r-- 1 thomas thomas   81797260 22 févr.  2024 radio-lynx-g5300q-231218-240202-b-11396366.img

Regardons le script flash-all.sh pour se faire une idée du rôle de ces différents fichiers :

(...)
fastboot flash bootloader bootloader-lynx-lynx-14.4-11290827.img
fastboot reboot-bootloader
sleep 5
fastboot flash radio radio-lynx-g5300q-231218-240202-b-11396366.img
fastboot reboot-bootloader
sleep 5
fastboot -w update image-lynx-ap1a.240305.019.a1.zip

Un petit coup d’oeil au help de fastboot nous apprend que

fastboot flash <partition> <fichier>

écrit le fichier <fichier> sur la partition <partition>.

Ainsi, ce script met à jour la partition bootloader avec le fichier

bootloader-lynx-lynx-14.4-11290827.img,

la partition radio avec

radio-lynx-g5300q-231218-240202-b-11396366.img,

puis les autres partitions avec le contenu de

image-lynx-ap1a.240305.019.a1.zip.

Dézippons maintenant image-lynx-ap1a.240305.019.a1.zip :

thomas@ankou:~/articles/android_root_magisk/lynx-ap1a.240305.019.a1$ ls -l
total 8436988
-rw-r--r-- 1 thomas thomas    1646592  1 janv.  2009 abl.img
-rw-r--r-- 1 thomas thomas        168  1 janv.  2009 android-info.txt
-rw-r--r-- 1 thomas thomas      12288  1 janv.  2009 bl1.img
-rw-r--r-- 1 thomas thomas     536576  1 janv.  2009 bl2.img
-rw-r--r-- 1 thomas thomas      94208  1 janv.  2009 bl31.img
-rw-r--r-- 1 thomas thomas   67108864  1 janv.  2009 boot.img
-rw-r--r-- 1 thomas thomas   14663432 22 févr.  2024 bootloader-lynx-lynx-14.4-11290827.img
-rw-r--r-- 1 thomas thomas   16777216  1 janv.  2009 dtbo.img
-rw-r--r-- 1 thomas thomas        407  1 janv.  2009 fastboot-info.txt
-rw-r--r-- 1 thomas thomas        993 22 févr.  2024 flash-all.bat
-rwxr-xr-x 1 thomas thomas       1110 22 févr.  2024 flash-all.sh
-rwxr-xr-x 1 thomas thomas       1057 22 févr.  2024 flash-base.sh
-rw-r--r-- 1 thomas thomas     315392  1 janv.  2009 gsa.img
-rw-r--r-- 1 thomas thomas 2892830617 22 févr.  2024 image-lynx-ap1a.240305.019.a1.zip
-rw-r--r-- 1 thomas thomas    8388608  1 janv.  2009 init_boot.img
-rw-r--r-- 1 thomas thomas    2392064  1 janv.  2009 ldfw.img
-rw-r--r-- 1 thomas thomas   81797120  1 janv.  2009 modem.img
-rw-r--r-- 1 thomas thomas      40960  1 janv.  2009 pbl.img
-rw-r--r-- 1 thomas thomas 3270004736  1 janv.  2009 product.img
-rw-r--r-- 1 thomas thomas    1048576  1 janv.  2009 pvmfw.img
-rw-r--r-- 1 thomas thomas   81797260 22 févr.  2024 radio-lynx-g5300q-231218-240202-b-11396366.img
-rw-r--r-- 1 thomas thomas       5184  1 janv.  2009 super_empty.img
-rw-r--r-- 1 thomas thomas     348160  1 janv.  2009 system_dlkm.img
-rw-r--r-- 1 thomas thomas  276996096  1 janv.  2009 system_ext.img
-rw-r--r-- 1 thomas thomas  946470912  1 janv.  2009 system.img
-rw-r--r-- 1 thomas thomas   18255872  1 janv.  2009 system_other.img
-rw-r--r-- 1 thomas thomas    6967296  1 janv.  2009 tzsw.img
-rw-r--r-- 1 thomas thomas      12288  1 janv.  2009 vbmeta.img
-rw-r--r-- 1 thomas thomas       8192  1 janv.  2009 vbmeta_system.img
-rw-r--r-- 1 thomas thomas       4096  1 janv.  2009 vbmeta_vendor.img
-rw-r--r-- 1 thomas thomas   67108864  1 janv.  2009 vendor_boot.img
-rw-r--r-- 1 thomas thomas   53944320  1 janv.  2009 vendor_dlkm.img
-rw-r--r-- 1 thomas thomas  762724352  1 janv.  2009 vendor.img
-rw-r--r-- 1 thomas thomas   67108864  1 janv.  2009 vendor_kernel_boot.img

L’essentiel des fichiers obtenus sont des fichiers img, d’autres images de partition, donc.

À ce stade il est intéressant de regardons ce que dit la documentation

(https://source.android.com/docs/core/architecture/partitions?hl=fr) sur les partitions standards d’un système android :

• La partition boot, qui contient une image noyau.
• La partition init_boot, qui contient un ramdisk initial (comparable à l’initramfs sur une machine Linux). Cette partition n’existait pas avant Android 13, le ramdisk étant alors inclus dans la partition boot.
• La partition system, qui contient le système Android.
• La partition radio, contenant l’image radio du terminal.

Cette liste est loin d’être exhaustive.

Une grande partie des fichiers img sont des systèmes de fichiers ext2, ou bien des fichiers bootimg :

thomas@ankou:~/articles/android_root_magisk/lynx-ap1a.240305.019.a1$ file *
abl.img:                                        MPEG-4 LOAS
android-info.txt:                               ASCII text
bl1.img:                                        data
bl2.img:                                        data
bl31.img:                                       data
boot.img:                                       Android bootimg, kernel
bootloader-lynx-lynx-14.4-11290827.img:         data
dtbo.img:                                       data
fastboot-info.txt:                              ASCII text
flash-all.bat:                                  DOS batch file, ASCII text
flash-all.sh:                                   POSIX shell script, ASCII text executable
flash-base.sh:                                  POSIX shell script, ASCII text executable
gsa.img:                                        data
image-lynx-ap1a.240305.019.a1.zip:              Zip archive data, at least v2.0 to extract
init_boot.img:                                  Android bootimg
ldfw.img:                                       data
modem.img:                                      POSIX tar archive (GNU)
pbl.img:                                        data
product.img:                                    Linux rev 1.0 ext2 filesystem data, UUID=02451e5a-f7eb-5fb1-abde-8e2050760baf, volume name "product" (extents) (large files) (huge files)
pvmfw.img:                                      Android bootimg, kernel
radio-lynx-g5300q-231218-240202-b-11396366.img: data
super_empty.img:                                data
system_dlkm.img:                                Linux rev 1.0 ext2 filesystem data, UUID=84fcdd28-c7df-5da1-8a4e-a6a463236cad, volume name "system_dlkm" (extents) (large files) (huge files)
system_ext.img:                                 Linux rev 1.0 ext2 filesystem data, UUID=325c0af1-f051-5882-bd0f-3b06c21874ca, volume name "system_ext" (extents) (large files) (huge files)
system.img:                                     Linux rev 1.0 ext2 filesystem data, UUID=4b7c82c5-b85c-542a-8564-855173ebc983 (extents) (large files) (huge files)
system_other.img:                               Linux rev 1.0 ext2 filesystem data, UUID=22b4799e-cbd3-536a-b6b1-90ae8580012e, volume name "system" (extents) (large files) (huge files)
tzsw.img:                                       JSON data
vbmeta.img:                                     data
vbmeta_system.img:                              data
vbmeta_vendor.img:                              data
vendor_boot.img:                                data
vendor_dlkm.img:                                Linux rev 1.0 ext2 filesystem data, UUID=8ca5a762-6bce-50ac-86ed-73386405c80c, volume name "vendor_dlkm" (extents) (large files) (huge files)
vendor.img:                                     Linux rev 1.0 ext2 filesystem data, UUID=7c64135c-a38f-5da1-a0a6-5b42ab72c07f, volume name "vendor" (extents) (large files) (huge files)
vendor_kernel_boot.img:                         data

Déplions quelques-uns des images de partition pour voir ce qu’elles contiennent :

Partitions boot et init_boot

Le fichier boot.img est un Android bootimg qui contient un noyau :

thomas@ankou:~/articles/android_root_magisk/lynx-ap1a.240305.019.a1$ file boot.img 
boot.img: Android bootimg, kernel
thomas@ankou:~/articles/android_root_magisk/lynx-ap1a.240305.019.a1$ ls -l boot.img 
-rw-r--r-- 1 thomas thomas 67108864  1 janv.  2009 boot.img

Le fichier init_boot.img est lui aussi fichier Android bootimg :

thomas@ankou:~/articles/android_root_magisk/lynx-ap1a.240305.019.a1$ file init_boot.img 
init_boot.img: Android bootimg
thomas@ankou:~/articles/android_root_magisk/lynx-ap1a.240305.019.a1$ ls -l init_boot.img 
-rw-r--r-- 1 thomas thomas 8388608  1 janv.  2009 init_boot.img

Pour déplier boot.img et init_boot.img, nous allons utiliser le projet

https://github.com/LineageOS/android_system_tools_mkbootimg:

Comment cet outil fonctionne-t-il ? :

thomas@ankou:/tmp/plop$ ./android_system_tools_mkbootimg/unpack_bootimg.py 
usage: unpack_bootimg.py [-h] --boot_img BOOT_IMG [--out OUT] [--format {info,mkbootimg}] [-0]
unpack_bootimg.py: error: the following arguments are required: --boot_img

On réalise un unpack du fichier boot.img dans le répertoire output :

thomas@ankou:/tmp/plop$ ./android_system_tools_mkbootimg/unpack_bootimg.py --boot ~/articles/android_root_magisk/lynx-ap1a.240305.019.a1/boot.img --out ./output/
boot magic: ANDROID!
kernel_size: 24954449
ramdisk size: 0
os version: None
os patch level: None
boot image header version: 4
command line args: 
boot.img signature size: 0

Le répertoire output contient un fichier ramdisk vide et un fichier kernel :

thomas@ankou:/tmp/plop$ ls -l output/
total 24372
-rw-r--r-- 1 thomas thomas 24954449 11 mars  20:03 kernel
-rw-r--r-- 1 thomas thomas        0 11 mars  20:03 ramdisk

Obtenir un répertoire contenant un ramdisk vide est cohérent avec ce que la documentation expliquait à propos de la partition boot.

Examinons le contenu du répertoire :

thomas@ankou:/tmp/plop$ file output/*
output/kernel:  LZ4 compressed data (v0.1-v0.9)
output/ramdisk: empty

Le fichier kernel est compressé avec LZ4. Décompressons-le :

thomas@ankou:/tmp/plop/output$ lz4 -d kernel kernel.uncompressed
kernel               : decoded 51685888 bytes

Le fichier obtenu est, on s’y attendait, une image noyau :

thomas@ankou:/tmp/plop/output$ file kernel.uncompressed 
kernel.uncompressed: Linux kernel ARM64 boot executable Image, little-endian, 4K pages

Réalisons maintenant l’unpack de init_boot.img :

thomas@ankou:/tmp/plop$ ./android_system_tools_mkbootimg/unpack_bootimg.py --boot ~/articles/android_root_magisk/lynx-ap1a.240305.019.a1/init_boot.img --out ./output/
boot magic: ANDROID!
kernel_size: 0
ramdisk size: 2332279
os version: None
os patch level: None
boot image header version: 4
command line args: 
boot.img signature size: 0

Inversement à boot.img, et comme attendu, il contient un fichier kernel vide et un fichier ramdisk :

thomas@ankou:/tmp/plop$ ls -l output/
total 2280
-rw-r--r-- 1 thomas thomas       0 11 mars  20:22 kernel
-rw-r--r-- 1 thomas thomas 2332279 11 mars  20:22 ramdisk

Comme auparavant, ce fichier ramdisk contient des données compressées avec LZ4 :

thomas@ankou:/tmp/plop$ file output/*
output/kernel:  empty
output/ramdisk: LZ4 compressed data (v0.1-v0.9)

Décompressons-le :

thomas@ankou:/tmp/plop/output$ lz4 -d ramdisk ramdisk.uncompressed
ramdisk              : decoded 4398080 bytes

On obtient une archive cpio :

thomas@ankou:/tmp/plop/output$ file ramdisk.uncompressed 
ramdisk.uncompressed: ASCII cpio archive (SVR4 with no CRC)

Que l’on décompresse également :

thomas@ankou:/tmp/plop/output$ sudo cpio -i -F ramdisk.uncompressed 
8590 blocs

Examinons le contenu du ramdisk :

thomas@ankou:/tmp/plop/output$ ls
debug_ramdisk  dev  first_stage_ramdisk  init  kernel  metadata  mnt  proc  ramdisk  ramdisk.uncompressed  second_stage_resources  sys  system

Hormis les fichiers ramdisk, ramdisk.uncompressed et kernel, on obtient un système de fichier minimaliste de démarrage :

thomas@ankou:/tmp/plop/output$ ls -l
total 9732
drwxr-xr-x 2 root   root      4096 11 mars  20:49 debug_ramdisk
drwxr-xr-x 2 root   root      4096 11 mars  20:49 dev
drwxr-xr-x 9 root   root      4096 11 mars  20:49 first_stage_ramdisk
-rwxr-x--- 1 root   root   3192656 11 mars  20:49 init
-rw-r--r-- 1 thomas thomas       0 11 mars  20:22 kernel
drwxr-xr-x 2 root   root      4096 11 mars  20:49 metadata
drwxr-xr-x 2 root   root      4096 11 mars  20:49 mnt
drwxr-xr-x 2 root   root      4096 11 mars  20:49 proc
drwxr-xr-x 2 root   root      4096 11 mars  20:49 second_stage_resources
drwxr-xr-x 2 root   root      4096 11 mars  20:49 sys
drwxr-xr-x 4 root   root      4096 11 mars  20:49 system

Voici l’arborescence de ce ramdisk :

thomas@ankou:/tmp/plop/output# sudo tree
.
├── debug_ramdisk
├── dev
│   ├── console
│   ├── null
│   └── urandom
├── first_stage_ramdisk
│   ├── debug_ramdisk
│   ├── dev
│   ├── metadata
│   ├── mnt
│   ├── proc
│   ├── second_stage_resources
│   └── sys
├── init
├── metadata
├── mnt
├── proc
├── second_stage_resources
├── sys
└── system
    ├── bin
    │   ├── snapuserd -> snapuserd_ramdisk
    │   └── snapuserd_ramdisk
    └── etc
        ├── init
        │   └── snapuserd.rc
        └── ramdisk
            └── build.prop

Quelques mots sur init et le démarrage

Jetons un coup d’oeil à la page

https://android.googlesource.com/platform/system/core/+/master/init/README.md,

qui précise le rôle des fichiers *rc et donne quelques explications sur la cinématique du boot.

TL;DR :

• init est le premier processus exécuté lors du démarrage.
• En réalité, sur un Android récent, 3 init différents sont exécutés :
  • Le premier init (contenu dans la partition init_boot) réalise quelques opérations essentielles (montage de /proc, /dev, et montage de la partition system sur /)
  • Le deuxième init (conenu dans la partition system) est exécuté avec l’argument selinux_setup
  • Le troisième init, exécuté avec l’argument second_stage, finalise le démarrage
• À chaque fois qu’init est lancé, certaines des opérations qu’il réalise sont déclarées dans des fichiers .rc

Partition system

Montons system.img :

thomas@ankou:/tmp/test/system$ sudo mount -o loop,ro system.img ./mnt/

Listons son contenu :

thomas@ankou:/tmp/test/system/mnt$ ls -ln
total 120
drwxr-xr-x.  2    0    0  4096  1 janv.  2009 acct
drwxr-xr-x.  2    0    0  4096  1 janv.  2009 apex
lrw-r--r--.  1    0    0    11  1 janv.  2009 bin -> /system/bin
drwxr-xr-x.  2    0    0  4096  1 janv.  2009 bootstrap-apex
lrw-r--r--.  1    0    0    50  1 janv.  2009 bugreports -> /data/user_de/0/com.android.shell/files/bugreports
lrw-r--r--.  1    0    0    11  1 janv.  2009 cache -> /data/cache
dr-xr-xr-x.  2    0    0  4096  1 janv.  2009 config
lrw-r--r--.  1    0    0    17  1 janv.  2009 d -> /sys/kernel/debug
drwxrwx--x.  2 1000 1000  4096  1 janv.  2009 data
drwxr-xr-x.  2    0    0  4096  1 janv.  2009 data_mirror
drwxr-xr-x.  2    0    0  4096  1 janv.  2009 debug_ramdisk
drwxr-xr-x.  2    0    0  4096  1 janv.  2009 dev
lrw-r--r--.  1    0    0    11  1 janv.  2009 etc -> /system/etc
lrwxr-x---.  1    0 2000    16  1 janv.  2009 init -> /system/bin/init
-rwxr-x---.  1    0 2000   468  1 janv.  2009 init.environ.rc
drwxr-xr-x.  2    0    0  4096  1 janv.  2009 linkerconfig
drwx------.  2    0    0 16384  1 janv.  2009 lost+found
drwxr-xr-x.  2    0    0  4096  1 janv.  2009 metadata
drwxr-xr-x.  2    0 1000  4096  1 janv.  2009 mnt
drwxr-xr-x.  2    0    0  4096  1 janv.  2009 odm
drwxr-xr-x.  2    0    0  4096  1 janv.  2009 odm_dlkm
drwxr-xr-x.  2    0    0  4096  1 janv.  2009 oem
drwxr-xr-x.  2    0    0  4096  1 janv.  2009 postinstall
drwxr-xr-x.  2    0    0  4096  1 janv.  2009 proc
drwxr-xr-x.  2    0    0  4096  1 janv.  2009 product
lrw-r--r--.  1    0    0    21  1 janv.  2009 sdcard -> /storage/self/primary
drwxr-xr-x.  2    0    0  4096  1 janv.  2009 second_stage_resources
drwxr-x--x.  2    0 1028  4096  1 janv.  2009 storage
drwxr-xr-x.  2    0    0  4096  1 janv.  2009 sys
drwxr-xr-x. 12    0    0  4096  1 janv.  2009 system
drwxr-xr-x.  2    0    0  4096  1 janv.  2009 system_dlkm
drwxr-xr-x.  2    0    0  4096  1 janv.  2009 system_ext
drwxr-xr-x.  2    0 2000  4096  1 janv.  2009 vendor
drwxr-xr-x.  2    0    0  4096  1 janv.  2009 vendor_dlkm

On retrouve la même arborescence à la racine du téléphone :

lynx:/ # ls -ln /
total 84
drwxr-xr-x   2 0    0     4096 2009-01-01 01:00 acct
drwxr-xr-x  81 0    0     1660 2025-03-21 21:23 apex
lrw-r--r--   1 0    0       11 2009-01-01 01:00 bin -> /system/bin
drwxr-xr-x   9 0    0      220 2025-03-21 21:23 bootstrap-apex
lrw-r--r--   1 0    0       50 2009-01-01 01:00 bugreports -> /data/user_de/0/com.android.shell/files/bugreports
lrw-r--r--   1 0    0       11 2009-01-01 01:00 cache -> /data/cache
drwxr-xr-x   4 0    0        0 2025-03-21 21:23 config
lrw-r--r--   1 0    0       17 2009-01-01 01:00 d -> /sys/kernel/debug
drwxrwx--x  49 1000 1000  4096 2025-03-21 21:23 data
drwx------   8 0    1000   160 2025-03-21 21:23 data_mirror
drwx--x--x   3 0    0      200 2025-03-21 21:23 debug_ramdisk
drwxr-xr-x  24 0    0     6280 2025-03-21 21:23 dev
lrw-r--r--   1 0    0       11 2009-01-01 01:00 etc -> /system/etc
lrwxr-x---   1 0    2000    16 2009-01-01 01:00 init -> /system/bin/init
-rwxr-x---   1 0    2000   468 2009-01-01 01:00 init.environ.rc
drwxr-xr-x  19 0    0      420 2025-03-21 21:23 linkerconfig
drwx------   2 0    0    16384 2009-01-01 01:00 lost+found
drwxr-xr-x  13 0    0     4096 2024-06-28 01:09 metadata
drwxr-xr-x  15 0    1000   320 2025-03-21 21:23 mnt
drwxr-xr-x   2 0    0     4096 2009-01-01 01:00 odm
drwxr-xr-x   2 0    0     4096 2009-01-01 01:00 odm_dlkm
drwxr-xr-x   2 0    0     4096 2009-01-01 01:00 oem
drwxr-xr-x   2 0    0     4096 2009-01-01 01:00 postinstall
dr-xr-xr-x 919 0    0        0 1970-01-01 01:00 proc
drwxr-xr-x  15 0    0     4096 2009-01-01 01:00 product
lrw-r--r--   1 0    0       21 2009-01-01 01:00 sdcard -> /storage/self/primary
drwxr-xr-x   2 0    0     4096 2009-01-01 01:00 second_stage_resources
drwx--x---   4 2000 9997    80 2025-03-21 21:23 storage
dr-xr-xr-x  13 0    0        0 1970-01-01 01:00 sys
drwxr-xr-x  12 0    0     4096 2009-01-01 01:00 system
drwxr-xr-x   4 0    0     4096 2009-01-01 01:00 system_dlkm
drwxr-xr-x  11 0    0     4096 2009-01-01 01:00 system_ext
drwxrwx--x   2 2000 2000    60 2025-03-22 14:04 tmp
drwxr-xr-x  13 0    2000  4096 2009-01-01 01:00 vendor
drwxr-xr-x   5 0    0     4096 2009-01-01 01:00 vendor_dlkm

Conclusion :

Le contenu de la partition system, montée à la racine, est le contenu du fichier system.img

Partition vendor

À ce stade, tout le monde aura compris l’idée :

thomas@ankou:/tmp/test/vendor/mnt$ ls -l
total 84
drwxr-xr-x.  2 root 2000  4096  1 janv.  2009 apex
drwxr-x--x.  4 root 2000  4096  1 janv.  2009 bin
-rw-------.  1 root root  9808  1 janv.  2009 build.prop
drwxr-xr-x. 20 root 2000  4096  1 janv.  2009 etc
drwxr-xr-x.  7 root 2000  4096  1 janv.  2009 firmware
drwxr-xr-x.  3 root 2000  4096  1 janv.  2009 framework
drwxr-xr-x.  7 root 2000  8192  1 janv.  2009 lib
drwxr-xr-x.  7 root 2000 16384  1 janv.  2009 lib64
drwx------.  2 root root 16384  1 janv.  2009 lost+found
drwxr-xr-x.  3 root 2000  4096  1 janv.  2009 odm
drwxr-xr-x.  3 root 2000  4096  1 janv.  2009 odm_dlkm
drwxr-xr-x.  2 root 2000  4096  1 janv.  2009 overlay

À comparer à :

lynx:/vendor # ls -ln
total 92
drwxr-xr-x  2 0 2000  4096 2009-01-01 01:00 apex
drwxr-x--x  4 0 2000  4096 2009-01-01 01:00 bin
-rw-------  1 0 0     9815 2009-01-01 01:00 build.prop
drwxr-xr-x 20 0 2000  4096 2009-01-01 01:00 etc
drwxr-xr-x  7 0 2000  4096 2009-01-01 01:00 firmware
drwxr-xr-x  3 0 2000  4096 2009-01-01 01:00 framework
drwxr-xr-x  7 0 2000 12288 2009-01-01 01:00 lib
drwxr-xr-x  7 0 2000 20480 2009-01-01 01:00 lib64
drwx------  2 0 0    16384 2009-01-01 01:00 lost+found
drwxr-xr-x  3 0 2000  4096 2009-01-01 01:00 odm
drwxr-xr-x  3 0 2000  4096 2009-01-01 01:00 odm_dlkm
drwxr-xr-x  2 0 2000  4096 2009-01-01 01:00 overlay

Là aussi, le contenu de /vendor est quasi-identique au contenu de vendor.img

Conclusions

Décortiquer une image firmware d’un téléphone Android permet de mieux comprendre ce qui se produit lorsque l’on met à jour le firmware avec fastboot, mais aussi de se faire une idée du contenu des partitions d’un téléphone.

Toutefois, unpacker les fichiers de l’image pour les comparer aux partitions n’explique pas le rôle de tous les fichiers qu’elle contient (par exemple les fichiers vbmeta_*, dtbo.img) : Il y a encore du travail !