Con esta imagen hecha, es sencillo replicar dicha configuración software para producción de más equipos.

Puede ocurrir que sea necesario acceder a dichos ficheros para consulta, generación de una nueva versión, etc.

Con software para equipos embebidos suele resultar difícil o imposible acceder al rootfs desde el propio sistema.

Voy a explicar un procedimiento que uso para poder montar dichas particiones desde cualquier equipo con GNU/Linux a partir del “dumpeo” de disco creado mediante DD.
Básicamente lo que vamos a hacer es localizar donde es probable que empiece nuestra partición y luego crear un dispositivo loopback aplicando un offset donde posiblemente empiece dicha partición.

Para localizar la partición haremos uso de la utilidad scandrive de Stephen J. Frield. Esta utilidad busca la palabra mágica que representa un header de ext2 (0xEF53). Además, y esto es casi lo más importante, localiza un potencial inodo-root (vamos, el directorio raiz). Esto sirve para intentar idefintificar correctamente donde comienza nuestra partición. ¿Cómo? Miramos el offset donde se encuentra el header de ext2 justo anterior a la localización del directorio raiz (depende del tamaño del disco, es posible que nos encontremos con muchos “falsos positivos”).

He modificado la utilidad scandrive, para que nos de el posible offset real para hacer el montaje correcto. Dicha posición se calcula restando al offset donde se encuentra el header de partición, los 1024 bytes de offset donde se encuentra el superbloque.

Este seria el procedimiento:

Midiendo tiempos de respuesta en Django

El tiempo de respuesta de un servicio web es el tiempo que transcurre desde que se realiza una petición hasta que se envía el último byte de respuesta al cliente.

Es vital para las aplicaciones web medir este tiempo con el objeto de optimizar la capacidad de respuesta. Nos interesa por tanto minimizar el tiempo de respuesta.

Para aplicaciones web desarrolladas con el framework Django he desarrollado un middleware sencillo que mide el tiempo de respuesta de proceso desde que Django es “consciente” (Python).

Sin duda el middleware, es una de las características que más me gusta de Django. Permite, entre otras tantas cosas, añadir objetos al request.

Una clase middleware debe tener al menos un método: process_request.

En nuestro caso, tenemos 3 métodos: process_request, process_response y __init__.

La idea es simple. Cuando llega un request, añadimos una marca de tiempo al request (process_request).

Cuando ese request es procesado, obtenemos la diferencia de tiempo y la “logueamos” (process_response).

En __init__ simplemente inicializamos el contexto de logging.

Os dejo el código.

¡Que aproveche!

import logging
from datetime import datetime
from django.conf import settings
class LogTime(object):

        def __init__(self):

                self.log = logging.getLogger("tm")
                self.log.setLevel(logging.INFO)
                formatter = logging.Formatter('[%(asctime)s] "%(message)s"','%Y-%m-%d %a %H:%M:%S')
                if len(self.log.handlers) == 0:
                        hdlr = logging.FileHandler(settings.LOG_TIME_FILE)
                        hdlr.setFormatter(formatter)
                        self.log.addHandler(hdlr)

        def process_request(self,request):

                request.dtLogTimeStart = datetime.now()

        def process_response(self,request,response):
                if 'dtLogTimeStart' in dir(request):
                        delta = datetime.now()-request.dtLogTimeStart
                        self.log.info("req: %s - time: %i.%06i" % (request.path,delta.seconds,delta.microseconds))
                return response

#nolesvotes

