Extraer copias de seguridad TWRP hechas con adb

Tengo un teléfono inteligente Samsung Galaxy S2 GT-I9100 con LineageOS y TWRP. Cada semana hago una copia de seguridad con el siguiente comando:

adb backup -f twrp-20170322.ab --twrp boot data system

Opcionalmente, también puedo usar la --compressopción.

¿Hay alguna forma de extraer el twrp-20170322.abarchivo de copia de seguridad con las herramientas de línea de comandos estándar de GNU/Linux? También consideraré instalar software adicional si es necesario, pero debe ser gratuito (como en libertad).

Enlaces:

Respuestas (3)

Descubrí que los .abarchivos generados por TWRP son diferentes de los adb backuparchivos normales, por lo que el desplazamiento es diferente de los .abarchivos normales. Pude inspeccionar y extraer archivos usando (por ejemplo, para inspeccionar) el siguiente comando:

dd if=backup.ab bs=512 skip=1 | tar ft -

Aparentemente, el encabezado puede ser más largo, pero debe alinearse con los límites de 512 bytes, así que simplemente cambie el skip=parámetro si no puede encontrarlo al principio.

Tenga en cuenta que el formato de archivo se define en twadbstream.h , si necesita profundizar más en esto.

El problema con el enfoque ingenuo basado en dd es que hay metadatos de vez en cuando en el archivo. Esto da como resultado la corrupción de archivos de cualquier longitud significativa.

Escribí una herramienta de extracción utilizando twadbstream.h (gracias @anarcat) que he usado para recuperar con éxito grandes (~10 GB) copias de seguridad TWRP ADB de sistemas de archivos múltiples. twrpabx

¡Gracias! Su herramienta me funcionó después de aplicar estos parches mencionados en los problemas de Github github.com/prudy/twrpabx/tree/img_and_issue4
@TrojanName, ¿pudo extraer la copia de seguridad de varias particiones con estos parches?
@SandroAntonucci Sí, creo que sí.

Siempre que no lo hayas protegido con una contraseña:

dd if=$1 bs=24 skip=1 | openssl zlib -d >${1%%.ab}.tar
  • ddes el "Duplicador de disco" (también conocido como "destructor de disco" en caso de que confundas sus parámetros con el interruptor ify of;)
  • bs=23aconseja utilizar un tamaño de bloque de 24 bytes, que necesitamos para...
  • skip=1omita 1 bloque de 24 bytes (el "encabezado de copia de seguridad")
  • la salida se canaliza opensslpara procesarla y desempaquetarla
  • … y la salida de eso se redirige a un Tarball

A partir de ahí, debes saber tu camino: simplemente "descomprimir" (extraer) lo que quieras.

¿Por qué se usa $1? Bueno, copié esta línea de ab2tar, que se incluye con mi pequeña herramienta Adebar que también te puede interesar: crea una buena documentación del dispositivo, scripts de respaldo y más, todo a través de ADB usando nada más que Bash 😇 Así que pon esa línea en un pequeño pequeño script de shell, y llámalo:

ab2tar twrp-20170322.ab

Luego encuentra un twrp-20170322.tarresultado. Por supuesto, esto requiere opensslser instalado en su máquina Linux.

Recibo el siguiente mensaje de error: 140376894071512:error:29065064:lib(41):BIO_ZLIB_READ:zlib inflate error:c_zlib.c:548:zlib error:data error
Nunca he visto eso. ¿Podría ser que TWRP use un método de compresión diferente al ADB estándar (no pude encontrar detalles al respecto)? O, como no especificó --compressal crear la copia de seguridad, ¿crea copias de seguridad sin comprimir? En este último caso, intente omitir el zlibparámetro (o hágalo al revés y especifique --compressal crear la copia de seguridad;).
Probé con: dd if=twrp-20170320.ab bs=24 skip=1 > twrp-20170320.tar (sin insertar openssl). Pero cuando trato de enumerar el contenido del archivo tar con tar -tf twrp-20170320.tar obtengo: tar: esto no parece un archivo tar; tar: saltar al siguiente encabezado; tar: Saliendo con estado de falla debido a errores anteriores
Hay una razón para no usar la --compressopción con adb: comprime de manera menos eficiente que xz. Prefiero ahorrar el mayor espacio posible. Pero eso no está relacionado con mi problema inicial.
Lo que describí anteriormente funciona bien para las copias de seguridad ADB "normales" (lo uso con frecuencia para eso, y tampoco uso --compressallí). De su declaración ( adb backup …) asumí el mismo formato. Si solo está usando una compresión diferente, debe considerar eso. openssles necesario para descifrar la copia de seguridad, por lo que sin eso, no obtiene un archivo .tar. De sus últimos comentarios, supongo que debe reemplazar zlibpor la parte correspondiente para xz. Aparte de eso, me quedé sin ideas, lo siento.
por lo que puedo decir, este procedimiento solo funciona con copias de seguridad generadas "normales" (es decir, no TWRP). cuando TWRP envía la transmisión, coloca un nuevo encabezado en la parte superior, que es más largo (512 bytes). consulte android.stackexchange.com/a/180402/158769 para obtener una solución que funcionó para mí.
@anarcat ¡Gracias por el consejo! Entonces, mi enfoque sigue siendo válido, uno solo tiene que omitir un tamaño de sector diferente, ¿y puede omitir todo el material de openssl?
@Izzy, su respuesta es para la copia de seguridad de adb, no funciona para la copia de seguridad de TWRP. revisa mi script twab.sh
Umpf, ¿entonces estás diciendo adb backupque no está creando una "copia de seguridad ADB" aquí? Eso es bastante confuso.
es data.ext4.wincon un encabezado de 1536 bytes, pero 'dividido' en bloques de datos. también puede contener múltiples particiones sourceforge.net/p/adbextractor/discussion/general/thread/…