Tutorial para recuperar un Samsung Galaxy Y después de un flasheo fallido del boot.img

Cuando falla el flasheo del boot.img el teléfono puede quedar en uno de estos dos estados:

ESTADO 1: No arranca en modo normal. Sí arranca en modo recovery.

ESTADO 2: No arranca en modo normal ni en modo reccovery, quedándose colgado en la pantalla de inicio

El boot.img es la unión del kernel y el ramdisk. Si las modificaciones han sido hechas en el kernel, el teléfono debería arrancar en modo recovery por lo que habría más opciones de recuperación además de la que vamos a ver. En el segundo caso caso las modificaciones fallidas se han hecho en el ramdisk, por lo que ya ni siquiera se llega a montar la partición de recovery.

Necesitamos:

– El boot.img anterior a nuestra metedura de pata, que deberíamos tener ya como backup en el PC.

– El programa Odin3 v1.85 desde donde efectuar el flasheo (descargar aquí). Ojo porque otras versiones anteriores no reconocen al SGY (creo que lo hacen a partir de la 1.75). Por otra parte he leido que versiones anteriores de Odin no eran capaces de flashear desde un sólo fichero.

– Drivers USB para que el teléfono sea reconocido en el PC. A mí me ha sacado de apuros este blog, que además de proporcionar el SAMSUNG_USB_Driver_1.5.4.0.rar que funciona perfectamente, nos advierte de manera muy acertada:

Ojo, si un driver no funciona hay que desinstalarlo desde el panel de control, reiniciar y ahí probar con otro. Y también probar en distintos puertos USB.

Actualización: Me comenta un lector que los drivers anteriores no le funcionaron y lo pudo solucionar dejando el móvil conectado e instalando el Driver Genius Pro 11. Desde aquí mi agradecimiento por el aporte.

Procedimiento:

Paso 1: Preparamos nuestro boot.img (desde Linux) para que sea flasheable con Odin, ya que necesita que esté empaquetado como tar.

tar -cf boot-sgy.tar boot.img

Nota: El nombre del fichero .tar puede ser cualquiera.

Paso 2: Si no los tenemos ya, instalar los drivers USB de Samsung. Si se han instalado previamente otros drivers hay que desinstalarlos primero desde el Panel de Control-Agregar o quitar programas.

Paso 3: Ponemos el teléfono en Modo Download (Odin Mode Download). Pulsamos Vol- y home, y con ellos dos pulsados le damos a la tecla de encendido.

Odin Warning

Después del mensaje de advertencia pulsamos Vol+ y el teléfono queda en espera

Odin mode downloading
Paso 4: Ejecutamos Odin3 versión 1.85. Lo primero es conseguir que detecte al teléfono. Hacemos la conexión por un puerto USB. Si todo va bien veremos que el recuadro “ID:COM” de la izquierda se pone amarillo.

Odin conectado
Si no se pone amarillo hay que verificar que los drivers están correctamente instalados. He leido también que se debe conectar el USB original sin alargadores y a un puerto trasero de le CPU mejor que a uno delantero.

Cuando se consigue la conexión, hay que dejar las opciones que vienen por defecto.

Opciones

Marcamos en PDA y pulsamos el botón del mismo nombre para indicarle a Odin dónde está el fichero que queremos flashear.Una vez encontrado pulsamos Start.

En la parte de los mensajes va saliendo el log:

<ID:0/003> Added!!
<ID:0/003> Odin v.3 engine (ID:3)..
<ID:0/003> File analysis..
<ID:0/003> SetupConnection..
<ID:0/003> Initialzation..
<ID:0/003> Get PIT for mapping..
<ID:0/003> Firmware update start..
<ID:0/003> boot.img
<ID:0/003> NAND Write Start!! 
<ID:0/003> RQT_CLOSE !!
<ID:0/003> RES OK !!
<ID:0/003> Completed..
 All threads completed. (succeed 1 / failed 0)
<ID:0/003> Removed!!

y en varios segundos ya está

Terminado

El teléfono se reinicia y milagrosamente vuelve a la vida en el familiar modo recovery.

recovery

Basta reiniciar en la primera opción y arrancará en modo normal tal como lo habíamos dejado, ya que al restaurar sólo el boot.img conservaremos todas nuestras aplicaciones, datos, etc.

Publicado en B5510, ROM, root, Seguridad | Etiquetado , , , , , , , , , , , , , , , , | 75 comentarios

Soporte para poder ejecutar scripts en /etc/init.d antes del arranque


ATENCIÓN: de momento este procedimiento está en cuarentena y lo pongo solamente con fines teóricos, ya que después de seguirlo el teléfono dejó de arrancar en modo normal y en modo recovery,  teniendo que hacer una restauración con Odin desde el modo download.  Si averigüo lo que ha fallado actualizaré esta entrada.

Mediante este procedimiento se puede conseguir la capacidad de ejecutar scripts desde el init.d para los teléfonos que no la tienen.

Consiste en extraer el ramdisk del teléfono, modificarlo y volverlo a flashear. El esquema es el siguiente:

Requisitos:

– Samsung Galaxy Y creo que funciona por lo menos en los modelos

GT-S5360, GT-S5360B, GT-S5360L, GT-S5360T, GT-S5363, GT-S5369, GT-B5510 y GT-S5701

– Acceso root
– PC con linux
– Tener busybox en la ruta /system/xbin/ del teléfono

En primer lugar conviene comprobar que no se tiene soporte para init.d. Se puede hacer con este programa que se ejecuta desde modo recovery, explicado en esta página por su autor. Si después de ejecutarlo no aparece el fichero Test.log en /data quiere decir que tu teléfono no tiene soporte para init.d.

Pasos

1. Backup del boot.img de nuestro teléfono
2. Separar el Kernel y el ramdisk
3. Extraer el filesystem del ramdisk
4. Modificaciones en el ramdisk
5. Volver a construir el boot.img con el nuevo ramdisk
6. Flashear el nuevo boot.img

1. Backup del boot.img de nuestro teléfono

El ramdisk es básicamente un sistema de ficheros que contiene el núcleo de ficheros necesarios para inicializar el sistema, y es utilizado por el kernel al comienzo del arranque del móvil. Para conseguir una copia de nuestro ramdisk tenemos que hacer un backup del boot.img, que es un fichero imagen que contiene ambos: kernel y ramdisk.

– Bajarse el kernel_backup.zip

– Ejecutaremos el fichero desde el recovery del ClockWorkMod. Aquí explico como instalar el ClockWorkMod. Una vez en el menú del recovery hay que:

– seleccionar la opción “install zip from sdcard”
– en el menu que se abre seleccionar “choose zip from sdcard
– ir hasta el archivo .zip que pusimos en la tarjeta sd y seleccionarlo
– confirmar la instalación seleccionando “Yes — Install kernel_backup.zip
– al terminar la instalación salir conreboot system now

Ahora ya tenemos en el raiz de la tarjeta sd un fichero llamado kernel_boot.img que debemos renombrar como boot.img. La razón de renombrarlo es que este boot.img original quedará en /sdcard con ese nombre por si en algún momento futuro es necesario restaurarlo.

– Colocamos el boot.img en un directorio del PC que llamaremos /sgy

Este fichero hay que guardarlo a buen recauto. Conviene hacerle una copia y guardarla en sitio seguro, ya que si nos falla el flasheo la necesitaremos para la restauración.
2. Separar el Kernel y el ramdisk

– Bajarse el split_bootimg.pl a la carpeta ~/sgy y ejecutar en el PC los comandos

cd ~/sgy/
perl split_bootimg.pl boot.img

Tenemos ahora el “boot.img-kernel” y el “boot.img-ramdisk.gz”. Ya tenemos el kernel y el ramdisk por separado.

3. Extraer el filesystem del ramdisk

– Creamos en ~/sgy un directorio llamado “ramdisk” donde copiamos el boot.img-ramdisk.gx. El sistema de ficheros está metido en un contenedor cpio y comprimido con gzip, por lo que hay que hacer el proceso inverso.

– Descomprimir el gzip. Desde ~/sgy/ramdisk/ metemos

gzip -d boot.img-ramdisk.gz

Lo convierte en un contenedor cpio llamado “boot.img-ramdisk”

– Extraer el sistema de ficheros.

cpio -iv < boot.img-ramdisk

– Ahora en ~/sgy/ramdisk/ ya tenemos el sistema de ficheros. Borramos el contenedor “boot-img-ramdisk.gz” porque ya no lo necesitaremos y cuando haya que volver a comprimir no lo queremos ahí.

rm boot.img-ramdisk

4. Modificaciones en el ramdisk

Para tener soporte para el init.d hay que añadir varias líneas al final del archivo init.rc, que es uno de los que se encuentran en el ramdisk

# Execute files in /etc/init.d before booting
service userinit /system/xbin/busybox run-parts /system/etc/init.d
    oneshot
    class late_start
    user root
    group root

Ojo, asegurarse que en /system/xbin del teléfono tenemos el busybox. Si no es así conseguimos uno y lo metemos en esa ruta (instalando el apk o por comando desde un emulador de terminal).

Ahora hay que volver a empaquetar el sistema de ficheros del ramdisk en un contenedor cpio y comprimirlo con gzip. Desde ~/sgy/ramdisk/metemos

find . | cpio -o  -H newc | gzip > ../boot.img-ramdisk-modificado.gz

Ya tenemos en ~/sgy/el ramdisk modificado y listo para juntarlo al kernel

5. Volver a construir el boot.img con el nuevo ramdisk

– desde  ~/sgy calculamos el md5sum del “boot.img-kernel” que habíamos separado en el punto 2.

md5sum boot.img-kernel

Un md5sum es un hash md5 del archivo, que proporciona un número prácticamente único para cada archivo. La salida será algo similar a esto:

1fd319aa60abc2abae2e5932bcb9fc77  boot.img-kernel

con la diferencia de que la cadena alfanumérica será distinta a esta. La cadena hay que copiarla en algún sitio y guardarla, ya que se necesitará dentro de poco.

Toca ahora reempaquetar nuestro nuevo boot.img, que ya quedará listo para flashearlo en el teléfono. Utilizaremos el mkbootimg. Este programa utiliza como parámetros los ficheros que hemos ido preparando anteriormente:

– el boot.img-kernel, donde está el kernel original del teléfono
– el boot.img-ramdisk-modificado.gz, con el ramdisk que hemos modificado

Los comandos son los siguientes:

chmod +x mkbootimg --> nos aseguramos que tenemos permiso de ejecución
../mkbootimg --kernel boot.img-kernel --ramdisk boot.img-ramdisk-modificado.gz --base 0x81600000 --kernelMD5 1fd319aa60abc2abae2e5932bcb9fc77 -o boot.img

Ojo, tu cadena md5sum será distinta de la mía.

.

6. Flashear el nuevo boot.img

ATENCIÓN: Este paso puede ser peligroso para tu teléfono y lo haces bajo tu propia responsabilidad

Después del necesario mensaje de advertencia, decir que con este método de flasheo tenemos también un procedimiento de recuperación en caso de fallo.

Se necesita este fichero:

kernel_actualizar.zip –> flashea el fichero creado por nosotros con el mkbootimg, renombrado ahora como boot_com.img, y que debe estar situado en el raiz de la sdcard

Ha llegado el momento de sustituir el boot.img por el que acabamos de crear. Lo haremos desde el modo recovery con el ClockWorkMod Recovery.

6.1 En la sdcard tengo ya el boot.img original por si acaso hay que restaurar. No está de más comprobar que lo tengamos realmente.
6.2 Renombramos el boot.img recién creado, como boot_com.img y lo metemos en /sdcard a través del cable USB.
6.3 Metemos también de la misma forma en /sdcard los ficheros Kernel_actualizar.zip y kernel_restaurar.zip
6.4 Arrancamos en modo recovery (Vol+, Home y Power) y ejecutamos el ClockWorkMod.
Desde su menú instalamos el kernel_actualizar.zip (tal como lo habíamos hecho en el punto 5.2), que se encarga de buscar en el raiz de la sdcard el fichero boot_com.img y flashearlo. A continuación reiniciamos.
Por último, volvemos a hacer el test del principio para comprobar si ya se ejecutan en nuestro teléfono los scripts situados en el init.d

Enlaces

Arranque en Android muy bien explicado: http://wiki.acsblog.es/acswiki/InitAndroid

Publicado en B5510, root, Seguridad | Etiquetado , , , , , , , , , , , , , | Deja un comentario

Droidwall a fondo. Tutorial para el cortafuegos Droidwall 1.5.7

Para disfrutar de esta estupenda aplicación open source de Rodrigo Zechin Rosauro (un desarrollador de São Paulo (Brasil) al que le estoy muy agradecido por su esfuerzo desinteresado) me fue necesario compilar y flashear el kernel, pero ha valido la pena. En mi Samsung Galaxy Y Pro B5510 salía el error “no chains/target/match by that name” que pude solucionar como detallo en esta otra entrada.

He tratado de hacer un tutorial lo más completo posible para animar a que cada vez más gente utilice el Droidwall. Serán bienvenidas las aportaciones, correcciones y sugerencias en los comentarios.

Contenido

1. Listado de aplicaciones
2. Modos de funcionamiento
3. Opciones del menú
4. Añadir el widget
5. Localización de Droidwall
6. Forma de trabajo
7. Las reglas de iptables
8. El script "droidwall.sh"
9. El estado inactivo
10. Custom scripts. Añadir reglas personalizadas
11. Exportar el Log a un fichero
12. Algunos problemas que pueden surgir
13. Palabras finales
14. Enlaces

1. El listado de aplicaciones

El Droidwall es un cortafuegos que utiliza el iptables de linux para filtrar los paquetes y necesita tener acceso root. Muestra un listado con las aplicaciones, y hace posible de manera muy sencilla que podamos seleccionar qué aplicaciones pueden salir y cuales no. Además nos da la facultad de escoger por qué interfaz le permitimos la salida: wifi o 3G (esta expresión engloba los interfaces 2G, 3G, 4G, etc).

A la izquierda de cada fila aparece, cuando lo hay, el icono de cada aplicación. A continuación están dos columnas de casillas en las que marcar cuando damos permiso a una aplicación (wifi y 3G). El listado está compuesto por todas las aplicaciones instaladas que tienen permiso para acceder a internet (hasta la versión 1.3.7 las mostraba todas), y también por lo que su creador ha llamado “aplicaciones especiales”, que son las siguientes:

Any application: marcar esta opción es lo mismo que marcar todas las aplicaciones una a una, pero tiene la ventaja de que emplea una sola regla en iptables haciendo más rápida la generación de reglas y el filtrado de paquetes.
Linux Kernel: desde el kernel también puede haber accesos a la red, como estos intentos de conexión a direcciones ip de la red de google:

Kernel
Root : marca de una sola vez todas las aplicaciones que están siendo ejecutadas con permisos de root.
Media server: para reproducir vídeos desde la red. Si no está marcada no se pueden ver los vídeos de youtube.
VPN networking: conexiónes a una red privada virtual.
Linux shell (uid:2000): para establecer conexiones adb sobre wifi .

En el listado de aplicaciones que muestra Droidwall aparecen primero las que tienen alguna casilla marcada, y a continuación todas las demás por orden alfabético.

2. Modos de funcionamiento

Pulsando en la zona de arriba encima del listado de aplicaciones podemos elegir el criterio a seguir para generar las reglas en iptables.

lista blanca: permitir salida a red a las aplicaciones seleccionadas
lista negra: bloquear salida a red a las aplicaciones seleccionadas

Para mi gusto da más tranquilidad usar el modo lista blanca. Así nos aseguramos que sólo tendrán acceso al exterior las aplicaciones a las que se lo permitamos expresamente. La idea es partir de todo cerrado e ir permitiendo lo que vamos necesitando:

– si necesitamos enviar sms, le permitimos la salida por 3G a la apliación de mensajería que utilicemos.
– si queremos ver vídeos desde la aplicación youtube, le permitimos la salida a dicha aplicación (para las búsquedas) y también a otra llamada “Media Server” (para reproducir los vídeos)

3. Opciones del menú

Al pulsar el botón menú nos aparecen estas opciones:

Estado del firewall

Estado FirewallPor un error en la traducción al español las cadenas de ambos estados se han cambiado. Cuando está en verde está activo (aunque ponga “Firewall inactivo” y viceversa)

En el código fuente se puede apreciar este error de traducción:

Error traducción

El estado del cortafuegos nada más instalar Droidwall es “inactivo”. No era así inicialmente, pero había usuarios que lo instalaban y se olvidaban de aplicar las reglas, quedando el cortafuegos en estado “activo” pero sin reglas de filtrado.

Estado del Log

Estado logCuando el Log está activo se añaden a las reglas del cortafuegos las que permite loguear los paquetes rechazados. Al dejarlo inactivo se suprimen dichas reglas.

La posibilidad de ver el Log se añadió en la versión 1.4.2 y fue un avance muy importante, condicionado eso sí por la existencia en el kernel del módulo que añade el “LOG target”.

Aplicar reglas

Al pulsar este botón Droidwall da instrucciones a iptables para que genere y aplique las reglas. Como esto requiere acceso al kernel el cortafuegos necesita permisos de superusuario (de ahí la necesidad de tener el teléfono rooteado) y aparece el siguiente mensaje del sistema operativo:

la ruta de la parte final del texto es el lugar de la memoria interna donde se encuentra el script que utiliza Droidwall para generar las reglas, cuyo nombre es “droidwall.sh“. Más adelante hablaremos de él.

Quedan unas cuantas opciones del menú que el desarrollador ha incluido en el botón “Más” por falta de espacio.

Menu Mas

mostrar log: muestra para cada aplicación información sobre los paquetes interceptados. En el Log se detallan los intentos de conexión por parte de aplicaciones que no tienen la salida a red permitida, como en este ejemplo:

La información proporcionada es: aplicación que realiza el intento de conexión, uid de la aplicación, número de paquetes interceptados y dirección ip de destino.

En caso de que el Log esté vacío sale el mensaje

log vacíomostrar reglas: aquí se pueden ver las reglas generadas en iptables

reglas

borrar log: el Log de droidwall se almacena en la memoria interna y con esta opción lo borramos.

definir contraseña: para el que quiera acceder a Droidwall de forma segura

definir script personalizado: los usuarios con conocimientos de iptables pueden hacer su propio script. Más adelante veremos cómo.

4. Añadir el widget

En la versión 1.4.0 se incluyó un widget para poder cambiar entre los estados activo/inactivo directamente desde el home. Para añadir el widget de Droidwall, desde home pulsar un par de segundos en la pantalla y aparece el menú de “añadir a pantalla de inicio”, seleccionar “Widgets” y ya está.

5. Localización de Droidwall

Los ficheros de Droidwall se localizan en la siguiente ruta de nuestro teléfono correspondiente a la partición /data de la memoria interna:

/data/data/com.googlecode.droidwall/

Aquí se almacena la estructura de directorios de la aplicación, consistente en tres carpetas

directorios droidwall

En app_bin se encuentran tres ficheros:

busybox_g1: desde la versión 1.4.2 se incluye un binario de busybox, que incluye muchas herramientas de Unix, algunas de las cuales necesita Droidwall.
droidwall.sh: es un script que se genera cada vez que se van a actualizar las reglas de iptables. Una vez generado se ejecuta para que iptables cree las reglas.
iptables_armv5: es el binario de iptables compilado para la arquitectura ARM que necesita Droidwall. Desde la versión 1.5.2 se incluye este binario cuya versión de iptables es la 1.4.10. El binario iptables que trae el kernel (/system/bin/iptables) en los Gingerbread es la 1.3.7 y no sirve para Droidwall. Aunque inicialmente Droidwall utilizaba el iptables del sistema, el autor compiló un kernel más actualizado y lo incluyó desde la versión 1.4.0 en la aplicación para que se pudiese utilizar desde más modelos de teléfono.

6. Forma de trabajo

Droidwall no está permanentemente activo como los antivirus u otros cortafuegos, ya que es sólo un front-end para iptables/netfilter. El trabajo de interceptar los paquetes lo hace netfilter desde el kernel de linux.

netfiiter

La intención de su creador fue que Droidwall no tuviera que estar residente en memoria constantemente corriendo como un servicio todo el tiempo, sino que se activase solamente ante determinados eventos para luego volverse a cerrar. Esta decisión tiene sus consecuencias, como que desde Droidwall no se pueda ir almacenando el Log entero en un fichero.

Los eventos que provocan la activación de Droidwal (listados desde la aplicación Autostarts) son:

Vamos a ver qué es lo que pasa cuando se produce cada uno de estos eventos.

