Un cd mejorado

A menudo echaba en falta poder hacer

pablo@golgi:~$ cd dir1/dir2/

sin preocuparme de si dir1/ y/o dir2/ estaban creados, confiando en que cd los crearía.

Si bien se puede hacerle un hack al fuente de bash, es más laborioso que crear una función para la shell y añadirla a .bashrc:

ccd () {

if [ $# == 1 ]; then

if [ -d $1 ]; then

cd $1;

else

mkdir -p $1 && cd $1;

fi;

else

if [ $# == 0 ]; then

cd $HOME;

else

printf "Too many arguments\n";

fi;

fi;

}

Por ejemplo:

pablo@golgi:~/md$ ccd d1/d2 (no existen ni d1/ ni d2/, así que los crea)
pablo@golgi:~/md/d1/d2$ cd ../..
pablo@golgi:~/md$ ccd d1/d2 (ya existen d1/ y d2/, así que no los crea)
pablo@golgi:~/md/d1/d2$ cd ../..
pablo@golgi:~/md$ ccd d1 d2
Too many arguments
pablo@golgi:~/md$ ccd
pablo@golgi:~$

Y ahora lo que hecho en falta es un plugin para wordpress que represente código adecuadamente.

Comments

Redes de computadoras

Un libro de uno de los míticos: Andy Tanenbaum. Junto con Silberschatz y Stallings creo que son la biblioteca básica de cualquier estudiante de ciencas de la computación.

800 y pico páginas, casi tan tocho como sus otros libros. Escrito en un tono muy cercano y ameno, y posiblemente gracias a esa forma de transmitir conocimiento le hayan dado el premio Karl V. Karlstrom.

El libro pretende ser una introducción a todo lo que es el campo de las redes de computadoras, tratando desde los niveles más bajos (sin mucha profusión) hasta los niveles más altos. Habla de normalización, de estándares y de las instituciones que se ocupan de ellos. Trata ligeramente el medio físico, procurando abarcar desde fibra óptica a satélites. A la capa de enlace le otorga casi doscientas páginas, para luego pasar a la capa de red. En la capa de red, aparte de algoritmos de enrutamiento, habla un poco de congestión y de calidad de servicio. Le siguen el nivel de transporte, protocolos del nivel de aplicación y seguridad en redes, donde repasa la criptografía simétrica y la de clave pública, además de hablar de certificados, SSL, PGP, S/MIME, IPsec, etc.

El libro es un must-read: una primera lectura sirve para introducirnos en (¿casi?) todos los temas de redes, lecturas posteriores como libro de referencia pueden ser útiles para reintroducirnos en algún aspecto en el que queramos trabajar, ya que además el libro finaliza con una extensa lista de bibliografía para profundizar más en ese tema en concreto.

Desde luego recomiendo su lectura, aunque cuesten las 800 páginas, tanto en términos de tiempo como de dinero (45 o 50 euros, aunque es fácil de encontrar en bibliotecas).

Comments

Pequeño parche para BlueZ/hcitool

Hace más de un mes trabajando con hcitool detecté lo que a mi juicio era un bug muy tonto y de fácil solución, así que me puse a ello, hice un parche y lo envié a los desarrolladores de BlueZ…

Copy+paste del mensaje que envié a la lista bluez-devel:

Hi! If I want to scan on hci0 the next sintax is bad, but hcitool
doesn't complain:
pablo@golgi:~$ hcitool hci0 scan
pablo@golgi:~$
(I better should use hcitool -i hci0 scan)

I've written a little patch to warn when an unrecognised command is given:

pablo@golgi:~/work/hcitool-patch1/utils/tools$ diff -u hcitool.c.orig
hcitool.c
--- hcitool.c.orig	2007-12-28 20:06:58.000000000 +0100
+++ hcitool.c	2007-12-29 11:35:00.000000000 +0100
@@ -2329,5 +2329,11 @@
 		command[i].func(dev_id, argc, argv);
 		break;
 	}
+
+	if(!command[i].cmd) {
+		fprintf(stderr, "\"%s\" isn't a valid command. Try --help for a list
of commands.\n", argv[0]);
+		exit(1);
+	}
+
 	return 0;
 }

Now, when I ask for an inexistent command it complains:
pablo@golgi:~$ ./hcitool nop scan
"nop" isn't a valid command. Try --help for a list of commands.
pablo@golgi:~$

If you find it useful, feel free to commit it.

Bye.

La verdad es que el parche es tontísimo y no sé si lo aplicarán, pero hay queda, por si a alguien le vale para algo. Me dio más guerra seguir el coding style que hacer el propio parche (por aquí va el hilo).

Update: me acabo de fijar que me dieron más indicaciones para el coding style de las que seguí (no las vi), razón adicional para omitir el parche.

Comments

Beginning Perl for Bioinformatics

El mayor fallo que le achaco a este libro es que está muy poco actualizado desde 2001 que es de cuando data la primera edición. Al leer el texto se nota en algunas partes que haría falta alguna revisión.

Mi intención cuando lo compré era leer algo que me introdujera en la bioinformática y refrescar un poco el perl, que de no usarse las cosas se oxidan.

El perl que se trata en el libro es muy básico, como cabía esperar, ya que el libro está orientado para biólogos (o similares) sin apenas conocimientos de informática –aunque alguno sí: tener instalado un Unix, aunque sea MacOS X, sí se hace necesario. Apenas se profundiza en el lenguaje, pero realmente para mí tampoco era esa la intención (para eso probablemente el Programming Perl de Larry Wall, o el de Damian Conway sean más adecuados). Creo que para un biólogo sí puede ser un texto recomendable, ya que presenta una serie de ejemplos en perl muy bien comentados, y desde mi punto de vista es fácil de seguir –igual que para un biólogo un texto de bioquímica también le será fácil de asimilar :).

