Extrahieren Sie TWRP-Backups, die mit adb erstellt wurden

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 nutzen.

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

Verbindungen:

Antworten (3)

Ich habe festgestellt, dass sich TWRP-generierte .abDateien von den normalen adb backupDateien unterscheiden, daher unterscheidet sich der Offset von normalen .abDateien. Ich war in der Lage, Dateien mit dem folgenden Befehl zu inspizieren und zu extrahieren (zum Beispiel zum Inspizieren):

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, also stoßen Sie einfach den skip=Parameter, wenn er ihn zuerst nicht finden kann.

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

Das Problem mit dem naiven dd-basierten Ansatz besteht darin, dass die Datei hin und wieder Metadaten enthält. Dies führt zu einer Beschädigung von Dateien beliebiger Länge.

Ich habe ein Extraktionstool unter Verwendung von twadbstream.h (danke @anarcat) geschrieben, das ich verwendet habe, um große (~10 GB) Multi-Dateisystem-TWRP-ADB-Backups erfolgreich wiederherzustellen. twrpabx

Danke dir! Ihr Tool hat für mich funktioniert, nachdem ich diese Patches angewendet hatte, die in den Github-Problemen github.com/prudy/twrpabx/tree/img_and_issue4 erwähnt wurden
@TrojanName konnten Sie mit diesen Patches Backups mit mehreren Partitionen extrahieren?
@SandroAntonucci Ja, ich denke schon

Sofern Sie es nicht mit einem Passwort geschützt haben:

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 und wechseln ifund of;)
  • bs=23rät ihm, eine Blockgröße von 24 Byte zu verwenden, die wir brauchen, um…
  • skip=11 Block von 24 Byte überspringen (der "Backup-Header")
  • die Ausgabe wird weitergeleitet, um opensslsie zu verarbeiten und zu entpacken
  • … und die Ausgabe davon wird in einen Tarball umgeleitet

Von da an sollten Sie Ihren Weg kennen: einfach "enttarnen" (extrahieren), was Sie wollen.

Warum verwendet es $1? Nun, ich habe diese Zeile aus kopiert ab2tar, die in meinem kleinen Tool Adebar enthalten ist, das Sie vielleicht auch interessieren könnte: erstellt eine nette Gerätedokumentation, Backup-Skripte und mehr, alles über ADB, nur mit Bash 😇 Also packen Sie diese Zeile in eine winzige kleines Shell-Skript, und nennen Sie es:

ab2tar twrp-20170322.ab

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

Ich bekomme folgende Fehlermeldung: 140376894071512:error:29065064:lib(41):BIO_ZLIB_READ:zlib inflate error:c_zlib.c:548:zlib error:data error
Nie gesehen. Könnte es sein, dass TWRP eine andere Komprimierungsmethode als Standard-ADB verwendet (ich konnte keine Details dazu finden)? Oder, wie Sie es beim Erstellen des Backups nicht angegeben --compresshaben, 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 ;).
Ich habe es versucht mit: dd if=twrp-20170320.ab bs=24 skip=1 > twrp-20170320.tar (ohne Einfügen von 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; tar: Beenden mit Fehlerstatus aufgrund früherer Fehler
Es gibt einen Grund, die --compressOption mit nicht zu verwenden adb: Sie komprimiert viel weniger effizient als xz. Ich bevorzuge es, so viel Platz wie möglich zu sparen. Aber das hat nichts mit meinem anfänglichen Problem zu tun.
Was ich oben beschrieben habe, funktioniert gut für "normale" ADB-Backups (ich verwende es häufig für diese, und ich verwende --compressdort auch kein). 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 also keine gültige .tar. Aus Ihren letzten Kommentaren gehe ich davon aus, dass Sie zlibdurch den entsprechenden Teil für ersetzen sollten xz. Abgesehen davon gehen mir die Ideen aus, sorry.
Soweit ich das beurteilen kann, funktioniert dieses Verfahren nur mit "normalen" (dh nicht von TWRP) generierten Sicherungen. Wenn TWRP den Stream sendet, schlägt es einen neuen Header darüber, der länger ist (512 Bytes). siehe android.stackexchange.com/a/180402/158769 für eine Lösung, die für mich funktioniert hat.
@anarcat Danke für den Hinweis! Mein Ansatz ist also immer noch gültig, man muss nur eine andere Sektorgröße überspringen – und kann das gesamte Openssl-Zeug überspringen?
@Izzy Ihre Antwort ist für die Adb-Sicherung und funktioniert nicht für die TWRP-Sicherung. Überprüfen Sie mein Skript twab.sh
Umpf, du sagst also, hier adb backupwird kein "ADB-Backup" erstellt? Das ist ziemlich verwirrend.
Es hat data.ext4.wineinen 1536-Byte-Header, ist aber in Datenblöcke "aufgebrochen". es kann auch mehrere Partitionen enthalten sourceforge.net/p/adbextractor/discussion/general/thread/…
Extrahieren Sie TWRP-Backups, die mit adb erstellt wurden
AntwortenHierDatenschutz-Bestimmungen1y, 0v