After Startup: Si tenemos activado el cortafuegos, el Droidwall se ejecuta cada vez que se encienda el teléfono, apareciendo el mensaje del sistema que avisa de que se le han concedido permisos de superusuario. Simplemente ejecuta el script almacenado en la ruta /data/data/com.googlecode.droidwall/app_bin/droidwall.sh, que se encarga de mandar a iptables que genere las reglas para que netfilter pueda hacer el filtrado de paquetes.

procesoA continuación Droidwall se cierra y queda actuando netfilter desde el kernel.

Application installed: este evento ocurre cada vez que instalamos una aplicación. En ese caso Droidwall debe activarse,  incluirla en el script y ejecutarlo para que iptables genere las nuevas reglas . Si está trabajando en modo lista blanca la aplicación tendrá por defecto denegada la salida a red. En modo lista negra no lo he probado.

Cuando entramos en Droidwall nos muestra en primer lugar las aplicaciones instaladas desde la última vez que entramos, para que podamos elegir si queremos marcar alguna de las casillas sin tener que buscar por el listado. En segundo lugar muestra las que tienen alguna casilla marcada, y por último todas las demás por orden alfabético.

Application removed: después de desinstalar una aplicación también hay que actualizar las regas de la misma manera que en el caso anterior, eliminando de ellas si es necesario la aplicación que acabamos de desinstalar.

Widget updating: Droidwall viene con un widget para que se pueda cambiar el estado del cortafuegos de actuvo a inactivo desde el home. Este evento se produce cada vez que el usuario utiliza el widget.

En este esquema vemos de manera gráfica el funcionamiento de Droidwall activandose su proceso com.googlecode.droidwall ante ciertos eventos, así como la existencia o no de las reglas en iptables según el estado del cortafuegos:

Esquema

7. Las reglas de iptables

Para ver realmente cuales son las reglas con las que Droidwall configura en nuestro teléfono es necesario instalar primero un emulador de terminal, como por ejemplo este, llamado Android Terminal Emulator de Jack Palevich (ver web del proyecto)

Terminal Emulator

y teclear los siguientes comandos:

su
/data/data/com.googlecode.droidwall/app_bin/iptables_armv5 -L -v -n

El resultado es algo parecido a esto:

Para poder interpretar las reglas conviene tener una idea de cómo funciona iptables. Hay muchos tutoriales sobre iptables. Estos dos están muy bien.

IPTABLES. Manual práctico de Pello Xabier Altadill Izura
Tutorial de IPtables de Oskar Andreasson

En este esquema se muestra un poco de como funcionan las cadenas en iptables

Dentro de las cadenas se colocan las reglas de filtrado de paquetes.

De todas formas no hace falta estudiarse a fondo los tutoriales. La forma en que Droidwall configura las reglas se puede ver con un ejemplo.

En un teléfono con Droidwall instalado y con las reglas aplicadas por ejemplo para rechazar el tráfico 3G y permitir sólo algunas aplicaciones por wifi, lo que aparecería al listar las reglas  sería esto:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
0     0 droidwall  all    —  *      *       0.0.0.0/0            0.0.0.0/0
Chain droidwall (1 references)
pkts bytes target     prot opt in     out     source               destination
0     0 RETURN     udp  —  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:53
0     0 droidwall-3g  all    —  *      rmnet+  0.0.0.0/0            0.0.0.0/0
0     0 droidwall-3g  all    —  *      pdp+    0.0.0.0/0            0.0.0.0/0
0     0 droidwall-3g  all    —  *      ppp+    0.0.0.0/0            0.0.0.0/0
0     0 droidwall-3g  all    —  *      uwbr+   0.0.0.0/0            0.0.0.0/0
0     0 droidwall-3g  all    —  *      wimax+  0.0.0.0/0            0.0.0.0/0
0     0 droidwall-3g  all    —  *      vsnet+  0.0.0.0/0            0.0.0.0/0
0     0 droidwall-3g  all    —  *      ccmni+  0.0.0.0/0            0.0.0.0/0
0     0 droidwall-3g  all    —  *      usb+    0.0.0.0/0            0.0.0.0/0
0     0 droidwall-wifi  all    —  *      tiwlan+  0.0.0.0/0            0.0.0.0/0
0     0 droidwall-wifi  all    —  *      wlan+   0.0.0.0/0            0.0.0.0/0
0     0 droidwall-wifi  all    —  *      eth+    0.0.0.0/0            0.0.0.0/0
0     0 droidwall-wifi  all    —  *      ra+     0.0.0.0/0            0.0.0.0/0
Chain droidwall-3g (8 references)
pkts bytes target     prot opt in     out     source               destination
0     0 droidwall-reject  all    —  *      *       0.0.0.0/0            0.0.0.0/0
Chain droidwall-reject (2 references)
pkts bytes target     prot opt in     out     source               destination
0     0 LOG        all    —  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 8 level 4 prefix `[DROIDWALL] ‘
0     0 REJECT     all    —  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
Chain droidwall-wifi (4 references)
pkts bytes target     prot opt in     out     source               destination
0     0 RETURN     all    —  *      *       0.0.0.0/0            0.0.0.0/0     owner UID match 1014
0     0 RETURN     all    —  *      *       0.0.0.0/0            0.0.0.0/0     owner UID match 1010
0     0 RETURN     all    —  *      *       0.0.0.0/0            0.0.0.0/0     owner UID match 10027
0     0 RETURN     all    —  *      *       0.0.0.0/0            0.0.0.0/0     owner UID match 10063
0     0 droidwall-reject  all    —  *      *       0.0.0.0/0            0.0.0.0/0

.

NOTA: las dos reglas que están en color rojo existen solamente si el LOG de Droidwall está puesto en “estado activo”. Se borran cuando pulsamos para desactivar el Log y se crean cuando pulsamos activar el Log.

En primer lugar está la política por defecto para las cadenas INPUT, FORWARD y OUTPUT que en los tres casos es ACCEPT (también podría ser DROP)

En la cadena OUTPUT hay una regla que manda todo el tráfico a otra subcadena creada por el cortafuegos, llamada droidwall. Esto quiere decir que todo el tráfico de salida se encamina a dicha cadena en primer lugar.

En la cadena droidwall el tráfico se manda a otras subcadenas según el interfaz de salida, excepto el tráfico UDP destinado al puerto 53,  que se supone va destinado al DNS y se le aplica (con el RETURN) la política por defecto de la cadena OUTPUT que en este caso es ACCEPT. Esta regla (en rojo) sólo se crea cuando lo necesita el Log.

El tráfico destinado a cualquier interfaz que sea por wifi se encamina a la cadena droidwall-wifi y el tráfico destinado a la red móvil a la cadena droidwall-3g.

En la cadena droidwall-3g todo el tráfico se envía a la cadena droidwall-reject, que es donde se va a tratar todo el tráfico rechazado, enviándolo al Log antes de rechazarlo para poder analizarlo posteriormente. La regla que está en rojo es la que hace que se genere un Log con los paquetes rechazados, y se crea siempre que está el Log activo.

En la cadena droidwall-wifi están las reglas con las aplicaciones permitidas.

Las dos primeras líneas las añade siempre droidwall para asegurarse que tengan acceso a red el DHCP (uid 1014) que nos permite recibir una dirección ip, y la conexión wifi (uid 1010). Los uid de nuestras aplicaciones estarán a partir del 10000 (cinco cifras), que serían las líneas tercera y cuarta. En el ejemplo tiene las UID 10027 y 10063.

Vemos que lo que hace Droidwall es añadir dentro de la cadena OUTPUT una serie de subcadenas donde colocará sus reglas:

subcadenas

La idea de utilizar estas subcadenas personalizadas se puso en práctica en la versión 1.4.0 para evitar conflictos con otras aplicaciones que también utilizan iptables.

Si lo que queremos es exportar las reglas a un fichero valdría este comando:

su -> (ojo, este comando solo es necesario ejecutarlo una vez en cada sesión)
/data/data/com.googlecode.droidwall/app_bin/iptables_armv5 -L -v -n > /mnt/sdcard/reglas.txt

8. El script droidwall.sh

Cada vez que Droidwall necesita que iptables genere las reglas para netfilter lo que hace es ejecutar un script situado en:

/data/data/com.googlecode.droidwall/app_bin/droidwall.sh

En primer lugar busca el binario de busybox (el fichero busybox_g1), ya que necesita las utilidades grep y echo. Si no encuentra grep nos dará un error (“The grep command is required. DroidWall will not work.”), ya que esta herramienta es fundamental para Droidwall. A continuación busca el binario que contiene a iptables (el fichero iptables_armv5) y una vez encontrado borra las reglas preexistentes (sólo en las cadenas pertenecientes a Droidwall) y ejecuta los comandos para crear las nuevas reglas.

El script que genera las reglas del ejemplo del apartado anterior lo puedes encontrar en este enlace.

El droidwall.sh se vuelve a crear cada vez que se actualizan las reglas desde Droidwall: al inicio, al poner el cortafuegos en estado activo, al pulsar el botón “Aplicar Reglas”, y también si es necesario después de instalar o desinstalar aplicaciones.

9. El estado inactivo

¿Qué ocurre cuando pasamos Droidwall a estado inactivo? Para entenderlo veamos primero cuales son las reglas que quedan en iptables al desactivar el cortafuegos. Primero entramos en Droidwall y lo desactivamos. Nos salimos y entramos en el Terminal Emulator como hicimos más arriba en el apartado “Las reglas de iptables”, e introducimos los comandos vistos para listar las reglas. ¿Que sale? Pues esto:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
0     0 droidwall  all    —  *      *       0.0.0.0/0            0.0.0.0/0
Chain droidwall (1 references)
pkts bytes target     prot opt in     out     source               destination
Chain droidwall-3g (0 references)
pkts bytes target     prot opt in     out     source               destination
Chain droidwall-reject (0 references)
pkts bytes target     prot opt in     out     source               destination
Chain droidwall-wifi (0 references)
pkts bytes target     prot opt in     out     source               destination

.

Son las mismas cadenas que antes pero se les han borrado las reglas. En la práctica es como si estuviesen solamente las tres cadenas INPUT, FORWARD y OUTPUT con sus políticas por defecto ACCEPT. No hay restricciones de tráfico. Sin embargo aunque se han borrado las reglas, ha quedado intacta la estructura de subcadenas de Droidwall.

Es importante entender que al dejar inactivo el cortafuegos estamos borrando todas las reglas existentes en las subcadenas de Droidwall. Las cadenas INPUT, FORWARD y OUTPUT no las toca.

10. Custom scripts. Añadir reglas personalizadas

En la versión 1.5.3 de Droidwall su autor Rodrigo Zechin implementó una petición de algunos de los usuarios que solicitaban que se pudieran personalizar las reglas. Añadió la opción Definir script personalizado (custom script), desde la que es posible cambiar la ruta y nombre del script que Droidwall va a ejecutar cada vez que necesite actualizar las reglas. Es decir, creamos un nuevo script, lo colocamos en el teléfono y le decimos a Droidwall que lo ejecute siempre en lugar del droidwall.sh.

Al pinchar en dicha opción, aparece un formulario con dos cuadros de texto.

* En el primero debemos meter la nueva ruta de la siguiente manera: un punto “.” seguido de un espacio ” ” y a continuación la ruta a nuestro script, como por ejemplo:

Custom Script

Y se pulsa el botón “aceptar” de abajo. Las reglas anteriores (sólo las contenidas en las subcadenas de Droidwall) serán borradas antes de aplicar las del nuevo script. A partir de este momento nuestro script será ejecutado en todos los casos en que antes se ejecutaba el droidwall.sh. También se posible meter varias líneas con el mismo formato indicando distintos scripts que deben ejecutarse uno a continuación del otro. En caso de que se quiera volver a trabajar con el droidwall.sh se dejaría el cuadro de texto en blanco y se le daría a aceptar.

La ventaja de utilizar un script personalizado es poder aprovechar las capacidades de iptables con toda su potencia, añadiendo posibilidades de filtrado como puertos de origen y destino, direcciones ip, tipo de protocolo, estado de la conexión, etc.

* El segundo cuadro de texto se refiere a otra opción llamada Custom shutdown script (script de apagado) consistente en definir otro script para que se ejecute cuando Droidwall pase al estado desactivado.

Script Personalizado 2

El shutdown script es necesario en caso de que el custom script añada reglas en cadenas distintas de las de Droidwall. Supongamos que nuestro custom script añadimos una regla a la cadena OUTPUT. Cada vez que sea ejecutado, añadirá la misma regla duplicándola en iptables una y otra vez. Para evitar esto es posible borrar las reglas necesarias desde el shutdown script.

Cada vez que pasemos el cortafuegos a estado inactivo se borrarán primero todas las reglas contenidas en las subcadenas de Droidwall, y a continuación se borrarán las que definamos desde el shutdown script.
Tanto en el custom script como el shutdown script las reglas deben escribirse como cadenas de texto. Pueden ir dentro de un fichero .sh referenciado como se indicó más arriba, o dentro de sus respectivos cuadros de texto, sin necesidad de colocar los ficheros de script en el teléfono. Iptables debe invocarse mediante la variable $IPTABLES, como en el siguiente ejemplo:

#bloquear la navegación por internet
$IPTABLES -A "droidwall" -p TCP --destination-port 80 -j "droidwall-reject"

Cuando estén cubiertos ambos o alguno de los cuadros de texto del formulario de script personalizado, pulsaremos el boton “Aceptar”.

Esta nueva posibilidad de scripts personalizados conlleva sin embargo ciertos riesgos ya que nuestros scripts siempre serán ejecutados como root. Por esa razón no debemos colocarlos en /sdcard ya que cualquier aplicación podría modificar las reglas.

La opción de custom script está muy bien explicada por el autor (en ingles) con unos cuantos ejemplos de reglas en esta página.

11. Exportar el Log a un fichero

Cuando pulsamos la opción de “Mostrar Log”, lo que hace Droidwall es ejecutar el comando:

dmesg | $GREP DROIDWALL

dmseg saca por la salida estandar (la pantalla) los mensajes del kernel y grep filtra los que contengan la palabra DROIDWALL. Acordémonos ahora de las reglas incluidas en la cadena droidwall-reject:

Chain droidwall-reject (2 references)
pkts bytes target     prot opt in     out     source               destination
0     0 LOG        all    —  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 8 level 4 prefix `[DROIDWALL] ‘
0     0 REJECT     all    —  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable

.

La regla a la que hace referencia el listado es esta:

$IPTABLES -A droidwall-reject -j LOG --log-prefix \"[DROIDWALL] \" --log-uid

Cada vez que se rechace un paquete, netfilter añade una línea de Log a los mensajes del kernel, que contiene la clave [DROIDWALL] para que pueda ser facilmente filtrable. Esta es una de esas líneas:

<4>[  110.878448] [DROIDWALL] IN= OUT=eth0 SRC=192.168.1.35 DST=67.214.210.43 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=10464 DF PROTO=TCP SPT=50203 DPT=443 WINDOW=5840 RES=0x00 SYN URGP=0 UID=10083 GID=10083

Al mostrarnos el log, Droidwall no la enseña entera, sino que hace un resumen de todas las líneas de cada aplicación informándonos de cuántos paquetes se bloquearon y a qué direcciones ip.

ejemplo de log

Lo ideal es que esta información tan preciada la pudiéramos almacenar y conservar en un fichero, pero se necesitaría que Droidwall tuviera un servicio activo todo el tiempo, lo cual no convencía a su creador.

Sorry, but adding such a feature would require DroidWall to keep a service running 100% of the time, and I don’t like this idea.

.

Quien bloquea los paquetes que no cumplen las reglas y genera los mensajes de Log no es Droidwall sino el target LOG de iptables. Además no los va metiendo en un fichero, sino en el kernel ring buffer (buffer de anillo del kernel). Este ring buffer es un archivo especial que se almacena en la memoria interna, en /proc/kmsg concretamente. Siempre tiene el mismo tamaño porque va borrando las líneas más antiguas a medida que aparecen las nuevas.

Por eso ocurre a veces que al rato de consultar el LOG de Droidwall y ver paquetes bloqueados, volvermos a mirar y nos saca el mensaje de que está vacío. El comando dmesg que utiliza Droidwall para mostrar el Log no hace otra cosa sino mostrarnos por pantalla el kernel ring buffer filtrado convenientemente con el grep. Un tiempo después la información ha volado.

¿Hay alguna forma de encaminar la salida de dmesg hacia un fichero? Si que la hay:

dmesg | grep DROIDWALL > /mnt/sdcard/droidwall.log

De esta manera nos vuelca a fichero las lineas de Log que hay en el kernel ring buffer en ese momento, pero no es la solución definitiva que estamos buscando.

Otra posibilidad es tratar de encaminar hacia un fichero el propio ring buffer:

cat /proc/kmsg >> /mnt/sdcard/buffer.log

Con este comando iremos almacenando en tiempo real todas las lineas nuevas que se van añadiendo al kernel ring buffer hasta que apaguemos el teléfono o hagamos un Vol.Down+c. El fichero generado buffer.log puede ser filtrado posteriormente en el PC o bien mostrado nuevamente por pantalla ya filtrado con:

cat < /mnt/sdcard/buffer.log | grep DROIDWALL

Los intentos de aplicarle el grep DROIDWALL directamente mientras se almacena el buffer.log en la sdcard no me han dado resultado.

Como curiosidad, cuando marcamos la opción “Borrar Log” del menú, se ejecuta el comando

dmesg -c > /dev/null

que borra el ring buffer. Es decir, que cuando marcamos esa opción lo que estamos haciendo es borrar no solamente los mensajes de Log relativos a Droidwall, sino el ring buffer completo. Si ahora metemos el comando dmesg no nos devolvería nada por estar el buffer vacío.

12. Algunos problemas que pueden surgir

Sale mensaje de “Log vacío” y hace un rato no lo estaba

Como hemos visto cuando utilizamos la opción de “mostrar Log” estamos filtrando el kernel ring buffer. Este buffer se va sobreescribiendo y después de un tiempo (no mucho) ya no están los logs que antes sí podíamos ver. Por eso el Log no puede ser utilizado para almacenar y consultar posteriormente, sino para ocasiones puntuales.

Si se quiere guardar un histórico sólo se me ocurre encaminar hacia un fichero el ring buffer y filtrarlo posteriormente en el PC como hemos visto en el apartado anterior.

Error “Iptables: No chain/target/match by that name”

Después de instalar Droidwall, al pulsar en el menú el botón que pasa a estado activo y de darle los permisos de superusuario requerido, aparece un mensaje con el texto:

Error applying iptables rules. Exit code:11
Iptables v1.4.10
Iptables: No chain/target/match by that name

Lo que ocurre es que al compilar el kernel de nuestro teléfono han dejado deshabilitada la opción CONFIG_NETFILTER_XT_METCH_OWNER. la cual permite que se incluya en el kernel el módulo “netfilter owner”, necesario para que funcione Droidwall, pues es el que permite que iptables pueda distinguir qué aplicación ha enviado cada paquete en el momento del filtrado.

La única solución es sustituir el kernel por otro, bien actualizando toda la ROM, bien compilando un kernel apropiado y flashearlo en el teléfono. Esta segunda opción fue la que utilicé.

Tráfico no filtrado por Droidwall

Puede ocurrir que al iniciar el sistema se cuele algún tráfico que debería haber sido filtrado, como reporta algún usuario. Al iniciarse el sistema operativo Adroid, por defecto empieza sin reglas en iptables. Da igual que cuando apaguemos el teléfono Droidwall esté en estado activo; las reglas no se conservan. En cuanto el teléfono ha arrancado se produce el evento After_Startup y arrancan todas las aplicaciones que se activen con dicho evento. Puede ocurrir que Droidwall no sea la primera aplicacion en arrancar y hay unos instantes en que otra aplicación puede conectarse a la red, ya que en esos momentos no hay reglas.

Problema

No es un problema de Droidwall en realidad. Se puede solucionar con un scrpit en el init.d, pero en algunos teléfonos (en mio por ejemplo) no funciona. La solución más eficaz para dar soporte al init.d es flashear el ramdisk. Otra manera de implementarlo es mediente el fichero /etc/init_post.sh (que no forma parte del ramdisk) pero así no habría manera de controlar el orden de ejecución de los scripts del init.d.

Acceso a red por el puerto 53 cuando el Log está activo y Droidwall trabaja en modo lista blanca.

Cuando vimos las reglas de iptables en el punto 7, en el ejemplo había dos reglas marcadas de color rojo porque Droidwall sólo las crea cuando está activo el Log. La primera de ellas no es estrictamente necesaria para que funcione el Log. Su propósito es que el Log tenga la posibilidad de traducir direcciones ip cuando estamos en modo lista blanca (todo cerrado excepto las aplicaciones marcadas). Según el autor:

"Allow DNS lookups on white-list for a better logging"

La regla en cuestión es la siguiente:

IPTABLES -A droidwall -p udp --dport 53 -j RETURN

y permite que cualquier aplicación pueda salir por el puerto 53 (en teoría para utilizar los servicios DNS, pero en la práctica es un agujero de seguridad que puede ser utilizado por aplicaciones malintencionadas) cuando el Log está activo.

Por otra parte, esta regla está situada dentro de la cadena droidwall, es decir, antes de que discriminemos el tráfico según sea por wifi o 3G. Si alguien desea cerrar totalmente las salidas por 3G a cualquier aplicación sencillamente no podría.

Cuando un usuario le hizo notar este problema, el autor respondió que la característica del Log no estaba pensada para estar activada permanentemente aunque era consciente que la mayoría de la gente lo utilizaba de esa manera, así que iba a considerar la posibilidad de suprimir esa regla. Pero parece que al final decidió dejarlo como estaba.

En este ejemplo vemos a la aplicación “Fruit Ninja”, que aún estando bloqueada puede acceder al DNS.

Salida por DNS

Sin embargo después intenta conectarse por el puerto 443 y ya es bloqueada. La captura por cierto fue hecha con Network Log, que merece un tutorial aparte.

Desafortunadamente al consultar el código fuente comprobamos que la regla que nos ocupa, la que permite las salidas por el puerto 53, se añade después de las reglas que podríamos incluir los usuarios a través del “custom script” y no al revés.

Codigo problema DNS

Esto elimina la posibilidad de borrarla nosotros desde el “custom script”.

La posibilidad que nos queda a los que utilizamos el modo lista blanca es hacerle caso al autor teniendo el Log normalmente inactivo y sólo activarlo para casos concretos, lo cual tiene sentido dada la rapidez con la que se pierden los logs al irse llenando el kernel ring buffer.

13. Palabras finales

Esta aplicación es el resultado de las mejoras introducidas por el autor desde la primera versión en Julio de 2009 hasta la última en Diciembre de 2011, tratando de atender las sugerencias y problemas de los usuarios. Por el momento parece que está discontinuada, ya que no he visto actividad del autor en los foros desde Febrero de 2012. Si es así espero que alguien tome el testigo y se puedan seguir añadiendo mejoras a este estupendo cortafuegos.

Este tutorial no está terminado. Espero ir mejorándolo incorporando las posibles aportaciones que vayan llegando.

14. Enlaces:

Descargar Droidwall 1.5.7: http://droidwall.googlecode.com/files/droidwall-v1_5_7.apk

Código fuente de la última versión de Droidwall: http://code.google.com/p/droidwall/source/browse/tags/v1.5.7?spec=svn250&r=250#v1.5.7

Wiki donde los usuarios pueden exponer sus problemas (ya no está mantenida por el autor): http://code.google.com/p/droidwall/issues/list

Publicado en Aplicaciones, B5510, Privacidad, root, Seguridad | Etiquetado , , , , , , , , , , , , , , , , , , , | 17 comentarios

Objetivo 3 (continuación) – Droidwall: Error “No chain/target/match by that name” – Compilar el kernel del B5510

Cuando me enteré de las implicaciones que tenía este error se me heló la sangre en las venas. La única manera de que funcionase Droidwall en el Samsung Galaxy Y Pro GT-B5510 era cambiando el kernel. Sabía de otra persona que lo había intentado, y por desgracia no le había salido bien (ver comentario en el blog de Chucho).

En esta entrada voy a relatar el procedimiento que me dió resultado, que es la adaptación de otros que encontré en los foros de xda-developers (ver créditos al final). Tuve que modificar algunas partes y suprimir otras, ya que el tipo de móvil no era el mismo, y también he añadido algunas aportaciones propias. Lo explico de la mejor manera que sé, puesto que estoy empezando con android y mis conocimientos de linux son bastante rudimentarios.

PROCEDIMIENTO PARA COMPILAR Y FLASHEAR EL KERNEL DEL SAMSUNG GALAXY Y

Como vimos en la entrada anterior, el kernel del Samsung Galaxy Y no incluye el módulo netfilter owner (NETFILTER_XT_MATCH_OWNER). Este módulo es utilizado por iptables para poder filtrar los paquetes según el UID de cada aplicación y es requisito fundamental para que funcione el cortafuegos Droidwall. Como netfilter forma parte del kernel no queda más remedio que cambiar este último por otro que sí tenga el dichoso módulo.

Nota: Lo que viene a continuación me ha dado resultado a mí, aunque no puedo garantizarle a nadie al 100% que le vaya a funcionar. Lo que hagas en tu móvil será tu responsabilidad.

Sí es probable que funcione en los modelos siguientes, que son compatibles entre sí según esta información:

GT-S5360, GT-B5510, GT-S5360B, GT-S5360L, GT-S5360T, GT-S5363, GT-S5369, GT-B5510L y GT-S5701
Nota: en los modelos subrayados tengo seguridad 100% que funciona. Si me entero de alguno más actualizaré esta lista.

.

Advertencias previas

– un requisito previo es tener el móvil rooteado. No es difícil y se puede hacer de varias maneras.  Aquí está la forma que utilicé yo.

– debemos tratar de entender todo lo que vamos haciendo. Este procedimiento lo hice con un GT-B5510. Si tienes otro Samsung Galaxy Y puede que debas cambiar algunas cosas según se va explicando. Por eso no debemos limitarnos sólo a copiar los comandos sin entender lo que estamos haciendo. Ha sido probado también en los modelos GT-B5510L, GT-S5360 y GT-S5360L.

– el procedimiento implica utilizar el ClockWorkMod Recovery, correr ficheros zip, compilar el kernel desde una distribución linux, flashear el kernel…Puede asustar un poco, pero todo está explicado.

– el momento más delicado es el flasheo del kernel. Si se siguen las instrucciones correctamente el nuevo kernel estará correcto y todo irá bien. Por si el móvil no arranca al reiniciar después de flashearlo, tendremos preparada una restauración del kernel original arrancando desde modo recovery (aunque también se podría restaurar en modo download con Odin). En cualquier caso lo que hagas será bajo tu responsabilidad.

Partes en que se divide este método

Lo que vamos a hacer se puede estructurar en estas cinco partes:

- encontrar el código fuente del kernel para nuestro modelo de móvil.
- hacer los cambios necesarios para incluir los módulos que necesita iptables
- hacer un backup del kernel original del móvil.
- compilar el nuevo kernel.
- flashear el kernel.
Si tu móvil es un GT-B5510, GT-B5510L o GT-S5360L puedes saltarte toda la parte de compilación. Al final he dejado enlaces a kernels ya compilados para estos modelos que ya han sido probados. Compilar el kernel uno mismo es más trabajoso pero también más divertido y aprendes por si necesitas volver a compilarlo en el futuro. En cualquier caso recomiendo que leas el tutorial en su totalidad antes de decidirte.

.

Paso 1: disponer de un entorno con linux para empezar

La compilación del kernel debe hacerse desde linux. Si has leido hasta aquí y no tienes experiencia con linux es el momento de lanzarte a probarlo. Eso sí, te llevará un poco más de tiempo que a alguien que se salte este paso. Hay un muy buen tutorial que indica:

– donde conseguir el sistema operativo, en este caso Ubuntu.
– como instalarlo: puede ser directamente en el disco duro (instalación nativa) o en una máquina virtual utilizando Virtual Box. En ambos casos te va guiando paso por paso.
– una vez arrancado explica como meter los comandos en la consola y da las indicaciones para dejarlo a punto para el paso 2.

El tutorial es la primera parte del proyecto Doha, orientado precisamente a que los no expertos aprendamos a construirnos una ROM personalizada. No vamos a llegar tan lejos, así que sólo hay que seguir el tutorial de esta primera parte.

Paso 2: Lo que se va a necesitar

2.1 Un PC con linux de 32 bits: para compilar después, hay que tener instalado gcc:

sudo apt-get install build-essential
sudo apt-get install linux-headers-$(uname -r)

2.2 El código fuente del kernel que tiene nuestro móvil. Para los móviles de Samsung está disponible en esta dirección: http://opensource.samsung.com Para hacer la búsqueda puse B5510 y hay disponibles los siguientes:

Samsung Open Source

Estos ficheros contienen distintas versiones del código fuente del sistema operativo, llamado PDA.

Son todos para el B5510 excepto uno que es para el B5510L (la versión para latinoamética). Para Europa, que es lo que a mí me interesa, hay dos versiones, ambas para la región XX (Austria, Belgium, France, Germany, Hungary, Italy, Spain, United Kingdom)

B5510XXLA1 (L=año 2012, A= mes Enero, 1= Revisión 1)
B5510XXKI6 (K= año 2011, I= mes Septiembre; 6= Revisión 6)
.

Me quedo con la primera por ser la más reciente, y descargo el fichero GT-B5510_GB_Opensource_Update1.zip, que contiene (entre otras muchas cosas) el código fuente del kernel.

Por supuesto que para cada modelo habrá que hacer la búsqueda y seleccionar el fichero que corresponda. Por ejemplo para el GT-S5360 el que corresponde es el GT-S5360_GB_Opensource_Update2.zip, para el GT-S5360L es el GT-S5360L_Opensource.zip, y para un modelo B5510L el fichero a descargar sería el GT-B5510L_GB_Opensource.zip

Para ver qué versión hay instalada en mi móvil marco *#1234#, obteniendo como resultado PDA: B5510XXKK3, es decir, de noviembre de 2011

y le voy a compilar la B5510XXLA1 , que es un poco más reciente, de Enero de 2012.

2.3 Un cross compiler (compilador cruzado) para ARM llamado Sourcery G++ Lite 2009q3-68 toolchain for ARM EABI (descargar aquí) para compilar el código fuente del kernel a la arquitectura ARM que utilizan los móviles. Hay que cubrir un formulario para que te envíen el enlace para la descarga por email.

nota: he visto que han sacado otras versiones más recientes, aunque no sé si estas también valen, ya que he leido en el foro de xda el siguiente comentario, que me hace pensar que es mejor quedarse con la versión de 2009:

“make sure using the same compiler version…using different version make prebuild kernel module inside initramfs not working.”

