Windows XP más rápido = servicios necesarios

Windows XP, como cualquier otro sistema operativo viene por defecto con una serie de servicios que se inician automaticamente cuando el ordenador arranca. Dependiendo del uso que demos al ordenador utilizaremos algunos y otros no.

En este post, explicaré algunos servicios de Windows XP, comprobaremos si los necesitamos o no, y los que no necesitemos los desactivaremos. El resultado será el ahorro de recursos y el incremento de la rapidez de Windows XP, tanto en arranque como en el uso normal.

Lo primero que haremos es abrir el gestor de servicios y ver lo que hay. Para ello vamos a inicio, ejecutar y ponemos: services.msc, pulsamos ENTER y aparecerán los servicios. Para verlos mejor, maximizamos la ventana y pinchamos abajo en la pestaña "Estándar".

La columna interesante es Tipo de inicio. Si ordenamos los servicios por Tipo de inicio los veremos mejor. Hay tres tipos de inicio:

• Automático: siempre inicia el servicio en el arranque de Windows.
  
  
• Manual: se inicia a demanda. Normalmente lo inicia otro servicio ya iniciado, como por ejemplo alguno que ya se inicie de forma automática.
  
  
• Deshabilitado: nunca se inicia.
  

Podemos cambiar el tipo de inicio de un servicio dado, además de iniciarlo o detenerlo haciendo doble click izquierdo en él e indicando lo que queremos.

A continuación voy a explicar algunos de los servicios de Windows XP SP3 Profesional que podemos tocar sin problemas, y así averiguamos si los necesitamos o no:

Acceso a dispositivo de interfaz humana: Si tienes un teclado con botones multimedia tipo volúmen, enviar correo, hacer la colada, etc., déjalo en automático. Si tienes un teclado convencional y no utilizas este tipo de controles multimedia, lo puedes detener y deshabilitar.

Actualizaciones automáticas: es recomendable que esté en automático sino quieres que tu Windows se convierta en un colador.

Administrador de IIS: si tienes un servidor Web, o ftp, o alguna aplicación que utilice IIS (Internet Information Server) déjalo en automático. Si utilizas otro servidor web como Apache o Tomcat, lo puedes desactivar. Si lo anterior te suena a chino, desactívalo.

Administrador de sesión de Ayuda de escritorio remoto: esto sirve para que un amigo tuyo se conecte a tu ordenador y te ayude con algún problema. Desactívalo sino necesitas ayuda on-line.

Adquisición de imágenes de Windows (WIA): si tienes un escáner o cámara conectado al ordenador, déjalo en automático, sino, lo puedes desactivar.

Agente de Protección de acceso a redes: el servicio NAP, una capa nueva extra de seguridad que Microsoft sacó ya con Windows Vista y Windows 2008. Tiene sentido en una red local de ordenadores donde queremos más seguridad. En entornos corporativos donde la seguridad es un factor crítico entre ordenadores y servidores no estaría mal. En el caso doméstico no le veo utilidad y puede desactivarse.

Ayuda y soporte técnico: por la utilidad que he visto en este servicio, es mejor desactivarlo.

Configuración inalámbrica rápida: si tu ordenador tiene WIFI, déjalo activado, sino, desactívalo.

DDE de red: otro servicio para dar seguridad al transporte de datos en determinadas aplicaciones (nunca he visto una aplicación que utilice este servicio). No es necesario para compartir carpetas en una red local, por tanto se puede desactivar.

DSDM de DDE de red: más de lo mismo que el servicio anterior. 

Enrutamiento y acceso remoto: desactívalo. Un router es un router, y un Windows es un Windows.

Escritorio remoto compartido de NetMeeting: esto es una cosa parecida a la asistencia remota, pero utilizando NetMeeting. Sino te suena, desactívalo.

Instantáneas de volumen: si utilizas el sistema de copia de seguridad propio de Windows, puede ser útil, sino, desactívalo.

