¿Hay alguna manera de mirar dentro y modificar un archivo creado de respaldo de adb?

Creé una copia de seguridad de mi Galaxy Nexus con adb backup. El archivo resultante se llama backup.db y de alguna manera está encriptado.

Quería restaurar la copia de seguridad, pero se detiene cuando se trata de restaurar com.android.providers.contacts. Solía adb logcataveriguar qué estaba pasando y descubrí que se com.android.acorebloquea durante el proceso de restauración.

Me gustaría obtener acceso a los datos en la copia de seguridad y eliminar la base de datos de contactos para restaurar todo a mi teléfono. ¿Hay alguna otra forma de restaurar los datos de la copia de seguridad?

El archivo no está encriptado, a menos que lo especifique al crear la copia de seguridad. Sin embargo, está comprimido (usando desinflar). Puede encontrar el formato exacto mirando el código fuente de Android (com / android / server / BackupManagerService.java) y, técnicamente, debería poder extraer datos específicos de él. Sin embargo, IIRC, hay algunas comprobaciones de integridad de archivos, por lo que probablemente no funcionará si simplemente borras un montón de datos. Desafortunadamente, el restorecomando no parece tener una opción para restaurar una aplicación / paquete en particular solo o excluir un paquete.

Empecé a trabajar en esto. Estoy publicando mis resultados hasta ahora aquí como una respuesta de "wiki de la comunidad" por dos razones: primero, si alguien más quiere unirse, hay un lugar para hablar; segundo, si me alejan de este proyecto, habrá sugerencias para que alguien más comience a trabajar.

La lógica de respaldo en el host está completamente contenida en https://github.com/android/platform_system_core/blob/master/adb/commandline.cpp , en la función nombrada backup. La función es muy simple: valida las opciones de la línea de comandos, envía el comando en su mayoría tal cual al adb daemon en el teléfono y escribe la salida del teléfono en el archivo. Ni siquiera hay verificación de errores: si, por ejemplo, rechaza la copia de seguridad en el teléfono, adbsimplemente escribe un archivo vacío.

En el teléfono, la lógica de respaldo comienza service_to_fd()en https://github.com/android/platform_system_core/blob/master/adb/services.cpp . La función identifica que el comando del host es "backup", y pasa el comando no analizado a /system/bin/bu, que es un script de shell trivial para iniciar com.android.commands.bu.Backupcomo la clase principal de un nuevo proceso de aplicación de Android. Eso llama ServiceManager.getService("backup")para obtener el servicio de respaldo como un IBackupManager, y llama IBackupManager.fullBackup(), pasándole el descriptor de archivo aún no utilizado (muy indirectamente) conectado al backup.abarchivo en el host.

El control pasa al fullBackup()de com.android.server.backup.BackupManagerService , la cual aparece la interfaz gráfica de usuario que pide al usuario que confirme / rechazar la copia de seguridad. Cuando el usuario lo hace, acknowledgeFullBackupOrRestore()se llama (mismo archivo). Si el usuario aprobó la solicitud, acknowledgeFullBackupOrRestore()descubre si la copia de seguridad está encriptada y pasa un mensaje a BackupHandler(mismo archivo), BackupHandlerluego crea una instancia y lanza un PerformAdbBackupTask( mismo archivo, línea 4004 al momento de la escritura)

Finalmente comenzamos a generar resultados allí, enPerformAdbBackupTask.run() , entre la línea 4151 y la línea 4330 .

Primero, run()escribe un encabezado, que consta de 4 o 9 líneas ASCII:

1. "ANDROID BACKUP"
2. la versión del formato de copia de seguridad: actualmente "4"
3. ya sea "0"si la copia de seguridad no está comprimida o "1"si está
4. El método de cifrado: actualmente "none"o"AES-256"
5. (si está cifrado), la "sal de contraseña de usuario" codificada en hexadecimal, todo en mayúsculas
6. (si está cifrado), la "sal de comprobación de la clave maestra" codificada en hexadecimal, todo en mayúsculas
7. (si está cifrado), el "número de rondas PBKDF2 utilizadas" como un número decimal: actualmente "10000"
8. (si está encriptado), el "IV de la clave de usuario" codificado en hexadecimal, todo en mayúsculas
9. (si está encriptado), el "blob de claves maestro IV +, encriptado por la clave de usuario" codificado en hexadecimal, todo en mayúsculas

Los datos de copia de seguridad real sigue, ya sea como (dependiendo de la compresión y cifrado) tar, deflate(tar), encrypt(tar), o encrypt(deflate(tar)).

TODO : escriba la ruta del código que genera la salida de tar; simplemente puede usar tar siempre que las entradas estén en el orden correcto (consulte a continuación).

Formato de archivo tar

Los datos de la aplicación se almacenan en el directorio app /, comenzando con un archivo _manifest, el APK (si se solicita) en a /, archivos de aplicación en f /, bases de datos en db / y preferencias compartidas en sp /. Si solicitó una copia de seguridad de almacenamiento externo (utilizando la opción compartida), también habrá un directorio compartido en el archivo que contiene archivos de almacenamiento externo.

$ 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

Detalles de cifrado

1. Una clave AES 256 se deriva de la contraseña de cifrado de respaldo utilizando 10000 rondas de PBKDF2 con una sal de 512 bits generada aleatoriamente.
2. Se genera aleatoriamente una clave maestra AES 256
3. Se genera una 'suma de verificación' de la clave maestra ejecutando la clave maestra a través de 10000 rondas de PBKDF2 con una nueva sal de 512 bits generada aleatoriamente.
4. Se genera una encriptación de respaldo aleatoria IV.
5. El IV, la clave maestra y la suma de verificación se concatenan y cifran con la clave derivada en 1. El blob resultante se guarda en el encabezado como una cadena hexadecimal.
6. Los datos de la copia de seguridad real se cifran con la clave maestra y se agregan al final del archivo.

Ejemplo de implementación de código de paquete / desempaquetado (produce / usa) archivos tar: https://github.com/nelenkov/android-backup-extractor

Algunos detalles más aquí: http://nelenkov.blogspot.com/2012/06/unpacking-android-backups.html

Scripts de Perl para empacar / desempacar y arreglar archivos rotos:

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

Gran y detallada respuesta de Nikolay Elenkov . Sin embargo, debería agregar que alguien ya desarrolla un software que hace exactamente eso y lo empaqueta aquí: http://sourceforge.net/projects/adbextractor/

El paquete contiene herramientas Java y Perl. Yo prefiero Perl sobre Java cualquier día, así que extraje los códigos de Perl, me aseguré de que sean ejecutables, instalé la biblioteca Perl requerida, backupdecrypt.plejecuté el archivo de copia de seguridad de adb y lo convirtió en un archivo tar o gzipped tar sin ningún tipo de problema.

Incluso formé un forro en Bash 3 que me permite hacer una copia de seguridad de adb directamente al archivo tar comprimido:

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

Espero eso ayude.

Para explorar el archivo de copia de seguridad existente, pruebe la página http://www.adb-backup.com , es simple sin "dd", "tar", ...

Los datos no se almacenan en este servidor. Desarrollé este servicio en línea para que sea más fácil ver las copias de seguridad sin manipularlas con dd / tar o instalar software adicional. Soy autor www.adb-backup.com