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



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.


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


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.

  • 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 Mar 23 '17 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 Mar 23 '17 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 Mar 23 '17 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 Mar 23 '17 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 Mar 23 '17 at 13:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy