-[ 0x0A ]--------------------------------------------------------------------
-[ John The Ripper "over MPI" ]----------------------------------------------
-[ by set-ezine ]----------------------------------------------------SET-35--


Hace apenas unos meses, en la revista @RROBA, hablamos de pasada sobre una 
versión de"John The Ripper" distribuida bajo un "live CD" como tantas otras 
versiones de linux. La característica de esta rama no oficial del famoso 
cracker es su capacidad de utilizar la potencia total de una maquina multicore 
o de poder distribuir de forma automática la tarea de crackear una hash por 
fuerza bruta. Nos podríamos preguntar porque los creadores de JTR no han 
soportado de forma activa esta rama de su criatura, razones puede que existan 
muchas pero lo único cierto es que si queremos hacer algo especial tenemos que 
andar sobre nuestras propias piernas. Hoy pretendemos contaros los problemas y 
posibles soluciones cuando se pretenden hacer cosas distintas a lo que nos 
tiene acostumbrada nuestra sociedad. 

RESPUESTAS DE Solar Designer

En cualquier distribución de John The Ripper, existe en el directorio DOC un 
archivo llamado FAQ, ahí el creador de JTR nos dice, aparentemente, con 
claridad, porque no se soporta de forma activa una distribución de JTR hecha 
para una maquina multiprocesor o para correr bajo un proceso distribuido. Según 
sus propias palabras, simplemente no es necesario, ya que se puede fácilmente 
planear la distribución de las tareas de forma manual. Una de las maneras es 
lanzar john en diferentes sesiones atacando objetivos de longitud distinta. 
Esto se puede hacer fácilmente con el modo "incremental" y jugando con la 
configuración de los parámetros "MinLen" y "MaxLen". Aparentemente se pueden 
lanzar varias sesiones de john y diferenciar el avance a través del parámetro 
"--session" 

No se a vosotros, pero a mi me ha dado dolor de cabeza solo imaginar la 
complejidad de la operación. Mejor dicho, es fácilmente explotable, si lo 
único que se desea es utilizar al máximo la potencia de una maquina multicore, 
pero si lo que nos interesa es atacar una hash difícil, lanzar la tarea y 
olvidarnos de la historia hasta que el objetivo haya sido alcanzado, no es 
precisamente el consejo de Solar el que nos puede ayudar y estamos seguros que 
nuestro amigo tiene la inteligencia suficiente para saberlo.

Es casi seguro que su problema reside en no verse involucrado en un ataque 
masivo en donde se haya utilizado su criatura en forma distribuida, ya que este 
tipo de cosas pueden acabar con una visita de la policía a tu casa, en el mejor
de los casos o al menos esta es nuestra opinión. Pero dado que no podemos 
obtener respuestas fáciles y transparentes en ambientes públicos hay que 
plantear las preguntas en otros entornos donde podamos obtener otras respuestas.

RESPUESTAS DE SET EZINE

Como no estamos dispuestos a confiar en la primera respuesta, ya que somos 
escépticos profesionales, nos complace encontrar otras soluciones, lo que 
ocurre es que se requiere algún incentivo para que decidamos movernos y 
utilizar nuestras energías para conseguir un objetivo concreto, veamos como 
empezó todo.

El caso es que en un anónimo despacho, dentro de un flamante edificio de vidrio 
y cemento perteneciente a una de tantas corporaciones que velan por proveernos 
de servicios o cosas, vitales o inútiles, sonó un teléfono con insistencia. 
Nuestro viejo amigo Perico Viajero no tenia muchas prisas por responder, estaba 
enfrascado en responder a un e-mail idiota sin que se notara demasiado su 
opinión sobre el cretino que lo había escrito, cuando vió por el visor de donde
procedía la llamada y se decidió a contestar. "¿Si?", "Oye, tenemos tu nuevo 
laptop", fue la rotunda respuesta. Era uno de los pocos dentro de la anónima 
sociedad, que recibía, por motivos ignotos, un cierto trato personalizado del 
departamento informático. "Vale, ya era hora. El que tengo empieza a tener 
problemas de disco duro", contestó con soltura Viajero "Si no hicieras cosas 
raras con tu maquina, estas serian mas longevas. En dos días lo tendrás listo".