1. OBJETIVO DE #NOLESVOTES. Las personas que apoyamos a la iniciativa #nolesvotes desde sus inicios, a la vista de la catarata de tergiversaciones vertidas por políticos y medios de comunicación, queremos recordar y subrayar que la iniciativaen ningún modo promueve la abstención, y que surgió para hacer una llamada al ejercicio del voto responsable el próximo 22-M. La iniciativa pide específicamente que no se vote a los partidos que responden a intereses distintos a los de la ciudadanía: PP, PSOE y CiU, pero recomienda que en su lugar se examinen otras opciones. La iniciativa no pide el voto para ninguna opción concreta: el voto es responsabilidad de cada ciudadano.
2. HAZ DE TU PÁGINA UN CARTEL ELECTORAL. Las calles están llenas de carteles electorales, pero muchas personas no se ven representadas en ellos: la intermediación hizo que la política sea cada vez más lejana al ciudadano. Para subsanar tal déficit democrático, proponemos que todo ciudadano que así lo desee pueda convertir su blog, su web, su muro o su twitter en un “cartel electoral” del movimiento. Si quieres respaldar esta iniciativa, convierte tu sitio en Internet en un cartel electoral antes de las 24 horas del próximo día 20 de mayo, con el logotipo de #nolesvotes o de las plataformas con las que simpatices, y el texto “ni PP, ni PSOE, ni CiU”.
3. COLABORACIÓN DISTRIBUIDA. Te invitamos a copiar este texto y construir páginas de enlaces que referencien todos los sitios que dan apoyo a la iniciativa. De igual modo, invitamos a los demás colectivos que comparten nuestra propuesta a que lleven a cabo acciones similares. La fuerza de la red reside en la distribución y colaboración entre sus nodos.
4. TÚ ERES EL ALTAVOZ. Tan importante es la red como la calle: no te limites a actuar en internet. Levántate y explícaselo a todos tus conocidos, especialmente a aquellos más vulnerables a la propaganda en los medios de comunicación masivos.
5. ACCIÓN. No te quedes en casa el domingo 22. Sal a la calle y ejerce tu derecho al voto. No votes a quienes, actuando abiertamente en contra de la voluntad e intereses de los ciudadanos, han convertido la democracia en una burla de sí misma. Por la participación democrática activa: ni PP, ni PSOE, ni CiU.

#nolesvotes

MÁS INFORMACIÓN

Manifiesto de #Nolesvotes | http://www.nolesvotes.com/
Wiki colaborativo #nolesvotes | http://wiki.nolesvotes.org/wiki/Portada
Twitter #nolesvotes | http://twitter.com/#!/search/nolesvotes
Facebook #nolesvotes | http://goo.gl/4Nmj1
Material gráfico #nolesvotes | http://goo.gl/dbGAb

No existe sistema 100% seguro e impenetrable y afirmo que jamás lo existirá.

Puedo entender por tanto que se realice un ataque y roben la valiosa base de datos.

Pero lo que me parece INADMISIBLE es leer lo siguiente del comunicado oficial:

fecha de nacimiento, nombre de acceso y contraseña de PlayStation Network/ Qriocity

No especifican nada de cómo está almacenada la contraseña.

Cualquier webmaster amateur, sabe que las contraseñas JAMÁS deben de almacenarse como tal.

El procedimiento habitual es realizar un cálculo hash sobre la contraseña y almacenar este resultado en la BBDD.

Cuando un usuario quiere autenticarse, basta con calcular el hash al valor introducido como contraseña y enviarlo al servidor.

Si ambos hash coinciden, bingo, es Fulano.

Si por ejemplo tu contraseña es “mypassword”, el hash con md5 seria: 34819d7beeabb9260a5c854bc85b3e44 (si queréis probarlo en GNU/Linux, echo -n “mypassword” | md5sum).

En fin, estoy realmente enfadado con la noticia y espero que den detalles de cómo almacenan las contraseñas.

Como he leido hoy en Twitter: “menos abogados y más ingenieros de calidad“

¬¬

ACTUALIZACIÓN: Sony no afirma que se hayan efectuado el robo de los datos de las tarjetas de crédito.  Hay que estar atentos a los movimientos bancarios y denunciar cualquier cargo no realizado lo antes posibles (creo que hay un plazo para anular cobros).

ACTUALIZACIÓN 2:  Añado una conversación obtenida en red IRC donde “hackers” hablan sobre la poca seguridad de los servidores de PSN Network. La fuente original esta en PSX-SCENE.

PSN Hacker IRC Log

Videojuego en Español, Fuente: arsGames

Os traigo mi último desarrollo:  ZX Launcher.

En otra ocasión, os presente el lanzador de juegos para Intermediae: artLauncher.

Se trata de un lanzador de juegos de Spectrum desarrollado para mis amigos de arsGames de cara a la exposición “Videojuegos en español” que recorrerá los centros del Instituto Cervantes mostrando el pasado y presente de los videojuegos en Español.

