I created a backup of my Galaxy Nexus with adb backup. The resulting file is named backup.db and it's somehow encrypted.

I wanted to restore the backup, but it stops when it comes to restoring com.android.providers.contacts. I used adb logcat to find out what's going on and found out that com.android.acore crashes during the restore process.

I'd like to gain access to the data in the backup and remove the contacts database to restore everything back to my phone. Are there any other ways restoring the data from the backup?

  • I believe none of the answers without using Java will work on encrypted phones. See my answer here: android.stackexchange.com/a/224474/95893 summing up the use of nelenkov's app (github.com/nelenkov/android-backup-extractor). Unfortunately Izzy's Adebar perl scripts ab2tar will not work on encrypted backup files. Similar: android.stackexchange.com/questions/28481/…
    – alchemy
    Commented Apr 28, 2020 at 22:57

4 Answers 4


The file is not encrypted, unless your specify so when creating the backup. It is however compressed (using deflate). You can find out the exact format by looking at Android source (com/android/server/BackupManagerService.java) code, and, technically, should be able to extract specific data from it. However, IIRC, there are some file integrity checks in place, so it most probably won't work if you just delete a bunch of data from it. Unfortunately the restore command doesn't seem to have an option to restore a particular app/package only or exclude a package.

  • Thanks! That's at least a starting point to look inside the file. Would have been easier if I hadn't provided a password for the backup. Commented May 23, 2012 at 5:44
  • If you provided a password, it is indeed encrypted. `BackupManagerService' has details on the actual encryption algorithms, and key derivation paramters (salt, iteration count etc) are written in the file header. Since you know the password, you can derive the key and decrypt the data. So it's still doable, but not particularly easy...
    – Nikolay Elenkov
    Commented May 23, 2012 at 5:57
  • Yes, I'm currently extracting everything from BackupManagerService to read the contents of the backup file. It's a good amount of work, but I need my data back... Commented May 23, 2012 at 6:20
  • @ingorichter I started working on this and posted a ton of notes below, in a "community wiki" answer. Feel free to add to it.
    – jade
    Commented May 29, 2012 at 23:58

I started working on this. I'm posting my results so far here as a "community wiki" answer for two reasons: first, if someone else wants to join in, there's a place to talk; second, if I get pulled away from this project, there'll be hints for someone else to start working.


The backup logic on the host is entirely contained within https://github.com/android/platform_system_core/blob/master/adb/commandline.cpp, in the function named backup. The function is very simple: it validates the command line options, sends the command mostly as-is to the adb daemon on the phone, and writes the phone's output to the file. There isn't even error-checking: if, for example, you refuse the backup on the phone, adb just writes out an empty file.

On the phone, the backup logic starts in service_to_fd() in https://github.com/android/platform_system_core/blob/master/adb/services.cpp. The function identifies that the command from the host is "backup", and passes the unparsed command to /system/bin/bu, which is a trivial shell script to launch com.android.commands.bu.Backup as the main-class of a new Android app process. That calls ServiceManager.getService("backup") to get the backup service as an IBackupManager, and calls IBackupManager.fullBackup(), passing it the still-unused file descriptor (very indirectly) connected to the backup.ab file on the host.

Control passes to fullBackup() in com.android.server.backup.BackupManagerService, which pops up the GUI asking the user to confirm/reject the backup. When the user do so, acknowledgeFullBackupOrRestore() (same file) is called. If the user approved the request, acknowledgeFullBackupOrRestore() figures out if the backup is encrypted, and passes a message to BackupHandler (same file.) BackupHandler then instantiates and kicks off a PerformAdbBackupTask (same file, line 4004 as of time of writing)

We finally start generating output there, in PerformAdbBackupTask.run(), between line 4151 and line 4330.

First, run() writes a header, which consists of either 4 or 9 ASCII lines:

  2. the backup format version: currently "4"
  3. either "0" if the backup is uncompressed or "1" if it is
  4. the encryption method: currently either "none" or "AES-256"
  5. (if encrypted), the "user password salt" encoded in hex, all caps
  6. (if encrypted), the "master key checksum salt" encoded in hex, all caps
  7. (if encrypted), the "number of PBKDF2 rounds used" as a decimal number: currently "10000"
  8. (if encrypted), the "IV of the user key" encoded in hex, all caps
  9. (if encrypted), the "master IV + key blob, encrypted by the user key" encoded in hex, all caps

The actual backup data follows, either as (depending on compression and encryption) tar, deflate(tar), encrypt(tar), or encrypt(deflate(tar)).


TODO: write up the code path that generates the tar output -- you can simply use tar as long as entries are in the proper order (see below).

Tar archive format

App data is stored under the app/ directory, starting with a _manifest file, the APK (if requested) in a/, app files in f/, databases in db/ and shared preferences in sp/. If you requested external storage backup (using the -shared option), there will also be a shared/ directory in the archive containing external storage files.

$ tar tvf mybackup.tar
-rw------- 1000/1000      1019 2012-06-04 16:44 apps/org.myapp/_manifest
-rw-r--r-- 1000/1000   1412208 2012-06-02 23:53 apps/org.myapp/a/org.myapp-1.apk
-rw-rw---- 10091/10091     231 2012-06-02 23:41 apps/org.myapp/f/share_history.xml
-rw-rw---- 10091/10091       0 2012-06-02 23:41 apps/org.myapp/db/myapp.db-journal
-rw-rw---- 10091/10091    5120 2012-06-02 23:41 apps/org.myapp/db/myapp.db
-rw-rw---- 10091/10091    1110 2012-06-03 01:29 apps/org.myapp/sp/org.myapp_preferences.xml

Encryption details

  1. An AES 256 key is derived from the backup encryption password using 10000 rounds of PBKDF2 with a randomly generated 512 bit salt.
  2. An AES 256 master key is randomly generated
  3. A master key 'checksum' is generated by running the master key through 10000 rounds of PBKDF2 with a new randomly generated 512 bit salt.
  4. A random backup encryption IV is generated.
  5. The IV, master key, and checksum are concatenated and encrypted with the key derived in 1. The resulting blob is saved in the header as a hex string.
  6. The actual backup data is encrypted with the master key and appended to end of the file.

Sample pack/unpack code implementation (produces/uses) tar archives: https://github.com/nelenkov/android-backup-extractor

Some more details here: http://nelenkov.blogspot.com/2012/06/unpacking-android-backups.html

Perl scripts for packing/unpacking and fixing broken archives:


  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Andrew T.
    Commented Jul 28, 2022 at 20:49

Great and detailed answer from Nikolay Elenkov. However I should added that somebody already develop a software that do just that and package it here: http://sourceforge.net/projects/adbextractor/

The package contains both Java and Perl tool. I myself prefer Perl over Java any day, so I extracted the Perl codes, make sure they are executable, installed the required Perl library, and run the backupdecrypt.pl against an adb backup file, and it convert it into a tar or gzipped tar file without any issue.

I even formed a one liner in Bash 3 that allow me to do adb backup directly to gzipped tar file:

adb backup -f >(backupdecrypt.pl -D -z - backup.tgz) -all

Hope it helps.

  • 7
    Yeah, they packaged the tool (the Java one) I wrote:) I also helped port the thing to Perl. If you didn't read the READMEs, it might not be immediately apparent that the writeup came first, then the tools.... Commented Aug 27, 2014 at 2:02
  • I have taken backup but it has not created .ab file, instead it has created .backup file. I want to know how to extract it. Also i am not sure whether it has taken all the photos and video's as backup?
    – hajirazin
    Commented Apr 13, 2015 at 19:04

For explore existing backup file, try http://www.adb-backup.com page, it is simple without "dd", "tar", ...

Data is not stored on this server. I've developed this online service to make it easier to view backups without manipulating with dd / tar or installing additional software. I'm author www.adb-backup.com

  • 10
    I'd be very careful about uploading an adb backup (and providing the password) to a random website... The data included in the adb backup is private and you have no way of knowing what the site does with the backup. It could be harmless but I wouldn't recommend doing this.
    – bmdixon
    Commented Jan 19, 2018 at 16:28
  • Data is not stored on this server. I've developed this online service to make it easier to view backups without manipulating with dd / tar or installing additional software. I'm author www.adb-backup.com
    – Liszak
    Commented Jan 21, 2018 at 20:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .