Captura detalles Motorola Defy con Cyanogen 7.1

Tas replicar el procedimiento de la guía de instalación he conseguido ejecutar CyanogenMod 7.1 en mi Motorola Defy sin ningún contratiempo. La instalación la realicé a partir de la rom 3.4.2 131-003 Orange Deblur rooteada (procedimiento que seguí para su rooteo). Las primeras pruebas fueron satisfactorias, el sistema es estable y más fluido que con la anterior rom. Sin embargo salió a la luz un problema con la conexión WiFi. En condiciones de uso “estándar” la conexión funcionaba correctamente. Al hacer uso intensivo de la red WiFi, como por ejemplo en la sincronización de música a través de Spotify o llamadas vía Skype, la conexión se perdía. Para recuperar dicha conexión era necesario desactivar la comunicación WiFi en el móvil y reactivarla.

Tras consultar las fuentes habituales (xda-developers y HTC manía) parecía que dicho problema era algo aislado. De modo que si no es un problema de la rom, debería ser de algún tipo de parámetro personalizable. Tras repetir los wipes de cache, dalvik, SD, etc. el problema persistía por lo que se me ocurrió que podría ser que a mi anterior rom, la cual no era oficial, le hubiese cambiado también el firmware de radio, encargado de las comunicaciones inalámbricas móviles y WiFi. En ese punto recordé que Cyanogen 7.1 incluye la utilidad Defy Baseband Switcher que permite cambiar la banda base de la radio. La banda base que tenía seleccionada por defecto era “Europa Central Hong Kong, Taiwan, Saudita, Francia, Nóridocos 3.4.x, Reino Unido 4.5.1-85“. Tras seleccionar “Europa Central RT_3.4.2-145” y reiniciar el sistema, pasé ha realizar una sincronización de música con Spotify y el problema de pérdida de conexión WiFi se había solucionado.

Captura Baseband Switcher

Éstos son los pasos que he seguido para conseguir root en Motorola Defy con Android 2.1 y firmware 2.51.1 (desde Windows 7 64bits):

1. Descargar e instalar drivers motorola.
2. En el teléfono activar Depuración USB: Acceder a: Menú->Ajustes->Aplicaciones->Desarrollo y activar “Deputación USB”.
3. Conectar teléfono por USB al PC. Seleccionar “Portal y herramientas ” en el modo de conexión USB en el móvil. Se instalarán los drivers y se abrirá el portal motorola. Cerraremos todas las ventanas del portal motorola
4. El programa para el rooteo será SuperOneClick, el cual depende de Microsoft .NET Framework 2.0, por lo que se ha de instalar: versión 32 bits | versión 64 bits.
5. Descargar SuperOneClick, descomprimirlo y ejecutarlo cómo administrador haciendo click derecho encima de SuperOneClick.exe y seleccionando “Ejecutar como administrador“.
6. En SuperOneClick hacer click en el botón “Root”. Una vez finalice el proceso correctamente, cerrar SuperOneClick, desactivar Depuración USB y reiniciar el teléfono.

deb unstable main contrib non-free

Tras buscar unos minutos encontré la alternativa a  netselect-apt: apt-spy. Su funcionalidad prácticamente la misma, testea mirrors de Debian y genera un archivo sources.list con el servidor de mayor ancho de banda.

Instalar apt-spy en Debian

Tomar privilegios de administrador y actualizar el repositorios

# su - && apt-get update

Podríamos ver la descripción de la utilidad antes de instalarla:

# apt-cache show apt-spy

Con lo que obtendríamos:

“Maneja una lista de réplicas y comprueba el ancho de banda de cada una. Entonces, escribe un archivo /etc/apt/sources.list.d/apt-spy.list en base a las respuestas obtenidas.”

Descargamos e instalamos los paquetes necesarios:

# apt-get install apt-spy

Uso de apt-spy

Una vez instalado sin problemas pasamos a ejecutar apt-spy:

# apt-spy -d unstable -a Europe -t 15

Explicación del comando anterior:

