Extrahieren Sie TWRP-Backups, die mit adb erstellt wurden


10

Ich habe ein Samsung Galaxy S2 GT-I9100 Smartphone mit LineageOS und TWRP. Jede Woche mache ich ein Backup mit dem folgenden Befehl:

adb backup -f twrp-20170322.ab --twrp boot data system

Optional kann ich die --compressOption auch verwenden.

Gibt es eine Möglichkeit, die twrp-20170322.abSicherungsdatei mit den Standard-GNU / Linux-Befehlszeilentools zu extrahieren ? Ich werde auch in Betracht ziehen, bei Bedarf zusätzliche Software zu installieren, diese muss jedoch kostenlos sein (wie in Freiheit).

Links:

Antworten:


1

Vorausgesetzt, Sie haben es nicht mit einem Passwort geschützt:

dd if=$1 bs=24 skip=1 | openssl zlib -d >${1%%.ab}.tar
  • ddist der "Disk Duplicator" (auch als "Disk Destroyer" bekannt, falls Sie seine Parameter verwechseln ifund schalten und of;)
  • bs=23 empfiehlt die Verwendung einer Blockgröße von 24 Byte, die wir benötigen, um…
  • skip=1 1 Block mit 24 Byte überspringen (der "Backup-Header")
  • Die Ausgabe wird weitergeleitet, um sie opensslzu verarbeiten und zu entpacken
  • … Und die Ausgabe davon wird an einen Tarball umgeleitet

Von dort aus sollten Sie Ihren Weg kennen: einfach "entpacken" (extrahieren), was Sie wollen.

Warum verwendet es $1? Nun, ich habe diese Zeile aus kopiert ab2tar, die in meinem kleinen Tool Adebar enthalten ist, an dem Sie vielleicht auch interessiert sind: Erstellt eine schöne Gerätedokumentation, Sicherungsskripte und mehr, alles über ADB, wobei nur Bash verwendet wird kleines Shell-Skript, und nennen Sie es:

ab2tar twrp-20170322.ab

Dann finden Sie ein twrp-20170322.tarals Ergebnis. Dies muss natürlich opensslauf Ihrem Linux-Computer installiert sein.


Ich erhalte die folgende Fehlermeldung: 140376894071512: Fehler: 29065064: lib (41): BIO_ZLIB_READ: Zlib-Inflate-Fehler: c_zlib.c: 548: Zlib-Fehler: Datenfehler
Francesco Turco

Das habe ich noch nie gesehen. Könnte es sein, dass TWRP eine andere Komprimierungsmethode als Standard-ADB verwendet (Details dazu konnte ich nicht finden)? Oder, wie Sie --compressbeim Erstellen des Backups nicht angegeben haben , unkomprimierte Backups erstellen? Versuchen Sie im letzteren Fall, den zlibParameter wegzulassen (oder machen Sie es umgekehrt und geben Sie ihn --compressbeim Erstellen des Backups an;).
Izzy

Ich habe versucht mit: dd if = twrp-20170320.ab bs = 24 skip = 1> twrp-20170320.tar (ohne Einfügen openssl). Aber wenn ich versuche, den Inhalt des tar-Archivs mit tar -tf twrp-20170320.tar aufzulisten, erhalte ich: tar: Dies sieht nicht wie ein tar-Archiv aus; tar: Zum nächsten Header springen; Teer: Beenden mit Fehlerstatus aufgrund früherer Fehler
Francesco Turco

Es gibt einen Grund, die --compressOption nicht zu verwenden adb: Sie komprimiert viel weniger effizient als xz. Ich bevorzuge es, so viel Platz wie möglich zu sparen. Aber das hängt nicht mit meinem anfänglichen Problem zusammen.
Francesco Turco

Was ich oben beschrieben habe, funktioniert gut für "normale" ADB-Backups (ich verwende es häufig für diese und ich verwende dort auch kein --compress). Aus Ihrer Aussage ( adb backup …) habe ich das gleiche Format angenommen. Wenn Sie nur eine andere Komprimierung verwenden, müssen Sie dies berücksichtigen. opensslwird benötigt, um das Backup zu entschlüsseln - ohne das erhalten Sie keine gültige .tar. Aus Ihren letzten Kommentaren würde ich annehmen, dass Sie zlibdurch das entsprechende Teil für ersetzen sollten xz. Abgesehen davon habe ich keine Ideen mehr, sorry.
Izzy

1

Ich habe festgestellt, dass TWRP-generierte .abDateien sich von den normalen adb backupDateien unterscheiden, sodass sich der Offset von normalen .abDateien unterscheidet. Ich konnte Dateien mit dem folgenden Befehl überprüfen und extrahieren (z. B. um sie zu überprüfen):

dd if=backup.ab bs=512 skip=1 | tar ft -

Anscheinend kann der Header länger sein, aber er sollte an 512-Byte-Grenzen ausgerichtet sein. Erhöhen Sie also einfach den skip=Parameter, wenn er zuerst nicht gefunden werden kann.

Beachten Sie, dass das Dateiformat in twadbstream.h definiert ist , wenn Sie sich weiter damit befassen müssen.


0

Das Problem mit dem naiven dd-basierten Ansatz ist, dass die Datei von Zeit zu Zeit Metadaten enthält. Dies führt zu einer Beschädigung von Dateien mit einer signifikanten Länge.

Ich habe ein Extraktions-Tool mit twadbstream.h geschrieben (danke @anarcat), mit dem ich große TWRP ADB-Backups mit mehreren Dateisystemen (~ 10 GB) erfolgreich wiederhergestellt habe. twrpabx

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.