Introduction

Les blobs propriétaires peuvent être extraits soit depuis un appareil sur lequel /e/OS est déjà installé, soit depuis un zip d’installation /e/OS. Dans ce guide, nous décrivons les étapes nécessaires pour extraire les fichiers propriétaires depuis des zips d’installation.

Avant de commencer, il faut connaître la différence entre les types d’OTA :

  • OTA par blocs (block-based) : le contenu de la partition system est stocké dans un fichier .dat/.dat.br sous forme de données binaires.

  • OTA par fichiers (file-based) : le contenu de la partition system est disponible dans un dossier du zip nommé system.

  • OTA par payload (payload-based) : le contenu de la partition system est stocké sous forme de fichier .img à l’intérieur de payload.bin.

Si votre zip n’a pas de dossier system ou que celui-ci est quasiment vide, et qu’un fichier nommé system.transfer.list existe à la racine, alors vous avez un OTA par blocs. Dans ce cas, passez à Extraire les blobs propriétaires depuis des OTA par blocs.

Si vous avez l’intégralité du contenu de la partition system dans le dossier system et pas de system.transfer.list, alors vous avez un OTA par fichiers. Consultez Extraire les blobs propriétaires depuis des OTA par fichiers.

Vous pouvez aussi avoir un OTA par payload, ce que votre appareil utilise s’il repose sur le partitionnement A/B. Si c’est votre cas, passez à Extraire les blobs propriétaires depuis des OTA par payload.

Extraire les blobs propriétaires depuis des OTA par blocs

Certains OTA par blocs sont découpés en plusieurs fichiers, pour la partition system et les autres partitions comme vendor, product, oem, odm et d’autres. Vous pouvez vérifier si le vôtre est découpé en cherchant les fichiers *.transfer.list correspondants pour chacune, à la racine du zip d’installation /e/OS.

Si vous avez un fichier OTA par blocs découpé, vous devrez extraire, décompresser et convertir chacun d’eux de la même manière que system et vendor, comme décrit ci-dessous.

Si vous n’avez pas de fichier OTA découpé, vous pouvez sauter toute étape qui fait référence à vendor.transfer.list et vendor.new.dat.br ou vendor.new.dat

Créez un répertoire temporaire et rendez-vous y :

mkdir ~/android/system_dump/
cd ~/android/system_dump/

Extrayez system.transfer.list et system.new.dat.br ou system.new.dat du zip d’installation //e/OS :

unzip path/to/e-*.zip system.transfer.list system.new.dat*

où path/to/ est le chemin vers le zip d’installation.

Si votre OTA inclut vendor.transfer.list et vendor.new.dat.br ou vendor.new.dat (ou d’autres), extrayez-les également du zip d’installation /e/OS :

unzip path/to/e-*.zip vendor.transfer.list vendor.new.dat*

où path/to/ est le chemin vers le zip d’installation.

Si un fichier system.new.dat.br/vendor.new.dat.br/etc. (une archive brotli) existe, vous devrez d’abord les décompresser avec l’utilitaire brotli :

sudo apt-get install brotli
brotli --decompress --output=system.new.dat system.new.dat.br

Et si vous avez un fichier vendor.dat.new.br (ou d’autres) :

brotli --decompress --output=vendor.new.dat vendor.new.dat.br

Vous devez maintenant récupérer une copie de sdat2img. Ce script peut convertir le contenu des OTA par blocs en dumps qui peuvent être montés. sdat2img est disponible dans le dépôt git suivant, que vous pouvez cloner avec :

git clone https://github.com/xpirt/sdat2img

Une fois sdat2img obtenu, utilisez-le pour extraire l’image system :

python sdat2img/sdat2img.py system.transfer.list system.new.dat system.img

Et si vous avez un fichier vendor.dat.new (ou d’autres) :

python sdat2img/sdat2img.py vendor.transfer.list vendor.new.dat vendor.img