• “-d unstable”: Se selecciona la rama de Debian de nuestro sistema. Puede ser: “stable”, “testing”, “unstable” o nombres de distribución.
• “-a Europe”: Selección de área. Puede ser: “Africa”, “Asia”, “Europe”, “North-America”, “Oceania” y “South-America”. Éste parámetro es opcional.
• “-t 15″: Número de segundos que se testeará cada servidor.

Mostrará por cada servidor testeado la siguiente información:

SERVER: ftp.es.debian.org
Benchmarking FTP…
Downloaded 5803185 bytes in 12.50 seconds
Download speed: 453.26 kB/sec

Al finalizar creará el /etc/apt/sources.list.d/apt-spy.list con el servidor escogido:

Writing new sources.list file: /etc/apt/sources.list.d/apt-spy.list

A continuación y para finalizar sería recomendable deshacernos del antiguo sources.list

# mv /etc/apt/sources.list /etc/apt/sources.list_pre-apt-spy

Si bien a priori la configuración de un servidor DHCP y TFTP necesarios para iniciar con PXE podría parecer engorrosa, gracias a éste manual conseguí realizar la instalación sin topar ninguna dificultad. He añadido a mi wiki un resumen del proceso modificando algún detalle (ver la página de debian en el wiki).

Principalmente es para mi uso personal pero lo hago público por si le pudiese resultar útil a alguien en algún momento.

Wiki de Rodrigo Rega

Versión de gcc no concuerda con el kernel

A la hora de compilar los módulos del kernel, el instalador detecta que la versión de gcc por defecto no es la misma con la que se compiló el kernel que que se está ejecutando:

Your kernel was built with “gcc” version “4.3.4″, while you are trying to use
“/usr/bin/gcc” version “4.4.4″. This configuration is not recommended and
VMware Server may crash if you’ll continue. Please try to use exactly same
compiler as one used for building your kernel. Do you want to go with compiler
“/usr/bin/gcc” version “4.4.4″ anyway?

Para solucionar esto, hemos de indicar que para compilar los módulos usaremos la versión 4.3 de gcc, ya que es la que más concuerda con nuestro kernel. Cancelar el instalador (ctrl+z) de VMware y en la misma terminal se introduce lo siguiente y se vuelve a iniciar el instalador:

export CC="/usr/bin/gcc-4.3"

Error de compilación de módulos VMware

Una vez comenzada la compilación de módulos harán presencia varios errores de compilación. Para superarlos es necesario aplicar una serie de parches, éste sería el proceso:

- Descarga de los parches:

su root
mkdir /root/dev
cd /root/dev
wget http://nerdbynature.de/bits/2.6.32-22/00-vmware-2.6.32_functional.diff.txt -O vmware-2.6.32_functional.diff
wget http://nerdbynature.de/bits/2.6.32-22/02-vmnet-include.diff.txt.gz
wget http://nerdbynature.de/bits/2.6.32-22/01-vmware-2.6.32_cosmetic.diff.txt -O 01-vmware-2.6.32_cosmetic.diff
wget http://nerdbynature.de/bits/2.6.32-22/vmware-config.pl.diff.txt -O vmware-config.pl.diff
wget http://nerdbynature.de/bits/2.6.32-22/patch-vmware_2.6.3x.sh.txt -O patch-vmware_2.6.3x.sh
gunzip 02-vmnet-include.diff.txt.gz

- Editar el script de parcheado: patch-vmware_2.6.3x.sh
- Modificar en él la línea 53 eliminando el primer “../” de la línea, de modo que quede:

$DEBUG cd ../../../bin || exit 2′

- Ejecutar el script de parcheado:

chmod u+x patch-vmware_2.6.3x.sh
./patch-vmware_2.6.3x.sh /ruta/a/vmware-server-distrib/lib/modules/source

No funcionan las teclas de los cursores

Una vez instalado todo correctamente y ya con una máquina virtual ejecutándose pude comprobar que algunas teclas no funcionaban, por ejemplo los cursores. Para arreglar esto se debe crear un archivo “config” (en caso de que existiese se debe sobreescribir) dentro del directorio $HOME/.vmware/ de cada usuario que vaya a usar VMware con el siguiente contenido:

