Rooteo de la tablet Energy Sistem NEO2

En esta entrada explicamos el proceso seguido para rootear una tablet Energy Sistem NEO2 como esta:

Por defecto la tablet está protegida por el fabricante, si intentas acceder con el superusuario "root", obtendrás este mensaje de error:

    $ adb root
    adbd cannot run as root in production builds

Los fabricantes son rehacios a dejar que los usuarios normales tenga acceso root a sus dispositivos, ya que no les gusta que los usuarios normales puedan customizar sus dispositivos (y tampoco que usuarios que no saben lo que hacen los puedan estropear). Si no eres root, tu capacidad de hacer modificaciones en tu dispositivo estará bastante limitada. La intención de esta articulo es hacerse root de la tablet Energy Sistem NEO2. Usaremos como sistema host un Ubuntu Linux 14.04. Advierto que el procedimiento es altamente destructivo si no se hace con cuidado. Advertido quedas, lector!

Averigua el product-id y el vendor-id

Conecta la tablet a tu PC con el cable USB y mira la salida del comando "lsusb":

    $ lsusb

Identifica en el listado una linea como esta:

    Bus 003 Device 066: ID 2207:0011

El ID 2207:0011 se corresponde con tu tablet Energy Sistem de 10.1 pulgadas.

Acceso al dispositivo a través de USB

Configurar el sistema operativo de tu PC para que tenga acceso al dispositivo Android a través del USB. Bajo Ubuntu, los usuarios regulares no pueden acceder directamente a los dispositivos USB por defecto. El sistema necesita estar configurado para permitir tal acceso. La mejor solución consiste en crear un fichero (como usuario root):

    $ sudo vi /etc/udev/rules.d/51-android.rules

Y añadir el siguiente contenido:

    SUBSYSTEM=="usb", ATTR{idVendor}=="<idvendor>", ATTR{idProduct}=="<idproduct>", MODE="0600", OWNER="<username>"

Donde:

• <username>: es el nombre del usuario que estará autorizado a acceder al dispositivo a través del USB
• <idvendor>: es el identificador del vendedor del dispositivo
• <idproduct>: es el identificador del producto

Para el dispositivo que nos ocupa:

    <username> es "aicastell"
    <idvendor> es "2207"
    <idproduct> es "0011"

Por tanto, añade este contenido:

    # adb protocol
    SUBSYSTEM=="usb", ATTR{idVendor}=="2207", ATTR{idProduct}=="0011", MODE="0600", OWNER="aicastell"

Cambia los permisos del fichero:

    $ chmod a+r /etc/udev/rules.d/51-android.rules

Reinicia el servicio del udev:

    $ sudo service udev restart

Estas reglas nuevas pasan a tener efecto la siguiente vez que se conecta un dispositivo. Por tanto, será necesario desconectar el dispositivo y volver a conectarlo al USB.

Customización especial

Este paso no es habitual en todos los dispositivos Android, pero SI es necesario para los dispositivos SOC Rockchip. Si no lo haces, el comando "adb devices" no detectará el dispositivo Android conectado. Crea este directorio:

    $ mkdir ~/.android

Y crea este fichero, con este contenido:

    $ vi ~/.android/adb_usb.ini

    # ANDROID 3RD PARTY USB VENDOR ID LIST -- DO NOT EDIT.
    # USE 'android update adb' TO GENERATE.
    # 1 USB VENDOR ID PER LINE
    0x2207

Habilitar el modo desarrollador Android

En tu dispositivo Android, navega hasta el menu de configuración y busca la opción:

    { } Opciones de desarrollo

Si no tienes acceso a estas opciones, ves al apartado:

    Ajustes > información de la tablet > Numero de compilación

Pulsa varias veces sobre la opción "Numero de compilación" hasta que se active la opción "Opciones de desarrollo".

Ahora navega a traves de estas opciones:

    "Opciones de desarrollo" > "Depuración" > "Depuración USB"

para activar el modo de depuración cuando el dispositivo este conectado por USB.

Android Debug Bridge (ADB)

La herramienta “adb" es esencial para depurar, manejar y personalizar dispositivos Android. "adb" son las siglas de Android Debug Bridge. Esta herramienta esta disponible a partir de Ubuntu 14.04 como binario precompilado. Puedes instalarla usando este comando:

    $ sudo apt-get install android-tools-adb