Por tanto,  por si el enlace que envían por correo es de una nueva versión, éste es el enlace directo a la versión de 2009, que es la que he probado yo y funciona.

De todas formas cuando lleguemos al punto 4.2 veremos que hay un fichero dentro del código fuente del kernel que nos hemos bajado en 2.1, en donde se indica qué versión del compilador se debe utilizar, por lo que luego confirmaremos que tengamos la versión de compilador correcta.

2.4 El kernel_backup.zip, (descargar aquí) para hacer una copia del kernel de nuestro móvil, cortesía de Harkunwar (me sorprendió la juventud de este muchacho de nacionalidad india).

2.5 El split_bootimg.pl (descargar aquí, boton derecho>guardar enlace como), un script en pearl de William Enk para dividir el boot.img en dos partes. Después de bajarlo le quitamos la extensión .txt y le dejamos la .pl

2.6 El mkbootimg con soporte md5 : (descargar aquí) para construir el nuevo boot.img, gracias a harish2704

2.7 kernel_actualizar.zip: (descargar aquí) para flashear el kernel del móvil

2.8 kernel_restaurar.zip: (descargar aquí) para restaurar el kernel del móvil por si hay algún problema al flashear.

Paso 3: Posicionarse y preparar el código fuente del kernel

3.1 Desde linux creamos en /home/<tu_usuario>/ una carpeta llamada “sgy”. El resultado será la carpeta /home/<tu_usuario>/sgy, en la que vamos a colocar los cinco ficheros que nos hemos bajado en el paso anterior.

nota:  es lo mismo escribir “/home/<tu_usuario>/sgy” que “~/sgy”. Es decir, que cada vez que aparezca “~/sgy” significa que hay que escribir toda la ruta hasta la carpeta “sgy”, que lógicamente varía en cada PC.
.

3.2 Descomprimimos el fichero que contiene el código del kernel (en mi caso GT-B5510_GB_Opensource_Update1.zip) y nos quedamos con el que tiene extensión .tar.gz (en mi caso el GT-B5510_Kernel.tar.gz), dejándolo en la carpeta ~/sgy.

3.3 Abrimos un terminal y nos posicionamos en la carpeta de trabajo

cd ~/sgy

3.4 Extraemos el compilador Sourcery G++ para ARM.

tar -xvf arm-2009q3-68-arm-none-eabi-i686-pc-linux-gnu.tar.bz2

3.5 Creamos la carpeta “kernel” y extraemos el código del kernel en ella descomprimiendo el fichero con la extensión .tar.gz del punto 3.2

mkdir kernel
cd kernel
tar -xvf ../sgy/GT-B5510_Kernel.tar.gz --> ojo, cada cual que ponga el nombre de su fichero

Paso 4: Compilación del kernel

4.1 Dentro de ~/sgy/kernel/ nos aparecen las carpetas “common” y “modules” y un fichero de texto que en este caso se llama GT-B5510_Kernel.txt (lo necesitaremos más tarde), aunque  puede tener otro nombre. Entramos en “common” y buscamos el fichero “makefile”, que describe las relaciones entre los ficheros de nuestro programa, y las órdenes necesarias para actualizar cada fichero. Lo abrimos con un editor de texto y buscamos la línea que contenga este texto:
“/opt/toolchains/arm-eabi-4.4.3/bin/arm-eabi-“
(en mi caso ha coincidido exáctamente, pero es posible que en otros casos la cadena sea similar aunque no idéntica. Si no la encuentras, prueba a buscar simplemente “toolchains”). Lo que estamos buscando es el comando CROSS COMPILE que indica dónde está localizado el compilador arm.

Para el caso del B5510 encontramos la línea:

CROSS_COMPILE ?=/opt/toolchains/arm-eabi-4.4.3/bin/arm-eabi-

que debemos reemplazar por la siguiente:

CROSS_COMPILE ?=/home/<tu_usuario>/sgy/arm-2009q3/bin/arm-none-eabi-

Para el caso del B5510L encontramos las líneas:

#CROSS_COMPILE ?=/opt/toolchains/arm-eabi-4.4.3/bin/arm-eabi-
CROSS_COMPILE ?= /opt/toolchains/arm-2009q3/bin/arm-none-linux-gnueabi-

la primera no hay que tocarla, ya que al comenzar por el símbolo “#” no es tenida en cuenta. La segunda hay que sustituirla por esta otra:

CROSS_COMPILE ?=/home/<tu_usuario>/sgy/arm-2009q3/bin/arm-none-eabi-

y para el caso del S5360L encontramos la línea:

CROSS_COMPILE    ?=/opt/toolchains/arm-eabi-4.4.3/bin/arm-eabi-

que hay que sustituir como en los otros casos por:

CROSS_COMPILE ?=/home/<tu_usuario>/sgy/arm-2009q3/bin/arm-none-eabi-

(hay que acordarse de sustituir <tu_usuario> por el nombre del directorio de la cual hemos colgado la carpeta “sgy”, que suele coincidir con nuestro nombre de usuario en linux. Es decir, que lo importante es que esté correcta la ruta de la carpeta “sgy”)

En mi caso la línea queda de la siguiente manera:

CROSS_COMPILE ?=/home/ubuntu/sgy/arm-2009q3/bin/arm-none-eabi-

ya que la ruta de la carpeta “sgy” en mi PC es precisamente “/home/ubuntu/”

4.2 En el terminal vamos a la carpeta “common” y cargamos el defconfig. El kernel ARM que compilemos va a necesitar un fichero de configuración que varía según nuestro modelo de móvil, llamado “defconfig”. Para saber qué defconfig nos corresponde hay que buscar en el fichero de texto que hay en “~/sgy/kernel. Puede tener distintos nombres. En el caso del B5510 este fichero se llama GT-B5510_Kernel.txt, en el caso del B5510L se llama Readme_kernel.txt, en el caso del S5360L se llama GT-S5360L_Kernel.txt, etc. En él hay unas instrucciones para compilar el kernel donde nos dan dos datos importantes: el compilador y el defconfig que nos corresponden, los cuales he marcado en rojo:

Instrucciones para compilar el kernel

También nos informa de la versión de kernel que vamos a compilar, en mi caso la 2.6.35.7

En la carpeta “~/sgy/kernel/common/arch/arm/configs/” es donde están todos los defconfig. Debemos asegurarnos que el defconfig que utilicemos se encuentre en esa carpeta.

Los comandos serán entonces:

cd ~/sgy/kernel/common
make bcm21553_luisa_03_defconfig --> ojo, cada cual que ponga el nombre de su fichero

después de terminar de ejecutar el make, aparece el mensaje “configuration written to .config”

nota: cada modelo de móvil tiene su defconfig. Para el GT-S5360/GT-S5360L es el bcm21553_totoro_05_defconfig. Para el GT-B5510L es el mismo que para el GT-B5510.
.

4.3 Después de ejecutar el comando make (cuyo propósito es determinar qué piezas de un programa necesitan ser recompiladas, y lanzar las órdenes para recompilarlas) hemos de ir a ~/sgy/kernel/common/.config buscar una a una estas tres líneas:

# CONFIG_IP_NF_TARGET_REJECT is not set
# CONFIG_NETFILTER_XT_MATCH_OWNER is not set
# CONFIG_IP_NF_TARGET_LOG is not set

Cada una de ellas tenemos que descomentarlas quitándoles el “# ” del comienzo de línea y también sustituir el ” is not set” del final por “=y”. El resultado final tiene que ser:

CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_NETFILTER_XT_MATCH_OWNER=y
CONFIG_IP_NF_TARGET_LOG=y

nota: si no puedes modificar el .config por falta de permisos puedes dárselos situándote en su carpeta y haciendo “chmod 777 .config”. Otra opción es hacer los cambios directamente en el defconfig (en mi caso el bcm21533_luisa_03_deconfig) o incluso con un make menuconfig. Lo importante es que al final en el “.config” estén marcados como “=y” los tres módulos que nos interesan.
OJO! Si decides hacer los cambios en el defconfig, lógicamente tendrás que hacerlos antes de ejecutar el comando “make” del punto 4.2
.

Con estos cambios le estamos diciendo que al hacer la compilación incluya esos tres módulos. El primero permite gestionar paquetes ICMP, el segundo permite filtrar por UID y el tercero vale para generar un Log, cosa muy recomendable si queremos enterarnos de qué está pasando en nuestro móvil.

Log

En esta imagen vemos al log en acción, avisando que una aplicación se ha intentado conectar a una ip de China.

.

4.4 En este momento ya está todo preparado para compilar el kernel que nos hemos bajado, que ya incluirá los módulos que necesita Droidwall. Siguiendo desde “~/sgy/kernel/common, si nuestro PC tiene sólo un núcleo hacemos:

make

en caso de tener más de un nucleo ahorramos tiempo haciendo:

make -j3

4.5 Cuando termine de compilar, si no ha salido ningún eror, el resultado estará en el fichero ~/sgy/kernel/common/arch/arm/boot/zImage, el cual vamos a copiar en nuestra carpeta sgy

cp arch/arm/boot/zImage ~/sgy

Ya tenemos el kernel de linux compilado para la arquitectura ARM.  Pero resulta que el kernel se almacena en una partición junto con el ramdisk, así que tenemos que conseguir el ramdisk de nuestro móvil para juntarlo con el kernel (fichero zImage) recien compilado.

Paso 5: Hacer un backup del kernel original del móvil

El ramdisk es básicamente un sistema de ficheros que contiene el núcleo de ficheros necesarios para inicializar el sistema, y es utilizado por el kernel al comienzo del arranque del móvil. Para conseguir una copia de nuestro ramdisk tenemos que hacer un backup del kernel, en forma de fichero boot.img.

El boot.img es un fichero imagen que contiene ambos: kernel y ramdisk

5.1 Ahora necesitaremos el fichero kernel_backup.zip del punto 2.4. Debemos pasarlo a la tarjeta sd desde nuestro PC, dejándolo en el raiz (/sdcard). Si no sabes cómo hacerlo, lo explico aquí.

5.2 Ejecutaremos el fichero zip en el móvil. Debemos hacerlo desde el recovery del ClockWorkMod. Aquí explico como instalar el ClockWorkMod. Una vez en el menú del recovery hay que:

– seleccionar la opción “install zip from sdcard”
– en el menu que se abre seleccionar “choose zip from sdcard
– ir hasta el archivo .zip que pusimos en la tarjeta sd y seleccionarlo
– confirmar la instalación seleccionando “Yes — Install kernel_backup.zip
– al terminar la instalación salir conreboot system now