Es gratificante saber que ZX Launcher se ejecutará por todo el mundo. La primera parada ha sido Tetuán (Marruecos). Aquí podéis ver fotos y vídeos del primer éxito de la exposición.

Los años 80 fueron sin duda la época de esplendor del sector de los videojuegos en España. Compañías como Dinamic (actual FX Interactive) fueron líderes internacionales del sector.

Este lanzador recoge algunos de esos magníficos juegos que seguro provocaran alguna sonrisa melancólica al “treintañero” que lo pruebe.

Gracias a FX Interactive se puede distribuir. Podéis bajaros aquí el instalador.

Gracias también a arsGames por el magnífico trabajo gráfico del lanzador.

Aspectos técnicos

La aplicación esta escrita en Python y utiliza el framework de Qt para la interfaz gráfica.
A pesar de ser Python, sólo corre en sistemas Windows ya que se hace uso de algunas llamadas al API de Win32 (librería pywin32)

La pieza clave del software es el emulador de Spectrum. Después de valorar los emuladores disponibles FOSS, opté por FUSE debido a la opción de carga directa de juegos, que es multiplataforma y por su organización del código (backend y frontend).

Para integrarlo con Python y Qt, tuve que modificar el código de FUSE para hacerlo embebido a una ventana de Qt. Lo que hice fue, sin entrar en detalles, obtener el handle de la ventana para que FUSE dibujara directamente dentro. Además, para controlar y pasar los eventos de teclado, tuve que implementar un paso de mensajes entre Python y FUSE usando Win32 SendMessage con mensajes tipo WM_COMMAND.

Os dejo con un vídeo demostrativo.

LedController for GNU/Linux

Hoy me ha llegado un chinagadget comprado en DealExtreme.

Se trata de un notificador de nuevos emails o eventos de mensajería.

Como era de esperar el driver/software sólo funciona para sistemas Windows pero me gustaría poder utilizar este “cachibache” en mi Ubuntu.

He supuesto que encender una bombilla vía USB no debía ser muy complicado y me he puesto manos a la obra.

Lo primero que tenia que averiguar era la configuración y el protocolo del driver para encender/apagar el LED a voluntad.

Para hacer esta mini ingeniería inversa he utilizado VirtualBox y Wireshark.

Wireshark es ampliamente usado como sistema de captura y análisis de paquetes de red. Ahora además nos permite “sniffar” el tráfico USB.

Con VirtualBox se crea una maquina virtual Windows donde instalamos los drivers oficiales del notificador.

Con nuestra máquina virtual corriendo, ponemos a escuchar a nuestro sniffer.

Es necesario saber en que bus se encuentra nuestro dispositivo. Ésto se soluciona con un simple lsusb.

Ahora le indicamos a WireShark que escuche en dicho bus y ejecutamos un escenario donde se encienda/apague el led.

El resultado es un gran fichero de captura con mucha morralla.

Analizando el tráfico se observa un incontable número de paquetes enviados por interrupción pero cuyo contenido es siempre el mismo. Desconozco su propósito (¿quizás un sistema rudimentario de heartbeat?).

Filtrando por endpoint, se ve que hay dos endpoints, 1 y 2 (además del EP de control 0).

El EP 1 es el que usa para transferencias por interrupción del mensaje repetitivo.

El EP 2 es el que se usa para el envio de comandos de encendido.

En concreto, después de jugar con la aplicación de notificación, detecte la siguiente trama para encender el led rojo:

0x02 0x04 0x04 0x04 0x04

Para apagarlo, se usa ésta otra:

0x00 0x04 0x04 0x04 0x04

Con el protocolo (a priori) detectado, decidí hacer el driver en espacio de usuario para GNU/Linux.

Para acometer ésto, opté por usar la librería de acceso a USB, libusb.

Esta librería permite el desarrollo rápido de drivers/aplicaciones USB en GNU/Linux (también está disponible para Windows). Para dispositivos sencillos como este se ajusta perfectamente. Si por el contrario queremos controlar un dispositivo con alta intesidad de E/S, es recomendable implementarlo mediante un módulo kernel.

La implementación es sencilla. Se pasa como parámetro el color del LED a encender (en la secuencia, 2 = rojo, 1 = azul, 2 = verde).

Lo relevante está en la línea 55. Aquí es donde se envía por interrupción, el comando por el EP 2.

También es interesante la línea 41. Aquí se descarga el manejador kernel de dispositivo en caso de que algún driver lo haya reclamado (en este caso el driver HID).

#include <stdio.h>
#include <libusb.h>
#include <errno.h>

#define VID 0x1294
#define PID 0x1320

static struct libusb_device_handle *devh = NULL;

int main(int argc,char** argv)
{
 int ret;
 unsigned char code = 0;
 if (argc != 2 )
 {
    printf("syntax: %s red | green | blue | off\n",argv[0]);
    return -1;
 }
 if ( strcmp(argv[1],"red") == 0 )
 {
     code = 2;
 }
 else if ( strcmp(argv[1],"green") == 0 )
 {
     code = 3;
 }
 else if ( strcmp(argv[1],"blue") == 0 )
 {
     code = 1;
 }
 libusb_init(NULL);
 devh = libusb_open_device_with_vid_pid(NULL, VID, PID);
 if (devh == NULL )
 {
	printf("not found\n");
        return -1;
 }
 if ( libusb_kernel_driver_active(devh,0) )
 {
	printf("detach from kernel\n");
        ret = libusb_detach_kernel_driver(devh,0);
        if (ret < 0 )
        {
		printf("can't detach\n");
                return -1;
        }
 }
 char data[5];
 data[0] = code;
 data[1] = 0x4;
 data[2] = 0x4;
 data[3] = 0x4;
 data[4] = 0x4;
 int dummy;
 ret =  libusb_interrupt_transfer(devh,0x2,data,5,&dummy,0);
 if ( ret < 0 )
 {
  perror("error");
 }
return 0;
}

Os dejo el fuente de programa, una versión compilada dinámicamente y otra estáticamente.
Fuente: ledcontroller.tar.gz

Os voy a explicar como transferir archivos por red usando netcat.

Supongamos que tenemos el fichero “vmlinuz” que queremos transferir a un nuevo equipo (con IP 192.168.1.2) .

Lo primero es poner el equipo receptor en modo escucha para recepcionar el fichero:

nc -l -p 10000 > vmlinuz

Los parámetros son sencillos. Con -l ponemos a nc en modo escucha y con -p especificamos el puerto.  Usamos redirección para indicar donde almacenar el fichero (vmlinuz).

Vamos a enviar el fichero

nc 192.168.1.2 10000 < vmlinuz

Poco que explicar: IP, puerto de destino y fichero de entrada (vmlinuz).

Espero que os sirva.

ACTUALIZACIÓN: El otro día no me funciono este tip usando clientes distintos de nc, tuve que añadir al emisor el flag “-q 0″ (nc -q 0 192.168.1.2 10000 < vmlinuz) para que cerrara la transferencia justo al terminar el envío.

PS3 EPIC FAIL

La seguridad de la PS3 ha sido comprometida al 100% . Después de presumir de 5 años sin sucumbir al “ataque” de los hackers, a día de hoy se conoce hasta la clave root (a.k.a. metldr key) de cifrado.

Esto es muy grave. Es un gran palo para la industria y especialmente para Sony.

El mérito de esta gesta no pertenece a un único hacker, sino a la contribución de varios grupos y “artistas” en solitario.

Voy a resumir los principales hitos hasta la fecha.

• Acceso al RSX desde GNU/Linux instalado en la PS3.
• Geohot accedió al Hypervisor
• El grupo fail0verflow demuestra cómo se puede obtener las claves de cifrado de PS3 (EPIC FAIL)
• Geohot comunica que ya tenia la clave raíz.

Insisto en la gravedad del asunto. Son muchos los desarrolladores a los que sin duda afectará esto.

La pregunta es, ¿cómo se ha tardado tanto tiempo en conseguir esto?

Cuando Sony saco la PS3, incluyo la posibilidad de ejecutar otro sistema operativo en la consola (OtherOS). La mayoria de los hackers optó por usar GNU/Linux dada su inmediatez, disponibilidad y soporte de IBM.