También se podría compilar descargando los fuentes del Android Open Source Project (AOSP), aunque no es el objetivo de este documento.

Detección del dispositivo

Cuando conectes el dispositivo Android por USB a tu PC, podrás verificar que tu dispositivo esta conectado ejecutando el comando:

    $ adb devices

Desde Android 4.2.2 en adelante se introdujo una nueva caracteristica de seguridad. Debes confirmar que tu dispositivo android esta conectado a un PC autorizado antes de que se permita ningún dialogo. Por tanto, si es la primera vez que lanzas este comando, verás esta salida:

    List of devices attached

    d1548bec06f16120    unauthorized

En este caso, en el dispositivo de Android saldrá una ventana de dialogo preguntando si quieres aceptar la clave RSA que acepte la depuración del dispositivo a través del PC desde el que has conectado. Este mecanismo de seguridad protege al dispositivo frente a ataques remotos, porque asegura que el debugging USB y otros comandos adb no puedan ser ejecutados a menos que seas capaz de desbloquear el dispositivo confirmando este dialogo.

Si no es la primera vez que lanzas el comando, verás esta salida, sin mas:

    $ adb devices
    List of devices attached
    0123456789ABCDEF    device

El problema

El fabricante protege la tablet y no podremos lanzar este comando, ya que genera error:

    $ adb root
    adbd cannot run as root in production builds

El objetivo de este post es encontrar una solución a este problema, así que vamos a analizar este error. Lo primero es buscar en los fuentes de Android (proyecto AOSP) el string del error. Encontramos el mensaje en este fichero:

    $ vi aosp/system/core/adb/services.c

    property_get("ro.debuggable", value, "");
    if (strcmp(value, "1") != 0) {
        snprintf(buf, sizeof(buf), "adbd cannot run as root in production builds\n");
        writex(fd, buf, strlen(buf));
        adb_close(fd);
        return;
    }

Como vemos, el método "property_get" lee el valor de la propiedad "ro.debuggable" y si su valor no es 1, muestra el error "adbd cannot run as root in production builds".

Buscando mas a fondo en los fuentes de Android, encontramos que la función property_get esta definida en este fichero:

    $ vi aosp/system/core/libcutils/properties.c

    int property_get(const char *key, char *value, const char *default_value)
    {
        int len;

        len = __system_property_get(key, value);
        if(len > 0) {
            return len;
        }

        if(default_value) {
            len = strlen(default_value);
            memcpy(value, default_value, len + 1);
        }
        return len;
    }

Por el nombre del método __system_property_get, deducimos que se trata de una propiedad de la partición "system" de Android. Por tanto, el primer objetivo será obtener el contenido de la partición system de la tablet, para modificar su fichero de propiedades (build.prop), añadiendo en su interior la propiedad ro.debuggable=1.

La herramienta rkflashtool

La herramienta "rkflashtool" permite leer/escribir el contenido de cualquier partición de la tablet. Para instalar esta herramienta, lo primero es instalar las dependencias de Ubuntu necesarias para su compilación:

    $ sudo apt-get install build-essential libusb-1.0-0-dev

Descarga la herramienta:

    $ git clone https://github.com/linux-rockchip/rkflashtool

Compila e instala:

    $ cd rkflashtool
    $ make
    $ sudo cp rkflashtool rkcrc rkunpack rkunsign /usr/local/bin

Despues arrancas la tablet en modo bootloader:

    $ adb reboot bootloader

Y ya puedes obtener el layout de la memoria flash con este comando:

    $ rkflashtool p > parameters.txt

En mi caso concreto, tengo este layout:

    NAME OFFSET NSECTORS
    misc 0x00002000 0x00002000
    kernel 0x00004000 0x00006000
    boot 0x0000a000 0x00006000
    recovery 0x00010000 0x00010000
    backup 0x00020000 0x00020000
    cache 0x00040000 0x00040000
    metadata 0x00080000 0x00002000
    kpanic 0x00082000 0x00002000
    system 0x00084000 0x00200000
    vendor 0x00284000 0x00002000
    userdata 0x00286000 -

Ahora puedo leer el contenido de cualquier partición con este comando:

    $ rkflashtool r <nombre_particion> > <nombre_particion>.img

Y puedo grabar el contenido de cualquier partición con este comando:

    $ rkflashtool w <nombre_particion> <nombre_particion>.img