Ahora ya tenemos en el raiz de la tarjeta sd un fichero llamado kernel_boot.img que debemos renombrar como boot.img (se puede hacer desde el PC conectando el móvil por USB). La razón de renombrarlo es que este boot.img original quedará en /sdcard con ese nombre por si en algún momento es necesario restaurarlo.

5.3 Pasamos a través del cable USB el fichero boot.img a la carpeta ~/sgy

Paso 6: Construcción del nuevo boot.img

6.1 Con el split_bootimg.pl del punto 2.5 vamos a separar en dos ficheros nuestro boot.img

cd ~/sgy/
perl split_bootimg.pl boot.img

Esto es lo que sale en el terminal

split

Hemos dividido el boot.img en dos: el “boot.img-kernel” y el “boot.img-ramdisk.gz”.

6.2 Ahora movemos a otro sitio el boot.img y el boot.img-kernel, ya que no los vamos a necesitar y no queremos que anden estorbando en ~/sgy.

6.3 Necesitamos el md5sum del fichero zImage, que contiene el nuevo kernel que habíamos compilado, por lo que escribimos (acuérdate que seguimos dentro de “~/sgy”):

md5sum zImage

Un md5sum es un hash md5 del archivo, que proporciona un número prácticamente único para cada archivo. La salida será algo similar a esto:

1fd319aa60abc2abae2e5932bcb9fc77  zImage

La cadena alfanumérica hay que copiarla en algún sitio y guardarla, ya que se necesitará dentro de poco.

6.4 Toca ahora reempaquetar nuestro nuevo boot.img, que ya quedará listo para flashearlo en el móvil. Utilizaremos el mkbootimg del punto 2.6. Este programa utiliza como parámetros los ficheros que hemos ido preparando anteriormente:

– el zImage, donde está el nuevo kernel compilado
– el boot.img-ramdisk.gz, con el ramdisk extraido de nuestro móvil

Los comandos son los siguientes:

chmod +x mkbootimg --> nos aseguramos que tenemos permiso de ejecución
./mkbootimg --kernel zImage --ramdisk boot.img-ramdisk.gz --base 0x81600000 --kernelMD5 <your md5sum result> -o boot.img

Observaciones:

– El parámetro “base” hacer referencia a la dirección base de memoria, y se corresponde con el parámetro CONFIG_SDRAM_BASE_ADDR del fichero defconfig que habíamos utilizado en la compilación, que en mi caso era bcm21553_luisa_03_defconfig, y está situado en la ruta:

~/sgy/kernel/common/arch/arm/configs/bcm21553_luisa_03_defconfig

se da la circunstancia que la dirección base es la misma para el B5510/B5510L y para el S5360/S5360L, pero para cualquier otro modelo de móvil hay que consultarlo en el defconfig.

– obviamente hay que sustituir <your md5sum result> por la cadena alfanumerica que calculamos con el md5sum.

Una vez ejecutados estos comandos ya tenemos el nuevo boot.img con nuestros apreciados módulos para iptables, preparado para ser flasheado. Hay que tener cuidado y no confundirlo con el boot.img que habíamos extraido del móvil, por eso nos lo hemos llevado antes a otro sitio.

Quisiera hacer un inciso para contar la situación en la que me encontraba en este punto. Había seguido las indicaciones de los foros xda, que eran para el S5360 y había ido cambiando lo necesario para adaptarlo al B5510, pero no tenía la seguridad de que no se me hubiese pasado por algo algún detalle.

Por ejemplo, no sabía si la dirección base que valía para el S5360 era válida también para el B5510 y tuve que bucear bastante hasta encontrar cómo comprobarla. Por tanto, cuando por fin obtuve el nuevo boot.img tenía muchas dudas y no me atrevía a dar el paso de flashearlo. Estuve más de una semana haciendo comprobaciones hasta estar lo suficientemente convencido como para arriesgarme a efectuar el flasheo. Otro día las comento.

.

Paso 7: Flashear el kernel

No me decidí a flashear hasta que tuve a punto un procedimiento para echar marcha atrás en caso de fallo. Haciendo algunas modificaciones al programa del punto 2.4 pude crear los dos ficheros de los puntos 2.6 y 2.7, para ser utilizados con el ClockWorkMod Recovery

kernel_actualizar.zip –> flashea el fichero compilado por nosotros, renombrado como “boot_com.img” y que debe estar situado en el raiz de la sdcard.

kernel_restaurar.zip –> flashea el fichero “boot.img” original que tenía previamente el móvil, y que debe estar situado en el raiz de la sdcard.

Ha llegado el momento de sustituir el kernel original por el que acabamos de compilar. Lo haremos desde el modo recovery con el ClockWorkMod Recovery.

7.1 En la sdcard tengo ya el boot.img original por si acaso hay que restaurar. No está de más comprobar que lo tengamos realmente.
7.2 Renombramos el boot.img recién compilado como boot_com.img y lo metemos en /sdcard a través del cable USB.
7.3 Metemos también de la misma forma en /sdcard los ficheros Kernel_actualizar.zip y kernel_restaurar.zip

7.4 Arrancamos en modo recovery (Vol+, Home y Power) y ejecutamos el ClockWorkMod.
Desde su menú instalamos el kernel_actualizar.zip (tal como lo habíamos hecho en el punto 5.2), que se encarga de buscar en el raiz de la sdcard el fichero boot_com.img y flashearlo.

7.5 Si falla algo tenemos el kernel_restaurar.zip que es casi identico y flashea el boot.img original. Tengo que advertir que no he probado la restauración del kernel desde este fichero, ya que todavía no he tenido esa necesidad, aunque el programa es idéntico al anterior cambiando sólamente el nombre del fichero que flashea.

.
Posibles problemas

– Si después de compilar y flashear el boot.img te sigue dando el mismo error “No chain/target/match by that name”, quiere decir que el módulo de netfilter sigue sin estar en el kernel. Recomiendo repetir nuevamente todo el proceso fijándose en que se marcan correctamente los tres módulos con “=y” y se descomentan sus respectivas líneas ,  y sobretodo teniendo especial cuidado en que no salgan errores durante la compilación.

– Si hay problemas para arrancar en modo normal después del flasheo, lo primero es recuperar el boot.img anterior siguiendo las instrucciones del punto 7.5. En caso de no poder acceder ni siquiera al modo recovery (improbable ya que no se toca el ramdisk) seguiremos este procedimiento para recuperar el móvil desde el modo download flasheando el boot.img desde el PC con Odin.

Kernels ya compilados para que funcione Droidwall

A continuación para quien tenga un móvil compatible con el B5510 y quiera ahorrarse la compilación, adjunto el boot.img que he compilado y que me funciona a la perfección, ya listo para flashear, y también algunos para otros modelos.

boot.img (4,32 Mb) –> para el GT-B5510

boot.img (4,5 Mb) –> para el GT-B5510L

boot.img (4,3 Mb) –> para el GT-S5360L (éste ha sido probado también para el S5360  con éxito)

Tengo que decir no obstante que creo que lo mejor es compilarnos nuestro propio boot.img y dejar esta opción solamente como último recurso. Hay que tener en cuenta que al utilizar estos boot.img estamos sustituyendo no sólo el kernel, sino también nuestro ramdisk.

Nota: Antes de flashear cualquiera de estos ficheros, hay que renombrarlos previamente como boot_com.img.

Epílogo

Al reiniciar justo después de flashear el kernel no se nota absolutamente nada. Realmente está todo igual, excepto que Droidwall ahora funciona. Una gozada. !Por fin puedo controlar qué aplicaciones salen a la red y por donde lo hacen!

Me gustaría que si has seguido este tutorial pusieras un comentario contando qué tal te ha ido, si alguna parte no está clara, qué cambios tuviste que hacer si es que tienes otro modelo de movil, etc. Con tus aportes trataré de ir mejorando el tutorial.

.

Créditos y agradecimientos:

Tutorial de irfanbagus en http://forum.xda-developers.com/showthread.php?t=1594875 (comentario nº4)
Tutorial de mikstev en http://forum.xda-developers.com/showthread.php?t=1626406

Agradecimiento a Noob Saibot por compilar el boot.img según este procedimiento y probarlo para el GT-B5510L.

Agradecimiento a Soria por compilar el boot.img según este procedimiento y probarlo para el GT-S5360L.

Agradecimiento a tallerwillian, que probó el boot.img del S5360L en su S5360 con éxito.

Enlaces

Tutorial “Droidwall a fondo”: http://wp.me/p2v4vY-9K

Página web de Droidwall: http://code.google.com/p/droidwall/

Publicado en Aplicaciones, B5510, Privacidad, ROM, root, Seguridad | Etiquetado , , , , , , , , , , , , , , , , , , , , , , | 124 comentarios

Objetivo 3 – Controlar la salida a internet de las aplicaciones

Hasta ahora me había preocupado de varias de las cosas que creo necesarias al comprar móvil:

conseguir acceso root: fundamental
hacer un backup de la ROM: muy importante por si se da algún paso en falso
personalizar los procesos que se ejecutan al inicio: muy recomendable para ahorrar batería.

Una vez resueltas, ha llegado el momento de intentar hacerse con el control del acceso de las aplicaciones a la red.

Muchas apps salen a internet sin permiso, para transmitir nuestra localización GPS, nuestros contactos, número de teléfono, device id y hasta el número de serie de nuestra tarjeta SIM. Esa información en el mejor de los casos es vendida a otras empresas. Una táctica empleada es diseñar una aplicación gratuita con la calidad suficiente para que el usuario desee conservarla instalada en el móvil, pero que actua como troyano enviando datos al exterior.

Un caso sangrante que enseguida desapareció de los medios de comunicación. En algunos países algunas operadoras incluyeron preinstalada en su ROM una aplicación de Carrier IQ, un software que espiaba todas las actividades del usuario (teclas pulsadas, navegación, mensajes SMS, geolocalización…)  y las transmitía a dicha empresa sin encriptar.

Pregunta: ¿Por qué el sistema operativo Android no trae entre las aplicaciones preinstaladas un cortafuegos?
Respuesta: Porque lo que interesa (a Google, a la operadora, y a cualquiera de los que sacan beneficio de la ignorancia del usuario) es que no tengamos control sobre las aplicaciones que instalamos en nuestro móvil, que no podamos escoger a quién le damos permiso para abrir un shocket y conectarse a internet.