La nueva maquina que recibió fue un "dual core" de esos de ultima generación. 
Viajero se emocionó un poco al verlo, la posibilidad de utilizar la nueva 
capacidad de calculo mientras haraganeaba en los vestíbulos de los aeropuertos 
le despertó el apetito de volver a intentar nuevos ataques sobres hash  que en 
un pasado habían resistido a sus ataques. Lo primero que se le ocurrió fue 
desenterrar una vieja hash de una maquina Win2000 que yacía en un despacho de 
un país de habla germánica. La clave pertenecía a una clave LM, que como todo 
el mundo debiera saber utiliza una clave de 14 byte, concatenada con ceros si 
no tiene esta longitud, convierte en mayúsculas todas las letras alfabéticas y 
dividida en dos mitades. Cada mitad es cifrada de forma separada mediante el 
algoritmo DES sin aplicar ningún tipo de salto. Todo ello parece ser hecho para 
facilitar la vida de los hackers mas tontos del mundo, pero los administradores,
menos inteligentes intentan complicarles la vida usando caracteres que no 
existan en los teclados de tipo "QWERTY" de los mas normales o si simplemente 
se tiene a disposición un teclado configurado para escribir en esa lengua, es 
sumamente facil introducir un par de caracteres alemanes.

En el caso que nos ocupa la primera parte la clave indicaba que la password era
una derivación de la palabra "administrator", pero intercalando números y 
caracteres especiales. Todo ello no es gran problema salvo si estos caracteres 
especiales son un tanto raros, tal como lengua alemana u otra cosa mas exótica, 
en este caso de poco sirven los múltiples diccionarios rainbow que existen en 
la red, solo un ataque por fuerza bruta, pero aplicando algo de inteligencia 
puede ser de alguna utilidad. 

Viajero se planteó construir un ataque en base a "john" utilizando un modo 
"external" especifico para atacar cinco o seis caracteres en forma bruta. 
Calculaba que con los procesadores trabajando en paralelo podía atacar 
fácilmente cinco caracteres y si la cosa se complicaba debería plantearse un 
ataque conjunto con varias maquinas. Para ello pensó en utilizar la versión de 
"john" adaptada para trabajar en redes neuronales tipo MPI.

Todo muy bonito pero, la versión de john en cuestión solo viene distribuida 
bajo sus fuentes lo que significa que si se desea ejecutarlo hay que compilarlo 
y enlazarlo. Si ademas deseamos hacerlo bajo Windows, todo hay que hacerlo bajo
este paraguas y tradicionalmente esto supone utilizar herramientas de pago. La 
documentación disponible no era extraordinaria pero parecía claro que era 
necesaria una versión de MPI instalada en la maquina donde se quería compilar. 
Estudiando un poco mas la web http://bindshell.net/tools/johntheripper/ vio que
todas las pruebas habían sido hechas con la versión MPICH2-1.0.2 operando bajo 
Linux o MacOSX. Como su intención era Windows el escenario era radicalmente 
distinto, supuso que las cosas no iban a ser fáciles y el tiempo se encargó de 
darle razón.

A veces es sumamente útil cuando se emprende algo que supones va a ser 
complicado escribir sobre un papel cual es el objetivo. Después de reflexionar 
un rato, Viajero anotó algo sobre un papel y después leyó complacido lo 
siguiente. Compilar bajo cygwin "John The Ripper" versión MPI (MPICH2) para 
poderlo ejecutarlo sobre Win2000 y WinXP. 

INSTALACION DE MPICH2 BAJO CYGWIN

Lo primero que hizo fue bajarse  de la web del departamento "Argonne National 
Laboratory Group" de la Universidad de Chicago (www.mcs.anl.gov) el archivo 
comprimido mpich2-1.0.6.tar.gz, lo descomprimió en un directorio temporal y 
leyó en el README que le haría falta en un entorno linux, el compilador gcc, 
gfortran o g77, el compilador g++, python 2.2 o superior y como opción el 
compilador Fortran 90.

Después empezó con la laboriosa tarea de instalarse el cygwin con todos los 
anteriores requisitos. No es difícil ya que basta con bajarse de www.cygwin.com
el ejecutable setup.exe, lo mejor es colocarlo en un directorio accesorio y 
lanzarlo con una conexión a internet activa, ya que este pequeño programa lo 
que hace es proponer una instalación standard y va buscando los paquetes que le
hemos indicado.

Es en la selección de los paquetes donde Viajero casi perdió la cabeza y los 
nervios. La tarea de seleccionar uno a uno y comprobar las dependencias no es 
de lo mas divertido del mundo, aunque cygwin presta una mano de forma activa. 
También hay que saber que en caso de dificultad recalcitrante siempre puedes 
elegir directamente los paquetes en www.cygwin.com/packages/ 

