Coloreando scripts

En bash podemos establecer muchos atributos de pantalla usando las secuencias de escape, incluyendo las negritas, el subrayado, el molesto blink y los colores de background y foreground. También podemos usar el comando tput ¿Qué nos impide usar todo eso para “adornar” nuestros bash scripts?

tput

El comando tput es lo más parecido en bash a las librerías de C ncurses (UNIX) y conio (Win). Permite posicionar el cursor en el lugar que queramos, limpiar la pantalla, cambiar el color del texto o ponerlo en negritas. No permite mayor control sobre el estilo y además solo funciona en terminales con las capacidades necesarias (xterm o terminales X, lo podemos comprobar mirando el contenido de la variable de entorno $TERM), excepto el control del cursor en columnas, que funciona en todo tipo de terminales (no así en filas). A cambio, es fácil de usar y los comandos que requiere son sencillos.

Un ejemplo. La salida del siguiente script (si no reconoces la sintaxis del bucle for échale un ojo a esto):

#!/bin/bash         

for ((i=0;i<9;i++))
        do
                tput setf $i
                echo -e Color asociado a $i
        done         

tput sgr0

Sería algo así:

El color asociado a tput setf 0 no se ve porque es el negro.

Secuencias de escape

Las secuencias de escape son un poco más complicadas de escribir pero, como suele pasar, nos dan un mayor control ya que establecen atributos de pantalla, no de terminal, por lo que funcionan también en terminales “no X” (osea, la shell). La desventaja es que, en terminales X, pueden no comportarse como se espera, por lo que la portabilidad se ve algo comprometida.

Un listado exhaustivo de las secuencias disponibles las podeis encontrar en este capitulo de la Advanced Bash-Scripting Guide. Como muestra, un botón. Un botón con sorpresa :D

Descarga este archivo (es texto plano, lo siento, no sirve un copipaste por las secuencias especiales). Luego hazle un cat ;)

:wq

Por ~aKira~ el Sábado 29 de Marzo de 2008 a las 11:03 | Categoría: Programación
4 comentarios

Trasteando con el protocolo TCP/IP

Cuando te gusta en serio la informática, y más concretamente el tema de redes, antes o después terminas enfrentándote con el protocolo TCP/IP. En mi caso fue antes, hace años, gracias a una magnífica serie de tutoriales publicados por la (difunta) revista HackXCrack. Tutoriales que, gracias a alguien que se entretuvo en escanear estas revistas y subirlas a la red, aun releo de vez en cuando.

El caso es que teniendo una idea clara de cómo funciona esta familia de protocolos, y con alguna pequeña ayuda, podemos hacer algunas “guarradas” (no de ese tipo, degenerado! ¬¬). Veamos cómo podemos generar paquetes TCP/IP a la carta y de qué nos pueden ser de utilidad :)

Gspoof

Gspoof (en cuya página de proyecto deberían añadir algunas ‘@’ al código PHP) es un generador de paquetes TCP/IP. Corre en modo consola o en GTK+ y nos permite configurar, como debe ser, cualquier number o flag del paquete. No es tan completo como Némesis, pero es desde luego mi preferido.

Némesis/jNémesis

Némesis es sin duda la packet injection suite más completa. Genera e inyecta paquetes TCP, UDP e ICMP, además de “encolar” (queue) paquetes.

Aunque la versión UNIX de Némesis funciona en línea de comandos, hay una excelente interfaz gráfica escrita en Java (es un proyecto parado desde 2004): jNémesis, que hace su uso intuitivo a más no poder. Aquí hay un vídeo-tutorial en flash sobre su uso.

TTpU

Quiero nombrar también, aunque sólo sea de pasada, a TTpU. De pasada digo porque no es open source, sólo está disponible el binario para descarga. Y porque tampoco aporta nada más, estando los que ya he nombrado…

¿Y qué hacemos con esto?

Generar paquetes TCP/IP “a medida” tiene muchas utilidades: evasión de cortafuegos, de IDS’s, IP spoofing… aunque voy a nombrar algunos de los más básicos. Si te interesa el tema y quieres profundizar, ya sabes, toca leer muuucho.

Escaneos syn y connect

El concepto de syn scan es muy simple. Mandamos un paquete con el flag SYN levantado al host remoto a un puerto determinado. Si el puerto está cerrado deberíamos recibir un paquete con los flags RST y ACK levantados. Si en cambio no recibimos nada podemos sospechar que el puerto está filtrado (firewalled).

