Einführung

Proprietäre Blobs können entweder von einem Gerät extrahiert werden, auf dem bereits /e/OS läuft, oder aus einer installierbaren /e/OS-ZIP-Datei. In dieser Anleitung beschreiben wir die Schritte zum Extrahieren proprietärer Dateien aus installierbaren ZIP-Dateien.

Bevor Sie beginnen, müssen Sie den Unterschied zwischen den OTA-Typen kennen:

  • Block-basiertes OTA: Der Inhalt der System-Partition wird als Binärdaten innerhalb einer .dat/.dat.br-Datei gespeichert.

  • Datei-basiertes OTA: Der Inhalt der System-Partition liegt in einem Ordner namens system innerhalb der ZIP-Datei vor.

  • Payload-basiertes OTA: Der Inhalt der System-Partition wird als .img-Datei innerhalb von payload.bin gespeichert.

Wenn Ihre ZIP-Datei keinen system-Ordner enthält oder dieser nahezu leer ist und auf oberster Ebene eine Datei namens system.transfer.list existiert, handelt es sich um ein block-basiertes OTA. Springen Sie in diesem Fall zu Proprietäre Blobs aus block-basierten OTAs extrahieren.

Wenn Sie den gesamten Inhalt der System-Partition im system-Ordner vorfinden und keine system.transfer.list vorhanden ist, handelt es sich um ein datei-basiertes OTA. Siehe Proprietäre Blobs aus datei-basierten OTAs extrahieren.

Möglicherweise haben Sie auch ein payload-basiertes OTA, das Ihr Gerät verwendet, wenn es das A/B-Partitionierungssystem nutzt. Springen Sie in diesem Fall zu Proprietäre Blobs aus payload-basierten OTAs extrahieren.

Proprietäre Blobs aus block-basierten OTAs extrahieren

Manche block-basierten OTAs sind in mehrere Dateien aufgeteilt, für die System-Partition und die anderen Partitionen wie vendor, product, oem, odm und weitere. Ob Ihre so aufgeteilt ist, erkennen Sie an den entsprechenden *.transfer.list-Dateien im Stammverzeichnis der installierbaren /e/OS-ZIP-Datei.

Wenn Sie eine aufgeteilte block-basierte OTA-Datei haben, müssen Sie jede davon auf ähnliche Weise wie system und vendor unten beschrieben extrahieren, dekomprimieren und konvertieren.

Wenn Sie keine aufgeteilte OTA-Datei haben, können Sie jeden Schritt überspringen, der sich auf vendor.transfer.list und vendor.new.dat.br oder vendor.new.dat bezieht.

Erstellen Sie ein temporäres Verzeichnis und wechseln Sie dorthin:

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

Extrahieren Sie system.transfer.list und system.new.dat.br oder system.new.dat aus der installierbaren /e/OS-ZIP-Datei:

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

wobei path/to/ der Pfad zur installierbaren ZIP-Datei ist.

Wenn Ihr OTA vendor.transfer.list und vendor.new.dat.br oder vendor.new.dat (oder andere) enthält, extrahieren Sie diese ebenfalls aus der installierbaren /e/OS-ZIP-Datei:

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

wobei path/to/ der Pfad zur installierbaren ZIP-Datei ist.

Falls system.new.dat.br/vendor.new.dat.br/usw. (ein Brotli-Archiv) vorhanden ist, müssen Sie diese zunächst mit dem Werkzeug brotli dekomprimieren:

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

Und falls Sie eine Datei vendor.dat.new.br (oder andere) haben:

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

Jetzt benötigen Sie eine Kopie von sdat2img. Dieses Skript kann den Inhalt block-basierter OTAs in Dumps umwandeln, die gemountet werden können. sdat2img ist im folgenden Git-Repository verfügbar, das Sie wie folgt klonen können:

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

Sobald Sie sdat2img haben, extrahieren Sie damit das Systemabbild:

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