Una vez la primera parte de la tarea estaba terminada solo faltaba la segunda, 
o sea instalarse MPICH2. Bastaba con seguir cautelosamente las instrucciones que
pudo leer en el archivo README que encontró al desempaquetar   
mpich2-1.0.6.tar.gz. No fue difícil, tan solo laborioso. Desempaqueto sobre un 
directorio de su elección "tar xfz mpich2.tar.gz" y se situó sobre el raíz "cd 
mpich2-1.0.6". Creó un directorio donde situaría posteriormente el paquete
"mkdir /home/viajero/mpich2-install", después configuró el paquete 
"./configure --prefix=/home/viajero/mpich2-install 2>&1 | tee c.txt" 
La ultima parte de la instrucción es todo un detalle por parte de la 
Universidad de Chicago, ya que, vaya todo bien o no, se crea un fichero "c.txt"
donde hay copia de la ejecución. En caso de problemas Viajero sabia que podía 
enviarlo a "mpich2-maint@mcs.anl.gov" para ayudarle a desenredar la madeja.

Pero todo fue como una seda, lo cual es bastante raro, ya que como sabemos 
Viajero se encontraba bajo un cygwin y no sobre una distribución real de linux. 
Solo quedaba construir el paquete con "make |& tee m.txt" y tambien en este 
caso se crea un fichero "m.txt" que se puede enviar a sus creadores en caso de 
problemas. Finalmente se instalan los ejecutables y scripts en el directorio 
bin "make install 2>&1 | tee mi.txt" y finalmente se actualiza el PATH para que 
todos sepan donde están "PATH=/home/viajero/mpich2-install/bin:$PATH" , "export 
PATH"

Viajero temía algún problema en el momento de comprobar la instalación, pero 
tanto "which mpd" como "which mpiexec" dieron los resultados apetecidos. MPICH2 
estaba funcionando correctamente bajo cygwin. Paso libre para compilar John The 
Ripper, versión MPI.

Aunque ahora se encuentran en la versión 
"http://bindshell.net/tools/johntheripper//john-1.7.2-bp17-mpi7.tar.gz" y fue 
ésta la que utilizó Viajero para hacer sus pruebas. Descarga sobre un 
directorio temporal dentro de cygwin y desempaquetado de forma standard da como 
resultado tres directorios y un fichero README. Del README rápidamente se dio 
cuenta que lo mejor era "pasar" de ‚l. Se volvió hacia el directorio "src" e 
intentó lo clásico con "John The Ripper", un simple 
"make win32-cygwin-x86-sse2" debería rápidamente crear un ejecutable en el 
directorio "run", sin embargo lo que cosechó fue un mensaje de error diciendo 
que no se encontraba "mpicc", en concreto el mensaje era 
"make[1]: mpicc: Command not found". "mpicc" es es solo una utilidad creada 
especialmente para poder compilar en ambientes MPI. Una consulta rápida a la 
mail list (john-mpi-subscribe@bindshell.net) recibió la sorprendente respuesta 
de que lo mejor era que utilizara gcc en lugar de mpicc

Con un editor de lo mas normal, Viajero, substituyó en el fichero "Makefile" 
todas las ocurrencias "mpicc" por "gcc" y las cosas marcharon un poco mejor,...
pero solo un poco. Ahora el mensaje fue 
"bench.c:38:17: mpi.h: No such file or directory". El mensaje no podía ser mas 
claro, "make" era incapaz de encontrar las librerías que pertenecen a la 
distribución de MPI. Aparentemente el problema es fácil de resolver, basta con 
añadir al PATH de cygwin la dirección donde se encuentran las fuentes que 
deseamos utilizar. Viajero deseaba hacerlo de forma inteligente, o sea que no 
tuviera que modificar PATH a cada arranque, y esto se consigue modificando el 
fichero "cygwin.bat" que se encuentra en directorio raíz de cygwin. Con añadir 
la linea "PATH=%PATH%:/dirección-deseada" al susodicho "bat" y a correr.

Digamos que correr no corrió mucho, ya que la siguiente compilación le dejo un 
amargo sabor de boca con un esóterico mensaje sobre una linea de uno de los 
includes. No era posible. Algo iba irremediablemente mal. Volvió a consultar la 
lista de distribución de bindshell que le respondieron rápidamente. "Si quieres
compilar un programa basado en MPI bajo cygwin y que posteriormente corra bajo 
Windows, tienes que borrar la instalación de MPICH2 bajo cygwin e instalar la 
versión para Windows". Se dice mas pronto de lo que se hace y a Viajero le dio 
dolor de cabeza nada mas pensar en lo que se le venia encima, pero nada se 
termina si no se empieza, así que lo mejor en estos casos es dejarse de 
lamentarse y ponerse manos a la obra.