Machine Debug Manager: si te dedicas a analizar volcados de memoria cuando algo revienta, es hasta necesario. Si lo anterior te suena a chino, desactívalo.

Mensajero: esto tiene sentido en la oficina cuando el administrador de sistemas necesita alertar de algo a los usuarios. A nivel doméstico no tiene sentido.

MS Software Shadow Copy Provider: esto es lo mismo que el servicio de Instantáneas de volumen.

Programador de tareas: si necesitas hacer algo de forma automática de vez en cuando, tiene sentido, sino, desactívalo.

Publicación en World Wide Web: igual que el Administrador de IIS.

Servicio de alerta: igual que el servicio Mensajero, pero en vez de que la alerta la realice el administrador de sistemas la realiza alguna aplicación en respuesta a algún evento. En entorno doméstico no tiene sentido.

Servicio de Index Server: dice que mejora la velocidad de las búsquedas de archivos en Windows, pero yo no he visto ninguna mejora significativa. Lo puedes desactivar perfectamente.

Servicio de restauración de sistema: yo lo he probado en varios contextos, y es mejor tener una copia de seguridad de nuestros archivos que no pueden perderse fuera del ordenador, por ejemplo en un disco duro externo. Además, es un nicho de virus. Mejor desactivado.

Servicio de uso compartido de red del Reproductor de Windows Media: si utilizas Windows Media Player junto con aparatos reproductores externos, puede servir para que compartan datos entre si (esto es como el itunes y el ipod pero en plan Windows), sino, desactívalo.

Servicio del número de serie de medio portátil: íntimamente ligado al servicio anterior.

Servicios de Terminal Server: si quieres conectar con el escritorio de otro ordenador en red, bien, sino, desactívalo.

Servicios IPSEC: este servicio de cifrado de red tiene sentido en comunicaciones cifradas entre servidores de archivos confidenciales. En entornos domésticos no tiene sentido.

Sistema de alimentación ininterrumpida: si tienes un SAI conectado al ordenador y quieres mirar su estado con el mismo Windows, bien. Si tu SAI ya dispone de software para esto, o no tienes un SAI, desactívalo.

Tarjeta inteligente: esto se utiliza en caso de que algún programa necesite leer tarjetas de identificación, para temas de seguridad. Sino tienes alguna tarjeta de estas, puedes desactivarlo.

Telnet: si te gusta la línea de comandos con conexión remota y la inseguridad, pues vale, sino desactívalo.

Temas: Windows más bonito. Si lo desactivas, se queda con los gráficos en plan Windows 95, y ten por seguro que Windows irá más rápido.

Como dije, el resto de servicios suelen ser más necesarios y están más vinculados con el funcionamiento de Windows, aunque puedes probar a desactivar alguno a ver que pasa.

Si dejamos activos sólo los servicios que utilizamos y deshabilitamos los que no utilizamos, tendremos una mejora significativa en rapidez, que si por contra dejamos los servicios configurados por defecto.

Ejecutable ¿o no?, esa es la cuestión

Que un archivo comience con los bytes "4d5a" (hexadecimal), no es casualidad. Se trata de un archivo ejecutable de cualquier sistema operativo de Microsoft.

Concretamente estamos hablando del comienzo de la cabecera PE (Portable Executable), que identifica a los archivos ejecutables de MS-DOS también soportados por compatibilidad en las versiones de los ejecutables posteriores de Windows. Disponemos de más información acerca de la estructura de la cabecera PE aquí y aquí.

Las extensiones de los nombres de los archivos ejecutables de Windows son muchas, las más conocidas son .EXE, (el de toda la vida), .DLL (librerías dinámicas) y los .SYS (Drivers). Menos conocidas son .CPL y DPL. En cualquier caso, todos estos tipos de archivos comienzan con los bytes mencionados y tienen la capacidad de ejecutar código en el sistema, para bien y para mal.