De los trece capítulos del libro los seis primeros tratan de introducir perl: expresiones regulares, variables, subrutinas, el depurador, acceso a ficheros, etc.

Además en la web del libro están todos los ejercicios resueltos, así como una librería de funciones útiles para la bioinformática (al menos para empezar, porque gran parte de esas funciones ya están en Bioperl).

Y la bioinformática: el texto sirve para introducirse un poquito en qué es lo que se hace, aunque dada mi falta de conocimientos en biología se me queda un tanto cojo. En el libro se menciona el paso de ADN a proteína. Presenta varios métodos para realizar el proceso, para que el lector se familiarice con perl y que vea cómo se trabaja con expresiones regulares y conozca las hashes de perl.

De ADN a proteína

Biológicamente una cadena de ADN es una secuencia de bases nucleotídicas, y bases nucleotídicas hay cinco: adenina, timina, uracilo guanina y citosina, de las cuales en el ADN están todas presentes a excepción del uracilo (que reemplaza a la timina en el ARN).

Estas secuencias en perl se representan como cadenas de caracteres, así una cadena de ADN que sea adenina, citosina y guanina se representa como 'ACG'.

Cada tres bases forman lo que se llama un codón, y cada codón codifica un aminoácido. Habiendo cuatro bases y tres bases por codón, un codón podría tener hasta 64 valores diferentes (i.e. codificar 64 aminoácidos diferentes). Sin embargo, en la naturaleza sólo hay 20 aminoácidos, por lo que parte de esas secuencias no tienen significado (código degenerado), otras tienen el mismo significado (p.ej. UUU y UUC codifican la dos la fenilalanina), y otras simplemente son códigos de parada: le indican a la maquinaria celular que la cadena ha llegado al final.

En la célula quien hace las tareas son las proteínas: las proteínas son quienes componen mayoritariamente la máquina celular, las que hacen que esa maquinaria trabaje, y en definitiva son las que dirijen el cotarro. Qué proteínas se deben fabricar y cuándo es tarea de los genes: cuando un gen se expresa se inicia un proceso de transcripción que da lugar a una cadena de ARN mensajero a partir de una cadena de ADN. Ese ARN mensajero (ARNm) pasa por un proceso de traducción en los ribosomas de la célula. Los ribosomas toman codones de ARNm y por cada codón el aminoácido señalado por el codón. El ribosoma va uniendo estos aminoácidos y formando una cadena: la proteína. Posteriormente esa proteína se pliega, según condiciones de temperatura y pH se pliega de una manera o de otra, y según cómo se pliege realizará su función de una manera o de otra, o no la realizará.

