Un viejo amigo de UNIX, pero relativamente nuevo en el mundo de Android. Sigue leyendo.
EPISODIO 1: Una nueva copia de seguridad (esperaba)
Recientemente he comprado un Asus MemoPAD (ME103K); luego me convertí en Root, y tomé un dd la imagen de la lectura de sólo system de la partición de la tarjeta SD externa:
$ su
# dd if=/dev/block/platform/msm_sdcc.1/by-name/system \
of=/storage/MicroSD/system.img bs=1M
# ls -l /storage/MicroSD/system.img
-rw-r--r-- 1 root root 2147483648 Sep 27 13:15 system.imgEl tamaño (exactamente 2GiB) era un poco sospechoso - ¿podría ser que esto se debiera a la partición FAT32 de la tarjeta SD?
No, no fue tune2fs -l reveló que esta era, de hecho, una imagen EXT4 válida, con un tamaño exacto de 2GiB, que pasó fsck -f sin ningún tipo de error. Y fastboot (de la máquina de linux conectada a la tablet) coincidió, después de una adb reboot bootloader :
linuxbox# fastboot getvar all
(bootloader) version-bootloader: 3.03
(bootloader) version-hardware: rev_c
(bootloader) variant: LEOPARDCAT 16G
(bootloader) version-baseband: H00_0.16.F_0521
(bootloader) serialno: 0a3dXXXX
...
(bootloader) partition-type:system: ext4
(bootloader) partition-size:system: 0x0000000080000000Ese tamaño, es de hecho 2GB:
linuxbox# python2 -c 'print 0x0000000080000000'
2147483648Así que todo está bien, tengo una copia de seguridad de la imagen. Ahora para probar la restauración.
Trato de flashear el system.img de vuelta a la tablet - para asegurarme de que puedo recuperarme de cualquier cosa, el tipo de respaldo a prueba de balas que hacemos en el mundo Unix ( por ejemplo, restaurar el contenido de una unidad a través de dd if=backup.image of=/dev/sdXXX ).
Todo lo relacionado con adb y fastboot trabajar sin problemas, así que intento...
linux_box# fastboot devices
0a3dXXXX fastboot
linux_box# mount /dev/sdcard /mnt/sdcard
linux_box# cp /mnt/sdcard/system.img .
linux_box# fastboot flash system system.img
error: cannot load 'system.img'Hmm. Descargo y construyo el android-tools-5.1.1 de mi distribución de fuentes, agregando información de depuración - y paso en el depurador, para ver este fallo:
linuxbox# gdb --args fastboot flash system system.img
...
Interesante - aunque estoy en una máquina de 64 bits, aparentemente hay problemas que hacen que el tamaño del archivo sea "negativo" (en un mundo de 32 bits, el tamaño del archivo de mi imagen, 2^31, es de hecho considerado negativo - para ser exactos, -2147483648 .
Vale, bien ¿cómo hacen para mostrar grandes archivos de imagen en Android?
Buscando en Google, buscando resulta que usan esto make_ext4fs que crea imágenes flash. De hecho, es parte de lo que acabo de compilar, así que también podría usarlo:
linuxbox# mkdir /system
linuxbox# mount -o loop,ro system.img /system
linuxbox# ls -l /system
total 208
drwxr-xr-x 106 root root 8192 Sep 17 22:24 app
drwxr-xr-x 3 root 2000 8192 Sep 26 21:08 bin
-rw-r--r-- 1 root root 6847 Sep 12 16:59 build.prop
drwxr-xr-x 19 root root 4096 Sep 26 21:08 etc
drwxr-xr-x 2 root root 4096 Aug 11 22:27 fonts
drwxr-xr-x 4 root root 4096 Sep 12 16:56 framework
drwxr-xr-x 10 root root 16384 Sep 12 16:59 lib
drwxr-xr-x 2 root root 4096 Jan 1 1970 lost+found
drwxr-xr-x 3 root root 4096 Aug 11 22:18 media
drwxr-xr-x 59 root root 4096 Aug 11 22:29 priv-app
-rw-r--r-- 1 root root 126951 Aug 1 2008 recovery-from-boot.p
drwxr-xr-x 3 root root 4096 Aug 11 21:02 scripts
drwxr-xr-x 3 root root 4096 Aug 11 21:02 tts
drwxr-xr-x 11 root root 4096 Sep 26 21:08 usr
drwxr-xr-x 8 root 2000 4096 Aug 11 22:29 vendor
drwxr-xr-x 2 root 2000 4096 Sep 26 21:09 xbin
linuxbox# ../extras/source/extras/ext4_utils/make_ext4fs \
-l 2048M new_system.img /system
Creating filesystem with parameters:
Size: 2147483648
Block size: 4096
Blocks per group: 32768
Inodes per group: 8192
Inode size: 256
Journal blocks: 8192
Label:
Blocks: 524288
Block groups: 16
Reserved block group size: 127
Created filesystem with 2666/131072 inodes and 375014/524288 blocksGenial, así que aparentemente puedo construir imágenes del sistema a partir de simples carpetas. El cielo será mi límite. Podré añadir lo que quiera a esta imagen.
Quemémoslo...
linuxbox# fastboot flash system new_system.img
erasing 'system'...
OKAY [ 0.064s]
sending 'system' (2088960 KB)...
^CEsperé una hora antes de pulsar ese Ctrl-C. Y tuve que hacer un ciclo de energía con la tablet, que volvió a arrancar en modo de arranque rápido.
Esto no se ve bien.
¿Y si construyo una imagen más pequeña? Tal vez los 2 GB son de alguna manera un problema, y esta partición no se utiliza a plena capacidad - tiene espacio libre:
linuxbox# ../extras/source/extras/ext4_utils/make_ext4fs \
-l 1536M new_system.img /system
linuxbox# ./fastboot flash system system.img
erasing 'system'...
OKAY [ 0.065s]
sending 'system' (1572864 KB)...
OKAY [ 51.039s]
writing 'system'...
OKAY [235.080s]
finished. total time: 286.183sOK, esto parece muy prometedor (y sólo tomó 5 minutos). Supongo que ahora puedo reiniciar y todo debería ser normal, ¿sí?
No :-)
No me importa un dispositivo de ladrillo temporal, siempre y cuando hacer llegar a controlarlo al final (las máquinas de las que no soy un maestro, son máquinas que no me importa operar ;-)
¿Alguna idea de lo que hice mal y de lo que puedo hacer para arreglar esto?
Gracias de antemano.
P.D. Revisé la página de soporte de Asus para mi tablet, sólo proporcionan las fuentes del núcleo, y el archivo .zip Over-the-air. Que a su vez contiene una copia de seguridad a nivel de sistema de archivos de root - es decir, el system existe allí como una carpeta, no una imagen, no una system.img que puedo tener un flash, así que eso no me ayuda mucho.
EPISODIO 2: Ataque de las botas personalizadas
En ausencia de cualquier tipo de recovery.img de Asus (¿por qué un fabricante se molestaría en publicar un flash de arranque rápido recovery.img ? ¿Por qué? y una ausencia similar en las imágenes de recuperación de los sitios CWM y TWRP... ...me quedo solo en la batalla.
Afortunadamente, el archivo de actualización de Asus incluye en su interior...
linuxbox# unzip -l /opt/Asus/firmware/UL-K01E-WW-12.16.1.12-user.zip |\
grep boot.img$
7368704 2011-03-22 11:21 boot.img...la imagen de la bota de mi tablet. Ahora tal vez - sólo tal vez - puedo hacer algo con esto.
linuxbox$ mkdir rootfs
linuxbox$ cd rootfs
linuxbox$ abootimg -x /path/to/boot.img
linuxbox$ ls -l
bootimg.cfg
initrd.img
zImageExpandiendo el ramdisk...
linuxbox$ mkdir initrd
linuxbox$ cd initrd
linuxbox$ gzip -cd ../initrd.img | cpio -ivd
...
linuxbox$ vi default.propYo preparé default.prop para ser Root cuando el núcleo arranque:
ro.secure=0
ro.debuggable=1
ro.adb.secure=0
androidboot.selinux=disabledTambién copié /system/bin/sh ( del archivo .zip de Asus en el aire ) en /sbin/sh . Hice lo mismo con busybox - una herramienta bastante práctica.
Y reempaquetó la bota...
busybox$ find . | cpio --create --format='newc' | gzip -9 > ../initrd.custom.gz
busybox$ cd ..
busybox$ abootimg --create ../new_boot_busybox.img \
-f bootimg.cfg -k zImage -r initrd.custom.gzabootimg en realidad falló la primera vez que dirigí esto, ya que bootimg.cfg tuvo que ser actualizado - el bootsize el parámetro tuvo que ser cambiado, ya que el paquete es más grande ahora. abootimg informa de lo que necesita, así que es bastante fácil.
Y ahora, arranco mi imagen personalizada...
linuxbox# fastboot boot new_boot_busybox.img...y ser testigo de lo siguiente...
linuxbox# adb logcat
- exec '/system/bin/sh' failed: Permission denied (13) -
linuxbox# adb shell
- exec '/system/bin/sh' failed: Permission denied (13) -Hmm... ¿Tal vez el ADB no se ejecuta como Root?
linuxbox# adb root
restarting adbd as root
linuxbox# adb shell
- exec '/system/bin/sh' failed: Permission denied (13) -Bien... Hexedito adbd, y parcheo /sistema/bin/sh para que sea /sbin/sh (copié el /sistema/bin/sh de la imagen OTA a las root del initrd): Reiniciar, arrancar rápido...
linuxbox# adb shell
- exec '/sbin/sh' failed: Permission denied (13) -Maldición. ¿Esta cosa es capaz de hacer algo?
linuxbox# adb pull /proc/partitions
15 KB/s (1272 bytes in 0.079s)Es... veamos:
linuxbox# adb pull /proc/mounts
16 KB/s (1358 bytes in 0.079s)
linuxbox# grep system mounts
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 rw,seclabel,relatime,data=ordered 0 0Bien, entonces el sistema es montado. ¿Puedo ver lo que hay dentro?
linuxbox# adb pull /system
remote object '/system' does not exist¿Qué...? Tal vez pueda comprobar lo que contiene /proc/kmsg (lo que "dmesg" produciría)
linuxbox# adb pull /proc/kmsg
failed to copy '/proc/kmsg' to './kmsg': Operation not permittedNo, necesito ser Root para hacer eso.
linuxbox# adb push /sbin/sh /system/bin/sh
failed to copy '/sbin/sh' to '/system/bin/sh': Permission deniedY eso también.
Esto está resultando ser todo un rompecabezas...
2 votos
Lo único bueno que no hiciste aquí (y que deberías haber hecho) es flashear un Recovery personalizado y luego tomar un nandroid copia de seguridad de las particiones de la misma. Ese es uno de los métodos a prueba de balas por ahí para recuperar los dispositivos de tal estado bricked. Ese Over-the-air.zip (OTA zip) es un zip flashable de recuperación, es decir, para ser flasheado cuando se arranca en la recuperación y siguen un formato de embalaje diferente, pero logra el mismo objetivo. Resumiendo, flashea un Recovery personalizado (o arranca en uno de stock), flashea la ROM de stock y luego experimenta todo lo que quieras.
1 votos
@Firelord: Esa es la cuestión, aunque
fastbootsigue funcionando (responde a las peticiones sin problemas) y por lo tanto puedo grabar cualquier imagen de recuperación, (a) He buscado y no he encontrado ninguna imagen de recuperación CWM o TWRP para ME103K - Supongo que no hay una "genérica" a la que te refieres, ¿verdad? (b) Apagar, pulsar el botón de encendido + volumen hacia abajo no trae la imagen de recuperación - Yo todavía sólo llegar al estado fastboot. Ni idea de por qué. De hecho, nunca he visto el proceso de recuperación (un poco de curiosidad por verlo) ...1 votos
Prueba otras combinaciones de botones como Power+Vol Up+Vol Down para arrancar en modo Recovery. Si tienes acceso al Recovery ZIP de stock, puede que haya un archivo de imagen del Recovery de stock en algún lugar que puedas flashear desde fastboot o arrancar directamente en él (
fastboot boot <FILE>.img), y luego flashear todo el archivo ZIP de stock. Alternativamente, ver si existe (en la web) los archivos de la ROM de stock que se puede flashear usando fastboot.1 votos
@Firelord: No, Asus no proporciona un recovery.zip. Desde el archivo OTA, no hay nada .img-y (
unzip -l UL-K01E-WW-12.16.1.12-user.zip | grep recoverymuestra sólo un par de scripts de shell - Voy a echar un vistazo, pero definitivamente no hayrecovery.imgallí). Buscar en Google tampoco ayudó: no hay imágenes de recuperación de esta tablet en ningún sitio... Supongo que tendré que esperar a que algún alma bondadosaddsu partición de recuperación y compartir?