Entrando en el contexto de la seguridad, lo normal es que un archivo ejecutable tenga una extensión como las que hemos visto, como EXE, y lo extraño es encontrar un archivo que por su nombre/extensión no parezca ejecutable y su contenido sí lo sea.

Muchos virus utilizan archivos con extensión .TMP (temporal) para alojarse en ellos y "despistar" al observador. Ahora, su contenido comienza con "4d5a", y digo .TMP como si se trata de cualquier otra extensión que no parezca ser un ejecutable, o simplemente que no tenga extensión. Si no nos percatamos de este detalle, el .TMP de turno puede ser abierto por cualquier otro proceso y ejecutarlo... y en ese caso tenemos papeletas para el premio.

Para saber si existe en nuestro sistema algún archivo que por su extensión no denote "ejecución", he preparado un script en perl. Este script trabaja sobre archivos que NO tengan las extensiones típicas de los ejecutables (exe, dll, sys, drv, ocx, com, cpl, dpl) para comprobar si el contenido comienza con "4d5a". Si el script detecta estos bytes al inicio del archivo, indica la ruta y el nombre del archivo en cuestión. En estos casos, habría que buscar información de la extensión de este archivo y comprobar de qué se trata.

Este script da la opción de realizar esta búsqueda en toda la unidad C: incluyendo todos sus subdirectorios (tarda un buen rato), y también da la opción de realizar esta búsqueda en el directorio actual. En ambos casos, el resultado lo dejará en el archivo resultados.txt del directorio donde se ejecute el script.

He pasado este script en tres ordenadores con Windows XP SP3, y no podeis imaginar la cantidad de archivos que existen, que no parecen ejecutables, y sí lo son. En próximos posts intentaré dar más información acerca de este tipo de extensiones como ax, flt, mui, wpc, etc.

El script está disponible en este enlace.

Protege los drivers de tu Windows, y 2

El script del post anterior sólo trabaja con MD5: crea MD5 de los drivers actuales a un archivo (drivers.md5) y también puede comprobarlos en un futuro.

Pero le falta una cosa importante: si hay drivers nuevos no los procesa porque toma como referencia el archivo drivers.md5, y en base a su contenido comprueba si existe el driver correspondiente en el sistema, sin realizar un recorrido en éste. Por tanto, sólo procesa los que tiene en drivers.md5 ignorando los nuevos que pudieran existir. Esta funcionalidad es crítica y necesaria puesto que necesitamos saber si algún driver ha sido instalado en el sistema desde la última "foto" que le hicimos.

Para ofrecer esta nueva funcionalidad, he ampliado el script dando una opción más que es: Comprobar drivers nuevos. Además, como ahora he utilizado contadores para contar tanto los drivers en drivers.md5 como en el sistema, los resultados en general se han ampliado.

Como los cambios son significativos respecto al script anterior, a éste lo he llamado control-drivers.pl y su versión es la 1.0.

Y para evitar erratas producidas por blogger, el nuevo script se encuentra en este enlace.

Protege los drivers de tu Windows

En base al trabajo del post anterior, podemos eliminar los drivers que no utilizamos, y si el resto es de confianza, podemos controlarlos haciéndolos una foto con MD5 para después compararlos con la realidad. De esta forma sabremos si alguno es modificado.

El sentido de esto es saber cuando queramos si estos archivos (de confianza) han sido alterados o no, comparándolos con sus MD5 antes generados. Así, si instalamos una versión nueva de un driver, o si Windows Update lo hace, lo podremos confirmar. Y si ha habido algún cambio sin que nosotros lo sepamos, pues puede ser un virus.

Para ello, realizaremos un script con perl con un menú donde podamos elegir realizar el MD5 de los drivers, que son los archivos que tengan extensión .SYS, o .sys, o, Sys (perl distingue entre mayúsculas y minúsculas), que se encuentren tanto en system32 como en system32\drivers y guardarlo en un archivo de texto.