Si queremos hacer un connect scan tenemos que intentar establecer una conexión mandando un paquete SYN. Si el puerto remoto está abierto recibiremos un paquete SYN y ACK envíado por el host remoto.

Aprovecho este tema de los tipos de escaneo para recomendar encarecidamente el magnífico tutorial Sabuesos en la red de Death Master.

Ataques DoS

Con un spoofer (como también son llamados este tipo de programas) podemos “comprobar” vulnerabilidades en los sistemas operativos (naturalmente, de un host remoto :P). Por ejemplo, sabemos que podemos provocar un DoS en un sistema Windows XP SP2 con el firewall desactivado si le enviamos un paquete spoofeado que declare un mismo host y puerto de origen y de destino. Y, como lo sabemos, queremos comprobarlo in situ. Ejem.

Como ya he dicho, hay técnicas mucho más avanzadas, como el IP spoofing, el firewalking, etc. A leer tocan ;)

:wq

Por ~aKira~ el Domingo 23 de Marzo de 2008 a las 12:20 | Categoría: Hacking, Software
9 comentarios

BlueScan: 36.000 descargas

Hace un par de años, fruto de una tarde de aburrimiento y de lectura sobre el protocolo Bluetooth, comencé a escribir una pequeña aplicación, BlueScan, un escáner para dispositivos Bluetooth.

Es, como digo, una aplicación pequeña, pero muy útil, con la ventaja sobre otras de su tipo de que es ligera, eficaz y al ser sólo un bash script no tiene complicaciones de instalación. Que cumple su papel, vamos. Así que me decidí a compartirla, y hace un año subí el proyecto a Sourceforge (donde se llama Bluescanner, ya que había otro proyecto llamado Bluescan).

El caso es que anoche me llevé una grata sorpresa: el proyecto ha superado ya las… 36.000 descargas!! :D

Lo mejor es que la tendencia es al alza, con más de 5000 descargas al mes en este año (la escala de la izquierda indica miles de descargas). Todo un subidón para el ego, vamos :D

Y para eso era este post, sólo para seguir alimentando mi ego ;)

:wq

Por ~aKira~ el Miércoles 12 de Marzo de 2008 a las 14:22 | Categoría: Vida de un debianita
3 comentarios

Lenny will be shipped as Debian 5.0

Así como suena lo anunció ayer Marc Brockschmidt, ayudante de versiones (como podeis ver en el organigrama de Debian): Debian Lenny será la versión 5.0.

No sólo eso, que al fin y al cabo así, sin más, es poco. Dijo también que, si KDE 4.1 está listo a tiempo, será incluido en esta versión. Que así sea! :D

:wq

Por ~aKira~ el Lunes 3 de Marzo de 2008 a las 14:39 | Categoría: Mundo Debian
1 comentario

Linux en Wii: vía libre

Hace algunos días nos alegramos con el descubrimiento del exploit del Zelda, que permite ejecutar código sin firmar en la Wii, lo que abría el camino al homebrew en esta consola.

Pues bien, entre esa noticia y este wii-linux Proof of Concept 0.1 no ha pasado ni un mes. La cosa promete :D

:wq

Por ~aKira~ el Domingo 2 de Marzo de 2008 a las 20:04 | Categoría: Vídeos, /dev/urandom
1 comentario

bootchart: Tiempos en el arranque

Sesenta y dos segundos. Es lo que tarda mi portátil (que ya empieza a quedarse viejo) desde que lo enciendo hasta que gdm está listo para recibir el login (sí, soy kdeero acérrimo pero kdm me parece la cosa más fea del mundo mundial). Un minuto y pico en el que no puedo hacer absolutamente nada, excepto esperar, con el colmillo goteando, a que mi Debian esté listo. Y qué coño, yo soy un impaciente, así que me parece una eternidad. ¿Se puede mejorar ese tiempo? ¿En qué lo usa la máquina?

bootchar es una aplicación que nos permite saber qué tiempo lleva cada uno de los procesos que se ejecutan durante el arranque, en qué secuencia, cuántos procesos hay activos en cada momento… En una palabra, nos destripa el arranque del sistema y para colmo nos lo presenta en un bonito gráfico :)

Para ello necesitamos sólo tres paquetes: bootchart, bootchart-view y acct. Es éste último el que proporciona al daemon de bootchart (bootchartd) las estadísticas de ejecución de cada proceso.

