11

I have a Samsung Galaxy S2 GT-I9100 smartphone with LineageOS and TWRP. Every week I make a backup with the following command:

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

I may optionally use the --compress option, too.

Is there a way to extract the twrp-20170322.ab backup file with stardard GNU/Linux command line tools? I will also consider installing extra software if needed, but it must be free (as in freedom).

Links:

Improve this question

3 Answers 3

Reset to default
2

I have found that TWRP-generated .ab files are different from the normal adb backup files, so the offset is different from normal .ab files. I was able to inspect and extract files using (for example to inspect) the following command:

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

Apparently, the header may be longer, but it should be aligned with 512-bytes boundaries, so just bump the skip= parameter if it can't find it at first.

Note that the file format is defined in twadbstream.h, if you need to dig into this further.

Improve this answer
2

The problem with the naive dd-based approach is that there is metadata every so often in the file. This results in corruption for files of any significant length.

I wrote an extraction tool utilizing twadbstream.h (thanks @anarcat) that I have used to successfully recover large (~10GB) multi-filesystem TWRP ADB backups. twrpabx

Improve this answer
3
  • Thank you! Your tool worked for me after applying these patches mentioned in the Github issues github.com/prudy/twrpabx/tree/img_and_issue4
    – TrojanName
    Commented Apr 11, 2021 at 12:02
  • @TrojanName were you able to extract multi partitions backup with these patches?
    – Sandro Antonucci
    Commented Jan 23, 2022 at 23:30
  • @SandroAntonucci Yes I think it did
    – TrojanName
    Commented Jan 27, 2022 at 14:59
1

Provided you didn't protect it with a password:

dd if=$1 bs=24 skip=1 | openssl zlib -d >${1%%.ab}.tar
  • dd is the "Disk Duplicator" (also known as "disk destroyer" in case you confuse its parameters ans switch if and of ;)
  • bs=23 advises it to use a block size of 24 byte, which we need to…
  • skip=1 skip 1 block of 24 byte (the "Backup header")
  • the output gets piped to openssl to process and unpack it
  • … and the output from that is redirected to a Tarball

From there, you should know your way: simply "untar" (extract) what you want.

Why it uses $1? Well, I copied this line from ab2tar, which is included with my little tool Adebar you might be interested in as well: creates a nice device documentation, backup scripts and more, all via ADB using nothing but Bash 😇 So put that line in a tiny little shell script, and call it:

ab2tar twrp-20170322.ab

Then find a twrp-20170322.tar as result. Of course, this requires openssl to be installed on your Linux machine.

Improve this answer
10
  • I get the following error message: 140376894071512:error:29065064:lib(41):BIO_ZLIB_READ:zlib inflate error:c_zlib.c:548:zlib error:data error
    – user212450
    Commented Mar 23, 2017 at 10:42
  • Never seen that. Could it be TWRP uses a different compression method than standard ADB (I couldn't find details on that)? Or, as you didn't specify --compress when creating the backup, creates uncompressed backups? In the latter case, try leaving out the zlib parameter (or do it the other way around and specify --compress when creating the backup ;).
    – Izzy
    Commented Mar 23, 2017 at 10:51
  • I tried with: dd if=twrp-20170320.ab bs=24 skip=1 > twrp-20170320.tar (without inserting openssl). But when I try to list the contents of the tar archive with tar -tf twrp-20170320.tar I get: tar: This does not look like a tar archive; tar: Skipping to next header; tar: Exiting with failure status due to previous errors
    – user212450
    Commented Mar 23, 2017 at 12:42
  • There's a reason for not using the --compress option with adb: it compresses way less efficiently than xz. I prefer to save as much space as possible. But that's not related to my initial problem.
    – user212450
    Commented Mar 23, 2017 at 12:44
  • What I described above works fine for "normal" ADB backups (I use it frequently for those, and I don't use a --compress there either). From your statement (adb backup …) I assumed the very same format. If you're just using a different compression, you must consider that. openssl is needed to decrypt the backup – so without that, you don't get a valid .tar. From your last comments, I'd assume you should replace zlib by the corresponding part for xz. Apart from that, I'm out of ideas, sorry.
    – Izzy
    Commented Mar 23, 2017 at 13:11

You must log in to answer this question.