A raíz del acceso ilegítimo al RSX, Sony creyó conveniente quitar el acceso a OtherOS (primero con la PS3 Slim sin OtherOS y luego con un revisión de firmware que denegaba el acceso a las PS3 “fat“). Esto incluso provocó que usuarios demandarán a Sony.

ERROR. Sony quitó el caramelo gamusino que tenia entretenidos a los hackers. A raíz de ahí, la comunidad se propuso el reto de devolver la opción de instalar OtherOS de nuevo en la consola. Han ido mucho más alla.

Los ingenieros de Sony se centraron en que el Cell y su SPE security isolation hacian que no fuera posible acceder al código descifrado en ejecución dentro de SPE. Dejaron a un lado aspectos criptográficos importantes  (como delvolver una constante en una función que genera números aleatorios) que han permitido el EPIC FAIL.

Esto no sólo permite la piratería. Abre un camino para que cualquiera pueda sacar software legítimo técnicamente a espaldas de Sony. Dada su alta conectividad en red, no creo que tarde tiempo en aparecer incluso virus. Ya existen numerosas utilidades para firmar código como si la misma Sony se tratara.

No sólo la PS3 ha sido comprometida, la PSP también lo ha sido. Parece ser que la clave raíz de la PSP se incluye dentro del firmware de PS3, luego ha sido cuestión de buscar un poco.

¿Qué debería hacer Sony ahora?

Dos buenos refranes encajan aquí:  ”Si no puedes con el enemigo, únete a él” y “No hay mal que por bien no venga“.

Desde mi punto de vista,  tres cosas:

1. Centrarse en PS4. Reestructurar recursos para sacar en la mayor brevedad posible una nueva versión. Puede ser muy conveniente aceptar la demanda de trabajo de geohot (tal y como reza en su web:  ”it’d be fun to be on the other side“)
2. PSN y periféricos. Desconozco como quedará de comprometido el PSN después de esto.  No sé si se podrá conectar  la consola al PSN. Teniendo control total sería posible cambiar información básica como ID/MAC siempre y cuando no se corrobore ese número de serie con la BBDD de Sony. El caso es que tiene que mejorar los contenidos de PSN para sacarle rendimiento ecónomico a la plataforma. Otra opción mucho más sencilla es sacar juegos que requieran periféricos especiales.  De esta forma se venden tantos juegos, como periféricos. Son buenos ejemplos: Singstar, EyePet, Buzz, etc.
3. OpenPS3. Más radical. El OtherOS mantuvo a la comunidad hacker (no confundir con cracker) entretenida durante más de 3 años. ¿Por qué no abrir la PS3 a todos? Bastaría con hacer un sitio web y poner al frente a un pequeño grupo de trabajadores. Esto ayudaría a mejorar la imagen de Sony mientras  mantiene distraidos a los hackers. Esta opción no tiene porque prescindir de una contraprestación económica. Un modelo de negocio freemium podría funcionar bien.

¿se te ocurre alguna opción más?

En fin, un EPIC FAIL como la copa de un pino que espero no hunda a la miseria a más de uno.

P.D. Esta mañana fué liberado el primer custom firmware basado en 3.55 firmado como si fuera legítimo. Éste se puede instalar perfectamente desde un pendrive en cualquier consola. Sony debe mover ficha.

En Python, lo normal es que de forma automática aparezca el traceback cuando se produce una excepción:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'ls' is not defined

Hay ocasiones en los que obtener esta información no es tan trivial.
Un ejemplo común es el desarrollo de servicios webs. En este caso no sirve de nada imprimir por pantalla el error, ya que no queda registrado en ningún sitio.

Para poder obtener el traceback y depurar correctamente el servicio, podemos hacer uso del módulo traceback.

El siguiente codesnippet permite imprimir en el archivo de log el correspondiente traceback:

try:

# Código bajo sospecha

....
except:

import traceback
import StringIO
s=StringIO.StringIO()
traceback.print_exc(file=s)
s.seek(0)
msg=s.read()
logging.debug("TRACEBACK: %s" % msg)

Tutorial Amazon Route 53

