Clonar particiones de Android desde la red para recuperar archivos borrados

Antes de comenzar, si su dispositivo con Android tiene memoria extraíble  y los archivos se almacenan en esta lo mejor que pueden hacer es meterla directamente en su PC y recurrir a Photorec (para cualquier SO) o Recuva (si solo disponen de Windows) y evitarse leer todo lo que sigue, dicho lo anterior.

El fin de semana sin querer borre todo el contenido de la carpeta /sdcard de mi Xoom, imaginaran mi sobresalto al darme cuenta del error cometido, sin embargo no entre en pánico inmediatamente porque se que al borrar los archivos de cualquier partición, estos realmente no se borran sino hasta ser sobreescritos, como ya tengo algo de experiencia en el asunto (léase torpeza jajajaja), decidí poner manos a la obra, sin embargo mi sobresalto comenzó cuando Photorec (mi gallo a la hora de recuperar datos XD), no reconocía la carpeta donde tenía montado el sistema de archivos, así que comenzó la investigación, luego de un rato me dí cuenta de que mi error era el intentar la recuperación sin tomar en cuenta que este tipo de dispositivos usan MTP como protocolo para la transferencia de archivos (reprochable creo yo, pero como Dios no cumple antojos...); entre todas las búsquedas desesperadas me encontré con algunos que afirmaban que los dispositivos que funcionan con MTP pueden ser instalados como dispositivos de almacenamiento masivo (comunes) seleccionando el driver apropiado en la lista de dispositivos (tan mal estaba que trate de recurrir a Windows XD), la solución final fue en realidad una variación de un método para recuperar archivos borrados de un iphone que ofrecen los mismos desarrolladores de Photorec mezclado con un toque de ingenio al estilo ZoSemU?, seguramente muchos dirán que es muy simple, pero ese es mi problema, nunca veo la solución más simple sin antes haber agotado todas las soluciones complicadas (léase absurdo jajajaja).

¿Porque lo publico?, bueno porque aunque resulto algo simple como dije antes, no encontré información para este método y espero que les sea de utilidad a otros.

Lo primero que necesitamos es tener rooteado nuestro dispositivo (xoom) e instalado el busybox (la forma más sencilla para esto último es: una vez rooteado su dispositivo, vayan al market y busquen busybox installer, en un par de minutos lo tendrán listo y sin tantas complicaciones ahora que si se quieren complicar en algún momento explicaré como...), lo siguiente es tener un emulador de terminal instalado, aunque eso no es realmente necesario se los sugiero para no tener que recurrir al "adb shell" del SDK. Como he repetido en otras ocasiones el mejor emulador de terminal que conozco (en Android) es ConnectBot, para mayor comodidad les sugiero instalar SSHDroid para tener una terminal remota en su Android (aunque realmente no es necesario y si lo sugiero es para realizar todo desde su PC, además de que pueden sacarle provecho usando SFTP o SCP para copiar archivos entre otras cosas).

Partiendo del principio que no instalaron SSHDroid voy a explicar como hice para recuperar mi información, ejecuten el ConnectBot e inicien una sesión local; el primer problema (si ya intentaron algo de esto) es que el comando fdisk -l no da ningún resultado, tampoco sirve el df -h, la solución para saber como realizar esto vino luego de ejecutar dos comandos, el primero es df (sin ningún parámetro) esto me llevo al siguiente resultado:

$ su

# df
Filesystem         Size      Used    Free     Blksize
/dev                   359M    32K      359M   4096
/mnt/asec          359M     0K       359M   4096
/mnt/obb           359M     0K       359M   4096
/system             251M     211M  40M     4096
/data                 28G       3G       25G      2048
/cache              163M     8M       155M   2048
/pds                  1M        108K     1M      2048
/mnt/sdcard     28G       3G         25G     2048

en realidad la el parámetro -h resulto innecesario debido a que la información ya la arroja comprensible para humanos, que saco de esto lo más útil aquí es el Blksize (tamaño de bloque) que nos servirá para realizar una clonación limpia del disco interno de nuestro Android, ahora seguimos con:

# mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/platform/sdhci-tegra.3/by-name/system /system ext4 ro,relatime,barrier=1,data=ordered 0 0
/dev/block/platform/sdhci-tegra.3/by-name/userdata /data ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered 0 0
/dev/block/platform/sdhci-tegra.3/by-name/cache /cache ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered 0 0
/dev/block/platform/sdhci-tegra.3/by-name/pdsb /pds ext2 ro,relatime 0 0
/dev/fuse /mnt/sdcard fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0

Bien algo de luz al fin, ¿por qué? porque hasta este momento me dí cuenta de como estaba operando Android con este tipo de dispositivos, para entenderlo lo primero que debemos saber es que coño es fuse? (aunque también esta en español recomiendo este porque trae más documentación al final), bueno en términos cristianos fuse es una gran solución implementada para evitar los conflictos del sistema de archivos nativo en todo tipo de dispositivos, ¿por qué? (aquí viene todo un choro de mi parte por lo que si quieren pueden saltar el párrafo siguiente).

Uno de los principales problemas a la hora de determinar el sistema de archivos que se va a usar en la partición de un disco, es para que se va a usar dicha partición y desde que sistema será accedido?, lo más común hoy en día es encontrarse con FAT32, el principal problema de esto es que no se puede tener archivos de más de 4G, así que los dispositivos móviles estaban condenados a cargar con esta limitante, o enfrentarse a problemas de incompatibilidad en los diversos sistemas operativos, lo que fuse hace es crear un sistema de archivos "virtual" (por llamarlo de alguna manera) que opera entre el sistema de archivos real y el nivel de acceso del usuario, evitando de esta manera que el sistema de archivos este condenado a ser FAT32 y permitiendo a usuarios Windows acceder de manera transparente a particiones ext3 o ext4, sin requerir soporte especial para esto y entonces para que usar MTP?, bueno eso simplemente para facilitar la sincronización con reproductores de Windows y otros programas, pero como es lo que predomina, que se le va a hacer.

Bueno una vez explicado que es fuse, eso fue lo que me dio la solución y fue porque una vez que entendí que hacia el sombrero mágico ahora solo restaba averiguar en donde estaba escondido el conejo, para eso volví a echarle un vistazo a la salida de mount y esta fue la linea que me dio la solución:

/dev/block/platform/sdhci-tegra.3/by-name/userdata /data ext4

Por si no lo han inferido he aquí la respuesta: en Android la carpeta /data tiene una particular importancia pues es donde las aplicaciones descargan el contenido necesario para funcionar, normalmente a esta carpeta solo puede acceder el sistema (también el usuario root, pero no en todos los casos a fin de evitar dejar inservible el sistema), teniendo eso en cuenta y que con las nuevas versiones de Android ha crecido la cantidad de datos necesaria para hacer funcionar las aplicaciones de calidad HD, me resulto lógico pensar que el sistema de archivos sea el mismo, es decir nuestro sobrero mágico (fuse) mediante el mago (MTP) permite el acceso a la partición ext4 en donde se aloja todo, incluido nuestro conejo (información), por lo tanto la respuesta al final del camino es hasta aburrida, y consiste en usar netcat en un puerto cualquiera, una tubería y el comando dd para recibir los datos y desde nuestro Android dd, una tubería y netcat para volcar el contenido a nuestra IP y asunto resuelto, quedaría algo así:

terminal destino:

#nc -l 1618 | dd of=/home/zosemu/xoom.img

terminal origen (ConnectBot)

#dd if=/dev/block/platform/sdhci-tegra.3/by-name/userdata bs=2048 | nc 192.168.1.100 1618

deje marcado con rojo los parámetros que tienen que modificar, puede ser que la ubicación del conejo cambie pero usando mount y df será posible encontrarlo, por último este proceso tardará un buen rato, dependiendo del tamaño del disco interno, al final solo habrá que usar:

#photorec /home/zosemu/xoom.img

si tienen dudas no duden en escribirme, saluDoS!