Añadir ro.debuggable=1

Para obtener el contenido de la partición de system hacemos:

    $ sudo rkflashtool r system > system.img

Vemos que system.img es la imagen de un sistema de ficheros en formato ext4:

    $ file system.img
    system.img: Linux rev 1.0 ext4 filesystem data, UUID=da594c53-9beb-f85c-85c5-cedf76546f7a, volume name "system" (extents) (large files)

Podemos montar esta partición system.img en modo loopback:

    $ sudo mount -o loop system.img /media/removable

Cambiar el contenido del fichero build.prop:

    $ vi /media/removable/build.prop
    ro.debuggable=1

Tras desmontar la partición:

    $ sudo umount /media/removable

Vuelve a grabar el contenido con este comando:

    $ rkflashtool w system < system.img

Sin embargo, el problema sigue manifestándose:

    $ adb root
    adbd cannot run as root in production builds

Con esto deducimos que el cliente "adb" conecta con un servicio de la tablet (llamado adbd), que se encarga de decodificar el contenido del fichero build.prop y proporcionar una respuesta al cliente "adb". Si el fichero build.prop tiene la propiedad ro.debuggable=1 y sigue sin funcionar, debe ser porque este servicio adbd esta capado, y siempre devuelve error, independientemente del contenido del fichero de propiedades build.prop.

La herramienta imgrepackerrk

Para solucionar este problema intentaremos reemplazar el adbd capado por uno no-capado. Para ello lo primero es averiguar donde está almacenado el adbd capado. Tras buscar adbd en la partición system, no lo encontramos. Podría estar almacenado en la partición de boot, así que lo primero es leer su contenido con la herramienta rkflashtool:

    $ rkflashtool r boot > boot.img

Vemos que la imagen de boot (boot.img) no se puede montar, pues se trata de un fichero de datos, no de un sistema de ficheros:

    $ file boot.img
    boot.img: data

Necesitamos una herramienta para extraer el contenido de esta partición. En este foro de xda-developers:

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

encontramos la herramienta "imgrepackerrk" (versión 104). Esta utilidad permite desempaquetar/reempaquetar imágenes de boot.img.

Tras descargar la herramienta, la instalámos en nuestra máquina, copiandola en /usr/local/bin:

    $ cp imgrepackerrk /usr/local/bin
    $ chmod 755 /usr/local/bin/imgrepackerrk

Usamos esta herramienta para extraer el contenido de la imagen boot.img:

    $ imgrepackerrk boot.img

Una vez desempaquetado el contenido de boot.img, buscamos el servicio adbd en su interior:

    $ find boot.img.dump/ | grep adbd
    boot.img.dump/ramdisk.dump/sbin/adbd

Efectivamente, el servicio se encuentra dentro de esta partición. Este fichero es el que creemos que está capado, y hay que reemplazar por un servicio adbd que no este capado.

El servicio adbd no-capado

El servicio adbd no-capado lo vamos a obtener descargando el paquete adbd-Insecure-v2.00.apk desde esta URL:

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

El checksum del archivo descargado es este:

    $ md5sum adbd-Insecure-v2.00.apk
    df9ef24983dd29530bbbe2a7caeb35d8  adbd-Insecure-v2.00.apk

Descomprime su contenido:

    $ unzip adbd-Insecure-v2.00.apk

Dentro de este apk encontraremos el nuevo adbd no-capado, que curiosamente tiene una extensión .png (normalmente usada para fotos), aunque vemos que en realidad no se trata de una foto, se trata de un binario ejecutable:

    $ file ./assets/adbd.21.png
    ./assets/adbd.21.png: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, stripped

Reemplaza este archivo adbd.21.png por el adb capado:

    $ cp ./assets/adbd.21.png boot.img.dump/ramdisk.dump/sbin/adbd

Reempaqueta la imagen boot.img con el nuevo servicio adbd no-capado:

    $ imgrepackerrk boot.img.cfg

El comando anterior reempaqueta la imagen boot.img con un adbd no-capado que esperamos que resuelva nuestro problema inicial.

Graba el nuevo boot.img en la flash:

    $ rkflashtool w boot < boot.img

Disfrutar del resultado

Reinicia la tablet. Si todo ha ido bien podrás disfrutar de tu tablet rooteada:

    # adb root
    adbd is already running as root

    # adb remount
    remount succeeded