En definitiva, este proceso de transcripción y traducción a efectos computacionales no deja de ser una simple sustitución de cada tres caracteres (sin solapamiento) de una cadena de ADN por su caracter correspondiente, si lo hay, que represente un aminoácido. Por ejemplo, la cadena 'ACGGGAGGA' pasa a ser 'TGG'. Las equivalencias entre codones y aminoácidos son casi universales: en todos los organismos son las mismas (la excepción la suponen las mitocondrias y algunos protistas).

Realizar esta traducción en perl es trivial. En el BPfB se presentan tres métodos: uno usa hashes en plan %codigo{'ACG'}='T', los otros dos usan expresiones regulares: if ($codon =~ /UU[CU]/){return 'P';}

El GenBank y el PDB
También toca el tema de las bases de datos que guardan información biológica: el GenBank y el Protein Data Bank, aunque sin profundizar en la interfaz de perl con las bases de datos más allá de los DBMs.

El GenBank es una de las bases de datos donde se almacenan genes. Hay una especificación de formato para los ficheros GenBank, y entre otros datos almacena la posición del gen, la especie a la que pertenece el gen, el ADN del gen, la transcripción de ese ADN y unas cuantas anotaciones más.

El Protein Data Bank guarda información similar pero para las proteínas: qué cadena de aminoácidos, y qué atomos y en qué posición están esos átomos. La posición de esos átomos es muy importante, así como la forma que adquiere la proteína, ya que de ello depende su función. Además determinar esta forma es computacionalmente muy costoso ya que se trata de un problema intratable (aunque en el PDB se obtiene mediante cristalografía de rayos X y resonancia magnética nuclear).

El penúltimo capítulo se dedica a BLAST. BLAST es un programa que sirve para comprobar el alineamiento de distintas secuencias de ADN, y así comprobar la similitud entre las secuencias. Hay varias versiones, hay versiones que comprueban cadenas de nucleótidos con cadenas de nucleótidos, otras cadenas de nucleótidos con aminoácidos, etc. La similitud se comprueba de manera estadística, y de hecho viene comentada en un paper del año 1990.

Comments

Address changed - Reset device now

He adquirido un Bluetooth USB Adapter, es decir, un cacharro USB para conectarme por Bluetooth a otros chismes. Andaba tiempo detrás de uno, desde que empezó todo el tema del bluehacking.

Ayer tarde, cuando llegué con mi flamante Adapter de 17 euros –Conceptronic CBTU2, funciona perfecto en Linux hasta donde he probado– me puse a probarlo y a enredar con él. Al final acabé a las dos de la mañana habiendo leído la mitad del proyecto fin de carrera Seguridad en Bluetooth, de Alberto Moreno.

Uno de los ataques que se describen (dicho sea de paso, en la actualidad muy pocos de ellos son practicables) consiste en suplantar la identidad de otro dispositivo mediante el cambio de la MAC de nuestro adaptador Bluetooth.

Los interfaces Bluetooth tienen asociada una dirección unívoca cada uno de ellos. Bluetooth, de hecho, es el estándar IEEE 802.15 (ethernet es el 802.3, y wireless es el 802.11), por lo que las direcciones de Bluetooth son exactamente iguales que las Ethernet. Se trata de 48 bits, divididos en 24 superiores para indicar el OUI (identificador del fabricante del adaptador), y en 24 bits inferiores, para identificar el dispositivo fabricado por una determinada empresa. El espacio de direcciones se reparte por tanto, entre todas las normas 802.x que requieren direcciones MAC, por lo que no encontraremos un dispositivo Bluetooth con las misma MAC que una tarjeta inalámbrica o una ethernet.

El ataque llamado Blue MAC Spoofing se basa en los niveles de confianza en que se organiza el acceso a los servicios Bluetooth. Según sea el servicio, se podrá acceder tan sólo estando autorizado, o también estando autenticado.

