Есть ли способ заглянуть внутрь и изменить созданный файл резервной копии ADB?

Я создал резервную копию моего Galaxy Nexus с adb backup. Полученный файл называется backup.db, и он каким-то образом зашифрован.

Я хотел восстановить резервную копию, но она останавливается, когда дело доходит до восстановления com.android.providers.contacts. Раньше я adb logcatвыяснял, что происходит, и обнаруживал, что происходит com.android.acoreсбой во время процесса восстановления.

Я хотел бы получить доступ к данным в резервной копии и удалить базу данных контактов, чтобы восстановить все обратно на мой телефон. Есть ли другие способы восстановления данных из резервной копии?

Файл не зашифрован, если вы не указали это при создании резервной копии. Однако он сжимается (используя deflate). Точный формат можно узнать, посмотрев код исходного кода Android (com / android / server / BackupManagerService.java), и технически должен быть в состоянии извлечь из него конкретные данные. Тем не менее, IIRC, есть некоторые проверки целостности файлов, поэтому, скорее всего, это не сработает, если вы просто удалите из него кучу данных. К сожалению, restoreкоманда, похоже, не имеет возможности восстановить только определенное приложение / пакет или исключить пакет.

Я начал работать над этим. Пока я публикую свои результаты в качестве ответа "сообщества вики" по двум причинам: во-первых, если кто-то хочет присоединиться, есть место для разговора; во-вторых, если я отойду от этого проекта, у кого-то еще будут советы начать работать.

Логика резервного копирования на хосте полностью содержится в https://github.com/android/platform_system_core/blob/master/adb/commandline.cpp в названной функции backup. Функция очень проста: она проверяет параметры командной строки, отправляет команду, в основном, как есть, демону adb на телефоне и записывает вывод телефона в файл. Нет даже проверки ошибок: если, например, вы отказываетесь от резервного копирования на телефоне, adbпросто записывает пустой файл.

На телефоне логика резервного копирования начинается service_to_fd()с https://github.com/android/platform_system_core/blob/master/adb/services.cpp . Функция определяет, что команда от хоста есть "backup", и передает команду unparsed /system/bin/bu, которая является тривиальным сценарием оболочки, который запускается com.android.commands.bu.Backupкак основной класс нового процесса приложения Android. Это вызывает, ServiceManager.getService("backup")чтобы получить службу резервного копирования как IBackupManager, и вызывает IBackupManager.fullBackup(), передавая ему все еще неиспользованный файловый дескриптор (очень косвенно), связанный с backup.abфайлом на хосте.

Управление передается fullBackup()в com.android.server.backup.BackupManagerService , который выскакивает в GUI, запрашивая у пользователя подтверждение / отклонение резервной копии. Когда пользователь делает это, acknowledgeFullBackupOrRestore()(тот же файл) вызывается. Если пользователь одобрил запрос, acknowledgeFullBackupOrRestore()выясняет, зашифрована ли резервная копия, и передает сообщение BackupHandler(тот же файл), BackupHandlerзатем создает экземпляр и запускает PerformAdbBackupTask( тот же файл, строка 4004 на момент написания)

Наконец, мы начинаем генерировать вывод тамPerformAdbBackupTask.run() , между строки 4151 и 4330 .

Сначала run()записывается заголовок, который состоит из 4 или 9 строк ASCII:

1. "ANDROID BACKUP"
2. версия формата резервной копии: в настоящее время "4"
3. либо "0"если архив не распакован, либо "1"если
4. метод шифрования: в настоящее время либо "none"или"AES-256"
5. (если зашифровано), "соль пароля пользователя", закодированная в шестнадцатеричном виде, все заглавные буквы
6. (если зашифровано), "соль контрольной суммы главного ключа", закодированная в шестнадцатеричном виде, все заглавные буквы
7. (если зашифровано), «количество использованных раундов PBKDF2» как десятичное число: в настоящее время "10000"
8. (если зашифровано), «IV пользовательского ключа» закодировано в шестнадцатеричном виде, все заглавные буквы
9. (если зашифровано), «главный IV + блоб ключа, зашифрованный ключом пользователя», закодированный в шестнадцатеричном виде, все заглавные буквы

Фактические данные резервного копирования следующим образом , либо в виде ( в зависимости от сжатия и шифрования) tar, deflate(tar), encrypt(tar), или encrypt(deflate(tar)).

TODO : запишите путь к коду, который генерирует вывод tar - вы можете просто использовать tar, если записи находятся в правильном порядке (см. Ниже).

Формат архива тар

Данные приложения хранятся в каталоге app /, начиная с файла _manifest, APK (если требуется) в /, файлы приложения в f /, базы данных в db / и общие настройки в sp /. Если вы запросили резервное копирование внешнего хранилища (используя опцию -shared), в архиве также будет каталог shared /, содержащий файлы внешнего хранилища.

$ 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

Детали шифрования

1. Ключ AES 256 получен из резервного пароля шифрования с использованием 10000 раундов PBKDF2 со случайно сгенерированной 512-битной солью.
2. Главный ключ AES 256 генерируется случайным образом
3. Главный ключ 'контрольная сумма' генерируется путем запуска главного ключа через 10000 раундов PBKDF2 с новой случайно сгенерированной 512-битной солью.
4. Случайное резервное копирование шифрования IV генерируется.
5. IV, главный ключ и контрольная сумма объединяются и шифруются ключом, полученным в 1. Полученный большой двоичный объект сохраняется в заголовке в виде шестнадцатеричной строки.
6. Фактические данные резервной копии шифруются с помощью мастер-ключа и добавляются в конец файла.

Пример реализации кода пакета / распаковки (производит / использует) архивы tar: https://github.com/nelenkov/android-backup-extractor

Некоторые подробности здесь: http://nelenkov.blogspot.com/2012/06/unpacking-android-backups.html

Скрипты Perl для упаковки / распаковки и исправления испорченных архивов:

http://forum.xda-developers.com/showthread.php?p=27840175#post27840175

Отличный и подробный ответ от Николая Еленкова . Однако я должен добавить, что кто-то уже разработал программное обеспечение, которое делает именно это и упаковывает его здесь: http://sourceforge.net/projects/adbextractor/

Пакет содержит инструменты Java и Perl. Я сам предпочитаю Perl вместо Java каждый день, поэтому я извлек коды Perl, убедился, что они исполняемые, установил требуемую библиотеку Perl и запустил backupdecrypt.plфайл резервной копии против adb, и он преобразовал его в файл tar или gzipped tar без каких-либо вопрос.

Я даже сформировал один вкладыш в Bash 3, который позволяет мне делать резервное копирование adb напрямую в файл gzipped tar:

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

Надеюсь, это поможет.

Для изучения существующего файла резервной копии, попробуйте страницу http://www.adb-backup.com , это просто без "dd", "tar", ...

Данные не хранятся на этом сервере. Я разработал этот онлайн-сервис, чтобы упростить просмотр резервных копий без манипуляций с dd / tar или установки дополнительного программного обеспечения. Я автор www.adb-backup.com