Vous devriez maintenant avoir un fichier nommé system.img que vous pouvez monter comme suit :

mkdir system/
sudo mount system.img system/

Si vous avez aussi un fichier nommé vendor.img, vous pouvez le monter comme suit :

sudo rm system/vendor
sudo mkdir system/vendor
sudo mount vendor.img system/vendor/

Vous devez également monter maintenant tous les autres fichiers image dont vous disposez, dans leurs répertoires respectifs.

Après avoir monté la ou les images, rendez-vous à la racine des sources de votre appareil et exécutez extract-files.sh comme suit :

./extract-files.sh ~/android/system_dump/

Cela indique à extract-files.sh de récupérer les fichiers depuis le dump system monté plutôt que depuis un appareil connecté.

Une fois tous les fichiers propriétaires extraits, démontez le dump vendor si vous l’aviez monté :

sudo umount ~/android/system_dump/system/vendor

Puis démontez le dump system :

sudo umount ~/android/system_dump/system

Enfin, démontez toute autre image avant de supprimer les fichiers devenus inutiles :

rm -rf ~/android/system_dump/

Extraire les blobs propriétaires depuis des OTA par fichiers

Créez un répertoire temporaire pour extraire le contenu du zip et rendez-vous y :

mkdir ~/android/system_dump/
cd ~/android/system_dump/

Extrayez le dossier system du zip :

unzip path/to/e-*.zip system/*

où path/to/ est le chemin vers le zip d’installation.

Après avoir extrait le dossier system, rendez-vous à la racine des sources de votre appareil et exécutez extract-files.sh comme suit :

./extract-files.sh ~/android/system_dump/

Cela indique à extract-files.sh de récupérer les fichiers depuis le dump system extrait plutôt que depuis un appareil connecté.

Une fois tous les fichiers propriétaires extraits, vous pouvez supprimer les fichiers qui ont été extraits du zip :

rm -rf ~/android/system_dump/

Extraire les blobs propriétaires depuis des OTA par payload

Créez un répertoire temporaire pour extraire le contenu du zip et rendez-vous y :

mkdir ~/android/system_dump/
cd ~/android/system_dump/

Extrayez le fichier payload.bin du zip d’installation /e/OS :

unzip /path/to/e-*.zip payload.bin

où /path/to/ est le chemin vers le zip d’installation.

Vous devrez maintenant utiliser un outil nommé update-payload-extractor.

Pour utiliser cet outil, vous aurez besoin de python-protobuf, si vous ne l’avez pas déjà :

sudo apt-get install python-protobuf

Vous pouvez maintenant extraire les fichiers .img du payload :

  • Si vous avez déjà une arborescence de build /e/OS récupérée, vous pouvez simplement exécuter le script pour extraire le payload :

    python /path/to/e-tree/e/scripts/update-payload-extractor/extract.py payload.bin --output_dir ./

  • Si vous n’avez pas d’arborescence de build /e/OS, vous pouvez cloner notre dépôt de scripts, puis exécuter le script pour extraire le payload :

    git clone https://github.com/LineageOS/scripts
python /path/to/scripts/update-payload-extractor/extract.py payload.bin --output_dir ./

Cela prend quelques instants. Une fois terminé, nous devons monter le fichier system.img, ainsi que les fichiers vendor.img et product.img s’ils existent, pour obtenir l’ensemble complet des blobs propriétaires :

mkdir system/
sudo mount system.img system/
sudo mount vendor.img system/vendor/
sudo mount product.img system/product/

Rendez-vous à la racine des sources de votre appareil et exécutez extract-files.sh comme suit :

./extract-files.sh ~/android/system_dump/

Cela indique à extract-files.sh d’extraire les blobs propriétaires depuis le dump system monté plutôt que depuis un appareil connecté.

Une fois terminé, démontez le dump system et supprimez les fichiers devenus inutiles :

sudo umount -R ~/android/system_dump/system/
rm -rf ~/android/system_dump/