INSTALACION DE MPICH2 BAJO WinXP 

Viajero empezó por el principio, o sea buscar las herramientas adecuadas en 
este caso el instalador. Está en 
"http://www.mcs.anl.gov/research/projects/mpich2/downloads/index.php?s=downloads"
, elegir el fichero correcto, "mpich2-1.0.7-win32-ia32.msi" y en este caso 
copiarlo en un sitio que después se debe recordar y lanzarlo con derechos de 
administrador. El directorio por defecto donde se instala es 
"C:\Program Files\MPICH2" y bajo ‚l se encuentran "include", "lib", donde se 
encuentran "headers" y librerias y tambien el directorio "bin" donde están los 
ejecutables. Durante la instalación se le pidió una palabra de paso que en 
teoría después se debe reutilizar sobre el resto de maquinas donde se quiera 
monta el anillo de CPUs, pero de eso hablaremos mas tarde. Viajero se limitó a 
crear un password que no tuviera nada que ver con ‚l ni con sus andanzas mas 
habituales y anotarla cuidadosamente.

Terminado esto, tuvo que desinstalar laboriosamente todo lo que se encontraba 
bajo cygwin para evitar interferencias entre las dos instalaciones sin 
olvidarse de todos los PATH habidos y por haber, que en esto, todo el entorno 
de Windows es sumamente quisquilloso y tiene una memoria prodigiosa e 
inoportuna que fastidia cuando menos te lo esperas. Finalmente todo quedó listo 
para la siguiente etapa. La compilación.

LA COMPILACION 

Contento como niño con zapatos nuevos, Viajero volvió a probar con 
"make win32-cygwin-x86-sse2", con desesperación recibió de nuevo una catarata 
de mensajes que se podían reducir a que seguían sin encontrarse las librerías. 
Y sin embargo Viajero había modificado convenientemente el PATH de cygwin para 
que buscara los programas en donde habían sido instalados automáticamente por 
MPICH2 o sea en "C:/Program Files/MPICH2/include" ¿Que había podido fallar? Le 
costó bastante darse cuenta que estaba cometiendo un error de principiante. 
"make" no va a buscar las librerias y headers en función del contenido de las 
variables de entorno, hay que indicarse lo de forma explicita en el propio 
"Makefile". La razón no la conocía, pero bien pudiera ser que los programadores
de esta utilidad se quisieran asegurar que las cosas estaban donde el 
programador desea y no donde le parece al Sistema Operativo el mejor sitio. 
Esto los utilizadores de Windows puede que no lo entiendan, pero los de 
Unix/Linux lo comprenden perfectamente.

Viajero modificó levemente el Makefile para que encontrara la joya de la corona.
En este caso ademas había que acordarse que se estaba compilando bajo cygwin y 
por tanto las cosas están en sitios que aparentemente no son los mas evidentes.
En este caso tuvo que cambiar la linea 
"CFLAGS = -c -Wall -O3 -fomit-frame-pointer" por 
"CFLAGS = -c -Wall -O3 -fomit-frame-pointer
          -I/cygdrive/c/Progra~1/MPICH2/include" 
Véase con atención que los includes apuntan a  
"/cygdrive/c/Progra~1/MPICH2/include" y no a 
"Progra~1/MPICH2/include" ya que cygwin mapea todo lo que se encuentra bajo el 
disco principal a un dispositivo virtual llamado "/cygwin/c/". Es una de las 
características y gracias de este simulador. A Viajero le salieron algunas 
canas hasta que no se dio cuenta de lo que pasaba.

Quien piense que hasta aquí llegaron las desventuras de Viajero, intuirá que 
nada mas lejos de la realidad, aunque solo sea porque el articulo le falta un 
buen trozo para terminar. El siguiente problema fue que "make" se lamentaba con 
amargura que no encontraba algunos componentes de las librerías. Vuelta a 
consultar a la lista de distribución para descubrir que las librerías no son 
las mismas si se quiere compilar desde cygwin utilizando una distribución 
MPICH2 instalada bajo cygwin que si esta instalada en Windows. Afortunadamente 
fue rápida la solución ya que le informaron de exactamente cuales eran las 
librerías a copiar en "/MPICH2/lib" y substituir la linea en Makefile que decía
"LDFLAGS = -s -lm" por otra donde ponía 
"LDFLAGS = -s -lm -L/cygdrive/c/Progra~1/MPICH2/lib -lmpicxx -lfmpich2 -lmpi"
Aquí hay un pequeño detalle, mpicxx.h es un header y no una librería, pero el 
caso es que las quejas sobre las librerías inexistentes desaparecieron, solo 
para que aparecieran nuevos problemas.