Es FUNDAMENTAL hacerse con el control de los accesos a la red, y si puede ser nada más comprar el móvil, mejor.

Afortunadamente el desarrollador Rodrigo Zechin Rosauro debió pensar lo mismo allá en Brasil, y compartió desinteresadamente la que para mí es la mejor aplicación que he visto hasta ahora. Útil, efectiva y sencilla. Droidwall.

Logo Droidwall

Descripción de la aplicación

Droidwall se puede descargar desde su propia web aquí (recuerdo que requiere root)

Screenshot de Droiwall

Es un front-end (la parte del software que interactúa con el usuario) para el iptables. Android utiliza el kernel de linux, el cual controla el filtrado de paquetes. Iptables permite definir un sistema de reglas para aceptar o rechazar los paquetes. Droidwall nos da acceso a iptables por medio de un entorno gráfico sencillo y comprensible.

La cosa es sencilla. Hay una lista de todas las aplicaciones/paquetes instalados tanto del sistema como por el usuario. Cada una de ellas con su identificativo de usuario (uid), que es un número que se asigna a cada paquete instalado. Gracias a este uid, el iptables puede distinguir en sus reglas entre las distintas aplicaciones para definir a quien deja salir y a quien no. A la izquierda de cada aplicación hay dos casillas para marcar si queremos que tengan acceso al exterior, y en ese caso si le dejamos por 3G, wifi o ambas.

Es así de sencillo. En este tutorial se explica su funcionamiento.

Las malas noticias (para algunos)

Al instalar el Droidwall la configuración por defecto es en estado desactivado, es decir, la opción “Firewall enabled” está apagada. Al pulsarla para activar el cortafuegos me sale el siguiente error:

Error applying iptables rules. Exit code:11
Iptables v1.4.10
Iptables: No chain/target/match by that name

¿Qué significa esto? Algo bastante chungo, tal como nos explica su creador Rodrigo en las FAQ de su wiki:

This error message unfortunately means that your kernel does not support netfilter owner match module, so DroidWall will not work.
The only possible solution is to flash a customized ROM (or kernel) with full netfilter support.
ROM developers, please ensure that the following configuration option is enabled in the kernel (either built-in or as a module): CONFIG_NETFILTER_XT_MATCH_OWNER

La explicación es la siguiente:

Android utiliza un kernel de linux. El iptables, que Droidwall necesita para establecer las reglas de filtrado de paquetes, utiliza a su vez los módulos de netfilter. Estos módulos son unos cuantos. Uno de ellos (CONFIG_NETFILTER_XT_MATCH_OWNER) es estríctamente necesario para que podamos filtrar los paquetes según sea su uid. Pero cuando Google compiló el kernel que iba a utilizar en el Gingerbread 3.6, no metió este módulo. El resultado es que el kernel de mi B5510, cuya versión es la 2.6.35.7, ha sido compilado sin ese módulo y por tanto no hay forma de que Droidwall funcione. Mi gozo en un pozo.

Como dice Rodrigo, la única solución posible es flashear la ROM o el Kernel. Eso son palabras mayores para los que estamos empezando en esto. Pero hay un momento en la vida de todo aprendiz de android en que hay que decidir qué queremos ser de mayores. ¿Quiero mantener a raya a las apps? ¿Me arriesgo a brickear el móvil para conseguirlo?

Brick

Si te suena esta historia y estás en la misma situación, te interesará saber cómo lo hice. El que haya tocado alguna vez en linux lo tiene más fácil. El que no lo haya hecho nunca no pasa nada. Llevará un poco más de tiempo, porque será necesario instalar ubuntu para compilar el kernel. Para el que se atreva, en la siguiente entrada lo trataré de explicar en detalle.

Publicado en B5510, Privacidad, root, Seguridad | Etiquetado , , , , , , , , | 1 Comentario

Objetivo 2 – Optimizar los procesos que se ejecutan al inicio

Una vez conseguido el primer objetivo consistente en hacer un backup de la ROM, voy a tratar de ver qué procesos se autoejecutan al iniciar el sistema y si es posible prescindir de alguno de ellos.

En Ajustes>Aplicaciones>Administrar aplicaciones>Servicios en ejecución se pueden ver las aplicaciones y sus procesos y servicios que están en ejecución o en la memoria caché.

ProcesosEnEjecucion

proceso: es una tarea que se ejecuta generalmente en segundo plano, que no tiene interfaz y que puede ser consultado o usado por cualquier programa o simplemente realiza una acción para que el sistema funcione con normalidad.

servicio: es una aplicación que corre de forma automática, sin interacción con el usuario. Desarrollan tareas importantes para el resto de las aplicaciones o para el sistema.

Al principio de este artículo explican la relación entre aplicaciones, procesos y servicios.

La idea que tengo es dejar que se autoejecuten al inicio sólo los procesos indispensables para que funcione el sistema, pero desde la configuración de android Gingerbread no veo manera de controlar esto.

La aplicación que más me ha gustado por ahora para este fín se llama Autostarts, de Michael Elsdörfer. Requiere acceso root para hacer cambios, de lo contrario es de sólo lectura.

Autostarts

Esta app permite ver, para cada aplicación instalada en nuestro móvil, los distintos eventos que hacen que ésta se active. Además da la opción de desactivar manualmente en cada evento. Es decir, permite configurar el sistema para que puedas decidir que apps permiten arrancar cuando se produce un determinado evento. Por otro lado también se pueden ver qué aplicaciones se activan con un evento determinado. Uno de los eventos es el inicio del sistema pero hay muchos más como por ejemplo cambio de conectividad, recibir llamadas o mensajes, pulsación de algunos botones.

Autostarts Cargando

En este caso el evento que interesa es “After Startup”. De todos los procesos que aparecen hay algunos que se pueden desactivar si no se van a utilizar.

Hay otros que no se deben tocar porque se corre el riesgo de que no funcione bien el sistema operativo:


Marco de servicios Google->com.google.android.gsf.checkin.CheckInServicesReceiver
Marco de servicios Google->com.google.android.gsf.checkin.EventServicesReceiver
Marco de servicios Google->com.google.android.gsf.update.SystemUpdateServicesReceiver
Marco de servicios Google->com.google.android.gsf.gtalkservice.ServiceAutoStarter
Configuración para partners de Google->com.google.android.partnersetup.GooglePartnerSetup
Configuración para partners de Google->com.google.android.partnersetup.RlzPingBroadcastReceiver
CSC->com.samsung.sec.android.application.csc.CscReceiver
Encrypt App->com.sec.android.app.encrypt.EncryptionReceiver
Service Mode->com.sec.android.app.servicemodeapp.FTMDialogBroadcastReceiver
PCW Device->com.sec.pcw.device.receiver.PCWReceiver

Un caso particular es la aplicación preinstalada Market. Cuando se intenta evitar que se active con Autostarts devuelve un mensaje de error como si no tuviésemos acceso root, lo cual evita que la podamos desactivar de esa manera.

Logo MarketError Market

Me ha parecido muy interesante esta página donde se analizan los procesos de las aplicaciones preinstaladas en un móvil Samsung. Se informa en qué consiste cada uno de ellos y si es seguro matarlo o no, con un código de colores (verde, amarillo y rojo). Puede ser de mucha ayuda para decidir si dejamos que un proceso se ejecute con el evento “After Startup”.

El siguiente vídeo tutorial de http://www.lagavetablog.com explica el funcionamiento de esta excelente aplicación:

Este otro tutorial también está bien

Esta aplicación es de pago, pero es posible conseguir el fichero apk buscando un poco.

Publicado en Aplicaciones, B5510, root, Seguridad | Etiquetado , , , , , , , | 3 comentarios

Como descargarse una aplicación para Android para instalarla posteriormente desde la tarjeta SD

Quizá la forma más sencilla para instalar aplicaciones en Android sea a través del Google Play (antes Market). Sin embargo tiene varios inconvenientes:

– es obligatorio tener una cuenta en google.
– quedan registradas todas las búsquedas y descargas efectuadas desde tu teléfono.
– algunas aplicaciones son de pago, lo cual es un inconveniente para las personas que no desean efectuar pagos por la red.

Para justificar las descargas a través de Google Play se utiliza el argumento de que así se evita instalar aplicaciones que contienen malware.

…si tu usas solo la plataforma oficial de aplicaciones Google Play, entonces no tienes nada de que preocuparte.

Eso es cierto sólo en parte (hay métodos para burlar el anti-malware de Google Play), y tomando las precauciones adecuadas los usuarios podemos reducir los riesgos derivados de instalar aplicaciones desconocidas.

La búsqueda

Las personas que no desean acatar el procedimiento anterior han de buscar por la red los ficheros de extensión apk que contienen cada aplicación. La búsqueda no es fácil y en ocasiones no se encuentra la aplicación buscada.

Hay personas que suben a la red una copia de sus aplicaciones para compartirlas con los demás y las dejan en algún servicio de alojamiento de archivos, como Mediafire, 4shared, etc. Utilizando un buscador de archivos de descarga directa es posible llegar a encontrar la aplicación buscada aunque la búsqueda puede ser laboriosa, ya que en muchas ocasiones el fichero ha sido retirado y el enlace ya no es válido. A pesar de eso se encuentran bastantes aplicaciones de este modo.

Buscadores de archivos de descarga directa en los que se puede probar suerte:

http://filespart.com/
http://www.filecrop.com/
http://pastebin.com

Hay ocasiones en que las aplicaciones gratuitas se encuentran disponibles para la descarga en la página del desarrollador o del proyecto, por lo que esta debería ser la primera opción en esos casos.

Otros sitios donde probar:

http://www.freewarelovers.com/android
http://androidappsfree.blogspot.com.es/
http://lisvid.com/
http://apk-spot.blogspot.com.es/

Otra opción es la búsqueda a la desesperada en Google. De esa manera se puede llegar a páginas que contengan el enlace que buscamos, pero muchas otras tendrán enlaces trampa que no llevan a la descarga directa que buscamos. Es cuestión de suerte y echarle tiempo.

Bueno, esto es lo que conozco por ahora. Seguro que hay más sitios en los que buscar, por lo que agradezco ayuda para completar la entrada.

Instalación desde la tarjeta SD

Para qué repetirlo cuando está tan bien explicado aquí.

Publicado en Aplicaciones, B5510 | 2 comentarios