Und falls Sie eine Datei vendor.dat.new (oder andere) haben:

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

Sie sollten nun eine Datei namens system.img haben, die Sie wie folgt mounten können:

mkdir system/
sudo mount system.img system/

Falls Sie auch eine Datei namens vendor.img haben, können Sie diese wie folgt mounten:

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

Sie müssen nun auch alle weiteren vorhandenen Abbilddateien in ihre jeweiligen Verzeichnisse mounten.

Nachdem Sie die Abbilder gemountet haben, wechseln Sie in das Stammverzeichnis der Quellen Ihres Geräts und führen Sie extract-files.sh wie folgt aus:

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

Dies weist extract-files.sh an, die Dateien aus dem gemounteten Systemdump zu holen statt von einem verbundenen Gerät.

Sobald Sie alle proprietären Dateien extrahiert haben, hängen Sie den Vendor-Dump aus, falls Sie ihn zuvor gemountet haben:

sudo umount ~/android/system_dump/system/vendor

Hängen Sie anschließend den Systemdump aus:

sudo umount ~/android/system_dump/system

Hängen Sie schließlich alle weiteren Abbilder aus, bevor Sie die nicht mehr benötigten Dateien löschen:

rm -rf ~/android/system_dump/

Proprietäre Blobs aus datei-basierten OTAs extrahieren

Erstellen Sie ein temporäres Verzeichnis, um den Inhalt der ZIP-Datei zu extrahieren, und wechseln Sie dorthin:

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

Extrahieren Sie den system-Ordner aus der ZIP-Datei:

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

wobei path/to/ der Pfad zur installierbaren ZIP-Datei ist.

Nachdem Sie den system-Ordner extrahiert haben, wechseln Sie in das Stammverzeichnis der Quellen Ihres Geräts und führen Sie extract-files.sh wie folgt aus:

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

Dies weist extract-files.sh an, die Dateien aus dem extrahierten Systemdump zu holen statt von einem verbundenen Gerät.

Sobald Sie alle proprietären Dateien extrahiert haben, können Sie die aus der ZIP-Datei extrahierten Dateien löschen:

rm -rf ~/android/system_dump/

Proprietäre Blobs aus payload-basierten OTAs extrahieren

Erstellen Sie ein temporäres Verzeichnis, um den Inhalt der ZIP-Datei zu extrahieren, und wechseln Sie dorthin:

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

Extrahieren Sie die Datei payload.bin aus der /e/OS-Installations-ZIP-Datei:

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

wobei /path/to/ der Pfad zur installierbaren ZIP-Datei ist.

Nun benötigen Sie ein Werkzeug namens update-payload-extractor.

Um das Werkzeug zu verwenden, benötigen Sie python-protobuf, falls noch nicht vorhanden:

sudo apt-get install python-protobuf

Sie können nun die .img-Dateien aus dem Payload extrahieren:

  • Wenn Sie bereits einen /e/OS-Build-Tree ausgecheckt haben, können Sie einfach das Skript ausführen, um den Payload zu extrahieren:

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

  • Wenn Sie keinen /e/OS-Build-Tree ausgecheckt haben, können Sie unser Skripte-Repository klonen und dann das Skript ausführen, um den Payload zu extrahieren:

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

Es wird einen Moment dauern. Sobald es fertig ist, müssen wir die Datei system.img sowie, falls vorhanden, die Dateien vendor.img und product.img mounten, um den vollständigen Satz proprietärer Blobs zu erhalten:

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

Wechseln Sie in das Stammverzeichnis der Quellen Ihres Geräts und führen Sie extract-files.sh wie folgt aus:

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

Dies weist extract-files.sh an, die proprietären Blobs aus dem gemounteten Systemdump statt von einem verbundenen Gerät zu extrahieren.

Sobald dies abgeschlossen ist, hängen Sie den Systemdump aus und entfernen Sie die nun nicht mehr benötigten Dateien:

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