Por estar autorizado se entiende que la MAC de tu adaptador Bluetooth está en la lista de MACs permitidas del receptor. La autenticación implica además el conocimiento de una clave compartida de 128 bits y una clave de sesión (un desafío de 128 bits). A partir de la dirección MAC propia, y esas dos claves se genera una respuesta de autenticación de 32 bits, que sirve para autenticarse ante el otro dispositivo.

Como hay servicios que tan sólo estando autorizados podemos utilizar, podemos dejar que sea otro dispositivo el que pase a ser autorizado, y luego suplantando su identidad, alcanzar su mismo nivel de privilegios. Supongamos un escenario donde una persona (A) le transfiere a otra conocida (B) un fichero (una fotografía, p.ej.). Si para poder hacer esta transferencia se necesita estar autorizado, al comenzar el móvil de B alertará y pedirá permiso para empezar a recibir la transmisión de A. Una vez que se le ha permitido la recepción (A y B son conocidos, y confían entre sí) la MAC de A pasa a la lista de autorizados de B. Si posteriormente cambiamos la MAC de nuestro dispositivo por la de A podremos hacernos pasar por A, heredando sus permisos.

El cambio de MAC se hace con la aplicación bdaddr, y no sé si funciona con todos los adaptadores (con el Conceptronic CBTU2 sí). Esta aplicación pareceser que viene en el paquete bluez-utils, aunque ahora mismo estoy con Debian SID actualizado y el paquete bluez-utils no cuenta con esa aplicación. Me he bajado el fuente de otro lado (aquí y acá) y he montado un .tar.bz2 con (casi) todo lo necesario para que compile el programa. Hay que tener instaladas las cabeceras en /usr/include/bluetooth/, y eso se consigue instalando el paquete libbluetooth-dev. Una vez bajado el bdaddr.tar.bz2, se descomprime y se compila:

pablo@golgi:~$ tar xvjf bdaddr.tar.bz2
pablo@golgi:~$ cd bdaddr/
pablo@golgi:~/bdaddr$ make

Y se ejecuta:

pablo@golgi:~/bdaddr$ ./bdaddr
Manufacturer: Cambridge Silicon Radio (10)
Device address: 00:80:5A:xx:xx:xx

O para cambiar la MAC, como root:

pablo@golgi:~/bdaddr$ sudo ./bdaddr -i hci0 00:80:5a:yy:yy:yy
Manufacturer: Cambridge Silicon Radio (10)
Device address: 00:80:5A:xx:xx:xx
New BD address: 00:80:5A:yy:yy:yy
Address changed - Reset device now
pablo@golgi:~/bdaddr$

Lo de reset device hay que tomárselo al pie de la letra: he tenido que desenchufar y volver a enchufar el adaptador, la orden hciconfig hci0 reset no funcionó.

En principio con eso hemos cambiado la MAC (si hacéis un hciconfig hci0 veréis que ha cambiado). Pero, ¿cómo saber la MAC del dispositivo autorizado? Aún estoy en ello, pero me figuro que a base de hcidump se podrá sniffar el tráfico de la red y determinar qué MACs están autorizadas.

Más interesante aún sería automatizar todo esto de forma que permanentemente se esté analizando el tráfico del entorno, y se determine qué MACs establecen conexiones y son autorizadas.

Update (2007-12-29): Efectivamente con hcidump se puede esnifar el tráfico, pero el tráfico dirigido hacia ti. En Bluetooth no hay nada parecido al modo promiscuo de las tarjetas ethernet. Las tramas de bluetooth van saltando de canal en canal de forma seudoaleatoria. Predecir ese salto son palabras mayores (por lo menos para mí), y disponer de hardware que pueda seguir los saltos también. Lo explican en este hilo de la lista de desarrollo de Bluez. Desde luego esa idea de averiguar qué MACs se comunican con qué MACs es nada factible ahora mismo. De alguna forma hay que conseguir que la víctima se conecte con tú dispositivo bluetooth para hallar su MAC.

Comments (3)

« Previous entries