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?

3 Answers
3

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.
–
ingorichterMay 23 '12 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 ElenkovMay 23 '12 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...
–
ingorichterMay 23 '12 at 6:20

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.c, 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.

Control passes to fullBackup() in com.android.server.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 PerformFullBackupTask (same file, line 2228 as of time of writing)

We finally start generating output there, in PerformFullBackupTask.run(), between line 2367 and line 2453.

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

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.

If you put the code somewhere, I might able to join. The OP (@ngorichter) probably has some working code by now too :) A utility that decompresses and extracts the actual files might be useful, so that you can restore only parts (if you have root of course).
–
Nikolay ElenkovMay 30 '12 at 1:12

1

As for the encryption part, I have to look it up for the details, but the key is derived using PBKDF2 by the salt and device unlock PIN, password or pattern (converted to string). The master key is generated randomly, and encrypted with the password-derived key. Get it to work for unencrypted archives first. I can implement the decryption part if you are having trouble with it.
–
Nikolay ElenkovMay 30 '12 at 1:14

Sorry, the key is actually derived based on the password you specify when starting the backup.
–
Nikolay ElenkovMay 30 '12 at 4:16

@NikolayElenkov I don't have any code yet, but I do plan on writing a utility to manipulate ab files. W.r.t. encryption, I don't think it'll be difficult; it's just that I've only glanced over that part of the code. Similarly, I've traced the code path (not yet written above) that generates the tar stream, but not yet checked that the actual format is GNU tar.
–
jonMay 30 '12 at 10:31

Wow, I'm impressed with your analysis. I extracted some code from BackupManagerService into a simple groovy script, but when I run the program the result is always the same: wrong password entered! I created a new backup with a simple password, but the password verification failed again. Currently I try to follow the program as described above to find my mistake.
–
ingorichterMay 31 '12 at 21:28

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:

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....
–
Nikolay ElenkovAug 27 '14 at 2:02