xkeymap.keycode.108 = 0x138 # Alt_R
xkeymap.keycode.106 = 0x135 # KP_Divide
xkeymap.keycode.104 = 0x11c # KP_Enter
xkeymap.keycode.111 = 0x148 # Up
xkeymap.keycode.116 = 0x150 # Down
xkeymap.keycode.113 = 0x14b # Left
xkeymap.keycode.114 = 0x14d # Right
xkeymap.keycode.105 = 0x11d # Control_R
xkeymap.keycode.118 = 0x152 # Insert
xkeymap.keycode.119 = 0x153 # Delete
xkeymap.keycode.110 = 0x147 # Home
xkeymap.keycode.115 = 0x14f # End
xkeymap.keycode.112 = 0x149 # Prior
xkeymap.keycode.117 = 0x151 # Next
xkeymap.keycode.78 = 0x46 # Scroll_Lock
xkeymap.keycode.127 = 0x100 # Pause
xkeymap.keycode.133 = 0x15b # Meta_L
xkeymap.keycode.134 = 0x15c # Meta_R
xkeymap.keycode.135 = 0x15d # Menu

Por último es recomendable reiniciar VMware:

/etc/init.d/vmware restart

mount.ntfs-3g usa el 100% de la CPU

En caso de usar para nuestras máquinas virtuales una partición ntfs como medio de almacenamiento, nos encontraremos con que el proceso mount.ntfs-3g usa el 100% de la CPU haciendo que la máquina virutal VMware funcione exageradamente lenta. Para solucionarlo se debe añadir la siguiente línea al archivo de configuración general de VMware “/etc/vmware/config”:

mainMem.useNamedFile = "FALSE"

Fuentes:

• http://communities.vmware.com/message/1568283#1568283
• http://www.question-defense.com/2010/05/02/arrow-keys-not-working-in-vmware-server-2-0-guest
• http://vmfaq.com/entry/25/

rar a -r -s -v51200 mi_nuevo_archivo_multipart.rar "directorio_que_quiero_comprimir/"

Los parámetros usados para comprimr el archivo rar en varias partes en Linux son los siguientes:

a: Añadir archivos (comprimir).

r: Añadir directorios recursivamente.

s: Archivo sólido. Copia todos los archivos a uno único antes de comprimir, aumentando así el ratio de compresión.

v: Divide el archivo comprimido resultante en partes de 50 MB cada uno (expresado en KB).

Para solucionar este problema he usado esta pequeña función que se encarga de formatear un archivo XML.

function formatXml($archivoXml) {
    $doc = new DOMDocument();
    $doc->preserveWhiteSpace = false;
    $doc->formatOutput = true;
    $doc->load($archivoXml);
    $doc->save($archivoXml);
}

Un captcha visual débil resulta sencillo de romper gracias a programas de reconocimiento óptico de caracteres (OCR). Un captcha visual que resulte difícil de crackear debe contar con diferentes fuentes tipográficas, tamaños, colores, caracteres distorsionados y ruido en el fondo.

Ejemplo de un buen captcha

En esta entrada me gustaría mostrar lo sencillo que resulta el crackeo de un captcha débil. Para ello voy a exponer un caso real, omitiendo la dirección de la página web en cuestión. Se trata de una página que permite a sus usuarios hacer pública cierta información en forma de código. Este proceso se realiza anonimamente y sin ningún tipo de autentificación,  tan sólo cuenta con el siguiente captcha:

captcha debil que romperemos

A simple vista se aprecia que el captcha no aporta gran seguridad gracias a sus caracteres perfectamente definidos.

Ejemplo práctico de crackeo de captcha débil

Para crackearlo usaremos el programa GOCR, el cual es open souce y en Linux se puede instalar desde las fuentes habituales.

Este programa requiere un “entrenamiento” previo para reconocer los caracteres, por lo que será lo que hemos de hacer en primer lugar:

mkdir ocrdb
gocr -d 2 -p ./ocrdb/ -m 256 -m 130 captcha.png