La segunda opción tendrá sentido a futuro, cuando comparemos los MD5 de los drivers actuales con los guardados (la foto) . Si no hay ningúna discrepancia, el script no dará ningún resultado, y si la hay, indicará cual es el driver afectado.

------------- Comienzo md5-drivers.pl -------------------------------

# Generación y comprobación de los MD5 de los drivers de Windows
# ramiro.encinas@gmail.com - 2009
# Tuya es la responsabilidad del buen o mal uso de este script

use Digest::MD5::File qw(file_md5_hex); # Cargamos el módulo MD5 para archivos

sub menu # El menú con las tres opciones
{
print "\nControl de drivers. Elige opcion:\n";
print "-------------------------------------\n";
print "- [1] Generar MD5 de los drivers en $file_out\n";
print "- [2] Comparar los MD5 de los drivers con el de $file_out existente\n";
print "- [3] Salir\n";
print "->";
}

sub genera # Procesa los MD5 de los drivers actuales en ambas ubicaciones
{
open f_out, ">$file_out"; # Abre para escritura a drivers.md5

$path = $path1; # Procesa la primera ubicación
busca($path); # Y llama a la función correspondiente para generar los MD5

$path = $path2; # Procesa la segunda ubicación
busca($path); # Y llama a la función correspondiente para generar los MD5

close f_out; # Cierra drivers.md5
print "Archivo $file_out generado ok.\n";
}

sub busca # Busca drivers en ubicación, genera MD5 y los guarda en drivers.md5
{
opendir DIRECTORY, $path or die; # Abre la carpeta $path (la ubicación actual)

# Recorre $path y deja en $file cada nombre de archivo

while ($file = readdir(DIRECTORY)) # Leemos todos los archivos de la ubicación
{
if ( -d $path.$file ){# $file es un directorio
}
else # $file es un archivo (porque puede un directorio)
{
if ($file =~/.[sS][yY][sS]$/) # Sólo *.SYS (mayus y minus).
{
$md5 = file_md5_hex($path.$file); # Calcula el MD5 de $file
print f_out "$path$file\:\:$md5\n"; # Escribe en drivers.md5 path+archivo+::+md5
}
}
}
}

sub compara # Compara los MD5 actuales con los guardados en drivers.md5
{
open f_in, $file_out or die "No puedo abrir $file_out"; # Abre drivers.md5

while () # Leemos línea a línea hasta la última
{
chomp $_; # Quitamos el fin de línea
$_ =~ /(.*)::/; # Extrae el nombre del archivo (path incluido) de drivers.md5
$f = $1; # y lo pone en $f

$_ =~ /::(.*)/; # Extrae el MD5 del archivo de drivers.md5
$md5 = $1; # y lo pone en $md5

$md5_actual = file_md5_hex($f); # Generamos el MD5 del driver actual

# Y comparamos. Si hay discrepancia la pone, sino, no la pone

if ($md5 ne $md5_actual){print "\nCuidadito, el MD5 de $f no coincide.\n";}
}
close f_in; # Cerramos drivers.md5
}

sub principal # Empezamos aquí
{
$path1="C:\\WINDOWS\\system32\\"; # Primera ubicación de los drivers
$path2="C:\\WINDOWS\\system32\\drivers\\"; # Segunda ubicación de los drivers
$file_out = "drivers.md5"; # Nombre de archivo donde se guardarán los MD5 actuales

menu(); # Llama al menú
while ($opcion=) # Espera opción desde el teclado para meterla en $opcion
{
chomp $opcion; # Elimina el fin de línea
if ($opcion == 1){genera($path1,$path2);exit;} # Llama a sub genera
elsif ($opcion == 2){compara($file_out);exit;} # Llama a sub compara
elsif ($opcion == 3){exit;} # A la calle
else {$opcion = NULL;menu();} # Sino hay opción válida, volvemos.
}
}

principal(); # Esta es la primera función que se ejecuta

-------------- Final md5-drivers.pl -------------------------------