El mensaje era siempre parecido 
"john.o:john.c:(.text+0x33): undefined reference to `_MPI_Init'", o sea que 
había un procedimiento, variable o parámetro que se no encontraba en ninguna 
parte. Fueron duros días los que tuvo que sufrir Viajero, ya que _MP_Init esta 
claramente definido en "mpi.h" y sin embargo parecía ser ignorada durante la 
operación de enlazado. Fueron de nuevo los chicos que desarrollan MPICH2 que le
identificaron el problema y le indicaron la solución. Es algo no ciertamente 
intuitivo y forma parte de la filosofía que siguen los enlazadores a la hora de
unir todas las piezas precompiladas. Hay que acordarse que en el momento de 
enlazar, si el archivo "a.o" utiliza símbolos definidos en el archivo "b.o", 
hay que especificar "a.o" antes que "b.o". Si, definitivamente no es intuitivo,
pero el caso es que cuando Viajero cambio la linea 
"$(LD) $(JOHN_OBJS) -lkernel32 -o ../run/john.exe" 
por la linea 
"$(LD) $(JOHN_OBJS) -lkernel32 $(LDFLAGS) -o ../run/john.exe" 
se acabaron sus problemas y encontró un magnifico fichero llamado john.exe bajo
el directorio "run". Ya tenia el ejecutable, ahora no había mas que utilizarlo.

MPICH2, JOHN, DUAL CORE. 

La instalación de MPICH2 bajo Windows no solo crea una serie de librerías y 
headers,  también instala un servicio llamado "smpd" y un ejecutable llamado 
"mpiexec.exe" que sirve para lanzar el programa "MPIzado". De todas formas 
Viajero era la primera vez que utilizaba estos entornos y siempre los comienzos 
son difíciles, así que hechó mano de un par de utilidades que vienen con la 
distribución. "wmpiregister" sirve para configurar un anillo y como el primer 
paso de Viajero era solo aprovechar los dos procesadores de un "DUAL CORE" 
supuso que podía pasar de sus servicios. Después esta "wmpiregister" muy util 
para registrar un nombre y su password en el registro de Windows. De utilidad 
dudosa si eres el administrador de la maquina. El que tiene muchas mas 
posibilidades es "wmpiexec". Es simplemente un "front end" que hecha una mano. 
Viajero tuvo que especificar donde estaba el "john" que quería lanzar  y las 
diversas opciones. Lo mas importante era tener presente que solo deseaba lanzar
su programa en una sola maquina, para hacerlo tuvo que checkear "more options" 
y en la opción "host" poner "localonly".

Al lanzar el "john" mediante "execute" aparentemente todo funcionó 
correctamente, al comprobar mediante "Task Manager" la situacion de las dos 
CPUs, comprobó que ambas estaban al 100%. Pensó que ya habia encontrado la 
solución definitiva hasta que se le ocurrió parar el ataque, lo intentó, pero 
no lo consiguió, un extraño bug en el programa se lo impedía. Tuvo que pararlo 
con el "Task Manager" y rearrancarlo, después con la opción "shown" vio 
exactamente cuales eran las opciones y comandos que utilizaba MPI, después 
abrió una sesión "cmd" y desde allí recopió lo que había observado. Y desde 
allí si que podia pararlo, el problema es que no podía utilizar prácticamente 
la maquina ya que ésta consumía todos los recursos para "john-mpi". Viajero lo 
que deseaba era que su maquina consumiera todos los tiempos muertos, no que lo 
matara con esperas desesperantes para abrir una vulgar hoja "excel".

La solución se encontraba en una de las múltiples opciones que tiene "mpiexec" 
y que consiste en fijar la prioridad de la sesión. Finalmente lanzo una sesión 
con la instrucción 
"mpiexec.exe -hosts 1 localonly 2  -localonly -priority 1 
-noprompt john.exe -session=pims -e=prepend-pims hash-pims.txt", 
ya que tenia una serie de hash interesantes en el fichero hash-pims.txt y había
creado un modo especial extendido con el nombre de "prepens-pims", para poder 
recuperar la sesión la había denominado "pims".

