Чи є спосіб заглянути всередину та змінити створений файл резервної копії adb?


40

Я створив резервну копію свого Galaxy Nexus за допомогою adb backup. Отриманий файл називається backup.db і він якось зашифрований.

Я хотів відновити резервну копію, але вона зупиняється, коли йдеться про відновлення com.android.providers.contacts. Я використовував, adb logcatщоб дізнатися, що відбувається, і виявив, що відбувається com.android.acoreзбій під час відновлення.

Я хотів би отримати доступ до даних із резервної копії та видалити базу даних контактів, щоб відновити все назад у своєму телефоні. Чи є інші способи відновлення даних із резервної копії?

Відповіді:


14

Файл не зашифрований, якщо ви не вкажете це під час створення резервної копії. Однак він стискається (використовуючи дефлат). Ви можете дізнатись точний формат, переглянувши вихідний код Android (com / android / server / BackupManagerService.java), і, технічно, ви зможете витягувати з нього конкретні дані. Однак, IIRC, є кілька перевірок цілісності файлів, тому він, швидше за все, не спрацює, якщо ви просто видалите з нього купу даних. На жаль, restoreкоманда, здається, не має можливості відновити певний додаток / пакет або виключити пакет.


Дякую! Це хоча б відправна точка, щоб заглянути всередину файлу. Було б простіше, якби я не вказав пароль для резервної копії.
ingorichter

Якщо ви вказали пароль, він дійсно зашифрований. "BackupManagerService" містить детальну інформацію про фактичні алгоритми шифрування, а ключові параметри виведення (сіль, кількість ітерацій тощо) записуються у заголовок файлу. Оскільки ви знаєте пароль, ви можете отримати ключ і розшифрувати дані. Тож це все-таки виконано, але не особливо просто ...

Так, я наразі видобуваю все, BackupManagerServiceщоб прочитати вміст файлу резервної копії. Це хороший обсяг роботи, але мені потрібні мої дані назад ...
ingorichter

@ingorichter якийсь прогрес?
Джон

@ingorichter Я почав працювати над цим і опублікував тонну нотаток нижче, у відповіді "Вікі спільноти". Сміливо додайте до нього.
jon

50

Я почав працювати над цим. Я публікую свої результати поки що тут як відповідь на "вікі спільноти" з двох причин: по-перше, якщо хтось інший хоче приєднатися, є де поговорити; по-друге, якщо я відволічуся від цього проекту, з’являться підказки, щоб хтось інший почав працювати.

 

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

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

Керування передається fullBackup()в com.android.server.backup.BackupManagerService , який спливає графічний інтерфейс із проханням користувача підтвердити / відхилити резервну копію. Коли користувач робить це, 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, якщо записи проходять у належному порядку (див. Нижче).

Формат архіву Тар

Дані програми зберігаються під додатком / каталогом, починаючи з файлу _manifest, APK (якщо вимагається) в /, файлів додатків у f /, баз даних у db / та спільних уподобань у sp /. Якщо ви попросили створити резервну копію зовнішнього сховища (використовуючи параметр -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. ІV, головний ключ і контрольна сума об'єднуються та шифруються з ключем, похідним у 1. Отриманий крап зберігається у заголовку у вигляді шістнадцяткової рядки.
  6. Фактичні дані резервного копіювання шифруються за допомогою головного ключа та додаються до кінця файлу.

Реалізація зразків упаковки / розпакування коду (виробляє / використовує) таргові архіви: 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


Якщо ви десь поставите код, я, можливо, зможу приєднатися. У OP (@ngorichter), мабуть, і зараз є якийсь робочий код :) Утиліта, яка декомпресує та витягує фактичні файли, може бути корисною, щоб ви могли відновити лише частини (якщо у вас звичайно є root).
Микола Єленков

1
Що стосується частини шифрування, я мушу шукати її для деталей, але ключ виводиться за допомогою PBKDF2 за допомогою солі та PIN-коду для розблокування солі та пристрою (перетвореного на рядок). Головний ключ генерується випадковим чином і шифрується ключем, отриманим паролем. Спочатку змусьте його працювати з незашифрованими архівами. Я можу реалізувати частину розшифровки, якщо у вас виникли проблеми.
Микола Єленков

На жаль, ключ фактично виводиться на основі пароля, який ви вказуєте при запуску резервної копії.
Микола Єленков

@NikolayElenkov У мене ще немає коду, але я планую написати утиліту для управління файлами ab. Шифрування Wrt, я не думаю, що це буде складно; це лише те, що я лише оглянув цю частину коду. Так само я простежив шлях коду (ще не написано вище), який генерує дзеркальний потік, але ще не перевірив, що фактичний формат - GNU tar.
jon

Нічого собі, я вражений вашим аналізом. Я вилучив якийсь код із BackupManagerService у простий скрипкий сценарій, але коли я запускаю програму, результат завжди однаковий: введений неправильний пароль! Я створив нову резервну копію з простим паролем, але перевірка пароля знову не вдалася. В даний час я намагаюся слідувати програмі, як описано вище, щоб знайти свою помилку.
ingorichter

7

Чудова і детальна відповідь від Миколи Єленкова . Однак я повинен додати, що хтось уже розробляє програмне забезпечення, яке робить саме це, і пакує його тут: 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

Сподіваюся, це допомагає.


6
Так, вони упакували інструмент (Java), про який я писав :) Я також допоміг перенести річ на Perl. Якщо ви не прочитали README, можливо, не одразу буде очевидно, що спочатку було написано, а потім інструменти ....
Микола Єленков,

Я взяв резервну копію, але він не створив .ab файл, натомість створив .backup файл. Я хочу знати, як його витягти. Також я не впевнений, чи сприйняв він всі фотографії та відео як резервні копії?
Хаджиразін

-4

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

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


7
Я буду дуже обережним щодо завантаження резервної копії adb (та надання пароля) на випадковий веб-сайт ... Дані, включені до резервної копії adb, є приватними, і ви не можете знати, що робить сайт із резервною копією. Це може бути нешкідливим, але я б не рекомендував це робити.
bmdixon

За інформацією Metasmoke, це адреса спаму . Крім того, я повністю згоден з @bmdixon тут - тим більше, що існують безпечні способи, які виконують завдання на місцях.
Izzy

@Izzy Все одно я позначив як спам і повідомив про це SmokeDetector.
iBug

Дані не зберігаються на цьому сервері. Я розробив цей онлайн-сервіс, щоб полегшити перегляд резервних копій без маніпуляцій з dd / tar або встановленням додаткового програмного забезпечення. Я автор www.adb-backup.com
Лисак
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.