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
dd
est le "Duplicateur de disque" (également connu sous le nom de "destructeur de disque" au cas où vous confondriez ses paramètres et basculer if
et 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
openssl
pour 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.tar
résultat. Bien sûr, cela nécessite openssl
d'être installé sur votre machine Linux.
--compress
lors de la création de la sauvegarde, crée-t-il des sauvegardes non compressées? Dans ce dernier cas, essayez d'omettre lezlib
paramètre (ou faites-le dans l'autre sens et spécifiez--compress
lors de la création de la sauvegarde;).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--compress
option avecadb
: elle compresse beaucoup moins efficacement quexz
. Je préfère économiser autant d'espace que possible. Mais ce n'est pas lié à mon problème initial.--compress
plus). 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.openssl
est 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 remplacerzlib
par la partie correspondante pourxz
. A part ça, je suis à court d'idées, désolé.J'ai constaté que les
.ab
fichiers générés par TWRP sont différents desadb backup
fichiers normaux , donc le décalage est différent des.ab
fichiers normaux . J'ai pu inspecter et extraire des fichiers en utilisant (par exemple pour inspecter) la commande suivante: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.
la 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
la source