La ruta ./ocrdb/ será en dónde se guardarán los datos que genere gocr a partir de su “entrenamiento”, este directorio lo tenemos que crear manualmente. ‘captcha.png’ es el captcha que crackearemos. Al ejecutar este comando, nos encontraremos con lo siguiente:

Entrenamiento de gocr

En esta captura vemos como gocr nos pregunta por la primera letra, en este caso una “V”. La letra por la que nos pregunte en cada momento estará pintada con corchetes ‘#’, las demás con ‘O’. Al introducir la letra “V” continuará con las siguientes letras del captcha. Este proceso lo tendremos que repetir cuantas más veces mejor, hasta que gocr sea capaz de entender el captcha sin nuestra ayuda. Por lo que tendremos que ejecutar el comando bastantes veces, para agilizar el proceso podemos usar el siguiente script:

#!/bin/bash
while [ 1 ]; do
        wget -O captcha.png http:/servidor-ejemplo.com/captcha_gen.php ;
        gocr -d 2 -p ./ocrdb/ -m 256 -m 130 captcha.png ;
done

Cuando gocr sea capaz de descifrar la mayoría de captchas por si mismo pulsamos ctrl+c para detener el script. Lo siguiente sería poner a prueba el programa:

gocr -p ./ocrdb/ -m 256 -m 2 captcha.png

Este sería el método general para usar gocr, pero en el ejemplo que he propuesto es poco útil. Vamos a crear un script que se encargue del crackeo del captcha y del envío de nuestros códigos a la página con wget:

#!/bin/bash
# este será el código que se le enviará a la web
miCodigo='XPEYWZA-002'

# urls de la página. La general y la que recibe los datos por POST
url='http:/servidor-ejemplo.com'
postUrl='http:/servidor-ejemplo.com/add-code.php'

# rutas temporales de trabajo
dirActual=`pwd`
dirTrabajo='/tmp/captcha'

# si existe el directorio temporal lo borramos
if [ -d "$dirTrabajo" ]; then
        rm -Rf $dirTrabajo
fi
mkdir $dirTrabajo
cd $dirTrabajo

# hacemos una primera petición a la web guardando cookies
wget --save-cookies $dirTrabajo/cookies.txt --keep-session-cookies \
        -r $url

# renombrarmos el captcha, realizamos el OCR y eliminamos los espacios en blanco
mv captcha.php captcha.png
captchaResuelto=`gocr -p $dirActual/ocrdb/ -m 256 -m 2 captcha.png`
captchaResuelto=${captchaResuelto/ /}
echo 'CAPTCHA RESUELTO:' $captchaResuelto

# envíamos por POST el código a añadir y el resultado del captcha,
# teniendo en cuenta las cookies y datos de sesión
wget --post-data="add=$miCodigo&captcha_code=$captchaResuelto" \
                --keep-session-cookies --load-cookies $dirTrabajo/cookies.txt \
                $postUrl
cd $dirActual

Este script lo guardaremos el el mismo directorio en el que tenemos “ocrdb/”. Le podríamos añadir algunas comprobaciones de respuesta de la web, algún bucle para repetir el envío, ejecutarlo cada X tiempo vía crontab, etc. Pero eso se sale de las pretensiones de esta entrada.

Nota: Las urls de los scripts están mal formadas intencionadamente (http:/) para que el resaltador de código no las incluya como enlaces.

Dicho error es producido por la configuración por defecto de java en Debian. Al comprobar los servicios a la escucha, el puerto 9000 (eclipse) está escuchando sobre ipv6:

netstat -anp -t tcp | grep 9000

tcp6 0 0 :::9000 :::*  LISTEN  4390/java

Para solucionar dicho problema será necesario  modificar el siguiente archivo:

/etc/sysctl.d/bindv6only.conf

Localizar la siguiente línea:

net.ipv6.bindv6only = 1

sustituirla por esta que sigue:

net.ipv6.bindv6only = 0

a continuación ejecutar:

sysctl -p /etc/sysctl.d/bindv6only.conf

por último reiniciar Eclipse.