AVISO: Debido a que blogger elimina los símbolos mayor menor que, a este script le faltan algunas cosas para funcionar. El script completo puedes verlo y descargarlo en este enlace.

Perl, MD5 y los drivers sospechosos de Windows

En Windows, los drivers que normalmente están alojados en

c:\windows\system32 y

c:\windows\system32\drivers,

pueden ejecutarse en el espacio de memoria del núcleo y por tanto, pueden hacer lo que quieran en el sistema. Estos archivos suelen tener la extensión .sys, y normalmente no se les presta atención.

Hay drivers que ya los pone Windows, otros se alojan ahí cuando instalamos algún dispositivo, y hasta hay programas que también dejan ahí su .sys para hacer cosas. Los virus también los utilizan para sus cometidos, y con más frecuencia que lo que creemos.

Se inicie el driver o no al encender el ordenador dependerá si el driver es llamado desde el registro. Para ver esto, aconsejo autoruns de Sysinternals.

A veces es difícil saber si un .sys es de fiar o no, aunque consultemos en la red. Una forma de averiguarlo es, si sospechamos de alguno, crear una carpeta en la misma carpeta donde se aloja el driver y moverlo ahí. Después reiniciamos y a ver que pasa. Si hemos movido un driver crítico del sistema, seguramente nos toque arrancar con un live-cd y volver a poner el driver en su ubicación original. Sino ocurre nada, podemos esperar a ver que pasa, y si sigue sin pasar nada, pues lo mismo ese driver no se usa.

Si da la casualidad de que hemos movido un driver que es utilizado por algún virus u otro programa malicioso, es posible que, si el virus está en memoria, lo vuelva a crear incluso con otro nombre, y aquí es donde entra el

MD5

El MD5 de un archivo es un resumen del contenido del archivo y además es único para ese archivo. Lo bueno es que ese resumen sólo ocupa 32 dígitos hexadecimales (128 bits), ocupe lo que ocupe el archivo. De esta forma, con estos 32 dígitos podemos verificar la integridad de un archivo.

Si hemos apartado los drivers sospechosos a una carpeta llamada "sospechosos", podemos calcular el MD5 de cada uno y crear un archivo de texto donde cada línea tendrá el nombre del archivo y su MD5. Después, si alguno de estos drivers sospechosos es el resultado de un virus y éste vuelve a crear el driver, aunque sea con otro nombre, para identificarlo podemos comparar los MD5 sospechosos que contiene nuestro archivo de texto con los MD5 de los archivos de las carpetas de sistema de Windows (system32 y system32\drivers) hasta que salte la coincidencia. Si el nuevo driver tiene otro nombre y el mismo MD5, se trata de un virus seguro.

Entrando en harina

Primero vamos a hacer un pequeño script en perl llamado md5.pl para sacar los MD5 de un archivo dado:

------- comienzo md5.pl -----------------------------------------------
# ramiro.encinas@gmail.com - 2009
# Tuya es la responsabilidad del buen o mal uso de este script

use Digest::MD5::File qw(file_md5_hex);

if ($ARGV[0]) {$archivo = $ARGV[0];}
else {print "\n";print "Sintaxis: perl md5.pl nombre_archivo.\n";exit;}

if ( -e $archivo )
{
    $md5 = file_md5_hex($archivo);
    print "\n";print "El MD5 de $archivo es: $md5\n";
}
else {print "\n";print "Sintaxis: perl md5.pl nombre_archivo.\n";exit;}
------- fin md5.pl ----------------------------------------------------

Con este script podemos sacar los MD5 de los archivos sospechosos. Después, en la carpeta de trabajo, creamos un archivo de texto llamado drivers-sospechosos.txt, donde cada línea contendrá cada nombre de archivo sospechoso y su MD5 correspondiente. Para separar el nombre del archivo y su MD5 utilizaremos "::" como vemos en este ejemplo:

data.sys::ee2f07a2d1f81e2f5a8a454f61d9395a

