¿Hay alguna forma de obtener una imagen de disco del espacio de almacenamiento del usuario en los dispositivos Android modernos?

Quiero saber si es posible obtener una "imagen de disco" del espacio de almacenamiento en dispositivos Android cuando no usan almacenamiento externo como tarjetas SD.

Estoy más interesado porque mis hijos restablecieron mi Kindle Fire HDX de fábrica y esperaba poder obtener una imagen de disco (usando algo como dd en Linux) y luego tratar de recuperar algunos de los datos de usuario como fotos y videos (usando algo como PhotoRec, http://www.cgsecurity.org/wiki/PhotoRec ). He hecho esto muchas veces con tarjetas SD y discos duros simplemente montando el dispositivo de almacenamiento en un escritorio que ejecuta Debian y ejecutando algo como:

# dd if=/dev/sdb1 of=image.iso

Luego puede usar PhotoRec y/o TestDisk, según lo que desee, para obtener cosas útiles del archivo de imagen.

Incluso algunos de mis dispositivos Android muy antiguos parecen permitir montar un dispositivo de almacenamiento de esta manera (sin quitar la tarjeta SD del teléfono) y seguir este proceso. Desafortunadamente, parece que muchos dispositivos nuevos que no tienen almacenamiento extraíble (como mi Kindle Fire HDX y mi Nexus 5) solo te permiten interactuar con una computadora usando el Protocolo de transferencia de medios (MTP) y el Protocolo de transferencia de imágenes (PTP).

¿Puedo usar estos protocolos para obtener una copia bit a bit del almacenamiento en el dispositivo? ¿Hay alguna manera de agregar las capacidades de los dispositivos de almacenamiento más antiguos a los teléfonos nuevos?

Respuestas (3)

Después de investigar un poco más, creo que he encontrado una solución parcial aquí:

http://forum.xda-developers.com/showthread.php?t=2450045

  • Primero, debe configurar ADB en su computadora. En Linux es bastante fácil. Algo así como ejecutar # apt-get install android-tools-adbo descargar y extraer un directorio.

  • Encuentra tus particiones. Ejecute algo como: adb shell cat /proc/partitionsHay otras opciones en el enlace sobre cómo encontrar e identificar todas las particiones.

  • Copie los datos La herramienta dd debería estar disponible. Puedes ejecutar algo comodd if=/dev/block/mmcblk0p9 of=/sdcard/image.img

Desafortunadamente, tengo dos problemas con esto. La primera es que los permisos en los dispositivos de partición pueden requerir acceso de root. La segunda es que el Kindle Fire HDX y muchos otros dispositivos modernos que no tienen "almacenamiento masivo USB" tampoco usan tarjetas SD. Por lo tanto, no hay una ubicación fácil para escribir la imagen que desea que no se haya utilizado para otra cosa en el dispositivo.

Estoy tratando de encontrar una manera de montar dispositivos de red o transferir datos a través de USB entre el dispositivo y la computadora (adb push y adb pull no harán lo que se necesita hasta donde puedo decir). Actualizaré esto si puedo encontrar una buena solución. De lo contrario, haré algunas otras preguntas al respecto.

Editar: esta página tiene una excelente descripción en la línea de lo que tengo arriba: http://www.df.lth.se/~jokke/androidfilerecovery/

Como se indica a continuación, la raíz es necesaria, pero generalmente hay muchas maneras de obtenerla fácilmente. Desafortunadamente, estaba trabajando con Fire HDX 8.9. A la mitad de mi copia de datos a un archivo de imagen, la cosa descarga automáticamente una actualización a 4.1.1. Lo siguiente que sé es que el acceso a la raíz desaparece y no creo que haya un exploit todavía. Probablemente perdí cualquier dato recuperable después de que la actualización se escribiera en el almacenamiento interno de todos modos. Estoy tan frustrado con Amazon últimamente...

Tiene razón: no hay forma de obtener un ddvolcado sin acceso de root. En cuanto a la copia, AFAIK hay formas de "puentear" a través de USB al otro extremo: he visto un artículo que describe eso en alguna parte, pero no recuerdo dónde estaba :( Básicamente: redirigir la salida de me ddgusta adb shell "dd ..." > /localdir/file.dump, donde localdirreside en su computadora.
Gracias. Esa parece la solución ideal. He actualizado mi respuesta. Hay una gran página sobre este proceso en: df.lth.se/~jokke/androidfilerecovery (todavía no puedo creer cuánto tiempo me tomó encontrarlo).
¡Sí! Exactamente eso era lo que tenía en mente. Gusto, al menos podría proporcionar el puntero correcto :) // Por cierto: como es preferible incluir lo esencial con su respuesta (el enlace podría morir algún día), ¿le importaría hacerlo con su respuesta? ¿O prefieres que ponga una respuesta separada haciendo eso?
Hubiera sido bueno incluir el procedimiento exacto del enlace, en lugar de simplemente vincularlo. Los enlaces mueren a veces. Además, la actualización va a la partición del sistema. No hay ninguna razón por la que también habría sobrescrito la partición de datos.

Joshua prácticamente respondió a la pregunta. Sin embargo, Izzy brindó información adicional para abordar las variaciones extrañas/raras del mismo problema.

Me gustaría contribuir (mi primera publicación de contribución en más de 10 años) para aquellos que se topan con el mismo escenario que yo. De todos modos, 24 horas después, con persistencia y determinación, el siguiente comando arrojará algo de luz (suponiendo que ya tenga habilidades intermedias/avanzadas).

Por cierto, no lo explicaré, ya que el comando en sí es bastante obvio.

adb shell "dd if=/dev/block/mmcblk0p37 of=/dev/pts/0" > part37-img-dump.dd

Estas son las herramientas que utilicé para hacer el trabajo.

C:\HTCOneRoot\
 |--\adb.exe (version 1.0.31 21/05/2013, latest was buggy)
 |--\fastboot.exe (version fc2a139a55f5-android 24/04/2016)
 |--\AdbWinApi.dll
 |--\AdbWinUSBApi.dll
 |--\part37-img-dump.dd (output from the 'adb' command)

Nota:

  1. dd enviará estadísticas a stdout después de completarse (relacionado con BusyBox)
  2. encuentre una herramienta para recortar las compensaciones no deseadas en el EOF (no es obligatorio)
  3. monte la imagen usando el software de recuperación de datos preferido o lo que sea
  4. /dev/pts/0 debería funcionar directamente, pero si está ejecutando varios comandos de shell adb desde varias consolas/terminales, tenga cuidado con el número de referencia del puntero de desarrollo, ya que será diferente. Usando el siguiente comando, simplemente puede averiguar cuál: pts: 0, pts: 1, ...
    adb shell "ps -l"
    
En mi caso he usado adb shell su -c "dd if=/dev/block/mmcblk0" | pv > backup.dd... si no tengo pv... apt-get install pvo quite de la linea

Esta línea: adb pull /Dev/block/device-by-name/userdata data.imgdebería funcionar. No lo probé, pero debería estar cerca. Esto extraería la imagen completa que podría flashear o tal vez empujar más tarde en el proceso de restauración. Solo funciona si estás rooteado. No trabajaré cuando tú no lo estés. Error de permisos. Supongo que si hizo fastboot con TWRP y no rooteó, si obtiene el descifrado, puede copiar la imagen de esa manera. Estoy evitando el enraizamiento en este momento. Parece ser más estable con Android 10