El resultado fue bastante agradable, ambos procesadores marcaban al 100%, pero 
cuando quería trabajar para su empresa, la carga se reducía automáticamente, 
con el único peaje de una ligera espera cuando cambiaba de tareas. Todo parecía 
funcionar correctamente y Viajero muy contento, interrumpió la sesión y 
construyó un fichero "bat" que contenía la siguiente instrucción 
"mpiexec.exe -hosts 1 localonly 2  -localonly -priority 1 -noprompt john.exe 
             -restore=pims"
y que copió en su directorio "...\Programs\Startup". Seguro de su éxito no hizo
mas pruebas.

A la mañana siguiente, cuando llego a su trabajo, después de hacer los falsos 
saludos de todos los días, conectó y encendió su ordenador, que después de 
hacer todas las comprobaciones y rutinas que Windows nos tiene acostumbrado, 
lanzó su especialmente construido fichero "bat",.... que en unos segundos se 
detuvo. Según el mensaje en pantalla no existían ni "john_rec.rec.0" ni tampoco 
"john_rec.rec.1". Evidentemente hay un bug en el programa. John crea por 
defecto un fichero "john.rec" donde se guardan los datos necesarios para 
recuperar una sesión interrumpida. En caso de que se especifique una sesión con
un nombre en concreto, por ejemplo "pims", se crea un fichero llamado 
"pims.rec". Como en este caso había que recuperar dos sesiones, una para cada 
procesador, john había creado dos ficheros distintos denominados "pims.rec.o" y
"pims.rec.1", pero después hacia caso de la opción "restore=pims" y seguía 
buscando sus amados "john.rec".

A Viajero le dolía la cabeza ya que mientras estaba buscando el problema una 
amable secretaria de esas que parecen puestas en este mundo solo para ser lo 
mas inoportunas e inútiles, le había estado dando la lata sobre un documento, 
evidentemente anodino, que debía ser firmado con urgencia. Por tanto ni se le 
ocurrió buscar el bug en los fuentes, simplemente cambio los nombres de los 
ficheros para que john los encontrara, este los descubrió a la primera. El 
contento y Viajero mas. 

Solar Designer, al que hemos mencionada al principio del articulo podrá decir 
lo que quiera, pero lo cierto que un john "MPIzado" de esta forma se comió un 
par de hash en apenas dos días , cuando la experiencia de Viajero le decía que 
le hubiera costado el doble con el método clásico y todo ello sin tener que 
preocuparse ni de repartir tareas ni de hacer cálculos. Dos únicos 
inconvenientes. Probablemente debido a otro bug en el programa no se puede ver 
el avance del ataque y el otro es que la maquina funciona a plena potencia 
desde el momento en que se enciende y esto, en opinión de Viajero, no puede ser
bueno par la salud del laptop ni para su longevidad. De todas formas la 
password alemana que fue el motivo de toda esta carrera contra los elementos 
cayó en cosa de una semana.

MPICH2, JOHN, EN RED 

Perico Viajero tampoco deseaba freír la maquina que habían depositado a su 
cuidado. Puede que a otros no les guste que la inversión de sus escuálidos 
ahorros desaparezca en una nube de humo, poco virtual y bastante maloliente. 
Viajero pensó que otra opción era organizar un anillo de maquinas. Según la 
documentación de MPI esto es posible hacerlo si somos administradores del 
DOMAIN de la red, pues es ella la encargada de permitir la entrada en cada una 
de las maquinas que la componen, en la practica esto no es cierto, basta con 
tener el mismo usuario registrado en las maquinas que deseamos utilizar para 
que estas se pongan a trabajar obedientemente. Viajero hizo la prueba con éxito
con dos maquinas fijas, una con Windows 2000 y otra con WinXP. A continuación 
añadió un viejo laptop que ni siquiera tenia SSE2. Como anécdota, esta vieja 
reliquia se negaba a hacer su parte y Viajero tuvo que recompilar john con la 
option "any" y esta vez el viejo laptop se agregó obedientemente al anillo 
aportando su granito de potencia.

Por falta de espacio no podemos detallar los entresijos de la operación, que 
tampoco es sencilla, pero si demuestra que es posible infectar varias maquinas 
en una red y conseguir que se pongan a trabajar en tu honor para fines honestos
o deshonestos.

2008 SET, Saqueadores Ediciones Técnicas. Información libre para gente libre
www.set-ezine.org
web@set-ezine.org

*EOF*