bootchartd se ejecuta en el mismo momento en que se monta /proc, y desde entonces hasta el fin del arranque colecta todos los datos que acct le proporciona, guardando los logs finales en /var/log/bootchart.tgz. Si descomprimimos los logs veremos que, aparte del archivo header (que guarda los datos sobre el sistema, el procesador y las opciones pasadas al kernel) no entendemos una leche. Sin embargo, el mismo programa se ocupará de generarnos un bonito gráfico entendible por aquellos que no contamos ovejitas en binario para dormirnos.

Para que el daemon se ejecute durante el arranque debemos pasar la opción a GRUB o a LILO en el append del loader con un init=/sbin/bootchartd. Es de lo único que nos tenemos que preocupar. Cuando queramos ver las estadísticas sólo tenemos que ejecutar bootchart para que genere el gráfico correspondiente. Por defecto genera un PNG en nuestro $HOME, aunque también puede generar un gráfico vectorial (SVG). Se pueden ver las opciones con bootchart -h. El resultado es algo así:

:wq

Por ~aKira~ el Domingo 2 de Marzo de 2008 a las 12:16 | Categoría: Software
Dejar un comentario

Fin del soporte de seguridad para Debian 3.1 Sarge

Pues nada, que todo llega y todo pasa. Y Sarge ya pasó. Ayer se anunció el fin del soporte de seguridad para Debian Sarge.

A partir del día 31 de este mes, casi tres años después de su liberación como stable, acabarán las actualizaciones de seguridad para la versión 3.1. En realidad supongo que no importa demasiado, ya que tenemos los ojos puestos en Lenny, que se espera para finales de este año o principios del que viene. Esperemos que no se haga de rogar como se hizo Etch.

:wq

Por ~aKira~ el Sábado 1 de Marzo de 2008 a las 22:21 | Categoría: Mundo Debian
4 comentarios

eMovix: Películas bootables

eMovix es una LiveCD pensada para reproducir automáticamente contenido multimedia: arranca, ejecuta MPlayer, y reproduce los vídeos (también música) que haya en el directorio raíz. Los archivos de eMovix sólo ocupan 8 megabytes, dejando el resto de espacio en el CD/DVD para archivos multimedia.

Lo mejor de todo es que podemos instalar eMovix en nuestro sistema Debian para, usando K3b, crear nuestros propios CDs y DVDs eMovix. No está en ningún repositorio (que yo sepa), pero el paquete DEB se puede descargar de la página del proyecto en SourceForge. Después sólo hay que indicar a K3b la ruta al ejecutable movixmaker-2 (Herramientas -> Configurar K3b -> Programas -> Buscar):

Desde ese momento tenemos ya disponible la opción de crear CDs y DVDs eMovix con K3b:

:wq

Por ~aKira~ el Sábado 28 de Julio de 2007 a las 11:55 | Categoría: Distros, Software
13 comentarios

Xinerama: Sistemas multipantalla con GNU/Linux

Un sistema multipantalla es, como su propio nombre indica,aquél que utiliza más de un monitor a la vez para la salida de vídeo. Dicho así parece una perogrullada. Verlo en acción es acojonante, sobre todo si lo combinamos con los escritorios de última generación (no me hago responsable del daño que la “banda sonora” del vídeo pueda causar al cerebro del espectador):

Quieres uno como ese, ¿verdad? Yo también. Y, tras la mudanza, cuando mi “sala de control” vuelva a estar en todo lo suyo (qué triste es apagar uno a uno todos los equipos y meterlos en cajas de cartón…) será lo primero que haga. Veamos cómo puede hacerse.

Lo primero que hace falta es, evidentemente, disponer de los dispositivos de salida adecuados. Una tarjeta gráfica medianamente aceptable tiene dos salidas de vídeo (VGA/DVI). La alternativa, si tenemos una AGP con una sola salida, es poner una PCI. Lo que no nos va a servir es, si le hemos puesto una gráfica al equipo, usarla junto con la onboard. La BIOS se encarga de anular esta última y, a no ser que nos dé opción de usar las dos (poco habitual), para el sistema será como si la tarjeta onboard no existiese.

Ahora que tenemos dos salidas de vídeo (o tres, o cuatro) y dos monitores (o tres, o cuatro) nada nos impide montarnos algo así:

Esto lo podemos conseguir gracias a Xinerama, una extensión del X Window System disponible desde la versión X11R6.4 (1998) que permite precisamente eso, que los gestores de ventanas y las aplicaciones puedan usar más de una pantalla a la vez. Y para eso hay que ensuciarse las manos: configurando, que es gerundio.

Lo primero es tener claras las cosas. Empezando por la terminología. En el sistema X Window, un device es una salida de vídeo, un monitor es lo que en español llamamos monitor (somos así de chulos), mientras que una screen es una combinación de device y monitor. Conclusión: debemos añadir a nuestro xorg.conf una nueva Section “Device”, una nueva Section “Monitor” y una nueva Section “Screen”.

