Как извлечь данные приложения из полной резервной копии, сделанной с помощью «резервной копии»?

Просто для справки других, вот какой-то фон в формате .ab.

Файл Android Backup (* .ab) представляет собой сжатый файл TAR , Он сжимается с помощью алгоритма DEFLATE . Кроме того, может использоваться шифрование AES . Это определяется при создании резервной копии, если вы вводите пароль, тогда резервная копия зашифровывается, в противном случае; нет шифрования, он только сжат.

HEADER файла немного отличается от обычного архива DEFLATE. Он содержит информацию о резервном копировании и выглядит следующим образом:

ANDROID BACKUP
1
1
none

Первая строка - строка «Магия» . Следующая строка - это версия формата файла Android Backup. Следующая строка - логическая (true или false, 1 или 0), указывающая, сжат ли файл. Последняя строка - тип шифрования. В этом примере не используется шифрование. Если бы был пароль, строка читала бы «AES-256». После этого шифр шифрования. Если пароль отсутствует, начинается «архив» DEFLATE.

Он сжимается с помощью Java Deflater . Что, с точки зрения разработчиков, вызывает проблемы, если вы хотите использовать что-либо помимо Java, чтобы извлечь его. Я не смог найти ничего, что могло бы сдуть его, используя тот же алгоритм, хотя все, что я нашел (например, C #), должно следовать за «SPEC».

С учетом этого существует проект с открытым исходным кодом под лицензией Apache 2.0, написанный Николаем Еленковым , который позволит вам извлечь .ab в tar-файл.

Использование:

java -jar abe.jar unpack <backup.ab> <backup.tar> <password>

Если вы не знаете, как реально использовать это (что выходит за рамки этого ответа), следующая версия Droid Explorer v0.8.8.7 ( доступно здесь ) позволит вам сделать именно это, и больше, прямо от Проводника. Подробнее о функциях можно узнать на странице мой блог (да, я знаю, бесстыдный плагин. Я делаю это, когда он подходит к вопросу)

Или с одним слоем:

( printf "\x1f\x8b\x08\x00\x00\x00\x00\x00" ; tail -c +25 backup.ab ) |  tar xfvz -

Еще один вариант - использовать bash, cat и gunzip (gzip).

Полный процесс может быть таким ( с незашифрованной резервной копией ):

1. резервное копирование данных одного приложения (например, Переопределение DNS для KitKat " ):

   $ adb backup -f net.mx17.overridedns.ab -noapk net.mx17.overridedns
   Now unlock your device and confirm the backup operation.
   

2. извлечь сжатые данные

   $ dd if=net.mx17.overridedns.ab bs=1 skip=24 > compressed-data
   1285+0 records in
   1285+0 records out
   1285 bytes (1,3 kB) copied, 0,00745877 s, 172 kB/s
   

3. распаковать сжатые данные

   $ printf "\x1f\x8b\x08\x00\x00\x00\x00\x00" \
       | cat - compressed-data | gunzip -c > decompressed-data.tar
   gzip: stdin: unexpected end of file
   

4. "untar" tar-файл

   $ tar xf decompressed-data.tar
   

Другим вариантом является использование Perl AdbBackupRoutines из этого потока XDA . У них есть несколько требований: Perl, очевидно, плюс libterm-readkey-perl, libcrypt-cbc-perl и libcrypt-pbkdf2-perl (если ваши резервные копии не зашифрованы, вы можете пропустить последнюю зависимость, просто прокомментировав строку 103 из backupdecrypt.pl, где она включена - работала отлично для меня).

Использование довольно просто:

./backupdecrypt.pl [options] <backupfile.ab> <outfile.tar>

Полученный файл .tar затем может быть исследован как любой другой архив. Его структура довольно интересна, по крайней мере, по одному аспекту: она не отражает реальные пути, из которых были взяты файлы (например, не /data/data/com.app.name/databases/whatever.db, но вместо этого apps/com.app.name/db/whatever.db) - указывает, что резервное копирование приложения на одном устройстве /ROM может быть восстановлено до любое другое устройство /ПЗУ без проблем, так как adb restore должен определить реальные пути.

Основываясь на информации других пользователей, теперь я знаю, что файл резервной копии представляет собой только префиксный поток Deflated (GZip), основанный на этой информации, эта простая программа может распаковать его для вас:

import java.io.*;
import java.util.zip.*;

/** Run: javac unab.java && java unab backupfile.ab */
public class unab {
    private static final int BACKUP_HEADER_LENGTH = 24;
    public static void main(String[] args) throws IOException {
        InputStream in = new FileInputStream(args[0]);
        try {
            OutputStream out = new FileOutputStream(args[0] + ".tar");
            try {
                if (in.skip(BACKUP_HEADER_LENGTH) != BACKUP_HEADER_LENGTH) {
                    throw new IOException("Unexpected end of file while skipping backup header.");
                }
                byte[] buffer = new byte[100 * 1024];
                int count;
                InputStream zip = new InflaterInputStream(in);
                while ((count = zip.read(buffer)) > 0) {
                    out.write(buffer, 0, count);
                }
            } finally {
                out.close();
            }
        } finally {
            in.close();
        }
    }
}

Я написал это, потому что у меня нет ни одного из упомянутых выше инструментов Unix, и это было проще, чем установка Cygwin или других инструментов.

Преимущества :

• кросс-платформенный
• простой (без эзотерических параметров)
• нет необходимости в инструментах для трубопроводов

Недостатки

• нужен JDK (которого вы, вероятно, уже имеете, потому что вы возитесь с Android SDK)
• нет поддержки зашифрованных резервных копий
• нужно что-то извлечь из полученного tar-файла (я использую Total Commander)

Чтобы сделать это инструментом командной строки, создайте unab.bat с содержимым: java -cp "%~dp0." unab %* и каталог PATH.

Как и в неявном вопросе, как восстановить данные отдельных приложений, я хотел бы упомянуть этот отличный скрипт, который разбивает данный full-backup.ab в файлах с одним-app.ab:

https://sourceforge.net/projects/adb-split/

для этого требуются файлы jar: abe.jar и tar-bin-split.jar который можно найти здесь:

sourceforge.net/projects/adbextractor/files/
sourceforge.net/projects/tar-binary-splitter/files/

(не может размещать более двух ссылок ... arrg)

Он работал, по крайней мере, для моей тестовой версии.