ACTUALIZACIÓN: (17/11/2011)  Amazon acaba de anunciar que ha incluido la gestión de Route53 desde la consola de gestión. Sin duda un gran avance que facilita enormemente la gestión DNS.

Amazon Web Services no para de sacar productos interesantes y económicos. Si las bases de datos se volvieron más simples con Amazon RDS, ahora “desaparece” el problema de la gestión DNS (más bien, se simplifica bastante) con Amazon Route 53.

Voy a explicar cómo podemos hacer un uso sencillo de Route 53 para nuestra pequeña web en nube. Vamos a suponer que tenemos corriendo una instancia de EC2 con la IP elástica 123.123.123.123.

A día hoy no se puede gestionar Route 53 desde la consola de AWS. Hay que recurrir a invocar directamente los servicios web mediante cURL.

Como ocurre en muchas ocasiones, la comunidad SL va por delante de las corporaciones y ya existe una utilidad CLI que nos permite operar con Route 53 de una manera más sencilla.

La utilidad se llama cli53 y ha sido desarrollada por bee11149. Lo primero que haremos será instalar tanto la utilidad como sus prerequisitos (Boto y dnspython).

git clone git://github.com/boto/boto && cd boto && python setup.py install
easy_install dnspython
git clone git://github.com/barnybug/cli53

En la primera línea instalamos Boto (Control de Amazon Web Services para Python).
Luego se instala dnspython y por último nos descargamos la utilidad cli53.

Para que funcione cli53, debemos establecer dos variables de entorno con nuestros credenciales de acceso a AWS.

export AWS_ACCESS_KEY_ID=<nuestra_clave_id>
export AWS_SECRET_ACCESS_KEY=<nuestra_clave_privada>
cd cli53

Ya esta preparado el entorno para empezar a usar cli53. Lo primero que haremos será crear nuestra hostedzone. Vamos a suponer que nuestro dominio es caramelos.com y queremos poder acceder a la web mediante “caramelos.com” y “www.caramelos.com”

./cli53.py create caramelos.com

Si todo va bien, nos debe devolver algo similar a esto:

HostedZone:
CallerReference: xxxxxxxx-8efb-4947-yyyy-53489dxxxxxxx
Config:
Comment:
Id: /hostedzone/Z2JZCX7IR3C3O9
Name: caramelos.com.
ChangeInfo:
Status: PENDING
SubmittedAt: 2010-12-21T10:16:05.719Z
Id: /change/C2JH25LA6TOVE9
DelegationSet:
NameServers:
- ns-739.awsdns-28.net
- ns-118.awsdns-14.com
- ns-1414.awsdns-48.org
- ns-1829.awsdns-36.co.uk

Esta información nos indica que se ha creado correctamente la hostedzone con ID Z2JZCX7IR3C3O9 (línea 5), que esta pendiente de sincronizar (8) y nos da
los servidores DNS a donde debemos apuntar el dominio (13-16).  Ahora debemos de contactar con el registrador de nuestro dominio “caramelos.com” y especificar estos servidores DNS.
Lo normal es que dejen establecer entre 2 y 4 servidores. A más servidores, mayor disponibilidad.

Por último, necesitamos crear las entradas DNS para que se pueda acceder a nuestra web. Recordemos que la IP del servidor donde tenemos nuestra web es 123.123.123.123.  Vamos a crear una entrada tipo A y otra CNAME. En formato BIND sería:

./cli53.py rrcreate caramelos.com @ A 123.123.123.123 --ttl 3600
./cli53.py rrcreate caramelos.com www CNAME caramelos.com --ttl 3600

Con la primera linea creamos un registro A que mapea nuestro dominio (caramelos.com, representado por @) a la IP 123.123.123.123, mientras que
con la segunda, asociamos el nombre www.caramelos.com a caramelos.com usando un registro CNAME. El parametro TTL (Time to live) sirve para indicar con
qué frecuencia se debería de refrescar la lectura de dicho registro por parte de clientes DNS.

Si todo ha ido bien, después de darle un tiempo para que se sincronice toda la cadena DNS, nuestro navegador web deberia mostrar la página si introducimos
“caramelos.com” o “www.caramelos.com“.

Aquí podéis obtener más información sobre los distintos tipos de registros DNS.
¡A migrar DNS!