Cuando tengamos drivers-sospechosos.txt lleno con los archivos (drivers) sospechosos y sus MD5, y además tengamos movidos dichos archivos a la carpeta "sospechosos", podemos esperar unos días y ejecutar el siguiente script que realizará la búsqueda-comprobación:

------- comienzo drivers-sospechosos.pl ----------------------------------------

# Los drivers sospechosos de c:\windows\system32 y c:\windows\system32\drivers
# han sido movidos a la carpeta "sospechosos" que está en la misma carpeta donde
# estaba el driver sospechoso.

# Cada uno de los nombres de estos drivers sospechosos junto con su MD5 están en
# una línea de drivers-sospechosos.txt, y éste archivo está en la carpeta de trabajo.

# Este script busca los MD5 de los archivos de drivers-sospechosos.txt
# en c:\windows\system32 y c:\windows\system32\drivers
# para comprobar si existe alguna coincidencia.

# Este script asume que la carpeta de trabajo es 
# C:\WORKSPACE\drivers-sospechosos 
# y que dentro está el archivo drivers-sospechosos.txt con los nombres y MD5 
# de los archivos sospechosos, uno por línea y este mismo script, claro.

# Este script también asume que por cada línea de drivers-sospechosos.txt hay
# un nombre de driver sospechoso, una separación "::" y su MD5.

# ramiro.encinas@gmail.com - 2009
# Tuya es la responsabilidad del buen o mal uso de este script

use Digest::MD5::File qw(file_md5_hex);

# Ubicación del archivo con los archivos sospechosos

$path_filein = "C:\\WORKSPACE\\drivers-sospechosos\\drivers-sospechosos.txt";

# Función principal

sub todo 
{
    # Apertura drivers-sospechosos.txt
    open f_drivers, $path_filein or die "No puedo abrir $path_filein";
    $c = 0; #Número de coincidencias
 
    while( ) # Abro drivers-sospechosos.txt y lee línea a línea
    {
        chomp $_; # Quita el fin de línea, que si se queda esto no funciona
  
        $_ =~ /(.*)::/; # Extrae el nombre del archivo 
        $filein = $1; # y lo pone en $filein
  
        $_ =~ /::(.*)/; # Extrae el MD5 del archivo 
        $fileinmd5 = $1; # y lo pone en $md5
  
        $path = "C:\\WINDOWS\\system32\\"; 
        proceso($path,$filein,$fileinmd5); # Búsqueda en system32
  
        $path = "C:\\WINDOWS\\system32\\drivers\\";  
        proceso($path,$filein,$fileinmd5); # Búsqueda en drivers
    }
    close f_drivers; # Cierra drivers-sospechosos.txt
    print "\n";
    print "Coincidencias: $c\n"; # Muestra número de coincidencias
}
 
# Función de búsqueda por cada $path

