¿Cómo recuperar datos del almacenamiento adaptativo mientras el teléfono rooteado se atasca en el arranque?

Antes de comenzar, recomendaría hacer una copia de seguridad COMPLETA de su tarjeta SD, a través de una imagen sin procesar (googlee el comando 'dd' en Linux)

seguí la guía aquí; Tarjeta SD corrupta formateada como almacenamiento interno

¡PERO con algunas MODIFICACIONES IMPORTANTES mías!

1. El teléfono se atascó en BOOTLOOP y luego se atascó en BOOT Animation, sin acceso a ninguna utilidad habitual de administrador de archivos. Eso sí, esta es una situación MUY grave, ya que no existe un método trivial para obtener acceso a su tarjeta SD (se muestra como 0mb en el administrador de archivos TWRP) para hacer una copia de seguridad de sus valiosos datos, fotos y recuerdos. Además, esta es la única parte que es un poco inestable ya que no estoy completamente seguro de si mi teléfono estaba rooteado o no (ya que mi problema cambió de bootloop a animación de arranque cuando intenté instalar SuperSu a través de TWRP) y recuperar la clave de cifrado es fundamental para resolver esto. Tuve que obtener el archivo .key, ya que era fundamental para romper el cifrado de la tarjeta SD. Entonces, en medio de todo el pánico, pude navegar, a través del administrador de archivos TWRP, a la carpeta /data/misc/vold y encontré el archivo .key. ¡Este fue un gran avance!

2. A continuación, para extraer el archivo. Usé otra tarjeta SD NO CIFRADA y transfirí el archivo .key a esa tarjeta, a través del administrador de archivos TWRP, leí esa tarjeta SD en la computadora portátil y obtuve el archivo .key en Ubuntu (16.04). Decodificó el archivo .key y obtuvo la clave de 16 bytes. hay 2 formas de hacer esto... abra el archivo a través de un editor hexadecimal (usé BLESS) y copie los 16 pares de dígitos hexadecimales que ve O use este comando;

hexdump -e '1/1 "%.2x"' expand_8838e738a18746b6e435bb0d04c15ccd.clave

asegúrese de estar en el MISMO directorio que el archivo .key al ejecutar este comando (los usuarios avanzados de Linux solucionarán esto, pero quiero que sea lo más fácil posible para principiantes)

Entonces, obtuve la clave de 32 dígitos / 16 bytes.

3. SIGUIENTE, descifrar la tarjeta SD Y hacer que Linux la reconozca. cuando lo leí, a través del lector de tarjetas, no aparecía en Nautilus (el administrador de archivos de Ubuntu), pero al ejecutar fdisk-l y parted -l, vi

"partid -l salida"

http://pasteboard.co/5klviklR8.jpg

"fdisk -l salida"

http://pasteboard.co/POGvyBOxO.png

observe android_meta y android_expand, esos nombres me dieron esperanza, que mis datos aún estaban intactos. ESPECIALMENTE, ya que al comienzo del problema, había creado particiones y tablas de partición en la tarjeta SD a través de la utilidad fdisk (pero ctrl + c'ed out, por lo que es posible que los cambios no se hayan escrito, ¡UFH!)

el sistema de archivos desconocido fue el mayor dolor en todo este fiasco... ya que de acuerdo con las pocas guías y discusiones sobre este tema, se suponía que las tarjetas SD formateadas como internas por marshmallow eran un sistema de archivos ext4. pero ese no fue el caso, al menos no aquí.

4. Entonces, para descifrar la tarjeta, usé

dmsetup create crypt1 --table "0 `blockdev --getsize /dev/mmcblk0p2` crypt aes-cbc-essiv:sha256 "insert your 16-byte key here w/out double quotes" 0 /dev/mmcblk0p2 0"

si obtiene algún error relacionado con ioctl, use este formato en su lugar (este es el formato EXACTO que usé hoy, con mi clave y todo)

dmsetup create crypt7 --table "0 `blockdev --getsize /dev/mmcblk0p2` crypt aes-cbc-essiv:sha256 07147CFFB77F249A5DBD2AD204610E7D  0 /dev/mmcblk0p2 0"

tenga en cuenta que la utilidad dmsetup debe instalarse en Linux. (buscalo en Google ) . también, tenga en cuenta que opté por la parición 'mmcblk0p2', ya que era la más grande en tamaño y tenía la inferencia obvia de contener todos los datos.

esto salió bien, se completó sin errores. Sin embargo, el siguiente bit, ABSOLUTAMENTE me volvió loco y tomó alrededor de 20 horas (incluido mi tiempo de sueño) para resolverlo correctamente.

5. el sistema de archivos GADDAMN! estaba escrito EN TODAS PARTES que el almacenamiento adoptivo está formateado como ext4, así que cuando ejecuté el comando

# montar -t ext4 /dev/mapper/crypt1 /mnt/1/

(Tenga en cuenta que mnt/1/ debe existir como directorio en su carpeta raíz, si no, use mkdir para crearlo)

dio el maldito error

mal fs o mala opción.

y esto me hizo pensar... si la tarjeta SD NO es del tipo ext4, entonces ¡CÓMO DEBO saber qué sistema de archivos es de todos los posibles!

Busqué y busqué un comando que pudiera forzar el ciclo a través de TODAS las posibilidades en un método de fuerza bruta o cualquier entrada que pudiera hacer en el archivo /etc/fstab que pudiera detectar AUTOMÁTICAMENTE el sistema de archivos de alguna manera, pero fue en vano...

5 . Al final, recordé... que tal vez, solo TAL VEZ el sistema de archivos era f2fs (sistema de archivos compatible con flash). Y eso resultó ser un recuerdo revelador...

para este código;

montar -t f2fs /dev/mapper/crypt1 /mnt/1

resultó ser el OBJETIVO GANADOR!

Luego pude hacer un cd en /mnt/1 y vi algunos archivos muy familiares al estilo de Android y, a partir de ahí, ¡fue Eternal BLISS!