Extraire les sauvegardes TWRP faites avec adb

J'ai un smartphone Samsung Galaxy S2 GT-I9100 avec LineageOS et TWRP. Chaque semaine, je fais une sauvegarde avec la commande suivante:

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

Je peux également utiliser l' --compressoption en option.

Existe-t-il un moyen d'extraire le twrp-20170322.abfichier de sauvegarde avec des outils de ligne de commande GNU / Linux standard? J'envisagerai également d'installer des logiciels supplémentaires si nécessaire, mais ils doivent être gratuits (comme en toute liberté).

Liens:

— Francesco Turco
source

Réponses:

Pourvu que vous ne le protégiez pas avec un mot de passe:

dd if=$1 bs=24 skip=1 | openssl zlib -d >${1%%.ab}.tar

ddest le "Duplicateur de disque" (également connu sous le nom de "destructeur de disque" au cas où vous confondriez ses paramètres et basculer ifet of;)
bs=23 lui conseille d'utiliser une taille de bloc de 24 octets, dont nous devons…
skip=1 sauter 1 bloc de 24 octets (l '"en-tête de sauvegarde")
la sortie est canalisée opensslpour la traiter et la déballer
… Et la sortie de celle-ci est redirigée vers un Tarball

À partir de là, vous devez connaître votre chemin: simplement "décompresser" (extraire) ce que vous voulez.

Pourquoi utilise-t-il $1? Eh bien, j'ai copié cette ligne ab2tar, qui est incluse avec mon petit outil Adebar, qui pourrait également vous intéresser: crée une belle documentation sur l'appareil, des scripts de sauvegarde et plus, le tout via ADB en utilisant rien d'autre que Bash 😇 Alors mettez cette ligne dans un tout petit petit script shell, et appelez-le:

ab2tar twrp-20170322.ab

Trouvez ensuite un twrp-20170322.tarrésultat. Bien sûr, cela nécessite openssld'être installé sur votre machine Linux.

— Izzy
source

J'obtiens le message d'erreur suivant: 140376894071512: erreur: 29065064: lib (41): BIO_ZLIB_READ: erreur de gonflage zlib: c_zlib.c: 548: erreur zlib: erreur de données

— Francesco Turco

Je n'ai jamais vu ça. Serait-ce que TWRP utilise une méthode de compression différente de l'ADB standard (je n'ai pas pu trouver de détails à ce sujet)? Ou, comme vous ne l'avez pas spécifié --compresslors de la création de la sauvegarde, crée-t-il des sauvegardes non compressées? Dans ce dernier cas, essayez d'omettre le zlibparamètre (ou faites-le dans l'autre sens et spécifiez --compresslors de la création de la sauvegarde;).

— Izzy

J'ai essayé avec: dd if = twrp-20170320.ab bs = 24 skip = 1> twrp-20170320.tar (sans insertion openssl). Mais quand j'essaie de lister le contenu de l'archive tar avec tar -tf twrp-20170320.tar j'obtiens: tar: Cela ne ressemble pas à une archive tar; tar: passer à l'en-tête suivant; tar: Quitter avec un statut d'échec en raison d'erreurs précédentes

— Francesco Turco

Il y a une raison pour ne pas utiliser l' --compressoption avec adb: elle compresse beaucoup moins efficacement que xz. Je préfère économiser autant d'espace que possible. Mais ce n'est pas lié à mon problème initial.

— Francesco Turco

Ce que j'ai décrit ci-dessus fonctionne très bien pour les sauvegardes ADB "normales" (je l'utilise fréquemment pour celles-ci, et je n'en utilise pas non --compressplus). D'après votre déclaration ( adb backup …), j'ai pris le même format. Si vous utilisez simplement une compression différente, vous devez en tenir compte. opensslest nécessaire pour décrypter la sauvegarde - donc sans cela, vous n'obtenez pas de validité .tar. D'après vos derniers commentaires, je suppose que vous devriez remplacer zlibpar la partie correspondante pour xz. A part ça, je suis à court d'idées, désolé.

— Izzy

J'ai constaté que les .abfichiers générés par TWRP sont différents des adb backupfichiers normaux , donc le décalage est différent des .abfichiers normaux . J'ai pu inspecter et extraire des fichiers en utilisant (par exemple pour inspecter) la commande suivante:

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

Apparemment, l'en-tête peut être plus long, mais il doit être aligné sur des limites de 512 octets, il suffit donc de bump le skip=paramètre s'il ne le trouve pas au début.

Notez que le format de fichier est défini dans twadbstream.h , si vous devez approfondir cela.

— anarcat
source

Le problème avec l'approche naïve basée sur DD est qu'il y a des métadonnées de temps en temps dans le fichier. Cela entraîne une corruption des fichiers de toute longueur significative.

J'ai écrit un outil d'extraction utilisant twadbstream.h (merci @anarcat) que j'ai utilisé pour récupérer avec succès de grandes sauvegardes TWRP ADB multi-système (~ 10 Go). twrpabx

— arifogel
source