sub proceso($path,$filein,$fileinmd5) 
{
    opendir DIRECTORY, $path or die; # Abre la carpeta $path
 
    # Recorre $path y deja en $file cada nombre de archivo
 
    while ($file = readdir(DIRECTORY)) 
    {  
        if ( -d $path.$file ){# $file es un directorio}
        else # $file es un archivo
        {  
            $filemd5 = file_md5_hex($path.$file); # Calcula el MD5 de $file
   
            if ($filemd5 eq $fileinmd5) # Si los MD5 coinciden, premio
            {
                print "\n";
                print "Cuidadito, $path$file tiene el mismo MD5 que $filein.\n";
                $c++;
            }
        }
    }
}

todo();

------- fin drivers-sospechosos.pl ---------------------------------------------

Este proceso normalmente tarda un buen rato, así que podeis ir a preparar un café y esperar a que a la vuelta no haya premio.

Asegurando a Apache2

Llevo poco tiempo con Apache2 en Debian etch (la versión estable actual) y lo que me interesa es realizar un sitio web con comunicación cifrada (OpenSSL) y que tenga algún directorio privado protegido con nombre de usuario y contraseña.

La instalación y configuración de Apache2 con soporte de OpenSSL no da problemas en Debian etch, pero el tema de la autenticación del directorio privado me hizo dar más vueltas.

La documentación de Apache2 ofrece un sistema de autenticación simple que requiere un archivo con los nombres de los usuarios para autenticarlos, pero, ¿quien quiere crear un archivo con usuarios cuando ya tenemos usuarios locales? De la misma forma, utilizar el soporte de autenticación con MySQL (auth_MySQL) supone trabajo extra, aunque es más eficiente si tenemos que autenticar a una montaña de usuarios.

Al final llegué al sistema de autenticación PAM. PAM tiene bastantes implementaciones para autenticar incluyendo a Apache2 y permite autenticar a los usuarios locales que queramos, utilizando un grupo para ello. No obstante, una vez instalado el módulo de PAM para Apache2, hay que realizar una serie de ajustes en el sistema para que funcione.

He documentado todo el proceso aquí, para tenerlo como referencia.

La persistencia del adware

Fragmento extraido de http://philosecurity.org/2009/01/12/interview-with-an-adware-author

¿Puedes contarnos más sobre como hacer que el adware sea complicado de eliminar en un ordenador?

Si. Primero prefiero contarte como funciona el adware. El objetivo fundamental del adware son los usuarios de Internet Explorer porque obviamente es el más utilizado en el mercado. Además, tienden a ser los más ingenuos. Si utilizas IE quiere decir que, o no pones cuidado, o no sabes nada sobre vulnerabilidades en IE.

IE tiene un mecanismo llamado Browser Helper Object (BHO), que básicamente es un trozo de código ejecutable que consigue información de las solicitudes web que se están produciendo. Esto corre en el proceso actual del navegador, quiere decir que puede hacer cualquier cosa que pueda hacer el navegador - y esto básicamente quiere decir: cualquier cosa. Nosotros podemos tener un BHO que actualmente es el servidor de ads, y lo hemos realizado de forma que para eliminarlo tengas que eliminar todas las instancias del navegador. Esto es una pequeña parte en cuanto a la persistencia.

Si además tienes un instalador, un pequeño ejecutable, puedes crear una entrada en el Registro para que en cada reinicio el instalador compruebe que el BHO existe. Si existe, bien. Sino existe lo instala. Esto funciona hasta que alguien elimina el ejecutable.

Lo siguiente es crear un ejecutable que continuamente compruebe cada 10 segundos que el BHO está activo y en su sitio. Si así es, perfecto. Sino, el ejecutable lo instalará. Para asegurarse de que el ejecutable sea dificilmente detectable, desarrollamos un algoritmo para hacer que los nombres de estos ejecutables sean aleatorios, a la vez que estén relacionados con el ordenador anfitrión y que sea complicado descubrirlos. Creo que utilizabamos los primeros 6 u 8 caracteres de la codificación DES de la dirección MAC del ordenador. Codificas la MAC con DES, tienes en cuenta los primeros 6 u 8 caracteres y ya está. Esto está muy bien. La pega es que el archivo en sí podía ser el mismo binario. Si sumas el MD5 del archivo siempre sería el mismo, y siempre estaría en el mismo ordenador (con esa MAC).

Lo siguiente que hicimos fue una función para repartir funciones, que podía ir dentro de un ejecutable, tomando funciones y repartiéndolas aleatoriamente, de forma que las firmas de los archivos estén mezcladas. También mezclábamos un montón de punteros con cada función corriendo. Esto cambia completamente la forma del ejecutable.

Luego creamos un lanzador, que es un minúsculo trozo de código escrito en ensamblador que descifraba el ejecutable en memoria y lo ejecutaba. Al mismo tiempo también creabamos un proceso ejecutable virtual. Nunca he oído que alguien hiciera esto antes. Windows tiene una cosa llamada Create Remote Thread. Semánticamente quiere decir: eres un proceso, yo soy un proceso distinto, puedo llamarte y decirte "¡Oye! tengo este código, y me gustaría que lo ejecutaras". Tu dices "Claro" porque eres un proceso de Windows -tu eres un hippie que crees en el amor libre-. Los procesos de Windows, dicho sea de paso, son peligrosamente promíscuos. Por tanto, podemos pillar unos cuantos procesos de Windows y darles un trozo de código para que lo ejecuten. Cada proceso conoce a los dos anteriores (el anfitrión y el que le hemos dado que es el trozo de código), y de esta forma podemos hacer un anillo para que se ayuden mutuamente, ¿ok?.

Hasta ahora tenemos una entrada en el registro, un ejecutable, nombres aleatorios para ejecutables, un ejecutable que es repartido en cada ordenador, uno de ellos está cifrado -y para más ofuscación- un ejecutable que ni siquiera se ejecuta como tal. Esto se ejecuta simplemente en forma de hilos. Ahora, esos hilos pueden comunicarse entre sí, pueden comprobar que el BHO está activo, y que cualquier otro software que queramos también esté bajo control.

Hay una cosa más avanzada que empezamos a realizar pero no terminamos de probar, y es prescindir de los hilos y utilizar los manejadores de las interrupciones.Resulta que en Windows puedes acceder facilmente al manejador de interrupciones. De hecho, puedes registrar con el OS un trozo de código para manejar una interrupción dada. Todo lo que tienes que hacer es pillar una interrupción, y cuando ésta se inicie, haces tu trabajo y listo. Nunca hemos hecho esto pero es algo que estamos pensando hacer.

Creamos claves de registro y nombres de archivos que no se podían modificar, explotando una "desajuste de impedancia" entre la API de Win32 y la API de NT. Windows XP está basado en el kernel de NT. La mayor parte de NT es un sistema Unicode, y debido a ello, los strings internamente son Unicode de 16-bit. La mayor parte de la API Win32 es ASCII. Existen strings que puedes expresar como Unicode 16-bit pero no puedes expresar en ASCII. Sorprendentemente, puedes ver cosas con un Null en medio de ello.

Esto quiere decir que podemos, por ejemplo, escribir una clave de Registro que contenga un Null. Debido a que la interfaz de usuario está basada en la API Win32, éste podría ver la clave, pero no podría modificarla porque no sabría interpretar el Null. De esta forma podemos hacer que las claves del Registro sean invisibles o inmodificables para cualquiera que utilice la API Win32. Esto es muy interesante, no para la gente común, pero sí para nuestros competidores y para las compañías antivirus.

También escribí un controlador y luego un controlador de impresora. Cuando escribes un controlador puedes hacer las cosas más locas que puedas imaginar, incluso más locas todavía que pudieras hacer normalmente con Windows. Esto ocurría cuando Eliot Spitzer demandó a la compañía y empezó a decaer. Tomaron una mala decisión justo cuando empezaron a dar más visibilidad a la compañía y entonces todo el mundo al mismo tiempo me quería para deshacerse de nuestros competidores y nosotros mientras tanto trabajando en todo lo anterior.

Por supuesto que se trataba de un plan. No nos gustaba escribir un nuevo programa en C cada vez que queríamos echar a alguien fuera de una máquina. Todo el mundo decía, "Lo que necesitamos es algo configurable". Yo decía, "Instalemos un lenguaje basado totalmente en Turing", y para eso utilicé tinyScheme, que es un intérprete muy pequeño y rápido con licencia BSD que puede compilarse en un ejecutable de 20kb, si sabes lo que estas haciendo.

A veces, en vez de escribir ejecutables independientes, utilizamos un gusano, así podemos escribir código, lo ponemos en el servidor, e inmediatamente las cosas deberían oscurecerse, llegando a repartirse el código en una guerra de entre 4 y 10 millones de nodos en red.