Pero lo primero es lo primero, y lo primero es activar Xinerama:

Section “ServerFlags”
Option “Xinerama”
EndSection

Ahora sí, vamos al lío de verdad. Empezamos por las Section “Device”. De primeras tenemos una. La mía, por ejemplo, es ésta:

Section “Device”
Identifier “Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller”
Driver “i810″
BusID “PCI:00:02:0″
VideoRam 65536
Option “UseFBDev” “False”
Option “RenderAccel” “True”
Option “AllowGLXWithComposite” “True”
EndSection

Lo que hacemos es añadir una segunda, teniendo en cuenta ciertas cosas. Como por ejemplo, que cada una debe tener un Identifier único. Si estamos usando una sóla tarjeta con dos salidas lo correcto es que echemos mano de la opción BoardName para poner lo de Intel Corporation Mobile… y en Identifier les pongamos, por ejemplo, DVI a una y VGA a la otra. Al gusto.

Si son tarjetas distintas (una AGP y una PCI o dos PCI) debemos cuidar de poner el BusID correcto para cada una de ellas. Lo podemos ver tirando de lspci.

Finalmente, tenemos que asignar un número de Screen a cada una de ellas, comenzando, cómo no, por el cero. Podría quedar así:

Section “Device”
Identifier “Widescreen”
BoardName “Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller”
Driver “i810″
BusID “PCI:00:02:0″
VideoRam 65536
Option “UseFBDev” “False”
Option “RenderAccel” “True”
Option “AllowGLXWithComposite” “True”
Screen 0
EndSection

Section “Device”
Identifier “VGA”
BoardName “Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller”
Driver “i810″
BusID “PCI:00:02:0″
VideoRam 65536
Option “UseFBDev” “False”
Option “RenderAccel” “True”
Option “AllowGLXWithComposite” “True”
Screen 1
EndSection

Seguimos con los monitor. Nada destacable, excepto cuidar de poner a cada uno sus tasas correctas de HorizSync y de VertRefresh y, de nuevo, de que los Identifier sean distintos.

Lo mismo para las screen. Debemos definir, para cada una, uno de los monitor y uno de los device que hemos configurado:

Section “Screen”
Identifier “Derecha”
Device “VGA”
Monitor “Compaq-V55″
DefaultDepth 24
SubSection “Display”
Depth 24
Modes “1024×768″ “800×600″ “640×480″
EndSubSection
EndSection

Y como todo llega al final, llegamos nosotros también diciéndole al servidor X cómo tiene que colocar las screen. Dentro de la sección Section “ServerLayout” añadimos:

Screen 0 “Izquierda”
Screen 1 “Derecha” RightOf “Izquierda”

Hora de reiniciar las X:

invoke-rc.d [gdm|kdm|xdm] restart

Si todo ha ido bien, ya tenemos rulando el sistema multipantalla. Si no, tocará repasar los logs del servidor X (/var/log/Xorg.0.log) a ver en qué la hemos cagado. Lo cierto es que si las cosas salen bien a la primera, el resultado no se disfruta igual ¿verdad? :D

:wq

Por ~aKira~ el Sábado 28 de Julio de 2007 a las 10:31 | Categoría: Vídeos, How To
5 comentarios

Debian Unofficial

Me acabo de enterar, gracias a Viva Linux, de la existencia de los repositorios Debian Unofficial.

Debian Unofficial son repositorios para software que, por diversas causas (licencias restrictivas, no inclusión de código fuente, etc) no incluye Debian en sus repositorios oficiales. Paquetes como adobe-reader, opera, wink, flash-player, libdvdcss2 (también disponible en debian-multimedia), etc.

Como siempre al añadir un repositorio, tenemos que importar la clave:

gpg --keyserver wwwkeys.eu.pgp.net --recv-key D5642BC86823D007

gpg: requesting key 6823D007 from hkp server wwwkeys.eu.pgp.net
gpg: key 6823D007: public key “Debian Unofficial Archive Automatic Signing Key (2006) [ftpmaster]” imported
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 17 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 17u
gpg: next trustdb check due at 2009-07-01
gpg: Total number processed: 1
gpg: imported: 1

gpg --armor --export D5642BC86823D007 | sudo apt-key add -

OK

:wq

Por ~aKira~ el Miércoles 25 de Julio de 2007 a las 14:11 | Categoría: Mundo Debian
2 comentarios